polish batch, run 12: install-path

coilyco-ops commented

2026-07-01 21:54:52 +00:00

Member

Why

Non-gating friction from run 12 (forgejo-selfhoster / install-path), batched per sweep rules:

The brew formula's warded comment tells a different story than the docs: formula says the multicall rewrites argv to ward drive <args>, citing "ward#277 / docs/drive.md" — but docs/drive.md is a 404 (nothing drive-named exists in the tree) and README + docs/agent.md both say the rewrite target is ward agent (ward#247, ward#282). Self-hosters read formulas before piping them to brew; a dead doc link plus a contradicting mechanism in the install artifact costs trust at the worst moment.
Release v0.242.0 ships Linux-only binaries (ward-linux-{amd64,arm64}, six ward-kdl-* tier binaries) with no explanation anywhere of what they're for, whether direct binary install is supported, or why there are no darwin assets when the sanctioned install path is Homebrew. One sentence in the release notes template or README ("release binaries exist for the container path; humans install via brew") closes the gap.

Deliverable / Done condition

Each checkbox independently fixable; done when both are checked.

Severity: polish · persona: forgejo-selfhoster · angle: install-path
Filed by Claude Code during a cold-read release pressure test (run 12).

## Why Non-gating friction from run 12 (`forgejo-selfhoster` / `install-path`), batched per sweep rules: - [ ] The brew formula's `warded` comment tells a different story than the docs: formula says the multicall rewrites argv to **`ward drive <args>`**, citing "ward#277 / docs/drive.md" — but `docs/drive.md` is a 404 (nothing drive-named exists in the tree) and README + docs/agent.md both say the rewrite target is **`ward agent`** (ward#247, ward#282). Self-hosters read formulas before piping them to brew; a dead doc link plus a contradicting mechanism in the install artifact costs trust at the worst moment. - [ ] Release v0.242.0 ships **Linux-only** binaries (`ward-linux-{amd64,arm64}`, six `ward-kdl-*` tier binaries) with no explanation anywhere of what they're for, whether direct binary install is supported, or why there are no darwin assets when the sanctioned install path is Homebrew. One sentence in the release notes template or README ("release binaries exist for the container path; humans install via brew") closes the gap. ## Deliverable / Done condition Each checkbox independently fixable; done when both are checked. --- **Severity: polish** · persona: forgejo-selfhoster · angle: install-path Filed by Claude Code during a cold-read release pressure test (run 12).

coilyco-ops added the

pressure-test

label

2026-07-01 21:54:52 +00:00

coilyco-ops referenced this issue

2026-07-01 21:55:39 +00:00

meta: release pressure-test run log (cold-read usability sweeps) #428

coilyco-ops commented

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

Author

Member

+1 — independently hit via the-agent-itself/install-path, run 8. Also confirmed the pinned source tarball (v0.242.0) itself resolves fine and go build mechanics check out - the two checkboxes here are the only real gaps in an otherwise-working install path.

+1 — independently hit via the-agent-itself/install-path, run 8. Also confirmed the pinned source tarball (v0.242.0) itself resolves fine and `go build` mechanics check out - the two checkboxes here are the only real gaps in an otherwise-working install path.

coilyco-ops referenced this issue

2026-07-01 22:07:03 +00:00

meta: release pressure-test run log (cold-read usability sweeps) #428

coilyco-ops referenced this issue

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

Publish the full release binary matrix to GitHub releases, checksummed and CI-built from the same tags #454

coilyco-ops referenced this issue

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

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

coilyco-ops referenced this issue

2026-07-01 22:56:02 +00:00

Publish the full release binary matrix to GitHub releases, checksummed and CI-built from the same tags #454

coilyco-ops added this to the ward launch milestone

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

coilyco-ops added the

headless

P1

labels

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

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 commented

2026-07-02 03:15:49 +00:00

Author

Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-442 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T03:15:47Z). 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-442` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T03:15:47Z). 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 04:30:57 +00:00

Author

Member

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

— Codex, via ward agent

🔒 Reserved by `ward agent --driver codex` — container `engineer-codex-ward-442` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T04:30:55Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Codex, via `ward agent`

coilysiren referenced this issue from a commit

2026-07-02 04:33:05 +00:00

docs: clarify release install path and assets

coilysiren closed this issue

2026-07-02 04:33:05 +00:00

coilysiren commented

2026-07-02 04:33:21 +00:00

Owner

WARD-OUTCOME: done - clarified the warded/ward agent install story and noted the Linux-only release assets are for the container path.

This was straightforward overall, but the repo’s doc-size gate pushed back on the first pass, so I kept the change small and left the extra explanation in README only. Confidence is high; the remaining rough edge is that the tap formula itself lives in the tap repo, so this branch only fixes the source-of-truth docs and the release-side enforcement comment.

WARD-OUTCOME: done - clarified the warded/ward agent install story and noted the Linux-only release assets are for the container path. This was straightforward overall, but the repo’s doc-size gate pushed back on the first pass, so I kept the change small and left the extra explanation in README only. Confidence is high; the remaining rough edge is that the tap formula itself lives in the tap repo, so this branch only fixes the source-of-truth docs and the release-side enforcement comment.

coilyco-ops commented

2026-07-02 07:53:32 +00:00

Author

Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-442 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T07:53:30Z). 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-442` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T07:53:30Z). 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:53:36 +00:00

Author

Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-442 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T07:53:30Z). 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-442` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T07:53:30Z). 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:53:39 +00:00

Author

Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-442 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T07:53:30Z). 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-442` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T07:53:30Z). 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 07:57:40 +00:00

docs(release): explain the Linux-only release binaries in the notes template

coilysiren commented

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

Owner

WARD-OUTCOME: done - release-notes template now carries a standing Install note explaining the Linux-only assets, next to where they attach.

Honest retrospective: I came in expecting two open checkboxes and found both already effectively closed. The formula ward drive / dead docs/drive.md comment (box 1) is fixed at the source by the formula-normalising sed in release.yml (ce64d9e, ward#247/#282), and box 2 already had a sentence in README (line 41) from an earlier run. So the "gap" the issue described was largely already sealed.

Rather than no-op, I put the release-binaries explanation where a self-hoster actually hits the confusion: the release page itself. release-notes.sh now emits a standing ## Install note on every body (any verdict, empty range included), stating the ward-linux-{amd64,arm64} assets exist for the container agent path and that humans install via brew. Covered by TestInstallNoteAlwaysRenders and documented in docs/release-notes.md.

What fought back: only the code-comment discipline hook, which caps contiguous comment blocks at two lines - my first commit's 4-line comments tripped it, quick trim and it passed. Confidence high; the change is a pure text transform with fixture tests. The one durable rough edge is unchanged and out of this repo's reach: the tap formula lives in coilyco-flight-deck/homebrew-tap, so the source-of-truth fix here only lands in the published formula on the next release bump, when release.yml's sed rewrites it. Nothing worth filing.

WARD-OUTCOME: done - release-notes template now carries a standing Install note explaining the Linux-only assets, next to where they attach. Honest retrospective: I came in expecting two open checkboxes and found both already effectively closed. The formula `ward drive` / dead `docs/drive.md` comment (box 1) is fixed at the source by the formula-normalising `sed` in release.yml (ce64d9e, ward#247/#282), and box 2 already had a sentence in README (line 41) from an earlier run. So the "gap" the issue described was largely already sealed. Rather than no-op, I put the release-binaries explanation where a self-hoster actually hits the confusion: the release page itself. release-notes.sh now emits a standing `## Install` note on every body (any verdict, empty range included), stating the `ward-linux-{amd64,arm64}` assets exist for the container agent path and that humans install via brew. Covered by TestInstallNoteAlwaysRenders and documented in docs/release-notes.md. What fought back: only the code-comment discipline hook, which caps contiguous comment blocks at two lines - my first commit's 4-line comments tripped it, quick trim and it passed. Confidence high; the change is a pure text transform with fixture tests. The one durable rough edge is unchanged and out of this repo's reach: the tap formula lives in coilyco-flight-deck/homebrew-tap, so the source-of-truth fix here only lands in the published formula on the next release bump, when release.yml's sed rewrites it. Nothing worth filing.

coilysiren referenced this issue from a commit

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

feat(release): publish the full binary matrix to GitHub releases, checksummed

Rows
Columns

polish batch, run 12: install-path #442

Why

Deliverable / Done condition