@skyf0xx/hedgehog 5.0.0 → 5.1.0

package/README.md

@@ -1,6 +1,7 @@
 # Turn AI from a code generator into a reliable software engineer ⭐
 
 [![Total downloads](https://raw.githubusercontent.com/skyf0xx/hedgehog/master/badges/npm-downloads.svg)](https://www.npmjs.com/package/@skyf0xx/hedgehog)
+[![Support Hedgehog](https://raw.githubusercontent.com/skyf0xx/hedgehog/master/badges/kofi-top.svg)](https://ko-fi.com/skyf0xx)
 
 AI can write code in seconds.
 
@@ -42,6 +43,7 @@ Hedgehog combines:
 - **TDD and progressive layering** — build one tested layer at a time
 - **Mechanical enforcement** — use tooling and phase gates instead of trusting the AI to follow instructions
 - **Small context loops** — keep every change focused, verifiable, and easy to review
+- **Deterministic scaffolding** — generate boilerplate and schemas instead of asking the AI to write it freehand
 
 Software that stays structured as it grows.
 
@@ -138,7 +140,7 @@ Artifact
 
 ### Anything else
 
-A CLI, a library, a browser extension, a data pipeline, etc. fitting neither shape gets its own build order, designed at intake rather than chosen from a menu — starting from a [battle-tested blueprint](src/skills/hedgehog-core-design/blueprints) for the system's shape where one exists.
+A CLI, a library, a browser extension, a data pipeline, etc. fitting neither shape gets its own build order, designed at intake rather than chosen from a menu — starting from a battle-tested blueprint (in [`hedgehog-core-authored`](https://github.com/skyf0xx/hedgehog-core-authored)'s `hedgehog-core-design` skill) for the system's shape where one exists.
 
 Run `init` with no core flag: planning intake names the system shape, picks
 the stack, derives the layers, and locks them to `.hedgehog/core.yaml`,
@@ -195,17 +197,6 @@ npx @skyf0xx/hedgehog update
 
 This refreshes the installed agents and skills in a specific repo (note, not vendor skills)
 
-### Installing a specific core
-
-Naming a core up front installs it with the shared payload. Without one, `init` installs the shared payload alone and leaves the choice to planning intake, where `planner` selects a core — `full-stack-app`, `landing-page`, or one it designs for the project:
-
-``` bash
-npx @skyf0xx/hedgehog init --core full-stack-app
-npx @skyf0xx/hedgehog cores list   # every core this release can install, and what each is for
-```
-
-Each named core ships as its own npm package (`@skyf0xx/hedgehog-core-full-stack-app`, `@skyf0xx/hedgehog-core-landing-page`); `init` fetches the version `src/registry/cores.json` names and caches it locally, so a repeat install on the same version needs no network.
-
 ## Why Hedgehog
 
 Most AI coding tools improve prompting.
@@ -253,6 +244,8 @@ pnpm-only workspace convention.
 
 ## Support Hedgehog
 
-If Hedgehog helps you build better software with AI, give it a ⭐ on GitHub.
+If Hedgehog helps you build better software with AI, **give it a ⭐ on GitHub**, or [buy me a coffee on Ko-fi](https://ko-fi.com/skyf0xx).
 
-[![GitHub stars](https://img.shields.io/github/stars/skyf0xx/hedgehog?style=social)](https://github.com/skyf0xx/hedgehog/stargazers)
+[![GitHub stars](https://raw.githubusercontent.com/skyf0xx/hedgehog/master/badges/github-stars.svg)](https://github.com/skyf0xx/hedgehog/stargazers)
+[![Total downloads](https://raw.githubusercontent.com/skyf0xx/hedgehog/master/badges/npm-downloads.svg)](https://www.npmjs.com/package/@skyf0xx/hedgehog)
+[![Support Hedgehog](https://raw.githubusercontent.com/skyf0xx/hedgehog/master/badges/kofi.svg)](https://ko-fi.com/skyf0xx)

package/bin/cli.mjs

@@ -5,6 +5,7 @@
 // Usage:
 //   npx @skyf0xx/hedgehog init                        install; planner picks the core at intake
 //   npx @skyf0xx/hedgehog init --ts-full-stack-app     scaffold the full-stack-app core now
+//   npx @skyf0xx/hedgehog init --pwa-app               scaffold the pwa-app core now
 //   npx @skyf0xx/hedgehog init --landing-page          scaffold the landing-page core now
 //   npx @skyf0xx/hedgehog init --cursor                install for Cursor (default: Claude Code)
 //   npx @skyf0xx/hedgehog init --all-hosts             install for every supported coding agent
@@ -36,6 +37,7 @@ import {
   releaseTask,
   renewLease,
   retryTask,
+  reapExpiredLeases,
 } from '../src/db/claim.mjs';
 import { readyTasks, formatReady } from '../src/db/ready.mjs';
 import { graphStatus, formatStatus } from '../src/db/status.mjs';
@@ -104,7 +106,7 @@ const DOTFILE_RENAMES = { 'gitignore.template': '.gitignore' };
 
 // Build artifacts that must never be copied into a consuming project,
 // even if a future publish accidentally includes them: the full-stack-app
-// golden core documents that `node_modules` is regenerated by `pnpm
+// core documents that `node_modules` is regenerated by `pnpm
 // install` in step 4, not shipped, and a platform-specific `node_modules`
 // snapshot from the publisher's machine can be stale or broken for
 // everyone else (e.g. a dangling optional-dependency symlink).
@@ -148,7 +150,7 @@ async function namedCore(args) {
 // which core applies left for `planner` to decide. `bootstrap` lands the
 // core workspace and fills the CLAUDE.md section for whichever core
 // `planner` picks — the first time either way. An explicit flag
-// (`--ts-full-stack-app`, `--landing-page`) is a confirmed choice, so it
+// (`--ts-full-stack-app`, `--pwa-app`, `--landing-page`) is a confirmed choice, so it
 // scaffolds that workspace immediately, at install time.
 //
 // A core is passed in as `{ manifest, root }` from fetchCore — the parsed
@@ -482,6 +484,7 @@ ${bold('Usage')}
   npx @skyf0xx/hedgehog init                      install; planner picks the core at intake
   npx @skyf0xx/hedgehog init --core <name>        install that core now, by name
   npx @skyf0xx/hedgehog init --ts-full-stack-app  scaffold the full-stack-app core now
+  npx @skyf0xx/hedgehog init --pwa-app            scaffold the pwa-app core now
   npx @skyf0xx/hedgehog init --landing-page       scaffold the landing-page core now
   npx @skyf0xx/hedgehog cores list                every core this release can install
   npx @skyf0xx/hedgehog init --cursor             install for Cursor (default: Claude Code)
@@ -811,7 +814,7 @@ async function update({ hosts }) {
 // refresh.
 const UNRESOLVED = Symbol('unresolved core');
 
-// A root `core.yaml` is a Golden Core's own file: `corePayload` lands it
+// A root `core.yaml` is a core's own file: `corePayload` lands it
 // as part of that core's `workspace` at install time, so its presence is
 // direct evidence a core package's files are on disk — independent of
 // `.hedgehog/core.yaml`, the authored-core path, which is a different
@@ -928,7 +931,7 @@ async function dbCommand(args) {
 }
 
 // Resolves the project's core definition: an authored .hedgehog/core.yaml
-// takes precedence (spec: "Authored cores"); otherwise the Golden Core's
+// takes precedence (spec: "Authored cores"); otherwise the core's
 // own core.yaml, which lands at repo root along with the rest of that
 // core package's workspace. Neither exists yet on a deferred install
 // (plain `init`, no core named) until `bootstrap` runs — this returns
@@ -1222,7 +1225,9 @@ async function intentCommand(args) {
   try {
     intent = await addIntent(db, record);
   } catch (err) {
-    console.error(`${red('Failed to add intent:')} ${err.message}\n`);
+    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`,
+    );
     process.exitCode = 1;
     return;
   } finally {
@@ -2062,6 +2067,12 @@ async function statusCommand() {
   const db = openDb();
   let result;
   try {
+    // A task whose lease expired with no intervening `claim`/`verify`
+    // call is still sitting in `building`/`verifying` in the DB —
+    // without this, status keeps reporting a dead agent's task as
+    // in-flight indefinitely, and `hedgehog retry` refuses it as "not
+    // blocked" until some other command happens to reap it first.
+    reapExpiredLeases(db);
     result = graphStatus(db, { core, overrides });
   } finally {
     db.close();
@@ -2136,6 +2147,7 @@ async function quiesceCommand() {
   const db = openDb();
   let inFlight;
   try {
+    reapExpiredLeases(db);
     ({ inFlight } = graphStatus(db));
   } finally {
     db.close();
@@ -2612,7 +2624,9 @@ async function debtCommand(args) {
     try {
       entry = addDebt(db, { taskId, note });
     } catch (err) {
-      console.error(`${red('Failed to declare debt:')} ${err.message}\n`);
+      console.error(
+        `${red('Failed to declare debt:')} ${err.message}\n\nRun ${bold('hedgehog status')} to see valid task ids.\n`,
+      );
       process.exitCode = 1;
       return;
     } finally {
@@ -2698,6 +2712,10 @@ async function main() {
     await help();
     return;
   }
+  if (args.includes('--version') || args.includes('-v')) {
+    console.log(PKG_VERSION);
+    return;
+  }
   const cmd = args[0];
   const force = args.includes('--force') || args.includes('-f');
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@skyf0xx/hedgehog",
-  "version": "5.0.0",
+  "version": "5.1.0",
   "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

@@ -89,26 +89,85 @@ A core whose `when` fits and whose `flag` is listed is chosen by name
 and handed to `bootstrap`, which installs that core's package and
 follows the bootstrap skill it ships.
 
-Data that gets stored is `full-stack-app`, at any size: a todo list, a
-notes app, a tracker of any kind. Never talk the user down to
-browser-local storage, an in-memory array, or a single-file page because
-the app sounds small, and never offer that as a quicker start — the core
-ships a real database, and reaching for less is the drift this
-discipline exists to prevent.
+**Before matching against `when` paragraphs, ask up to three
+clarifying questions if the description alone doesn't already settle
+them.** Most users describing a project for the first time are not
+naming their own architecture — they're naming what the thing does —
+so this step exists to pull out the handful of facts that actually
+distinguish one core's `when` from another's, in the same plain
+language the user already used, not in the vocabulary of the cores
+themselves. Skip a question outright whenever the description already
+answers it; skip the whole step when the description is unambiguous
+(a landing page with no state, an obvious full-stack SaaS with several
+described entities and accounts) — this is a gap-filler, not a
+mandatory interview. Never exceed three, and never ask more than one
+at a time if the conversation is turn-by-turn.
+
+The three questions this step exists for, asked as an engineer
+eliciting requirements would ask them, never as an architecture quiz
+the user can't answer without already knowing the answer:
+
+- **Where does the data really need to live?** — "does this need to
+  work on one device, or be the same for you across your phone and
+  laptop, or shared with other people?" Distinguishes `pwa-app`
+  (single-device or a small, known set of people) from `full-stack-app`
+  (a system other people or services interact with independently) —
+  never phrase this as "will your app have a full API backend," which
+  assumes the answer.
+- **Is there ongoing behavior, or just a page?** — "once it's built,
+  does anything keep happening on its own — reminders, scheduled
+  updates, other people's actions showing up — or is it something you
+  open and use?" Distinguishes `landing-page` (nothing ongoing, no
+  state of its own) from either app core.
+- **Is this a one-time thing, or a real, evolving artifact?** — "is
+  this a one-off script or document, or something you'll keep coming
+  back to and adding to?" Separates "nothing to build here" and
+  "authored core" from the shipped cores above.
+
+Answers here are inputs to the `when`-paragraph match below, not a
+replacement for it — don't skip reading every core's `when` just
+because a question landed on a name. State which questions you're
+asking and why in one line each, so the user can see this is
+narrowing a real ambiguity rather than a rote checklist. This step
+never runs on re-entry (Phase 0 as a whole is skipped there) and never
+substitutes for `hedgehog-planning-intake`'s own elicitation once a
+core is chosen — that's a full BMAD-driven pass; this is three
+questions to pick which pass to run.
+
+Data that gets stored is not, by itself, `full-stack-app` — that used to
+be the rule, and it swallowed every candidate for `pwa-app` (a tracker,
+journal, notebook, or planner whose data belongs on the user's own
+device). The real question is where the data lives and who needs to
+enforce the rules around it. A description naming a local-first app —
+offline capability or installability named explicitly is a strong
+signal — is `pwa-app`, even with sharing, accounts, or multi-device sync
+in scope (Dexie Cloud covers that), and even with a small number of
+entities that must be server-authoritative (those go `--remote`, backed
+by Supabase, without moving the whole project off `pwa-app`). What
+routes a project to `full-stack-app` instead is server-side logic across
+*most* of the app: authorization more expressive than per-object
+row-level security, background jobs or webhooks as the app's primary
+function, server-rendered or SEO-critical pages, or a working set too
+large for a device. Never talk the user down to browser-local storage
+for `full-stack-app` shape sounding small, and never talk them up to a
+server for `pwa-app` shape sounding real — the core ships a real
+database either way, and picking the wrong one because of what a core
+"sounds like" is the drift this discipline exists to prevent.
 
 This is a distinct question from project *size*. A single-table, single-
-user tool (one person's task list, a personal habit tracker) is still
-`full-stack-app`, scoped through the Add-ons decision, not routed to
-landing-page for being small. Likewise a landing page with a dozen
-sections is still `landing-page`, not promoted to `full-stack-app` for
-being long. Shape decides the core; size decides nothing.
+user tool (one person's task list, a personal habit tracker) fits
+`pwa-app` if its data is local, or `full-stack-app` scoped through the
+Add-ons decision if it isn't — size alone decides neither. Likewise a
+landing page with a dozen sections is still `landing-page`, not promoted
+to `full-stack-app` for being long. Shape decides the core; size decides
+nothing.
 
 Three outcomes are decided here rather than in the registry, because
 none of them is a description matching a `when` paragraph:
 
 - **Neither shipped core fits, but something is being built** — the
   description names a real artifact a Builder step would produce, just
-  not in either Golden Core's shape. This project gets an **authored
+  not in either shipped core's shape. This project gets an **authored
   core**, designed by you and written to `.hedgehog/core.yaml`. Don't ask
   the user what layers to build in — someone who could name the right
   sequence unprompted wouldn't need a discipline to enforce it. Run
@@ -118,7 +177,7 @@ none of them is a description matching a `when` paragraph:
   archive: it names the system shape, picks the stack, derives the
   layers, decides the module axis, and writes `.hedgehog/core.yaml` plus
   its rationale at its own Confirm & Lock. An authored core is a weaker
-  guarantee than a Golden Core (the sequence was designed for this
+  guarantee than a shipped core (the sequence was designed for this
   project, not battle-tested across many) but carries the same
   enforcement — ordered layers, scoped file access, verification before
   completion — and the loader has no leniency for it
@@ -143,7 +202,7 @@ none of them is a description matching a `when` paragraph:
   everything above: it's not about which core fits new work, because no
   new workspace gets built at all. Route straight to `hedgehog-adopt` —
   bootstrap and every other Phase 0 outcome are skipped entirely, since
-  there is no workspace to scaffold and no golden stack to adopt toward.
+  there is no workspace to scaffold and no shipped stack to adopt toward.
   `hedgehog-adopt` runs its own read-only intake and writes its own
   `.hedgehog/core.yaml`; don't run `hedgehog-planning-intake`'s BMAD shelf
   first — the drivers that skill elicits (persistence, stack, deployment
@@ -174,6 +233,15 @@ the first-run shape; on re-entry, run `hedgehog-planning-intake`'s
   Hedgehog's own build discipline."* BMAD elicits and produces planning
   documents; it has no execution discipline of its own — Hedgehog starts
   where BMAD's output ends.
+- **`pwa-app`** → open `hedgehog-planning-intake` and follow it in full,
+  exactly as `full-stack-app` does: Phase 0 runs the same vendored BMAD
+  shelf, archived to `.hedgehog/BMAD/`; Phase 1 mines `04-prd.md` into
+  intent records the same way, one domain module per PRD Feature; the
+  same Confirm & Lock stage is the hard stop before anything gets
+  written. State the same BMAD attribution as full-stack-app before that
+  Phase 0 begins. The one addition: this core's own Add-ons-equivalent
+  decision (sync, remote entities — see below) instead of
+  full-stack-app's Auth/Queue/Mobile.
 - **`landing-page`** → open `hedgehog-landing-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,
@@ -190,9 +258,9 @@ the first-run shape; on re-entry, run `hedgehog-planning-intake`'s
   `hedgehog-planning-intake`.
 
 Either way, this is the mechanical procedure; the judgment — what's
-actually in scope, where a table becomes a module (full-stack-app) or
-what the page's single job actually is (landing-page) — stays yours
-throughout.
+actually in scope, where a table becomes a module (full-stack-app,
+pwa-app) or what the page's single job actually is (landing-page) —
+stays yours throughout.
 
 ## The Add-ons decision (full-stack-app only)
 
@@ -246,6 +314,42 @@ differently. Written once at Phase 1; a later run (new scope entering
 play) only edits it if new scope genuinely changes a trigger (e.g.
 accounts get added where there were none).
 
+## The sync/remote-entities decision (pwa-app only)
+
+Two independent booleans, the `pwa-app` counterpart to full-stack-app's
+Add-ons decision above — same mechanism (`.hedgehog/addons.yaml`, decided
+once while mining `04-prd.md`, shown at Confirm & Lock), different
+triggers, since this core has no Auth/Queue/Mobile infra to decide:
+
+- **Sync** — on if the PRD describes more than one user or more than one
+  device sharing the same data (a shared list, a two-person journal, a
+  small team's board) — Dexie Cloud, wired by this core's bootstrap skill.
+- **Remote entities** — on if the PRD names at least one entity a client
+  must not be able to write to directly (a points balance, a reward
+  ledger, anything server-arbitrated) — Supabase, wired the same way.
+  This is a project-wide bootstrap decision (whether the Supabase client
+  gets wired at all); *which* entities are generated `--remote` is a
+  later, per-entity, build-time choice, not decided here.
+
+Infer first, gap-fill second, same discipline as the Add-ons decision:
+"is this used by more than one person, or shared across your own
+devices?" for sync, "is there any balance or record here a user
+shouldn't be able to edit directly?" for remote entities. A "no" is a
+resolved answer. Neither disqualifies `pwa-app` as the core — see Phase
+0 above — they only decide what bootstrap wires.
+
+```yaml
+sync:
+  on: true
+  reason: shared list, two members
+remote_entities:
+  on: false
+  reason: no server-authoritative entity in scope
+```
+
+A project can take either, both, or neither — independent booleans, same
+as full-stack-app's Auth/Queue/Mobile trio.
+
 ## Core Responsibilities
 
 - Decide which core applies before running any planning-intake skill —
@@ -256,6 +360,10 @@ accounts get added where there were none).
   artifacts; the
   intent records Phase 1 writes via `hedgehog intent add` live in the
   build graph, not a file this agent owns.
+- **pwa-app**: same shape as full-stack-app — owns `.hedgehog/BMAD/` and
+  `.hedgehog/addons.yaml` (sync, remote entities, per "The sync/
+  remote-entities decision" above) as artifacts; intent records live in
+  the build graph.
 - **landing-page**: owns `.hedgehog/BMAD/` and
   `.hedgehog/chain/00-brief.md` as artifacts.
 - **brownfield adoption**: owns nothing here — `hedgehog-adopt` owns
@@ -294,7 +402,9 @@ accounts get added where there were none).
 
    Read the commit log alongside it for what's already built —
    full-stack-app: `feat(<module>): api` commits and each task's status in
-   the graph mark modules with a closed Phase A. Landing-page: a
+   the graph mark modules with a closed Phase A. pwa-app: `feat(<module>):
+   screen` commits and each task's status mark a module's closed
+   sequence, per its own five-layer `core.yaml`. Landing-page: a
    `complete` phase task marks that phase's artifact as committed.
    Authored core: each `complete` task marks that layer committed, per
    `.hedgehog/core.yaml`'s own commit messages. On re-entry this is what
@@ -319,6 +429,9 @@ accounts get added where there were none).
      the user directly only for whatever the PRD leaves unresolved. The
      mining step is the same either way; only how the archive was
      produced differs.
+   - **First run, pwa-app**: identical procedure to full-stack-app above,
+     substituting the sync/remote-entities decision for the Add-ons
+     decision.
    - **First run, landing-page**: run the same vendored BMAD shelf in
      full, then mine `.hedgehog/BMAD/` into a draft subject statement
      (subject, audience, single page job) — asking the user directly only
@@ -328,7 +441,8 @@ accounts get added where there were none).
      only what's new — the BMAD shelf does not run again.
 6. **Run the matching Confirm & Lock** before writing anything — the
    first-run stage on a first run, the extension variant on re-entry.
-7. **Write the intent records**: full-stack-app writes each intent via
+7. **Write the intent records**: full-stack-app and pwa-app each write
+   every intent via
    `hedgehog intent add`, one call per PRD Feature (per new module, on
    re-entry), plus `.hedgehog/addons.yaml`; landing-page writes
    `.hedgehog/chain/00-brief.md` per its own Confirm & Lock, in the shape
@@ -344,8 +458,8 @@ accounts get added where there were none).
    `chore(planning): intake` on a first run, `chore(planning): extend
    scope` on re-entry, so the passes are distinguishable in the log. It
    carries the committed `.hedgehog/hedgehog.db` (its new intent and task
-   rows), `.hedgehog/addons.yaml` (full-stack-app only, and on re-entry
-   only if a trigger actually changed), this core's own archival planning
+   rows), `.hedgehog/addons.yaml` (full-stack-app and pwa-app only, and on
+   re-entry only if a trigger actually changed), this core's own archival planning
    output (`.hedgehog/BMAD/` or `.hedgehog/chain/`, first run only), the
    authored core's `.hedgehog/core.yaml` and `.hedgehog/core-design.md` if
    step 4 ran, and root `CLAUDE.md`'s filled placeholders (first run
@@ -354,8 +468,9 @@ accounts get added where there were none).
    intake's own unit of work, landed before `bootstrap` touches anything.
 9. **First run only, and not on the brownfield path — hand off to the
    `bootstrap` agent** once the commit lands. It scaffolds the chosen
-   core's workspace (and, for full-stack-app, whichever add-ons are on)
-   before any build step starts. On re-entry on any other core the
+   core's workspace (and, for full-stack-app, whichever add-ons are on;
+   for pwa-app, whichever of sync/remote entities is on) before any build
+   step starts. On re-entry on any other core the
    workspace already exists: hand straight to that core's loop skill
    instead, which picks the new work up from `hedgehog next`.
 10. **Return a summary**: which core (naming it as authored or adopted,
@@ -365,8 +480,9 @@ accounts get added where there were none).
 ## Constraints
 
 - Never write or modify application code. Read-only against the
-  codebase; you may write `.hedgehog/addons.yaml` (full-stack-app only —
-  see "The Add-ons decision" below), `.hedgehog/core.yaml` and
+  codebase; you may write `.hedgehog/addons.yaml` (full-stack-app and
+  pwa-app only — see "The Add-ons decision" and "The sync/remote-entities
+  decision" below), `.hedgehog/core.yaml` and
   `.hedgehog/core-design.md` (authored cores only, via
   `hedgehog-core-design`), `.hedgehog/core.yaml` and
   `.hedgehog/adoption.md` (brownfield adoption only, via
@@ -378,7 +494,7 @@ accounts get added where there were none).
   `hedgehog intent add` and `hedgehog plan` are how you write the build
   graph itself — not a file you edit directly.
 - On the brownfield path, never route toward converting the host repo's
-  existing stack, structure, or conventions toward any Golden Core's —
+  existing stack, structure, or conventions toward any shipped core's —
   not even as a suggestion. `hedgehog-adopt` designs `verify` commands
   and layer order around what the repo already uses; it doesn't propose
   Nx, Drizzle, or any other opinionated choice a shipped core would make.

package/src/db/claim.mjs

@@ -373,6 +373,13 @@ export function claimTask(db, taskId, { owner, leaseMinutes = 45 }) {
 // would — still subject to its dependencies being complete.
 export function retryTask(db, taskId) {
   return inTransaction(db, () => {
+    // Same reason verifyTask reaps before its own status check: a task
+    // whose lease expired with no intervening `claim` call is still
+    // sitting in `building`/`verifying` here, not yet swept to `blocked`
+    // — without this, retry on that task reads "not blocked" and refuses,
+    // even though the lease is in fact dead and this is exactly the
+    // situation retry exists to recover from.
+    reapExpiredLeases(db);
     const task = loadTask(db, taskId);
     if (task === undefined) return { retried: false, reason: 'no_such_task' };
     if (task.status !== 'blocked') return { retried: false, reason: 'not_blocked', task };

package/src/db/core.mjs

@@ -1,4 +1,4 @@
-// Core-definition loader. Parses `core.yaml` — a Golden Core's own shipped
+// Core-definition loader. Parses `core.yaml` — a shipped core's own
 // definition, or an authored .hedgehog/core.yaml — into the same in-memory
 // shape either way. See hedgehog-persistent-build-graph.md, "Core
 // definitions".

package/src/hosts/capabilities.mjs

@@ -19,6 +19,7 @@ export const AGENT_CAPABILITY = {
   'landing-executor': 'full',
   'layer-eng': 'full',
   planner: 'full',
+  'pwa-eng': 'full',
   tweaker: 'full',
 
   // Author artifacts, but never run commands.

package/src/hosts/cursor/DISPATCH.md

@@ -5,6 +5,9 @@ one, read its file and follow it for that task, passing the `hedgehog
 next` packet in full. Where a subagent is available, pass the file's
 entire body as that subagent's prompt — the file is the role.
 
+Independent steps can go out as several concurrent tool calls in one
+response. Steps that depend on each other stay sequential.
+
 Each agent file opens with the tools that role may use. Honor it: Cursor
 grants tools per session, so the constraint is yours to keep. `hedgehog
 verify` checks the touched files against the packet's ALLOWED SCOPE and

package/src/registry/cores.json

@@ -7,7 +7,16 @@
       "version": "^1.0.0",
       "language": "typescript",
       "repository": "https://github.com/skyf0xx/hedgehog-core-full-stack-app",
-      "selects_when": "The description names persistent domain data with its own lifecycle: something that gets created, changes state, gets queried back later, or needs accounts/auth, background jobs, or a real app beyond a single page. Data that gets stored is this core at any size — a todo list, a notes app, a tracker of any kind — never talked down to browser-local storage or a single-file page for sounding small. 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."
+      "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."
+    },
+    {
+      "name": "pwa-app",
+      "flag": "--pwa-app",
+      "package": "@skyf0xx/hedgehog-core-pwa-app",
+      "version": "^1.0.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."
     },
     {
       "name": "landing-page",
@@ -24,7 +33,7 @@
       "version": "^1.0.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 Golden 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 Golden Core — ordered layers, scoped file access, verification before completion — but the sequence is designed for this project rather than battle-tested across many."
+      "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."
     }
   ]
 }

package/src/registry/index.mjs

@@ -1,6 +1,6 @@
 // Core package registry. One entry per Hedgehog core — full-stack-app,
 // landing-page, authored — naming the npm package that ships its agents,
-// skills, and (for the two Golden Cores) scaffold, plus the CLI flag
+// skills, and (for the two shipped cores) 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.

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

@@ -1,24 +1,25 @@
 ---
 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 decision) is full-stack-app's own procedure. Phase 0 also defines compressed intake, the path a user's explicit "just build it" choice takes on full-stack-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, 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. 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
 
 Turns a person's description of a problem into planning material, by
-running the vendored BMAD-METHOD planning shelf (Phase 0, shared by both
-cores) and mining its output. On full-stack-app that mining is this
-skill's own Phase 1, into intent records written via `hedgehog intent
+running the vendored BMAD-METHOD planning shelf (Phase 0, shared by
+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
 `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 `hedgehog-landing-loop` (landing-page's own mining)
-are the fixed procedures that judgment runs inside.
+full-stack-app and pwa-app) and `hedgehog-landing-loop` (landing-page'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,
+enters play later on a core with a module axis (full-stack-app, pwa-app,
 authored), `planner` runs the **Re-entry pass** at the end of this file
 instead: it reads the existing archive as context and elicits only what's
 new, adding intents to a graph that keeps everything already built.
@@ -98,7 +99,7 @@ states the source repo, pinned version (`vendor-skills/BMAD/ATTRIBUTION.md` has
 the pinned commit), date, which intake mode ran (`full`, below, or
 `compressed`), and which skills ran.
 
-### Compressed intake (full-stack-app, authored core)
+### Compressed intake (full-stack-app, pwa-app, authored core)
 
 A user who opens with "just build it" — no clarifying questions — is
 asking for something Phase 0's live elicitation can't give them.
@@ -120,11 +121,13 @@ compressing the elicitation removes the thing the chain audits against.
 A "just build it" landing-page request is a conflict to surface, not a
 mode to switch into.
 
-**The Add-ons decision is what the batched round is for.** Auth, Queue,
-and Mobile must each be *answered* — inferred from a concrete trigger in
-the user's brief, or asked directly in that one round. Compressed intake
-compresses BMAD's elicitation, never `planner`'s gate; an add-on left as
-a guess is the same error here as on a full run.
+**The Add-ons decision (or, on pwa-app, the sync/remote-entities
+decision) is what the batched round is for.** Auth, Queue, and Mobile
+(full-stack-app) or sync and remote entities (pwa-app) must each be
+*answered*: inferred from a concrete
+trigger in the user's brief, or asked directly in that one round.
+Compressed intake compresses BMAD's elicitation, never `planner`'s gate;
+a boolean left as a guess is the same error here as on a full run.
 
 Write the manifest and the PRD always, and the experience spec where the
 brief gives it something to say — at the same path and in the same
@@ -174,11 +177,12 @@ drivers, and that's the user's call to accept there.
 Nothing in `hedgehog-loop`'s day-to-day operation, `hedgehog-bootstrap`,
 or `reviewer` reads this folder live — `planner` reads it exactly once,
 right after the shelf completes, to mine it (this skill's Phase 1 below
-on full-stack-app; `hedgehog-landing-loop`'s planning-intake section on
+on full-stack-app and pwa-app; `hedgehog-landing-loop`'s planning-intake
+section on
 landing-page). After that it's historical record only, the same
 relationship the commit log has to a merged PR.
 
-## Phase 1 — Mining (full-stack-app only)
+## Phase 1 — Mining (full-stack-app, pwa-app)
 
 landing-page's counterpart to this Phase 1 is
 `hedgehog-landing-loop`'s own planning-intake section, run once Phase 0
@@ -211,7 +215,8 @@ Procedure:
    description across the two if it names both the capability and the
    result; otherwise the same sentence can serve both).
 
-   On a module-axis core (`full-stack-app`, and any authored core whose
+   On a module-axis core (`full-stack-app`, `pwa-app`, and any authored
+   core whose
    layers scope by `{module}`), **name the id plural** — `tasks`, not
    `task`; `order-items`, not `order-item`. The id is substituted as
    `{module}` into every layer's scope glob and verify command, and the
@@ -238,8 +243,10 @@ Procedure:
    holding the foreign key depends on the intent for the entity it
    references. A relationship entirely inside one Feature's entities
    produces no row — it's already the same intent.
-5. **Run the Add-ons decision** (`planner`'s own judgment call — see that
-   agent's "The Add-ons decision") for Auth, Queue, and Mobile.
+5. **Run this core's Add-ons-equivalent decision** (`planner`'s own
+   judgment call): full-stack-app's "The Add-ons decision" (Auth, Queue,
+   Mobile), or pwa-app's "The sync/remote-entities decision" (sync,
+   remote entities) — see that agent.
 6. **Run Confirm & Lock** (below) before writing anything.
 7. **Write each intent via `hedgehog intent add`** — one invocation per
    Feature: `--acceptance` per row from step 2, `--rule` per row from step
@@ -247,7 +254,7 @@ Procedure:
    <path.json>` batch matching the same shape (`{ id, goal, outcome,
    rules, acceptance, depends_on, priority }`). This is Phase 1's only
    write to the build graph.
-8. **Write `.hedgehog/addons.yaml`** with the Add-ons decision from step 5.
+8. **Write `.hedgehog/addons.yaml`** with the decision from step 5.
 9. **Fill root `CLAUDE.md`'s `{{PROJECT_NAME}}` and `{{PROJECT_SUMMARY}}`
    placeholders**, first run only, then delete the installer's HTML
    comment block at the top of that file. Leave every other line
@@ -266,8 +273,9 @@ stops being true, so it's a hard stop, not a recap in passing.
 
 - Each intent about to be added: `id`, `goal`, `outcome`, its
   `requirements` (rule/acceptance), and its `depends_on` list.
-- The Add-ons decision (Auth / Queue / Mobile, each explicitly on or
-  off, with the one-line reason).
+- This core's Add-ons-equivalent decision, each boolean explicitly on or
+  off with the one-line reason (Auth / Queue / Mobile on full-stack-app;
+  sync / remote entities on pwa-app).
 - Which intake mode ran, and on a full run which BMAD skills ran — or,
   on a compressed run, what the batched round asked and what was inferred
   from the brief without asking. Either way, where the output lives
@@ -276,7 +284,7 @@ stops being true, so it's a hard stop, not a recap in passing.
 Then state plainly what happens on confirmation, before it happens:
 
 > This writes each intent above via `hedgehog intent add` and the
-> Add-ons decision to `.hedgehog/addons.yaml`, then shows the compiled
+> decision above to `.hedgehog/addons.yaml`, then shows the compiled
 > graph with `hedgehog status`. Phase A build (schema first) starts on
 > the first ready task once that closes. Anything wrong or missing — say
 > so now; it's a normal edit before this point, and a Correction Protocol
@@ -288,7 +296,7 @@ the confirmation holds. Once confirmed, after every `hedgehog intent add`
 call lands, run `hedgehog status` and show it in full as the graph's
 confirmation view.
 
-## Re-entry pass — new scope on an existing project (full-stack-app, authored core)
+## Re-entry pass — new scope on an existing project (full-stack-app, pwa-app, authored core)
 
 Runs when `planner`'s Workflow step 2 finds intents already in the graph,
 on a core with a module axis to add an intent to: new scope entering play
@@ -321,8 +329,8 @@ their commits.
 3. **Elicit only what's new.** A short, scoped set of questions — not a
    full interview:
    - What is the new scope, in the project's own vocabulary?
-   - Which entities/tables does it introduce? On full-stack-app each
-     table is its own module, same rule as Phase 1.
+   - Which entities/tables does it introduce? On full-stack-app and
+     pwa-app each table is its own module, same rule as Phase 1.
    - What does it depend on that already exists? Each answer becomes a
      `--depends-on` onto an existing intent.
    - What has to be true for it to be done? Each answer becomes an
@@ -334,10 +342,13 @@ their commits.
    If the answers reveal this isn't new scope at all but a change to
    something already built, stop: that's the Correction Protocol, not an
    extension.
-4. **Check whether any add-on trigger actually changed** (full-stack-app).
-   Usually none has. Only if the new scope genuinely introduces one — the
-   first accounts in a project that had none, the first long-running job —
-   edit `.hedgehog/addons.yaml`, and say plainly that turning an add-on on
+4. **Check whether any boolean trigger actually changed**
+   (full-stack-app's Add-ons, or pwa-app's sync/remote-entities). Usually
+   none has. Only if the new scope genuinely introduces one — the
+   first accounts in a project that had none, the first long-running job,
+   the first shared device on a pwa-app project, the first entity that
+   must be server-authoritative —
+   edit `.hedgehog/addons.yaml`, and say plainly that turning a boolean on
    after bootstrap needs its Bootstrap step run before anything depends on
    it. Never rewrite root `CLAUDE.md`'s `{{PROJECT_NAME}}`/
    `{{PROJECT_SUMMARY}}` placeholders here; they describe the project,