Skip to content

P1: Prove local database correctness; defer production parity #260

Description

@tomqwu

Current Priority Decision

Owner direction, 2026-09-13: complete Church/Basketball business workflows and day-to-day operations for every role first; billing and platform readiness later.

Execution lane: phase: business-flow. Current business milestone: #289.
This section overrides older priority, start conditions, broad dependency order and launch estimates below. Keep the detailed technical recommendations where compatible. Execute only the NOW slice; do not expand a mixed issue into its whole production scope. Record completed slice receipts in #289; keep this issue open while retained later work remains.

NOW

Provide only the owned local database/transaction harness required to prove current workflow persistence and #264/#286 race safety. SQLite remains useful for ordinary tests; if the chosen lock protocol requires PostgreSQL, run minimal local PostgreSQL tests rather than fake them with SQLite.

LATER

Full PostgreSQL production parity, complete release migration/cascade matrix and infrastructure deployment. Local DB correctness is not a platform-production acceptance claim.

Validation stays local. No CI checks, hosted reviewers or Ollama code review. Preserve tenant isolation, real member responses and atomic roster changes. A deferred feature is not permission to expose an unfixed vulnerability. No deployment, paid-provider activation or production sign-off is authorized by this reprioritization.

Before implementation, read #252 and #289; finish one role/work package with tests, local review and affected docs/assets. The earlier completion receipt below covers whole-issue closure, not a requirement to finish every deferred package before the business milestone.


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: database isolation, migrations and concurrency evidence.
Start condition: Start only the NOW work package defined above. Use its local business prerequisites, not the entire older platform-release dependency list.

Source of Truth and Current State

Per-run SQLite isolation exists. The root fixture still supplies SQLite-specific connect_args and create_all; setting DATABASE_URL alone does not prove PostgreSQL tests use that engine.

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

Recommended Decisions

  1. Keep SQLite as fast default. Add an explicit local PostgreSQL test mode with a per-run unique database/schema owned by the harness and engine-aware fixtures; no implicit fallback to SQLite.
  2. Require loopback/explicitly authorized local endpoint and an ownership marker before any create/reset/drop. Validate and display redacted destination identity before destructive setup.
  3. Run Alembic upgrade against an empty DB and an earlier revision populated with synthetic data. Production-like tests must not repair missing migrations with create_all.
  4. Use separate connections/processes and synchronization barriers for race tests. Each test report names actual dialect/server version, migration head and isolated destination.

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.

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.

  • T260-01: PostgreSQL mode with missing service or SQLite URL -> explicit failure, never skipped success.
  • T260-02: Two runs create independent fixtures; cleanup of A leaves B and an unrelated sentinel database untouched.
  • T260-03: Upgrade from previous revision preserves people/roles/assignments/accepted state and reaches one Alembic head without create_all.
  • T260-04: Parallel claim/publication transactions use PostgreSQL locks and produce deterministic invariant outcomes, not serialized TestClient calls.

Local Commands and Evidence

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

poetry run pytest tests/unit/test_make_test_db_path.py tests/unit/test_conftest_mocking.py -q
poetry run pytest tests/integration/test_api_server_smoke.py tests/integration/test_tenancy_guard.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

A local test harness is new infrastructure, not a new production schema. Fix only migration defects reproduced on supported engines; never edit published migration history to erase drift.

Stop Conditions

No shared/customer DB reset, Docker volume deletion or remote DB targeting. Missing local PostgreSQL blocks engine-specific acceptance but not harness/unit work.

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: Verify connection URLs/dialects, ownership guards, real separate transactions, migration history and teardown refusal paths.

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 #260.
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)

Per-run SQLite paths are implemented in Makefile and tests/conftest.py. Keep that regression coverage. Remaining work is local PostgreSQL parity, explicit engine selection, concurrent workers and upgrade-from-existing-data evidence.

Parent roadmap: #252

Priority: P1, blocks core production pilot. Phase: B. Suggested owner: Backend/test infrastructure. Original estimate (superseded; re-estimate remaining work): 4-6 engineering days.

Historical audit evidence (recheck against current source)

.github/workflows/ci.yml starts PostgreSQL but applies DATABASE_URL only to the Alembic upgrade step. tests/conftest.py forces a shared /tmp/signupflow_test.db; API/web fixtures use in-memory SQLite plus create_all. api/database.py:98 creates tables during app startup. The audit passed fresh SQLite upgrade and alembic check, so no SQLite schema drift is asserted. PostgreSQL runtime parity and migration upgrade-from-existing-data remain unverified.

Source baseline: GitHub main 214e3f3f17a582d5f9b2063be6872ea2b1d25714, audited 2026-09-09.

Implementation plan

  1. Give every test run/worker a disposable database namespace. Remove hidden overrides of an explicitly supplied PostgreSQL URL and avoid shared fixed-path deletion from Makefile/test fixtures.
  2. Add a local PostgreSQL integration suite that constructs schema through Alembic, runs real-JWT API/web workflows, and verifies foreign keys, cascade behavior, JSON queries and date/time handling.
  3. Add PostgreSQL race tests for reset issue/redeem, refresh rotation, first-admin creation, publish/rollback, open-shift capacity and swap claim.
  4. Test an empty database and an upgrade from a previous schema with representative synthetic data; run alembic check after upgrade and validate required indexes/constraints.
  5. Make production startup verify migration state instead of create_all; run migrations once per deployment using a controlled release step/lock.
  6. Keep SQLite as the fast tier, enforce foreign keys where appropriate, and document any intentional backend differences.

Acceptance criteria

  • Local PostgreSQL validation runs business requests, not merely a migration command.
  • Concurrent test runs cannot truncate or contaminate another run's database.
  • Migration-only schema supports the application with no create_all repair.
  • Upgrade preserves data and constraints; racing operations have one valid winner or documented idempotent outcomes.
  • Existing SQLite test tiers and CLI flows still pass.

Dependencies

None; may start in parallel with security fixes.

Validation

Run isolated tests twice and in parallel, PostgreSQL integration/upgrade tests, alembic check, and make test-all. Record the database engine/version in local validation reports. Alembic check detects proposed schema operations with documented autogenerate limits: https://alembic.sqlalchemy.org/en/latest/autogenerate.html#running-alembic-check-to-test-for-new-upgrade-operations .

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.

Account for all nine alembic files and the ORM/startup path, not only a fresh migration. Keep per-run SQLite isolation already implemented. Add upgrade-from-existing-data, schema drift, foreign keys/cascades, timezone/JSON behavior, concurrent writes and process-level worker tests against explicitly isolated PostgreSQL. Include role/constraint and publication cases (#263/#286), claim races (#264), and restored-data checks (#268). Legacy tests/security and performance code must not connect to an implicit default database/server (#281). No PostgreSQL or Docker runtime validation was performed in this planning audit.

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestphase: business-flowCurrent Church/Basketball business-flow work; execute only the active slice in each issue.tests

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions