fix(review): authorize private target PR lookup with Noema App

[seonghobae]

Purpose

Repair the central reviewer’s cross-repository trust bootstrap so private target repositories are supported without widening authority. GitHub documents the automatically generated GITHUB_TOKEN as repository-scoped to the repository containing the workflow; the previous central-review.yml used that Noema-repository token for the first target PR lookup before minting the target-scoped Noema App token.

Exact implementation

Freshly revalidated source identity:

• Base branch: main; live/base tip 9adb784902cae19a150146a8fadd6a0491f67814.
• Head branch: fix/private-target-review-auth.
• Current exact head: 8d5d62437a944e8c1e9eda4a2b695edb3b5678e3.
• Draft by operational-acceptance design.

The evidence-collection job now orders the trust bootstrap as:

syntactic target repository / PR / head validation
→ derive bounded repository name only
→ mint existing read-only Noema App token for exactly that repository
→ read and bind the live target PR with that App token
→ require open state + exact dispatched head + same target head/base repository
→ checkout trusted reviewer and exact target source

The target identifier step performs no target-state GitHub API request and has no GH_TOKEN. The first live repos/${TARGET_REPOSITORY}/pulls/${PR_NUMBER} read uses ${{ steps.noema_read_app.outputs.token }}. Downstream evidence collection already uses the same scoped App token, so this removes a credential-scope inconsistency rather than introducing another credential family.

No merge, release, deployment, contents-write, or broader publication authority is added.

Test-first lineage

• 01d4f69c0c98c8aa95c79afe0dd8ac8835a09769: test-only contract requiring target validation → repository-scoped App token → authenticated live PR binding → checkout. The pre-fix workflow visibly violated this ordering and used ${{ github.token }} in the live target-binding step. GitHub-hosted ci, reviewer-ci, and Security Scan remained queued without runner assignment and were cancelled by concurrency when the branch advanced, so no executed RED run is falsely claimed.
• a2084c9ce7c9c523227c5dad93162c1c8a4ba8f1: minimal workflow repair moving live target-state access behind the existing read-only target-scoped App token.
• 575b840e08a33f4ee22815b97a0f5489fa0b66a4: APA 7 doctoring documenting GitHub token scope, failure behavior, and private-target acceptance.
• 0b611e649878038828ff8c3dc8b39c9385455121: records the security/interoperability contract under CHANGELOG.md → ## Unreleased.
• 8d5d62437a944e8c1e9eda4a2b695edb3b5678e3: current exact head; adds regression assertions for the existing review-dependent-check exclusion set so the independent reviewer waits on every review-independent current-head check while excluding only opencode-review and metadata-only gate evaluation. The exact comparison from 0b611... changes only reviewer/tests/test_central_review_workflow.py (+20/-0); production workflow source is unchanged by this final commit.

RCA and feasibility

Root cause: the first cross-repository API read used workflow-repository GITHUB_TOKEN authority even though the product supports targets beyond the Noema repository. Public targets can hide the defect because their PR metadata is public; private targets cannot rely on that authority.

Verified remediation path: the workflow already possesses a dedicated Noema GitHub App credential and already minted a repository-scoped read token for later target checkout/evidence reads. The narrow repair therefore performs only syntax validation before token creation, then uses that existing least-privilege token for the first live target read.

Rejected alternatives: broadening GITHUB_TOKEN, adding PAT-like credentials, making the target repository public, skipping exact-head binding, widening the App installation token to the whole organization, or treating public-repository success as proof of private-target authority.

Current exact-head evidence

For exact head 8d5d62437a944e8c1e9eda4a2b695edb3b5678e3:

• ci run 31320482243: terminal failure. The application/repository tests and configured 100% coverage gates complete successfully before the unchanged repository-wide npm audit --audit-level=high boundary rejects inherited nanoid@3.3.16 (GHSA-2v37-7h3g-55p8). The root dependency remediation is PR fix(security): update transitive nanoid for CVE-2026-67213 #76; duplicating it here is rejected.
• reviewer-ci run 31320482244: terminal success.
• Central Security Scan run 31320482249: terminal success.
• Formal GitHub reviews: none.
• Current inline review threads: 0.

The earlier queued-run symptom has recovered for this exact head; it is not counted as a source remedy and remains tracked as organization/control-plane RCA under #30. The current CI failure is a distinct inherited dependency boundary, not a private-target-auth implementation failure.

Documentation

docs/doctoring/private-target-review-auth.md records the decision, failure/recovery behavior, acceptance contract, and current GitHub primary sources in APA 7 format. CHANGELOG.md records the behavior change under ## Unreleased.

Required acceptance before Ready / merge

1. Integrate fix(security): update transitive nanoid for CVE-2026-67213 #76 under actual live governance so the inherited dependency audit can pass without an audit waiver.
2. Refresh/revalidate this exact branch if the protected base moves materially, then require terminal-success ci, reviewer-ci, and Security Scan on the unchanged exact head.
3. Review the current exact head and resolve only valid current findings; satisfy applicable qualifying independent-approval and ruleset requirements.
4. Preserve 100% reviewer/production coverage and public-docstring gates.
5. After protected integration, dispatch a real review against a private ContextualWisdomLab repository on which the Noema App is installed and prove exact-head evidence collection succeeds without permission broadening.
6. Record protected-main operational evidence before claiming private-target support accepted for release/acquisition purposes.

Queued, pending, cancelled, absent, status-only, stale-head, predecessor-head, model-only, or synthetic evidence is never promoted to passing check, approval, or merge authority. No version bump or release is warranted for an unintegrated workflow repair.

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 4b5b810e-1b1d-442f-a6b5-e86b03a35660

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}