@ai-matrx/records-ui 0.3.1 → 0.3.2

package/dist/index.d.cts

@@ -1037,17 +1037,36 @@ declare function personActor(userId: Uuid$1 | null | undefined): RecordsActor;
  *
  * `RecordsDataSource` is deliberately a small structural subset of
  * `SupabaseClient` — the package holds no key and opens no connection, the host
- * hands it a client that already carries the person's session. Structurally the
- * two agree. PROVING it does not fit in the type checker's budget: a generated
- * `Database` type makes `schema().from().select()` enormous, and a host app
- * that passes its client straight into `config` gets
- * `TS2589: Type instantiation is excessively deep and possibly infinite` in its
- * own build (matrx-frontend, 2026-09-18, on all three campaign routes at once).
+ * hands it a client that already carries the person's session.
  *
- * So the assertion is made HERE, once, where it is explained — rather than as a
- * cast copied into every route that mounts a screen.
+ * IT IS NOT AN IDENTITY CAST, and it cost a live screen to learn why
+ * (2026-09-19, /data-v2's first load): the port's `rpc(fn, args, { schema })`
+ * says the schema OUT LOUD, because every door of this store is `custom.<name>`
+ * and every door of the trust layer is `iam.<name>`. supabase-js's own
+ * `rpc(fn, args, options)` has no `schema` option at all — its third argument is
+ * `{ head, get, count }` — so a client passed straight through silently asked
+ * its default PostgREST profile and the store answered, correctly and uselessly,
+ * "Could not find the function public.table_kernel_id ... PGRST202". The schema
+ * is chosen the one way supabase-js offers: `client.schema(name).rpc(...)`.
+ *
+ * `schema(name).from(table)` already agrees structurally and is passed through.
+ *
+ * `fallbackSchema` is the profile a call that says NOTHING is sent to. No caller
+ * in `@ai-matrx/records` omits the option — `callDoor` always says `custom` and
+ * `trustDoor` always says `iam` — so it never fires today; it exists so that a
+ * call which one day forgets lands on the store rather than silently on
+ * `public`. It is a FALLBACK and not the answer: a version of this adapter that
+ * sent EVERY door to one fixed schema would route the `iam` trust doors (the
+ * external principal, the publish binding) into `custom` and get a PGRST202
+ * naming the wrong schema.
+ *
+ * The cast itself stays HERE, once, where it is explained: a generated
+ * `Database` type makes `schema().from().select()` enormous, and a host app that
+ * passes its client straight into `config` gets `TS2589: Type instantiation is
+ * excessively deep and possibly infinite` in its own build (matrx-frontend,
+ * 2026-09-18, on all three campaign routes at once).
  */
-declare function recordsDataSource(client: object, schema?: string): RecordsDataSource;
+declare function recordsDataSource(client: object, fallbackSchema?: string): RecordsDataSource;
 
 type TableLane = "mine" | "organization" | "system" | "community";
 /** The four lanes, in the order a person reads them. Never a flat list. */

package/dist/index.d.ts

@@ -1037,17 +1037,36 @@ declare function personActor(userId: Uuid$1 | null | undefined): RecordsActor;
  *
  * `RecordsDataSource` is deliberately a small structural subset of
  * `SupabaseClient` — the package holds no key and opens no connection, the host
- * hands it a client that already carries the person's session. Structurally the
- * two agree. PROVING it does not fit in the type checker's budget: a generated
- * `Database` type makes `schema().from().select()` enormous, and a host app
- * that passes its client straight into `config` gets
- * `TS2589: Type instantiation is excessively deep and possibly infinite` in its
- * own build (matrx-frontend, 2026-09-18, on all three campaign routes at once).
+ * hands it a client that already carries the person's session.
  *
- * So the assertion is made HERE, once, where it is explained — rather than as a
- * cast copied into every route that mounts a screen.
+ * IT IS NOT AN IDENTITY CAST, and it cost a live screen to learn why
+ * (2026-09-19, /data-v2's first load): the port's `rpc(fn, args, { schema })`
+ * says the schema OUT LOUD, because every door of this store is `custom.<name>`
+ * and every door of the trust layer is `iam.<name>`. supabase-js's own
+ * `rpc(fn, args, options)` has no `schema` option at all — its third argument is
+ * `{ head, get, count }` — so a client passed straight through silently asked
+ * its default PostgREST profile and the store answered, correctly and uselessly,
+ * "Could not find the function public.table_kernel_id ... PGRST202". The schema
+ * is chosen the one way supabase-js offers: `client.schema(name).rpc(...)`.
+ *
+ * `schema(name).from(table)` already agrees structurally and is passed through.
+ *
+ * `fallbackSchema` is the profile a call that says NOTHING is sent to. No caller
+ * in `@ai-matrx/records` omits the option — `callDoor` always says `custom` and
+ * `trustDoor` always says `iam` — so it never fires today; it exists so that a
+ * call which one day forgets lands on the store rather than silently on
+ * `public`. It is a FALLBACK and not the answer: a version of this adapter that
+ * sent EVERY door to one fixed schema would route the `iam` trust doors (the
+ * external principal, the publish binding) into `custom` and get a PGRST202
+ * naming the wrong schema.
+ *
+ * The cast itself stays HERE, once, where it is explained: a generated
+ * `Database` type makes `schema().from().select()` enormous, and a host app that
+ * passes its client straight into `config` gets `TS2589: Type instantiation is
+ * excessively deep and possibly infinite` in its own build (matrx-frontend,
+ * 2026-09-18, on all three campaign routes at once).
  */
-declare function recordsDataSource(client: object, schema?: string): RecordsDataSource;
+declare function recordsDataSource(client: object, fallbackSchema?: string): RecordsDataSource;
 
 type TableLane = "mine" | "organization" | "system" | "community";
 /** The four lanes, in the order a person reads them. Never a flat list. */

package/dist/index.js

@@ -5596,11 +5596,16 @@ function RecordsMount({
 function personActor(userId) {
   return userId ? { actor: "user", user_id: userId } : { actor: "user" };
 }
-function recordsDataSource(client, schema = "custom") {
+function recordsDataSource(client, fallbackSchema = "custom") {
   const supabase = client;
   return {
-    rpc: (fn, args) => supabase.schema(schema).rpc(fn, args),
-    schema: (name) => supabase.schema(name)
+    rpc(fn, args, options) {
+      const on = supabase.schema(options?.schema ?? fallbackSchema);
+      return on.rpc(fn, args);
+    },
+    schema(name) {
+      return supabase.schema(name);
+    }
   };
 }