fabric-reference

# VNX Fabric Reference How the fabric works, as runbooks. This is lookup, not judgment — the `t0-orchestrator` skill owns orchestration decisions; `vnx-manager` owns infra maintenance. When a T0 rediscovers the same mechanism a third time, it belongs here. Master-rule (see `role-orchestrator.md`): project files describe the project; the fabric describes itself. Fabric mechanism lives in the canonical role and here, never copied into a consumer's `CLAUDE.md`. ## Runbook: state resolution Tracks, objectives, receipts, and coordination state live in the **central** store, never repo-local. - Central store: `~/.vnx-data/<project_id>/state/` (resolved by the vnx runtime, not hardcoded). - Never pin `VNX_STATE_DIR=.vnx-data/state` in a role or script — a repo-local pin forks state from central = split-brain. - Resolution helpers: Python `scripts/lib/project_root.py`; Bash `scripts/lib/vnx_resolve_root.sh`. - `project_id` never silently defaults to `vnx-dev` (ADR-007) — it resolves from `VNX_PROJECT_ID` / `.vnx-project-id` / git remote, else it rejects. ```bash vnx status # situational awareness from central state cat .vnx-data/state/t0_state.json | python3 -m json.tool # SessionStart projection vnx fabric-audit # store-hygiene: split-brain stores, per-project ledgers, hash-chain ``` ## Runbook: the single-entry dispatch door Every dispatch goes through the one door, which decides the lane. Calling a lane script directly is a side door. ```bash v...