Author the `burndown` repo-exclusion block in .ward/repos.kdl + validator (ward#1105 config half) #462

New issue

Closed

opened 2026-07-10 23:32:24 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-10 23:32:24 +00:00

Member

Problem

Companion to coilyco-flight-deck/ward#1105 (director burndown repo-exclusion). aos is the source of truth for the ward-specs bundle (docs/ward-specs.md), so the burndown config block is authored here and flows into ward at release via WARD_CONFIG_REF.

Do

Add a burndown block to .ward/repos.kdl as a sibling of repo-authority:

    burndown default=true {
        repo "coilyco-flight-deck/infrastructure" false
        repo "coilyco-bridge/deploy" false
    }

Update the byte-for-byte EXPECTED_REPOS string in agentic_os/pre_commit/check_ward_specs_bundle.py to match, or the ward-specs-bundle pre-commit hook fails the commit. Add/adjust the assertion in tests/test_ward_specs_bundle.py so the new block is covered.
No tar-member changes (still ./repos.kdl), so EXPECTED_TAR_MEMBERS is untouched.

Coordination

The config block is inert until ward parses it (ward#1105). Either order is non-breaking - ward ignores an absent block, and a shipped block ward does not yet parse is a harmless no-op - but the intended landing is a single cross-repo run driven from the ward issue with a --repo coilyco-flight-deck/agentic-os grant, so both halves ship together.

Why these two repos to start

coilyco-flight-deck/infrastructure and coilyco-bridge/deploy are the observed churn sources: their real work needs live-cluster verification a sealed engineer clone cannot do, so a headless burndown run against them writes unverifiable code and fails on a loop.

## Problem Companion to coilyco-flight-deck/ward#1105 (director burndown repo-exclusion). aos is the source of truth for the ward-specs bundle (`docs/ward-specs.md`), so the `burndown` config block is **authored here** and flows into ward at release via `WARD_CONFIG_REF`. ## Do - Add a `burndown` block to `.ward/repos.kdl` as a sibling of `repo-authority`: ```kdl burndown default=true { repo "coilyco-flight-deck/infrastructure" false repo "coilyco-bridge/deploy" false } ``` - Update the byte-for-byte `EXPECTED_REPOS` string in `agentic_os/pre_commit/check_ward_specs_bundle.py` to match, or the `ward-specs-bundle` pre-commit hook fails the commit. Add/adjust the assertion in `tests/test_ward_specs_bundle.py` so the new block is covered. - No tar-member changes (still `./repos.kdl`), so `EXPECTED_TAR_MEMBERS` is untouched. ## Coordination The config block is inert until ward parses it (ward#1105). Either order is non-breaking - ward ignores an absent block, and a shipped block ward does not yet parse is a harmless no-op - but the intended landing is a single cross-repo run driven from the ward issue with a `--repo coilyco-flight-deck/agentic-os` grant, so both halves ship together. ## Why these two repos to start `coilyco-flight-deck/infrastructure` and `coilyco-bridge/deploy` are the observed churn sources: their real work needs live-cluster verification a sealed engineer clone cannot do, so a headless burndown run against them writes unverifiable code and fails on a loop.

coilyco-ops added the

headless

labels

2026-07-10 23:32:24 +00:00

coilyco-ops referenced this issue from coilyco-flight-deck/ward

2026-07-10 23:32:32 +00:00

Honor a burndown repo-exclusion block in repos.kdl so the director stops churning engineers against no-code repos #1105

coilyco-ops commented

2026-07-10 23:34:35 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-agentic-os-462 on host KAI-DESKTOP-TOWER.

Reserved by ward agent --harness codex (reserved 2026-07-10T23:34:35Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h TTL). --force overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

run seed context — what this run is carrying (ward#609)

Resolved: coilyco-flight-deck/agentic-os#462 · branch issue-462 · harness codex · workflow pull-requests-and-merge
Run: engineer-codex-agentic-os-462 · ward v0.605.0 · dispatched 2026-07-10T23:34:35Z
Comment thread: 0 included in the pre-flight read, 0 stripped (ward's own automated comments).

Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.605.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-agentic-os-462` on host `KAI-DESKTOP-TOWER`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T23:34:35Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (1h TTL). `--force` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh**. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-flight-deck/agentic-os#462` · branch `issue-462` · harness `codex` · workflow `pull-requests-and-merge` - **Run:** `engineer-codex-agentic-os-462` · ward `v0.605.0` · dispatched `2026-07-10T23:34:35Z` - **Comment thread:** 0 included in the pre-flight read, 0 stripped (ward's own automated comments). Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.605.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a pull request that will close it,

2026-07-10 23:39:49 +00:00

Author the burndown repo-exclusion block in .ward/repos.kdl + validator (ward#1105 config half) #464

coilyco-ops commented

2026-07-10 23:40:42 +00:00

Author

Member

WARD-OUTCOME: submitted

details

workflow: pull-request-and-merge; review summary: skipped because the temporary ward default is pending brokered QA

felt: narrow and straightforward
confidence: high
surprises: none
follow-ups: PR #464 is green and ready for merge

WARD-OUTCOME: submitted <details><summary>details</summary> workflow: pull-request-and-merge; review summary: skipped because the temporary ward default is pending brokered QA - felt: narrow and straightforward - confidence: high - surprises: none - follow-ups: PR #464 is green and ready for merge </details>

coilyco-ops closed this issue

2026-07-10 23:41:35 +00:00