Config-driven ward: source fail-loud + audit integrity (#650-4) #656

New issue

Closed

opened 2026-07-08 03:33:07 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-08 03:33:07 +00:00

Member

Blocked on #653 (the fs.FS seam).

Breakdown of the config-driven ward epic (#650). Depends on the resolver. This is the source-resolution fail-loud - "does the named bundle resolve", distinct from per-harness value validity (that is its own issue in this breakdown).

Do (the behavior matrix, epic design §5)

ward does not police which ref (settled decision 3), but fails loud whenever the named source cannot resolve, consistent with docs/config-discovery.md's set-but-missing override rule:

WARD_CONFIG_REF unset -> baked neutral default embed.FS. Never an error.
Set but malformed grammar (no //, empty subpath, empty repospec) -> fail loud naming the exact grammar violation, before any network. Same spirit as parseConfigOverrides' loud unknown-key error.
Set, well-formed, clone/fetch fails AND no cache -> fail loud naming the unresolvable ref + URL. ward must not silently fall back to the neutral default when the operator named a source - that would mask a broken pin (the config-discovery "an explicit override is never silently downgraded to the walk-up" rule).
Set, fetch fails, cached checkout exists -> warn and use the cache (the substrate warmer's using cached state). Offline resilience, not a hard fail.
Resolved, but subpath missing or KDL does not parse -> fail loud via the opsCommand degrade-to-error-leaf (the fs.FS-seam issue wires this), so a bad bundle cannot silently drop a verb surface.

Audit integrity

The ref itself is the integrity guarantee (a sha ref is the pin - ward adds no separate checksum policy, that would be policy not mechanism). ward records the resolved sha in the audit row, so every guarded invocation is attributable to the exact bundle commit it compiled from.

Filed from the read-only director surface (she/her).

**Blocked on #653** (the fs.FS seam). Breakdown of the [config-driven ward epic (#650)](https://forgejo.coilysiren.me/coilyco-flight-deck/ward/issues/650). **Depends on the resolver.** This is the **source-resolution** fail-loud - "does the named bundle resolve", distinct from per-harness value validity (that is its own issue in this breakdown). ## Do (the behavior matrix, epic design §5) ward does not police which ref (settled decision 3), but fails loud whenever the **named source cannot resolve**, consistent with `docs/config-discovery.md`'s set-but-missing override rule: * **`WARD_CONFIG_REF` unset** -> baked neutral default `embed.FS`. Never an error. * **Set but malformed grammar** (no `//`, empty subpath, empty repospec) -> fail loud naming the exact grammar violation, before any network. Same spirit as `parseConfigOverrides`' loud unknown-key error. * **Set, well-formed, clone/fetch fails AND no cache** -> fail loud naming the unresolvable ref + URL. ward must **not** silently fall back to the neutral default when the operator named a source - that would mask a broken pin (the config-discovery "an explicit override is never silently downgraded to the walk-up" rule). * **Set, fetch fails, cached checkout exists** -> warn and use the cache (the substrate warmer's `using cached state`). Offline resilience, not a hard fail. * **Resolved, but subpath missing or KDL does not parse** -> fail loud via the `opsCommand` degrade-to-error-leaf (the fs.FS-seam issue wires this), so a bad bundle cannot silently drop a verb surface. ## Audit integrity The ref itself is the integrity guarantee (a sha ref **is** the pin - ward adds no separate checksum policy, that would be policy not mechanism). ward **records** the resolved sha in the audit row, so every guarded invocation is attributable to the exact bundle commit it compiled from. Filed from the read-only director surface (she/her).

coilyco-ops added the

label

2026-07-08 03:33:07 +00:00

coilyco-ops referenced this issue

2026-07-08 03:33:46 +00:00

[epic] Config-driven ward: one precompiled binary, personal config resolved live from a git ref (supersedes the build-variant matrix) #650

coilyco-ops referenced this issue

2026-07-08 04:49:15 +00:00

[epic] Config-driven ward: one precompiled binary, personal config resolved live from a git ref (supersedes the build-variant matrix) #650

coilyco-ops commented

2026-07-08 09:31:02 +00:00

Author

Member

🔒 Reserved by ward agent --harness codex — container engineer-codex-ward-656 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-08T09:31:00Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s 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/ward#656 · branch issue-656 · harness codex · workflow direct-main
Run: engineer-codex-ward-656 · ward v0.449.0 · dispatched 2026-07-08T09:31:00Z
Comment thread: 0 included in the pre-flight read, 0 stripped (ward's own automated comments).

Issue body as seeded:

**Blocked on #653** (the fs.FS seam).

Breakdown of the [config-driven ward epic (#650)](https://forgejo.coilysiren.me/coilyco-flight-deck/ward/issues/650). **Depends on the resolver.** This is the **source-resolution** fail-loud - "does the named bundle resolve", distinct from per-harness value validity (that is its own issue in this breakdown).

## Do (the behavior matrix, epic design §5)

ward does not police which ref (settled decision 3), but fails loud whenever the **named source cannot resolve**, consistent with `docs/config-discovery.md`'s set-but-missing override rule:

* **`WARD_CONFIG_REF` unset** -> baked neutral default `embed.FS`. Never an error.
* **Set but malformed grammar** (no `//`, empty subpath, empty repospec) -> fail loud naming the exact grammar violation, before any network. Same spirit as `parseConfigOverrides`' loud unknown-key error.
* **Set, well-formed, clone/fetch fails AND no cache** -> fail loud naming the unresolvable ref + URL. ward must **not** silently fall back to the neutral default when the operator named a source - that would mask a broken pin (the config-discovery "an explicit override is never silently downgraded to the walk-up" rule).
* **Set, fetch fails, cached checkout exists** -> warn and use the cache (the substrate warmer's `using cached state`). Offline resilience, not a hard fail.
* **Resolved, but subpath missing or KDL does not parse** -> fail loud via the `opsCommand` degrade-to-error-leaf (the fs.FS-seam issue wires this), so a bad bundle cannot silently drop a verb surface.

## Audit integrity

The ref itself is the integrity guarantee (a sha ref **is** the pin - ward adds no separate checksum policy, that would be policy not mechanism). ward **records** the resolved sha in the audit row, so every guarded invocation is attributable to the exact bundle commit it compiled from.

Filed from the read-only director surface (she/her).

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

— Codex, via ward agent

🔒 Reserved by `ward agent --harness codex` — container `engineer-codex-ward-656` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-08T09:31:00Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s 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/ward#656` · branch `issue-656` · harness `codex` · workflow `direct-main` - **Run:** `engineer-codex-ward-656` · ward `v0.449.0` · dispatched `2026-07-08T09:31:00Z` - **Comment thread:** 0 included in the pre-flight read, 0 stripped (ward's own automated comments). **Issue body as seeded:** ``` **Blocked on #653** (the fs.FS seam). Breakdown of the [config-driven ward epic (#650)](https://forgejo.coilysiren.me/coilyco-flight-deck/ward/issues/650). **Depends on the resolver.** This is the **source-resolution** fail-loud - "does the named bundle resolve", distinct from per-harness value validity (that is its own issue in this breakdown). ## Do (the behavior matrix, epic design §5) ward does not police which ref (settled decision 3), but fails loud whenever the **named source cannot resolve**, consistent with `docs/config-discovery.md`'s set-but-missing override rule: * **`WARD_CONFIG_REF` unset** -> baked neutral default `embed.FS`. Never an error. * **Set but malformed grammar** (no `//`, empty subpath, empty repospec) -> fail loud naming the exact grammar violation, before any network. Same spirit as `parseConfigOverrides`' loud unknown-key error. * **Set, well-formed, clone/fetch fails AND no cache** -> fail loud naming the unresolvable ref + URL. ward must **not** silently fall back to the neutral default when the operator named a source - that would mask a broken pin (the config-discovery "an explicit override is never silently downgraded to the walk-up" rule). * **Set, fetch fails, cached checkout exists** -> warn and use the cache (the substrate warmer's `using cached state`). Offline resilience, not a hard fail. * **Resolved, but subpath missing or KDL does not parse** -> fail loud via the `opsCommand` degrade-to-error-leaf (the fs.FS-seam issue wires this), so a bad bundle cannot silently drop a verb surface. ## Audit integrity The ref itself is the integrity guarantee (a sha ref **is** the pin - ward adds no separate checksum policy, that would be policy not mechanism). ward **records** the resolved sha in the audit row, so every guarded invocation is attributable to the exact bundle commit it compiled from. Filed from the read-only director surface (she/her). ``` Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.449.0). </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a commit

2026-07-08 09:38:42 +00:00

config-driven ward audit integrity

coilyco-ops closed this issue

2026-07-08 09:39:13 +00:00

coilyco-ops commented

2026-07-08 09:40:25 +00:00

Author

Member

WARD-OUTCOME: done - stamped resolved bundle HEADs into audit rows.
The change held together cleanly. The only fight was the docs size cap, which I trimmed back before landing. Confidence is high.
PR-BODY-NOTE: ADVISORY-ONLY REVIEW: no heterogeneous reviewer family was available besides the worker (codex), so the adversarial panel could not run and did NOT gate this diff. Dropped: opencode (unavailable: opencode not on PATH); codex (worker's own family - never reviews its own diff). A human should review this change with the extra scrutiny an unrun panel would have applied.

WARD-OUTCOME: done - stamped resolved bundle HEADs into audit rows. The change held together cleanly. The only fight was the docs size cap, which I trimmed back before landing. Confidence is high. PR-BODY-NOTE: ADVISORY-ONLY REVIEW: no heterogeneous reviewer family was available besides the worker (codex), so the adversarial panel could not run and did NOT gate this diff. Dropped: opencode (unavailable: opencode not on PATH); codex (worker's own family - never reviews its own diff). A human should review this change with the extra scrutiny an unrun panel would have applied.

coilyco-ops referenced this issue

2026-07-08 09:51:57 +00:00

[epic] Config-driven ward: one precompiled binary, personal config resolved live from a git ref (supersedes the build-variant matrix) #650

coilyco-ops referenced this issue

2026-07-10 00:36:27 +00:00

Remove coilyco ward-kdl specs from ward's baked default bundle #893