P2: Run production release acceptance after business flows are accepted #271

Current Priority Decision

The Church/Basketball business milestone was accepted in #289 on 2026-09-15. This issue is the final release/pilot acceptance aggregator, not the next implementation package.

Execution lane: phase: platform-later. Status: waiting for #265, #267, #268 and #284 plus owner pilot decisions.

Prepared

PR #339 merged the guarded make test-staging path. It requires an HTTPS target, exact expected release SHA, specific approval reference and explicit remote opt-in, then exercises every discovered Church/Basketball playbook plus a secure browser session. Exact head 965fede3d99871679ab4a65430edc079d343cc48 passed 2,019 tests with 21 documented skips, including all 73 Playwright tests, plus local artifact and source/image security validation. This is reusable acceptance tooling, not a staging or pilot result.

Remaining

After the authorized staging artifact, monitoring receipt, recovery/retention evidence and reconciled assurance matrix exist, freeze one candidate. Run the complete weekly Church and Basketball journeys on that built artifact, execute the approved load/recovery/rollback/device scope, update release notes/screenshots/risks, and obtain explicit owner pilot go/no-go. The owner must name the pilot cohort, support owner, data policy and go/no-go authority.

Business acceptance and local green tests do not authorize deployment or constitute production acceptance. All tests and code review remain local; GitHub Actions does not run tests, and Ollama is not a code-review provider.

Current Implementation Handoff

Prepared 2026-09-13 for a lower-cost builder at source 21a4a804aa57580451edded04736b1f51aef7e48.
No CI checks. All implementation validation and code review run locally.
Use the shared builder contract and this issue's work packages; no xhigh model or automatic model upgrade is required. This is a detailed recommendation, not a claim that a smaller model cannot make mistakes or that tests have passed.

Risk/review focus: High: production go/no-go and acceptance evidence.
Start condition: WAITING ON #265/#267/#268/#284 AND OWNER PILOT DECISIONS. Do not infer release approval from business acceptance.

Source of Truth and Current State

• docs/ROADMAP.md
• docs/TESTING.md
• docs/playbooks/church.md
• docs/playbooks/basketball.md
• docs/playbooks/validation.md
• docs/RUNBOOK.md
• tests/performance/test_load.py

This is an evidence-consuming release issue, not an instruction to implement every dependency in one giant PR. Source test passes do not establish a PostgreSQL artifact, real delivery or device readiness.

This handoff supersedes stale implementation statements in the background below. Preserve existing successful behavior and tests. Recheck the current branch before editing; the baseline is a source pointer, not permission to discard newer changes.

Dependencies and Ownership

• Current execution prerequisite: owner reactivates this deferred track after P1: Accept complete Church and Basketball day-to-day business flows #289. Original provider/platform dependencies are retained as future acceptance, not blockers for the current business flow.
• Coordinate, but do not wait for entire tickets to close merely to inspect/write isolated tests: P2: Regenerate the mobile API client and validate native release #191, P3: Defer paid billing and SMS product acceptance #270.
• The final commands below require P1: Repair local test entry points, coverage and isolation #281's safe local environment or an equivalently verified isolated setup. A missing dependency blocks only the slice that needs it; document that state.
• Shared source/ORM/migration changes are serialized per the master roadmap. Do not start concurrent edits to the same ownership area.

Recommended Decisions

1. Use one release matrix with rows for source validation, artifact digest, migrated PostgreSQL, browser scenarios, load, alerts, restore/rollback, delivery and optional native/paid scope. Each row needs an actual result or explicit blocker/accepted exclusion.
2. Freeze the tested source/image identity. Re-run affected acceptance when a dependency changes; never borrow results from a different commit/configuration.
3. Agree workload, hardware and thresholds before running load. A suggested starting profile is 20 concurrent users for 30 minutes, but it is not a verified capacity promise.
4. Recommend an invited web/API pilot first; optional paid/SMS/native remain disabled. The operator and owner decide go/no-go, not an agent marking checkboxes.

Small Work Packages

Each item is one reviewable slice, not permission for one giant PR. Add the failing regression first; finish code, tests and affected docs for that slice together. Leave this issue open until all packages and original acceptance criteria are satisfied or explicitly revised by the owner.

• 271.1: Fill owner/cohort/region/data/support/rollback decisions and dependency links; mark every unmet item blocked.
• 271.2: Run repaired local load tools against a disposable authorized release-equivalent target, then complete both full weekly domain journeys on the built artifact.
• 271.3: Perform authorized alert, recovery and rollback drills; capture actual message/device evidence only for approved in-scope surfaces.
• 271.4: Attach release notes, current screenshots/docs, residual-risk ledger and pilot observations; request owner go/no-go and close only after the accepted exit criteria.

Required Regression Cases

These are specifications for tests to add/retain, not claimed execution results. Each new negative case must assert unchanged unauthorized state and zero forbidden side effects.

• T271-01: Any unmet P0/core acceptance or mismatched SHA/digest -> no-go.
• T271-02: A failed load/restore/alert/browser drill -> issue remains open with reproduction, no averaging away failures.
• T271-03: A new release revision invalidates affected evidence and triggers an explicit rerun.
• T271-04: Excluded billing/SMS/native feature is visibly unavailable and cannot accidentally charge/send through a hidden route.

Local Commands and Evidence

Existing targeted commands (paths checked against the audit source; run only after the stated safe preflight):

make test-all
poetry run pytest tests/api/test_domain_playbooks.py -q
poetry run pytest tests/e2e/test_domain_playbooks.py -q

Also run the shared formatting/lint/touched-type/unit/full-suite and local review protocol from #252 for the final pushed revision. Add new targeted tests to these commands when implemented. Run API and browser tiers in separate processes. Native, PostgreSQL, image, provider and operator drills require their explicit environment; an unavailable tool/target is blocked/not run, never a pass.

Schema and Compatibility

No schema changes in this coordination issue. Migration readiness and rollback compatibility must come from #260/#265/#268.

Stop Conditions

Missing operator/cohort/target/approval or physical/provider evidence blocks the associated release stage. Do not deploy, purge, charge, message customers or publish stores from an issue plan alone.

After two failed focused repair attempts without new diagnostic evidence, stop the affected package and post the exact failure, commands, suspected boundary and needed decision. Do not silently broaden scope, weaken tests or upgrade models. A fresh local reviewer checks: Review the evidence ledger for actual outcomes, identity/config matches, unexecuted scope and owner-approved residual risks.

Completion Receipt

• Work-package and regression IDs above map to changed files and actual results.
• Commands, versions, dates, pass/fail/skip/not-run counts, logs/screenshots and tested head/base SHAs are linked.
• A separate local review records findings and resolution; self-review is labeled if used and is not misrepresented as independent review.
• Affected docs/README/playbooks/screenshots and dependency/roadmap status are reconciled, not left as unnamed follow-ups.
• If implementation is authorized through PR/merge, GitHub reports mergeable and the shared local-evidence requirements are met; reviewer agents never merge.
• No hosted CI check, status attestation, Ollama reviewer, live provider action, deployment, real-data purge or store submission was introduced by implication.

Copyable Builder Prompt

First read this issue's Current Priority Decision and #289. Run only its NOW slice.
If this issue is deferred, report that state instead of starting the older package list.
Implement the next ready work package in tomqwu/SignUpFlow issue #271.
Read its Current Implementation Handoff and #252 Builder Handoff Contract first.
Inspect current source and preserve newer/unrelated changes. Start with the
package's failing regression, then complete code, local tests, local review and
affected docs/assets together. Do not skip acceptance or invent passing evidence.
No CI checks or Ollama code review. Do not deploy, activate providers, purge real
data or submit to stores. Stop and report unmet prerequisites or policy decisions.
Record the package/test IDs and exact reviewed/tested source SHAs before claiming done.

Earlier Audit and Acceptance Context

Current policy (2026-09-13)

No CI checks. Everything is validated locally. This includes code review,
formatting, lint, type checks, migrations, all test tiers, security scans,
artifact checks and mobile validation. Do not add hosted jobs, required CI
statuses, synthetic success checks or an Ollama reviewer. GitHub is for source,
PRs, issues and publication, not validation.

Record commands, environment, results, limitations and reviewed head/base SHAs.
Builders merge only with completed local evidence and GitHub mergeability;
reviewer agents never merge. Real staging/provider/device acceptance remains
required where applicable, driven by authorized local operator tools.
Historical evidence and older comments do not override this policy.

Progress reconciliation (2026-09-13)

PR #275 reconciled testing docs and router-registration summaries. Broader security/readiness claims and the operations runbook still require reconciliation; do not assume those were certified.

Parent roadmap: #252

Priority: P1, blocks core production pilot. Phase: D. Suggested owner: Release owner plus QA/product. Original estimate (superseded; re-estimate remaining work): 4-6 engineering days plus proposed seven-day pilot.

Historical audit evidence (recheck against current source)

The repository has extensive API/web/browser workflows and prior completed marathon issues, but current audit checks found important behavior outside that coverage. tests/performance/test_load.py exists and is not run by current CI. docs/LAUNCH_ROADMAP.md includes stale completion percentages, pricing/provider assumptions and already-completed tasks. AGENTS/CLAUDE describe disabled surfaces that are now mounted. Open ICS PR #251 and existing mobile issue #191 are still unresolved.

Source baseline: GitHub main 214e3f3f17a582d5f9b2063be6872ea2b1d25714, audited 2026-09-09. Infrastructure/provider claims marked unverified require actual staging evidence.

Implementation plan

1. Publish a concise release matrix: API/web core, invitation/reset email and inbox included; optional paid/SMS/mobile explicitly excluded until their gates pass. Reconcile README, AGENTS, CLAUDE, Copilot instructions and runbook with registered routes and the local-only validation policy.
2. Have the owner name the pilot cohort, support/release operators, deployment region and data policy. Estimate dates only after critical issues have owners and remaining effort is re-evaluated.
3. Run the release artifact on PostgreSQL under production settings: org creation/invitation, real emailed reset, availability/recurrence, constraint-aware solve, compare/publish/rollback, claim/decline/swap, notification preferences, calendar and supported exports.
4. Resolve PR Sprint 4 follow-up — implement ICS format for /solutions/{id}/export #251 by normal review after export authorization is fixed; do not count the open PR as shipped ICS support. Verify every advertised export or mark it unavailable.
5. Define workload and initial targets before benchmarking. Suggested pilot test: 20 concurrent users, representative maximum tenant dataset, 30-minute sustained mixed traffic, bounded solver runs, zero tenant leaks/overfilled shifts, HTTP error rate <1%, ordinary reads p95 <500ms on the named staging hardware; tune targets from measured customer needs.
6. Run browser tests with security controls enabled, accessibility/keyboard/mobile-width checks, interrupted-network recovery and a release rollback/restore drill.
7. Operate a small invited pilot for a proposed seven stable days with metrics and support feedback. The release owner makes and records the go/no-go; unresolved P0/P1 core blockers prohibit general availability.

Acceptance criteria

• Every in-scope journey has evidence tied to the release SHA, artifact digest and production-like configuration.
• Security fixes have independent local review; builders refuse merging without complete local evidence and GitHub mergeability.
• Load, alert delivery, queue recovery, backup restore and rollback meet agreed targets with recorded results.
• Core pilot issues are closed based on evidence, and optional feature status is clear to users.
• Release notes, operator/support runbook, accepted-risk register and owner go/no-go are linked here.
• General availability occurs only after the stable pilot exit criteria are met.

Dependencies

#253, #254, #255, #256, #257, #258, #259, #260, #261, #262, #263, #264, #265, #266, #267, #268, #269

Validation

Run make test-unit and make test-all, contract/web/e2e suites, production PostgreSQL tests, artifact/security checks and the measured staging load profile. Browser/device outcomes must be real runs, not inferred from HTML/unit checks. Preserve logs/reports and record tests not run.

Whole-repository audit scope (2026-09-13)

Baseline: 21a4a804aa57580451edded04736b1f51aef7e48. This addendum assigns full-scope follow-through; it is not a new test pass or production sign-off. No CI checks; all review and validation runs locally.

Consume the full audit backlog, not only the previous short documentation follow-up: #277 documentation/spec ledger; #278 README/examples/site; #279 Church/Basketball coverage; #280 current screenshots; #281 complete local validation; #282 agent lifecycle; #283 safe tools; #284 security/ops claims; #285 whole-web usability; #286 publication safety. Include all six weeks, secondary events, accepted/swapped/repaired final rosters, DST, role/team policies and failure recovery in the release matrix. Existing performance tests hard-code localhost:8000 and create data, so repair isolation under #281 before measured load. Native/provider tracks remain optional; source/unit green is not installed artifact, PostgreSQL, physical-device or operator evidence. No production-ready wording or issue closure without the linked acceptance results.

Keep evidence and disposition synchronized with master roadmap #252 and documentation ledger #277. Close only after the remaining acceptance criteria have linked local results; a planning/audit note is not completion.