Merge remote-tracking branch 'origin/main' into claude/issue-14749-inline-i18nlabel-not-unauthored

Author: claude

.changeset/flow-end-node-refused-outcome.md

@@ -0,0 +1,15 @@
+---
+"@objectstack/spec": minor
+---
+
+A flow can now REFUSE with per-record text: the `end` node gains `outcome` and an interpolated `message`, and the run vocabulary gains `refused`.
+
+Until now every terminal of a flow was "completed". A flow could say *do this* but not *refuse this, and say why, for which record* — the only channel that interpolated per-record text was a `screen` node's `description`, and a message-only screen renders Submit and, on submit, resumes to `end`, whose runner toasts `Flow "…" completed` at a user who was just told "this is refused". Maintainer ruling (2026-09-05, option 2′): the refusal is a first-class outcome of the existing terminal node, not a second node type.
+
+The contract, declared here first (the engine and runner halves follow in their own packages):
+
+- **`end` node config** — `EndConfigSchema` (`@objectstack/spec/automation`): `outcome?: 'completed' | 'refused'` (default `completed`) and `message?: string`, a `{token}` template interpolated at run time exactly like a screen `description` (`{record.name}` etc.). `outcome: 'refused'` without a `message` is refused at parse (a refusal without text is the shape this exists to replace); `message` on a completed end is refused too (nothing would ever render it). The shape is strict: an undeclared key is a parse error naming the intended key. Because `end` is structural (no executor, no descriptor), `FlowNodeSchema` applies the contract itself to every `type: 'end'` node it parses and writes the parsed (defaulted) config back; a node with no `config` is left without one. Every other node type's `config` stays the open, executor-owned slot it was.
+- **Run row** — `ExecutionStatus` gains `refused` (appended last: a terminal state distinct from `failed` — a refusal is a successful evaluation that says no; never resumed) and `ExecutionLogSchema` gains `refusalMessage`, the rendered per-record text, set only on a refused run.
+- **Result / wire** — `AutomationResult.status` and `TriggerFlowResponseSchema.data.status` gain `'refused'`, and both carry `refusalMessage`; on a refusal `success` is `true` and `successMessage` is absent, so a runner shows the message with Close only — no Submit, no completion toast.
+
+Additive throughout: nothing renamed or retired, so no ADR-0087 conversion-layer entry (disposition: not-required). Flows that never set `config` on an `end` node parse exactly as before.

.changeset/plugin-security-scanner-ledger-entry.md

@@ -0,0 +1,42 @@
+---
+"@objectstack/spec": patch
+---
+
+ADR-0087 semantic-migration ledger: register the retirement of `@objectstack/core`'s `PluginSecurityScanner` (#14919)
+
+`PluginSecurityScanner`, `ScanTarget` and `SecurityIssue` are removed from
+`@objectstack/core` in the same PR, under ADR-0049 enforce-or-remove (maintainer
+ruling 2026-09-05, director summon #14, decision batch #42). This is the ledger
+half: a D3 semantic entry
+(`src/migrations/entries/semantic/18.plugin-security-scanner-retired.ts`,
+concatenated into `MIGRATIONS_BY_MAJOR[18].semantic` by `gen:migration-registry`)
+so the retirement reaches `spec-changes.json` and the generated upgrade guide
+rather than being invisible to every upgrade channel.
+
+FROM `new PluginSecurityScanner(kernel.logger)` → TO nothing: delete the import
+and every call. There is no replacement export, and a caller that branched on
+`result.status === 'passed'` takes that branch unconditionally — it is the only
+branch the scanner ever produced, because four of its five scan methods returned
+an empty issue list on every input and the fifth read a vulnerability database
+whose only writer had zero callers.
+
+Why an entry is owed at all, and why D3 rather than a D2 conversion: the class
+has no spec schema and never had one. It is a runtime TS class, so there is no
+authorable key to tombstone with `retiredKey()` and no stored `sys_metadata` row
+a conversion could rewrite — a scanner was constructed per call and every result
+lived in a per-instance Map discarded with the object, so
+`applyConversionsToStoredItem` has no seam that would ever see one. The enforced
+channel is tsc at the consumer's own import site; for anyone it does not reach,
+this entry and the upgrade guide are the only channel. That is the
+`contracts.IDataDriver.findStream` and `actor-user-roles-to-positions`
+disposition, applied to a surface one layer further out than either — those are
+declared in `packages/spec`, this one only in `packages/core`.
+
+Measured, and worth recording because the entries README warns of a regeneration
+lap that did not materialise here: `check:generated` reports all 15 artifacts up
+to date after the entry landed, and running `gen:spec-changes` and
+`gen:upgrade-guide` explicitly moved neither file — a major-18 semantic entry is
+not yet projected into either. `registry.ts` is the whole generated diff.
+
+No behaviour in `@objectstack/spec` changes; this adds a ledger row and the
+regenerated region that carries it.

.changeset/plugin-security-scanner-retired.md

@@ -0,0 +1,83 @@
+---
+"@objectstack/core": minor
+---
+
+feat(core)!: retire `PluginSecurityScanner` — plugin security scanning is not a platform capability (#14919)
+
+<!-- adr-0087: registered plugin-security-scanner-retired -->
+
+**ADR-0087 disposition: registered**, as `plugin-security-scanner-retired` in
+`MIGRATIONS_BY_MAJOR[18].semantic` — a **D3 semantic** entry, not a D2 conversion,
+and so not the metadata migration the ruling excludes. The class has no spec schema
+and never had one, so there is no authorable key to tombstone with `retiredKey()`
+and no stored `sys_metadata` row a conversion could rewrite: a scanner was
+constructed per call and every result lived in a per-instance Map discarded with the
+object, so `applyConversionsToStoredItem` has no seam that would ever see one. An
+entry is nevertheless owed rather than optional, because this changeset carries a
+real consumer prescription — the enforced channel is tsc at the import site, and for
+any consumer it does not reach, the ledger and the generated upgrade guide are the
+only channel there is. Same disposition as `contracts.IDataDriver.findStream` and
+`actor-user-roles-to-positions`.
+
+**BREAKING** — `PluginSecurityScanner` is removed from `@objectstack/core`,
+together with its two companion types `ScanTarget` and `SecurityIssue`. Landing
+as `minor` under the repo's launch-window convention for breaking changes.
+**There is no replacement**, and none is planned.
+
+⚠️ **The out-of-repo consumer population for these three exports is NOT
+MEASURED.** This changeset can state only what was measured *inside* the
+sources this repo can read: zero constructors in objectstack, zero in objectui
+at the pinned sha, and zero in the deleted example itself. How many published
+consumers of `@objectstack/core` import the class is unknown — no download,
+dependent or source telemetry was consulted. Read the removal as breaking for
+an unmeasured population, not as a removal proven to break nobody.
+
+## Why it was removed rather than repaired
+
+The class was a shell that reported success. `scan()` composed five private
+scanners: four of them (`scanCode`, `scanMalware`, `scanLicenses`,
+`scanConfiguration`) allocated an empty issue array, logged, and returned it
+with no code in between — none could report a finding for any input. The fifth,
+`scanDependencies`, ran a real loop but matched only against an in-memory
+vulnerability database whose sole writer, the public `addVulnerability`, had
+zero callers; `updateVulnerabilityDatabase()` logged twice and fetched nothing.
+The database was therefore empty on every code path that has ever executed, so
+no issue was ever produced, the score stayed 100, and the result was
+`status: 'passed'` for every plugin the scanner was ever handed — a malicious
+one included.
+
+A security control that cannot fail is worse than no security control, because
+callers rely on it. Repair — writing a real vulnerability scanner — was refused
+by name: it is a feature with a design surface and no demand, not a defect fix.
+
+## FROM → TO
+
+```ts
+// FROM — compiles today, and passes every plugin it is given
+import { PluginSecurityScanner } from '@objectstack/core';
+
+const scanner = new PluginSecurityScanner(kernel.logger);
+const result = await scanner.scan({ pluginId, version, dependencies });
+if (result.status === 'passed') { await kernel.use(plugin); }
+
+// TO — delete it. The condition above was always true.
+await kernel.use(plugin);
+```
+
+**The one-line fix:** delete the import and every call; no symbol replaces it.
+If your code branched on `result.status`, take the `'passed'` branch — that is
+the only branch it ever took.
+
+**If you were relying on it for actual security**, you were not getting any.
+Audit dependencies with the tools built for it (`npm audit` / `pnpm audit`,
+Dependabot, the GitHub Advisory Database, OSV) and treat an unaudited
+third-party plugin as untrusted code. What ObjectStack does still enforce is
+artifact **integrity and signatures** (`verifyPluginArtifactIntegrity`, the
+plugin signature verifier — "is this what the publisher signed?", never "is
+this safe?"), explicit plugin **permissions**, and the sandbox **resource
+limits**; all three are unchanged.
+
+Removed under ADR-0049 enforce-or-remove, per the maintainer ruling of
+2026-09-05 (director summon #14, decision batch #42). The retirement is pinned
+as an export-list assertion on both barrels in
+`packages/core/src/security/security-scanner-retirement.pin.test.ts`.

.changeset/quiet-pans-repair.md

@@ -0,0 +1,9 @@
+---
+'@objectstack/plugin-security': patch
+---
+
+Remove seven dead `{ records }` union-normalizer limbs on engine `find()` results, and repair the one that was silently dropping instead of gapping.
+
+Six seams in this plugin normalized an engine read as `Array.isArray(x) ? x : x.records`. The envelope limb was unreachable: `ObjectQL.find` resolves a bare array of row objects, measured by booting a real engine over a real `SqlDriver` and driving each seam through the shipped function that owns it, rather than inferred from `IDataEngine.find`'s declared `Promise<any[]>` (a declared type is not proof — this repo also has a `find()` that resolves an envelope). Each seam keeps its existing disposition for a non-array; only the dead limb is gone.
+
+The seventh is repaired in the opposite direction. `SecurityPlugin`'s `sys_permission_set` loader mapped three different facts onto one value: a read that succeeded on an empty catalog, a read that threw, and a read that resolved something it could not read all left as `[]`. On the enforcement plane that silently withdraws grants that exist while every request still looks normal, and it made `PermissionEvaluator`'s existing "db lookup failed" warning unreachable — so a transient database error and an empty catalog produced identical, undiagnosable 403s. The loader now lets the read fault propagate and refuses an unreadable result with `DATABASE_ERROR`. Enforcement is unchanged for every result the shipped engine produces; an envelope or a non-row element now refuses (fail-closed) where the old code read through it. An unanswered read still grants nothing; what changes is that it is now reported instead of silent.

.changeset/rest-translate-options-default-locale.md

@@ -0,0 +1,9 @@
+---
+"@objectstack/rest": patch
+---
+
+fix(rest): the metadata reads pass the declared default locale to the label resolvers, so a request for it answers with the authored label (#15711)
+
+`translateOptionsFor` — the single seam every metadata-document translation in the REST server goes through — now threads `i18n.getDefaultLocale()` into `ResolveOptions.defaultLocale` beside the declared fallback chain it has passed since #14882. Both accessors are optional on `II18nService` and both are feature-detected: a provider that declares no default gets no default, one that declares no fallback gets no chain, and the seam never answers `'en'` on a provider's behalf.
+
+Measured on the reporter's stack shape (`defaultLocale: 'zh-CN'`, `fallbackLocale: 'en'`, an `en` bundle and no `zh-CN` bundle): `GET /api/v1/meta/object/kpi_entry_sheet` with `Accept-Language: zh-CN` — or with no header at all, which resolves to the default — now serves the authored `填报单`, not the `en` bundle's `Entry Sheet`; a `fr` request still walks the declared `en` bundle; an `en` request still gets the `en` bundle. Pinned in `meta-i18n-declared-fallback-chain.test.ts` §4 and §5.

.changeset/spec-i18n-default-locale-authored-label.md

@@ -0,0 +1,22 @@
+---
+"@objectstack/spec": minor
+---
+
+feat(spec): the authored label is the default locale's text — `ResolveOptions.defaultLocale` skips the fallback chain for a default-locale request, and a chain-less caller no longer falls to a literal `en` (#15711)
+
+<!-- adr-0087: not-required (no-migration-prescription) A published RUNTIME DEFAULT moves: the label resolvers' chain-less fallback, a literal `['en']` before this change, is now `[]`; and one OPTIONAL key is added to a plain TS options interface (`ResolveOptions.defaultLocale` in `packages/spec/src/system/i18n-resolver.ts`). No Zod schema, no authorable metadata key and no stored row changes shape, so the meta conversion tooling has nothing to touch and a registry entry would be false data in the one ledger this gate keeps true. Which TEXT answers a chain-less non-default request moves; nothing starts failing, and no source edit is prescribed: a host that wants `en` consulted declares `fallbackChain: ['en']`, which it always could. -->
+
+**BREAKING** (launch-window convention: ships as `minor`; this entry is the signal) — the second facet of the #15711 ruling moves a published default of the `@objectstack/spec/system` label resolvers. A caller that passes no `fallbackChain` used to get a literal `['en']`; it now gets `[]`, "requested locale, then the authored label". Nothing silently falls to `en` because a literal said so: a chain is consulted only when someone declared it. In this repo the blast radius is zero production callers (the REST serving layer has declared its chain since #14882; one pin flips); out-of-repo hosts unmeasured. A host that relied on the implicit `en` declares it as `fallbackChain: ['en']`.
+
+## The ruling (#15711, recorded 2026-09-05)
+
+A workspace that authors its metadata labels in its default locale (`i18n.defaultLocale: 'zh-CN'`, inline `label: '填报单'`) and ships a courtesy `en` bundle used to serve `Entry Sheet` to a `zh-CN` request whenever its declared chain named `en` — a reflexive `fallbackLocale: 'en'` in an AI-authored config was enough. `os i18n check` already counted the authored text as the default locale's coverage; the runtime did not. Ruled A: **the authored label IS the default locale's text**.
+
+- `ResolveOptions` gains an optional `defaultLocale?: string` — the deployment's default locale, the language its labels are authored in. When the requested locale names it (BCP-47 tags compare case-insensitively, the same rule `resolveBundleLocale` applies), the resolvers consult the requested locale's own bundle and then answer with the authored label; the fallback chain is not walked.
+- `fallbackChain` keeps its full meaning for every non-default request: a `fr` request still walks the `fr` bundle, then the declared `en` bundle, then the authored label.
+- A bundle entry for the default locale still wins when one is shipped, so `os i18n extract --locales=zh-CN` keeps working — optional now, not required.
+- `II18nService.getDefaultLocale()` documents that it is also what the serving layer threads into `ResolveOptions.defaultLocale`; `@objectstack/rest` passes it through its single `translateOptionsFor` seam (that package's own changeset).
+
+Unchanged: `os i18n check`; both boot paths (`os serve` and the dev plugin still collapse the declaration to `fallbackLocale || defaultLocale || 'en'` before constructing the service); every request whose locale is not the default.
+
+Not taken, ruled out on the card: the rule living only in `packages/rest` (every other host would re-implement it and spec could not pin it); requiring every supported locale to ship a bundle (a generated bundle that duplicates the app's own source text, the stale-translation class already closed); documenting the divergence.

.changeset/strand-verdict-survives-bookkeeping-throw.md

@@ -0,0 +1,17 @@
+---
+'@objectstack/service-automation': patch
+---
+
+Keep a resume's `status: 'stranded'` verdict when the bookkeeping after the repair journal throws.
+
+`resumeInternal`'s catch arm journals the consumed suspension — the snapshot `restoreConsumedSuspension` puts back — and only then stamps `status: 'stranded'`. Two statements sat between them and could throw out of the whole arm: `recordLog`'s terminal run-summary line, and a store whose `recordTerminal` throws synchronously (the `void write.catch(...)` beneath that call only ever sees a returned promise's rejection). `failAncestors` follows them.
+
+A throw in that window left the run genuinely repairable while the verdict never shipped, and every consumer derives repairability from the verdict — `plugin-approvals` computes its operator-facing `repairable` as `status === 'stranded'` — so the approvals decision door reported `repairable: false` about a run that `restoreConsumedSuspension` answers `restored: true` for. That is a false negative on a repair instruction: it tells an operator not to attempt a repair that works.
+
+The window is now guarded. The bookkeeping may still fail — and says so loudly, at `error`, naming the run, what did not land, and the verb that repairs the strand — while the verdict still ships. Measured: with a store whose terminal write throws, `resume` now returns `{ success: false, status: 'stranded' }` instead of throwing, the door reports `repairable: true`, and the repair verb succeeds on that same run.
+
+The guard opens **after** the journal, so only a run that demonstrably has a snapshot can reach the stamp: a throw from the journal itself still propagates, every exit above the consumption point still carries no status at all, and cascade-failed ancestors — which journal nothing — are untouched and still correctly non-repairable.
+
+⚠️ This change also makes a pre-existing fault **visible** rather than creating it. The completion path's history write sits inside the same `try` as the node-failure arm, so a run that **completed** — every node succeeded — is journalled and reported `stranded` when its `completed` history row throws, and repairing such a run **re-runs the flow**. That phantom, its repair snapshot and the double run were all measurable before this change; what changes here is only that more store failures now report the verdict instead of throwing over it, so an operator can now be told to repair a completed run. Filed as #15944, with the measurement on both trees.
+
+⚠️ `repairable` remains a point-in-time fact, and this change does not make it durable: the run in the case above has no terminal history row (that write is what failed), so the repair rides on the in-memory journal and a restart loses it. The verdict reports what an operator can do now, which is exactly what was being denied.