Merge remote-tracking branch 'origin/main' into claude/issue-20280-mysql-date-read-century

# Conflicts:
#	.changeset/20240-date-year-four-digits.md

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/19098-retire-generate-schema.md

@@ -0,0 +1,87 @@
+---
+'@objectstack/cli': minor
+---
+
+fix(cli): **BREAKING** — `os generate schema` is retired, and it now says why and points at `os validate` and the per-type JSON Schemas `@objectstack/spec` publishes (#19098)
+
+Clause-②: no (narrowing)
+
+<!-- adr-0087: not-required (no-migration-prescription) A CLI COMMAND NAME is an invocation surface, not authorable metadata. There is no authorable key, no `sys_metadata` row and no schema to tombstone here, so there is nothing for `objectstack migrate meta` to rewrite, nothing for `spec-changes.json` to project and no FROM -> TO spelling for the upgrade guide to carry: the ruling generates no replacement file, so there is no call to rename, only one to delete. Nor is the ledger the notification channel: the command itself now refuses, exits 1 and names `os validate` and the published per-type schemas at the exact moment and place of use. Same reasoning shape as the `os g agent` retirement, one command over. -->
+
+**⛔ If a script, a Makefile or a CI step in your project runs `os generate schema`
+(or `os g schema`), it will now exit 1 and write nothing.** That is the intended
+outcome: the command is gone by maintainer ruling, and the failure is how you find
+out. Nothing in this repository reads the file it wrote.
+
+`minor`, not `major`: during the launch window this stack ships breaking changes as
+`minor` (pre-1.0 semantics under lockstep versioning — see
+`scripts/check-changeset-no-major.mjs`).
+
+**What the command actually did.** `os generate schema` wrote
+`objectstack.schema.json`, a JSON Schema of the whole stack definition for an editor
+to check `objectstack.config.ts` against. It projected `ObjectStackDefinitionSchema`
+through a bare `z.toJSONSchema`, so the refinements the platform enforces beyond the
+shape — a non-blank string, a required one-of, a banned key — were missing from the
+file. Measured against the published projection on the tree the ruling was made on,
+the file lacked 874 keywords, every one of them an absence. An editor pointed at it
+reported a config as valid, and the platform then refused that config.
+
+**Why it is retired rather than repaired.** A TypeScript configuration is typed by its
+own `define*` helper, and `objectstack.config.ts` is typed end to end by
+`defineStack`, so no config format this CLI loads is one an editor validates against
+a JSON Schema. JSON metadata already has the per-type schemas `@objectstack/spec`
+publishes, which carry the published projection. Repairing the command would have
+added a permanent public export to `@objectstack/spec` for a file with no reader. The
+ruling generates no replacement file. What you see now:
+
+```
+  ✗ `os g schema` was retired — its JSON Schema passed configs the platform refuses (maintainer ruling).
+
+  The file it wrote described only the shape of a stack. Every rule the
+  platform enforces beyond that shape — a non-blank string, a required
+  one-of, a banned key — was missing from it, so an editor showed a config
+  as valid and the platform then refused it. By maintainer ruling it is
+  retired, not repaired, and no replacement file is generated.
+
+  Check a project against the rules that actually run:
+
+      os validate
+
+  For JSON metadata, point your editor at the per-type schemas that
+  @objectstack/spec publishes. They state the rules a JSON Schema can
+  express, and name the ones it cannot under `x-dropped-refinements`:
+
+      node_modules/@objectstack/spec/json-schema/<category>/<Type>.json
+
+  `objectstack.config.ts` needs neither: `defineStack` types it in your
+  editor. Delete the `os generate schema` call, and any editor setting
+  that maps `objectstack.schema.json` — nothing writes that file now.
+
+  Docs: https://objectstack.ai/docs/deployment/cli
+```
+
+**What to do.** The refusal's pointer is the whole of it. Delete the
+`os generate schema` call, and any editor setting that maps `objectstack.schema.json`
+(a `json.schemas` or `yaml.schemas` entry, for example). Run `os validate` to check a
+project against the rules that actually run. For JSON metadata, point the editor at
+`node_modules/@objectstack/spec/json-schema/`, one file per metadata type. There is no
+call to rename: nothing replaces the command.
+
+**Reach outside this repository is NOT MEASURED.** There is no telemetry, so whether
+any project runs the command or reads its file is unknown. Inside this repository
+nothing does: no reader and no editor mapping of `objectstack.schema.json` exists.
+If these release notes also record that `os generate schema` can now write its file,
+this retirement supersedes that repair.
+
+**Two neighbouring answers change with it.** The retirement ledger is now read before
+the command routes its sub-commands and before it asks for a `<name>`, which is what
+lets `os generate schema` (no name) reach the refusal at all. So `os g agent` with no
+name now prints the agent retirement instead of `Missing required argument: <name>`.
+The ledger lookup also reads its own keys only: `os g constructor <name>` used to be
+taken for a retired type and crashed with a `TypeError`, and it now falls through to
+the ordinary type checks.
+
+The docs row that advertised the command — "Autocomplete and validation for
+`objectstack.config.ts` (via `os generate schema`)" in
+`content/docs/api/data-flow.mdx` — is gone, with the diagram's JSON Schema node above
+it.

.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/19974-having-comparand-shape-face.md

@@ -27,4 +27,4 @@ The gate is ONE call in `engine.aggregate`, ahead of both `having` evaluations,
 
 Who is affected: `having` is a request-only key (`QuerySchema.having`, `EngineAggregateOptions.having`), and no metadata type stores it. Every `having` in this repository's docs and published skills is a scalar comparison (`{ order_count: { $gt: 5 } }` and the like), and none authors a refused shape. Callers of `engine.aggregate` and of the REST aggregate query in a deployment were NOT measured.
 
-Not changed: scalars, `null` in the equality slot (the has-no-value predicate), `$in` / `$nin` lists including the empty list, a two-bound `$between`, and scalar ordering bounds all answer exactly as before, on both paths. `$ne` with a list is not judged by the face yet, so `having` still answers it. Neither the comparand-TYPE door nor the unknown-field and declared-type gates that `where` also passes are run on `having`; this change adds the comparand-shape face only.
+Not changed: scalars, `null` in the equality slot (the has-no-value predicate), `$in` / `$nin` lists including the empty list, a two-bound `$between`, and scalar ordering bounds all answer exactly as before, on both paths. `$ne` with a list is not judged by the face yet, so `having` still answers it. Neither the comparand-TYPE door nor the unknown-field and declared-type gates that `where` also passes are run on `having` by this change, which adds the comparand-shape face only (the comparand-TYPE door, #20099, and the temporal-comparand door, #20263, reach `having` in the same release).