@skyf0xx/hedgehog-core-deepseek-harness 0.2.0 → 0.2.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@skyf0xx/hedgehog-core-deepseek-harness",
-  "version": "0.2.0",
+  "version": "0.2.2",
   "description": "Hedgehog's deepseek-harness core: a pinned DSH/Cordis plugin workspace, a tool-plugin generator, and the skills that drive building DeepSeek Harness plugins with Hedgehog's build discipline.",
   "type": "module",
   "scripts": {

package/skills/hedgehog-bootstrap-deepseek-harness-core/SKILL.md

@@ -56,6 +56,11 @@ Everything under this package's `workspace/`, copied to the repo root:
   `dsh-credentials-local` provider reads from a project-root `.env`.
   Copy to `.env` and fill in before any layer past `wiring` runs; `.env`
   itself is gitignored, never committed.
+- `README.md` — a thin index: what the workspace is, plus a `## Plugins`
+  section. `pnpm generate:tool <name>` appends one bullet here per new
+  plugin, right after the `<!-- plugin-readme-links -->` marker, linking
+  to that plugin's own generated README — this file is never hand-edited
+  beyond that.
 
 `node_modules` is not part of the copy — `pnpm install` regenerates it
 from the committed `pnpm-lock.yaml`.
@@ -114,11 +119,16 @@ are typecheck/structural checks against source files, not a real DSH
 boot. `smoke` (and later, `dsh web`) does: it boots a real profile and
 calls the model, so it needs `DEEPSEEK_API_KEY` resolvable by DSH's
 `dsh-credentials-local` provider. The simplest path is a `.env` file at
-the workspace root — `workspace/.env.example` documents this; copy it
-to `workspace/.env` and fill in the key (gitignored, never committed).
-Confirm with the user this exists or that they'll add it before
-`harness-eng` reaches a plugin's `smoke` layer — raise it now rather
-than letting it surface as a late failure three layers in.
+the repo root — `.env.example` documents this.
+
+Copy `.env.example` to `.env` yourself, leaving `DEEPSEEK_API_KEY=`
+blank — do not put a value in it. Never ask the user to paste the key
+into the conversation; a live credential has no reason to pass through
+chat history or logs. Tell them the file exists and where, and that
+they need to fill in the value directly in their editor or filesystem
+before `harness-eng` reaches a plugin's `smoke` layer — raise this now
+rather than letting it surface as a late failure three layers in. `.env`
+itself is gitignored, never committed.
 
 ### 5. Install
 

package/skills/hedgehog-dsh-loop/SKILL.md

@@ -31,13 +31,33 @@ is the cross-plugin integration check the per-plugin layers can't be.
 ## Planning intake (Phase 0, before any build layer)
 
 Run once per new plugin, before that plugin's `scaffold` task can be
-claimed. Ask the user directly, before anything else: mechanical intake
-(name + goal + outcome, fast) or the full BMAD shelf (brainstorming →
-brief → PRD → UX spec, the same procedure `full-stack-app`/`pwa-app` run,
-archived to `.hedgehog/BMAD/`)? A trivial single-tool plugin usually
-wants mechanical; a plugin with real ambiguity in its hook, UI, or
-protocol-driver shape can genuinely benefit from BMAD's elicitation —
-the choice is the user's, not fixed by this core.
+claimed. Always surface this as an explicit question to the user, even
+when confident which answer fits — never infer the answer from the
+plugin's apparent complexity and proceed without asking: mechanical
+intake (name + goal + outcome, fast) or the full BMAD shelf
+(brainstorming → brief → PRD → UX spec, the same procedure
+`full-stack-app`/`pwa-app` run, archived to `.hedgehog/BMAD/`)? A trivial
+single-tool plugin usually wants mechanical; a plugin with real ambiguity
+in its hook, UI, or protocol-driver shape can genuinely benefit from
+BMAD's elicitation — that's context for how to phrase the question and
+state a recommendation ("this sounds trivial enough for mechanical
+intake — sound right, or do you want the full BMAD pass?"), not a license
+to skip asking it. The choice is the user's, not fixed by this core.
+
+Ask it as its own distinct, dedicated prompt — a yes/no or
+multiple-choice tool call, not folded into the same turn as any other
+question (e.g. confirming the plugin's name, the mechanical path's next
+step). End the turn there and wait for the user's actual answer before
+starting either path; do not proceed to any step of either path in the
+same response that states the question.
+
+**Anti-pattern:** stating a recommendation and continuing in the same
+turn — "Let's do mechanical intake since this is trivial — now, what
+should we call the plugin?" — does not satisfy "surfacing it as an
+explicit question," even though it names both options and states a
+recommendation. Mentioning the choice is not the same as asking it: the
+turn must end on the question alone, with intake work starting only
+after the user replies.
 
 **Mechanical path:**
 
@@ -370,7 +390,13 @@ boundary`'s check applies regardless of which framing prompted the ask.
 Confirm it with `hedgehog boundary` before offering the handoff: it
 exits 0 only when nothing is in flight, the working tree is clean, and
 the last closed task completed its intent, and names which of the three
-failed otherwise. `hedgehog quiesce` answers only the in-flight third —
+failed otherwise. No layer's `ALLOWED SCOPE` covers `.hedgehog/friction/log.md`,
+so friction entries logged mid-build never ride along with a layer's own
+verify-commit — if it shows uncommitted at this point, commit it
+standalone first (`git add .hedgehog/friction/log.md && git commit -m
+"chore: friction log"`) before running `hedgehog boundary`, or its
+clean-tree check fails on a path no layer was ever going to commit.
+`hedgehog quiesce` answers only the in-flight third —
 the right check while waiting out a correction, not the one for clearing
 context. The same command is what decides any mid-build `/clear` too,
 and `hedgehog boundary --handoff` prints the block the next session

package/workspace/README.md

@@ -0,0 +1,9 @@
+# DeepSeek Harness Plugin Workspace
+
+A DeepSeek Harness (DSH) plugin workspace built with Hedgehog.
+
+## Plugins
+
+See each plugin's own README for what it does and how to run it:
+
+<!-- plugin-readme-links -->

package/workspace/core.yaml

@@ -3,6 +3,7 @@
 # plugin per project just never has a second intent; nothing forces or
 # blocks multi-plugin.
 id: deepseek-harness
+pluralizes: false
 layers:
   - id: scaffold
     scope: ["plugins/{module}/**", ".hedgehog/dsh-smoke/{module}.md"]
@@ -30,7 +31,7 @@ layers:
   - id: bundle
     depends_on: smoke
     scope: ["plugins/{module}/package.json", "plugins/{module}/lib/**"]
-    verify: "pnpm --filter {module} pack --pack-destination \"$(mktemp -d)\""
+    verify: "pnpm --filter {module} build && pnpm --filter {module} pack --pack-destination \"$(mktemp -d)\""
     commit: "feat({module}): bundle"
 
   - id: join

package/workspace/gitignore.template

@@ -1,5 +1,4 @@
 node_modules/
-plugins/*/lib/
 .env
 .hedgehog/hedgehog.db
 .hedgehog/hedgehog.db-*

package/workspace/package.json

@@ -13,5 +13,11 @@
     "@deepseek-ai/dsh": "0.1.0-rc.8",
     "@deepseek-ai/cordis": "4.0.1",
     "@deepseek-ai/dsh-tools": "0.1.0-rc.8"
+  },
+  "pnpm": {
+    "overrides": {
+      "react": "19.2.8",
+      "react-dom": "19.2.8"
+    }
   }
 }