- node-pg-migrate + pg: baseline migration (extensions, app_meta) with working down - src/infrastructure/db fail-fast pool and typed query helper - docker-compose: postgres:16-alpine + redis:7-alpine with one-command up - table naming convention <module>_<table> documented in README - integration tests (6) against real PostgreSQL; strict identifier validation for test DDL after security-gate hardening round - deps justified in spec/tech.md; all gates approved; verify.sh green
1.4 KiB
1.4 KiB
Architect — F-002 Database foundation with module-owned schemas
done -> work/artifacts/F-002/architect.md
Decision summary
- Migration tool: node-pg-migrate + pg driver. Pure npm deps, boring, up/down support, version table owned by the tool.
- Single PostgreSQL instance, module ownership by table prefix (
<module>_<table>). No per-module PG schemas — simplicity first; prefix rule documented and exemplified. - Baseline migration only ships foundation objects (extensions +
app_meta). Business tables arrive with their modules. - Dev environment: docker-compose with postgres:16-alpine + redis:7-alpine, one command up.
- Env via Node 22
--env-file; fail fast whenDATABASE_URLmissing. Integration tests skip explicitly whenTEST_DATABASE_URLabsent — no silent magic.
Expected blast radius
EXPECTED BLAST RADIUS
Modules modified: src/infrastructure/db (new)
Modules indirectly affected: none (no HTTP API, no business modules)
Database changes: baseline migration (extensions, app_meta) - greenfield
API changes: none
Events added/changed: none
Risk level: low
Handoff to implementer
Follow specs/F-002-database-foundation/TASKS.md. Docker daemon is available (verified at intake). Definition of done for build stage: compose up green, migrations up/down/up demonstrated against real PostgreSQL, integration tests passing with TEST_DATABASE_URL, and evidence in implementer.md.