@starci/hfs 4.0.8 → 4.0.9

package/runtime/knowledge/hfs/canon-pins.yaml

@@ -3,14 +3,12 @@ purpose: >-
   The exact version of every dependency a StarCi product repository pins. One version per dependency for the whole
   family. Raising a version is a change to this file first (with the package bump when it is a @starci package),
   then the repositories' own upgrade lane (each sets the exact version and reinstalls; nothing else installs a @starci package). Read on 2026-09-29 from the packages under
-  .claude/packages and from the installed node_modules of nivo-backend, nivo-fe, starci-next, starci-next-fe,
-  mia-mia-backend and miamia-fe; where they disagreed the newest version installed in more than one repository
-  won, and the runtime's own version won for @starci packages. An app (hfs 4) has ONE package.json for both sides, so a
+  .claude/packages and from the installed node_modules of the six product repositories; where they disagreed the
+  newest version installed in more than one repository won, and the runtime's own version won for @starci packages.
+  An app (hfs 4) has ONE package.json for both sides, so a
   dependency both sides declared at different versions takes one: its pin where it has one, otherwise the higher of the
-  two, pinned here with a why (2026-10-01, from nivo-backend/nivo-fe, starci-next/starci-next-fe and
-  mia-mia-backend/miamia-fe: every such conflict but graphql was already pinned). The runtime's example apps merged the
-  same way on 2026-10-01 (examples/todo-app from todo-app-backend/todo-app-frontend, examples/ecommerce-app from
-  ecommerce-app-be/ecommerce-app-fe): no dependency outside this file was declared at two versions across their sides, so
+  two, pinned here with a why (2026-10-01: every such conflict but graphql was already pinned). The runtime's example apps
+  merged the same way on 2026-10-01: no dependency outside this file was declared at two versions across their sides, so
   every choice is a pin (each side's older @starci pins and graphql moved to the version here). `side` names the side whose code uses
   the dependency; the app root package.json carries the pins of both.
 pins:
@@ -29,23 +27,23 @@ pins:
     install: registry
     side: fe
     source: packages/grammar/package.json
-    why: nivo-fe pins 0.4.11 and 0.5.0 in one workspace, starci-next-fe 0.5.1, miamia-fe 0.5.0; the runtime source is 0.8.0 (the brand layer sets `--font-sans` and `--font-mono`; the grammar reads them; 0.7.2 added the Input tel kind and IconButton disclosure props).
+    why: the product front ends pinned older versions (0.4.11, 0.5.0, 0.5.1); the runtime source is 0.8.0 and wins for a @starci package (the brand layer sets `--font-sans` and `--font-mono`; the grammar reads them; 0.7.2 added the Input tel kind and IconButton disclosure props).
   '@starci/eslint-canon-be':
-    version: 3.0.8
+    version: 3.0.9
     group: starci
     install: registry
     side: be
     source: packages/eslint/be/package.json
     why: '3.0.3: its bundled canon-pins copy pins stylelint-canon 2.0.2 and hfs 4.0.3; no rule changed. 3.0.2: its bundled runtime copies (slots, canon-pins, failure codes, the architecture machine) put .starcistacks and .sops.yaml at the app root (app.starcistacks, app.sops) and pin hfs 4.0.2. 3.0.1: its bundled canon-pins copy pins hfs 4.0.1. 3.0.0: `loadHfs(import.meta.url)` of be/eslint.config.mjs finds the app-root hfs.json (kind app) and gives every linted file the view of the be side; the project graph is built per side. 2.0.0 (C0 release): starciBeConfig({ hfs: loadHfs(import.meta.url) }) typed factory and the BE-CONVENTION laws.'
   '@starci/eslint-canon-fe':
-    version: 8.0.8
+    version: 8.0.9
     group: starci
     install: registry
     side: fe
     source: packages/eslint/fe/package.json
     why: '8.0.3: its bundled canon-pins copy pins stylelint-canon 2.0.2 and hfs 4.0.3; no rule changed. 8.0.2: its bundled runtime copies (slots, canon-pins, failure codes, the architecture machine) put .starcistacks and .sops.yaml at the app root (app.starcistacks, app.sops) and pin hfs 4.0.2. 8.0.1: its bundled canon-pins copy pins hfs 4.0.1. 8.0.0: `loadHfs(import.meta.url)` of fe/eslint.config.mjs finds the app-root hfs.json (kind app) and gives every linted file the view of the fe side; the project graph is built per side. 7.0.0: the front end has no tests (FE_NO_TESTS R97 in hfs); no-vietnamese-in-source (R91).'
   '@starci/stylelint-canon':
-    version: 2.0.3
+    version: 2.0.4
     group: starci
     install: registry
     side: fe
@@ -58,43 +56,55 @@ pins:
     side: both
     source: packages/tsconfig/package.json
   '@starci/prettier-config':
-    version: 1.0.1
+    version: 1.0.2
     group: starci
     install: registry
     side: both
     source: packages/prettier-config/package.json
   '@starci/jest-preset':
-    version: 2.2.3
+    version: 2.2.4
     group: starci
     install: registry
     side: be
     source: packages/jest-preset/package.json
-    why: '2.2.2: the unit run writes the lcov Sonar and Codecov import (services only); 2.2.0: the integration, e2e and contract projects run every spec file in a worker process of its own (world-runner.cjs), so a process-global framework registry (@nestjs/graphql type metadata) never leaks between e2e files; 2.1.0: four projects on the test world, the unit kit (mockEntityManager, fakeTransaction, fakeIds, FakeClock, Outcome matchers) and the recordingOutbox claim side.'
+    why: '2.2.4: the world runner runs up to min(--maxWorkers, slots) world files at once, each in its own process bound to one data slot of the test world (STARCI_TEST_WORLD_SLOT), and reads test-world state protocol 2 only: pinned together with @starci/test-world 1.1.0, any other state file is JEST_PRESET_WORLD_PAIR_MISMATCH. 2.2.3: republished after the move (no preset change). 2.2.2: the unit run writes the lcov Sonar and Codecov import (services only); 2.2.0: the integration, e2e and contract projects run every spec file in a worker process of its own (world-runner.cjs), so a process-global framework registry (@nestjs/graphql type metadata) never leaks between e2e files; 2.1.0: four projects on the test world, the unit kit (mockEntityManager, fakeTransaction, fakeIds, FakeClock, Outcome matchers) and the recordingOutbox claim side.'
   '@starci/test-world':
-    version: 1.0.6
+    version: 1.2.0
     group: starci
     install: registry
     side: be
     source: packages/test-world/package.json
-    why: '1.0.5: a modules world boots real peer apps beside its modules, world.apps.<name>.during(fn) is the outage of a peer app, and w.keycloak.clientSecret(client) answers the run-generated secret of a confidential realm client. 1.0.4: world.resolve and scope.resolve take any Nest token (class, string or symbol). 1.0.3: the globalSetup registers the path aliases as TypeScript resolves them (the extends chain, paths from the config that declares them, the effective baseUrl), so a tests tsconfig that only extends the side config loads the declaration. 1.0.2: every path a declaration names (`stack`, seeds, the realm, Dockerfiles) resolves from the app root (the directory of hfs.json), where .starcistacks lives, never from the be side. The shared e2e library of every back end (R47, R48): the warm stack behind toxiproxy, the network-edge fakes, the Nest boot, the typed useTestWorld handle, useSandbox for contract specs, the outage lock and the starci-test-stack bin behind the managed test:stack script; a devDependency of every back end. 1.0.1: world.keycloak.events/sessions (the user events of the realm and live sessions through the admin API) and world.infra.postgresql.connection(name) (the database of one connection down while the others serve, under the outage lock).'
+    why: '1.2.0: Kafka as real own infra (the one digest-pinned apache/kafka KRaft image, a broker listener and proxy per slot, slot-prefixed topics, consumer groups and client ids) and schema-per-context Postgres (a schema and a login role per context in a shared database); its CLI main is exported at ./cli for starci app stack, and the former starci app stack bin is removed. 1.1.0: per-worker data slots: a run provisions min(jest workers, workers cap, default 2) slots, each its own namespace (<ns>_w<k>) with its own databases, Keycloak realm, leased Redis DB, bucket/collection/topic prefixes, fakes host, toxiproxy proxies and outage lock, so world files run in parallel; state file protocol 2, paired exactly with @starci/jest-preset 2.2.4 (TEST_WORLD_PAIR_MISMATCH otherwise). 1.0.6: republished after the move (no library change). 1.0.5: a modules world boots real peer apps beside its modules, world.apps.<name>.during(fn) is the outage of a peer app, and w.keycloak.clientSecret(client) answers the run-generated secret of a confidential realm client. 1.0.4: world.resolve and scope.resolve take any Nest token (class, string or symbol). 1.0.3: the globalSetup registers the path aliases as TypeScript resolves them (the extends chain, paths from the config that declares them, the effective baseUrl), so a tests tsconfig that only extends the side config loads the declaration. 1.0.2: every path a declaration names (`stack`, seeds, the realm, Dockerfiles) resolves from the app root (the directory of hfs.json), where .starcistacks lives, never from the be side. The shared e2e library of every back end (R47, R48): the warm stack behind toxiproxy, the network-edge fakes, the Nest boot, the typed useTestWorld handle, useSandbox for contract specs and the outage lock; a devDependency of every back end. 1.0.1: world.keycloak.events/sessions (the user events of the realm and live sessions through the admin API) and world.infra.postgresql.connection(name) (the database of one connection down while the others serve, under the outage lock).'
+  '@starci/cli':
+    version: 1.0.0
+    group: starci
+    install: registry
+    side: both
+    source: packages/cli/package.json
+    why: '1.0.0: the only StarCi command package; product repositories install it for starci app, while @starci/hfs remains its pinned transitive implementation.'
   '@starci/hfs':
-    version: 4.0.8
+    version: 4.0.9
     group: starci
     install: registry
     side: both
     source: packages/hfs/package.json
-    why: '4.0.3: its bundled canon-pins copy pins stylelint-canon 2.0.2, eslint-canon-be 3.0.3 and eslint-canon-fe 8.0.3 (what `hfs scaffold app` writes); the package gains its own clean-install test. 4.0.2: .starcistacks and .sops.yaml live at the app root (slots app.starcistacks, app.sops; a side holding either is refused, HFS_STACKS_IN_SIDE), the managed .gitignore block carries the custody rules, the scaffold writes them at the root. 4.0.1: `hfs scaffold app` resolves the real lockfile with npm (`npm install --package-lock-only`) instead of writing a root-only stub that `npm ci` refuses. 4.0.0: the app monorepo standard: one app repository with the root package.json, lockfile and hfs.json of kind app, and the be/ and fe/ sides; `hfs scaffold app <name>` makes it, `hfs lint` at the root lints be/** with the BE canon and fe/** with the FE canon; the standalone be/fe repository kinds and `hfs init` are deleted.'
+    why: '4.0.9: the transitive app implementation used by @starci/cli; it carries the generated runtime slice read by starci app commands.'
   # --- tooling
   typescript:
     version: 5.9.3
     group: tooling
     side: both
-    why: all six repositories resolve 5.9.3 already; the declared ranges (^5, ^5.7.3) become exact.
+    why: all six product repositories resolve 5.9.3 already; the declared ranges (^5, ^5.7.3) become exact.
+  turbo:
+    version: 2.11.6
+    group: tooling
+    side: fe
+    why: 'every app is a monorepo (R143): turbo runs build, dev, lint and typecheck over the fe workspaces fe/apps/* and fe/packages/* from the app root turbo.json, as nivo-fe does; 2.11.6 is the newest 2.x on 2026-10-02.'
   prettier:
     version: 3.9.6
     group: tooling
     side: both
-    why: only nivo-backend has it installed (3.9.6); the other five adopt it with the formatter change.
+    why: only one product repository had it installed (3.9.6); the other five adopt it with the formatter change.
   stylelint:
     version: 17.15.0
     group: tooling
@@ -109,7 +119,7 @@ pins:
     version: 9.39.5
     group: tooling
     side: both
-    why: five repositories resolve 9.39.5, nivo-backend 9.39.4.
+    why: five product repositories resolve 9.39.5, the sixth 9.39.4.
   eslint-plugin-react-hooks:
     version: 7.1.1
     group: tooling
@@ -119,7 +129,42 @@ pins:
     version: 22.20.4
     group: tooling
     side: both
-    why: nivo-fe resolves 20.19.43 and nivo-backend 22.20.0; the package engines are node >=22.
+    why: one front end resolves 20.19.43 and one back end 22.20.0; the package engines are node >=22.
+  '@types/express':
+    version: 4.17.25
+    group: tooling
+    side: be
+    why: the Express types of a back end; the reference app declares ^4.17.21 and resolves 4.17.25.
+  '@types/react':
+    version: 19.3.0
+    group: tooling
+    side: fe
+    why: the React types of a front end; the reference app declares ^19.0.0 and resolves 19.3.0.
+  '@types/react-dom':
+    version: 19.3.0
+    group: tooling
+    side: fe
+    why: the React DOM types of a front end; the reference app declares ^19.0.0 and resolves 19.3.0.
+  husky:
+    version: 9.1.7
+    group: tooling
+    side: both
+    why: the managed git hooks of the app root (pre-commit, pre-push); the reference app declares ^9.1.7 and resolves 9.1.7.
+  ts-node-dev:
+    version: 2.0.0
+    group: tooling
+    side: be
+    why: 'the watch runner of the managed dev:be:<app> script (ts-node-dev --respawn -r tsconfig-paths/register); 2.0.0 is its latest release.'
+  tsc-alias:
+    version: 1.9.7
+    group: tooling
+    side: be
+    why: 'rewrites the path aliases in the compiled output (build:be); the reference app declares ^1.8.10 and resolves 1.9.7.'
+  tsconfig-paths:
+    version: 4.2.0
+    group: tooling
+    side: be
+    why: 'loads the path aliases for the dev runner (dev:be:<app>); the reference app declares ^4.2.0 and resolves 4.2.0.'
   # --- test
   jest:
     version: 29.7.0
@@ -146,11 +191,16 @@ pins:
     version: 19.2.3
     group: framework
     side: fe
+  nest-commander:
+    version: 3.21.0
+    group: framework
+    side: be
+    why: 'the one command-line framework of a back end (R148-R150): apps/cli boots with CommandFactory.run and every one-off action is a nest-commander command of src/features/cli; 3.21.0 is the newest on 2026-10-02 and takes @nestjs 11 as its peer.'
   '@nestjs/core':
     version: 11.2.5
     group: framework
     side: be
-    why: nivo-backend resolves 11.1.27, starci-next and mia-mia-backend 11.2.5.
+    why: one product back end resolves 11.1.27, the others 11.2.5.
   '@nestjs/common':
     version: 11.2.5
     group: framework
@@ -167,30 +217,111 @@ pins:
     version: 11.1.1
     group: framework
     side: be
-    why: readiness probes with dependency indicators use Terminus (the liveness route of the hfs sync --init skeleton does not, being a thin door over the liveness service); nivo-backend, starci-next and mia-mia-backend all resolve 11.1.1.
+    why: readiness probes with dependency indicators use Terminus (the liveness route of the scaffolded skeleton does not, being a thin door over the liveness service); every measured product back end resolves 11.1.1.
+  '@nestjs/cqrs':
+    version: 11.0.3
+    group: framework
+    side: be
+    why: 'the CQRS module of the application layer (commands, queries, handlers); the reference app declares ^11.0.3 and resolves 11.0.3.'
+  '@nestjs/typeorm':
+    version: 11.0.3
+    group: framework
+    side: be
+    why: 'the Nest bridge of TypeORM; the reference app declares ^11.0.3 and resolves 11.0.3.'
+  typeorm:
+    version: 0.3.31
+    group: framework
+    side: be
+    why: 'the one ORM of a back end; the reference app declares ^0.3.20 and resolves 0.3.31.'
+  pg:
+    version: 8.23.1
+    group: framework
+    side: be
+    why: 'the Postgres driver behind TypeORM; the reference app declares ^8.12.0 and resolves 8.23.1.'
+  reflect-metadata:
+    version: 0.2.2
+    group: framework
+    side: be
+    why: 'the decorator-metadata runtime Nest reads; the reference app declares ^0.2.2 and resolves 0.2.2.'
+  rxjs:
+    version: 7.8.2
+    group: framework
+    side: be
+    why: 'the observable runtime Nest is built on; the reference app declares ^7.8.1 and resolves 7.8.2.'
+  tslib:
+    version: 2.8.1
+    group: framework
+    side: be
+    why: 'the helper runtime the TypeScript emit references (importHelpers); the reference app declares ^2.8.1 and resolves 2.8.1.'
+  server-only:
+    version: 0.0.1
+    group: framework
+    side: fe
+    why: 'the Next.js marker that fails a client bundle that imports it; the i18n workspace of the reference app declares ^0.0.1.'
   next-intl:
     version: 4.13.6
     group: framework
     side: fe
-    why: every HFS front end uses next-intl with the [locale] segment (hfs sync --init writes it); nivo-fe resolves 4.13.6.
+    why: every HFS front end uses next-intl with the [locale] segment (starci app scaffold writes it); the measured front end resolves 4.13.6.
   graphql:
     version: 16.14.2
     group: framework
     side: both
-    why: 'one app package.json for both sides (hfs 4): nivo-backend declares ^16.14.1 and nivo-fe ^16.14.2, the higher wins; all four product installs resolve 16.14.2. The example apps: todo-app-backend declared ^16.14.2 (devDependencies) and ecommerce-app-be ^16.14.2 (dependencies and devDependencies); each app root now has one dependencies entry at the pin.'
+    why: 'one app package.json for both sides (hfs 4): where the two sides declared different ranges (^16.14.1 on a back end, ^16.14.2 on a front end), the higher wins; the measured product installs resolve 16.14.2. The example apps declared ^16.14.2 as well; each app root now has one dependencies entry at the pin.'
   supertest:
     version: 7.3.0
     group: tooling
     side: be
-    why: the e2e world of a back end calls the app over HTTP (/health/live in the skeleton); starci-next and mia-mia-backend resolve 7.3.0, nivo-backend 7.2.2.
+    why: the e2e world of a back end calls the app over HTTP (/health/live in the skeleton); two product back ends resolve 7.3.0, one 7.2.2.
   # --- ui
   '@heroui/react':
     version: 3.2.6
     group: ui
     side: fe
-    why: nivo-fe resolves 3.2.4, starci-next-fe and miamia-fe 3.2.6.
+    why: one product front end resolves 3.2.4, the others 3.2.6.
   '@heroui/styles':
     version: 3.2.6
     group: ui
     side: fe
-    why: nivo-fe resolves 3.2.4, starci-next-fe and miamia-fe 3.2.6.
+    why: one product front end resolves 3.2.4, the others 3.2.6.
+  tailwindcss:
+    version: 4.3.3
+    group: ui
+    side: fe
+    why: 'the styling engine of a front end; the reference app declares ^4 and resolves 4.3.3.'
+  '@tailwindcss/postcss':
+    version: 4.3.3
+    group: ui
+    side: fe
+    why: 'the PostCSS plugin tailwindcss 4 runs through; the reference app declares ^4 and resolves 4.3.3.'
+  # --- Supabase lite
+  '@supabase/ssr':
+    version: 0.12.7
+    group: framework
+    side: fe
+    why: the one server/browser client factory for a lite Next app; exact version registry-checked for the lite scaffold.
+  '@supabase/supabase-js':
+    version: 2.117.2
+    group: framework
+    side: both
+    why: the generated Database-typed client used by the FE data owner and the BE Auth/Storage integration.
+  jose:
+    version: 6.2.12
+    group: framework
+    side: be
+    why: verifies Supabase access tokens against the project JWKS with issuer, audience, expiry and algorithm checks.
+  supabase:
+    version: 2.119.0
+    group: tooling
+    side: both
+    why: the root CLI wrapper owns local schema lifecycle and generates the committed database types.
+  class-transformer:
+    version: 0.5.1
+    group: framework
+    side: be
+    why: Nest request transformation in the API runtime, pinned with the validation library.
+  class-validator:
+    version: 0.15.1
+    group: framework
+    side: be
+    why: Nest boundary validation in the API runtime, pinned with the transformation library.

package/runtime/knowledge/hfs/peer-integrations.yaml

@@ -2,8 +2,8 @@ schema: starci/hfs-peer-integrations@1
 purpose: >-
   The runtime peers a driver integration needs and npm does not install for it: "if the app depends on every package of
   `when` (at the named major, when one is named), it must declare `requires` in its dependencies". A missing peer is
-  invisible to the type checker and the unit specs and only fails when the api boots (todo-app and ecommerce-app,
-  2026-10-01: neither old backend declared @as-integrations/express5, so the Apollo GraphQL api could not boot under
+  invisible to the type checker and the unit specs and only fails when the api boots (ecommerce-app,
+  2026-10-01: the old backend did not declare @as-integrations/express5, so the Apollo GraphQL api could not boot under
   Express 5 and nothing noticed before e2e). R111 HFS_PEER_INTEGRATION_MISSING judges the app root package.json, the one
   manifest of both sides, with this catalog; an entry is added the day a boot failure of the same kind is found.
 pairs: