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

coilyco-ops commented

2026-07-01 21:47:33 +00:00

Member

Why

Persona: the-agent-itself (cold read, verifying README claims read-only). The repo's identity and support path fork between forges:

Forgejo (canonical) description: "Harness driver: sends an AI agent harness (claude/goose/codex/qwen) into ephemeral containers to carry Forgejo issues end to end…". GitHub mirror description: "Generic-purpose cli-guard consumer for repos with external contributors." Two different value propositions; a GitHub arrival reads a divergent one-liner. (Repo descriptions don't ride mirror-to-github.yml, so they drift silently.)
The README Support section sends "create a new issue" to github.com/coilyco-flight-deck/ward/issues/new/choose. Issues are enabled there (0 open) while the canonical tracker with ~118 open issues is on Forgejo — and AGENTS.md calls GitHub "the read-only GitHub mirror". Nothing tells a visitor which tracker warded engineers actually watch, or why the Forgejo README exports its bug reports to GitHub.

A newcomer can technically file feedback, but the two surfaces disagree about what ward is and where its front door is — exactly the framing-gap class this sweep hunts.

Deliverable

State the public support channel in the README in one sentence ("canonical development happens on Forgejo; public issues go to X because Y"), and sync the GitHub mirror description to the canonical one — ideally automated alongside mirror-to-github.yml so it cannot drift again.

Done condition

Both forges show the same one-line description; the README says explicitly which tracker to use and why; a cold reader can name the canonical forge without opening AGENTS.md. (Anchor: #414 carries the broader github-parity story; this is the narrow identity/support slice, independently dispatchable.)

Severity: major-friction · persona: the-agent-itself · angle: yaml-config
Filed by Claude Code during a cold-read release pressure test (run 2).

## Why Persona: `the-agent-itself` (cold read, verifying README claims read-only). The repo's identity and support path fork between forges: - Forgejo (canonical) description: "Harness driver: sends an AI agent harness (claude/goose/codex/qwen) into ephemeral containers to carry Forgejo issues end to end…". GitHub mirror description: "Generic-purpose cli-guard consumer for repos with external contributors." Two different value propositions; a GitHub arrival reads a divergent one-liner. (Repo descriptions don't ride `mirror-to-github.yml`, so they drift silently.) - The README Support section sends "create a new issue" to `github.com/coilyco-flight-deck/ward/issues/new/choose`. Issues are enabled there (0 open) while the canonical tracker with ~118 open issues is on Forgejo — and AGENTS.md calls GitHub "the read-only GitHub mirror". Nothing tells a visitor which tracker warded engineers actually watch, or why the Forgejo README exports its bug reports to GitHub. A newcomer can technically file feedback, but the two surfaces disagree about what ward is and where its front door is — exactly the framing-gap class this sweep hunts. ## Deliverable State the public support channel in the README in one sentence ("canonical development happens on Forgejo; public issues go to X because Y"), and sync the GitHub mirror description to the canonical one — ideally automated alongside `mirror-to-github.yml` so it cannot drift again. ## Done condition Both forges show the same one-line description; the README says explicitly which tracker to use and why; a cold reader can name the canonical forge without opening AGENTS.md. (Anchor: #414 carries the broader github-parity story; this is the narrow identity/support slice, independently dispatchable.) --- **Severity: major-friction** · persona: the-agent-itself · angle: yaml-config Filed by Claude Code during a cold-read release pressure test (run 2).

coilyco-ops added the

pressure-test

label

2026-07-01 21:47:33 +00:00

coilyco-ops referenced this issue

2026-07-01 21:48:05 +00:00

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

coilyco-ops commented

2026-07-01 21:51:35 +00:00

Author

Member

+1 — independently hit via the-agent-itself/docs-ia, run 8.

coilyco-ops referenced this issue

2026-07-01 21:51:59 +00:00

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

coilyco-ops referenced this issue

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

README's only bug-report link points to a GitHub repo that doesn't exist #433

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:47:25 +00:00

GitHub mirror's releases/tags are frozen at v0.5.8 (36 tags) while canonical is v0.242.0, contradicting the documented mirror-main+tags contract #477

coilyco-ops commented

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

Author

Member

+1 — independently hit via github-only-dev/release-story, run 32: descriptions still diverge as of 2026-07-01 (Forgejo 'Harness driver…' vs GitHub 'Generic-purpose cli-guard consumer for repos with external contributors').

coilyco-ops referenced this issue

2026-07-01 22:48:11 +00:00

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

coilyco-ops referenced this issue

2026-07-01 22:51:32 +00:00

CONTRIBUTING's required path (Forgejo issue + PR) is impossible for outsiders: registration is disabled and the GitHub mirror is read-only #481

coilyco-ops added this to the ward launch milestone

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

coilyco-ops added the

consult

P1

labels

2026-07-01 23:30:43 +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 referenced this issue

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

GitHub mirror repo hygiene: issue templates, topics/description parity, front-door signals #490

coilyco-ops added

headless

and removed

consult

labels

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

coilyco-ops commented

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

Author

Member

DECISION - GitHub is the public front door: GitHub mirror hosts issues (and external PRs, carried to Forgejo by a maintainer/agent per #481); README support routes to GitHub; descriptions/topics synced (#490); the mirror relationship explained in contributor-facing docs, not the README. External copy is GitHub-only per #461's decision. 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:20 +00:00

README's only bug-report link points to a GitHub repo that doesn't exist #433

coilyco-ops referenced this issue

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

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

coilysiren referenced this issue

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

CONTRIBUTING's required path (Forgejo issue + PR) is impossible for outsiders: registration is disabled and the GitHub mirror is read-only #481

coilysiren referenced this issue from a commit

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

feat(mirror): staff the GitHub front door with templates and metadata sync

coilyco-ops commented

2026-07-02 03:09:23 +00:00

Author

Member

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

2026-07-02 03:09:43 +00:00

GitHub mirror repo hygiene: issue templates, topics/description parity, front-door signals #490

coilysiren referenced this issue from a commit

2026-07-02 03:11:32 +00:00

docs(readme): state the canonical tracker and why public issues go to the mirror

coilysiren closed this issue

2026-07-02 03:11:32 +00:00

coilysiren commented

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

Owner

WARD-OUTCOME: done - README Support section now names Forgejo as canonical and explains why public issues route to the GitHub mirror; description sync was already automated on main.

Retrospective: this one was mostly archaeology, not authoring. The description-drift half was already solved before I arrived - a prior run (ward#490) had wired the "Sync repo description and topics to GitHub" step into mirror-to-github.yml, pulling canonical values from the Forgejo API on every push, so my merge just re-triggered it. The real remaining slice was tiny: the README Support line routed newcomers to GitHub with zero explanation of which tracker is canonical or why, so a cold reader had to open AGENTS.md to learn Forgejo is home.

What fought back a little was the tension between the decision comment ("explain the mirror relationship in contributor docs rather than the README") and the done condition ("the README says explicitly which tracker to use and why"). I read those as complementary, not contradictory: one concise README sentence naming the canonical forge and the reason, plus a pointer to CONTRIBUTING.md which already carries the full flow. Confident in the result - it's a small, self-contained doc edit, pre-commit is green, and the push lands the description re-sync automatically. No follow-ups worth filing; the broader github-parity story stays at #414.

WARD-OUTCOME: done - README Support section now names Forgejo as canonical and explains why public issues route to the GitHub mirror; description sync was already automated on main. Retrospective: this one was mostly archaeology, not authoring. The description-drift half was already solved before I arrived - a prior run (ward#490) had wired the "Sync repo description and topics to GitHub" step into mirror-to-github.yml, pulling canonical values from the Forgejo API on every push, so my merge just re-triggered it. The real remaining slice was tiny: the README Support line routed newcomers to GitHub with zero explanation of which tracker is canonical or why, so a cold reader had to open AGENTS.md to learn Forgejo is home. What fought back a little was the tension between the decision comment ("explain the mirror relationship in contributor docs rather than the README") and the done condition ("the README says explicitly which tracker to use and why"). I read those as complementary, not contradictory: one concise README sentence naming the canonical forge and the reason, plus a pointer to CONTRIBUTING.md which already carries the full flow. Confident in the result - it's a small, self-contained doc edit, pre-commit is green, and the push lands the description re-sync automatically. No follow-ups worth filing; the broader github-parity story stays at #414.

coilyco-ops referenced this issue

2026-07-07 22:49:10 +00:00

GitHub mirror is fully frozen (main + tags + releases at July 1 / v0.5.8): no live sync path after mirror-to-github removal #646

Rows
Columns

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

Why

Deliverable

Done condition