Collapse per-repo hourly review-repair callers into one roster file

[seonghobae]

Decision

Per-repo *-hourly-review-repair.yml files are the wrong increment. The reusable engine stays pr-review-fix-scheduler.yml. Product identity (repository, cron minute, base branch, max_prs, max_dispatches, retry_hours) belongs in one roster file that calls that engine.

Do not add another thin caller, doctoring file, or per-product pytest that only asserts YAML strings. Stack the collapse on #1360 (vendored contextual-orchestrator / orchestrator/free / ZDR-first). Do not revive NVIDIA NIM, OpenRouter-direct, or OpenAI/Azure sequential fallback hops.

Why this is closed as a copy-PR class

#1288 (LineageWeave), #1267 (Inkspan), and #1361 (learning-interoperability-contracts) each add another 30-line caller plus a contract test and doctoring page. The only real difference is four inputs. That pattern already produced 17 copies on protected main.

Collapse these existing callers

• accounting-information-platform-hourly-review-repair.yml
• afipc-hourly-review-repair.yml
• bandscope-hourly-review-repair.yml
• clearfolio-hourly-review-repair.yml
• contextual-orchestrator-hourly-review-repair.yml
• disksage-hourly-review-repair.yml
• fast-mlsirm-hourly-review-repair.yml
• github-hourly-review-repair.yml
• governance-risk-compliance-hourly-review-repair.yml
• inkspan-hourly-review-repair.yml
• metering-billing-platform-hourly-review-repair.yml
• nonnest2-hourly-review-repair.yml
• orgmetra-hourly-review-repair.yml
• originweave-hourly-review-repair.yml
• psychometrics-commons-hourly-review-repair.yml
• quarantine-sandbox-hourly-review-repair.yml
• semantic-data-portal-hourly-review-repair.yml

Keep pr-review-fix-scheduler.yml and pr-review-autofix.yml. Replace hourly-nvidia-nim-review-repair.yml path-filter sprawl with the single roster plus its one contract test.

Acceptance

• One workflow file owns the hourly roster (matrix or equivalent data, not N YAML clones).
• Adding a product is a roster row, not a new workflow/PR.
• LineageWeave and learning-contracts enter as roster rows (base_branch: "*" where stacked) after feat(ci): route central review through vendored contextual-orchestrator (orchestrator/free, ZDR-first) #1360, not as dedicated files.
• No secrets: inherit, no caller-scoped provider keys, no COPILOT_GITHUB_TOKEN.
• Protected merge, independent exact-head OpenCode APPROVE, and product-home lane ownership stay unchanged.

[seonghobae]

Fresh protected-main evidence for the roster owner boundary: scheduled Governance Risk Compliance Hourly Review Repair run 33147619027 at main@f6c2a2702b7b7578b2d1fc5f2f9a5125a0390d33 failed in job 98772043280, step Validate scheduler target and dispatch authority, before any checkout or mutation. The live OPENCODE_REPOSITORY_DISPATCH_TARGETS value omitted ContextualWisdomLab/governance-risk-compliance, so the reusable scheduler correctly failed closed with Scheduler target repository is not allowlisted. This is configuration/roster drift, not a GRC source defect. The single-roster acceptance here should make caller identity and the scheduler allowlist derive from one authority (or audit their exact equality) so a protected-main caller cannot exist while its target is operationally absent. No leaf workaround or gate relaxation is appropriate.

[seonghobae]

Fresh Inkspan canary exposes a second roster-control failure class at the same central owner boundary.

Exact evidence:

• Inkspan release PR Fix OpenCode coverage fetch authentication #389 current exact head 4b02834fd56a676589afd6b57516da44f8f984be against main@128a239f8b71ca16add4b9e15e21752d1ad63ff0 has required OpenCode verifier run 33170543483; job 98915371357 fails only because the Reviews API has no authenticated APPROVED/CHANGES_REQUESTED verdict on that exact head. Bootstrap job 98915371265 successfully binds the exact target/base/head, so the leaf verifier is healthy.
• Protected central main@e1b03eebc6dc5c85aed393e5928927c96376cf46 still contains .github/workflows/inkspan-hourly-review-repair.yml with an hourly schedule and the existing reusable scheduler.
• Workflow id 342735802 has no current protected-main execution: the latest visible Inkspan Hourly Review Repair schedule run is 33155225826 (run 13), created 2026-08-28T08:24:39Z on predecessor central head cdde0d82602d9568128fd0c1e985ea40b2292710; meanwhile other central scheduled workflows continued through 2026-08-28T19:00Z on current main.
• Central repository_dispatch inventory around the Fix OpenCode coverage fetch authentication #389 verifier window contains OpenCode dispatches for other products but no dispatch bound to Inkspan head 4b02834fd56a676589afd6b57516da44f8f984be.

First causal boundary / falsifiable RCA: the dedicated Inkspan caller exists in protected source but is no longer producing hourly runs, so the exact-head verifier is starved before provider/model execution. This is central scheduler/workflow-lifecycle/roster ownership, not an Inkspan product defect and not evidence that a provider failed for this head. Falsify by showing a later run for workflow id 342735802 or an authenticated dispatch bound to the exact Inkspan head.

Smallest owner remedy should stay on this existing #1362 collapse path: make caller/roster membership and operational scheduling one authoritative machine-checkable state, and fail closed when a roster member has no durable tick/dispatch evidence instead of silently leaving the product verifier without a verdict. Do not add another Inkspan caller or leaf workaround.

RED acceptance: a registered Inkspan roster row/caller with no scheduled execution/dispatch during its bounded cadence is detected as non-passing with exact workflow/run/target evidence.
GREEN acceptance: on an unchanged Inkspan #389 head, the next governed roster tick creates a central dispatch explicitly bound to 4b02834fd56a676589afd6b57516da44f8f984be; that path posts a formal current-head APPROVED or CHANGES_REQUESTED, and required OpenCode consumes that exact verdict. Predecessor runs/status-only output must not satisfy the gate.

[seonghobae]

DiskSage consumer evidence for the roster/review-repair owner, observed on exact current ContextualWisdomLab/disksage#264 head d932e32f33782801bf5cf22c2b71213472541113 against protected main@79067c1160ddedf7fc962cbf8067ce7e83c4564a:

• DiskSage-owned Test 33190435837, Release 33190435790, Security Scan 33190435865, and SAST Semgrep 33190435776 are terminal-success on that unchanged head.
• All current DiskSage review threads are resolved; formal review inventory contains only COMMENTED, no qualifying APPROVED current-head review.
• Central required-workflow run 33190433493 attempt 3 materialized successfully, but job/check 98983769761 (opencode-review) fails specifically at Fail closed without a current-head OpenCode verdict while coverage-evidence 98983770399 and coverage-source-tree 98983770576 succeed.
• This is not repairable by a DiskSage source/workflow workaround without duplicating or bypassing the central reviewer contract.

Please treat this as a concrete DiskSage acceptance canary for the roster collapse: after the central owner change, the unchanged then-current DiskSage head must receive an authoritative Reviews API APPROVED or CHANGES_REQUESTED verdict bound to that exact head, and the required opencode-review job must reflect that verdict without synthetic status, self-approval, or a leaf-side provider path. If the head moves, re-evaluate the fresh head rather than transferring this evidence.