fix(data): make data the sole writer of repos.yaml to end promotion conflicts

[marcusrbrown]

Why

The weekly data → main promotion PR keeps being born with conflicts in metadata/repos.yaml. The root cause is that one file carries two different kinds of change written from two different branches: the autonomous survey state (advanced on data every run) and privacy-policy edits (orphan-entry deletions made on main). When both sides touch the same file between merge-bases, the promotion conflicts — and the only way out has been a manual conflict-resolution recipe.

What this does

Makes data the sole writer of metadata/repos.yaml so the promotion is always a clean fast-forward of that file, and removes the reasons main ever had to edit it.

• Privacy gate reworked. The wiki-leak check no longer resolves private repos' canonical slugs (which is what forced the brittle, fail-on-everything behavior). It now works from a public allowlist: a wiki page may promote only if its slug belongs to an explicitly public repo, or the page is byte-identical to one already on main. Pages are attributed to a single public repo by the repo URL they already carry, and a slug claimed by two public repos fails closed.
• Grandfathering is by content, not filename. An unchanged page already on main still promotes (so legacy lost-access pages like marcusrbrown--copiloting keep working), but a modified page for a repo that is no longer public is blocked.
• Promotion no longer copies main's metadata. The gate reads data's own repos.yaml, so there's no cross-branch read to drift.
• Born-conflicted promotion PRs fail loudly. If the promotion PR comes up conflicted (or its mergeability can't be determined), the run opens a deduplicated alert issue and exits non-zero instead of reporting success and quietly accumulating a backlog.
• repos.yaml is guarded on main. A change to metadata/repos.yaml targeting main is only allowed when it comes from the data promotion, even for Fro Bot identities — closing the path that let a feature-branch edit land there directly.

Verification

• pnpm lint, pnpm check-types, full test suite green (682 passed, 3 todo).
• Simulated the new gate against the live main/data state: 0 pages flagged — all 25 public pages attribute cleanly, and the one lost-access legacy page passes via content-identity grandfathering.
• Confirmed every current public wiki page carries its exact github.com/owner/name URL, so attribution introduces no over-block.

After merge, a manual Merge Data Branch dispatch is the real cross-layer check that the promotion now resolves on its own.

[fro-bot]

The structural move here is the right one: collapsing repos.yaml to a single writer eliminates the both-sides mutation at its root rather than patching the conflict-resolution recipe forever. You're not teaching the promotion to survive collisions — you're removing the collision's reason to exist. That's the correct altitude for this fix.

The privacy-gate rewrite is the load-bearing change and it lands cleanly. Inverting from "resolve private slugs via GraphQL" to "promote only what an explicit public allowlist or content-identity grandfather admits" trades a brittle fail-on-everything network dependency for a pure function. detectPrivateWikiLeaks is deterministic, fails closed on absent private, and the content-hash grandfathering is exactly how you keep marcusrbrown--copiloting alive without re-admitting modified private pages. Test coverage is dense across all four decision branches — ambiguous slug, content-spoof miss, hash-match pass, hash-drift block.

The born-conflicted detection is also well-shaped: distinguishing a successfully-fetched mergeable_state: 'unknown' (GitHub still computing — not an alarm) from an 'unavailable' fetch failure (can't determine — exit non-zero) is the kind of distinction that prevents both false backlogs and silent drift. The dedup-by-prefix alert and retryable-error tolerance on alert creation are correct.

Verdict: PASS

Blocking issues

None.

Non-blocking concerns

• scripts/check-wiki-authority.ts:59 — headRef is attacker-influenced for fork PRs. The new input.headRef !== 'data' bypass only triggers inside the FROBOT_AUTHORS branch, and the workflow checks out github.head_ref, so a fork could in principle name its branch data. In practice a fork PR's author is never fro-bot/fro-bot[bot], so it falls to GUARDED_PATTERNS and is blocked anyway. The guard holds, but it holds because of an identity invariant that isn't asserted at this line. Impact: low (defense-in-depth gap, not an open door). Remediation: optional — a one-line comment noting the bypass is safe only because fro-bot identities never originate from forks would document the load-bearing assumption.

• scripts/merge-data-pr.ts:384-389 — conflict-alert dedup uses unpaginated listForRepo({per_page: 30}). If more than 30 open issues exist, an older conflict alert could fall off the first page and the run would create a duplicate. Same pattern as the existing stale-divergence alert (line 489), so this is consistent, not a regression. Impact: low (low issue volume in this repo). Remediation: if you ever cross ~30 open issues, switch both dedup queries to a title/label search via gh api --paginate or issues.listForRepo with pagination.

• scripts/check-wiki-private-presence.ts:93 — attribution is a substring includes. A page whose stem collides with a public repo's slug AND happens to embed that public repo's github.com/owner/name URL (e.g. as a "related repos" reference) would pass even if the page is really about a different repo. The stem-collision precondition makes this narrow, and the fail-closed defaults elsewhere absorb the residual risk. Impact: low. Remediation: none required; flagging for the record since attribution is the gate's trust anchor.

Missing tests

None. Happy path, both error classes (unknown vs unavailable), conflict dedup, retryable alert-creation failure, and every privacy-gate branch are covered. The headRef matrix in check-wiki-authority.test.ts exercises data/non-data × fro-bot/fro-bot[bot] × repos.yaml/other-metadata, which is the right cross-product.

Risk assessment

LOW. The change is additive to the guard surface (one new head-ref rule), replaces a network-dependent gate with a pure deterministic one, and converts silent promotion failures into loud non-zero exits with deduplicated alerts. The author simulated the new gate against live main/data state (0 pages flagged, 25 public pages attribute cleanly, lost-access legacy page grandfathers). The real cross-layer proof is the first post-merge Merge Data Branch dispatch — until that promotion resolves on its own, treat the conflict-class as fixed-in-theory. Pinned action SHAs and minimal contents: read permissions on merge-data.yaml are intact.

---

Run Summary

Field	Value
Event	pull_request
Repository	fro-bot/.github
Run ID	26751633013
Cache	hit
Session	ses_17d17a6daffeD0aQkf5yH1SiSy