@ngocsangairvds/vsaf 4.0.6 → 4.0.7

package/skills/vds-skill/vds-scripts/docker/docker-compose.services.yml

@@ -0,0 +1,425 @@
+# =============================================================================
+# VDS Tier 2 — Long-Running Service Compose
+# =============================================================================
+# Version: 2.0.0
+# Phase: ecosystem-infrastructure-evolution v2.13.x (WP-5.3)
+#
+# This file declares ONLY the long-running services (per ADR-INF-10):
+# memory-api, memory-worker, scheduler-orchestrator, multi-agent-orchestrator.
+# CLI orchestrators (audit, pdf, progress, db-query) live in
+# `docker-compose.cli.yml` (Tier 3). Earlier versions of this file mixed both
+# patterns under "services" which caused CLI containers to restart-loop after
+# each clean exit.
+#
+# NOTE (v2.15.10 / ADR-INF-10): memory-migrate, audit-migrate, and
+# progress-migrate were retired — migrations are now an explicit operator
+# step (`docker compose run --rm --no-deps <service> alembic upgrade head`).
+# The Tier 3B auto-init one-shot sub-shape no longer exists.  See ADR.md
+# Tier 3 Sub-Shapes section for the updated table.
+#
+# Environment File Loading Order:
+
+#   1. ~/.vds/.env (user-level credentials, loaded first)
+#   2. docker/infrastructure/.env (infra-specific config)
+#   3. Shell environment variables (${VAR:-default} syntax)
+#   4. docker compose -e overrides
+#
+# Usage:
+#   docker compose -p vds-platform \
+#                  -f docker/docker-compose.infra.yml \
+#                  -f docker/docker-compose.services.yml \
+#                  -f docker/docker-compose.cli.yml \
+#                  --profile memory up -d
+#
+# Profiles (long-running only):
+#   - memory      : memory-api + memory-worker (FastAPI + Celery)
+#   - scheduler   : scheduler-orchestrator (DBOS-managed FastAPI; needs VDS_SCHEDULER_ENABLED=true)
+#   - multi-agent : multi-agent-orchestrator (FastAPI agent coordinator)
+#   - full        : all of the above
+#
+# For CLI profiles (audit/pdf/progress/db-query/vds-cli/mcp-server) and the
+# three migrate one-shots load `docker-compose.cli.yml` instead.
+# =============================================================================
+
+# Must match docker-compose.infra.yml + docker-compose.cli.yml so all three
+# files form ONE compose project (ADR-INF-7 hybrid identity anchor).
+name: vds-platform
+
+x-env-files: &env_files
+  - ${HOME}/.vds/.env
+
+# v2.15.15 (I5): bound JSON-file log driver to prevent unbounded disk growth.
+# Long-running services accumulate logs over weeks; default has no size cap.
+x-logging-default: &logging-default
+  driver: json-file
+  options:
+    max-size: "10m"
+    max-file: "3"
+
+# Operator note (v2.0.17 N.52 consolidation): Docker Compose's `${VAR}` YAML
+# substitution reads from compose's own env (the invoking shell or
+# `--env-file`/`docker/.env`), NOT from the per-service `env_file:` block.
+# To make `${VDS_POSTGRES_PASSWORD}` (and similar) resolve at compose-up time
+# WITHOUT duplicating values in two locations, a developer-local symlink
+# `docker/.env -> ~/.vds/.env` is required (gitignored). One canonical
+# `~/.vds/.env` then feeds BOTH compose-time interpolation AND the in-container
+# env_file. To bootstrap on a fresh checkout: `ln -sf ~/.vds/.env docker/.env`.
+
+services:
+  # ---------------------------------------------------------------------------
+  # Memory API Service (FastAPI + uvicorn; long-running)
+  # ---------------------------------------------------------------------------
+  memory-api:
+    profiles: ["memory", "full"]
+    env_file: *env_files
+    build:
+      context: ../
+      dockerfile: memory_orchestrator/Dockerfile
+    image: vds-memory:${VERSION:-1.0.0}
+    container_name: vds-memory-api
+    depends_on:
+      # Post-v2.15.10: migrations are an explicit operator step
+      # (`docker compose run --rm --no-deps memory-api alembic -c memory_orchestrator/alembic.ini upgrade head`),
+      # not an auto-init dependency. Tier 3B sub-shape retired per ADR-INF-10 v2.15.10.
+      postgres:
+        condition: service_healthy
+      redis:
+        condition: service_healthy
+      pgbouncer:
+        condition: service_healthy
+    environment:
+      # Memory schema DSN — Phase 224 single-DSN deploy model.
+      # `+psycopg` driver suffix forces SQLAlchemy to use psycopg v3 (the only
+      # driver installed; pyproject:42 ships `psycopg[binary]>=3.3.3` and
+      # psycopg2 is intentionally absent from the slim image). The entrypoint's
+      # python+psycopg probe strips the dialect prefix before psycopg.connect
+      # (which is libpq-native). Read by alembic env.py via `resolve_database_url`
+      # and by the runtime FastAPI app — both accept the +psycopg suffix.
+      #
+      # No MIGRATION_DATABASE_URL override needed: Phase 224 ADR retires the
+      # two-DSN workaround. The entrypoint never reads MIGRATION_DATABASE_URL,
+      # so any value leaking from ~/.vds/.env is harmless.
+      DATABASE_URL: postgresql+psycopg://postgres:${VDS_POSTGRES_PASSWORD:-vds_postgres_secret}@vds-pgbouncer:6432/vds_memory
+
+      # PostgreSQL connection — all values env-driven from ~/.vds/.env (sourced by
+      # the operator before `up`). Defaults match the shared `vds-postgres` service
+      # per ADR-INF-10 so the stack works out-of-the-box for fresh clones.
+      # P8 v2.15.4: routes through vds-pgbouncer:6432 (session-mode) per ADR-INF-13.
+      # POSTGRES_DB is the PgBouncer stanza name (vds_memory), NOT the underlying
+      # database (which IS vds_platform; the stanza maps to it transparently).
+      POSTGRES_HOST: ${POSTGRES_HOST:-vds-pgbouncer}
+      POSTGRES_PORT: ${POSTGRES_PORT:-6432}
+      POSTGRES_USER: ${POSTGRES_USER:-postgres}
+      POSTGRES_PASSWORD: ${VDS_POSTGRES_PASSWORD:-vds_postgres_secret}
+      POSTGRES_DB: ${POSTGRES_DB:-vds_memory}
+
+      # Redis connections with explicit DB suffixes
+      REDIS_HOST: redis
+      REDIS_PORT: 6379
+      REDIS_URL: redis://redis:6379/${REDIS_CELERY_BROKER_DB:-0}
+      REDIS_MEMORY_CACHE_DB: ${REDIS_MEMORY_CACHE_DB:-1}
+      REDIS_SESSION_STORE_DB: ${REDIS_SESSION_STORE_DB:-2}
+      REDIS_ANALYTICS_DB: ${REDIS_ANALYTICS_DB:-3}
+      REDIS_SEARCH_CACHE_DB: ${REDIS_SEARCH_CACHE_DB:-4}
+      REDIS_RATE_LIMITING_DB: ${REDIS_RATE_LIMITING_DB:-5}
+      REDIS_TOOL_DISCOVERY_DB: ${REDIS_TOOL_DISCOVERY_DB:-9}
+
+      # Qdrant for mem0
+      MEM0_QDRANT_HOST: qdrant
+      MEM0_QDRANT_PORT: 6333
+
+      # Service config — required by memory_orchestrator config validator
+      SERVICE_NAME: "VDS AI Memory Service"
+      SERVICE_ENVIRONMENT: ${SERVICE_ENVIRONMENT:-development}
+      SERVICE_JWT_SECRET_KEY: ${SERVICE_JWT_SECRET_KEY:?required — set in ~/.vds/.env (generate with `openssl rand -hex 32`)}
+      MCP_ENABLE_MCP_SERVER: ${MCP_ENABLE_MCP_SERVER:-false}
+
+      # Phase 225 (FR-225.12, ADR-98): embeddings via host Ollama through
+      # vds_agent_core EmbeddingClient. Legacy EMBEDDING_* vars from env_file
+      # remain supported for one cycle (back-compat).
+      VDS_AGENT_CORE_EMBED__PROVIDER: ollama
+      VDS_AGENT_CORE_EMBED__BASE_URL: http://host.docker.internal:11434
+    extra_hosts:
+      # Linux portability — macOS auto-resolves host.docker.internal.
+      - "host.docker.internal:host-gateway"
+    ports:
+      - "${API_PORT:-8000}:8000"
+    deploy:
+      resources:
+        limits:
+          cpus: "${VDS_MEMORY_API_CPU_LIMIT:-1.0}"
+          memory: "${VDS_MEMORY_API_MEM_LIMIT:-1g}"
+        reservations:
+          cpus: "${VDS_MEMORY_API_CPU_RESERVE:-0.5}"
+          memory: "${VDS_MEMORY_API_MEM_RESERVE:-256m}"
+    volumes:
+      - memory_logs:/app/logs
+    networks:
+      - vds
+    restart: unless-stopped
+    logging: *logging-default
+
+  # ---------------------------------------------------------------------------
+  # Memory Worker Service (Celery; long-running)
+  # ---------------------------------------------------------------------------
+  memory-worker:
+    profiles: ["memory", "full"]
+    env_file: *env_files
+    build:
+      context: ../
+      dockerfile: memory_orchestrator/Dockerfile
+    image: vds-memory:${VERSION:-1.0.0}
+    container_name: vds-memory-worker
+    depends_on:
+      # Post-v2.15.10: migrations are an explicit operator step
+      # (`docker compose run --rm --no-deps memory-worker alembic -c memory_orchestrator/alembic.ini upgrade head`),
+      # not an auto-init dependency. Tier 3B sub-shape retired per ADR-INF-10 v2.15.10.
+      postgres:
+        condition: service_healthy
+      redis:
+        condition: service_healthy
+      pgbouncer:
+        condition: service_healthy
+    environment:
+      # Memory schema DSN — Phase 224 single-DSN deploy model (matches memory-api).
+      # `+psycopg` driver suffix forces SQLAlchemy v3 (only driver installed).
+      # Entrypoint's python+psycopg probe strips the prefix for psycopg.connect.
+      # No MIGRATION_DATABASE_URL override needed — see memory-api comment.
+      DATABASE_URL: postgresql+psycopg://postgres:${VDS_POSTGRES_PASSWORD:-vds_postgres_secret}@vds-pgbouncer:6432/vds_memory
+
+      # PostgreSQL connection — all values env-driven from ~/.vds/.env.
+      # P8 v2.15.4: routes through vds-pgbouncer:6432 (session-mode) per ADR-INF-13.
+      # POSTGRES_DB is the PgBouncer stanza name (vds_memory), NOT the underlying
+      # database (which IS vds_platform; the stanza maps to it transparently).
+      POSTGRES_HOST: ${POSTGRES_HOST:-vds-pgbouncer}
+      POSTGRES_PORT: ${POSTGRES_PORT:-6432}
+      POSTGRES_USER: ${POSTGRES_USER:-postgres}
+      POSTGRES_PASSWORD: ${VDS_POSTGRES_PASSWORD:-vds_postgres_secret}
+      POSTGRES_DB: ${POSTGRES_DB:-vds_memory}
+
+      # Redis with explicit Celery broker DB (REDIS_HOST/PORT also required by config validator)
+      REDIS_HOST: redis
+      REDIS_PORT: 6379
+      REDIS_URL: redis://redis:6379/${REDIS_CELERY_BROKER_DB:-0}
+      REDIS_TOOL_DISCOVERY_DB: ${REDIS_TOOL_DISCOVERY_DB:-9}
+
+      # Service config — required by memory_orchestrator config validator
+      SERVICE_NAME: "VDS AI Memory Worker"
+      SERVICE_ENVIRONMENT: ${SERVICE_ENVIRONMENT:-development}
+      SERVICE_JWT_SECRET_KEY: ${SERVICE_JWT_SECRET_KEY:?required — set in ~/.vds/.env (generate with `openssl rand -hex 32`)}
+      MCP_ENABLE_MCP_SERVER: ${MCP_ENABLE_MCP_SERVER:-false}
+
+      # Worker config
+      CELERY_WORKER_CONCURRENCY: ${CELERY_WORKER_CONCURRENCY:-4}
+
+      # Phase 225 (FR-225.12, ADR-98): embeddings via host Ollama through
+      # vds_agent_core EmbeddingClient. Legacy EMBEDDING_* vars from env_file
+      # remain supported for one cycle (back-compat).
+      VDS_AGENT_CORE_EMBED__PROVIDER: ollama
+      VDS_AGENT_CORE_EMBED__BASE_URL: http://host.docker.internal:11434
+    extra_hosts:
+      # Linux portability — macOS auto-resolves host.docker.internal.
+      - "host.docker.internal:host-gateway"
+    volumes:
+      - memory_logs:/app/logs
+    deploy:
+      resources:
+        limits:
+          cpus: "${VDS_MEMORY_WORKER_CPU_LIMIT:-1.0}"
+          memory: "${VDS_MEMORY_WORKER_MEM_LIMIT:-1g}"
+        reservations:
+          cpus: "${VDS_MEMORY_WORKER_CPU_RESERVE:-0.25}"
+          memory: "${VDS_MEMORY_WORKER_MEM_RESERVE:-128m}"
+    networks:
+      - vds
+    restart: unless-stopped
+    logging: *logging-default
+    healthcheck:
+      # Worker has no HTTP endpoint; use Celery ping instead of the
+      # image's default `curl /health` (which is for memory-api).
+      test: ["CMD-SHELL", "/opt/venv/bin/celery -A vds_memory_orchestrator.service.services.memory_evolution.celery_entrypoint:celery_app inspect ping -t 5 || exit 1"]
+      interval: 30s
+      timeout: 10s
+      start_period: 30s
+      retries: 3
+    command:
+      - /opt/venv/bin/celery
+      - -A
+      - vds_memory_orchestrator.service.services.memory_evolution.celery_entrypoint:celery_app
+      - worker
+      - --loglevel=info
+      - --concurrency
+      - "${CELERY_WORKER_CONCURRENCY:-4}"
+
+  # ---------------------------------------------------------------------------
+  # Multi-Agent Orchestrator Service (FastAPI; long-running)
+  # ---------------------------------------------------------------------------
+  multi-agent-orchestrator:
+    profiles: ["multi-agent", "full"]
+    env_file: *env_files
+    build:
+      context: ../
+      dockerfile: multi_agent_orchestrator/Dockerfile
+    image: vds-multi-agent:${VERSION:-1.0.0}
+    container_name: vds-multi-agent-orchestrator
+    depends_on:
+      redis:
+        condition: service_healthy
+    environment:
+      # Multi-agent uses Redis DB 6 (FR-3 allocation)
+      REDIS_URL: redis://redis:6379/6
+      REDIS_HOST: redis
+      REDIS_PORT: 6379
+      REDIS_DB: 6
+
+      # Memory service backfill (allows multi-agent to discover memory-api)
+      VDS_AI_MEMORY_BASE_URL: ${VDS_AI_MEMORY_BASE_URL:-http://memory-api:8000}
+    ports:
+      - "${MULTI_AGENT_PORT:-8003}:8080"
+    deploy:
+      resources:
+        limits:
+          cpus: "${VDS_MULTI_AGENT_CPU_LIMIT:-1.0}"
+          memory: "${VDS_MULTI_AGENT_MEM_LIMIT:-512m}"
+        reservations:
+          cpus: "${VDS_MULTI_AGENT_CPU_RESERVE:-0.25}"
+          memory: "${VDS_MULTI_AGENT_MEM_RESERVE:-128m}"
+    networks:
+      - vds
+    restart: unless-stopped
+    logging: *logging-default
+
+  # ---------------------------------------------------------------------------
+  # Scheduler Orchestrator Service (DBOS-managed FastAPI; long-running)
+  # ---------------------------------------------------------------------------
+  scheduler-orchestrator:
+    profiles: ["scheduler", "full"]
+    env_file: *env_files
+    build:
+      context: ../
+      dockerfile: scheduler_orchestrator/Dockerfile
+    image: vds-scheduler:${VERSION:-1.0.0}
+    container_name: vds-scheduler-orchestrator
+    # Phase 217 (ADR-79): added memory-api depends_on so scheduler waits for
+    # the HTTP target to be healthy before starting (prevents first-tick 503s).
+    depends_on:
+      postgres:
+        condition: service_healthy
+      redis:
+        condition: service_healthy
+      pgbouncer:
+        condition: service_healthy
+      memory-api:
+        condition: service_healthy
+    # env_file. The `environment:` block ONLY overrides the hostname portion of
+    # DSNs (the env_file uses `localhost` which resolves from host-side
+    # uvicorn/CLI; inside the container we need Docker-DNS `postgres`/`redis`).
+    # Everything else (passwords, ports, kill switch, app version) is sourced
+    # exclusively from ~/.vds/.env.
+    environment:
+      DATABASE_URL: postgresql://postgres:${VDS_POSTGRES_PASSWORD}@vds-pgbouncer:6432/vds_sched
+      MIGRATION_DATABASE_URL: postgresql://postgres:${VDS_POSTGRES_PASSWORD}@vds-pgbouncer:6432/vds_sched
+      REDIS_URL: redis://redis:6379/8
+      # Phase 217 (ADR-79): scheduler workflows now POST to memory-api via
+      # httpx (no more memory_orchestrator import). VDS_MEMORY_API_URL is the
+      # base URL the workflows hit; VDS_SCHEDULER_SERVICE_TOKEN is the
+      # service-account JWT that the workflows pass as Authorization: Bearer
+      # against memory-api's auth-gated /api/v1/maintenance/* endpoints.
+      # Phase 213 SERVICE_NAME/SERVICE_ENVIRONMENT/REDIS_HOST/MCP/POSTGRES_*
+      # env vars REMOVED — they were only needed when memory_orchestrator's
+      # Config() ran at scheduler import time. With Phase 217 HTTP refactor,
+      # the scheduler no longer imports memory_orchestrator at all.
+      # Hardcoded — must point at Docker DNS (`memory-api:8000`), not the
+      # host-side `localhost:8010` that ~/.vds/.env defines for operator CLI.
+      # Same pattern as POSTGRES_HOST=postgres override in pre-Phase-217 setup.
+      VDS_MEMORY_API_URL: http://memory-api:8000
+      VDS_SCHEDULER_SERVICE_TOKEN: ${VDS_SCHEDULER_SERVICE_TOKEN:-}
+    ports:
+      - "${SCHEDULER_PORT:-8005}:8005"
+    volumes:
+      # H4 fix (v2.15.18): EcosystemReportConfig.resolved_report_dir resolves to
+      # /opt/reports/ecosystem inside the container (monorepo_root falls back to
+      # /opt when the .git marker is absent). /opt is root-owned and not writable
+      # by the scheduler user (uid=999). A named volume mounted at /opt/reports
+      # provides a writable, persistent surface for daily report files.
+      - vds_scheduler_reports:/opt/reports
+    deploy:
+      resources:
+        limits:
+          cpus: "${VDS_SCHEDULER_CPU_LIMIT:-1.0}"
+          memory: "${VDS_SCHEDULER_MEM_LIMIT:-512m}"
+        reservations:
+          cpus: "${VDS_SCHEDULER_CPU_RESERVE:-0.25}"
+          memory: "${VDS_SCHEDULER_MEM_RESERVE:-128m}"
+    networks:
+      - vds
+    restart: unless-stopped
+    logging: *logging-default
+    # v2.0.17 N.53: healthcheck directive — without this, `docker compose up -d`
+    # returns Started while the entrypoint is still running alembic upgrade +
+    # DBOS launch. start_period gives 60s for the entrypoint sequence to complete
+    # before health probes start counting against retry budget.
+    healthcheck:
+      test: ["CMD", "curl", "-f", "http://localhost:8005/health"]
+      interval: 30s
+      timeout: 10s
+      start_period: 60s
+      retries: 3
+
+  # ---------------------------------------------------------------------------
+  # Phase 200 ADR-63: opt-in maintenance profile; activate via COMPOSE_PROFILES=maintenance docker compose up memory-maintenance
+  # ---------------------------------------------------------------------------
+  memory-maintenance:
+    profiles: ["maintenance"]
+    env_file: *env_files
+    image: vds-memory:${VERSION:-1.0.0}
+    container_name: vds-memory-maintenance
+    depends_on:
+      postgres:
+        condition: service_healthy
+    environment:
+      # Memory schema DSN (same interpolation pattern as memory-api)
+      DATABASE_URL: postgresql+psycopg://postgres:${VDS_POSTGRES_PASSWORD:-vds_postgres_secret}@vds-pgbouncer:6432/vds_memory
+
+      # PostgreSQL connection — sourced from ~/.vds/.env via env_file; defaults
+      # match the shared `vds-postgres` service per ADR-INF-10.
+      # P8 v2.15.4: routes through vds-pgbouncer:6432 (session-mode) per ADR-INF-13.
+      # POSTGRES_DB is the PgBouncer stanza name (vds_memory), NOT the underlying
+      # database (which IS vds_platform; the stanza maps to it transparently).
+      POSTGRES_HOST: ${POSTGRES_HOST:-vds-pgbouncer}
+      POSTGRES_PORT: ${POSTGRES_PORT:-6432}
+      POSTGRES_USER: ${POSTGRES_USER:-postgres}
+      POSTGRES_PASSWORD: ${VDS_POSTGRES_PASSWORD:-vds_postgres_secret}
+      POSTGRES_DB: ${POSTGRES_DB:-vds_memory}
+
+      # Service config — required by memory_orchestrator config validator
+      SERVICE_NAME: "VDS AI Memory Maintenance"
+      SERVICE_ENVIRONMENT: ${SERVICE_ENVIRONMENT:-development}
+      SERVICE_JWT_SECRET_KEY: ${SERVICE_JWT_SECRET_KEY:?required — set in ~/.vds/.env (generate with `openssl rand -hex 32`)}
+      MCP_ENABLE_MCP_SERVER: ${MCP_ENABLE_MCP_SERVER:-false}
+    deploy:
+      resources:
+        limits:
+          cpus: "${VDS_MAINTENANCE_CPU_LIMIT:-0.5}"
+          memory: "${VDS_MAINTENANCE_MEM_LIMIT:-256m}"
+    networks:
+      - vds
+    restart: "no"
+    logging: *logging-default
+    command:
+      - /opt/venv/bin/python
+      - -m
+      - vds_memory_orchestrator.cli
+      - entity-backfill
+      - --confirm
+      - --limit
+      - "100"
+
+# =============================================================================
+# Volumes (Tier 2 only — CLI-specific volumes live in docker-compose.cli.yml)
+# =============================================================================
+volumes:
+  memory_logs:
+    name: vds-memory-logs
+  vds_scheduler_reports:
+    name: vds-scheduler-reports

package/skills/vds-skill/vds-scripts/docker/infrastructure/init-schemas.sql

@@ -0,0 +1,177 @@
+-- =============================================================================
+-- VDS Shared Infrastructure — Schema Initialization
+-- =============================================================================
+-- Phase: ecosystem-infrastructure-evolution P0
+-- Created: 2026-04-25
+--
+-- This script creates schemas and roles for all VDS orchestrators.
+-- It is idempotent — safe to run multiple times.
+--
+-- Schemas:
+--   - audit_state: audit_orchestrator (LangGraph checkpoints + audit state)
+--   - memory: memory_orchestrator (mem0, evolution, analytics)
+--   - sched: scheduler_orchestrator (DBOS schedules, events, chains)
+--   - progress: progress_report_orchestrator (report state)
+--   - dbos: scheduler_orchestrator (DBOS system tables)
+-- =============================================================================
+
+-- =============================================================================
+-- OWNERSHIP BOUNDARY (per ADR-INF-11, P4 v2.11.1)
+-- =============================================================================
+-- This file owns: schemas + roles + DBOS CREATE grant ONLY.
+-- This file does NOT own: tables, indexes, functions, views, ENUMs, etc.
+--
+-- Per-service tables are owned by per-service Alembic environments:
+--   - audit_state.* tables  -> audit_orchestrator/alembic/versions/
+--   - memory.* tables       -> memory_orchestrator/alembic/versions/
+--   - sched.* tables        -> scheduler_orchestrator/alembic/versions/
+--   - progress.* tables     -> progress_report_orchestrator/alembic/versions/
+--   - dbos.* tables         -> DBOS framework (system tables; CREATE granted to vds_sched_runtime)
+--
+-- This script runs ONCE at postgres container init (Docker entrypoint
+-- /docker-entrypoint-initdb.d/01-schemas.sql); it does NOT re-run on
+-- subsequent container restarts. Schema/role changes require a fresh
+-- volume init (rare; coordinate with operator).
+--
+-- Adding tables here would create a divergent source-of-truth from the
+-- per-service Alembic envs. DO NOT add CREATE TABLE statements to this file.
+-- =============================================================================
+
+-- v2.0.17 N.55: pre-install uuid-ossp extension so DBOS bootstrap (which issues
+-- `CREATE EXTENSION IF NOT EXISTS "uuid-ossp"` at first launch) does NOT require
+-- SUPERUSER privileges on every fresh container start. Pre-installing here lets
+-- the future v2.0.18 least-privilege DSN switch (vds_sched_runtime) work; today
+-- DBOS bootstrap runs as `postgres` superuser so `CREATE EXTENSION` succeeds
+-- regardless, but pre-installing makes the privilege contract explicit and
+-- forward-compatible.
+CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
+
+-- Create schemas
+CREATE SCHEMA IF NOT EXISTS audit_state;
+CREATE SCHEMA IF NOT EXISTS memory;
+CREATE SCHEMA IF NOT EXISTS sched;
+CREATE SCHEMA IF NOT EXISTS progress;
+CREATE SCHEMA IF NOT EXISTS dbos;
+
+-- Create roles (passwords are set via environment variables at runtime)
+-- Note: In production, passwords should be managed via Docker secrets or vault
+
+-- Role: audit_orchestrator application user
+DO $$
+BEGIN
+    CREATE ROLE vds_audit_app WITH LOGIN;
+EXCEPTION
+    WHEN duplicate_object THEN NULL;
+END
+$$;
+
+-- Role: memory_orchestrator application user
+DO $$
+BEGIN
+    CREATE ROLE vds_memory_app WITH LOGIN;
+EXCEPTION
+    WHEN duplicate_object THEN NULL;
+END
+$$;
+
+-- Role: scheduler_orchestrator application user
+DO $$
+BEGIN
+    CREATE ROLE vds_scheduler_app WITH LOGIN;
+EXCEPTION
+    WHEN duplicate_object THEN NULL;
+END
+$$;
+
+-- Role: DBOS scheduler runtime user
+DO $$
+BEGIN
+    CREATE ROLE vds_sched_runtime WITH LOGIN;
+EXCEPTION
+    WHEN duplicate_object THEN NULL;
+END
+$$;
+
+-- Role: progress_report_orchestrator application user
+DO $$
+BEGIN
+    CREATE ROLE vds_progress_app WITH LOGIN;
+EXCEPTION
+    WHEN duplicate_object THEN NULL;
+END
+$$;
+
+-- v2.0.17 N.52: Role passwords for least-privilege DSN switch.
+-- Without these ALTER ROLE statements, the roles exist with LOGIN but no
+-- password — peer/trust auth via `docker exec psql -U <role>` works, but
+-- TCP connections from other containers (the canonical deployment path)
+-- fail with "password authentication failed". The passwords below are
+-- DEFAULT DEV PASSWORDS for the local shared-infra bring-up. Operators MUST
+-- rotate them via a separate post-init step in production:
+--
+--   docker exec vds-postgres psql -U postgres -c \
+--     "ALTER ROLE vds_scheduler_app WITH PASSWORD '<production-secret>';"
+--
+-- and update the compose DATABASE_URL accordingly. The ecosystem-scheduling
+-- spec (TSK-N.52 carryover) tracks the cross-orchestrator coordination
+-- needed to migrate the canonical DSN from `postgres` superuser to
+-- least-privilege role for all 4 schema owners.
+ALTER ROLE vds_audit_app     WITH PASSWORD 'dev_audit_pw';
+ALTER ROLE vds_memory_app    WITH PASSWORD 'dev_memory_pw';
+ALTER ROLE vds_scheduler_app WITH PASSWORD 'dev_scheduler_app_pw';
+ALTER ROLE vds_sched_runtime WITH PASSWORD 'dev_sched_runtime_pw';
+ALTER ROLE vds_progress_app  WITH PASSWORD 'dev_progress_pw';
+
+-- v2.0.17 N.52: vds_sched_runtime needs database-level CREATE for DBOS
+-- bootstrap (DBOS issues `CREATE SCHEMA "dbos"` without IF NOT EXISTS, which
+-- requires db-level CREATE even when the schema already exists).
+GRANT CREATE ON DATABASE vds_platform TO vds_sched_runtime;
+
+-- Grant schema usage
+GRANT USAGE ON SCHEMA audit_state TO vds_audit_app;
+GRANT USAGE ON SCHEMA memory TO vds_memory_app;
+GRANT USAGE ON SCHEMA sched TO vds_scheduler_app, vds_sched_runtime;
+GRANT USAGE ON SCHEMA progress TO vds_progress_app;
+GRANT USAGE ON SCHEMA dbos TO vds_sched_runtime;
+
+-- Grant CREATE privilege on dbos schema for DBOS system tables
+GRANT USAGE, CREATE ON SCHEMA dbos TO vds_sched_runtime;
+
+-- Grant ALL privileges on each schema to its owner role
+GRANT ALL PRIVILEGES ON SCHEMA audit_state TO vds_audit_app;
+GRANT ALL PRIVILEGES ON SCHEMA memory TO vds_memory_app;
+GRANT ALL PRIVILEGES ON SCHEMA sched TO vds_scheduler_app, vds_sched_runtime;
+GRANT ALL PRIVILEGES ON SCHEMA progress TO vds_progress_app;
+GRANT ALL PRIVILEGES ON SCHEMA dbos TO vds_sched_runtime;
+
+-- Default privileges so future tables are auto-granted
+ALTER DEFAULT PRIVILEGES IN SCHEMA audit_state GRANT ALL ON TABLES TO vds_audit_app;
+ALTER DEFAULT PRIVILEGES IN SCHEMA audit_state GRANT ALL ON SEQUENCES TO vds_audit_app;
+ALTER DEFAULT PRIVILEGES IN SCHEMA memory GRANT ALL ON TABLES TO vds_memory_app;
+ALTER DEFAULT PRIVILEGES IN SCHEMA memory GRANT ALL ON SEQUENCES TO vds_memory_app;
+ALTER DEFAULT PRIVILEGES IN SCHEMA sched GRANT ALL ON TABLES TO vds_scheduler_app, vds_sched_runtime;
+ALTER DEFAULT PRIVILEGES IN SCHEMA sched GRANT ALL ON SEQUENCES TO vds_scheduler_app, vds_sched_runtime;
+ALTER DEFAULT PRIVILEGES IN SCHEMA progress GRANT ALL ON TABLES TO vds_progress_app;
+ALTER DEFAULT PRIVILEGES IN SCHEMA progress GRANT ALL ON SEQUENCES TO vds_progress_app;
+
+-- Note: dbos schema uses USAGE, CREATE (not ALL) since DBOS manages its own objects
+
+-- =============================================================================
+-- v2.15.9 (P8 follow-up F20 close): no database-level search_path override
+-- =============================================================================
+-- Pre-P8, this database had `search_path = 'memory, public'` set at the database
+-- level (a P0-leftover from when vds_platform was the memory-only DB). Post-P8,
+-- search_path pinning happens in two places:
+--   1. PgBouncer per-stanza `connect_query='SET search_path TO <schema>, public'`
+--      (fires on backend SPAWN — see docker/infrastructure/pgbouncer/pgbouncer.ini)
+--   2. Per-application connect-time SQL (SQLAlchemy `connect` event listener,
+--      psycopg helper wrapper) for unqualified-DML resilience across PgBouncer
+--      backend reuse — see references/connection-pooling.md F21/D1 caveats
+--
+-- A database-level default would silently override the per-stanza connect_query
+-- value after `server_reset_query=DISCARD ALL` resets session state between
+-- client checkouts in session mode (originally caught as F20 in v2.15.6 audit).
+-- This RESET ensures fresh deploys never regress to the legacy default. The
+-- statement is a no-op when search_path is already unset, so it's safe to
+-- run on every fresh init.
+ALTER DATABASE vds_platform RESET search_path;

package/skills/vds-skill/vds-scripts/docker/infrastructure/pgbouncer/pgbouncer.ini

@@ -0,0 +1,75 @@
+; =============================================================================
+; VDS PgBouncer config — SESSION-mode pooling, per-database stanzas
+; ADR-INF-13 / FR-15 / ecosystem-infrastructure-evolution P8 (v2.15.3)
+; Pinned: edoburu/pgbouncer >= v1.24 (image v1.25.1-p0)
+;
+; Session mode (1:1 client:backend) preserves correctness for:
+;   - DBOS LISTEN/NOTIFY (scheduler_orchestrator event bus, dispatcher loop,
+;     chains, WS streams)
+;   - audit_orchestrator session-scoped advisory locks
+;     (state/store.py:5265,5279 — corpus-refresh coordination)
+;   - asyncpg full statement_cache_size=512 (memory_orchestrator)
+;   - WITH HOLD cursors, temp tables, application_name, query cancel
+;   - alembic pg_try_advisory_xact_lock (tx-scoped is a strict subset of
+;     what session mode permits)
+;
+; Future R12 escalation: per-stanza `pool_mode=transaction` override on
+; memory/progress stanzas if 90-day SHOW POOLS shows sustained cl_waiting>0.
+; Audit and sched stay session-mode permanently.
+; =============================================================================
+
+[databases]
+; One stanza per VDS schema. `connect_query` runs ONCE per backend connection
+; at startup, pinning search_path before the pool hands the backend to a client.
+; (`options=` is NOT a valid per-stanza key in PgBouncer 1.24+; use `connect_query`.)
+vds_audit    = host=vds-postgres port=5432 dbname=vds_platform connect_query='SET search_path TO audit_state, public' pool_size=40
+vds_memory   = host=vds-postgres port=5432 dbname=vds_platform connect_query='SET search_path TO memory, public' pool_size=40
+vds_progress = host=vds-postgres port=5432 dbname=vds_platform connect_query='SET search_path TO progress, public' pool_size=40
+vds_sched    = host=vds-postgres port=5432 dbname=vds_platform connect_query='SET search_path TO sched, public' pool_size=40
+
+[pgbouncer]
+listen_addr        = 0.0.0.0
+listen_port        = 6432
+auth_type          = scram-sha-256
+auth_file          = /etc/pgbouncer/userlist.txt
+; auth_query runs as auth_user (NOT the connecting client). Without auth_user,
+; PgBouncer attempts pg_shadow lookups using the client's own credentials —
+; works only when client is superuser. Since we may add non-superuser DSNs
+; later, pin auth_user to the dedicated pgbouncer_auth role (created at deploy
+; time per ROLLBACK.md §P8 First-Time Deploy Prerequisites).
+auth_user          = pgbouncer_auth
+auth_query         = SELECT usename, passwd FROM pg_shadow WHERE usename=$1
+; FR-224.7 hardening: pin auth_query to a real DB. Without this, pgbouncer
+; 1.18+ uses the *connecting* db as auth_dbname; when a client connects to
+; the special `pgbouncer` admin DB (e.g. the healthcheck's `psql -d pgbouncer`),
+; the lookup fails with "cannot use the reserved 'pgbouncer' database as an
+; auth_dbname". `vds_memory` is one of the 4 stanzas defined above and routes
+; to the underlying vds_platform DB where pg_shadow lives.
+auth_dbname        = vds_memory
+admin_users        = pgbouncer_admin
+stats_users        = pgbouncer_stats
+pool_mode          = session
+max_client_conn    = 500
+default_pool_size  = 40
+min_pool_size      = 5
+max_prepared_statements = 200
+server_reset_query = DISCARD ALL
+server_reset_query_always = 0
+server_idle_timeout = 600
+server_lifetime    = 3600
+; v2.15.12: trimmed to `extra_float_digits` only (Postgres standard parameter
+; many drivers send by default — not legacy compat).
+;   - `options` was added pre-P8 for clients sending DSN-URL `?options=-c
+;     search_path=...` query fragments. v2.15.x retired URL-options in favor
+;     of per-stanza `connect_query` pinning + per-app post-handshake SET.
+;     No active code sends `options` as a startup parameter post-v2.15.10.
+;   - `search_path` was added in v2.15.8 first-attempt fix when memory-api
+;     used asyncpg `server_settings={"search_path": ...}` (StartupMessage
+;     route). v2.15.8 robust fix replaced that with SQLAlchemy `connect`
+;     event listener (post-handshake SET). The allowlist entry was retained
+;     "in case other libraries use it" — removed v2.15.12 per no-legacy
+;     directive. Verified zero `unsupported startup parameter` rejections
+;     in PgBouncer logs pre-removal.
+ignore_startup_parameters = extra_float_digits
+log_pooler_errors  = 1
+stats_period       = 60