Mission Control doc

Milestones Manifesto

milestones-manifesto.md

Milestones Manifesto — Super Detailed Build Checklist

Date: 2026-05-12 Status: Forward-looking build manifesto + sequenced milestone checklist with explicit sub-milestone decomposition Companion to: vertical-fusion-checklist.md + v_platform/PLATFORM.md baseline Discipline: Checklist Manifesto (per SOUL.md mindset #7) Terminology lock (per operator 2026-05-12): ADE Factory = val-forge — the dev factory engine. Throughout this manifesto + sibling MC docs the terms "ADE Factory" + "val-forge" + "ADE Factory Pipeline" + "val-forge pipeline" are synonymous. Per ADR-011 + ADR-025.

The Manifesto

ValOS is built one verified milestone at a time. No milestone advances without its pause-point verification. No layer accepts work that violates the layer below's locked invariants. Every item is either done, in-flight with named owner, or explicitly blocked.

Checklist Manifesto principles:

Killer items — gating sub-tasks; cannot skip
Pause points (⏸️) — verification gates between sub-milestones / milestones
Acceptance criteria — concrete pass/no-pass
Sub-milestones — explicit numbered decomposition (MX.Y format)
Dependencies — graphed; no starting work blocked by upstream
Owners — named accountability
References — research docs + ADRs + PLATFORM.md rows tight

Public, versioned, wrong until proven right.

Status Legend

Symbol	Meaning
✅	Done / verified
🔧	In progress / partial
❌	Not started
⏸️	Pause point (verification gate)
🎯	ADR proposed; operator approval pending
📋	Spec'd; build pending
🔒	Locked (invariant — cannot modify without operator approval)

Sub-Milestone Format

Each milestone (MN) decomposes into numbered sub-milestones (MN.1, MN.2, ...) plus a pause point (MN.P). Each sub-milestone has:

Goal — one sentence
Killer items — 3-7 concrete tasks
Acceptance — pass/no-pass criterion
Depends on — within-milestone or external dependency
Owner — explicit accountability
Status — ❌ / 🔧 / ✅

Pause points (MN.P) verify the whole milestone before next milestone advances.

Critical Path Sequencing

M0 → M_up → M1 → M2 → M3 → M4 → [Part 1→2 gate] → M5 → M6
                                                         ├── M7 (parallel)
                                                         └── M8 (parallel)
                                                              ↓
                                                              M9
                                                               ├── M10 (parallel)
                                                               ├── M11 (parallel)
                                                               └── M12 (parallel)

M_up sequenced before M1 per operator commitment 2026-05-12: val-up (per ADR-024) bootstraps Mission Control orchestration + client onboarding. Without val-up, M1-M12 work proceeds via manual markdown editing + manual Decision Card YAML. With val-up, every subsequent milestone is tracked via val-up Decision Cards from day 1.

Milestone 0 — Pre-flight: Current State Lockup

Goal: All in-flight pipeline documentation committed + memory updated + on VM before M1 advances.

Sub-milestones

M0.1 — Research pipeline commits

Goal: 40 research docs committed across 5 commit batches
Killer items:
- ✅ Batch 1 commit c94810b (11 docs)
- ✅ Batch 2 commit 68a6cb3 (7 docs + spec)
- ✅ Batch 3 commit f17d215 (3 docs + appends + spec expansion)
- ✅ Batch 4 commit 8674223 (13 docs)
- ✅ Batch 5 commit 6a361c3 (6 docs + 2 modifications)
Acceptance: git log --oneline shows 5 batch commits on claude/silly-grothendieck-5cb6f5
Status: ✅

M0.2 — 16 ADR drafts authored

Goal: All 16 ADRs from pipeline-state queue drafted in d_mission-control/specs/
Killer items:
- ✅ ADR-007 / -009 / -010 / -011 / -012 / -013 / -014 / -015 / -016 / -017 / -018 / -019 / -020 / -021 / -022 / -023
Acceptance: 16 files exist; standard ADR format applied; all status Proposed
Status: ✅

M0.3 — Two checklist specs composed

Goal: Vertical fusion checklist + milestones manifesto composed
Killer items:
- ✅ vertical-fusion-checklist.md (16 layers)
- ✅ milestones-manifesto.md (this doc; 13 milestones with sub-milestone decomposition)
Acceptance: Both files exist + cross-reference each other
Status: ✅

M0.4 — 9 memory updates applied

Goal: Persistent strategic commitments captured in operator memory directory
Killer items:
- project_val_bay_cost_envelope.md (doc 23 R136)
- project_msp_vertical.md (doc 25 R148 + R232 + R243 + R252 + R271 + R281)
- project_opscenter_design.md (doc 28 R173)
- project_work_tracking_surface.md (doc 30 R187)
- project_editor_collaboration_substrate.md (doc 31 R196)
- project_palantir_competitive_intel.md (doc 32 R205)
- project_substrate_design_discipline.md (doc 33 R216)
- project_problem_solving_blueprint.md (doc 34 R220)
- project_business_central_sor.md (doc 38 R261)
Acceptance: 9 files exist in C:\Users\ClydeNelsen\.claude\projects\C--Users-ClydeNelsen-valos-next\memory\ + MEMORY.md index updated
Status: ❌

M0.5 — Commit + push + SCP this batch

Goal: 16 ADRs + 2 checklist specs committed + pushed + SCP'd to VM
Killer items:
- git add 18 files (16 ADRs + 2 checklists)
- Commit with comprehensive message + Next steps block
- git push to remote
- SCP 18 files to valosadmin@valos-hq-gpu:/home/valosadmin/valos-next/d_mission-control/specs/
Acceptance: Commit lands; remote sync verified; VM file count matches
Status: ❌

⏸️ M0.P — Pause point: Pipeline lockup verification

All 40 research docs + 16 ADR drafts + 2 checklist specs on VM
9 memory entries present + indexed in MEMORY.md
git status clean on claude/silly-grothendieck-5cb6f5
Operator-team review window scheduled

Acceptance criteria for M0 overall: All sub-milestones ✅; ready for ADR approval window in M1.

Owner: Claude Cowork (this session)

Milestone M_up — val-up Engine + Public Launch + val-forge Multi-Repo ADE

Goal: val-up operational at up.valtience.com + val-forge multi-repo ADE extension live. Bootstraps Mission Control orchestration + client onboarding for all subsequent milestones. Per ADR-024 + ADR-025.

Sub-milestones

M_up.1 — val-up Rust scaffolding

Goal: val-up Rust engine compiles + boots locally
Killer items:
- v_source/fusion-engines/engines/val-up/ created
- Cargo.toml with library borrows (val-factchain + val-graph + val-pulses + val-events + val-store + val-memory + val-skills + val-policy + val-config + val-llm + val-learning + val-cache + val-runtime + val-dispatch + val-sidecar + val-node NATS-local mode)
- axum HTTP server scaffold
- Local NATS-local broker via val-node library
- Local sled + postgres+pgvector for own substrate
Acceptance: cargo check clean; engine boots; /up/health returns 200
Depends on: M0 complete
Status: ❌

M_up.2 — val-forge Multi-Repo ADE extension

Goal: val-forge handles 4 ADE scopes per ADR-025
Killer items:
- Multi-repo orchestration logic in val-forge
- Per-repo credentials management (val-grid CA + Entra OAuth tokens)
- Per-tenant pipeline namespace
- mission.forge.repo.create.v1 + archive.v1 + upgrade.v1 Missions implemented
- Per-scope promoter approval workflow
Acceptance: Test multi-repo dispatch (dev-workspace + canonical scope tested with mock client repo)
Depends on: M_up.1
Status: ❌

M_up.3 — val-up frontend (Next.js + Tiptap + Hocuspocus)

Goal: Operator-team + client-onboarding frontend operational
Killer items:
- v_source/apps/val-up-frontend/ (or workspace package within val-up engine)
- Next.js + TypeScript scaffolding
- Tiptap editor integration (per ADR-023)
- Hocuspocus collaboration (per ADR-023; first concrete consumer)
- Tailwind + Radix UI components
- TanStack Query + Zustand state management
Acceptance: Frontend builds; basic Mission Control views render (5 MC docs interactive)
Depends on: M_up.1
Status: ❌

M_up.4 — Microsoft Entra OAuth + per-tenant isolation

Goal: Multi-tenant auth + per-tenant data segregation
Killer items:
- Microsoft Entra app registration per ValOS deployment
- Per-tenant OAuth 2.0 / OIDC flows
- val-policy ABAC capability binding for tenant isolation
- Per-tenant Decision Card ledger isolation in val-up storage
Acceptance: 2 tenants tested (Valtience operator-team tenant + mock client tenant); cross-tenant access denied
Depends on: M_up.3
Status: ❌

M_up.5 — Decision Card ledger UI + emission wizard

Goal: Per-tenant Decision Card ledger UI + 11 card template wizard per master-decision-card-spec
Killer items:
- Decision Card ledger browser (filter by type / status / date / tenant)
- 11 card template wizard (adr / sub-milestone / pause-point / strategic-commitment / intake-triage / state-flip / pipeline-branch / engagement-decision / vertical-decision / failure-recovery / memory-update)
- Card emission → val-up local ledger + NATS-local broker
- MCP push to HQ val-ledger when HQ available
Acceptance: Test card emission cycle: Draft → Proposed → Decided → Executed → Verified
Depends on: M_up.4
Status: ❌

M_up.6 — Engagement Wizard runtime (per ADR-013)

Goal: 7-phase Engagement Wizard operational for client onboarding
Killer items:
- Phase 1 Scope-assessment workflow
- Phase 2 Substrate provisioning (calls val-forge for per-client repo creation per ADR-025)
- Phase 3 Ring 3 vertical blueprint selection
- Phase 4 Microsoft-stack integration (per doc 38 — Business Central + Defender + Intune + Dataverse + Entra)
- Phase 5 Operator + technician training
- Phase 6 Soft-launch validation
- Phase 7 Go-live + monitoring
- 5-level maturity framework progression
Acceptance: Mock client engagement walks through 7 phases; Decision Cards emitted per phase
Depends on: M_up.5 + M_up.2 (val-forge for repo creation)
Status: ❌

M_up.7 — val-cargo MCP integration (HQ sync)

Goal: val-up MCP-connects to HQ val-cargo when HQ available
Killer items:
- MCP client in val-up (val-sidecar library)
- mcp/sync.ledger.push.v1 (Decision Cards → val-ledger b_facts)
- mcp/sync.ledger.pull.v1 (HQ-side cards merge)
- mcp/sync.entities.push.v1 (Mission Control entities → val-ontology)
- mcp/sync.pipeline.spawn.v1 (val-up → val-forge pipeline-branch dispatch)
- mcp/sync.pipeline.status.v1 (val-forge → val-up status streaming)
Acceptance: Test HQ-connected sync; Decision Card emit propagates to HQ val-ledger; pipeline branch spawned via val-forge
Depends on: M_up.5 + M_up.2
Status: ❌

M_up.8 — Public launch at up.valtience.com

Goal: val-up cloud-hosted + publicly accessible
Killer items:
- Azure VM deployment alongside valos-hq-gpu (sibling process)
- Public DNS up.valtience.com (Cloudflare or similar)
- TLS via Let's Encrypt (Caddy reverse proxy)
- Entra OAuth production tenant
- First Valtience operator-team account onboarded
- First mock client tenant onboarded via 7-phase Wizard
Acceptance: https://up.valtience.com reachable; Valtience operator-team can log in; mock client onboarding completes
Depends on: M_up.4 + M_up.6 + M_up.7
Status: ❌

⏸️ M_up.P — val-up + multi-repo ADE production readiness

All 8 sub-milestones complete + smoke green
M_up.8 public launch verified at up.valtience.com
At least 1 mock client tenant onboarded successfully through 7-phase Wizard
Decision Card lifecycle (Draft → Verified) tested across all 11 card types
val-forge multi-repo dispatch verified (mock client repo created via Engagement Wizard Phase 2)
Cross-tenant isolation verified (Valtience operator-team cannot see client data without elevated scope)

Acceptance criteria for M_up overall:

val-up operational + public-launched
val-forge multi-repo ADE operational
Mission Control orchestration fully interactive (5 MC docs + Decision Card ledger + ADE Factory dispatch)
Engagement Wizard runtime ready for first real client onboarding (SBR per M6)

Dependencies: M0 complete (pre-flight + 9 memory updates + commit + push + SCP) Owner: Claude Cowork (Rust + frontend); Operator (Azure deployment + Entra config + DNS + carrier-style decisions); Operator-team (testing + verification)

Why M_up sequenced before M1:

val-up bootstraps all subsequent Mission Control work
ADR review window (M1) benefits from interactive ADR browser in val-up
Pre-flight discipline applies to val-up itself (operator-team can mock-test before ADR review)

Milestone 1 — ADR Approval Window: Substrate-Primitive Lock (8 ADRs)

Goal: 8 substrate-primitive ADRs flip Proposed → Accepted. Three-way block-schema cross-lock verified.

Sub-milestones

M1.1 — ADR-007 Missions review + lock

Goal: Mission decomposition primitive accepted
Killer items:
- Verify Mission decomposition (Orchestrator + Workers + Validators) clear
- Verify Dynamic-Worker-roles variant scope agreed
- Verify Initiative-vocabulary lock per doc 28 R171
- Verify 5-corroboration evidence sufficient
- Operator signoff recorded
Acceptance: Status flip 🎯 → ✅; cross-doc updates to dependent ADRs propagated
Status: 🎯

M1.2 — ADR-015 Scenarios review + lock

Goal: Scenarios as val-ontology substrate primitive accepted
Killer items:
- Verify val-ontology storage routing supports scenarios primitive
- Verify 6 first concrete consumers acknowledged (QMS NCR+CAPA + supplier onboarding + audit + MSP MDR + Backup restore + Password rotation)
- Operator signoff recorded
Acceptance: Status flip; ADR-016 + ADR-019 cross-references confirmed
Status: 🎯

M1.3 — ADR-016 Transactions review + lock

Goal: Atomic multi-pulse dispatch primitive accepted
Killer items:
- Verify ACID-style scope clear (not Saga compensation)
- Verify val-ledger working-set staging design agreed
- Verify cross-engine timeout default (5 min) tunable
- Operator signoff
Acceptance: Status flip; first concrete consumers identified (ADR-019 Core transfer + ADR-017 val-ingest bulk + ADR-007 Mission promotion)
Status: 🎯

M1.4 — ADR-019 Context Cores review + lock (BROADEST cross-cutting)

Goal: Packageable engagement bundles primitive accepted
Killer items:
- Verify 12 directory archive structure complete
- Verify 6 lifecycle Missions (build/test/version/promote/rollback/transfer)
- Verify knowledge-node granularity hierarchy clear per doc 32 F210
- Verify 13 cross-pipeline surfaces acknowledged
- Operator signoff
Acceptance: Status flip; ADR-020 cross-lock (Cores + heartbeat) verified at M2.P
Status: 🎯

M1.5 — ADR-022 Canvas substrate-primitive review + lock (THREE-WAY)

Goal: JSON Canvas 1.0 spatial composition primitive accepted
Killer items:
- Verify JSON Canvas 1.0 spec adopted format-only (no Obsidian app dependency)
- Verify 8 archetype templates curated set
- Verify 5 consumer engines enumerated
- Operator signoff
Acceptance: Status flip; three-way block-schema cross-lock verification queued
Status: 🎯

M1.6 — ADR-023 Editor + Collaboration substrate review + lock (THREE-WAY)

Goal: Tiptap + Hocuspocus adoption accepted
Killer items:
- Verify Tiptap + Hocuspocus adoption (MIT-licensed)
- Verify 6 consumer surfaces enumerated
- Verify Hocuspocus Ring 0 Docker deployment strategy
- Verify Alga PSA Hocuspocus cross-validation (doc 40 F267) reviewed
- Operator signoff
Acceptance: Status flip; three-way cross-lock queued
Status: 🎯

M1.7 — ADR-010 val-block-renderer review + lock (THREE-WAY)

Goal: Multi-channel block rendering substrate accepted
Killer items:
- Verify 11 block kinds enumerated
- Verify 4+ rendering target backends scoped
- Verify block-schema sharing with Canvas + Editor substrate confirmed
- Operator signoff
Acceptance: Status flip; three-way cross-lock final-verified
Status: 🎯

M1.8 — ADR-017 val-ingest review + lock

Goal: Document ingestion substrate accepted
Killer items:
- Verify MarkItDown integration scope
- Verify 3 extraction modes (judgment / structured / video)
- Verify distinct from Hydrator pattern (per doc 32 F203)
- Operator signoff
Acceptance: Status flip; Hydrator pattern scope captured for future Mission categories
Status: 🎯

⏸️ M1.P — Three-way block-schema cross-lock verification

Critical gating before any of ADR-010 / ADR-022 / ADR-023 implementation:

Block schema spec written in single canonical location
Renderer block kinds align with Canvas archetypes align with Editor authoring kinds
Schema versioning strategy locked (coral growth pattern)
All three ADRs reference same block schema spec
Schema change-control process locked

Acceptance criteria for M1 overall:

8 ADRs ✅ status
Block-schema spec written + cross-referenced
Operator commitment captured per ADR

Dependencies: M0 complete Owner: Operator + Operator-team (review); Claude Cowork (drafting / cross-doc updates)

Milestone 2 — ADR Approval Window: Capability + Pattern Lock (8 ADRs)

Goal: 8 remaining ADRs flip Proposed → Accepted. ADR-019 + ADR-020 cross-lock verified.

Sub-milestones

M2.1 — ADR-009 Inbound MCP review + lock

Goal: val-cargo gateway scope accepted
Killer items:
- Verify gateway scope (inbound + outbound + REST/OData adapters)
- Verify 6 Microsoft surfaces integration plan
- Verify per-tenant OAuth 2.0 flow architecture
- Operator signoff
Acceptance: Status flip; Microsoft-stack-aligned positioning locked
Status: 🎯

M2.2 — ADR-011 val-forge integration review + lock

Goal: Path C hybrid integration accepted
Killer items:
- Verify Path C hybrid (vendor + Rust daemon port + delegate to ValOS engines)
- Verify val-forge AI panel composition modes (spatial / editor / AI-orchestrated)
- Operator signoff
Acceptance: Status flip; val-forge in-flight scope aligned
Status: 🎯

M2.3 — ADR-012 Device provisioning review + lock

Goal: val-grid + Rufus + USB sidecar accepted
Killer items:
- Verify rejection of Microsoft Autopilot (substrate-ownership thesis)
- Verify 3 provisioning paths (online / USB sidecar / air-gapped)
- Operator signoff
Acceptance: Status flip; doc 17 §3 row 5 corroboration confirmed
Status: 🎯

M2.4 — ADR-013 Engagement Wizard review + lock

Goal: 5-level maturity framework accepted
Killer items:
- Verify 5-level maturity (Level 0 manual → Level 4 self-evolving)
- Verify 8 Wizard instances acknowledged
- Verify per-vertical Wizard variants supported
- Operator signoff
Acceptance: Status flip; ADR-013 templates available for M6 SBR + M9 MSP scoping
Status: 🎯

M2.5 — ADR-014 Legacy Modernization Mission review + lock

Goal: Army + Foundry pattern accepted at SMB scope
Killer items:
- Verify 7-phase Mission template (Inventory / Mapping / Bridge / Migration / Validation / Cutover / Audit retention)
- Verify engagement learning loop discipline (append-only)
- Operator signoff
Acceptance: Status flip
Status: 🎯

M2.6 — ADR-018 Marketing Automation review + lock

Goal: Cross-vertical capability layer accepted
Killer items:
- Verify cross-vertical capability layer (3rd alongside QMS + Problem-Solving)
- Verify 8 capability scope areas
- Operator signoff
Acceptance: Status flip; cross-vertical pattern count locked at 3
Status: 🎯

M2.7 — ADR-020 Heartbeat watchdog review + lock

Goal: val-orchestrator background process accepted
Killer items:
- Verify two trigger types (Interval + Plateau)
- Verify 3 corroborations evidence (Coral + Automaton + K4D)
- Verify cross-lock with ADR-019 (consolidation → Core knowledge nodes)
- Operator signoff
Acceptance: Status flip; ADR-019 + ADR-020 cross-lock final-verified at M2.P
Status: 🎯

M2.8 — ADR-021 caveman-shrink filter review + lock

Goal: val-cargo MCP middleware compression accepted
Killer items:
- Verify per-traffic-class tier policy (Full default / Lite high-stakes / Ultra bulk-read)
- Verify ~65% token reduction multiplier on doc 23 F130 cost envelope
- Operator signoff
Acceptance: Status flip; cost envelope mathematics locked
Status: 🎯

⏸️ M2.P — ADR-019 + ADR-020 cross-lock verification

Cores + Heartbeat tightly coupled — heartbeat consolidation Missions emit b_facts that feed Core knowledge-node accretion:

Heartbeat consolidation event → knowledge-node update protocol locked
Knowledge-node granularity consistent across both ADRs
Cross-references in both ADR docs synchronized

Acceptance criteria for M2 overall:

16 of 16 ADRs total now locked
ADR queue (per pipeline state) emptied
ADR-019 + ADR-020 cross-lock verified

Dependencies: M1 complete Owner: Operator + Operator-team (review); Claude Cowork (cross-doc updates)

Milestone 3 — Substrate-Primitive Library Build-Out

Goal: 5 substrate-primitive Rust libraries / engines compile + smoke green.

Sub-milestones

M3.1 — val-canvas Rust library

Goal: Spatial composition library operational
Killer items:
- v_source/fusion-engines/libraries/val-canvas/ created
- JSON Canvas 1.0 schema validation
- 6 layout algorithms (dagre / grid / radial / force-directed / linear / auto-detect)
- 8 archetype template library
- Canvas read/write API
- Unit tests + property tests for layout determinism
Acceptance: cargo check clean; smoke: round-trip JSON Canvas → archetype layout → JSON Canvas
Depends on: M1.5 (ADR-022 locked)
Status: ❌

M3.2 — val-editor Rust library

Goal: Editor authoring substrate library
Killer items:
- v_source/fusion-engines/libraries/val-editor/ created
- Tiptap JSON document handling
- Schema validation (block-schema cross-lock per M1.P)
- val-ledger b_fact emission per edit
- val-policy capability binding integration
Acceptance: cargo check clean; smoke: Tiptap document → block-schema validate → b_fact emit
Depends on: M1.6 + M1.P (ADR-023 locked + block-schema spec)
Status: ❌

M3.3 — Hocuspocus Ring 0 Docker

Goal: Collaboration server operational alongside val-editor
Killer items:
- Add valos-hocuspocus to docker-compose.core.yml
- Node.js Hocuspocus server configured
- Y.js/CRDT persistence wired
- val-editor library connects to Hocuspocus
Acceptance: docker inspect reports running; smoke: 2-user concurrent edit → CRDT merge → consistent state
Depends on: M3.2
Status: ❌

M3.4 — val-block-renderer library

Goal: Multi-channel block rendering library
Killer items:
- v_source/fusion-engines/libraries/val-block-renderer/ created
- 11 block kinds implemented
- 4 rendering backends (markdown / HTML / PDF / SVG)
- Cross-channel rendering tests
Acceptance: Smoke: block JSON → 4 outputs (markdown / HTML / PDF / SVG)
Depends on: M1.7 + M1.P
Status: ❌

M3.5 — val-ingest engine

Goal: Document ingestion engine operational
Killer items:
- v_source/fusion-engines/engines/val-ingest/ created
- MarkItDown integration
- 3 extraction modes implemented (judgment / structured / video)
- DOCX / PDF / PPTX / XLSX / image OCR / audio transcription
- b_fact emission with provenance chain
Acceptance: Smoke: DOCX file → MarkItDown → markdown + b_facts emitted
Depends on: M1.8
Status: ❌

⏸️ M3.P — Substrate-primitive library smoke verification

All 5 smokes green per sub-milestone acceptance criteria
Inspector skill (system.inspector.v1) clean walk
PLATFORM.md baseline row updated for each new library / engine

Acceptance criteria for M3 overall: 5 libraries/engines compile + boot + pass smoke; PLATFORM.md baseline rows updated

Dependencies: M1 + M2 complete Owner: Claude Cowork

Milestone 4 — Peer-Service Engines: val-policy + val-fab + val-orchestrator Completion

Goal: Three engines complete; Part 1 → Part 2 gate passed.

Sub-milestones

M4.1 — val-policy engine scaffolding

Goal: val-policy engine compiles + boots
Killer items:
- v_source/fusion-engines/engines/val-policy/ created
- Engine scaffolding (NATS routing per val-node; systemd unit; smoke)
- Skill governance + signing
- Fleet-wide distribution
Acceptance: Engine boots; /policy/health 200; smoke green
Depends on: M3 complete
Status: ❌

M4.2 — val-policy capability binding (5 capabilities)

Goal: 5 capabilities locked (Reads / Builds / Grows / Evolves / Computes per doc 33 R210)
Killer items:
- Reads capability implementation
- Builds capability implementation
- Grows capability implementation
- Evolves capability implementation
- Computes capability implementation (5th, derived properties per doc 33 R210)
- Per-skill capability assignment via frontmatter
Acceptance: Test skill dispatch with all 5 capabilities gated correctly
Depends on: M4.1
Status: ❌

M4.3 — val-policy ABAC extension

Goal: Attribute-based access control alongside RBAC (per doc 40 F269 + R276)
Killer items:
- ABAC rule engine
- Per-tenant attribute predicates
- Multi-tenant isolation enforcement
Acceptance: Test multi-tenant scenario with tenant-scope ABAC rules; cross-tenant access denied
Depends on: M4.2
Status: ❌

M4.4 — val-policy DefenseClaw filter list

Goal: Write-path admission control (per doc 27 F161 + R162)
Killer items:
- PII filter
- Prompt injection filter
- Length filter (per doc 23 F130 cost envelope discipline)
- Malicious URL filter
Acceptance: 4 filters tested + applied per-skill via val-policy capability
Depends on: M4.3
Status: ❌

M4.5 — Cost-threshold capability gate

Goal: Mission cost limits (per doc 27 F162 R138)
Killer items:
- Per-Mission cost cap (operator-tunable)
- Deployment-wide cost ceiling
- mission.cost-breach.v1 event emission when threshold approached
Acceptance: Cost-breach event emitted when test Mission approaches threshold
Depends on: M4.4
Status: ❌

M4.6 — Blueprint engine (val-fab) scaffolding

Goal: val-fab engine compiles + boots
Killer items:
- v_source/fusion-engines/engines/val-fab/ created
- Manifest registry
- Slot resolver
- Widget binding contract
- Mount mechanism
Acceptance: Engine boots; sample blueprint validates against meta/TAXONOMY at install time
Depends on: M4.1
Status: ❌

M4.7 — Three-layer model support

Goal: val-fab supports base + vertical + client three-layer blueprint composition
Killer items:
- Base blueprint loader
- Vertical blueprint extension mechanism
- Client config thin-layer support
Acceptance: Test 3-layer composition: base + vertical + client → composed blueprint
Depends on: M4.6
Status: ❌

M4.8 — val-orchestrator extension: watcher kinds

Goal: Remaining watcher kinds operational (PLATFORM.md current state: only fleet_host)
Killer items:
- comms watcher kind
- finance watcher kind
- identity watcher kind
Acceptance: All watcher kinds emit anomaly facts on test inputs
Depends on: M4.1
Status: ❌

M4.9 — val-orchestrator extension: Wizard + Matter + Decision + Gate primitives

Goal: Multi-step OODA primitives per ADR-013 + AGENTS.md autonomy gates
Killer items:
- Wizard primitive (multi-step OODA per ADR-013 engagement Wizard 5-level)
- Matter primitive (entity kind in val-ontology; lifecycle in val-orchestrator)
- Decision primitive
- Gate primitive
Acceptance: Sample Wizard executes 5-step OODA; sample Matter persists state across pulses
Depends on: M4.8
Status: ❌

M4.10 — val-orchestrator extension: Mission decomposition + dynamic Worker roles

Goal: ADR-007 Mission decomposition operational (Orchestrator + Workers + Validators)
Killer items:
- Mission template loader
- Worker dispatch (parallel + serial)
- Validator gating
- Dynamic-Worker-roles variant (per doc 34 F226 + ADR-007 R218)
Acceptance: Test Mission with 5 dynamically-instantiated Worker roles completes; validators gate promotion
Depends on: M4.9
Status: ❌

M4.11 — Heartbeat watchdog implementation

Goal: val-orchestrator heartbeat watchdog operational per ADR-020
Killer items:
- mission.heartbeat.v1 background Mission category
- Interval trigger (every N pulses; tunable)
- Plateau trigger (context pressure 95% + no-progress detection + loop detection)
- Per-Mission tunable cadence + thresholds
- b_fact emission per trigger firing
Acceptance: Test Mission with interval trigger fires consolidation prompt; plateau trigger fires escalation
Depends on: M4.10
Status: ❌

M4.12 — val-agent OODA generalization

Goal: val-agent OODA operates beyond chat-only (per PLATFORM.md Master Checklist Phase 1.2)
Killer items:
- Generalize OODA to arbitrary pulses (not just chat)
- Subscribe to valos.skill.updated.> for hot-reload
Acceptance: val-agent OODA processes button-press + scheduled-trigger + inbound-email + sensor-event pulse types
Depends on: M4.5 (val-policy gates) + M4.2 (Computes capability for OODA logic)
Status: ❌

M4.13 — val-bay hot-reload

Goal: val-bay subscribes to valos.skill.updated.> for runtime skill reload
Killer items:
- Subscription wired
- Skill registry invalidation on update
- No-restart skill swap verified
Acceptance: Modify a skill markdown; val-bay registry refreshes; new dispatch uses updated skill
Depends on: M4.1 (val-policy active for hot-reload validation)
Status: ❌

M4.14 — val-desk slot system + chrome chassis

Goal: val-desk slots queryable as Core/Endpoint API; chrome repackaged for blueprint hosting
Killer items:
- Declare slots as queryable Core/Endpoint API
- Codify widget primitive contract (widget = pulse hook at blueprint binding)
- Repackage chrome chassis to host blueprints (rip operational behavior out of v_source/apps/valdesk/frontend/src/chrome.rs)
Acceptance: Sample blueprint mounts into val-desk via slot system; widget pulse fires on user interaction
Depends on: M4.7 (val-fab three-layer model)
Status: ❌

⏸️ M4.P — Part 1 → Part 2 gate (operator approval required)

Per PLATFORM.md Master Checklist locked rule (operator 2026-05-07): "We build in two parts — technical first and the logical (business). Part 2 cannot begin until Part 1's Core/HQ + Core/Endpoint + essential Peer Services (val-ingest, Policy engine, Blueprint engine) are locked."

val-ingest engine ✅ (per M3.5)
val-policy engine ✅ (per M4.1-M4.5)
Blueprint engine (val-fab) ✅ (per M4.6-M4.7)
Part 1 Phase 1.2 complete (M4.12 + M4.13 + M4.14)
All Phase 1.3 essentials green

Operator approval gate (explicit signoff required): "Part 2 unlocked" — recorded in writing before any Part 2 work begins.

Acceptance criteria for M4 overall:

3 engines compile + boot + pass smoke
val-policy enforces capability binding on test skill dispatch
val-fab validates sample blueprint against TAXONOMY
val-orchestrator handles multi-step Mission per ADR-007
PLATFORM.md baseline rows updated
Inspector clean walk
Operator approval recorded for Part 1 → Part 2 transition

Dependencies: M3 complete; M2 ADRs locked Owner: Claude Cowork (Rust); Operator (approval gate)

Milestone 5 — Business Central as System of Record + val-cargo Integration

Goal: Microsoft Dynamics 365 Business Central operational as ValOS SoR. 3 val-cargo skills + integration patterns wired.

Sub-milestones

M5.1 — Microsoft Entra app + OAuth 2.0

Goal: Per-deployment Entra app registration + per-tenant OAuth flow
Killer items:
- Entra app registration per ValOS deployment
- Per-tenant OAuth 2.0 client credentials flow
- Token refresh + caching in val-grid (per PLATFORM.md row 12 token-exchange proxy)
Acceptance: OAuth flow tested with 2 separate Microsoft tenants; tokens cached + refreshed
Depends on: M4 complete
Status: ❌

M5.2 — val-cargo `bc.read.v1` skill

Goal: Business Central CRUD reads via val-cargo
Killer items:
- Skill markdown spec authored in v_platform/skills/
- val-policy "Reads" capability gate
- Single-record read endpoint
- List read with pagination
- Smoke test against Business Central sandbox
Acceptance: Skill dispatch reads customer record from Business Central sandbox; result matches expected
Depends on: M5.1
Status: ❌

M5.3 — val-cargo `bc.write.v1` skill

Goal: Business Central CRUD writes via val-cargo (gated by val-policy "Builds")
Killer items:
- Skill markdown spec authored
- val-policy "Builds" capability gate
- Single-record write endpoint
- Batch write
- Smoke against sandbox
Acceptance: Skill dispatch creates invoice in sandbox; returns bc_invoice_id; b_fact emitted with reference
Depends on: M5.2
Status: ❌

M5.4 — val-cargo `bc.query.v1` skill

Goal: OData query against Business Central via val-cargo
Killer items:
- Skill markdown spec authored
- val-policy "Reads" capability gate
- OData query parser
- Result streaming for large queries
- Smoke
Acceptance: OData filter query returns expected records from sandbox
Depends on: M5.2
Status: ❌

M5.5 — Entity reference pattern

Goal: val-ontology Client entity references Business Central customer record by bc_id
Killer items:
- val-ontology schema extension: bc_id foreign-key field
- Client entity creation flow with bc_id assignment
- Resolve-via-val-cargo at runtime (when operator queries client details)
Acceptance: Operator-facing Client view shows name + bc_id + resolved current BC data (address / AR balance) via val-cargo round-trip
Depends on: M5.2 + M5.4
Status: ❌

M5.6 — b_fact emission pattern with Business Central transaction refs

Goal: Missions touching transactional data emit b_facts with bc_*_id references
Killer items:
- b_fact schema extension for Business Central transaction-reference fields
- Pattern documented in val-cargo skill specs
- Example: MDR incident → val-cargo bc.write.v1 (invoice) → b_fact mdr.incident.billed.v1 with bc_invoice_id
Acceptance: Test b_fact emitted with valid bc_*_id; audit chain via parent_fact_ids preserves transaction reference
Depends on: M5.3
Status: ❌

M5.7 — Cache + sync pattern

Goal: High-frequency-access entities cached in val-ontology with periodic sync
Killer items:
- mission.bc.sync.client-master.v1 Mission (scheduled per 15 min default)
- mission.bc.sync.product-catalog.v1
- mission.bc.sync.open-projects.v1
- Operator-tunable cadence per use case
Acceptance: Test sync Mission updates val-ontology Client entities; cache freshness verified
Depends on: M5.5
Status: ❌

M5.8 — Multi-currency + multi-company support

Goal: Business Central multi-company within tenant supported (per doc 38 Q178)
Killer items:
- bc_company_id field in val-ontology entities
- Per-company scope enforcement in val-policy
- Multi-currency handling in b_fact financial KPIs
Acceptance: Test 2-company scenario; per-company queries return scoped results
Depends on: M5.5
Status: ❌

⏸️ M5.P — Microsoft licensing pass-through commercial model decision

Operator decision: pass-through to client OR absorb in ValOS engagement fee
Pricing-model surface decision per Ring 4 client config
Memory project_business_central_sor.md reflects commercial model choice

Acceptance criteria for M5 overall:

3 val-cargo skills compile + smoke green
val-ontology Client entity references Business Central customer (round-trip)
Integration patterns documented
Per-tenant OAuth flow tested with 2 tenants
Commercial model decision recorded

Dependencies: M4 complete; Microsoft Entra app + Business Central sandbox tenant available Owner: Claude Cowork (Rust + skill authoring); Operator (Microsoft tenant procurement + commercial model decision)

Milestone 6 — SBR First Production Engagement (v1)

Goal: ValOS deployed for Slater Byrne Recoveries (debt-recovery-au; first production client). 30-day delivery.

Sub-milestones

M6.1 — Collections base blueprint

Goal: Universal collections base blueprint scoped + authored
Killer items:
- v_platform/skills/system/blueprints/collections/ scaffolded
- Core collection workflows (intake / contact / payment-plan / escalation / closure)
- val-policy capability bindings per workflow
- Validates against meta/TAXONOMY
Acceptance: Blueprint installs cleanly; sample collection workflow executes
Depends on: M5 complete
Status: ❌

M6.2 — Field_services base blueprint

Goal: Universal field-services base blueprint
Killer items:
- Scaffolded
- Core field workflows (dispatch / route / on-site / close)
- val-policy bindings
- TAXONOMY validation
Acceptance: Blueprint installs; sample field workflow
Depends on: M6.1
Status: ❌

M6.3 — Trust_reconciliation base blueprint

Goal: Trust accounting reconciliation base blueprint
Killer items:
- Scaffolded
- Trust account workflow (receipt / hold / disburse / reconcile)
- AU jurisdiction trust rules
- Privacy Act 1988 compliance binding (per doc 2 §10 F11)
Acceptance: Blueprint installs; sample reconciliation workflow
Depends on: M6.1
Status: ❌

M6.4 — Debt-recovery-au vertical blueprint

Goal: AU debt-recovery vertical blueprint composes base blueprints + AU-specific extensions
Killer items:
- v_platform/skills/system/blueprints/vertical/debt-recovery-au/
- AU jurisdiction rules (per-state collection laws)
- Privacy Act 1988 compliance framework binding
- Court-action workflows
Acceptance: Vertical blueprint composes with collections + field_services + trust_reconciliation
Depends on: M6.1 + M6.2 + M6.3
Status: ❌

M6.5 — SBR Ring 4 client blueprint

Goal: SBR-specific client configuration + brand pack
Killer items:
- v_clients/sbr/blueprints/<operator>/<device>/ scaffolded
- SBR brand pack (per doc 10 R49) — branding + tone
- SBR Business Central tenant config (per M5)
- Per-operator surfaces (Tasks + Metrics + Initiatives per doc 28)
Acceptance: Ring 4 installs cleanly; SBR operators see branded UI
Depends on: M6.4
Status: ❌

M6.6 — SBR Engagement Core

Goal: First concrete consumer of ADR-019 — SBR Engagement Core produced
Killer items:
- mission.core.build.v1 executed against SBR engagement
- 12-directory archive populated (per ADR-019 + batch 5-6 extensions)
- core.engagement.sbr-debt-recovery.v1.zip artifact produced
Acceptance: Core archive valid; round-trip (export + import) verified
Depends on: M6.5
Status: ❌

M6.7 — SBR-specific Problem-Solving consumers

Goal: Complex-debtor-case scenarios authored
Killer items:
- complex-debtor-case.v1 scenario per ADR-015
- Worker roles: legal-research + skip-tracing + payment-history-analysis + risk-assessment
- Dynamic-Worker-roles ADR-007 variant per doc 34 F226
Acceptance: Sample complex case dispatched; multi-agent annealment completes; plan produced
Depends on: M4.10 + M6.4
Status: ❌

M6.8 — SBR entity resolution Mission

Goal: Debtor reconciliation via entity resolution per doc 33 R212
Killer items:
- mission.resolution.v1 background Mission per doc 32 F202
- Per-debtor canonical entity creation
- Multi-source debtor record merge logic
Acceptance: Test scenario: 3 debtor records (John Smith Sr / J. Smith / JOHN SMITH) resolved to single canonical entity
Depends on: M4.11 (heartbeat for background curation Missions) + M6.5
Status: ❌

M6.9 — Operator team training + Wizard onboarding

Goal: SBR account managers + technicians onboarded
Killer items:
- Engagement Wizard executed per ADR-013 (SBR variant)
- Operator training (~18 SBR team members)
- Maturity Level 1 (substrate-assisted) reached
- Maturity Level 2 (substrate-orchestrated) reached
Acceptance: 18+ team members trained; maturity-level scorecard shows L2 across operators
Depends on: M6.5 + M6.7
Status: ❌

⏸️ M6.P — 30-day delivery soft-launch validation

Per ADR-013 Engagement Wizard Phase 6 — soft-launch before go-live:

All Ring 3 + Ring 4 blueprints validate against meta/TAXONOMY
val-policy capability bindings tested
Operator-facing workflows tested with SBR sample data
Engagement Core round-trip verified
Operator approval recorded for go-live

Acceptance criteria for M6 overall:

SBR processes real debtor cases via ValOS (go-live)
Engagement Core captured at 30-day milestone
Maturity Level 2 verified
First production revenue recorded

Dependencies: M5 complete (Business Central operational) Owner: Operator-team (SBR account management + technician training); Claude Cowork (blueprint authoring + Mission scoping)

Milestone 7 — val-track First-Party Engine (Work-Tracking)

Goal: ValOS-native "Linear-equivalent" engine operational. Substrate-ownership at work-tracking layer preserved.

Sub-milestones

M7.1 — val-track engine scaffolding

Goal: val-track engine compiles + boots
Killer items:
- v_source/fusion-engines/engines/val-track/ created
- Engine scaffolding (NATS routing; systemd unit; smoke)
Acceptance: /track/health 200; smoke green
Depends on: M4 complete (val-policy + val-fab gate Mission dispatch)
Status: ❌

M7.2 — work_item primitive (substrate-primitive decision)

Goal: work_item as 8th substrate-primitive layer member (per doc 30 Q134)
Killer items:
- Operator decision: work_item as primitive OR compose from b_facts
- If primitive: ADR-024 spec required
- val-ontology schema extension for work_item
- Primitive registration in substrate layer
Acceptance: work_item entity creates / reads / updates via val-policy capability gates
Depends on: M7.1
Status: ❌

M7.3 — 11 Linear-equivalent semantic categories

Goal: All 11 categories per doc 30 F182 implemented (or v1-prioritized subset)
Killer items:
- Work items (stories / epics / tasks / sub-tasks hierarchy)
- Statuses (todo / in-progress / in-review / done / cancelled — operator-configurable)
- Assignees + reviewers (single-assignee + multi-reviewer)
- Cycles / sprints
- Projects
- Roadmaps
- Custom fields + labels
- Filters + saved views
- Activity history + comments
- Code integration (val-forge pipeline branch linkage)
- External work-source mirroring (Linear / Jira / GitHub Issues / Asana)
Acceptance: All 11 categories testable via API; sample work item progresses through full lifecycle
Depends on: M7.2
Status: ❌

M7.4 — val-desk OpsCenter val-track surface

Goal: 4th OpsCenter mode (alongside Tasks + Metrics + Initiatives + Canvas)
Killer items:
- OpsCenter val-track mode UI
- Kanban view
- Roadmap view
- Backlog view
- Cross-consumer with val-forge pipeline branches
Acceptance: Operator can view + manipulate work items in val-desk
Depends on: M7.3
Status: ❌

M7.5 — Vocabulary lock

Goal: Operator-facing triad locked (per doc 30 R185)
Killer items:
- valos-reference.md §48 updated: Work items < Initiatives (Missions) < Roadmap
- Internal architecture vocabulary preserved (Mission per ADR-007)
Acceptance: Vocabulary register updated; cross-doc references align
Depends on: M7.4
Status: ❌

M7.6 — MSP-toolstack cross-cuts

Goal: val-track integrates with MSP-toolstack capability layers
Killer items:
- MDR alerts auto-create val-track tickets (per doc 37 F244 + doc 30 R193)
- RMM-triggered remediation creates val-track work items (per doc 35)
- Backup failure auto-creates tickets (per doc 36)
- Password rotation events linked (per doc 39)
Acceptance: All 4 cross-cuts emit val-track entities on test triggers
Depends on: M7.4 + (M9 partial — MSP capabilities available)
Status: ❌

⏸️ M7.P — work_item-as-primitive decision verification

Decision recorded: primitive vs composition
If primitive: ADR-024 drafted + locked
Substrate-primitive layer count update (10 → 11 if added)

Acceptance criteria for M7 overall:

val-track engine operational
11 semantic categories (or v1 subset) implemented
val-desk OpsCenter val-track mode operational
MSP-toolstack cross-cuts wired
Memory project_work_tracking_surface.md updated

Dependencies: M6 complete (SBR validates substrate before val-track) Owner: Claude Cowork (Rust); Operator (work_item-primitive decision)

Milestone 8 — val-host Engine (VPS / DNS / Web Hosting)

Goal: Net-new ValOS hosting capability layer operational. Per-client DNS + web hosting + certificate management.

Sub-milestones

M8.1 — Engine vs val-grid extension decision

Goal: Operator decision on architectural scope
Killer items:
- Operator decision: new val-host engine OR val-grid scope extension
- If new engine: ADR-025 spec required
- If val-grid extension: val-grid scope-creep risk vs cohesion tradeoff analyzed
Acceptance: Decision recorded; ADR-025 drafted if new engine
Depends on: M7 complete (val-track as first-party engine reference)
Status: ❌

M8.2 — val-host (or extension) scaffolding

Goal: Engine / extension compiles + boots
Killer items:
- Codebase scaffolded
- Engine scaffolding (NATS routing; systemd unit; smoke)
Acceptance: /host/health 200 (or val-grid handles via extension)
Depends on: M8.1
Status: ❌

M8.3 — Per-client DNS management

Goal: Per-tenant DNS configuration + updates
Killer items:
- DNS record CRUD operations
- Per-tenant isolation
- Cross-cut with val-cargo external DNS provider integration (M8.6 / M8.7)
Acceptance: Test client DNS records created + updated + verified
Depends on: M8.2
Status: ❌

M8.4 — Web hosting

Goal: Caddy reverse proxy + static-site hosting
Killer items:
- Caddy reverse proxy configured
- Static-site hosting (per-client landing pages + portals)
- Reverse proxy to per-client backends
Acceptance: Test client site deployed + accessible at custom domain
Depends on: M8.3
Status: ❌

M8.5 — Certificate management

Goal: Let's Encrypt automation
Killer items:
- Let's Encrypt ACME client integration
- Certificate auto-renewal
- Cross-cut with val-grid CA for internal cert chain
Acceptance: Test cert issued + auto-renewed before expiration
Depends on: M8.4
Status: ❌

M8.6 — Cloudflare API integration

Goal: Cloudflare as DNS provider via val-cargo MCP
Killer items:
- Cloudflare API skill (val-cargo)
- DNS record sync between val-host and Cloudflare
Acceptance: Test record propagates from val-host → Cloudflare → resolves correctly
Depends on: M8.3 (val-host) + M5 (val-cargo external integration)
Status: ❌

M8.7 — AWS Route 53 integration

Goal: AWS Route 53 as alternative DNS provider
Killer items:
- AWS Route 53 skill (val-cargo)
- DNS sync from val-host
Acceptance: Test record propagates to Route 53 + resolves
Depends on: M8.3 + M5
Status: ❌

⏸️ M8.P — 2-client deployment test

2 client deployments tested with per-client DNS + hosting
Certificate auto-renewal verified
Cross-cut with val-grid CA preserved

Acceptance criteria for M8 overall:

val-host (or val-grid extension) operational
2 client deployments tested
Memory updated

Dependencies: M7 complete (val-track as reference) Owner: Claude Cowork (Rust); Operator (engine vs extension decision)

Milestone 9 — MSP-Vertical Scoping + 5 Sibling Docs → Specs

Goal: MSP-vertical Ring 3 blueprint operational. 5 MSP-toolstack sibling docs promoted to specs. First MSP engagement triggered.

Sub-milestones

M9.1 — MSP Ring 3 vertical blueprint scaffolding

Goal: msp-it-services vertical blueprint scoped
Killer items:
- v_platform/skills/system/blueprints/vertical/msp-it-services/ scaffolded
- 16-area capability sketch operationalized (per doc 25 F167)
- Composes with base blueprints (Problem-Solving + Marketing + QMS partial)
Acceptance: Blueprint validates against TAXONOMY; sample MSP workflow executes
Depends on: M6 complete (SBR validates substrate)
Status: ❌

M9.2 — Mesh transport (MeshCentral primary)

Goal: Mesh transport substrate operational per doc 35 F234
Killer items:
- valos-meshcentral Ring 0 docker (per L0.8)
- MeshCentral as agent-server transport for cloud/hybrid MSP
- NATS retained for on-prem-only
- val-grid registry knows agent transport per-client
Acceptance: MeshCentral handles agent traffic for test client; on-prem fallback works
Depends on: M9.1
Status: ❌

M9.3 — Cross-platform Rust agent v1

Goal: ValOS native Rust agent for endpoint coverage
Killer items:
- Cross-platform agent (Windows / macOS / Linux desktop v1)
- Mesh + NATS transport support via abstraction layer
- Endpoint inventory + monitoring + remote-access
- Per-OS install packaging
Acceptance: Agent installs on 3 platforms; reports to ValOS server via mesh
Depends on: M9.2
Status: ❌

M9.4 — Wazuh Ring 0 deployment

Goal: Wazuh SIEM substrate operational
Killer items:
- valos-wazuh Ring 0 docker (Wazuh manager + indexer + dashboard)
- Wazuh agents on managed endpoints
- Alert ingestion into val-ontology via val-cargo
Acceptance: Test endpoint security event detected + alert in val-ontology
Depends on: M9.3
Status: ❌

M9.5 — MDR via Microsoft Defender for Business

Goal: 6 MDR Mission categories operational per doc 37
Killer items:
- mission.mdr.ingest.v1 (Defender telemetry via Graph API)
- mission.mdr.triage.v1 (AI-powered alert triage)
- mission.mdr.hunt.v1 (threat hunting)
- mission.mdr.respond.v1 (incident response with RMM dispatch)
- mission.mdr.report.v1
- mission.mdr.hunt-team.v1 (Problem-Solving for complex incidents)
- 6 MDR ↔ RMM dispatch patterns (per doc 37 F245 + doc 39 password rotation)
Acceptance: Test detection → triage → response Mission → RMM action (isolate / patch / etc.)
Depends on: M9.4 + M5 (Microsoft tenant)
Status: ❌

M9.6 — Backup orchestration (Kopia + Duplicati)

Goal: 6 backup orchestration Missions operational per doc 36
Killer items:
- valos-kopia Ring 0 docker (per L0.10)
- valos-duplicati Ring 0 docker (alternative)
- 6 Missions: schedule / run / verify / report / restore / retention
- Per-client engine choice at Ring 4 config
Acceptance: Test client backup scheduled + executed + restored
Depends on: M9.3
Status: ❌

M9.7 — Password management (Vaultwarden)

Goal: 6 password management Missions operational per doc 39
Killer items:
- valos-vaultwarden Ring 0 docker (per L0.10)
- 6 Missions: provision / rotation-policy / audit / rotate / report / recovery
- MDR ↔ password rotation cross-cut (6th MDR dispatch pattern per doc 39 F259)
Acceptance: Test client vault provisioned; password rotation Mission completes
Depends on: M9.5
Status: ❌

M9.8 — PSA via val-track + Business Central + Alga PSA borrowable patterns

Goal: PSA-vertical-extension operational per doc 40
Killer items:
- val-track work-tracking core (per M7)
- Business Central billing/invoicing integration (per M5)
- Client portal val-desk extension (per doc 40 F270 + R277)
- 6 PSA Mission categories (per doc 40 F265)
- val-policy ABAC extension (per M4.3 + doc 40 F269)
Acceptance: Test MSP client engagement: ticket → time-entry → invoice flow
Depends on: M9.7 + M7
Status: ❌

M9.9 — 5 MSP-toolstack sibling docs → specs promotion

Goal: Research-doc → spec doc promotion (per F167 protocol)
Killer items:
- doc 35 RMM → d_mission-control/specs/msp-rmm.md
- doc 36 Backup → d_mission-control/specs/msp-backup.md
- doc 37 MDR → d_mission-control/specs/msp-mdr.md
- doc 39 Password Management → d_mission-control/specs/msp-password-management.md
- doc 40 PSA → d_mission-control/specs/msp-psa.md
Acceptance: 5 spec docs land in d_mission-control/specs/; original research docs archived to d_archive/
Depends on: M9.1 through M9.8 all complete
Status: ❌

M9.10 — doc 17 §3 corroborations

Goal: 5 reserved corroborations added to doc 17 substrate-ownership positioning
Killer items:
- Row 19 — Password Management (Bitwarden Cloud / 1Password vs Vaultwarden)
- Row 20 — Work-tracking (Linear / Jira vs val-track)
- Row 21 — PSA (ConnectWise Manage / Datto Autotask vs val-track + BC + Alga PSA)
- Row 22 — SIEM (Splunk / IBM QRadar vs Wazuh)
- Row 23 — Backup (Veeam / Datto vs Kopia / Duplicati)
Acceptance: doc 17 §3 updated; cumulative count = 23
Depends on: M9.9
Status: ❌

⏸️ M9.P — First MSP engagement trigger

First New Era IT (AU) MSP client engagement signed OR operator pre-emptive scoping decision
Operator approval for MSP-vertical scoping kickoff

Acceptance criteria for M9 overall:

MSP-vertical Ring 3 blueprint operational
5 specs landed
First MSP client engagement onboarded
5 doc 17 §3 corroborations added (cumulative count 23)

Dependencies: M6 complete; M7 + M8 complete; M5 Microsoft-stack integration Owner: Operator-team + Claude Cowork

Milestone 10 — Voice/Comms Own Provider + Carrier Partner

Goal: ValOS own voice/comms provider operational. val-switch all channels live.

Sub-milestones

M10.1 — Kamailio SIP edge / SBC

Goal: valos-kamailio Ring 0 docker operational
Killer items:
- valos-kamailio Ring 0 docker (per L0.6)
- SIP edge / SBC configuration
- Mediation between carrier SIP trunk + FreeSWITCH
Acceptance: Kamailio routes test SIP traffic; carrier SIP trunk verified
Depends on: M9 complete (MSP context establishes voice/comms scope)
Status: ❌

M10.2 — FreeSWITCH media engine

Goal: valos-freeswitch Ring 0 docker operational
Killer items:
- valos-freeswitch Ring 0 docker (per L0.7)
- RTP media handling
- Transcoding + recording + conferencing
Acceptance: Test call completes; recording stored; conference works
Depends on: M10.1
Status: ❌

M10.3 — WebRTC bridge

Goal: Browser-based calling
Killer items:
- WebRTC gateway in FreeSWITCH or separate proxy
- Browser → WebRTC → SIP routing
- val-desk WebRTC integration
Acceptance: Test browser-initiated call via val-desk
Depends on: M10.2
Status: ❌

M10.4 — Call recording + transcription pipeline

Goal: Calls recorded + transcribed via val-ingest
Killer items:
- FreeSWITCH recording on
- Recording → val-ingest pipeline (per ADR-017 + val-ingest video/audio mode)
- Transcript b_facts emitted
Acceptance: Test call → recording → transcript → b_fact in val-ontology
Depends on: M10.2 + M3.5 (val-ingest)
Status: ❌

M10.5 — Voice channel in val-switch

Goal: val-switch voice channel operational
Killer items:
- Voice channel implementation
- Outbound call dispatch
- Inbound call routing
Acceptance: val-switch dispatches outbound; routes inbound to operator-team
Depends on: M10.3
Status: ❌

M10.6 — Email channel

Goal: Email via MS Graph (Microsoft-stack) + IMAP/SMTP (other tenants)
Killer items:
- MS Graph email skill (val-cargo + val-switch)
- IMAP/SMTP fallback skill
- Email b_fact emission
Acceptance: Test email sent + received; b_facts emitted
Depends on: M10.5
Status: ❌

M10.7 — SMS channel

Goal: SMS via carrier-partner SIP trunking
Killer items:
- Carrier-partner SMS gateway integration
- val-switch SMS channel
Acceptance: Test SMS sent + received
Depends on: M10.5
Status: ❌

M10.8 — Teams channel

Goal: Microsoft Teams via Graph API
Killer items:
- MS Graph Teams skill
- Team messages + DM support
Acceptance: Test Teams message dispatched + received
Depends on: M10.5 + M5 (Microsoft Entra)
Status: ❌

M10.9 — WhatsApp / IG / FB / Telegram

Goal: Evolution adapter integration
Killer items:
- Evolution adapter Ring 0 (or external)
- WhatsApp + Instagram + Facebook + Telegram channel skills
Acceptance: Test message dispatched + received on each platform
Depends on: M10.5
Status: ❌

M10.10 — Webchat

Goal: Web-embed widget for client-facing chat
Killer items:
- Web widget JS bundle
- WebSocket bridge to val-switch
- val-desk operator-side inbox
Acceptance: Test website embeds widget; client → operator chat works
Depends on: M10.5
Status: ❌

M10.11 — Carrier partner integration

Goal: Carrier partner contracted + SIP trunking live
Killer items:
- Carrier partner selection (Twilio / Bandwidth / Telnyx / SignalWire / etc.) — operator decision
- Contract signed
- SIP trunking configured
- Phone number provisioning workflow
- Per-tenant routing isolation
Acceptance: 1 carrier partner integrated; phone number provisioned; per-tenant routing verified
Depends on: M10.1
Status: ❌

⏸️ M10.P — Voice substrate 4/4 dockers green

valos-kamailio ✅
valos-freeswitch ✅
valos-meshcentral ✅
Per-channel smoke green (all 6 channel types)
Carrier partner integration tested with 2 client tenants

Acceptance criteria for M10 overall:

All 6 channel types operational
1+ carrier partner integrated
Voice substrate 4/4 dockers green
Per-tenant routing isolation verified
First client voice/comms engagement

Dependencies: M5 + M9 (Microsoft-stack + MSP context) Owner: Claude Cowork (Rust + skill authoring); Operator (carrier partner contracting)

Milestone 11 — Problem-Solving + QMS + Marketing Base Blueprints

Goal: 3 cross-vertical base blueprints operational. First concrete consumers triggered.

Sub-milestones

M11.1 — Problem-Solving spec promotion

Goal: doc 34 → d_mission-control/specs/problem-solving-base-blueprint.md
Killer items:
- Spec doc landed (full design from doc 34 + R219)
- Research doc archived
Acceptance: Spec exists; cross-refs updated
Depends on: M6 complete (SBR provides first Problem-Solving deployment per M6.7)
Status: ❌

M11.2 — Problem-Solving 6 Mission categories

Goal: 6 Mission categories implemented per doc 34 F223
Killer items:
- Problem-framing Mission
- Idea-generation Mission
- Per-idea critique team Mission (dynamic Workers)
- Annealment loop
- Idea-to-plan promotion
- Plan-team Mission
Acceptance: Sample complex problem → 6-stage Mission completes → plan produced
Depends on: M11.1
Status: ❌

M11.3 — Dynamically-instantiated Worker roles

Goal: ADR-007 variant operational (per doc 34 F226 + R218)
Killer items:
- Worker role synthesis at Mission instantiation
- Operator-context-aware prompt generation
- Per-role validators
Acceptance: Test Mission instantiates 5 dynamically-defined Worker roles per problem context
Depends on: M11.2 + M4.10
Status: ❌

M11.4 — Three-tier knowledge accretion

Goal: b_facts + knowledge-nodes + Engagement Cores all accrete per Mission
Killer items:
- Per-Mission b_facts (already locked)
- Knowledge-node synthesis from Mission (per doc 32 F210)
- Engagement Core bundling (per ADR-019)
Acceptance: Test Mission produces knowledge-node updates; Engagement Core includes
Depends on: M11.3
Status: ❌

M11.5 — QMS spec promotion

Goal: doc 29 → d_mission-control/specs/qms-base-blueprint.md
Killer items:
- Spec doc landed
- Research doc archived
Acceptance: Spec exists
Depends on: First QMS-consuming client engagement (manufacturing / construction / healthcare)
Status: ❌

M11.6 — QMS 8 surface areas

Goal: All 8 QMS surface areas implemented per doc 29 F174
Killer items:
- Document control (auto-version + approval workflow)
- Training tracker
- NCR + CAPA register (first scenarios consumer per ADR-015)
- ISO 9001 audit (first adversarial validation consumer at compliance scope per doc 19)
- Risk register + FMEA (RPN computed property per doc 33 R210)
- Supplier management (Trust-Pilot-style peer scorecards)
- Complaints management
- Change management
Acceptance: Sample NCR scenario completes; RPN computed; audit cycle initiated
Depends on: M11.5
Status: ❌

M11.7 — Compliance frameworks added

Goal: 8 frameworks added to applies_to.compliance_frameworks per doc 29 R178
Killer items:
- ISO 9001 + IATF 16949 + ISO 13485 + ISO 45001 + HACCP + GxP + FDA 21 CFR Part 11 + (2nd ISO 13485 variant for Class II/III)
Acceptance: All 8 frameworks selectable in skill frontmatter
Depends on: M11.6
Status: ❌

M11.8 — Marketing Automation spec promotion

Goal: doc 18 → d_mission-control/specs/marketing-automation-base-blueprint.md
Killer items:
- Spec doc landed
- Research doc archived
Acceptance: Spec exists
Depends on: First marketing engagement
Status: ❌

M11.9 — Marketing 8 capability areas

Goal: All 8 areas operationalized per doc 18 + ADR-018
Killer items:
- Lead generation
- Lead nurture
- Lead qualification
- Customer onboarding
- Customer retention
- Customer advocacy
- SEO + content
- Video Genie
Acceptance: Test campaign orchestrated end-to-end
Depends on: M11.8 + M10 (val-switch comms)
Status: ❌

⏸️ M11.P — First cross-vertical capability layer adoption

First Problem-Solving Mission deployment (SBR complex-case completed per M6.7)
First QMS-consuming client engagement
First Marketing Automation campaign

Acceptance criteria for M11 overall:

3 base blueprints in d_mission-control/specs/
3 first concrete deployments per cross-vertical capability layer
8 compliance frameworks added

Dependencies: M9 complete; ADR-015 + ADR-018 locked Owner: Claude Cowork; Operator (per-vertical engagement triggers)

Milestone 12 — FORCE Deck + Commercial Launch

Goal: Public-facing positioning + commercial pricing model finalized. Substrate-ownership thesis articulated for prospects.

Sub-milestones

M12.1 — Substrate-ownership slide cluster (15a / 15b / 15c)

Goal: FORCE deck Slides 15a-c authored per doc 17 R91
Killer items:
- Slide 15a — Two doorways into the same substrate (Val MCP + operator val-desk + same val-ledger/val-ontology)
- Slide 15b — The AI flywheel (model-gateway agnostic; substrate stable; intelligence improves)
- Slide 15c — No middleman in the access layer (9 open-vs-locked examples)
Acceptance: 3 slides authored + reviewed
Depends on: M11 (full capability backing)
Status: ❌

M12.2 — Microsoft-stack alignment positioning

Goal: 6 Microsoft surfaces positioned in FORCE deck
Killer items:
- Slide showing 6 surfaces integrated (Business Central + Defender + Intune + Dataverse + Entra + M365)
- Strategic-positioning win articulated (ValOS = substrate-value-add on Microsoft commodity)
Acceptance: Slide authored
Depends on: M12.1
Status: ❌

M12.3 — Two-layer competitor map

Goal: Competitor map per doc 28 F172 + doc 27 + doc 30
Killer items:
- Substrate-scope competitors (Automaton / Basic Memory / Mem.ai / Letta)
- OpsCenter-surface-scope competitors (ClickUp / Notion / Asana / Monday)
- Dev-factory-scope competitors (OpenAI Symphony)
- Editor + collaboration substrate-scope competitors (Tiptap Platform / Liveblocks)
Acceptance: Competitor map slide authored
Depends on: M12.2
Status: ❌

M12.4 — Open-vs-locked corroborations

Goal: 23+ corroborations (per M9.10 + further per cumulative count)
Killer items:
- All corroborations from doc 17 §3 reflected in FORCE deck
- Strategic positioning per category (subsume / integrate-with / native-build)
Acceptance: Substrate-ownership matrix in FORCE deck
Depends on: M12.3 + M9.10
Status: ❌

M12.5 — Pricing model with Microsoft licensing pass-through

Goal: Commercial pricing model finalized
Killer items:
- Per-engagement fee structure
- Microsoft licensing pass-through (~$92/user/month per doc 38 F252)
- Cost-envelope mathematics per doc 23 F130 + doc 24 F136 (caveman multiplier)
- Engagement-tier pricing (SMB / Medium Enterprise / Enterprise)
Acceptance: Pricing model documented + reviewed
Depends on: M12.4 + M5.P (commercial model decision recorded)
Status: ❌

M12.6 — Academic citations

Goal: 2 academic-grade citations in FORCE deck
Killer items:
- Coral arXiv 2604.01658 (MIT + Stanford + NUS substrate-ownership corroboration)
- Caveman March 2026 research (terse-responses-more-accurate)
Acceptance: Citations on FORCE deck slides
Depends on: M12.5
Status: ❌

M12.7 — Production reference customers

Goal: Reference customer logos / case studies
Killer items:
- SBR case study (post-go-live)
- New Era IT (AU) reference (post-MSP scoping)
- Pipeline-referenced customer signals (First Solar Palantir reference; Hivemind; GBrain; Tiptap customer base; etc. — narrative, not direct customers)
Acceptance: Customer slide authored
Depends on: M6 + M9
Status: ❌

M12.8 — Sales talk-tracks

Goal: Operator-team-ready prospect-conversation scripts
Killer items:
- "What about [SaaS vendor X]?" objection-handling per doc 17 §3
- "Why ValOS vs Microsoft?" positioning
- "What's your pricing?" model walkthrough
- "How long to deploy?" 30-day Blueprint-as-a-Service framing
Acceptance: Talk-tracks rehearsed by operator-team
Depends on: M12.5
Status: ❌

M12.9 — Vocabulary discipline

Goal: valos-reference.md §48 Vocabulary register finalized for customer-facing material
Killer items:
- All operator-facing labels locked:
  - Initiative ↔ Mission
  - Work item ↔ val-track entity
  - Approach ↔ Idea
  - Context Cores
  - System of Record
- Caveman tier discipline in customer-facing material
- "Agent" framing replaced with ValOS-canonical vocabulary per doc 17 §6
Acceptance: Vocabulary register approved
Depends on: M12.8
Status: ❌

M12.10 — Strategic positioning brief

Goal: 1-page brief per doc 17 R95
Killer items:
- d_engagements/positioning-brief-substrate-ownership.md authored
- 3 principles + 5 positioning lines + 9-example competitor table compressed
Acceptance: Brief landed in d_engagements/
Depends on: M12.9
Status: ❌

⏸️ M12.P — Commercial launch readiness review

FORCE deck approved by operator + operator-team
Sales talk-tracks rehearsed
First non-SBR / non-New-Era-IT prospect conversation completed
Pricing model validated against 2+ prospect proposals

Acceptance criteria for M12 overall:

FORCE deck v2 shipped
Positioning brief landed
All 9+ memory updates applied
First commercial revenue beyond SBR + New Era IT in pipeline

Dependencies: M11 complete (full capability stack for prospect demos) Owner: Operator-team (sales + positioning); Claude Cowork (FORCE deck content + memory updates)

Sub-Milestone Count Summary

Milestone	# Sub-milestones	+ Pause point	Cumulative
M0	5	1	6
M_up	8	1	15
M1	8	1	24
M2	8	1	33
M3	5	1	39
M4	14	1	54
M5	8	1	63
M6	9	1	73
M7	6	1	80
M8	7	1	88
M9	10	1	99
M10	11	1	111
M11	9	1	121
M12	10	1	132

Total: ~118 sub-milestones + 14 pause points = ~132 verification gates.

M_up added (per ADR-024 + ADR-025) — 8 sub-milestones bootstrap Mission Control + Engagement Wizard for all subsequent milestones.

Heaviest milestones: M4 (peer-service engines, 14 sub-milestones — Part 1 → Part 2 gate) + M9 (MSP-vertical scoping, 10 sub-milestones — 5 sibling specs + 16-area capability) + M10 (voice/comms, 11 sub-milestones — all channel types + carrier partner) + M12 (commercial launch, 10 sub-milestones — FORCE deck + positioning + pricing).

Cross-Milestone Dependency Graph (Sub-Milestone Detail)

M0.5 commit → M1 ADR review window begins
M1.5 + M1.6 + M1.7 → M1.P block-schema cross-lock → M3.1 + M3.2 + M3.3 + M3.4 ADR-locked libs
M1.8 → M3.5 val-ingest
M2.7 + M1.4 → M2.P Cores+heartbeat cross-lock → M4.11 heartbeat impl
M3.P substrate libs smoke → M4 peer-service engines
M4.5 + M4.6 + M4.7 + M4.12 + M4.13 + M4.14 → M4.P Part 1 → Part 2 gate (operator approval)
M4.P operator approval → M5 Business Central
M5.P commercial model decision → M6 SBR engagement
M6.P SBR go-live → M7 + M8 parallel (val-track + val-host)
M9 MSP-vertical → M10 + M11 + M12 parallel

Cadence + Review Protocol

Per-sub-milestone (within active milestone)

Killer items reviewed daily; status flips noted
Sub-milestone acceptance verified before next sub-milestone starts (where dependency exists)

Per-milestone pause point (⏸️)

Operator + operator-team reviews acceptance criteria for the whole milestone
Cross-doc updates flow into vertical-fusion-checklist + PLATFORM.md
Memory entries updated
Next milestone scoped with sub-milestone breakdown

Failure protocol

If a sub-milestone fails:

Halt sub-milestone progression within that milestone
Document failure (which killer item failed; why)
Either: fix + re-verify, or revise sub-milestone scope, or de-prioritize entire milestone (operator decision)

If a pause point fails:

Halt milestone progression to next milestone
Escalate to operator
Document in failure log

Manifesto Discipline Principles

Killer items are killer. No skipping.
Sub-milestones are verification checkpoints. Each requires acceptance before next.
Pause points are non-negotiable. Read-and-confirm, not do-and-assume.
Acceptance criteria are concrete. Pass/no-pass.
Dependencies are graphed. Within-milestone (sub-milestone) + cross-milestone.
Owners are named. No floating tasks.
References are tight. Every item cross-links to research doc + ADR + PLATFORM.md row.
Failure halts progression. No silent skip.
Public, versioned, wrong until proven right. This doc updates when state flips.

References

Doc / File	Purpose
vertical-fusion-checklist.md	Sister doc: layered architectural inventory (current state)
`v_platform/PLATFORM.md`	Baseline live status + Master Checklist Part 1 + Part 2
16 ADR drafts (`d_mission-control/specs/adr-NNN-*.md`)	Architectural decisions referenced per sub-milestone
40 research docs (`d_mission-control/research/2026-05-11.*.md`)	Pipeline depth references per sub-milestone
Memory (operator-team)	Persistent strategic commitments — 9+ pending updates
`valos-reference.md`	Engine + capability + vocabulary register
`CLAUDE.md`	Cowork dev rules
SOUL.md + AGENTS.md	Architectural law + discipline locks

Milestones Manifesto — Cowork-side composition. Sub-milestone decomposition added 2026-05-12. ~110 sub-milestones across 13 milestones + 13 pause points = ~123 verification gates. Companion to vertical-fusion-checklist + PLATFORM.md. Public, versioned, wrong until proven right. Updates every state flip.

Milestones Manifesto — Super Detailed Build Checklist

The Manifesto

Status Legend

Sub-Milestone Format

Critical Path Sequencing

Milestone 0 — Pre-flight: Current State Lockup

Sub-milestones

M0.1 — Research pipeline commits

M0.2 — 16 ADR drafts authored

M0.3 — Two checklist specs composed

M0.4 — 9 memory updates applied

M0.5 — Commit + push + SCP this batch

⏸️ M0.P — Pause point: Pipeline lockup verification

Milestone M_up — val-up Engine + Public Launch + val-forge Multi-Repo ADE

Sub-milestones

M_up.1 — val-up Rust scaffolding

M_up.2 — val-forge Multi-Repo ADE extension

M_up.3 — val-up frontend (Next.js + Tiptap + Hocuspocus)

M_up.4 — Microsoft Entra OAuth + per-tenant isolation

M_up.5 — Decision Card ledger UI + emission wizard

M_up.6 — Engagement Wizard runtime (per ADR-013)

M_up.7 — val-cargo MCP integration (HQ sync)

M_up.8 — Public launch at up.valtience.com

⏸️ M_up.P — val-up + multi-repo ADE production readiness

Milestone 1 — ADR Approval Window: Substrate-Primitive Lock (8 ADRs)

Sub-milestones

M1.1 — ADR-007 Missions review + lock

M1.2 — ADR-015 Scenarios review + lock

M1.3 — ADR-016 Transactions review + lock

M1.4 — ADR-019 Context Cores review + lock (BROADEST cross-cutting)

M1.5 — ADR-022 Canvas substrate-primitive review + lock (THREE-WAY)

M1.6 — ADR-023 Editor + Collaboration substrate review + lock (THREE-WAY)

M1.7 — ADR-010 val-block-renderer review + lock (THREE-WAY)

M1.8 — ADR-017 val-ingest review + lock

⏸️ M1.P — Three-way block-schema cross-lock verification

Milestone 2 — ADR Approval Window: Capability + Pattern Lock (8 ADRs)

Sub-milestones

M2.1 — ADR-009 Inbound MCP review + lock

M2.2 — ADR-011 val-forge integration review + lock

M2.3 — ADR-012 Device provisioning review + lock

M2.4 — ADR-013 Engagement Wizard review + lock

M2.5 — ADR-014 Legacy Modernization Mission review + lock

M2.6 — ADR-018 Marketing Automation review + lock

M2.7 — ADR-020 Heartbeat watchdog review + lock

M2.8 — ADR-021 caveman-shrink filter review + lock

⏸️ M2.P — ADR-019 + ADR-020 cross-lock verification

Milestone 3 — Substrate-Primitive Library Build-Out

Sub-milestones

M3.1 — val-canvas Rust library

M3.2 — val-editor Rust library

M3.3 — Hocuspocus Ring 0 Docker

M3.4 — val-block-renderer library

M3.5 — val-ingest engine

⏸️ M3.P — Substrate-primitive library smoke verification

Milestone 4 — Peer-Service Engines: val-policy + val-fab + val-orchestrator Completion

Sub-milestones

M4.1 — val-policy engine scaffolding

M4.2 — val-policy capability binding (5 capabilities)

M4.3 — val-policy ABAC extension

M4.4 — val-policy DefenseClaw filter list

M4.5 — Cost-threshold capability gate

M4.6 — Blueprint engine (val-fab) scaffolding

M4.7 — Three-layer model support

M4.8 — val-orchestrator extension: watcher kinds

M4.9 — val-orchestrator extension: Wizard + Matter + Decision + Gate primitives

M4.10 — val-orchestrator extension: Mission decomposition + dynamic Worker roles

M4.11 — Heartbeat watchdog implementation

M4.12 — val-agent OODA generalization

M4.13 — val-bay hot-reload

M4.14 — val-desk slot system + chrome chassis

⏸️ M4.P — Part 1 → Part 2 gate (operator approval required)

Milestone 5 — Business Central as System of Record + val-cargo Integration

Sub-milestones

M5.1 — Microsoft Entra app + OAuth 2.0

M5.2 — val-cargo bc.read.v1 skill

M5.3 — val-cargo bc.write.v1 skill

M5.4 — val-cargo bc.query.v1 skill

M5.5 — Entity reference pattern

M5.6 — b_fact emission pattern with Business Central transaction refs

M5.7 — Cache + sync pattern

M5.2 — val-cargo `bc.read.v1` skill

M5.3 — val-cargo `bc.write.v1` skill

M5.4 — val-cargo `bc.query.v1` skill