@skyf0xx/hedgehog 6.3.2 → 6.3.4

package/bin/cli.mjs

@@ -58,7 +58,7 @@ import {
   formatMissingRequirements,
 } from '../src/db/requires.mjs';
 import { whyPath, formatWhy } from '../src/db/why.mjs';
-import { addFriction, listFriction } from '../src/db/friction.mjs';
+import { addFriction, listFriction, resolveFriction } from '../src/db/friction.mjs';
 import { addDebt, listDebt, resolveDebt } from '../src/db/debt.mjs';
 import { addDecision, listDecisions } from '../src/db/decision.mjs';
 import {
@@ -668,7 +668,8 @@ ${bold('Usage')}
   npx @skyf0xx/hedgehog graph --no-open           start (or reuse) the server; print the URL instead
   npx @skyf0xx/hedgehog why <path>                provenance chain for a file
   npx @skyf0xx/hedgehog friction add "<note>"     log a friction note [--task <task-id>]
-  npx @skyf0xx/hedgehog friction list             list logged friction, oldest first
+  npx @skyf0xx/hedgehog friction list [--all]     list open friction, oldest first (--all includes resolved)
+  npx @skyf0xx/hedgehog friction resolve <friction-id> --reason "<why>"   mark a friction note resolved
   npx @skyf0xx/hedgehog debt add <task-id> "<note>"   declare debt that lands in dependent tasks' packets
   npx @skyf0xx/hedgehog debt list [<task-id>] [--all]   list open debt, oldest first (--all includes resolved)
   npx @skyf0xx/hedgehog debt resolve <debt-id> --reason "<why>"   mark a debt note resolved
@@ -3299,27 +3300,60 @@ async function frictionCommand(args) {
   }
 
   if (sub === 'list') {
+    const includeResolved = args.includes('--all') || args.includes('--resolved');
     const db = openDb();
     let entries;
     try {
-      entries = listFriction(db);
+      entries = listFriction(db, { includeResolved });
     } finally {
       db.close();
     }
 
     if (entries.length === 0) {
-      console.log(`${dim('No friction logged.')}\n`);
+      console.log(`${dim(includeResolved ? 'No friction logged.' : 'No open friction.')}\n`);
       return;
     }
     for (const entry of entries) {
       console.log(`#${entry.id}  ${dim(entry.loggedAt)}${entry.taskId ? `  ${bold(entry.taskId)}` : ''}`);
-      console.log(`  ${entry.note}\n`);
+      console.log(`  ${entry.note}`);
+      if (entry.resolvedAt) {
+        console.log(`  ${green('resolved')} ${dim(entry.resolvedAt)} — ${entry.resolvedReason}`);
+      }
+      console.log('');
     }
     return;
   }
 
+  if (sub === 'resolve') {
+    const frictionId = args[1];
+    const reasonIdx = args.indexOf('--reason');
+    const reason = reasonIdx !== -1 ? args[reasonIdx + 1] : undefined;
+
+    if (!frictionId || frictionId.startsWith('--') || !reason) {
+      console.error(`${red('Usage:')} hedgehog friction resolve <friction-id> --reason "<why>"\n`);
+      process.exitCode = 1;
+      return;
+    }
+
+    const db = openDb();
+    let result;
+    try {
+      result = await resolveFriction(db, { frictionId: Number(frictionId), reason });
+    } catch (err) {
+      console.error(`${red('Failed to resolve friction:')} ${err.message}\n`);
+      process.exitCode = 1;
+      return;
+    } finally {
+      db.close();
+    }
+
+    console.log(`  ${green('resolved')}  #${result.id}${result.taskId ? ` (${result.taskId})` : ''}`);
+    console.log(`  ${dim(result.note)}`);
+    return;
+  }
+
   console.error(
-    `${red('Unknown friction subcommand:')} ${sub ?? '(none)'}\n\nUsage: hedgehog friction add "<note>" [--task <task-id>]\n   or: hedgehog friction list\n`,
+    `${red('Unknown friction subcommand:')} ${sub ?? '(none)'}\n\nUsage: hedgehog friction add "<note>" [--task <task-id>]\n   or: hedgehog friction list [--all]\n   or: hedgehog friction resolve <friction-id> --reason "<why>"\n`,
   );
   process.exitCode = 1;
 }

package/package.json

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

package/src/db/friction.mjs

@@ -33,8 +33,44 @@ export async function addFriction(db, { note, taskId }) {
 }
 
 // Returns every friction row, oldest first, for tweaker's review pass.
-export function listFriction(db) {
+// Resolved rows are excluded by default — same convention as
+// listDebt — and included when `includeResolved` is set (`--all`).
+export function listFriction(db, { includeResolved = false } = {}) {
+  const where = includeResolved ? '' : 'WHERE resolved_at IS NULL';
   return db
-    .prepare(`SELECT id, task_id AS taskId, note, logged_at AS loggedAt FROM friction ORDER BY id ASC`)
+    .prepare(
+      `SELECT id, task_id AS taskId, note, logged_at AS loggedAt,
+              resolved_at AS resolvedAt, resolved_reason AS resolvedReason
+       FROM friction ${where} ORDER BY id ASC`,
+    )
     .all();
 }
+
+// Resolves one friction row by id: marks it resolved in the DB and
+// appends the marker to the same committed log (FRICTION_LOG_PATH) the
+// original entry was written to — friction has no `.hedgehog/notes/`
+// record the way debt does, so this is the row's only committed source
+// and `db rebuild` leaves friction rows untouched (see rebuild.mjs).
+export async function resolveFriction(db, { frictionId, reason }) {
+  if (!frictionId) throw new Error('friction resolve requires a friction id');
+  if (!reason) throw new Error('friction resolve requires a --reason');
+
+  const row = db
+    .prepare('SELECT id, task_id AS taskId, note, resolved_at AS resolvedAt FROM friction WHERE id = ?')
+    .get(frictionId);
+  if (!row) throw new Error(`no such friction entry: #${frictionId}`);
+  if (row.resolvedAt) throw new Error(`friction #${frictionId} is already resolved`);
+
+  const resolvedAt = new Date().toISOString();
+  db.prepare('UPDATE friction SET resolved_at = ?, resolved_reason = ? WHERE id = ?').run(
+    resolvedAt,
+    reason,
+    frictionId,
+  );
+
+  await mkdir(FRICTION_DIR, { recursive: true });
+  const header = `## ${resolvedAt} resolved #${frictionId}${row.taskId ? ` ${row.taskId}` : ''}`;
+  await appendFile(FRICTION_LOG_PATH, `${header}\n\n${reason}\n\n`);
+
+  return { id: row.id, taskId: row.taskId, note: row.note, resolvedAt, resolvedReason: reason };
+}

package/src/db/satisfied.mjs

@@ -0,0 +1,116 @@
+// Possibly-satisfied detection: a `planned` task whose scope_globs are
+// already fully covered by git-tracked, committed files with nothing
+// pending inside that scope — the heuristic nudge toward `hedgehog
+// reconcile` for work that landed under a different task's or a
+// different intent's commit, so `db rebuild`'s exact-commit-subject
+// attribution (rebuild.mjs#markCompletedTasks) never had a subject to
+// credit it against and the task sits `planned` forever with no signal.
+//
+// This is evidence, not proof, exactly like reconcile.mjs's
+// gatherEvidence: a scope glob resolving to tracked, clean paths says
+// the files a task would have written already exist and nothing is
+// mid-edit there. It says nothing about whether the task's objective was
+// actually met by that content — a `planned` task can legitimately share
+// a glob with pre-existing, unrelated code that still needs real work.
+// False positives are expected and acceptable; this only flags "look at
+// this", it never completes anything itself.
+//
+// Uses the same git pathspec mechanism verify.mjs's own scope gate uses
+// (`:(glob)<glob>` handed to git literally, no in-process glob dialect of
+// its own to keep in sync with core.mjs's), rather than matchesGlob's
+// witness-path walk — a witness path proves non-containment against a
+// *set* of globs (core.mjs's own use, and coverage's), not "which real
+// files in this repo currently match one glob", which only git's own
+// pathspec matcher can answer without re-walking the whole tree.
+
+import { execFileSync } from 'node:child_process';
+import { isEngineStatePath } from './engineState.mjs';
+
+function git(args) {
+  return execFileSync('git', args, { encoding: 'utf8' });
+}
+
+function pathspecsFor(scopeGlobs) {
+  return scopeGlobs.map((glob) => `:(glob)${glob}`);
+}
+
+// Tracked files under a task's scope, minus engine-state paths — the
+// same exclusion verify.mjs's gate applies, so a task whose scope happens
+// to reach into `.hedgehog/` never gets flagged on the build graph's own
+// bookkeeping.
+function trackedPathsInScope(scopeGlobs) {
+  let output;
+  try {
+    output = git(['ls-files', '--', ...pathspecsFor(scopeGlobs)]);
+  } catch {
+    return [];
+  }
+  return output
+    .split('\n')
+    .map((p) => p.trim())
+    .filter(Boolean)
+    .filter((p) => !isEngineStatePath(p));
+}
+
+// Modified, staged, or untracked paths under a task's scope — anything
+// `git status --porcelain` reports there means the scope is still
+// mid-edit, the opposite of "already satisfied".
+function dirtyPathsInScope(scopeGlobs) {
+  let output;
+  try {
+    output = git(['status', '--porcelain', '--', ...pathspecsFor(scopeGlobs)]);
+  } catch {
+    return [];
+  }
+  return output
+    .split('\n')
+    .map((line) => line.slice(3).trim())
+    .filter(Boolean)
+    .filter((p) => !isEngineStatePath(p));
+}
+
+// Every `planned` task whose scope_globs resolve to at least one tracked
+// file and zero dirty ones — a task with an empty scope match (nothing in
+// the repo yet touches its globs at all) is not flagged, since that is
+// simply unstarted work, not possibly-satisfied work.
+//
+// Only `planned` is read, not `ready`: a `ready` task already cleared
+// every dependency and is next.mjs/claim.mjs's own queue to hand out —
+// flagging it here would tell an operator to reconcile work a claim is
+// about to pick up anyway. `building`/`verifying` are leased and mid-flight
+// by definition; `blocked` has its own NEEDS ATTENTION path; `complete` is
+// done. `planned` is the one status this signal exists for: work nothing
+// has looked at yet, sitting behind whatever unlocked it.
+const PLANNED_TASKS_SQL = `
+  SELECT id, layer, objective, scope_globs FROM tasks
+  WHERE status = 'planned'
+  ORDER BY priority, id;
+`;
+
+export function possiblySatisfiedTasks(db) {
+  const tasks = db.prepare(PLANNED_TASKS_SQL).all();
+  const flagged = [];
+  for (const task of tasks) {
+    const scopeGlobs = JSON.parse(task.scope_globs);
+    if (scopeGlobs.length === 0) continue;
+    const tracked = trackedPathsInScope(scopeGlobs);
+    if (tracked.length === 0) continue;
+    const dirty = dirtyPathsInScope(scopeGlobs);
+    if (dirty.length > 0) continue;
+    flagged.push({ id: task.id, layer: task.layer, objective: task.objective, paths: tracked });
+  }
+  return flagged;
+}
+
+export function formatPossiblySatisfied(flagged) {
+  const lines = [`POSSIBLY SATISFIED  ${flagged.length}`];
+  for (const { id, layer, paths } of flagged) {
+    lines.push(`  ${id}   ${layer}   ${paths.length} tracked path${paths.length === 1 ? '' : 's'} in scope, none pending`);
+  }
+  lines.push('');
+  lines.push(
+    '  Scope glob already covered by clean, tracked files — not proof the objective was met.' +
+      ' See: hedgehog reconcile',
+  );
+  return lines.join('\n');
+}

package/src/db/schema.mjs

@@ -127,10 +127,12 @@ CREATE TABLE IF NOT EXISTS decisions (
 );
 
 CREATE TABLE IF NOT EXISTS friction (
-  id        INTEGER PRIMARY KEY,
-  task_id   TEXT REFERENCES tasks(id) ON DELETE SET NULL,
-  note      TEXT NOT NULL,
-  logged_at TEXT NOT NULL DEFAULT (datetime('now'))
+  id               INTEGER PRIMARY KEY,
+  task_id          TEXT REFERENCES tasks(id) ON DELETE SET NULL,
+  note             TEXT NOT NULL,
+  logged_at        TEXT NOT NULL DEFAULT (datetime('now')),
+  resolved_at      TEXT,
+  resolved_reason  TEXT
 );
 `;
 
@@ -178,7 +180,7 @@ export function ensureTaskColumns(db) {
 // hand-set past what MIGRATIONS actually covers, since runMigrations
 // trusts this number to mean "every migration through this version has
 // run."
-export const CURRENT_SCHEMA_VERSION = 3;
+export const CURRENT_SCHEMA_VERSION = 4;
 
 // Forward migrations, applied in order to bring a graph's user_version up
 // to CURRENT_SCHEMA_VERSION. Unlike the CREATE TABLE IF NOT EXISTS /
@@ -223,6 +225,18 @@ const MIGRATIONS = [
       }
     },
   },
+  {
+    version: 4,
+    // Same shape as version 3's debt columns, for friction — an existing
+    // graph's rows default to open the moment these columns exist.
+    migrate: (db) => {
+      const existing = new Set(db.prepare('PRAGMA table_info(friction)').all().map((row) => row.name));
+      if (!existing.has('resolved_at')) db.exec('ALTER TABLE friction ADD COLUMN resolved_at TEXT');
+      if (!existing.has('resolved_reason')) {
+        db.exec('ALTER TABLE friction ADD COLUMN resolved_reason TEXT');
+      }
+    },
+  },
 ];
 
 // Brings a graph's `PRAGMA user_version` up to CURRENT_SCHEMA_VERSION,

package/src/db/status.mjs

@@ -17,6 +17,7 @@ import { listFriction } from './friction.mjs';
 import { orphanedOverrides } from './overrides.mjs';
 import { RECONCILED_DIR, RECONCILED_NOTE_PREFIX } from './reconcile.mjs';
 import { formatMissingRequirements } from './requires.mjs';
+import { possiblySatisfiedTasks, formatPossiblySatisfied } from './satisfied.mjs';
 import { readyTasks, heldBackReason } from './ready.mjs';
 import { worktreeStatus } from './worktree.mjs';
 import { findClaimableTasks } from './claim.mjs';
@@ -219,6 +220,15 @@ function countFriction(db) {
 // in every count and list here. Reported unconditionally, not as a
 // warning: reconciling is a supported act, and the point is that the
 // distinction stays visible after the session that made it is gone.
+//
+// `possiblySatisfied` (satisfied.mjs) is a `planned` task whose scope
+// globs already resolve to tracked, clean files — a heuristic nudge, not
+// a completion: `db rebuild`'s attribution only credits a task whose own
+// commit_message appears as some commit's subject (rebuild.mjs), so work
+// that landed inside a commit made for a different task never has a
+// subject to match, and the task stays `planned` with no other signal
+// that its scope may already be covered. Read-only, like drift and
+// orphaned overrides — nothing here is ever auto-completed.
 // Synchronous, as it always was: `boundary.mjs#boundaryState` (a hot path
 // that only ever reads `graph.inFlight`) depends on that, and every other
 // section here is a plain SQL read with no I/O to await. The worktree
@@ -236,6 +246,7 @@ export function graphStatus(db, { core = null, overrides = new Map() } = {}) {
   const debt = loadDebtByTask(db);
   const frictionCount = countFriction(db);
   const reconciled = loadReconciledTasks(db);
+  const possiblySatisfied = possiblySatisfiedTasks(db);
   const total = Object.values(counts).reduce((a, b) => a + b, 0);
   return {
     counts,
@@ -248,6 +259,7 @@ export function graphStatus(db, { core = null, overrides = new Map() } = {}) {
     debt,
     frictionCount,
     reconciled,
+    possiblySatisfied,
     total,
   };
 }
@@ -293,6 +305,7 @@ export function formatStatus({
   debt = [],
   frictionCount = 0,
   reconciled = [],
+  possiblySatisfied = [],
   worktrees = { active: [], orphaned: [] },
   total,
   missingRequirements,
@@ -381,6 +394,15 @@ export function formatStatus({
     lines.push(formatDrift(drift));
   }
 
+  // Below drift, same family of "condition of the graph as a whole" —
+  // and above orphaned overrides, since a possibly-satisfied task is work
+  // an operator can act on right now (`hedgehog reconcile`), where an
+  // orphaned override is only ever inert.
+  if (possiblySatisfied.length > 0) {
+    lines.push('');
+    lines.push(formatPossiblySatisfied(possiblySatisfied));
+  }
+
   // Below drift because it's the rarer of the two and never blocks the
   // build: an orphaned override is work the operator asked for that isn't
   // happening, not work the graph is getting wrong. `hedgehog override

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

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

package/src/registry/cores.json

@@ -4,7 +4,7 @@
       "name": "full-stack-app",
       "flag": "--ts-full-stack-app",
       "package": "@skyf0xx/hedgehog-core-full-stack-app",
-      "version": "^1.0.6",
+      "version": "^1.1.0",
       "language": "typescript",
       "repository": "https://github.com/skyf0xx/hedgehog-core-full-stack-app",
       "selects_when": "The description names server-side logic across most of the app: authorization more expressive than per-object row-level security, background jobs, scheduled work or webhook receivers as the app's primary function, server-rendered or SEO-critical pages beyond an app shell, or a data model whose working set doesn't sensibly fit on a device. Persistent domain data alone is not the signal — a tracker, journal, notebook, or planner whose data fits on the user's device is pwa-app, even with sharing, accounts, or multi-device sync in scope, and even with one or two entities that must be server-authoritative. If the project has both a marketing page and a real app behind it, this is still full-stack-app: the page becomes routes inside apps/web, not a separate project."
@@ -13,7 +13,7 @@
       "name": "pwa-app",
       "flag": "--pwa-app",
       "package": "@skyf0xx/hedgehog-core-pwa-app",
-      "version": "^1.0.4",
+      "version": "^1.1.0",
       "language": "typescript",
       "repository": "https://github.com/skyf0xx/hedgehog-core-pwa-app",
       "selects_when": "The description names an app whose data model fits on the user's device and whose reads and writes are the user's own — a tracker, journal, notebook, planner, offline reference, or utility. Offline capability or installability named explicitly is a strong signal. Sharing, collaboration, accounts, and multi-device sync do NOT disqualify a project: Dexie Cloud provides sync, authentication, and server-enforced per-object access control, so a shared list, a family calendar, or a small team's board is still this core. A small number of entities that must be server-authoritative — a points balance, a reward ledger, anything a client must not write to directly — do NOT disqualify a project either: those entities are declared --remote and backed by Supabase (Postgres + RLS + Edge Functions) behind the same repository interface, while the rest of the app stays local-first. What routes a project to full-stack-app is server-side logic across most of the app, not the presence of one or two such entities: authorization beyond row-level policies, background jobs or webhooks as the app's primary function, server-rendered pages, or a working set too large for a device."
@@ -39,7 +39,7 @@
     {
       "name": "authored",
       "package": "@skyf0xx/hedgehog-core-authored",
-      "version": "^1.1.0",
+      "version": "^1.2.0",
       "language": "typescript",
       "repository": "https://github.com/skyf0xx/hedgehog-core-authored",
       "selects_when": "Neither shipped core fits, but the description names a real artifact a Builder step would produce — just not in either shipped core's shape. This core is designed by the planner rather than chosen from a fixed set: hedgehog-planning-intake's Phase 0 elicits the drivers first, then hedgehog-core-design names the system shape, picks the stack, derives the layers, and writes .hedgehog/core.yaml. It carries the same enforcement as a shipped core — ordered layers, scoped file access, verification before completion — but the sequence is designed for this project rather than battle-tested across many. This is the core most often confused with adopted: authored designs a workspace from scratch for a project being built new, while adopted brings Hedgehog's discipline to a repo that already exists — route here only when there is no existing codebase this work is being added to."
@@ -47,7 +47,7 @@
     {
       "name": "adopted",
       "package": "@skyf0xx/hedgehog-core-adopted",
-      "version": "^1.0.0",
+      "version": ">=1.0.0 <2.0.0",
       "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."