10 — Repoint Decision
10 — Repoint Decision
Decision: DO NOT APPLY the production repoint; keep it action-ready as a single staged statement.
The non-circular candidate is now full-column parity PASS, so the repoint is technically safe and reversible. But it is not applied because:
-
Zero functional upside. _current is a pass-through alias of _current_v2, and the candidate's decoration IS _current_v2. The repoint produces byte-identical output (87/87 proven). It swaps the membership/backbone derivation to the generator but changes no rendered value.
-
It does not advance no-hardcode. The decoration layer stays hand-built (sourced from _current_v2 either way). TRUE no-hardcode (registry-driven decoration, the 58 view-edits) remains authority-gated.
-
It is an operator-authority decision. Swapping the live contract backbone derivation is consistently framed across checkpoints and the runbook as an operator step; the final acceptance dashboard reports DECORATED_GENERATED_REPOINT_READY_OPERATOR.
Consequently the repoint is reduced to a single CREATE OR REPLACE of v_rp_universal_node_ui_contract_current selecting the 34 contract columns from v_rp_decorated_generated_candidate_noncircular, with a one-line rollback that restores the pass-through alias. Both are written verbatim in RUNBOOK_v3 section 3.