coilyco-flight-deck/ward

Fork 0

Finish ward#453: neutralize ward's default bundle + re-point brew/release at the aos bundle #503

New issue

Closed

opened 2026-07-02 03:10:29 +00:00 by coilysiren · 5 comments

coilysiren commented

2026-07-02 03:10:29 +00:00

Owner

Status (refreshed 2026-07-02)

The (a)/(b) fork below is decided: (a) - neutral default in ward, and the deployment channels (tap + release) overlay the aos bundle. The old "overlay in the same change or the fleet breaks" framing is superseded by a safe staging order (the landing checklist on ward#453): each overlay step lands as a no-op while ward's tree is still coilyco, and only the final step flips the tree. So this no longer needs one risky lockstep push.

Prerequisite now met: aos#315 landed - the coilyco ward-specs/ bundle is homed on aos main (the ward#453 mechanism sits at b7fae91).

Context

ward#453 landed the swappable-input mechanism on main:

examples/ward-specs/ - a neutral starter bundle (forgejo guardfile + fleet).
the assets-dir convention (overlay cmd/ward-kdl/), documented in docs/ward-kdl-authoring.md.
TestExampleBundleHasNoCoilycoValues in cmd/ward - proves a build from the example bundle reproduces none of the #441 coupling.

What's left - the safe no-op-then-flip sequence

ward#453 done-condition 1 ("ward's tree contains no coilyco-specific endpoint/token/owner values") is met at the end of this ordered sequence. Each step is individually safe because an overlay onto a still-coilyco tree changes nothing:

aos (done, aos#315) - the coilyco ward-specs/ bundle is homed on aos main. Tighten-up: publish it as a pinned, checksummed release asset if only tracked files exist today, so steps 2-3 pin to an asset rather than a raw path.
homebrew-tap Formula/ward.rb (Kai, GitHub PR) - add a pinned + checksummed ward-specs resource and cp_r it into cmd/ward-kdl/ before the existing go build. Safe no-op while ward's tree is still coilyco. See the proposed block in the ward#453 landing-checklist comment.
ward .forgejo/workflows/release.yml - add the same overlay step (fail-closed on a blank pin), still against the coilyco tree. Safe no-op.
ward tree neutralization - reverse-overlay the neutral bundle then make build-ward-kdl, commit the neutral cmd/ward-kdl/ plus the embeds and the golden. Only now does the tree go clean, and both build sites already overlay, so no shipped artifact breaks.

Per-step green checks live in the ward#453 landing-checklist comment.

Tap source lives at Forgejo (infrastructure#440)

Decision (Kai, 2026-07-02): the homebrew-tap repo stays canonically on GitHub (so this tap edit lands as a GitHub PR), but the fleet installs from a Forgejo mirror of the tap, pointed there by infra-repo config - tracked in infrastructure#440. The formula's ward-specs resource URL already targets the aos Forgejo release asset, so the fleet build stays off github.com.

Human gate

Step 2 (the tap PR on GitHub) is Kai's to land - no autonomous run touches the fleet's install root. Steps 3-4 (ward) are dispatchable once step 2 lands. The spec-bundle half of ward#395 (forge base, SSM token path, registry image) folds into step 4 rather than moving separately.

ward#441 (the finding), ward#453 (the mechanism plus the landing checklist), aos#315 (the aos bundle, landed), ward#395 (infra-topology externalization), infrastructure#440 (tap source at Forgejo).

Dispatch note (2026-07-06, director loop): Kai greenlit the topology move

Kai cleared the cross-repo grant that blocked ward#453 three times. This run is dispatched with homebrew-tap and agentic-os granted writable, so the deployment-channel overlay (re-point the tap formula + wire the aos-side release) can actually land instead of blocking on missing access.

Follow the decided staging order (approach (a), safe no-op-until-final-flip): each overlay step lands green while ward's tree is still coilyco, and only the last step flips ward's default bundle neutral. Do not do the risky lockstep push.

Release-key caveat (Kai flagged): aos probably does not yet have auth to publish to Homebrew. This run can author the release/publish CI job and wire it, but minting and storing the actual release secret is a human/secret step Kai must do — a headless container cannot create the credential. If you reach the point where the publish needs the secret, land everything up to it, and clearly surface "release key needs provisioning by Kai" as the remaining step rather than treating the run as blocked from the start. Everything up to the secret is in scope.

Grants on this run: coilyco-flight-deck/homebrew-tap, coilyco-flight-deck/agentic-os (aos bundle already homed per aos#315, closed).

DECISION from Kai (2026-07-06): regenerate

The ward-side overlay architecture is decided: regenerate embeds from the source bundle at build time (NOT ship pre-generated embeds).

Concretely:

ward's build pulls the aos-published ward-specs-<tag>.tar.gz bundle (step 1 landed - the aos release job publishes it + .sha256, verified on v0.197.0, no release secret needed) and regenerates the embedded ward-kdl assets from that bundle at build time.
ward's own tree carries the neutral default bundle only (the examples/ward-specs/ example), so the tree stays coilyco-free. The coilyco deployment specifics come from the bundle at build, not from committed pre-generated embeds.
Then land the deployment-channel overlay (re-point the homebrew-tap formula + the release build) at the coilyco bundle, following the safe staging order (each overlay step lands green while the tree is still coilyco, the final step flips the default neutral). No risky lockstep.

Grants on this run: coilyco-flight-deck/homebrew-tap, coilyco-flight-deck/agentic-os. Finish ward#453/#503 with this architecture.

## Status (refreshed 2026-07-02) The (a)/(b) fork below is **decided: (a)** - neutral default in ward, and the deployment channels (tap + release) overlay the aos bundle. The old "overlay in the same change or the fleet breaks" framing is **superseded** by a safe staging order (the landing checklist on ward#453): each overlay step lands as a no-op while ward's tree is still coilyco, and only the final step flips the tree. So this no longer needs one risky lockstep push. **Prerequisite now met:** aos#315 landed - the coilyco `ward-specs/` bundle is homed on aos main (the ward#453 mechanism sits at `b7fae91`). ## Context ward#453 landed the swappable-input **mechanism** on main: - `examples/ward-specs/` - a neutral starter bundle (forgejo guardfile + fleet). - the assets-dir convention (overlay `cmd/ward-kdl/`), documented in `docs/ward-kdl-authoring.md`. - `TestExampleBundleHasNoCoilycoValues` in `cmd/ward` - proves a build from the example bundle reproduces none of the #441 coupling. ## What's left - the safe no-op-then-flip sequence ward#453 done-condition 1 ("ward's tree contains no coilyco-specific endpoint/token/owner values") is met at the end of this ordered sequence. Each step is individually safe because an overlay onto a still-coilyco tree changes nothing: 1. **aos** (done, aos#315) - the coilyco `ward-specs/` bundle is homed on aos main. Tighten-up: publish it as a pinned, checksummed release asset if only tracked files exist today, so steps 2-3 pin to an asset rather than a raw path. 2. **homebrew-tap `Formula/ward.rb`** (Kai, GitHub PR) - add a pinned + checksummed `ward-specs` `resource` and `cp_r` it into `cmd/ward-kdl/` before the existing `go build`. Safe no-op while ward's tree is still coilyco. See the proposed block in the ward#453 landing-checklist comment. 3. **ward `.forgejo/workflows/release.yml`** - add the same overlay step (fail-closed on a blank pin), still against the coilyco tree. Safe no-op. 4. **ward tree neutralization** - reverse-overlay the neutral bundle then `make build-ward-kdl`, commit the neutral `cmd/ward-kdl/` plus the embeds and the golden. Only now does the tree go clean, and both build sites already overlay, so no shipped artifact breaks. Per-step green checks live in the ward#453 landing-checklist comment. ## Tap source lives at Forgejo (infrastructure#440) Decision (Kai, 2026-07-02): the `homebrew-tap` repo stays **canonically on GitHub** (so this tap edit lands as a GitHub PR), but the **fleet installs from a Forgejo mirror of the tap**, pointed there by infra-repo config - tracked in **infrastructure#440**. The formula's `ward-specs` `resource` URL already targets the aos Forgejo release asset, so the fleet build stays off github.com. ## Human gate Step 2 (the tap PR on GitHub) is Kai's to land - no autonomous run touches the fleet's install root. Steps 3-4 (ward) are dispatchable once step 2 lands. The spec-bundle half of ward#395 (forge base, SSM token path, registry image) folds into step 4 rather than moving separately. ## Related ward#441 (the finding), ward#453 (the mechanism plus the landing checklist), aos#315 (the aos bundle, landed), ward#395 (infra-topology externalization), infrastructure#440 (tap source at Forgejo). --- ## Dispatch note (2026-07-06, director loop): Kai greenlit the topology move Kai cleared the cross-repo grant that blocked ward#453 three times. This run is dispatched with **homebrew-tap** and **agentic-os** granted writable, so the deployment-channel overlay (re-point the tap formula + wire the aos-side release) can actually land instead of blocking on missing access. Follow the decided staging order (approach (a), safe no-op-until-final-flip): each overlay step lands green while ward's tree is still coilyco, and only the last step flips ward's default bundle neutral. Do not do the risky lockstep push. **Release-key caveat (Kai flagged):** aos probably does **not** yet have auth to publish to Homebrew. This run can author the release/publish CI job and wire it, but **minting and storing the actual release secret is a human/secret step Kai must do** — a headless container cannot create the credential. If you reach the point where the publish needs the secret, land everything up to it, and clearly surface "release key needs provisioning by Kai" as the remaining step rather than treating the run as blocked from the start. Everything up to the secret is in scope. Grants on this run: coilyco-flight-deck/homebrew-tap, coilyco-flight-deck/agentic-os (aos bundle already homed per aos#315, closed). --- ## DECISION from Kai (2026-07-06): regenerate The ward-side overlay architecture is **decided: regenerate embeds from the source bundle at build time** (NOT ship pre-generated embeds). Concretely: - ward's build pulls the aos-published `ward-specs-<tag>.tar.gz` bundle (step 1 landed - the aos `release` job publishes it + `.sha256`, verified on v0.197.0, no release secret needed) and **regenerates the embedded ward-kdl assets from that bundle at build time.** - ward's own tree carries the **neutral** default bundle only (the `examples/ward-specs/` example), so the tree stays coilyco-free. The coilyco deployment specifics come from the bundle at build, not from committed pre-generated embeds. - Then land the deployment-channel overlay (re-point the homebrew-tap formula + the release build) at the coilyco bundle, following the safe staging order (each overlay step lands green while the tree is still coilyco, the final step flips the default neutral). No risky lockstep. Grants on this run: coilyco-flight-deck/homebrew-tap, coilyco-flight-deck/agentic-os. Finish ward#453/#503 with this architecture.

coilyco-ops added the

interactive

labels

2026-07-02 07:04:09 +00:00

coilyco-ops referenced this issue

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

Externalize infra topology hardcoded in ward: hosts, SSM, registry, telemetry (audit bucket C) #395

coilyco-ops commented

2026-07-06 00:51:40 +00:00

Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-503 on host KAI-DESKTOP-TOWER is carrying this issue (reserved 2026-07-06T00:51:37Z). 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#503 · branch issue-503 · driver claude · workflow direct-main
Run: engineer-claude-ward-503 · ward v0.406.0 · dispatched 2026-07-06T00:51:37Z
Comment thread: 0 included in the pre-flight read, 0 stripped (ward's own automated comments).

Issue body as seeded:

## Status (refreshed 2026-07-02)

The (a)/(b) fork below is **decided: (a)** - neutral default in ward, and the deployment channels (tap + release) overlay the aos bundle. The old "overlay in the same change or the fleet breaks" framing is **superseded** by a safe staging order (the landing checklist on ward#453): each overlay step lands as a no-op while ward's tree is still coilyco, and only the final step flips the tree. So this no longer needs one risky lockstep push.

**Prerequisite now met:** aos#315 landed - the coilyco `ward-specs/` bundle is homed on aos main (the ward#453 mechanism sits at `b7fae91`).

## Context

ward#453 landed the swappable-input **mechanism** on main:

- `examples/ward-specs/` - a neutral starter bundle (forgejo guardfile + fleet).
- the assets-dir convention (overlay `cmd/ward-kdl/`), documented in `docs/ward-kdl-authoring.md`.
- `TestExampleBundleHasNoCoilycoValues` in `cmd/ward` - proves a build from the example bundle reproduces none of the #441 coupling.

## What's left - the safe no-op-then-flip sequence

ward#453 done-condition 1 ("ward's tree contains no coilyco-specific endpoint/token/owner values") is met at the end of this ordered sequence. Each step is individually safe because an overlay onto a still-coilyco tree changes nothing:

1. **aos** (done, aos#315) - the coilyco `ward-specs/` bundle is homed on aos main. Tighten-up: publish it as a pinned, checksummed release asset if only tracked files exist today, so steps 2-3 pin to an asset rather than a raw path.
2. **homebrew-tap `Formula/ward.rb`** (Kai, GitHub PR) - add a pinned + checksummed `ward-specs` `resource` and `cp_r` it into `cmd/ward-kdl/` before the existing `go build`. Safe no-op while ward's tree is still coilyco. See the proposed block in the ward#453 landing-checklist comment.
3. **ward `.forgejo/workflows/release.yml`** - add the same overlay step (fail-closed on a blank pin), still against the coilyco tree. Safe no-op.
4. **ward tree neutralization** - rev

… (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.406.0).

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-503` on host `KAI-DESKTOP-TOWER` is carrying this issue (reserved 2026-07-06T00:51:37Z). 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#503` · branch `issue-503` · driver `claude` · workflow `direct-main` - **Run:** `engineer-claude-ward-503` · ward `v0.406.0` · dispatched `2026-07-06T00:51:37Z` - **Comment thread:** 0 included in the pre-flight read, 0 stripped (ward's own automated comments). **Issue body as seeded:** ``` ## Status (refreshed 2026-07-02) The (a)/(b) fork below is **decided: (a)** - neutral default in ward, and the deployment channels (tap + release) overlay the aos bundle. The old "overlay in the same change or the fleet breaks" framing is **superseded** by a safe staging order (the landing checklist on ward#453): each overlay step lands as a no-op while ward's tree is still coilyco, and only the final step flips the tree. So this no longer needs one risky lockstep push. **Prerequisite now met:** aos#315 landed - the coilyco `ward-specs/` bundle is homed on aos main (the ward#453 mechanism sits at `b7fae91`). ## Context ward#453 landed the swappable-input **mechanism** on main: - `examples/ward-specs/` - a neutral starter bundle (forgejo guardfile + fleet). - the assets-dir convention (overlay `cmd/ward-kdl/`), documented in `docs/ward-kdl-authoring.md`. - `TestExampleBundleHasNoCoilycoValues` in `cmd/ward` - proves a build from the example bundle reproduces none of the #441 coupling. ## What's left - the safe no-op-then-flip sequence ward#453 done-condition 1 ("ward's tree contains no coilyco-specific endpoint/token/owner values") is met at the end of this ordered sequence. Each step is individually safe because an overlay onto a still-coilyco tree changes nothing: 1. **aos** (done, aos#315) - the coilyco `ward-specs/` bundle is homed on aos main. Tighten-up: publish it as a pinned, checksummed release asset if only tracked files exist today, so steps 2-3 pin to an asset rather than a raw path. 2. **homebrew-tap `Formula/ward.rb`** (Kai, GitHub PR) - add a pinned + checksummed `ward-specs` `resource` and `cp_r` it into `cmd/ward-kdl/` before the existing `go build`. Safe no-op while ward's tree is still coilyco. See the proposed block in the ward#453 landing-checklist comment. 3. **ward `.forgejo/workflows/release.yml`** - add the same overlay step (fail-closed on a blank pin), still against the coilyco tree. Safe no-op. 4. **ward tree neutralization** - rev ``` … (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.406.0). </details>  — Claude (she/her), via `ward agent`

coilysiren commented

2026-07-06 01:09:28 +00:00

Author

Owner

Step 1 landed, and cleaner than expected. The aos release job now publishes ward-specs-<tag>.tar.gz + a .sha256 on every release. It already shipped on v0.197.0 (sha256 24cfe2c2bcfe818fcfec2e63b871f2adbba00f8fd9bac8261e60e3742f7c7526, reproducible from the tracked bundle). Nice surprise: it needs no release secret - the built-in job token create-release already uses carries contents: write, so your "release key needs provisioning" caveat does not apply to the aos side. Push verified on aos main, release run went green.

Why I stopped before touching the fleet. The frozen step-2 block (cp_r the bundle into cmd/ward-kdl, then the unchanged go build ./cmd/ward) no longer works against ward's tree. go build ./cmd/ward embeds the committed generated assets under cmd/ward/{opsassets,execassets,fleetassets}, not the .ward/ward-kdl/ guardfiles (that dir moved out of cmd/ward-kdl in ward#435, and the build never runs make). So overlaying source guardfiles changes nothing in the binary - a neutralized tree plus that formula would ship a neutral, broken ward to the fleet. Same class of failure the reverted sibling-checkout attempt (b7fae91 -> 6f12a09) hit.

The fork you need to settle. To actually inject coilyco values at build time:

(a) regenerate - the formula runs make build-ward-kdl (the kdl-specs driver) after overlaying the source bundle, then builds. Keeps the aos asset pure source, but adds an install-time generator step to every fleet host.
(b) ship embeds - the aos asset carries the coilyco opsassets/fleetassets/execassets, and both build sites cp them over ward's tree with a plain build. No install-time generator, but the deploy asset now tracks ward's embed layout.

I lean (a) (honors "reference repo ships source, not compiled artifacts", reuses the module the build already fetches), but it changes fleet brew install either way and I can't run a real brew --build-from-source headless, so I did not want to ship it unratified. Two notes for whoever wires it: the aos bundle only homes the coilyco-carrying subset (forgejo, fleet, ollama, signoz), so the eco-* guardfiles (X:/...coilyco-flight-deck, /home/kai paths) still need a home or separate handling (ward#395), and the tap is Forgejo-canonical now, so the re-point is a push, not a GitHub PR.

Confidence: high on the aos asset (published, checksummed, reproducible, CI-green). The tap + release.yml + tree-flip are one coupled, fleet-install-path change gated on (a)/(b) - I left ward and homebrew-tap untouched, so nothing half-wired is live. Once you pick: wire both build sites to overlay v0.197.0's asset, verify a from-source build reproduces today's embeds byte-for-byte, then flip ward's tree in the same change.

WARD-OUTCOME: blocked - need Kai to pick the ward-side overlay architecture (regenerate embeds from the source bundle at build time, vs ship pre-generated embeds) before the tap/release overlay + tree-flip can land; step 1 (aos ward-specs release-asset publish) landed and is verified working. **Step 1 landed, and cleaner than expected.** The aos `release` job now publishes `ward-specs-<tag>.tar.gz` + a `.sha256` on every release. It already shipped on **v0.197.0** (`sha256 24cfe2c2bcfe818fcfec2e63b871f2adbba00f8fd9bac8261e60e3742f7c7526`, reproducible from the tracked bundle). Nice surprise: it needs **no release secret** - the built-in job token create-release already uses carries `contents: write`, so your "release key needs provisioning" caveat does not apply to the aos side. Push verified on aos main, release run went green. **Why I stopped before touching the fleet.** The frozen step-2 block (`cp_r` the bundle into `cmd/ward-kdl`, then the unchanged `go build ./cmd/ward`) no longer works against ward's tree. `go build ./cmd/ward` embeds the committed generated assets under `cmd/ward/{opsassets,execassets,fleetassets}`, not the `.ward/ward-kdl/` guardfiles (that dir moved out of `cmd/ward-kdl` in ward#435, and the build never runs `make`). So overlaying source guardfiles changes nothing in the binary - a neutralized tree plus that formula would ship a **neutral, broken ward** to the fleet. Same class of failure the reverted sibling-checkout attempt (b7fae91 -> 6f12a09) hit. **The fork you need to settle.** To actually inject coilyco values at build time: - **(a) regenerate** - the formula runs `make build-ward-kdl` (the kdl-specs driver) after overlaying the source bundle, then builds. Keeps the aos asset pure source, but adds an install-time generator step to every fleet host. - **(b) ship embeds** - the aos asset carries the coilyco `opsassets/fleetassets/execassets`, and both build sites `cp` them over ward's tree with a plain build. No install-time generator, but the deploy asset now tracks ward's embed layout. I lean **(a)** (honors "reference repo ships source, not compiled artifacts", reuses the module the build already fetches), but it changes fleet `brew install` either way and I can't run a real `brew --build-from-source` headless, so I did not want to ship it unratified. Two notes for whoever wires it: the aos bundle only homes the coilyco-carrying subset (forgejo, fleet, ollama, signoz), so the eco-* guardfiles (`X:/...coilyco-flight-deck`, `/home/kai` paths) still need a home or separate handling (ward#395), and the tap is Forgejo-canonical now, so the re-point is a push, not a GitHub PR. **Confidence:** high on the aos asset (published, checksummed, reproducible, CI-green). The tap + release.yml + tree-flip are one coupled, fleet-install-path change gated on (a)/(b) - I left ward and homebrew-tap untouched, so nothing half-wired is live. Once you pick: wire both build sites to overlay v0.197.0's asset, verify a from-source build reproduces today's embeds byte-for-byte, then flip ward's tree in the same change.

coilyco-ops commented

2026-07-06 01:59:47 +00:00

Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-503 on host KAI-DESKTOP-TOWER is carrying this issue (reserved 2026-07-06T01:59:43Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

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

Resolved: coilyco-flight-deck/ward#503 · branch issue-503 · driver claude · workflow direct-main
Run: engineer-claude-ward-503 · ward v0.406.0 · dispatched 2026-07-06T01:59:43Z
Comment thread: 1 included in the pre-flight read, 1 stripped (ward's own automated comments).
- included: @coilysiren (2026-07-06T01:09:28Z)
- stripped: @coilyco-ops (2026-07-06T00:51:40Z)

Issue body as seeded:

## Status (refreshed 2026-07-02)

The (a)/(b) fork below is **decided: (a)** - neutral default in ward, and the deployment channels (tap + release) overlay the aos bundle. The old "overlay in the same change or the fleet breaks" framing is **superseded** by a safe staging order (the landing checklist on ward#453): each overlay step lands as a no-op while ward's tree is still coilyco, and only the final step flips the tree. So this no longer needs one risky lockstep push.

**Prerequisite now met:** aos#315 landed - the coilyco `ward-specs/` bundle is homed on aos main (the ward#453 mechanism sits at `b7fae91`).

## Context

ward#453 landed the swappable-input **mechanism** on main:

- `examples/ward-specs/` - a neutral starter bundle (forgejo guardfile + fleet).
- the assets-dir convention (overlay `cmd/ward-kdl/`), documented in `docs/ward-kdl-authoring.md`.
- `TestExampleBundleHasNoCoilycoValues` in `cmd/ward` - proves a build from the example bundle reproduces none of the #441 coupling.

## What's left - the safe no-op-then-flip sequence

ward#453 done-condition 1 ("ward's tree contains no coilyco-specific endpoint/token/owner values") is met at the end of this ordered sequence. Each step is individually safe because an overlay onto a still-coilyco tree changes nothing:

1. **aos** (done, aos#315) - the coilyco `ward-specs/` bundle is homed on aos main. Tighten-up: publish it as a pinned, checksummed release asset if only tracked files exist today, so steps 2-3 pin to an asset rather than a raw path.
2. **homebrew-tap `Formula/ward.rb`** (Kai, GitHub PR) - add a pinned + checksummed `ward-specs` `resource` and `cp_r` it into `cmd/ward-kdl/` before the existing `go build`. Safe no-op while ward's tree is still coilyco. See the proposed block in the ward#453 landing-checklist comment.
3. **ward `.forgejo/workflows/release.yml`** - add the same overlay step (fail-closed on a blank pin), still against the coilyco tree. Safe no-op.
4. **ward tree neutralization** - rev

… (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.406.0).

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-503` on host `KAI-DESKTOP-TOWER` is carrying this issue (reserved 2026-07-06T01:59:43Z). 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#503` · branch `issue-503` · driver `claude` · workflow `direct-main` - **Run:** `engineer-claude-ward-503` · ward `v0.406.0` · dispatched `2026-07-06T01:59:43Z` - **Comment thread:** 1 included in the pre-flight read, 1 stripped (ward's own automated comments). - included: @coilysiren (2026-07-06T01:09:28Z) - stripped: @coilyco-ops (2026-07-06T00:51:40Z) **Issue body as seeded:** ``` ## Status (refreshed 2026-07-02) The (a)/(b) fork below is **decided: (a)** - neutral default in ward, and the deployment channels (tap + release) overlay the aos bundle. The old "overlay in the same change or the fleet breaks" framing is **superseded** by a safe staging order (the landing checklist on ward#453): each overlay step lands as a no-op while ward's tree is still coilyco, and only the final step flips the tree. So this no longer needs one risky lockstep push. **Prerequisite now met:** aos#315 landed - the coilyco `ward-specs/` bundle is homed on aos main (the ward#453 mechanism sits at `b7fae91`). ## Context ward#453 landed the swappable-input **mechanism** on main: - `examples/ward-specs/` - a neutral starter bundle (forgejo guardfile + fleet). - the assets-dir convention (overlay `cmd/ward-kdl/`), documented in `docs/ward-kdl-authoring.md`. - `TestExampleBundleHasNoCoilycoValues` in `cmd/ward` - proves a build from the example bundle reproduces none of the #441 coupling. ## What's left - the safe no-op-then-flip sequence ward#453 done-condition 1 ("ward's tree contains no coilyco-specific endpoint/token/owner values") is met at the end of this ordered sequence. Each step is individually safe because an overlay onto a still-coilyco tree changes nothing: 1. **aos** (done, aos#315) - the coilyco `ward-specs/` bundle is homed on aos main. Tighten-up: publish it as a pinned, checksummed release asset if only tracked files exist today, so steps 2-3 pin to an asset rather than a raw path. 2. **homebrew-tap `Formula/ward.rb`** (Kai, GitHub PR) - add a pinned + checksummed `ward-specs` `resource` and `cp_r` it into `cmd/ward-kdl/` before the existing `go build`. Safe no-op while ward's tree is still coilyco. See the proposed block in the ward#453 landing-checklist comment. 3. **ward `.forgejo/workflows/release.yml`** - add the same overlay step (fail-closed on a blank pin), still against the coilyco tree. Safe no-op. 4. **ward tree neutralization** - rev ``` … (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.406.0). </details>  — Claude (she/her), via `ward agent`

coilysiren referenced this issue from a commit

2026-07-06 02:32:54 +00:00

chore(ward-specs): refresh bundle to ward's current values + document the cp-overlay

coilysiren commented

2026-07-06 02:39:52 +00:00

Author

Owner

WARD-OUTCOME: blocked - the ward-side flip needs Kai to land + verify it in a real brew install and a real ward agent container, because the neutral binary reaches the fleet through five build sites (two unverifiable headless) and a wrong overlay bricks agent dispatch fleet-wide. The aos prerequisite landed and is verified.

What landed (aos, verified). Refreshed the published ward-specs bundle to ward's current coilyco values and cut v0.198.0 (ward-specs-v0.198.0.tar.gz, sha256 b2d913b17d7920656dedb3b792521ab2c47290e5f1e6207d4de4241f3fa74502). This matters: the prior asset (v0.197.0) was stale - it predated the delete issue-comment leaf, the fleet roles block, and the doc-link footers - so no existing asset could be a no-op overlay source. I verified the refresh two ways: the tarball is deterministic (my local precompute matched the CI-published sha exactly), and downloading the real published asset, overlaying its three source files onto a neutralized ward tree, reproduces ward's committed opsassets/fleetassets/execassets embeds byte-for-byte. aos docs/ward-specs.md now documents the decided overlay too.

Why I stopped before flipping ward. I built and locally proved the whole flip (neutralize forgejo guardfile + fleet + ollama, regenerate embeds, go test ./... green, overlay reproduces byte-for-byte) - then found the wall the staging checklist did not name. go build ./cmd/ward embeds the committed assets, so every place that builds ward from source must overlay, not just brew + release.yml. There are five: (1) the brew formula, (2) release.yml publish-binaries, (3) publish-kdl-write, (4) publish-kdl-read, and the two that make this dangerous - (5) the aos dev-base Dockerfile:276 and ward's own entrypoint.sh:254, both plain go build ./cmd/ward with no overlay. Those two are how the ward agent container gets its ward binary. Flip the tree without overlaying them and every container ships a neutral broker: ward ops forgejo points at git.example.com, comments/reservations/the reaper all break - fleet-wide dispatch failure. brew install and live container dispatch are exactly the two I cannot exercise in a headless box, and a miss there is not reversible-cheap, it is a broken fleet. So I reverted my ward edits and left ward + homebrew-tap untouched: nothing half-wired is live, same stance as the prior run.

One design call for you to accept or reject. I would overlay by plain file-copy of the bundle's source guardfiles over the embeds (what make sync-*-assets already does), not by running make build-ward-kdl in each sandbox as (a) was framed. Same result - embeds re-derived from the pinned source bundle - but deterministic, no install-time kdl-specs generator, and no live swagger re-fetch that could drift or fail in Homebrew's sandbox. It is what I proved byte-for-byte. It also decouples the shipped binary from the tier-lock generation.

The ready recipe for whoever lands it (in a real brew + container env). Pin WARD_SPECS_TAG=v0.198.0 + that sha256, and at each of the five sites: curl the asset, sha256sum -c (fail-closed - abort, never build), extract, then cp ward-kdl.forgejo.guardfile.kdl->cmd/ward/opsassets/forgejo.guardfile.generated.kdl, ward-kdl.fleet.kdl->cmd/ward/fleetassets/fleet.generated.kdl, ward-kdl.ollama.guardfile.kdl->cmd/ward/execassets/ward-kdl.ollama.guardfile.kdl, then build. Guard each site so a mis-cp cannot silently ship neutral (assert the opsassets embed no longer contains git.example.com). Land all five green (no-op while the tree is still coilyco), then flip the tree in one last push. The forgejo swagger lock is already deployment-agnostic, so it needs no overlay.

Scope note. This resolves ward#441 for the shipped ward binary's default bundle (forgejo endpoint/token/owner, bot attribution, ollama host). The broker/director tier guardfiles (ward-kdl-{read,write,admin}/) and signoz still carry coilyco base-url/SSM values, and the eco-* guardfiles carry /home/kai / X:/ host paths - those are internal-infra, higher blast radius, and eco is ward#395. I would neutralize them in a follow-up once the shipped-binary flip is proven, not fold them into the same fleet-critical push.

Confidence. High on the aos refresh (deterministic, checksum-verified, reproduces byte-for-byte, CI-green). High that the cp-overlay is correct. The irreducible gap is that no headless run can verify a real brew install --build-from-source or a real container dispatch, and those are the two sites where a wrong overlay is fleet-breaking - which is why this is your flip to land, not mine.

WARD-OUTCOME: blocked - the ward-side flip needs Kai to land + verify it in a real `brew install` and a real `ward agent` container, because the neutral binary reaches the fleet through five build sites (two unverifiable headless) and a wrong overlay bricks agent dispatch fleet-wide. The aos prerequisite landed and is verified. **What landed (aos, verified).** Refreshed the published `ward-specs` bundle to ward's *current* coilyco values and cut **v0.198.0** (`ward-specs-v0.198.0.tar.gz`, sha256 `b2d913b17d7920656dedb3b792521ab2c47290e5f1e6207d4de4241f3fa74502`). This matters: the prior asset (v0.197.0) was stale - it predated the `delete issue-comment` leaf, the fleet `roles` block, and the doc-link footers - so no existing asset could be a no-op overlay source. I verified the refresh two ways: the tarball is deterministic (my local precompute matched the CI-published sha exactly), and downloading the real published asset, overlaying its three source files onto a neutralized ward tree, reproduces ward's committed `opsassets`/`fleetassets`/`execassets` embeds **byte-for-byte**. aos docs/ward-specs.md now documents the decided overlay too. **Why I stopped before flipping ward.** I built and locally proved the whole flip (neutralize forgejo guardfile + fleet + ollama, regenerate embeds, `go test ./...` green, overlay reproduces byte-for-byte) - then found the wall the staging checklist did not name. `go build ./cmd/ward` embeds the committed assets, so *every* place that builds ward from source must overlay, not just brew + release.yml. There are **five**: (1) the brew formula, (2) release.yml `publish-binaries`, (3) `publish-kdl-write`, (4) `publish-kdl-read`, and the two that make this dangerous - **(5) the aos dev-base `Dockerfile:276` and ward's own `entrypoint.sh:254`, both plain `go build ./cmd/ward` with no overlay**. Those two are how the `ward agent` container gets its `ward` binary. Flip the tree without overlaying them and every container ships a neutral broker: `ward ops forgejo` points at `git.example.com`, comments/reservations/the reaper all break - fleet-wide dispatch failure. brew install and live container dispatch are exactly the two I cannot exercise in a headless box, and a miss there is not reversible-cheap, it is a broken fleet. So I reverted my ward edits and left ward + homebrew-tap untouched: nothing half-wired is live, same stance as the prior run. **One design call for you to accept or reject.** I would overlay by **plain file-copy of the bundle's source guardfiles over the embeds** (what `make sync-*-assets` already does), *not* by running `make build-ward-kdl` in each sandbox as (a) was framed. Same result - embeds re-derived from the pinned source bundle - but deterministic, no install-time kdl-specs generator, and no live swagger re-fetch that could drift or fail in Homebrew's sandbox. It is what I proved byte-for-byte. It also decouples the shipped binary from the tier-lock generation. **The ready recipe for whoever lands it (in a real brew + container env).** Pin `WARD_SPECS_TAG=v0.198.0` + that sha256, and at each of the five sites: curl the asset, `sha256sum -c` (fail-closed - abort, never build), extract, then `cp` `ward-kdl.forgejo.guardfile.kdl`->`cmd/ward/opsassets/forgejo.guardfile.generated.kdl`, `ward-kdl.fleet.kdl`->`cmd/ward/fleetassets/fleet.generated.kdl`, `ward-kdl.ollama.guardfile.kdl`->`cmd/ward/execassets/ward-kdl.ollama.guardfile.kdl`, then build. Guard each site so a mis-cp cannot silently ship neutral (assert the opsassets embed no longer contains `git.example.com`). Land all five green (no-op while the tree is still coilyco), *then* flip the tree in one last push. The forgejo swagger lock is already deployment-agnostic, so it needs no overlay. **Scope note.** This resolves ward#441 for the shipped `ward` binary's default bundle (forgejo endpoint/token/owner, bot attribution, ollama host). The broker/director **tier** guardfiles (`ward-kdl-{read,write,admin}/`) and **signoz** still carry coilyco base-url/SSM values, and the **eco-*** guardfiles carry `/home/kai` / `X:/` host paths - those are internal-infra, higher blast radius, and eco is ward#395. I would neutralize them in a follow-up once the shipped-binary flip is proven, not fold them into the same fleet-critical push. **Confidence.** High on the aos refresh (deterministic, checksum-verified, reproduces byte-for-byte, CI-green). High that the cp-overlay is correct. The irreducible gap is that no headless run can verify a real `brew install --build-from-source` or a real container dispatch, and those are the two sites where a wrong overlay is fleet-breaking - which is why this is your flip to land, not mine.

coilysiren closed this issue

2026-07-06 20:30:59 +00:00

coilyco-ops referenced this issue

2026-07-07 21:57:36 +00:00

Land the #503 flip residual: wire the release.yml aos-bundle overlay (no-op, tree stays coilyco) #644

coilyco-ops commented

2026-07-07 21:57:48 +00:00

Member

Residual flip (release.yml aos-bundle overlay, step 3) split out to #644 and dispatched as a headless engineer run. This issue was closed on the aos-publish half (aos#315); #644 tracks landing the ward-side build overlay as a no-op, with tree neutralization (step 4) + the tap PR (step 2, Kai's GitHub gate) still downstream. Filed from the read-only director surface (she/her).

coilyco-ops referenced this issue from a commit

2026-07-07 22:19:00 +00:00

feat(release): overlay the pinned aos ward-specs bundle before go build (#503 step 3)

coilyco-ops referenced this issue

2026-07-07 22:21:46 +00:00

Land the #503 flip residual: wire the release.yml aos-bundle overlay (no-op, tree stays coilyco) #644

coilyco-ops referenced this issue

2026-07-07 23:40:21 +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-09 17:07:48 +00:00

Design warded role capability tiers before adding ops #819