Tighten GA RC feedback intake policy

docs/release-control/v6/internal/HIGH_RISK_RELEASE_VERIFICATION_MATRIX.md

@@ -172,22 +172,29 @@ Companion drill:
   1. Open or install the exact GA candidate being considered for promotion.
   2. Materialize the current dated RC issue-closure record and confirm it
      enumerates the full current RC issue set in scope for v6 GA.
-  3. For each issue, verify one of these dispositions on the affected surface:
-     fixed in candidate with proof, invalid with evidence, or conservatively
-     superseded with the original user-visible failure resolved or explicitly
-     narrowed.
-  4. Confirm no open RC-era user-visible issue is being accepted as normal
-     post-GA cleanup for the v6 line.
+  3. Review the active RC feedback intake surfaces for anything newer than the
+     dated record: newly opened issues, new comments on open RC-soak issues,
+     the pinned prerelease feedback hub, and equivalent actionable feedback
+     reports.
+  4. Fold any still-in-scope user-visible item from that intake back into the
+     dated RC issue-closure record before making the gate call.
+  5. For each issue or absorbed feedback item, verify one of these
+     dispositions on the affected surface: fixed in candidate with proof,
+     invalid with evidence, or conservatively superseded with the original
+     user-visible failure resolved or explicitly narrowed.
+  6. Confirm no open RC-era user-visible issue or still-in-scope RC feedback
+     item is being accepted as normal post-GA cleanup for the v6 line.
 - Pass when:
-  Every issue in the current RC closure set is fixed in the candidate with
-  proof, proven invalid with evidence, or conservatively superseded with the
-  original problem resolved or narrowed, and no user-visible RC-era issue
-  remains open as intended GA carryover.
+  Every issue or still-in-scope feedback item in the current RC closure set is
+  fixed in the candidate with proof, proven invalid with evidence, or
+  conservatively superseded with the original problem resolved or narrowed,
+  and no user-visible RC-era issue remains open as intended GA carryover.
 - Latest exercised record:
   `docs/release-control/v6/internal/records/known-rc-issue-closure-for-ga-blocked-2026-04-21.md`
 - Block release if:
-  Any RC-era issue in scope remains open, unverified, or hand-waved into
-  post-GA work, or if the dated RC issue-closure record is missing or stale.
+  Any RC-era issue or still-in-scope RC feedback item remains open,
+  unverified, or hand-waved into post-GA work, or if the dated RC
+  issue-closure record is missing or stale.
 
 ## Gate: `self-hosted-commercial-ga-coherence`
 

docs/release-control/v6/internal/PRE_RELEASE_CHECKLIST.md

@@ -53,6 +53,7 @@ Use this as the final gate before cutting a Pulse v6 pre-release.
 ## RC Issue Closure
 - [ ] Materialize a dated RC issue-closure record for the actual GA candidate under `docs/release-control/v6/internal/records/`.
 - [ ] Confirm that record enumerates the labeled `affects-6.0.0-rc.*` issues plus any additional open v6 RC-soak issues the project owner still expects v6 GA to address.
+- [ ] Review the live RC feedback intake surface before GA signoff: newly opened issues, new issue comments, the pinned prerelease feedback hub, and equivalent actionable RC feedback must either be absorbed into the dated closure record or explicitly judged out of v6 GA scope.
 - [ ] For each item, record exactly one disposition: fixed in the candidate with proof, invalid with evidence, or conservatively superseded with the original user-visible failure resolved or explicitly narrowed.
 - [ ] Do not carry any open RC-era user-visible issue into GA as accepted “post-GA cleanup”.
 

docs/release-control/v6/internal/SOURCE_OF_TRUTH.md

@@ -159,7 +159,9 @@ Pulse v6 is ready when these outcomes land together:
 4. Stable or GA promotion happens only after prerelease validation, not as the first
    customer exposure.
 5. Stable or GA does not knowingly carry unresolved RC-era user-visible issues
-   across the admitted v6 scope.
+   across the admitted v6 scope, regardless of whether that feedback arrived as
+   a labeled issue, a new issue, an issue comment, the pinned prerelease
+   feedback hub, or an equivalent RC feedback report.
 
 Pulse v6 GA is intended to be a feature-complete release for the
 monitoring-first, unified-resource product case proven during prerelease.

docs/release-control/v6/internal/subsystems/deployment-installability.md

@@ -130,6 +130,11 @@ server-side update execution surfaces.
    The prerelease feedback intake template and active demo/update metadata must
    also stay on generic or current-RC wording instead of hard-coding stale
    `rc.1` examples once later candidates exist.
+   GA signoff must also treat prerelease feedback intake as a live surface, not
+   a one-time issue export: the owned checklist and release runbook must force
+   a last-pass review of new issues, new issue comments, the pinned prerelease
+   feedback hub, and equivalent actionable RC reports before a candidate is
+   declared feature-complete.
    The repo-root VERSION file is part of the same governed boundary and must
    not drift as an
    unowned release-cut switch: changing the version string for a new RC or