@@ -0,0 +1,80 @@
+---
+'@objectstack/spec': minor
+'@objectstack/metadata-core': minor
+'@objectstack/platform-objects': patch
+---
+
+**BREAKING** — retire `object.tenancy.organizationField`, the stamp-only column
+declaration the whole protocol declared exactly once, on a table this platform ships.
+
+The key answered "which column says who this platform row is ABOUT", where
+`tenancy.tenantField` answers "what is this object WALLED by". The spec's own docblock
+stated the consequence: *"For ordinary objects the two coincide and `organizationField`
+is never needed."* Measured on `main` before this change, the entire repository declared
+it **once** — `packages/platform-objects/src/identity/sys-api-key.object.ts`, the
+better-auth credential table — and zero business objects declared it anywhere. Its
+readers were three platform-row writers, scope-pinned **by name** (audit stamping, the
+approval-row writer, the automation-run recorder), so an application declaration was
+inert by construction while still being authorable on every object, which made every
+future piece of organization logic owe the question "what if somebody set this?".
+ADR-0049 enforce-or-remove; maintainer ruling 2026-09-18, verbatim and untranslated:
+「organizationField 撤出可授权面 同意你的建议」.
+
+## FROM → TO
+
+| you wrote (17.4 and earlier) | write instead |
+| --- | --- |
+| `tenancy: { enabled: false, organizationField: 'active_organization_id' }` | `tenancy: { enabled: false }` — delete the key. Nothing read it on an application object |
+| `tenancy: { enabled: true, organizationField: 'about_org_id' }` on an object whose tenant column really is `about_org_id` | `tenancy: { enabled: true, tenantField: 'about_org_id' }` — the surviving key both walls the object and stamps its platform rows |
+| you declared it to make one platform table's rows stamp differently | nothing to write. That divergence is a platform fact now, not a knob |
+
+The `tenancy` block is `.strict()`, so the key is **refused** with its prescription
+rather than stripped, and `os migrate meta --from 17` lists the mechanical edits for
+existing sources.
+
+## What does NOT change
+
+The `sys_api_key` divergence is intact, and that is the point of the shape this takes.
+The credential table is `managedBy: 'better-auth'`, so `resolveInjectedSystemColumns`
+bails before tenancy is consulted and no `organization_id` is ever injected; the column
+it really carries is better-auth's `active_organization_id`. Its audit, approval and
+automation-run rows still stamp that column. What moved is only where the fact is
+written: `PLATFORM_STAMP_ORGANIZATION_COLUMNS` in `@objectstack/metadata-core`, one row,
+keyed by object name and read by the STAMP face alone. The WALL face
+(`resolveRecordWallOrganizationField`) never read the key and is untouched, so the
+stamp/wall divergence pin stands unchanged.
+
+⛔ The column is **not** renamed to `organization_id` and must never be: in this platform
+"has an `organization_id` column" IS the wall, so the rename would wall the credential
+table on an equality that excludes NULL and every pre-existing key would vanish from its
+own owner's key list.
+
+## For `@objectstack/metadata-core` consumers
+
+`resolveRecordOrganizationField` and `createRecordOrganizationResolver` keep their
+signatures and their four-limb precedence. Limb 0 is now keyed by the object's
+registered NAME against the platform table instead of by a declaration on the definition:
+the engine-bound resolver passes the name it was asked about, and the two-argument
+function reads `objectDef.name` when the definition carries one. A caller that fed it a
+hand-built definition carrying `tenancy.organizationField` — only reachable by
+reimplementing a platform writer — now gets limbs 1 to 4.
+
+The retirement kit, in the shape the playbook prescribes:
+
+- the key is DELETED from `TenancyConfigSchema` (the block is a `strictObject`), and a
+  `TENANCY_RETIRED_KEY_GUIDANCE` row carries the prescription beside the two v15.0
+  precedents (`tenancy.strategy`, `tenancy.crossTenantAccess`)
+- D2 conversion `object-tenancy-organization-field-removed` (`toMajor: 18`,
+  `retiredFromLoadPath: true`) strips the key from authored sources and stored
+  `sys_metadata` rows; D3 wires it into the protocol-18 chain step, and
+  `RETIRED_KEYS_BY_MAJOR[18]` declares `data/TenancyConfig:organizationField`
+- the `authorable-surface/data.json` row is deleted in this same commit — the strict
+  route's tripwire — with the build computing the guidance-route proof for itself
+- the liveness ledger row is deleted, since the key leaves the walked shape entirely
+- pin tests: the authored shape is refused with its prescription, and the `sys_api_key`
+  stamp is pinned end to end beside the closed-set control (the same shape under any
+  other object name takes the ordinary limbs)
+
+Clause-②: no
+
+<!-- adr-0087: registered object-tenancy-organization-field-removed -->
@@ -0,0 +1,21 @@
+---
+'@objectstack/spec': patch
+---
+
+`packages/spec/src/migrations/registry.ts`: the shipped ADR-0087 semantic entry `filter-preset-ordering-comparand-refused` listed a page filter and a component filter among the `FilterConditionSchema` carriers, and said the schema door and the `@objectstack/lint` `filter-preset-comparand` rule refuse a bare date-range preset there at publish. Both are `ViewFilterRuleSchema` rule arrays, and a rule array carries no preset check, so an upgrader who swept stored pages with a schema parse found nothing and concluded the sweep was clean. The entry's `surface`, `reason` and `acceptanceCriteria` now put each carrier under the door that actually refuses it.
+
+Clause-②: no
+
+No behaviour moves. No schema, accept set or lint rule is touched, and no export is added, removed or retyped. Every line this change edits in `registry.ts` is a string literal inside that one step-18 entry, which the exported `MIGRATIONS_BY_MAJOR` carries, so what moves in `dist` is prose.
+
+- **The three groups the entry now draws.** They list the carriers measured, not a closed partition; the entry's grep sentence is the catch-all. Each was measured against the built `dist` with a preset comparand (`last_30_days`, and `today` as a `between` endpoint), and an ISO-date dark control reads green in every cell.
+  1. Slots typed `FilterConditionSchema`: `DashboardWidgetSchema.filter`, `GlobalFilterOptionsFromSchema.filter`, `DatasetSchema.filter`, `DatasetMeasureSchema.filter`, `ReportSchema.runtimeFilter`, `JoinedReportBlockSchema.runtimeFilter`, `FieldSchema.relatedListFilter` and `FieldSchema.summaryOperations.filter`. A parse of the declaring schema refuses each one at the comparand's own path, and the lint rule reports each one as well.
+  2. Filters under a key the lint walks whose declared type carries no preset check. These are `ViewFilterRuleSchema` rule arrays (a view's `filter`, a page element's `dataSource.filter`, a page component's `filter` prop) and a Mongo-shape record typed as a loose record rather than `FilterConditionSchema` (a flow `get_record` / `update_record` / `delete_record` node's `config.filter`). These parse green, and the lint rule alone refuses them.
+  3. A page's `interfaceConfig.filterBy` and a lookup field's `lookupFilters` parse green and also lint green, because the lint's filter walk descends neither key. Neither door refuses them at publish, so the entry now tells the upgrader to sweep both by hand. Two controls back the `filterBy` reading. A malformed `filterBy` value is refused at `interfaceConfig.filterBy.0.value`, so the slot is parsed. The same rule under `interfaceConfig.filter` is refused by the lint, so the key name is what decides. `lookupFilters` takes `gt`, `gte`, `lt` and `lte` as its only ordering spellings (`greater_than`, `after`, `between`, `>` and `$gt` are refused at `lookupFilters.0.operator`), and the by-hand clause names those four.
+- **Two more false sentences are narrowed.**
+  - The `replacement` called the dashboard date-filter positions "the only place any layer ever resolved" a preset name. An analytics query's `timeDimensions[].dateRange` accepts and resolves the names too.
+  - The `reason` said equality and membership "are NOT judged". That holds for the schema door only. The lint rule refuses a preset in an equality or membership position on a field it can resolve to a declared `date` or `datetime`, while `this_quarter` on a `select` field stays green. Where the filter binds to no object, such as a widget whose `dataset` names no dataset, that arm does not fire.
+- **Reach.** Counted over `dist/index.js`, `dist/index.mjs`, `dist/browser/index.js` and `dist/browser/index.mjs`:
+  - The removed carrier list `page filter, component filter, rollup filter` and each of the four other removed claims read 4 before and 0 after.
+  - Each of nine sentences unique to the corrected text reads 0 before and 4 after.
+  - The unchanged dark control `compared false against every row: HTTP 200` reads 4 on both sides.
@@ -0,0 +1,26 @@
+---
+'@objectstack/spec': minor
+---
+
+fix(spec): `defineStack(config, { strict: false })` refuses a non-array `objects` with the ADR-0112 envelope
+
+**BREAKING** — `defineStack`, a public root export, now refuses under `strict: false` a class of input it used to crash on or hand on unusable: a non-array `objects`, or an `objects` array holding an entry that is not an object.
+
+The non-strict door skips the parse and hands the normalized input to the action merge that ends every `defineStack` call. That merge read `objects` with no shape guard. Measured before this change:
+
+| `objects` under `strict: false` | before | after |
+| :--- | :--- | :--- |
+| a number or a string (`5`, `'abc'`) | bare `TypeError: config.objects.map is not a function`, `code` and `status` both `undefined` | refused, `STACK_SCHEMA_INVALID`, `status: 422` |
+| `null`, `''`, `0`, `false` | returned untouched, refused one call later by `composeStacks` | refused, `STACK_SCHEMA_INVALID`, `status: 422` |
+| an array holding `null` (`[null, obj]`) | bare `TypeError` reading `actions` off `null` | refused, `STACK_SCHEMA_INVALID`, `status: 422`, one issue per entry at `['objects', index]` |
+| an array holding another non-object (`[obj, 7]`, `[obj, 'x']`) | returned with the entry in place, a success whose objects are not all objects | refused, `STACK_SCHEMA_INVALID`, `status: 422`, one issue per entry at `['objects', index]` |
+
+`strict: false` skips validation — cross-references and schema detail — and never promised to accept a shape the merge cannot read. The refusal carries the code the strict parse raises for the same authored mistake, with the zod issue on `issues` — `path: ['objects']`, `expected: 'array'` for the collection, `path: ['objects', index]`, `expected: 'object'` for each non-object entry — the same line `composeStacks` draws for a non-array `objects`. Every row narrows: nothing that used to be refused is accepted now. An absent `objects` (`undefined`) is not malformed and behaves as before; the map form (`{ name: { … } }`) is still normalized to an array first and accepted.
+
+Fix: author `objects` as an array of object definitions or in the map form, or drop `strict: false` to have every schema check run.
+
+No code is added to the ADR-0112 ledger and no export changes: `STACK_SCHEMA_INVALID` is already registered under `@objectstack/spec`.
+
+<!-- adr-0087: not-required (no-migration-prescription) Nothing authorable moves: no spec key, Zod schema, export, config field or stored metadata shape is added, removed, renamed or re-spelled. The strict defineStack parse already refused every input this refuses, so an authored stack that passed its schema builds exactly as before; what narrows is the runtime behaviour of the strict: false door on inputs that bypassed that parse, and objectstack migrate meta has no document to rewrite for it. -->
+
+Clause-②: no (narrowing)