@ngocsangairvds/vsaf 3.2.16 → 4.0.1

package/tools/vds-scripts/AGENTS.md

@@ -1,250 +0,0 @@
-# AGENTS.md — VDS Scripts Workspace
-
-> Python automation workspace for VDS orchestrators and routed CLI commands.
-
-## Scope
-
-- Repository: `WHO-project/vds-scripts`
-- Primary responsibilities:
-  - `vds-cli` routed command surface
-  - audit/spec/task/progress/research/evolution orchestrators
-  - shared runtime and environment contracts
-- This file is Tier-0 operator contract (keep concise). Deep command catalogs and phase details live in docs references.
-
-## Repo Boundary
-
-This repo holds **runtime Python only** — CLI entry points, orchestrators, MCP
-servers, platform abstractions, agent-core libraries, evolution loops.
-Claude-Code-facing artifacts (skills, hook plugins, sync machinery, governance
-docs) live in `WHO-project/vds-skills/`.
-
-Canonical rules: `who-ecosystem-alignment` Phase 4 FR-8 (Repo purpose) and FR-9
-(Direction of dependency: skills may reference vds-scripts entry points;
-vds-scripts must build, test, and run with **zero** vds-skills artifacts
-present). FR-11 forbids `.claude/skills/<name>/` directories here. FR-12
-forbids new hook packages here (canonical hook surface is
-`vds-skills/plugins/vds-hooks-*/`).
-
-## Quick Start
-
-```bash
-cd WHO-project/vds-scripts
-
-# CLI router — unified entry point for all operations
-./scripts/worktree_uv.sh run --project vds_cli vds-cli --help
-./scripts/worktree_uv.sh run --project vds_cli vds-cli env status
-./scripts/worktree_uv.sh run --project vds_cli vds-cli status
-./scripts/worktree_uv.sh run --project vds_cli vds-cli doctor
-
-# Specialist services (all route through vds-cli)
-./scripts/worktree_uv.sh run --project vds_cli vds-cli audit --help
-./scripts/worktree_uv.sh run --project vds_cli vds-cli spec --help
-./scripts/worktree_uv.sh run --project vds_cli vds-cli evolution --help
-```
-
-## Unified Routing Contract
-
-**`vds-cli` is the single canonical entry point** for all user-facing orchestrator operations.
-
-- All commands route through `./scripts/worktree_uv.sh run --project vds_cli vds-cli <service> <command> [args]`.
-- `pyproject.toml [project.scripts]` are router implementation detail — not user-facing contracts.
-- Internal scripts (e.g., `vds-evolution`) are backend mechanisms invoked by the router, not directly by users.
-
-## Rules
-
-- Use `./scripts/worktree_uv.sh run --project vds_cli vds-cli ...` for worktree-safe Python execution.
-- Runtime is Postgres-first. Do not add filesystem fallback for audit state or evidence.
-- Use VDS SDK surfaces for Confluence/Bitbucket operations.
-- Keep phase history and long command narratives out of AGENTS.md.
-
-### Testing Rules
-
-- Tests must mock all external services (Confluence, Bitbucket, LLM providers, HTTP endpoints).
-- Control env vars with `monkeypatch.setenv` / `delenv`; do not read real local credentials.
-- Prefer focused tests for changed modules during development; run broad suites at merge gates.
-
-### Phase Numbering & Branch Naming
-
-Phase numbers are **per-spec local** structural labels, not monorepo-global tags. The same number can mean different things in different specs (e.g., `## Phase 219` in `vds-ai-memory` ≠ `## Phase 219` in `ecosystem-scheduling`). To prevent silent branch-namespace collisions when sessions run in parallel, new phase branches MUST use the prefix `<spec-prefix>-phase<N>`:
-
-- `vai-phase219` — vds-ai-memory (`vai`)
-- `eco-phase5` — ecosystem-infrastructure-evolution (`eco`)
-- `audit-phase6` — audit-orchestrator (`audit`)
-- `core-phase172` — vds-agent-core-alignment (`core`)
-
-Commit messages retain the narrative `phase<N>` form for readability. Existing un-prefixed branches (e.g., `phase218`, `phase219/...`) are grandfathered; the prefix rule applies prospectively. When starting a new phase, check the spec's `requirements.md` for the next free phase number within that spec, then `git branch -a | grep <spec-prefix>-phase<N>` before creating the branch — collision is now diagnosable by name.
-
-### Active Spec Sync
-
-vds-ai-memory: **1547 tests**, spec v20.22.0 (Phase 228/229/230/231 Finalized, Phase 232 Blocked — dedup never ran, max_groups=10, embed degraded)
-
-### Containerization Policy
-
-| Command Category                | Runtime                         | Examples                                                                       |
-| ------------------------------- | ------------------------------- | ------------------------------------------------------------------------------ |
-| **Host-only** (never in Docker) | Host filesystem                 | `vds-cli skills sync`, `git commit/rebase`, `vds-cli spec create`              |
-| **Host-only**                   | Host credentials/env            | `vds-cli memory store/search`, `./scripts/worktree_uv.sh`                      |
-| **Container-eligible**          | Docker                          | `vds-cli audit workflow`, `vds-cli research search`, `vds-cli confluence sync` |
-| **Hybrid**                      | Container (read) + Host (write) | `vds-cli progress report` (read DB, write reports), `vds-cli pdf convert`      |
-
-`vds-skills` remains container-free. Skill sync must run on host.
-
-### Scheduler Architecture (Single-Scheduler Operator Note, post-2026-04-24)
-
-The VDS ecosystem now has **one** periodic-task scheduler: **`scheduler_orchestrator`** (DBOS-backed, in `scheduler_orchestrator/`). Celery Beat was retired by ADR-14 on 2026-04-24 (commit `a0ba4179`); audit trail at `scheduler_orchestrator/CLOSURE-v2.0.18.md` (Phase 0 of `.gpt-5.4/specs/vds-scheduler/`).
-
-| Concern                                  | Owner                                                                | Notes                                                                                                                                                                                                                                                                    |
-| ---------------------------------------- | -------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| All periodic schedules (cron + interval) | `scheduler_orchestrator` (DBOS)                                      | Includes the 6 ex-Celery-Beat memory-evolution tasks (`memory.evolution.{dispatch,sweep,replay-dlq}`, `mem0.{resolve-pending-ids,repush-stalled,repush-local-only}`) plus audit drift scans, chain triggers, event-bus dispatch, and scheduled agent-step workflows      |
-| Ad-hoc Celery task dispatch              | Celery worker in `memory_orchestrator/` (worker only — beat retired) | The worker plumbing (`memory_evolution/celery_app.py` + `celery_entrypoint.py`) is intentionally retained per `scheduler_orchestrator/CLOSURE-v2.0.18.md` §Scope Clarification, for explicit `.delay()` / `.send_task()` dispatch from production code. Not a scheduler. |
-| Kill switch                              | `VDS_SCHEDULER_ENABLED=false` (default)                              | Disables `scheduler_orchestrator` completely. Celery worker dispatch is unaffected.                                                                                                                                                                                      |
-
-**Kill-switch rule**: `VDS_SCHEDULER_ENABLED=false` (the default in `~/.vds/.env`) keeps `scheduler_orchestrator` dormant. Set `VDS_SCHEDULER_ENABLED=true` only when the scheduler service is intentionally started; this activates 7+ DBOS schedules (6 ex-Celery memory-evolution + `evolution.auto-promote` + the autoscaler tick).
-
-- **Ecosystem Daily Report** (`ecosystem.daily.report`): Runs at 06:00 UTC daily on `ops-default` queue. Collects git activity, scheduler health, event bus metrics, queue depths. Writes Markdown to `reports/ecosystem/`, persists to `sched.ecosystem_report_runs`, publishes `ecosystem.daily.completed`/`.failed` events. Config: `VDS_ECOSYSTEM_DAILY__*` env vars. Spec: `.gpt-5.4/specs/ecosystem-daily-report/`.
-
-**What is NOT a scheduler anymore**: Celery Beat (container removed from the legacy mem0-deploy stack; the unified `docker/docker-compose.services.yml` is beat-free by design; `beat_schedule` is empty `{}`). Tests asserting Celery Beat schedule registrations were updated in v2.0.10 to assert post-retirement empty state. The legacy compose files were retired to `docker/legacy/` in P3 + P4 WP-4.0; that directory was removed in spec v2.15.12 per the no-legacy directive — recover via git history if rollback is ever needed.
-
-## Entry Points
-
-All services route through a single entry:
-
-```bash
-vds-cli <service> <command> [args]
-```
-
-**Core service families** (non-exhaustive):
-
-- `vds-cli audit ...` — Audit operations (repo, project, multi-project)
-- `vds-cli spec ...` — Spec lifecycle (create, validate, consolidate)
-- `vds-cli tasks ...` — Task orchestrator
-- `vds-cli progress ...` — Progress reports
-- `vds-cli research ...` — Research orchestrator
-- `vds-cli memory ...` — Memory operations
-- `vds-cli evolution ...` — Evolution loop
-- `vds-cli confluence ...` — Confluence operations
-- `vds-cli bitbucket ...` — Bitbucket operations
-- `vds-cli git ...` — Git orchestrator
-- `vds-cli jira ...` — JIRA operations
-- `vds-cli db-query ...` — Database queries
-- `vds-cli grafana ...` — Grafana operations
-- `vds-cli sonarqube ...` — SonarQube operations
-- `vds-cli lsp ...` — LSP operations
-- `vds-cli elastic ...` — Elasticsearch operations
-- `vds-cli pdf ...` — PDF generation
-- `vds-cli diagrams ...` — Diagram generation
-- `vds-cli schema ...` — Schema conversion
-- `vds-cli excel ...` — Excel operations
-- `vds-cli google-sheets ...` — Google Sheets operations
-- `vds-cli circular-dependency ...` — Circular dependency analysis
-- `vds-cli openapi ...` — OpenAPI operations
-- `vds-cli links ...` — Link validation
-- `vds-cli structure ...` — Structure validation
-- `vds-cli brd ...` — BRD coverage
-- `vds-cli intellij ...` — IntelliJ operations
-- `vds-cli metabase ...` — Metabase operations
-- `vds-cli hexagonal ...` — Hexagonal compliance
-- `vds-cli markdown ...` — Markdown operations
-- `vds-cli mcp ...` — MCP server operations
-- `vds-cli multi-agent ...` — Multi-agent operations
-- `vds-cli public-interface ...` — Public interface boundary
-- `vds-cli scheduler ...` — Ecosystem scheduler (schedule/event/chain ops); requires `VDS_SCHEDULER_ENABLED=true`
-- `vds-cli telegram ...` — Telegram bridge ops (DISABLED 2026-04-30 — aiogram pydantic conflict; restore when aiogram >=3.28.0). Bridge code present at `telegram_bridge/`, 102 tests pass offline.
-
-## Search & Navigation
-
-- Start with `rg` for exact symbols and strings.
-- Use `sg` / structural search for pattern-level code exploration.
-- For large-scope understanding, prefer graphify/gitnexus before broad file scans.
-- Phase truth and runtime baselines are maintained in docs references (below), not inline here.
-
-## Code
-
-### Critical Path Symbols
-
-Before changing a symbol, run impact analysis:
-
-- `gitnexus_impact({target: "SymbolName", direction: "upstream"})`
-
-Before committing, run scope detection:
-
-- `gitnexus_detect_changes({scope: "staged"})`
-
-For unknown flows, start with:
-
-- `gitnexus_query({query: "concept"})`
-- `gitnexus_context({name: "symbol"})`
-
-### GitNexus Guardrails
-
-- Treat HIGH/CRITICAL impact results as explicit risk gates and surface them before continuing edits.
-- Never perform symbol renames via plain find/replace; use graph-aware rename workflows.
-- Re-index intentionally after significant code changes:
-  - `npx gitnexus analyze`
-  - `npx gitnexus analyze --embeddings` (when embeddings are in use)
-
-## Validation Gates (last verified: 2026-05-04 (Phase 14 post-merge))
-
-| Package                                      | Passed     | Failed | Skipped | Gate                                                                                                                                               |
-| -------------------------------------------- | ---------- | ------ | ------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
-| spec_orchestrator                            | 14         | 0      | 0       | GREEN                                                                                                                                              |
-| scheduler_orchestrator                       | 1,454      | 0      | 3       | GREEN (+2 from FR-14.2 cache fix)                                                                                                                  |
-| vds_agent_core                               | 932        | 0      | 0       | GREEN (+6 from FR-14.1 + FR-14.5 forward-ref fixes)                                                                                                |
-| memory_orchestrator (Phase 225 surface)      | 8          | 0      | 0       | GREEN                                                                                                                                              |
-| multi_agent_orchestrator (Phase 225 surface) | 49         | 0      | 0       | GREEN                                                                                                                                              |
-| audit_orchestrator (profile-focused subset)  | 121        | 15     | 24      | DEGRADED — pre-existing Python 3.14 forward-ref + config_hooks bugs (FR-14.1/14.5 reduced GAP cascade, full audit suite 8,290 PASS still DEGRADED) |
-| progress_report_orchestrator                 | 452        | 1      | 0       | DEGRADED — pre-existing alembic env_py schema-name assertion                                                                                       |
-| telegram_bridge                              | 102+       | 0      | 0       | GREEN                                                                                                                                              |
-| vds_cli (ecosystem)                          | 286        | 0      | 5       | GREEN                                                                                                                                              |
-| **Phase 14 surface total**                   | **1,477+** | **0**  | **8**   | GREEN (+8 from Phase 14 fixes)                                                                                                                     |
-
-- Scheduler Alembic: `a1b2c3d4e5f8` (Phase 2 golden-signals columns live)
-- Memory/Progress/Audit Alembic: AT_HEAD
-- Docker: 10/10 containers healthy; worker + API same image digest
-- Live CLI smoke: 6/6 pass (spec validate, scheduler help, trigger-now, db-query, onboarding-funnel, freshness)
-- Phase 231 deploy: vds-memory:1.0.0 image **10.4 GB** (62% reduction from 27.6 GB pre-Phase-225); all 7 health layers healthy; doctor embedding fallback OLLAMA_BASE_URL → BASE_URL deployed; VDS_MEMORY_TIMEOUT_SECONDS=300 set; entrypoint.sh alembic upgrade head verified
-
-## Docs
-
-- CLI command reference: `docs/agents/reference/cli-commands.md`
-- Ecosystem report: `docs/agents/reference/ecosystem-daily-report.md`
-- Skills commands: `docs/agents/reference/skills-commands.md`
-- Infrastructure v2.15: `docs/agents/reference/infrastructure-v2.15.md`
-- CI workflows: `docs/agents/reference/ci-workflows.md`
-- Ecosystem index: `ECOSYSTEM-DOCS.md`
-- Ecosystem changelog: `ECOSYSTEM-CHANGELOG.md`
-- Environment git-helper: `docs/agents/reference/env-git-helper.md`
-- Phase archive: `docs/phases/CHANGELOG.md`
-- Script authoring contract: `scripts/README.md`
-- Worktree wrapper contract (Phase 220.V): `scripts/README.md` §Worktree Wrapper Scripts (`worktree-add.sh` / `worktree-remove.sh` are canonical for vds-scripts; bare `git worktree` is fallback only)
-- Telegram Bridge reference: `telegram_bridge/skill_content/references/README.md`
-- Root router: `../AGENTS.md`
-- Ecosystem alignment: `ECOSYSTEM_ALIGNMENT.md` (openspace hook analysis)
-- Canonical spec: `.gpt-5.4/specs/ARCHIVE/who-project-documentation-enhancement/` (ARCHIVED — Phases 177→179 + post-merge updates merged)
-
-### Comprehensive Docs (Phase 180)
-
-- Introduction: `docs/agents/explanation/who-ecosystem-introduction.md`
-- Quick Start: `docs/agents/tutorials/quick-start.md`
-- Configuration: `docs/agents/reference/configuration-reference.md`
-- Troubleshooting: `docs/agents/how-to/troubleshooting-guide.md`
-- Architecture: `docs/agents/explanation/system-architecture.md`
-- Tips & Tricks: `docs/agents/how-to/tips-and-tricks.md`
-- See all: `ECOSYSTEM-DOCS.md`
-
-### Symlink Handling
-
-- `CLAUDE.md` in this repo is a symlink → `AGENTS.md`.
-- On filesystems where `core.symlinks=false`, the validator reports:
-  `CLAUDE.md is not a symlink to AGENTS.md (ERROR)`.
-- Fix: enable Git symlinks (`git config --global core.symlinks true`) or re-clone.
-
-## Ngôn ngữ / Language
-
-- [English](./AGENTS.md)
-- [Tiếng Việt](./AGENTS.vi.md)
-
-## Confluence Documentation
-
-- [WHO-Project Ecosystem Documentation](http://confluence.digital.vn/display/TTCN24/WHO-Project+Ecosystem+Documentation)
-  ecosystem: **41 tests**, spec v2.16.0 (Phase 0/8 Finalized; v2.16.0 deploy-portability extension applied)

package/tools/vds-scripts/AGENTS.vi.md

@@ -1,92 +0,0 @@
-# AGENTS.md — Không gian làm việc VDS Scripts
-
-> Không gian làm việc Python tự động hóa cho các điều phối viên và lệnh CLI được định tuyến của VDS.
-
-## Phạm vi
-
-- Repository: `WHO-project/vds-scripts`
-- Trách nhiệm chính:
-  - Bề mặt lệnh được định tuyến `vds-cli`
-  - Các điều phối viên audit/spec/task/progress/research
-  - Hợp đồng runtime và môi trường chia sẻ
-- Tệp này là hợp đồng vận hành Tier-0 (giữ ngắn gọn). Chi tiết lệnh sâu và giai đoạn nằm trong tài liệu tham khảo.
-
-## Khởi động nhanh
-
-```bash
-cd WHO-project/vds-scripts
-./scripts/worktree_uv.sh run --project vds_cli vds-cli --help
-./scripts/worktree_uv.sh run --project vds_cli vds-cli env status
-./scripts/worktree_uv.sh run --project audit_orchestrator vds-audit --help
-./scripts/worktree_uv.sh run --project spec_orchestrator vds-spec --help
-```
-
-## Quy tắc
-
-- Sử dụng `./scripts/worktree_uv.sh` để thực thi Python an toàn cho worktree.
-- Runtime ưu tiên Postgres-first. Không thêm dự phòng filesystem cho trạng thái audit hoặc bằng chứng.
-- Sử dụng bề mặt SDK VDS cho các thao tác Confluence/Bitbucket.
-- Giữ lịch sử giai đoạn và câu chuyện lệnh dài ở ngoài AGENTS.md.
-
-### Quy tắc kiểm thử
-
-- Các bài kiểm thử phải giả lập tất cả dịch vụ bên ngoài (Confluence, Bitbucket, nhà cung cấp LLM, điểm cuối HTTP).
-- Kiểm soát biến môi trường bằng `monkeypatch.setenv` / `delenv`; không đọc thông tin xác thực cục bộ thực.
-- Ưu tiên các bài kiểm thử tập trung cho các mô-đun đã thay đổi trong quá trình phát triển; chạy bộ kiểm thử rộng ở cổng merge.
-
-## Điểm vào
-
-- Bộ định tuyến thống nhất:
-  - `./scripts/worktree_uv.sh run --project vds_cli vds-cli <service> ...`
-- Các nhóm dịch vụ cốt lõi:
-  - `vds-cli audit ...`
-  - `vds-cli spec ...`
-  - `vds-cli tasks ...`
-  - `vds-cli progress ...`
-  - `vds-cli research ...`
-  - `vds-cli memory ...`
-
-## Tìm kiếm & Điều hướng
-
-- Bắt đầu bằng `rg` cho các ký hiệu và chuỗi chính xác.
-- Sử dụng `sg` / tìm kiếm cấu trúc để khám phá mẫu mức độ mã.
-- Để hiểu phạm vi lớn, ưu tiên graphify/gitnexus trước khi quét tệp rộng.
-- Sự thật về giai đoạn và đường cơ sở runtime được duy trì trong tài liệu tham khảo (bên dưới), không nội tuyến ở đây.
-
-## Trí tuệ mã
-
-Repo này được GitNexus lập chỉ mục là **vds-scripts**.
-
-- Trước khi thay đổi ký hiệu, chạy phân tích tác động:
-  - `gitnexus_impact({target: "SymbolName", direction: "upstream"})`
-- Trước khi commit, chạy phát hiện phạm vi:
-  - `gitnexus_detect_changes({scope: "staged"})`
-- Đối với các luồng chưa biết, bắt đầu bằng:
-  - `gitnexus_query({query: "concept"})`
-  - `gitnexus_context({name: "symbol"})`
-
-### Rào cản GitNexus
-
-- Coi kết quả tác động CAO/QUAN TRỌNG là rào cản rủi ro rõ ràng và trình bày chúng trước khi tiếp tục chỉnh sửa.
-- Không bao giờ thực hiện đổi tên ký hiệu qua tìm/thay thế thông thường; sử dụng quy trình đổi tên có nhận thức đồ thị.
-- Lập chỉ mục lại có chủ đích sau các thay đổi mã quan trọng:
-  - `npx gitnexus analyze`
-  - `npx gitnexus analyze --embeddings` (khi embeddings đang được sử dụng)
-
-## Tài liệu
-
-- Tài liệu tham khảo lệnh CLI: `docs/agents/reference/cli-commands.md`
-- Lưu trữ giai đoạn: `docs/phases/CHANGELOG.md`
-- Hợp đồng viết script: `scripts/README.md`
-- Bộ định tuyến gốc: `../AGENTS.md`
-
-### Xử lý Symlink
-
-- `CLAUDE.md` trong repo này là symlink → `AGENTS.md`.
-- Trên các hệ thống tệp nơi `core.symlinks=false`, trình xác thực báo cáo:
-  `CLAUDE.md is not a symlink to AGENTS.md (ERROR)`.
-- Khắc phục: bật Git symlinks (`git config --global core.symlinks true`) hoặc clone lại.
-
-## Ngôn ngữ / Language
-- [English](./AGENTS.md)
-- [Tiếng Việt](./AGENTS.vi.md)

package/tools/vds-scripts/Makefile

@@ -1,97 +0,0 @@
-# VDS Ecosystem Infrastructure Makefile
-# Phase: ecosystem-infrastructure-evolution v2.10.0
-#
-# Quick targets for the unified docker/ three-tier compose topology.
-# Run from vds-scripts repo root.
-#
-# Tiers (per ADR-INF-10):
-#   - Tier 1 docker-compose.infra.yml     : postgres, redis, qdrant
-#   - Tier 2 docker-compose.services.yml  : memory-api/worker, scheduler (long-running)
-#   - Tier 3 docker-compose.cli.yml       : db-query, vds-cli, mcp-server (CLI)
-#
-# Long-running services use `up -d` (`make up-memory`, etc.).
-# CLI containers use `run --rm` (`make run-db-query ARGS="query ..."`).
-
-.PHONY: help \
-        env-link \
-        up-infra up-memory up-scheduler up-services \
-        run-db-query run-vds-cli \
-        down restart status verify build-cli clean-volumes
-
-# Hybrid project-identity anchor: -p flag + `name: vds-platform` in compose YAML
-# both pin the project as "vds-platform" regardless of CWD (ADR-INF-7).
-COMPOSE_PROJECT := vds-platform
-INFRA           := -f docker/docker-compose.infra.yml
-SERVICES        := -f docker/docker-compose.infra.yml -f docker/docker-compose.services.yml
-CLI             := -f docker/docker-compose.infra.yml -f docker/docker-compose.cli.yml
-ALL             := -f docker/docker-compose.infra.yml -f docker/docker-compose.services.yml -f docker/docker-compose.cli.yml
-
-DC := docker compose -p $(COMPOSE_PROJECT)
-
-help: ## Show this help message
-	@grep -E '^[a-zA-Z_-]+:.*?## .*$$' $(MAKEFILE_LIST) | sort | awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-20s\033[0m %s\n", $$1, $$2}'
-
-# === One-time bootstrap: env symlink (v2.0.17 N.52 consolidation) ===========
-# Compose's `${VAR}` substitution reads from compose's own .env (or shell),
-# NOT from the per-service env_file: block. To make ~/.vds/.env feed BOTH
-# in-container env_file AND YAML interpolation, link docker/.env -> ~/.vds/.env.
-env-link: ## Create docker/.env -> ~/.vds/.env symlink (idempotent; gitignored)
-	@if [ ! -L docker/.env ]; then \
-		ln -sf $$HOME/.vds/.env docker/.env && \
-		echo "Linked docker/.env -> ~/.vds/.env"; \
-	else \
-		echo "docker/.env already linked"; \
-	fi
-
-# === Long-running services (Tier 2; `up -d` keeps them running) ============
-# Per spec v2.12.2 P4 deploy postmortem: `--build` is included by default so
-# pulling latest master always rebuilds the service image. Operators who want
-# to skip the build (image is fresh) can set NO_BUILD=1.
-BUILD_FLAG := $(if $(NO_BUILD),,--build)
-
-up-infra: env-link ## Start shared infrastructure only (postgres, redis, qdrant)
-	$(DC) $(INFRA) --profile infra up -d
-
-up-memory: env-link ## Start infra + memory-api + memory-worker (rebuilds image; set NO_BUILD=1 to skip)
-	$(DC) $(SERVICES) --profile memory up -d $(BUILD_FLAG)
-
-up-scheduler: env-link ## Start infra + scheduler-orchestrator (rebuilds image; needs VDS_SCHEDULER_ENABLED=true; set NO_BUILD=1 to skip)
-	# Phase 217 HTTP refactor: scheduler depends_on memory-api; activate both --profile scheduler and --profile memory.
-	$(DC) $(SERVICES) --profile scheduler --profile memory up -d $(BUILD_FLAG)
-
-up-services: env-link ## Start infra + long-running services (rebuilds images; set NO_BUILD=1 to skip)
-	# Tier 3B retired in v2.15.10 (ADR-INF-10): long-running services only need services.yml.
-	$(DC) $(SERVICES) --profile full up -d $(BUILD_FLAG)
-
-# === CLI containers (Tier 3; `run --rm` invocation pattern) ================
-# Override ARGS to pass subcommands. ARGS defaults to --help.
-ARGS ?= --help
-
-run-db-query: env-link ## Run db-query CLI (set ARGS="query --connection prod -q 'SELECT 1'")
-	$(DC) $(CLI) --profile db-query run --rm db-query-orchestrator $(ARGS)
-
-run-vds-cli: env-link ## Run unified vds-cli router (set ARGS="<service> <command>")
-	$(DC) $(CLI) --profile vds-cli run --rm vds-cli $(ARGS)
-
-# === Build / build CLI images ahead of time ================================
-
-build-cli: ## Pre-build CLI images (db-query, vds-cli, mcp-server)
-	$(DC) $(CLI) --profile cli build
-
-# === Lifecycle =============================================================
-
-down: ## Stop and remove ALL containers (volumes preserved)
-	$(DC) $(ALL) --profile full --profile cli down
-
-restart: down up-services ## Stop everything and start the long-running services
-
-status: ## Show running containers and ports
-	@docker ps --filter "name=vds-" --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"
-
-verify: ## Run topology verification (stdlib python3, no uv)
-	python3 scripts/verify-infra-topology.py --profile infra
-
-clean-volumes: ## Remove all VDS-managed volumes (DESTRUCTIVE — prompts first)
-	@echo "About to remove: vds_postgres_data vds_redis_data vds_qdrant_data vds-memory-logs"
-	@read -p "Type YES to confirm: " confirm && [ "$$confirm" = "YES" ] || (echo "Aborted." && exit 1)
-	docker volume rm -f vds_postgres_data vds_redis_data vds_qdrant_data vds-memory-logs 2>/dev/null || true

package/tools/vds-scripts/README.md

@@ -1,103 +0,0 @@
-# VDS Scripts & Orchestrator Ecosystem
-
-**Centralized Automation Platform for Viettel Digital Services**
-
-This repository contains the `vds-cli` and a collection of specialized orchestrators designed to automate the software development lifecycle, from documentation management to infrastructure verification.
-
-`WHO-project` is the canonical VDS ecosystem for both reusable skills and routed scripts. Within that model, this repository is the authoritative scripts workspace, while the companion `WHO-project/vds-skills/` repository is the authoritative skills catalog.
-
-## 🚀 Quick Start
-
-Ensure you have the VDS CLI installed and configured.
-For the canonical human + AI-agent install/bootstrap flow, start with `docs/agents/how-to/install-and-bootstrap-who-scripts-and-skills.md`.
-
-```bash
-# Install dependencies in the current worktree
-./scripts/worktree_uv.sh sync
-
-# Verify installation
-./scripts/worktree_uv.sh run --project vds_cli vds-cli --version
-
-# Check environment status
-./scripts/worktree_uv.sh run --project vds_cli vds-cli env status
-```
-
----
-
-## 📦 Available Orchestrators
-
-The platform is modularized into specialized orchestrators, each handling a specific domain.
-
-### Core Utilities
-
-| Orchestrator | Command | Description |
-|--------------|---------|-------------|
-| **[Task Orchestrator](./task_orchestrator/README.md)** | `vds-cli tasks --` | Manage, refine, and audit service task breakdowns and project plans. |
-| **[Excel Orchestrator](./excel_orchestrator/README.md)** | `vds-cli excel --` | Read, write, and format Excel reports (used by Task Orchestrator). |
-| **[Git Orchestrator](./git_orchestrator/README.md)** | `vds-cli git --` | Repository management, cloning, and syncing across projects. |
-| **[OpenAPI Orchestrator](./openapi_orchestrator/README.md)** | `vds-cli openapi --` | Validate, merge, and manage OpenAPI 3.x specifications. |
-
-### Documentation & Knowledge
-
-| Orchestrator | Command | Description |
-|--------------|---------|-------------|
-| **[Markdown Orchestrator](./markdown_orchestrator/README.md)** | `uv run --project markdown_orchestrator vds-markdown ...` | Format, lint, and validate Markdown documentation (direct CLI). |
-| **[PDF Orchestrator](./pdf_orchestrator/README.md)** | `vds-cli pdf --` | Generate high-fidelity PDFs from markdown sources. |
-| **[Diagram Generator](./diagram_generator/README.md)** | `vds-cli diagrams --` | Generate C4, Sequence, and ER diagrams from code/text. |
-| **[BRD Orchestrator](./brd_orchestrator/README.md)** | `vds-cli brd --` | Validate requirement coverage against Business Requirements Documents. |
-| **[Schema Converter](./schema_converter/README.md)** | `vds-cli schema --` | Convert between SQL, Prisma, JSON Schema, and Markdown. |
-
-### Integration & Infrastructure
-
-| Orchestrator | Command | Description |
-|--------------|---------|-------------|
-| **[Jira Orchestrator](./jira_orchestrator/README.md)** | `vds-cli jira` | Interact with Jira API for ticket management. |
-| **[Confluence Orchestrator](./confluence_orchestrator/README.md)** | `vds-cli confluence` | Publish documentation to Confluence pages. |
-| **[Bitbucket Orchestrator](./bitbucket_orchestrator/README.md)** | `vds-cli bitbucket` | Manage PRs, repositories, and branch permissions. |
-| **[Elastic Orchestrator](./elastic_orchestrator/README.md)** | `vds-cli elastic --` | Query and manage Elasticsearch indices. |
-| **[DB Query Orchestrator](./db_query_orchestrator/README.md)** | `vds-cli db_query --` | Manage named DB connections and run safe read-only SQL against PostgreSQL, SQL Server, and MariaDB. |
-| **[Grafana Orchestrator](./grafana_orchestrator/README.md)** | `vds-cli grafana --` | Query logs and metrics via Grafana Datasource. |
-| **[SonarQube Orchestrator](./sonarqube_orchestrator/README.md)** | `vds-cli sonarqube --` | Trigger scans and check quality gates. |
-
-### Ecosystem Scheduling
-
-| Orchestrator | Command | Description |
-|--------------|---------|-------------|
-| **[Scheduler Orchestrator](./scheduler_orchestrator/README.md)** | `vds-cli scheduler --` | Durable cron/interval/one-shot schedule management, event-bus dispatch, chain triggers, and DBOS workflow orchestration. Requires `VDS_SCHEDULER_ENABLED=true`. |
-
-### Developer Experience
-
-| Orchestrator | Command | Description |
-|--------------|---------|-------------|
-| **[IntelliJ Orchestrator](./intellij_orchestrator/README.md)** | `vds-cli intellij --` | Automate workspace setup and run configurations. |
-| **[Links Orchestrator](./links_orchestrator/README.md)** | `vds-cli links --` | Validate relative and absolute links across documentation. |
-| **[Structure Orchestrator](./structure_orchestrator/README.md)** | `vds-cli structure --` | Enforce repository folder structure and naming conventions. |
-
----
-
-## 🛠️ Development Standards
-
-All orchestrators should follow the `vds-cli` routed command model and shared environment-loading pattern used in `vds_cli_common`.
-
-### Key Requirements
-1.  **Structure**: Must follow `src/vds_[name]_orchestrator/cli.py` pattern.
-2.  **Configuration**: Keep secrets in `VDS_ENV_FILE` or `<config-root>/.env`; `<config-root>` resolves from `VDS_CONFIG_DIR` when set, otherwise from the friendly user-home VDS default (`~/.vds` on Unix-like systems). Keep non-sensitive extraction tuning in `<config-root>/config/extract-docs.toml`.
-3.  **Testing**: Minimum 80% unit test coverage.
-4.  **CLI**: Expose commands via `typer` for integration into `vds-cli`.
-5.  **Audit Runtime Contract (current merged baseline)**: `vds-audit` workflow/analyze/ad-hoc consume evidence from Postgres chunks only (no runtime disk evidence ingestion path). Use `vds-audit prepare --project <PROJECT_STORAGE_KEY>` to run the deterministic prep sequence (`parse-registry -> sync repos -> extract-docs`), then confirm `state readiness` reports `ready=true`, `docs_chunk_ready=true`, and `code_chunk_ready=true`.
-
-### Creating a New Orchestrator
-
-1.  Copy the structure from an existing module (e.g., `task_orchestrator`).
-2.  Implement the logic in `src/`.
-3.  Register the module in `vds_cli/src/vds_cli/router.py`.
-4.  Add the command group in `vds_cli/src/vds_cli/cli.py`.
-5.  Add entry to this README.
-
----
-
-## 🤝 Contributing
-
-1.  Create a feature branch `feature/enhance-[orchestrator]`.
-2.  Ensure tests pass: `uv run pytest`.
-3.  Submit a PR via `vds bitbucket pr create`.

package/tools/vds-scripts/bitbucket_manifest_mapping.toml

@@ -1,34 +0,0 @@
-# Bitbucket project → manifest mapping rules for dynamic repo-manifest.yaml generation
-#
-# This file is intentionally minimal: it only defines how to convert a Bitbucket
-# project key into:
-# - project_id: short id used in repo-manifest.yaml (lep, insurance, saving, ekyc)
-# - path_prefix: local path prefix in the monorepo
-# - default_branch: default branch name when generating entries
-#
-# To add more projects later, extend this file and rerun the generator.
-
-[projects.LEP]
-project_id = "lep"
-path_prefix = "LEP-project"
-default_branch = "release"
-
-[projects.INSURANCE]
-project_id = "insurance"
-path_prefix = "INSURANCE-project"
-default_branch = "release"
-
-[projects.SAVING]
-project_id = "saving"
-path_prefix = "SAVING-project"
-default_branch = "release"
-
-[projects.EKYC]
-project_id = "ekyc"
-path_prefix = "EKYC-project"
-default_branch = "release"
-
-[projects.DOPS]
-project_id = "dops"
-path_prefix = "DOPS-project"
-default_branch = "master"