@femtomc/mu-agent 26.2.107 → 26.2.109

package/prompts/skills/core/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: core
-description: "Meta-skill for core mu operating primitives. Routes to mu, memory, tmux, and code-mode based on task shape."
+description: "Meta-skill for core mu operating primitives. Routes to mu, programmable-ui, memory, tmux, and code-mode based on task shape."
 ---
 
 # core
@@ -10,19 +10,22 @@ Use this meta-skill when the user asks for general `mu` operation guidance and y
 ## Subskills
 
 - `mu` — default CLI-first operating workflow (inspect, mutate, verify, handoff).
-- `memory` — historical context retrieval, timeline reconstruction, and memory-index maintenance.
+- `programmable-ui` — canonical `mu_ui`/`UiDoc` workflow for publishing, inspecting, and debugging interactive UI docs.
+- `memory` — prior-context retrieval, timeline reconstruction, and memory-index maintenance.
 - `tmux` — persistent terminal/session substrate for bounded command execution and fan-out.
 - `code-mode` — tmux-backed REPL loops for iterative execution and context compression.
 
 ## Selection guide
 
 1. Start with `mu` for most day-to-day operator work.
-2. Add `memory` when historical context or timeline anchors are required.
-3. Add `tmux` when durable shell state or parallel worker shells are needed.
-4. Add `code-mode` when solving by live execution is cheaper than chat-only reasoning.
+2. Route to `programmable-ui` when the user asks about `mu_ui`, `/mu ui ...`, `UiDoc` payloads, action wiring, or interactive prompt behavior.
+3. Add `memory` when prior context or timeline anchors are required.
+4. Add `tmux` when durable shell state or parallel worker shells are needed.
+5. Add `code-mode` when solving by live execution is cheaper than chat-only reasoning.
 
 ## Common patterns
 
 - **Bounded investigation**: Use `mu` commands (`get`, `read`, `health`) to inspect current state, then use `memory` to find "when did this last work?" before attempting a fix.
+- **Programmable UI scaffolding**: Route to `programmable-ui` to emit schema-valid `UiDoc` templates quickly, verify state with `/mu ui status|snapshot`, and close docs with `mu_ui remove|clear`.
 - **Context compression**: If a user asks for complex debugging that involves running code and printing huge errors, route to `code-mode`. The agent can spin up a REPL, iterate on a fix offline, and return only the root cause to the chat.
 - **Parallel fan-out**: If a command takes a long time, or needs to run across multiple directories, route to `tmux` to spawn parallel worker shells, keep them running in the background, and periodically read their output.

package/prompts/skills/core/memory/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: memory
-description: "Runs cross-store memory retrieval and index maintenance workflows with bounded filters and timeline anchors. Use when querying historical context or repairing memory index health."
+description: "Runs cross-store memory retrieval and index maintenance workflows with bounded filters and timeline anchors. Use when querying prior context or repairing memory index health."
 ---
 
 # memory
 
-Use this skill when the user asks for historical context lookup, timeline reconstruction,
+Use this skill when the user asks for prior-context lookup, timeline reconstruction,
 or memory index diagnostics.
 
 ## Contents

package/prompts/skills/core/mu/SKILL.md

@@ -197,7 +197,15 @@ One-shot prompt (no durable session):
 mu exec --message "<task>" --json
 ```
 
-In attached terminal operator chat, `/mu` helpers are available (`/mu events`, `/mu hud ...`, `/mu help`).
+In attached terminal operator chat, `/mu` helpers are available (`/mu events`, `/mu ui status`, `/mu ui snapshot compact`, `/mu help`).
+
+Canonical visibility checks while running orchestrated work:
+
+```bash
+/mu ui status
+/mu ui snapshot compact
+/mu ui snapshot multiline
+```
 
 ## Durable automation handoff
 
@@ -209,10 +217,14 @@ mu cron --help
 ```
 
 When work is multi-step and issue-graph driven, use `planning` to shape the DAG,
-then `hud` for canonical HUD behavior, then `protocol` to keep DAG
-semantics consistent, then `control-flow` for explicit loop/termination policy,
-then `model-routing` for per-issue provider/model/thinking selection overlays,
-then `execution` for durable execution supervision.
+then `protocol` to keep DAG semantics consistent, then `control-flow` for explicit
+loop/termination policy, then `model-routing` for per-issue provider/model/thinking
+selection overlays, then `execution` for durable execution supervision.
+Keep operator↔human communication mu_ui-first across these skills:
+- one non-interactive status doc per active profile (`metadata.profile.variant: "status"`)
+- separate interactive prompt docs for decisions (`metadata.command_text` actions)
+- explicit `mu_ui remove` teardown for resolved prompts and completed passes
+For focused `UiDoc` schema templates/action wiring/status diagnostics, use `programmable-ui`.
 For REPL-driven exploration and context compression, use `code-mode`.
 For persistent terminal sessions and worker fan-out mechanics, use `tmux`.
 For recurring bounded automation loops, use `heartbeats`.
@@ -234,9 +246,10 @@ For wall-clock schedules (one-shot, interval, cron-expression), use `crons`.
 
 ## Escalation map
 
-- Historical context retrieval and index maintenance: **`memory`**
+- Prior-context retrieval and index maintenance: **`memory`**
 - Planning/decomposition and DAG review: **`planning`**
-- HUD contract/state updates across surfaces: **`hud`**
+- Programmable UI schema/templates/action-routing diagnostics: **`programmable-ui`**
+- mu_ui-first status/prompt communication patterns for DAG work: **`planning`**, **`execution`**, **`control-flow`**, **`model-routing`**
 - Shared DAG semantics for planning + execution: **`protocol`**
 - Loop/termination policy overlays (review gates, retries, escalation): **`control-flow`**
 - Per-issue model/provider/thinking selection overlays: **`model-routing`**

package/prompts/skills/core/programmable-ui/SKILL.md

@@ -0,0 +1,299 @@
+---
+name: programmable-ui
+description: "Builds and debugs mu_ui UiDocs with schema-valid payloads, interaction wiring, and status/snapshot verification."
+---
+
+# programmable-ui
+
+Use this skill when the task involves `mu_ui`, `UiDoc` payloads, interactive actions, or `/mu ui ...` inspection commands.
+
+## Contents
+
+- [Core contract](#core-contract)
+- [60-second quickstart](#60-second-quickstart)
+- [UiDoc schema cheat sheet](#uidoc-schema-cheat-sheet)
+- [mu_ui action semantics](#mu_ui-action-semantics)
+- [Canonical templates](#canonical-templates)
+- [Status-profile rules](#status-profile-rules)
+- [Debugging playbook](#debugging-playbook)
+- [Verify and teardown checklist](#verify-and-teardown-checklist)
+- [Evaluation scenarios](#evaluation-scenarios)
+
+## Core contract
+
+1. **Publish schema-valid docs only**
+   - `mu_ui` accepts `doc: object`, but runtime validation is strict (`UiDoc` schema).
+   - Invalid payloads fail with `Invalid UiDoc.`.
+
+2. **Keep interaction command-driven**
+   - Interactive actions must set `action.metadata.command_text` (for example `/answer yes`).
+   - User clicks/taps are translated back into normal command turns.
+
+3. **Separate status and decisions**
+   - Keep one non-interactive status doc per active profile (`metadata.profile.variant: "status"`).
+   - Use separate interactive docs for user decisions.
+
+4. **Use monotonic revisions**
+   - Increment `revision.version` on each update for the same `ui_id`.
+   - Replays/reconnects keep the highest revision deterministically.
+
+5. **Read -> act -> verify**
+   - After each `set|update|replace|remove|clear`, check `/mu ui status` and `/mu ui snapshot`.
+
+6. **Close docs explicitly**
+   - Resolve prompts with `mu_ui remove` (preferred) or `mu_ui clear`.
+
+## 60-second quickstart
+
+1. Publish one interactive doc:
+
+```json
+{
+  "action": "set",
+  "doc": {
+    "v": 1,
+    "ui_id": "ui:demo",
+    "title": "Demo",
+    "summary": "Minimal interactive panel",
+    "components": [
+      { "kind": "text", "id": "intro", "text": "Choose an option", "metadata": {} }
+    ],
+    "actions": [
+      {
+        "id": "ack",
+        "label": "Acknowledge",
+        "kind": "primary",
+        "payload": { "choice": "ack" },
+        "metadata": { "command_text": "/answer ack" }
+      }
+    ],
+    "revision": { "id": "rev:demo:1", "version": 1 },
+    "updated_at_ms": 1,
+    "metadata": {}
+  }
+}
+```
+
+2. Verify live state:
+
+```text
+/mu ui status
+/mu ui snapshot compact
+/mu ui snapshot multiline
+```
+
+3. Handle command (`/answer ack`) in normal skill logic.
+
+4. Remove prompt doc:
+
+```json
+{ "action": "remove", "ui_id": "ui:demo" }
+```
+
+## UiDoc schema cheat sheet
+
+Required top-level fields for each doc:
+
+- `v`: `1`
+- `ui_id`: non-empty string (max 64)
+- `title`: non-empty string
+- `components`: non-empty array (`text|list|key_value|divider`)
+- `revision`: `{ id: string, version: nonnegative int }`
+- `updated_at_ms`: nonnegative integer
+
+Common optional fields (recommended):
+
+- `summary`: deterministic fallback summary
+- `actions`: interactive options (empty for pure status)
+- `metadata`: profile/snapshot metadata and custom annotations
+
+Component minimums:
+
+- `text`: `id`, `text`
+- `list`: `id`, `items[]` (`id`, `label`, optional `detail`, optional `tone`)
+- `key_value`: `id`, `rows[]` (`key`, `value`, optional `tone`)
+- `divider`: `id`
+
+Action minimums:
+
+- `id`, `label`
+- `metadata.command_text` required for interactive routing
+- optional: `kind`, `description`, `payload`, `component_id`, `callback_token`
+
+## mu_ui action semantics
+
+- `status`
+  - Returns count, `ui_id` list, status-profile counts/warnings, and awaiting counts.
+- `snapshot`
+  - `snapshot_format`: `compact|multiline` (defaults to `compact`).
+- `set`
+  - Upsert one doc by `ui_id`.
+- `update`
+  - Same behavior as `set` (single-doc upsert).
+- `replace`
+  - Replace entire active doc set with `docs[]`.
+- `remove`
+  - Remove one doc by `ui_id`.
+- `clear`
+  - Remove all docs for the session.
+
+## Canonical templates
+
+### 1) Interactive `/answer` prompt
+
+```json
+{
+  "action": "set",
+  "doc": {
+    "v": 1,
+    "ui_id": "ui:answer",
+    "title": "Answer",
+    "summary": "Please choose yes or no",
+    "components": [
+      { "kind": "text", "id": "prompt", "text": "Choose an answer", "metadata": {} }
+    ],
+    "actions": [
+      {
+        "id": "answer_yes",
+        "label": "Yes",
+        "kind": "primary",
+        "payload": { "choice": "yes" },
+        "metadata": { "command_text": "/answer yes" }
+      },
+      {
+        "id": "answer_no",
+        "label": "No",
+        "kind": "secondary",
+        "payload": { "choice": "no" },
+        "metadata": { "command_text": "/answer no" }
+      }
+    ],
+    "revision": { "id": "rev:answer:1", "version": 1 },
+    "updated_at_ms": 1,
+    "metadata": {}
+  }
+}
+```
+
+Handler contract:
+
+1. Parse `/answer <choice>`.
+2. Validate choice.
+3. `mu_ui remove` (or `clear`) for `ui:answer`.
+4. Emit normal response.
+
+### 2) Status-profile doc (non-interactive)
+
+```json
+{
+  "action": "set",
+  "doc": {
+    "v": 1,
+    "ui_id": "ui:planning",
+    "title": "Planning status",
+    "summary": "Drafting issue DAG",
+    "components": [
+      {
+        "kind": "key_value",
+        "id": "kv",
+        "rows": [
+          { "key": "phase", "value": "decomposition" },
+          { "key": "next", "value": "approval prompt" }
+        ],
+        "metadata": {}
+      },
+      {
+        "kind": "list",
+        "id": "milestones",
+        "items": [
+          { "id": "m1", "label": "Root issue captured" },
+          { "id": "m2", "label": "Leaf tasks drafted" }
+        ],
+        "metadata": {}
+      }
+    ],
+    "actions": [],
+    "revision": { "id": "rev:planning:12", "version": 12 },
+    "updated_at_ms": 1730000000000,
+    "metadata": {
+      "profile": {
+        "id": "planning",
+        "variant": "status",
+        "snapshot": {
+          "compact": "planning: DAG draft ready",
+          "multiline": "phase: decomposition\nnext: approval prompt"
+        }
+      }
+    }
+  }
+}
+```
+
+### 3) Parameterized command text with payload defaults
+
+```json
+{
+  "id": "approve",
+  "label": "Approve",
+  "payload": { "choice": "approve", "note": "looks good" },
+  "metadata": { "command_text": "/answer choice={{choice}} note={{note}}" }
+}
+```
+
+In terminal UI interaction flow, placeholders are auto-filled from `payload` when possible, and unresolved fields are prompted.
+
+## Status-profile rules
+
+When `metadata.profile.id` is one of `planning|subagents|control-flow|model-routing` and variant is `status`:
+
+- expected `ui_id` values:
+  - `planning` -> `ui:planning`
+  - `subagents` -> `ui:subagents`
+  - `control-flow` -> `ui:control-flow`
+  - `model-routing` -> `ui:model-routing`
+- keep `actions: []` (status docs are non-interactive)
+- include `summary` plus `metadata.profile.snapshot.compact`
+- preferred components by profile:
+  - `planning`: `key_value` + `list`
+  - `subagents`: `key_value` + `list`
+  - `control-flow`: `key_value`
+  - `model-routing`: `key_value` + `list`
+
+Use `/mu ui status` to catch profile warnings early.
+
+## Debugging playbook
+
+- **`doc is required`**
+  - Missing `doc` parameter for `set|update`.
+- **`Invalid UiDoc.`**
+  - Schema mismatch. Re-check required fields and component/action shapes.
+- **`docs must be an array` / `docs[i]: invalid UiDoc`**
+  - `replace` payload malformed.
+- **Action appears but cannot run**
+  - Missing/empty `metadata.command_text`, or status-profile doc (actions intentionally non-runnable).
+- **`awaiting` stays non-zero**
+  - Prompt doc still active. Remove with `mu_ui remove` once handled.
+
+## Verify and teardown checklist
+
+After each change:
+
+1. `/mu ui status` shows expected doc count and ids.
+2. `/mu ui snapshot compact` shows deterministic summary.
+3. `/mu ui snapshot multiline` shows readable panel/action projection.
+4. Prompt resolved? Remove/clear doc explicitly.
+5. Keep issue/forum truth in sync; `mu_ui` is communication state, not source-of-truth task state.
+
+## Evaluation scenarios
+
+1. **First-time interactive prompt**
+   - Publish `ui:answer`, click action, confirm `/answer ...` reaches normal handler, remove prompt doc.
+
+2. **Status + decision split**
+   - Keep `ui:planning` status-profile doc active; open separate interactive approval doc; verify status remains non-interactive.
+
+3. **Replay/reconnect safety**
+   - Publish revisions 1 then 2; replay stale rev 1; verify highest revision remains active.
+
+4. **Channel degrade resilience**
+   - Ensure every actionable row has deterministic `command_text` fallback so manual command entry always works.

package/prompts/skills/subagents/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: subagents
-description: "Meta-skill for protocol-driven planning and execution. Routes to planning, protocol, execution, control-flow, model-routing, and hud."
+description: "Meta-skill for protocol-driven planning and execution. Routes to planning, protocol, execution, control-flow, and model-routing with mu_ui-first communication."
 ---
 
 # subagents
@@ -14,21 +14,105 @@ Use this meta-skill when work should run through the full multi-agent DAG stack.
 - `execution` — durable orchestration/supervision loop over the DAG.
 - `control-flow` — loop/termination overlays (`flow:*`) on top of protocol primitives.
 - `model-routing` — provider/model/thinking overlays (`route:*`) from live harness capabilities.
-- `hud` — canonical HUD ownership/update/teardown contract.
 
-## Hard-cutover naming
+## Naming conventions
 
 - Use `protocol` (not `orchestration`).
-- Use `execution` (not the old execution leaf named `subagents`).
+- Use `execution` for execution/supervision workflows.
 
 ## Recommended bundles
 
-- Planning bundle: `planning` + `protocol` + `hud`
-- Execution bundle: `execution` + `protocol` + `hud`
+- Planning bundle: `planning` + `protocol`
+- Execution bundle: `execution` + `protocol`
 - Policy overlays: add `control-flow` and/or `model-routing` as needed
 
+## Canonical mu_ui communication pattern
+
+Use `mu_ui` as the shared operator↔human surface during planning/execution passes.
+
+```bash
+/mu ui status
+/mu ui snapshot compact
+/mu ui snapshot multiline
+```
+
+Status doc example (`ui:subagents`):
+
+```json
+{
+  "action": "set",
+  "doc": {
+    "v": 1,
+    "ui_id": "ui:subagents",
+    "title": "Subagents execution status",
+    "summary": "ready=2 · active=1 · blocked=0",
+    "components": [
+      {
+        "kind": "key_value",
+        "id": "queue",
+        "title": "Queue",
+        "rows": [
+          { "key": "ready", "value": "2" },
+          { "key": "active", "value": "1" },
+          { "key": "blocked", "value": "0" }
+        ],
+        "metadata": {}
+      }
+    ],
+    "actions": [],
+    "revision": { "id": "subagents-status", "version": 3 },
+    "updated_at_ms": 1772060000000,
+    "metadata": {
+      "profile": {
+        "id": "subagents",
+        "variant": "status",
+        "snapshot": {
+          "compact": "ready=2 · active=1 · blocked=0",
+          "multiline": "ready: 2\nactive: 1\nblocked: 0"
+        }
+      }
+    }
+  }
+}
+```
+
+Interactive prompt example (`ui:subagents:handoff`):
+
+```json
+{
+  "action": "set",
+  "doc": {
+    "v": 1,
+    "ui_id": "ui:subagents:handoff",
+    "title": "Execution handoff decision",
+    "components": [
+      { "kind": "text", "id": "question", "text": "Close root now?", "metadata": {} }
+    ],
+    "actions": [
+      {
+        "id": "close-root",
+        "label": "Close root",
+        "kind": "primary",
+        "payload": {},
+        "metadata": { "command_text": "/answer close-root" }
+      }
+    ],
+    "revision": { "id": "subagents-handoff", "version": 1 },
+    "updated_at_ms": 1772060005000,
+    "metadata": { "profile": { "id": "subagents-handoff", "variant": "interactive" } }
+  }
+}
+```
+
+Teardown/handoff uses explicit removes:
+
+```json
+{"action":"remove","ui_id":"ui:subagents:handoff"}
+{"action":"remove","ui_id":"ui:subagents"}
+```
+
 ## Common patterns
 
-- **End-to-End Orchestration**: Route to `planning` to get a structured issue DAG, present the plan in the `hud` to the user, then route to `execution` to drive the workers until the DAG is complete.
+- **End-to-End Orchestration**: Route to `planning` to get a structured issue DAG, publish plan state in `ui:planning` (status) plus `ui:planning:approval` (interactive prompt) when needed, then route to `execution` to drive workers until DAG completion.
 - **DAG Recovery / Unblocking**: If a DAG stalls, route to `protocol` to inspect `mu issues ready` constraints, followed by a bounded `execution` pass to claim and manually unblock the stalled task.
-- **Differentiated Model Provisioning**: If different nodes need different abilities (e.g. specialized docs vs. complex refactoring), add `model-routing` to set `route:model-routing-v1` policies per issue. The `execution` worker shell will then automatically spin up the required model profiles based on those policies.
+- **Differentiated Model Provisioning**: If different nodes need different abilities (for example specialized docs vs. complex refactoring), add `model-routing` to set `route:model-routing-v1` policies per issue. The `execution` worker shell will then launch the required model profiles based on those policies.

package/prompts/skills/subagents/control-flow/SKILL.md

@@ -17,7 +17,7 @@ shared protocol.
 - [Transition table](#transition-table)
 - [Planning handoff contract](#planning-handoff-contract)
 - [Subagents/heartbeat execution contract](#subagentsheartbeat-execution-contract)
-- [HUD visibility and teardown](#hud-visibility-and-teardown)
+- [mu_ui visibility and handoff](#mu_ui-visibility-and-handoff)
 - [Evaluation scenarios](#evaluation-scenarios)
 
 ## Purpose
@@ -37,7 +37,7 @@ Load these skills before applying control-flow policies:
 - `protocol` (protocol primitives/invariants)
 - `execution` (durable execution runtime)
 - `heartbeats` and/or `crons` (scheduler clock)
-- `hud` (required visibility/handoff surface)
+- `mu` (for `/mu ui` inspection commands and communication checks)
 
 ## Core contract
 
@@ -128,29 +128,134 @@ Per orchestrator tick:
 4. Verify with:
    - `mu issues ready --root <root-id> --tag proto:hierarchical-work-v1 --pretty`
    - `mu issues validate <root-id>`
-5. Post one concise ORCH_PASS update.
-6. If final: disable heartbeat program.
+5. Upsert control-flow visibility via `mu_ui` (`ui_id:"ui:subagents"` when orchestration is shared, or `ui_id:"ui:control-flow"` when standalone).
+6. Post one concise ORCH_PASS update.
+7. If final: disable heartbeat program.
 
 Reusable bounded heartbeat prompt fragment:
 
 ```text
-Use skills subagents, protocol, execution, control-flow, and hud.
+Use skills subagents, protocol, execution, control-flow, and mu.
 For root <root-id>, enforce flow:review-gated-v1 with spawn-per-attempt rounds.
-Run exactly one bounded control-flow transition pass, verify DAG state,
+Run exactly one bounded control-flow transition pass, keep control-flow visibility
+current via mu_ui (`ui:subagents` or `ui:control-flow`), verify DAG state,
 post one ORCH_PASS, and stop. If validate is final, disable the supervising
 heartbeat and report completion.
 ```
 
-## HUD visibility and teardown
+## mu_ui visibility and handoff
+
+Use `mu_ui` as the primary communication surface for active control-flow
+execution.
+
+- Publish control-flow status in one status-profile doc:
+  - shared orchestration: `ui_id:"ui:subagents"`
+  - standalone control-flow loop: `ui_id:"ui:control-flow"`
+- Set profile metadata for deterministic snapshots:
+  - `metadata.profile.id: "subagents"` or `"control-flow"`
+  - `metadata.profile.variant: "status"`
+  - `metadata.profile.snapshot.compact|multiline`
+- Keep status docs non-interactive (`actions: []`).
+- For user decisions (for example max-round escalation), publish a separate
+  interactive prompt doc (for example `ui_id:"ui:control-flow:escalation"`).
+- Update status docs each bounded pass before posting `ORCH_PASS`.
+- On completion or handoff, remove control-flow-owned docs with explicit
+  `mu_ui remove` actions. Prefer `remove` over `clear`.
+
+### Canonical status doc (`ui:control-flow`)
+
+```json
+{
+  "action": "set",
+  "doc": {
+    "v": 1,
+    "ui_id": "ui:control-flow",
+    "title": "Control-flow status",
+    "summary": "policy=review-gated · round=2/3 · state=review_pending",
+    "components": [
+      {
+        "kind": "key_value",
+        "id": "policy",
+        "title": "Review gate",
+        "rows": [
+          { "key": "policy", "value": "flow:review-gated-v1" },
+          { "key": "round", "value": "2/3" },
+          { "key": "attempt", "value": "mu-attempt-2" },
+          { "key": "review", "value": "mu-review-2" },
+          { "key": "next", "value": "Run review_2" }
+        ],
+        "metadata": {}
+      }
+    ],
+    "actions": [],
+    "revision": { "id": "control-flow-status", "version": 5 },
+    "updated_at_ms": 1772067720000,
+    "metadata": {
+      "profile": {
+        "id": "control-flow",
+        "variant": "status",
+        "snapshot": {
+          "compact": "round=2/3 · state=review_pending",
+          "multiline": "policy: review-gated\nround: 2/3\nstate: review_pending\nnext: run review_2"
+        }
+      }
+    }
+  }
+}
+```
 
-HUD usage is not optional for active control-flow execution.
+### Canonical escalation prompt (`ui:control-flow:escalation`)
+
+```json
+{
+  "action": "set",
+  "doc": {
+    "v": 1,
+    "ui_id": "ui:control-flow:escalation",
+    "title": "Review rounds exhausted",
+    "summary": "Need user decision after max failed review rounds.",
+    "components": [
+      {
+        "kind": "text",
+        "id": "question",
+        "text": "Max review rounds were reached. Should execution open another attempt or stop for manual intervention?",
+        "metadata": {}
+      }
+    ],
+    "actions": [
+      {
+        "id": "open-extra-round",
+        "label": "Open one extra round",
+        "kind": "primary",
+        "payload": {},
+        "metadata": { "command_text": "/answer open-extra-round" }
+      },
+      {
+        "id": "stop-and-handoff",
+        "label": "Stop and hand off",
+        "kind": "secondary",
+        "payload": {},
+        "metadata": { "command_text": "/answer stop-and-handoff" }
+      }
+    ],
+    "revision": { "id": "control-flow-escalation", "version": 1 },
+    "updated_at_ms": 1772067730000,
+    "metadata": {
+      "profile": {
+        "id": "control-flow-escalation",
+        "variant": "interactive"
+      }
+    }
+  }
+}
+```
 
-- If subagents HUD is already active, publish control-flow state in that HUD doc
-  (for example policy mode, round counters, escalation state).
-- If running control-flow standalone, own a dedicated `hud_id:"control-flow"` doc.
-- Update HUD state each bounded pass before reporting ORCH_PASS output.
+### Teardown / handoff
 
-- Follow the HUD ownership and teardown protocol from the `hud` skill when completing or handing off.
+```json
+{"action":"remove","ui_id":"ui:control-flow:escalation"}
+{"action":"remove","ui_id":"ui:control-flow"}
+```
 
 ## Evaluation scenarios