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
Release and post-merge audits are currently discoverable only by reading a mix of release-gate comments, tracking issues, and chat summaries. That makes "what has already been audited?" ambiguous.
The detailed findings should still live in audit-specific parent issues, but the release gate should answer the coverage question immediately: "last audited through SHA X; next audit starts at X."
Problem
Release and post-merge audits are currently discoverable only by reading a mix of release-gate comments, tracking issues, and chat summaries. That makes "what has already been audited?" ambiguous.
Current examples:
Those are all useful, but none is a canonical audit ledger that records coverage by range/head SHA and points to follow-up status.
Proposal
Use the release gate issue as the canonical audit coverage ledger for a release train, with finding details staying in dedicated audit parent issues.
Add an Audit ledger section or append-only
Audit Ledger Update:comments with:2026-06-14-rc3-catchupThe detailed findings should still live in audit-specific parent issues, but the release gate should answer the coverage question immediately: "last audited through SHA X; next audit starts at X."
Acceptance criteria
2026-06-09-process-12h2026-06-10-rc2-skillspost-merge-auditor the release-gate workflow documents where audit coverage is recorded.Related