Config-driven ward: topology fold (container consts) into the bundle, staged (#650-3)

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 fs.FS seam + the resolver. Coordinates with #539 (ward-kdl -> ward migration).

Corrected scope vs the epic design comment

The design proposed "add a topology section to the bundle (Stage 1)" for all ~14 WARD_* values. aos#332 landing already moved half of it: the endpoint topology (forgejo base, SSM paths, signoz, ollama) rode into aos's .ward/ bundle inside the guardfiles (ward-kdl.forgejo/signoz/ollama.guardfile.kdl, glitchtip.openapi.lock.json). So this issue's real remaining surface is the container consts still hard-wired in cmd/ward/container_compute.go:

Tailnet + tower - defaultTailnetNetwork / defaultTailnetProxy / defaultTowerHost / defaultTowerOllamaPort (:104-127).
ollama / observe endpoints - towerOllamaURL (:151) and friends.
Substrate topology - WARD_SUBSTRATE_SEED / _DEST / _MANIFEST / _TTL (:633-636).

Do

Insert the bundle as a middle tier in the resolution that already exists (container_compute.go:100 already treats these as env-over-baked-default DATA per ward#395, and ward#616 already resolves --config agent.<name>.<key> into WARD_* keys). New precedence, a strict superset of today:

WARD_* env > KDL bundle topology > baked neutral default

Nothing that sets an env var today changes behavior - env still wins. The bundle only fills the slot the baked coilyco literal fills now. Convert each envOr(...) resolver to envOrBundleOr(...).

Stage it, no flag-day:

Stage 1 (pure addition): add the container-consts topology to the bundle + insert the bundle tier. A run with WARD_CONFIG_REF unset is byte-for-byte today.
Stage 2: point the fleet's container_compute.go driver + infra at WARD_CONFIG_REF. The container path that sets these vars for children (wardEnv, :605) resolves from the bundle first, then still passes them as env, so entrypoint.sh / container_bootstrap.go and the docs/container-env.md contract are unchanged - the bundle is just the new source.
Stage 3 (later, optional): delete the coilyco-specific baked literals, leaving only the opaque neutral default. Gated on the bundle path being proven in the fleet.

Coordinate with #539

#539's verb-gap (mount tailscale / signoz / glitchtip under ward ops) and its guardfile-spec section overlap this fold - the signoz/ollama/glitchtip guardfiles are already in the aos bundle. Sequence the container-consts fold so it does not collide with #539's verb-surface migration.

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 fs.FS seam + the resolver.** Coordinates with #539 (ward-kdl -> ward migration). ## Corrected scope vs the epic design comment The design proposed "add a topology section to the bundle (Stage 1)" for all ~14 `WARD_*` values. **aos#332 landing already moved half of it**: the endpoint topology (forgejo base, SSM paths, signoz, ollama) rode into aos's `.ward/` bundle **inside the guardfiles** (`ward-kdl.forgejo/signoz/ollama.guardfile.kdl`, `glitchtip.openapi.lock.json`). So this issue's real remaining surface is the **container consts** still hard-wired in `cmd/ward/container_compute.go`: * Tailnet + tower - `defaultTailnetNetwork` / `defaultTailnetProxy` / `defaultTowerHost` / `defaultTowerOllamaPort` (`:104-127`). * ollama / observe endpoints - `towerOllamaURL` (`:151`) and friends. * Substrate topology - `WARD_SUBSTRATE_SEED` / `_DEST` / `_MANIFEST` / `_TTL` (`:633-636`). ## Do Insert the bundle as a **middle tier** in the resolution that already exists (`container_compute.go:100` already treats these as env-over-baked-default DATA per ward#395, and ward#616 already resolves `--config agent.<name>.<key>` into `WARD_*` keys). New precedence, a strict superset of today: `WARD_* env > KDL bundle topology > baked neutral default` Nothing that sets an env var today changes behavior - env still wins. The bundle only fills the slot the baked coilyco literal fills now. Convert each `envOr(...)` resolver to `envOrBundleOr(...)`. **Stage it, no flag-day:** * **Stage 1 (pure addition):** add the container-consts topology to the bundle + insert the bundle tier. A run with `WARD_CONFIG_REF` unset is byte-for-byte today. * **Stage 2:** point the fleet's `container_compute.go` driver + infra at `WARD_CONFIG_REF`. The container path that **sets** these vars for children (`wardEnv`, `:605`) resolves from the bundle first, then still passes them as env, so `entrypoint.sh` / `container_bootstrap.go` and the `docs/container-env.md` contract are unchanged - the bundle is just the new source. * **Stage 3 (later, optional):** delete the coilyco-specific baked literals, leaving only the opaque neutral default. Gated on the bundle path being proven in the fleet. ## Coordinate with #539 #539's verb-gap (mount `tailscale` / `signoz` / `glitchtip` under `ward ops`) and its guardfile-spec section overlap this fold - the signoz/ollama/glitchtip guardfiles are already in the aos bundle. Sequence the container-consts fold so it does not collide with #539's verb-surface migration. Filed from the read-only director surface (she/her).

coilyco-ops added the

P1

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 03:33:58 +00:00

Migrate ward-kdl -> ward: track remaining references (verb gaps, guardfile specs, repo internals) #539

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 added the

headless

label

2026-07-08 08:02:59 +00:00

coilyco-ops commented

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

Author

Member

🔒 Reserved by ward agent --harness codex — container engineer-codex-ward-655 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-08T08:03:14Z). 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#655 · branch issue-655 · harness codex · workflow direct-main
Run: engineer-codex-ward-655 · ward v0.443.0 · dispatched 2026-07-08T08:03:14Z
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 fs.FS seam + the resolver.** Coordinates with #539 (ward-kdl -> ward migration).

## Corrected scope vs the epic design comment

The design proposed "add a topology section to the bundle (Stage 1)" for all ~14 `WARD_*` values. **aos#332 landing already moved half of it**: the endpoint topology (forgejo base, SSM paths, signoz, ollama) rode into aos's `.ward/` bundle **inside the guardfiles** (`ward-kdl.forgejo/signoz/ollama.guardfile.kdl`, `glitchtip.openapi.lock.json`). So this issue's real remaining surface is the **container consts** still hard-wired in `cmd/ward/container_compute.go`:

* Tailnet + tower - `defaultTailnetNetwork` / `defaultTailnetProxy` / `defaultTowerHost` / `defaultTowerOllamaPort` (`:104-127`).
* ollama / observe endpoints - `towerOllamaURL` (`:151`) and friends.
* Substrate topology - `WARD_SUBSTRATE_SEED` / `_DEST` / `_MANIFEST` / `_TTL` (`:633-636`).

## Do

Insert the bundle as a **middle tier** in the resolution that already exists (`container_compute.go:100` already treats these as env-over-baked-default DATA per ward#395, and ward#616 already resolves `--config agent.<name>.<key>` into `WARD_*` keys). New precedence, a strict superset of today:

`WARD_* env  >  KDL bundle topology  >  baked neutral default`

Nothing that sets an env var today changes behavior - env still wins. The bundle only fills the slot the baked coilyco literal fills now. Convert each `envOr(...)` resolver to `envOrBundleOr(...)`.

**Stage it, no flag-day:**

* **Stage 1 (pure addition):** add the container-consts topology to the bundle + insert the bundle tier. A run with `WARD_CONFIG_REF` unset is byte-for-byte today.
* **Stage 2:** point the fleet's `container_compute.go` driver + infra at `WARD_CONFIG_REF`. The container path that **sets** these vars for children (`wardEnv`, `:605`) resolve

… (truncated to 2000 chars; full body is on this issue)

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

— Codex, via ward agent

🔒 Reserved by `ward agent --harness codex` — container `engineer-codex-ward-655` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-08T08:03:14Z). 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#655` · branch `issue-655` · harness `codex` · workflow `direct-main` - **Run:** `engineer-codex-ward-655` · ward `v0.443.0` · dispatched `2026-07-08T08:03:14Z` - **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 fs.FS seam + the resolver.** Coordinates with #539 (ward-kdl -> ward migration). ## Corrected scope vs the epic design comment The design proposed "add a topology section to the bundle (Stage 1)" for all ~14 `WARD_*` values. **aos#332 landing already moved half of it**: the endpoint topology (forgejo base, SSM paths, signoz, ollama) rode into aos's `.ward/` bundle **inside the guardfiles** (`ward-kdl.forgejo/signoz/ollama.guardfile.kdl`, `glitchtip.openapi.lock.json`). So this issue's real remaining surface is the **container consts** still hard-wired in `cmd/ward/container_compute.go`: * Tailnet + tower - `defaultTailnetNetwork` / `defaultTailnetProxy` / `defaultTowerHost` / `defaultTowerOllamaPort` (`:104-127`). * ollama / observe endpoints - `towerOllamaURL` (`:151`) and friends. * Substrate topology - `WARD_SUBSTRATE_SEED` / `_DEST` / `_MANIFEST` / `_TTL` (`:633-636`). ## Do Insert the bundle as a **middle tier** in the resolution that already exists (`container_compute.go:100` already treats these as env-over-baked-default DATA per ward#395, and ward#616 already resolves `--config agent.<name>.<key>` into `WARD_*` keys). New precedence, a strict superset of today: `WARD_* env > KDL bundle topology > baked neutral default` Nothing that sets an env var today changes behavior - env still wins. The bundle only fills the slot the baked coilyco literal fills now. Convert each `envOr(...)` resolver to `envOrBundleOr(...)`. **Stage it, no flag-day:** * **Stage 1 (pure addition):** add the container-consts topology to the bundle + insert the bundle tier. A run with `WARD_CONFIG_REF` unset is byte-for-byte today. * **Stage 2:** point the fleet's `container_compute.go` driver + infra at `WARD_CONFIG_REF`. The container path that **sets** these vars for children (`wardEnv`, `:605`) resolve ``` … (truncated to 2000 chars; full body is on this issue) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.443.0). </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a commit

2026-07-08 08:20:41 +00:00

ward: add container topology bundle tier

coilyco-ops closed this issue

2026-07-08 08:20:42 +00:00

coilyco-ops commented

2026-07-08 08:21:41 +00:00

Author

Member

WARD-OUTCOME: done - added the container topology bundle tier and env > bundle > default precedence.
The staged topology layer was straightforward once the asset split was settled. The only friction was the doc and comment budgets plus the missing alternate reviewer family, so I kept stage 1 conservative and left the fallback unchanged when the bundle file is absent.

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 - added the container topology bundle tier and env > bundle > default precedence. The staged topology layer was straightforward once the asset split was settled. The only friction was the doc and comment budgets plus the missing alternate reviewer family, so I kept stage 1 conservative and left the fallback unchanged when the bundle file is absent. 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 reopened this issue

2026-07-08 08:22:04 +00:00

coilyco-ops commented

2026-07-08 08:22:04 +00:00

Author

Member

⚠️ Reopened: this run's work did not land on `main`

An ephemeral ward container (codex mode) dispatched for this issue finished but its work was not merged to main, so the reaper preserved it on a branch before teardown and reopened the issue (its closes #655 never reached main). Recover from the salvage branch below.

Repo: coilyco-flight-deck/ward
Salvage branch: ward-salvage/ward-7ca66e36
Reason: missing same-repo closing reference
Container uptime at reap: 18m (age of the baked Forgejo PAT snapshot; a long-lived container is likelier to carry a rotated token)

Reap diagnostics

--- reap diagnostics ---
ward version:      v0.443.0
version source:    pinned via WARD_VERSION/--ward-version (v0.443.0)
HEAD:              d3c432f15c8c
origin/main:       adfa549c1b94
ancestry:          HEAD is NOT yet on origin/main - residual work remains to land
decision gate:     missing same-repo closing reference
reason:            missing same-repo closing reference
provenance:        present
run-owned landed:  yes
working tree:      1 dirty path(s)
container uptime:  18m (baked Forgejo PAT age proxy)
--- end reap diagnostics ---

Recover

git fetch https://forgejo.coilysiren.me/coilyco-flight-deck/ward.git ward-salvage/ward-7ca66e36
git checkout -b ward-salvage/ward-7ca66e36 FETCH_HEAD

Working tree at reap time

?? .ward-run-provenance.json

— Codex, via ward agent

## ⚠️ Reopened: this run's work did not land on `main` An ephemeral `ward container` (codex mode) dispatched for this issue finished but its work was **not merged to `main`**, so the reaper preserved it on a branch before teardown and reopened the issue (its `closes #655` never reached `main`). Recover from the salvage branch below. - **Repo:** `coilyco-flight-deck/ward` - **Salvage branch:** `ward-salvage/ward-7ca66e36` - **Reason:** missing same-repo closing reference - **Container uptime at reap:** 18m (age of the baked Forgejo PAT snapshot; a long-lived container is likelier to carry a rotated token) ## Reap diagnostics ``` --- reap diagnostics --- ward version: v0.443.0 version source: pinned via WARD_VERSION/--ward-version (v0.443.0) HEAD: d3c432f15c8c origin/main: adfa549c1b94 ancestry: HEAD is NOT yet on origin/main - residual work remains to land decision gate: missing same-repo closing reference reason: missing same-repo closing reference provenance: present run-owned landed: yes working tree: 1 dirty path(s) container uptime: 18m (baked Forgejo PAT age proxy) --- end reap diagnostics --- ``` ## Recover ```bash git fetch https://forgejo.coilysiren.me/coilyco-flight-deck/ward.git ward-salvage/ward-7ca66e36 git checkout -b ward-salvage/ward-7ca66e36 FETCH_HEAD ``` ## Working tree at reap time ``` ?? .ward-run-provenance.json ```  — Codex, via `ward agent`

coilyco-ops referenced this issue

2026-07-08 08:26:18 +00:00

Recover #655 topology fold from salvage branch #664

coilyco-ops referenced this issue from a commit

2026-07-08 08:30:42 +00:00

chore: recover topology-fold landing

coilyco-ops closed this issue

2026-07-08 08:30:42 +00:00

coilyco-ops referenced this issue

2026-07-08 08:31:04 +00:00

Recover #655 topology fold from salvage branch #664

coilyco-ops referenced this issue