Merge origin/main into claude/issue-4616-notification-orphan-schemas

Author: claude

.changeset/adr0104-attest-after-boot-writes.md

@@ -0,0 +1,58 @@
+---
+"@objectstack/objectql": patch
+"@objectstack/platform-objects": patch
+---
+
+fix(objectql,platform-objects): 一次启动不能证明它自己随即违反的契约 —— ADR-0104 空库自证改为在本次启动写完数据后下结论 (#4769)
+
+一个全新部署第一次 `pnpm dev` 全绿(130 rows,0 ERROR),**第二次启动开始永久 10 条
+ERROR**、10 条种子记录写不进去。数据没变、代码没变,只是重启了一次;被拒的正是首启
+自己写进去的数据。
+
+根因不是哪个值算错了,是**顺序反了**。`sys_migration` 里那两行
+(`adr-0104-file-references` / `adr-0104-value-shapes`)带着
+`{"attested":"datastore-created-empty"}` 写在 `kernel:ready`,而同一次启动的 seed
+还在往里写行。「空库 ⇒ 没有历史值」这个推理成立的前提是**没有数据可写**,而它恰恰
+写在即将写入 130 行之前 —— 证明落笔那一刻是真的,一秒之后就不是了。于是首启在
+warn-first 下把数据留下,之后每一次启动读到这张证书、进入 strict、拒掉前任写下的
+那批行。
+
+## 改了什么
+
+**证书必须覆盖它所声称的那批数据。**
+
+- **写入时机**:新库自证改为在**本次启动自己的数据落定之后**进行 ——
+  `app:seeded`(inline seed 结算点,含超出 `OS_INLINE_SEED_BUDGET_MS` 后台跑完的
+  那一半),不 seed 的 kernel 仍由 `kernel:ready` 兜底。两条路径进的是同一个幂等
+  调用。
+- **写入前提**:`attestFreshDatastore` 先问引擎「这次启动放行过违反该契约的值吗」。
+  引擎在 warn-first 放行每一个不合形状的值时,用**与 strict 模式完全相同的判定**把
+  它记下来 —— 证明干净需要扫全库,证伪只需要一个反例,而这个反例写路径已经算出来
+  了。任一条被本次启动证伪的迁移 id **不再自证**,部署维持 warn-first(真实且可
+  恢复),并在日志里指名是哪个 `对象.字段` 让这道闸没关上、该跑哪条 `os migrate`。
+  两行一起改:`adr-0104-file-references` 与 `adr-0104-value-shapes` 各自独立判定,
+  一个 `cover` 不合形状不牵连 `location`,反之亦然。
+- **写入之后**:证书若在签发之后被本次启动推翻(操作员显式开了
+  `OS_ALLOW_LAX_MEDIA_VALUES` / `OS_ALLOW_LAX_VALUE_SHAPES`,或后台 seed 收尾晚于
+  签发),引擎**撤销**它 —— `verified_at` 清空、`blocking` 记上、`details` 保留原
+  `attested` 并补一条 `revoked`。只针对**本次启动亲手创建的库**上的自证行:扫过全
+  库的真实迁移证据不会被一次写入的观察推翻。
+
+**记忆化的第二张脸也一并修了。** 首启之所以「看起来是绿的」,一半靠的是进程内正好
+缓存了 `false`。`sys_migration` 在 kernel init 期间才注册,而第一条写可能赶在它之
+前 —— 那次读根本没读到账本,却被当成结论冻结了一整个进程的姿态。现在区分两种否定:
+**问过了、账本说不**(结论,照旧缓存)与**根本问不到**(未注册 / 查询抛错 —— 依旧
+答 `false`,闸依旧关着,但不记住,下一次写再问一次)。代价是账本存在之前每次写多一
+次 registry 查表(在任何查询之前就短路),账本可读之后即止。
+
+启动横幅那条 ADR-0104 建议行(`kernel:bootstrapped`)也改为直接读账本而非读记忆化
+结果 —— 否则一个刚刚自证成功的新部署会被告知去跑一条已经不需要跑的迁移。
+
+## 对既有部署的影响
+
+- 数据本来就合规的新部署:行为不变,照旧 born-migrated,启动即 strict。
+- 种子数据不合规的新部署:**不再**发出那张假证书。首启与之后每一次启动一致地停在
+  warn-first,并且每次都告诉你是哪一个值、跑哪条命令。数据本身该怎么修还是怎么修
+  (showcase 的 `cover` 种子值在 #4774 单独跟踪)。
+- 已经跑过 `os migrate … --apply` 的部署:完全不受影响 —— 扫描得来的证据不经由本
+  次改动的任何路径改写。

.changeset/hook-condition-previous-binding.md

@@ -0,0 +1,55 @@
+---
+'@objectstack/objectql': minor
+---
+
+**A declarative hook `condition` can now express a TRANSITION: the CEL scope binds `previous` alongside `record` (#4784).**
+
+The condition gate evaluated against a single root — `{ record }`. Both published skill
+docs, however, taught the `previous` form: `objectstack-formula` §5 ("Update hook
+condition — `previous` vs `record`") gives
+`P\`previous.status != 'escalated' && record.status == 'escalated'\``, and its legacy
+migration table maps `OLD.x` → `previous.x` and `ISCHANGED(x)` → `previous.x != record.x`.
+Written into a hook, any of those aborted the expression with `No such key: previous`,
+which the gate swallowed into `false` — the hook simply never ran, leaving one WARN line.
+Declared ≠ delivered.
+
+It became load-bearing with #4770. `record` now means the record's **state** (stored ⊕
+payload), so `record.done == true` is true on *every* update of an already-done row — not
+only the one that completed it. `showcase_audit_task_completion`'s own description says
+"after a task transitions to done", and there was no way to write that. Now there is:
+
+```ts
+condition: P`previous.done != true && record.done == true`
+```
+
+`previous` is built exactly as the validation side builds it (#4649), through the shared
+`materializeDeclaredFields` helper, so one CEL expression means one thing on both
+surfaces:
+
+- **the stored pre-write row**, made **total over the object's DECLARED fields** — a
+  column the driver never returned reads as `null` instead of aborting the expression;
+- **declared fields only** — `previous.dnoe` stays unevaluable, so a typo is still
+  reported rather than quietly answered;
+- **copied, never mutated in place.** `ctx.previous` is the engine's own pre-image object,
+  observed by every after-hook; the materialised `null`s do not leak into it.
+
+**Where `previous` is NOT bound** — verbatim the rule `validation/rule-validator.ts`
+already applies, so referencing it there makes the condition unevaluable:
+
+- **insert events** (`beforeInsert` / `afterInsert`) — there is no prior state. Write
+  insert conditions over `record` alone.
+- **predicate (`multi: true`) bulk updates** — one write matches N rows and the hook fires
+  once, so there is no single prior record. Binding `{}` or `null` would answer
+  `previous.x == null` with a fabricated fact about rows nobody read.
+
+**Cost: none.** No new demand-driven fetch was introduced. `previous` rides on the prior
+row `engine.update` already reads whenever an afterUpdate hook is registered — the same
+one that feeds `ctx.previous` and record-change flow triggers. A condition that never
+mentions `previous` reads nothing extra, pinned by test.
+
+**What you may see after upgrading:** hooks whose condition referenced `previous` never
+fired before and start firing now. That is the declaration finally being honoured — review
+any hook carrying a `previous.*` condition before you upgrade.
+
+**Unchanged, deliberately:** a condition that is *still* unevaluable is logged at WARN and
+treated as `false`. Whether that should fail loudly instead is tracked separately.

.changeset/many-data-atomic-real-or-refused.md

@@ -0,0 +1,40 @@
+---
+"@objectstack/metadata-protocol": minor
+---
+
+fix(metadata-protocol): `deleteMany` / `updateMany` honour `atomic` for real, or refuse it (#4620)
+
+ADR-0119 D4 made `batchData`'s `atomic` flag a real guarantee. Its two siblings
+in the same file were out of that PR's confirmed scope and kept the defect:
+
+- **`deleteManyData` was fake-atomic.** `atomic: true` opened no transaction; it
+  only `break`-ed the loop, so every row deleted before the failure stayed
+  **deleted** while the response called itself atomic and reported those rows
+  `success: true`. Worse than the `batchData` case it was copied from, because a
+  partial delete has no natural undo — a client cannot reconstruct the rows from
+  its own request.
+- **`updateManyData` ignored `atomic` entirely.** The option was accepted,
+  declared in `BatchOptionsSchema` with an all-or-nothing contract, and never
+  read: a caller asking for atomicity silently got best-effort, with no signal.
+
+Both now run the **same** atomic arm as `batchData`, extracted into one shared
+runner so a fourth copy of transaction handling cannot drift into a fourth lie:
+
+- `atomic: true` runs the whole batch inside ONE `engine.transaction()`; the
+  first failure rolls back every prior write.
+- A rolled-back batch reports **zero successes**. Rows that had succeeded are
+  marked `ROLLED_BACK: record <i> failed — <cause>`, rows never reached are
+  `NOT_ATTEMPTED: atomic batch aborted by record <i>`, and the causal row keeps
+  its own error — so a client can tell "attempted, undone" from "never ran".
+- `atomic` outranks `continueOnError`, whose contract text already scoped it to
+  `atomic=false`.
+
+**Behaviour change to be aware of:** a runtime that cannot roll back (no
+`engine.transaction()`, or a default driver without `beginTransaction`) now
+**refuses** an `atomic: true` `deleteMany` / `updateMany` with `501
+NOT_IMPLEMENTED` instead of silently running best-effort — the same fail-closed
+gate `batchData` uses. That silent downgrade is the defect class this fixes; if
+you want best-effort, ask for it (`atomic: false`, or omit the option), or probe
+the runtime's transaction support before sending. Non-atomic behaviour of both
+endpoints — including the `continueOnError` interaction and their response
+shapes — is unchanged.

examples/app-showcase/src/data/hooks/index.ts

@@ -38,13 +38,20 @@ export const NormalizeTaskTitleHook = {
   description: 'Trims leading/trailing whitespace from the task title before every write.',
 };
 
-/** afterUpdate (gated) — log a line whenever a task flips to done. */
+/**
+ * afterUpdate (gated) — log a line on the update that flips a task to done.
+ *
+ * The condition compares against `previous` on purpose (#4784). Since #4770
+ * `record` means the record's STATE, so `record.done == true` alone would audit
+ * every later edit of an already-done task — while this hook's own description
+ * says "transitions to done". The transition is the two-root form.
+ */
 export const AuditTaskCompletionHook = {
   name: 'showcase_audit_task_completion',
   label: 'Audit Task Completion',
   object: 'showcase_task',
   events: ['afterUpdate'] as LifecycleEvent[],
-  condition: "record.done == true",
+  condition: "previous.done != true && record.done == true",
   body: {
     language: 'js' as const,
     source: "var r = ctx.result || ctx.input || {}; ctx.log.info('task completed: ' + (r.title || r.id || 'unknown'));",

packages/metadata-protocol/src/protocol.delete-many.test.ts

@@ -145,15 +145,19 @@ describe('deleteManyData — partial-failure semantics (#3897)', () => {
     expect(res).toMatchObject({ success: false, total: 3, succeeded: 2, failed: 1 });
   });
 
-  it('atomic aborts the remaining ids on the first failure', async () => {
+  // [#4620] This used to pin the fake-atomic: `atomic: true` merely broke the
+  // loop, so `a` stayed DELETED and the response reported `succeeded: 1` under
+  // a flag whose one job is to guarantee it was undone. On this engine — no
+  // `transaction()` at all — the honest answer is a refusal, not a half-batch.
+  // Real rollback is pinned in protocol.many-data-atomic.test.ts.
+  it('atomic REFUSES on an engine that cannot roll back, deleting nothing (#4620)', async () => {
     const { p, del } = failOn('b');
-    const res: any = await p.deleteManyData({
+    await expect(p.deleteManyData({
       object: 'invoice',
       ids: ['a', 'b', 'c'],
       options: { atomic: true, continueOnError: true },
-    } as any);
+    } as any)).rejects.toMatchObject({ status: 501, code: 'NOT_IMPLEMENTED' });
 
-    expect(del).toHaveBeenCalledTimes(2);
-    expect(res.succeeded).toBe(1);
+    expect(del).not.toHaveBeenCalled();
   });
 });