You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The code audit found no release-blocking defect, but several PRs were not machine-clean under the merge ledger because priority review findings had no replayable disposition evidence.
Motivating Miss
Manual inspection showed the current code/docs were acceptable, but script/pr-merge-ledger --strict in the consumer repo could not prove that from durable metadata:
Those threads were outdated or otherwise manually resolved by later code/review context, but the audit had to reconstruct that by hand.
Process Gap Disposition
Mechanism target: checklist+replay
Motivating miss: priority review threads became stale/outdated, and the final PR state was OK, but the merge-readiness ledger could not replay a fixed/waived/deferred/noise disposition.
Replay evidence or park reason: replay the consumer repo ledger for the affected PRs using the repo's merge-ledger seam and strict mode, then verify each priority finding has a durable disposition with evidence URL and head SHA.
Non-goal: requiring every stale bot thread to be perfect, or blocking on old non-priority review noise that no longer applies to current head.
Proposed Work
Connect the existing structured-review direction from #39 to merge closeout:
Define the minimum durable disposition fields for priority review findings: source, finding URL/id, priority/actionability, current-head status, disposition, evidence URL, and head SHA/range.
Teach pr-batch / address-review / post-merge-audit guidance to require this when a priority finding is fixed, waived, deferred, or rejected.
Make the post-merge audit path classify missing disposition evidence as an explicit process finding rather than a manual archaeology exercise.
Keep current-head unresolved review threads stricter than outdated/stale threads; the point is to make stale-thread disposition replayable, not to ignore live blockers.
Acceptance Criteria
A replay against the affected React on Rails PRs reproduces the disposition gap before sample metadata is added.
A sample durable disposition block lets the replay classify an outdated priority finding as fixed, waived, deferred, or false positive without reading chat history.
The shared workflow docs name the consumer repo's merge-ledger seam instead of hardcoding React on Rails commands.
Audit ledger: not applicable (non-release audit)
Context
A full post-merge audit of
shakacode/react_on_railscovered the merge window:2026-07-01-independent-closeout-full575922ff3e2d50f8750877e8847fe7d2c79b995cedb02c7c6be18a2919e9398ee1275d114d21a2edThe code audit found no release-blocking defect, but several PRs were not machine-clean under the merge ledger because priority review findings had no replayable disposition evidence.
Motivating Miss
Manual inspection showed the current code/docs were acceptable, but
script/pr-merge-ledger --strictin the consumer repo could not prove that from durable metadata:unknown_priority_finding_dispositionfindings.unknown_priority_finding_dispositionfindings.unknown_priority_finding_dispositionfindings.unknown_priority_finding_dispositionfindings.unknown_priority_finding_dispositionfindings.Those threads were outdated or otherwise manually resolved by later code/review context, but the audit had to reconstruct that by hand.
Process Gap Disposition
checklist+replayProposed Work
Connect the existing structured-review direction from #39 to merge closeout:
pr-batch/address-review/post-merge-auditguidance to require this when a priority finding is fixed, waived, deferred, or rejected.Acceptance Criteria
Related