coilyco-flight-deck/ward

Fork 0

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

New issue

Closed

opened 2026-07-07 21:57:36 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

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

Member

What this is

Residual of #503 (which was closed on the aos-publish half, not the final flip). The aos side of the ward-kdl spec-bundle cutover is live - coilyco-flight-deck/agentic-os publishes ward-specs-<tag>.tar.gz + .sha256 as a pinned, checksummed release asset (aos#315, verified on v0.197.0). But ward itself is still compiled primarily via ward, not via the aos bundle. Two things confirm the flip has not landed in this tree (verified 2026-07-07):

.forgejo/workflows/release.yml builds go build ./cmd/ward straight from the checked-out tree, with no fetch or overlay of the aos ward-specs bundle before the build. (grep -niE 'ward-specs|overlay|bundle' matches only SHA256SUMS comment lines.)
.ward/ward-kdl/ still carries the coilyco values in ~18 files (ward-kdl.forgejo.guardfile.kdl, ward-kdl.fleet.kdl, the signoz/skillsmp specs). docs/ward-kdl-authoring.md:61 still says so literally: "Ward's own tracked bundle still carries the coilyco values today (#441)."

So a released ward binary embeds coilyco from its own tree, which is exactly the state #441/#453/#503 set out to end.

The decided approach (do not re-litigate)

From #503, Kai's 2026-07-06 decision: regenerate the ward-kdl embeds from the aos-published source bundle at build time. ward's own tree carries the neutral examples/ward-specs/ bundle only; the coilyco deployment values come from the aos bundle at build, not from committed embeds. The mechanism (assets-dir convention, make build-ward-kdl reading .ward/ward-kdl/, the neutral example, TestExampleBundleHasNoCoilycoValues) already landed under #453.

Safe staging order - this is load-bearing, do not shortcut it

The #453 landing checklist mandates no-op-then-flip: every overlay step lands green while ward's tree is still coilyco (overlaying coilyco onto coilyco changes nothing), and only the final step flips the tree neutral, by which point both build sites already overlay so no shipped artifact breaks. Do not do a risky lockstep push, and do not neutralize the tree before the build sites overlay.

The two build sites:

homebrew-tap Formula/ward.rb (step 2) - Kai's human gate, lands as a GitHub PR, out of scope for a headless run (no autonomous run touches the fleet install root).
ward .forgejo/workflows/release.yml (step 3) - this issue's dispatchable scope.

Scope for this run (step 3 only)

Wire release.yml to produce the shipped binaries from the aos coilyco bundle, as a no-op while the tree is still coilyco:

Before the go build ./cmd/ward loop, fetch the pinned aos ward-specs-<tag>.tar.gz, verify its .sha256, overlay it into .ward/ward-kdl/, and regenerate embeds (make build-ward-kdl / the tier builds) so the binary embeds the bundle-derived assets.
Pin the aos bundle tag explicitly and fail-closed on a blank/missing pin (mirror the -z guard the other release jobs use). A blank pin must fail the job, never silently ship the neutral tree.
This is a no-op for the shipped artifact today (coilyco onto coilyco), so the release stays byte-equivalent in the values that matter. Prove that.

Explicitly OUT of scope for this run

Step 4 (tree neutralization) - do NOT flip .ward/ward-kdl/ to neutral in this run. It is only safe once BOTH build sites overlay, and step 2 (the tap PR) is Kai's GitHub-side human gate. Neutralizing now would ship a neutral brew-installed ward. Land step 3, verify it green, then surface "step 2 (tap overlay) + step 4 (tree neutralization) remain, step 2 is Kai's GitHub gate" as the remaining work.
#550 (the publish-kdl-write package-token 401) is a separate admin-secret gate, not this.

Acceptance

release.yml fetches + sha256-verifies + overlays the pinned aos ward-specs bundle and regenerates embeds before go build, fail-closed on a blank pin.
A release run is green and the shipped binaries carry the same coilyco surface as today (no-op proven, e.g. the ops-forgejo base/owner unchanged).
The tree is untouched in its coilyco-ness (step 4 not done here); the doc/status note names the remaining gated steps.

#503 (finish/decision), #453 (mechanism + landing checklist), #441 (finding), aos#315 (aos bundle, landed), #539 (ward-kdl -> ward migration tracker), #550 (package-token 401, separate gate). Filed from the read-only director surface (she/her).

## What this is Residual of **#503** (which was closed on the aos-publish half, not the final flip). The aos side of the ward-kdl spec-bundle cutover is live - `coilyco-flight-deck/agentic-os` publishes `ward-specs-<tag>.tar.gz` + `.sha256` as a pinned, checksummed release asset (aos#315, verified on v0.197.0). But ward itself is **still compiled primarily via ward**, not via the aos bundle. Two things confirm the flip has not landed in this tree (verified 2026-07-07): - **`.forgejo/workflows/release.yml`** builds `go build ./cmd/ward` straight from the checked-out tree, with **no fetch or overlay** of the aos `ward-specs` bundle before the build. (`grep -niE 'ward-specs|overlay|bundle'` matches only SHA256SUMS comment lines.) - **`.ward/ward-kdl/`** still carries the coilyco values in ~18 files (`ward-kdl.forgejo.guardfile.kdl`, `ward-kdl.fleet.kdl`, the signoz/skillsmp specs). `docs/ward-kdl-authoring.md:61` still says so literally: "Ward's own tracked bundle still carries the coilyco values today (#441)." So a released ward binary embeds coilyco from its own tree, which is exactly the state #441/#453/#503 set out to end. ## The decided approach (do not re-litigate) From #503, Kai's 2026-07-06 decision: **regenerate the ward-kdl embeds from the aos-published source bundle at build time.** ward's own tree carries the **neutral** `examples/ward-specs/` bundle only; the coilyco deployment values come from the aos bundle at build, not from committed embeds. The mechanism (assets-dir convention, `make build-ward-kdl` reading `.ward/ward-kdl/`, the neutral example, `TestExampleBundleHasNoCoilycoValues`) already landed under #453. ## Safe staging order - this is load-bearing, do not shortcut it The #453 landing checklist mandates **no-op-then-flip**: every overlay step lands green while ward's tree is still coilyco (overlaying coilyco onto coilyco changes nothing), and only the **final** step flips the tree neutral, by which point both build sites already overlay so no shipped artifact breaks. Do **not** do a risky lockstep push, and do **not** neutralize the tree before the build sites overlay. The two build sites: 1. **homebrew-tap `Formula/ward.rb`** (step 2) - Kai's human gate, lands as a **GitHub PR**, out of scope for a headless run (no autonomous run touches the fleet install root). 2. **ward `.forgejo/workflows/release.yml`** (step 3) - **this issue's dispatchable scope.** ## Scope for this run (step 3 only) Wire `release.yml` to produce the shipped binaries from the **aos coilyco bundle**, as a **no-op while the tree is still coilyco**: - Before the `go build ./cmd/ward` loop, fetch the pinned aos `ward-specs-<tag>.tar.gz`, verify its `.sha256`, overlay it into `.ward/ward-kdl/`, and regenerate embeds (`make build-ward-kdl` / the tier builds) so the binary embeds the bundle-derived assets. - **Pin the aos bundle tag explicitly and fail-closed on a blank/missing pin** (mirror the `-z` guard the other release jobs use). A blank pin must fail the job, never silently ship the neutral tree. - This is a no-op for the shipped artifact today (coilyco onto coilyco), so the release stays byte-equivalent in the values that matter. Prove that. ## Explicitly OUT of scope for this run - **Step 4 (tree neutralization)** - do NOT flip `.ward/ward-kdl/` to neutral in this run. It is only safe once BOTH build sites overlay, and step 2 (the tap PR) is Kai's GitHub-side human gate. Neutralizing now would ship a neutral brew-installed ward. Land step 3, verify it green, then surface "step 2 (tap overlay) + step 4 (tree neutralization) remain, step 2 is Kai's GitHub gate" as the remaining work. - **#550** (the `publish-kdl-write` package-token 401) is a separate admin-secret gate, not this. ## Acceptance - `release.yml` fetches + sha256-verifies + overlays the pinned aos `ward-specs` bundle and regenerates embeds before `go build`, fail-closed on a blank pin. - A release run is green and the shipped binaries carry the same coilyco surface as today (no-op proven, e.g. the ops-forgejo base/owner unchanged). - The tree is untouched in its coilyco-ness (step 4 not done here); the doc/status note names the remaining gated steps. ## Related #503 (finish/decision), #453 (mechanism + landing checklist), #441 (finding), aos#315 (aos bundle, landed), #539 (ward-kdl -> ward migration tracker), #550 (package-token 401, separate gate). Filed from the read-only director surface (she/her).

coilyco-ops added the

headless

labels

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

coilyco-ops referenced this issue

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

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

coilyco-ops commented

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

Author

Member

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

Issue body as seeded:

## What this is

Residual of **#503** (which was closed on the aos-publish half, not the final flip). The aos side of the ward-kdl spec-bundle cutover is live - `coilyco-flight-deck/agentic-os` publishes `ward-specs-<tag>.tar.gz` + `.sha256` as a pinned, checksummed release asset (aos#315, verified on v0.197.0). But ward itself is **still compiled primarily via ward**, not via the aos bundle. Two things confirm the flip has not landed in this tree (verified 2026-07-07):

- **`.forgejo/workflows/release.yml`** builds `go build ./cmd/ward` straight from the checked-out tree, with **no fetch or overlay** of the aos `ward-specs` bundle before the build. (`grep -niE 'ward-specs|overlay|bundle'` matches only SHA256SUMS comment lines.)
- **`.ward/ward-kdl/`** still carries the coilyco values in ~18 files (`ward-kdl.forgejo.guardfile.kdl`, `ward-kdl.fleet.kdl`, the signoz/skillsmp specs). `docs/ward-kdl-authoring.md:61` still says so literally: "Ward's own tracked bundle still carries the coilyco values today (#441)."

So a released ward binary embeds coilyco from its own tree, which is exactly the state #441/#453/#503 set out to end.

## The decided approach (do not re-litigate)

From #503, Kai's 2026-07-06 decision: **regenerate the ward-kdl embeds from the aos-published source bundle at build time.** ward's own tree carries the **neutral** `examples/ward-specs/` bundle only; the coilyco deployment values come from the aos bundle at build, not from committed embeds. The mechanism (assets-dir convention, `make build-ward-kdl` reading `.ward/ward-kdl/`, the neutral example, `TestExampleBundleHasNoCoilycoValues`) already landed under #453.

## Safe staging order - this is load-bearing, do not shortcut it

The #453 landing checklist mandates **no-op-then-flip**: every overlay step lands green while ward's tree is still coilyco (overlaying coilyco onto coilyco changes nothing), and only the **final** step flips the tree neutral, by which point both build sites already overlay

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

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-644` on host `KAI-DESKTOP-TOWER` is carrying this issue (reserved 2026-07-07T21:57:54Z). 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#644` · branch `issue-644` · driver `claude` · workflow `direct-main` - **Run:** `engineer-claude-ward-644` · ward `v0.422.0` · dispatched `2026-07-07T21:57:54Z` - **Comment thread:** 0 included in the pre-flight read, 0 stripped (ward's own automated comments). **Issue body as seeded:** ``` ## What this is Residual of **#503** (which was closed on the aos-publish half, not the final flip). The aos side of the ward-kdl spec-bundle cutover is live - `coilyco-flight-deck/agentic-os` publishes `ward-specs-<tag>.tar.gz` + `.sha256` as a pinned, checksummed release asset (aos#315, verified on v0.197.0). But ward itself is **still compiled primarily via ward**, not via the aos bundle. Two things confirm the flip has not landed in this tree (verified 2026-07-07): - **`.forgejo/workflows/release.yml`** builds `go build ./cmd/ward` straight from the checked-out tree, with **no fetch or overlay** of the aos `ward-specs` bundle before the build. (`grep -niE 'ward-specs|overlay|bundle'` matches only SHA256SUMS comment lines.) - **`.ward/ward-kdl/`** still carries the coilyco values in ~18 files (`ward-kdl.forgejo.guardfile.kdl`, `ward-kdl.fleet.kdl`, the signoz/skillsmp specs). `docs/ward-kdl-authoring.md:61` still says so literally: "Ward's own tracked bundle still carries the coilyco values today (#441)." So a released ward binary embeds coilyco from its own tree, which is exactly the state #441/#453/#503 set out to end. ## The decided approach (do not re-litigate) From #503, Kai's 2026-07-06 decision: **regenerate the ward-kdl embeds from the aos-published source bundle at build time.** ward's own tree carries the **neutral** `examples/ward-specs/` bundle only; the coilyco deployment values come from the aos bundle at build, not from committed embeds. The mechanism (assets-dir convention, `make build-ward-kdl` reading `.ward/ward-kdl/`, the neutral example, `TestExampleBundleHasNoCoilycoValues`) already landed under #453. ## Safe staging order - this is load-bearing, do not shortcut it The #453 landing checklist mandates **no-op-then-flip**: every overlay step lands green while ward's tree is still coilyco (overlaying coilyco onto coilyco changes nothing), and only the **final** step flips the tree neutral, by which point both build sites already overlay ``` … (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.422.0). </details>  — Claude (she/her), via `ward agent`

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 closed this issue

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

coilyco-ops commented

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

Author

Member

WARD-OUTCOME: done - release.yml overlays the pinned aos ward-specs bundle before go build (fail-safe no-op today); release v0.427.0 green.

Landed step 3. publish-binaries now fetches, sha256-verifies, and overlays the pinned aos ward-specs bundle (AOS_SPECS_TAG=v0.201.0) onto .ward/ward-kdl/, re-derives the shipped embeds by the same file-copy sync-*-assets uses, then cross-compiles. Blank pin fails closed. Release run 971 (v0.427.0) went green, publish-binaries included.

The one thing that fought back: the "no-op, coilyco onto coilyco" premise did not actually hold. I pulled the live, sha256-verified aos v0.201.0 asset and diffed it against ward's tree. The ops-forgejo base/owner coupling matches, but the aos bundle currently LAGS ward: it is missing the ward#620 per-role model/effort overrides in ward-kdl.fleet.kdl and a newer forgejo.swagger.lock.json (an extra issueDeleteComment endpoint). A naive overlay would have silently regressed the shipped fleet manifest and forgejo API surface, which is the opposite of "same coilyco surface as today."

So I did not ship that. The overlay asserts the base/owner coupling fail-closed (a neutral or foreign bundle can never ship), then fails SAFE: if the regenerated embeds diverge from ward's committed ones it restores them and warns loudly, so the released binary stays byte-identical to today's surface until aos catches up. Today that fail-safe path engages - I verified the exact revert locally against the real asset before pushing. It becomes a genuine live no-op the moment aos homes ward's current values.

Confidence: high on the wiring and the safety logic (exercised overlay + regenerate + revert against the live asset locally, and the release ran green). Honest caveat: the overlay is inert today by design (it reverts), so it is not yet feeding aos values into the binary.

Rough edges / follow-ups worth filing:

The real blocker for a live no-op is an aos-side sync: home ward#620's fleet overrides + the current forgejo lock in aos's ward-specs bundle. That is out of this repo's scope (aos is not a granted repo here). Worth an aos issue against #503 / #539.
Step 2 (homebrew-tap Formula/ward.rb overlay, Kai's GitHub gate) and step 4 (neutralizing ward's tracked tree) remain. Step 4 must REMOVE the fail-safe revert - once the tree is neutral the overlay is supposed to change the embeds.
The tier jobs (publish-kdl-write / publish-kdl-read) build from the tier subdirs and do not overlay the aos bundle - a possible follow-up if the internal tiers should also source from aos.
Incidental: main was red on the repo-wide dead-cross-links gate from four leftover links to already-deleted eco/mirror docs. I scrubbed them so the commit could land.
claude-linux-df7258f11807-ad18-she-her (she/her)

WARD-OUTCOME: done - release.yml overlays the pinned aos ward-specs bundle before go build (fail-safe no-op today); release v0.427.0 green. Landed step 3. publish-binaries now fetches, sha256-verifies, and overlays the pinned aos ward-specs bundle (AOS_SPECS_TAG=v0.201.0) onto .ward/ward-kdl/, re-derives the shipped embeds by the same file-copy sync-*-assets uses, then cross-compiles. Blank pin fails closed. Release run 971 (v0.427.0) went green, publish-binaries included. The one thing that fought back: the "no-op, coilyco onto coilyco" premise did not actually hold. I pulled the live, sha256-verified aos v0.201.0 asset and diffed it against ward's tree. The ops-forgejo base/owner coupling matches, but the aos bundle currently LAGS ward: it is missing the ward#620 per-role model/effort overrides in ward-kdl.fleet.kdl and a newer forgejo.swagger.lock.json (an extra issueDeleteComment endpoint). A naive overlay would have silently regressed the shipped fleet manifest and forgejo API surface, which is the opposite of "same coilyco surface as today." So I did not ship that. The overlay asserts the base/owner coupling fail-closed (a neutral or foreign bundle can never ship), then fails SAFE: if the regenerated embeds diverge from ward's committed ones it restores them and warns loudly, so the released binary stays byte-identical to today's surface until aos catches up. Today that fail-safe path engages - I verified the exact revert locally against the real asset before pushing. It becomes a genuine live no-op the moment aos homes ward's current values. Confidence: high on the wiring and the safety logic (exercised overlay + regenerate + revert against the live asset locally, and the release ran green). Honest caveat: the overlay is inert today by design (it reverts), so it is not yet feeding aos values into the binary. Rough edges / follow-ups worth filing: - The real blocker for a live no-op is an aos-side sync: home ward#620's fleet overrides + the current forgejo lock in aos's ward-specs bundle. That is out of this repo's scope (aos is not a granted repo here). Worth an aos issue against #503 / #539. - Step 2 (homebrew-tap Formula/ward.rb overlay, Kai's GitHub gate) and step 4 (neutralizing ward's tracked tree) remain. Step 4 must REMOVE the fail-safe revert - once the tree is neutral the overlay is supposed to change the embeds. - The tier jobs (publish-kdl-write / publish-kdl-read) build from the tier subdirs and do not overlay the aos bundle - a possible follow-up if the internal tiers should also source from aos. - Incidental: main was red on the repo-wide dead-cross-links gate from four leftover links to already-deleted eco/mirror docs. I scrubbed them so the commit could land. - claude-linux-df7258f11807-ad18-she-her (she/her)

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-07 23:44:23 +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:32:51 +00:00

Config-driven ward: the fs.FS-at-launch config-resolve seam (#650-1, foundational) #653

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