@skyf0xx/hedgehog 6.2.4 → 6.2.6

package/README.md

@@ -192,6 +192,18 @@ Bundle
 Join
 ```
 
+### Copywriting
+
+Copy is drafted and revised against a mechanical gate instead of prompting alone:
+
+``` text
+Brief
+  ↓
+Draft ⇄ zod validation()
+  ↓ pass
+Ship
+```
+
 ### Anything else
 
 A CLI, a library, a browser extension, a data pipeline, etc. gets its build order.

package/README.zh-CN.md

@@ -192,6 +192,18 @@ Bundle
 Join
 ```
 
+### 文案写作
+
+文案的撰写与修改会经过一道机械化的关卡，而不是仅靠提示词：
+
+``` text
+Brief
+  ↓
+Draft ⇄ zod validation()
+  ↓ pass
+Ship
+```
+
 ### 其他任意类型
 
 CLI、库、浏览器扩展、数据管道等，都会拥有各自的构建顺序。

package/bin/cli.mjs

@@ -21,7 +21,7 @@ import { spawn, execFileSync } from 'node:child_process';
 import { dbInit, DB_PATH, dbAbsPath, openDb, openDbAt } from '../src/db/init.mjs';
 import { loadCore, lintCore, isModuleAxis } from '../src/db/core.mjs';
 import { planTasks, CORE_INTENT_ID } from '../src/db/plan.mjs';
-import { addIntent, INTENTS_DIR } from '../src/db/intent.mjs';
+import { addIntent, INTENTS_DIR, intentFilePath } from '../src/db/intent.mjs';
 import {
   nextTask,
   formatNext,
@@ -595,9 +595,13 @@ ${bold('Usage')}
   npx @skyf0xx/hedgehog abandon <intent-id> --reason "<why>"
                                                    drop an intent that will never finish: records why,
                                                    resets its tasks to planned on trunk, removes its
-                                                   worktree and branch
+                                                   worktree and branch — the id stays taken; to change
+                                                   an abandoned intent, edit its .hedgehog/intents/<id>.json
+                                                   by hand and run 'hedgehog plan', not 'intent add' again
   npx @skyf0xx/hedgehog intent add [flags]        add an intent (rules/requirements/dependencies)
-  npx @skyf0xx/hedgehog intent add --file <path>  add an intent from a JSON file
+  npx @skyf0xx/hedgehog intent add --file <path>  add an intent from a JSON file — fails on an id already
+                                                   in the build graph, including one reset by 'hedgehog
+                                                   abandon' (still 'planned', not removed); see 'abandon' above
   npx @skyf0xx/hedgehog next                      print the task packet for one ready task
   npx @skyf0xx/hedgehog show <task-id>            print the task packet for any task, at any status
   npx @skyf0xx/hedgehog claim --owner <owner> [--count <n>]   atomically claim up to n ready tasks
@@ -1555,7 +1559,11 @@ async function planCommand(args = []) {
   }
 
   for (const { intentId, branch, path } of worktreesCreated) {
-    console.log(`  ${green('worktree')}  ${bold(intentId)} ${dim(`${branch} → ${path}`)}`);
+    console.log(
+      `  ${green('worktree')}  ${bold(intentId)} ${dim(`${branch} → ${path}`)}\n` +
+        `             ${dim(`compiling here, not onto trunk, because every intent ${intentId} depends_on is already complete —`)}\n` +
+        `             ${dim(`see \`hedgehog merge ${intentId}\`/\`hedgehog abandon ${intentId}\` to close it out later`)}`,
+    );
   }
 
   // Compiles the new worktree's own graph from inside it — a plain
@@ -1728,8 +1736,15 @@ async function intentCommand(args) {
   try {
     intent = await addIntent(db, record);
   } catch (err) {
+    const idTaken = /UNIQUE constraint failed: intents\.id/.test(err.message);
     console.error(
-      `${red('Failed to add intent:')} ${err.message}\n\nUsage: hedgehog intent add --id <id> --goal <goal> --outcome <outcome> [--rule <r>]... [--depends-on <id>]...\n   or: hedgehog intent add --file <path.json>\n`,
+      `${red('Failed to add intent:')} ${err.message}\n\n` +
+        (idTaken
+          ? `${bold(record.id)} already exists in the build graph — this includes an intent \`hedgehog abandon\`\n` +
+            `reset to 'planned' rather than removed. To change it, edit ${intentFilePath(record.id)}\n` +
+            `by hand and run \`hedgehog plan\` to recompile; don't run \`intent add\` again for this id.\n\n`
+          : '') +
+        `Usage: hedgehog intent add --id <id> --goal <goal> --outcome <outcome> [--rule <r>]... [--depends-on <id>]...\n   or: hedgehog intent add --file <path.json>\n`,
     );
     process.exitCode = 1;
     return;
@@ -3705,7 +3720,10 @@ async function abandonCommand(args) {
   console.log(
     `\n${bold('Abandoned.')} ${dim(`${id} is reset to planned on trunk. Commit ${ABANDONED_DIR}/${id.toLowerCase()}.json —`)}\n` +
       `${dim('the build graph is derived and gitignored, and an uncommitted abandonment')}\n` +
-      `${dim('is reverted by the next `hedgehog db rebuild`.')}\n`,
+      `${dim('is reverted by the next `hedgehog db rebuild`.')}\n\n` +
+      `${dim(`${bold(id)} still exists in the build graph at 'planned' — do not run \`hedgehog intent add\` for`)}\n` +
+      `${dim(`this id again (it will fail: the id is already taken). To change the intent, edit`)}\n` +
+      `${dim(`${intentFilePath(id)} by hand and run \`hedgehog plan\` to recompile it.`)}\n`,
   );
 }
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@skyf0xx/hedgehog",
-  "version": "6.2.4",
+  "version": "6.2.6",
   "description": "Install the Hedgehog build discipline (agents + skills) into a repo, for Claude Code, Cursor, or Gemini CLI.",
   "type": "module",
   "repository": {

package/src/agents/planner.md

@@ -259,6 +259,20 @@ the first-run shape; on re-entry, run `hedgehog-planning-intake`'s
   owns `.hedgehog/chain/00-brief.md` and this core's own Confirm & Lock
   stage; `.hedgehog/BMAD/` is written by the shared Phase 0 in
   `hedgehog-planning-intake`.
+- **`copywriting`** → open `hedgehog-copywriting-loop`'s planning-intake
+  section and follow it: it opens with `hedgehog-planning-intake`'s
+  Phase 0 (the same vendored BMAD shelf `full-stack-app` runs, in full,
+  archived to `.hedgehog/BMAD/` — the same skill, not a separate copy of
+  its steps), then does its own mining into a draft brief (what's being
+  written, the audience, the register), the copywriting counterpart to
+  `hedgehog-planning-intake`'s Phase 1 (domain modules and an Add-ons
+  decision on full-stack-app). The mined draft is shown back at this
+  core's own Confirm & Lock stage, pre-filled from BMAD's output, for
+  the user to accept or correct. State the same BMAD attribution as
+  full-stack-app before that Phase 0 begins. `hedgehog-copywriting-loop`
+  owns `.hedgehog/copy/00-brief.md` and this core's own Confirm & Lock
+  stage; `.hedgehog/BMAD/` is written by the shared Phase 0 in
+  `hedgehog-planning-intake`.
 - **`deepseek-harness`** → no BMAD shelf runs on this core, and none of
   `hedgehog-planning-intake` applies. Intake is mechanical, owned
   entirely by `hedgehog-dsh-loop`'s own Planning intake section: confirm

package/src/db/plan.mjs

@@ -5,11 +5,11 @@
 //
 // full-stack-app and pwa-app: one task per layer per intent (an intent is
 // a domain module — see the core definition's `{module}` placeholder).
-// landing-page, deepseek-harness, and authored (whether designed from
-// scratch or adopted onto an existing repo): one task per phase/layer, no
-// module axis. All are the same operation — walk a core definition's layer
-// chain once per intent — because a linear chain is the degenerate case of
-// the layer graph (spec: MVP scope item 5).
+// landing-page, copywriting, deepseek-harness, and authored (whether
+// designed from scratch or adopted onto an existing repo): one task per
+// phase/layer, no module axis. All are the same operation — walk a core
+// definition's layer chain once per intent — because a linear chain is
+// the degenerate case of the layer graph (spec: MVP scope item 5).
 //
 // Layer cardinality: a layer marked `once: true` in the core definition
 // opts out of that per-intent multiplication and compiles a single task

package/src/db/worktree.mjs

@@ -431,6 +431,26 @@ function resetIntentTasksToPlanned(db, intentId) {
     .all(intentId);
 }
 
+// Deletes every `intent_dependencies` row naming `intentId` on either
+// side. An abandoned intent is reset to `planned` with no compiled tasks
+// on trunk, so a `depends_on` edge pointing at it (something else declared
+// as depending on it) or away from it (its own declared dependency) is
+// both stale the moment abandonment lands: `eligibleIntents` (this file)
+// reads that table directly to decide worktree eligibility, and a row
+// surviving abandonment lets an unrelated intent read as "its dependency
+// is satisfied" against an intent that no longer has any real status to
+// satisfy anything with, or lets this intent re-read as eligible against a
+// dependency it no longer declares. Re-adding the same id later
+// (`hedgehog intent add --file` with a JSON that still declares the
+// dependency) recreates the row from that file, same as any first-time
+// add — this only clears what abandonment made stale, not what a future
+// add might legitimately restate.
+function clearIntentDependencies(db, intentId) {
+  db.prepare(
+    'DELETE FROM intent_dependencies WHERE intent_id = ? OR depends_on_intent_id = ?',
+  ).run(intentId, intentId);
+}
+
 // Resets every task of `intentId` to `planned` on whichever DB `db` is
 // open against (trunk, by the CLI's own contract — see abandonCommand),
 // clears any lease, and reopens the intent itself to `planned` so a later
@@ -440,6 +460,11 @@ function resetIntentTasksToPlanned(db, intentId) {
 // tasks that don't exist yet). Mirrors reconcile.mjs#applyReconciliation's
 // shape: the committed file is written first, this is applied second.
 //
+// Also clears every `intent_dependencies` row naming this intent, on
+// either side (clearIntentDependencies, above) — an abandoned intent's own
+// declared dependency and any other intent's dependency on it are both
+// stale the instant it resets to `planned` with no shipped work.
+//
 // Refuses an intent already `complete` (merged, real shipped work) —
 // same reasoning as reconcile.mjs#confirmReconciliation refusing an
 // already-complete task: applyAbandonment resets tasks to 'planned'
@@ -458,6 +483,7 @@ export function applyAbandonment(db, intentId) {
     );
   }
   const resetTasks = resetIntentTasksToPlanned(db, intentId);
+  clearIntentDependencies(db, intentId);
 
   if (intent) {
     db.prepare("UPDATE intents SET status = 'planned' WHERE id = ?").run(intentId);
@@ -501,6 +527,7 @@ export function replayAbandonments(db, abandonments) {
     }
     setPlanned.run(intentId);
     resetIntentTasksToPlanned(db, intentId);
+    clearIntentDependencies(db, intentId);
     replayed.push({ intentId, reason: record.reason });
   }
   return { replayed, orphaned };

package/src/hosts/capabilities.mjs

@@ -13,6 +13,7 @@ export const AGENT_CAPABILITY = {
   // Build and scaffold: read, write, and run commands.
   'backend-eng': 'full',
   bootstrap: 'full',
+  'copy-writer': 'full',
   'front-end-eng': 'full',
   'harness-eng': 'full',
   'landing-builder': 'full',

package/src/hosts/gemini/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "hedgehog",
-  "version": "6.2.4",
+  "version": "6.2.6",
   "description": "Hedgehog build discipline: ordered, tested, verified build steps.",
   "contextFileName": "GEMINI.md"
 }

package/src/registry/cores.json

@@ -51,6 +51,15 @@
       "language": "typescript",
       "repository": "https://github.com/skyf0xx/hedgehog-core-adopted",
       "selects_when": "The description is about bringing Hedgehog's discipline to a codebase that already exists, rather than building something new — the repo already has real source files, or the user says so explicitly: \"adopt this repo\", \"add Hedgehog to my existing project\", \"I want scope/verify enforcement on my changes here\". Not chosen by matching a `when` paragraph the way a shipped core is: hedgehog-adopt reads the repo read-only, proposes a linear-chain .hedgehog/core.yaml whose verify commands are the repo's own, and writes only .hedgehog/ — never a workspace, never a stack migration. This is the core most often confused with authored: adopted brings discipline to an existing repo, while authored designs and scaffolds a workspace from scratch for something being built new — route here only when the work is landing on a codebase that already exists."
+    },
+    {
+      "name": "copywriting",
+      "flag": "--copywriting",
+      "package": "@skyf0xx/hedgehog-core-copywriting",
+      "version": "^0.1.1",
+      "language": "typescript",
+      "repository": "https://github.com/skyf0xx/hedgehog-core-copywriting",
+      "selects_when": "The description asks for a piece of writing or prose to be written or fixed as its own deliverable — marketing copy, a product announcement, UI microcopy strings, docs prose, an email, a pitch, an article, an essay, a blog post, or any other standalone written piece — with no page, app, or other artifact being built around it. Concrete signals: \"write an article about X\", \"write copy for X\", \"help me write a blog post\", \"make this sound less like AI\", \"fix this copy\", \"improve this writing\", \"draft a product announcement\", a request to run text through an AI-tell or humanizer check. Not just marketing/product framing — any standalone prose request qualifies, articles and essays included. The core drafts against `checkCopy()`, a real script running deterministic AI-tell and prose-quality checks (banned vocabulary, passive voice, readability score, sentence-length variance), not an agent's own self-review — a piece of writing ships because the script exited 0. This is the core most often confused with landing-page: landing-page's own copy skill still owns copy that's part of a full page build (headline, hero, section copy sequenced through that core's Chain Method); route here only when the writing is the entire ask, not one stage of a larger build."
     }
   ]
 }

package/src/registry/index.mjs

@@ -1,9 +1,10 @@
 // Core package registry. One entry per Hedgehog core — full-stack-app,
-// pwa-app, landing-page, deepseek-harness, and authored — naming the npm
-// package that ships its agents, skills, and (for the first four) scaffold,
-// plus the CLI flag `hedgehog init` accepts for it and the prose `planner`
-// reads aloud in Phase 0 to choose one. A fixed table, one entry per core,
-// discovered by name or flag rather than convention.
+// pwa-app, landing-page, copywriting, deepseek-harness, and authored —
+// naming the npm package that ships its agents, skills, and (for the
+// first five) scaffold, plus the CLI flag `hedgehog init` accepts for it
+// and the prose `planner` reads aloud in Phase 0 to choose one. A fixed
+// table, one entry per core, discovered by name or flag rather than
+// convention.
 //
 // `authored` carries no flag — it is never selected off a fixed list at
 // install time. hedgehog-core-design chooses it during planning (from-scratch

package/src/skills/hedgehog-planning-intake/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: hedgehog-planning-intake
-description: Use on any core for first-run planning intake — Phase 0 runs the vendored BMAD-METHOD planning shelf, shared by every core, and Phase 1 (mining `04-prd.md` into intent records plus the Add-ons/sync-and-remote-entities decision) is full-stack-app's and pwa-app's shared procedure — identical mechanics, a different decision at step 5/8. Phase 0 also defines compressed intake, the path a user's explicit "just build it" choice takes on full-stack-app, pwa-app, and authored cores: one batched round of questions in place of the shelf, writing the same archive at the same path so Phase 1, `ux-planner`, and the Re-entry pass all keep their documented source. Also use for the Re-entry pass, which mines new scope into additional intents without re-running the shelf, on any core with a module axis to add an intent to (full-stack-app, pwa-app, authored) — landing-page has none, so its own new-scope path runs through `hedgehog-landing-loop`'s Correction Protocol instead. Invoked by the `planner` agent, which decides the path; don't run standalone. landing-page runs this skill's Phase 0 on first run, then mines the same archive through `hedgehog-landing-loop`'s own planning-intake section, that core's counterpart to this skill's Phase 1. An authored core runs this skill's Phase 0, then `hedgehog-core-design`, then this skill's Phase 1 mining against the designed layer sequence. A brownfield adoption (`hedgehog-adopt`) never runs this skill's shelf at all — the drivers BMAD elicits are already settled facts of a repo that already exists.
+description: Use on any core for first-run planning intake — Phase 0 runs the vendored BMAD-METHOD planning shelf, shared by every core, and Phase 1 (mining `04-prd.md` into intent records plus the Add-ons/sync-and-remote-entities decision) is full-stack-app's and pwa-app's shared procedure — identical mechanics, a different decision at step 5/8. Phase 0 also defines compressed intake, the path a user's explicit "just build it" choice takes on full-stack-app, pwa-app, and authored cores: one batched round of questions in place of the shelf, writing the same archive at the same path so Phase 1, `ux-planner`, and the Re-entry pass all keep their documented source. Also use for the Re-entry pass, which mines new scope into additional intents without re-running the shelf, on any core with a module axis to add an intent to (full-stack-app, pwa-app, authored) — landing-page has none, so its own new-scope path runs through `hedgehog-landing-loop`'s Correction Protocol instead. Invoked by the `planner` agent, which decides the path; don't run standalone. landing-page runs this skill's Phase 0 on first run, then mines the same archive through `hedgehog-landing-loop`'s own planning-intake section, that core's counterpart to this skill's Phase 1. copywriting runs this skill's Phase 0 the same way, then mines the same archive through `hedgehog-copywriting-loop`'s own planning-intake section into a what/audience/register brief — no module axis, so its own new-scope path runs through that loop's Correction Protocol rather than the Re-entry pass below. An authored core runs this skill's Phase 0, then `hedgehog-core-design`, then this skill's Phase 1 mining against the designed layer sequence. A brownfield adoption (`hedgehog-adopt`) never runs this skill's shelf at all — the drivers BMAD elicits are already settled facts of a repo that already exists.
 ---
 
 # Hedgehog Planning Intake
@@ -11,12 +11,15 @@ every core) and mining its output. On full-stack-app and pwa-app that
 mining is this skill's own Phase 1, into intent records written via
 `hedgehog intent
 add`; on landing-page it's `hedgehog-landing-loop`'s planning-intake
-section, into a subject/audience/job statement. This is the mechanics
+section, into a subject/audience/job statement; on copywriting it's
+`hedgehog-copywriting-loop`'s planning-intake section, into a
+what/audience/register brief. This is the mechanics
 `planner` calls once its Phase 0 core-selection check has picked a core —
 the interpretive judgment (which Feature becomes which intent, Confirm &
 Lock either way) belongs to `planner`; this skill (Phase 0, and Phase 1 on
-full-stack-app and pwa-app) and `hedgehog-landing-loop` (landing-page's
-own mining) are the fixed procedures that judgment runs inside.
+full-stack-app and pwa-app), `hedgehog-landing-loop` (landing-page's own
+mining), and `hedgehog-copywriting-loop` (copywriting's own mining) are
+the fixed procedures that judgment runs inside.
 
 That shelf run is a **first run**, once per project. When new scope
 enters play later on a core with a module axis (full-stack-app, pwa-app,