Allow docs-only PRs without validation sections #73

Closed
opened 2026-06-27 14:56:20 +01:00 by vnprc-agent · 1 comment
Contributor

allod change submit still hard-requires every PR body to include a ## Validation section:

allod: PR body must contain a '## Validation' section

That now conflicts with the Allod memory guidance being added in allod/memory#6: docs-only PRs do not need validation sections unless a command checks a real failure mode, and agents should avoid process-noise comments when there are no findings worth sharing.

Update allod change submit so routine documentation-only PRs can be submitted without a fake validation section. The implementation should also update the submit tests in tests/allod-change.sh, which currently assert that missing validation is always rejected, including dry-run mode.

Possible implementation approaches:

  • add an explicit option such as --docs-only or --no-validation-required;
  • infer docs-only changes from the branch diff when that is reliable;
  • keep validation required by default for code or generated-behavior changes.

The important contract is that allod change submit should not force meaningless validation boilerplate for docs-only PRs, while still preserving useful validation requirements for code, generated artifacts, provisioning behavior, and other executable changes.

`allod change submit` still hard-requires every PR body to include a `## Validation` section: ```text allod: PR body must contain a '## Validation' section ``` That now conflicts with the Allod memory guidance being added in allod/memory#6: docs-only PRs do not need validation sections unless a command checks a real failure mode, and agents should avoid process-noise comments when there are no findings worth sharing. Update `allod change submit` so routine documentation-only PRs can be submitted without a fake validation section. The implementation should also update the submit tests in `tests/allod-change.sh`, which currently assert that missing validation is always rejected, including dry-run mode. Possible implementation approaches: - add an explicit option such as `--docs-only` or `--no-validation-required`; - infer docs-only changes from the branch diff when that is reliable; - keep validation required by default for code or generated-behavior changes. The important contract is that `allod change submit` should not force meaningless validation boilerplate for docs-only PRs, while still preserving useful validation requirements for code, generated artifacts, provisioning behavior, and other executable changes.
Member

After implementing the --docs-only flag initially proposed here, we reconsidered whether the validation check itself is worth keeping. The body_has_validation_heading check is a syntactic gate that can't verify quality — agents can trivially satisfy it with boilerplate. The real forcing function is agent memory guidance, which can apply judgment about when a validation section is meaningful.

Rather than adding a flag to work around a check that wasn't pulling its weight, PR #74 removes the validation enforcement entirely: deletes body_has_validation_heading, the --docs-only flag, and all related tests. Net -44 lines, no new options.

The ## Validation convention for code PRs continues to be guided by agent memory, where it belongs.

After implementing the `--docs-only` flag initially proposed here, we reconsidered whether the validation check itself is worth keeping. The `body_has_validation_heading` check is a syntactic gate that can't verify quality — agents can trivially satisfy it with boilerplate. The real forcing function is agent memory guidance, which can apply judgment about when a validation section is meaningful. Rather than adding a flag to work around a check that wasn't pulling its weight, PR #74 removes the validation enforcement entirely: deletes `body_has_validation_heading`, the `--docs-only` flag, and all related tests. Net -44 lines, no new options. The `## Validation` convention for code PRs continues to be guided by agent memory, where it belongs.
vnprc closed this issue 2026-06-27 15:18:43 +01:00
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
allod/tools#73
No description provided.