@skyf0xx/hedgehog 4.3.0 → 4.3.4

package/src/golden-cores/full-stack-app/tools/generators/fields.ts

@@ -7,6 +7,13 @@
  * Wire format (the `--fields` option): a comma-separated list of
  * `name:type` pairs, with a trailing `?` on the type marking the column
  * nullable — `title:string,done:boolean,dueDate:timestamp?`.
+ *
+ * A `string` takes an optional length in parentheses —
+ * `title:string(500)`, or `title:string(500)?` when it is also nullable.
+ * The value threads to both the Drizzle `varchar` and the Zod `.max()`,
+ * so the two bounds are the same number by construction: a Zod bound that
+ * outran its column would let an over-long value past validation and fail
+ * at the driver as a 500 instead of a 400.
  */
 
 export type FieldType =
@@ -20,8 +27,13 @@ export interface Field {
   name: string;
   type: FieldType;
   nullable: boolean;
+  /** Max characters for a `string`; undefined on every other type. */
+  length?: number;
 }
 
+/** The `varchar` bound a `string` gets when the field list names none. */
+export const DEFAULT_STRING_LENGTH = 255;
+
 const FIELD_TYPES: readonly FieldType[] = [
   'string',
   'text',
@@ -43,18 +55,35 @@ export function parseFields(raw: string): Field[] {
         );
       }
       const nullable = rawType.endsWith('?');
-      const type = (nullable ? rawType.slice(0, -1) : rawType) as FieldType;
+      const bare = nullable ? rawType.slice(0, -1) : rawType;
+
+      const sized = /^(\w+)\((\d+)\)$/.exec(bare);
+      const type = (sized ? sized[1] : bare) as FieldType;
+      const length = sized ? Number(sized[2]) : undefined;
+
       if (!FIELD_TYPES.includes(type)) {
         throw new Error(
           `Field "${entry}" has unknown type "${type}". Known types: ${FIELD_TYPES.join(', ')}.`,
         );
       }
+      // A length on anything but `string` has no column to bind to, so it
+      // would be silently dropped — the exact failure mode the syntax
+      // exists to remove. `text` is unbounded by design: cap it and you
+      // want a `string`.
+      if (length !== undefined && type !== 'string') {
+        throw new Error(
+          `Field "${entry}" puts a length on "${type}", which has no length. Only string does (title:string(500)).`,
+        );
+      }
+      if (length !== undefined && length < 1) {
+        throw new Error(`Field "${entry}" has length ${length}; it must be at least 1.`);
+      }
       if (RESERVED_FIELD_NAMES.includes(name)) {
         throw new Error(
           `Field "${name}" collides with a column every table already carries (${RESERVED_FIELD_NAMES.join(', ')}).`,
         );
       }
-      return { name, type, nullable };
+      return { name, type, nullable, length };
     });
 
   if (fields.length === 0) {
@@ -88,10 +117,15 @@ const DRIZZLE_IMPORT: Record<FieldType, string> = {
   timestamp: 'timestamp',
 };
 
+/** The character bound for a `string`, named or defaulted. */
+export function stringLength(field: Field): number {
+  return field.length ?? DEFAULT_STRING_LENGTH;
+}
+
 export function drizzleColumn(field: Field): string {
   const column = `'${columnName(field.name)}'`;
   const base: Record<FieldType, string> = {
-    string: `varchar(${column}, { length: 255 })`,
+    string: `varchar(${column}, { length: ${stringLength(field)} })`,
     text: `text(${column})`,
     boolean: `boolean(${column})`,
     integer: `integer(${column})`,
@@ -116,7 +150,7 @@ export function isDateField(field: Field): boolean {
 /** The Zod schema for a field as it appears in a hand-written override. */
 export function zodSchema(field: Field): string {
   const base: Record<FieldType, string> = {
-    string: 'z.string().min(1).max(255)',
+    string: `z.string().min(1).max(${stringLength(field)})`,
     text: 'z.string()',
     boolean: 'z.boolean()',
     integer: 'z.number().int()',

package/src/golden-cores/full-stack-app/tools/generators/hook/generator.ts

@@ -196,19 +196,29 @@ export function useRemove${entityPascal}() {
     toggleField
       ? `
 
+/**
+ * Sends the id and nothing else. The server reads the current
+ * ${toggleField} and flips it inside one transaction, so a stale row in
+ * this cache cannot overwrite a newer state — which is what computing
+ * the new value here from a cached row would do, losing one of any two
+ * flips that raced.
+ */
 export function useToggle${entityPascal}() {
-  const update = useUpdate${entityPascal}();
-
-  return {
-    ...update,
-    mutate: (variables: { id: string; ${toggleField}: boolean }) =>
-      update.mutate({ id: variables.id, ${toggleField}: !variables.${toggleField} }),
-    mutateAsync: (variables: { id: string; ${toggleField}: boolean }) =>
-      update.mutateAsync({
-        id: variables.id,
-        ${toggleField}: !variables.${toggleField},
-      }),
-  };
+  const queryClient = useQueryClient();
+
+  return useMutation({
+    mutationFn: async (id: string) => {
+      const response = await client.toggle({ params: { id } });
+      if (response.status !== 200) {
+        throw new Error(\`Failed to toggle ${names.entityCamel} \${id}.\`);
+      }
+      return response.body;
+    },
+    onSuccess: (_result, id) => {
+      queryClient.invalidateQueries({ queryKey: ${camel}Keys.lists() });
+      queryClient.invalidateQueries({ queryKey: ${camel}Keys.detail(id) });
+    },
+  });
 }`
       : ''
   }
@@ -266,6 +276,13 @@ describe('${camel} hooks', () => {
     const { useToggle${entityPascal} } = await import('./use-${names.module}');
 
     expect(useToggle${entityPascal}).toBeTypeOf('function');
+  });
+
+  it('routes the toggle at a server endpoint that takes no body', async () => {
+    const { ${camel}Contract } = await import('contracts');
+
+    expect(${camel}Contract.toggle.method).toBe('POST');
+    expect(String(${camel}Contract.toggle.body)).toBe('Symbol(ContractNoBody)');
   });`
       : ''
   }

package/src/golden-cores/full-stack-app/tools/generators/hook/schema.json

@@ -12,7 +12,7 @@
     },
     "toggleField": {
       "type": "string",
-      "description": "A boolean field from the schema layer to expose as a dedicated toggle mutation. Omit when the module has none."
+      "description": "A boolean field from the schema layer to expose as a server-side toggle. Pass the same value to the schema, contract, service, controller, and hook layers. Omit when the module has none."
     }
   },
   "required": ["module"]

package/src/golden-cores/full-stack-app/tools/generators/schema/schema.json

@@ -12,7 +12,7 @@
     },
     "fields": {
       "type": "string",
-      "description": "Comma-separated name:type pairs; a trailing ? marks the column nullable. Types: string, text, boolean, integer, timestamp. Example: title:string,done:boolean,dueDate:timestamp?",
+      "description": "Comma-separated name:type pairs; a trailing ? marks the column nullable, and string takes an optional length in parentheses (default 255). Types: string, text, boolean, integer, timestamp. Example: title:string(500),done:boolean,dueDate:timestamp?",
       "x-prompt": "Fields (name:type, comma-separated)?"
     }
   },

package/src/golden-cores/full-stack-app/tools/generators/service/generator.ts

@@ -4,6 +4,7 @@ import { moduleNames, ModuleNames } from '../naming';
 
 interface ServiceGeneratorOptions {
   module: string;
+  toggleField?: string;
 }
 
 export default async function serviceGenerator(
@@ -22,10 +23,13 @@ export default async function serviceGenerator(
   });
 
   tree.write(`${root}/src/lib/${names.entityKebab}.errors.ts`, errorsFile(names));
-  tree.write(`${root}/src/lib/${names.entityKebab}.service.ts`, serviceFile(names));
+  tree.write(
+    `${root}/src/lib/${names.entityKebab}.service.ts`,
+    serviceFile(names, options.toggleField),
+  );
   tree.write(
     `${root}/src/lib/${names.entityKebab}.service.spec.ts`,
-    serviceSpecFile(names),
+    serviceSpecFile(names, options.toggleField),
   );
   tree.write(`${root}/src/index.ts`, barrelFile(names));
 
@@ -58,7 +62,35 @@ export class ${entityPascal}InvalidStateError extends Error {
 `;
 }
 
-function serviceFile(names: ModuleNames): string {
+/**
+ * The flip is computed from the row this transaction just read, never
+ * from a value the caller supplied: the client has no way to send a
+ * stale one, so two toggles racing against each other serialize into two
+ * flips instead of both writing the same value and losing one.
+ */
+function toggleMethod(names: ModuleNames, toggleField: string): string {
+  const { entityPascal, entityCamel } = names;
+
+  return `
+
+  async toggle${entityPascal}(id: string): Promise<${entityPascal}> {
+    return this.${entityCamel}s.transaction(async (repository) => {
+      const existing = await repository.findById(id);
+      if (!existing) {
+        throw new ${entityPascal}NotFoundError(id);
+      }
+      const updated = await repository.update(id, {
+        ${toggleField}: !existing.${toggleField},
+      } as ${entityPascal}Patch);
+      if (!updated) {
+        throw new ${entityPascal}NotFoundError(id);
+      }
+      return updated;
+    });
+  }`;
+}
+
+function serviceFile(names: ModuleNames, toggleField?: string): string {
   const { entityPascal, entityCamel, entityKebab, module } = names;
 
   return `import type {
@@ -115,12 +147,12 @@ export class ${entityPascal}Service {
     if (!removed) {
       throw new ${entityPascal}NotFoundError(id);
     }
-  }
+  }${toggleField ? toggleMethod(names, toggleField) : ''}
 }
 `;
 }
 
-function serviceSpecFile(names: ModuleNames): string {
+function serviceSpecFile(names: ModuleNames, toggleField?: string): string {
   const { entityPascal, entityCamel, entityKebab } = names;
 
   return `import { describe, expect, it, vi } from 'vitest';
@@ -183,7 +215,51 @@ describe('${entityPascal}Service', () => {
       ${entityPascal}NotFoundError,
     );
   });
-});
+${
+  toggleField
+    ? `
+  it('derives the new ${toggleField} from stored state, not from the caller', async () => {
+    const repository = repositoryDouble({
+      findById: vi.fn(async () => ({ id: 'present', ${toggleField}: true }) as never),
+      update: vi.fn(async (_id, patch) => ({ id: 'present', ...patch }) as never),
+    });
+    const service = new ${entityPascal}Service(repository);
+
+    await service.toggle${entityPascal}('present');
+
+    expect(repository.update).toHaveBeenCalledWith('present', {
+      ${toggleField}: false,
+    });
+    expect(repository.transaction).toHaveBeenCalledOnce();
+  });
+
+  it('flips twice back to the original value, so no flip is lost', async () => {
+    let stored = false;
+    const repository = repositoryDouble({
+      findById: vi.fn(async () => ({ id: 'present', ${toggleField}: stored }) as never),
+      update: vi.fn(async (_id, patch) => {
+        stored = (patch as { ${toggleField}: boolean }).${toggleField};
+        return { id: 'present', ${toggleField}: stored } as never;
+      }),
+    });
+    const service = new ${entityPascal}Service(repository);
+
+    await service.toggle${entityPascal}('present');
+    expect(stored).toBe(true);
+    await service.toggle${entityPascal}('present');
+    expect(stored).toBe(false);
+  });
+
+  it('rejects a toggle against a ${entityCamel} that is not there', async () => {
+    const service = new ${entityPascal}Service(repositoryDouble());
+
+    await expect(service.toggle${entityPascal}('missing')).rejects.toBeInstanceOf(
+      ${entityPascal}NotFoundError,
+    );
+  });
+`
+    : ''
+}});
 `;
 }
 

package/src/golden-cores/full-stack-app/tools/generators/service/schema.json

@@ -9,6 +9,10 @@
       "description": "Domain module name, plural kebab-case (e.g. tasks, order-items).",
       "$default": { "$source": "argv", "index": 0 },
       "x-prompt": "Domain module name (plural kebab-case)?"
+    },
+    "toggleField": {
+      "type": "string",
+      "description": "A boolean field from the schema layer to expose as a server-side toggle. Pass the same value to the schema, contract, service, controller, and hook layers. Omit when the module has none."
     }
   },
   "required": ["module"]

package/src/skills/hedgehog-bootstrap-full-stack-app-core/SKILL.md

@@ -136,6 +136,32 @@ runtime `fs.readdirSync` scan for sibling files would find nothing in the
 built output even though the same scan works when Vitest runs the same
 source directly. Generating literal imports keeps both paths identical.
 
+## The route index
+
+`apps/web/src/app/page.tsx` is the same category of file on the web side,
+and gets the same answer. The screen layer's scope is
+`apps/web/src/app/{module}/**`, module-disjoint and — by the same
+`validateCore` rule — unable to be widened to reach one level up, so the
+root page is outside every layer's scope. Left to itself it can never
+learn about the modules built beneath it, and a finished build ships a
+landing page with no route into the app it just built.
+
+`tools/generate-module-routes.cjs` globs `apps/web/src/app/*/page.tsx`
+and writes `apps/web/src/app/module-routes.ts` — an exported
+`moduleRoutes` array of `{ href, label }`, one per route directory found,
+skipping Next.js route groups (`(group)`) and `_`/`.`-prefixed
+directories, which are not routes. The root page imports that one
+generated file and renders a link per entry, or a short "no modules yet"
+line when the array is empty, which is what the shipped core has. A
+module's screen layer only ever creates its own `page.tsx` inside its own
+`apps/web/src/app/{module}/` directory — always in scope — and nothing
+ever hand-edits the root page or the generated file.
+
+`generate-module-routes` is wired as an explicit Nx target on `apps/web`
+(`apps/web/package.json`'s `nx.targets`), cached, with `build`, `dev`,
+`test` and `typecheck` picking it up through `nx.json`'s `targetDefaults`
+the same way its API sibling does.
+
 ## Steps
 
 ### 1. Confirm this hasn't already run

package/src/skills/hedgehog-core-design/SKILL.md

@@ -117,7 +117,10 @@ Every layer's `scope` and `verify` in Step 3 draws from this record.
 ## Step 3 — derive the layers
 
 Read `.hedgehog/BMAD/` for what the system actually does, then decide the
-layers it builds in. A layer earns its place by owning a distinct
+layers it builds in. Read `00-manifest.md` first for which files the
+archive holds: a compressed intake leaves `04-prd.md` as the only source
+for this step, and where it doesn't settle something a layer boundary
+depends on, ask rather than infer. A layer earns its place by owning a distinct
 artifact that can be verified on its own. Order by dependency first (a
 layer that another layer imports comes first), by contract second (a
 layer that pins an external interface — a schema, a wire format, a public
@@ -620,6 +623,11 @@ to change only until the file lands. Hard stop.
 - That this is an authored core: the sequence was designed for this
   project, not battle-tested across many, and it carries the same
   enforcement as a Golden Core but a weaker guarantee.
+- If `.hedgehog/BMAD/00-manifest.md` records a compressed intake: that
+  this architecture was designed from a brief and one batched round
+  rather than from elicited drivers, so the stack and layer choices rest
+  on thinner input than a full shelf run would give them. Name it here
+  rather than in passing — it's part of what the user is accepting.
 
 Then state plainly what happens on confirmation, before it happens:
 

package/src/skills/hedgehog-loop/SKILL.md

@@ -130,7 +130,9 @@ Phase A — one claimed packet per dispatch, in its own context. Step
 the `hook` layer's task is `complete` and before `front-end-eng` starts
 the `screen` layer — via `ux-planner`, starting from whatever `planner`
 filed in `docs/design/<module>-notes.md` at planning intake, or the raw
-UX spec directly if that file is absent. Its first run for a module also
+UX spec directly if that file is absent, or — where the archive holds
+neither — from the contract and hook plus whatever the user supplies when
+it asks. Its first run for a module also
 signals to the user that Phase B has started, and is the point a mockup,
 screenshot, or export (Google Stitch, Figma) can be handed over. It
 writes `docs/design/<module>.md`, not its own compiled layer — the
@@ -220,10 +222,10 @@ starts from its own:
 
 ```bash
 nx g ./tools/generators:schema     --module=<module> --fields='<name:type,...>'
-nx g ./tools/generators:contract   --module=<module> --fields='<name:type,...>'
+nx g ./tools/generators:contract   --module=<module> --fields='<name:type,...>' [--toggleField=<boolField>]
 nx g ./tools/generators:repository --module=<module>
-nx g ./tools/generators:service    --module=<module>
-nx g ./tools/generators:controller --module=<module> --fields='<name:type,...>'
+nx g ./tools/generators:service    --module=<module> [--toggleField=<boolField>]
+nx g ./tools/generators:controller --module=<module> --fields='<name:type,...>' [--toggleField=<boolField>]
 nx g ./tools/generators:hook       --module=<module> [--toggleField=<boolField>]
 nx g ./tools/generators:screen     --module=<module>
 ```
@@ -234,8 +236,26 @@ over `string`, `text`, `boolean`, `integer`, and `timestamp`, with a
 trailing `?` marking the column nullable
 (`--fields='title:string,done:boolean,dueDate:timestamp?'`); `contract`
 and `controller` take the same list the module's `schema` was generated
-with. `hook`'s optional `--toggleField` names a boolean field from the
-schema to expose as a dedicated toggle mutation.
+with. A `string` field takes an optional length in parentheses
+(`title:string(500)`), threaded to both the Drizzle `varchar` and the Zod
+`.max()` so the two cannot disagree; omitted, it is 255. Check every
+length against the intent's own rules in the packet's **RELEVANT RULES** —
+a rule like "at most 500 characters" is the field list's business, not
+the authored delta's, and a Zod bound that outruns its column surfaces as
+a driver error at the database rather than a 400 at the boundary.
+
+`--toggleField` names a boolean field from the schema to expose as a
+toggle, and is passed to `contract`, `service`, `controller`, and `hook`
+alike — one flag, four layers, so the route, the domain method, the
+handler, and the mutation are generated from one source. The toggle is
+server-side by construction: `POST /<module>/:id/toggle` carries no body,
+and the service reads the current value and flips it inside the same
+transaction its `update` uses. The client sends only the id, so a stale
+cached row cannot overwrite a newer state — which is exactly what
+computing the new value on the client would do, losing one of any two
+flips that raced. Note that `@ts-rest/core` generates no `body` parameter
+for a `c.noBody()` route: the call is `client.toggle({ params: { id } })`,
+and passing `body: undefined` is a compile error.
 
 Each generator lands the whole conventional shape of its layer in one
 deterministic step — the package shell (`package.json`, `tsconfig*.json`,
@@ -263,6 +283,13 @@ depend on. Never register a module by editing `app.module.ts` — a shared
 file no module-scoped task can safely touch. Validation is ts-rest + Zod,
 so this core has no Nest DTOs and no class-validator.
 
+The root page is the same: `apps/web/src/app/page.tsx` renders whatever
+`module-routes.ts` holds, and that file is regenerated by the
+`generate-module-routes` Nx target from every
+`apps/web/src/app/*/page.tsx` on disk. A screen layer creates its own
+`page.tsx` in its own directory and the root page picks it up — never
+edit either the root page or the generated file to add a link.
+
 **A new package needs wiring into the workspace before `hedgehog verify`
 runs on it.** A package that exists on disk isn't yet part of the
 workspace:
@@ -327,7 +354,12 @@ generator's `timestamp.ts` is one (a shared Zod util every module in the
 package imports, written once, sibling to `src/index.ts`). That file needs
 the same widening as the shell itself.
 
-Widen that one task, before building it:
+The packet says so: when the package a scope points into has no
+`package.json` on disk yet, `hedgehog next`/`show` prints a **FIRST
+ARRIVAL** section under ALLOWED SCOPE carrying the exact command for that
+task. Run it before building — the widening is only available while the
+task is still `ready`, and a verify that rejects the shell paths blocks
+the task and turns this into a five-command recovery.
 
 ```bash
 hedgehog override add TASKS-CONTRACT \

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

@@ -1,6 +1,6 @@
 ---
 name: hedgehog-planning-intake
-description: Use on any core for first-run planning intake — Phase 0 runs the vendored BMAD-METHOD planning shelf, shared by every core, and Phase 1 (mining `04-prd.md` into intent records plus the Add-ons decision) is full-stack-app's own procedure. 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 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.
 ---
 
 # Hedgehog Planning Intake
@@ -95,7 +95,80 @@ Write each skill's output to `.hedgehog/BMAD/`, per the fixed layout:
 
 Every file/folder carries a one-line attribution header. `00-manifest.md`
 states the source repo, pinned version (`vendor-skills/BMAD/ATTRIBUTION.md` has
-the pinned commit), date, and which skills ran.
+the pinned commit), date, which intake mode ran (`full`, below, or
+`compressed`), and which skills ran.
+
+### Compressed intake (full-stack-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.
+`planner` surfaces that conflict rather than resolving it silently (see
+that agent), and **compressed intake is the defined path when the user
+chooses it**. It is never the default and never offered as the
+easier option: it runs only on an explicit choice, after the conflict has
+been named.
+
+Compressed intake replaces the shelf with **one batched round of
+questions covering only what can't be inferred from the user's brief**,
+then writes the archive below directly. Everything else about intake is
+unchanged — Phase 1 mining, Confirm & Lock, and the Add-ons gate all run
+exactly as they do on a full run, against the archive this mode writes.
+
+Not available on landing-page: that core's whole chain is a traceability
+audit rooted in a subject statement mined from BMAD's material, so
+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.
+
+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
+layout:
+
+```
+.hedgehog/BMAD/
+  00-manifest.md        # mode: compressed, date, what the batched round covered
+  04-prd.md             # §3 Glossary and §4 Features only, mined from the brief
+  05-ux-spec/
+    EXPERIENCE.md       # flows and behaviour, where the brief states them
+```
+
+- **`04-prd.md`** carries the load: Phase 1 below reads §3 Glossary and
+  §4 Features, so compressed intake writes exactly those two sections,
+  derived from the brief plus the batched answers, in the shape that
+  mining table expects. Not a full BMAD PRD — the minimum shape Phase 1
+  can walk.
+- **`05-ux-spec/EXPERIENCE.md`** only where the brief actually states
+  flows or behaviour ("a list you can filter", "mark done inline"). No
+  `DESIGN.md`: visual identity is what a compressed brief is least
+  likely to state, and inventing one is exactly the improvisation this
+  mode exists to prevent. `ux-planner` reads whichever of the two the
+  archive holds, and treats an absent file as its cue to ask (see that
+  agent).
+- **`01-brainstorming.md`, `02-brief.md`, `03-prfaq.md`, and
+  `06-research.md` are not written.** Those exist on a full run to
+  produce a good PRD; compressed intake reaches the PRD by a different
+  route. `00-manifest.md` naming them as not-run is the record — an
+  empty placeholder file is not.
+
+`00-manifest.md` states `mode: compressed`, the date, which files were
+written and which weren't, what the batched round asked, and which
+add-ons were answered directly versus triggered by the brief. That
+manifest is the single record of how this project was planned: **the
+archive exists on every core after intake, whichever mode ran**, so an
+absent `.hedgehog/BMAD/` means intake never ran, not that a compressed
+path was taken.
+
+On an authored core, `hedgehog-core-design` reads this archive to pick a
+stack and derive layers. A compressed PRD is thinner input for that than
+a full shelf run, so say so plainly at that skill's own Confirm & Lock —
+the architecture is being designed from a brief rather than from elicited
+drivers, and that's the user's call to accept there.
 
 `.hedgehog/BMAD/` is archival and immutable once written, on every core.
 Nothing in `hedgehog-loop`'s day-to-day operation, `hedgehog-bootstrap`,
@@ -117,6 +190,9 @@ Read `.hedgehog/BMAD/04-prd.md` only — §3 Glossary and §4 Features.
 Nothing else in `.hedgehog/BMAD/` is read again: brainstorming, brief,
 PR-FAQ, and deep-recon existed to produce a good PRD, and the UX spec is
 read later, once per module, by `ux-planner`, not by this mining pass.
+This is the same read on either intake mode — a compressed archive writes
+those two sections directly, so mining has its documented source
+whichever mode ran.
 Mining is mechanical, not interpretive — one graph row per PRD element,
 per this table:
 
@@ -134,6 +210,21 @@ Procedure:
    `outcome` drawn directly from the Feature's description (split the
    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
+   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
+   generators each layer's packet names take the module plural, so a
+   singular id compiles a graph scoped to a directory the generator will
+   never write. This is the moment that choice is cheapest: it is one
+   string here, and a Correction Protocol case across every compiled task
+   three layers later. `hedgehog intent add` and `hedgehog plan` both
+   report an id that looks singular — `plan` for as long as none of that
+   intent's tasks has been started, since every route into the graph
+   (`--file`, a hand-written intent file, `db rebuild`) converges there.
+   Both are advisory: `billing` and `search` are legitimately singular, so
+   read the report and decide, rather than renaming on sight.
 2. **Walk that Feature's FRs.** Each FR's "Consequences (testable)" list
    items become that intent's `requirements` with `kind='acceptance'`,
    one per item, verbatim or lightly tightened — no rephrasing that
@@ -177,7 +268,9 @@ stops being true, so it's a hard stop, not a recap in passing.
   `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).
-- Which BMAD skills ran and where their output lives
+- 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
   (`.hedgehog/BMAD/`).
 
 Then state plainly what happens on confirmation, before it happens:
@@ -215,9 +308,13 @@ their commits.
 
 1. **Read `.hedgehog/BMAD/` for context**, chiefly `02-brief.md` and
    `04-prd.md` — what this project is, and what its existing vocabulary
-   calls things. Read-only. The new scope has to sit inside the same
-   product and reuse its terms; you're extending a project, not starting
-   a neighbouring one.
+   calls things. Read `00-manifest.md` first for which of those the
+   archive actually holds: on a compressed archive that's `04-prd.md` and
+   the manifest's own record of the batched round, which carry the same
+   two things this step needs (the product, and its vocabulary).
+   Read-only. The new scope has to sit inside the same product and reuse
+   its terms; you're extending a project, not starting a neighbouring
+   one.
 2. **Read the existing graph**: `hedgehog status` for what's built, and
    the existing intent ids for the vocabulary already in play. New scope
    names must not collide with an existing intent id.

package/src/templates/CLAUDE.core.full-stack-app.md

@@ -3,7 +3,10 @@
 Backend-first, schema → contract → repository → service → controller, then
 hook → UX rationale → screen, per domain module. See `.hedgehog/BMAD/` for
 the archival planning intake output — BMAD-METHOD's brainstorming, brief,
-PRD, and UX spec, written once by `planner` and never edited after.
+PRD, and UX spec, written once by `planner` and never edited after. Its
+`00-manifest.md` records which intake mode produced it; a compressed
+archive holds the PRD and whatever flows the brief stated, and nothing
+else.
 `.hedgehog/addons.yaml` carries this core's Add-ons decision
 (Auth/Queue/Mobile, each on or off) — check it before assuming any
 add-on's infra exists.
@@ -49,7 +52,9 @@ steps from memory:
 - **`ux-planner`** — once per module in Phase B, after the hook exists and
   before the screen: writes `docs/design/<module>.md`, reading
   `.hedgehog/BMAD/05-ux-spec/` directly (or
-  `docs/design/<module>-notes.md` if a prior run already filed one).
+  `docs/design/<module>-notes.md` if a prior run already filed one). Where
+  the archive holds no UX spec, it asks for visual input rather than
+  inferring a direction.
 - **`front-end-eng`** — builds each module's Phase B layers (hook, screen)
   from the ux-planner rationale, one `hedgehog next` packet at a time,
   gated by `hedgehog verify`.