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

coilyco-ops commented

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

Member

Why

Persona github-only-dev / angle release-story. This persona evaluates a repo's health from its GitHub releases page. Observed (2026-07-01, all read-only via API):

Canonical Forgejo: v0.242.0, 242 releases, latest published today.
GitHub mirror (github.com/coilyco-flight-deck/ward): latest release v0.5.8, only 36 tags total — but main is current (pushed_at today), so the mirrored README describes v0.24x-era behavior sitting on top of a release page frozen ~200 versions ago.

AGENTS.md § Release documents the contract as: "mirror-to-github.yml mirrors main + tags to the read-only GitHub mirror." Observed state contradicts it: main mirrors, tags stopped at v0.5.x, and a set of real GitHub Release objects (v0.5.4–v0.5.8) is stranded at the top of the mirror's Releases page.

For the GitHub arrival this is worse than an empty release page: it affirmatively misstates currency ("latest release v0.5.8") while the tap formula and docs pin v0.24x. The likely cold read is "releases died months ago" → bounce, or "docs are from the future" → distrust.

Distinct from the planned #454 (publish the binary matrix to GitHub releases): that plan makes tag/release parity load-bearing, but the defect here — the existing, documented tag mirroring not holding, plus stranded stale releases — needs fixing (or the stale releases scrubbing) regardless of and prior to #454. Related: #438 (mirror identity/support split).

Deliverable

Fix or re-run tag mirroring so the mirror's tags match canonical, and delete (or clearly supersede) the stranded v0.5.x GitHub releases; alternatively, if tags are deliberately not mirrored anymore, update AGENTS.md's mirror contract and put one line on the mirror explaining where releases live.

Done condition

The GitHub mirror shows either (a) tags/releases matching canonical Forgejo, or (b) zero stale releases plus an explicit pointer to the canonical release page; AGENTS.md's mirror sentence matches observed behavior.

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

## Why Persona `github-only-dev` / angle `release-story`. This persona evaluates a repo's health from its GitHub releases page. Observed (2026-07-01, all read-only via API): - Canonical Forgejo: **v0.242.0**, 242 releases, latest published today. - GitHub mirror (`github.com/coilyco-flight-deck/ward`): **latest release v0.5.8**, only **36 tags total** — but `main` is current (pushed_at today), so the mirrored README describes v0.24x-era behavior sitting on top of a release page frozen ~200 versions ago. AGENTS.md § Release documents the contract as: "`mirror-to-github.yml` mirrors main + tags to the read-only GitHub mirror." Observed state contradicts it: main mirrors, tags stopped at v0.5.x, and a set of real GitHub Release objects (v0.5.4–v0.5.8) is stranded at the top of the mirror's Releases page. For the GitHub arrival this is worse than an empty release page: it affirmatively misstates currency ("latest release v0.5.8") while the tap formula and docs pin v0.24x. The likely cold read is "releases died months ago" → bounce, or "docs are from the future" → distrust. Distinct from the planned #454 (publish the binary matrix to GitHub releases): that plan makes tag/release parity load-bearing, but the defect here — the *existing, documented* tag mirroring not holding, plus stranded stale releases — needs fixing (or the stale releases scrubbing) regardless of and prior to #454. Related: #438 (mirror identity/support split). ## Deliverable Fix or re-run tag mirroring so the mirror's tags match canonical, and delete (or clearly supersede) the stranded v0.5.x GitHub releases; alternatively, if tags are deliberately not mirrored anymore, update AGENTS.md's mirror contract and put one line on the mirror explaining where releases live. ## Done condition The GitHub mirror shows either (a) tags/releases matching canonical Forgejo, or (b) zero stale releases plus an explicit pointer to the canonical release page; AGENTS.md's mirror sentence matches observed behavior. --- **Severity: major-friction** · persona: github-only-dev · angle: release-story Filed by Claude Code during a cold-read release pressure test (run 32).

coilyco-ops added the

pressure-test

label

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

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 added this to the ward launch milestone

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

coilyco-ops added the

headless

P1

labels

2026-07-01 23:30:20 +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 02:31:31 +00:00

Author

Member

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

fix(mirror): backfill tags + scrub stranded legacy GitHub releases

coilysiren closed this issue

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

coilysiren commented

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

Owner

WARD-OUTCOME: done - mirror now backfills all tags (fetch-tags on checkout) and scrubs the stranded github-actions[bot] releases; AGENTS.md contract corrected to "refs only".

The root cause was cleaner than the symptom looked: the checkout carried no tag objects, so git push --tags had literally nothing to push and the mirror sat at whatever the retired .github/workflows run last left (v0.5.8). One fetch-tags: true fixes the tag half and backfills the whole set on the next push. The stale Release objects are a separate axis - the Forgejo pipeline never creates them - so I added an author-guarded scrub (delete only github-actions[bot] releases), which keeps a future PAT-authored #454 untouched without it having to unwind this first.

What actually fought back was the docs-layout caps, not the logic. AGENTS.md sits ~30 chars under its 4000 cap and release.md was pegged at exactly 80 lines / 3995 chars, so every phrasing had to be shaved to the character, and two concurrent rebases regrew both files mid-flight and reset my headroom twice. jq being absent on the docker runner also pushed me to grep tag names then resolve/delete per tag; I tested that parsing against the real payload (release id resolves before author.id, guard reads the bot login) but it's still shell-string-parsing GitHub JSON, so that's the one part I'd flag as fragile.

Confidence: high on the tag backfill (mechanical, well-understood), medium on the scrub until it runs live against the real API with the PAT - the delete path can only be exercised in CI. Worth a glance at the next mirror run's logs to confirm both the tag count and the scrub landing. Rough edge / follow-up: release.md is at its hard cap, so the next edit there will need a split regardless.

WARD-OUTCOME: done - mirror now backfills all tags (fetch-tags on checkout) and scrubs the stranded github-actions[bot] releases; AGENTS.md contract corrected to "refs only". The root cause was cleaner than the symptom looked: the checkout carried no tag objects, so `git push --tags` had literally nothing to push and the mirror sat at whatever the retired `.github/workflows` run last left (v0.5.8). One `fetch-tags: true` fixes the tag half and backfills the whole set on the next push. The stale Release *objects* are a separate axis - the Forgejo pipeline never creates them - so I added an author-guarded scrub (delete only `github-actions[bot]` releases), which keeps a future PAT-authored #454 untouched without it having to unwind this first. What actually fought back was the docs-layout caps, not the logic. AGENTS.md sits ~30 chars under its 4000 cap and release.md was pegged at exactly 80 lines / 3995 chars, so every phrasing had to be shaved to the character, and two concurrent rebases regrew both files mid-flight and reset my headroom twice. jq being absent on the docker runner also pushed me to grep tag names then resolve/delete per tag; I tested that parsing against the real payload (release id resolves before author.id, guard reads the bot login) but it's still shell-string-parsing GitHub JSON, so that's the one part I'd flag as fragile. Confidence: high on the tag backfill (mechanical, well-understood), medium on the scrub until it runs live against the real API with the PAT - the delete path can only be exercised in CI. Worth a glance at the next mirror run's logs to confirm both the tag count and the scrub landing. Rough edge / follow-up: release.md is at its hard cap, so the next edit there will need a split regardless.

coilyco-ops commented

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

Author

Member

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

Author

Member

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

Author

Member

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

fix(mirror): fail loud when GITHUB_MIRROR_PAT is missing

coilysiren reopened this issue

2026-07-02 08:22:40 +00:00

coilysiren commented

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

Owner

WARD-OUTCOME: blocked - the mirror is still frozen because GITHUB_MIRROR_PAT is down, not because of code; rotate/restore that Forgejo Actions secret and the next push to main re-converges tags + scrub.

Not the run I expected to write. The prior run's tag-backfill + scrub fix (d879e21) was correct - but it never actually ran. The whole mirror-to-github workflow has been silently no-op'ing since ~2026-07-01: each PAT-gated step skipped with exit 0 when GITHUB_MIRROR_PAT went missing/expired, so a green check sat on top of a frozen mirror. The mirror's main HEAD is still stuck at July 1 11:18 while canonical raced to v0.30x, and the Releases page is still v0.5.8 / 36 tags. Same silent-credential trap as ward#237's frozen tap.

So this run didn't re-fix the tags (that code was already merged and is sound). It made the freeze impossible to hide: each PAT guard now emits ::error + exit 1. The proof is live - the mirror run on my push (#742) went red in ~5s instead of green. That red run is exactly the signal that was missing for ~200 versions.

What's left is purely operational and out of an agent's reach: rotate/restore GITHUB_MIRROR_PAT in ward -> Settings -> Actions -> Secrets. The next push to main then backfills every tag and scrubs the stranded v0.5.x releases via the already-merged code. I checked for a way to converge the live GitHub state directly and there isn't one from here (the GitHub MCP surface has no release-delete or tag-push).

Confidence: high that the freeze is a down PAT (red run + mirror main frozen at July 1 while canonical moved on), high that loud-fail stops the next silent recurrence. Reopened because the observable defect persists until the secret is rotated - the earlier "done" was accurate about the code but the code had never executed. One follow-up worth filing: the mirror has no external heartbeat, so a red run still relies on someone watching Actions; a scheduled "is the mirror HEAD == canonical HEAD" check would close that gap independently of the PAT.

WARD-OUTCOME: blocked - the mirror is still frozen because GITHUB_MIRROR_PAT is down, not because of code; rotate/restore that Forgejo Actions secret and the next push to `main` re-converges tags + scrub. Not the run I expected to write. The prior run's tag-backfill + scrub fix (d879e21) was correct - but it never actually ran. The whole `mirror-to-github` workflow has been silently no-op'ing since ~2026-07-01: each PAT-gated step skipped with `exit 0` when `GITHUB_MIRROR_PAT` went missing/expired, so a green check sat on top of a frozen mirror. The mirror's `main` HEAD is still stuck at July 1 11:18 while canonical raced to v0.30x, and the Releases page is still v0.5.8 / 36 tags. Same silent-credential trap as ward#237's frozen tap. So this run didn't re-fix the tags (that code was already merged and is sound). It made the freeze impossible to hide: each PAT guard now emits `::error` + `exit 1`. The proof is live - the mirror run on my push (#742) went red in ~5s instead of green. That red run is exactly the signal that was missing for ~200 versions. What's left is purely operational and out of an agent's reach: rotate/restore `GITHUB_MIRROR_PAT` in ward -> Settings -> Actions -> Secrets. The next push to `main` then backfills every tag and scrubs the stranded v0.5.x releases via the already-merged code. I checked for a way to converge the live GitHub state directly and there isn't one from here (the GitHub MCP surface has no release-delete or tag-push). Confidence: high that the freeze is a down PAT (red run + mirror `main` frozen at July 1 while canonical moved on), high that loud-fail stops the next silent recurrence. Reopened because the observable defect persists until the secret is rotated - the earlier "done" was accurate about the code but the code had never executed. One follow-up worth filing: the mirror has no external heartbeat, so a red run still relies on someone watching Actions; a scheduled "is the mirror HEAD == canonical HEAD" check would close that gap independently of the PAT.

coilyco-ops commented

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

Author

Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-477 on host KAI-DESKTOP-TOWER is carrying this issue (reserved 2026-07-04T08:25:57Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh — that is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-477` on host `KAI-DESKTOP-TOWER` is carrying this issue (reserved 2026-07-04T08:25:57Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh** — that is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).  — Claude (she/her), via `ward agent`

coilysiren commented

2026-07-04 08:32:18 +00:00

Owner

WARD-OUTCOME: blocked - mirror fix is fully coded and merged, but the GITHUB_MIRROR_PAT Actions secret does not exist, so nothing runs; a human must provision it in ward -> Settings -> Actions -> Secrets.

This one was already solved in code before I arrived (d879e21 / e10ff5d / 98ecfb2 are on main): tags backfill on fetch-tags, the release scrub is author-guarded, and release.yml's publish step recreates PAT-authored GitHub releases going forward. So there was nothing left to write, and I resisted inventing a no-op commit just to have something to push.

What actually moved the needle was checking runtime, not code. The mirror is still frozen at v0.5.8 (36 tags, every one github-actions[bot]-authored - so the scrub will clear all of them once it runs). Reason nothing has executed: I listed the repo's Actions secrets and GITHUB_MIRROR_PAT is simply not there - only TAP_WRITE_TOKEN, CI_RELEASE_TOKEN, SCOOP_WRITE_TOKEN are set. That matches the 2026-07-02 reopen exactly; I just confirmed it's absent, not merely expired.

What fought back: I kept hunting for a code angle to land and there isn't one. This container has no GitHub credentials, and provisioning a Forgejo Actions secret is outside its git loop (and I don't hold the PAT value anyway), so I can't converge the runtime state myself.

Confidence is high that the code is correct and converges the instant a valid GITHUB_MIRROR_PAT is added. Single human action: create GITHUB_MIRROR_PAT (a GitHub PAT with push to the mirror + repo/release write for the metadata sync and release publish), then push any commit to main. Follow-up worth filing: the workflow only needs a PAT because Forgejo's built-in push-mirror evidently syncs main but not tags - if that built-in mirror carried tags too, the ref half of this would survive a dead PAT.

WARD-OUTCOME: blocked - mirror fix is fully coded and merged, but the `GITHUB_MIRROR_PAT` Actions secret does not exist, so nothing runs; a human must provision it in ward -> Settings -> Actions -> Secrets. This one was already solved in code before I arrived (d879e21 / e10ff5d / 98ecfb2 are on `main`): tags backfill on `fetch-tags`, the release scrub is author-guarded, and `release.yml`'s publish step recreates PAT-authored GitHub releases going forward. So there was nothing left to write, and I resisted inventing a no-op commit just to have something to push. What actually moved the needle was checking runtime, not code. The mirror is still frozen at v0.5.8 (36 tags, every one `github-actions[bot]`-authored - so the scrub *will* clear all of them once it runs). Reason nothing has executed: I listed the repo's Actions secrets and `GITHUB_MIRROR_PAT` is simply not there - only `TAP_WRITE_TOKEN`, `CI_RELEASE_TOKEN`, `SCOOP_WRITE_TOKEN` are set. That matches the 2026-07-02 reopen exactly; I just confirmed it's *absent*, not merely expired. What fought back: I kept hunting for a code angle to land and there isn't one. This container has no GitHub credentials, and provisioning a Forgejo Actions secret is outside its git loop (and I don't hold the PAT value anyway), so I can't converge the runtime state myself. Confidence is high that the code is correct and converges the instant a valid `GITHUB_MIRROR_PAT` is added. Single human action: create `GITHUB_MIRROR_PAT` (a GitHub PAT with push to the mirror + repo/release write for the metadata sync and release publish), then push any commit to `main`. Follow-up worth filing: the workflow only needs a PAT because Forgejo's built-in push-mirror evidently syncs `main` but not tags - if that built-in mirror carried tags too, the ref half of this would survive a dead PAT.

coilysiren referenced this issue

2026-07-06 19:34:49 +00:00

chore(triage): apply the 2026-07-06 backlog re-triage relabel-downs (label-only, no code) #621

coilysiren commented

2026-07-06 19:40:26 +00:00

Owner

Relabeled headless->consult in the 2026-07-06 backlog re-triage (stale headless label over a standing human-gate).

coilysiren commented

2026-07-06 19:42:13 +00:00

Owner

Correction. The preceding "Relabeled headless->consult" comment is inaccurate - the relabel did NOT apply, and this issue still carries headless. This container's Forgejo write path routes through a broker that serves only the issue write tier (create / edit / comment / close / reopen); issue-label add/remove is out of tier and was refused. The headless->consult relabel is deferred to a surface (or role) that holds the issue-label tier - or requires the broker's write tier to include issue-label. Tracked back on ward#621.

**Correction.** The preceding "Relabeled headless->consult" comment is **inaccurate** - the relabel did NOT apply, and this issue still carries `headless`. This container's Forgejo write path routes through a broker that serves only the **issue write tier** (create / edit / comment / close / reopen); `issue-label add`/`remove` is **out of tier** and was refused. The headless->consult relabel is deferred to a surface (or role) that holds the issue-label tier - or requires the broker's write tier to include issue-label. Tracked back on ward#621.

coilyco-ops referenced this issue

2026-07-06 19:43:21 +00:00

chore(triage): apply the 2026-07-06 backlog re-triage relabel-downs (label-only, no code) #621

coilyco-ops commented

2026-07-07 22:38:04 +00:00

Author

Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-477 on host KAI-DESKTOP-TOWER is carrying this issue (reserved 2026-07-07T22:37:59Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh — that is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

run seed context — what this run is carrying (ward#609)

Resolved: coilyco-flight-deck/ward#477 · branch issue-477 · driver claude · workflow direct-main
Run: engineer-claude-ward-477 · ward v0.422.0 · dispatched 2026-07-07T22:37:59Z
Comment thread: 5 included in the pre-flight read, 5 stripped (ward's own automated comments).
- included: @coilysiren (2026-07-02T02:45:24Z), @coilysiren (2026-07-02T08:22:54Z), @coilysiren (2026-07-04T08:32:18Z), @coilysiren (2026-07-06T19:40:26Z), @coilysiren (2026-07-06T19:42:13Z)
- stripped: @coilyco-ops (2026-07-02T02:31:31Z), @coilyco-ops (2026-07-02T08:12:26Z), @coilyco-ops (2026-07-02T08:12:30Z), @coilyco-ops (2026-07-02T08:12:33Z), @coilyco-ops (2026-07-04T08:26:03Z)

Issue body as seeded:

## Why
Persona `github-only-dev` / angle `release-story`. This persona evaluates a repo's health from its GitHub releases page. Observed (2026-07-01, all read-only via API):

- Canonical Forgejo: **v0.242.0**, 242 releases, latest published today.
- GitHub mirror (`github.com/coilyco-flight-deck/ward`): **latest release v0.5.8**, only **36 tags total** — but `main` is current (pushed_at today), so the mirrored README describes v0.24x-era behavior sitting on top of a release page frozen ~200 versions ago.

AGENTS.md § Release documents the contract as: "`mirror-to-github.yml` mirrors main + tags to the read-only GitHub mirror." Observed state contradicts it: main mirrors, tags stopped at v0.5.x, and a set of real GitHub Release objects (v0.5.4–v0.5.8) is stranded at the top of the mirror's Releases page.

For the GitHub arrival this is worse than an empty release page: it affirmatively misstates currency ("latest release v0.5.8") while the tap formula and docs pin v0.24x. The likely cold read is "releases died months ago" → bounce, or "docs are from the future" → distrust.

Distinct from the planned #454 (publish the binary matrix to GitHub releases): that plan makes tag/release parity load-bearing, but the defect here — the *existing, documented* tag mirroring not holding, plus stranded stale releases — needs fixing (or the stale releases scrubbing) regardless of and prior to #454. Related: #438 (mirror identity/support split).

## Deliverable
Fix or re-run tag mirroring so the mirror's tags match canonical, and delete (or clearly supersede) the stranded v0.5.x GitHub releases; alternatively, if tags are deliberately not mirrored anymore, update AGENTS.md's mirror contract and put one line on the mirror explaining where releases live.

## Done condition
The GitHub mirror shows either (a) tags/releases matching canonical Forgejo, or (b) zero stale releases plus an explicit pointer to the canonical release page; AGENTS.md's mirror sentence matches observe

… (truncated to 2000 chars; full body is on this issue)

Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.422.0).

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-477` on host `KAI-DESKTOP-TOWER` is carrying this issue (reserved 2026-07-07T22:37:59Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh** — that is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-flight-deck/ward#477` · branch `issue-477` · driver `claude` · workflow `direct-main` - **Run:** `engineer-claude-ward-477` · ward `v0.422.0` · dispatched `2026-07-07T22:37:59Z` - **Comment thread:** 5 included in the pre-flight read, 5 stripped (ward's own automated comments). - included: @coilysiren (2026-07-02T02:45:24Z), @coilysiren (2026-07-02T08:22:54Z), @coilysiren (2026-07-04T08:32:18Z), @coilysiren (2026-07-06T19:40:26Z), @coilysiren (2026-07-06T19:42:13Z) - stripped: @coilyco-ops (2026-07-02T02:31:31Z), @coilyco-ops (2026-07-02T08:12:26Z), @coilyco-ops (2026-07-02T08:12:30Z), @coilyco-ops (2026-07-02T08:12:33Z), @coilyco-ops (2026-07-04T08:26:03Z) **Issue body as seeded:** ``` ## Why Persona `github-only-dev` / angle `release-story`. This persona evaluates a repo's health from its GitHub releases page. Observed (2026-07-01, all read-only via API): - Canonical Forgejo: **v0.242.0**, 242 releases, latest published today. - GitHub mirror (`github.com/coilyco-flight-deck/ward`): **latest release v0.5.8**, only **36 tags total** — but `main` is current (pushed_at today), so the mirrored README describes v0.24x-era behavior sitting on top of a release page frozen ~200 versions ago. AGENTS.md § Release documents the contract as: "`mirror-to-github.yml` mirrors main + tags to the read-only GitHub mirror." Observed state contradicts it: main mirrors, tags stopped at v0.5.x, and a set of real GitHub Release objects (v0.5.4–v0.5.8) is stranded at the top of the mirror's Releases page. For the GitHub arrival this is worse than an empty release page: it affirmatively misstates currency ("latest release v0.5.8") while the tap formula and docs pin v0.24x. The likely cold read is "releases died months ago" → bounce, or "docs are from the future" → distrust. Distinct from the planned #454 (publish the binary matrix to GitHub releases): that plan makes tag/release parity load-bearing, but the defect here — the *existing, documented* tag mirroring not holding, plus stranded stale releases — needs fixing (or the stale releases scrubbing) regardless of and prior to #454. Related: #438 (mirror identity/support split). ## Deliverable Fix or re-run tag mirroring so the mirror's tags match canonical, and delete (or clearly supersede) the stranded v0.5.x GitHub releases; alternatively, if tags are deliberately not mirrored anymore, update AGENTS.md's mirror contract and put one line on the mirror explaining where releases live. ## Done condition The GitHub mirror shows either (a) tags/releases matching canonical Forgejo, or (b) zero stale releases plus an explicit pointer to the canonical release page; AGENTS.md's mirror sentence matches observe ``` … (truncated to 2000 chars; full body is on this issue) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.422.0). </details>  — Claude (she/her), via `ward agent`

coilyco-ops referenced this issue from a commit

2026-07-07 22:46:46 +00:00

docs(release): correct the GitHub-mirror contract after mirror-to-github removal

coilyco-ops closed this issue

2026-07-07 22:46:46 +00:00

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

coilyco-ops commented

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

Author

Member

WARD-OUTCOME: done - AGENTS.md mirror contract corrected + dead workflow refs scrubbed (3290adc, closes #477); the live GitHub-side scrub is human-gated and now tracked in #646.

Retro: this one fought back in an interesting way. Every prior attempt on #477 died on the same wall (no GITHUB_MIRROR_PAT), and the twist this run was that Kai had already removed mirror-to-github.yml that morning - but the "scrub docs refs" left dangling pointers to the deleted workflow and doc in AGENTS.md, release.yml, pyproject.toml, and the issue config. So the honest, landable fix was finishing that scrub and rewriting the AGENTS.md contract to match reality, which is exactly the "alternatively" branch the issue offered.

What surprised me: I actually had owner-read GitHub access (as coilysiren), so for a moment I thought I could scrub the stale releases directly - but the MCP surface is read-only (delete-release absent, create_or_update_file 403), there's no gh, and only FORGEJO_TOKEN is in env. So the mirror is genuinely unreachable from the container, and worse than the issue described: main itself is frozen at July 1, not just the releases page. High confidence in the doc half (mechanical, pre-commit green). The observable defect persists and is strictly a human credential/infra step - I drafted the mirror-README banner but the 403 blocked it. #646 captures all three human options (restore ref sync, scrub the bot releases, add the banner).

WARD-OUTCOME: done - AGENTS.md mirror contract corrected + dead workflow refs scrubbed (3290adc, closes #477); the live GitHub-side scrub is human-gated and now tracked in #646. Retro: this one fought back in an interesting way. Every prior attempt on #477 died on the same wall (no `GITHUB_MIRROR_PAT`), and the twist this run was that Kai had *already* removed `mirror-to-github.yml` that morning - but the "scrub docs refs" left dangling pointers to the deleted workflow and doc in AGENTS.md, release.yml, pyproject.toml, and the issue config. So the honest, landable fix was finishing that scrub and rewriting the AGENTS.md contract to match reality, which is exactly the "alternatively" branch the issue offered. What surprised me: I actually had owner-read GitHub access (as coilysiren), so for a moment I thought I could scrub the stale releases directly - but the MCP surface is read-only (delete-release absent, `create_or_update_file` 403), there's no `gh`, and only `FORGEJO_TOKEN` is in env. So the mirror is genuinely unreachable from the container, and worse than the issue described: main itself is frozen at July 1, not just the releases page. High confidence in the doc half (mechanical, pre-commit green). The observable defect persists and is strictly a human credential/infra step - I drafted the mirror-README banner but the 403 blocked it. #646 captures all three human options (restore ref sync, scrub the bot releases, add the banner).

coilysiren referenced this issue

2026-07-14 15:27:09 +00:00

director should emit colorized, space buffered, visually distinct messages about the categories of actions its performing on startup #1283

Rows
Columns

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

Why

Deliverable

Done condition