Read agent.workflow from AGENTS.md frontmatter instead of .ward/ward.yaml

coilyco-ops commented

2026-08-14 04:52:44 +00:00

Member

Follow-on from coilysiren/inbox#365, which deletes .ward/ward.yaml from repos. just has taken over commands:, and agent.workflow is ruled to move into AGENTS.md frontmatter.

The hazard this creates

Ward resolves the lane from .ward/ward.yaml today. cmd/ward/agent_workflow.go:32 sets:

defaultWorkflow = workflowDirectToMain

So once the key leaves ward.yaml and ward has not learned the new location, the five PR-lane repos (agentic-os, deploy, infrastructure, sirens-echo, ward) silently fall back to direct-to-main. Agents would push straight to main with no pull request, contradicting the line every one of those repos carries in AGENTS.md:

Nothing lands straight on main, and the merge stays director-gated.

Ward has been inert for weeks, so this is dormant rather than live. It activates the moment ward resumes dispatching. Treat this issue as a blocker on that.

The shape landing in the fleet

---
ward:
  workflow: pull-request-and-merge
---
# Agent instructions

Namespaced under ward: so it does not collide with harness-level frontmatter keys. Values are the existing workflowMode set: merge-remote-main, pull-request, pull-request-and-merge, remote-branch-only.

Asked of ward

Parse leading YAML frontmatter from the repo's AGENTS.md and read ward.workflow.
Precedence: explicit --workflow flag, then AGENTS.md frontmatter, then .ward/ward.yaml (while it still exists), then operator smart defaults, then the compiled default.
Consider refusing to fall back to direct-to-main when a repo declares a PR lane anywhere. A silent downgrade from PR-gated to straight-to-main is the failure mode worth engineering against, independent of this migration.
Update docs/ward-yaml.md, which currently documents agent.workflow as repository-configurable there.

Sequencing

The fleet sweep lands the frontmatter and removes agent.workflow from ward.yaml in the same commit per repo. Until this issue lands, the declaration is doctrine that ward does not read. Repos keeping .ward/ward.yaml for other reasons will still resolve correctly if you implement the precedence above.

Decision record: coilysiren/inbox#365
catalog.dependsOn retirement: ward#1660

Follow-on from coilysiren/inbox#365, which deletes `.ward/ward.yaml` from repos. `just` has taken over `commands:`, and `agent.workflow` is ruled to move into AGENTS.md frontmatter. ## The hazard this creates Ward resolves the lane from `.ward/ward.yaml` today. `cmd/ward/agent_workflow.go:32` sets: ```go defaultWorkflow = workflowDirectToMain ``` So once the key leaves `ward.yaml` and ward has not learned the new location, the five PR-lane repos (agentic-os, deploy, infrastructure, sirens-echo, ward) silently fall back to **direct-to-main**. Agents would push straight to `main` with no pull request, contradicting the line every one of those repos carries in AGENTS.md: > Nothing lands straight on `main`, and the merge stays director-gated. Ward has been inert for weeks, so this is dormant rather than live. **It activates the moment ward resumes dispatching.** Treat this issue as a blocker on that. ## The shape landing in the fleet ```yaml --- ward: workflow: pull-request-and-merge --- # Agent instructions ``` Namespaced under `ward:` so it does not collide with harness-level frontmatter keys. Values are the existing `workflowMode` set: `merge-remote-main`, `pull-request`, `pull-request-and-merge`, `remote-branch-only`. ## Asked of ward 1. Parse leading YAML frontmatter from the repo's `AGENTS.md` and read `ward.workflow`. 2. Precedence: explicit `--workflow` flag, then AGENTS.md frontmatter, then `.ward/ward.yaml` (while it still exists), then operator smart defaults, then the compiled default. 3. Consider refusing to fall back to `direct-to-main` when a repo declares a PR lane anywhere. A silent downgrade from PR-gated to straight-to-main is the failure mode worth engineering against, independent of this migration. 4. Update `docs/ward-yaml.md`, which currently documents `agent.workflow` as repository-configurable there. ## Sequencing The fleet sweep lands the frontmatter and removes `agent.workflow` from `ward.yaml` in the same commit per repo. Until this issue lands, the declaration is doctrine that ward does not read. Repos keeping `.ward/ward.yaml` for other reasons will still resolve correctly if you implement the precedence above. ## Related * Decision record: coilysiren/inbox#365 * `catalog.dependsOn` retirement: ward#1660

coilyco-ops referenced this issue from coilyco-flight-deck/homebrew-tap

2026-08-14 05:10:40 +00:00

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

coilyco-ops referenced this issue from coilyco-flight-deck/bluesky-mcp

2026-08-14 05:10:43 +00:00

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

coilyco-ops referenced this issue from coilyco-flight-deck/node-stats-mcp

2026-08-14 05:10:53 +00:00

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

coilyco-ops referenced this issue from coilyco-flight-deck/lunch-money-k8s

2026-08-14 05:10:59 +00:00

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