@overdeck/desktop 0.45.22 → 0.45.23

package/sync-sources/skills/feature-work/SKILL.md

@@ -9,7 +9,7 @@ When implementing a new feature:
 
 ## 1. Understand Requirements
 - Read the Linear/GitHub issue thoroughly
-- Check for an associated PRD draft at `<projectRoot>/.pan/drafts/<ISSUE-ID>.md` and the workspace vBRIEF at `.pan/spec.vbrief.json`
+- Check for an associated PRD draft at `<projectRoot>/.pan/drafts/<ISSUE-ID>.md` and the workspace xBRIEF at `.pan/spec.vbrief.json`
 - Identify acceptance criteria
 - Clarify ambiguities BEFORE coding
 

package/sync-sources/skills/pan/SKILL.md

@@ -38,7 +38,8 @@ LIFECYCLE VERBS (top-level)
   pan wipe <id>            Destructive reset-to-Todo for an issue
   pan close <id>           Close-out ceremony for completed issues
   pan plan <id>            Create execution plan
-  pan plan finalize <id>   Materialize plan to vBRIEF tasks
+  pan plan finalize <id>   Finalize the xBRIEF plan
+  pan task <subcommand>    Read and update xBRIEF item state
   pan issues               List and triage work across trackers
 
 OBSERVATION
@@ -70,7 +71,6 @@ ADMIN (PLUMBING)
   pan admin specialists <cmd> Review/test/merge agents
   pan admin remote <cmd>      Fly.io infra
   pan admin db <cmd>          Database seeding
-  pan admin vBRIEF tasks <cmd>       vBRIEF tasks CLI management
   pan admin config <cmd>      Configuration management
   pan admin hooks install     Install Claude Code heartbeat hooks
   pan admin tldr <cmd>        TLDR daemon management

package/sync-sources/skills/pan-admin-config/SKILL.md

@@ -45,5 +45,6 @@ Settings page or edit `~/.overdeck/config.yaml` directly.
 ## See Also
 
 - `pan admin migrate-config` — migrate legacy settings.json → config.yaml
+- `pan admin state migrate-xbrief <project> [--dry-run]` — migrate state files to xBRIEF envelopes and extensions
 - `pan admin tracker <cmd>` — tracker-specific operations
 - `pan doctor` — verify configuration is valid

package/sync-sources/skills/pan-approve/SKILL.md

@@ -17,7 +17,7 @@ allowed-tools:
 
 `pan approve` was a legacy CLI command that bypassed critical infrastructure:
 - **Merge queue** — no serialization, could collide with concurrent merges
-- **Post-merge lifecycle** — no Docker cleanup, label cleanup, stash cleanup, vBRIEF tasks compaction
+- **Post-merge lifecycle** — no Docker cleanup, label cleanup, stash cleanup, xBRIEF task-state compaction
 - **Idempotency guards** — no protection against the infinite loop (PAN-328)
 - **Verification gate** — no post-rebase quality checks
 

package/sync-sources/skills/pan-close/SKILL.md

@@ -57,7 +57,7 @@ pan close PAN-1234 --force --accept-deploy
 Runs the close-out ceremony after mechanically checking review, tests, branch verification,
 forge merge, post-merge lifecycle, main verification, deployment, and teardown. Merge
 moves the issue to canonical state `verifying_on_main`; close-out is the deliberate final
-step that completes the vBRIEF, archives planning artifacts, applies final cleanup, closes
+step that completes the xBRIEF, archives planning artifacts, applies final cleanup, closes
 the tracker issue, and clears review status.
 
 Close-out is lighter than `pan wipe`: it preserves history and follows the configured

package/sync-sources/skills/pan-doctor/SKILL.md

@@ -47,7 +47,7 @@ pan doctor
 # ✓ Skills directory exists
 # ✓ tmux available
 # ✓ Docker available
-# ⚠ orphan-proposed-specs: proposed vBRIEF specs without work agents, grouped by project with remediation hints
+# ⚠ orphan-proposed-specs: proposed xBRIEF specs without work agents, grouped by project with remediation hints
 ```
 
 ### 2. Check Configuration

package/sync-sources/skills/pan-new-project/SKILL.md

@@ -3,7 +3,7 @@ name: pan-new-project
 description: >
   Complete setup for registering a new project with Overdeck. Handles
   project registration, issue prefix, workspace config, trust setup,
-  vBRIEF tasks init, tracker config, and validates against working projects.
+  xBRIEF task support init, tracker config, and validates against working projects.
 triggers:
   - new project
   - add new project
@@ -31,7 +31,7 @@ license: "MIT"
 Sets up a new project for Overdeck management. This is the ONLY correct
 way to add a new project. Do NOT just run `pan project add` alone — it
 creates a skeleton entry that breaks planning agents, workspace creation,
-issue routing, and vBRIEF tasks.
+issue routing, and xBRIEF task support.
 
 ---
 
@@ -185,16 +185,14 @@ extra config needed beyond `issue_prefix` in projects.yaml.
 
 For **GitLab** projects, TBD — not yet supported in dashboard polling.
 
-### Step 5: Initialize vBRIEF tasks
+### Step 5: Verify xBRIEF Task Support
+
+No per-project task database initialization is required. xBRIEF plan items become the executable checklist after planning, and `pan task` reads and updates their state through the canonical state door.
 
 ```bash
-cd <project-path>
-git config vBRIEF tasks.role agent
+pan task --help >/dev/null && echo "PASS: pan task available"
 ```
 
-New worktrees inherit this automatically since Overdeck now sets it during
-workspace creation (`workspace-manager.ts` and `worktree.ts`).
-
 ### Step 6: Create workspaces/ Directory
 
 ```bash
@@ -250,8 +248,8 @@ console.log(d.projects?.['<path>']?.hasTrustDialogAccepted
 grep 'GITHUB_REPOS' ~/.overdeck.env | grep -q '<PREFIX>' && \
   echo "PASS: in GITHUB_REPOS" || echo "FAIL: not in GITHUB_REPOS"
 
-# 5. vBRIEF tasks configured
-cd <path> && git config vBRIEF tasks.role && echo "PASS" || echo "FAIL: vBRIEF tasks.role not set"
+# 5. xBRIEF task command available
+pan task --help >/dev/null && echo "PASS" || echo "FAIL: pan task unavailable"
 
 # 6. workspaces/ exists
 test -d <path>/workspaces && echo "PASS" || echo "FAIL: no workspaces/"
@@ -278,7 +276,7 @@ Tracker:        GitHub (<owner/repo>)
 Workspace type: <type>
 Tests:          <command>
 Trusted:        Yes
-vBRIEF tasks:          Configured
+xBRIEF task support:   Available through pan task
 Dashboard:      Issues visible
 
 Validation: 8/8 checks passed

package/sync-sources/skills/pan-oversee/SKILL.md

@@ -27,7 +27,7 @@ Supervise an agent working on an issue through the **entire lifecycle**:
 `spawn/resume → work → completion → review → feedback loop → test → merge-ready`
 
 This is NOT passive monitoring. You are actively:
-- **Watching for bugs at every stage** — dashboard rendering, agent spawning, workspace creation, vBRIEF tasks lifecycle, specialist handoffs, status transitions, terminal output, API responses
+- **Watching for bugs at every stage** — dashboard rendering, agent spawning, workspace creation, xBRIEF tasks lifecycle, specialist handoffs, status transitions, terminal output, API responses
 - **Documenting everything** — no bug is too small. If something flickers, logs a warning, shows stale data, or doesn't match expected state, that's a finding
 - **Fixing infrastructure bugs** when they block progress, then continuing the test
 - **Filing or updating GitHub issues** (PAN-XXX) for every bug found
@@ -92,12 +92,12 @@ echo "Completed: ${COMPLETED:-NO}"
 REVIEW_STATUS=$(curl -s http://localhost:3011/api/review/$ISSUE_ID/status 2>/dev/null)
 echo "Review status: $REVIEW_STATUS"
 
-# 6b. Branch-portable vBRIEF pipeline mirror (corroborating, not authoritative)
+# 6b. Branch-portable xBRIEF pipeline mirror (corroborating, not authoritative)
 PIPELINE_MIRROR=""
 if [ -n "$WS_PATH" ] && [ -f "$WS_PATH/.pan/spec.vbrief.json" ]; then
   PIPELINE_MIRROR=$(jq -c '.plan.metadata.pipeline // empty' "$WS_PATH/.pan/spec.vbrief.json" 2>/dev/null)
 fi
-echo "vBRIEF pipeline mirror: ${PIPELINE_MIRROR:-NONE}"
+echo "xBRIEF pipeline mirror: ${PIPELINE_MIRROR:-NONE}"
 
 # 7. Specialist activity?
 SPECIALISTS=$(curl -s http://localhost:3011/api/specialists 2>/dev/null)
@@ -106,7 +106,7 @@ echo "Specialists: $SPECIALISTS"
 
 ### Phase Decision Matrix
 
-Based on the checks above, determine the current phase. Treat `REVIEW_STATUS` and other live SQLite-backed API status as authoritative; use the branch-portable vBRIEF `plan.metadata.pipeline` mirror as a corroborating signal when API status is missing, stale, or ambiguous. If the mirror disagrees with the API, log a bug and prefer the API.
+Based on the checks above, determine the current phase. Treat `REVIEW_STATUS` and other live SQLite-backed API status as authoritative; use the branch-portable xBRIEF `plan.metadata.pipeline` mirror as a corroborating signal when API status is missing, stale, or ambiguous. If the mirror disagrees with the API, log a bug and prefer the API.
 
 | Condition | Current Phase | Jump To |
 |-----------|--------------|---------|
@@ -344,7 +344,7 @@ When you find a bug in the Overdeck infrastructure:
 Be thorough. All of these are findings worth logging:
 - Dashboard shows wrong status, stale data, or flickers
 - Agent state file says one thing, dashboard shows another
-- vBRIEF tasks not created, duplicated, or disappearing
+- xBRIEF tasks not created, duplicated, or disappearing
 - Specialist doesn't wake up or takes too long
 - Terminal output garbled or missing
 - API returns unexpected response

package/sync-sources/skills/pan-plan/SKILL.md

@@ -18,7 +18,7 @@ allowed-tools:
 
 # Overdeck Planning Lifecycle
 
-`pan plan <id>` is the plan-ONLY verb: it starts a planning session for an issue and produces a PRD and vBRIEF, but it does not start the work agent. Use `pan start <id>` when you want planning and work in one command.
+`pan plan <id>` is the plan-ONLY verb: it starts a planning session for an issue and produces a PRD and xBRIEF, but it does not start the work agent. Use `pan start <id>` when you want planning and work in one command.
 
 Use `--auto` when the user wants the planning agent to run non-interactively and infer defensible defaults. Use `--probe` when the plan needs an adversarial pre-finalize self-pass; `--effort high` enables the same probe instructions automatically.
 
@@ -85,13 +85,13 @@ What it does:
 2. Validates the tasks already stored in `plan.items[]`, including their declared dependencies.
 3. Flips the spec's `plan.status` from `draft` to `proposed`.
 4. Calls the dashboard's complete-planning endpoint to promote the canonical spec into `<projectRoot>/.pan/specs/`, commit it on main, push, transition the tracker state to Planned, and terminate the planning session — same flow as `pan plan done` and the dashboard Done button.
-5. Returns a summary of finalized vBRIEF tasks and promotion status, or JSON with `--json`.
+5. Returns a summary of finalized xBRIEF tasks and promotion status, or JSON with `--json`.
 
-Use `-w <path>` to point at another workspace. Use `--no-promote` to leave the spec at `status=proposed` without promoting (rare; for humans who want to review the plan in the dashboard before clicking Done). Finalize runs vBRIEF quality lint by default; use `--no-quality-lint` only as a loud one-run emergency bypass when the plan must be promoted despite known quality issues.
+Use `-w <path>` to point at another workspace. Use `--no-promote` to leave the spec at `status=proposed` without promoting (rare; for humans who want to review the plan in the dashboard before clicking Done). Finalize runs xBRIEF quality lint by default; use `--no-quality-lint` only as a loud one-run emergency bypass when the plan must be promoted despite known quality issues.
 
 ### PRD-first gate
 
-Finalize and complete-planning refuse to promote a plan unless a **PRD draft** of at least 20 lines exists for the issue. `roles/plan.md` has always required the PRD as the first artifact; this gate makes it mechanical. The gate searches, in order, for `<ISSUE-ID>.md` (uppercase then lowercase) under `<projectRoot>/.pan/drafts/` then `<workspace>/.pan/drafts/`; the first existing file with ≥20 lines satisfies it. A found-but-thinner draft fails with its line count; a fully missing draft fails naming the canonical path to write. `pan start <id> --auto` is structurally exempt (it synthesizes a minimal vBRIEF and never POSTs complete-planning, so the gate cannot block it). Use `--no-prd` (on `finalize` or `done`) only for a genuinely trivial issue that went through interactive planning anyway — it prints a yellow `⚠ PRD gate SKIPPED` warning and tells the endpoint to skip the check too.
+Finalize and complete-planning refuse to promote a plan unless a **PRD draft** of at least 20 lines exists for the issue. `roles/plan.md` has always required the PRD as the first artifact; this gate makes it mechanical. The gate searches, in order, for `<ISSUE-ID>.md` (uppercase then lowercase) under `<projectRoot>/.pan/drafts/` then `<workspace>/.pan/drafts/`; the first existing file with ≥20 lines satisfies it. A found-but-thinner draft fails with its line count; a fully missing draft fails naming the canonical path to write. `pan start <id> --auto` is structurally exempt (it synthesizes a minimal xBRIEF and never POSTs complete-planning, so the gate cannot block it). Use `--no-prd` (on `finalize` or `done`) only for a genuinely trivial issue that went through interactive planning anyway — it prints a yellow `⚠ PRD gate SKIPPED` warning and tells the endpoint to skip the check too.
 
 ## Completing planning (`pan plan done`)
 
@@ -101,7 +101,7 @@ Finalize and complete-planning refuse to promote a plan unless a **PRD draft** o
 pan plan done PAN-1071
 ```
 
-This promotes the workspace vBRIEF to `<projectRoot>/.pan/specs/`, syncs vBRIEF tasks, and transitions the tracker state to Planned. It is subject to the same PRD-first gate as `finalize`; pass `--no-prd` only for a genuinely trivial issue.
+This promotes the workspace xBRIEF to `<projectRoot>/.pan/specs/`, syncs xBRIEF tasks, and transitions the tracker state to Planned. It is subject to the same PRD-first gate as `finalize`; pass `--no-prd` only for a genuinely trivial issue.
 
 ## Related commands
 
@@ -112,5 +112,5 @@ This promotes the workspace vBRIEF to `<projectRoot>/.pan/specs/`, syncs vBRIEF
 ## See also
 
 - `roles/plan.md` — planning role prompt.
-- `docs/VBRIEF.md` — vBRIEF schema, artifact locations, lifecycle states.
+- `docs/XBRIEF.md` — xBRIEF schema, artifact locations, lifecycle states.
 - `docs/SKILLS-CONVENTION.md` — skill/CLI naming convention.

package/sync-sources/skills/pan-quickstart/SKILL.md

@@ -374,7 +374,7 @@ After completing this quick start, you have:
 
 ### Productivity Tips
 - Use dashboard to monitor multiple agents
-- Set up vBRIEF tasks for task tracking
+- Use xBRIEF plan items through `pan task` for task tracking
 - Configure git hooks for automated workflows
 - Create custom skills for your team's processes
 

package/sync-sources/skills/pan-recap/SKILL.md

@@ -130,14 +130,14 @@ gh issue list --state closed --search "closed:>=$SINCE_DATE" --limit 50 \
 ```
 
 Also scan real commits on `main` (drop the bookkeeping noise — `chore(records)`,
-`chore(state)`, `chore(vBRIEF tasks)` are per-issue state syncs, not work):
+`chore(state)` and `chore(records)` are per-issue state syncs, not work):
 
 ```bash
 echo "=== substantive commits on origin/main ==="
 git fetch -q origin main 2>/dev/null
 git log origin/main --since="$HOURS hours ago" --no-merges \
   --pretty='%h %ad %s' --date=format:'%m-%d %H:%M' \
-  | grep -vE 'chore\((records|state|vBRIEF tasks)\)' | head -40
+  | grep -vE 'chore\((records|state)\)' | head -40
 ```
 
 ### 2. What's in flight — active agents and in-review work

package/sync-sources/skills/pan-review/SKILL.md

@@ -90,7 +90,7 @@ all reviewers + the test specialist sign off; humans only click the button.
 
 ## See also
 
-- `pan show <id>` — inspect work agent state, vBRIEF status, recent activity
+- `pan show <id>` — inspect work agent state, xBRIEF status, recent activity
 - `pan done <id>` — signal initial work completion (from the worker side)
 - `pan code-review` skill — orchestrated parallel code review with synthesis
 - `roles/review.md` — the review role's frontmatter and prompt

package/sync-sources/skills/pan-start/SKILL.md

@@ -40,10 +40,10 @@ pan start PAN-123 --remote --tier ephemeral  # Remote Fly.io workspace that wind
 `pan start <id>` is the single paved-road entry point: it takes an issue from whatever
 state it is in to running work.
 
-- **No plan exists** — `pan start` auto-plans (non-interactive), materializes vBRIEF tasks, and
+- **No plan exists** — `pan start` auto-plans (non-interactive), materializes xBRIEF tasks, and
   starts the work agent when planning finalizes.
 - **Plan exists** — `pan start` creates the workspace if needed and spawns the work agent
-  from the existing vBRIEF and vBRIEF tasks.
+  from the existing xBRIEF and xBRIEF tasks.
 - **Already running** — `pan start` exits 0 with a no-op message naming `pan tell <id>` for
   messaging and the tmux attach command.
 
@@ -52,7 +52,7 @@ Planning depth is controlled by `--plan`:
 ```bash
 pan start PAN-1071 --plan interactive   # Q&A planning first, then work
 pan start PAN-1071 --plan auto          # non-interactive planning, then work (default)
-pan start PAN-1071 --plan skip          # synthesize a minimal vBRIEF and vBRIEF tasks, then work
+pan start PAN-1071 --plan skip          # synthesize a minimal xBRIEF and xBRIEF tasks, then work
 ```
 
 The default planning mode comes from `planning.default_mode` in `~/.overdeck/config.yaml`;

package/sync-sources/skills/pan-swarm/SKILL.md

@@ -5,7 +5,7 @@ description: Start and recover Overdeck swarm slots for planned issues with `pan
 
 # Pan Swarm
 
-Use `pan swarm` when an issue has a finalized vBRIEF plan and the operator wants Deacon-managed parallel slot execution.
+Use `pan swarm` when an issue has a finalized xBRIEF plan and the operator wants Deacon-managed parallel slot execution.
 
 ## Start a Swarm
 

package/sync-sources/skills/pan-sync/SKILL.md

@@ -286,7 +286,7 @@ These names are reserved by Overdeck. Don't use them for custom skills:
 
 **Pan operations:** `pan-down`, `pan-help`, `pan-install`, `pan-issue`, `pan-plan`, `pan-quickstart`, `pan-setup`, `pan-status`, `pan-up`, `pan-config`, `pan-tracker`, `pan-projects`, `pan-sync`, `pan-docker`, `pan-network`, `pan-approve`, `pan-tell`, `pan-kill`, `pan-doctor`, `pan-diagnose`, `pan-logs`, `pan-rescue`
 
-**Workflow skills:** `vBRIEF tasks`, `bug-fix`, `code-review`, `code-review-performance`, `code-review-security`, `dependency-update`, `feature-work`, `incident-response`, `onboard-codebase`, `refactor`, `release`, `session-health`, `skill-creator`, `web-design-guidelines`, `work-complete`
+**Workflow skills:** `pan-task`,  `bug-fix`, `code-review`, `code-review-performance`, `code-review-security`, `dependency-update`, `feature-work`, `incident-response`, `onboard-codebase`, `refactor`, `release`, `session-health`, `skill-creator`, `web-design-guidelines`, `work-complete`
 
 ## Related Skills
 

package/sync-sources/skills/pan-task/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: pan-task
-description: "pan task <verb> <issue> — claim and complete vBRIEF checklist items"
+description: "pan task <verb> <issue> — claim and complete xBRIEF checklist items"
 triggers:
   - pan task
   - claim task
@@ -11,7 +11,7 @@ allowed-tools:
 
 # pan task
 
-Run the requested task command now. Task state belongs to one issue's vBRIEF checklist.
+Run the requested task command now. Task state belongs to one issue's xBRIEF checklist.
 
 ```bash
 pan task next PAN-123

package/sync-sources/skills/pan-wipe/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: pan-wipe
-description: "pan wipe <id> — destructive reset to Todo: remove workspace, processes, branches, review state, vBRIEF tasks, and tracker status"
+description: "pan wipe <id> — destructive reset to Todo: remove workspace, processes, branches, review state, xBRIEF task state, and tracker status"
 triggers:
   - pan wipe
   - wipe issue
@@ -27,7 +27,7 @@ Performs the canonical destructive reset-to-Todo for an issue:
 - Removes the workspace directory (`workspaces/feature-<id>/`)
 - Removes agent state (`~/.overdeck/agents/<id>/`)
 - Deletes local and remote feature branches
-- Clears review status and issue vBRIEF tasks
+- Clears review status and issue xBRIEF task state
 - Resets issue status in the tracker to Todo
 
 ## When to Use

package/sync-sources/skills/pipeline-list/SKILL.md

@@ -140,7 +140,7 @@ PY
 - **Resource view** is backed by the resource-discovery service
   (`src/dashboard/server/services/resource-discovery.ts`), which includes an
   issue when it has ≥1 `resourceSource` (workspace, branch, tmux, docker, pr,
-  vbrief, vBRIEF tasks, or active tracker state) and computes `readyForMerge` +
+  xBRIEF plan, task state, or active tracker state) and computes `readyForMerge` +
   `stateLabel`. Same data the Command Deck `fetchProjects()` consumes.
 - **Lifecycle view** ports `getPipelineIssuePhase`
   (`src/dashboard/frontend/src/lib/pipeline-state.ts`). It can't see

package/sync-sources/skills/pipeline-status/SKILL.md

@@ -43,7 +43,7 @@ PAN-1028   in_flight           TTS: first speech utterance gets clipped   kimi-k
 PAN-945    post_merge_limbo    Planning artifact path mismatch            gpt-5.4            ·      ·       ·     ·       ✓*     ·
 PAN-1024   zombie_pr           Lazy-load per-turn diff summaries          gpt-5.4            ·      ·       ·     ·       ·      ·
 
-PLANNING (Opus drafting vBRIEFs)
+PLANNING (Opus drafting xBRIEFs)
 PAN-1015   Remove claudish routing in favor of CLIProxy           claude-sonnet-4-6  ◐ planning
 
 ✓ done/passing  ◐ in-progress  ✗ failed/blocked  · pending/n-a
@@ -170,7 +170,7 @@ for i in panissues:
           f"{'✓' if ready else '·'}")
 
 print()
-print("PLANNING SESSIONS (Opus drafting vBRIEFs)")
+print("PLANNING SESSIONS (Opus drafting xBRIEFs)")
 print('─' * 130)
 sessions = subprocess.check_output(['tmux','-L','overdeck','list-sessions','-F','#{session_name}']).decode().split('\n')
 for ps in sorted(s for s in sessions if s.startswith('planning-pan-')):

package/sync-sources/skills/plan/SKILL.md

@@ -2,7 +2,7 @@
 name: plan
 description: >
   Opus-driven planning for issues before Sonnet implementation. Creates workspace,
-  .pan/continue.json, .pan/spec.vbrief.json with vBRIEF tasks, and updates issue tracker.
+  .pan/continue.json, .pan/spec.vbrief.json with xBRIEF tasks, and updates issue tracker.
   Ensures strategic decisions are made by Opus, not cheaper models.
 triggers:
   - plan
@@ -31,7 +31,7 @@ license: "MIT"
 
 **Opus plans EVERYTHING. Sonnet executes.**
 
-Do NOT leave any decisions for the implementation agent. Every architectural choice, every file path, every function name, every edge case - all decided here. The implementation agent should be able to work through vBRIEF tasks mechanically without making any design decisions.
+Do NOT leave any decisions for the implementation agent. Every architectural choice, every file path, every function name, every edge case - all decided here. The implementation agent should be able to work through xBRIEF tasks mechanically without making any design decisions.
 
 ---
 
@@ -103,7 +103,7 @@ Create `.pan/continue.json` with COMPLETE planning context:
     { "id": "H1", "summary": "<risk/edge case>", "mitigation": "<how to handle it>" }
   ],
   "resumePoint": null,
-  "vBRIEF tasksMapping": {},
+  "tasksMapping": {},
   "agentModel": "plan",
   "sessionHistory": [
     { "timestamp": "<ISO timestamp>", "reason": "planning", "note": "Initial planning session", "agentModel": "plan" }
@@ -116,8 +116,8 @@ Create `.pan/continue.json` with COMPLETE planning context:
 
 ```json
 {
-  "vBRIEFInfo": {
-    "version": "0.5",
+  "xBRIEFInfo": {
+    "version": "0.8",
     "created": "<ISO timestamp>"
   },
   "plan": {
@@ -167,9 +167,9 @@ Create `.pan/continue.json` with COMPLETE planning context:
 }
 ```
 
-**CRITICAL vBRIEF Structure Rules:**
+**CRITICAL xBRIEF Structure Rules:**
 
-1. **Acceptance criteria MUST be subItems, NEVER top-level items.** Each AC is nested under its parent task/requirement as a `subItems` entry. Top-level items with `kind: "acceptance_criterion"` will fail vBRIEF Studio validation.
+1. **Acceptance criteria MUST be subItems, NEVER top-level items.** Each AC is nested under its parent task/requirement as a `subItems` entry. Top-level items with `kind: "acceptance_criterion"` will fail xBRIEF Studio validation.
 
 2. **Hierarchical IDs required.** SubItem IDs must use dot-notation from the parent: `parent-id.ac-name`. Example: `work-prompt-ac.injects-ac-per-task`. The parent prefix is mandatory.
 
@@ -183,17 +183,17 @@ Create `.pan/continue.json` with COMPLETE planning context:
 - Set `edges` to capture blocking relationships between items
 - `difficulty`: trivial (typo/config), simple (1 file), medium (2-3 files), complex (multi-system)
 - 10-40 items for a typical feature; more for large refactors
-- SubItems (acceptance criteria) are NOT converted to vBRIEF tasks — they're verification checklists
+- SubItems (acceptance criteria) are NOT converted to xBRIEF tasks — they're verification checklists
 
 **After writing the JSON file:**
 ```bash
-# Materialize vBRIEF tasks and mark the workspace spec proposed
+# Materialize xBRIEF tasks and mark the workspace spec proposed
 pan plan finalize
 ```
 
 **Cloister hand-off:** When `pan plan finalize` runs, it automatically:
 1. Reads `.pan/spec.vbrief.json` from the workspace
-2. Validates the vBRIEF tasks already stored in `plan.items[]`
+2. Validates the xBRIEF tasks already stored in `plan.items[]`
 3. Preserves dependency relationships from `edges` (blocking order)
 4. Includes acceptance criteria in task descriptions
 5. Marks `plan.status` as `proposed` so the dashboard shows Done
@@ -230,7 +230,7 @@ gh issue comment <number> --body "## Planning Complete
 **Planned by:** Claude Opus 4.6
 **Workspace:** workspaces/feature-<issue-id>/
 
-### vBRIEF tasks: <N> items in .pan/spec.vbrief.json
+### xBRIEF tasks: <N> items in .pan/spec.vbrief.json
 ### Next: /work-issue <ISSUE-ID>"
 ```