Merge remote-tracking branch 'origin/main' into claude/issue-15684-analytics-like-case-exact

Author: claude

.changeset/flow-edge-id-uniqueness.md

@@ -0,0 +1,64 @@
+---
+"@objectstack/spec": minor
+---
+
+feat(spec)!: `FlowSchema` refuses a flow whose `edges[]` declares the same id twice (#14964)
+
+<!-- adr-0087: not-required (no-migration-prescription) No authorable key is renamed, retired or re-typed: `edges[].id` keeps its name, its type and its describe, and every flow whose edge ids are unique parses byte-identically. The only newly refused shape is two edges sharing one id — a collision, not a spelling — and its remedy is to renumber one of the two, which is authoring intent no `objectstack migrate meta` rewrite can choose for the author. The Zone-2 census over this repo (776 `edges[]` arrays, 1,098 edges under `packages/**` and `examples/**`, with a lit control) found zero instances, so there is no in-repo file to name. -->
+
+**BREAKING** accept-set narrowing on `FlowSchema` — a flow whose `edges[]`
+carries two edges with the same `id` is now **refused at parse time** — by
+`FlowSchema.parse` / `safeParse`, `defineFlow`, and every door that validates a
+flow through the schema (`objectstack validate`, the runtime publish gate, a
+stack's `flows[]`) — where it used to parse on green. Shipped as `minor` under
+the repo's launch-window convention for breaking changes. Maintainer ruling
+2026-09-05 on #14964 (director decision batch #40, verbatim 「同意」): option
+A — an `error`, not a `warning`; no opt-out, no transition window.
+
+Every reader of an edge id assumes the ids in a flow are unique — a designer,
+a BPMN export, a flow diff, any traversal that dedupes by id — and nothing
+enforced it. A real duplicate (`id: 'e20'` on two edges of one flow) shipped
+through two releases of green CI in a downstream app and was inert only
+because the engine keys out-edges by `source`, never by `id`: the collision is
+invisible until something keys on ids, and then silently wrong rather than
+loudly broken. The id space is hand-authored, so the next author picking a
+"free" id from the sequence had no way to know it was taken.
+
+**What changes** (`packages/spec/src/automation/flow.zod.ts`): a `superRefine`
+on the flow's `edges[]`. Each later occurrence of an already-declared id raises
+one `custom` issue, anchored at `edges[N].id` of the *later* edge and naming
+both positions, so the formatted error points at the edge to renumber:
+
+```text
+✗ edges.7.id: Duplicate edge id `e20` — `edges[7]` reuses the id already declared by `edges[3]`; every edge id in a flow must be unique. Renumber one of them: …
+```
+
+**What does NOT change:** `edges[].id` keeps its name, type and describe; the
+node vocabulary, the edge `type` enum and every other refusal are untouched;
+a flow with unique edge ids (or no edges) parses exactly as before. Node ids
+are not covered by this change.
+
+The shape that is refused, and what the author does about it — a two-edge
+excerpt, the later edge renumbered:
+
+```ts
+// before — parsed on green, both edges keyed 'e20'
+edges: [
+  { id: 'e20', source: 'qualify', target: 'convert' },
+  { id: 'e20', source: 'convert', target: 'end' },
+]
+
+// after — refused at parse (edges.1.id: Duplicate edge id `e20` …); renumber the later one:
+edges: [
+  { id: 'e20', source: 'qualify', target: 'convert' },
+  { id: 'e21', source: 'convert', target: 'end' },
+]
+```
+
+**Remedy.** Renumber the later edge to an id no other edge in that flow
+carries; nothing else in the flow needs to move. The census over this
+repository found no flow to migrate, so this is a release note, not a
+migration: no shipped example, fixture or seed in `packages/**` or
+`examples/**` declares a duplicate edge id, and the pinned objectui tree
+carries none in its authored flows. The one known downstream instance was
+renumbered before this change (hotcrm PR #1571).

.changeset/lint-non-record-collection-entry.md

@@ -0,0 +1,11 @@
+---
+"@objectstack/lint": patch
+---
+
+No authoring rule throws on a non-record entry of any stack collection.
+
+A collection is authored either as a list or as a name-keyed map, so every rule that reads one coerces `unknown` into an array of records first. That coercion had been hand-copied into 39 modules, and 23 of the copies spelled the array branch as an unchecked cast — every member was asserted to be a record. A YAML list item left empty deserialises to `null`, so a single stray `-` under `flows:`, `pages:`, `dashboards:`, `datasets:`, `apps:`, `permissions:`, `capabilities:`, `data:`, `hooks:`, `views:`, `actions:`, `translations:` (or a per-object `fields:` / `actions:` / `views:`) reached a property read on `null` and threw a stack trace out of `os lint` / `os validate` instead of reporting a finding. The rules are pure `(stack) => Finding[]` running on the raw path, so nothing upstream had judged the entry's shape.
+
+Twenty-two of those readers now read through the shared, guarded `recordsOf`, which drops a non-record member of the array shape whole and keeps the author's key on the map shape. Nothing else about what the rules judge changes: a valid entry standing beside a junk one is still read, and still draws exactly the findings it drew before.
+
+The remaining copies are pinned by a new source-text test in the package, so the predicate cannot be pasted back in: it asserts that `recordsOf` is the only collection coercion, that every module still holding a private one is named in a dated ledger that is exact in both directions, and that no coercion outside a dated single-file allowance casts its array branch unchecked.

.changeset/serve-unlinked-database-file-watch.md

@@ -0,0 +1,11 @@
+---
+"@objectstack/cli": patch
+---
+
+`os serve` now says so when the SQLite file it is serving is no longer the file at its configured path.
+
+Deleting the data directory under a running server — `rm -rf .objectstack/data`, which is what a `demo:reset` script does and what a fresh-database repro starts with — unlinks the inode without touching the process. SQLite keeps reading and writing the now-invisible file, health keeps answering `200`, and a later boot creates a brand-new database at the same path. From that moment every filesystem inspection of that path describes a *different* database than the running server answers from, and nothing anywhere says so: a row edited there has no observable effect on the live server, and a user who authenticates against the live server is not in that file. Both readings are true, both look like a broken write path, and one investigation that reported them as evidence cost a full P0 cycle.
+
+A boot that serves an on-disk SQLite file now records that file's identity once the boot is complete and re-checks it on a 30-second interval. When the file is gone, or the path holds a different file, it reports **once** at `error` — naming the path, the consequence (every external observation of this deployment is now false, and it will keep looking healthy) and the fix (restart the server so it opens the file that is at that path now).
+
+It refuses nothing and retries nothing: the running server is still correct, merely invisible, and breaking a working dev loop to fix a reporting gap would trade a bad hour for a worse one. Nothing is added to any payload, endpoint or state file. Silence from the check is not a claim that the file is intact — every uncertainty in it resolves toward staying quiet, because a false report would send an operator to restart a server whose database is fine.

.changeset/signup-existing-address-explicit-refusal.md

@@ -0,0 +1,28 @@
+---
+"@objectstack/plugin-auth": minor
+"@objectstack/spec": patch
+---
+
+`POST /sign-up/email` for an address that already has a `sys_user` row is refused explicitly, instead of answering 200 for a row that is never written (#15587)
+
+**This is a wire-behaviour change on one lane**: a call that answers `200 {"token":null,"user":{…}}` today answers `422 USER_ALREADY_EXISTS_USE_ANOTHER_EMAIL` after this change. Nothing is newly admitted — the response that changes is one that reported a creation that never happened.
+
+### What was measured
+
+Under audience posture `email_domain` (domain allowlisted, `selfRegistrationPermissionSet` resolvable), a sign-up for an address that already carried a `sys_user` row answered **200 with a freshly minted user id** and persisted nothing: no new `sys_user`, no `sys_account`, and the next sign-in a `401` with nothing anywhere explaining it. The same call on the same population under the `invite_only` default was refused honestly with `422 USER_ALREADY_EXISTS_USE_ANOTHER_EMAIL`. An operator, a provisioning script or the console reading the status code concludes the account exists — and this sits directly on the recovery path a locked-out deployment walks, where widening the posture to let a seeded person register is exactly the remedy an operator is pointed at.
+
+### The mechanism
+
+better-auth's sign-up route computes `shouldReturnGenericDuplicateResponse = requireEmailVerification || autoSignIn === false` and, when it is on, answers a duplicate with a synthetic in-memory user instead of throwing. **No insert is attempted and nothing is swallowed**: the vendor's `findUserByEmail` short-circuits ahead of `createUser`, which is why no row and no credential appear.
+
+The posture is not itself the cause — it is only what arms the shield: a posture that permits self-registration **forces** `requireEmailVerification` on. Holding the posture constant at the `invite_only` default and moving only that flag reproduces the divergence exactly, which also means the defect was never confined to the widened postures: `emailAndPassword.autoSignIn: false` arms the same shield under any posture.
+
+### The fix
+
+The uniqueness refusal is raised on the `/sign-up/email` before-hook, the same seam and the same reason the audience-posture refusal is already raised there, and built from better-auth's own `BASE_ERROR_CODES` entry so both lanes answer byte-identically.
+
+**Order is load-bearing: it runs only for a caller the posture already admitted.** Asking uniqueness first would hand an uninvited stranger an account-existence oracle under the `invite_only` default (422 for a real address versus 403 for an unknown one). After the gate, `invite_only` is untouched — a stranger still gets `SELF_REGISTRATION_CLOSED` and learns nothing.
+
+**Operators of `open` / `email_domain` should know what the honest refusal costs:** on those postures a caller the audience gate admits can now distinguish an address that has an account from one that does not, where the synthetic 200 previously hid it. That is the disclosure the `invite_only` lane has always made to an invitation holder, and the platform's answer for a widened posture is now the same fact rather than a false receipt.
+
+`USER_ALREADY_EXISTS_USE_ANOTHER_EMAIL` is registered in the ADR-0112 error-code ledger under `@objectstack/plugin-auth`: the platform now **emits** it rather than only passing it through, and an emitted-but-unregistered code is the silent fourth state that ledger exists to prevent.

content/docs/deployment/self-hosting.mdx

@@ -557,11 +557,13 @@ this step.
 **Two remedies that look like they work, measured:**
 
 - **Opening the audience posture is not enough on its own.** With the posture
-  widened to `email_domain`, a seeded person's own registration answers `200`
-  and persists *nothing* — no new row, no account, and their sign-in is still
-  `401`. A fresh address does get an account, but every posture other than
-  `invite_only` forces email verification on, so its first sign-in is refused
-  `403 EMAIL_NOT_VERIFIED` until a mail transport delivers the link.
+  widened to `email_domain`, a seeded person's own registration is refused
+  `422 USER_ALREADY_EXISTS_USE_ANOTHER_EMAIL` and nothing is written — the same
+  answer the `invite_only` default already gives for an address the directory
+  holds, so the widened posture buys that person no login and their sign-in
+  stays `401`. A fresh address does get an account, but every posture other
+  than `invite_only` forces email verification on, so its first sign-in is
+  refused `403 EMAIL_NOT_VERIFIED` until a mail transport delivers the link.
 - **A hand-written credential row authenticates nothing.** The `sys_account`
   row shape is public; the format of the secret stored in its `password`
   column is the platform's own. A row carrying a plaintext password is refused

content/docs/references/api/contract.mdx

@@ -27,7 +27,7 @@ const result = ApiErrorSchema.parse(data);
 
 | Property | Type | Required | Description |
 | :--- | :--- | :--- | :--- |
-| **code** | `Enum<'VALIDATION_ERROR' \| 'INVALID_FIELD' \| 'MISSING_REQUIRED_FIELD' \| 'INVALID_FORMAT' \| 'VALUE_TOO_LONG' \| 'VALUE_TOO_SHORT' \| 'VALUE_OUT_OF_RANGE' \| … +293 more>` | ✅ | Error code (e.g. VALIDATION_ERROR; StandardErrorCode ∪ the ledger the serving side registers — ERROR_CODE_LEDGER for framework packages) |
+| **code** | `Enum<'VALIDATION_ERROR' \| 'INVALID_FIELD' \| 'MISSING_REQUIRED_FIELD' \| 'INVALID_FORMAT' \| 'VALUE_TOO_LONG' \| 'VALUE_TOO_SHORT' \| 'VALUE_OUT_OF_RANGE' \| … +294 more>` | ✅ | Error code (e.g. VALIDATION_ERROR; StandardErrorCode ∪ the ledger the serving side registers — ERROR_CODE_LEDGER for framework packages) |
 | **declaredCode** | `string` | optional | The producer-declared code, verbatim, when it is not a member of the closed `code` vocabulary — the open, author-authored channel (app-specific spellings; ADR-0112) |
 | **message** | `string` | ✅ | Readable error message |
 | **userMessage** | `string` | optional | Producer-marked user-facing refusal text, verbatim. Present exactly when the producer opted in at throw time; consumers render it to end users and keep their generic substitution for anything unmarked. Status-agnostic; never replaces `message`. |
@@ -333,6 +333,7 @@ const result = ApiErrorSchema.parse(data);
 * `UPLOAD_SESSION_EXPIRED`
 * `UPLOAD_SESSION_NOT_FOUND`
 * `USER_ALREADY_EXISTS`
+* `USER_ALREADY_EXISTS_USE_ANOTHER_EMAIL`
 * `VALIDATION_FAILED`
 * `VERSION_NOT_FOUND`
 * `VERSION_NOT_RESTORABLE`

content/docs/references/api/error-code-ledger.mdx

@@ -449,6 +449,7 @@ const result = ErrorCode.parse(data);
 * `UPLOAD_SESSION_EXPIRED`
 * `UPLOAD_SESSION_NOT_FOUND`
 * `USER_ALREADY_EXISTS`
+* `USER_ALREADY_EXISTS_USE_ANOTHER_EMAIL`
 * `VALIDATION_FAILED`
 * `VERSION_NOT_FOUND`
 * `VERSION_NOT_RESTORABLE`

packages/cli/src/commands/serve-driver-banner.test.ts

@@ -49,7 +49,7 @@ describe('describeRegisteredDriver', () => {
 
     expect(describeRegisteredDriver(fakeKernel({
       'driver.sql': { config: { client: 'better-sqlite3', connection: { filename: './data.db' } } },
-    }))).toEqual({ label: 'SqlDriver(better-sqlite3)', url: './data.db' });
+    }))).toEqual({ label: 'SqlDriver(better-sqlite3)', url: './data.db', sqliteFile: './data.db' });
 
     expect(describeRegisteredDriver(fakeKernel({
       'driver.sql': { config: { client: 'pg', connection: { host: 'db.example.com', port: 5432, database: 'app' } } },
@@ -133,10 +133,42 @@ describe('describeRegisteredDriver', () => {
     expect(describeRegisteredDriver(kernel)).toEqual({
       label: 'SqliteWasmDriver',
       url: './app.wasm.db',
+      sqliteFile: './app.wasm.db',
     });
   });
 
   it('returns null when no known driver is registered', () => {
     expect(describeRegisteredDriver(fakeKernel({}))).toBeNull();
   });
+
+  // `sqliteFile` is the SAME probe read a second time asking a different
+  // question: not "what do I print" but "which file on this filesystem", so
+  // the boot can `stat` it and notice later that the file it opened is no
+  // longer the file at that path. It is the plumbing between the driver and
+  // that watch, and nothing else pins it — a probe that stopped answering it
+  // would leave the watch silently un-armed on every boot, which is
+  // byte-identical to a deployment where nothing ever went wrong.
+  describe('sqliteFile — the on-disk file the boot is serving', () => {
+    it('answers the sqlite connection filename', () => {
+      expect(describeRegisteredDriver(fakeKernel({
+        'driver.com.objectstack.driver.sql': {
+          config: { client: 'better-sqlite3', connection: { filename: '/app/.objectstack/data/objectstack.db' } },
+        },
+      }))?.sqliteFile).toBe('/app/.objectstack/data/objectstack.db');
+    });
+
+    it('is absent for every driver that serves no file on disk', () => {
+      expect(describeRegisteredDriver(fakeKernel({
+        'driver.sql': { config: { client: 'better-sqlite3', connection: { filename: ':memory:' } } },
+      }))?.sqliteFile).toBeUndefined();
+
+      expect(describeRegisteredDriver(fakeKernel({
+        'driver.sql': { config: { client: 'pg', connection: { host: 'db.example.com', port: 5432, database: 'app' } } },
+      }))?.sqliteFile).toBeUndefined();
+
+      expect(describeRegisteredDriver(fakeKernel({
+        'driver.memory': { constructor: { name: 'InMemoryDriver' }, config: {} },
+      }))?.sqliteFile).toBeUndefined();
+    });
+  });
 });