fix(github): migrate repo identity on a GitHub repository rename webhook

[JSONbored]

Summary

• Nothing in the codebase handled the GitHub App's repository webhook with action: "renamed" — a repo rename (e.g. gittensory → loopover) left every repo-identity-keyed row pointing at the old full_name until an unrelated write happened to touch it, and rows keyed only by the old name (repositories, repository_settings) never updated at all without a webhook-driven path.
• Adds maybeHandleRepositoryRenamedWebhookEvent, wired into processGitHubWebhook right before the existing upsertRepositoryFromGitHub(payload.repository) call so that upsert UPDATEs the now-renamed anchor row instead of inserting a fresh, disconnected duplicate.
• renameRepositoryIdentity (src/db/repo-identity-rename.ts) migrates the structural identity columns for repositories, repository_settings, pull_requests, issues, and audit_events's target_key — explicit per-table code (matching this codebase's house convention in repositories.ts) rather than a generic Drizzle helper, with a fold-on-collision pattern for the unique (repo_full_name, number) constraints.
• Also detects the one thing a rename can't migrate on its own: a self-host operator's container-private per-repo config folder is derived from the current repo name and is read-only from the app's perspective, so a folder that existed under the old name but not the new one means the operator's gate/autonomy/review policy silently reverted to defaults. maybeWarnOnMissingLocalConfigAfterRename surfaces that as an error-level audit event + log line instead of a routine info line, using the new hasLocalManifest() (focus-manifest-loader.ts).

Scope

Deliberately narrow to structural repo-identity columns. Follow-up PRs (tracked separately) extend the same pattern to:

• review/audit tables (gate_outcomes, advisories, check_summaries, pull_request_files, pull_request_reviews, etc.)
• caches/analytics tables (ai_review_cache, signal_snapshots, product_usage_events, etc.)
• REES/enrichment tables (review_targets, contributor_gate_history, review_audit, repo_chunks)

Each stays independently reviewable rather than one large cross-cutting migration.

Test plan

• npx vitest run test/unit/repo-identity-rename.test.ts test/unit/repo-rename-webhook.test.ts test/unit/focus-manifest-loader.test.ts — 52/52 passing
• npm audit --audit-level=moderate — 0 vulnerabilities
• npm run test:ci currently fails at the typecheck step, but only on a pre-existing, unrelated issue on main (stale gittensory-named exports in test/unit/miner-cross-repo-evaluation.test.ts from docs(miner): rename gittensory prose to loopover in miner/mcp packages #5899, unrelated to this PR's files) — already fixed in test(miner): fix stale gittensory identifiers in cross-repo-evaluation test #5913. Once that merges and this branch rebases, the full local gate is expected to be clean; this PR's own diff introduces zero new typecheck errors.

[loopover-orb]

Caution

🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥

🛑 LoopOver review result - fixes required

_{Review updated: 2026-07-14 23:02:22 UTC}

7 files · 1 AI reviewer · 2 blockers · readiness 88/100 · CI failing · blocked

🛑 Suggested Action - Manual Review

Review summary
Adds a `repository`/`renamed` webhook handler that migrates repo-identity columns (repositories, repository_settings, pull_requests, issues, audit_events.target_key) from the old full_name to the new one before the existing upsert runs, plus a self-host-only audit warning when a container-private config folder didn't move with the rename. The migration is idempotent (each step only touches rows still under the old name, so redelivery is safe) and collision-safe (a stray row already created under the new name is folded away in favor of the pre-existing row). Test coverage is thorough and exercises the real webhook dispatch path (`processJob`), not a fabricated payload shape, including the no-op cases (same name, missing `from`, wrong action).

Nits — 5 non-blocking

• src/db/repo-identity-rename.ts: the five table updates run as separate sequential statements with no `db.batch()`/transaction wrapper, so a mid-migration crash leaves the identity partially renamed until a webhook redelivery completes it — worth a comment or a batch() call given D1's lack of implicit transactions across awaits.
• src/queue/processors.ts maybeWarnOnMissingLocalConfigAfterRename: records outcome: "denied" for what is a configuration-drift warning, not a denial — consider a dedicated outcome value so this doesn't get misread as a gate decision when scanning audit_events.
• src/queue/processors.ts maybeHandleRepositoryRenamedWebhookEvent: oldFullName is built from `payload.repository.owner.login` (the NEW owner), so a simultaneous org rename + repo rename would compute a non-matching oldFullName and silently no-op the migration — worth a one-line comment noting this known limitation since it isn't covered by a test.
• Consider wrapping the five updates in repo-identity-rename.ts in `db.batch()` (D1 supports batched statements) to make the migration atomic rather than relying purely on idempotent redelivery.
• src/queue/processors.ts: give the self-host config-drift audit event a distinct outcome (e.g. "warning") instead of "denied" so it's not conflated with actual gate denials when querying audit_events.

Why this is blocked

• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.

📋 Copy for AI agents — paste into your coding agent

Fix the following blocker(s) from this PR review:

1. No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.

2. Maintainer requires a linked issue — Link the relevant issue (for example `Closes #123`) before opening the PR.

CI checks failing

• validate
• validate-tests (5)
• validate-tests (3)
• validate-tests (2)
• validate-code

Signal	Result	Evidence
Code review	❌ 2 blockers	1 reviewer
Linked issue	⚠️ Missing	No linked issue or no-issue rationale found.
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (no linked issue context).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 43 registered-repo PR(s), 35 merged, 385 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 43 PR(s), 385 issue(s).
Gate result	❌ Blocking	Repo-configured hard blocker found.
Improvement	✅ Minor	risk: clean · value: minor — Code changes are accompanied by test evidence. LLM value judgment: significant — This closes a real, previously-unhandled data-integrity gap (renamed repos forking history into disconnected rows) with an idempotent, collision-safe migration and end-to-end test coverage against the actual webhook dispatch path.

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository registration is not available in the local Gittensory cache.
• Public profile languages: not available
• Official Gittensor activity: 43 PR(s), 385 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Treat this as maintainer-lane context rather than normal contributor-lane activity.
• Explain no-issue PR.
• Triage stale or unlinked PRs.
• No action.
• Link the issue being solved, or explicitly explain why this is a no-issue PR.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

[BETA] Chat with Gittensory

Ask Gittensory a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @gittensory ask <question> answers contribution-quality Q&A with source citations and freshness.
• @gittensory chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @gittensory mention with a real question is routed to the closest matching read-only command automatically -- no exact syntax required.

Full command reference: https://gittensory.aethereal.dev/docs/gittensory-commands

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.