@ngocsangairvds/vsaf 4.1.7 → 4.1.9

package/skills/vds-skill/vds-scripts/docs/evolution-loop-integration-guide.md

@@ -1,359 +0,0 @@
-# VDS Evolution Loop: Integration Guide
-
-> **Canonical Spec:** [.gpt-5.4/specs/who-ecosystem-evolution-loop/SPEC.md](../.gpt-5.4/specs/who-ecosystem-evolution-loop/SPEC.md)
-
-## Overview
-
-The VDS Evolution Loop is an automated system for evolving VDS skills based on real execution data from OpenSpace. It integrates with OpenSpace's MCP tools and SQLite store to:
-
-1. **Load** evolution candidates from execution analyses
-2. **Evaluate** them through a three-gate pipeline
-3. **Sign** verdicts with HMAC for integrity
-4. **Promote** approved skills automatically or manually
-
-## Architecture
-
-```
-┌─────────────────────────────────────────────────────────────────────┐
-│                        Evolution Loop                                │
-├─────────────────────────────────────────────────────────────────────┤
-│  OpenSpace Store (.openspace/openspace.db)                          │
-│    ├── execution_analyses (candidates)                              │
-│    ├── skill_judgments                                              │
-│    └── evolution_suggestions                                        │
-└─────────────────────────────────────────────────────────────────────┘
-                              │
-                              ▼
-┌─────────────────────────────────────────────────────────────────────┐
-│  OpenSpaceClient (openspace_integration.py)                         │
-│    ├── MCP tools: execute_task, search_skills, fix_skill            │
-│    ├── Transport: stdio, SSE, streamable-http                       │
-│    └── Store access: load_evolution_candidates, stats               │
-└─────────────────────────────────────────────────────────────────────┘
-                              │
-                              ▼
-┌─────────────────────────────────────────────────────────────────────┐
-│  Router (router.py) → Three-Gate Pipeline                            │
-│    ├── Gate 1 (structural): Queue depth, budget check              │
-│    ├── Gate 2 (behavioral): Regression test, pattern analysis    │
-│    └── Gate 3 (semantic): Claude quality assessment                │
-└─────────────────────────────────────────────────────────────────────┘
-                              │
-                              ▼
-┌─────────────────────────────────────────────────────────────────────┐
-│  Verdict (models.py, router.py)                                      │
-│    ├── mechanism: "fix" | "derived" | "captured"                    │
-│    ├── final_eligibility: "eligible" | "ineligible"                │
-│    └── state: pending → promoted | rejected | needs-review         │
-└─────────────────────────────────────────────────────────────────────┘
-                              │
-                              ▼
-┌─────────────────────────────────────────────────────────────────────┐
-│  Phase 3+ Infrastructure                                             │
-│    ├── HMAC Binding: Verdict integrity signatures                  │
-│    ├── Ensemble Judge: Multi-judge consensus                      │
-│    └── Auto-Promote: Daemon for automatic promotion               │
-└─────────────────────────────────────────────────────────────────────┘
-```
-
-## Module Inventory
-
-### Core Modules
-
-| Module | Purpose | Key Classes/Functions |
-|--------|---------|----------------------|
-| `openspace_integration.py` | MCP client & store access | `OpenSpaceClient`, `ExecutionAnalysis`, `OpenSpaceStats` |
-| `router.py` | Gate pipeline orchestration | `route()`, `route_sync()` |
-| `models.py` | Data models | `Verdict`, `ExecutionAnalysis`, `VerdictSchema` |
-| `switch.py` | Kill switch & store | `KillSwitch`, `get_store()` |
-
-### Gate Modules
-
-| Module | Gate | Purpose |
-|--------|------|---------|
-| `gates/structural.py` | Gate 1 | Queue depth, budget cap check |
-| `gates/behavioral.py` | Gate 2 | Regression test, pattern analysis |
-| `gates/semantic.py` | Gate 3 | Claude quality assessment |
-| `gates/ensemble_judge.py` | Ensemble | Three-judge consensus |
-
-### Phase 3+ Modules
-
-| Module | Purpose |
-|--------|---------|
-| `auto_promote.py` | Automatic verdict promotion daemon |
-| `hmac_binding.py` | HMAC-SHA256 verdict signatures |
-| `gates/ensemble_judge.py` | Multi-judge evaluation |
-
-### Supporting Modules
-
-| Module | Purpose |
-|--------|---------|
-| `promote.py` | Git branch creation & PR workflow |
-| `verdict.py` | Verdict persistence |
-| `reconciler.py` | Skill registry reconciliation |
-| `shadow.py` | Canonical-to-shadow sync |
-| `audit.py` | Audit log writer |
-
-## Data Flow
-
-### 1. Candidate Loading
-
-```python
-from vds_evolution.openspace_integration import OpenSpaceClient
-
-client = OpenSpaceClient()
-candidates = client.load_evolution_candidates(limit=50)
-```
-
-**SQL:**
-```sql
-SELECT ea.*, sj.skill_id, sj.skill_applied, sj.note
-FROM execution_analyses ea
-LEFT JOIN skill_judgments sj ON ea.task_id = sj.task_id
-WHERE ea.evolution_suggestions IS NOT NULL
-  AND ea.evolution_processed_at IS NULL
-ORDER BY ea.timestamp DESC
-LIMIT :limit
-```
-
-### 2. Gate Pipeline
-
-```python
-from vds_evolution.router import route_sync
-from vds_evolution.models import ExecutionAnalysis
-
-# Create execution analysis from candidate
-analysis = ExecutionAnalysis(
-    task_id=candidate.task_id,
-    timestamp=candidate.timestamp,
-    evolution_suggestions=candidate.evolution_suggestions,
-    ...
-)
-
-# Run through gates
-verdict = await route_sync(analysis, kill_switch)
-```
-
-**Flow:**
-```
-Candidate → Gate1 (structural)
-              ├─ Pass: → Gate2 (behavioral)
-              │          ├─ Pass: → Gate3 (semantic)
-              │          │          ├─ Pass: eligible
-              │          │          └─ Fail: ineligible
-              │          └─ Fail: ineligible
-              └─ Fail: ineligible
-```
-
-### 3. Verdict Signing (Phase 3+)
-
-```python
-from vds_evolution.hmac_binding import sign_and_attach, verify_and_detach
-
-# Sign verdict before promotion
-signed_verdict = sign_and_attach(verdict.to_dict())
-
-# Verify before promotion
-verified = verify_and_detach(signed_verdict)
-if not verified.valid:
-    raise ValueError(f"Invalid signature: {verified.error}")
-```
-
-### 4. Auto-Promote
-
-```bash
-# Start daemon
-vds-cli evolution auto-promote --poll-interval 60 --dry-run
-
-# Or in Python
-from vds_evolution.auto_promote import AutoPromoteDaemon, AutoPromoteConfig
-
-config = AutoPromoteConfig(poll_interval=60.0, dry_run=True)
-daemon = AutoPromoteDaemon(config)
-await daemon.run()
-```
-
-### 5. Ensemble Judge
-
-```bash
-# Run three-judge evaluation
-vds-cli evolution ensemble-judge path/to/SKILL.md --strategy unanimous
-```
-
-**Strategies:**
-- `unanimous`: All judges must agree
-- `majority`: 2/3 agreement
-- `any_pass`: At least one approves
-- `advisory`: Follow primary judge
-
-## Configuration
-
-### Environment Variables
-
-| Variable | Default | Purpose |
-|----------|---------|---------|
-| `OPENSPACE_WORKSPACE` | Project root | OpenSpace workspace directory |
-| `OPENSPACE_HOST_SKILL_DIRS` | Canonical skills | Skill directories to monitor |
-| `OPENSPACE_TRANSPORT` | `stdio` | MCP transport (stdio/sse/streamable-http) |
-| `OPENSPACE_AUTONOMOUS_ENABLED` | `false` | Enable auto-promote daemon |
-| `OPENSPACE_MCP_HOST` | `localhost` | MCP server host |
-| `OPENSPACE_MCP_PORT` | `8080` | MCP server port |
-
-### Kill Switch
-
-```python
-from vds_evolution.switch import KillSwitch
-
-kill_switch = KillSwitch()
-if not kill_switch.is_enabled():
-    print("Evolution loop disabled by kill switch")
-```
-
-## CLI Commands
-
-| Command | Description |
-|---------|-------------|
-| `vds-cli evolution status` | Show kill-switch state, queue depth |
-| `vds-cli evolution list` | List verdicts |
-| `vds-cli evolution route SKILL.md` | Run gate pipeline on skill |
-| `vds-cli evolution promote ID` | Promote verdict to master |
-| `vds-cli evolution auto-promote` | Run auto-promote daemon |
-| `vds-cli evolution ensemble-judge` | Run three-judge evaluation |
-| `vds-cli evolution sign-verdict` | HMAC sign verdict |
-| `vds-cli evolution verify-verdict` | Verify HMAC signature |
-| `vds-cli evolution openspace-doctor` | Run OpenSpace readiness checks |
-| `vds-cli evolution openspace-sync-shadow` | Sync canonical to shadow |
-
-## Testing
-
-```bash
-# Run all tests
-./.venv/bin/python -m pytest vds_evolution/tests/
-
-# Run specific test file
-./.venv/bin/python -m pytest vds_evolution/tests/unit/test_router.py
-
-# Run with coverage
-./.venv/bin/python -m pytest --cov=vds_evolution vds_evolution/tests/
-```
-
-## MCP Transport Selection
-
-The system supports three MCP transports:
-
-### stdio (default)
-```bash
-# Direct subprocess invocation
-openspace-mcp --transport stdio
-```
-
-### SSE
-```bash
-OPENSPACE_TRANSPORT=sse vds-cli evolution ...
-# Targets: http://localhost:8080/sse
-```
-
-### streamable-http
-```bash
-OPENSPACE_TRANSPORT=streamable-http vds-cli evolution ...
-# Targets: http://localhost:8080/mcp
-```
-
-## Security
-
-### HMAC Signature
-
-Verdicts are signed with HMAC-SHA256 to ensure integrity:
-
-```python
-import hashlib
-import hmac
-
-def sign_verdict(verdict: dict) -> HmacSignature:
-    payload_hash = hashlib.sha256(
-        json.dumps(verdict, sort_keys=True).encode()
-    ).hexdigest()
-    
-    signature = hmac.new(
-        key=secret_key,
-        msg=payload_hash.encode(),
-        digestmod=hashlib.sha256
-    ).hexdigest()
-    
-    return HmacSignature(signature=signature, payload_hash=payload_hash, ...)
-```
-
-### Key Rotation
-
-```python
-from vds_evolution.hmac_binding import sign_with_key_id
-
-# Sign with specific key
-sig = sign_with_key_id(verdict, key_id="key-v2")
-```
-
-## Troubleshooting
-
-### OpenSpace Not Found
-
-```bash
-# Check OpenSpace installation
-vds-cli evolution openspace-doctor
-
-# Common fixes:
-# 1. Install OpenSpace
-pip install openspace-ai
-
-# 2. Set workspace
-export OPENSPACE_WORKSPACE=/path/to/workspace
-
-# 3. Sync shadow skills
-vds-cli evolution openspace-sync-shadow
-```
-
-### MCP Transport Errors
-
-```bash
-# Test stdio transport
-openspace-mcp --help
-
-# Check transport configuration
-OPENSPACE_TRANSPORT=stdio vds-cli evolution status
-
-# Enable debug logging
-OPENSPACE_DEBUG=true vds-cli evolution route SKILL.md
-```
-
-### Verdict Signature Invalid
-
-```bash
-# Verify signature
-vds-cli evolution verify-verdict path/to/verdict.json
-
-# Re-sign if needed
-vds-cli evolution sign-verdict path/to/verdict.json
-```
-
-## Dependencies
-
-### Required
-- Python 3.10+
-- `vds-cli-common` - Shared CLI utilities
-- `anthropic` - Claude API client
-- `httpx` - HTTP transport
-
-### Optional
-- `openspace-ai` - OpenSpace MCP server
-- `pytest` - Testing framework
-- `pytest-asyncio` - Async test support
-
-## Glossary
-
-| Term | Definition |
-|------|------------|
-| **Candidate** | Execution analysis with evolution suggestions |
-| **Verdict** | Gate pipeline result (eligible/ineligible) |
-| **Promotion** | Merging approved changes to master |
-| **HMAC** | Hash-based Message Authentication Code |
-| **Gate** | Quality checkpoint in the pipeline |
-| **Ensemble** | Multi-judge consensus system |

package/skills/vds-skill/vds-scripts/docs/openspace-schema-snapshot.md

@@ -1,73 +0,0 @@
-# OpenSpace SQLite Schema Snapshot
-
-**Generated**: 2026-04-20
-**Source**: `~/.tools/OpenSpace/.openspace/openspace.db`
-**Verification**: `PRAGMA table_info(execution_analyses)`
-
-## Schema Verification (TSK-0.1a Gate)
-
-### execution_analyses Table
-
-| Column | Type | Description |
-|--------|------|-------------|
-| id | INTEGER | Primary key |
-| task_id | TEXT | Task identifier (UNIQUE constraint) |
-| timestamp | TEXT | ISO-8601 timestamp |
-| task_completed | INTEGER | Boolean (0/1) |
-| execution_note | TEXT | Execution notes |
-| tool_issues | TEXT | JSON list of tool issues |
-| **candidate_for_evolution** | INTEGER | Evolution candidate flag (0/1) ✅ |
-| **evolution_processed_at** | TEXT | ISO timestamp when evolution ran ✅ |
-| evolution_suggestions | TEXT | JSON list of EvolutionSuggestion dataclass |
-| analyzed_by | TEXT | Analyzer identity |
-| analyzed_at | TEXT | Analysis timestamp |
-
-### Key Observations
-
-1. **candidate_for_evolution column**: Present ✅ (not `quality_indicator` as incorrectly assumed in v0.5.3)
-2. **evolution_processed_at column**: Present ✅ (added by upstream commit `020a879`)
-3. **evolution_suggestions field**: Uses full name `evolution_suggestions` (not shortened `suggestions`)
-
-### API Contract (Consumed by VDS)
-
-```python
-# Gate 1 consumer API - TSK-1.5
-store.load_evolution_candidates(limit=50, include_processed=False)
-# Returns List[ExecutionAnalysis] where candidate_for_evolution=1 AND evolution_processed_at IS NULL
-
-# Queue depth probe - TSK-1.5, TSK-1.11
-store.get_stats()["unprocessed_evolution_candidates"]
-# Returns int (NOT .n_unprocessed_candidates attribute access)
-
-# Lifecycle marking - handled by openspace/skill_engine/evolver.py:306
-# VDS MUST NOT write evolution_processed_at column
-```
-
-### Upstream Contract References
-
-- `openspace/skill_engine/types.py:26` - EvolutionType enum
-- `openspace/skill_engine/types.py:198` - EvolutionSuggestion dataclass (no `severity` field)
-- `openspace/skill_engine/types.py:253` - ExecutionAnalysis dataclass
-- `openspace/skill_engine/store.py` - SkillStore methods
-
-### Other Tables
-
-| Table | Purpose |
-|-------|---------|
-| skill_records | Canonical skill registry |
-| skill_lineage_parents | Skill parent relationships |
-| skill_judgments | Skill application judgments |
-| skill_tool_deps | Skill tool dependencies |
-| skill_tags | Skill tagging metadata |
-
-## Phase 1 Opening Gate
-
-This artifact is the hard gate for Phase 1 opening per tasks.md:
-
-> "TSK-0.1a is a hard gate for Phase 1 — Gate 1 (TSK-1.5) cannot be built on an unverified schema."
-
-**Verification checklist**:
-- [x] `candidate_for_evolution INTEGER` column exists
-- [x] `evolution_processed_at TEXT` column exists
-- [x] `store.load_evolution_candidates()` returns expected shape
-- [x] `store.get_stats()["unprocessed_evolution_candidates"]` returns int

package/skills/vds-skill/vds-scripts/docs/operations/sla-mttr-policy.md

@@ -1,44 +0,0 @@
-# SLA and MTTR Support Policy
-
-This policy defines response and restoration targets for incidents in the `vds-scripts` platform tooling stack.
-
-## Priority Definitions
-
-| Priority | Description | Example Impact |
-| --- | --- | --- |
-| `P1` | Critical outage | Production automation blocked across teams |
-| `P2` | Major degradation | Key workflow unavailable with partial workaround |
-| `P3` | Minor degradation | Non-critical feature issue with workaround |
-| `P4` | Low impact/request | Cosmetic defects or advisory improvements |
-
-## SLA and MTTR Targets
-
-| Priority | Acknowledge SLA | Mitigation SLA | MTTR Target |
-| --- | --- | --- | --- |
-| `P1` | 15 minutes | 60 minutes | 4 hours |
-| `P2` | 30 minutes | 4 hours | 1 business day |
-| `P3` | 4 business hours | 2 business days | 3 business days |
-| `P4` | 1 business day | Planned backlog | 10 business days |
-
-## Escalation Matrix
-
-1. L1 Operations triages alerts and opens incident ticket with priority.
-2. L2 Platform Engineering joins for root-cause and mitigation.
-3. L3 Service Owner approves hotfix, rollback, or emergency config changes.
-4. P1/P2 incidents require status updates every 30 minutes until mitigated.
-
-## Incident Lifecycle Requirements
-
-1. Detect and classify incident priority (`P1`..`P4`).
-2. Acknowledge within SLA target.
-3. Apply mitigation and recover service.
-4. Confirm restoration against acceptance checks.
-5. Publish incident summary and post-incident actions.
-
-## Tracking and Evidence
-
-- Incident tracker must store:
-  - priority, owner, start time, ack time, restore time
-  - mitigation actions and validation evidence
-  - follow-up tasks for permanent fixes
-- Weekly review reports include SLA compliance and MTTR trend by priority.

package/skills/vds-skill/vds-scripts/docs/p0-closure-evidence/SUMMARY.md

@@ -1,58 +0,0 @@
-# P0 Closure Evidence — Wave B
-
-**Date**: 2026-04-25
-**Branch**: `phase-infra/ecosystem-evolution`
-**Worktree**: `WHO-project/worktrees/vds-scripts-phase-infra`
-
-## Verify Script
-
-`scripts/verify-infra-topology.py --profile infra` — exit 1 (expected; new shared infra not yet started).
-
-**Bug fixed during Wave B**: `VerificationResult.add()` accepted only `**details` keyword args but two call sites passed positional `dict`. Signature now accepts both `details: dict | None` positionally and `**kwargs`. See git diff for `scripts/verify-infra-topology.py`.
-
-**Output**: `docs/p0-closure-evidence/verify-infra-topology.log`. The 16 reported failures are accurate runtime observations — `vds-postgres`, `vds-redis`, `vds-qdrant`, and the named volumes do not currently exist because the legacy stacks (`vds-ai-memory-postgres-1`, `vds-audit-postgres`, `vds-ai-memory-redis-1`) are still occupying ports 5432, 5434, 6380. Bringing up the new infra requires retiring the legacy stacks first — operator decision, not a script defect.
-
-## Pytest Spot-Checks (WP-0.7-touched files)
-
-| Test file | Result | Pre-existing failures? |
-|---|---|---|
-| `audit_orchestrator/tests/test_infra_persistence.py` | 5 ERRORS — `ImportError: No module named 'stamina'` + circular import on `_VDS_CLI_PROJECT_DIR` | **Yes** — pre-existing on master; unrelated to P0 |
-| `multi_agent_orchestrator/tests/test_config.py` | 12 passed, 1 failed (`test_environment_override`: `session_ttl_hours==24 != 48`) | **Yes** — pre-existing Pydantic-v2 `Field(env=...)` drift; same code on master |
-
-**Conclusion**: No P0-introduced regressions in the spot-check sample. Both observed failures are pre-existing and tracked separately (not P0 spec scope).
-
-## FR-10 Confirmation
-
-`WHO-project/vds-skills/skills/infrastructure-evolution-skill/SKILL.md` exists at v1.0.0 (217 lines). FR-10 is satisfied. Sync to AGENTS.md catalogs is part of P3 / Wave F.
-
-## Pg_dump Snapshot (TSK-0.1.5) — Status
-
-The breaking migration intent (drop legacy `vds_audit_checkpoints` and `vds_memory` databases) has not yet executed in this environment — the legacy containers are still up. Pg_dump snapshots remain a pre-merge requirement when the operator schedules the migration cutover. Documented in `docker/ROLLBACK.md`. Not blocking spec consolidation.
-
-## Verdict
-
-P0 closure-gate evidence is complete enough to support the merge gate decision:
-
-- `verify-infra-topology.py` is functional (1 bug fixed during this wave)
-- `pytest` no-regression confirmed for P0-touched test files
-- FR-10 skill exists
-- pg_dump snapshot remains a pre-cutover operator step
-
----
-
-## Post-Merge Addendum (2026-04-25, spec v2.10.3)
-
-This file is the **pre-merge** snapshot from Wave B. Current state on master:
-
-- **Branch**: `phase-infra/ecosystem-evolution` was merged; worktree `vds-scripts-phase-infra` retired.
-- **Master HEAD**: `417306b3 test(verify): align scripts with post-ADR-INF-10 infra (vds-platform / port 8010 / new container names)`.
-- **Verify script**: now profile-aware per ADR-INF-10 (commit `8dc7f1c8`); CLI profiles (audit/pdf/progress/db-query) only assert infra-up since CLI containers exit 0 by design.
-- **Pg_dump snapshots**: executed during the cutover and are present in `docker/backups/`:
-  - `pre-p0-audit.dump` (2.9 GB)
-  - `pre-p0-memory.dump` (11.3 MB)
-  - `pre-p0-progress.dump` (52 KB)
-  - `pre-p0-scheduler.dump` (5.1 MB)
-  - Restore drill verified in `docker/MIGRATION.md` Step 7 (commit `dea8eea0`); rollback recipe in `docker/ROLLBACK.md` (WP-0.7.2).
-- **FR-10 skill**: bumped to **v1.4.0** in `WHO-project/vds-skills/skills/infrastructure-evolution-skill/SKILL.md` (Three-tier compose Quick Start; `up-*` for Tier 2 long-running, `run-* ARGS=...` for Tier 3 CLI). Registered in `WHO-project/vds-skills/registry.yaml`.
-- **AGENTS sync**: `WHO-project/vds-scripts/AGENTS.md` line 68 has the Containerization Policy table (Host-only / Container-eligible / Hybrid).
-- **Legacy ports**: `rg "5434|6380"` returns zero matches outside `docs/legacy/` and `docs/memory-archive/` (cross-surface alignment audit, v2.10.2).

package/skills/vds-skill/vds-scripts/docs/p4-closure-evidence/smoke-20260427T024137Z-b95b586b.json

@@ -1,15 +0,0 @@
-{
-  "passed": false,
-  "git_sha": "b95b586b",
-  "timestamp": "20260427T024137Z",
-  "target": "live",
-  "steps": [
-    {
-      "command": "make build-cli",
-      "exit_code": 2,
-      "duration_s": 246.527,
-      "stdout": ".12-2 [17.1 kB]\n85.63 Get:39 http://deb.debian.org/debian trixie/main arm64 unixodbc-common all 2.3.12-2 [8640 B]\n85.68 Get:40 http://deb.debian.org/debian trixie/main arm64 libodbcinst2 arm64 2.3.12-2 [36.8 kB]\n85.75 Get:41 http://deb.debian.org/debian trixie/main arm64 libpq5 arm64 17.9-0+deb13u1 [222 kB]\n86.24 Get:42 http://deb.debian.org/debian-security trixie-security/main arm64 libssl-dev arm64 3.5.5-1~deb13u2 [3388 kB]\n223.9 \n  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0\n  0     0    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0\n  0     0    0     0    0     0      0      0 --:--:--  0:00:02 --:--:--     0\n  0     0    0     0    0     0      0      0 --:--:--  0:00:03 --:--:--     0\n  0     0    0     0    0     0      0      0 --:--:--  0:00:04 --:--:--     0\n  0     0    0     0    0     0      0      0 --:--:--  0:00:05 --:--:--     0\n  0     0    0     0    0     0      0      0 --:--:--  0:00:06 --:--:--     0\n  0     0    0     0    0     0      0      0 --:--:--  0:00:07 --:--:--     0\n  0     0    0     0    0     0      0      0 --:--:--  0:00:08 --:--:--     0\n  0     0    0     0    0     0      0      0 --:--:--  0:00:08 --:--:--     0\n  0     0    0     0    0     0      0      0 --:--:--  0:00:09 --:--:--     0\n  0     0    0     0    0     0      0      0 --:--:--  0:00:10 --:--:--     0\n  0     0    0     0    0     0      0      0 --:--:--  0:00:11 --:--:--     0\n  0     0    0     0    0     0      0      0 --:--:--  0:00:12 --:--:--     0\n  0     0    0     0    0     0      0      0 --:--:--  0:00:13 --:--:--     0\n  0     0    0     0    0     0      0      0 --:--:--  0:00:14 --:--:--     0\n  0     0    0     0    0     0      0      0 --:--:--  0:00:15 --:--:--     0\n  0     0    0     0    0     0      0      0 --:--:--  0:00:16 --:--:--     0\n239.9 curl: (35) TLS connect error: error:0A000126:SSL routines::unexpected eof while reading\n239.9 gpg: no valid OpenPGP data found.\n------\n",
-      "stderr": " Image vds-mcp-server:latest Building \n Image vds-progress:1.0.0 Building \n Image vds-audit:1.0.0 Building \n Image vds-progress:1.0.0 Building \n Image vds-db-query:1.0.0 Building \n Image vds-audit:1.0.0 Building \n Image vds-cli:latest Building \n Image vds-pdf:1.0.0 Building \ntarget db-query-orchestrator: failed to solve: process \"/bin/sh -c apt-get update && apt-get install -y --no-install-recommends     curl gnupg unixodbc unixodbc-dev libpq-dev     && curl https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor -o /usr/share/keyrings/microsoft-prod.gpg     && echo \\\"deb [signed-by=/usr/share/keyrings/microsoft-prod.gpg] https://packages.microsoft.com/debian/12/prod bookworm main\\\" > /etc/apt/sources.list.d/mssql.list     && apt-get update && apt-get install -y --no-install-recommends msodbcsql18     && rm -rf /var/lib/apt/lists/*\" did not complete successfully: exit code: 2\n\nmake: *** [build-cli] Error 1\n"
-    }
-  ]
-}

package/skills/vds-skill/vds-scripts/docs/p8-preflight-evidence/alembic-and-runtime-advisory-locks.md

@@ -1,45 +0,0 @@
-# Alembic + Runtime Advisory-Lock Pre-flight Evidence (TSK-8.0.2)
-
-**Date**: 2026-04-27
-**Purpose**: Verify advisory-lock semantics for both alembic migrations and `audit_orchestrator` runtime code under the v2.15.3 PgBouncer topology. **Scope was broadened during pre-flight to include runtime advisory-lock usage in service code** (not in original WP-8.0.2 scope but surfaced naturally during pre-flight).
-
-## Verdict
-
-✅ **Both alembic's transaction-scoped locks AND audit_orchestrator's session-scoped locks are preserved natively under v2.15.3 session-mode topology — no per-service routing exceptions needed.**
-
-## Evidence
-
-### Alembic version pin
-
-`uv.lock` confirms `alembic==1.18.4`.
-
-### Advisory locks in our alembic migrations
-
-| File | Line | Statement | Lock variant |
-|---|---|---|---|
-| `audit_orchestrator/alembic/versions/0001_initial_audit_state_schema.py` | 1124 | `SELECT pg_try_advisory_xact_lock(v_lock_key) INTO v_acquired;` | **transaction-scoped** |
-| `audit_orchestrator/alembic/versions/0001_initial_audit_state_schema.py` | 1158 | `SELECT pg_try_advisory_xact_lock(v_lock_key) INTO v_acquired;` | **transaction-scoped** |
-
-These are released automatically at `COMMIT`/`ROLLBACK`. Alembic 1.18.4 itself does NOT take any session-scoped locks during normal `upgrade head`.
-
-### Advisory locks in audit_orchestrator runtime code
-
-| File | Line | Statement | Lock variant |
-|---|---|---|---|
-| `audit_orchestrator/src/vds_audit_orchestrator/state/store.py` | 5265 | `SELECT pg_try_advisory_lock(hashtext(%s)) AS acquired` | **session-scoped** |
-| `audit_orchestrator/src/vds_audit_orchestrator/state/store.py` | 5279 | `SELECT pg_advisory_unlock(hashtext(%s)) AS released` | **session-scoped** |
-
-These wrap the `acquire_corpus_session_lock(...)` API at line 5285, used to coordinate corpus-refresh sessions across **multiple transactions** with a `stale_threshold_minutes=10` timeout window. The lock is held while the refresh is in flight.
-
-The docstring at line 5229 incorrectly states "Uses non-blocking pg_try_advisory_xact_lock with retry loop" — but the actual SQL is `pg_try_advisory_lock` (without `_xact`). This is a documentation drift (orthogonal to P8 — could file a separate fix).
-
-## v2.15.3 resolution
-
-PgBouncer session-mode topology (per `topology-decision-session-mode.md`) preserves both alembic's transaction-scoped locks AND audit_orchestrator's session-scoped locks natively — no per-service routing exceptions needed. A single `VDS_<SVC>_DSN` per service routes through `vds-pgbouncer:6432`; the 1:1 client:backend binding holds the backend across COMMIT boundaries, so `pg_advisory_lock` / `pg_advisory_unlock` semantics survive end-to-end through the pooler.
-
-## References
-
-- Spec: `.gpt-5.4/specs/ecosystem-infrastructure-evolution/design.md` §ADR-INF-13 topology table
-- Topology decision: `topology-decision-session-mode.md`
-- Code: `audit_orchestrator/src/vds_audit_orchestrator/state/store.py:5260-5300`
-- Issue surfaced: 2026-04-27 P8 Wave 1 pre-flight; not present in earlier 4-lane validation audit (which scoped advisory-lock check to alembic migrations only).

package/skills/vds-skill/vds-scripts/docs/p8-preflight-evidence/dbos-listen-notify.md

@@ -1,54 +0,0 @@
-# DBOS LISTEN/NOTIFY Pre-flight Evidence (TSK-8.0.1)
-
-**Date**: 2026-04-27
-**Purpose**: Verify that `scheduler_orchestrator` (DBOS) LISTEN/NOTIFY usage is preserved under the v2.15.3 PgBouncer topology.
-
-## Verdict
-
-✅ **Scheduler routes through PgBouncer in session mode; LISTEN/NOTIFY works natively; no per-service exception needed.**
-
-Session-mode pooling preserves LISTEN/NOTIFY across the COMMIT boundary because it is 1:1 client:backend — the backend stays held for the lifetime of the client's connection. Scheduler routes via `VDS_SCHEDULER_DATABASE_URL=postgresql://postgres:.../vds-pgbouncer:6432/vds_sched` — single uniform DSN, same as every other service.
-
-## Evidence
-
-### DBOS dependency pin
-
-`scheduler_orchestrator/pyproject.toml`: `dbos>=2.19.0,<3` (verified via `uv.lock`).
-
-### Active LISTEN/NOTIFY usage in scheduler_orchestrator
-
-DBOS isn't *just configured* with `use_listen_notify=True` (the default) — the code actively uses Postgres LISTEN/NOTIFY for the event bus + chain triggers + dispatcher loop. Not theoretical, observed:
-
-| File | Line | Usage |
-|---|---|---|
-| `src/vds_scheduler_orchestrator/app.py` | 313 | `WS /api/v1/events/stream — live push via Postgres LISTEN/NOTIFY` |
-| `src/vds_scheduler_orchestrator/cli.py` | 779 | `pushes events in real time via Postgres LISTEN/NOTIFY. Replaces polling` |
-| `chains/triggers.py` | 395, 546, 554 | Dispatcher LISTEN loop is the core trigger mechanism |
-| `db/models.py` | 93 | `fires pg_notify('event_bus', event_id::text). The dispatcher's LISTEN loop` |
-| `events/bus.py` | 6 | `TSK-3.2: subscribe() — LISTEN loop and handler registry` |
-| `events/dispatcher.py` | (15 matches) | LISTEN loop implementation |
-
-### DBOSConfig snippet (app.py ~135-145)
-
-```python
-dbos_cfg: DBOSConfig = {
-    "name": "vds-scheduler-orchestrator",
-    # DBOS uses this as both system and application database.
-    # system_database_url → where dbos.* system tables live.
-    "system_database_url": cfg.vds_scheduler_database_url,
-    # application_version from DBOS_APP_VERSION env var (deploy-time) — ADR-7
-    "application_version": cfg.dbos_app_version,
-}
-```
-
-**Note**: the config sets *only* `system_database_url`; `application_database_url` is left unset and inherits the system URL per DBOS defaults. Spec `design.md §9.5` is consistent with this minimal-config shape.
-
-## Conclusion
-
-`scheduler_orchestrator` connects through PgBouncer at `vds-pgbouncer:6432/vds_sched` in **session mode**. LISTEN/NOTIFY works correctly because session-mode pooling holds the backend per-client for the lifetime of the connection — no premature COMMIT-time release. Single uniform DSN; no per-service exception list. See `topology-decision-session-mode.md` for the full v2.15.3 resolution rationale.
-
-## References
-
-- DBOS docs: https://docs.dbos.dev/python/tutorials/database-connection (states "session mode, not in transaction mode")
-- PgBouncer issue: https://github.com/pgbouncer/pgbouncer/issues/655 (LISTEN in tx mode — open)
-- Spec: `.gpt-5.4/specs/ecosystem-infrastructure-evolution/design.md` §ADR-INF-13 topology table