README's first sentence conflates dev-verb wrapping (forge-agnostic) with agent-carries-a-Forgejo-issue (Forgejo-only), losing GitHub-only adopters of the half that would actually work for them

coilyco-ops commented

2026-07-01 22:15:26 +00:00

Member

Why

Persona: github-only-dev, angle install-path - specifically the calibration question this whole sweep exists for: does ward tell a GitHub-only visitor what it requires, honestly? Run 1 (front-page) already confirmed the Forgejo dependency is disclosed and not hidden - good. This run goes one level deeper: verifying that disclosure against the actual mechanics.

README sentence one: "It drives an agent harness... into an ephemeral container to carry a Forgejo issue end to end, then gates every dev verb it runs behind cli-guards policy." Read plainly, this is one continuous pipeline requiring Forgejo throughout.

But docs/exec-verb.md (the doc for ward exec - the build/test/vet/lint/tidy/cover wrapping) never mentions Forgejo once. Its clean-tree gate is generic git (HEAD is detached / has no upstream / is behind its upstream - forge-agnostic language). docs/FEATURES.mds own "Scope" line is "Contributor-facing cli-guard gate: repo dev verbs + audited host wrappers" - also no Forgejo. I verified ward lint, ward doctor, ward audit, and ward exec <verb> all operate purely on .ward/ward.yaml + the local Makefile + git, with zero Forgejo touchpoints - only ward agent/warded #<issue> (and ward ci watch, ward ops forgejo) actually need it.

So the true shape is: two independent halves, one forge-agnostic (dev-verb gating, usable today by a GitHub-only repo), one Forgejo-only (issue-carrying agents). The README's first sentence presents them as one Forgejo-bound pipeline. A github-only-dev reading only that sentence - exactly this persona's behavior - reasonably concludes the entire tool needs Forgejo and bounces, when half of it (arguably the easier on-ramp: wrap your Makefile targets, get an audit log, gate risky dev verbs) would work for them today with zero Forgejo setup.

Deliverable

Split the claim in the README's opening: state plainly that dev-verb wrapping (ward exec/lint/doctor/audit) works on any git host, and only the agent/carry feature (ward agent/warded) requires Forgejo. This could be as small as one clause change to sentence one, or a short "works without Forgejo" callout near the top.

Done condition

A GitHub-only reader can tell from the first paragraph which ward features are usable on their repo today without Forgejo, and which require it.

Severity: major-friction · persona: github-only-dev · angle: install-path
Filed by Claude Code during a cold-read release pressure test (run 12).

## Why Persona: `github-only-dev`, angle `install-path` - specifically the calibration question this whole sweep exists for: does ward tell a GitHub-only visitor what it requires, honestly? Run 1 (front-page) already confirmed the Forgejo dependency is disclosed and not hidden - good. This run goes one level deeper: verifying that disclosure against the actual mechanics. README sentence one: "It drives an agent harness... into an ephemeral container to carry a **Forgejo issue** end to end, **then** gates every dev verb it runs behind cli-guards policy." Read plainly, this is one continuous pipeline requiring Forgejo throughout. But `docs/exec-verb.md` (the doc for `ward exec` - the build/test/vet/lint/tidy/cover wrapping) never mentions Forgejo once. Its clean-tree gate is generic git (`HEAD is detached / has no upstream / is behind its upstream` - forge-agnostic language). `docs/FEATURES.md`s own "Scope" line is "Contributor-facing cli-guard gate: repo dev verbs + audited host wrappers" - also no Forgejo. I verified `ward lint`, `ward doctor`, `ward audit`, and `ward exec <verb>` all operate purely on `.ward/ward.yaml` + the local Makefile + git, with zero Forgejo touchpoints - only `ward agent`/`warded #<issue>` (and `ward ci watch`, `ward ops forgejo`) actually need it. So the true shape is: **two independent halves**, one forge-agnostic (dev-verb gating, usable today by a GitHub-only repo), one Forgejo-only (issue-carrying agents). The README's first sentence presents them as one Forgejo-bound pipeline. A `github-only-dev` reading only that sentence - exactly this persona's behavior - reasonably concludes the entire tool needs Forgejo and bounces, when half of it (arguably the easier on-ramp: wrap your Makefile targets, get an audit log, gate risky dev verbs) would work for them today with zero Forgejo setup. ## Deliverable Split the claim in the README's opening: state plainly that dev-verb wrapping (`ward exec`/`lint`/`doctor`/`audit`) works on any git host, and only the agent/carry feature (`ward agent`/`warded`) requires Forgejo. This could be as small as one clause change to sentence one, or a short "works without Forgejo" callout near the top. ## Done condition A GitHub-only reader can tell from the first paragraph which ward features are usable on their repo today without Forgejo, and which require it. --- **Severity: major-friction** · persona: github-only-dev · 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 22:15:26 +00:00

coilyco-ops referenced this issue

2026-07-01 22:15:52 +00:00

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

coilyco-ops commented

2026-07-01 22:24:18 +00:00

Author

Member

+1 — independently hit via forgejo-selfhoster/agent-legibility, this run. The README still treats ward as both a forge-agnostic dev-verb wrapper and a Forgejo-issue carrier in the same opening paragraph, which muddies the adoptability signal.

coilyco-ops referenced this issue

2026-07-01 22:24:36 +00:00

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

coilyco-ops added this to the ward launch milestone

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

coilyco-ops added the

consult

P1

labels

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

coilyco-ops referenced this issue

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

warded carries GitHub issues end to end (dispatch, comments, PR) - GitHub as a first-class forge #489

coilyco-ops added

headless

and removed

consult

labels

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

coilyco-ops referenced this issue

2026-07-01 23:58:15 +00:00

README opening buries what ward actually does under four paragraphs of naming lore and unexplained bare issue refs #444

coilyco-ops commented

2026-07-01 23:58:18 +00:00

Author

Member

DECISION (Kai, verbatim intent): change ALL external copy to mention GitHub only - Forgejo can get mentioned in contributor guides / source code. This supersedes the original deliverable's split-sentence framing. Fold into the #444 README epic for the README instance; #443 carries the rule repo-wide; honesty dependency on #489 (warded on GitHub issues) - external copy must not claim GitHub end-to-end until it works. Recorded by Claude Code (Fable) during the 2026-07-01 ward launch triage session with Kai.

coilyco-ops referenced this issue

2026-07-01 23:58:19 +00:00

Canonical Forgejo repo and GitHub mirror disagree on what ward is, and README routes support to the mirror without explanation #438

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:43 +00:00

Update repo desc + tags #203

coilysiren referenced this issue

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

README opening buries what ward actually does under four paragraphs of naming lore and unexplained bare issue refs #444

coilyco-ops commented

2026-07-02 02:48:40 +00:00

Author

Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-461 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T02:48:38Z). 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-461` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T02:48:38Z). 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 02:52:20 +00:00

docs(readme): tell GitHub-only readers the verb gate needs no forge (closes #461)

coilysiren closed this issue

2026-07-02 02:52:20 +00:00

coilysiren commented

2026-07-02 02:52:38 +00:00

Owner

WARD-OUTCOME: done - README paragraph one now tells a GitHub-only reader the dev-verb gate is forge-agnostic (works on any git repo, no forge account), leaving the agent half as the sole forge-tied part.

The interesting part of this one was that the fix wasn't the fix the issue asked for. The frozen deliverable wanted a split-sentence framing, but the live thread had a superseding decision from Kai (external copy leans GitHub, Forgejo moves to contributor guides/source) plus an honesty rider: #489 (warded on GitHub end-to-end) isn't shipped, so external copy can't claim the agent loop works on GitHub yet. That collapsed the design space nicely - the honest move today IS the contrast, just framed GitHub-forward: verb gate = "any git repo, GitHub included, no forge account", agent half = still honestly names Forgejo.

The #444 rework had already moved most of the way there, so this was a one-paragraph edit rather than a rebuild. What fought back was the merge, not the writing: three concurrent pushes to main during the run (container-image docs, a troubleshooting section), all clean auto-merges since none touched the opening.

Fairly confident in the result for this issue's scope. The one honest limitation: this is the README-opening instance only. The repo-wide Forgejo-to-GitHub sweep is #443, and the whole GitHub-forward story stays gated on #489 landing - until then "Releases live on Forgejo", the tap URL, and the "What it requires" Forgejo line are still load-bearing and correct, not cleanup targets.

WARD-OUTCOME: done - README paragraph one now tells a GitHub-only reader the dev-verb gate is forge-agnostic (works on any git repo, no forge account), leaving the agent half as the sole forge-tied part. The interesting part of this one was that the fix wasn't the fix the issue asked for. The frozen deliverable wanted a split-sentence framing, but the live thread had a superseding decision from Kai (external copy leans GitHub, Forgejo moves to contributor guides/source) plus an honesty rider: #489 (warded on GitHub end-to-end) isn't shipped, so external copy can't claim the agent loop works on GitHub yet. That collapsed the design space nicely - the honest move today IS the contrast, just framed GitHub-forward: verb gate = "any git repo, GitHub included, no forge account", agent half = still honestly names Forgejo. The #444 rework had already moved most of the way there, so this was a one-paragraph edit rather than a rebuild. What fought back was the merge, not the writing: three concurrent pushes to main during the run (container-image docs, a troubleshooting section), all clean auto-merges since none touched the opening. Fairly confident in the result for this issue's scope. The one honest limitation: this is the README-opening instance only. The repo-wide Forgejo-to-GitHub sweep is #443, and the whole GitHub-forward story stays gated on #489 landing - until then "Releases live on Forgejo", the tap URL, and the "What it requires" Forgejo line are still load-bearing and correct, not cleanup targets.

coilysiren referenced this issue

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

README's first sentence names qwen as a harness; it is a deprecated alias for opencode with no doc at the expected path #448

coilysiren referenced this issue

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

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

coilysiren referenced this issue

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

README opening buries what ward actually does under four paragraphs of naming lore and unexplained bare issue refs #444

coilyco-ops commented

2026-07-02 08:06:34 +00:00

Author

Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-461 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T08:06:32Z). 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-461` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T08:06:32Z). 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 08:06:38 +00:00

Author

Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-461 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T08:06:32Z). 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-461` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T08:06:32Z). 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 08:06:42 +00:00

Author

Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-461 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T08:06:32Z). 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-461` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T08:06:32Z). 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:09:04 +00:00

Owner

WARD-OUTCOME: done - README paragraph one already splits the forge-agnostic verb gate from the Forgejo-only agent driver (landed in 7fb4520, on main); this re-dispatch found the deliverable already satisfied, no new change needed.

Honestly this one was a non-event to build because it was already built. I came in ready to rework sentence one, read the current README, and the exact split the deliverable asks for was staring back at me: para one leads with the dev-verb gate, calls it forge-agnostic ("any git repo - GitHub included ... no forge account of any kind"), and pins the agent driver as the sole forge-tied half. git log -L on line 3 explained why - commit 7fb4520 already carried #461 to a close on 2026-07-02, and fc4daa1 refined it further. Both are on main; tree clean, HEAD == origin/main.

The only thing that fought back was the instinct to do something anyway. The right call was to not fabricate an edit against a satisfied done-condition - that's noise, not work. Confidence is high: the done-condition (a GitHub-only reader can tell which features need Forgejo from para one) is plainly met. This looks like a duplicate dispatch of an already-reserved-and-closed issue; the only follow-up worth naming is on the dispatch side (guard against re-dispatching closed issues), not the README.

WARD-OUTCOME: done - README paragraph one already splits the forge-agnostic verb gate from the Forgejo-only agent driver (landed in 7fb4520, on main); this re-dispatch found the deliverable already satisfied, no new change needed. Honestly this one was a non-event to *build* because it was already built. I came in ready to rework sentence one, read the current README, and the exact split the deliverable asks for was staring back at me: para one leads with the dev-verb gate, calls it forge-agnostic ("any git repo - GitHub included ... no forge account of any kind"), and pins the agent driver as the sole forge-tied half. `git log -L` on line 3 explained why - commit 7fb4520 already carried #461 to a close on 2026-07-02, and fc4daa1 refined it further. Both are on main; tree clean, HEAD == origin/main. The only thing that fought back was the instinct to *do something* anyway. The right call was to not fabricate an edit against a satisfied done-condition - that's noise, not work. Confidence is high: the done-condition (a GitHub-only reader can tell which features need Forgejo from para one) is plainly met. This looks like a duplicate dispatch of an already-reserved-and-closed issue; the only follow-up worth naming is on the dispatch side (guard against re-dispatching closed issues), not the README.

Rows
Columns

README's first sentence conflates dev-verb wrapping (forge-agnostic) with agent-carries-a-Forgejo-issue (Forgejo-only), losing GitHub-only adopters of the half that would actually work for them #461

Why

Deliverable

Done condition