@skyf0xx/hedgehog-core-full-stack-app 1.0.9 → 1.0.11

package/agents/ux-planner.md

@@ -85,6 +85,16 @@ mockup, not a design system, not code:
    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.
+6. **Platform divergence**, only when the Mobile add-on is on: a section
+   stating, per module, whether `apps/web` and `apps/mobile` match or
+   diverge on — the navigation model on each platform; how the
+   create/edit form is presented (inline, modal, or its own route/screen)
+   on each platform; and list density and what a row shows on each
+   platform. State each shared decision once, in the sections above, and
+   use this section only to call out where a platform genuinely diverges
+   from it, and why — not to restate the web description in mobile
+   terms. Say what you decided, not what the answer should generically
+   be. Omit this section entirely when Mobile is off — no empty heading.
 
 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
@@ -123,28 +133,35 @@ conclusion.
 
 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
+2. Read `.hedgehog/addons.yaml` to determine whether the Mobile add-on is
+   on (`mobile.on`) for this project — the same file `bootstrap` and
+   `reviewer` already read as the source of truth for add-on state. This
+   decides whether "What you produce," above, needs a platform section.
+3. 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
+   notes nor the spec covers what you need, that gap goes into step 4's
    ask — it is not something to fill in yourself.
-3. Announce the Phase B transition and ask for visual input, per "When
+4. 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
+5. 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
+6. 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
+7. 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
+   first, external conventions second). When Mobile is on, this is also
+   where you look for prior platform-divergence calls to stay consistent
+   with.
+8. Write `docs/design/<module>.md` per "What you produce," above.
+9. 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.
+   (`feat(<module>): screen-web`, or `feat(<module>): screen` when the
+   Mobile add-on is on), same as any other file `front-end-eng` touches
+   while building that step.
 
 ## Constraints
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@skyf0xx/hedgehog-core-full-stack-app",
-  "version": "1.0.9",
+  "version": "1.0.11",
   "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",
   "scripts": {

package/skills/hedgehog-bootstrap/SKILL.md

@@ -236,18 +236,50 @@ 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
+npx nx g @nx/expo:app apps/mobile --unitTestRunner=jest
+npx @react-native-reusables/cli@latest init
+npx @react-native-reusables/cli@latest add button text
 ```
 
-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`.
+`@nx/expo:app`'s own default for `--unitTestRunner` is `none` — pass it
+explicitly, or `apps/mobile` has no `test` target at all and the `screen`
+layer's verify command below fails on a missing target rather than a
+real test.
+
+React Native Reusables ships as a CLI, same copy-you-own-the-code model
+as `apps/web`'s ShadCN setup, not a plain npm dependency: `init` wires
+NativeWind and the `@/*` path alias into `apps/mobile/tsconfig.json`
+(matching `apps/web`'s own `components.json` alias); `add` copies the
+named components' source into `apps/mobile/src/components/ui/`. `button`
+and `text` are the two the `screen` generator's mobile output imports —
+add any further components `front-end-eng` needs the same way, per
+module, as it builds.
+
+Edit `init`'s generated theme (`tailwind.config.js` colors, light/dark)
+to match `apps/web`'s base theme (landed by
+`hedgehog-bootstrap-full-stack-app-core`) rather than its own default
+palette — 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.
 
+**Set the `screen` generator's platform default to both.** The generator
+ships defaulting to `web` alone — this is the one Bootstrap step that
+knows `apps/mobile` exists, so it's where the default widens. Add a
+`generators` entry to root `nx.json`:
+
+```json
+"generators": {
+  "hedgehog:screen": {
+    "platforms": "web,mobile"
+  }
+}
+```
+
+so every module's `screen` layer task runs the generator against both
+platforms without each dispatch having to pass `--platforms` by hand.
+
 **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
@@ -256,11 +288,26 @@ 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}/**"]
+    scope:
+      [
+        "apps/web/src/app/{module}/**",
+        "apps/mobile/src/{module}/**",
+        "apps/mobile/src/app/{module}.tsx",
+      ]
     verify: "pnpm nx test web -- src/app/{module}/ && pnpm nx test mobile -- src/{module}/"
-    commit: "feat({module}): screen-web"
+    commit: "feat({module}): screen"
 ```
 
+The third scope entry is the mobile route file itself: Expo Router only
+resolves routes under `src/app/`, so `screen`'s mobile output has a thin
+route re-export there (mirroring `apps/web`'s own `page.tsx`) alongside
+the screen/form/spec under `src/{module}/`. Both paths need to be in
+scope, or `hedgehog verify` flags the route file as an unscoped write on
+every module.
+
+The commit message drops the `-web` suffix here because the layer now
+covers both platforms, not just 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

package/skills/hedgehog-loop/SKILL.md

@@ -75,6 +75,8 @@ controller  (thin HTTP)
 hook        (TanStack Query)       — Phase B only
 ```
 
+This is what `workspace/core.yaml` declares as `pattern: vertical-slice` — every layer's scope carries `{module}`, so the chain above runs once per module, independently, joined only at the exclusive `join` layer.
+
 Plus, when an operation needs async **and the Queue add-on is on for this
 project** (check `.hedgehog/addons.yaml`'s `queue.on`): **queue = port +
 BullMQ adapter**, same port/adapter shape as the repository. The service
@@ -120,7 +122,7 @@ before frontend work starts.
 |---|---|---|---|
 | 6 | `hook` | `packages/hooks` (TanStack Query) | `feat(<module>): hooks` |
 | 6a | UX rationale | `docs/design/<module>.md`, `ux-planner` agent | bundled into layer 7's commit |
-| 7 | `screen` | `apps/web`, plus `apps/mobile` when the Mobile add-on is on | `feat(<module>): screen-web` |
+| 7 | `screen` | `apps/web`, plus `apps/mobile` when the Mobile add-on is on | `feat(<module>): screen-web`, or `feat(<module>): screen` when the Mobile add-on is on |
 
 Phase B starts once Phase A is done for the scope. The frontend is a pure
 consumer of an already-finished API. Delegate each module's Phase B
@@ -202,10 +204,7 @@ outcome of the whole intent, not just this layer's objective. A layer's
 verify command runs the tests that layer wrote, so it measures internal
 consistency, never coverage of what was asked; build the layer's share of
 the goal and say so when the packet doesn't account for something the
-goal asks for. How deep those tests need to go is not uniform across
-layers — see `hedgehog-authored-loop`'s "Test depth follows verify
-radius" for the rule (`verify_radius`/`exclusive: true` mark where the
-real bar and the `reviewer` pass belong). Every per-module layer here has
+goal asks for. Every per-module layer here has
 its verify radius equal to its own scope by construction (`core.yaml`'s
 own header comment says so) — internally-consistent-only. The real
 integration point is `join`, the workspace-wide `exclusive: true` layer

package/workspace/core.yaml

@@ -17,6 +17,7 @@
 # every test once after every module's layers land, in exchange for those
 # layers running in parallel.
 id: full-stack-app
+pattern: vertical-slice
 layers:
   - id: schema
     scope: ["packages/db/src/schema/{module}/**", "packages/db/src/schema/index.ts"]

package/workspace/package.json

@@ -14,17 +14,17 @@
     "@nestjs/schematics": "^11.0.0",
     "@nestjs/testing": "^11.0.0",
     "@next/eslint-plugin-next": "^16.1.6",
-    "@nx/devkit": "23.1.0",
-    "@nx/eslint": "^23.1.0",
-    "@nx/eslint-plugin": "^23.1.0",
-    "@nx/js": "^23.1.0",
-    "@nx/nest": "23.1.0",
-    "@nx/next": "23.1.0",
-    "@nx/node": "23.1.0",
-    "@nx/playwright": "23.1.0",
-    "@nx/vitest": "23.1.0",
-    "@nx/web": "23.1.0",
-    "@nx/webpack": "23.1.0",
+    "@nx/devkit": "23.1.2",
+    "@nx/eslint": "23.1.2",
+    "@nx/eslint-plugin": "23.1.2",
+    "@nx/js": "23.1.2",
+    "@nx/nest": "23.1.2",
+    "@nx/next": "23.1.2",
+    "@nx/node": "23.1.2",
+    "@nx/playwright": "23.1.2",
+    "@nx/vitest": "23.1.2",
+    "@nx/web": "23.1.2",
+    "@nx/webpack": "23.1.2",
     "@playwright/test": "^1.37.0",
     "@swc-node/register": "~1.11.1",
     "@swc/cli": "~0.8.1",
@@ -49,10 +49,10 @@
     "eslint-plugin-jsx-a11y": "6.10.1",
     "eslint-plugin-playwright": "^1.6.2",
     "eslint-plugin-react": "^7.35.0",
-    "eslint-plugin-react-hooks": "5.0.0",
+    "eslint-plugin-react-hooks": "7.1.1",
     "jsdom": "^30.0.1",
     "lefthook": "^2.1.10",
-    "nx": "23.1.0",
+    "nx": "23.1.2",
     "prettier": "~3.6.2",
     "tslib": "^2.3.0",
     "typescript": "~6.0.3",
@@ -83,7 +83,16 @@
     "onlyBuiltDependencies": [
       "lefthook"
     ],
+    "peerDependencyRules": {
+      "allowedVersions": {
+        "eslint-plugin-import>eslint": "10",
+        "eslint-plugin-jsx-a11y>eslint": "10",
+        "eslint-plugin-react>eslint": "10",
+        "@exodus/bytes>@noble/hashes": "1"
+      }
+    },
     "overrides": {
+      "@nx/module-federation": "23.1.2",
       "esbuild": "0.25.12",
       "axios": "^1.18.0",
       "brace-expansion@1": "^1.1.18",