Remove ward-kdl (authoring binary + tier CLIs) from the public-facing published artifacts

coilyco-ops commented

2026-07-01 22:12:17 +00:00

Owner

Why

Decision direction from Kai (2026-07-01, post-pressure-test-sweep): ward-kdl probably should not be in the public-facing published artifact at all.

Note this is two removals, not one — the name covers two different things that both ship publicly today:

The authoring tool (ward-kdl binary) installed by the brew formula alongside ward.
The generated tier CLIs (ward-kdl-{read,write,admin} × 2 arches) — six of the eight assets on the release page.

End users need neither: the authored surfaces are already embedded in the ward binary, and the tier CLIs are hardwired to coilyco infra anyway (#441's coupling). Dropping both shrinks the install, makes the release page legible at a glance (8 assets → 2), and sharpens the adoption contract the sweep begged for: "for dev-verb adoption, .ward/ward.yaml is all you write" (#437's deliverable).

Deliverable

Remove ward-kdl from the formula and the tier binaries from the public release assets (they can ride an internal channel if the container/broker path needs them).
Keep it obtainable for spec authors: a separate formula or a documented go install ...@tag, referenced from the authoring doc.
Same-commit doc/test alignment — two known breakage points: the formula's test do block asserts ward-kdl --version, and FEATURES.md + README advertise that the formula installs it.

Done condition

brew install coilyco-flight-deck/tap/ward yields ward + warded only and the formula test passes; the release page shows only ward binaries (+ checksums); a spec author can still reach ward-kdl via one documented path; no public doc claims the formula installs ward-kdl.

Related: #437/#440 (adopter contract + authoring docs), #442 (release-asset legibility), #441 (tier-CLI infra coupling).

Filed by Claude Code, capturing Kai's release-direction decisions from the 2026-07-01 pressure-test debrief.

## Why Decision direction from Kai (2026-07-01, post-pressure-test-sweep): ward-kdl probably should not be in the public-facing published artifact at all. Note this is **two removals, not one** — the name covers two different things that both ship publicly today: 1. The **authoring tool** (`ward-kdl` binary) installed by the brew formula alongside ward. 2. The **generated tier CLIs** (`ward-kdl-{read,write,admin}` × 2 arches) — six of the eight assets on the release page. End users need neither: the authored surfaces are already embedded in the ward binary, and the tier CLIs are hardwired to coilyco infra anyway (#441's coupling). Dropping both shrinks the install, makes the release page legible at a glance (8 assets → 2), and sharpens the adoption contract the sweep begged for: "for dev-verb adoption, `.ward/ward.yaml` is all you write" (#437's deliverable). ## Deliverable - Remove `ward-kdl` from the formula and the tier binaries from the public release assets (they can ride an internal channel if the container/broker path needs them). - Keep it obtainable for spec authors: a separate formula or a documented `go install ...@tag`, referenced from the authoring doc. - Same-commit doc/test alignment — two known breakage points: the formula's `test do` block asserts `ward-kdl --version`, and FEATURES.md + README advertise that the formula installs it. ## Done condition `brew install coilyco-flight-deck/tap/ward` yields `ward` + `warded` only and the formula test passes; the release page shows only ward binaries (+ checksums); a spec author can still reach ward-kdl via one documented path; no public doc claims the formula installs ward-kdl. Related: #437/#440 (adopter contract + authoring docs), #442 (release-asset legibility), #441 (tier-CLI infra coupling). --- Filed by Claude Code, capturing Kai's release-direction decisions from the 2026-07-01 pressure-test debrief.

coilyco-ops referenced this issue

2026-07-01 22:12:38 +00:00

As shipped, ward can only target forgejo.coilysiren.me: endpoint, SSM token path, and a coily* owner gate are compiled in, and no doc says so before install #441

coilyco-ops added this to the ward launch milestone

2026-07-01 23:29:45 +00:00

coilyco-ops added the

labels

2026-07-01 23:30:36 +00:00

coilyco-ops referenced this issue

2026-07-01 23:57:04 +00:00

homebrew-tap: build+install the 3 forgejo tier binaries (follow-up to #240) #246

coilyco-ops referenced this issue

2026-07-01 23:57:05 +00:00

release: publish-kdl-tiers (write) + bump-tap-formula cancelled under matrix fan-out (ward#343 follow-up) #345

coilyco-ops referenced this issue

2026-07-01 23:59:29 +00:00

guardfile authoring docs are a two-node pointer circle, and no doc says whether a downstream adopter needs a guardfile at all #437

coilyco-ops referenced this issue

2026-07-02 00:01:42 +00:00

meta: jul 1st evening sprint - launch burndown session 1 #492

coilyco-ops referenced this issue

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

its unclear how to use ward with various read / write / admin style KDL profiles underneath it #431

coilyco-ops commented

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

Author

Owner

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-455 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T02:53:58Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-455` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T02:53:58Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Claude (she/her), via `ward agent`

coilysiren referenced this issue from a commit

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

build(release): drop ward-kdl + tier CLIs from public published artifacts

coilysiren closed this issue

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

coilysiren referenced this issue from a commit

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

ward: stop installing ward-kdl; install only ward + warded

coilysiren commented

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

Owner

WARD-OUTCOME: done - ward-kdl + the read/write/admin tier CLIs are off the public artifacts: the brew formula installs only ward+warded, the publish-kdl-tiers release job is gone, docs realigned, spec-author build path documented.

Retrospective, candid:

The headline change was small and clean - drop the inline ward-kdl build from the formula (+ its --version test) and delete the publish-kdl-tiers matrix job so the release page goes 8 assets to 2. What actually fought back was everything around it.

The one thing that made me stop and think: the in-container credential broker downloads ward-kdl-write straight from the release page (entrypoint.sh install_ward_kdl_write). So this wasnt purely cosmetic - removing the tier assets silently turns the broker off for release-built containers. It degrades gracefully (best-effort, dual-mode falls back to the FORGEJO_TOKEN path), and the issue explicitly said the tiers can ride an internal channel, with #441 already tracking the coupling, so I scoped the internal channel out and filed it as a native follow-up (#501) rather than guess at a CI package-registry upload I couldnt test in here.

The doc-layout caps were the real grind. release.md, broker.md and FEATURES.md all sat within a handful of chars of the 4000-char / 80-line caps, so every correction I added breached them and I trimmed prose repeatedly. Worse, main was extremely busy - I merged it ~4 times, and two of those rounds landed release-notes/adopter-contract prose into the exact files I was editing, re-breaching the caps and, once, a genuine conflict in ward-kdl-authoring.md (main had concurrently rewritten the whole file for the #437/#440/#441 adopter work). Resolved by keeping their rewrite and grafting a concise Getting the ward-kdl binary section.

Confidence: high on the removal, the doc alignment, and the spec-author path (make build-ward-kdl from a checkout). Both repos verified landed (local HEAD == fresh origin/main). Caveat: I could not run brew or the release workflow in-container, so the formula is correct-by-reading not brew-tested, and I could not confirm the release run for my commit (the Actions task list returns a stale/simulated clock). The workflow edit is a dependency-free job removal, so the remaining jobs are unaffected.

Rough edges / follow-ups: #501 (give ward-kdl-write an internal channel so the broker survives this removal). Someone should also eyeball the first real release after this to confirm the page shows only the two ward binaries.

WARD-OUTCOME: done - ward-kdl + the read/write/admin tier CLIs are off the public artifacts: the brew formula installs only ward+warded, the publish-kdl-tiers release job is gone, docs realigned, spec-author build path documented. Retrospective, candid: The headline change was small and clean - drop the inline ward-kdl build from the formula (+ its --version test) and delete the publish-kdl-tiers matrix job so the release page goes 8 assets to 2. What actually fought back was everything around it. The one thing that made me stop and think: the in-container credential broker downloads ward-kdl-write straight from the release page (entrypoint.sh install_ward_kdl_write). So this wasnt purely cosmetic - removing the tier assets silently turns the broker off for release-built containers. It degrades gracefully (best-effort, dual-mode falls back to the FORGEJO_TOKEN path), and the issue explicitly said the tiers can ride an internal channel, with #441 already tracking the coupling, so I scoped the internal channel out and filed it as a native follow-up (#501) rather than guess at a CI package-registry upload I couldnt test in here. The doc-layout caps were the real grind. release.md, broker.md and FEATURES.md all sat within a handful of chars of the 4000-char / 80-line caps, so every correction I added breached them and I trimmed prose repeatedly. Worse, main was extremely busy - I merged it ~4 times, and two of those rounds landed release-notes/adopter-contract prose into the exact files I was editing, re-breaching the caps and, once, a genuine conflict in ward-kdl-authoring.md (main had concurrently rewritten the whole file for the #437/#440/#441 adopter work). Resolved by keeping their rewrite and grafting a concise Getting the ward-kdl binary section. Confidence: high on the removal, the doc alignment, and the spec-author path (make build-ward-kdl from a checkout). Both repos verified landed (local HEAD == fresh origin/main). Caveat: I could not run brew or the release workflow in-container, so the formula is correct-by-reading not brew-tested, and I could not confirm the release run for my commit (the Actions task list returns a stale/simulated clock). The workflow edit is a dependency-free job removal, so the remaining jobs are unaffected. Rough edges / follow-ups: #501 (give ward-kdl-write an internal channel so the broker survives this removal). Someone should also eyeball the first real release after this to confirm the page shows only the two ward binaries.

coilysiren referenced this issue

2026-07-02 07:10:55 +00:00

meta: jul 1st evening sprint - launch burndown session 1 #492

coilyco-ops commented

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

Author

Owner

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-455 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T07:58:58Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-455` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T07:58:58Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Claude (she/her), via `ward agent`

coilyco-ops commented

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

Author

Owner

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-455 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T07:58:58Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-455` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T07:58:58Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Claude (she/her), via `ward agent`

coilyco-ops commented

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

Author

Owner

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-455 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T07:58:58Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-455` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T07:58:58Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Claude (she/her), via `ward agent`

coilysiren commented

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

Owner

WARD-OUTCOME: done - ward-kdl authoring binary and the read/write/admin tier CLIs are off the public artifacts; formula installs ward and warded only, release page carries two ward binaries, docs realigned, spec-author build path documented.

Honest note on how this run felt: I picked up a re-dispatch. The prior container carried this same issue to completion a few hours earlier, so I opened the clone expecting to implement and instead found the work already landed on main and the issue already closed. That reframed the job from build to verify.

I read the whole surface anyway before trusting that. The removal commit is an ancestor of a freshly-fetched origin main, release.yml no longer has any tier publish job so the page drops to the two ward-linux binaries, the tap formula on homebrew-tap builds only ward plus the warded shim and its test block asserts ward version rather than ward-kdl version, and README plus FEATURES plus ward-kdl-authoring all state the formula does not install ward-kdl and point spec authors at make build-ward-kdl from a checkout. Every done-condition holds.

What I could not close from in here: brew itself and the real release run. Same caveat the prior run flagged. The formula is correct-by-reading, not brew-tested, and someone should eyeball the first release after this to confirm the page shows only the two ward binaries. The one live coupling worth remembering is the broker: the entrypoint install_ward_kdl_write step now 404s against the release page and falls back to the token path, tracked as the ward#501 follow-up.

Confidence high that the deliverable is landed and durable. I made no new commits because there was nothing left to change, and fabricating a no-op commit would only muddy the history.

WARD-OUTCOME: done - ward-kdl authoring binary and the read/write/admin tier CLIs are off the public artifacts; formula installs ward and warded only, release page carries two ward binaries, docs realigned, spec-author build path documented. Honest note on how this run felt: I picked up a re-dispatch. The prior container carried this same issue to completion a few hours earlier, so I opened the clone expecting to implement and instead found the work already landed on main and the issue already closed. That reframed the job from build to verify. I read the whole surface anyway before trusting that. The removal commit is an ancestor of a freshly-fetched origin main, release.yml no longer has any tier publish job so the page drops to the two ward-linux binaries, the tap formula on homebrew-tap builds only ward plus the warded shim and its test block asserts ward version rather than ward-kdl version, and README plus FEATURES plus ward-kdl-authoring all state the formula does not install ward-kdl and point spec authors at make build-ward-kdl from a checkout. Every done-condition holds. What I could not close from in here: brew itself and the real release run. Same caveat the prior run flagged. The formula is correct-by-reading, not brew-tested, and someone should eyeball the first release after this to confirm the page shows only the two ward binaries. The one live coupling worth remembering is the broker: the entrypoint install_ward_kdl_write step now 404s against the release page and falls back to the token path, tracked as the ward#501 follow-up. Confidence high that the deliverable is landed and durable. I made no new commits because there was nothing left to change, and fabricating a no-op commit would only muddy the history.

Rows
Columns

Remove ward-kdl (authoring binary + tier CLIs) from the public-facing published artifacts #455

Why

Deliverable

Done condition