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

Activity

1. seonghobae commented on Aug 28, 2026

   

   seonghobae

   on Aug 28, 2026 – with ChatGPT Codex Connector

   ContributorAuthor

   More actions

   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.
2. seonghobae commented on Aug 28, 2026

   

   seonghobae

   on Aug 28, 2026 – with ChatGPT Codex Connector

   ContributorAuthor

   More actions

   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.
3. seonghobae commented on Aug 29, 2026

   

   seonghobae

   on Aug 29, 2026 – with ChatGPT Codex Connector

   ContributorAuthor

   More actions

   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.
4. seonghobae

   added

   priority: mediumNormal-priority or P2 workNormal-priority or P2 work

   maintenance

   type: maintenanceMaintenance, build, dependency, or operational upkeepMaintenance, build, dependency, or operational upkeep

   on Sep 7, 2026