coilyco-flight-deck/umbra

Watch

umbra declares its landing lane only in .ward/ward.yaml, so every reader sees it as undeclared #333

New issue

Closed

opened 2026-08-28 02:35:10 +00:00 by coilyco-ops · 1 comment

coilyco-ops commented

2026-08-28 02:35:10 +00:00

Owner

Split out of coilyco-flight-deck/agentic-os#1321 rather than folded into it, because the fix belongs in this repo.

What is true today

umbra declares workflow: merge-remote-main in .ward/ward.yaml and carries no ward.workflow key in AGENTS.md frontmatter. Every reader of the lane reads only the frontmatter:

agentic_os.generators.generate_git_workflow.detect_lane - so apply-git-workflow.py run here writes the undeclared variant of the managed AGENTS.md block, which tells the agent to work the pull-request shape and never push main.
scripts/pr-guard-pre-push.sh, as of agentic-os#1330 - it now stands down on a declared merge-remote-main and keeps guarding anything it reads as undeclared. umbra reads as undeclared, so its default-branch pushes stay refused.

The guard happens to do the safe thing here, but for the wrong reason: it is guarding a repo that did declare a lane, in a file nothing reads.

Why the fix is here rather than in the resolver

Teaching detect_lane to fall back to .ward/ward.yaml would deepen a dependency the fleet is currently shedding. .ward/ward.yaml has no validator reading it at all, and coilyco-flight-deck/agentic-os#1329 is an open decision on whether 15 repos keep declaring the file. Adding the lane to the list of things that file feeds would prejudge that decision in the direction of keeping it.

The ward: AGENTS.md frontmatter key is unrelated to Ward's runtime and survives the archive. It is the declared source of truth for the lane, and two hooks already consume it.

What this needs

Add the frontmatter block to AGENTS.md:

---
ward:
  workflow: merge-remote-main
---

Run agentic-os/scripts/apply-git-workflow.py against this repo. It never has been run here, so the managed block is absent as well as wrong, and check-git-workflow fails until it lands. That is tracked alongside the pin work in coilysiren/inbox#457.
Leave the workflow: key in .ward/ward.yaml alone until agentic-os#1329 is decided. Two declarations that agree are a smaller problem than one declaration nothing reads, and removing it is that issue's call rather than this one's.

Acceptance

generate-git-workflow --print-lane prints merge-remote-main in this checkout.
The managed git-workflow block in AGENTS.md renders the merge-remote-main variant, and check-git-workflow passes.
A push to main here is not refused by pr-guard once the pin carries agentic-os#1330.

coilyco-flight-deck/agentic-os#1321 / #1330 - the guard that surfaced this.
coilyco-flight-deck/agentic-os#1329 - whether .ward/ward.yaml survives at all.
coilysiren/inbox#457 - umbra's remaining CI-shape blockers, of which this is one.

Split out of coilyco-flight-deck/agentic-os#1321 rather than folded into it, because the fix belongs in this repo. ## What is true today umbra declares `workflow: merge-remote-main` in `.ward/ward.yaml` and carries no `ward.workflow` key in AGENTS.md frontmatter. Every reader of the lane reads only the frontmatter: * `agentic_os.generators.generate_git_workflow.detect_lane` - so `apply-git-workflow.py` run here writes the **undeclared** variant of the managed AGENTS.md block, which tells the agent to work the `pull-request` shape and never push `main`. * `scripts/pr-guard-pre-push.sh`, as of agentic-os#1330 - it now stands down on a declared `merge-remote-main` and keeps guarding anything it reads as undeclared. umbra reads as undeclared, so its default-branch pushes stay refused. The guard happens to do the safe thing here, but for the wrong reason: it is guarding a repo that did declare a lane, in a file nothing reads. ## Why the fix is here rather than in the resolver Teaching `detect_lane` to fall back to `.ward/ward.yaml` would deepen a dependency the fleet is currently shedding. `.ward/ward.yaml` has no validator reading it at all, and coilyco-flight-deck/agentic-os#1329 is an open decision on whether 15 repos keep declaring the file. Adding the lane to the list of things that file feeds would prejudge that decision in the direction of keeping it. The `ward:` AGENTS.md frontmatter key is unrelated to Ward's runtime and survives the archive. It is the declared source of truth for the lane, and two hooks already consume it. ## What this needs 1. Add the frontmatter block to `AGENTS.md`: ```yaml --- ward: workflow: merge-remote-main --- ``` 2. Run `agentic-os/scripts/apply-git-workflow.py` against this repo. It never has been run here, so the managed block is absent as well as wrong, and `check-git-workflow` fails until it lands. That is tracked alongside the pin work in coilysiren/inbox#457. 3. Leave the `workflow:` key in `.ward/ward.yaml` alone until agentic-os#1329 is decided. Two declarations that agree are a smaller problem than one declaration nothing reads, and removing it is that issue's call rather than this one's. ## Acceptance * `generate-git-workflow --print-lane` prints `merge-remote-main` in this checkout. * The managed git-workflow block in AGENTS.md renders the `merge-remote-main` variant, and `check-git-workflow` passes. * A push to `main` here is not refused by `pr-guard` once the pin carries agentic-os#1330. ## Related * coilyco-flight-deck/agentic-os#1321 / #1330 - the guard that surfaced this. * coilyco-flight-deck/agentic-os#1329 - whether `.ward/ward.yaml` survives at all. * coilysiren/inbox#457 - umbra's remaining CI-shape blockers, of which this is one.

coilyco-ops commented

2026-08-28 03:41:57 +00:00

Author

Owner

Closing this: the premise is wrong, and it was mine to check

I filed this on the report in coilyco-flight-deck/agentic-os#1321 without opening this repo. Having now cloned it, the claim does not hold.

AGENTS.md here already carries the frontmatter:

---
ward:
  workflow: merge-remote-main
---

And .ward/ward.yaml carries no workflow key at all. It holds only the catalog block, with a comment saying it survives because check_catalog_block pins the path and catalog-trifecta wants the three links.

Verified rather than inferred: generate-git-workflow --print-lane prints merge-remote-main in this checkout, which is exactly the reader pr-guard consults. So the lane resolves correctly, nothing reads it as undeclared, and this repo's default-branch pushes are not guarded by accident.

What was true, and where it went

One part of the underlying report holds: apply-git-workflow.py had never run here, so the managed AGENTS.md block is absent and check-git-workflow fails until it lands. That is not a declaration problem, it is a rollout gap, and it is being handled with the pin advance under coilysiren/inbox#457 rather than separately.

The correction worth keeping

Everything in agentic-os#1321's "One more gap" section about umbra should be read as stale. It described the generator writing the undeclared variant here, which cannot happen with the frontmatter present. I propagated that into this issue unchecked, which is the same failure I spent the evening catching in other people's reports: the conclusion was inherited from a description rather than from the thing.

No action needed here. Closing.

## Closing this: the premise is wrong, and it was mine to check I filed this on the report in coilyco-flight-deck/agentic-os#1321 without opening this repo. Having now cloned it, the claim does not hold. `AGENTS.md` here already carries the frontmatter: ```yaml --- ward: workflow: merge-remote-main --- ``` And `.ward/ward.yaml` carries **no `workflow` key at all**. It holds only the catalog block, with a comment saying it survives because `check_catalog_block` pins the path and `catalog-trifecta` wants the three links. Verified rather than inferred: `generate-git-workflow --print-lane` prints `merge-remote-main` in this checkout, which is exactly the reader `pr-guard` consults. So the lane resolves correctly, nothing reads it as undeclared, and this repo's default-branch pushes are not guarded by accident. ## What was true, and where it went One part of the underlying report holds: `apply-git-workflow.py` had never run here, so the managed AGENTS.md block is absent and `check-git-workflow` fails until it lands. That is not a declaration problem, it is a rollout gap, and it is being handled with the pin advance under coilysiren/inbox#457 rather than separately. ## The correction worth keeping Everything in agentic-os#1321's "One more gap" section about umbra should be read as stale. It described the generator writing the `undeclared` variant here, which cannot happen with the frontmatter present. I propagated that into this issue unchecked, which is the same failure I spent the evening catching in other people's reports: the conclusion was inherited from a description rather than from the thing. No action needed here. Closing.

coilyco-ops closed this issue

2026-08-28 03:42:01 +00:00

No milestone

No project

No assignees

1 participant

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

coilyco-flight-deck/umbra#333

No description provided.

Rows
Columns