Merge origin/main (post-#6526 retirement sweep) into claude/issue-5728-i18n-label-contract-sweep

Second conflict round on the pin count: the sweep's -7 (755->748) merged in
under this branch's +1 (InlineLocaleMapSchema); receipts stacked in merge
order, count recomputed from the file = 749. Generated files taken from
origin/main verbatim; regenerated wholesale in the follow-up commit.

Author: claude

.changeset/docs-gen-same-dir-bare-path.md

@@ -0,0 +1,31 @@
+---
+"@objectstack/spec": patch
+---
+
+fix(spec): 参考页里写在同目录的裸源码路径不再以纯文本落地 (#6484)
+
+参考页开篇那段模块描述由 `packages/spec/scripts/lib/file-description.ts` 渲染。它把
+JSDoc 里裸写的 `*.zod.ts` 路径改写成站内链接,而这条机制的**两侧**过去都要求路径里
+至少有一个目录段:改写正则的 `[\w-]+/` 分组是必需的,`build-docs.ts` 的
+`sourcePathToDocsRoute()` 也要求那个斜杠、并把第一段读作分类名。
+
+于是作者按最自然的方式引用邻居 —— 写 `auth.zod.ts` 而不是 `identity/auth.zod.ts` ——
+两侧都匹配不上,既没成链接,也没回退成代码段,以**纯文本**发布在四张参考页上,共 9 处:
+`api/realtime-shared`、`cloud/package`、`identity/identity`、`system/security-context`。
+
+缺的从来不是正则,而是**上下文**:`build-docs.ts` 按分类遍历,自己知道正在渲染哪个目录,
+却只把一个成员交给渲染方。现在 `FileDescriptionContext` 增加 `fromCategory`,由
+`build-docs.ts` 传入,裸文件名在渲染方补全成 `<分类>/<文件>` 后再去解析 —— 与
+`schemaHrefFrom(fromCategory)` 是同一道缝。补全放在调用方一侧是有意的:裸名不是身份
+(#4696),`auth.zod.ts` 在多个分类下都存在,让解析器自己去全分类搜同名文件只会答出
+目录遍历最后到达的那一个。
+
+读者可见的变化是这 9 处:**5 处成为可点链接**(`api/realtime`、`api/websocket`、
+`cloud/package-version`、`cloud/environment-package`、`system/encryption`),**4 处回退成
+代码段**(`auth`、`audit`、`compliance`、`masking` —— 这四个邻居本就不存在,按 #6229
+的规矩「目标没有页面就不发链接」)。纯文本是三种结果里唯一错的那种,现在一处不剩。
+
+`sourcePathToDocsRoute()` 同时补上了它文档里一直声明、实现却没做的那一半:分类是真的
+不等于页面存在。旧实现只校验分类,这在放宽之前侥幸成立(能匹配上的路径恰好都有页面);
+放宽后那 4 个不存在的邻居会各产出一条 404 链接。现在按本次运行真正发出的页面清单判断,
+全语料 216 条站内路由、437 个位置,无死链。

.changeset/engine-suspended-run-store-log-cause.md

@@ -0,0 +1,40 @@
+---
+"@objectstack/service-automation": patch
+---
+
+fix(service-automation): the last three `engine.ts` seams stop splicing a driver's failure into the log message, and two of them are re-graded `error` (#6299)
+
+All three catches sit around the `SuspendedRunStore` driver and rendered their
+failure by interpolating the thrown value's `.message` into the log MESSAGE.
+`ObjectLogger.write()` adds exactly one `<ts> <LEVEL>` head per call, so a
+driver error carrying newlines turned ONE record into several physical lines of
+which only the first was greppable — and on the `warn` path, inside `serve`'s
+boot-quiet window, `BootLogCapture.offer()` keeps only lines with a level head,
+so the continuation lines were dropped outright. Measured on the restored
+concatenation: a three-line driver error became 3 physical lines and the boot
+filter retained 1, and that one carried no driver fact. The cause now goes to
+the logger's structured slot (`describeThrownForLog`), so the record stays on
+one physical line in every format. This closes the family of #5048 / #5575 /
+#5636 / #5661 / #5737 / #5912 / #6230 for this file.
+
+The level was judged per seam (#4632), not batch-copied from #6230:
+
+- **`forgetSuspendedRun` → raised to `error`.** The hot cache is dropped before
+  the store delete and this is the single choke point every consumption of a
+  suspension passes through, so a failed `delete` leaves the suspension gone
+  in-process and the durable row alive. Callers still report success, and the
+  surviving row is re-listed and re-resumed after the next restart, running a
+  continuation that already ran.
+- **`cancelRun` → raised to `error`.** An unreadable store makes the failed read
+  read as "no such suspended run", so the method returns `false` — which its
+  contract calls idempotent success — and the cancellation is silently skipped
+  while the call reads clean. The run stays parked and durably resumable.
+- **`listSuspendedRunsDurable` → stays `warn`.** Nothing claimed-persisted
+  failed to land: the rows are intact and still resumable by id. The listing
+  degrades to the in-memory cache alone, so the message now says out loud that
+  the result is short and that the caller cannot tell.
+
+Operator-visible: two records move from stdout to stderr and from `WARN` to
+`ERROR`, and all three messages are reworded to state their consequence. Log
+filters or alert rules keyed on the old `warn`-level text for a failed
+suspended-run delete or cancel need updating.

.changeset/etl-pipeline-layer-retired.md

@@ -0,0 +1,51 @@
+---
+"@objectstack/spec": major
+---
+
+refactor(spec)!: retire the L2 ETL layer — `automation/etl.zod.ts` had no executor, and the sync architecture doc was recommending it (#6414)
+
+`ETLPipeline`, `ETLPipelineRun`, `ETLSource`, `ETLDestination`, `ETLTransformation`,
+the `ETLEndpointType` / `ETLTransformationType` / `ETLSyncMode` / `ETLRunStatus`
+enums and the `ETL` factory are REMOVED under ADR-0049 enforce-or-remove. The whole
+file goes, on the same reading #4738 used to retire L1 `DataSyncConfig` one layer up:
+**narrative-only**. No engine ever parsed, scheduled or executed an `ETLPipeline`.
+
+Measured on `origin/main` immediately before the removal: the only non-spec
+references in this repo are two fumadocs-generated documentation sources
+(`apps/docs/.source/*.ts`), not executors; objectui has no reference at all; and
+there is no `packages/spec/liveness/etl.json`, so no ADR-0049 gate ever had a reading
+on the surface — while the same file family's EXECUTED half does have one
+(`liveness/mapping.json`), which is what makes that absence meaningful rather than an
+oversight.
+
+FROM → TO, layer by layer — with one gap stated plainly instead of redirected:
+
+| removed | use instead |
+|---|---|
+| `ETLPipeline.source` + `syncMode` + `schedule` (scheduled extraction from an external system) | `ConnectorSchema.syncConfig` (`integration/connector.zod.ts`) — the live, parsed sync surface: strategy, direction, cron schedule, `conflictResolution`, batching, delete mode |
+| `ETLTransformation` of type `map` / `cast`-like per-field work | `mapping.fieldMapping[].transform` (`data/mapping.zod.ts`) — `none`/`constant`/`map`/`split`/`join`/`lookup`, applied row by row by the REST import path |
+| `ETLPipeline.schedule` alone | `system/job.zod.ts` |
+| `ETLTransformation` of type `join` / `aggregate` / `script` / `merge` / `deduplicate` / … | **nothing.** There is no replacement because there was never an implementation — those ten transformation types named capabilities no runtime had. Do the work where it runs (the destination warehouse's ELT, a `flow`, a scheduled job), and let multi-stage movement return through ADR-0049's ENFORCE route: the engine first, the vocabulary second |
+
+**The fix:** delete the import. Nothing was ever deployed under an `ETLPipeline` —
+that is the finding, not a consolation — so there is no data migration; `tsc` reports
+TS2724/TS2305 at every import of a retired name.
+
+**`packages/spec/docs/SYNC_ARCHITECTURE.md` is rewritten in the same change**, and
+that is not incidental. It named `ETLPipeline` as the recommended destination for
+authors displaced by the L1 retirement and tabulated ten transformation types with
+copyable examples down to `script | Custom JavaScript/Python`. Retiring the schema
+while the doc still recommended it would have been self-contradictory, and
+forwarding L1's authors to a second layer with no executor was the defect compounding
+rather than closing.
+
+**Absorbed:** the #4962 `etl-retry-converged-onto-retry-policy` entry (`retry.maxAttempts`
+→ `maxRetries`, default 3 → 0) — both land in the unreleased protocol 17, so composed,
+a rename on a shape that does not survive the major has no observable effect, and its
+`retiredKey()` tombstone goes with the shape that carried it.
+
+The retirement kit — route 3: no tombstone, no D2 conversion.
+`RETIRED_DEFS_BY_MAJOR[17]` (9 defs) plus the D3 `SemanticMigration`
+`etl-pipeline-layer-retired` are the declaration.
+
+<!-- adr-0087: registered etl-pipeline-layer-retired -->

.changeset/http-server-runtime-vocabulary-retired.md

@@ -0,0 +1,52 @@
+---
+"@objectstack/spec": major
+---
+
+refactor(spec)!: retire `system/http-server.zod.ts`'s runtime vocabulary — the event, capability and status shapes nothing ever emitted (#5295)
+
+`ServerEventType`, `ServerEventSchema` / `ServerEvent`, `ServerCapabilitiesSchema` /
+`ServerCapabilities` / `ServerCapabilitiesParsed` and `ServerStatusSchema` /
+`ServerStatus` are REMOVED under ADR-0049 enforce-or-remove. This is the second and
+final pass over the file: #4938 removed its CONFIG half (`HttpServerConfigSchema`,
+nine keys, zero readers, zero authoring entry), and this removes the RUNTIME half —
+a 7-member lifecycle event union, an eight-boolean capability report and a
+five-state status record with connection and request counters. Nothing ever emitted,
+consumed or parsed any of them.
+
+FROM → TO:
+
+| removed | what actually decides it |
+|---|---|
+| `ServerEventType` / `ServerEvent(Schema)` | nothing emits a server event feed. Lifecycle is the transport plugin's own start/stop seam; observability is `system/metrics.zod.ts` + `system/logging.zod.ts`, and `OS_SERVER_TIMING` for timings |
+| `ServerCapabilities(Schema/Parsed)` | a transport plugin declares what it provides by implementing the kernel plugin contract — the seams it registers ARE the capability statement |
+| `ServerStatus(Schema)` | `/health` for liveness, the metrics surface for counters |
+
+**The fix:** delete the import. There is no replacement key, because there was
+never a key — none of the four was authorable on any shape. Server-level
+configuration that IS authorable is untouched: `defineStack({ server: { trustProxy,
+security } })` / `StackServerConfigSchema` (#5006) parses exactly as it did in 16.x,
+as does the route-registration half of the same module (`RouteHandlerMetadata`,
+`MiddlewareType`, `MiddlewareConfig`).
+
+**Why now, and what unblocked it.** The card was held rather than queued on a real
+doubt: a response/capability vocabulary can legitimately be a REFERENCE surface for
+host implementers, so "zero consumers in this repo" is weaker evidence for one of
+those than for an authorable key. It was lifted by measuring the reference reader
+itself — `plugin-hono-server`, the one in-tree host implementation, neither
+implements nor reports any of the three: it names no capability record, no status
+shape and no event union, and what it registers is routes and middleware. The
+control passed in the same sweep (`MiddlewareConfig`, twelve lines away, resolves to
+`packages/runtime/src/middleware.ts`).
+
+The retirement kit — route 3 of the retirement playbook, as #4938 was in this same
+file: **no `retiredKey()` tombstone and no D2 conversion**, because a prescription
+nobody can receive is noise and there is no authored document to rewrite.
+`RETIRED_DEFS_BY_MAJOR[17]` (4 defs) plus the D3 `SemanticMigration`
+`http-server-runtime-vocabulary-retired` are the declaration; the generated
+baselines (`json-schema.manifest/system.json`, `authorable-surface/system.json`,
+`api-surface/system.json`) lose their entries in the same change, deliberately.
+
+If host-implementer conformance becomes a real requirement it returns through the
+ENFORCE route: an adapter contract with a checker behind it, vocabulary second.
+
+<!-- adr-0087: registered http-server-runtime-vocabulary-retired -->

.changeset/import-dryrun-asks-for-the-verdict.md

@@ -0,0 +1,50 @@
+---
+"@objectstack/rest": patch
+"@objectstack/objectql": patch
+---
+
+fix(rest,objectql): the import dry run asks the engine for its verdict instead of predicting it (#4633 ruling D)
+
+`POST /api/v1/data/:object/import?dryRun=true` green-lit rows the very same
+endpoint then rejected. Measured on 17.0.0-rc.1: a CSV cell aimed at a
+structured `address` field reported `{ ok: 1, created: 1 }` on the dry run and
+`{ errors: 1, code: 'VALIDATION_FAILED' }` on the real write.
+
+The dry run predicted the write's verdict with a hand-copied mirror of a slice
+of the engine's rules (`import-coerce.ts`'s `firstMissingRequiredField` and
+`firstConstraintViolation`). A copy cannot structurally keep up with the family
+it mirrors: ADR-0104 value shapes (`address` / `location` / references / media),
+`format` checks, object-level `validations` and the state machine had no
+counterpart, and `coerceFieldValue` routes structured shapes through its
+pass-through catch-all, so no verdict was formed at all.
+
+**The mirror is retired.** The dry run now calls `DataProtocol.validateData`
+(#6037), which runs the same `validateRecord` / `evaluateValidationRules` that
+`insert()` runs, under the deployment's own ADR-0104 posture — so a bad value
+shape is an error on a self-certified deployment and an admitted warning on a
+warn-first one, exactly as on the write. Agreement is by construction, not by a
+copy kept in step by hand.
+
+Also in this change:
+
+- **`engine.validate()` now resolves `defaultValue`s and seeds owned roll-up
+  `summary` fields before validating, on `insert` mode**, because `insert()`
+  does. Without it a required-but-defaulted column left unmapped was previewed
+  `failed` and written `created` — a false alarm on the row a preview is meant
+  to reassure you about. `update` mode still does not default (#2706).
+- **A row report failed by validation now names the offending column.** The
+  engine's `ValidationError` carries `fields[]`, so the row's `field` is set and
+  its `code` is the field-level code (`required`, `min_value`, `max_length`,
+  `invalid_type`, …) rather than the wrapper's `VALIDATION_FAILED`. This is the
+  same vocabulary the dry run and the per-cell coercion failures already spoke;
+  before, a `min: 0` violation was `min_value` on the dry run and
+  `VALIDATION_FAILED` on the write.
+- **Dry-run rows may carry `warnings[]`** — findings this deployment admits
+  rather than rejects (ADR-0104 warn-first). The row is `ok`, and the complaint
+  is visible instead of living only in a server log line.
+
+A protocol that does not implement `validateData` (plugin-auth's identity
+import, whose write is better-auth rather than the engine) is not handed a
+substitute: its dry run reports coercion and create/update/skip resolution only.
+An engine-derived preview of a non-engine write would report findings that write
+never produces.

.changeset/lucky-pears-arrive.md

@@ -0,0 +1,25 @@
+---
+'@objectstack/cli': patch
+---
+
+fix(cli): `--json` now owns stdout — kernel boot logs move to stderr (#6217)
+
+Every `os migrate` / `os meta` subcommand that boots a kernel wrote its
+machine-readable payload into a stream it shared with ~60 INFO lines. The
+kernel logger routes `debug`/`info`/`warn` to stdout and only `error`/`fatal`
+to stderr, so `os migrate recorded-by --json | jq .` failed with `parse error:
+Invalid numeric literal` while stderr sat completely empty — a `--json` flag
+whose only audience is a program, handing that program something it cannot
+parse.
+
+With this change, a `--json` run reserves stdout for its payload: everything
+the kernel and its plugins write goes to **stderr** instead, including the
+`[StandaloneStack] no compiled artifact …` notice that never went through the
+logger at all. `JSON.parse(<entire stdout>)` now succeeds with no heuristic
+extraction, and no diagnostic is lost — every line an operator used to see is
+still printed, on the stream diagnostics belong on.
+
+Covers the whole family that shares the boot seam: `os migrate plan` / `apply`
+/ `resume` / `recorded-by` / `summary-nulls` / `value-shapes` /
+`files-to-references`, `os migrate meta --stored`, and `os meta resync`.
+Human-mode runs are unchanged.