The GitHub mirror of sirens-echo served a 3-day-old tree, and an agent read it as current #822

New issue

Open

opened 2026-08-14 04:50:10 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-14 04:50:10 +00:00

Member

🤖 Filed by Claude Code on Kai's behalf.

Filed by Olaf (OPS) from a working session, with a concrete instance rather than a hypothetical.

What happened

Asked to review sirens-echo's evaluation harness, I read the repository through the GitHub mirror, because the Forgejo MCP surface exposes no file-read tool (repos, branches, releases, issues, PRs — nothing for contents). The mirror served commit d04fed9e, dated 2026-08-10 11:19. Canonical Forgejo main was 2f24a738, dated 2026-08-13 22:21.

Roughly three and a half days stale. Not diverged — d04fed9e is a real ancestor in canonical history — simply behind.

Why that was expensive

The eval system had been substantially rebuilt in that window. I produced a full written assessment of a design that no longer existed, and filed coilyco-gaming/sirens-echo#763 against it. Most of that issue's supporting evidence was wrong: I described agent/evaluation.json with four cases (the current pack is agent/evaluation.yaml plus sixteen packs under evaluations/), claimed regex and positive assertions were missing when ForbiddenPatterns and RequiredPatterns both exist, and claimed a known leak was ungated when ForbidPrincipalEcho exists specifically for it.

Kai caught it with "the repo is in fj ??? all my repos are in fj." I cloned canonical and corrected the issue. Nothing shipped on the bad reading.

The failure mode is the concerning part: a stale mirror reads exactly like a current one. There is no signal at read time. Every file I fetched was internally consistent and plausibly current, and the assessment built on it was confidently wrong.

Where the defect is

sirens-echo has no mirror workflow — .forgejo/workflows/ holds only ci.yml and image-coverage.yml, and nothing in .github/ pushes. So the GitHub copy is a Forgejo-side push mirror, configured on the server rather than in the repository, which puts it in this repo's territory.

I did not check whether other repos are affected. mcp-beaver's GitHub copy appeared current when I read it earlier the same session, so this may be one repo's mirror rather than the mechanism.

Two questions worth separating

1. Is the mirror broken, or just slow? Push mirrors normally fire on push and retry on a schedule. Three days suggests either a failing job nobody sees or an interval far longer than intended. Worth checking whether the mirror has an error state recorded, and whether any other repo's mirror is behind.

2. Should agents be reading GitHub at all? Arguably not, and that half is cheaper than fixing sync. The tracker rules already say Kai's work routes through Forgejo and GitHub issues are an inbox for external contributors. Nothing says the equivalent for code, and an agent with no Forgejo file-read tool will reach for the mirror by default because it is the only tool-shaped path.

Cloning canonical over HTTPS works fine and needs no token for public repos — that is what I did to recover. If that is the intended path it should be written down somewhere an agent loads, because the current guidance leaves the mirror as the path of least resistance.

Acceptance

Mirror freshness for sirens-echo restored, and the cause identified rather than nudged.
Other repos' mirrors checked for the same lag.
A decision recorded on whether agents should read code from GitHub mirrors at all, and if not, guidance placed where an agent will load it.

Note on scope

I am not proposing the Forgejo MCP grow a file-read tool. That is a real gap in the surface and it is why the mirror got used, but widening a read grant on a public-facing MCP is its own decision with its own blast radius, and should not be made as a side effect of this. Recording it as context, not as a request.

Incidental

Filing this initially against coilysiren/infrastructure returned:

opcore: refusing to follow a POST redirect to
https://forgejo.coilysiren.me/api/v1/repos/coilyco-flight-deck/infrastructure/issues;
a mutating verb must not be silently downgraded

That is opcore working correctly — it declined to let a mutating request be silently re-pointed at a different repo than the caller named. Worth noting that the repo-infrastructure skill points at ~/projects/coilysiren/infrastructure/ while the Forgejo owner is coilyco-flight-deck, which is what sent me to the wrong path. Same class of local-path-versus-canonical-owner drift as the mirror issue itself.

> 🤖 Filed by Claude Code on Kai's behalf. **Filed by Olaf (OPS)** from a working session, with a concrete instance rather than a hypothetical. ## What happened Asked to review `sirens-echo`'s evaluation harness, I read the repository through the GitHub mirror, because the Forgejo MCP surface exposes no file-read tool (repos, branches, releases, issues, PRs — nothing for contents). The mirror served commit `d04fed9e`, dated **2026-08-10 11:19**. Canonical Forgejo `main` was `2f24a738`, dated **2026-08-13 22:21**. Roughly three and a half days stale. Not diverged — `d04fed9e` is a real ancestor in canonical history — simply behind. ## Why that was expensive The eval system had been substantially rebuilt in that window. I produced a full written assessment of a design that no longer existed, and filed https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/763 against it. Most of that issue's supporting evidence was wrong: I described `agent/evaluation.json` with four cases (the current pack is `agent/evaluation.yaml` plus sixteen packs under `evaluations/`), claimed regex and positive assertions were missing when `ForbiddenPatterns` and `RequiredPatterns` both exist, and claimed a known leak was ungated when `ForbidPrincipalEcho` exists specifically for it. Kai caught it with "the repo is in fj ??? all my repos are in fj." I cloned canonical and corrected the issue. Nothing shipped on the bad reading. **The failure mode is the concerning part: a stale mirror reads exactly like a current one.** There is no signal at read time. Every file I fetched was internally consistent and plausibly current, and the assessment built on it was confidently wrong. ## Where the defect is `sirens-echo` has no mirror workflow — `.forgejo/workflows/` holds only `ci.yml` and `image-coverage.yml`, and nothing in `.github/` pushes. So the GitHub copy is a **Forgejo-side push mirror**, configured on the server rather than in the repository, which puts it in this repo's territory. I did not check whether other repos are affected. `mcp-beaver`'s GitHub copy appeared current when I read it earlier the same session, so this may be one repo's mirror rather than the mechanism. ## Two questions worth separating **1. Is the mirror broken, or just slow?** Push mirrors normally fire on push and retry on a schedule. Three days suggests either a failing job nobody sees or an interval far longer than intended. Worth checking whether the mirror has an error state recorded, and whether any other repo's mirror is behind. **2. Should agents be reading GitHub at all?** Arguably not, and that half is cheaper than fixing sync. The tracker rules already say Kai's work routes through Forgejo and GitHub issues are an inbox for external contributors. Nothing says the equivalent for *code*, and an agent with no Forgejo file-read tool will reach for the mirror by default because it is the only tool-shaped path. Cloning canonical over HTTPS works fine and needs no token for public repos — that is what I did to recover. If that is the intended path it should be written down somewhere an agent loads, because the current guidance leaves the mirror as the path of least resistance. ## Acceptance - Mirror freshness for `sirens-echo` restored, and the cause identified rather than nudged. - Other repos' mirrors checked for the same lag. - A decision recorded on whether agents should read code from GitHub mirrors at all, and if not, guidance placed where an agent will load it. ## Note on scope I am not proposing the Forgejo MCP grow a file-read tool. That is a real gap in the surface and it is why the mirror got used, but widening a read grant on a public-facing MCP is its own decision with its own blast radius, and should not be made as a side effect of this. Recording it as context, not as a request. ## Incidental Filing this initially against `coilysiren/infrastructure` returned: ``` opcore: refusing to follow a POST redirect to https://forgejo.coilysiren.me/api/v1/repos/coilyco-flight-deck/infrastructure/issues; a mutating verb must not be silently downgraded ``` That is opcore working correctly — it declined to let a mutating request be silently re-pointed at a different repo than the caller named. Worth noting that the `repo-infrastructure` skill points at `~/projects/coilysiren/infrastructure/` while the Forgejo owner is `coilyco-flight-deck`, which is what sent me to the wrong path. Same class of local-path-versus-canonical-owner drift as the mirror issue itself.

coilyco-ops referenced this issue from a commit

2026-08-14 07:14:17 +00:00

fix(mirror): stop skipping sirens-echo, its 404 no longer holds

coilyco-ops referenced this issue

2026-08-14 07:14:18 +00:00

fix(mirror): stop skipping sirens-echo, its 404 no longer holds #833