Merge origin/main into claude/issue-5488-allowruntimecreate-false

Merge-lap onto current main. One conflict, in the shared ADR-0087 retirement
registry (`packages/spec/src/migrations/registry.ts`): main's
`import-run-automations-declared-default-corrected` (#6190) and this branch's
`api-runtime-create-withdrawn` (#5488) both append a SemanticMigration into
step 17's array, sharing the brace above and below.

Resolved UNION-KEEP — neither entry may be lost (#6526). Recounted from the
merged file: 43 step-17 semantic entries, with both #42
(`api-runtime-create-withdrawn`) and #43
(`import-run-automations-declared-default-corrected`) present.

The two generated artifacts were NOT text-merged (the os-regen merge driver
refuses to): `spec-changes.json` and `docs/protocol-upgrade-guide.md` were
regenerated from the merged tree, and both entries are present in each.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PiRUoQkTSBBmpyXBY3cVn2

Author: claude

.changeset/database-driver-flag-derived-from-table.md

@@ -0,0 +1,37 @@
+---
+"@objectstack/spec": patch
+"@objectstack/cli": patch
+---
+
+refactor(spec,cli): `--database-driver` 的可选值从共享驱动表推导，删掉 CLI 里的第二份词表 (#6969)
+
+**无行为变更**：`os start --database-driver` / `os dev --database-driver` 接受的取值集合
+与改动前**逐字相同**（`memory`、`sqlite`、`sqlite-wasm`、`postgres`、`mysql`、`mongodb`、
+`turso` 七个，一个不多一个不少）。唯一可见的差别是 `--help` 里这七个值的**枚举顺序**，
+说明见下。
+
+#6345 把平台的驱动词表收敛成 `@objectstack/spec` 的一张表之后，CLI 里仍留着它的副本：
+两条命令各自用手写字面量数组声明 oclif 的 `options:`（一份强制白名单），并且各自在
+`description:` 的散文里把同样的 id **再抄一遍**。四份副本，一张表，正是 #6535
+（`IMPORT_JOB_MAX_ROWS` 两处定义）的形状挪了个包。
+
+现在 `@objectstack/spec` 导出 `DATABASE_DRIVER_SELECTION_IDS`——**选择面**（
+`DriverVocabularyEntry.aliases`）收敛到规范拼写后的投影——两条命令连同 help 散文里的
+枚举都从它派生，CLI 内不再有任何手写驱动 id 列表。
+
+取的是选择面而**不是**配置契约面（`DRIVER_ID_ALIASES` / `resolveDriverId`）：后者按设计
+包含 `contractOnlyAliases`（`sqlite3`、`better-sqlite3`、`mariadb`、`inmemory`）——它们能
+解析出一份存量 datasource 的 config 契约，但两个启动宿主从来都不接受它们作为启动选择。
+把它们摆上 flag 会是一次**放宽**，只是穿了重构的外衣。新增用例驱动 oclif 真实 parser，
+证明这四个拼写仍在 parse 阶段被拒。
+
+这不是在修一个用户会撞到的缺陷：`database-driver-allowlist.pin.test.ts`（#6860）已经在钉
+「白名单 ↔ `resolveStorageDefinition` 能解析出的驱动种类」这条一致性，而且 #6345 落地当天
+就抓到过一次真回归。本次改动是结构性的——第二份定义没有了，钉子守的那条一致性也就无法
+再由「改了一个文件忘了另一个」打破。该钉子**未被改动**，改后依旧全绿。
+
+**`--help` 顺序**：枚举顺序从 CLI 手写的 `sqlite | sqlite-wasm | turso | postgres | mysql |
+mongodb | memory` 变为共享表的行序 `memory | sqlite | sqlite-wasm | postgres | mysql |
+mongodb | turso`。同一份 CLI 在你拼错驱动名时打印的 “Supported drivers: …” 早就用的是行序，
+所以改后 `--help` 与它自己的拒绝信息终于按同一个顺序列举驱动。要保住旧顺序，就必须在
+`packages/cli` 里留下一份手写的顺序列表——恰恰是本卡要删掉的东西。

.changeset/driver-sql-batch-autonumber-resync.md

@@ -0,0 +1,72 @@
+---
+"@objectstack/driver-sql": patch
+---
+
+fix(driver-sql): `bulkCreate` and `upsert` re-seed a stale autonumber counter instead of burning the whole batch (#6943)
+
+#5495 taught `create()` to re-seed a stale autonumber counter and retry instead
+of burning one number per failed insert. `bulkCreate()` and `upsert()` call the
+same `fillAutoNumberFields` and did not get that fix. They are not, however, the
+same defect as each other — measured on `main` @ `c8ff269`, on a fresh database
+with seeded rows above the counter (the one-time-storm repro constraint #5495
+established):
+
+**`upsert` is `create()`'s old shape exactly.** Single row, so a stale counter
+costs it one burned number per call: `last_value` walked 1 → 2 → 3 across two
+refused upserts. Its `ON CONFLICT (mergeKeys) DO UPDATE` absorbs a conflict on
+the merge key only; the tenanted autonumber lives under a *different* unique
+index, so that violation is still raised and still reaches the caller.
+
+**`bulkCreate` is worse.** Each row reserves its number in its own committed
+transaction and the batch then goes in as ONE insert, so a single colliding row
+burns *every* number the batch reserved and fails the whole request:
+
+| 3-row `bulkCreate`, counter at 10, rows 11–39 already present | before | after |
+|:---|:---|:---|
+| caller-visible failures | both calls threw | **0** |
+| rows written | **0** | 3 |
+| `last_value` | 10 → 13, then 13 → 16 | 10 → 42, by one re-seed |
+
+And it is the worst path to leave without recovery: framework#2678 made
+`bulkCreate` the common case for seed/import, and seed/import is exactly what
+*creates* the staleness — an `isSystem` replay or a `preserveAudit` import keeps
+its explicit numbers and never enters `fillAutoNumberFields` (#5495/#5503).
+
+Both paths now reuse #5495's machinery unchanged — `collidingAutoNumberReservations`
+for the three-state routing, `autoNumberValueExists` for the data-based
+discriminator (the conflicting column is never determinable for a tenanted
+autonumber), and the forward-only `resyncSequenceToDataMax`. A collision that is
+not provably this counter's is still rethrown untouched, so a duplicate on a
+value the caller supplied still reaches them as its own error.
+
+**Batch semantics are unchanged, and that is a measurement rather than a
+choice.** `insert(rows[])` is a single statement, so the batch was already
+all-or-nothing — the failed batch above left the table exactly as it found it.
+Re-issuing and retrying the whole batch therefore preserves the existing
+contract: no partial success is introduced, no transaction is opened, and no
+"does a failed row roll back its siblings" question arises, because siblings
+already fail together. Per-row retry inside the batch was rejected for the
+opposite reason — it would have had to split the one statement into N and invent
+partial success where none existed.
+
+One thing the batch may not borrow from `create()`: `create()` keeps a
+reservation that did not collide, to avoid burning a second number. A batch
+cannot. One that straddles the seeded range has its low rows collide and its
+high rows not, and re-issuing only the collided ones would hand them numbers
+*above* the kept ones — an intra-batch duplicate the driver would have
+manufactured itself. Re-issue is therefore per counter: every row drawn from a
+counter that went stale is re-issued, and counters that did not go stale keep
+their values, so a co-tenant's rows in the same batch are undisturbed.
+
+As with #5495, retrying is confined to the no-caller-transaction case. Inside a
+caller's transaction the sequence `UPDATE` rolls back with the refused `INSERT`,
+so nothing is burned and there is nothing to repair (measured on both paths), and
+on Postgres a constraint failure aborts the transaction outright. The caller owns
+that retry.
+
+`TursoDriver` (local/replica) and `SqliteWasmDriver` inherit both fixes, each
+pinned by its own test rather than assumed from the base class — Turso
+*overrides* `bulkCreate`/`upsert` to route remote traffic away, so inheritance
+there is a routing fact, not a class fact. Turso's remote transport builds its
+own INSERT and generates no autonumber at all, so it neither has this defect nor
+receives this fix (that gap is #6944).

.changeset/flow-variable-default-value.md

@@ -0,0 +1,60 @@
+---
+"@objectstack/spec": minor
+"@objectstack/service-automation": minor
+---
+
+feat(spec,service-automation): a flow variable can declare a `defaultValue`, so "declared" means "bound" (#4697)
+
+Declaring a flow variable used to guarantee nothing at run time. The engine bound
+an `isInput` variable **only** when the caller actually supplied it
+(`params[name] !== undefined`), so every path that omitted the parameter left the
+name unbound — and a flow condition is strict CEL, where an unbound name does not
+read as `false`, it **aborts the predicate and stops the run**. The declaration was
+documentation, not a guarantee, and there was no metadata form that said "this
+variable always has a value".
+
+`FlowVariableSchema` now takes an optional `defaultValue`, and the engine binds it
+whenever no parameter supplies one:
+
+```typescript
+variables: [
+  { name: 'createOpportunity', type: 'boolean', isInput: true, defaultValue: false },
+]
+```
+
+The rules:
+
+- **A supplied parameter always wins**, including a falsy one — the boundary is
+  `!== undefined`, so `false`, `null`, `0` and `''` are answers rather than
+  absences, and only a genuinely missing parameter falls through to the default.
+- **A non-input declaration takes its default too.** `isInput: false` means no
+  parameter can reach the name, so the default is the only thing that can bind it.
+- **A declared variable shadows a trigger-record field of the same name**, whether
+  it was bound from a parameter or from its default — the rule a parameter already
+  followed. A name cannot resolve out of a different source depending on whether
+  the caller passed it.
+
+Both run entry points seed from one shared site, so the retry path behaves
+identically to the first attempt.
+
+**Additive and opt-in.** A declaration without `defaultValue` behaves exactly as
+before, so existing flows parse and run unchanged. The value is not cross-checked
+against the declared `type` — `type` is an open string with no vocabulary to check
+against, the same posture as every other `defaultValue` on the authoring surface.
+
+The case this closes came from a screen flow (hotcrm#643): a screen collects an
+optional checkbox, the client returns only the fields the user actually touched,
+so on the untouched path the variable was never bound, the outgoing edge aborted,
+and a lead conversion persisted nothing. The workaround was an `assignment` node
+before every screen mirroring the screen field's own `defaultValue`; a declared
+default replaces that ceremony.
+
+The docs half of the same gap is now written down too
+(`content/docs/automation/flows.mdx`): under strict CEL the guard an author
+reaches for first — `has(X.f)` — **aborts** on an unbound `X`, the very case it is
+written for. Only the `vars.`-scoped `has(vars.X)` tests bindedness. That truth
+table is measured against the live evaluator in
+`service-automation/src/flow-variable-default.test.ts` rather than asserted, so a
+prescription nothing executes cannot quietly stop being true. Prefer
+`defaultValue` over either guard: a guard encodes "unanswered means no" into the
+predicate and leaves the graph defect in place.

.changeset/import-run-automations-declared-default.md

@@ -0,0 +1,60 @@
+---
+"@objectstack/spec": major
+---
+
+fix(spec)!: `ImportRequest.runAutomations` declares the default the import route actually applies (#6704, ADR-0049)
+
+`POST /api/v1/data/:object/import` — and its async twin `POST /api/v1/data/:object/import/jobs` —
+has fired triggers and hooks for an omitted `runAutomations` since #2922. The server
+decides with `body?.runAutomations !== false`: automations always ran on import
+historically, so opting **out** was made the explicit act, matching platform
+convention (Salesforce fires triggers on import by default).
+
+The schema declared the opposite, and said so twice. `.default(false)` shipped in
+`@objectstack/spec`'s JSON Schema, and the `describe` prose — "off by default for
+bulk" — rendered into the published reference tables for **both** defs
+(`ImportRequest` and `CreateImportJobRequest`). Both are now corrected to the
+runtime: `.default(true)`, with prose that states automations run by default and
+that opt-out must be explicit.
+
+**Runtime behaviour is deliberately UNCHANGED.** `packages/rest/src/import-prepare.ts`
+is untouched by this change. Nothing starts being refused, and no request that
+worked before behaves differently on the wire.
+
+### Why a wrong declaration was reachable at all
+
+Nothing in the repo reconciled the two halves, which is why no gate could see the
+divergence: no request path parses an import body through this schema. The route
+reads the raw body, and the single reference to `CreateImportJobRequestSchema` is
+the declarative `ImportJobApiContracts` catalog entry — a declaration, not a parse.
+Each half was internally consistent; only their disagreement was wrong.
+
+### Migration: FROM → TO
+
+| FROM | TO |
+| :--- | :--- |
+| omitting `runAutomations` and expecting no triggers, because the schema said so | send `runAutomations: false` — the only spelling the server has ever read |
+| omitting it and expecting triggers | change nothing; that is what you already got, and now what is declared |
+| reading `ImportRequestParsed.runAutomations` after parsing a body without the key | it now yields `true` instead of `false` — the value the server would have applied anyway |
+
+**Who is actually affected:** a client or SDK that validates its request through the
+published schema and sends the **parsed** object. It materialised
+`runAutomations: false` from the declared default and sent it explicitly, and the
+server honoured that — so identical request bodies produced opposite behaviour
+depending on whether the caller validated before sending, with the validating
+caller silently losing its triggers. Those bulk loads ran with automations off and
+will now run with them on, which is what an unvalidated caller always got. A caller
+that never parsed its own request body is unaffected in every direction.
+
+`dryRun` is untouched and still runs **no** automations whatever this flag says
+(#6037).
+
+Maintainer ruling 2026-08-09 (#6704), disposition A — the spec follows the runtime:
+
+> **Maintainer ruling (2026-08-09): disposition A — the spec follows the runtime.** `ImportRequest.runAutomations` becomes `.default(true)` with corrected describe prose (state that automations run by default and opt-out must be explicit, per the #2922 rationale); the generated reference tables follow. Runtime behaviour unchanged. [...] Changeset notes the declared-default flip of a published schema (a correction toward the actual shipped behaviour, not a behaviour change).
+
+The declared move itself is recorded per key in `DEFAULT_CHANGES_BY_MAJOR[17]`, whose
+`from`/`to` fingerprints are re-derived on every build, so the declaration cannot
+outlive the fact it describes.
+
+<!-- adr-0087: registered import-run-automations-declared-default-corrected -->

.changeset/meta-save-manage-metadata-gate.md

@@ -0,0 +1,39 @@
+---
+"@objectstack/rest": minor
+---
+
+feat(rest): `PUT /api/v1/meta/:type/:name` 要求 `manage_metadata` 能力 (#6603)
+
+**这是一次访问面收紧,线上可见。** 保存单个元数据项的这条路由此前只有
+`enforceAuth` —— 任何已认证会话都能写任意元数据项。现在它与隔壁的
+`POST /api/v1/meta/_migrate-stored` 用同一道门、同一套机制:调用方必须持有
+ADR-0066 D1 的 `manage_metadata` 能力,`isSystem` 照例放行。
+
+## 谁开始吃 403,需要什么
+
+**任何不持 `manage_metadata` 的已认证调用方**,对这条路由的 `PUT` 一律
+403 `FORBIDDEN`(匿名调用方仍先吃 `/meta` 伞下的 401,门是第二层)。
+平台自带的 `admin_full_access` 权限集本就带 `manage_metadata`,所以
+Studio / Setup 里的管理员与 CLI 的 dev admin **不受影响**;受影响的是
+自建集成、自建权限集,以及只持 `setup.access` 的 `organization_admin`。
+
+**要恢复写入:给该调用方的权限集加上 `manage_metadata`**(Setup →
+Permission Sets → `systemPermissions`),而不是绕过这条路由。
+
+## 为什么必须收紧
+
+ADR-0106 D1 会把调用方不可读的字段**整个**从服务出的对象 schema 里摘掉,
+而这条路由原样持久化收到的 body。于是一次最普通的
+GET → 改个 label → PUT,就把调用方**从来没被允许看见的字段删掉了**,
+整个交互过程中没有任何东西提示。GET-改-PUT 正是 AI agent 编写元数据的
+标准动作,原先这个动作会静默销毁它看不见的字段;现在它在写入时得到一个
+**响亮的 403**。
+
+同时这也关掉一个与掩码无关、更早就存在的洞:任何已认证会话都能覆写
+任意 schema。
+
+## 尚未关闭的部分
+
+本次只收紧这一条路由。同形的 `PUT /meta/:type/:section/:name`(复合名)
+与运行时 dispatcher 自己的 `/meta` PUT 仍无能力门,同一次往返丢失仍可经
+它们复现 —— 已另立 #7019 跟踪,不在本次范围内。

.changeset/public-form-empty-declaration-refusal.md

@@ -0,0 +1,55 @@
+---
+"@objectstack/rest": minor
+---
+
+fix(rest): a public form that declares no fields now REFUSES the submit instead of accepting every key the caller sent (#6920)
+
+`POST /api/v1/forms/:slug/submit` narrows a visitor's suppliable keys to the
+fields the matched FormView's `sections` declare — and the filter read
+`allowedFields.size === 0 || allowedFields.has(k)`. For a form with no declared
+fields that limb degenerated, and not into "every field of the object": it
+accepted **every key the caller sent**, minus the `#3022` server-managed anchors
+and the three prototype keys. Measured on the real registered handler,
+anonymously, against a `sections: []` form:
+
+    submit accepted = ["email","internal_margin","internal_tier",
+                       "not_even_a_field","status","subject"]
+
+`not_even_a_field` is not declared on the target object at all. So an anonymous
+visitor could set `status`, a workflow stage, an internal tier — anything, on
+the one object the form targets. `publicFormGrant` (ADR-0056) keeps the insert
+scoped to that object, so this was never a cross-object hole; it was an
+unbounded **column** surface on one. The way in is an ordinary authoring
+mid-state: the author creates the public form and wires its sections later.
+
+**What changes.** A form whose sections declare no fields now answers
+`400 VALIDATION_ERROR` and inserts nothing. The message names the empty
+declaration and gives the author's fix ("wire the fields it collects into the
+form's sections"); it names no object, field or slug, because this reply is
+readable by anyone on the internet. The three authoring shapes that reach it —
+`sections: []`, sections present but declaring no fields, and `sections` omitted
+— are treated identically, and the refusal keys off the **declaration**, not the
+body, so an empty POST is refused too rather than inserting a blank row.
+
+`VALIDATION_ERROR` is the standard ADR-0112 catalog's generic validation
+failure, and what `HttpStatusErrorCodeMap[400]` already names a bare 400. It is
+deliberately not a newly minted `FORM_*` synonym of a condition the catalog
+already covers.
+
+**Why a refusal and not a silent drop.** Dropping the keys would have kept the
+`201` and changed no wire status, but it would swallow data the caller believes
+it wrote — a visitor is told their support ticket was filed and an empty row is
+stored. Loud is also the only answer that reaches the author, who is the one who
+can fix it.
+
+**This is a behaviour change on a shipped success path.** A deployment that
+today collects submissions through a section-less public form starts getting
+`400`s. That form's read side already publishes nothing (`fields: {}`) since
+`#6601`, so it cannot render either — the two planes now enforce the same rule,
+"the form declares what it collects", on both. **Fix: declare the fields in the
+form's `sections`.** Forms that already declare sections are entirely
+unaffected — that path never consulted the removed limb.
+
+`#3022`'s anchor guarantee is preserved unchanged: `owner_id`,
+`organization_id`, `id` and the audit columns remain unsuppliable on this
+surface, including when a FormView mis-declares one in a section.