Merge remote-tracking branch 'origin/main' into claude/issue-14256-declarative-job-outcome

Author: claude

.changeset/adr0130-metadata-door-reads-packages.md

@@ -0,0 +1,75 @@
+---
+"@objectstack/metadata": patch
+"@objectstack/core": minor
+"@objectstack/objectql": patch
+"@objectstack/runtime": patch
+---
+
+fix(metadata): register a `packages[]` artifact per package at the metadata door so every object has one owner across every door (#14599)
+
+A release artifact carrying `packages[]` (ADR-0130 D4) was read at the metadata
+door as if it carried one package: `MetadataPlugin._parseAndRegisterArtifact`
+iterated the **flattened top level** and stamped every item with the artifact's
+own `manifest.id`. For an artifact composed with `composeStacks(…, { manifest:
+'preserve' })` that id is one arbitrary member's — `selectManifest`'s `'last'`
+pick — so a two-package artifact registered the **module's** object under the
+**App** package's identity, while the ObjectQL load path, reading the same
+artifact's `packages[]`, owned it under the module's.
+
+The platform then held two answers to "who owns this object", and which one a
+consumer saw depended on the door it went through. Measured on a real boot of
+`examples/app-multi-package`:
+
+- `GET /api/v1/meta/object` served `crm_order` **twice** — the list merge keys
+  slots by `${packageId}${name}`, so the two differently-attributed copies
+  landed in two slots;
+- `GET /api/v1/meta/object?package=<the App package>` returned the **module's**
+  object, because the App-stamped copy was re-ingested into the registry as that
+  package's contribution;
+- the layers door named the App package while the item door and
+  `GET /api/v1/packages` named the module;
+- Studio's Data pillar for the App package listed the module's object — ADR-0130
+  Consequences §1.3a ("Studio's scope is the package") did not hold.
+
+**The door now reads both shapes, and attributes every item to the body it was
+found in.** `packages` present → each assembled package body's collections are
+registered stamped with **that body's** id; `packages` absent → the single
+`manifest` branch runs exactly as before (D7). The owner is read off the body an
+item was found in — never reverse-derived by matching a top-level item's name
+against a name-to-package index, which would be the second metadata-identity
+resolution path #14512's triage rejected by name.
+
+**Ordering and the entry gate are reused, not re-derived (D5).** The door calls
+the same `resolveArtifactPackageOrder` the ObjectQL load path calls, so the two
+readers of one `packages[]` cannot disagree about the registration order **or**
+about which artifacts are loadable at all.
+
+⚠️ **`resolveArtifactPackageOrder` / `artifactPackageId` moved to
+`@objectstack/core`** — hence the `minor` there. They were in
+`@objectstack/objectql`, which **depends on** `@objectstack/metadata`, so the
+metadata door could not import them from where they lived; `@objectstack/core`
+already owns `resolvePluginOrder` and is already a dependency of both readers,
+so hosting them there adds **no edge** to the package graph. `@objectstack/objectql`
+re-exports both under their existing names — its published surface is unchanged,
+which is why it is graded `patch`. `@objectstack/runtime` is `patch` for the
+dispatcher error vocabulary's `file:` anchors, repointed at the new path.
+
+**Single-package artifacts are byte-for-byte unaffected (D7)**, measured rather
+than asserted: the whole `manager.register` sequence for a single-`manifest`
+artifact — every call, in order, with the id and version each item was stamped
+with — is pinned as a literal in
+`packages/metadata/src/plugin-artifact-packages-attribution.test.ts` and was
+recorded identically on both legs of the ablation. A real boot of
+`examples/app-todo` answers every door identically before and after.
+
+**Nothing a booted instance can see today disappears.** Every live
+`ARTIFACT_FIELD_TO_TYPE` key is a member of `AssembledPackageBodySchema`
+(measured, not assumed), so iterating bodies loses no collection; and because
+`packages` composes by `concat`, an artifact whose top level carries a
+definition no package body repeats keeps it — registered once, attributed to the
+artifact's own identity, and logged, because it means the artifact's two halves
+disagree about what it ships.
+
+⛔ The **producer** half is untouched: `composeStacks` and `os build` keep
+emitting the flattened top level alongside `packages[]`. Whether they should is
+#14512's decision, not this door's.

.changeset/auth-email-accept-language.md

@@ -0,0 +1,37 @@
+---
+"@objectstack/plugin-auth": minor
+---
+
+feat(plugin-auth): auth mail follows the caller's `Accept-Language`, deployment default second (#14319)
+
+Request-triggered auth email — signup verification, password reset, magic link,
+and the change-email notice — now picks its `sys_email_template` row from the
+requesting caller's `Accept-Language`, falling back to the deployment default
+(`localization.locale`, then `i18n.defaultLocale`) and finally to
+`EmailService`'s documented `en-US`.
+
+The motivating case is the one no deployment default can answer: at cloud
+self-service signup there is no workspace yet, so nothing on the server
+represents that person's language — a Chinese browser reached a Chinese signup
+screen and received an English verification email.
+
+The header is parsed by the platform's existing `preferredLocaleFromHeader`,
+the same function REST uses for metadata translation and the runtime dispatcher
+uses for `ExecutionContext.requestLocale`, so the mail cannot disagree with the
+screen that triggered it. A requested locale takes effect only when it names one
+of `AUTH_EMAIL_TEMPLATE_LOCALES` (`en-US`, `zh-CN`, `ja-JP`, `es-ES`); anything
+else falls through rather than naming a row that does not exist.
+
+Two deliberate exclusions. **Invitations keep the deployment default**:
+better-auth hands that callback a request too, but it is the *inviter's*, and
+stamping their browser language onto the invitee's mail would reproduce this
+same defect one seat over. **Per-user language stays deferred** — `sys_user`
+grows no locale column here.
+
+This ships as `minor` because it changes which template row an existing
+deployment sends: a workspace whose users' browsers ask for a different language
+than the workspace declares will now send in the browser's language.
+
+**Ruling:** maintainer, 2026-09-02, superseding the 2026-08-13 ruling that had
+rejected `Accept-Language` outright. Both are recorded, with the older one
+marked superseded, on `AuthManager.setDefaultEmailLocale`.

.changeset/automation-result-stranded-status.md

@@ -0,0 +1,22 @@
+---
+"@objectstack/spec": minor
+---
+
+feat(spec): name the terminally-failed-but-repairable run on `AutomationResult.status` — `'stranded'` (#14384, contract half of #13937)
+
+`AutomationResult.status` (`contracts/automation-service.ts`) gains a fourth
+member beside `'completed' | 'paused' | 'failed'`: **`'stranded'`** — the run
+whose resume CONSUMED its suspension and then had a downstream node throw, so
+the run is recorded as failed and can be re-armed only by an explicit operator
+verb (#13909's condition; the #13937 shape-4 ruling, maintainer 2026-09-01
+「命名同批定」). The wire mirror `TriggerFlowResponseSchema.data.status`
+(`api/automation-api.zod.ts`) carries the same four, and a pin test binds the
+two at the type level and the value level.
+
+Additive: no existing literal changes meaning, `'failed'` still says "the run
+ran and was rejected", and no engine, route or client behaviour moves in this
+change — the engine begins stamping `'stranded'` when #13937's services half
+(the operator re-arm verb) lands. A consumer that switches exhaustively over
+`status` needs a `'stranded'` arm; the measured count of such switches in this
+repo is zero. plugin-approvals' report-only `StrandedRunState`
+(`'missing' | 'failed'`) is deliberately not promoted (same ruling).

.changeset/flow-loop-per-iteration-containment-lint.md

@@ -0,0 +1,35 @@
+---
+"@objectstack/lint": patch
+---
+
+flows: warn on a `loop` body with a fallible node and no containment, and on a `try_catch` with no `catch` (#14394)
+
+Two authoring-time rules in the flow anti-pattern family, both `warning`:
+
+- **`flow-loop-body-uncontained`** — a `loop` whose `body` region runs a node
+  that can end the run (a record read/write, `http`, `notify`,
+  `connector_action`, `script`, `subflow`, `map`, `approval`) with no
+  `try_catch` between the loop and that node. The `loop` executor iterates with
+  a bare `await` and has no `try`/`catch` at all, so the first failing item ends
+  the whole run: later items are never processed, and the work already done is
+  not even reported. The finding names the loop, the node, and the prescribed
+  spelling.
+- **`flow-try-catch-without-catch`** — the near-miss, and the first target
+  rather than an extra: `catch` is optional in the schema, and omitting it makes
+  the container fail through, so an author who wrapped the node and stopped
+  there gets **zero** containment and previously got no diagnostic either.
+  Measured, the no-`catch` run and the unwrapped control produce identical
+  output; a `retry` policy only delays that.
+
+Both stay warnings under the family's severity bar: a loop deliberately allowed
+to stop at the first failure, and a retry-then-fail `try_catch`, are legitimate
+readings the rule cannot disprove.
+
+`content/docs/automation/flows.mdx` documents `loop { try_catch { … } }` as the
+per-iteration containment spelling, with the measured minimal handler — one bare
+`assignment` node, `edges` and `errorVariable` omitted — and the three `catch`
+spellings the schema refuses (`catch` omitted gives no containment; `catch: {}`
+and `catch: { nodes: [] }` are rejected, the region's `nodes` being `.min(1)`).
+
+No spec, engine or runtime change: the containment capability already exists and
+was measured working (5 of 5 iterations, items 4-5 processed, run completes).

.changeset/liveness-rest-server-config-sub-objects.md

@@ -0,0 +1,53 @@
+---
+"@objectstack/spec": patch
+---
+
+chore(spec): govern the four `RestServerConfig` sub-objects in the liveness ledger (#14369)
+
+The `liveness/` ledgers ship inside this package's npm tarball (they are named in
+`files`), so this is a published-data change even though no runtime behaviour
+moves, no schema key changes spelling, and `packages/spec/src/api/rest-server.zod.ts`
+is not edited at all.
+
+Four new ledger files — `crud_endpoints.json`, `metadata_endpoints.json`,
+`batch_endpoints.json`, `route_generation.json` — classify all 32 authorable
+properties of `CrudEndpointsConfigSchema`, `MetadataEndpointsConfigSchema`,
+`BatchEndpointsConfigSchema` and `RouteGenerationConfigSchema`, the four
+`RestServerConfig` sub-objects a host writes when it constructs the REST server.
+They are enrolled through the gate's `SPEC_ONLY_SCHEMAS` override, the route
+`query` / `qa` / `manifest` already take: server configuration is neither a
+metadata item nor a request body nor a manifest, so no registry has ever held it
+and no ratchet rooted in one could ask who reads it.
+
+Seventeen properties are `live` with a symbol-anchored consumer and a producer
+pointer at the normalizer that threads the authored value into `this.config`.
+Fifteen are `dead` — the ten keys the census filed with this card measured, with
+the two container keys (`crud.patterns`, `routes.overrides`) expanded into a row
+per member. `routes` is dead entire: `excludeObjects: ['sys_log']` excludes
+nothing and `nameTransform: 'plural'` still mounts every route under the raw
+object name. `metadata.endpoints.schema` and `batch.operations.upsertMany` are
+switches for routes that were never built — no path ending in `/schema` is
+mounted anywhere in `packages/rest/src`, and the protocol has no `upsertManyData`
+counterpart to its three sibling batch methods.
+
+What this records, and what it deliberately does not. #11984 made
+`RestServer.normalizeConfig` PARSE and CONSUME these four sub-objects instead of
+casting them, so an out-of-enum or out-of-range value is now refused at
+construction. That settles accept/reject and nothing else: executing a declared
+contract does not give a key a consumer. No key is removed, enforced, deprecated
+or re-described here. The enforce-or-remove call per dead key (ADR-0049) is a
+follow-up on the human floor — the enforce route is a feature per key, and
+`routes.excludeObjects` is advertised in `RestServerConfigSchema`'s own
+`@example`, which makes its removal a capability retirement rather than a cleanup.
+
+Rooted on the four sub-schemas rather than on `RestServerConfigSchema` itself,
+which is measurement rather than taste: the ledger walk drills exactly ONE level,
+so with the whole config as the root the sub-objects would BE the drilled level
+and `metadata.endpoints.schema` / `batch.operations.upsertMany` would have no row
+of their own — their container's blanket `live` (three of four members gate a real
+route mount) silently covering a dead key, which is the #4956 shape in the file
+written to end it. `RestApiConfigSchema` (the fifth sub-object, `api`) is not
+enrolled: its consumption seam is still validate-only and is the subject of its
+own card, so a census of it would record a half that is about to move.
+
+<!-- adr-0087: not-required (no-migration-prescription) Nothing authorable is removed, renamed or re-described: this change adds ledger rows and a gate enrolment, and every key it classifies keeps the exact spelling, type, default and describe() it had. There is no source for `objectstack migrate meta` to rewrite, because no author's config becomes invalid or becomes valid as a result. -->

.claude/agents/os-dev.md

@@ -325,19 +325,19 @@ dispatch prompt 只携带每单增量(裁决引文、裁决 / PM-机制假设分
   内容的 PR 顺带」、2026-08-29 裁「筹行(为内容购买行数)⛔ vs 独立密度修复(无内容购买)允
   许」。分界只问折行有没有为新增内容买行 —— 门禁分不出两种 net-0;⛔ 不买内容的密度
   修复是修复,不要当筹行拒掉。删不出等量内容 ⇒ 报 `blocked`,⛔ 不抬 ceiling(人工地板)。
-- **`skip-changeset` 标签按仓库分流——先认清目标仓库有没有这个机制。** 判据:**不从任何包
-  发布东西**;闭合清单:仅含 `docs/adr/**` · `.claude/**` · `scripts/pm/**` · tests/workflow · 注释 的
-  diff。**本仓库**:标签是真实机制,打标签是你的步骤、不是 CI 的,**PR 一开出就打**,⛔ 永不
-  等 Check Changeset 转红再补。写入首选**加法端点**(REST `POST .../issues/<n>/labels`——不碰已有标
-  签),⚠️ 可达性是**会话**属性、不是端点或席位的(门先于端点应答、读写同拒,门开会话
-  实测 200;读数住 platform-readings)⇒ 先探后用;被拒 ⇒ 走回退:MCP 读现值→并集→整组
-  写→**必做对比式读回**(diff 现集对 union(读集, 目标),union 有而回读缺 = 被剥的并发标签,重
-  挂并写进报告;读回只**检测**剥除防不了,门语义标签被剥恰成绿灯),并申报换道。加法写
-  同样必要不充分:size-labeler 整组 PUT 曾 ~1 秒内抹掉正确加法写——收尾一律读回、清单引
-  进报告;标签消失读作被抹,**重新加上**,不是你的错。关此步骤的是读回不是写入;读回
-  验「写落了」验不出「有门在读」——幻影门标签读回照样成功。**objectui:同名标签对象
-  在(历史误挂铸出),零 workflow/脚本读它、豁免不了任何东西,pin 测试钉着**——那边用空
-  frontmatter 的 changeset 声明,门禁判定行是权威;⛔ 永不在那边施加该标签。
+- **`skip-changeset` 标签按仓库分流——先认清目标仓库有没有这个机制。** 判据是规则:**不从
+  任何包发布东西**;清单仅为示例(`docs/adr/**` · `.claude/**` · `scripts/pm/**` · 仓根工具配置 ·
+  `examples/**` 等私有 workspace · tests/workflow · 注释)。**本仓库**:标签是真实机制,打标签是你
+  的步骤、不是 CI 的,**PR 一开出就打**,⛔ 永不等 Check Changeset 转红再补。写入首选**加法端
+  点**(REST `POST .../issues/<n>/labels`——不碰已有标签),⚠️ 可达性是**会话**属性(读写同拒;读
+  数住 platform-readings)⇒ 先探后用;被拒 ⇒ 走回退:MCP 读现值→并集→整组写→**必做对比式
+  读回**(diff 现集对 union(读集, 目标),union 有而回读缺 = 被剥的并发标签,重挂并写进报告;读
+  回只**检测**剥除防不了,门语义标签被剥恰成绿灯),并申报换道。加法写同样必要不充
+  分:size-labeler 整组 PUT 曾 ~1 秒内抹掉正确加法写——收尾一律读回、清单引进报告;标签消
+  失读作被抹,**重新加上**,不是你的错。关此步骤的是读回不是写入;读回验「写落了」验不
+  出「有门在读」——幻影门标签读回照样成功。**objectui:同名标签对象在(历史误挂铸出),
+  零 workflow/脚本读它、豁免不了任何东西,pin 测试钉着**——那边用空 frontmatter 的 changeset
+  声明,门禁判定行是权威;⛔ 永不在那边施加该标签。
 - **报告在 draft PR 时点交付 —— CI 收敛等待归 PM,不归你**(维护者 2026-08-10 拍板)。分支一推
   上、draft PR 一开出,立刻交报告;门禁状态如实记录 —— `in_progress` 是诚实值。⛔ draft PR 开
   出后永不 sleep、定时等待或空转轮询 CI(实测:空转轮询烧掉的恰是一个红门禁需要的预