Merge remote-tracking branch 'origin/main' into claude/issue-20273-connector-resilience-keys-retired

# Conflicts:
#	packages/spec/src/migrations/registry.ts

Author: claude

.changeset/17321-conversion-todo-channel.md

@@ -0,0 +1,50 @@
+---
+"@objectstack/spec": minor
+"@objectstack/metadata-protocol": minor
+---
+
+feat(spec,metadata-protocol): `os migrate meta --stored` lists every stored page filter the record-filter conversion leaves as stored, as a TODO naming the page, the block and why — the ADR-0087 D3 TODO channel (#17321, ruling B item 2)
+
+**Clause-②: yes** — `@objectstack/spec` gains public exports (`CONVERSION_TODO_CODE`,
+`ConversionTodoDetail`, `ConversionTodoNotice`, and the optional `ApplyConversionsOptions.onTodo`
+and `ConversionContext.reportTodo`), and `@objectstack/metadata-protocol` gains
+`StoredMigrationTodo` and `StoredMigrationRow.todos`. No door's accept set moves, and nothing
+that was left as stored before starts converting: every stored body is rewritten exactly as it
+was.
+
+**What was silent.** The D2 conversion `page-component-filter-record-to-rule-array` leaves a
+stored filter as stored wherever no lossless rule-array spelling exists — above all a record
+carrying `$and` / `$or` / `$not`, which is never flattened. It emitted nothing for such a site,
+and `os migrate meta --stored` reads conversion notices as its change signal, so a page whose
+only legacy filter carried a combinator was reported as **already on protocol**.
+
+**What it says now.** Each such site is a structured TODO (code `OS_METADATA_CONVERSION_TODO`)
+carrying its path, the shape left in place, and a reason that names the block (its type, and its
+`id` when it has one) and what blocks the rewrite — the combinator by name, the operator
+(`$null`, `$exists`, an AST `like`), the null or array value, the rule the door would refuse, or
+the inline rows the block renders. The stored pass lists them under their row, whatever the
+row's outcome:
+
+```text
+⚠ 1 row(s) are outside this pass — each row's reason says why:
+  • page/pipeline_board [env-wide] — the conversion chain rewrites nothing here: it left 1 site(s) of this row as stored, …
+      TODO page-component-filter-record-to-rule-array: {"$or":[…]} left as stored at pages[0].regions[0].components[0].properties.filter — On the `object-kanban` block, this filter carries the combinator `$or`: …
+☐ TODO: 1 site(s) in 1 row(s) are left as stored — no conversion can rewrite them without changing what they mean, so no run of this pass will. …
+```
+
+The same list is `rows[].todos` in `--json` and in the `POST /api/v1/meta/_migrate-stored`
+report. A run with no TODO prints exactly what it printed before.
+
+**Outcome and exit code.** A row whose only finding is TODOs has nothing to persist and is now
+reported `skipped` (it was `canonical`). Like every other skip class it does not change the
+run's exit code: no run of this pass can clear it, because the conversion must not flatten a
+combinator — it is the hand rewrite's to decide. A row that also converts something keeps the
+outcome its conversion gives it, with its TODOs listed beside its notices. Measured through the
+write path: on `--apply`, a row whose leftover sits in a block's `properties.filter` or
+`properties.defaultFilters` is rewritten (its lossless filters persist; the metadata API's save
+does not refuse block props by component type), while a leftover in `dataSource.filter` fails
+the save, and the row's TODO says why.
+
+**For code calling the conversion layer.** `onTodo` and `reportTodo` are optional. Only the
+stored-metadata pass passes a sink today; every other seam leaves the site as stored silently,
+exactly as before.

.changeset/17321-record-filter-d2-conversion.md

@@ -45,8 +45,11 @@ are **inline** (`data: { provider: 'value', … }`, a `data` array, or `staticDa
 stored: the `object-map`, `object-tree`, `object-calendar` and `object-gantt` renderers match
 that filter against their own rows in an in-memory data source that reads the record form but
 excludes every row for a rule array, so a rewrite there would empty the block. The same filter
-on a block that queries an object converts. Such a page keeps loading and rendering unchanged and is refused at its
-`filter` door on its next save — and for a combinator record that refusal no longer renders the
+on a block that queries an object converts. Such a page keeps loading and rendering unchanged,
+and its `filter` door refuses the form: at `dataSource.filter` on the page's next save; at a
+block's `properties.filter` / `properties.defaultFilters` only as the component-props gate's
+advisory finding (`os validate`, `os build`, `os lint`) — a re-save through the metadata API is
+not refused there, measured — and for a combinator record that refusal no longer renders the
 combinator as a field (`{ field: '$or', … }`); it names the combinator and says why no rule
-spells it. `os migrate meta --stored` does not list these rows yet: a row the conversion leaves
-as stored reports there as already on protocol.
+spells it.
+`os migrate meta --stored` lists each such filter left as stored as a TODO under its row.

.changeset/19886-stored-list-ordering-refused.md

@@ -0,0 +1,40 @@
+---
+"@objectstack/formula": minor
+"@objectstack/plugin-security": minor
+"@objectstack/spec": patch
+---
+
+A row-level write check that orders a field against a bound (`>`, `>=`, `<`, `<=`) is refused with `INVALID_FILTER` / 400 when that field holds a list or an object on the record being written, instead of comparing the list's string form and admitting the write (#19886).
+
+**BREAKING** — an accept-set narrowing, shipped by `@objectstack/formula` and `@objectstack/plugin-security` as `minor` under the repo's launch-window convention for accept-set narrowings. The hand-migration prescription is registered under protocol major 18 as `rls-predicate-stored-list-ordering-refused`.
+
+Clause-②: no (narrowing)
+
+**Security fix for RLS write checks.** Measured through the real plugin-security on driver-sql and driver-memory: `record.tags > 'a'`, with `tags` a `json` field holding `['m']`, compared `'m' > 'a'` and admitted and stored the write. `record.meta < 'a'` with `meta` holding `{ a: 1 }` compared `'[object Object]' < 'a'` and did the same, and so did a `multiple` lookup. `using` stands in as the check for a policy that declares no `check`, so the same predicate in `using` was enforced the same way on writes. No shipped row-level or sharing-rule predicate orders a field at all.
+
+What changes:
+
+- `@objectstack/formula`: `matchesFilterCondition` refuses `$gt` / `$gte` / `$lt` / `$lte` and `$between` on a field whose value on the record is a list or a plain object, whatever the comparand, with the same `INVALID_FILTER` / 400 and the same message as the stage 2d refusals. The refusal is per record: a record whose `json` field holds one scalar is compared as before. `null` and `Date` values are unchanged, and so is every equality against a stored list (`$eq`, `$ne`, implicit equality, `$in`, `$nin`). `$between` is not produced by the CEL lowering, so it reaches this only through a filter passed to `matchesFilterCondition` directly.
+- `@objectstack/plugin-security`: a check insert or by-id update whose post-image holds a list or an object in an ordered field is refused 400 and stores nothing. That includes a by-id update that edits another field of a row whose stored `json` column holds a list, because the post-image merges the stored row.
+- `@objectstack/spec`: the migration registry carries the entry. The stage 2a entry `rls-predicate-array-comparand-refused` now ends "Scalar != and ==, null, Date comparands, and { $field } references between single-valued columns evaluate exactly as before", which is true since stage 2d.
+
+Three moves, named:
+
+1. **The write check now matches driver-sql's read.** driver-sql refuses every ordering comparison, and `$between`, on a column it stores as JSON text, by declared type (400, #7398). The in-process check now refuses the same predicate on the same row (400).
+2. **driver-memory's read parts from the write check.** driver-memory, a test driver, compares a stored list element by element on a read and keeps returning those rows (`record.tags > 'a'` reads a row holding `['m']`), while the check now refuses writing it. This is declared on #15104, as for stage 2d's `{ $field }` half.
+3. **A list written into a scalar field under an ordering check now answers 400.** `status: ['m']` into a `text` field under `record.status > 'a'`, or `amount: [500]` into a `number` field under `record.amount > 10`, was admitted, and driver-sql stored it as the text `'["m"]'` / `'[500]'`. It is now refused before anything is stored.
+
+**The explain answer.** `security/explain` evaluates the business RLS predicate in-process on the fetched record, so it now answers `INVALID_FILTER` / 400 where the record holds a list or an object under an ordering predicate (this stage). It already answered 400 for a `{ $field }` comparison against a list-holding column (stage 2d). For both, per operation:
+
+| explain operation | driver | the enforced operation answers | same as explain's 400? |
+|---|---|---|---|
+| `read` | driver-sql | 400 `INVALID_FILTER` (the driver's refusal) | yes |
+| `update` | driver-memory | 400 `INVALID_FILTER` (the post-image check) | yes |
+| `update` | driver-sql | 403 `PERMISSION_DENIED`: the pre-image gate fails closed on the driver's 400 | no — both deny |
+| `read` | driver-memory | the rows its element-wise read admits | no — the test driver's read |
+
+Explain itself is unchanged.
+
+**What to change.** Order a single-valued column (`record.priority > 2`), or test membership in the list with `in` (`record.status in ['open', 'pending']`). A `json` or `multiple` field has no ordering.
+
+<!-- adr-0087: registered rls-predicate-stored-list-ordering-refused -->

.changeset/19961-decision-branch-expression-absent-refused.md

@@ -0,0 +1,61 @@
+---
+'@objectstack/spec': minor
+'@objectstack/lint': minor
+---
+
+fix(spec)!: a `decision` branch with no `expression` — the key absent, or `null` — is refused at authoring (#19961)
+
+Clause-②: no (narrowing)
+
+<!-- adr-0087: registered flow-decision-branch-expression-absent-refused -->
+
+**BREAKING** — an accept-set narrowing on one authored flow-node slot, shipped as
+`minor` under the launch-window convention (`check-changeset-no-major` refuses
+`major` until GA; breaking-ness is carried by this banner and the ADR-0087
+disposition above, not by the level).
+
+**What changed.** `DecisionConditionSchema` declares a branch `{ label, expression }`
+with `expression` a required `z.string()`. Nothing enforced that: a decision node's
+`config` is an open record no schema is parsed against, and the expression ledger's
+resolver skipped an absent value as "not authored". So `conditions: [{ label: 'y' }]`
+passed `FlowSchema.parse`, `AutomationEngine.registerFlow` and `objectstack validate`,
+and the run then failed at that branch — the executor evaluates every branch it
+reaches, and a branch with no `expression` is a condition with no `source`, which
+`evaluateCondition` refuses. The ledger now marks the slot `required` (reconciled
+against the schema's own `required` list), and the branch is refused at all three
+doors through the walk and the function that already refuse a blank one — by
+`FlowSchema.parse` with a `custom` issue anchored at the slot (for example
+`nodes.1.config.conditions.0.expression`), by `registerFlow` and `objectstack validate`
+through that same parse, and by `validateStackExpressions` for a stack handed to it
+directly — with one message, led by the published `PREDICATE_SLOT_STRING_REFUSAL`
+sentence. `expression: null` is refused the same way, and so is a branch that wrote
+its predicate under `condition` (the edge's spelling), which has no `expression`
+either. The Studio flow designer writes the refused shape when a branch row's
+expression cell is left empty. Where such a branch already sits, the whole flow is
+refused: registered from the metadata
+registry or `sys_metadata` at boot, it is skipped with a `failed to register flow`
+warn naming it while the flows beside it register; a `defineStack({ flows })` source
+throws `StackSchemaInvalidError` for the whole stack; an artifact file is refused
+whole at load.
+
+## FROM → TO
+
+| you wrote | write instead |
+|:--|:--|
+| `conditions: [{ label: 'high' }]` on a `decision` node | the predicate you meant — `{ label: 'high', expression: 'record.amount > 10000' }` |
+| `conditions: [{ label: 'high', condition: 'record.amount > 10000' }]` | the same predicate under `expression` |
+| `conditions: [{ label: 'high', expression: null }]` | the predicate you meant, or `expression: 'false'` to keep the branch and never take it |
+
+**One-line fix:** write the predicate under `expression`. `expression: 'false'` keeps
+the branch and its label and never takes it — a change of behaviour, not a preserved
+one: a run that reached the branch used to FAIL there, and now routes on to the next
+branch or the declared fallback. ⚠️ Do not drop a decision's only branch: the node
+then routes by its out-edges alone, and the out-edge that branch labelled is no
+longer held back.
+
+**Unchanged.** A branch carrying a non-blank predicate parses, registers and
+validates as before; a blank one keeps its refusal and its own prescription
+(`flow-predicate-slot-blank-string-refused`); a `decision` with no `conditions`, or
+an empty list, still routes by its out-edges; an absent screen field `visibleWhen`
+is still legal (that slot is not required); and `PREDICATE_SLOT_STRING_REFUSAL`
+keeps its name and its text.

.changeset/20146-app-ledger-repoint.md

@@ -0,0 +1,12 @@
+---
+"@objectstack/spec": patch
+---
+
+`liveness/app.json`: every `AppSchema` row that cited objectui's `AppSidebar.tsx` as read evidence now cites the reader that is actually mounted, and `branding.logo` is `planned` instead of riding on its container's `live`. Ledger evidence and comment prose only. ⛔ No schema, parse or accept-set change.
+
+The ledgers ship inside this package (`files[]` includes `liveness`), and `@objectstack/lint` reads them to decide which authored keys draw an advisory warning, so the rows an upgrading reader or tool consults are these.
+
+- **Twelve rows re-pointed, and the file `_note`.** `label`, `description`, `icon`, `branding`, `active`, `hidden`, `navigation[].id`, `navigation[].visible`, `areas[].id`, `areas[].label`, `areas[].icon` and `areas[].navigation` cited `AppSidebar`. That component was deprecated, never mounted (the console renders `UnifiedSidebar`), and objectui has since removed it, so it was never evidence of a live reader. Each row now names its mounted reader, file and symbol: `AppSwitcher`, `UnifiedSidebar`, `AppHeader`, `ConsoleLayout` into `AppShell`'s `useAppShellBranding`, `HomeAppsStrip`, `filterActiveApps`, `NavigationRenderer`, `NavMenuRenderer` and `AppManagementPage`. All are read at the `.objectui-sha` pin f8a9d0fb, and each reads its key unchanged at objectui main fb91ac9b0.
+- **`branding.logo` is `planned`.** Plugin-designer's app wizard and branding editor write it, and nothing mounted renders it: the console's branding handoff passes `primaryColor`, `accentColor` and `favicon` and never `logo`. The row names the objectui card that will render it (objectui#10827). It is not `authorWarn`'d: a logo URL is display metadata, and an author who sets it now loses nothing, because the value takes effect when that renderer lands. The `branding` row is drilled so `primaryColor`, `accentColor` and `favicon` keep their own `live` verdicts. Its entry in `undrilled-containers.baseline.json` goes away with the drill, and `state-counts.md` is regenerated (`app`: 56 → 59 classified, one `planned`).
+- **`description` is still `live`, but narrower.** Its one mounted reader is the admin app list at `/system/apps`, which shows each app's description and searches it. The sidebar presentation this row used to describe has no successor.
+- **Two corrections found while re-reading.** The `active` row's note said the sidebar's active-app lookup spans all apps. It skips `active: false` apps, and what keeps an inactive app routable by direct URL is the console's route resolver, which matches against every app. The two `AppSidebar` mentions in `ui/app.zod.ts` (the `recordId` template-variable note and the `AREA_ORDER_RETIRED` note) now name `NavigationRenderer` / `UnifiedSidebar`.

.changeset/20201-d3-entry-per-family-major-18.md

@@ -0,0 +1,30 @@
+---
+'@objectstack/spec': patch
+---
+
+fix(spec): every protocol-18 retirement family now carries its D3 entry, including the 25 whose data repair is a lossless D2 conversion (#20201)
+
+Clause-②: no
+
+ADR-0087 D3 requires one semantic (D3) entry per retirement family, even when a
+lossless D2 conversion already repairs the data: D2 carries the mechanical repair
+only, and the D3 entry says what the consumer still has to decide. Twenty-five
+protocol-18 families shipped a D2 conversion and no D3 entry, some of them
+justified by "lossless, so no semantic residue". `MIGRATIONS_BY_MAJOR[18].semantic`
+gains one entry per family, so `os migrate meta` lists each as a TODO on the
+17 → 18 hop, with its reason and acceptance criteria. Among them:
+
+- the seven duration renames (`hook.timeout`, `job.timeout`, `apis[].cacheTtl`,
+  `dashboard.refreshInterval`, the connector health / trigger durations, the memory
+  driver's `autoSaveInterval` and the turso `timeout`). The rename keeps the value,
+  so only the author can say whether it was ever written in the unit the new key
+  names.
+- `object.tenancy.organizationField`, `view.owner` / `view.hidden`,
+  `permission.objects.*.allowRestore` / `allowPurge` and the list-view `page` mount.
+  Each delete is lossless, and each leaves a belief the author held that the
+  platform never honoured.
+
+No accept set moves and no conversion changes. The registry's own test now fails
+when a protocol-18-or-later step graduates a conversion that no D3 entry of that
+step names. The prose that justified the missing entries is corrected, and the
+protocol-17 docblock no longer calls that step's `semantic` list empty.

.changeset/20233-ui-plugin-migration-guidance-tracker-free.md

@@ -0,0 +1,21 @@
+---
+'@objectstack/spec': patch
+---
+
+fix(spec): `os migrate meta` guidance for the `ui-*` and `plugin-*` migration entries states each lesson in words instead of citing tracker numbers
+
+Clause-②: no
+
+The ADR-0087 semantic entries of the `ui-*` family (component props rows, form-field
+and list-view refusals, the react-tier `ListView` aliases, and the retired
+interaction, notification, embed, widget and i18n vocabularies) and of the `plugin-*`
+family (the plugin manifest, runtime, health-monitor and security-scanner retirements)
+are printed by `os migrate meta` as the header, `why:` and `verify:` lines of a manual
+change. Their text sent the reader to issue-tracker numbers — some of which no longer
+resolve — for what a ruling, measurement or fix had decided; it now says what was
+decided, in the sentence being read. The same holds for the two `surface` headers that
+carried a number. ADR ids are kept.
+
+Text only: no entry id, `from` / `to`, conversion or matching logic changes, and the
+chain rewrites exactly what it rewrote before. The generated migration registry,
+`spec-changes.json` and the protocol upgrade guide carry the same text.