Merge remote-tracking branch 'origin/main' into claude/issue-13533-system-write-sharing-materialization

Resolves the single CONFLICT (content) in
content/docs/permissions/system-context.mdx (the os-regen driver flags
this file as MIXED — generated anchors plus hand-written prose — so it
text-merges instead of taking one side whole).

Row 37 (share-link policy `enabled` check, isSystem) diverged: this
branch's copy already carried the #14033 prose ("resolution is not
bypassed since #14033 ... a link minted this way does not resolve
until the block is enabled"), added when 13bf05d landed on both
branches. main's copy had reverted to the pre-#14033 wording via an
unrelated commit (8ce628a, "store a serializable manifest projection
in the package registry (#14499)") whose own docs-regen step appears
to have run against a stale pre-#14033 checkout of this file.

Kept this branch's row 37 text: packages/plugins/plugin-sharing/src/
share-link-service.ts:652-697 (the `[#14033]` docblock and the
`if (!policy.enabled)` redemption-time check it documents, citing the
maintainer's 2026-09-01 ruling and this exact ledger row by number)
confirms it is what the current source does, not the reverted main
copy. Row 36 differed only in its generated anchor line number
(1088 vs 1077) — anchor numbers are recomputed by
`pnpm gen:system-context-census` below, so either side was equivalent;
kept this branch's.

Anchors re-derived on the merged tree with
`pnpm gen:system-context-census` in a follow-up commit, per the
os-regen driver's documented recovery for this file.

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

Author: claude

.changeset/action-description-and-params-translation.md

@@ -0,0 +1,33 @@
+---
+"@objectstack/spec": patch
+---
+
+fix(spec): an action's `description` and its parameter dialog now honour the translation bundle
+
+`translateAction` overlaid only `label`, `confirmText`, `successMessage` and
+`resultDialog`. The keys for the rest were already there — the translation
+schema declares `_actions.ACTION.description` and
+`_actions.ACTION.params.PARAM.{label, helpText, placeholder, options}`, and the
+translation linter validates both, reporting a parameter key the action does not
+declare with a did-you-mean naming the ones it does. So the keys parsed, they
+linted, and they resolved to nothing: a translated deployment rendered a
+translated action button that opened an untranslated form, because an action's
+`description` is the explanatory line under the dialog title and its
+parameters' `label` / `helpText` / `placeholder` / option labels are the rest of
+that dialog.
+
+They are applied now, wherever the action is served — the REST metadata read,
+OpenAPI, MCP — and through `globalActions` for an action that belongs to no
+object, the same object-scoped-first order every other action key already used.
+
+Parameters are matched by `name`, falling back to `field` for a field-backed
+parameter that names no key of its own: the same rule the linter collects
+parameters by, so a key the linter accepts is a key the resolver finds. Option
+labels are matched on the stored option `value`, since the authored side is an
+array of options while the translation side is a `value` to label map.
+
+Nothing changes for a bundle that carries none of these keys: the authored text
+is kept, the parameter array keeps its identity, and a bundle key naming a
+parameter the action does not declare is ignored rather than invented into the
+dialog. No schema, no validator and no accepted shape moves — every key applied
+here was already declared and already validated.

.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/chilled-eels-shave.md

@@ -0,0 +1,16 @@
+---
+'@objectstack/objectql': patch
+---
+
+A `state_machine` rule's refusal now carries `constraint` and `value` alongside an **author-written** `message`, not only alongside the built-in one (#14311).
+
+`checkStateMachine` emitted the full field-error envelope — `field`, `code`, `message`, `label`, `constraint`, `value` — when the rule left its message empty, but dropped `constraint` and `value` the moment the rule declared one. Since `ValidationRuleSchema` **requires** `message` on every rule, the machine-readable half was in practice reachable only by declaring `message: ''`: every normally-authored state machine refused writes with no way for a client to learn *which* states are legal.
+
+A create form that wants to offer exactly the declared `initialStates`, or a detail page that wants to grey out illegal transitions, had to parse the author's prose or keep a second copy of the state machine.
+
+Now both paths emit the same envelope:
+
+- insert — `constraint: { allowed: 'planned' }`, `value: 'active'`, `code: 'invalid_initial_state'`
+- update — `constraint: { from: 'draft', to: 'approved' }`, `code: 'invalid_transition'`
+
+The author still owns the wording; only the facts beside it are restored. Nothing about which writes are refused changes, and `constraint` / `value` are already declared on `FieldValidationError` (mirroring `FieldErrorSchema`), so no consumer contract widens — REST ships the same `400 VALIDATION_FAILED` envelope with the fields it always declared.

.changeset/cli-generate-ghost-field-types.md

@@ -0,0 +1,47 @@
+---
+"@objectstack/cli": patch
+---
+
+fix(cli): `os generate` stops naming field types that do not exist (#13871)
+
+`packages/cli/src/commands/generate.ts` carried three hand-authored field-type
+vocabularies — `FIELD_TYPE_MAP` (`os generate types`), `FIELD_TYPE_SQL_MAP`
+(`os generate migration --format sql`) and the `switch (fType)` in the
+typescript migration generator — and none of the three had ever been checked
+against the `FieldType` enum it claims to describe. Between them they named six
+types the platform has never had: `slug`, `ip_address`, `encrypted`, `integer`,
+`uuid`, and `geo_point`.
+
+They are not leftovers of retired types. `git log -S` over the whole reachable
+history of `packages/spec/src/data/field.zod.ts` returns zero commits for every
+one of those tokens — they were invented in the CLI and mirrored table to table
+inside this one file.
+
+Through every supported authoring path the arms were unreachable: `os init`
+scaffolds `export default defineStack({ … })`, `define*` is a strict
+`Schema.parse`, and a field typed `slug` is refused while the config module is
+evaluated — before the generator runs a line. The one input class that could
+reach them is a config that parses nothing (a plain-object default export, or
+`defineStack(x, { strict: false })`), and for that class the generators were
+emitting bespoke columns for types no runtime can serve. A vocabulary is a claim
+about what the platform accepts, so the visible cost of keeping them was that
+anyone — or any model — reading this file to learn the field types learned six
+that do not exist.
+
+Every ghost is removed rather than re-spelled. None of the six was a
+misspelling of a real member with a fix to apply: `number` already had its own
+entry and arm, so `integer` had nothing to correct to; `address` is a structured
+postal address, not an IP; and the concepts that later arrived under other names
+(`secret`, `location`) have no entry in these tables at all, which is a separate
+coverage question rather than a spelling one.
+
+Behaviour is unchanged for every config the platform accepts. For a config that
+bypasses validation, a field typed with one of the six now falls to the same
+default any unknown type gets — `table.text` / `TEXT` / `unknown` — instead of a
+bespoke column.
+
+`generate-field-type-vocabulary.pin.test.ts` now reads all three vocabularies
+out of the source and fails on any key or case label that is not a `FieldType`
+member, so the class cannot reopen. The pin is forward-only: real members with
+no entry still fall through to the deliberate default, which it does not
+prejudge.

.changeset/converge-standalone-action-owner-key.md

@@ -0,0 +1,57 @@
+---
+"@objectstack/objectql": minor
+"@objectstack/runtime": patch
+---
+
+refactor(objectql,runtime): give the standalone-action owner-key ladder one spelling (#14422)
+
+`action.objectName` -> `action.object` -> the object-less `'global'` key decides
+which engine key a standalone `action` declaration is filed under. It was
+written out three times — `standaloneActionOwnerKey` in
+`packages/objectql/src/action-governance.ts`, `standaloneActionObjectName` in
+`packages/runtime/src/action-execution.ts`, and a private
+`ObjectQLPlugin.actionObjectKey` — and the only thing holding the three equal
+was a sentence in each docblock saying it must stay in lockstep with the
+others. #14123 was already the bill for that shape: two readers of "where does
+this declaration live" answering from different code.
+
+All three now resolve to the one implementation. The plugin calls
+`standaloneActionOwnerKey` directly (same package, four call sites, not the one
+the card estimated); the runtime re-exports it in the ADR-0110 block that
+already exists in that file for exactly this purpose, alongside
+`GLOBAL_ACTION_OBJECT_KEY`, `isObjectLessActionKey` and the rest. No behaviour
+moves: the three ladders were measured equivalent across a twelve-row truth
+table before the change.
+
+**The divergence this removes was real, not hypothetical.** The plugin's copy
+terminated on a bare `'global'` string literal while the other two return the
+shared `GLOBAL_ACTION_OBJECT_KEY` constant. The constant is `'global'` today, so
+the three agreed and nothing was broken — but the plugin copy was the one that
+would have parted from the others in silence the day that constant moved, and
+no test in the repo would have caught it. The same literal in the plugin's
+`isArtifactShippedAction` reader is converged to the constant with it.
+
+**`_deps`: kept, as a delegating alias — not dropped.** The engine helper is
+`standaloneActionOwnerKey(action)` and the runtime's name is
+`standaloneActionObjectName(_deps, action)`. `_deps` was already unused, but
+dropping it would move an EXPORTED signature to save two characters at the two
+in-repo call sites, both of which live in `action-execution.ts` itself. The
+alias keeps its arity and its meaning, so `ownsRoute` and any out-of-repo
+importer compile and behave exactly as before; its body is now
+`return standaloneActionOwnerKey(action);` and nothing else.
+
+**Levels, and the instrument.** `@objectstack/objectql` is `minor` because
+`standaloneActionOwnerKey` had to be added to its published entry
+(`src/index.ts`) for the runtime to import it at all — measured in the built
+`packages/objectql/dist/index.d.ts`, where the name is now both declared and
+exported. `@objectstack/runtime` is `patch`: `action-execution.ts` is not
+re-exported from `packages/runtime/src/index.ts` and the package publishes only
+`.`, so the new re-export does not reach the published entry — measured as zero
+occurrences of `standaloneActionOwnerKey`, `standaloneActionObjectName` and
+`GLOBAL_ACTION_OBJECT_KEY` in the built `packages/runtime/dist/index.d.ts`,
+against a positive control of 32 for `HttpDispatcher`.
+
+The docblocks that promised lockstep are replaced by welds that enforce it —
+`action-owner-key-single-source.test.ts` in each package — because a docblock
+is not a check. Each is scoped to its own package's source, so neither becomes
+a cross-package test input.

.changeset/data-event-organization-id.md

@@ -0,0 +1,34 @@
+---
+"@objectstack/spec": minor
+---
+
+feat(spec): `DataEvent` names the organization the record belongs to, so a tenant-scoped consumer can tell whose event it is
+
+The realtime `DataEvent` payload (`@objectstack/spec/api`, the body of every
+`data.record.created` / `data.record.updated` / `data.record.deleted` event)
+gains an optional `organizationId`: the organization the record belongs to.
+Until now the event carried the object name, the record id and the row body,
+and nothing that named the tenant — so a consumer that fans events out per
+organization (a webhook subscription, a per-organization realtime subscriber)
+had no term to discriminate on short of reading the row body, which is absent
+on delete events and is not the consumer's to read.
+
+What a consumer may assume:
+
+- **Present** — exactly that organization, never a guess: the organization the
+  record belongs to, not the caller's active organization standing in for it.
+- **Absent** — the record belongs to no organization. That is every event on a
+  `single`-posture deployment (no organization wall, nothing stamps the
+  column) and an organization-less, environment-wide row under a walled
+  posture. Read it as "not behind any organization wall", never as "unknown,
+  look it up".
+
+Declared = enforced: the key is optional and nothing else. No default
+fabricates a tenant; `null` and the empty string are refused with a located
+issue, so "no organization" has exactly one spelling — the key is absent.
+
+Additive and shape-preserving: every event that parsed before parses
+identically, and no producer emits the key yet — the ObjectQL engine's publish
+site is a separate change that follows this contract. The bulk
+`BulkDataEvent` (`data.records.*`) is deliberately untouched: a predicate
+write's affected set is its own contract with its own tenant question.