@femtomc/mu-agent 26.2.100 → 26.2.102

package/prompts/skills/hud/SKILL.md

@@ -0,0 +1,171 @@
+---
+name: hud
+description: "Defines HUD usage for `mu_hud` and `/mu hud`, including doc schema patterns, deterministic update rules, and rendering-safe conventions."
+---
+
+# hud
+
+Use this skill whenever you need to publish, update, or inspect HUD state.
+
+This skill is the canonical HUD reference for:
+
+- `mu_hud` tool calls (structured HUD state)
+- `/mu hud ...` command usage (inspection/control)
+- `HudDoc` conventions that render well in TUI/Slack/Telegram
+
+## Contents
+
+- [Core contract](#core-contract)
+- [HudDoc shape](#huddoc-shape)
+- [Recommended turn loop](#recommended-turn-loop)
+- [Planning and subagents profiles](#planning-and-subagents-profiles)
+- [Determinism and rendering limits](#determinism-and-rendering-limits)
+- [Evaluation scenarios](#evaluation-scenarios)
+
+## Core contract
+
+### Tool (`mu_hud`)
+
+Actions:
+
+- `status`, `snapshot`
+- `on`, `off`, `toggle`
+- `set`, `update`, `replace`, `remove`, `clear`
+
+Key params:
+
+- `doc` (for `set`/`update`)
+- `docs` (for `replace`)
+- `hud_id` (for `remove`)
+- `snapshot_format` (`compact` or `multiline`)
+
+Notes:
+
+- `set` and `update` are both upsert-style single-doc writes.
+- `replace` is whole-inventory replacement.
+- Tool results include normalized `hud_docs` for downstream transport/rendering.
+- Advisory preset-shape warnings are surfaced in tool `details.preset_warnings` when `metadata.style_preset` and doc shape diverge (non-blocking).
+
+### Command (`/mu hud ...`)
+
+Supported subcommands:
+
+- `/mu hud status`
+- `/mu hud snapshot [compact|multiline]`
+- `/mu hud on|off|toggle`
+- `/mu hud clear`
+- `/mu hud remove <hud-id>`
+
+Use the tool (`mu_hud`) for structured doc writes.
+
+## HudDoc shape
+
+HUD docs are validated against `HudDoc` (`@femtomc/mu-core`).
+
+Minimum practical fields:
+
+- `v: 1`
+- `hud_id: <non-empty>`
+- `title: <non-empty>`
+- `snapshot_compact: <non-empty>`
+- `updated_at_ms: <int>`
+
+Common optional fields:
+
+- `scope` (for root/session/issue scoping)
+- `title_style` / `snapshot_style` (`{weight?:"normal|strong", italic?:boolean, code?:boolean}`)
+- `chips` (`[{key,label,tone?,style?}]`)
+- `sections`:
+  - `kv` (key/value; supports `title_style` + item `value_style`)
+  - `checklist` (checkbox-style progress; supports `title_style` + item `style`)
+  - `activity` (recent lines; supports `title_style`)
+  - `text` (free text; supports `title_style` + `style`)
+- `actions` (`[{id,label,command_text,kind?,style?}]`)
+- `metadata` (machine-readable extras; optional `style_preset` convention: `planning|subagents`)
+
+Example checklist doc:
+
+```json
+{
+  "action": "set",
+  "doc": {
+    "v": 1,
+    "hud_id": "planning",
+    "title": "Planning HUD",
+    "scope": "mu-root-123",
+    "chips": [
+      { "key": "phase", "label": "phase:drafting", "tone": "accent", "style": { "weight": "strong" } },
+      { "key": "steps", "label": "steps:2/5", "tone": "dim" }
+    ],
+    "sections": [
+      {
+        "kind": "checklist",
+        "title": "Checklist",
+        "items": [
+          { "id": "1", "label": "Investigate", "done": true },
+          { "id": "2", "label": "Draft DAG", "done": true },
+          { "id": "3", "label": "Review", "done": false }
+        ]
+      }
+    ],
+    "actions": [
+      { "id": "snapshot", "label": "Snapshot", "command_text": "/mu hud snapshot", "kind": "secondary", "style": { "italic": true } }
+    ],
+    "snapshot_compact": "HUD(plan) · phase=drafting · steps=2/5",
+    "updated_at_ms": 1771853115000,
+    "metadata": { "style_preset": "planning", "phase": "drafting" }
+  }
+}
+```
+
+## Recommended turn loop
+
+1. Ensure HUD is on:
+
+```json
+{"action":"on"}
+```
+
+2. Upsert exactly the docs you own (`set`/`update`).
+3. Emit compact snapshot for user-facing status:
+
+```json
+{"action":"snapshot","snapshot_format":"compact"}
+```
+
+4. Keep response text and HUD state aligned (no contradictions).
+
+## Planning and subagents profiles
+
+Use profile-specific `hud_id` values:
+
+- planning profile: `hud_id: "planning"`
+- subagents profile: `hud_id: "subagents"`
+
+Treat these as conventions layered on top of this generic contract.
+
+## Determinism and rendering limits
+
+- Keep one canonical doc per `hud_id`.
+- Keep `updated_at_ms` monotonic for each `hud_id`.
+- Prefer a small doc set (usually 1–3 docs total) for channel readability.
+- Keep command actions concise; long commands may degrade to text-only fallbacks on some channels.
+- Assume channel renderers cap docs/actions/lines; put critical state in `snapshot_compact` and first section items.
+
+If behavior is unclear, inspect implementation/tests before guessing:
+
+- `packages/core/src/hud.ts`
+- `packages/agent/src/extensions/hud.ts`
+- `packages/server/src/control_plane.ts`
+- `packages/agent/test/hud_tool.test.ts`
+
+## Evaluation scenarios
+
+1. **Planning review turn**
+   - Expected: `planning` doc updates phase/checklist/waiting state, then emits compact snapshot.
+
+2. **Subagents orchestration pass**
+   - Expected: `subagents` doc updates queue/activity/chips after each bounded pass.
+
+3. **HUD reset handoff**
+   - Expected: after phase completion, HUD is cleared or removed by `hud_id`, and status reflects no stale docs.

package/prompts/skills/mu/SKILL.md

@@ -98,7 +98,7 @@ mu session <session-id>
 mu turn --session-kind operator --session-id <session-id> --body "<follow-up>"
 ```
 
-In attached terminal operator chat, `/mu` helpers are available (`/mu events`, `/mu plan`, `/mu subagents`, `/mu help`).
+In attached terminal operator chat, `/mu` helpers are available (`/mu events`, `/mu hud ...`, `/mu help`).
 
 ## Durable automation handoff
 

package/prompts/skills/planning/SKILL.md

@@ -10,6 +10,7 @@ Use this skill when the user asks for planning, decomposition, or a staged execu
 ## Contents
 
 - [Planning HUD is required](#planning-hud-is-required)
+- [HUD skill dependency](#hud-skill-dependency)
 - [Shared protocol dependency](#shared-protocol-dependency)
 - [Core contract](#core-contract)
 - [Suggested workflow](#suggested-workflow)
@@ -28,10 +29,17 @@ For this skill, the planning HUD is the primary status/communication surface.
 
 Default per-turn HUD loop:
 
-1. Apply an atomic `update` with current `phase`, `waiting_on_user`, `next_action`, `blocker`, and `confidence`.
-2. Synchronize checklist items and `root_issue_id` with the issue DAG.
+1. Emit a fresh `planning` HUD doc (`mu_hud` action `set` or `update`) with current `phase`, `waiting_on_user`, `next_action`, `blocker`, and `confidence` in sections/metadata.
+2. Keep checklist progress and root issue linkage synchronized with the live issue DAG.
 3. Emit `snapshot` (`compact` or `multiline`) and reflect it in your response.
 
+## HUD skill dependency
+
+Before emitting or mutating planning HUD state, load **`hud`** and follow its canonical contract.
+
+- Treat `hud` as source-of-truth for generic `mu_hud` actions, `HudDoc` shape, and rendering constraints.
+- This planning skill defines planning-specific conventions only (for example `hud_id: "planning"`, planning phases, checklist semantics).
+
 ## Shared protocol dependency
 
 This skill plans DAGs for execution by `subagents`, so planning must follow the
@@ -58,6 +66,7 @@ Do not invent alternate protocol names or tag schemas.
    - Add clear titles, scope, acceptance criteria, and protocol tags.
 
 3. **Drive communication through the planning HUD**
+   - Load `hud` and use its canonical `mu_hud`/`HudDoc` contract.
    - Treat HUD state as the canonical short status line for planning.
    - Keep `phase`, `waiting_on_user`, `next_action`, `blocker`, and `confidence` current.
    - Ensure HUD state and your natural-language response never contradict each other.
@@ -72,6 +81,10 @@ Do not invent alternate protocol names or tag schemas.
    - Update issues/dependencies and re-present deltas.
    - Do not begin broad execution until the user signals satisfaction.
 
+6. **After user approval, ask user about next steps**
+   - On user acceptance of the plan, turn the planning HUD off.
+   - Read the `subagents` skill and offer to supervise subagents to execute the plan.
+
 ## Suggested workflow
 
 ### A) Investigation pass
@@ -86,46 +99,37 @@ mu memory search --query "<topic>" --limit 30
 Bootstrap HUD immediately (interactive operator session):
 
 ```text
-/mu plan on
-/mu plan phase investigating
-/mu plan waiting off
-/mu plan confidence medium
-/mu plan next "Investigate constraints and gather evidence"
-/mu plan snapshot
+/mu hud on
+/mu hud status
+/mu hud snapshot
 ```
 
 Tool contract (preferred when tools are available):
 
-- Tool: `mu_planning_hud`
-- Actions:
-  - state: `status`, `snapshot`, `on`, `off`, `toggle`, `reset`, `phase`, `root`
-  - checklist: `check`, `uncheck`, `toggle_step`, `set_steps`, `add_step`, `remove_step`, `set_step_label`
-  - communication: `set_waiting`, `set_next`, `set_blocker`, `set_confidence`
-  - atomic: `update`
-- Key parameters:
-  - `phase`: `investigating|drafting|reviewing|waiting_user|blocked|executing|approved|done`
-  - `root_issue_id`: issue ID or `clear`
-  - `waiting_on_user`: boolean
-  - `next_action`, `blocker`: string or `clear`
-  - `confidence`: `low|medium|high`
-  - `steps`: string[]
-  - `step_updates`: array of `{index, done?, label?}`
+- Canonical contract: see skill `hud`
+- Tool: `mu_hud`
+- Actions: `status`, `snapshot`, `on`, `off`, `toggle`, `set`, `update`, `replace`, `remove`, `clear`
+- Planning convention: maintain a HUD doc with `hud_id: "planning"`
+- Suggested planning doc structure:
+  - `title`: `Planning HUD`
+  - chips: `phase:<...>`, `steps:<done>/<total>`, `waiting:<yes|no>`, `conf:<low|medium|high>`
+  - sections:
+    - `kv` status block (`phase`, `root`, `waiting_on_user`, `confidence`, `next_action`, `blocker`)
+    - `checklist` block for plan milestones
+  - actions: include useful follow-ups (for example, `snapshot`)
+  - metadata: include `style_preset:"planning"` for consistent renderer emphasis without repeating style hints
 
 Example tool calls:
-- Atomic status update for an investigation turn:
-  - `{"action":"update","phase":"investigating","waiting_on_user":false,"next_action":"Draft root issue and child DAG","blocker":"clear","confidence":"medium"}`
-- Atomic handoff when waiting for approval:
-  - `{"action":"update","phase":"waiting_user","waiting_on_user":true,"next_action":"Confirm scope change","blocker":"Need approval","confidence":"low"}`
-- Clear communication fields after user reply:
-  - `{"action":"update","waiting_on_user":false,"blocker":"clear","next_action":"Incorporate feedback and re-draft DAG"}`
-- Customize checklist:
-  - `{"action":"set_steps","steps":["Investigate","Draft DAG","Review with user","Finalize"]}`
+- Turn HUD on:
+  - `{"action":"on"}`
+- Set/replace planning doc after investigation pass:
+  - `{"action":"set","doc":{"v":1,"hud_id":"planning","title":"Planning HUD","scope":"mu-root-123","chips":[{"key":"phase","label":"phase:investigating","tone":"dim"},{"key":"steps","label":"steps:1/4","tone":"accent"},{"key":"waiting","label":"waiting:no","tone":"dim"},{"key":"confidence","label":"conf:medium","tone":"accent"}],"sections":[{"kind":"kv","title":"Status","items":[{"key":"phase","label":"phase","value":"investigating"},{"key":"root","label":"root","value":"mu-root-123"},{"key":"waiting","label":"waiting_on_user","value":"no"},{"key":"confidence","label":"confidence","value":"medium"},{"key":"next","label":"next_action","value":"Draft root DAG"},{"key":"blocker","label":"blocker","value":"(none)"}]},{"kind":"checklist","title":"Checklist","items":[{"id":"1","label":"Investigate relevant code/docs/state","done":true},{"id":"2","label":"Create root + child issue DAG","done":false},{"id":"3","label":"Present plan + tradeoffs","done":false},{"id":"4","label":"Refine until approved","done":false}]}],"actions":[{"id":"snapshot","label":"Snapshot","command_text":"/mu hud snapshot","kind":"secondary"}],"snapshot_compact":"HUD(plan) · phase=investigating · steps=1/4 · waiting=no · conf=medium","updated_at_ms":1771853115000,"metadata":{"style_preset":"planning","phase":"investigating","waiting_on_user":false,"confidence":"medium"}}}`
 - Human-facing status line:
   - `{"action":"snapshot","snapshot_format":"compact"}`
 
 If HUD behavior is unclear, inspect implementation/tests before guessing:
-- `packages/agent/src/extensions/planning-ui.ts`
-- `packages/agent/test/planning_ui_tool.test.ts`
+- `packages/agent/src/extensions/hud.ts`
+- `packages/agent/test/hud_tool.test.ts`
 
 Also inspect repo files directly (read/bash) for implementation constraints.
 
@@ -186,23 +190,17 @@ mu issues validate "$root_id"
 
 Required HUD updates during the loop:
 
-```text
-/mu plan root <root-id>
-/mu plan phase drafting
-/mu plan check 1
-/mu plan phase waiting-user
-/mu plan waiting on
-/mu plan next "Need your approval on tradeoff A/B"
-/mu plan snapshot
-```
+- Re-emit the `planning` HUD doc with current `phase`, checklist progress, `waiting_on_user`, `next_action`, and `blocker` after each meaningful planning step.
+- Use `{"action":"snapshot","snapshot_format":"compact"}` for concise user-facing HUD lines.
+- Keep `updated_at_ms` monotonic across updates so latest doc wins deterministically.
 
 ## Effective HUD usage heuristics
 
-- Prefer `update` for multi-field changes to avoid inconsistent intermediate state.
-- Reserve `waiting_user` for explicit user input/decision waits; use `blocked` for non-user blockers.
+- Keep one canonical planning doc (`hud_id: "planning"`) and refresh it whenever planning state changes.
+- Keep `updated_at_ms` monotonic so deterministic dedupe/ordering always keeps the latest planning state.
+- Use explicit, concise status fields (`phase`, `waiting_on_user`, `next_action`, `blocker`, `confidence`) in sections/metadata.
 - Keep `next_action` as one concrete action, not a paragraph.
-- Adjust `confidence` as evidence quality changes (`low` when assumptions are unresolved).
-- Customize checklist steps once scope is understood; check them off as milestones complete.
+- Customize checklist steps once scope is understood; mark them complete as milestones land.
 
 ## Evaluation scenarios
 

package/prompts/skills/subagents/SKILL.md

@@ -9,6 +9,7 @@ description: "Orchestrates issue-driven subagent execution with heartbeat superv
 
 - [Purpose (what this skill is for)](#purpose-what-this-skill-is-for)
 - [Shared protocol dependency](#shared-protocol-dependency)
+- [HUD skill dependency](#hud-skill-dependency)
 - [When to use](#when-to-use)
 - [Success condition](#success-condition)
 - [Dispatch modes](#dispatch-modes)
@@ -45,6 +46,13 @@ Before orchestration begins, load that skill and enforce:
 
 Do not run subagent orchestration against alternate protocol tags.
 
+## HUD skill dependency
+
+Before emitting or mutating subagent HUD state, load **`hud`** and follow its canonical contract.
+
+- Treat `hud` as source-of-truth for generic `mu_hud` actions, `HudDoc` shape, and rendering constraints.
+- This subagents skill defines orchestration-specific conventions only (for example `hud_id: "subagents"`, queue/activity semantics).
+
 ## When to use
 
 - Work is represented as issue-scoped deliverables with explicit outcomes.
@@ -98,7 +106,10 @@ mu forum read issue:<root-id> --limit 20 --pretty
 2. Choose exactly one action/primitive from `hierarchical-work-protocol`.
 3. Apply it.
 4. Verify (`get`, `children`, `ready`, `validate`).
-5. Post concise progress to forum.
+5. Post a human-facing `ORCH_PASS` update to forum:
+   - start with a short title that captures status in plain language
+   - follow with one concise paragraph covering: project objective context, milestone moved this pass, impact, overall progress, and next high-level step
+   - include queue/worker/drift internals only when diagnosing blocker/anomaly.
 6. Exit tick.
 
 Stop automation when `mu issues validate <root-id>` returns final.
@@ -114,7 +125,7 @@ For claimed issue `<issue-id>` under `<root-id>`:
    - directly solvable -> `complete`
 3. Apply primitive.
 4. Verify state.
-5. Post concise progress to `issue:<issue-id>`.
+5. Post progress to `issue:<issue-id>` focused on deliverable status, capability impact, and next step.
 
 Repeat bounded passes until issue closes.
 
@@ -138,7 +149,17 @@ mu heartbeats create \
   --title "hierarchical-work-v1 <root-id>" \
   --reason hierarchical_work_protocol_v1 \
   --every-ms 15000 \
-  --prompt "Use skills subagents and hierarchical-work-protocol for root <root-id>. Run exactly one bounded orchestration pass: claim/work one ready proto:hierarchical-work-v1 issue (or perform one orchestration action), verify state, and report status. Stop when 'mu issues validate <root-id>' is final."
+  --prompt "Use skills subagents, hud, and hierarchical-work-protocol for root <root-id>. Run exactly one bounded orchestration pass: inspect the proto:hierarchical-work-v1 queue, perform exactly one corrective orchestration action (including in_progress-without-worker drift recovery) or claim/work-start one ready issue, then verify state. Report human-facing progress as a titled status note plus one concise paragraph that explains project context, milestone moved, impact, overall progress, and next high-level step; avoid low-level orchestration internals unless diagnosing a blocker/anomaly. Post a matching ORCH_PASS update to issue:<root-id>. Stop when 'mu issues validate <root-id>' is final."
+```
+
+Reusable status-voice add-on for heartbeat prompts (copy/paste):
+
+```text
+Write each ORCH_PASS as a human status note, not operator telemetry.
+Use a short plain-language title + one concise paragraph covering:
+project objective, milestone moved this pass, impact/precondition,
+overall progress, and next high-level step.
+Keep queue/worker/session internals out unless diagnosing a blocker.
 ```
 
 ### B) tmux fan-out (parallel workers)
@@ -148,7 +169,7 @@ run_id="$(date +%Y%m%d-%H%M%S)"
 for issue_id in $(mu issues ready --root <root-id> --tag proto:hierarchical-work-v1 --json | jq -r '.[].id' | head -n 3); do
   session="mu-sub-${run_id}-${issue_id}"
   tmux new-session -d -s "$session" \
-    "cd '$PWD' && mu exec 'Use skills subagents and hierarchical-work-protocol. Work issue ${issue_id} using hierarchical-work.protocol/v1. Claim first, then run one full control loop.' ; rc=\$?; echo __MU_DONE__:\$rc"
+    "cd '$PWD' && mu exec 'Use skills subagents, hud, and hierarchical-work-protocol. Work issue ${issue_id} using hierarchical-work.protocol/v1. Claim first, then run one full control loop.' ; rc=\$?; echo __MU_DONE__:\$rc"
 done
 ```
 
@@ -157,26 +178,29 @@ done
 Use HUD for user visibility. Truth still lives in issues/forum.
 
 ```text
-/mu subagents on
-/mu subagents prefix mu-sub-
-/mu subagents root <root-id>
-/mu subagents tag proto:hierarchical-work-v1
-/mu subagents mode operator
-/mu subagents refresh
-/mu subagents snapshot
+/mu hud on
+/mu hud status
+/mu hud snapshot
 ```
 
-Tool: `mu_subagents_hud`
+Tool: `mu_hud`
 
-- Actions: `status`, `snapshot`, `on`, `off`, `toggle`, `refresh`,
-  `set_prefix`, `set_root`, `set_tag`, `set_mode`, `set_refresh_interval`,
-  `set_stale_after`, `set_spawn_paused`, `update`, `spawn`
+- Canonical contract: see skill `hud`
+- Actions: `status`, `snapshot`, `on`, `off`, `toggle`, `set`, `update`, `replace`, `remove`, `clear`
+- Subagents convention: maintain a HUD doc with `hud_id: "subagents"`
+- Suggested subagents doc structure:
+  - chips: health, mode, paused
+  - sections: queue counts + recent activity lines
+  - actions: refresh/spawn command hooks (if desired)
+  - metadata: include `style_preset:"subagents"` for consistent renderer emphasis
+- Example update:
+  - `{"action":"set","doc":{"v":1,"hud_id":"subagents","title":"Subagents HUD","scope":"mu-root-123","chips":[{"key":"health","label":"healthy","tone":"success"},{"key":"mode","label":"mode:operator","tone":"dim"},{"key":"paused","label":"paused:no","tone":"dim"}],"sections":[{"kind":"kv","title":"Queue","items":[{"key":"ready","label":"Ready","value":"3"},{"key":"active","label":"Active","value":"2"},{"key":"sessions","label":"Sessions","value":"2"}]},{"kind":"activity","title":"Activity","lines":["Spawned worker for mu-abc123","Posted ORCH_PASS update"]}],"actions":[{"id":"refresh","label":"Refresh","command_text":"/mu hud snapshot","kind":"secondary"}],"snapshot_compact":"HUD(subagents) · healthy · mode=operator · ready=3 · active=2","updated_at_ms":1771853115000,"metadata":{"style_preset":"subagents","spawn_mode":"operator","spawn_paused":false}}}`
 
 ## Evaluation scenarios
 
 1. **Heartbeat bounded-orchestration tick**
    - Setup: root issue with multiple ready leaves tagged `proto:hierarchical-work-v1`.
-   - Expected: one heartbeat tick performs exactly one bounded orchestration action, verifies state, posts concise progress, and exits.
+   - Expected: one heartbeat tick performs exactly one bounded orchestration action, verifies state, posts a high-level titled narrative status update, and exits.
 
 2. **tmux fan-out on ready leaves**
    - Setup: at least three independent ready issues under one root.

package/dist/extensions/hud-mode.d.ts

@@ -1,8 +0,0 @@
-import type { ExtensionContext } from "@mariozechner/pi-coding-agent";
-export type MuHudMode = "planning" | "subagents";
-export declare function getActiveHudMode(): MuHudMode | null;
-export declare function resetHudMode(): void;
-export declare function setActiveHudMode(mode: MuHudMode | null): void;
-export declare function clearHudMode(mode: MuHudMode): void;
-export declare function syncHudModeStatus(ctx: ExtensionContext): void;
-//# sourceMappingURL=hud-mode.d.ts.map

package/dist/extensions/hud-mode.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"hud-mode.d.ts","sourceRoot":"","sources":["../../src/extensions/hud-mode.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,gBAAgB,EAAE,MAAM,+BAA+B,CAAC;AAEtE,MAAM,MAAM,SAAS,GAAG,UAAU,GAAG,WAAW,CAAC;AAIjD,wBAAgB,gBAAgB,IAAI,SAAS,GAAG,IAAI,CAEnD;AAED,wBAAgB,YAAY,IAAI,IAAI,CAEnC;AAED,wBAAgB,gBAAgB,CAAC,IAAI,EAAE,SAAS,GAAG,IAAI,GAAG,IAAI,CAE7D;AAED,wBAAgB,YAAY,CAAC,IAAI,EAAE,SAAS,GAAG,IAAI,CAIlD;AAED,wBAAgB,iBAAiB,CAAC,GAAG,EAAE,gBAAgB,GAAG,IAAI,CAK7D"}

package/dist/extensions/hud-mode.js

@@ -1,21 +0,0 @@
-let activeHudMode = null;
-export function getActiveHudMode() {
-    return activeHudMode;
-}
-export function resetHudMode() {
-    activeHudMode = null;
-}
-export function setActiveHudMode(mode) {
-    activeHudMode = mode;
-}
-export function clearHudMode(mode) {
-    if (activeHudMode === mode) {
-        activeHudMode = null;
-    }
-}
-export function syncHudModeStatus(ctx) {
-    if (!ctx.hasUI) {
-        return;
-    }
-    ctx.ui.setStatus("mu-hud-mode", activeHudMode ? `hud:${activeHudMode}` : undefined);
-}

package/dist/extensions/planning-ui.d.ts

@@ -1,4 +0,0 @@
-import type { ExtensionAPI } from "@mariozechner/pi-coding-agent";
-export declare function planningUiExtension(pi: ExtensionAPI): void;
-export default planningUiExtension;
-//# sourceMappingURL=planning-ui.d.ts.map

package/dist/extensions/planning-ui.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"planning-ui.d.ts","sourceRoot":"","sources":["../../src/extensions/planning-ui.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,YAAY,EAAoB,MAAM,+BAA+B,CAAC;AA0gBpF,wBAAgB,mBAAmB,CAAC,EAAE,EAAE,YAAY,QAuenD;AAED,eAAe,mBAAmB,CAAC"}