@starci/hfs 4.3.0 → 4.4.0

package/runtime/knowledge/patterns/be/api.yaml

@@ -249,7 +249,7 @@ rules:
   - id: BE-API-4
     title: An api app parses env separately and composes in area groups; its options hold values and port bindings only
     kind: mandatory
-    hfsRules: [R245, R246, R32, R45, R43]
+    hfsRules: [R245, R246, R32, R45, R43, R265, R289]
     requirement: |-
       An app's `src/` (slot `be.app.api`, and alike `be.app.worker` and `be.app.cli`) holds five app roles, each within the
       line budget its slot names (owner ruling 2026-10-14):
@@ -269,13 +269,17 @@ rules:
         listing `*Module` classes, module or queue registrations (`register`, `forRoot`, `registerQueue`) or scheduler entries,
         or an `imports`, `modules`, `schedulers` or `processors` list. The env file also refuses standalone module or queue
         registration calls (`BE_APP_OPTIONS_COMPOSITION`).
-      - `compose/<area>.ts` (120) is a composition group: it exports the module list of one area of the app (the platform, the
+      - `compose/<area>.ts` (120) is a composition group: it exports explicitly typed module, DynamicModule, Provider, queue or
+        scheduler lists and maps for one area of the app (the platform, the
         background mechanisms with their message and queue doors, a product area), as a function of the options when it needs
         them, and the providers of the area's global ports when it has any. It is composition only: no business logic, no
         environment read (no `parse<C>Config`, `process.env` or `EnvSource` reads), and its `X.register({ isGlobal: true, ...options.x })` calls
         count as the app root's registrations (R45).
-      - `app.module.ts` (250) imports the groups and spreads them into its `imports` (`...platformModules(options)`), registers
-        what is left, and binds the app-wide guards and filter.
+      - `app.module.ts` (250) imports the groups and spreads them into its `imports` (`...platformModules(options)`); its own
+        providers bind only the app-wide guards and filter. Module-list literals belong in the compose groups.
+      Resolved composition types establish these roles even when imports are aliased, a registration is saved to a constant,
+      or scheduler definitions use a typed constant array. `starci app add` writes and updates the generated feature's typed
+      area group. A compose group holds no business arrow, branch or other decision that belongs in a tested module.
       A file over its budget is `BE_APP_COMPOSITION_BUDGET`; the budget is absolute, so an app root that outgrows 250 lines
       moves an area into a new group, never into the env or options file. An entrypoint over 80 moves its parsing into the env file.
     rationale: |-
@@ -305,13 +309,16 @@ rules:
         - BE_MODULE_HANDLER_REGISTRATION
         - BE_MODULE_PROVIDER_REREGISTRATION
         - BE_CONFIG_OWNER
+        - BE_COMPOSITION_UNTYPED
+        - BE_APP_ENV_REQUIRED
+        - BE_APP_MODULE_LIST_INLINE
       manual:
         - Confirm each group is one area of the app and holds no decision a capability should own.
     relatedExamples: [api]
   - id: BE-OPERATIONS-1
     title: A versioned operation is declared once in the app's typed operation table
     kind: mandatory
-    hfsRules: [R95, R88, R23]
+    hfsRules: [R95, R88, R23, R278]
     requirement: |-
       A versioned operation `<name>@<version>` (for example `sales.policy@1`) that an app serves over one operation route is
       declared once, in the app's operation table `be/apps/<app>/src/operations.ts`, which exports `OPERATIONS`. The table is made by
@@ -324,6 +331,8 @@ rules:
       outcome }` out, `outcome` being the canon Outcome `{ kind: "ok", value }` or `{ kind: "refused", code }`. `starci app emit`
       derives `be/contracts/<app>/openapi.json` (OpenAPI 3.1, `x-operation: "<name>@<version>"`, a oneOf over the operations) from the
       table with the type checker, and the full `starci app check` fails when the committed file is stale.
+      A public REST operation in either edition belongs to this nonempty table, and its route decorator supplies its own
+      versioned-operation evidence; a class-level reference does not justify a route absent from the table.
     rationale: |-
       The operation set of an app is a contract the front end (`fe/`, through the root codegen) and other consumers generate a client from. A name-to-string registry with `unknown`
       bodies and results forces every client to hand-type the wire; one typed table gives the client generator, the route and the
@@ -345,6 +354,8 @@ rules:
         - BE_OPERATION_CONTRACT
         - BE_TRANSPORT_SHAPE
         - HFS_CONTRACT_SNAPSHOT_DRIFT
+        - BE_REST_DOOR_EVIDENCE
+        - BE_REST_ROUTE_UNDECLARED
       manual:
         - Confirm each refusal code is one the operation's owner can actually answer.
     relatedExamples: [api]
@@ -354,6 +365,14 @@ files:
     role: The public surface of the feature; only apps import it.
     rules: [BE_PUBLIC_SURFACE]
     template: api/feature.index.ts.tpl
+  - path: src/features/api/<feature>/<feature>.options.ts
+    slot: be.feature
+    template: api/feature.options.ts.tpl
+    role: The options of the module (the configurable module base needs a type); empty until the module takes some.
+  - path: src/features/api/<feature>/<feature>.module-definition.ts
+    slot: be.feature
+    template: api/feature.module-definition.ts.tpl
+    role: The configurable-module base of the module, registered as register.
   - path: src/features/api/<feature>/<feature>.module.ts
     slot: be.feature
     role: Composes the application handlers.
@@ -388,6 +407,14 @@ files:
     slot: be.transport.graphql
     role: Maps the input to the request and the result to the type.
     template: api/graphql.mapper.ts.tpl
+  - path: src/features/api/<feature>/transport/graphql/<feature>-graphql.options.ts
+    slot: be.transport.graphql
+    template: api/graphql.options.ts.tpl
+    role: The options of the module (the configurable module base needs a type); empty until the module takes some.
+  - path: src/features/api/<feature>/transport/graphql/<feature>-graphql.module-definition.ts
+    slot: be.transport.graphql
+    template: api/graphql.module-definition.ts.tpl
+    role: The configurable-module base of the module, registered as register.
   - path: src/features/api/<feature>/transport/graphql/<feature>-graphql.module.ts
     slot: be.transport.graphql
     role: One module for the whole GraphQL transport of the feature.

package/runtime/knowledge/patterns/be/cli.yaml

@@ -81,14 +81,15 @@ rules:
   - id: BE-CLI-2
     title: Commands live in the cli feature root as groups and sub-commands
     kind: mandatory
-    hfsRules: [R149]
+    hfsRules: [R149, R295]
     requirement: |-
       A nest-commander command (`@Command` or `@SubCommand`) is declared only in the cli feature root `src/features/cli/`
       (slot `be.cli`). The root holds `index.ts` and `cli.module.ts` and one folder per group: `<group>/<group>.cli.ts` (the
       group `@Command` with its `subCommands`), `<group>/<group>.module.ts` and `<group>/subs/<name>.cli.ts` (a `@SubCommand`
-      class extending `CommandRunner`), one command per file. The cli feature root is a feature, so every module of it is a
-      static `@Module({ imports, providers })` with no module definition, no options file and no `register`: `CliModule`
-      imports each group module and a group module provides its commands. A command makes its one delegating call on an
+      class extending `CommandRunner`), one command per file. Every module of the cli feature root has a module definition
+      and an options file beside it (owner:module-definition-everywhere, R295) and declares only its `@Module({ imports,
+      providers })` metadata, with no `register` override: `CliModule` imports each group module as `<Group>Module.register({})`
+      and a group module provides its commands. A command makes its one delegating call on an
       injected runner service of the modules (the migrate and seed runners of `platform/database`) and takes its options
       from a nest-commander `@Option` of its own (`cli seed run --env <name>`). The suffix is
       `.cli.ts`, because `.command.ts` is the CQRS message (api.yaml).
@@ -102,6 +103,7 @@ rules:
     verification:
       automated:
         - BE_CLI_COMMAND_SHAPE
+        - BE_MODULE_DEFINITION_MISSING
       manual: []
     relatedExamples: [cli]
   - id: BE-CLI-3
@@ -287,6 +289,14 @@ files:
     slot: be.cli
     role: the unit spec of the group, beside it
     template: cli/group.cli.spec.ts.tpl
+  - path: src/features/cli/<group>/<group>.options.ts
+    slot: be.cli
+    template: cli/group.options.ts.tpl
+    role: The options of the module (the configurable module base needs a type); empty until the module takes some.
+  - path: src/features/cli/<group>/<group>.module-definition.ts
+    slot: be.cli
+    template: cli/group.module-definition.ts.tpl
+    role: The configurable-module base of the module, registered as register.
   - path: src/features/cli/<group>/<group>.module.ts
     slot: be.cli
     role: "the static group module: provides its command and sub-commands"

package/runtime/knowledge/patterns/be/event-bus.yaml

@@ -283,7 +283,7 @@ files:
     role: "The consumed event's e2e flow; titles event-bus/<scenario>: ... prove the pattern."
     spec: event-bus/atomic-with-transaction, event-bus/relay-only-after-commit, event-bus/redelivery-then-dead-letter, event-bus/duplicate-delivery-is-a-noop
     rules: [BE_PATTERN_SPEC_MISSING]
-# Edition lite (owner ruling 2026-10-12, R212 case-1): the same ports and rules, a Supabase adapter behind them.
+# Edition lite (R212, owner ruling 2026-10-14): the same ports and rules, a Supabase adapter behind them.
 liteAdapter:
   summary: >-
     Under lite the event bus keeps typed events, the vendored contract, publish(event, tx) in the domain transaction, the outbox,
@@ -295,6 +295,6 @@ liteAdapter:
     - {port: EventConsumer (platform/event-bus), adapter: "pgmq.read with a visibility timeout, the inbox claim on the event id, pgmq.delete on success, pgmq.archive as the dead letter"}
   forbids: [kafkajs]
   proof: >-
-    Unit specs as full; the event-bus/* scenarios are optional integration specs on `starci supabase start`, and there is no e2e
-    async spec (R155 and R167 are full's).
+    Unit specs as full; declaring event-bus requires integration specs titled `event-bus/<scenario>: ...` for every declared
+    scenario on `starci supabase start` (R284). Lite has no e2e world.
   see: [knowledge/patterns/be/supabase-queues.yaml]

package/runtime/knowledge/patterns/be/jobs.yaml

@@ -228,9 +228,25 @@ files:
   - path: src/features/jobs/<job>/index.ts
     slot: be.feature.jobs
     template: jobs/job.index.ts.tpl
+  - path: src/features/jobs/<job>/<job>.options.ts
+    slot: be.feature.jobs
+    template: jobs/job.options.ts.tpl
+    role: The options of the module (the configurable module base needs a type); empty until the module takes some.
+  - path: src/features/jobs/<job>/<job>.module-definition.ts
+    slot: be.feature.jobs
+    template: jobs/job.module-definition.ts.tpl
+    role: The configurable-module base of the module, registered as register.
   - path: src/features/jobs/<job>/<job>.module.ts
     slot: be.feature.jobs
     template: jobs/job.module.ts.tpl
+  - path: src/features/jobs/<job>/transport/queue/<job>-queue.options.ts
+    slot: be.feature.jobs.queue
+    template: jobs/job.queue.options.ts.tpl
+    role: The options of the module (the configurable module base needs a type); empty until the module takes some.
+  - path: src/features/jobs/<job>/transport/queue/<job>-queue.module-definition.ts
+    slot: be.feature.jobs.queue
+    template: jobs/job.queue.module-definition.ts.tpl
+    role: The configurable-module base of the module, registered as register.
   - path: src/features/jobs/<job>/transport/queue/<job>-queue.module.ts
     slot: be.feature.jobs.queue
     template: jobs/job.queue.module.ts.tpl
@@ -259,7 +275,7 @@ files:
     role: "Titles fenced-job/<scenario>: ... prove the pattern."
     spec: fenced-job/claim-bumps-token, fenced-job/zombie-fenced-out, fenced-job/redispatch-isolated
     rules: [BE_PATTERN_SPEC_MISSING]
-# Edition lite (owner ruling 2026-10-12, R212 case-1): the same ports and rules, a Supabase adapter behind them.
+# Edition lite (R212, owner ruling 2026-10-14): the same ports and rules, a Supabase adapter behind them.
 liteAdapter:
   summary: >-
     Under lite a fenced job is unchanged: the job row with its fencing token, the atomic claim, guarded writes and run keys. The
@@ -267,5 +283,7 @@ liteAdapter:
   ports:
     - {port: job claim (platform/jobs), adapter: "the same claim SQL through the shared EntityManager; the table comes from supabase/migrations"}
     - {port: processor delivery, adapter: "the lite queue worker (pgmq.read, visibility timeout, archive on dead letter)"}
-  proof: Unit specs as full (job-claim.service.spec.ts); the fenced-job/* scenarios are optional integration specs on `starci supabase start`.
+  proof: >-
+    Unit specs as full (job-claim.service.spec.ts); declaring fenced-job requires integration specs titled
+    `fenced-job/<scenario>: ...` for every declared scenario on `starci supabase start` (R284).
   see: [knowledge/patterns/be/supabase-queues.yaml]

package/runtime/knowledge/patterns/be/projections.yaml

@@ -176,7 +176,7 @@ files:
     role: "Titles projection/<scenario>: ... prove the pattern."
     spec: projection/recompute-is-idempotent, projection/replay-rebuilds
     rules: [BE_PATTERN_SPEC_MISSING]
-# Edition lite (owner ruling 2026-10-12, R212 case-1): the same ports and rules, a Supabase adapter behind them.
+# Edition lite (R212, owner ruling 2026-10-14): the same ports and rules, a Supabase adapter behind them.
 liteAdapter:
   summary: >-
     Under lite a projection is unchanged in behaviour (only it writes its table, recompute is idempotent and replayable, readers
@@ -184,5 +184,7 @@ liteAdapter:
     overlay), and it is kept current by a reactor or a job on the lite transport.
   ports:
     - {port: read model table, adapter: "a supabase migration plus <name>.sql.ts and <name>.rows.ts under persistence/"}
-  proof: Unit specs as full (the projection is a logic role at 100 per file); the projection/* scenarios are optional integration specs.
+  proof: >-
+    Unit specs as full (the projection is a logic role at 100 per file); declaring projection requires integration specs titled
+    `projection/<scenario>: ...` for every declared scenario on `starci supabase start` (R284).
   see: [knowledge/patterns/be/supabase-queues.yaml]

package/runtime/knowledge/patterns/be/queues.yaml

@@ -216,6 +216,14 @@ files:
   - path: src/modules/queues/<queue>/index.ts
     slot: be.queues
     template: queues/queue.index.ts.tpl
+  - path: src/modules/queues/<queue>/<queue>.options.ts
+    slot: be.queues
+    template: queues/queue.options.ts.tpl
+    role: The options of the module (the configurable module base needs a type); empty until the module takes some.
+  - path: src/modules/queues/<queue>/<queue>.module-definition.ts
+    slot: be.queues
+    template: queues/queue.module-definition.ts.tpl
+    role: The configurable-module base of the module, registered as register.
   - path: src/modules/queues/<queue>/<queue>.module.ts
     slot: be.queues
     role: The Nest module that provides the typed producer.
@@ -234,7 +242,7 @@ files:
     role: "Titles queue/<scenario>: ... prove the pattern."
     spec: queue/enqueue-atomic-with-transaction, queue/relay-job-id-is-outbox-id, queue/scheduler-fires-once
     rules: [BE_PATTERN_SPEC_MISSING]
-# Edition lite (owner ruling 2026-10-12, R212 case-1): the same ports and rules, a Supabase adapter behind them.
+# Edition lite (R212, owner ruling 2026-10-14): the same ports and rules, a Supabase adapter behind them.
 liteAdapter:
   summary: >-
     Under lite the queue pattern is unchanged above the port (producers, the outbox written in the caller's transaction, processors,
@@ -246,6 +254,6 @@ liteAdapter:
     - {port: schedulers, adapter: "a pg_cron job declared in a supabase migration that calls pgmq.send; no BullMQ job scheduler"}
   forbids: [bullmq, "@nestjs/bullmq", redis, ioredis, "@nestjs/schedule"]
   proof: >-
-    Unit specs as full (queue-outbox, relay and worker services, the pgmq client against mockEntityManager); the queue/* scenarios are
-    optional integration specs on `starci supabase start` (R155 is full's).
+    Unit specs as full (queue-outbox, relay and worker services, the pgmq client against mockEntityManager); declaring queue
+    requires integration specs titled `queue/<scenario>: ...` for every declared scenario on `starci supabase start` (R284).
   see: [knowledge/patterns/be/supabase-queues.yaml]

package/runtime/knowledge/patterns/be/reactors.yaml

@@ -114,6 +114,14 @@ files:
   - path: src/features/reactors/<reactor>/index.ts
     slot: be.feature.reactors
     template: reactors/reactor.index.ts.tpl
+  - path: src/features/reactors/<reactor>/<reactor>.options.ts
+    slot: be.feature.reactors
+    template: reactors/reactor.options.ts.tpl
+    role: The options of the module (the configurable module base needs a type); empty until the module takes some.
+  - path: src/features/reactors/<reactor>/<reactor>.module-definition.ts
+    slot: be.feature.reactors
+    template: reactors/reactor.module-definition.ts.tpl
+    role: The configurable-module base of the module, registered as register.
   - path: src/features/reactors/<reactor>/<reactor>.module.ts
     slot: be.feature.reactors
     template: reactors/reactor.module.ts.tpl
@@ -131,6 +139,14 @@ files:
     template: reactors/consumer.ts.tpl
     role: The consumer door of one event.
     rules: [BE_EVENT_CONSUMER_SHAPE]
+  - path: src/features/reactors/<reactor>/transport/message/<reactor>-message.options.ts
+    slot: be.transport.message
+    template: reactors/message.options.ts.tpl
+    role: The options of the module (the configurable module base needs a type); empty until the module takes some.
+  - path: src/features/reactors/<reactor>/transport/message/<reactor>-message.module-definition.ts
+    slot: be.transport.message
+    template: reactors/message.module-definition.ts.tpl
+    role: The configurable-module base of the module, registered as register.
   - path: src/features/reactors/<reactor>/transport/message/<reactor>-message.module.ts
     slot: be.transport.message
     template: reactors/message.module.ts.tpl
@@ -138,11 +154,14 @@ files:
   - path: src/tests/e2e/<area>/<event>.e2e-spec.ts
     slot: be.tests.e2e
     role: The reactor's event flow through the bus, redelivery included.
-# Edition lite (owner ruling 2026-10-12, R212 case-1): the same ports and rules, a Supabase adapter behind them.
+# Edition lite (R212, owner ruling 2026-10-14): the same ports and rules, a Supabase adapter behind them.
 liteAdapter:
   summary: >-
     Under lite a reactor is unchanged: a thin consumer of another context's events that dispatches one command. Its deliveries
     come from the lite event bus (its own pgmq queue per consumer group).
   ports:
     - {port: EventConsumer delivery, adapter: "the reactor's pgmq queue (see event-bus.yaml liteAdapter)"}
+  proof: >-
+    `starci app check --wiring` proves the composing lite app's module graph with doubles (R272); declaring event-bus requires
+    its scenario-titled integration specs on `starci supabase start` (R284), including redelivery through the reactor.
   see: [knowledge/patterns/be/supabase-queues.yaml]

package/runtime/knowledge/patterns/be/realtime.yaml

@@ -155,22 +155,43 @@ files:
     slot: be.feature.realtime
     template: realtime/channel.index.ts.tpl
     role: The public surface of the kind folder, the module class an api-kind app composes.
+  - path: src/features/realtime/<channel>/transport/graphql/<channel>-graphql.options.ts
+    slot: be.feature.realtime.graphql
+    template: realtime/channel.graphql.options.ts.tpl
+    role: The options of the module (the configurable module base needs a type); empty until the module takes some.
+  - path: src/features/realtime/<channel>/transport/graphql/<channel>-graphql.module-definition.ts
+    slot: be.feature.realtime.graphql
+    template: realtime/channel.graphql.module-definition.ts.tpl
+    role: The configurable-module base of the module, registered as register.
   - path: src/features/realtime/<channel>/transport/graphql/<channel>-graphql.module.ts
     slot: be.feature.realtime.graphql
     template: realtime/channel.graphql.module.ts.tpl
     role: Nest module of the subscription door, composed only by an api-kind app.
+  - path: src/features/realtime/<channel>/transport/websocket/<channel>-websocket.options.ts
+    slot: be.feature.realtime.websocket
+    template: realtime/channel.websocket.options.ts.tpl
+    role: The options of the gateway door's module - the cryptographic verifier that authenticates each connection.
+    optional: true
+  - path: src/features/realtime/<channel>/transport/websocket/<channel>-websocket.module-definition.ts
+    slot: be.feature.realtime.websocket
+    template: realtime/channel.websocket.module-definition.ts.tpl
+    role: The configurable-module base of the gateway door's module, registered as register.
+    optional: true
   - path: src/features/realtime/<channel>/transport/websocket/<channel>-websocket.module.ts
     slot: be.feature.realtime.websocket
+    template: realtime/channel.websocket.module.ts.tpl
     role: Nest module of the gateway door, composed only by an api-kind app.
     optional: true
   - path: src/features/realtime/<channel>/transport/websocket/<channel>.gateway.ts
     slot: be.feature.realtime.websocket
+    template: realtime/channel.gateway.ts.tpl
     role: A socket door (one WebSocketGateway class); exactly one of gateway or subscription per channel file name.
     rules: [BE_REALTIME_SHAPE, BE_REALTIME_WRITES, BE_REALTIME_TOPIC_SCOPE]
     spec: src/features/realtime/<channel>/transport/websocket/<channel>.gateway.spec.ts
     optional: true
   - path: src/features/realtime/<channel>/transport/websocket/<channel>.gateway.spec.ts
     slot: be.feature.realtime.websocket
+    template: realtime/channel.gateway.spec.ts.tpl
     role: Unit spec of the gateway beside it.
     optional: true
   - path: src/features/realtime/<channel>/transport/graphql/<channel>.subscription.ts
@@ -207,7 +228,7 @@ files:
     spec: realtime/subscriber-receives-push, realtime/foreign-topic-is-isolated, realtime/disconnect-releases-subscription
     rules: [BE_PATTERN_SPEC_MISSING]
     optional: true
-# Edition lite (owner rulings 2026-10-12 and 2026-10-13, R212 cases 1-2): the same ports, door and rules; one instance behind them.
+# Edition lite (R212, owner ruling 2026-10-14): the same ports, door and rules; one instance behind them.
 liteAdapter:
   summary: >-
     Under lite the realtime pattern is the full one: the socket.io gateway of be.feature.realtime.websocket
@@ -221,6 +242,7 @@ liteAdapter:
     - {port: topic scope, adapter: "the room name built from @CurrentPrincipal (BE_REALTIME_TOPIC_SCOPE), as full"}
   forbids: [redis, ioredis, "@socket.io/redis-adapter", graphql-ws, graphql-subscriptions]
   proof: >-
-    The gateway's own unit spec (<channel>.gateway.spec.ts) and the hub adapter's spec, as full; the realtime/* scenarios are
-    optional integration specs on `starci supabase start` (lite has no e2e).
+    The gateway's own unit spec (<channel>.gateway.spec.ts) and the hub adapter's spec, as full; declaring realtime requires
+    integration specs titled `realtime/<scenario>: ...` for every declared scenario on `starci supabase start` (R284), using a
+    real socket.io client. Lite has no e2e world.
   see: [knowledge/patterns/be/supabase-queues.yaml, knowledge/patterns/fe/realtime.yaml]

package/runtime/knowledge/patterns/be/saga.yaml

@@ -31,6 +31,14 @@ files:
     slot: be.feature.saga
     template: saga/saga.index.ts.tpl
     role: "The public surface of the kind folder: the message module an app composes."
+  - path: src/features/saga/<saga>/<saga>.options.ts
+    slot: be.feature.saga
+    template: saga/saga.options.ts.tpl
+    role: The options of the module (the configurable module base needs a type); empty until the module takes some.
+  - path: src/features/saga/<saga>/<saga>.module-definition.ts
+    slot: be.feature.saga
+    template: saga/saga.module-definition.ts.tpl
+    role: The configurable-module base of the module, registered as register.
   - path: src/features/saga/<saga>/<saga>.module.ts
     slot: be.feature.saga
     template: saga/saga.module.ts.tpl
@@ -120,6 +128,14 @@ files:
     role: "A thin door that hands the delivery of the last event, with its `eventId`, to the complete command; the saga takes it through the inbox."
     suffix: consumer
     rules: [R80, R88, R172]
+  - path: src/features/saga/<saga>/transport/message/<saga>-message.options.ts
+    slot: be.transport.message
+    template: saga/saga.message.options.ts.tpl
+    role: The options of the module (the configurable module base needs a type); empty until the module takes some.
+  - path: src/features/saga/<saga>/transport/message/<saga>-message.module-definition.ts
+    slot: be.transport.message
+    template: saga/saga.message.module-definition.ts.tpl
+    role: The configurable-module base of the module, registered as register.
   - path: src/features/saga/<saga>/transport/message/<saga>-message.module.ts
     slot: be.transport.message
     template: saga/saga.message.module.ts.tpl
@@ -246,7 +262,7 @@ rules:
       manual:
         - Check the injected fault hits the compensation, not only the step before it.
     relatedExamples: [saga]
-# Edition lite (owner ruling 2026-10-12, R212 case-1): the same ports and rules, a Supabase adapter behind them.
+# Edition lite (R212, owner ruling 2026-10-14): the same ports and rules, a Supabase adapter behind them.
 liteAdapter:
   summary: >-
     Under lite a saga is unchanged: the orchestrator service, the versioned state behind the fenced store, steps and their
@@ -256,6 +272,7 @@ liteAdapter:
     - {port: saga events, adapter: "the lite event-bus adapter (pgmq) - see event-bus.yaml liteAdapter"}
     - {port: saga state store, adapter: "the same table and version fence, created by a supabase migration (no TypeORM entity under lite)"}
   proof: >-
-    The orchestrator's unit spec (<saga>.saga.service.spec.ts) as full; the e2e compensation specs of R173 are full's, so a lite
-    saga proves each compensation in the orchestrator's unit spec and, optionally, an integration spec on `starci supabase start`.
+    The orchestrator's unit spec (<saga>.saga.service.spec.ts) as full; declaring saga requires integration specs titled
+    `saga/<scenario>: ...` for every declared scenario on `starci supabase start` (R284), including each compensation path with
+    failure injection and the final state read back. The e2e world of R173 remains full-only.
   see: [knowledge/patterns/be/supabase-queues.yaml]

package/runtime/knowledge/patterns/be/webhooks.yaml

@@ -88,7 +88,7 @@ rules:
   - id: BE-WEBHOOK-2
     title: The door verifies first and hands the delivery to one domain intake
     kind: mandatory
-    hfsRules: [R182, R183, R41, R42, R203]
+    hfsRules: [R182, R183, R41, R42, R203, R263]
     requirement: |-
       `<provider>.webhook.ts` is one `@Controller` with exactly one `@Post` handler and optionally one `@Get` subscription
       challenge handler. Each handler is declared
@@ -116,6 +116,8 @@ rules:
       The optional GET starts with a declared domain verifier's challenge call, awaited when async, and returns exactly that
       call's result: `const challenge = this.verifier.challenge(query); return challenge`, or directly returns that call.
       It makes no intake call and computes no other response. `@RateLimit(RateTier.Strict)` is required on both signed-webhook handlers.
+      `SignedWebhook` metadata belongs only to this HTTP door or the exact domain verifier named in its module's exported
+      `webhookVerifiers`. A public route whose path contains webhook, callback or events belongs in the webhook door too.
     rationale: |-
       The signature is the authentication of a public door. Making verification the first statement removes every door path that
       skips it; a combined domain method must finish that proof before intake. Keeping one intake and no decision leaves the door
@@ -215,6 +217,8 @@ rules:
         - BE_DEFAULT_DENY
         - BE_INPUT_BOUNDED
         - BE_FEATURE_THIN
+        - BE_WEBHOOK_SCOPE
+        - BE_WEBHOOK_INBOX_KEY
       manual:
         - Review that the raw body, not a re-serialized one, is verified, that the replay window matches the provider's tolerance, and that a domain verifier refuses the delivery before intake or business data access.
         - Trace intake helpers and dynamic dispatch that static resolution cannot inspect; none may dispatch a command before the receipt is durable.
@@ -222,7 +226,7 @@ rules:
   - id: BE-WEBHOOK-3
     title: The intake records the inbox receipt; a reactor or job dispatches after commit
     kind: mandatory
-    hfsRules: [R80, R152, R151]
+    hfsRules: [R80, R152, R151, R263]
     requirement: |-
       The sanctioned path is `verify -> inbox.record -> reactor/job dispatches the command`. `inbox.record` describes the
       domain intake's durable recording responsibility, not a new method on the shared `Inbox` port: the real port has `claim`.
@@ -236,6 +240,9 @@ rules:
       handler. A reactor consumes the receipt event and dispatches its own command, forwarding the delivered `eventId` and
       receipt reference; its domain service claims that separate consumer delivery before processing the receipt. A job may
       instead consume a transactionally enqueued receipt reference under the queue and fenced-job patterns.
+      This responsibility follows every intake identified by its first `*Id` parameter, a DTO delivery-id property or raw-body
+      signature input. The inbox key is the stable provider delivery id, and a duplicate returns before work. No `process`
+      callback, domain processing or command dispatch runs inside the receipt transaction; those run only after commit.
     rationale: |-
       Recording the delivery and writing the outbox row in one transaction means a crash cannot lose or duplicate the event, and
       keeping the publish in `modules/domain` keeps one place that owns the transaction boundary.
@@ -266,15 +273,18 @@ rules:
         - BE_INBOX_DEDUPE_MISSING
         - BE_OUTBOX_WRITE_TX
         - BE_EVENT_CLASS_CONTRACT
+        - BE_WEBHOOK_SCOPE
+        - BE_WEBHOOK_INBOX_KEY
       manual:
         - Confirm each accepted provider delivery records at most one receipt and outbox event, and the reactor or job alone dispatches processing commands.
     relatedExamples: [webhooks]
   - id: BE-WEBHOOK-4
     title: Three behaviours are proven on the test world
     kind: mandatory
-    hfsRules: [R155]
+    hfsRules: [R155, R284]
     requirement: |-
-      Declaring the pattern `webhooks` requires e2e or integration tests titled `webhooks/<scenario>: ...` for each scenario
+      Declaring the pattern `webhooks` requires e2e or integration tests in full and integration tests in lite (R284),
+      titled `webhooks/<scenario>: ...` for each scenario
       `bad-signature-is-refused` (a tampered body is refused and nothing is published), `replay-is-refused` (a stale timestamp is
       refused and nothing is published) and `accepted-delivery-publishes-once` (a valid delivery publishes the event once and a
       redelivery publishes nothing more). The provider is the network-edge fake of the test world (`world.fake.<provider>`), which
@@ -292,6 +302,7 @@ rules:
     verification:
       automated:
         - BE_PATTERN_SPEC_MISSING
+        - BE_LITE_PROOF_LANE_MISSING
       manual:
         - Confirm the fake signs exactly as the provider documents and that a contract spec guards its payload fixtures.
     relatedExamples: [webhooks]
@@ -300,6 +311,14 @@ files:
     slot: be.feature.webhooks
     template: webhooks/webhook.index.ts.tpl
     role: The public surface of the kind folder, the module class an api-kind app composes.
+  - path: src/features/webhooks/<provider>/transport/http/<provider>-http.options.ts
+    slot: be.feature.webhooks.http
+    template: webhooks/webhook.http.options.ts.tpl
+    role: The options of the module (the configurable module base needs a type); empty until the module takes some.
+  - path: src/features/webhooks/<provider>/transport/http/<provider>-http.module-definition.ts
+    slot: be.feature.webhooks.http
+    template: webhooks/webhook.http.module-definition.ts.tpl
+    role: The configurable-module base of the module, registered as register.
   - path: src/features/webhooks/<provider>/transport/http/<provider>-http.module.ts
     slot: be.feature.webhooks.http
     template: webhooks/webhook.http.module.ts.tpl

package/runtime/knowledge/patterns/fe/folder.yaml

@@ -306,6 +306,7 @@ rules:
       envelope, the generated wire types (from be/contracts/, through the root codegen) and the axios calls live in
       modules/api; the session lives in modules/auth; mutation feedback in modules/toast; environment reading in
       modules/config; every href builder in modules/routes; locale routing in modules/i18n; colour values in modules/brand.
+      Only hooks/swr imports the API transport operations; feature owners and other hooks consume those SWR hooks.
       A helper name defined twice across hook files is a finding.
     rationale: |
       A rule that says what a hooks folder is also says where everything else goes, so nobody copies a helper sixteen

package/runtime/knowledge/sonar-gate.yaml

@@ -82,7 +82,7 @@ overall:
     rule: typescript:S3776
     via: overall.issues
 # Lite is the same quality policy, coverage included: a lite back end keeps full's unit run and its 100 per file on the measured
-# logic files (owner ruling 2026-10-12, R212 case-1). Readers select this block from hfs.json edition; the gate keeps its own
+# logic files (owner ruling 2026-10-12, R212 case-1 (owner:lite-production-swarm), with the Work boundary amended by ruling:R212/case-4). Readers select this block from hfs.json edition; the gate keeps its own
 # name so a lite project's server gate stays a separate object, and every threshold below equals full's.
 lite:
   gate: