Implements #7980. Independent of #7982-#7984/#7986 — this is a narrow, immediately shippable fix to existing ORB code.
Problem
recordReversalSignals (src/review/outcomes-wire.ts:445) unconditionally excludes any reopen by the repo owner as "administrative re-queue, not a contributor dispute." Every maintainer-driven rescue of a bot mistake (confirmed: metagraphed #7594, reopened and merged by the repo owner within minutes, 2026-07-22 00:54-00:55 UTC) is therefore invisible to reversalRate, the public accuracy metric, AND the internal gate-eval confusion matrix's reversal-discount weighting. This is the single biggest reason the 2026-07-21/22 incidents don't show up anywhere.
Area
src/review/outcomes-wire.ts.
Proposal
- Narrow the exclusion: an owner/admin reopen followed by an approve or merge within a short window (e.g. the same session, a few hours) is a genuine correction signal and should record
reversal_reopened (or a distinguishable variant, e.g. reversal_reopened_by_owner, if keeping the signal separately auditable is preferred). A bare reopen with no follow-up merge (still ambiguous — could be a genuine re-queue) can stay excluded, or get its own lower-confidence bucket — pick based on what's cheapest to implement correctly.
- Confirm this also correctly threads through to
public-accuracy-trend.ts and orb/analytics.ts's export, which both key off the same reversal_* event types.
Deliverables
Resources
Boundaries
Only the owner-reopen exclusion. Does not touch the bot/administrative-reopen exclusion, which stays as-is (a bot reopening itself is genuinely not a human disagreement signal).
maintainer-only.
Implements #7980. Independent of #7982-#7984/#7986 — this is a narrow, immediately shippable fix to existing ORB code.
Problem
recordReversalSignals(src/review/outcomes-wire.ts:445) unconditionally excludes any reopen by the repo owner as "administrative re-queue, not a contributor dispute." Every maintainer-driven rescue of a bot mistake (confirmed: metagraphed #7594, reopened and merged by the repo owner within minutes, 2026-07-22 00:54-00:55 UTC) is therefore invisible toreversalRate, the public accuracy metric, AND the internal gate-eval confusion matrix's reversal-discount weighting. This is the single biggest reason the 2026-07-21/22 incidents don't show up anywhere.Area
src/review/outcomes-wire.ts.Proposal
reversal_reopened(or a distinguishable variant, e.g.reversal_reopened_by_owner, if keeping the signal separately auditable is preferred). A bare reopen with no follow-up merge (still ambiguous — could be a genuine re-queue) can stay excluded, or get its own lower-confidence bucket — pick based on what's cheapest to implement correctly.public-accuracy-trend.tsandorb/analytics.ts's export, which both key off the samereversal_*event types.Deliverables
Resources
src/review/outcomes-wire.ts:433-469(recordReversalSignals)src/services/public-accuracy-trend.ts,src/orb/analytics.ts(downstream consumers to verify)Boundaries
Only the owner-reopen exclusion. Does not touch the bot/administrative-reopen exclusion, which stays as-is (a bot reopening itself is genuinely not a human disagreement signal).
maintainer-only.