@@ -0,0 +1,46 @@
+---
+"@objectstack/spec": minor
+---
+
+feat(spec): `ComponentPropsMap['element:number'].filter` converges onto the `ViewFilterRule` array form (#12039, objectui#6206 Option B)
+
+<!-- adr-0087: registered element-number-filter-rule-array -->
+
+**BREAKING** accept-set change on one props-map entry, shipped as `minor` under
+the repo's launch-window convention for breaking changes; the migration
+prescription is registered under protocol major 18.
+
+One filter orthography platform-wide (maintainer batch adjudication
+2026-08-25, verbatim 「同意」, Option B): `element:number`'s `filter` was the
+one `filter` input in `ComponentPropsMap` declared as the MongoDB-style record
+(`FilterConditionSchema`) while every sibling (`record:related_list` and its
+Add-affordance picker) declared `z.array(ViewFilterRuleSchema)` — so the
+filter a list view stores and renders was refused by the KPI element beside
+it. The entry now declares the same array form its siblings do.
+
+Sequenced consumer-first (the 2026-08-25 Option-A ordering ruling):
+objectui#6828 made `ObjectStackAdapter.aggregate()` lower a rule array through
+the same `translateFilterArray` its `find()` path runs before the analytics
+wire; the objectui pin carrying it (`d8ec8d6d`) was re-measured before this
+declaration moved, and the end-to-end chain is authored array → adapter
+lowering → filter AST → accepted by `lowerAnalyticsWhere` (which still refuses
+a RAW rule-object array — by design, and unchanged here).
+
+Migration — FROM → TO, one rule per key (several keys AND):
+
+```ts
+// before (refused now — `invalid_type` at `filter`, expected array)
+filter: { status: 'won' }
+filter: { amount: { $gt: 100 } }
+// after
+filter: [{ field: 'status', operator: 'equals', value: 'won' }]
+filter: [{ field: 'amount', operator: 'greater_than', value: 100 }]
+```
+
+The ruled migration check ran with the change: the sweep of first-party
+corpora (examples/, skills/, create-objectstack, content/docs/, packages/apps/,
+spec fixtures) found one `element:number` author writing a record-form
+`filter` — a spec test fixture, rewritten to the array form here — and zero
+outside the spec package. `ElementNumberPropsParsed` is declared
+(ADR-0122: the parsed state now differs on `filter`, whose `operator` is
+normalized on parse). `element:record_picker.filter` is not changed here.
@@ -0,0 +1,22 @@
+---
+'@objectstack/metadata': patch
+---
+
+Artifact/HMR loader: read a view container's own top-level `object` field
+
+`MetadataPlugin`'s artifact/HMR registrar derived which object a `defineView`
+container binds to by walking `list.data.object` then `form.data.object`, and
+never consulted the container's own top-level `object` — the field
+`ViewSchema.object` documents as "how a stack-level `views: [...]` entry says
+which object its views belong to; read by `getViewsByObject()` /
+`GET /meta/view?object=`".
+
+A package-shipped `defineView({ object: 'crm_lead', list: { columns: [...] } })`
+therefore registered nothing at all through this path: the container was dropped
+before registration, so no expanded `crm_lead.<key>` ViewItems were produced and
+`getViewsByObject('crm_lead')` / `GET /meta/view?object=crm_lead` answered empty
+for it. Both derivation sites now call the package's single spelling of that
+derivation (`deriveViewContainerObject`), which consults the container's own
+`object` first and keeps the existing `list.data.object` → `form.data.object` →
+row-name fallback unchanged for every container written before that field was
+read here. This is the same order #13407 settled at the runtime door.
@@ -0,0 +1,5 @@
+---
+'@objectstack/service-automation': patch
+---
+
+`AutomationEngine.resume(runId)` called with no signal object is now held to the suspended `screen` node's declared field contract exactly like a signal-carrying resume: a run paused on a screen with an unconditional `required` field is refused with `INVALID_SCREEN_INPUT` and stays paused, instead of proceeding with that variable unbound. The bare `if (!signal) return null` early return in `refuseInvalidScreenInput` is gone — an absent signal is an empty submission, the same shape the HTTP resume route has always assembled for an empty body — and the engine's own continuations (subflow output mapping, `map` item handoff) remain exempt only through the existing engine-built-signal mechanism. Pauses that declare no input contract are unaffected: `wait` and `approval` nodes, message-only and object-form screens, and screens whose fields are all optional or hidden resume without a signal exactly as before.
@@ -0,0 +1,27 @@
+---
+'@objectstack/driver-turso': patch
+'@objectstack/spec': patch
+---
+
+drivers(turso): an unsafe identifier on the remote transport answers `400 INVALID_REQUEST`, not an opaque 500
+
+`RemoteTransport.assertSafeIdentifier` is the one gate for every position where
+an identifier is inlined into SQL — the `object`, `field` and `groupBy`
+field/output-key positions of `aggregate`, the table and column names in
+`syncSchema` / `syncSchemasBatch`, and the index name and columns in unique-index
+sync — plus the free function of the same name in the remote canonical backfill.
+All of them threw a bare `Error` with no `code` and no `status`, so `mapDataError`
+reached none of its classifying branches and served a sanitised **500**: a caller
+whose own identifier was refused was told the server had faulted, and an SDK
+reading a 5xx retries a request that can never succeed.
+
+Every one of those refusals now carries the ADR-0112 envelope `code:
+'INVALID_REQUEST'`, `status: 400`, built by one constructor so the positions
+cannot answer three ways. `@objectstack/spec` gains only the error-code ledger's
+provenance row registering this driver as an emitter of a code seven packages
+already register — the registered-code union is byte-identical (248 codes before
+and after) and no new code is minted.
+
+**Nothing about which identifiers are refused changed.** `SAFE_IDENTIFIER` and
+every refusal message are untouched; exactly the inputs refused before are
+refused after, with byte-identical prose. Only `code` and `status` are new.
@@ -55,7 +55,7 @@ When a feature, schema property, or API is deprecated, ObjectStack follows a str
 - Runtime warning is emitted on first use (once per session)
 - Migration path is documented in the CHANGELOG
 
-### Phase 2: Migration Period (minimum 2 MINOR releases)
+### Phase 2: Migration Period
 
 - Deprecated feature continues to function without behavior changes
 - Documentation is updated with migration guides
@@ -75,13 +75,12 @@ Shipped examples: `17.2.0` retired `http_request_errors_total` and `sys_position
 
 ```mermaid
 flowchart TD
-    A["v3.2.0 — feature deprecated (warning emitted)"] --> B["v3.3.0 — migration period continues"]
-    B --> C["v3.4.0 — migration continues (minimum 2 minor releases)"]
-    C --> D["v3.5.0 — feature removed (earliest possible removal, MINOR)"]
+    A["Deprecation notice — feature marked deprecated (warning emitted)"] --> B["Migration period — deprecated feature keeps working, no behavior change"]
+    B --> C["Removal — retired at the boundary the ADR-0087 registry records (MINOR release, during the launch window)"]
 ```
 
 <Callout type="warn">
-**Minimum guarantee:** Deprecated features survive for at least **2 MINOR releases** before they can be removed. During the launch window the removal itself lands in a MINOR release, so a MINOR bump is where you should expect a removal to arrive.
+**No minimum survival window.** ObjectStack does not guarantee a deprecated feature survives for a fixed number of releases — [ADR-0049](https://github.com/objectstack-ai/objectstack/blob/main/docs/adr/0049-no-unenforced-security-properties.md)'s dispositions for a flagged property are enforce, `experimental`, or remove, and none of them carries a dwell time. A deprecated feature is retired at the boundary the ADR-0087 registry records for it; during the launch window that removal itself lands in a MINOR release, so a MINOR bump is where you should expect a removal to arrive.
 </Callout>
 
 ---
@@ -109,7 +108,7 @@ Read the **Breaking?** column, not the version number: during the launch window
 
 ### Breaking Change Process
 
-1. **RFC (Request for Comments)** — Breaking changes are proposed as GitHub issues with the `breaking-change` label.
+1. **RFC (Request for Comments)** — Breaking changes are proposed as GitHub issues with the `protocol:breaking` label.
 2. **Deprecation** — The old behavior is deprecated in a MINOR release (see timeline above).
 3. **Migration Guide** — A detailed migration guide is published before the removal lands, in the release notes for the version that carries it.
 4. **Release** — During the launch window the breaking change ships in the next **MINOR** version, carrying a changeset entry marked `**BREAKING**`. `scripts/check-changeset-no-major.mjs` fails any pull request that declares a `major` bump, because under lockstep one `major` would promote all 69 published packages.
@@ -204,7 +203,7 @@ MAJOR releases do still happen — 17.0.0 was cut precisely because its breaking
 
 ### When it stops applying
 
-The tables and deprecation timeline above now state this rule directly, so the page no longer contradicts itself. Classic SemVer — where a breaking change once again requires a MAJOR — is the settled form the project returns to once the launch window closes; the condition that closes the window is tracked separately and is deliberately not stated here. Until it closes, **this section is the operative rule wherever any part of this page disagrees.**
+The tables and deprecation timeline above now state this rule directly, so the page no longer contradicts itself. Classic SemVer — where a breaking change once again requires a MAJOR — is the settled form the project returns to once the launch window closes: the window closes at GA, and strict SemVer resumes from that point. Until it closes, **this section is the operative rule wherever any part of this page disagrees.**
 
 ---
 
@@ -213,6 +212,6 @@ The tables and deprecation timeline above now state this rule directly, so the p
 If you encounter an unintended breaking change:
 
 1. **Check the CHANGELOG** — Verify the change was not documented as intentional.
-2. **Open an issue** — File a GitHub issue with the `compatibility` label.
+2. **Open an issue** — File a GitHub issue describing the unintended change.
 3. **Include a reproduction** — Provide a minimal code sample showing the breakage.
 4. **Reference the version** — Specify the exact versions where behavior changed.
@@ -175,12 +175,22 @@ const result = AIChatWindowProps.parse(data);
 | **object** | `string` | ✅ | Source object |
 | **field** | `string` | optional | Field to aggregate |
 | **aggregate** | `Enum<'count' \| 'sum' \| 'avg' \| 'min' \| 'max'>` | ✅ | Aggregation function |
-| **filter** | `any` | optional | Filter criteria |
+| **filter** | `{ field: string; operator: Enum<'equals' \| 'not_equals' \| 'contains' \| 'not_contains' \| 'icontains' \| …>; value?: string \| number \| boolean \| null \| (string \| number)[] }[]` | optional | Filter rules narrowing the aggregate — the ViewFilterRule array form `[{ field, operator, value }, ...]`, the one filter orthography every `filter` input in this map shares. The MongoDB-style record form is refused — see migration `element-number-filter-rule-array` |
 | **format** | `Enum<'number' \| 'currency' \| 'percent'>` | optional | Number display format |
 | **prefix** | `string` | optional | Prefix text (e.g. "$") |
 | **suffix** | `string` | optional | Suffix text (e.g. "%") |
 | **aria** | `{ ariaLabel?: string \| Record<string, string>; ariaDescribedBy?: string; role?: string }` | optional | ARIA accessibility attributes |
 
+### Nested Shape: `ElementNumberProps.filter[number]`
+
+View filter rule
+
+| Property | Type | Required | Description |
+| :--- | :--- | :--- | :--- |
+| **field** | `string` | ✅ | Field name to filter on |
+| **operator** | `Enum<'equals' \| 'not_equals' \| 'contains' \| 'not_contains' \| 'icontains' \| …>` | ✅ | Filter operator |
+| **value** | `string \| number \| boolean \| null \| (string \| number)[]` | optional | Filter value. The accepted SHAPE depends on the operator: `in` / `not_in` take an array (any length, including []), `between` takes exactly [min, max], every other operator takes a scalar. The unary operators (is_empty / is_not_empty / is_null / is_not_null) take their direction from the operator name and ignore this key. |
+
 ### Nested Shape: `ElementNumberProps.aria`
 
 | Property | Type | Required | Description |
 
@@ -1,6 +1,6 @@
 // Copyright (c) 2025 ObjectStack. Licensed under the Apache-2.0 license.
 
-import { ObjectStackManifest } from '@objectstack/spec/system';
+import type { ObjectStackManifest } from '@objectstack/spec/kernel';
 
 /**
  * In-Memory Driver Plugin Manifest
 
@@ -16,7 +16,7 @@
     "build": "tsup --config ../../../tsup.config.ts && node ../../../scripts/check-dts-emitted.mjs",
     "dev": "tsc -w",
     "test": "vitest run",
-    "typecheck": "tsc --noEmit"
+    "typecheck": "tsc --noEmit && tsc --noEmit -p tsconfig.typecheck.json"
   },
   "dependencies": {
     "@objectstack/core": "workspace:*",
 
@@ -0,0 +1,41 @@
+// The MANIFEST-layer type-check program for @objectstack/driver-memory (#13284).
+//
+// `objectstack.config.ts` sits at the PACKAGE ROOT and declares this driver's
+// plugin manifest, annotated `ObjectStackManifest`. Until this file existed no
+// tsc program read a line of it: `tsconfig.json` selects `src/**/*`, and that
+// glob cannot match a root-level file. The annotation was therefore decorative
+// -- the file imported the type from `@objectstack/spec/system`, an entry that
+// does not export it, and `pnpm --filter @objectstack/driver-memory typecheck`
+// still exited 0. A wrong key or a wrong import here cost nothing at author
+// time, which is the whole defect: the ADR-0049 manifest retirements
+// (#11332 / #10724 / #4914) lean on the `retiredKey()` DOUBLE channel -- tsc
+// (input typed `never`) plus parse -- and the tsc half was blind at the only
+// two places in this repo where a plugin manifest is authored in TypeScript.
+//
+// A SIBLING rather than a wider `include` on `tsconfig.json`, the distinction
+// #5475 drew for `packages/spec` and #10756 for `packages/objectql/scripts`:
+// that config EMITS (`rootDir: "./src"`, `outDir: "./dist"`, and `dev` runs
+// `tsc -w` through it), so widening it to reach the package root would put the
+// manifest in front of the emit -- measured, that is exactly TS6059 ("File
+// ... is not under 'rootDir' ... 'rootDir' is expected to contain all source
+// files"), and it fires under `--noEmit` too. This program emits nothing, so
+// it can neutralise `rootDir` without touching what ships. `tsup` builds
+// `src/index.ts` and `files` publishes `dist` only, so nothing about the
+// published package moves.
+//
+// STRICTNESS IS INHERITED and deliberately not relaxed: `strict`,
+// `esModuleInterop`, `forceConsistentCasingInFileNames` and the rest come from
+// the root config through `tsconfig.json`. The manifest type-checks clean
+// under them -- it enters with ZERO recorded debt, and there is no ledger here
+// to record any in.
+{
+  "extends": "./tsconfig.json",
+  "compilerOptions": {
+    "noEmit": true,
+    // `.` rather than the inherited `src`, because the file this program checks
+    // is the one outside `src`. Safe precisely because nothing is emitted from
+    // here -- see the header.
+    "rootDir": "."
+  },
+  "include": ["objectstack.config.ts"]
+}
@@ -93,6 +93,12 @@
  * twin's contract calls out, kept across the transport boundary.
  */
 
+// [#14287] The unsafe-identifier refusal's ADR-0112 envelope, from the one
+// place that decides it. Imported rather than re-spelled so this module and
+// `RemoteTransport` cannot answer one condition two ways; `turso-driver.ts`
+// already loads both modules together, so the edge costs nothing at runtime.
+import { unsafeIdentifierError } from './remote-transport.js';
+
 /** The `@libsql/client` surface this module uses — nothing more. */
 export interface RemoteBackfillClient {
   execute(stmt: { sql: string; args?: unknown[] } | string): Promise<{
@@ -218,9 +224,34 @@ export const REMOTE_BACKFILL_EPOCH_MS_MAX = 4_102_444_800_000;
  */
 const SAFE_IDENTIFIER = /^[a-zA-Z_][a-zA-Z0-9_]*$/;
 
-function assertSafeIdentifier(name: string): void {
+/**
+ * [#14287] The second producer of the transport's unsafe-identifier refusal,
+ * carrying the identical ADR-0112 envelope — `INVALID_REQUEST` / 400 — through
+ * the one constructor that decides it ({@link unsafeIdentifierError}). One
+ * condition, one wire answer, whichever of the two helpers refused it.
+ *
+ * ## Measured: on THIS module's paths the envelope is defence in depth, not a
+ * ## wire answer — and saying so is the point
+ *
+ * Both callers flatten the throw by design: {@link probeRemoteCanonicalColumns}
+ * turns it into `{ error: message }` and {@link backfillRemoteCanonicalColumn}
+ * into `report.error`, because ADR-0053 D-B3 forbids a migration from taking a
+ * boot down. So `code` and `status` reach no response envelope from here today
+ * — only the MESSAGE survives, into the report a caller logs. The envelope is
+ * still worth carrying, for two reasons and no third: the two producers of one
+ * condition must not drift onto two spellings (the card's own "decide the code
+ * once" argument), and a future caller that propagates instead of reporting
+ * inherits the right answer rather than re-deriving one.
+ *
+ * ⛔ It is therefore NOT the wire-reachability evidence for this package's
+ * ledger provenance row — `RemoteTransport`'s DDL and `aggregate` positions
+ * are, and they answer over HTTP. Exported so the envelope has a real pin: no
+ * exported path can observe it, and an unobservable assertion is the phantom
+ * check `AGENTS.md` names rather than a test.
+ */
+export function assertSafeIdentifier(name: string): void {
   if (!SAFE_IDENTIFIER.test(name)) {
-    throw new Error(`remote canonical backfill: unsafe identifier rejected: "${name}"`);
+    throw unsafeIdentifierError(`remote canonical backfill: unsafe identifier rejected: "${name}"`);
   }
 }
-Original file line number
+Diff line change
@@ @@ -0,0 +1,5 @@ @@
 +---
 +'@objectstack/service-automation': patch
 +---
++
 +`AutomationEngine.resume(runId)` called with no signal object is now held to the suspended `screen` node's declared field contract exactly like a signal-carrying resume: a run paused on a screen with an unconditional `required` field is refused with `INVALID_SCREEN_INPUT` and stays paused, instead of proceeding with that variable unbound. The bare `if (!signal) return null` early return in `refuseInvalidScreenInput` is gone — an absent signal is an empty submission, the same shape the HTTP resume route has always assembled for an empty body — and the engine's own continuations (subflow output mapping, `map` item handoff) remain exempt only through the existing engine-built-signal mechanism. Pauses that declare no input contract are unaffected: `wait` and `approval` nodes, message-only and object-form screens, and screens whose fields are all optional or hidden resume without a signal exactly as before.