# Current State This file is the integrated default-branch snapshot. Feature tasks record progress in `30-worklog/tasks/{task_id}.md` and propose canonical changes for the Integration Gate. Feature tasks must not rewrite this file; it changes only in integration mode. ## Integrated Through - `84d84ba94f136f10624700e8d34ed19fc6fe7fe7` (`20260812-rds-postgres-adapter-7f2c1a`) ## Current Focus The application now has a production deployment path for Alibaba Cloud ACK backed by direct Alibaba Cloud RDS PostgreSQL access. Local JSON remains an explicit development/test backend. ## Recently Completed - 2026-08-12: Replaced the Supabase/PostgREST runtime path with a server-only `pg` adapter across data, account, and billing stores. - 2026-08-12: Added versioned PostgreSQL migrations, strict backend selection, verified-CA TLS, database readiness, and ACK Web/Worker/migration manifests. ## In Progress - Production environment values and the real RDS/ACK rollout are not yet validated in this repository environment. ## Next Recommended Steps 1. Back up the target database; create separate migration and application roles; verify the RDS internal endpoint, VPC connectivity, whitelist, TLS mode, and CA certificate. 2. Build and push the reviewed image, run the one-shot migration Job, confirm `/api/ready`, then roll out Web and Worker. 3. Keep Web at one replica until generated assets are externalized to OSS or another shared object store. ## Open Questions / Blockers - Target RDS PostgreSQL version, connection budget, endpoint, TLS enforcement, CA bundle, database roles, and ACK network policy remain deployment inputs. ## Risky Areas - Database migrations and least-privilege grants must be tested against the actual RDS instance before production cutover. - Web pods still own runtime files; PostgreSQL does not make local uploads/generated assets safe for horizontal Web scaling. - The current image runs as root; moving to a non-root user requires an explicit writable-path ownership design. ## Last Updated 2026-08-12