dsh-embedded-workbench 0.8.12 → 0.9.1

package/package.json

@@ -1,7 +1,7 @@
 {
     "name": "dsh-embedded-workbench",
-    "version": "0.8.12",
-    "description": "Embedded C/C++ firmware development toolbox — 4 agents, 8 skills covering FreeRTOS, ISR, NVM storage, Keil MDK, ARMCLANG, HardFault, state machines, architecture, LVGL patterns, and claim fact-checking. Ships a native DeepSeek Harness (dsh) bundle that injects the session-start gate into the first model step.",
+    "version": "0.9.1",
+    "description": "Embedded C/C++ firmware development toolbox — 4 agents, 8 skills covering FreeRTOS, ISR, NVM storage, Keil MDK, ARMCLANG, HardFault, state machines, architecture, LVGL patterns, and claim fact-checking. Ships a native DeepSeek Harness (dsh) bundle that folds a short gate — the Plan Verification Gate plus a context-budget rule — into the first model step.",
     "type": "module",
     "main": "lib/index.js",
     "types": "lib/types/index.d.ts",
@@ -11,6 +11,7 @@
             "default": "./lib/index.js"
         },
         "./cordis.patch.yml": "./cordis.patch.yml",
+        "./client": "./lib/client.js",
         "./package.json": "./package.json"
     },
     "files": [
@@ -31,48 +32,63 @@
         "bundle": {
             "patch": "./cordis.patch.yml"
         },
+        "client": {
+            "platform": "web",
+            "inject": [
+                "@deepseek-ai/dsh-client-locale",
+                "@deepseek-ai/dsh-client-ui-settings",
+                "@deepseek-ai/dsh-client-ui-plugin-manager"
+            ]
+        },
         "compatibility": {
-            "dsh": "^0.1.0-rc.7 || ^0.1.1-rc.1 || ^0.1.2-alpha.2 || ^0.1.2-alpha.3 || ^0.1.2-alpha.4 || ^0.1.2-alpha.5 || ^0.1.2-rc.1 || ^0.1.3-alpha.1 || ^0.1.3-alpha.2 || ^0.1.5-alpha.1 || ^0.1.5-rc.1 || ^0.1.5-alpha.2 || ^0.1.5-rc.2 || ^0.1.6-alpha.1 || ^0.1.6-alpha.2 || ^0.1.7-alpha.1",
+            "dsh": "^0.1.0-rc.7 || ^0.1.1-rc.1 || ^0.1.2-alpha.2 || ^0.1.2-alpha.3 || ^0.1.2-alpha.4 || ^0.1.2-alpha.5 || ^0.1.2-rc.1 || ^0.1.3-alpha.1 || ^0.1.3-alpha.2 || ^0.1.5-alpha.1 || ^0.1.5-rc.1 || ^0.1.5-alpha.2 || ^0.1.5-rc.2 || ^0.1.5-rc.3 || ^0.1.6-alpha.1 || ^0.1.6-alpha.2 || ^0.1.7-alpha.1 || ^0.1.7-alpha.2 || ^0.1.7-rc.1 || ^0.1.7-rc.2 || ^0.2.0-rc.1",
             "dshReleases": {
-                "0.1.0-rc.7": "compatible",
-                "0.1.0-rc.8": "compatible",
-                "0.1.1-rc.1": "compatible",
-                "0.1.1-rc.2": "compatible",
-                "0.1.2-alpha.2": "compatible",
-                "0.1.2-alpha.3": "compatible",
-                "0.1.2-alpha.4": "compatible",
-                "0.1.2-alpha.5": "compatible",
-                "0.1.2-rc.1": "compatible",
-                "0.1.3-alpha.1": "compatible",
-                "0.1.3-alpha.2": "compatible",
-                "0.1.5-alpha.1": "compatible",
-                "0.1.5-alpha.2": "compatible",
-                "0.1.5-rc.1": "compatible",
-                "0.1.5-rc.2": "compatible",
-                "0.1.6-alpha.1": "compatible",
-                "0.1.6-alpha.2": "compatible",
-                "0.1.7-alpha.1": "compatible"
+              "0.1.0-rc.7": "compatible",
+              "0.1.0-rc.8": "compatible",
+              "0.1.1-rc.1": "compatible",
+              "0.1.1-rc.2": "compatible",
+              "0.1.2-alpha.2": "compatible",
+              "0.1.2-alpha.3": "compatible",
+              "0.1.2-alpha.4": "compatible",
+              "0.1.2-alpha.5": "compatible",
+              "0.1.2-rc.1": "compatible",
+              "0.1.3-alpha.1": "compatible",
+              "0.1.3-alpha.2": "compatible",
+              "0.1.5-alpha.1": "compatible",
+              "0.1.5-alpha.2": "compatible",
+              "0.1.5-rc.1": "compatible",
+              "0.1.5-rc.2": "compatible",
+              "0.1.5-rc.3": "compatible",
+              "0.1.6-alpha.1": "compatible",
+              "0.1.6-alpha.2": "compatible",
+              "0.1.7-alpha.1": "compatible",
+              "0.1.7-alpha.2": "compatible",
+              "0.1.7-rc.1": "compatible",
+              "0.1.7-rc.2": "compatible",
+              "0.2.0-rc.1": "compatible",
+              "0.2.0-rc.2": "compatible"
             },
             "profiles": [
-                "headless"
+                "headless",
+                "web"
             ]
         }
     },
     "scripts": {
-        "build": "tsc -p tsconfig.json",
+        "build": "tsc -p tsconfig.json && node scripts/build-client.mjs",
         "typecheck": "tsc -p tsconfig.json --noEmit",
         "bump": "node scripts/bump-version.mjs"
     },
     "peerDependencies": {
-        "@deepseek-ai/cordis": "^4.0.2",
-        "@deepseek-ai/dsh-agent": "^0.1.0-rc.6",
-        "@deepseek-ai/dsh-llm": "^0.1.0-rc.6",
-        "@deepseek-ai/dsh-session": "^0.1.0-rc.6",
-        "@deepseek-ai/dsh-skill-filesystem": "^0.1.0-rc.8",
-        "@deepseek-ai/schemastery": "^3.18.2"
+        "@deepseek-ai/cordis": "^4.0.4",
+        "@deepseek-ai/dsh-agent": "^0.1.0-rc.6 || ^0.2.0-rc.1",
+        "@deepseek-ai/dsh-llm": "^0.1.0-rc.6 || ^0.2.0-rc.1",
+        "@deepseek-ai/dsh-session": "^0.1.0-rc.6 || ^0.2.0-rc.1",
+        "@deepseek-ai/dsh-skill-filesystem": "^0.1.0-rc.8 || ^0.2.0-rc.1",
+        "@deepseek-ai/schemastery": "^3.18.4"
     },
     "devDependencies": {
-        "@deepseek-ai/cordis": "^4.0.2",
+        "@deepseek-ai/cordis": "^4.0.4",
         "@deepseek-ai/dsh-agent": "^0.1.0-rc.6",
         "@deepseek-ai/dsh-cordis-host-runner": "^0.1.0-rc.8",
         "@deepseek-ai/dsh-home-paths": "^0.1.0-rc.8",
@@ -82,8 +98,8 @@
         "@deepseek-ai/dsh-skill": "^0.1.0-rc.8",
         "@deepseek-ai/dsh-skill-filesystem": "^0.1.0-rc.8",
         "@deepseek-ai/dsh-timeout": "^0.0.1-rc.1",
-        "@types/node": "^26.6.1",
-        "@deepseek-ai/schemastery": "^3.18.2",
+        "@deepseek-ai/schemastery": "^3.18.4",
+        "@types/node": "^26.6.2",
         "typescript": "^7.0.2"
     },
     "author": {
@@ -91,7 +107,10 @@
         "url": "https://github.com/AmethystLuna"
     },
     "license": "MIT",
-    "repository": "https://github.com/AmethystLuna/embedded-workbench",
+    "repository": {
+        "type": "git",
+        "url": "git+https://github.com/AmethystLuna/embedded-workbench.git"
+    },
     "keywords": [
         "embedded",
         "firmware",

package/skills/embedded-workbench/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: embedded-workbench
-description: "Use when starting any non-trivial coding task — loads multi-agent workflows, engineering policies, and principles for embedded C/C++ firmware development. NOT for trivial single-line fixes, formatting-only changes, or read-only queries."
+description: "Use when starting any non-trivial coding task — loads risk-proportional workflows, engineering policies, and principles for embedded C/C++ firmware development. NOT for trivial single-line fixes, formatting-only changes, or read-only queries."
 ---
 
 <SUBAGENT-STOP>
@@ -23,7 +23,7 @@ If a user's CLAUDE.md says "skip design review for hotfixes" and the workflow re
 
 ## Platform Adaptation
 
-This plugin's skills and agents use Claude Code tool names (`Read`, `Write`, `Edit`, `Bash`, `Skill()`). If you are NOT on Claude Code, load `references/platform-tool-mapping.md` for the tool name equivalents on your platform (Codex CLI, Cursor, Kimi CLI, OpenCode, ZCode, Copilot CLI).
+This plugin's skills and agents use Claude Code tool names (`Read`, `Write`, `Edit`, `Bash`, `Skill()`). If you are NOT on Claude Code, load `references/platform-tool-mapping.md` for the tool name equivalents on your platform (Codex CLI, Cursor, Kimi CLI, OpenCode, ZCode, Copilot CLI, DeepSeek Harness). On DeepSeek Harness (dsh) the names are lowercase (`read`/`write`/`edit`/`glob`/`grep`/`pwsh`), skills load through the `skill` tool, the plan gate is `exit_plan_mode`, parallel work uses `subagent`/`subagent_fork`, and the 4 custom agents below are not ported.
 
 ## Red Flags
 
@@ -34,8 +34,8 @@ If you catch yourself thinking any of these, STOP — you are rationalizing:
 | "This is just a quick fix, I don't need a plan" | Quick fixes are the most likely to break something else. A 3-line design check costs 30 seconds. |
 | "I already understand the architecture" | You're looking at one file. The blast radius may span 5 modules you haven't read. |
 | "The worker can figure out the details" | The worker has NO context from previous calls. A vague plan = the worker guessing. |
-| "I'll review it myself, no need for quality-coordinator" | Self-review catches ~60% of issues. A second pair catches the other 40%. |
-| "This change is too small for a Detailed Change Plan" | If it touches more than one function, it needs a plan. Even single-function changes benefit from explicit invariants. |
+| "I'll review it myself, no need for quality-coordinator" | Self-review is enough for a bounded, reversible edit. A second pass earns its cost when the blast radius is unclear or the change is hard to undo. |
+| "This change is too small for a Detailed Change Plan" | Bounded, reversible, single-site edits do not need the ceremony. Crossing a module boundary, a public interface, or a non-obvious failure mode does. Name the invariants either way. |
 | "I've explored enough, time to exit plan mode" | ExitPlanMode is the verification gate. Have you loaded `Skill("logicprobe")` or, if it is not installed, the built-in fallback `Skill("fact-check")`? Every plan — simple or complex — must pass this gate before exit. |
 | "This plan is too simple for logicprobe" | logicprobe auto-classifies depth (LIGHTWEIGHT/STANDARD/ESCALATED); the fallback fact-check verifies every claim regardless. You don't decide whether verification is needed. |
 | "I already read the code, I know the file paths and API names are correct" | Organic verification leaves no audit trail. Load `Skill("logicprobe")` or the fallback `Skill("fact-check")`, verify each claim, append the `## Plan Verification` block. |
@@ -46,65 +46,82 @@ If you catch yourself thinking any of these, STOP — you are rationalizing:
 
 - Build context before acting: identify domain → load relevant skills → read key sources → analyze → edit.
 - **Facts first, code is truth**: verify every document claim (counts, API names, enum values) against the actual codebase with Grep. Design on verified facts, not assumptions.
-- Use `Agent(subagent_type: "Explore")` for broad searches instead of chaining Grep/Glob.
+- For a broad search that would otherwise take many Grep/Glob rounds, a read-only `Explore` sub-agent keeps the noise out of this context — but two direct searches are cheaper than dispatching one.
 - Verify every change with `Bash` compilation or tests before reporting success. No verification = no claim of success.
 - Reference file locations with line numbers in all reports: `[path/to/file.c#L100-L110]`.
 - Write project memory to `<workspace>/.github/memory/`, update `MEMORY.md` index. Personal preferences only in `~/.claude/projects/.../memory/`.
 
 ---
 
-## Workflows
+## Proportionality
+
+Match the process to the risk in front of you, not to habit. Start on the lightest path that covers the risk, and escalate only when you actually cross a boundary.
+
+| Task shape | Path |
+| --- | --- |
+| Question, read-only investigation, or a bounded reversible edit (typo, constant, one call site) | Do it directly — no plan header, no sub-agent |
+| One module, known repro, local refactor | Lite |
+| Cross-module, public interface, shared-state ownership, new state machine, non-obvious failure/recovery mode | Full |
+| Platform layer, contracts, staged migration | Full + audit matrix |
+
+You have crossed into a heavier path when the change spans more than one module, alters a public interface or state ownership, hides a failure mode you cannot describe, or two attempts have not converged. Scaling a bounded edit up costs more than the edit.
 
-Sub-agents are **stateless** — each `Agent()` call is a fresh process. Plan-then-Implement uses two separate spawns: the first produces a Plan, the orchestrator approves it, the second implements. Only worth it when the Plan is specific enough for mechanical execution.
+## Context Budget
 
-### Lite Workflow — Single-file fix, small bug, local refactor
+Complexity decides **how much process**; the budget decides **whether to split the window**. Split it for discovery whose detail you will not cite again — a suite, a log sweep, docs, several independent areas. Keep it for phases that share context (plan → implement → test), or when the change is quick and latency matters.
 
-**When**: single file/module, known repro, no cross-module boundaries. Trivial changes (typo, constant) — fix directly.
+**You cannot see your budget**: most harnesses show a token count to the user's interface, not to you, so never guess one. Act on what you do see — a result truncated, pruned, or spilled to a file, or a compaction / checkpoint summary. When a large step shows no signal at all, **ask the user** what to spend context on rather than deciding silently; if nobody can answer (headless run), take the reversible option and say so.
 
-`execution-worker` → Plan → **suggest user run `design-reviewer` or `logicprobe` to verify Plan claims against codebase** → approve → `execution-worker` → implement + verify. Self-check. Uncertain → `quality-coordinator`.
+Delegation is not free: the sub-agent spends its own tokens and its summary still lands here. When it needs context you already built, inherit it (dsh `subagent_fork`; Codex `fork_turns`, default `all`; Claude Code fork mode; Kimi `/btw`) instead of rebuilding it in a prompt. Per-harness markers and tool names: `references/platform-tool-mapping.md`.
+
+Delegation is not free: the sub-agent spends its own tokens, its summary still lands in this context, and its window is sized by *its* model, not this one. If the returns would be verbose, ask before delegating. Prefer read-only delegation when the point is to discard detail. When the delegated work needs the context you have already built, inherit it (dsh `subagent_fork`; Codex `fork_turns`, which defaults to `all`; Claude Code forked subagent; Kimi `/btw`) rather than rebuilding it inside a prompt (dsh `subagent`, Claude Code fresh subagent).
+
+## Workflows
 
-Escalate to Multi-Agent when cross-module or two revisions don't converge.
+Sub-agents are **optional equipment, not mandatory stages** — dispatch one when it buys something concrete (a frozen plan, context isolation, an independent review pass), never as ceremony. Each `Agent()` call is stateless: it sees only what its prompt contains. Choose isolation when the detail can be discarded, and inheritance when the sub-agent needs the context you already built (see Context Budget above).
 
-### Multi-Agent Workflow — Multi-module tasks, full plan/review/closure cycle
+### Lite — one module, known repro
 
-**When**: cross-module, new interfaces, state ownership changes, needs design package.
+Plan the change, make it, verify it. Self-review is sufficient for a bounded, reversible edit.
 
-`architecture-steward` → design → `design-reviewer` → fact-check → per slice: `execution-worker` (Plan → approve → Implement) → `quality-coordinator` → closure (normal/failure/recovery paths).
+If the plan rests on claims about the codebase (API names, file paths, enum values, counts), verify those claims before implementing — inline for a small change, or with `logicprobe` / the built-in `fact-check` skill. Escalate to Full when the change turns out to cross a boundary, or when two revisions fail to converge.
 
-### Framework Workflow — Platform layer, contracts, staged migration
+### Full — cross-module, new interfaces, state-ownership changes
 
-**When**: framework incubation, runtime path mounting, contract/sentinel/audit definition, old/new coexistence.
+Design first (module boundaries, slice breakdown, recovery paths), then per slice: plan → approve → implement → verify → close. Add an independent review pass (`quality-coordinator`, or a `subagent` with a review prompt) when the change is hard to reverse or the blast radius is unclear; for a well-bounded slice, self-review plus verification evidence is enough.
 
-Same as Multi-Agent, plus: design package includes audit matrix + rollback triggers; each slice reports audit delta; quality-coordinator checks audit ledger consistency.
+### Framework — platform layer, contracts, staged migration
 
-### Sub-Agent Reference
+Full, plus an audit matrix and rollback triggers; each slice reports its audit delta.
 
-| Agent | Role |
-| ------- | ------ |
-| `architecture-steward` | Read-only planning: design packages, module boundaries, slice breakdown |
-| `design-reviewer` | Design doc fact-check: verifies claims against codebase before implementation |
-| `execution-worker` | Plan round → Detailed Change Plan. Implement round → edit + verify |
-| `quality-coordinator` | Implementation review: bugs, compliance, closure completeness |
+### Sub-Agents
+
+| Agent | Role | When it earns its cost |
+| ------- | ------ | ------ |
+| `architecture-steward` | Read-only planning: design packages, module boundaries, slice breakdown | A design spanning modules you have not read |
+| `design-reviewer` | Design doc fact-check: verifies claims against codebase before implementation | The plan rests on claims you have not verified |
+| `execution-worker` | Plan round → Detailed Change Plan. Implement round → edit + verify | You want the plan frozen before edits, or a noisy investigation kept out of this context |
+| `quality-coordinator` | Implementation review: bugs, compliance, closure completeness | The change is hard to reverse or the risk surface is wide |
+
+These are roles, not gates: the main model can play any of them directly when that is cheaper.
 
 ---
 
 ## Plan Mode Integration
 
-Claude Code's built-in `EnterPlanMode` / `ExitPlanMode` maps to the **Plan phase** of the Lite and Multi-Agent workflows. Plan mode is a read-only exploration + plan-writing phase — it does NOT exempt you from embedded-workbench verification gates.
+Claude Code's built-in `EnterPlanMode` / `ExitPlanMode` maps to the **plan phase** of the Lite and Full paths. Plan mode is a read-only exploration + plan-writing phase — it does NOT exempt you from embedded-workbench verification gates.
 
 ### Plan Verification Gate
 
-> **⚠️ logicprobe 已拆分为独立插件 / moved to a standalone plugin** (v0.6.0): the full verification skill (executable model checks, adversarial probing) now ships in its own plugin — <https://github.com/AmethystLuna/logicprobe>. Install it with `claude plugin install logicprobe@logicprobe` (or clone to `~/.claude/plugins/dev/logicprobe`). This plugin ships a built-in simplified fallback — `Skill("fact-check")` — for claim-by-claim verification when logicprobe is not installed; behavioral/model claims then degrade to manual confirmation.
+> **⚠️ logicprobe 已拆分为独立插件 / moved to a standalone plugin** (v0.6.0): the full verification skill (executable model checks, adversarial probing) now ships in its own plugin — <https://github.com/AmethystLuna/logicprobe> (install commands are in the README's "Other Plugins"). This plugin ships a built-in simplified fallback — `Skill("fact-check")` — for claim-by-claim verification when logicprobe is not installed; behavioral/model claims then degrade to manual confirmation.
 
 **Before calling `ExitPlanMode`**, exactly one of the following must happen:
 
-1. **Load `Skill("logicprobe")`** (standalone plugin — install separately if missing) — the skill classifies depth (LIGHTWEIGHT / STANDARD / ESCALATED), runs verification (including executable model checks), and appends a `## Plan Verification` summary block to the plan file.
-2. **Load `Skill("fact-check")`** (built-in fallback, only when logicprobe is not installed) — verifies every verifiable claim against the codebase with evidence, appends a `## Plan Verification` block marked `fact-check (fallback)`, and tells the user that state-machine/behavioral claims degrade to manual confirmation — recommend installing logicprobe.
-3. **Inform the user** — if you choose not to load either skill, you MUST say: *"此计划未经核查。是否需要我在审批前运行事实核查？（This plan has not been fact-verified. Would you like me to run verification before approving?）"* The user must have the option to request verification before approving.
-
-Silent skip is not an option. Either verify, or tell the user you didn't.
+1. **Load `Skill("logicprobe")`** (standalone plugin) — it classifies depth (LIGHTWEIGHT / STANDARD / ESCALATED), runs the verification including executable model checks, and appends a `## Plan Verification` summary block to the plan.
+2. **Load `Skill("fact-check")`** (built-in fallback, only when logicprobe is not installed) — verifies every verifiable claim against the codebase with evidence, appends a `## Plan Verification` block marked `fact-check (fallback)`, and tells the user that state-machine/behavioral claims degrade to manual confirmation.
+3. **Inform the user** — if you load neither, say: *"此计划未经核查。是否需要我在审批前运行事实核查？（This plan has not been fact-verified. Would you like me to run verification before approving?）"*
 
-Plan mode permits `Read`, `Glob`, `Grep`, and `Skill` calls — all verification executes within plan mode before exit.
+Silent skip is not an option. Plan mode permits `Read`, `Glob`, `Grep`, and `Skill` calls, so all of this executes before exit.
 
 ---
 
@@ -113,20 +130,18 @@ Plan mode permits `Read`, `Glob`, `Grep`, and `Skill` calls — all verification
 <HARD-GATE>
 ### Approval Gate
 
-- Implementation-bearing slices MUST produce a Detailed Change Plan before editing. No exceptions.
-- Plan must include: objective, entry point, intended files, change shape, invariants, risks, validation, stop conditions.
-- If execution reveals facts that change scope/boundaries/acceptance/verification surface, pause and require re-approval.
-- Do NOT skip the plan phase because "the change is obvious" or "I've done this before."
+- A slice that crosses a module boundary, changes a public interface or state ownership, or carries a non-obvious failure/recovery mode MUST have its plan written and approved before editing: objective, entry point, intended files, change shape, invariants, risks, validation, stop conditions.
+- Bounded, reversible, single-site edits proceed without the ceremony — state the intent, make the change, verify the result.
+- If execution reveals facts that change scope, boundaries, acceptance, or the verification surface, pause and re-approve.
 </HARD-GATE>
 
 <HARD-GATE>
 ### Closure Gate
 
-- Slice is NOT done until: implementation intent + verification evidence + residual risks are all explicit.
+- Work is not done until implementation intent, verification evidence, and residual risks are all explicit.
 - Skipped checks MUST record a concrete reason. "Looks good" is not a reason.
-- For fault/recovery scenarios, MUST cover normal, failure, and recovery paths.
-- Documentation and memory updates MUST be completed or explicitly skipped with reason.
-- Do NOT call a slice closed if verification, documentation impact, or audit deltas are unclear.
+- For fault/recovery scenarios, cover the normal, failure, and recovery paths.
+- Documentation and memory updates are completed, or explicitly skipped with a reason.
 </HARD-GATE>
 
 ### Escalation Triggers
@@ -140,7 +155,7 @@ Plan mode permits `Read`, `Glob`, `Grep`, and `Skill` calls — all verification
 Sub-agents are **stateless with no implicit context inheritance** — each spawn only gets what's in its prompt:
 
 - **Explicit prompt construction**: put design conclusions, approved Plans, review findings directly in the prompt. Do NOT assume the agent "remembers" previous conversations.
-- **Plan is the key handoff artifact**: between Design → Plan round → Implement round, the Detailed Change Plan and review verdicts are the only bridge. Vague Plans = the next agent guessing.
+- **Plan is the key handoff artifact**: when you do dispatch sub-agents, the Detailed Change Plan and review verdicts are the only bridge between Design → Plan round → Implement round. Vague Plans = the next agent guessing.
 - **Pass only what's needed**: Design phase doesn't need full source code. Implement phase doesn't need the full Audit Matrix.
 - **Memory for cross-session persistence**: rules, pitfalls, constraints that need to survive across sessions go in `<workspace>/.github/memory/`. In-session coordination stays in chat.
 - **Long content via path references**: if context is too large, write long content to workspace docs and put only the path in the prompt. Let the agent Read it.
@@ -179,7 +194,7 @@ When multiple skills could apply, use this order:
 "Add retry logic" → state-machine-design first, then c-cpp-dev for implementation.
 "Review this design" → logicprobe first (or the built-in fact-check fallback if logicprobe is not installed), then escalate findings to design-reviewer agent.
 
-**Cross-domain links**: load secondary skills ONLY when the primary skill's findings indicate they are needed. Don't pre-load. `hardfault-triage` ↔ `keil-mdk-build` (.map file bridge — load keil-mdk-build only if .map analysis is needed). `hardfault-triage` ↔ `debug-methodology` (root-cause analysis — load debug-methodology only if the fault cause is complex). `embedded-firmware-dev` ↔ `state-machine-design` (state transitions — load state-machine-design only if state logic is involved). `embedded-firmware-dev` ↔ `debug-methodology` (debugging process). `logicprobe` ↔ `design-reviewer` agent (design doc review, logic verification). `logicprobe` ↔ `state-machine-design` (behavioral claim probing). `logicprobe` ↔ `fact-check` (built-in fallback when the logicprobe plugin is not installed).
+**Cross-domain links**: load a secondary skill only when the primary skill's findings call for it — don't pre-load. Each skill's own `Use when` and NOT clauses already tell you when it applies.
 
 ## Domain Skills
 
@@ -198,45 +213,15 @@ Design doc review, claim verification, logic primitive + adversarial probing →
 
 ## Templates & References
 
-This skill's `references/` directory contains document templates and platform references. Use `Read` with the skill's reference path to load the relevant file when needed:
-
-### Platform
-
-- `platform-tool-mapping.md` — Claude Code → Codex/Cursor/Kimi/OpenCode/ZCode/Copilot tool name equivalents. **Load this immediately if you are NOT on Claude Code.**
-
-### Workflow Templates
+The `references/` directory holds the workflow document templates plus three notes. Read the file you need by name:
 
-- `detailed-change-plan.md` — Pre-edit implementation plan
-- `task-charter.md` — Task scope and slice roadmap
-- `iteration-notes.md` — Per-slice execution notes
-- `steward-memo.md` — Pre-execution architecture framing
-- `result-note.md` — Post-edit closure evidence
-- `final-qc.md` — Formal review verdict
-- `decision-log.md` — Approved decisions with rationale
-- `audit-ledger.md` — Recurring audit tracking (Framework Workflow)
-- `contract-matrix.md` — Contract-to-sentinel mapping (Framework Workflow)
-- `durable-requirement-notes.md` — Long-lived business invariants
+- `platform-tool-mapping.md` — tool-name equivalents for Codex/Cursor/Kimi/OpenCode/ZCode/Copilot/dsh, and the per-harness context-budget table. **Read this immediately if you are not on Claude Code.**
+- `proactive-suggestions.md` — ready-to-use phrasings for the suggestions below.
+- `INDEX.md` — the working-memory index template.
+- Workflow templates: `detailed-change-plan.md`, `task-charter.md`, `iteration-notes.md`, `steward-memo.md`, `result-note.md`, `final-qc.md`, `decision-log.md`, `audit-ledger.md`, `contract-matrix.md`, `durable-requirement-notes.md`.
 
 ---
 
 ## Proactive Suggestions
 
-When you observe any of these patterns in the user's task, **suggest the relevant feature before the user asks**. Most users don't know these capabilities exist.
-
-| Pattern You Observe | Suggest |
-|---------------------|--------|
-| User describes refactoring a state machine (splitting/merging states, changing transitions) | "Before you start, would you like me to run logic-primitive verification on the refactoring? I can extract the current state machine from code, compare it against your plan, and flag any regressions, deadlocks, or behavioral deltas before you change a single line." |
-| User describes a new state machine or protocol with ≥3 states | "I can run an adversarial verification on this design — 14 automated checks for deadlocks, unreachable states, race conditions, guard completeness, and invariant violations. Want me to do that before we implement?" |
-| User pastes or writes a state enum + switch-case dispatcher | "I notice a state machine here. Would you like me to model it and run completeness checks? I can find missing transitions, detect absorbing error loops, and verify that every state is reachable." |
-| User says "always" / "never" / "guaranteed" about behavior | "That's a behavioral invariant. I can model this and try to find a counter-example — the shortest event sequence that would violate 'X always happens before Y'. Want me to check?" |
-| User reviews a PR or diff that touches a state machine file | "This PR changes state machine logic. Would you like me to extract the before/after models and verify no regressions were introduced?" |
-| User debugs a crash or lockup in a stateful module | "This might be a state machine completeness issue. I can model the state machine from the code and check for deadlocks, unreachable states, or event ordering problems that could cause the lockup." |
-| Task would benefit from parallel execution (multiple independent modules, files, or dimensions) | "These are independent. I can dispatch parallel subagents to handle each module concurrently and synthesize the results. Want me to do that?" |
-| User writes a Detailed Change Plan without design review | "Before implementing, would you like the design-reviewer agent to fact-check this plan against the codebase? It catches API mismatches, missing modules, and mechanism feasibility issues before you write code." |
-
-### Suggestion Rules
-
-- **Suggest once per task**, not repeatedly. If the user declines, don't push.
-- **Be specific about what the feature does** — don't just name-drop. Say "I can find deadlocks and missing transitions" not "I can run logicprobe." If logicprobe is not installed, offer the built-in fact-check skill: "I can check every claim in the plan against the codebase."
-- **Estimate cost**: for lightweight checks, say "this takes ~30 seconds." For Python harness runs, say "this will generate and run a verification script."
-- **Respect the user's decision**: if they decline, move on. The features are tools, not requirements.
+Suggest a capability when it clearly applies and the user is unlikely to know it exists — state-machine verification for a state machine, a protocol, or an "always"/"never" claim; parallel sub-agents for genuinely independent modules; a design fact-check for a plan that had no review. Suggest **once per task**, say what the check finds rather than which tool runs it, and drop it if the user declines. Ready-to-use phrasings: `references/proactive-suggestions.md`.

package/skills/embedded-workbench/references/platform-tool-mapping.md

@@ -1,31 +1,31 @@
 # Platform Tool Mapping
 
-This plugin's skills and agents are written with Claude Code tool names. This reference maps each tool to equivalents on other platforms. When an agent prompt says "use `Read`" but you are on Codex CLI, use the mapped tool instead.
+This plugin's skills and agents are written with Claude Code tool names. This reference maps each tool to equivalents on the other supported platforms — Codex CLI, Cursor, Kimi CLI, OpenCode, ZCode, Copilot CLI, and DeepSeek Harness (dsh). When an agent prompt says "use `Read`" but you are on Codex CLI, use the mapped tool instead.
 
 ## Core File Tools
 
-| Claude Code | Codex CLI | Cursor | Kimi CLI | OpenCode | ZCode | Copilot CLI |
-|-------------|-----------|--------|----------|----------|-------|-------------|
-| `Read` | `read_file` | `read_file` | `read_file` | `read` | `read_file` | `read_file` |
-| `Write` | `write_file` | `write_to_file` | `write_file` | `write` | `write_file` | `write_file` |
-| `Edit` | `edit_file` | `replace_in_file` | `edit_file` | `edit` | `edit_file` | `edit_file` |
-| `Glob` | `search_file` | `search_file` | `glob` | `glob` | `search_file` | `search_file` |
-| `Grep` | `search_content` | `search_content` | `grep` | `grep` | `search_content` | `search_content` |
-| `Bash` | `run_shell` | `execute_command` | `execute_command` | `terminal` | `run_shell` | `run_command` |
+| Claude Code | Codex CLI | Cursor | Kimi CLI | OpenCode | ZCode | Copilot CLI | DeepSeek Harness (dsh) |
+|-------------|-----------|--------|----------|----------|-------|-------------|------------------------|
+| `Read` | `read_file` | `read_file` | `read_file` | `read` | `read_file` | `view` | `read` |
+| `Write` | `write_file` | `write_to_file` | `write_file` | `write` | `write_file` | `create` | `write` |
+| `Edit` | `edit_file` | `replace_in_file` | `edit_file` | `edit` | `edit_file` | `edit` | `edit` |
+| `Glob` | `search_file` | `search_file` | `glob` | `glob` | `search_file` | `glob` | `glob` |
+| `Grep` | `search_content` | `search_content` | `grep` | `grep` | `search_content` | `grep` | `grep` |
+| `Bash` | `run_shell` | `execute_command` | `execute_command` | `terminal` | `run_shell` | `bash` | `pwsh` / `bash` |
 
 ## Agent & Skill Tools
 
-| Claude Code | Codex CLI | Cursor | Kimi CLI | OpenCode | ZCode | Copilot CLI |
-|-------------|-----------|--------|----------|----------|-------|-------------|
-| `Skill("name")` | `$name` (auto) | `use_skill` | `/skill:name` | `$name` | `$name` | `skill("name")` |
-| `Agent` | `task` | `task` | `agent` | `task` | `agent` | `task` |
+| Claude Code | Codex CLI | Cursor | Kimi CLI | OpenCode | ZCode | Copilot CLI | DeepSeek Harness (dsh) |
+|-------------|-----------|--------|----------|----------|-------|-------------|------------------------|
+| `Skill("name")` | `$name` (auto) | `use_skill` | `/skill:name` | `$name` | `$name` | `skill` tool, or `/skill-name` | `skill` tool (`name: "..."`) |
+| `Agent` | `task` | `task` | `agent` | `task` | `agent` | `task` (`agent_type`) | `subagent` / `subagent_fork` |
 
 ## Web Tools
 
-| Claude Code | Codex CLI | Cursor | Kimi CLI | OpenCode | ZCode | Copilot CLI |
-|-------------|-----------|--------|----------|----------|-------|-------------|
-| `WebFetch` | `web_fetch` | `web_fetch` | `web_search` | `fetch` | `web_fetch` | `web_fetch` |
-| `WebSearch` | `web_search` | `web_search` | `web_search` | `search` | `web_search` | `web_search` |
+| Claude Code | Codex CLI | Cursor | Kimi CLI | OpenCode | ZCode | Copilot CLI | DeepSeek Harness (dsh) |
+|-------------|-----------|--------|----------|----------|-------|-------------|------------------------|
+| `WebFetch` | `web_fetch` | `web_fetch` | `web_search` | `fetch` | `web_fetch` | `web_fetch` | `web_fetch` |
+| `WebSearch` | `web_search` | `web_search` | `web_search` | `search` | `web_search` | — (no tool) | `web_search` |
 
 ## Platform-Specific Notes
 
@@ -62,13 +62,50 @@ This plugin's skills and agents are written with Claude Code tool names. This re
 
 ### Copilot CLI (GitHub Copilot)
 
-- `run_command` requires explicit approval for destructive operations.
-- Skill invocation differs from Claude Code; check Copilot CLI docs.
-- Copilot CLI 1.0.11+ supports Agent Skills.
+- Copilot CLI has a plugin system: a `plugin.json` manifest plus `agents/NAME.agent.md`, `skills/NAME/SKILL.md`, hooks, and MCP servers, distributed through marketplaces (`copilot-plugins`, `awesome-copilot`). Install with `copilot plugin install NAME@MARKETPLACE`, or register this repository with `copilot plugin marketplace add AmethystLuna/embedded-workbench`.
+- **This repository already works as a Copilot plugin**: Copilot's legacy manifest lookup checks `.plugin/plugin.json`, `plugin.json`, `.github/plugin/plugin.json`, then `.claude-plugin/plugin.json` — and it also reads `marketplace.json` from `.claude-plugin/`. Both files already exist here.
+- Skills follow the Agent Skills open standard, so `skills/NAME/SKILL.md` loads as-is. Invoke one with `/skill-name` in a prompt, e.g. `Use the /debug-methodology skill to ...`; inspect them with `/skills list` or `copilot skill list`.
+- Tool names: `view` (read), `create` (write), `edit`, `glob`, `grep`, `bash`, `web_fetch`, `task`, `skill`. The edit tool is `str_replace_editor` under the hood, with `view`/`create`/`edit` as its aliases.
+- There is **no** `web_search` tool — use `web_fetch` against a search URL.
+- `task` requires an `agent_type` of `explore`, `task`, `general-purpose`, or `code-review`. `explore` is read-only and the cheapest; prefer it for searches.
+- Sub-agent status comes from `read_agent` / `list_agents`; async shell sessions use `bash` with `mode: "async"` plus `read_bash` / `write_bash` / `stop_bash` / `list_bash`.
+- Agents in this plugin are **not** loaded by Copilot: it requires `agents/NAME.agent.md`, and this repository ships `agents/NAME.md`.
+
+### DeepSeek Harness (dsh)
+
+- dsh is the one platform this plugin ships a **native bundle** for (root `package.json` declares `dsh.bundle`), so no skill-copy step is needed: `dsh plugin --profile <name> add dsh-embedded-workbench`.
+- Tool names are lowercase: `read`, `write`, `edit`, `glob`, `grep`. Shell access is `pwsh` on Windows hosts and `bash` elsewhere.
+- Skills load through the `skill` tool by name — there is no `Skill(...)` call syntax.
+- Plan mode is the native `exit_plan_mode` tool, not `ExitPlanMode`.
+- The 4 Claude Code sub-agents are intentionally **not** ported: use the native sub-agent tools for parallel work, and take the steward/reviewer roles directly.
+- `subagent` starts a **fresh** context and returns only its result — reach for it when the detail can be discarded (read-only discovery, sweeping logs, running a suite). `subagent_fork` is **seeded with this conversation** — reach for it when the sub-task needs context you already built, instead of rebuilding that context inside a prompt.
+- `Agent(subagent_type: "Explore")` has no separate equivalent — use `glob` / `grep` directly, or dispatch a read-only `subagent`.
+- **Context-budget markers** you can actually see (no token meter is exposed to the model): a tool result rewritten with `[... tool result middle pruned ...]`, a spill notice naming the omitted bytes and the complete-result path, and the compaction checkpoint preamble (`This is an automatically generated checkpoint condensing an earlier span…`). Treat any of them as "stop pulling content in whole" — switch to file references, or delegate the reading.
+- Install, verify, and config-override details live in `.dsh/INSTALL.md` at the repository root.
+
+## Context Budget Interfaces
+
+What each harness actually exposes to the **model** about its context budget, checked 2026-09-25 against vendor documentation (and, for Codex CLI, the `openai/codex` source). "User-only" means the signal exists but never reaches the model. `UNVERIFIED` means the vendor does not document it — do not invent a marker string for that cell.
+
+| Harness | Model sees a token/percent readout? | Compaction — trigger and what the model receives | Oversized tool output | Sub-agent context |
+| --- | --- | --- | --- | --- |
+| Claude Code | No — `/context` and the status line are user-facing (the status line even exposes `used_percentage`, but to the terminal, not the model) | Automatic near the limit (`/autocompact <100K–1M>`). Older tool outputs are cleared first, then history is summarized; afterwards an oversized re-read returns as a `Referenced file` path instead of content, and invoked skill bodies are re-injected capped at 5,000 tokens each / 25,000 total | Bash success output past ~30,000 characters becomes a file path plus a preview of up to 2,000 characters (a failure is truncated in place with **no** path); hook `additionalContext` over 10,000 characters is saved to a file and the model gets a preview plus the path; Read adds a `PARTIAL view` notice and Glob flags a 100-file cap | Fresh isolated window; **fork mode** (on by default in interactive sessions, off under `-p`/SDK) inherits the parent conversation. Note a skill's `context: fork` is *not* a conversation fork |
+| Codex CLI | Yes, but feature-gated: a `get_context_remaining` tool (feature `token_budget`, **off by default**) answers "You have {N} tokens left in this context window", and a reminder is injected once remaining drops below the threshold. `/status` percentages are user-only | Default 90% of the window, hard cap 95%. The model receives the summary behind a fixed handoff preamble ("Another language model started to solve this problem…") | `truncation_policy` defaults to bytes/10000: the model sees `Warning: truncated output (original token count: N)` and `…N tokens truncated…`. Spill-to-file exists only for hooks (`Full hook output saved to: <path>`) | `spawn_agent` `fork_turns`: `"none"` / `"all"` / a turn count — **the default is `"all"`** |
+| Copilot CLI | No — `/context`, `/usage`, and `footer.showContextWindow` are user-only | ~80% of the window in the background (defers to ~90% when static context already uses ≥75%), pausing at ~95%. The model gets the summary plus preserved user instructions and plan/todo state; each compaction writes a numbered checkpoint (`/session checkpoints`) | **Over 20 KiB** is saved to a temporary file and the model gets the path plus a preview (`COPILOT_LARGE_OUTPUT_THRESHOLD_BYTES`) | Fresh window; `contextTier: "inherit"` inherits the parent's tier. Repository custom instructions are **not** inherited unless the agent sets `include-custom-instructions: true` |
+| Cursor | Nothing documented — the context ring and breakdown tray are UI | Automatic once the window is full; `/summarize` (alias `/compress`). The injected summary text is not published | Not documented (UNVERIFIED) | Fresh window only; `model: inherit` inherits the **model**, not the conversation |
+| OpenCode | No | `compaction.auto` is on, keeping ~15,000 recent tokens (`keep.tokens`) with `buffer` at 10% of the limit. The model sees the summary **as past conversation** — there is no distinct notice, and later compactions update the same summary. Native provider compaction substitutes an opaque encrypted item | Long tool output is shortened beside the summary; no marker string documented | UNVERIFIED |
+| Kimi CLI | No — `/usage` is a user command | Automatic compression as the conversation approaches the window limit, plus `/compact [hint]`. `/undo` cannot cross a compaction | Not documented (UNVERIFIED) | Isolated context per sub-agent (its own event stream); built-ins `coder`, `explore`, `plan`. `/btw` runs in a **forked** sub-agent that sees the conversation |
+| ZCode | No — the usage-stats panel shows the context composition as UI | `/compact` is user-initiated; automatic compaction is not documented | Not documented (UNVERIFIED) | UNVERIFIED |
+| DeepSeek Harness (dsh) | No — `ctx.tokenMeter` deliberately adds no model-visible surface | At `floor(min(W × 0.8, W − O − 65536))`. The model receives the checkpoint preamble plus `<compacted-summary>`; `/compact` is a user command | `[... tool result middle pruned ...]` for results over 8,192 code points (4,096 head / 1,024 tail) once compaction pressure qualifies, plus a spill notice naming the omitted bytes and the complete-result path (12,500 estimated tokens in `dsh-base`) | `subagent` starts fresh; `subagent_fork` is seeded with the conversation so far |
+
+Two consequences worth remembering:
+
+- **A budget readout reaching the model is the exception, not the rule.** Only Codex documents one, and it is off by default. Everywhere else, act on the truncation, spill, or compaction notice your harness actually shows.
+- **With no signal, ask the user instead of guessing.** Say what you are about to consume, that this harness gives you no budget readout, and the options with their costs, then do what they choose — falling back to the reversible option only when no one can answer.
 
 ## Sub-Agent Platform Equivalents
 
-This plugin defines 4 sub-agents. On platforms without an `Agent` tool:
+This plugin defines 4 sub-agents. On platforms without an `Agent` tool (including DeepSeek Harness):
 
 | Claude Code Agent | Alternative Approach |
 |-------------------|---------------------|
@@ -81,7 +118,7 @@ This plugin defines 4 sub-agents. On platforms without an `Agent` tool:
 
 Load this when:
 
-- The session is NOT running on Claude Code (check environment: `$CLAUDE_PLUGIN_ROOT`, `$CODEX_CLI`, `$CURSOR_PLUGIN_ROOT`, etc.)
+- The session is NOT running on Claude Code (check environment: `$CLAUDE_PLUGIN_ROOT`, `$CODEX_CLI`, `$CURSOR_PLUGIN_ROOT`, etc.; a dsh session runs under `$DSH_HOME` and sees none of those)
 - An agent prompt references a tool you don't recognize
 - You need to translate a skill or workflow instruction to your platform
 

package/skills/embedded-workbench/references/proactive-suggestions.md

@@ -0,0 +1,27 @@
+# Proactive Suggestion Phrasings
+
+Ready-to-use wording for the suggestions the bootstrap skill describes. Suggest once per
+task, say what the check actually finds rather than which tool runs it, and drop it if the
+user declines.
+
+| Pattern you observe | Suggest |
+| --- | --- |
+| Refactoring a state machine (splitting/merging states, changing transitions) | "Before you start, would you like me to run logic-primitive verification on the refactoring? I can extract the current state machine from code, compare it against your plan, and flag regressions, deadlocks, or behavioral deltas before you change a line." |
+| A new state machine or protocol with ≥3 states | "I can run an adversarial verification on this design — 22 automated checks (8 structural S1–S8 plus 14 adversarial A1–A14) for deadlocks, unreachable states, race conditions, guard completeness, and invariant violations." |
+| A state enum plus a switch-case dispatcher | "I notice a state machine here. I can model it and run completeness checks — missing transitions, absorbing error loops, unreachable states." |
+| "always" / "never" / "guaranteed" about behavior | "That's a behavioral invariant. I can model it and look for a counter-example — the shortest event sequence that violates 'X always happens before Y'." |
+| A PR or diff touching a state machine file | "I can extract the before/after models and verify that no regressions were introduced." |
+| A crash or lockup in a stateful module | "This might be a state-machine completeness issue. I can model it and check for deadlocks, unreachable states, or event-ordering problems behind the lockup." |
+| Multiple independent modules, files, or dimensions | "These are independent. I can dispatch parallel sub-agents per module and synthesize the results." |
+| A Detailed Change Plan with no design review | "Would you like the plan fact-checked against the codebase first? It catches API mismatches, missing modules, and mechanism-feasibility gaps before you write code." |
+
+## Rules
+
+- **Suggest once per task**, not repeatedly. If the user declines, don't push.
+- **Say what the check finds**, not which tool runs it. If logicprobe is not installed,
+  offer the built-in `fact-check` skill instead — "I can check every claim in the plan
+  against the codebase" — and note that behavioral/model claims then degrade to manual
+  confirmation.
+- **Estimate cost** when it matters: a lightweight check is seconds; a full model
+  verification pass generates and runs a script.
+- **Respect the decision**: these are tools, not requirements.