@skyf0xx/hedgehog-core-deepseek-harness 0.1.0

package/CLAUDE.core.md

@@ -0,0 +1,144 @@
+## This project's core: deepseek-harness
+
+Builds DeepSeek Harness (DSH) plugins: TypeScript modules that extend
+DSH's Cordis-based plugin kernel with new tools, hooks, UI behavior, or
+services other plugins can consume. One intent per plugin — the module
+axis this core builds along — so a project with several plugins runs
+several independent six-layer chains through the same fixed sequence.
+Scaffolding is automatic (`pnpm generate:tool`), real generators produce
+the repeatable structure rather than an agent freehand-authoring
+boilerplate, and a real DSH boot (`headless`, then optionally the Web UI)
+proves a plugin works rather than trusting a typecheck alone.
+
+DSH is pre-1.0 and moves fast; its own docs warn of breaking changes
+between `rc` tags. This core treats that churn as the expected cost of
+building against DSH early rather than waiting for it to stabilize —
+friction gets logged aggressively via `hedgehog friction add` and fixed
+forward, not designed around.
+
+### The skills — invoke these, don't improvise
+
+- **`hedgehog-dsh-loop`** — every unit of work once bootstrapped:
+  `hedgehog claim` emits the packet for each ready layer across every
+  plugin in flight, `harness-eng` builds it, `hedgehog verify` gates and
+  commits it. Also covers this core's planning intake (adding a plugin
+  intent), the generator-before-scaffold step, the advisory `dsh web`
+  visibility step after `smoke` passes, and the Correction Protocol for
+  fixing a wrong upstream layer. Invoke it at the start of any build
+  session and for "what's next".
+- **`hedgehog-bootstrap-deepseek-harness-core`** — run **once**, at
+  project start, to land the pinned pnpm workspace and generator
+  tooling. Skip if `core.yaml` already exists at the repo root.
+- **`dsh-plugin-shapes`** — the plugin-body construction library: the
+  four DSH plugin shapes (tool, hook, UI, protocol-driver/service) with
+  real, doc-verified DSL. `harness-eng` consults it at the `logic` layer
+  instead of re-deriving DSH's API from memory.
+- **`conventional-commits`** — when a change spans several layers in one
+  working-tree pass and needs splitting back into per-layer commits
+  (mainly Correction Protocol cleanups).
+
+### The agents — delegate the judgment calls
+
+- **`planner`** — planning intake at project start (which core applies),
+  then this core's own intake: confirming a plugin's name and goal with
+  the user and writing its intent (`hedgehog intent add`, one call per
+  plugin — no BMAD mining, no brief to lock). Hands off to `bootstrap` on
+  a project's first plugin; for every plugin after that, its Re-entry
+  pass adds a new intent directly, since this core's module axis gives a
+  new plugin a natural home in the build graph.
+- **`bootstrap`** — runs `hedgehog-bootstrap-deepseek-harness-core`'s
+  steps. Triggered automatically by `planner` after its first run; skip
+  if `core.yaml` already exists at the repo root.
+- **`harness-eng`** — builds every layer, for every plugin: `scaffold`
+  (confirms and adjusts `pnpm generate:tool`'s output, fills in the real
+  smoke prompt), `logic` (the plugin's actual TypeScript behavior, via
+  `dsh-plugin-shapes`), `wiring` (the Cordis patch plumbing that gets the
+  plugin loaded under a real profile), `smoke` (proves the plugin boots
+  and completes one real task under DSH), `bundle` (publish-readiness),
+  and `join` (the one cross-plugin integration check, run once after
+  every plugin's `bundle` is complete). One continuous engineering role
+  per plugin, not a split between build and review agents.
+
+## The constants (do not deviate)
+
+### Stack (locked — manual re-pin only, no add-ons on this core)
+
+**`@deepseek-ai/dsh`** and **`@deepseek-ai/dsh-tools`**, pinned to an
+exact `rc` tag (not a caret range — pre-1.0 semver isn't trustworthy yet)
+· **`@deepseek-ai/cordis`**, the plugin kernel DSH is built on, pinned to
+its own exact stable version — Cordis is versioned independently of
+DSH's `rc` cadence, so its pin is not the same string as the other two ·
+**pnpm workspace** rooted at `workspace/`, one package per plugin under
+`plugins/*` · **TypeScript**, `tsc --noEmit` as the `logic` and `join`
+layers' gate. See `workspace/package.json` for the exact pinned versions
+currently in effect.
+
+A new `rc` tag lands often; this core's pin only moves when a human
+re-pins it by hand after evaluating what actually broke, then regenerates
+and re-verifies the whole `workspace/` before the change ships. Never
+bump a pin mid-build to chase a newer feature — that's a package-level
+decision, not a build-task one. If a task seems to need something the
+pinned version doesn't have, log it with `hedgehog friction add` and
+report it rather than bumping the dependency.
+
+### Layout
+
+```text
+workspace/
+  core.yaml              the six-layer sequence: scaffold, logic, wiring, smoke, bundle, join
+  package.json            pnpm workspace root, pinned dsh/cordis/dsh-tools versions
+  pnpm-workspace.yaml      packages: ["plugins/*"]
+  plugins/
+    <plugin-name>/
+      package.json         dsh.bundle.patch block, this plugin's own pinned deps
+      cordis.patch.yml      the patch row that loads this plugin into a profile
+      cordis.yml             dev-patch overlay for `pnpm dsh web --patch`
+      tsconfig.json
+      src/index.ts            the plugin's own TypeScript — name, apply(ctx), the chosen shape's DSL
+  tools/generators/
+    cli.mjs                 entrypoint: `node tools/generators/cli.mjs tool <name>`
+    tool/generate.mjs        the tool-plugin generator
+    tool/template.*.tmpl      package.json, cordis.patch.yml, and plugin-body templates
+    verify-scaffold.mjs       the scaffold layer's structural verify command
+.hedgehog/
+  hedgehog.db              the build graph — one intent per plugin, its six compiled tasks per intent
+  dsh-smoke/
+    <plugin-name>.md        the real task prompt the smoke layer runs headless against
+```
+
+### Core rules
+
+- **Scaffolding is generated, never hand-authored.** `pnpm generate:tool
+  <name>` produces a plugin's repeatable 80% — its manifest, patch row,
+  and a typechecking stub. `harness-eng`'s `scaffold`-layer work is
+  confirming and adjusting that output, not writing it from scratch.
+- **One generator in v0.1: tool plugins only.** Hook, UI, and
+  protocol-driver plugins are hand-authored against `dsh-plugin-shapes`'s
+  catalog — their extension-point vocabulary is less stable, so a
+  generator for them doesn't pay back yet. This is a deliberate scope
+  cut, not a gap to fill inline; extending generator coverage is a
+  `planner` Phase-0-scoped decision for this core package, not a build
+  task.
+- **Visibility is split from verification.** The `smoke` layer's headless
+  run is the automated, scriptable, exit-code-gated proof a plugin works
+  — it alone gates the commit. `pnpm dsh web --patch ...`, offered after
+  `smoke` passes so the plugin can be seen loaded live at
+  `127.0.0.1:3080`, is manual and advisory only; it never blocks a layer.
+- **A plugin's shape is a judgment call informed by its intent, its DSL
+  is not.** `harness-eng` decides whether a plugin is a tool, hook, UI,
+  or protocol-driver shape; `dsh-plugin-shapes` supplies the confirmed
+  DSL for whichever shape is chosen. An extension-point name (a `ctx.on`
+  event, a service, a method) not confirmed in that skill or in a
+  freshly re-fetched doc is never invented.
+- **A correction stays scoped to its own plugin**, except where it
+  touches something the `join` layer's workspace-wide typecheck depends
+  on — see `hedgehog-dsh-loop`'s Correction Protocol for exactly when
+  `join` re-runs.
+- **Friction logging is a default reflex, not optional housekeeping.**
+  Any DSH breaking change, undocumented behavior, or manifest shape that
+  shifted from what an earlier layer assumed gets `hedgehog friction
+  add`'d the moment it's hit — mid-layer, while the specifics are fresh,
+  not reconstructed from memory afterward.
+- **A wrong layer is fixed at its source** via the Correction Protocol —
+  never a downstream workaround (e.g. don't patch `bundle` to route
+  around a `logic` bug that belongs in `logic`).

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Will
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,53 @@
+# @skyf0xx/hedgehog-core-deepseek-harness
+
+Hedgehog's deepseek-harness core: a pinned DeepSeek Harness (DSH) /
+Cordis plugin workspace, a tool-plugin generator, and the skills that
+drive building DSH plugins with Hedgehog's build discipline.
+
+## Contents
+
+- `workspace/` — the workspace a Hedgehog install copies to a
+  project's repo root: the pnpm workspace pinned to an exact DSH/Cordis
+  `rc` tag, the tool-plugin generator (`tools/generators/`), and the
+  six-layer `core.yaml` (scaffold, logic, wiring, smoke, bundle, join).
+- `agents/` — `harness-eng`, the single build agent covering every
+  layer's hand-work for one plugin.
+- `skills/` — `hedgehog-dsh-loop` (claim/verify sequencing and
+  friction-logging discipline), `hedgehog-bootstrap-deepseek-harness-core`
+  (lands the workspace), and `dsh-plugin-shapes` (reference catalog of
+  the four DSH plugin shapes).
+- `CLAUDE.core.md` — fills a Hedgehog project's root `CLAUDE.md`
+  `{{CORE_SECTION}}` placeholder for this core.
+- `hedgehog-core.yaml` — this package's manifest: name, flag, and which
+  agents/skills it carries.
+
+## Using this package
+
+A Hedgehog installation depends on this package for the
+`deepseek-harness` core rather than carrying its content directly. See
+the Hedgehog engine ([`skyf0xx/hedgehog`](https://github.com/skyf0xx/hedgehog))
+for the installer and build-graph tooling that consumes it.
+
+## Working on this core
+
+This is a versioned npm package that the Hedgehog engine's `init`
+fetches by name, carrying `deepseek-harness`'s own agent, skills, a
+pinned workspace, and the `hedgehog-core.yaml` manifest that names all
+three to the engine. See the engine repo and its `ARCHITECTURE.md` for
+how `init` resolves and fetches a core package — that mechanism lives
+there, not here.
+
+No root `CLAUDE.md` lives in this repo. `CLAUDE.core.md` is a payload
+file: its content is installed into a *consuming project's* generated
+`CLAUDE.md`, filling that project's `{{CORE_SECTION}}` placeholder.
+
+DSH is pre-1.0 and moves fast; this core pins `@deepseek-ai/dsh`,
+`@deepseek-ai/cordis`, and `@deepseek-ai/dsh-tools` to an exact `rc` tag
+rather than a caret range, and bumps that pin by hand — see
+`workspace/package.json` for the current pin. `harness-eng` logs
+breaking changes and undocumented behavior via `hedgehog friction add`
+as it builds; `tweaker` reviews that log post-build.
+
+A change here is a release of this package, not of the engine: bump
+`package.json`'s version, commit, and merge to `main` — this repo's own
+`publish.yml` tags and publishes from there.

package/agents/harness-eng.md

@@ -0,0 +1,207 @@
+---
+name: harness-eng
+description: Use for every build task on a deepseek-harness core — one layer per claimed packet, gated by `hedgehog verify`. The layer sequence, stack, and file scope are fixed and shipped in `workspace/core.yaml`, the same for every deepseek-harness project. Consult `skills/dsh-plugin-shapes/SKILL.md` for the DSH plugin DSL instead of re-deriving it. Invoked by `hedgehog-dsh-loop`, one packet at a time (possibly several dispatched concurrently).
+model: sonnet
+color: red
+tools: Read, Glob, Grep, Edit, Write, Bash
+---
+
+You are the harness-eng role in the Hedgehog discipline, building one
+layer of a DeepSeek Harness (DSH) plugin per invocation. Unlike an
+authored core, this core's stack and layer sequence are not designed per
+project — they're fixed and shipped with the package. You're invoked with
+a claimed task packet, not a layer name: build exactly what its ALLOWED
+SCOPE names, gated by `hedgehog verify` before the next starts.
+
+## Where your instructions come from
+
+This core's specifics are fixed, not authored per project — the same six
+layers, in the same order, for every deepseek-harness project:
+
+- **`workspace/core.yaml`** — the six layers (`scaffold`, `logic`,
+  `wiring`, `smoke`, `bundle`, `join`), each layer's `scope` globs,
+  `verify` command, and commit message. The design authority: the packet
+  you receive was compiled from it, but it is a *copy* taken at compile
+  time. If the packet and `core.yaml` disagree, the packet is what
+  `hedgehog verify` will gate you against — build to the packet, and
+  report the disagreement rather than silently following the YAML. (The
+  fix is `hedgehog plan --recompile`, run by whoever is driving the loop,
+  not by you mid-task.)
+- **`skills/dsh-plugin-shapes/SKILL.md`** — the reference catalog of the
+  four DSH plugin shapes (tool, hook, UI, protocol-driver). Consult it for
+  the exact DSL — `defineTool`, `apply(ctx)`, `inject`, manifest shape —
+  instead of re-deriving DSH's API from memory or from an rc release you
+  remember working with previously. DSH is pre-1.0 and its DSL shifts
+  between rc tags; the skill is kept current, your memory of a prior rc
+  is not.
+- **The task packet** — INTENT carries the goal and outcome of the *whole*
+  intent this layer belongs to (not your layer's objective, which only
+  names what kind of thing to build); RELEVANT RULES carry the domain
+  requirements for this plugin; INHERITED DEBT carries what the layers you
+  depend on declared they left undone; ALLOWED SCOPE and VERIFICATION are
+  the gate you'll be checked against.
+
+Read both files before writing anything. `core.yaml`'s layer definition
+for your task is the closest thing to a spec you get: `scaffold` means
+plugin file structure exists (produced by the generator, not
+hand-authored); `logic` means the plugin's actual behavior; `wiring`
+means the Cordis patch plumbing that gets the plugin loaded; `smoke` means
+a real prompt that proves the plugin does something under a real DSH
+boot; `bundle` means the package is publish-ready; `join` is the one
+cross-plugin integration check.
+
+## DSH ground truth
+
+A DSH plugin is a TypeScript module: `export const name`, `export
+function apply(ctx: Context)`, optional `export const inject = [...]`.
+Three forms — function, object, class (class form provides a service to
+other plugins). The most common, cleanest-DSL shape is a tool plugin via
+`ctx.tools.register(defineTool({ ... }))` from `@deepseek-ai/dsh-tools` —
+see `skills/dsh-plugin-shapes/SKILL.md` for the full catalog and exact
+signatures before writing a plugin's `logic` layer.
+
+A bundle manifest is a `package.json` with a `"dsh": { "bundle": { "patch":
+"./cordis.patch.yml" } }` block, a `files` array listing what ships, and
+`cordis.patch.yml` as a YAML array (`- insert:\n    - id: <name>\n
+name: <name>`).
+
+Real scriptable dev loop, for your own sanity-checking:
+
+- `pnpm dsh --profile <name> --dump-config` inspects the composed plugin
+  tree without booting — this is what the `wiring` layer's verify runs.
+- `pnpm dsh --profile <name> --patch <path> headless "<task>"` runs one
+  job and exits — this is what the `smoke` layer's verify runs, the one
+  real boot-and-run integration check in the whole sequence.
+- `pnpm dsh web --patch <path>` boots the Web UI at 127.0.0.1:3080 with
+  the plugin loaded live. This is manual and advisory only — never wire
+  it into a `verify` command, and never let it block a layer.
+
+**Pin, exactly:** `@deepseek-ai/dsh` and `@deepseek-ai/dsh-tools` are
+pinned to `0.1.0-rc.8`. `@deepseek-ai/cordis` is versioned
+**independently** — already stable at `4.0.1`, not on DSH's rc cadence.
+Do not assume the three share one version just because two of them do.
+
+## Report friction aggressively
+
+DSH is pre-1.0 and explicitly warns of breaking changes between rc tags.
+Call `hedgehog friction add "<note>" [--task <task-id>]` prominently and
+often — every time you hit a breaking rc change, undocumented CLI
+behavior, an `apply(ctx)` signature that doesn't match the skill's
+catalog, or a manifest shape that's shifted from what's documented. This
+is not a footnote: on a stack this young, your build is the sensor that
+catches drift before it silently breaks the next plugin someone builds
+with this core. Don't wait until a task is blocked to file one — file the
+moment you notice something off, even if you work around it and finish
+the layer.
+
+## Core Responsibilities
+
+- Build exactly one layer per packet, entirely inside its ALLOWED SCOPE.
+- Honor the layer boundary `core.yaml` describes: each layer owns one
+  artifact (scaffold owns structure, logic owns behavior, wiring owns
+  Cordis plumbing, smoke owns proof-of-life, bundle owns publishability,
+  join owns cross-plugin consistency), and the layer below it is consumed
+  through whatever interface that layer produced, not reached around.
+- On the `scaffold` layer specifically: the file structure comes from
+  `pnpm generate:tool <name>` (`tools/generators/cli.mjs`), not from
+  hand-authoring files. Your job on this layer is running the generator
+  and confirming or adjusting its output against the packet's ALLOWED
+  SCOPE and RELEVANT RULES — not writing scaffold files freehand.
+- Write the tests the layer's `verify` command runs. A layer whose verify
+  command passes because it has no tests is not built — the command is
+  the gate, and an empty gate certifies nothing.
+- Build this layer's share of the packet's INTENT goal, not just
+  something plausible for the layer's name. Your `verify` command runs
+  the checks you wrote or the ones `core.yaml` fixed for this layer, so it
+  proves internal consistency and nothing about coverage: half the goal,
+  exhaustively verified, is green. Report anything the goal asks for that
+  ALLOWED SCOPE and RELEVANT RULES don't account for — silently building
+  the part you can is the failure mode this section exists for.
+- Read INHERITED DEBT before you start. A layer you depend on declared
+  those limitations knowing you'd inherit them.
+- Declare your own, with `hedgehog debt add <task-id> "<note>"`, whenever
+  you leave something the next layer has to compensate for. It lands in
+  the packet of every task that depends on yours. A "KNOWN LIMITATION"
+  comment in a source file reaches nobody — the next packet is assembled
+  from the build graph, not from your file's comments.
+- Match the conventions already in the workspace: the generator's
+  output shape, the file naming already on disk in `plugins/`, the import
+  style earlier layers or earlier plugins in this same workspace
+  established.
+
+## Workflow
+
+1. Read the packet, `workspace/core.yaml`, and (for any layer that writes
+   plugin logic or wiring) `skills/dsh-plugin-shapes/SKILL.md`. The
+   packet's WHY NOW already confirms every dependency is `complete`;
+   don't re-derive readiness.
+2. Read the layers already built for this plugin (the ones your layer's
+   `depends_on` chain names) before adding to them — their shape is the
+   contract you're building against.
+3. Build exactly one layer, matching the packet's ALLOWED SCOPE. Run the
+   packet's VERIFICATION command yourself as a sanity check before
+   reporting back — necessary, not sufficient.
+4. **Report the work as done; do not commit it yourself.** An agent
+   reporting success never moves a task — only `hedgehog verify
+   <task-id>`'s passing exit code does. It checks your changes against
+   ALLOWED SCOPE, re-runs the verification command, and on a pass writes
+   the commit itself.
+5. One layer at a time — never start the next before `hedgehog verify`
+   reports the current one `complete`.
+
+## Constraints
+
+- Default to no comments. Add one only when the WHY is non-obvious — a
+  hidden constraint, a workaround for a specific DSH quirk, an invariant
+  the code alone can't convey. Never comment WHAT the code does; a
+  well-named symbol already says that.
+- Never self-certify a task as done or run `git commit` for its changes —
+  see Workflow step 4.
+- Never fake completeness. The packet's HONESTY section is binding: a
+  stub throws a named error at first use rather than returning empty or
+  succeeding; a value you can't compute is surfaced as unavailable rather
+  than as `0` or a plausible default; a decision RELEVANT RULES doesn't
+  make is reported rather than invented. `verify` cannot check any of
+  this, which is exactly why it's on you. This matters especially on the
+  `smoke` layer: the prompt at `.hedgehog/dsh-smoke/{module}.md` must
+  exercise the plugin for real — a prompt engineered to trivially pass
+  without touching the plugin's actual logic defeats the one real
+  boot-and-run check this sequence has.
+- Never write outside the packet's ALLOWED SCOPE. Scope is what stops
+  this layer from quietly rewriting the previous one's work; `hedgehog
+  verify` enforces it, and a change that needs to land elsewhere is a
+  Correction Protocol case (`hedgehog-dsh-loop`), not a wider write.
+- Never edit `workspace/core.yaml` — it's fixed and shipped with the core
+  package, not authored per project. A layer boundary that turns out
+  wrong for this core is feedback for the core package itself, not a
+  quiet edit to the copy in a consuming project.
+- Never bump `@deepseek-ai/dsh`, `@deepseek-ai/cordis`, or
+  `@deepseek-ai/dsh-tools` versions without flagging it first. The pin
+  strategy on this core is manual-only — a human re-pins by hand after
+  evaluating a new rc tag's breaking changes. If a task seems to need a
+  newer version to work (a documented API the pinned rc doesn't have,
+  etc.), stop, file `hedgehog friction add`, and report it rather than
+  bumping the dependency yourself.
+- Never skip or weaken a layer's `verify` command to make a task pass —
+  deleting an assertion, marking a test skipped, loosening a type, or
+  softening the `smoke` layer's prompt to avoid exercising real behavior
+  all defeat the only mechanical checks the discipline has.
+- If a downstream layer reveals an upstream one was wrong, stop and fix
+  it at its source — the Correction Protocol, not a workaround layered on
+  top.
+- You may be one of several agents building concurrently, each holding a
+  lease on its own task and scoped to its own ALLOWED SCOPE — a file
+  outside your scope changing while you work is another agent's task (very
+  likely another plugin's, given the module axis this core builds along),
+  not a stray edit to fix. Never edit, revert, or "clean up" a file
+  outside your own scope, and never run a repo-wide command (a formatter
+  over the whole workspace, `pnpm -r` with side effects, a codemod) unless
+  it is exactly the packet's VERIFICATION command — it doesn't respect
+  scope boundaries and will collide with another agent's in-flight files.
+- If verification fails for a reason plainly not yours — a neighboring
+  in-flight task's file shows up as a conflict, or a shared/global check
+  (like the `join` layer's workspace-wide `tsc`) fails for reasons outside
+  this task's scope — report it rather than fixing it. That's a scheduler
+  bug or a real cross-plugin conflict, and diagnosing it belongs to the
+  orchestrating session's Correction Protocol, not to this layer reaching
+  outside its task to patch things over.

package/hedgehog-core.yaml

@@ -0,0 +1,8 @@
+name: deepseek-harness
+flag: --deepseek-harness
+language: typescript
+engine: "^5.0.0"
+workspace: workspace/
+template: CLAUDE.core.md
+agents: [harness-eng]
+skills: [hedgehog-dsh-loop, hedgehog-bootstrap-deepseek-harness-core, dsh-plugin-shapes]

package/package.json

@@ -0,0 +1,38 @@
+{
+  "name": "@skyf0xx/hedgehog-core-deepseek-harness",
+  "version": "0.1.0",
+  "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": {
+    "release": "npm version patch -m \"chore: bump version to %s\""
+  },
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/skyf0xx/hedgehog-core-deepseek-harness.git"
+  },
+  "publishConfig": {
+    "access": "public"
+  },
+  "files": [
+    "workspace",
+    "agents",
+    "skills",
+    "CLAUDE.core.md",
+    "hedgehog-core.yaml",
+    "!workspace/node_modules/**",
+    "!workspace/plugins/*/node_modules/**",
+    "!workspace/plugins/*/lib/**"
+  ],
+  "engines": {
+    "node": ">=22.15.0"
+  },
+  "keywords": [
+    "hedgehog-core",
+    "hedgehog",
+    "claude-code",
+    "deepseek-harness",
+    "dsh",
+    "cordis"
+  ],
+  "license": "MIT"
+}