@skyf0xx/hedgehog 3.0.8 → 3.0.11

package/README.md

@@ -48,6 +48,18 @@ The build order is encoded into the project. The AI does not have to remember wh
 
 ![Small steps, big leverage: small context loops, continuous verification, traceable evolution, sustainable velocity](https://raw.githubusercontent.com/skyf0xx/hedgehog/master/docs/images/small-steps.png)
 
+## Your build order is a graph
+
+**Every task** Hedgehog generates **is a node** with explicit dependencies in sqlite.
+
+Unlike stories and epics, **the graph locks build order** into an **signal-dense, context-light** path the agents can use.
+
+```bash
+npx @skyf0xx/hedgehog graph
+```
+
+![The Hedgehog build graph](https://raw.githubusercontent.com/skyf0xx/hedgehog/master/docs/images/graph.png)
+
 ## What Hedgehog builds
 
 ### Full-stack applications
@@ -101,7 +113,7 @@ scoped file access and a verification command per layer.
 
 ## Install
 
-From an empty project folder, run:
+From an empty project folder, ask Claude or your Agent to run:
 
 ``` bash
 # Full-stack app
@@ -156,15 +168,6 @@ from them. It never touches the instructions file, the build graph, the
 core workspace, or `skills/BMAD`, since those carry project-specific or
 write-once content.
 
-To see the build graph:
-
-``` bash
-npx @skyf0xx/hedgehog graph
-```
-
-Starts a small local server and opens a live, read-only diagram of every
-task, status and its dependencies.
-
 ## Why Hedgehog
 
 Most AI coding tools improve prompting.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@skyf0xx/hedgehog",
-  "version": "3.0.8",
+  "version": "3.0.11",
   "description": "Install the Hedgehog build discipline (agents + skills) into a repo, for Claude Code, Cursor, or Gemini CLI.",
   "type": "module",
   "repository": {
@@ -14,6 +14,7 @@
     "hedgehog": "bin/cli.mjs"
   },
   "scripts": {
+    "check": "node scripts/check.mjs",
     "release": "npm version patch -m \"chore: bump version to %s\""
   },
   "files": [

package/src/db/graph-server.mjs

@@ -15,6 +15,7 @@
 
 import { createServer } from 'node:http';
 import { readFile, writeFile, rm } from 'node:fs/promises';
+import { dirname, join } from 'node:path';
 import { DatabaseSync } from 'node:sqlite';
 import { buildGraph } from './graph.mjs';
 
@@ -31,6 +32,15 @@ if (!dbPath || !templatePath || !pidfilePath) {
 
 const template = await readFile(templatePath, 'utf8');
 
+// graph.html loads React/ReactFlow/dagre from here rather than a CDN, so
+// `hedgehog graph` works with no internet connection — vendored files
+// live alongside the template at src/templates/vendor/.
+const VENDOR_DIR = join(dirname(templatePath), 'vendor');
+const VENDOR_CONTENT_TYPES = {
+  '.js': 'application/javascript; charset=utf-8',
+  '.css': 'text/css; charset=utf-8',
+};
+
 function loadGraphJson() {
   // Opened and closed per request rather than held open: DatabaseSync is
   // synchronous and local, so the cost is negligible, and it avoids ever
@@ -44,7 +54,33 @@ function loadGraphJson() {
   }
 }
 
-const server = createServer((req, res) => {
+const server = createServer(async (req, res) => {
+  if (req.url.startsWith('/vendor/')) {
+    // Reject traversal/query strings before touching the filesystem —
+    // the vendor set is fixed and flat, so anything else is not a file
+    // this route is meant to serve.
+    const name = req.url.slice('/vendor/'.length);
+    const dotIndex = name.lastIndexOf('.');
+    const ext = dotIndex === -1 ? '' : name.slice(dotIndex);
+    if (!name || name.includes('/') || name.includes('..') || !(ext in VENDOR_CONTENT_TYPES)) {
+      res.writeHead(404);
+      res.end('Not found');
+      return;
+    }
+    try {
+      const body = await readFile(join(VENDOR_DIR, name));
+      res.writeHead(200, {
+        'content-type': VENDOR_CONTENT_TYPES[ext],
+        'cache-control': 'no-store',
+      });
+      res.end(body);
+    } catch {
+      res.writeHead(404);
+      res.end('Not found');
+    }
+    return;
+  }
+
   if (req.url === '/graph.json') {
     let body;
     try {

package/src/skills/hedgehog-core-design/blueprints/data-pipeline.md

@@ -15,9 +15,16 @@ schedule  — the orchestration wiring: what runs when, retries, backfill entry
 
 ## Adaptation points
 
-- Merge `schedule` into `load` when the pipeline is invoked externally
-  (cron calling a script, an orchestrator defined outside this repo) —
-  there's no orchestration surface here to build.
+- On the Dagster stack, `schedule` is Dagster's own schedule/sensor
+  definitions plus the retry policy on each op — real orchestration
+  surface that belongs in this repo and earns its own layer.
+- On the stdlib/argparse stack, or when a pipeline is invoked externally
+  regardless of stack (cron calling a script, an orchestrator defined
+  outside this repo), there is no in-repo orchestrator to retry or
+  backfill through: merge `schedule` into `load` and scope it to
+  whatever the script itself can do (an idempotent upsert key, a
+  `--since`/`--backfill` flag `load` reads), and record retries/
+  scheduling as owned by the caller rather than as a gap in this layer.
 - Split `extract` per source (`extract/{module}`) when the pipeline pulls
   from several genuinely different systems with independent failure modes
   and auth; keep one `extract` layer for a single source.