@skyf0xx/hedgehog 6.2.3 → 6.2.5

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.3",
+  "version": "6.2.5",
   "description": "Install the Hedgehog build discipline (agents + skills) into a repo, for Claude Code, Cursor, or Gemini CLI.",
   "type": "module",
   "repository": {

package/src/db/rebuild.mjs

@@ -218,26 +218,32 @@ async function replayIntents(db, intentsDir) {
   return count;
 }
 
-// Every commit subject in history mapped to its position, newest first —
-// one `git log` call rather than one per task. Membership alone answers
-// "did this task ever run"; position also answers "did it run *after*
-// the thing it depends on", which is what a `once: true` task needs,
-// since its commit subject is a constant that one historical occurrence
-// would otherwise satisfy forever. `--topo-order` so the position is a
+// Every commit subject in history mapped to EVERY position it occurs at,
+// newest first — one `git log` call rather than one per task. Membership
+// alone answers "did this task ever run"; position also answers "did it
+// run *after* the thing it depends on", which is what a `once: true`
+// task needs, since its commit subject is a constant that one historical
+// occurrence would otherwise satisfy forever. Keeping every occurrence
+// (not just the newest) is what lets markCompletedTasks tell two tasks
+// that share a constant commit_message apart on a linear-chain core: one
+// real commit per intent that actually ran the layer, each position
+// claimable by at most one task. `--topo-order` so position is a
 // property of the history's shape rather than of commit timestamps.
 function loadCommitSubjects() {
   const output = execSync('git log --topo-order --format=%H%x00%s', { encoding: 'utf8' });
-  const newestPosition = new Map();
+  const positions = new Map();
   let position = 0;
   for (const line of output.split('\n')) {
     if (!line) continue;
     const [, subject] = line.split('\0');
     if (subject === undefined) continue;
-    // Newest first, so the first occurrence seen is the most recent one.
-    if (!newestPosition.has(subject)) newestPosition.set(subject, position);
+    // Newest first, so pushing in read order keeps each subject's array
+    // newest-to-oldest.
+    if (!positions.has(subject)) positions.set(subject, []);
+    positions.get(subject).push(position);
     position++;
   }
-  return newestPosition;
+  return positions;
 }
 
 // A task is complete iff some commit's subject exactly matches its
@@ -246,25 +252,65 @@ function loadCommitSubjects() {
 // there's no verify_command to re-run and no working tree diff to check,
 // only the historical fact that the commit already happened.
 //
-// A `once: true` task carries two extra conditions: every prerequisite
-// must be complete, and its own commit must be *newer* than all of them.
-// Its prerequisite set is the only one that grows after the task has
-// already run — `planner`'s Re-entry pass adds a new intent whose work a
-// tail once-layer then depends on (plan.mjs reopens it for exactly that
-// reason). Its commit subject carries no {module}, so it is a constant:
-// the single `chore(infra): deploy` from the first run would otherwise
-// make the layer look done forever, re-closing it here on the next fresh
-// clone and quietly undoing the reopen. Requiring it to sit above its
-// prerequisites in history is what encodes "the deploy ran *after* that
-// module landed". Walked to a fixpoint, since a once-layer may sit
-// behind another one.
+// A task's `commit_message` is unique to it exactly when the layer's
+// `commit` template interpolates `{module}` — the module-axis case,
+// where each intent's copy of the layer produces a distinct string. A
+// `once: true` layer has no module to substitute (core.mjs's
+// validateCore rejects one that names {module}), so its single task's
+// commit subject is a constant by construction — and, since a core
+// compiles at most one once-task per once-layer, that task is the only
+// one carrying its subject. A linear-chain core (authored, adopted) has
+// no module axis at all: every layer's `commit` is a fixed string in
+// core.yaml with no `{module}` token, so every intent that walks the
+// chain compiles a per-layer task carrying that same constant — one task
+// per intent, all sharing one subject.
 //
-// This condition is deliberately not applied to per-module tasks. A task
-// that completed without touching any file leaves no commit at all
-// (verifyTask writes none), and cascading that gap through the whole
-// chain would reset already-built modules. Scoping it to once-layers
-// keeps the change to cores that use the feature, and errs toward
-// re-running an idempotent infrastructure step rather than skipping it.
+// A commit_message shared by more than one task (grouped below into
+// `ambiguousTasks`) means membership in commitSubjects can't tell those
+// tasks apart: every commit ever made with that subject is a candidate
+// match for every one of them. Two conditions resolve it:
+//
+//   1. Ordering — a task's own matching commit must sit *above* (be
+//      newer than) every one of its own prerequisites' matching
+//      commits, the same way a once-task has always required its commit
+//      to postdate the module it deploys. Without this, the first
+//      intent's commit for a layer would satisfy every later intent's
+//      task of that same layer forever, re-closing the layer on a fresh
+//      clone regardless of what that later intent's own chain has
+//      actually done.
+//   2. Consumption — a group of N tasks sharing a subject can credit at
+//      most as many of them complete as there are actual commits with
+//      that subject in history, each commit backing at most one task.
+//      Ordering alone doesn't catch a head-of-chain task: with no
+//      prerequisite of its own, "ran after its prerequisites" is
+//      vacuously true regardless of which commit it points at, which is
+//      exactly the shape of the bug — a fresh intent's first layer,
+//      sharing a constant commit_message with an already-built intent's
+//      completed first layer, has nothing to check position against.
+//      Consumption is what a head-of-chain task actually needs: once
+//      every real commit for that subject is claimed by other tasks,
+//      none is left for it to point at.
+//
+// Both are walked together, per group, in a single deterministic pass
+// ordered by task id: earlier-sorted tasks get first claim on the
+// oldest still-unclaimed matching commit that satisfies the ordering
+// condition against whatever their own prerequisites already claimed.
+// A task that finds no claimable commit is left incomplete — the safe
+// direction, matching every other cross-cutting-layer default in this
+// engine (re-running an idempotent step beats silently skipping one).
+// The whole thing is walked to a fixpoint, since one ambiguous task's
+// claim can be the prerequisite another ambiguous task needs before it
+// can claim its own (a once-layer behind another once-layer, or one
+// linear-chain layer behind the one before it in the same intent).
+//
+// A task with a commit_message unique to it (the ordinary module-axis
+// case) skips all of this: it is marked complete directly from
+// commitSubjects membership, with no ordering or consumption check.
+// That's necessary, not just cheaper — a task that completed without
+// touching any file leaves no commit at all (verifyTask writes none),
+// and applying either check there would cascade that gap through the
+// whole chain and reset already-built modules that have no ambiguity to
+// resolve in the first place.
 function markCompletedTasks(db, commitSubjects) {
   const tasks = db.prepare('SELECT id, module, commit_message FROM tasks').all();
   const prerequisites = new Map(tasks.map((t) => [t.id, []]));
@@ -272,39 +318,64 @@ function markCompletedTasks(db, commitSubjects) {
     prerequisites.get(d.task_id)?.push(d.depends_on_task_id);
   }
 
-  // Position of each task's most recent matching commit; undefined means
-  // the task never committed.
-  const positionOf = new Map(
-    tasks.map((t) => [t.id, commitSubjects.get(t.commit_message)]),
-  );
+  const messageCounts = new Map();
+  for (const task of tasks) {
+    messageCounts.set(task.commit_message, (messageCounts.get(task.commit_message) ?? 0) + 1);
+  }
+  const isAmbiguous = (task) => messageCounts.get(task.commit_message) > 1;
 
+  // Position of each unambiguous task's one matching commit; undefined
+  // means the task never committed. An ambiguous task's position is
+  // resolved separately below, since "the" matching commit for its
+  // subject isn't decided until a claim succeeds.
+  const positionOf = new Map();
   const complete = new Set();
-  const onceTasks = [];
+  const ambiguousTasks = [];
   for (const task of tasks) {
-    if (task.module === CORE_MODULE) {
-      onceTasks.push(task);
+    if (task.module === CORE_MODULE || isAmbiguous(task)) {
+      ambiguousTasks.push(task);
       continue;
     }
-    if (positionOf.get(task.id) !== undefined) complete.add(task.id);
+    const position = (commitSubjects.get(task.commit_message) ?? [])[0];
+    positionOf.set(task.id, position);
+    if (position !== undefined) complete.add(task.id);
   }
+  // Deterministic claim order within a shared subject: sorted by task id.
+  ambiguousTasks.sort((a, b) => a.id.localeCompare(b.id));
+
+  // Every commit position still unclaimed, per subject — shrinks as
+  // ambiguous tasks below claim one each.
+  const available = new Map(
+    [...commitSubjects].map(([subject, positions]) => [subject, [...positions]]),
+  );
 
-  // Lower position is newer, so a once-task ran after a prerequisite when
-  // its own position is strictly smaller.
-  const ranAfterPrerequisites = (task) => {
-    const own = positionOf.get(task.id);
-    return prerequisites.get(task.id).every((id) => {
+  // A task ran after a prerequisite when its own claimed position is
+  // strictly smaller (newer) than the prerequisite's.
+  const ranAfterPrerequisites = (task, position) =>
+    prerequisites.get(task.id).every((id) => {
       const prereq = positionOf.get(id);
-      return prereq === undefined || own < prereq;
+      return prereq === undefined || position < prereq;
     });
-  };
 
   let changed = true;
   while (changed) {
     changed = false;
-    for (const task of onceTasks) {
-      if (complete.has(task.id) || positionOf.get(task.id) === undefined) continue;
+    for (const task of ambiguousTasks) {
+      if (complete.has(task.id) || positionOf.has(task.id)) continue;
       if (!prerequisites.get(task.id).every((id) => complete.has(id))) continue;
-      if (!ranAfterPrerequisites(task)) continue;
+
+      const slots = available.get(task.commit_message) ?? [];
+      // Oldest-first, so a task claims the least-recent commit that
+      // still satisfies its ordering condition — leaving newer slots
+      // free for whichever task in the group depends on this one.
+      const slotIndex = [...slots]
+        .map((position, i) => [position, i])
+        .sort((a, b) => b[0] - a[0])
+        .find(([position]) => ranAfterPrerequisites(task, position))?.[1];
+      if (slotIndex === undefined) continue;
+
+      const [position] = slots.splice(slotIndex, 1);
+      positionOf.set(task.id, position);
       complete.add(task.id);
       changed = true;
     }
@@ -313,13 +384,14 @@ function markCompletedTasks(db, commitSubjects) {
   const setComplete = db.prepare("UPDATE tasks SET status = 'complete' WHERE id = ?");
   for (const id of complete) setComplete.run(id);
 
-  // A once-task can be marked complete by the loop above and then fail
-  // one of the extra conditions on a later pass of the fixpoint walk.
-  // Reconcile it back rather than leaving the stale status untouched.
+  // A task on the ambiguous path can be marked complete by the loop
+  // above and then fail to claim a slot on a later pass of the fixpoint
+  // walk. Reconcile it back rather than leaving the stale status
+  // untouched.
   const reopen = db.prepare(
     "UPDATE tasks SET status = 'planned' WHERE id = ? AND status = 'complete'",
   );
-  for (const task of onceTasks) {
+  for (const task of ambiguousTasks) {
     if (!complete.has(task.id)) reopen.run(task.id);
   }
 

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/gemini/gemini-extension.json

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