Roll the git-workflow block out across the fleet once a release carries the hook #1158

New issue

Open

opened 2026-08-20 08:28:07 +00:00 by coilyco-ops · 1 comment

coilyco-ops commented

2026-08-20 08:28:07 +00:00

Member

Follow-up to #1150 / PR #1157, which authors the git-workflow hook, the generate_git_workflow renderer, and scripts/apply-git-workflow.py here in agentic-os.

The fleet rollout is deliberately deferred. DEFAULT_HOOK_IDS in scripts/apply-agentic-os-hooks.py stays unchanged, because test_apply_agentic_os_hooks.py guards it: a hook id can only appear there once a tagged aos-precommit-v* release carries the hook.

What is left

Wait for the aos-precommit-v* train to advance past the merge of #1157. Merging a hook input triggers it.
Run python3 scripts/apply-git-workflow.py across the workspace so every AGENTS.md carries the block. A dry run today resolves 12 repos by declared lane: agentic-os-hardware, agentic-os-kai, agentic-os-xxx, deploy, eco-app, eco-mods, eco-ops, coilysiren on merge-remote-main, agentic-os, infrastructure, ward on pull-request-and-merge, and cli-guard undeclared.
Land each repo's stamped AGENTS.md on its canonical main, per that repo's own lane.
Only then add git-workflow to DEFAULT_HOOK_IDS and run the hook rollout.

Order matters. Enabling the hook before the block lands breaks every commit in that repo until the applier runs.

Also worth deciding

cli-guard declares no ward.workflow lane and renders the undeclared variant. Either declare its lane or accept the undeclared wording.
deploy declares merge-remote-main, though AGENTS.md prose lists it among the five PR-lane repos. The generator renders what the frontmatter declares, so the prose and the frontmatter disagree somewhere. Worth reconciling before the stamp makes the disagreement visible in every repo.
The per-repo rollout to canonical main belongs in infrastructure, alongside scripts/agents-pointer-migrate.py, per the authoring-vs-rollout split.

Follow-up to #1150 / PR #1157, which authors the `git-workflow` hook, the `generate_git_workflow` renderer, and `scripts/apply-git-workflow.py` here in agentic-os. The fleet rollout is deliberately deferred. `DEFAULT_HOOK_IDS` in `scripts/apply-agentic-os-hooks.py` stays unchanged, because `test_apply_agentic_os_hooks.py` guards it: a hook id can only appear there once a tagged `aos-precommit-v*` release carries the hook. ## What is left 1. Wait for the `aos-precommit-v*` train to advance past the merge of #1157. Merging a hook input triggers it. 2. Run `python3 scripts/apply-git-workflow.py` across the workspace so every AGENTS.md carries the block. A dry run today resolves 12 repos by declared lane: agentic-os-hardware, agentic-os-kai, agentic-os-xxx, deploy, eco-app, eco-mods, eco-ops, coilysiren on `merge-remote-main`, agentic-os, infrastructure, ward on `pull-request-and-merge`, and cli-guard undeclared. 3. Land each repo's stamped AGENTS.md on its canonical main, per that repo's own lane. 4. Only then add `git-workflow` to `DEFAULT_HOOK_IDS` and run the hook rollout. **Order matters.** Enabling the hook before the block lands breaks every commit in that repo until the applier runs. ## Also worth deciding - `cli-guard` declares no `ward.workflow` lane and renders the undeclared variant. Either declare its lane or accept the undeclared wording. - `deploy` declares `merge-remote-main`, though AGENTS.md prose lists it among the five PR-lane repos. The generator renders what the frontmatter declares, so the prose and the frontmatter disagree somewhere. Worth reconciling before the stamp makes the disagreement visible in every repo. - The per-repo rollout to canonical main belongs in infrastructure, alongside `scripts/agents-pointer-migrate.py`, per the authoring-vs-rollout split.

coilyco-ops commented

2026-08-20 08:49:26 +00:00

Author

Member

Two corrections to the body above.

The deploy observation was wrong. deploy/AGENTS.md declares merge-remote-main deliberately: "Temporary for the August 19 stream, reverting to pull-request-and-merge on 2026-08-20" (sirens-echo#929). That is a dated override expiring today, not a disagreement between prose and frontmatter. Nothing to reconcile. Whoever runs the rollout should just confirm the revert landed first, so the stamp does not freeze the temporary lane into the block.

The lane semantics in PR #1157 were inverted, twice, and are now fixed. A slug names what the author agent does:

pull-request-and-merge - the author opens the PR and merges it itself once green. The fully autonomous lane.
pull-request - the author opens the PR and stops. The director merge lane picks it up from there.

The first draft read -and-merge as "a human merges it later" and the second as "the director merges it". Both invert the pair against pull-request. The generated block now states the direction outright, and the tests reject the inverted phrasings rather than pinning wording.

This changes what the rollout asserts in every repo, so it is worth re-reading the block before running the applier. Ward's own director merge still gates on the opposite slug, tracked at ward#1677 - worth an answer before the fleet sweep, since the block will assert the semantics everywhere.

Two corrections to the body above. **The `deploy` observation was wrong.** `deploy/AGENTS.md` declares `merge-remote-main` deliberately: "Temporary for the August 19 stream, reverting to `pull-request-and-merge` on 2026-08-20" (sirens-echo#929). That is a dated override expiring today, not a disagreement between prose and frontmatter. Nothing to reconcile. Whoever runs the rollout should just confirm the revert landed first, so the stamp does not freeze the temporary lane into the block. **The lane semantics in PR #1157 were inverted, twice, and are now fixed.** A slug names what the **author agent** does: - `pull-request-and-merge` - the author opens the PR and merges it itself once green. The fully autonomous lane. - `pull-request` - the author opens the PR and stops. The director merge lane picks it up from there. The first draft read `-and-merge` as "a human merges it later" and the second as "the director merges it". Both invert the pair against `pull-request`. The generated block now states the direction outright, and the tests reject the inverted phrasings rather than pinning wording. This changes what the rollout asserts in every repo, so it is worth re-reading the block before running the applier. Ward's own director merge still gates on the opposite slug, tracked at ward#1677 - worth an answer before the fleet sweep, since the block will assert the semantics everywhere.

coilyco-ops referenced this issue

2026-08-20 08:49:59 +00:00

feat(pre-commit): stamp a standing git-workflow authorization into every AGENTS.md #1157