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

coilyco-ops commented

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

Member

Parent: release-readiness push batch from the 2026-07-10 director surface. Related: #650, #653, #654, #655, #656, #396, #539.

Goal

Remove Kai/coilyco-specific ward KDL configuration from ward's baked default bundle. Ward should ship a neutral self-contained default and load operator-specific specs through WARD_CONFIG_REF or an explicit bundle, not from tracked .ward/ward-kdl values that name Kai's forge, SSM paths, tailnet topology, or operator surfaces.

Context

The config-resolve seam exists now: docs/config-source.md says unset WARD_CONFIG_REF uses the baked default, while a named ref supplies edge KDL surfaces. That makes this slice feasible. The current tracked .ward/ward-kdl tree still carries custom deployment config and generated docs around it.

Do

Replace the baked/default .ward/ward-kdl bundle with the neutral starter shape that external users can ship safely.
Keep ward's own core runtime behavior working when WARD_CONFIG_REF is unset.
Preserve examples or docs that teach operators how to bring their own bundle, but do not leave Kai's live endpoints, owner gates, SSM paths, or topology as the shipped default.
Update generated or hand-written docs that currently describe the custom bundle as what ward ships.
If a test currently asserts the custom bundle is mirrored byte-for-byte, update that assertion to the neutral bundle and keep drift coverage.

Non-goals

Do not remove the WARD_CONFIG_REF resolver.
Do not remove ward-kdl as a build-time authoring layer.
Do not solve dynamic roles in this issue. That is a separate push.

Acceptance

rg for obvious custom values in the baked/default bundle no longer finds them in shipped default config. Examples and historical issue links are okay when clearly marked as examples/history.
ward exec test passes, or the issue comment names the exact failing check.
docs/FEATURES.md and the ward-kdl docs reflect that the baked default is neutral and operator config comes from a selected bundle.

Closes this issue when merged.

Parent: release-readiness push batch from the 2026-07-10 director surface. Related: #650, #653, #654, #655, #656, #396, #539. ## Goal Remove Kai/coilyco-specific ward KDL configuration from ward's baked default bundle. Ward should ship a neutral self-contained default and load operator-specific specs through `WARD_CONFIG_REF` or an explicit bundle, not from tracked `.ward/ward-kdl` values that name Kai's forge, SSM paths, tailnet topology, or operator surfaces. ## Context The config-resolve seam exists now: `docs/config-source.md` says unset `WARD_CONFIG_REF` uses the baked default, while a named ref supplies edge KDL surfaces. That makes this slice feasible. The current tracked `.ward/ward-kdl` tree still carries custom deployment config and generated docs around it. ## Do - Replace the baked/default `.ward/ward-kdl` bundle with the neutral starter shape that external users can ship safely. - Keep ward's own core runtime behavior working when `WARD_CONFIG_REF` is unset. - Preserve examples or docs that teach operators how to bring their own bundle, but do not leave Kai's live endpoints, owner gates, SSM paths, or topology as the shipped default. - Update generated or hand-written docs that currently describe the custom bundle as what ward ships. - If a test currently asserts the custom bundle is mirrored byte-for-byte, update that assertion to the neutral bundle and keep drift coverage. ## Non-goals - Do not remove the `WARD_CONFIG_REF` resolver. - Do not remove ward-kdl as a build-time authoring layer. - Do not solve dynamic roles in this issue. That is a separate push. ## Acceptance - `rg` for obvious custom values in the baked/default bundle no longer finds them in shipped default config. Examples and historical issue links are okay when clearly marked as examples/history. - `ward exec test` passes, or the issue comment names the exact failing check. - `docs/FEATURES.md` and the ward-kdl docs reflect that the baked default is neutral and operator config comes from a selected bundle. Closes this issue when merged.

coilyco-ops commented

2026-07-10 00:37:39 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-ward-893 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-10T00:37:37Z). 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/ward#893 · branch issue-893 · harness codex · workflow pull-requests-and-merge
Run: engineer-codex-ward-893 · ward v0.543.0 · dispatched 2026-07-10T00:37:37Z
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.543.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-893` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T00:37:37Z). 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/ward#893` · branch `issue-893` · harness `codex` · workflow `pull-requests-and-merge` - **Run:** `engineer-codex-ward-893` · ward `v0.543.0` · dispatched `2026-07-10T00:37:37Z` - **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.543.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops added the

headless

P1

labels

2026-07-10 00:41:31 +00:00

coilyco-ops referenced this issue

2026-07-10 00:45:41 +00:00

Director surface heartbeat marks broker-forwarded runs failed when local Docker is unavailable #900

coilyco-ops commented

2026-07-10 00:45:46 +00:00

Author

Member

WARD-DISPATCH: failed ❌

failure details

This forwarded dispatch failed after the issue was already reserved.

Attempted harness: codex
Attempted run: ward agent engineer coilyco-flight-deck/ward#893 --harness codex --image forgejo.coilysiren.me/coilyco-flight-deck/agentic-os --tag latest
Container: engineer-codex-ward-893
Container created: no running engineer was observed.
Host log: /Users/kai/.ward/agent-logs/dispatch/20260710T004439Z-director-codex-zv98-coilyco-flight-deck-ward-893.log
Failure: ward agent engineer --harness codex: issue coilyco-flight-deck/ward#893 already has a running worker container engineer-codex-ward-893; wait for it to finish or pass --force to reclaim

Retry: choose another harness if the first one is down, or rerun with --force if the reservation is stale.

— Codex, via ward agent

WARD-DISPATCH: failed ❌ <details><summary>failure details</summary> This forwarded dispatch failed after the issue was already reserved. Attempted harness: `codex` Attempted run: `ward agent engineer coilyco-flight-deck/ward#893 --harness codex --image forgejo.coilysiren.me/coilyco-flight-deck/agentic-os --tag latest` Container: `engineer-codex-ward-893` Container created: no running engineer was observed. Host log: `/Users/kai/.ward/agent-logs/dispatch/20260710T004439Z-director-codex-zv98-coilyco-flight-deck-ward-893.log` Failure: `ward agent engineer --harness codex: issue coilyco-flight-deck/ward#893 already has a running worker container engineer-codex-ward-893; wait for it to finish or pass --force to reclaim` Retry: choose another harness if the first one is down, or rerun with `--force` if the reservation is stale. </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue

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

fix: sync codex director overlay #901

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

2026-07-10 00:57:14 +00:00

fix: neutralize baked ward-kdl bundle #914

coilyco-ops referenced this issue

2026-07-10 01:07:38 +00:00

Replace baked ward-kdl bundle with toy/example-safe defaults #920

coilyco-ops commented

2026-07-10 01:11:03 +00:00

Author

Member

WARD-OUTCOME: merge-ready

details

workflow: pull-requests-and-merge; review summary: skipped because review gate skipped by ~/.ward/config.yaml default retrospective: the bundle neutralization was straightforward, but the branch needed a main merge plus a lint follow-up to stay green. confidence: high surprises: golangci-lint flagged an existing complexity threshold and a gofmt drift in the touched test. follow-ups: none

WARD-OUTCOME: merge-ready <details><summary>details</summary> workflow: pull-requests-and-merge; review summary: skipped because review gate skipped by ~/.ward/config.yaml default retrospective: the bundle neutralization was straightforward, but the branch needed a main merge plus a lint follow-up to stay green. confidence: high surprises: golangci-lint flagged an existing complexity threshold and a gofmt drift in the touched test. follow-ups: none </details>

coilyco-ops commented

2026-07-10 05:10:49 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-ward-893 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-10T05:10:49Z). 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/ward#893 · branch issue-893 · harness codex · workflow pull-requests
Run: engineer-codex-ward-893 · ward v0.555.0 · dispatched 2026-07-10T05:10:49Z
Comment thread: 2 included in the pre-flight read, 1 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-10T00:45:46Z), @coilyco-ops (2026-07-10T01:11:03Z)
- stripped: @coilyco-ops (2026-07-10T00:37:39Z)

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

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-893` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T05:10:49Z). 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/ward#893` · branch `issue-893` · harness `codex` · workflow `pull-requests` - **Run:** `engineer-codex-ward-893` · ward `v0.555.0` · dispatched `2026-07-10T05:10:49Z` - **Comment thread:** 2 included in the pre-flight read, 1 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-10T00:45:46Z), @coilyco-ops (2026-07-10T01:11:03Z) - stripped: @coilyco-ops (2026-07-10T00:37:39Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.555.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops commented

2026-07-10 05:16:42 +00:00

Author

Member

WARD-RESERVATION: released 🛑

release details

Run never started. ward container reap released container ward (--harness codex): it exited without launching the agent (smoke-test death, ward#222/#264/#595), so it did no work and the hold it took is retracted. Nothing is running on this issue. It needs re-dispatch. A ward agent director re-queues it automatically. A manual ward agent retry no longer needs --force.

— Codex, via ward agent

WARD-RESERVATION: released 🛑 <details><summary>release details</summary> Run never started. `ward container reap` released container `ward` (`--harness codex`): it exited without launching the agent (smoke-test death, ward#222/#264/#595), so it did no work and the hold it took is retracted. Nothing is running on this issue. It needs re-dispatch. A `ward agent director` re-queues it automatically. A manual `ward agent` retry no longer needs `--force`. </details>  — Codex, via `ward agent`

coilyco-ops closed this issue

2026-07-10 06:20:57 +00:00

Rows
Columns

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

Goal

Context

Do

Non-goals

Acceptance