coilyco-flight-deck/ward

Fork 0

Give ward-kdl-write an internal channel so the broker survives the ward#455 release-asset removal #501

New issue

Closed

opened 2026-07-02 02:58:45 +00:00 by coilysiren · 3 comments

coilysiren commented

2026-07-02 02:58:45 +00:00

Owner

Context

ward#455 removed ward-kdl and the ward-kdl-{read,write,admin} tier CLIs from the public-facing published artifacts: the brew formula no longer builds ward-kdl, and the publish-kdl-tiers release job was deleted so the release page now carries only the two ward binaries (+ checksums).

The gap this leaves

The in-container root credential broker (ward#329) downloads ward-kdl-write-linux-<arch> from the ward release download page (cmd/ward/containerassets/entrypoint.sh, install_ward_kdl_write). With the tier assets gone from the release, that download now 404s on every release-built container.

The broker install is best-effort and dual-mode by design (see docs/broker.md): a miss logs broker skipped (older release without the tier asset?) and the container falls back to the still-present FORGEJO_TOKEN path. So this is a graceful degradation of a hardening layer, not a crash - but the broker is effectively off for release-built containers until the write tier rides an internal channel again.

Deliverable

Give ward-kdl-write an internal channel (not the public release page) so the broker keeps working, per ward#455's "they can ride an internal channel if the container/broker path needs them". Candidate: publish the write tier to the Forgejo generic package registry from CI, and repoint install_ward_kdl_write at that URL. This is the tier-CLI infra coupling tracked in ward#441.

Done condition

A release-built read-only container brings the broker up (downloads ward-kdl-write from the internal channel, starts the daemon) without the write tier appearing on the public release page.

Related: ward#455 (this removal), ward#441 (tier-CLI infra coupling), ward#329 (the broker).

Filed by Claude Code as the ward#455 follow-up.

## Context ward#455 removed `ward-kdl` and the `ward-kdl-{read,write,admin}` tier CLIs from the public-facing published artifacts: the brew formula no longer builds `ward-kdl`, and the `publish-kdl-tiers` release job was deleted so the release page now carries only the two `ward` binaries (+ checksums). ## The gap this leaves The in-container root credential broker (ward#329) downloads `ward-kdl-write-linux-<arch>` from the ward **release download page** (`cmd/ward/containerassets/entrypoint.sh`, `install_ward_kdl_write`). With the tier assets gone from the release, that download now 404s on every release-built container. The broker install is best-effort and dual-mode by design (see docs/broker.md): a miss logs `broker skipped (older release without the tier asset?)` and the container falls back to the still-present `FORGEJO_TOKEN` path. So this is a **graceful degradation of a hardening layer**, not a crash - but the broker is effectively off for release-built containers until the write tier rides an internal channel again. ## Deliverable Give `ward-kdl-write` an **internal channel** (not the public release page) so the broker keeps working, per ward#455's "they can ride an internal channel if the container/broker path needs them". Candidate: publish the write tier to the Forgejo generic package registry from CI, and repoint `install_ward_kdl_write` at that URL. This is the tier-CLI infra coupling tracked in ward#441. ## Done condition A release-built read-only container brings the broker up (downloads `ward-kdl-write` from the internal channel, starts the daemon) without the write tier appearing on the public release page. Related: ward#455 (this removal), ward#441 (tier-CLI infra coupling), ward#329 (the broker). --- Filed by Claude Code as the ward#455 follow-up.

coilysiren referenced this issue

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

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

coilyco-ops added the

consult

labels

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

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-03 06:24:04 +00:00

Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-501 on host KAI-DESKTOP-TOWER is carrying this issue (reserved 2026-07-03T06:23:54Z). 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-501` on host `KAI-DESKTOP-TOWER` is carrying this issue (reserved 2026-07-03T06:23:54Z). 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-03 06:39:28 +00:00

ci(release): give ward-kdl-write an internal channel so the broker survives ward#455

coilysiren closed this issue

2026-07-03 06:39:28 +00:00

coilysiren commented

2026-07-03 06:40:31 +00:00

Author

Owner

WARD-OUTCOME: done - publish-kdl-write ships the write tier to the Forgejo generic package registry and the broker downloads it from there instead of the release page.

This one felt like careful reconstruction more than invention. ward#455 left a clean seam - the note in entrypoint.sh, this filed follow-up - so the shape was obvious: rebuild the write tier per release, PUT it to the generic package registry keyed to the tag, repoint install_ward_kdl_write. I used the deleted publish-kdl-tiers job as the template and trimmed it to write-only, since the broker only ever shells that tier.

What actually fought back was the pre-commit gate, not the feature. The code-comments catalog rule had tightened and main was already red on several unrelated Windows-guard files, so landing without --no-verify meant normalizing those too. Then main raced 5 commits ahead and independently fixed the same comment blocks, which became five comment-only merge conflicts I resolved by taking main's wording. The 4000-char / 80-line doc caps on broker.md and release.md, both already near the limit, made adding two paragraphs a genuine squeeze.

Confidence is high on the container side: the download URL and the graceful fallback are simple and covered by build/test. The one thing I could not verify from here is that CI_RELEASE_TOKEN carries package-write scope - if it does not, publish-kdl-write fails loudly on the next release and the broker just stays on its FORGEJO_TOKEN fallback, no worse than today. Worth a maintainer glance at that token scope and a look at the first release run to confirm the package lands. Everything else - build, vet, tests, full pre-commit suite - is green.

WARD-OUTCOME: done - publish-kdl-write ships the write tier to the Forgejo generic package registry and the broker downloads it from there instead of the release page. This one felt like careful reconstruction more than invention. ward#455 left a clean seam - the note in entrypoint.sh, this filed follow-up - so the shape was obvious: rebuild the write tier per release, PUT it to the generic package registry keyed to the tag, repoint install_ward_kdl_write. I used the deleted publish-kdl-tiers job as the template and trimmed it to write-only, since the broker only ever shells that tier. What actually fought back was the pre-commit gate, not the feature. The code-comments catalog rule had tightened and main was already red on several unrelated Windows-guard files, so landing without --no-verify meant normalizing those too. Then main raced 5 commits ahead and independently fixed the same comment blocks, which became five comment-only merge conflicts I resolved by taking main's wording. The 4000-char / 80-line doc caps on broker.md and release.md, both already near the limit, made adding two paragraphs a genuine squeeze. Confidence is high on the container side: the download URL and the graceful fallback are simple and covered by build/test. The one thing I could not verify from here is that CI_RELEASE_TOKEN carries package-write scope - if it does not, publish-kdl-write fails loudly on the next release and the broker just stays on its FORGEJO_TOKEN fallback, no worse than today. Worth a maintainer glance at that token scope and a look at the first release run to confirm the package lands. Everything else - build, vet, tests, full pre-commit suite - is green.

coilysiren referenced this issue

2026-07-03 06:48:36 +00:00

publish-kdl-write CI job 401s: CI_RELEASE_TOKEN lacks write:package scope, so #501's internal channel is empty #550

coilysiren commented

2026-07-03 06:48:46 +00:00

Author

Owner

Heads-up: the code landed here (commit 31281f1a) is correct, but the new publish-kdl-write CI job 401s because CI_RELEASE_TOKEN lacks write:package scope — so the generic package registry for ward-kdl-write is currently empty and the internal channel this issue built has nothing in it (ward#455 goal not yet met). Tracked as #550, which needs a credential action (rescope the token or add a dedicated package-write secret).

Heads-up: the code landed here (commit `31281f1a`) is correct, but the new `publish-kdl-write` CI job **401s** because `CI_RELEASE_TOKEN` lacks `write:package` scope — so the generic package registry for `ward-kdl-write` is currently **empty** and the internal channel this issue built has nothing in it (ward#455 goal not yet met). Tracked as #550, which needs a credential action (rescope the token or add a dedicated package-write secret).

coilyco-ops referenced this issue

2026-07-13 19:04:09 +00:00

Fix dispatch prelaunch reservation architecture #1188