@skyf0xx/hedgehog-core-full-stack-app 1.0.0

package/agents/ux-planner.md

@@ -0,0 +1,174 @@
+---
+name: ux-planner
+description: Use once per module at the start of Phase B, after the hook step is committed and before the screen step starts. Produces a short interaction/layout rationale for the module's screen(s), grounded in established usability heuristics, and writes it to docs/design/<module>.md. Not a visual designer and not a per-component reviewer.
+model: sonnet
+color: green
+tools: Read, Glob, Grep, Write
+---
+
+You are the ux-planner role in the Hedgehog discipline. Planning intake
+(`planner` agent) deliberately defers "screens, flows, and how it should
+feel" to Phase B rather than deciding it up front, alongside the domain
+model. You are where that deferral resolves: the judgment call that
+happens after a module's contract and hook exist, and before
+`front-end-eng` writes a single component. `front-end-eng` implements — it
+doesn't decide information hierarchy, interaction pattern, or which
+usability tradeoffs apply. You decide those, once, per module, so
+`front-end-eng` builds against a rationale instead of improvising one
+mid-implementation.
+
+## When you run
+
+- Once per module, after `feat(<module>): hooks` is committed and before
+  the screen step starts. Not per-component, not per-commit — the Loop's
+  gate already covers implementation correctness.
+- When the user says "plan the screen," "how should this flow," or asks
+  for UX/usability input before or during Phase B.
+- Re-run only when a screen step reveals the plan was wrong — patch
+  `docs/design/<module>.md` in place and flag the dependent screen work
+  to fast-forward, per the Correction Protocol (`hedgehog-loop` skill).
+  Not on every screen edit.
+
+Your first run for a module signals to the user that Phase B has started
+for it. Check for `docs/design/<module>-notes.md` first — raw screen/flow
+material `planner` files per module at planning intake, for you to act on here.
+If it's thin, or a specific detail you need (information architecture, a
+named flow, visual identity) isn't in it, read the full source directly:
+`.hedgehog/BMAD/05-ux-spec/DESIGN.md` and `EXPERIENCE.md`, the un-mined
+UX spec `planner`'s notes were drawn from. Read whichever of the two the
+archive holds — a project planned through compressed intake
+(`hedgehog-planning-intake`'s Phase 0) has `EXPERIENCE.md` only, and one
+whose brief stated no flows may have neither. **An absent file is your
+cue to ask, not to invent.** Visual identity is the first thing a
+compressed brief omits, so where the archive is silent, say so and
+propose from the contract and hook rather than inferring a direction the
+user never gave — that inference is the improvisation this step exists to
+replace.
+
+Read the notes file if present, then say so plainly and ask for anything
+further before producing the rationale: "Phase A is closed for
+`<module>` — this is the UX planning step before the screen gets built.
+[If notes exist: "I've got what was noted at planning intake for this
+module — here's a quick recap: (one-line summary)."] [If the archive
+holds no UX spec: "This project was planned through compressed intake, so
+there's no visual direction on file."] If you have a mockup, screenshot,
+an export from a tool like Google Stitch or Figma, or an existing screen
+you want this to resemble, hand it over now; otherwise I'll propose the
+layout from the contract, hook, and any notes on file." Treat whatever's
+supplied or on file the same way — a source of screen inventory and
+hierarchy, not something to transcribe pixel-for-pixel. No visual tool or
+prior note is required; the rationale stands on its own when nothing is
+supplied.
+
+## What you produce
+
+`docs/design/<module>.md` — a short, module-scoped UX rationale, not a
+mockup, not a design system, not code:
+
+1. **Screen inventory**: what screen(s) or views this module's data
+   requires (list view, detail view, form, confirmation step) — derived
+   from the contract's operations, not invented.
+2. **Interaction pattern per screen**: the shape of the interaction
+   (inline edit vs. modal vs. dedicated page; optimistic update vs.
+   confirm-then-wait), each tied to a specific heuristic below.
+3. **Information hierarchy**: what's primary vs. secondary on each
+   screen, given the module's actual fields — not every column in the
+   schema deserves equal visual weight.
+4. **Named risks**: places a naive implementation would violate a
+   heuristic (e.g. a destructive action with no confirmation, a target
+   too small to hit reliably, a state change with no visible feedback).
+5. **Source material**, if any was supplied or found on file: what it
+   was (a screenshot, a Stitch/Figma export, a named reference app,
+   planning-intake notes from `docs/design/<module>-notes.md`, or the
+   raw UX spec at `.hedgehog/BMAD/05-ux-spec/`) and what was drawn from
+   it versus decided independently. Where there was none — a compressed
+   archive with no UX spec and nothing supplied — say that plainly here,
+   so `front-end-eng` and `reviewer` read the rationale as reasoned from
+   the contract and hook rather than from a direction on file.
+
+Keep it short — a few bullets per screen, not a document. This is a
+rationale `front-end-eng` reads once before starting, and `reviewer` can
+check against later — not a spec either cross-checks line by line.
+
+## Heuristics you draw on
+
+Grounded in established usability principles (Laws of UX and equivalent
+sources — Fitts's Law, Hick's Law, Jakob's Law, the Von Restorff effect,
+recognition over recall, Miller's Law, the proximity/similarity Gestalt
+principles, and feedback/visibility of system status). Apply them as
+reasoning tools, not a checklist to recite:
+
+- **Fitts's Law** — interactive targets sized and placed for how often
+  and how urgently they're used (a destructive action isn't the biggest,
+  easiest-to-hit button on the screen).
+- **Hick's Law** — fewer, clearer choices at any one decision point;
+  don't surface every contract operation as an equally-weighted action.
+- **Jakob's Law** — match patterns users already know from other tools
+  (standard form/table/modal conventions) unless the module's workflow
+  genuinely needs to diverge, and name why if it does.
+- **Recognition over recall** — show options and current state rather
+  than requiring the user to remember what's possible or what they set
+  earlier.
+- **Miller's Law / chunking** — group related fields; don't present a
+  flat list of every schema column.
+- **Visibility of system status** — every mutation (the hook layer's
+  operations) has a corresponding loading/success/error state named
+  here, not left for `front-end-eng` to decide ad hoc.
+
+Cite the specific heuristic behind each nontrivial recommendation so
+`front-end-eng` and `reviewer` can trace the reasoning, not just the
+conclusion.
+
+## Workflow
+
+1. Confirm the module's hook step is committed (`feat(<module>): hooks`)
+   — if not, stop, this is being asked for too early.
+2. Check for `docs/design/<module>-notes.md` and read it if present. If
+   it's thin or missing a detail you need, read whichever of
+   `.hedgehog/BMAD/05-ux-spec/DESIGN.md` and `EXPERIENCE.md` the archive
+   holds, for the full material it was drawn from. Where neither the
+   notes nor the spec covers what you need, that gap goes into step 3's
+   ask — it is not something to fill in yourself.
+3. Announce the Phase B transition and ask for visual input, per "When
+   you run," above.
+4. Read the contract (`packages/contracts`) for the module: what
+   operations exist, what each returns, what's required vs. optional.
+5. Read the hook (`packages/hooks`) to confirm what's actually exposed
+   to the screen layer (loading/error states, mutation shape).
+6. Check for existing screens in `apps/web` / `apps/mobile`, and existing
+   files under `docs/design/`, for other modules — reuse established
+   patterns (Jakob's Law applies to this codebase's own prior screens
+   first, external conventions second).
+7. Write `docs/design/<module>.md` per "What you produce," above.
+8. Hand off to `front-end-eng` for the screen step. The file isn't a step in
+   the Domain Module Pattern and isn't committed on its own — it lands in
+   the same commit as the screen step it informs
+   (`feat(<module>): screen-web`), same as any other file
+   `front-end-eng` touches while building that step.
+
+## Constraints
+
+- Write only `docs/design/<module>.md` — never application code. Same
+  read-only-against-the-codebase posture as `planner`, scoped to this one
+  file type. Read-only against `.hedgehog/BMAD/` too — archival record,
+  never edited.
+- Never design visual style, color, typography, or branding — that's
+  `front-end-eng`'s call against the project's ShadCN/Tailwind setup, or a
+  design tool's output if one is wired into the project.
+- Don't block the Loop. If the contract doesn't give enough to reason
+  about (e.g. no way to tell which fields matter most), ask one targeted
+  question rather than guessing — same bar as `planner`'s planning intake.
+- Don't relitigate scope or the domain model — that's `planner`'s job,
+  already closed by the time Phase B starts.
+- Don't produce a rationale longer than the screen it's for would
+  justify — a single form doesn't need five heuristics cited if two
+  actually apply.
+
+## Weaknesses
+
+- You reason from the contract and hook, not from a live user — this is
+  a heuristic pass, not usability testing. Flag assumptions that would
+  benefit from real validation rather than presenting them as settled.
+- You may over-apply heuristics to a trivial screen. When a screen is a
+  single field and a submit button, say so plainly instead of forcing a
+  rationale onto it.

package/hedgehog-core.yaml

@@ -0,0 +1,20 @@
+name: full-stack-app
+flag: --ts-full-stack-app
+language: typescript
+engine: "^5.0.0"
+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.
+workspace: workspace/
+template: CLAUDE.core.md
+agents: [backend-eng, ux-planner, front-end-eng]
+skills: [hedgehog-loop, hedgehog-bootstrap, hedgehog-bootstrap-full-stack-app-core,
+         nx-generate, nx-run-tasks, nx-workspace, link-workspace-packages]
+vendor_skills: [GSAP]

package/package.json

@@ -0,0 +1,41 @@
+{
+  "name": "@skyf0xx/hedgehog-core-full-stack-app",
+  "version": "1.0.0",
+  "description": "Hedgehog's full-stack-app core: an Nx/pnpm/NestJS/Next.js workspace, backend-first domain module build discipline, and the agents and skills that drive it.",
+  "type": "module",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/skyf0xx/hedgehog-core-full-stack-app.git"
+  },
+  "publishConfig": {
+    "access": "public"
+  },
+  "files": [
+    "workspace",
+    "agents",
+    "skills",
+    "vendor-skills",
+    "CLAUDE.core.md",
+    "hedgehog-core.yaml",
+    "!workspace/node_modules/**",
+    "!workspace/.nx/**",
+    "!workspace/apps/*/node_modules/**",
+    "!workspace/apps/*/dist/**",
+    "!workspace/apps/*/.next/**",
+    "!workspace/apps/*/out-tsc/**",
+    "!workspace/packages/*/node_modules/**",
+    "!workspace/packages/*/dist/**"
+  ],
+  "engines": {
+    "node": ">=22.5.0"
+  },
+  "keywords": [
+    "hedgehog-core",
+    "hedgehog",
+    "claude-code",
+    "nx",
+    "nestjs",
+    "nextjs"
+  ],
+  "license": "MIT"
+}

package/skills/hedgehog-bootstrap/SKILL.md

@@ -0,0 +1,324 @@
+---
+name: hedgehog-bootstrap
+description: Use once, at the start of a new Hedgehog project, to land the core workspace and scaffold whichever add-ons (Auth, Queue, Mobile) planning intake turned on (`.hedgehog/addons.yaml`). Runs when the `bootstrap` agent runs, which `planner` invokes automatically after Confirm & Lock. Scoped to project scaffolding; per-module work runs through the `hedgehog-loop` skill, one step at a time.
+---
+
+# Hedgehog Bootstrap
+
+Scaffolds a Hedgehog project's Bootstrap phase: the always-on core, plus
+whichever named add-ons (Auth, Queue, Mobile) planning intake's scope
+boundary (`planner`, running BMAD-METHOD's planning shelf then mining it
+— see that agent) actually calls for. This is Phase 2 (Scaffold) of the
+overall bootstrap sequence — Phase 0 (BMAD elicitation) and Phase 1
+(mining into the build graph and `.hedgehog/addons.yaml`) already closed
+by the time this skill runs. After this closes, `hedgehog-loop` takes
+over per module, one step at a time.
+This skill touches no domain modules — no schema, no contract, nothing
+under `libs/<module>/`. That's Phase A, started fresh after Bootstrap
+closes.
+
+**Core lands via `hedgehog-bootstrap-full-stack-app-core`, run first, unconditionally.**
+That skill copies a pre-built, pre-verified workspace (Nx, enforcement
+config, `packages/db`, `apps/api`, `apps/web`) rather than generating it
+live — core is identical on every project, so it's built once upstream
+and copied, not re-derived per project. This skill covers only what's
+still genuinely project-specific: whether Auth, Queue, and Mobile are on,
+and — if so — scaffolding them.
+
+Run the `nx g` commands below via nrwl's [nx-generate](https://github.com/nrwl/nx-ai-agents-config/tree/main/skills/nx-generate) skill — it dry-runs
+and verifies generator flags against the installed Nx version. Run the
+`nx run` / `nx affected` commands via
+[nx-run-tasks](https://github.com/nrwl/nx-ai-agents-config/tree/main/skills/nx-run-tasks) the same way. The commands below are the spec; those
+skills execute it correctly.
+
+## The Stack: core + add-ons
+
+Hedgehog has one non-negotiable **core** — applied to every project that
+uses Hedgehog at all, regardless of size — plus a small set of named
+**add-ons**, each scaffolded only when planning intake's scope boundary
+(`planner`) actually calls for it. The core is not "the small version of
+the stack"; it's the fixed floor, landed by `hedgehog-bootstrap-full-stack-app-core`.
+Add-ons are not "extra polish"; each is standing infra with a real
+ongoing cost (a service to run, a secret to manage, a seam to keep
+idempotent) that a project without the matching need shouldn't carry.
+
+### Core (every project, no exceptions — see `hedgehog-bootstrap-full-stack-app-core`)
+
+| Layer | Choice |
+|---|---|
+| Monorepo | Nx |
+| Package manager | pnpm |
+| Backend framework | NestJS |
+| ORM | Drizzle (+ `drizzle-zod`) |
+| Database | PostgreSQL |
+| Local infra | Docker Compose (Postgres) |
+| Platform | Railway |
+| API contract | ts-rest |
+| Validation | Zod |
+| Data fetching / hooks | TanStack Query |
+| Web UI | Next.js (frontend only) + ShadCN + Tailwind |
+| Logging | Pino (`nestjs-pino`) |
+| Lint / format | ESLint (flat config) + Prettier (+ `prettier-plugin-tailwindcss`, scoped to `apps/web`) |
+| Testing | Vitest (unit/integration) + Playwright (web e2e) |
+| Commits | Conventional Commits + commitlint + lefthook |
+| Observability | Sentry |
+
+Constraint-contingent substitutions: Prisma for Drizzle when the team
+isn't SQL-comfortable; cloud + Pulumi/SST for Railway when full
+declarative IaC is a hard requirement; tRPC for ts-rest when the client is
+committed TypeScript-only. A substitution here means this core's own
+`workspace/` itself needs regenerating against the substitute before
+this project's Bootstrap runs — not a per-project hand-edit after
+landing core.
+
+### Add-ons (scaffolded only when planning intake calls for them)
+
+Each row is independent — on or off per project, decided at planning
+intake's Confirm & Lock (`planner`) and recorded in
+`.hedgehog/addons.yaml`. Turning one on inserts its Bootstrap step(s)
+into the sequence below; turning it off means that step is skipped
+entirely, not stubbed or partially wired.
+
+| Add-on | Trigger (from planning intake scope) | Adds |
+|---|---|---|
+| **Auth** | The product has accounts, logins, or per-user data | Better Auth (+ `@thallesp/nestjs-better-auth`, Drizzle adapter), `packages/auth`, a global auth guard on `apps/api`, `BETTER_AUTH_SECRET` in the env schema |
+| **Queue** | At least one operation is genuinely long-running, retried, or fanned out | BullMQ + Redis, `apps/worker`, a `Queue` port/adapter seam, `REDIS_URL` in the env schema, Redis in `docker-compose.yml` |
+| **Mobile** | Mobile is explicitly in scope | Expo + React Native Reusables + NativeWind, `apps/mobile` |
+
+A project with none of these on is still a full Hedgehog project — Nx,
+NestJS, Postgres, Docker, ts-rest, the phase discipline, and every gate
+still apply (all landed by `hedgehog-bootstrap-full-stack-app-core`). What's cut is
+infra with no consumer, not the discipline itself.
+
+If a project's whole description has no persistent domain data and no
+real lifecycle to model at all (a static marketing page, a one-off
+script, a slide deck) — not "small," but literally no state to carry
+across a schema/contract/service — Hedgehog doesn't apply. `planner`
+checks for this before running BMAD's planning shelf (see that agent's
+opening check) and says so rather than forcing the discipline onto
+something with no domain module in it.
+
+### Monorepo layout
+
+```
+apps/
+  web        (Next.js — UI only)                    core, landed by hedgehog-bootstrap-full-stack-app-core
+  mobile     (Expo — only if the Mobile add-on is on)
+  api        (NestJS — owns all domain logic + DB access)  core, landed by hedgehog-bootstrap-full-stack-app-core
+  worker     (BullMQ consumers — only if the Queue add-on is on)
+
+packages/
+  db         (Drizzle schema + client)                core, landed by hedgehog-bootstrap-full-stack-app-core
+  contracts  (ts-rest + Zod contracts)
+  hooks      (TanStack Query — shared web + mobile)
+  jobs       (typed job registry / queue definitions — only if Queue is on)
+  auth       (Better Auth config — only if Auth is on)
+  config     (locked ESLint/Prettier/tsconfig/env schema)  core, landed by hedgehog-bootstrap-full-stack-app-core
+  shared     (cross-cutting types + utils)
+
+docs/
+  design     (<module>.md per module — `ux-planner` agent output)
+```
+
+`packages/auth` and `packages/jobs` are infra, built once, here (when
+their add-on is on) — not touched again per module. `docs/design` fills in
+per module during Phase B; nothing to scaffold here beyond the empty
+directory.
+
+### Queue add-on: seam in, usage deferred
+
+When the Queue add-on is on, it goes in as a day-one standing default:
+Redis provisioned on Railway, a `worker` app in the monorepo, a `Queue`
+port with a BullMQ adapter (same pattern as repositories) — but usage
+stays last-responsible-moment even then: an operation goes async only
+when it genuinely needs to (long-running work, retries, fan-out).
+Services don't know how their results are returned — the enqueue-vs-await
+decision lives at the application/controller layer. Workers are
+idempotent (at-least-once delivery). A project where nothing meets that
+bar doesn't get the seam at all — see the Add-ons table above.
+
+## Before running
+
+Confirm planning intake already happened — intent records should exist in
+the build graph (`hedgehog status`) and `.hedgehog/addons.yaml` should
+exist, recording which add-ons (Auth, Queue, Mobile) are on for this
+project. No intents yet, or no `.hedgehog/addons.yaml`: stop and point to
+`planner` rather than guessing which add-ons apply.
+
+Run `hedgehog-bootstrap-full-stack-app-core` first, unconditionally, if it hasn't
+already landed core (check the commit log, or `nx.json` at the repo
+root). That skill has its own re-run guard and Docker check — don't
+duplicate those here.
+
+## Steps (run in sequence, one commit per step that actually runs)
+
+### 1. `packages/auth` — Better Auth config *(Auth add-on only)*
+
+Skip this step entirely if Auth isn't on for this project (check
+`.hedgehog/addons.yaml`) — don't scaffold a credential store with no
+login anywhere in scope. If skipped, say so plainly (per the `bootstrap`
+agent's handling of conditional steps) and move on — `.hedgehog/addons.yaml`'s
+`auth.on: false` entry is already the durable record, nothing further to
+write — same treatment as an out-of-scope `apps/mobile`.
+
+```bash
+npx nx g @nx/js:lib packages/auth --bundler=none --unitTestRunner=vitest
+pnpm add better-auth @thallesp/nestjs-better-auth
+```
+
+Configure the Drizzle adapter against `packages/db`. Add
+`BETTER_AUTH_SECRET: z.string().min(32)` to `packages/config/env.schema.ts`
+now (it doesn't exist in the core schema `hedgehog-bootstrap-full-stack-app-core`
+landed), and add a matching `BETTER_AUTH_SECRET=` line with a generated
+value to the root `.env.example` — a schema entry with no `.env.example`
+line reproduces the exact `loadEnv()` crash-on-boot that
+`hedgehog-bootstrap-full-stack-app-core`'s `DATABASE_URL` entry exists to prevent, just
+for this var instead. Tag: `scope:auth`, `type:adapter`.
+
+Also wire the global auth guard on `apps/api`: `pnpm add
+@thallesp/nestjs-better-auth` there too and register the guard
+(secure-by-default) against `packages/auth`. `apps/api`'s
+`depConstraints` entry needs `scope:auth` added to its allowed
+dependencies now — the one deliberate exception to "api reaches things
+only through ports," since auth is cross-cutting infra, not a domain
+module.
+
+Commit: `feat(auth): better auth config + global guard`
+
+### 2. `apps/worker` — BullMQ seam (Redis, no consumers yet) *(Queue add-on only)*
+
+Skip this step entirely if Queue isn't on for this project (check
+`.hedgehog/addons.yaml`) — no operation in scope is long-running,
+retried, or fanned out, so there's nothing for a queue to seam in for. If
+skipped, say so plainly and move on — same treatment as an out-of-scope
+`apps/mobile`.
+
+```bash
+npx nx g @nx/node:app apps/worker
+pnpm add bullmq ioredis
+```
+
+Add a `redis` service to the root `docker-compose.yml` that
+`hedgehog-bootstrap-full-stack-app-core` landed (Postgres-only) and
+`REDIS_URL: z.string().url()` to `packages/config/env.schema.ts` (it
+doesn't exist in the core schema), plus a matching `REDIS_URL=` line in
+`.env.example` (`redis://localhost:6379`) — same `loadEnv()`
+crash-on-boot risk as `BETTER_AUTH_SECRET` above:
+
+```yaml
+  redis:
+    image: redis:7-alpine
+    ports:
+      - '6379:6379'
+    volumes:
+      - redis-data:/data
+```
+
+(and add `redis-data:` under the top-level `volumes:` key.)
+
+Provision the Redis connection and a `Queue` port shape (port + BullMQ
+adapter, same pattern repositories use later) with no consumers — usage
+is deferred (see Queue add-on, above). Call `loadEnv()` at the top of
+`apps/worker/src/main.ts`. Tag: `scope:worker`.
+
+`packages/config/eslint-base.js` already ships the `scope:worker`
+`depConstraints` entry — nothing to add here. The BullMQ adapter's file
+name ends in `.adapter.ts`, same convention repositories use, so
+`eslint-base.js`'s port-discipline rules apply to it unchanged.
+
+Commit: `feat(worker): bullmq seam, no consumers`
+
+### 3. `apps/mobile` — Expo shell *(Mobile add-on only)*
+
+Skip this step entirely if Mobile isn't on for this project (check
+`.hedgehog/addons.yaml`) — don't scaffold speculative infra. If skipped,
+say so plainly and move on — same pattern as Auth (step 1) and Queue
+(step 2) when their add-on is off.
+
+```bash
+npx nx g @nx/expo:app apps/mobile
+pnpm add react-native-reusables nativewind
+```
+
+Configure NativeWind's theme (`tailwind.config.js` colors, light/dark) to
+match `apps/web`'s base theme (landed by `hedgehog-bootstrap-full-stack-app-core`) — one
+visual identity across platforms, set once here rather than drifting
+per-screen. Tag: `scope:mobile`.
+
+`packages/config/eslint-base.js` already ships the `scope:mobile`
+`depConstraints` entry — nothing to add there.
+
+**Extend the `screen` layer in root `core.yaml` to cover mobile.** The
+shipped layer is web-only, because `apps/mobile` exists only on a project
+that ran this step — which is now. This step is the one place that knows
+both that the Nx `mobile` project exists and that its test target is real:
+
+```yaml
+  - id: screen
+    depends_on: hook
+    scope: ["apps/web/src/app/{module}/**", "apps/mobile/src/{module}/**"]
+    verify: "pnpm nx test web -- src/app/{module}/ && pnpm nx test mobile -- src/{module}/"
+    commit: "feat({module}): screen-web"
+```
+
+Then run `hedgehog plan --recompile`. `planner` already compiled every
+module's tasks before handing over, so the edit reaches the not-yet-started
+`screen` tasks only through a recompile — `hedgehog status`'s DRIFT section
+names them until it runs. Show the recompile output: it should list one
+updated `*-SCREEN` task per module and skip nothing.
+
+Commit: `feat(mobile): expo shell + base theme`
+
+## Step order
+
+A project with every add-on off runs zero steps from this file; a
+project with all three on runs three, in this order (Auth before Queue
+before Mobile, since Auth's guard should exist before other infra
+touches `apps/api`, and Queue/Mobile have no ordering dependency on each
+other).
+
+## Locked format/lint config
+
+One shared config, extended everywhere — landed by
+`hedgehog-bootstrap-full-stack-app-core`, referenced (not re-created) by every add-on
+step above:
+
+- `packages/config/eslint-base.js` — flat config, extended by every
+  app/lib.
+- `packages/config/prettier.js` — the shared base, *without*
+  `prettier-plugin-tailwindcss` (that's `apps/web`'s own config, already
+  wired by `hedgehog-bootstrap-full-stack-app-core`).
+
+A per-app override request signals to fix the base config at the source.
+
+## After Bootstrap
+
+Once every `on` add-on in `.hedgehog/addons.yaml` has its commit landed
+(core's commit already landed via
+`hedgehog-bootstrap-full-stack-app-core`), hand off to `hedgehog-loop` —
+from here, every domain module goes through Phase A layers one at a
+time via `hedgehog next`/`hedgehog verify`, each its own commit.
+
+## Constraints
+
+- Run `hedgehog-bootstrap-full-stack-app-core` first, unconditionally, before any step
+  in this file — never scaffold an add-on against a core that hasn't
+  landed and verified clean.
+- Add-on steps (Auth, Queue, Mobile) run only if `.hedgehog/addons.yaml`
+  (written by `planner` at planning intake) turns that add-on on — say so
+  plainly and skip otherwise, don't leave it ambiguous whether the step
+  was considered.
+- Don't add domain schema, contracts, or any `libs/<module>/*` content —
+  that's Phase A, started after Bootstrap, one module at a time.
+- Don't deviate from the package/library choices above, for whichever
+  steps actually run. If a generator or package name changed upstream
+  since this was written, verify against current docs before running the
+  command — don't substitute a different library. Skipping an add-on
+  step whose trigger genuinely isn't in scope is not a deviation; adding
+  a library the stack doesn't call for, or dropping one it does, is.
+- Each step that runs is its own commit, in order — same unit-of-work
+  discipline as every other step in the discipline, even though this is
+  infra rather than a domain module.
+- Never substitute a natively-installed Postgres or Redis, even to match
+  a contributor's existing local setup — see `hedgehog-bootstrap-full-stack-app-core`'s
+  **Local infra: Docker, always**.