Merge remote-tracking branch 'origin/main' into claude/issue-14325-silent-gate-declarations-s1

Author: claude

.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/lint-liveness-live-elsewhere-rule-id.md

@@ -0,0 +1,36 @@
+---
+'@objectstack/lint': minor
+---
+
+`lintLivenessProperties` no longer crashes on the `live-elsewhere` verdict — and never tells an author to remove a key a sibling repo enforces
+
+`describe()` in `lint-liveness-properties.ts` knew three verdicts
+(`experimental`, `planned`, `dead`) and threw, loudly and by design, on any
+other. #13483 then shipped the ledger's fifth status — `live-elsewhere`: dead
+HERE by measurement, genuinely enforced in a sibling repo — and migrated
+`manifest.runtime` onto it (its enforcer is the cloud marketplace publish
+gate). Nothing taught `describe()` about it, so the day any `live-elsewhere`
+row opts into `authorWarn: true`, `os lint` would raise that
+shipped-ledger-integrity error instead of the advisory warning the author
+should get. No shipped row carries `authorWarn` today, so this was a fuse
+rather than a fire.
+
+`describe()` now has a fourth branch. `live-elsewhere` gets its own rule id —
+`liveness-live-elsewhere-property`, exported as `LIVENESS_LIVE_ELSEWHERE_PROPERTY`
+beside `LIVENESS_DEAD_PROPERTY` / `LIVENESS_EXPERIMENTAL_PROPERTY` /
+`LIVENESS_PLANNED_PROPERTY` and advisory-only like them — plus its own message
+(`is enforced in a sibling repo, not here`) and its own default hint, which keeps
+the property and points at the ledger row's `evidence` for the enforcer. It
+deliberately does **not** reuse the `dead` branch: that is the #11384 lesson,
+which is that verdicts imply OPPOSITE author actions, and "Remove it" is the
+single most damaging sentence available about a key whose enforcement is real
+and remote — deleting it tears out a live gate's input. The sentinel throw
+stays for genuinely unknown statuses, with its enumeration of the known ones
+updated.
+
+The suite gains a coverage pin derived from the shipped ledgers rather than from
+a hand-written list: every distinct `status` those ledgers actually carry must be
+answered by `describe()` with a rule id of its own, or (for `live`, which reaches
+`describe()` only through a ledger-authoring mistake) must still fail loud. A
+sixth status now fails that pin by name instead of waiting for an author to trip
+the sentinel.

.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. -->

content/docs/permissions/system-context.mdx

@@ -97,7 +97,7 @@ that silently does not happen.
 | 8 | `explain()` may target a principal other than the caller | plugin-security | Get: no `manage_users` / delegated-admin check | `security-plugin.ts:3857` |
 | 9 | Anonymous-deny treats the caller as authenticated | core | Get: passes the 401 seam with no `userId` | `anonymous-deny.ts:154` |
 | 10 | Permission-set projection middleware skipped | plugin-security | Lose: projection of permission-set-derived columns | `permission-set-projection.ts:1015` |
-| 11 | Session-resolution middleware skipped | plugin-auth | Get: no session lookup attempted | `auth-plugin.ts:1345` |
+| 11 | Session-resolution middleware skipped | plugin-auth | Get: no session lookup attempted | `auth-plugin.ts:1353` |
 | 12 | Per-request performance timings disclosed | observability | Get: timing headers a normal caller cannot pull | `perf-timing.ts:474` |
 | 13 | Permission-set **overlay discard** skips the tenant-admin assertion | plugin-security | Get: an overlay can be discarded with no authenticated tenant administrator | `permission-set-overlay-discard.ts:142` |
 | 14 | MCP stdio bridge skips the object API-exposure gate | mcp | Get: the bridge reaches objects whose `apiEnabled` / `apiMethods` would refuse an external caller | `stdio-data-bridge.ts:246` |

content/docs/references/api/automation-api.mdx

@@ -607,7 +607,7 @@ const result = AutomationApiErrorCode.parse(data);
 | **error** | `string` | optional | Error message if execution failed |
 | **durationMs** | `number` | optional | Execution duration in milliseconds |
 | **code** | `Enum<'PERMISSION_DENIED' \| 'INVALID_SIGNAL' \| 'RUN_NOT_FOUND' \| 'STORE_UNAVAILABLE' \| …>` | optional | Machine-readable failure classification, set alongside `error` when the caller must distinguish WHY it failed. A closed union - the members and their transport mappings are documented on the contract (`AutomationResult.code`, contracts/automation-service.ts). |
-| **status** | `Enum<'completed' \| 'paused' \| 'failed'>` | optional | Lifecycle status. `paused` means the run suspended at a node and can be continued with the resume route. Absent or `completed`/`failed` means the run reached a terminal state. |
+| **status** | `Enum<'completed' \| 'paused' \| 'failed' \| 'stranded'>` | optional | Lifecycle status. `paused` means the run suspended at a node and can be continued with the resume route. Absent or `completed`/`failed`/`stranded` means the run reached a terminal state. `stranded` is the terminally-failed-but-repairable run: a resume consumed the suspension and a downstream node threw, so the run is recorded as failed and can be re-armed only by an explicit operator verb - never by the resume route, which answers RUN_NOT_FOUND for it. |
 | **runId** | `string` | optional | Run id - set when `status` is `paused`, so callers can resume it |
 | **screen** | `{ nodeId: string; title?: string; description?: string; fields: object[]; … }` | optional | The screen to render - set when the run paused at a `screen` node awaiting user input. The client collects values for `screen.fields` and resumes the run with them. |
 | **successMessage** | `string` | optional | Friendly terminal message copied from the flow definition on terminal success, so a screen-flow runner can show a meaningful toast |

examples/app-showcase/src/data/objects/project.object.ts

@@ -135,7 +135,17 @@ export const Project = ObjectSchema.create({
       // `insert` in `events` is what makes the initialStates check run on create.
       events: ['insert', 'update'] as const,
       initialStates: ['planned'],
-      message: 'Invalid project status transition.',
+      // ONE authored sentence answers BOTH refusals this rule can raise —
+      // `invalid_initial_state` on insert and `invalid_transition` on update —
+      // because `authoredRuleMessage` resolves one key per RULE, not per code.
+      // The old wording ("Invalid project status transition.") described only
+      // the update half, so a create rejected for being born `active` was told
+      // about a "transition" it had not attempted. It is translated at
+      // `objects.showcase_project._validations.project_status_flow.message`
+      // (#14253) — an authored message is emitted verbatim unless the bundle
+      // carries that key, which is why this one used to be the single English
+      // sentence on an otherwise zh-CN form.
+      message: 'Projects start as Planned, and then move only along the declared status flow.',
       transitions: {
         planned: ['active', 'cancelled'],
         active: ['on_hold', 'completed', 'cancelled'],

examples/app-showcase/src/system/translations/index.ts

@@ -34,6 +34,33 @@ export const ShowcaseTranslationBundle = {
           start_date: { label: 'Start Date' },
           end_date: { label: 'End Date' },
         },
+        // An author-written `validations[].message` is emitted VERBATIM unless
+        // the bundle carries it here (#14253) — the built-in field catalog's
+        // own sentences have shipped zh-CN since #3957, so a rule that declares
+        // its own message is the one way a refusal escapes the caller's
+        // language. `project_status_flow` is the showcase's state machine and
+        // the only refusal a visitor reliably triggers (the New Project wizard
+        // used to offer four statuses the machine will not accept on create),
+        // so it read as the single English sentence on a zh-CN form.
+        // All FOUR of the object's rules, not just the state machines: the New
+        // Project wizard can trip `end_after_start` and `spent_within_budget`
+        // from its budget/schedule step, so translating only the status rule
+        // would move the single English sentence one step later rather than
+        // remove it.
+        _validations: {
+          project_status_flow: {
+            message: 'Projects start as Planned, and then move only along the declared status flow.',
+          },
+          project_health_progression: {
+            message: 'Health changed by more than one step — confirm this is intentional.',
+          },
+          end_after_start: {
+            message: 'Target End Date must be on or after the Start Date.',
+          },
+          spent_within_budget: {
+            message: 'Spend exceeds 120% of budget — escalate before continuing.',
+          },
+        },
       },
       showcase_task: {
         label: 'Task',
@@ -270,6 +297,16 @@ export const ShowcaseTranslationBundle = {
           start_date: { label: '开始日期' },
           end_date: { label: '结束日期' },
         },
+        // The zh-CN mirror of the `en` `_validations` block — see the note
+        // there. Without these two keys the write path's own refusals arrive in
+        // Chinese (built-in catalog, #3957) while these author-written ones
+        // arrive in English, inside one error envelope.
+        _validations: {
+          project_status_flow: { message: '项目的初始状态为“计划中”,此后只能按既定的状态流转变更。' },
+          project_health_progression: { message: '健康度一次变更超过一级,请确认这是有意为之。' },
+          end_after_start: { message: '结束日期不能早于开始日期。' },
+          spent_within_budget: { message: '已花费超过预算的 120%,请先上报后再继续。' },
+        },
         // `default` — the container's DEFAULT list. `defineView({ list })`
         // declares it without a `name`, and the composer therefore registers it
         // as `<object>.default`; `_views` keys are that bare runtime key