@ngocsangairvds/vsaf 4.1.8 → 4.1.9

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

@@ -1,425 +0,0 @@
-# =============================================================================
-# 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

@@ -1,177 +0,0 @@
--- =============================================================================
--- 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

@@ -1,75 +0,0 @@
-; =============================================================================
-; 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