docs(governance): add customer-surface quality stop gate

docs/release-control/internal/AGENT_VALUES.md

@@ -86,6 +86,9 @@ that already belong to the canonical system.
    Cleanup, presentation polish, and guardrail-only residue should normally
    support a selected candidate lane or an active blocker rather than
    displacing the queue.
+   That default queue does not override the product-quality stop gate: if a
+   customer-facing baseline is still not good enough to deserve iteration,
+   step back to the owning redesign or canonical model first.
 16. Make every governed slice explicit.
    A mutating slice should carry exactly one active `work_claim` naming the
    lane, candidate lane, coverage gap, or narrower governed item it advances.
@@ -94,6 +97,15 @@ that already belong to the canonical system.
    Before replacing or releasing the claim, record any same-lane residual in
    the owning lane completion or follow-up surface instead of letting the task
    disappear as informal context.
+17. Do not iterate on a bad customer baseline.
+   If a customer-facing surface is still prototype-grade, confusing, or
+   obviously below the product bar, do not treat it as a stable base for more
+   same-shape iteration. Step back to the owning product model, UX flow,
+   trust boundary, or architecture first.
+18. Treat browser truth as product truth for customer surfaces.
+   Code-level proof matters, but customer-facing surfaces are not acceptable
+   until real in-browser behavior and interaction quality are good enough to
+   deserve normal use.
 
 ## Delegation Rule
 

docs/release-control/internal/CONTROL_PLANE.md

@@ -141,6 +141,11 @@ model that active and future release profiles reuse.
    path as prose-only guidance.
    Support-only slices still need that claim boundary, and any same-lane
    residual must be normalized before the claim is replaced or released.
+20. Customer-surface quality is a stop gate, not a polish note.
+   If a customer-facing surface is still prototype-grade, confusing, or
+   untrustworthy in real browser use, the control plane should steer the
+   agent toward redesigning the owning model or boundary instead of
+   continuing narrow same-shape iteration on that weak baseline.
 
 ## Canonical Files
 
@@ -250,3 +255,9 @@ user language should update the control plane.
     It should not require agents to ingest raw `status.json` or `registry.json`
     in full at startup unless the current task genuinely needs to drill into
     those surfaces.
+11. The control plane now treats prototype-grade customer surfaces as a real
+    routing concern.
+    Agents should not let lane continuity or queue selection trap them into
+    repeated improvement of a baseline that is still obviously below the
+    product bar; they should step back to the owning redesign or canonical
+    boundary first.

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

@@ -247,6 +247,11 @@ Every substantial task must finish by checking these questions:
    If the result still has obvious same-lane gaps that make it feel partial,
    fragile, or not realistically shippable, continue the slice or record the
    remaining blocker/open decision before stopping.
+10b. Am I iterating on a baseline that is not good enough?
+    If a customer-facing surface is still prototype-grade, confusing, or
+    obviously below the intended product bar, do not keep refining the same
+    shape. Step back to the owning product model, IA, trust boundary, or
+    architecture first.
 10a. Am I treating support work like product progress?
     Guardrail-only proof routing, contract wording, registry cleanup, and
     audit/test ratchets can support a lane, but they do not count as
@@ -258,6 +263,11 @@ Every substantial task must finish by checking these questions:
     diagnostics?
     Missing evidence items, current-vs-target score, and proof counts are
     signals that help locate the real same-lane gap.
+10ab. Have I checked real browser truth for a customer-facing surface?
+    For important customer-facing UI, code-level proof is not enough by
+    itself. If the surface is meant to be trusted or used normally, exercise
+    it in-browser and judge whether it actually deserves more iteration in its
+    current shape.
     They are not the work item by themselves unless the remaining gap is
     explicitly governance-only.
     For ordinary lane work, identify the runtime, product, ownership, or

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

@@ -1,6 +1,6 @@
 # Pulse v6 Source Of Truth
 
-Last updated: 2026-03-20
+Last updated: 2026-03-27
 Status: ACTIVE
 
 This file is the stable human governance layer for the active v6 release
@@ -316,7 +316,12 @@ Assertion design rules:
     check landed. If obvious same-lane gaps still keep the outcome from being
     coherent, trustworthy, or realistically shippable, that lane is not done
     yet.
-17. Lanes that are at target but intentionally not closed must record a
+17. Do not ship a customer-facing surface that is still prototype-grade.
+    If a portal, hosted workflow, first-session flow, or other customer-facing
+    surface still feels confusing, second-rate, or untrustworthy in real
+    browser use, it is not acceptable to keep treating that surface as a good
+    baseline for narrow refinement.
+18. Lanes that are at target but intentionally not closed must record a
     bounded residual in `status.json` with a short rationale and explicit
     tracking references to the governing follow-up surface.
     Pair lane `status` and `completion.state` coherently: `complete` goes with
@@ -340,17 +345,17 @@ Assertion design rules:
     `completion.tracking`.
     Once a lane followup is no longer active residual work, remove it from
     `lane_followups` instead of leaving it behind with a completed status.
-18. Do not treat a lane as healthy just because it has local fixes on a legacy path.
+19. Do not treat a lane as healthy just because it has local fixes on a legacy path.
     If the canonical v6 route for that surface now runs through unified
     resources, canonical shared types, explicit subsystem ownership, or a
     modernized proof path, the lane is still below floor until that migration
     is made or the remaining gap is governed explicitly.
-19. Do not treat missing evidence count or a score delta as the task itself.
+20. Do not treat missing evidence count or a score delta as the task itself.
     If the real remaining gap is runtime, product, ownership, or behavior
     coherence, fix that gap and let the score/evidence catch up as proof.
     Only treat evidence-count closure itself as the task when the remaining
     gap is explicitly governance-only.
-20. Do not run parallel mutating agents out of one dirty checkout and call
+21. Do not run parallel mutating agents out of one dirty checkout and call
     that acceptable coordination.
     Claims reduce overlap, but they do not isolate hooks, formatters, staged
     reads, or unrelated dirt. Parallel mutation should use separate worktrees

docs/release-control/v6/internal/records/rc-to-ga-promotion-readiness-blocked-2026-03-26.md

@@ -9,23 +9,26 @@
 1. No Pulse v6 prerelease has shipped yet.
 2. The repository contains accidental prerelease git tag history (`v6.0.0-rc.1`),
    but those tags were never published and do not count as shipped prerelease lineage.
-3. The governed release profile in `docs/release-control/control_plane.json`
+3. The selected remote ref `origin/pulse/v6-release` is still behind the current
+   local governed branch state, so `Release Dry Run` would exercise stale remote
+   control-plane metadata instead of the intended candidate.
+4. The governed release profile in `docs/release-control/control_plane.json`
    currently declares both `prerelease_branch` and `stable_branch` as
    `pulse/v6-release`.
-4. The active control-plane target is still `v6-rc-stabilization`, not
+5. The active control-plane target is still `v6-rc-stabilization`, not
    `v6-ga-promotion`.
-5. The active local `pulse/v6-release` branch currently reports `VERSION=6.0.0-rc.1`, so the
+6. The active local `pulse/v6-release` branch currently reports `VERSION=6.0.0-rc.1`, so the
    working line is still prerelease and there is not yet a governed local stable
    `6.0.0` candidate.
-6. There is still no governed `Prerelease-to-GA Rehearsal Record` proving a successful
+7. There is still no governed `Prerelease-to-GA Rehearsal Record` proving a successful
    non-publish `Release Dry Run` for the eventual stable `6.0.0` candidate.
-7. `docs/releases/RELEASE_NOTES_v6.md` and
+8. `docs/releases/RELEASE_NOTES_v6.md` and
    `docs/release-control/v6/internal/V5_MAINTENANCE_SUPPORT_POLICY.md` still leave the
    GA announcement dates as placeholders because no real prerelease lineage or GA-ready
    rehearsal has locked them yet:
    - `v6` GA date placeholder: `[v6-ga-date]`
    - `v5` end-of-support placeholder: `[v5-eos-date]`
-8. There is still no governed `Release Dry Run` artifact or rehearsal record
+9. There is still no governed `Release Dry Run` artifact or rehearsal record
    exercising stable inputs for:
    - `version=6.0.0`
    - no governed `promoted_from_tag` exists yet because no prerelease has shipped

docs/release-control/v6/internal/status.json

@@ -1,6 +1,6 @@
 {
   "version": "6.0",
-  "updated_at": "2026-03-20",
+  "updated_at": "2026-03-27",
   "scope": {
     "active_repos": [
       "pulse",