Make ward-kdl.defaults.kdl the exclusive smart-defaults source of truth #1312

Closed
opened 2026-07-15 04:42:08 +00:00 by coilyco-ops · 5 comments
Member

PR 1311 exposed that director-max-parallel was effectively defined in too many places: .ward/ward-kdl/ward-kdl.defaults.kdl, generated KDL, baked Go defaults, help/docs text, and a numeric unit test all carried their own copy of the value.

That is a broader config-source problem, not just a director capacity problem. The canonical and exclusive config source for bundled smart defaults must be:

.ward/ward-kdl/ward-kdl.defaults.kdl

Acceptance:

  • Make .ward/ward-kdl/ward-kdl.defaults.kdl the only authored source for smart-default values, including director-max-parallel.
  • Remove hand-authored duplicate numeric defaults from Go code, generated assets, docs, and tests where possible. Generated artifacts may exist only if they are mechanically derived from the canonical KDL file.
  • If a baked fallback is still required for runtime/bootstrap reasons, generate it from the canonical KDL and make the generation path explicit enough that an engineer changes one source file only.
  • CLI help and docs must not hardcode the numeric value. They should read from the resolved default at runtime, say that the bundled value comes from the defaults bundle, or point to the canonical KDL file.
  • Tests must verify the derivation contract and drift detection, not encode the config value itself. A config value change should require editing only .ward/ward-kdl/ward-kdl.defaults.kdl plus regenerated artifacts if the build still needs them.
  • Add a focused guard that would have failed PR 1311s multi-place hand edit pattern. It should scan for duplicate authored smart-default literals or compare generated output against the canonical source.

Context: Kai reviewed #1311 after it merged and noticed the default max parallel config looked defined in roughly seven places. She called out .ward/ward-kdl/ward-kdl.defaults.kdl as the canonical and exclusive config file.

PR 1311 exposed that `director-max-parallel` was effectively defined in too many places: `.ward/ward-kdl/ward-kdl.defaults.kdl`, generated KDL, baked Go defaults, help/docs text, and a numeric unit test all carried their own copy of the value. That is a broader config-source problem, not just a director capacity problem. The canonical and exclusive config source for bundled smart defaults must be: `.ward/ward-kdl/ward-kdl.defaults.kdl` Acceptance: * Make `.ward/ward-kdl/ward-kdl.defaults.kdl` the only authored source for smart-default values, including `director-max-parallel`. * Remove hand-authored duplicate numeric defaults from Go code, generated assets, docs, and tests where possible. Generated artifacts may exist only if they are mechanically derived from the canonical KDL file. * If a baked fallback is still required for runtime/bootstrap reasons, generate it from the canonical KDL and make the generation path explicit enough that an engineer changes one source file only. * CLI help and docs must not hardcode the numeric value. They should read from the resolved default at runtime, say that the bundled value comes from the defaults bundle, or point to the canonical KDL file. * Tests must verify the derivation contract and drift detection, not encode the config value itself. A config value change should require editing only `.ward/ward-kdl/ward-kdl.defaults.kdl` plus regenerated artifacts if the build still needs them. * Add a focused guard that would have failed PR 1311s multi-place hand edit pattern. It should scan for duplicate authored smart-default literals or compare generated output against the canonical source. Context: Kai reviewed https://forgejo.coilysiren.me/coilyco-flight-deck/ward/pulls/1311 after it merged and noticed the default max parallel config looked defined in roughly seven places. She called out `.ward/ward-kdl/ward-kdl.defaults.kdl` as the canonical and exclusive config file.
Author
Member

WARDED_WORKFLOW: reservation-held

reservation details

Holder: launch intent for container engineer-codex-ward-1312 on host kais-macbook-pro-2.local.

Accepted by ward agent --harness codex (reserved 2026-07-15T04:42:42Z). Concurrent ward agent runs are blocked until this intent becomes visible or the intent is released. The stale-intent fallback is still TTL-bounded (3h TTL). --override-reservation 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#1312 · branch issue-1312 · harness codex · workflow pull-request-and-merge
  • Run: engineer-codex-ward-1312 · ward v0.697.0 · dispatched 2026-07-15T04:42:29Z
  • 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.697.0).

— Codex, via ward agent

<!-- ward-agent-reservation --> WARDED_WORKFLOW: reservation-held <details><summary>reservation details</summary> Holder: launch intent for container `engineer-codex-ward-1312` on host `kais-macbook-pro-2.local`. Accepted by `ward agent --harness codex` (reserved 2026-07-15T04:42:42Z). Concurrent `ward agent` runs are blocked until this intent becomes visible or the intent is released. The stale-intent fallback is still TTL-bounded (3h TTL). `--override-reservation` 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#1312` · branch `issue-1312` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-ward-1312` · ward `v0.697.0` · dispatched `2026-07-15T04:42:29Z` - **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.697.0). </details> </details> <!-- ward-agent-signature --> — Codex, via `ward agent`
Author
Member

WARDED_WORKFLOW: blocked 🛑

details

workflow: pull-request-and-merge; review summary: skipped because the temporary ward default pending brokered QA
blocked: Forgejo rejected merge and self-approval on PR 1318 is not allowed, so the run cannot land without an external maintainer approval or policy change.
implementation feel: mechanical and tidy until the final merge gate.
confidence: high on the code, low on the landing path without another approver.
surprises: the baked defaults cache had to be cloned because bundle overlays mutate map fields.
follow-up: another maintainer can approve PR 1318 or relax the self-approval gate, then the merge can be retried.
reservation hand-back: clear

WARDED_WORKFLOW: blocked 🛑 <details><summary>details</summary> workflow: pull-request-and-merge; review summary: skipped because the temporary ward default pending brokered QA blocked: Forgejo rejected merge and self-approval on PR 1318 is not allowed, so the run cannot land without an external maintainer approval or policy change. implementation feel: mechanical and tidy until the final merge gate. confidence: high on the code, low on the landing path without another approver. surprises: the baked defaults cache had to be cloned because bundle overlays mutate map fields. follow-up: another maintainer can approve PR 1318 or relax the self-approval gate, then the merge can be retried. reservation hand-back: clear <!-- ward-agent-signature --> </details>
Author
Member

WARDED_WORKFLOW: #1318

details

workflow: pull-request-and-merge; review summary: skipped because the temporary ward default pending brokered QA
retrospective: the change was mostly plumbing, but the baked-default cache clone fix mattered to keep overlays from mutating the baseline.
confidence: high
surprises: Forgejo required the canonical KDL to be the only authored defaults source, and the landing path needed policy to clear before the merge API would accept it.
follow-ups: none

WARDED_WORKFLOW: https://forgejo.coilysiren.me/coilyco-flight-deck/ward/pulls/1318 <details><summary>details</summary> workflow: pull-request-and-merge; review summary: skipped because the temporary ward default pending brokered QA retrospective: the change was mostly plumbing, but the baked-default cache clone fix mattered to keep overlays from mutating the baseline. confidence: high surprises: Forgejo required the canonical KDL to be the only authored defaults source, and the landing path needed policy to clear before the merge API would accept it. follow-ups: none <!-- ward-agent-signature --> </details>
Author
Member

WARD-TRIAGE: warded control plane coherence milestone

This issue is part of the warded control plane coherence sprint. The release thesis is to make warded feel like one dependable control plane for agent work: higher safe parallelism, coherent config defaults, reliable broker/container behavior, human-feedback gates, and enough structured evidence for the next actor after a paused or failed run.

For this sprint, headless means an engineer should be able to carry the issue from current issue context to a merged change without new human decisions. If the issue discovers a missing decision, split or demote the unclear part instead of guessing.

WARD-TRIAGE: warded control plane coherence milestone This issue is part of the `warded control plane coherence` sprint. The release thesis is to make `warded` feel like one dependable control plane for agent work: higher safe parallelism, coherent config defaults, reliable broker/container behavior, human-feedback gates, and enough structured evidence for the next actor after a paused or failed run. For this sprint, `headless` means an engineer should be able to carry the issue from current issue context to a merged change without new human decisions. If the issue discovers a missing decision, split or demote the unclear part instead of guessing.
Author
Member

WARD-TRIAGE: coherence-core label

This issue is part of the coherence-core review set for the warded control plane coherence sprint. Treat it as release-spine work: it should directly improve the safety, capacity, configuration coherence, observability, or recovery loop that makes director burndown trustworthy.

Core does not mean broader scope. Keep the implementation narrow, verify current main before reusing prior failed PRs, and split any design fork or lower-confidence follow-up out of the core path.

WARD-TRIAGE: coherence-core label This issue is part of the `coherence-core` review set for the `warded control plane coherence` sprint. Treat it as release-spine work: it should directly improve the safety, capacity, configuration coherence, observability, or recovery loop that makes director burndown trustworthy. Core does not mean broader scope. Keep the implementation narrow, verify current `main` before reusing prior failed PRs, and split any design fork or lower-confidence follow-up out of the core path.
Sign in to join this conversation.
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/ward#1312
No description provided.