@deksden-com/dd-flow-cli 0.3.0 → 0.3.1

package/CHANGELOG.md

@@ -0,0 +1,43 @@
+# @deksden-com/dd-flow-cli
+
+## 0.3.1
+
+### Patch Changes
+
+- 16f68a3: Add router-native engine snapshot commands and routed project-command dispatch.
+
+  Also include the runtime/dashboard compatibility wave needed by the current Memory Bank canon:
+  - target-based dashboard `open`/`refresh` commands and related-command help;
+  - persisted FIFO lane waiters and merge wait-acquire specialization;
+  - `migration plan/report/verify` evidence helpers for controlled `mb-upgrade` runtime migrations;
+  - `dd-flow/project-summary@1` publication and global dashboard aggregation from project summaries.
+  - active npm release runbook notes for Changesets-generated changelogs, strict Memory Bank canon build metadata, token-safe publish, local global link and post-publish compatibility verification.
+
+## 0.3.0
+
+### Minor Changes
+
+- Add CLI version preflight support with `dd-flow version`, `dd-flow --version`, `dd-flow version --json`, Memory Bank compatibility verdicts in `dd-flow status`, and an explicit cached npm registry check through `dd-flow status --check-registry`.
+- 565c601: Add static HTML dashboard rendering for global, project, and protocol dashboard pages.
+
+  The dashboard command family now supports `--format html`, a `dashboard data` command, adjacent JSON data files, protocol pages, bundled dashboard schemas, and compatibility with existing markdown dashboards.
+
+- Add `flow_guidance` to status-like protocol/run/project/merge outputs so agents can see current stage, allowed next stages, recommended prompt/action, guard status and missing predecessor evidence without moving semantic planning into the CLI.
+- Store new `RUN-*` artifacts in DD Flow home under `~/.dd-flow/projects/<PRJ-ID>/runs/<RUN-ID>/`, while keeping legacy project `.tasks/dd-flow-runs/<RUN-ID>/` readable as compatibility input.
+- Add protocol-set continuation support: protocol dependency blockers, `protocol ready`, safe `protocol-implement` guidance, blocked-protocol start guards and compact set status data for dashboards.
+- Add `mb-sdlc-review` / `review` flow-kind support, bundled `mb-sdlc-review-report` schema validation, semantic review-report checks and dashboard counters for review runs.
+- Extend dashboard data/rendering for protocol sets, review runs and home-run stage artifacts.
+
+### Patch Changes
+
+- Keep merge queue, protocol runtime and run status in sync when a merge job completes, so agents can verify `closed` protocol state, `merged` queue state and `done/merged` run state without stale `claimed` diagnostics.
+
+## 0.2.0
+
+### Minor Changes
+
+- Expose canonical Memory Bank version visibility in `dd-flow status`, including CLI build metadata, resolved canon metadata, project Memory Bank markers, project flow pack manifest state, drift diagnostics, and the `dd-flow/status-report@1` schema.
+
+### Patch Changes
+
+- 322cae9: Add canonical Memory Bank discovery commands and runtime status output.

package/README.md

@@ -97,6 +97,28 @@ dd-flow codex home --help
 dd-flow worktree --help
 ```
 
+## Engine Router
+
+`dd-flow` is the stable router command. The router keeps immutable engine snapshots in `DD_FLOW_HOME/engines` and selects the compatible engine for project-scoped commands.
+
+Router-native engine commands do not mutate project runtime:
+
+```bash
+dd-flow engine install --json
+dd-flow engine list --json
+dd-flow engine info --json
+dd-flow engine resolve --project-root "$PWD" --json
+dd-flow engine doctor --project-root "$PWD" --json
+```
+
+Old installable engines are installed from the matching published package version without replacing the global router:
+
+```bash
+npx @deksden-com/dd-flow-cli@<version> engine install
+```
+
+Project commands keep using `dd-flow ...`; agents should not call snapshot entrypoints directly.
+
 ## Lanes And Locks
 
 A lane is a named shared operational workspace inside a project. A lane lock is a time-bound ownership lease on that workspace. The CLI enforces one active non-expired lock per project/lane; prompts decide whether a task should use a feature worktree, `direct-main`, or `merge`.
@@ -121,10 +143,20 @@ Inspect lane state:
 ```bash
 dd-flow lane status --project-root "$PROJECT_ROOT" --json
 dd-flow lane lock status --project-root "$PROJECT_ROOT" --lane merge --json
+dd-flow lane waiters --project-root "$PROJECT_ROOT" --lane merge --json
 ```
 
 Branch checks are factual diagnostics. Lock mutation and merge queue claiming validate the registered workspace path mechanically. A mismatch can help a prompt or operator notice the wrong checkout, but the CLI does not decide whether the route is semantically allowed.
 
+Persisted lane waiters let agents wait for exclusive lane ownership without token-level polling:
+
+```bash
+dd-flow lane lock wait-acquire --project-root "$PROJECT_ROOT" --lane merge --worker-id "$WORKER_ID" --path "$WORKSPACE" --timeout 300 --poll-interval 10 --ttl 300 --reason "merge worker" --json
+dd-flow lane waiter cancel --project-root "$PROJECT_ROOT" --lane merge --worker-id "$WORKER_ID" --reason "session stopped" --json
+```
+
+`wait-acquire` creates one queued waiter per `project/lane/worker-id`, preserves FIFO acquisition order, treats same-worker retries idempotently, returns `timed_out` for the command's own timeout, and leaves stale queued waiters for `cleanup scan/apply`.
+
 ## Direct Main Recipe
 
 Use `direct-main` only after the prompt or operator has chosen direct integration work for a small, low-risk task.
@@ -164,7 +196,9 @@ For supervisor-style waiting outside model tokens:
 dd-flow merge-queue wait-next --project-root "$PROJECT_ROOT" --worker-id "$WORKER_ID" --path "$MERGE_WORKSPACE" --timeout 1200 --poll-interval 10 --acquire-lock true --json
 ```
 
-With `--acquire-lock true`, `wait-next` heartbeats the merge lane lock while it waits and releases a lock it acquired itself when the wait times out. Live merge workers should prefer long waits, for example 1200 seconds / 20 minutes, so the agent sleeps inside the CLI process instead of spending model tokens on frequent polling.
+With `--acquire-lock true`, `wait-next` first uses the generic FIFO lane waiter path for `lane=merge`, then heartbeats the merge lane lock while it waits and releases a lock it acquired itself when the wait times out. Live merge workers should prefer long waits, for example 1200 seconds / 20 minutes, so the agent sleeps inside the CLI process instead of spending model tokens on frequent polling.
+
+Merge queue JSON uses `queue_item`, `protocol`, and `claim` as the primary queued/claimed protocol contract. The legacy `job` field remains as a compatibility alias during the migration window.
 
 Complete or fail the claimed job:
 
@@ -206,6 +240,32 @@ dd-flow protocol cancel PRT-... --reason "replaced by fresh run" --close-session
 
 For a stale disposable feature checkout, use `--worktree remove`. The command removes the git worktree recorded either in `worktree_records` or in stable runtime `state.workspace`; with `--force`, it also force-deletes the local feature branch when present. It refuses dirty worktrees without `--force` and refuses to remove the stable project root or the current process working directory.
 
+## mb-upgrade Runtime Migrations
+
+Normal `dd-flow` commands do not migrate project runtime or home data just because a newer router/engine can read an older project. Runtime/home data migrations belong to the explicit canonical `mb-upgrade` contour and need backup evidence, an adjacent migration chain, active-state handling and post-upgrade verification.
+
+Use migration evidence helpers from `mb-upgrade`:
+
+```bash
+dd-flow migration plan --project-root "$PROJECT_ROOT" --source-version "$OLD_MB" --target-version "$NEW_MB" --run "$RUN_ID" --backup-path "$BACKUP" --json
+dd-flow migration report --project-root "$PROJECT_ROOT" --source-version "$OLD_MB" --target-version "$NEW_MB" --run "$RUN_ID" --backup-path "$BACKUP" --json
+dd-flow migration verify --file "$RUN_HOME/03-upgrade/migration-report.json" --json
+```
+
+The report contract is `dd-flow/mb-upgrade-migration-report@1`. A blocked report is valid evidence that upgrade cannot safely mutate runtime yet; it is not permission to bypass active protocols, active runs, merge queue items or lane locks.
+
+## Project Summaries
+
+Global dashboard data should consume compact project summaries instead of scanning deep project runtime directly. Publish the current project's read model with:
+
+```bash
+dd-flow project summary --project-root "$PROJECT_ROOT" --json
+```
+
+The summary is written to `~/.dd-flow/projects/<project-id>/summary/project-summary.json` and uses `dd-flow/project-summary@1`. `dashboard refresh --project <project>` also publishes the summary before rendering dashboards. Use `--write false` to inspect the payload without writing it.
+
+Global dashboard data reads published project summaries and builds one prepared JSON model for the renderer. Compatible summaries become project cards; missing, unreadable or unsupported summaries are listed in `unsupported_projects` with a reason, summary path and install/refresh hint when available. The global dashboard also exposes `supported_summary_versions` and `summary_version_groups` so agents can see which local projects are represented by each summary contract version.
+
 ## Cleanup
 
 Use cleanup when local runtime state is stale after a crash, abandoned rerun, or removed feature worktree. `cleanup scan` is read-only. `cleanup apply` requires an explicit plan file and reason, reports requested/applied/changed/skipped action results, and dirty/destructive worktree actions require `--force --reason`. Worktree record cleanup marks a checkout `removed` only when the path is already absent; if the checkout still exists, the record is closed as `kept` rather than silently deleting files.
@@ -224,6 +284,8 @@ Dashboard markdown is rendered state, not source of truth. Successful state-chan
 
 The dashboard is intentionally compact: it shows the last update time, active protocols/sessions, merge queue summary, active locks, recent outcomes, and missing project roots without dumping full hook payloads into the main view.
 
+Dashboard JSON separates protocol lifecycle from resource coordination. New consumers should read `lifecycle`, `lifecycle_summary`, `resource_summary`, `queued_protocols`, `queue_item`, and `claim` when present. Legacy fields such as `current_stage`, `raw_stage`, `raw_status`, `merge_queue`, and `job` remain available as compatibility aliases or diagnostics during the migration window.
+
 Defaults:
 
 ```text
@@ -236,12 +298,19 @@ protocol HTML:     ~/.dd-flow/projects/<PRJ-ID>/dashboard/protocols/<PRT-ID>.htm
 Useful commands:
 
 ```bash
-dd-flow dashboard render --project-root "$PROJECT_ROOT" --json
-dd-flow dashboard render-global --json
-dd-flow dashboard refresh --project-root "$PROJECT_ROOT" --open false --json
-dd-flow dashboard open --project-root "$PROJECT_ROOT" --viewer cmux --json
+dd-flow dashboard open --json
+dd-flow dashboard refresh --json
+dd-flow dashboard refresh --all --json
+dd-flow dashboard refresh --project PRJ-001 --open false --json
+dd-flow dashboard open --project PRJ-001 --viewer cmux --json
+dd-flow dashboard data --project PRJ-001 --json
 ```
 
+Compatibility forms remain available for older prompts and scripts: `refresh-global`,
+`render-global`, `--project-root`, and `data --global`. Prefer the target-based
+commands above for new automation. `--project` accepts a full project id, short
+id, slug, or registered project root path.
+
 Config keys:
 
 ```bash

package/dist/build-info.json

@@ -1,11 +1,11 @@
 {
   "cli_package": "@deksden-com/dd-flow-cli",
-  "cli_version": "0.3.0",
-  "cli_commit": "059594c2096e080548d470e789f594e20a1a8ebd",
-  "built_at": "2026-06-30T20:32:13.018Z",
+  "cli_version": "0.3.1",
+  "cli_commit": "b677e824e7d3b1e6553e7963eeceeb1db02e86db",
+  "built_at": "2026-07-03T20:02:54.356Z",
   "built_with_canon": {
-    "version": "2.8.0",
-    "commit": "f549c33bd73d8d18b5cb07d9737b02fe638e61b8",
+    "version": "2.9.0",
+    "commit": "7e8b51c1321e290d18df3572d6ab26ed32b85403",
     "flow_contract": "dd-flow-canonical-2026-06",
     "repo_root": "/Users/deksden/Documents/_Projects/dd-memorybank",
     "memorybank_root": "/Users/deksden/Documents/_Projects/dd-memorybank/.memory-bank",

package/dist/cli/help.js

@@ -11,11 +11,14 @@ Usage:
 Core commands:
   version                       Print the installed dd-flow CLI package version.
   status                        Inspect dd-flow runtime, project and canon roots.
+  engine install/list/info      Manage locally installed dd-flow engine snapshots.
+  engine resolve/doctor         Inspect router engine selection and health.
   canon register/status/resolve Register and resolve the canonical Memory Bank.
-  project register/status       Register a project and inspect runtime state.
+  project register/status/summary Register a project, inspect state, and publish project summaries.
   project resolve/archive       Resolve typed ids and archive stale project roots.
   project migrate-ids           Migrate old project ids.
   protocol register/status/transition Register, inspect, transition and repair protocol state.
+  migration plan/report/verify  Prepare and verify mb-upgrade runtime migration evidence.
   cleanup scan/apply            Detect and repair stale local runtime state.
   run start/status/list         Track concrete flow executions and stage artifacts.
   id next                       Preview next typed ids for protocol or run allocation.
@@ -25,7 +28,7 @@ Core commands:
   merge-worker status/start/stop Manage long-lived project merge workers.
   merge-queue status/next       Claim, wait for, complete, or fail merge jobs.
   session register/status/stop  Register flow sessions and stop workers.
-  dashboard data/render/open/refresh Render markdown or HTML project/global dashboards.
+  dashboard data/render/open/refresh Render, refresh, open, and inspect project/global dashboards.
   schema validate             Validate canonical dd-flow JSON data contracts.
   memory permissions preflight Check Memory Bank write/read permissions.
   integration cmux status       Inspect optional cmux integration.
@@ -35,6 +38,8 @@ Core commands:
 Examples:
   dd-flow project register --root "$PWD"
   dd-flow version
+  dd-flow engine install --json
+  dd-flow engine resolve --project-root "$PWD" --json
   dd-flow status --project-root "$PWD" --json
   dd-flow canon register --root "$DD_MEMORYBANK" --json
   dd-flow canon resolve --json
@@ -68,6 +73,29 @@ version reports the installed dd-flow CLI package version from package metadata.
 Examples:
   dd-flow version
   dd-flow version --json`
+    ],
+    [
+        "engine",
+        `dd-flow engine - manage router-installed engine snapshots
+
+Usage:
+  dd-flow engine install [--force] --json
+  dd-flow engine list --json
+  dd-flow engine info [--package <name>] [--version <version>] --json
+  dd-flow engine resolve [--project-root <root>] --json
+  dd-flow engine doctor [--project-root <root>] --json
+
+The globally invoked dd-flow command is the stable router surface. Engine snapshots live under DD_FLOW_HOME/engines and are selected by project Memory Bank compatibility data. Running an old package through npx can install that package's own engine without replacing the global router:
+
+  npx @deksden-com/dd-flow-cli@<version> engine install
+
+Router-native engine commands never mutate project runtime data. Normal project commands are routed to a compatible engine or fail closed with a missing-engine diagnostic.
+
+Examples:
+  dd-flow engine install --json
+  dd-flow engine list --json
+  dd-flow engine resolve --project-root "$PWD" --json
+  dd-flow engine doctor --project-root "$PWD" --json`
     ],
     [
         "status",
@@ -174,12 +202,29 @@ Prefer dd-flow protocol transition in new prompts and scripts. This top-level al
 Usage:
   dd-flow project register --root <root> --json
   dd-flow project status --root <root> --json
+  dd-flow project summary --project-root <root> [--write true|false] --json
   dd-flow project resolve <PRJ-ID|PRJ-NNN> --json
   dd-flow project archive <PRJ-ID|PRJ-NNN> --reason <text> --json
   dd-flow project archive --root <previous-root-path> --reason <text> --json
   dd-flow project migrate-ids --root <root> [--apply] --json
 
-New registrations use full typed ids such as PRJ-001-dd-flow-playground and short aliases such as PRJ-001. project resolve accepts full id or unique short alias. project archive removes stale or deleted project roots from active dashboards without deleting history. Re-registering an existing root reactivates it. migrate-ids is the explicit transition path for old hash-based local project ids; without --apply it returns a dry-run plan.`
+New registrations use full typed ids such as PRJ-001-dd-flow-playground and short aliases such as PRJ-001. project resolve accepts full id or unique short alias. project summary writes dd-flow/project-summary@1 to the project's home summary directory by default; use --write false to inspect the payload without writing. project archive removes stale or deleted project roots from active dashboards without deleting history. Re-registering an existing root reactivates it. migrate-ids is the explicit transition path for old hash-based local project ids; without --apply it returns a dry-run plan.`
+    ],
+    [
+        "migration",
+        `dd-flow migration - plan and verify mb-upgrade runtime/home data migrations
+
+Usage:
+  dd-flow migration plan --project-root <root> [--source-version <version>] [--target-version <version>] [--run <RUN-ID>] [--backup-path <path>] [--backup-created-at <iso>] [--allow-active true|false] --json
+  dd-flow migration report --project-root <root> [--source-version <version>] [--target-version <version>] [--run <RUN-ID>] [--backup-path <path>] [--backup-created-at <iso>] [--allow-active true|false] --json
+  dd-flow migration verify --file <mb-upgrade-migration-report.json> --json
+
+Migration commands are evidence and guardrail helpers for canonical mb-upgrade. They do not silently migrate runtime/home data during ordinary CLI use. Applying migrations remains an explicit mb-upgrade contour with backup, adjacent migration chain, active-state handling, derived artifact regeneration and post-upgrade verification.
+
+Related commands:
+  dd-flow status --project-root <root> --json
+  dd-flow memory permissions preflight --root <root> --memory-bank .memory-bank --flow mb-upgrade --mode write --json
+  dd-flow dashboard refresh --project <project> --json`
     ],
     [
         "lane",
@@ -187,13 +232,16 @@ New registrations use full typed ids such as PRJ-001-dd-flow-playground and shor
 
 Usage:
   dd-flow lane status --project-root <root> --json
+  dd-flow lane waiters --project-root <root> [--lane <name>] --json
   dd-flow lane workspace <action> [options] --json
   dd-flow lane lock <action> [options] --json
+  dd-flow lane waiter <action> [options] --json
 
 Use lanes when multiple agents might edit or merge through the same workspace. The CLI enforces mechanical ownership only; prompts decide whether a route should use merge, direct-main, or a feature worktree.
 
 Examples:
   dd-flow lane status --project-root "$PWD" --json
+  dd-flow lane waiters --project-root "$PWD" --lane merge --json
   dd-flow lane workspace set --project-root "$PWD" --lane direct-main --path "$PWD" --branch main --json
   dd-flow lane lock status --project-root "$PWD" --lane direct-main --json`
     ],
@@ -221,13 +269,30 @@ Usage:
   dd-flow lane lock release --project-root <root> --lane <name> --worker-id <id> [--path <workspace>] [--lease-token <token>] --reason <text> --json
   dd-flow lane lock status --project-root <root> --lane <name> --json
   dd-flow lane lock wait --project-root <root> --lane <name> --worker-id <id> [--path <workspace>] --timeout <seconds> --poll-interval <seconds> --json
+  dd-flow lane lock wait-acquire --project-root <root> --lane <name> --worker-id <id> [--path <workspace>] --timeout <seconds> --poll-interval <seconds> [--ttl 300] --reason <text> --json
 
-Lock mutation commands validate that --path, or the current working directory when --path is omitted, matches the registered lane workspace. Only the owner can heartbeat or release an active lease. Expired leases can be taken over mechanically and are recorded in audit.
+Lock mutation commands validate that --path, or the current working directory when --path is omitted, matches the registered lane workspace. Only the owner can heartbeat or release an active lease. wait-acquire creates a persisted FIFO waiter before acquiring the lock. Expired leases and stale waiters are recorded in audit.
 
 Examples:
   dd-flow lane lock acquire --project-root "$PWD" --lane merge --worker-id worker-1 --path "$PWD" --ttl 300 --reason "merge worker" --json
+  dd-flow lane lock wait-acquire --project-root "$PWD" --lane merge --worker-id worker-1 --path "$PWD" --timeout 300 --poll-interval 10 --reason "merge worker" --json
   dd-flow lane lock heartbeat --project-root "$PWD" --lane merge --worker-id worker-1 --path "$PWD" --lease-token "$TOKEN" --json
   dd-flow lane lock release --project-root "$PWD" --lane merge --worker-id worker-1 --path "$PWD" --lease-token "$TOKEN" --reason done --json`
+    ],
+    [
+        "lane waiter",
+        `dd-flow lane waiter - inspect and cancel persisted lane waiters
+
+Usage:
+  dd-flow lane waiters --project-root <root> [--lane <name>] --json
+  dd-flow lane waiter cancel --project-root <root> --lane <name> --worker-id <id> --reason <text> --json
+
+Waiters are runtime coordination records, not protocols or domain jobs. Use waiters to coordinate fair access to exclusive lanes before a worker owns the lane lock.
+
+Related lane commands:
+  dd-flow lane lock wait-acquire --project-root "$PWD" --lane merge --worker-id worker-1 --path "$PWD" --timeout 300 --poll-interval 10 --reason "merge worker" --json
+  dd-flow lane lock status --project-root "$PWD" --lane merge --json
+  dd-flow lane waiter cancel --project-root "$PWD" --lane merge --worker-id worker-1 --reason "session stopped" --json`
     ],
     [
         "merge",
@@ -237,7 +302,7 @@ Usage:
   dd-flow merge status --project-root <root> --json
   dd-flow merge one-shot --project-root <root> --worker-id <id> [--path <workspace>] --json
 
-merge status reports active merge worker, claimed jobs, active merge lane lock and queue state. merge one-shot is status-only when a long-lived worker, claimed job or active lock exists; otherwise it acquires the merge lane, claims at most one ready job, and returns that job for the shared merge job prompt. If no job is ready, it releases the lock and returns job: null.`
+merge status reports active merge worker, claimed protocols, active merge lane lock and queue state. merge one-shot is status-only when a long-lived worker, claimed protocol or active lock exists; otherwise it acquires the merge lane, claims at most one ready protocol, and returns queue_item/protocol/claim plus legacy job for the shared merge job prompt. If no protocol is ready, it releases the lock and returns queue_item: null and job: null.`
     ],
     [
         "merge-worker",
@@ -263,7 +328,7 @@ Usage:
   dd-flow merge-queue fail <protocol-id> --worker-id <id> [--path <workspace>] --reason <text> --requeue true|false --json
   dd-flow merge-queue cancel <protocol-id> --reason <text> [--worker-id <id>] [--path <workspace>] [--force] --json
 
-The worker must own the merge lane from the registered merge workspace before claiming, completing, or failing jobs. note updates the final completion summary after post-complete cleanup and does not require a lane lock. --path defaults to the current working directory. Use --worker-id as the owner identity.
+The worker must own the merge lane from the registered merge workspace before claiming, completing, or failing queued protocols. Outputs use queue_item/protocol/claim as the primary contract and retain job as a compatibility alias. note updates the final completion summary after post-complete cleanup and does not require a lane lock. --path defaults to the current working directory. Use --worker-id as the owner identity.
 
 Examples:
   dd-flow merge-queue wait-next --project-root "$PWD" --worker-id merge-worker --path "$PWD" --timeout 1200 --poll-interval 10 --acquire-lock true --json
@@ -282,12 +347,12 @@ cleanup scan is read-only and returns deterministic findings plus plan.actions.
     ],
     [
         "merge-queue wait-next",
-        `dd-flow merge-queue wait-next - wait for the next ready merge job
+        `dd-flow merge-queue wait-next - wait for the next ready merge protocol
 
 Usage:
   dd-flow merge-queue wait-next --project-root <root> --worker-id <id> [--path <workspace>] --timeout <seconds> --poll-interval <seconds> [--acquire-lock true] --json
 
-Use this from a shell or supervisor to wait outside model tokens. Live merge workers should prefer long waits, for example --timeout 1200 --poll-interval 10, so the agent sleeps inside the CLI process instead of spending model tokens on frequent polling. If --acquire-lock true is used, the merge lock is heartbeated while waiting and a lock acquired by this command is released on timeout. If a job is ready, it is claimed atomically. If no job appears before the timeout, the command returns a structured timeout result.
+Use this from a shell or supervisor to wait outside model tokens. Live merge workers should prefer long waits, for example --timeout 1200 --poll-interval 10, so the agent sleeps inside the CLI process instead of spending model tokens on frequent polling. If --acquire-lock true is used, wait-next first enters the generic FIFO lane waiter path (lane lock wait-acquire --lane merge), then heartbeats the merge lock while waiting for a ready protocol. A lock acquired by this command is released on timeout. If a protocol is ready, it is claimed atomically. If no protocol appears before the timeout, the command returns outcome: wait_timeout with queue_item: null and legacy job: null.
 
 Examples:
   dd-flow merge-queue wait-next --project-root "$PWD" --worker-id supervisor --path "$PWD" --timeout 1200 --poll-interval 10 --acquire-lock true --json`
@@ -332,18 +397,41 @@ Usage:
     ],
     [
         "dashboard",
-        `dd-flow dashboard - render or open markdown and HTML dashboards
+        `dd-flow dashboard - render, refresh, open, and inspect markdown/HTML dashboards
 
 Usage:
-  dd-flow dashboard data --project-root <root> [--protocol <PRT-ID>] --json
-  dd-flow dashboard data --global --json
-  dd-flow dashboard render --project-root <root> [--format markdown|html] [--protocol <PRT-ID>] [--output <path>] --json
+  dd-flow dashboard open [--viewer cmux] [--format html|markdown] --json
+  dd-flow dashboard refresh [--format html|markdown] --json
+  dd-flow dashboard refresh --all [--format html|markdown] --json
+  dd-flow dashboard refresh --project <project> [--format html|markdown] [--protocol <PRT-ID>] [--open auto|true|false] --json
+  dd-flow dashboard open --project <project> [--protocol <PRT-ID>] [--viewer cmux] [--format html] --json
+  dd-flow dashboard data [--project <project>] [--protocol <PRT-ID>] --json
+  dd-flow dashboard render [--project <project>] [--format html|markdown] [--protocol <PRT-ID>] [--output <path>] --json
+
+Compatibility aliases and explicit low-level forms:
+  dd-flow dashboard refresh-global [--format markdown|html] [--output <path>] --json
+    Preferred: dd-flow dashboard refresh
   dd-flow dashboard render-global [--format markdown|html] [--output <path>] --json
-  dd-flow dashboard open --project-root <root> [--format markdown|html] [--viewer cmux] --json
+    Preferred: dd-flow dashboard render
   dd-flow dashboard refresh --project-root <root> [--format markdown|html] [--protocol <PRT-ID>] [--open auto|true|false] --json
-  dd-flow dashboard refresh-global [--format markdown|html] [--output <path>] --json
+    Preferred: dd-flow dashboard refresh --project <project>
+  dd-flow dashboard open --project-root <root> [--format markdown|html] [--viewer cmux] --json
+    Preferred: dd-flow dashboard open --project <project>
+  dd-flow dashboard render --project-root <root> [--format markdown|html] [--protocol <PRT-ID>] [--output <path>] --json
+    Preferred: dd-flow dashboard render --project <project>
+  dd-flow dashboard data --global --json
+    Preferred: dd-flow dashboard data
+
+Project accepts full id, short id, slug, or registered project root path.
+
+Related dashboard commands:
+  dd-flow dashboard open
+  dd-flow dashboard refresh
+  dd-flow dashboard refresh --all
+  dd-flow dashboard open --project <project>
+  dd-flow dashboard data --project <project> --json
 
-Dashboards are rendered views of dd-flow state. Markdown remains the compatibility fallback. HTML dashboards write JSON next to self-contained local HTML: global under DD_FLOW_HOME/dashboard/ and project/protocol pages under DD_FLOW_HOME/projects/<PRJ-ID-slug>/dashboard/. State-changing commands still auto-refresh markdown during the transition. cmux is used only by explicit open/refresh commands and only according to project config.`
+Dashboards are rendered views of dd-flow state. Markdown remains the compatibility fallback. HTML dashboards write JSON next to self-contained local HTML: global under DD_FLOW_HOME/dashboard/ and project/protocol pages under DD_FLOW_HOME/projects/<PRJ-ID-slug>/dashboard/. Dashboard JSON uses lifecycle/resource/claim fields as the primary contract when present; current_stage/raw_stage/raw_status/merge_queue/job are compatibility or diagnostic fields. Global dashboard data consumes published project summaries, exposes supported_summary_versions and summary_version_groups, and lists missing/unreadable/unsupported project summaries under unsupported_projects instead of silently hiding those projects. State-changing commands still auto-refresh markdown during the transition. cmux is used only by explicit open/refresh commands and only according to project config. JSON mode writes machine-readable output only.`
     ],
     [
         "schema",