Clarify which website version the Owner is approving

[shiny-code-app]

Problem

The Owner release-review comparison reads Production <commit> → testing <commit>. During review, the operator reasonably interpreted this as production overwriting testing. The intended meaning is a comparison between the version currently deployed to production and the proposed production version available in testing.

Agreed design

Lead the Owner's review with the release changes, the testing-site link, and the existing approval action. Keep the version comparison in Technical details, using two labeled rows:

• Current production version: the deployed production commit.
• Proposed production version: the candidate commit, identified as currently in testing.

Remove the arrow between environment names. Use “production” rather than “live” so the wording also remains accurate before a site's public launch. Commit IDs remain available as supporting details.

Finish Line

• The comparison uses the two explicit labels above and has no environment-to-environment arrow.
• Changes, the testing-site link, and the approval action take visual priority over commit IDs.
• A reviewer can identify which version is proposed to replace production without knowing Git terminology.
• Real-browser review at desktop and phone widths verifies the hierarchy and readability using the existing release checklist. Record that evidence in the implementation PR; avoid tests that merely repeat the chosen copy.

Current Status

State: Completed in PR #2516, delivered with #2517 through protected batch #2526. Both originals merged in one LP landing call at 42b8e589b967623df736b38657313c58174e3402; the full qualification receipt is in #2494.

The page leads with changes and the testing link, identifies the viewer's role, preserves full latest feedback, explains pending publication and decision consequences, and separates operator approval-override justification. Current and Proposed production versions are labeled in collapsed Technical details with no environment arrow.

Validation: 74 frontend tests plus API drift/build, 124 shared browser cases, 8 final release-review cases, interactive desktop/phone fixture review, Ruff/format, and independent Anthropic review. All 33 checks passed on final source head 5fdc1499; all 65 combined candidate checks passed. Explicit six-file IDE inspection is RED with 31 unchanged-line findings; earlier clean-worktree GREEN was not full PR coverage and is withdrawn. The base refresh changed none of those six files.

Post-merge CI, Security, CodeQL, and deployment 36287171770 succeeded. Live service image provenance matches the landing. Read-only Chrome verification on the deployed CM release-review page confirmed the operator role, separate justification, initially collapsed Technical details, and Current/Proposed production labels. Only the disclosure was expanded; no real decision or override was submitted. Owner and phone states remain backed by the retained fixture evidence.

Evidence and local IDE state are retained and hash-verified; the task worktree/local branch are removed and main is clean/current. The completed remote head branch was subsequently deleted under the owner's cleanup clarification; its exact head 5fdc1499 remains in main and the qualification record. CM delivery remains held under CM #91.

Relationships

Related to #2446 — Owner approval at release. This follow-up does not add a blocking dependency to that workstream.

[shiny-code-app]

Additional observed review problem, reported by Chris on 2026-09-26: the CM Owner reportedly misunderstood that choosing Accept records approval and still needs to verify requirements and behavior. CM delivery is held in CM #91. The saved decisions and their reasons remain history.

When implementing this issue's already-agreed presentation work, evaluate whether the page makes the consequence of each action clear and keeps unresolved written feedback visible. This is evidence for usability work, not authorization to infer consent from prose, change the Owner, or bypass the release hold. Independent implementation can continue while CM waits for revalidation.

[shiny-code-app]

Proposed next delivery scope — September 26, 2026

Chris requested a concrete direction for continuing Launchplane engineering while CM Owner requirements and acceptance are revalidated. This proposal stays inside the existing DIRECTION.md journey and milestones. It is not a change to the CM hold or an implementation claim.

1. Deliver the release-review clarity fix in #2500

Live observation: the operator sees Production 58e5af7 → testing 719f15c above the checklist and Record operator override at the bottom. The operator interpreted the action as publishing testing to production. The existing route only saves a release decision and publishes its audit record; production promotion is a separate operation. A successful override nevertheless supplies release approval for a later promotion, so the UI must explain that consequence as well.

Implement the already-agreed current/proposed version presentation. Clearly identify whether the viewer is acting as Owner or operator, explain what each available decision records, and explain that deployment is a later action. Keep the operator override visibly distinct from ordinary Owner review. Verify the Owner and operator views at desktop and phone widths, including changes-requested and decision-recorded states, without submitting a real CM acceptance or override. Preserve the authorization and release-gate behavior.

The obsolete CM override reason prepared before the hold was cleared from the operator's browser. The button is disabled again and no decision was submitted.

2. Deliver the existing diagnostic repair in #2513

Use the already-observed Odoo maintenance failure to prove correct error ordering and retention of bounded schedule/module evidence. A failed module upgrade must remain failed and expose its useful diagnosis before later sender-marker checks. This changes Launchplane diagnosis, not CM website content or production data.

3. Use those two genuine fixes for the outstanding train proof in #2494

Keep the fixes in separate focused PRs. Once both satisfy their required checks and the landing window is coordinated, use the supported Launchplane controller to qualify and land the two-entry batch. Verify both final landing commits, provider/refusal evidence as applicable, service-posted feedback, and the installed Launchplane runtime. If the batch still exposes the recorded second-entry defect, repair that root cause within the qualification work and repeat the relevant proof; a single-entry fallback does not close #2494.

The proposed authorization scope ends in reviewed merges and the existing Launchplane deployment, followed by runtime verification. It does not authorize CM merges, promotion, rollback testing, or DNS changes while the hold applies, nor new credentials or permission changes.

Existing work continues with its owner

#2511 is in review as Launchplane #2515 and codex-skills #824. Leave implementation and delivery with its current session; coordinate the train window. Its service must land/deploy before the consumer is installed. This proposal does not independently grant those PRs merge authority.

CM delivery remains parked under CM #91. Justin can use the production release review's Request changes action to record concrete corrections against the proposed version. Owner review and CM production proof remain open while the independent engineering above proceeds.

Decision requested: select #2500 and #2513 as this session's next delivery pair through implementation, required checks, merge, Launchplane deployment, and #2494 qualification. No DIRECTION.md rewrite or new milestone is needed for this scope.

[shiny-code-app]

Chris selected #2500 and #2513, then #2494, accepting the delivery proposal in #2500. Codex session 01a0dfb4-bec1-74a3-9f81-b5c0a982775c owns this pair through implementation, required checks, reviewed merges, the existing Launchplane deployment, and runtime/train qualification.

The first branch is work/issue2500-release-review-clarity, based on eb39ed0bc8d1a22fcf72d36bdbfbe664af359cb4. Next: clarify the release review presentation and validate Owner/operator states at desktop and phone widths using local fixtures. #2513 follows in a separate focused PR; the pair will stay unqueued until both are qualified for #2494's two-entry proof.

Fresh issue discussions, open PRs, worktrees, and supported session inventory show no competing claim on this pair. #2511 / #2515 remain with their existing session. The train window will be rechecked before mutation. CM delivery remains held under CM #91; no CM decision, merge, promotion, rollback, DNS, credential, or grant change is included.

[shiny-code-app]

Operator wording clarification from Chris — September 26, 2026

Chris clarified that the operator-only form should describe an Operator Approval Override, or similarly explicit wording. The current label, Reason for changes or an operator override, suggests that the operator can submit correction requests from this form, although the operator-only view exposes only the override action. The reason must be presented as justification for approving a release by override, not as ordinary review feedback. This is guidance for the ongoing #2500 implementation; the exact final copy can follow the existing clarity criteria.

The explanation should distinguish the effects:

• An Owner Request changes decision records the Owner's notes and prevents approval of that release.
• An operator override records an operator approval of that release, with the entered text as its justification. The button determines the decision; the prose does not turn it into a request for changes.
• Every new submitted release decision is saved in Launchplane and published as a separate release-decision issue in the product repository, with the exact checklist, actor, and reason. Recovery of a pending publication reuses the saved decision/record. The publication is an audit record; clicking the decision button does not deploy.

Chris also questioned whether operators should have this approval authority at all, because ordinary website acceptance belongs to the site Owner. No decision to remove the capability has been made. Keep that ownership question separate from this issue's authorized presentation change. The existing implementation also uses an override for shared-input checklist coverage gaps, so removal needs an explicit decision about that path and cannot be achieved merely by hiding the button.

The existing implementation session retains ownership of #2500/#2513/#2494. CM's operator hold remains in force. This clarification authorizes no real release decision or CM deployment.

[shiny-code-app]

Owner decision — retain the operator override

On September 26, 2026, Chris decided to retain the existing operator approval override. This resolves the open removal question in the earlier wording clarification.

Continue #2500's presentation work: identify it clearly as an Operator Approval Override, explain that the text is an approval justification, and distinguish the recorded approval from the later deployment action. The operator-only form should not suggest that it submits ordinary change requests. Retain the existing capability and authorization behavior; this decision is not an instruction to use an override for CM.

The implementation session already recorded above retains #2500/#2513/#2494. The CM delivery hold in cbusillo/odoo-tenant-cm-website#91 remains in force. This CM session is performing closeout and will not duplicate that implementation.

[shiny-code-app]

Completed through protected batch #2526 at 42b8e589b967623df736b38657313c58174e3402. Both original PRs completed in one LP landing call with separate persisted outcomes. Post-merge CI, Security, CodeQL, deployment, and live image provenance are verified; #2494 and this issue's Current Status contain the receipts. Evidence is retained and task cleanup is complete. CM delivery remains held.