feat(agents): declare the git workflow in AGENTS.md frontmatter #1056

Merged

coilysiren merged 1 commit from aos/claude/mg96-fm into main

2026-08-14 05:17:19 +00:00

coilyco-ops commented

2026-08-14 05:13:30 +00:00

Member

Part of the coilysiren/inbox#365 teardown, which deletes .ward/ward.yaml from repos.

Moves agent.workflow into AGENTS.md frontmatter:

---
ward:
  workflow: pull-request-and-merge
---

The lane is doctrine about how this repo is worked, so it belongs beside the doctrine rather than in ward's config. Namespaced under ward: so it does not collide with harness-level frontmatter keys.

This one is not a no-op. Read before merging.

This is a PR-lane repo, one of five declaring pull-request-and-merge. Ward does not read AGENTS.md frontmatter yet, and cmd/ward/agent_workflow.go:32 sets defaultWorkflow = workflowDirectToMain (merge-remote-main).

So between this merging and coilyco-flight-deck/ward#1661 landing, a ward dispatch against this repo would resolve to merge-remote-main and push straight to main with no pull request.

Ward has been inert for weeks, so the hazard is dormant rather than live (Kai's call). ward#1661 is a blocker on ward resuming dispatch. The declaration here is doctrine in the meantime, and .ward/ward.yaml no longer carries the lane.

The 27 non-PR-lane repos in this sweep declared merge-remote-main, which is already the compiled default, so those are true no-ops. Only these five change resolved behavior while ward#1661 is open.

Mechanically checked

The edit refuses to run unless the workflow key is found and removed, the resulting YAML re-parses, commands and catalog are byte-identical afterward, and the new AGENTS.md stays under the 290-line / 26400-char documentation-layout caps counting the frontmatter itself.

Part of the coilysiren/inbox#365 teardown, which deletes `.ward/ward.yaml` from repos. Moves `agent.workflow` into AGENTS.md frontmatter: ```yaml --- ward: workflow: pull-request-and-merge --- ``` The lane is doctrine about how this repo is worked, so it belongs beside the doctrine rather than in ward's config. Namespaced under `ward:` so it does not collide with harness-level frontmatter keys. ## This one is not a no-op. Read before merging. This is a **PR-lane repo**, one of five declaring `pull-request-and-merge`. Ward does not read AGENTS.md frontmatter yet, and `cmd/ward/agent_workflow.go:32` sets `defaultWorkflow = workflowDirectToMain` (`merge-remote-main`). So between this merging and coilyco-flight-deck/ward#1661 landing, a ward dispatch against this repo would resolve to **merge-remote-main** and push straight to `main` with no pull request. Ward has been inert for weeks, so the hazard is dormant rather than live (Kai's call). **ward#1661 is a blocker on ward resuming dispatch.** The declaration here is doctrine in the meantime, and `.ward/ward.yaml` no longer carries the lane. The 27 non-PR-lane repos in this sweep declared `merge-remote-main`, which is already the compiled default, so those are true no-ops. Only these five change resolved behavior while ward#1661 is open. ## Mechanically checked The edit refuses to run unless the workflow key is found and removed, the resulting YAML re-parses, `commands` and `catalog` are byte-identical afterward, and the new AGENTS.md stays under the 290-line / 26400-char documentation-layout caps counting the frontmatter itself.

coilyco-ops added 1 commit

2026-08-14 05:13:30 +00:00

feat(agents): declare the git workflow in AGENTS.md frontmatter

ci / ward-doctor (pull_request) Successful in 21s

Details

ci / aos-cli-tests (pull_request) Successful in 1m27s

Details

ci / gate (pull_request) Successful in 2m19s

Details

214248b127

Moves agent.workflow out of .ward/ward.yaml, part of deleting that file
(coilysiren/inbox#365). The lane is doctrine about how this repo is worked,
so it belongs beside the doctrine rather than in ward's config.

Also stops the documentation-layout caps counting frontmatter. The caps bound
what a reader loads and frontmatter is machine-read config, not prose. Without
this, AGENTS.md sat exactly at both caps (290 lines / 26400 chars) and four
lines of frontmatter broke them -- which would have blocked the same move in
every repo near its cap.

Ward does not read the new location yet. It resolves the lane from ward.yaml
and defaults to direct-to-main when absent, so ward#1661 must land before ward
resumes dispatching. Ward has been inert for weeks, so this is dormant.

Refs coilysiren/inbox#365, ward#1661

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Kai Siren <coilysiren@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>

coilyco-ops requested review from coilysiren

2026-08-14 05:13:30 +00:00