@starci/hfs 4.9.11 → 4.10.0

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

@@ -288,14 +288,14 @@ 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 (R212): the same ports and rules, a Supabase adapter behind them. ruling:R212/case-10 moved the lite queue to Redis
+# Edition lite (R212): the same ports and rules, a self-hosted Postgres adapter behind them. ruling:R212/case-10 moved the lite queue to Redis
 # because full's queue is Redis; full's event bus is Kafka, so the lite event-bus adapter below is unchanged by that ruling.
 liteAdapter:
   summary: >-
     Under lite the event bus keeps typed events, the vendored contract, publish(event, tx, correlationId) in the domain transaction, the outbox,
     the inbox and thin consumers; Kafka is replaced by pgmq-backed topics, or by in-process delivery after commit for a back end
     with a single api app. Each consumer group of a topic has its own pgmq queue `<service>__<event>__<group>`, created by a
-    supabase migration, named by a literal `<GROUP>_TOPIC_QUEUE` constant under platform/event-bus (its owner, R258) and
+    db migration, named by a literal `<GROUP>_TOPIC_QUEUE` constant under platform/event-bus (its owner, R258) and
     granted only to the application role, so each group keeps its own cursor and dead letter.
   ports:
     - {port: EventPublisher (platform/event-bus), adapter: the same outbox row in the domain transaction}
@@ -304,4 +304,4 @@ liteAdapter:
   forbids: [kafkajs]
   proof: >-
     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.
+    scenario on the local db service (`npm run db:start`, R284). Lite has no e2e world.

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

@@ -81,7 +81,7 @@ rules:
       (`ON CONFLICT (source, event_id) DO NOTHING RETURNING event_id`) returns `true` for a new row and `false` for a
       duplicate without aborting the caller's transaction. It never reads first and writes after, which races two concurrent
       deliveries of the same event. Lite uses its existing `public.inbox` table with the same client receipt columns,
-      owned by a forward-only Supabase migration. A client receipt extends this table; no capability creates another
+      owned by a forward-only db migration. A client receipt extends this table; no capability creates another
       dedupe table or unique request-key constraint to compete with it.
     rationale: |-
       One shared table with one owner keeps the guarantee "this (source, event id) claims at most once" in one place, and
@@ -250,7 +250,7 @@ files:
 liteAdapter:
   summary: >-
     Lite keeps the Inbox port and transaction-owned client receipt API. Its existing public.inbox
-    table uses Supabase migration authority; the be/inbox platform templates carry the lite adapter and the
+    table uses db migration authority; the be/inbox platform templates carry the lite adapter and the
     platform/client-operation-outcomes.sql.tpl forward migration. The files tree above describes the full TypeORM adapter.
     Delivery-only webhook scaffolds do not install a client marker. When adopting this client pattern, add the shared
     idempotency/platform/inbox/effectful.decorators.ts.tpl as src/modules/platform/inbox/effectful.decorators.ts and
@@ -261,5 +261,5 @@ liteAdapter:
     - {port: receipt retention, adapter: a fenced job delivered by the BullMQ queue on the declared Redis and scheduled by a pg_cron tick that enqueues through the queue outbox}
   proof: >-
     The same inbox and fingerprint unit specs apply; declaring idempotency requires both client receipt scenarios in
-    lite's local Supabase integration lane.
+    lite's local db integration lane.
   see: [knowledge/patterns/be/queues.yaml]

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

@@ -277,18 +277,18 @@ 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 (R212, owner ruling 2026-10-14): the same ports and rules, a Supabase adapter behind them.
+# Edition lite (R212, owner ruling 2026-10-14): the same ports and rules, a self-hosted Postgres 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
-    row's table is a supabase migration, and the processor is fed by full's BullMQ queue on the declared Redis, so a lite app
+    row's table is a db migration, and the processor is fed by full's BullMQ queue on the declared Redis, so a lite app
     that declares fenced-job declares `backing: [redis]`. Without a declared Redis a lite app has no fenced job; a long task is
     a declared replicated-job running a cli command.
   ports:
-    - {port: job claim (platform/jobs), adapter: "the same claim SQL through the shared EntityManager; the table comes from supabase/migrations"}
+    - {port: job claim (platform/jobs), adapter: "the claim and guarded writes as the job_claim, job_advance, job_complete and job_fail functions of the jobs migration in db/migrations, called through callDbFunction of platform/database (R334)"}
     - {port: processor delivery, adapter: "full's BullMQ worker (attempts and exponential backoff from the queue policy, failed jobs kept as the dead letter)"}
   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 the local Supabase stack (R284, which runs no container of its
+    `fenced-job/<scenario>: ...` for every declared scenario on the local db service (R284, which runs no container of its
     own): the claim, the fencing token and the guarded writes are Postgres facts, driven there by the real runner without BullMQ.
   see: [knowledge/patterns/be/queues.yaml]

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

@@ -176,15 +176,17 @@ files:
     role: "Titles projection/<scenario>: ... prove the pattern."
     spec: projection/recompute-is-idempotent, projection/replay-rebuilds
     rules: [BE_PATTERN_SPEC_MISSING]
-# Edition lite (R212, owner ruling 2026-10-14): the same ports and rules, a Supabase adapter behind them.
+# Edition lite (R212, owner ruling 2026-10-14): the same ports and rules, a self-hosted Postgres adapter behind them.
 liteAdapter:
   summary: >-
     Under lite a projection is unchanged in behaviour (only it writes its table, recompute is idempotent and replayable, readers
-    use get*); its table is a supabase migration with a rows type, so the slot carries no projection entity (be.projections lite
-    overlay), and it is kept current by a reactor on the lite event bus or by a job on the queue (BullMQ on the declared Redis).
+    use get*); its table is a db migration mapped by a projection entity under persistence/entities/ (named in PRIMARY_ENTITIES of
+    platform/database/entities.ts) and read and written through the EntityManager, never raw SQL (R334, ruling
+    lite-persistence-typeorm-entities), and it is kept current by a reactor on the lite event bus or by a job on the queue (BullMQ on
+    the declared Redis).
   ports:
-    - {port: read model table, adapter: "a supabase migration plus <name>.sql.ts and <name>.rows.ts under persistence/"}
+    - {port: read model table, adapter: "a db migration plus its entity under persistence/entities/ and the capability's persistence/entities/index.ts list; no <name>.sql.ts or <name>.rows.ts"}
   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).
+    `projection/<scenario>: ...` for every declared scenario on the local db service (`npm run db:start`, R284).
   see: [knowledge/patterns/be/event-bus.yaml, knowledge/patterns/be/queues.yaml]

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

@@ -83,7 +83,7 @@ rules:
     hfsRules: [R90, R258]
     requirement: |-
       A recurring task is a job scheduler (`upsertJobScheduler`) that the queue module declares in its `schedulers` list and
-      `platform/queue` registers at boot, or, in an app on Supabase, a uniquely named pg_cron job of a migration whose command
+      `platform/queue` registers at boot, or, in a lite app, a uniquely named pg_cron job of a migration whose command
       (directly or through one `*_tick` function) only inserts one row of a queue constant into the queue outbox table of
       `ruleParams.db.queueOutbox` (`public.queue`), which the relay hands to BullMQ, or by calling the enqueue function that the app declares with its own outbox table in `hfs.json` `sides.be.queueOutbox` (redis declared in `sides.be.backing`; the function's active definition only inserts into that table); a tick has exactly one of the two owners. A job name is scheduled once while it is active: a later migration that replaces a tick's command calls `cron.unschedule` of the name first. Its job is processed by the same
       `features/jobs/<job>/<job>.processor.ts` as any enqueued job. `@nestjs/schedule`, `@Cron`, `@Interval`, `@Timeout` and
@@ -96,7 +96,7 @@ rules:
         when: Expire unpaid orders every five minutes
         write: 'order-expiry.queue.ts declares scheduler { every: 5 minutes } for the expire-orders job; the processor dispatches ExpireOrdersCommand.'
       - id: case-2
-        when: A lite app on Supabase sends booking reminders every fifteen minutes
+        when: A lite app sends booking reminders every fifteen minutes
         write: "A migration declares private.booking_reminder_tick() as one insert into public.queue (queue, payload, created_at) values ('booking_reminder', jsonb_build_object('tick', true), now()) and schedules it with cron.schedule('booking_reminder_tick', '*/15 * * * *', ...); the send-reminder processor is the queue's."
     verification:
       automated:
@@ -275,19 +275,19 @@ liteAdapter:
     full's adapter: the relay marks an outbox row sent only after the transport's persist step confirms Redis wrote the job to
     its append-only file (WAITAOF) and still holds it, so a job Redis loses inside the at most one second fsync window leaves
     its row waiting and is added again; that is why a lite queue does not lose a job. Without a declared Redis there is no queue
-    pattern: the work is a direct call inside the request, or a declared replicated-job running a cli command. Supabase Queues
-    (pgmq) is not a queue transport. `starci app add queue|job` writes this adapter in a lite app, with the outbox and job
-    tables as one supabase migration, the Redis declaration and the persisted Redis of every docker-swarm environment.
+    pattern: the work is a direct call inside the request, or a declared replicated-job running a cli command. pgmq
+    is not a queue transport. `starci app add queue|job` writes this adapter in a lite app, with the outbox and job
+    tables as one db migration, the Redis declaration and the persisted Redis of every docker-swarm environment.
   ports:
-    - {port: QueueOutbox (platform/queue), adapter: "full's outbox row written through the caller's tx; the table comes from a supabase migration (no TypeORM entity under lite)"}
+    - {port: QueueOutbox (platform/queue), adapter: "the outbox row written through the caller's tx by queue_write, and the relay's queue_waiting and queue_mark_sent, functions of the queue migration in db/migrations called through callDbFunction of platform/database (R334)"}
     - {port: queue transport (queue-transport.port.ts), adapter: "full's bullmq-queue-transport.client.ts over the declared Redis (host, port, db and the password read from its sealed secret file), plus persist(jobs): WAITAOF 1 0 on each queue's connection, then each job's state, refusing with QUEUE_NOT_PERSISTED or QUEUE_JOB_LOST (errors/queue.error.ts)"}
     - {port: outbox relay (queue-relay.service.ts), adapter: "full's relay, which calls persist after the adds and before it marks the rows sent, so a refusal rolls the mark back and the next pass adds the rows again"}
     - {port: QueueWorkerRegistry (platform/queue), adapter: "full's BullMQ worker per queue: attempts and exponential backoff from queue.policy.ts, failed jobs kept as the dead letter"}
-    - {port: schedulers, adapter: "a BullMQ job scheduler declared with its queue, as full, or a pg_cron job in a supabase migration whose tick inserts one row of the queue constant into the queue outbox"}
+    - {port: schedulers, adapter: "a BullMQ job scheduler declared with its queue, as full, or a pg_cron job in a db migration whose tick inserts one row of the queue constant into the queue outbox"}
   forbids: [kafkajs, "@nestjs/schedule"]
   proof: >-
     Unit specs as full (queue-outbox, relay and worker services, the BullMQ client against a mocked factory); declaring queue
-    requires integration specs titled `queue/<scenario>: ...` for every declared scenario on the local Supabase stack (R284,
+    requires integration specs titled `queue/<scenario>: ...` for every declared scenario on the local db service (R284,
     which runs no container of its own): the outbox, its commit boundary, the relay identity and the pg_cron tick are Postgres
     facts proved there with the real outbox writer and relay, and the queue transport records what the relay hands to BullMQ
     (the job id is the outbox id). BullMQ itself is covered by the unit spec of the BullMQ client, which also proves the

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

@@ -154,7 +154,7 @@ 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 (R212, owner ruling 2026-10-14): the same ports and rules, a Supabase adapter behind them.
+# Edition lite (R212, owner ruling 2026-10-14): the same ports and rules, a self-hosted Postgres 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
@@ -163,5 +163,5 @@ liteAdapter:
     - {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.
+    its scenario-titled integration specs on the local db service (`npm run db:start`, R284), including redelivery through the reactor.
   see: [knowledge/patterns/be/event-bus.yaml]

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

@@ -290,8 +290,8 @@ rules:
       the memory hub (STACKS_REALTIME_SCALED) and the two-replica scenarios are the realtime scale rule BE-REALTIME-7.
 
       Lite (ruling:R212/case-10, owner:lite-vector-is-pgvector):
-      ONE instance type, one api deployable, scales horizontally and stateless, with no sticky sessions, on Postgres/Supabase plus
-      Redis when a declared capability needs it. Vector search uses Supabase pgvector. The three doors above are served from that api (the GraphQL subscription door is new
+      ONE instance type, one api deployable, scales horizontally and stateless, with no sticky sessions, on its own Postgres plus
+      Redis when a declared capability needs it. Vector search uses pgvector in the db service. The three doors above are served from that api (the GraphQL subscription door is new
       in lite, ruling:R212/case-7). A lite api with more than one replica uses the Redis hub when Redis is
       declared, else the Postgres hub. The example is the SSE `booking-status` channel.
 
@@ -373,7 +373,7 @@ rules:
       snapshot with a query on every reconnect. The engines (`socket.io`, `@socket.io/postgres-adapter`, `@socket.io/redis-adapter`,
       `graphql-ws`, `graphql-subscriptions`, `pg` for LISTEN and `ioredis`) are imported only by `platform/realtime`
       (`BE_INFRA_OWNER`). The tables are migrations of the app (`realtime_events` and, for the Postgres socket adapter,
-      `socket_io_attachments`: a Supabase migration in lite, a TypeORM migration of `platform/realtime` in full). Declaring realtime
+      `socket_io_attachments`: a db migration in lite, a TypeORM migration of `platform/realtime` in full). Declaring realtime
       adds two scenarios, proven with two api replicas: `realtime/push-crosses-replicas` (published through replica A, received on
       replica B) and `realtime/resume-after-reconnect` (`Last-Event-ID` sent to the other replica receives the missed frames).
     rationale: |-
@@ -406,7 +406,7 @@ rules:
           publish writes the realtime_events row and NOTIFYs; every replica LISTENs and writes the frame to its local streams; a
           reconnect to ANY replica sends Last-Event-ID and the hub reads the missed rows from the table. A domain service that owns the
           change publishes inside its own transaction (`hub.publish(topic, frame, tx)`), so the confirmation and its push commit together. At the ingress the stream is
-          not buffered or compressed and the idle timeout is above the heartbeat. Migration: supabase/migrations/<ts>_realtime-events.sql
+          not buffered or compressed and the idle timeout is above the heartbeat. Migration: db/migrations/<ts>_realtime-events.sql
           (lite) or platform/realtime/persistence/migrations/<epochMs>-create-realtime-events.ts (full).
       - id: case-3
         when: SSE, scale on Redis (Redis declared, lite or full)
@@ -668,9 +668,9 @@ files:
     slot: be.persistence
     role: Full edition migration of the realtime_events replay table and the socket_io_attachments table of the Postgres adapter.
     optional: true
-  - path: supabase/migrations/<timestamp>_realtime-events.sql
+  - path: db/migrations/<timestamp>_realtime-events.sql
     slot: repo.side-root-forbidden
-    role: Lite edition migration (created with supabase migration new) of the same two tables, forced row level security for app_be, and the pg_cron tick of the retention queue.
+    role: Lite edition migration (created with `npm run db:new`) of the same two tables, forced row level security for app_be, and the pg_cron tick of the retention queue.
     optional: true
   - path: src/features/reactors/<name>/transport/message/<event>.consumer.ts
     slot: be.transport.message

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

@@ -262,7 +262,7 @@ rules:
       manual:
         - Check the injected fault hits the compensation, not only the step before it.
     relatedExamples: [saga]
-# Edition lite (R212, owner ruling 2026-10-14): the same ports and rules, a Supabase adapter behind them.
+# Edition lite (R212, owner ruling 2026-10-14): the same ports and rules, a self-hosted Postgres adapter behind them.
 liteAdapter:
   summary: >-
     Under lite a saga is unchanged: the orchestrator service, the versioned state behind the fenced store, steps and their
@@ -270,9 +270,9 @@ liteAdapter:
     consumer group).
   ports:
     - {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)"}
+    - {port: saga state store, adapter: "the same table and version fence, created by a db migration"}
   proof: >-
     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
+    `saga/<scenario>: ...` for every declared scenario on the local db service (`npm run db: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/event-bus.yaml]

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

@@ -370,7 +370,7 @@ sourceMaintenance: >-
   verifies first and calls the supplied domain service's record<Provider>Delivery once. Implement that method as the
   transactional inbox receipt/outbox recording intake above, then add its reactor or job separately.
   In lite, the generated POST verifies first and calls <Provider>InboxService.record<Provider>Delivery. This record-only
-  domain intake uses recordWebhookDelivery to insert a pending provider inbox row atomically in Supabase Postgres, unique on
+  domain intake uses recordWebhookDelivery to insert a pending provider inbox row atomically in the app's Postgres, unique on
   (provider, delivery_id), without processing it or marking it complete. Add a reactor or job separately to consume the
   committed pending row and dispatch the processing command (reactors.yaml, jobs.yaml). The --service option validates the
   future domain processing owner; the webhook writer does not import or call that owner synchronously and does not

package/runtime/modules/kernel/command-policy.yaml

@@ -182,7 +182,7 @@ raw-tools:
   podman: {use: 'starci docker up, starci docker down, starci docker build, or starci docker ps'}
   kubectl: {use: 'starci app stack'}
   k3d: {use: 'starci app stack'}
-  supabase: {use: "starci supabase start, starci supabase stop, or starci supabase status for the app's own stack"}
+  supabase: {use: "starci app db new|plan|migrate|dump, and npm run db:start or db:stop for the app's own database"}
   gh: {use: 'starci release cut (the GitHub release is created from the CHANGELOG section of the tag); anything else is the owner''s'}
   schtasks: {use: 'starci task register, starci task show, or starci task list for runtime scheduled tasks'}
   shutdown: {use: 'ask the owner: a worker never shuts the host down'}

package/runtime/modules/kernel/failure-codes.yaml

@@ -870,7 +870,7 @@ BE_JSON_PARSE_UNGUARDED:
 BE_JWT_ALG_PINNED:
   title: "JWT verification has no pinned asymmetric algorithm policy"
   title_vi: "Xác minh JWT thiếu chính sách thuật toán bất đối xứng cố định"
-  meaning_vi: "Bộ xác minh chưa cố định thuật toán an toàn, nguồn cấu hình của issuer hoặc vai trò authenticated của principal Supabase."
+  meaning_vi: "Bộ xác minh chưa cố định thuật toán an toàn, nguồn cấu hình của issuer hoặc vai trò authenticated của principal."
   causes_vi:
     - "Danh sách algorithms rỗng, động hoặc chứa none hay HS256"
     - "Issuer viết trực tiếp hoặc principal chấp nhận vai trò khác authenticated"
@@ -1497,25 +1497,7 @@ BE_SQL_TABLE_OWNER:
   owner: op-retry
   kind: check-finding
 
-BE_SUPABASE_CLIENT_OWNER:
-  title: "A back-end Supabase client, import or call is outside `be.integrations.supabase`, or is not typed with `Database`"
-  title_vi: "Supabase client phía back end sai chủ sở hữu hoặc thiếu kiểu Database"
-  meaning_vi: "Import/call Supabase ở `<path>` không thuộc `be.integrations.supabase`, hoặc client được tạo mà không mang kiểu `Database`."
-  causes_vi:
-    - "Vi phạm L10: back end dùng EntityManager cho dữ liệu; chỉ integration Supabase sở hữu Auth/Storage client và kiểu Database."
-  nextStep_vi: "Chuyển Auth/Storage client vào `be.integrations.supabase`, dùng API công khai của integration và thêm kiểu `Database`; dữ liệu thường đi qua EntityManager."
-  owner: op-retry
-  kind: check-finding
 
-BE_SUPABASE_JWT_VERIFIED:
-  title: "A Supabase principal is derived without pinned JWKS verification, or authorization claims come from the request body"
-  title_vi: "JWT Supabase chưa được xác minh đầy đủ hoặc claim lấy từ request body"
-  meaning_vi: "`<path>` decode JWT không verify, gọi `jwtVerify` ngoài integration/thiếu JWKS, issuer, audience `authenticated` hay algorithm pin, hoặc đọc role/membership từ body."
-  causes_vi:
-    - "Vi phạm L16: principal chỉ đến từ access token đã verify signature/iss/aud/exp/algorithm hoặc được đọc lại từ DB."
-  nextStep_vi: "Dùng `createRemoteJWKSet` + `jwtVerify` trong `be.integrations.supabase`, pin issuer/audience/algorithms và bỏ mọi authorization claim từ body."
-  owner: op-retry
-  kind: check-finding
 
 BE_TEST_BUILDER_ARRANGES:
   title: "A test data builder asserts or has a non-deterministic default"
@@ -1811,15 +1793,6 @@ CLI_ONLY_ENTRY:
   owner: op-retry
   kind: check-finding
 
-DB_API_EXPOSED:
-  title: "The database API never exposes pgmq and lite data access is closed"
-  title_vi: "API cơ sở dữ liệu mở schema bị cấm"
-  meaning_vi: "config.toml mở pgmq hoặc pgmq_public, hoặc ứng dụng lite mở API dữ liệu mà không có policy public_read rõ ràng."
-  causes_vi:
-    - "Vi phạm R259: cửa dữ liệu không khớp quy tắc front end chỉ dùng Supabase Auth."
-  nextStep_vi: "Loại pgmq và pgmq_public khỏi schema API; đóng API dữ liệu lite hoặc khai báo policy public_read giới hạn cần thiết."
-  owner: op-retry
-  kind: check-finding
 
 DB_APP_ROLE:
   title: "The back-end database role has explicit least privileges"
@@ -1852,26 +1825,7 @@ DB_BASELINE_SHAPE:
   owner: op-retry
   kind: check-finding
 
-DB_BE_ONLY_ACCESS:
-  title: "Exposed product data is accessed through the back end"
-  title_vi: "Dữ liệu exposed được mở trực tiếp cho trình duyệt"
-  meaning_vi: "Migration tại <path> cấp quyền bảng hoặc sequence cho authenticated, khai báo policy cho authenticated, hoặc mở quyền anon ngoài policy select có tên kết thúc _public_read; đối tượng chưa được khai báo ngoại lệ supabase.directAccess."
-  causes_vi:
-    - "Vi phạm R254: Supabase phía front end chỉ phục vụ Auth; dữ liệu sản phẩm đi qua back end."
-    - "Grant hoặc policy mới mở lại cửa dữ liệu trong schema exposed mà không có ngoại lệ rõ ràng."
-  nextStep_vi: "Gỡ grant và policy truy cập trực tiếp; cho back end truy cập bằng app role. Nếu chủ ý mở đối tượng, khai báo bảng trong hfs.json supabase.directAccess; anon chỉ đọc qua policy select *_public_read."
-  owner: op-retry
-  kind: check-finding
 
-DB_CONFIG_POLICY:
-  title: "`supabase/config.toml` holds no literal credential (`env(NAME)` only), `auth.jwt_expiry <= 3600`, and signup/site_url/redirects equal the Supabase block of hfs.json"
-  title_vi: "config.toml lệch policy"
-  meaning_vi: "`<path>` (supabase/config.toml) chứa giá trị literal dưới key credential (secret|password|token|client_id|*_key trừ anon/publishable), `auth.jwt_expiry` quá 3600, hoặc `enable_signup`/`site_url`/`additional_redirect_urls` khác với block Supabase mà hfs.json khai báo."
-  causes_vi:
-    - "Vi phạm luật L08: secret trong config.toml viết `env(NAME)`; jwt_expiry tối đa 3600; posture auth là fact được check, không phải claim trong doc."
-  nextStep_vi: "Đổi credential thành `env(TEN_BIEN)`, hạ `jwt_expiry` về <= 3600, và chỉnh block Supabase của hfs.json hoặc config.toml cho khớp nhau."
-  owner: op-retry
-  kind: check-finding
 
 DB_CRON_OWNED:
   title: "A uniquely owned migration cron job only enqueues through the queue outbox"
@@ -1930,7 +1884,7 @@ DB_FORCE_RLS_DEFAULT:
   meaning_vi: "Bảng tại <path> thuộc app role nhưng thiếu force row level security và không có ngoại lệ forceRls kèm lý do không rỗng trong hfs.json."
   causes_vi:
     - "Vi phạm R255: chủ sở hữu bảng có thể bỏ qua RLS khi không có force row level security."
-  nextStep_vi: "Thêm alter table <schema>.<table> force row level security trong migration; nếu cần miễn, khai báo đúng bảng và lý do trong hfs.json supabase.forceRls."
+  nextStep_vi: "Thêm alter table <schema>.<table> force row level security trong migration; nếu cần miễn, khai báo đúng bảng và lý do trong hfs.json db.forceRls."
   owner: op-retry
   kind: check-finding
 
@@ -1949,8 +1903,8 @@ DB_MIGRATION_SHAPE:
   title_vi: "Migration sai hình dạng hoặc bị sửa"
   meaning_vi: "`<path>` vi phạm luật migration: tên phải là `<ts14>_<kebab>.sql`, stamp là thời điểm UTC thật và không trùng giữa các migration đang hoạt động; migration mới xếp sau chuỗi đang hoạt động đã commit trên HEAD. Archive ghi nhận migration đã nghỉ khỏi chuỗi, nên baseline thay thế có thể mang stamp trước archive. Migration đã lên base là bất biến (sửa hay xoá mà không archive đều là finding)."
   causes_vi:
-    - "Vi phạm luật L02: `supabase/migrations/<ts14>_<kebab>.sql`; stamp mới tăng nghiêm ngặt so với chuỗi đang hoạt động đã commit trên HEAD, không so với đồng hồ, thời gian commit hay stamp trên remote; file đã lên base không được đổi."
-  nextStep_vi: "Tạo migration mới bằng the Supabase CLI new-migration command, không sửa/đổi tên/xoá migration đã lên base; nếu cần đổi nội dung, viết migration mới."
+    - "Vi phạm luật L02: `db/migrations/<ts14>_<kebab>.sql`; stamp mới tăng nghiêm ngặt so với chuỗi đang hoạt động đã commit trên HEAD, không so với đồng hồ, thời gian commit hay stamp trên remote; file đã lên base không được đổi."
+  nextStep_vi: "Tạo migration mới bằng `npm run db:new -- <ten>`, không sửa/đổi tên/xoá migration đã lên base; nếu cần đổi nội dung, viết migration mới."
   owner: op-retry
   kind: check-finding
 
@@ -1987,22 +1941,13 @@ DB_POLICY_TAUTOLOGY:
   owner: op-retry
   kind: check-finding
 
-DB_REALTIME_UNLISTED:
-  title: "Realtime publication tables require declared direct access"
-  title_vi: "Bảng Realtime chưa được khai báo truy cập trực tiếp"
-  meaning_vi: "Migration tại <path> thêm bảng vào publication supabase_realtime nhưng bảng không có trong hfs.json supabase.directAccess."
-  causes_vi:
-    - "Vi phạm R254: publication Realtime mở một cửa dữ liệu trực tiếp chưa được khai báo."
-  nextStep_vi: "Gỡ bảng khỏi publication supabase_realtime hoặc khai báo ngoại lệ có chủ ý trong hfs.json supabase.directAccess."
-  owner: op-retry
-  kind: check-finding
 
 DB_RLS_REQUIRED:
   title: "Every `create table` in an exposed schema is followed by `enable row level security` in the same migration"
   title_vi: "Bảng trong schema public thiếu RLS"
   meaning_vi: "`<path>` tạo bảng trong schema exposed (`public` và `[api] schemas` của config.toml) mà không có `alter table ... enable row level security` ngay trong cùng migration; bảng khai báo `forceRls` cần cả `force row level security`."
   causes_vi:
-    - "Vi phạm luật L03: mọi `create table`/`create table as` trong schema exposed phải có enable (và force khi hfs.json `supabase.forceRls` khai báo) trong cùng migration; partition con và bảng temp được miễn."
+    - "Vi phạm luật L03: mọi `create table`/`create table as` trong schema exposed phải có enable (và force khi hfs.json `db.forceRls` khai báo) trong cùng migration; partition con và bảng temp được miễn."
   nextStep_vi: "Viết `alter table <schema>.<table> enable row level security;` ngay sau create trong cùng migration; không dùng vòng lặp dynamic SQL."
   owner: op-retry
   kind: check-finding
@@ -2027,15 +1972,6 @@ DB_STORAGE_PREFIX:
   owner: op-retry
   kind: check-finding
 
-DB_TYPES_DRIFT:
-  title: "`supabase/types/database.types.ts` is committed and equals what `contract:emit` regenerates from the migrations"
-  title_vi: "database.types.ts lệch với migrations"
-  meaning_vi: "`supabase/types/database.types.ts` chưa được commit, hoặc khác với text mà `contract:emit` sinh lại từ migrations hiện tại (hoặc emit thất bại). Pattern giống R23 HFS_CONTRACT_SNAPSHOT_DRIFT."
-  causes_vi:
-    - "Vi phạm luật L09: file types là artefact sinh; commit bản mới nhất, không sửa tay."
-  nextStep_vi: "Chạy `starci app emit` và commit `supabase/types/database.types.ts` kết quả."
-  owner: op-retry
-  kind: check-finding
 
 DB_VAULT_WRITE:
   title: "Migrations contain no vault writes or role passwords"
@@ -2197,16 +2133,6 @@ FE_BUTTON_NO_VARIANT:
   owner: op-retry
   kind: check-finding
 
-FE_CALLBACK_SHAPE:
-  title: "An auth callback performs more than code exchange and redirect"
-  title_vi: "Callback xác thực làm thêm việc ngoài đổi mã và chuyển hướng"
-  meaning_vi: "Handler của fe.route.callback chứa operation dữ liệu, logic sản phẩm, handler bổ sung hoặc phản hồi JSON thay vì chỉ đổi mã xác thực rồi chuyển hướng."
-  causes_vi:
-    - "Callback gọi operation API hoặc xử lý dữ liệu sản phẩm"
-    - "Callback trả JSON hoặc định nghĩa thêm handler"
-  nextStep_vi: "Giữ callback ở việc đọc mã, tạo client xác thực, đổi mã và chuyển hướng; chuyển logic sản phẩm về back end hoặc hook phù hợp."
-  owner: op-retry
-  kind: check-finding
 
 FE_CLIENT_BOUNDARY:
   title: "Server first; `\"use client\"` only where allowed"
@@ -2925,15 +2851,6 @@ FE_SERVER_ONLY_MARK:
   owner: op-retry
   kind: check-finding
 
-FE_SERVICE_ROLE_FORBIDDEN:
-  title: "A service-role or credential-shaped environment value enters the front end"
-  title_vi: "Service role hoặc biến môi trường bí mật đi vào front end"
-  meaning_vi: "`<path>` chứa identifier/string service_role hoặc đọc biến `*_SECRET`, `*_PRIVATE`, `*_TOKEN`, `*_PASSWORD`; public config không được khai báo qua chủ `modules/config`."
-  causes_vi:
-    - "Vi phạm L13: front end chỉ giữ URL, anon/publishable key và public config; service role luôn ở back end."
-  nextStep_vi: "Xóa credential khỏi fe/, chuyển thao tác đặc quyền qua use case back end, và khai báo public config tại `modules/config`."
-  owner: op-retry
-  kind: check-finding
 
 FE_SINGLE_COMMIT_PER_RENDER:
   title: "A component renders more than one commit"
@@ -3077,15 +2994,6 @@ FE_SUBSCRIPTION_NO_SNAPSHOT:
   owner: op-retry
   kind: check-finding
 
-FE_SUPABASE_CLIENT_OWNER:
-  title: "A front-end Supabase import or call is outside `fe.modules.auth`, or reaches past the auth API"
-  title_vi: "Supabase phía front end ngoài modules/auth hoặc dùng ngoài API auth"
-  meaning_vi: "Import/call Supabase ở `<path>` không thuộc ô `fe.modules.auth`, hoặc gọi API ngoài auth (`.from`, `.rpc`, `.storage`, `.channel`): front end không đọc hay ghi dữ liệu qua Supabase."
-  causes_vi:
-    - "Vi phạm luật R217: Supabase trên front end chỉ là xác thực (đăng nhập, phiên, access token) trong `modules/auth`; dữ liệu đi qua `modules/api` (Apollo GraphQL) và hook SWR tới back end (R212 case-2)."
-  nextStep_vi: "Chuyển client Supabase vào `modules/auth` và chỉ giữ API auth; đọc/ghi dữ liệu bằng query/mutation GraphQL trong `modules/api` và hook `hooks/swr`; không thêm ngoại lệ."
-  owner: op-retry
-  kind: check-finding
 
 FE_SUSPENSE_NULL_FALLBACK:
   title: "Suspense fallback renders something"
@@ -3689,15 +3597,6 @@ HFS_EDITION_INVALID:
   owner: op-retry
   kind: check-finding
 
-HFS_EMIT_DB_TYPES_STALE:
-  title: "Database types require current migration history"
-  title_vi: "Lịch sử migration chưa khớp để sinh kiểu"
-  meaning_vi: "Tập phiên bản đã áp dụng trong DB cục bộ khác dấu thời gian tệp supabase/migrations."
-  causes_vi:
-    - "Tập phiên bản đã áp dụng trong DB cục bộ khác dấu thời gian tệp supabase/migrations."
-  nextStep_vi: "Chạy npm run db:reset rồi starci app emit; kiểm tra cả phiên bản thiếu và phiên bản thừa."
-  owner: op-retry
-  kind: verb-refusal
 
 HFS_EMPTY_DIR:
   title: "No empty directory outside an `ignored` slot"
@@ -4302,15 +4201,6 @@ HFS_SERVICE_PLACEMENT:
   owner: op-retry
   kind: check-finding
 
-HFS_SERVICE_ROLE_SCOPE:
-  title: "Service-role access belongs to the Supabase integration"
-  title_vi: "Service role được dùng ngoài integration Supabase"
-  meaning_vi: "Mã tại <path> tham chiếu service_role ngoài integration Supabase của back end, kể cả trong script triển khai."
-  causes_vi:
-    - "Vi phạm R252: sử dụng quyền service role ngoài thành phần sở hữu kết nối Supabase."
-  nextStep_vi: "Đưa quyền service role vào be/src/modules/integrations/supabase và truy cập qua port của integration; script gọi CLI của ứng dụng."
-  owner: op-retry
-  kind: check-finding
 
 HFS_SERVICE_STACK_DECLARATION:
   title: "Each service app is a service component of the stack"
@@ -5650,3 +5540,63 @@ BE_ENTITY_SCHEMA_DRIFT:
   nextStep_vi: "Viết migration mới trong db/migrations để schema có đúng cột đó, hoặc sửa entity cho khớp schema hiện tại, rồi chạy lại starci app db drift cho đến khi xanh."
   owner: op-retry
   kind: check-finding
+
+BE_AUTH_PASSPORT_OWNER:
+  title: "An identity library is imported outside integrations/passport"
+  title_vi: "Thư viện định danh bị import ngoài integrations/passport"
+  meaning_vi: "File `<path>` import @nestjs/passport, passport, passport-google-oauth20, passport-local, @nestjs/jwt, jose hoặc bcryptjs mà không thuộc `be.integrations.passport`, hoặc import bcrypt hay client Supabase."
+  causes_vi:
+    - "Vi phạm R328: chỉ integration passport sở hữu chiến lược Google, đăng nhập email/mật khẩu và token riêng của app."
+  nextStep_vi: "Chuyển mã vào `src/modules/integrations/passport/` và gọi qua API công khai của integration; dùng bcryptjs thay bcrypt, bỏ client Supabase."
+  owner: op-retry
+  kind: check-finding
+
+BE_AUTH_JWT_OWN_JWKS:
+  title: "A lite principal is not built from the app own verified access token"
+  title_vi: "Principal của app lite không đến từ access token riêng đã xác minh"
+  meaning_vi: "`<path>` gọi jwtVerify ngoài integrations/passport, xác minh với createRemoteJWKSet thay vì key set riêng (createLocalJWKSet), thiếu issuer/audience/algorithms, decode token không xác minh hoặc đọc role/membership từ request body."
+  causes_vi:
+    - "Vi phạm R329: principal chỉ đến từ token do chính app ký và xác minh bằng JWKS riêng."
+  nextStep_vi: "Dùng `createTokenKit` của integrations/passport (jwtVerify trên createLocalJWKSet, pin issuer/audience/algorithms) và để domain/identity dựng principal từ kết quả đó."
+  owner: op-retry
+  kind: check-finding
+
+BE_AUTH_REFRESH_COOKIE:
+  title: "A refresh token leaves the httpOnly cookie"
+  title_vi: "Refresh token rời khỏi cookie httpOnly"
+  meaning_vi: "`<path>` đặt cookie refresh thiếu httpOnly, secure, sameSite strict hoặc path của cửa refresh, hoặc đưa refresh token vào body của request/response."
+  causes_vi:
+    - "Vi phạm R330: refresh token chỉ sống trong cookie httpOnly Secure SameSite=Strict và được xoay vòng mỗi lần dùng."
+  nextStep_vi: "Đặt và xoá cookie qua `setRefreshCookie`/`clearRefreshCookie` của integrations/passport; bỏ trường refreshToken khỏi DTO và kết quả trả về."
+  owner: op-retry
+  kind: check-finding
+
+BE_STORAGE_OWNER:
+  title: "An S3 SDK is imported outside integrations/object-storage"
+  title_vi: "S3 SDK bị import ngoài integrations/object-storage"
+  meaning_vi: "File `<path>` import @aws-sdk/client-s3 hoặc @aws-sdk/s3-request-presigner ngoài `be.integrations.object-storage`, hoặc import minio."
+  causes_vi:
+    - "Vi phạm R331: chỉ integration storage sở hữu client S3 (MinIO trong lite) và URL presigned."
+  nextStep_vi: "Gọi port ObjectStorage của integrations/object-storage (presignPut, presignGet, remove); bỏ minio."
+  owner: op-retry
+  kind: check-finding
+
+LITE_DB_MIGRATION:
+  title: "A lite schema change lives outside db/migrations"
+  title_vi: "Thay đổi schema của app lite nằm ngoài db/migrations"
+  meaning_vi: "`<path>` là tệp của thư mục supabase/ hoặc một tệp SQL ngoài db/ (trừ seed của .starcistacks)."
+  causes_vi:
+    - "Vi phạm R332: schema của app lite chỉ nằm trong db/migrations/<ts14>_<kebab>.sql, archive và seed trong db/."
+  nextStep_vi: "Chuyển migration sang db/migrations (giữ nguyên stamp), seed sang db/seed.sql, types sang db/types/; xoá supabase/."
+  owner: op-retry
+  kind: check-finding
+
+BE_PERSISTENCE_NO_RAW_SQL:
+  title: "Lite domain code runs raw SQL instead of TypeORM entities"
+  title_vi: "Mã domain của app lite chạy SQL thô thay vì entity TypeORM"
+  meaning_vi: "File `<path>` gọi `.query(` hoặc dùng template `sql` ngoài platform/database và ngoài danh sách hàm ruleParams.be.lite.rawSqlFunctions."
+  causes_vi:
+    - "Vi phạm R334: dữ liệu của app lite đi qua entity TypeORM trên EntityManager (find, save, update, upsert, createQueryBuilder)."
+  nextStep_vi: "Khai entity ở persistence/entities/<table>.entity.ts và đọc/ghi bằng EntityManager hoặc createQueryBuilder với tham số có tên; hàm pg/SECURITY DEFINER không diễn đạt được thì khai vào rawSqlFunctions kèm lý do."
+  owner: op-retry
+  kind: check-finding

package/runtime/modules/schemas/application-stacks.schema.yaml

@@ -85,16 +85,16 @@ properties:
         command: {type: string, minLength: 1}
   backing:
     description: >-
-      Supabase backing: local Docker containers managed by the Supabase CLI in development and a hosted
-      service in production. Every other dependency is a Docker component, on Swarm in production.
+      The self-hosted database of a lite app: its db component (image supabase/postgres), a Docker container in
+      development and a Swarm service in production. Every other dependency is a Docker component too.
     type: object
     additionalProperties:
       type: object
       additionalProperties: false
-      required: [provider, managed]
+      required: [provider, component]
       properties:
-        provider: {const: supabase}
-        managed: {const: true}
+        provider: {const: postgres}
+        component: {type: string, minLength: 1}
   environments:
     type: object
     minProperties: 1

package/runtime/scripts/hfs/architecture/canon-clones.mjs

@@ -154,7 +154,7 @@ function readCall(env, call, managers) {
 function ownedRead(env, statement) {
   const { ts } = env;
   const call = statementCall(ts, statement);
-  if (!call || !ts.isCallExpression(call) || !imported(env, call.expression, 'requireOwnedRow', '@modules/platform/database') || call.arguments.length !== 5) return false;
+  if (!call || !ts.isCallExpression(call) || !imported(env, call.expression, 'requireOwnedEntity', '@modules/platform/database') || call.arguments.length !== 5) return false;
   if (!call.arguments.slice(0, 4).every(argument => mapping(env, argument))) return false;
   const callback = unwrap(ts, call.arguments[4]);
   if (!ts.isArrowFunction(callback) || callback.parameters.length || !ts.isBlock(callback.body) || callback.body.statements.length !== 1) return false;