Scheduled self-review runs with no GitHub access, so it cannot review the open-issue debt register its own checklist requires (concern #2)

[StarshipSuperjam]

The engine opened this item itself — you didn't create it.

What this is. The engine's scheduled self-review is meant to look over the project's open engine issues — its own "debt register" — and judge whether each still holds and whether the backlog has grown too big to triage. But when it runs on the schedule it has no access to GitHub, so it can't see any of that — and it doesn't say so.

• Where: the run step in .github/workflows/audit-prep.yml ("Run the read-only self-review…") and the seeded checklist .engine/audits/concern-list.json (its second concern).
• What the checklist requires: concern Proof 2 — guardrail-weakening (remove a check rule) #2 targets "the engine-labelled open issues (the deployed engine's own debt register)" and asks the review to judge whether any open issue "no longer reproduces against the current code" or whether "the backlog has grown past the point where the operator can honestly triage it." Both need reading the live issues on GitHub.
• What it actually gets: the run step is handed only the Claude sign-in token — no GitHub token — and the workflow's permissions don't grant reading issues. So the review sees only the committed files in its checkout; the GitHub API is unauthenticated. It can't list issues, open a closed one, or check a pull request.
• Why that's worse than just a missing feature: the audits design says a coverage limit must be disclosed in the summary, never silently skipped (the same way the saved-memory limit is). This review neither sees the debt register nor tells you it couldn't — so a clean-looking summary can quietly omit a whole half of what it is meant to check.
• How it was found: flagged after the first real end-to-end run; confirmed against the workflow's run-step environment and the checklist.

What happens next. A maintainer plans a fix that gives the review read-only access to this project's issues and pull requests, and — until that lands — makes it state plainly in its summary that it couldn't review the debt register. The exact access mechanism is a design decision to settle during planning.

• The wrinkle: the review is deliberately read-only (it reports; the workflow does the committing). The workflow's existing token carries write permissions for those later commit steps, so simply handing that token to the review would give the model write-capable credentials — against the read-only separation the design is built on. The fix should give it a read-scoped view of issues/PRs, not the write token.
• Options to weigh in planning: a read-only token scoped to issues/PRs for the review step; or splitting the run so the review job carries only read permission; or a fine-grained read token. Each trades setup against how cleanly it preserves read-only.
• Fold in the honesty step: until the access lands, the review should disclose the gap in its summary, and the setup page's coverage note (which today mentions only the saved-memory limit) should mention this one too.
• Separate and fuzzier (not this issue): confirming GitHub repo settings (branch protection, the Actions-permission toggle) isn't in the review's checklist today and is partly covered elsewhere on boot — track that on its own if it's wanted.

More detail.

• The run step that needs read access
• The checklist concern it can't satisfy (concern #2)
• The read-only audit persona
• Found while proving the audit end-to-end (PR #179)

[StarshipSuperjam]

Being resolved by #192.

The fix follows the engine's own design rather than the most obvious route. The self-review's persona is deliberately read-only and only ever sees your committed project — it never reaches out to GitHub itself. So instead of handing the persona a GitHub key (which would break that boundary), the scheduled workflow now reads your open engine-labelled issues itself and hands that list to the persona as part of its review. The persona judges the backlog (concern #2) without ever holding any GitHub access, and if the list can't be read on a given run, the summary says so plainly instead of quietly skipping it.

#192 closes this on merge.