@@ -0,0 +1,24 @@
+---
+"@objectstack/lint": minor
+---
+
+A sharing rule whose `condition` compares a field with a `json` or `multiple` field is refused when it is authored, at `os validate` / `os build` / `os lint`, instead of being seeded and then granting nothing (#19886).
+
+**BREAKING** — an accept-set narrowing, shipped by `@objectstack/lint` as `minor` under the repo's launch-window convention for accept-set narrowings. The hand-migration prescription is already registered under protocol major 18 as `cel-predicate-one-value-comparand-refused`, whose surface names `sharingRules[].condition` and this class.
+
+Clause-②: no (narrowing)
+
+`record.status != record.tags`, with `tags` a `json` field or a `multiple` lookup, lowers to a legal filter shape, because the CEL lowering sees the condition's text and not the object's field types, so the seeder seeds the rule. Measured before this change: 72 conditions (`==`, `!=`, `!(==)`, `>`, `>=`, `<`, `<=`; a `json`, `address`, `multiselect`, `multiple` lookup and `multiple` user field; both operand orders; plus a list-against-list and a compound spelling) were all accepted by the real `os validate`. The runtime refused every one of them, measured through the real plugin-sharing on driver-sql and driver-sqlite-wasm: the rule was seeded into `sys_sharing_rule`, every criteria query it ran answered `INVALID_FILTER` / 400, `SharingRuleService` read that as matching no record, and no `sys_record_share` grant was written, at boot or on a later insert or update. The recipient read nothing. The only signal was one WARN line per rule in the server log.
+
+What changes:
+
+- `@objectstack/lint`: `validateSharingRuleEnforceability` reports `sharing-rule-unlowerable-condition` for a condition that lowers but compares two fields (`==`, `!=`, `>`, `>=`, `<`, `<=`, on either side, under `!` too) where either column is DECLARED to hold a list or an object. It uses the same classification as the row-level-security rule's arm for this class (`listHoldingComparisons`, now exported from `validate-rls-predicate-enforceability.ts`), which reads the spec's value-shape classes, the same two driver-sql refuses such a comparison by: a structured JSON type (`json`, `composite`, `repeater`, `record`, `location`, `address`, `vector`), or a multi-valued field (`multiselect`, `checkboxes`, `tags`, or `select` / `radio` / `lookup` / `user` / `file` / `image` with `multiple: true`). The finding names each comparison and the declaration behind it, and states the run-time consequence. It keeps the unlowerable id because the fix is the same rewrite of the condition, and the literal spelling of the same class (`record.status == ['a', 'b']`) is already reported under that id.
+- Inactive rules are judged too, as the rule already does for every condition: the seeder seeds them regardless of `active`.
+
+Not changed: a field compared with a single-valued field (`record.status != record.owner_name`, `record.amount > record.budget`), a `json` or `multiple` field compared with a literal or tested against `null`, and any column the stack does not declare (an anchor object from another package, an object with no field map, an undeclared name), which the rule does not judge. No row-level-security verdict changes. The rule still runs only at the CLI doors; the metadata save door for a `sharing_rule` does not run it, as before.
+
+No shipped condition moves: the 3 declared sharing-rule conditions in this repository's packages and examples compare a field with a literal, the cloud repository declares none, and the real `os validate` over `app-crm`, `app-multi-package`, `app-showcase` and `app-todo` reports no new `sharing-rule-*` finding.
+
+**What to change.** A field compared with a `json` or `multiple` field has no row-filter form: compare with a single-valued column, or with a literal ("one of these values" is `record.status in ['open', 'pending']`), or keep the value the rule keys on in a single-valued field and compare with that.
+
+<!-- adr-0087: not-required (already-registered cel-predicate-one-value-comparand-refused) The entry's surface already names sharingRules[].condition and this exact class ("a field compared with another field (==, !=, or an ordering operator) where either column holds a list or an object on the record, as a json column or a multiple lookup does"), and its replacement carries the prescription ("A field compared with a json or multiple field has no pushdown form: compare with a single-valued column"). This change moves where that registered class is refused on a sharing rule, from a silent zero-share at run time to authoring time; it adds no class and no prescription the entry does not already hold, and it rewrites no stored metadata. -->
@@ -0,0 +1,78 @@
+---
+'@objectstack/spec': minor
+'@objectstack/platform-objects': patch
+---
+
+**BREAKING** — retire `currencyConfig.precision`: a currency's decimal places are its currency's (#19992).
+
+`currencyConfig.precision` was declared, validated against ISO 4217, and baked to `2`
+into parse output — and **no renderer or runtime ever read it**. objectui's
+`CurrencyField` derives an amount's decimal places from the currency's ISO 4217
+minor unit (2 for USD, 0 for JPY, 3 for KWD) and never looked at the key, so an
+author who wrote `precision: 4` saw the same two decimals as everyone else. Its
+only reader was its own contradiction check. ADR-0049 enforce-or-remove; triage
+direction REMOVE under ruling 乙 on #19910 — 「a currency's decimal places are the
+currency's, not a setting」.
+
+Clause-②: no
+
+## FROM → TO
+
+| you wrote (17.4 and earlier) | write instead |
+| --- | --- |
+| `currencyConfig: { precision: 2, currencyMode: 'fixed', defaultCurrency: 'USD' }` | `currencyConfig: { currencyMode: 'fixed', defaultCurrency: 'USD' }` |
+| `currencyConfig.decimals` / `currencyConfig.scale` (always refused, with a suggestion to write `precision`) | nothing — delete the key; the refusal now says why instead of suggesting `precision` |
+| a field whose amounts need a different number of decimals | a different currency: the width is the currency's minor unit and is declared nowhere |
+
+**The one-line fix:** delete `precision` from every `currencyConfig`. ⛔ Do not move
+the number to the field-level `precision`: that key is the amount's TOTAL digit count
+(a DECIMAL(18,2) amount declares `precision: 18`), not its decimal places, and it is
+unchanged by this release.
+
+`os migrate meta --from 17` lists the mechanical edits for existing sources; apply
+them by hand.
+
+## The retirement kit
+
+- **`CurrencyConfigSchema.precision`** — removed from the shape. The schema is a
+  `strictObject`, so the route is strict deletion plus a `guidance` entry: an
+  authored key is refused as `unrecognized_keys` at `currencyConfig`, and the message
+  carries the prescription (``currencyConfig.precision` was removed in
+  @objectstack/spec 17.5.0 (ADR-0049 enforce-or-remove) — no renderer or runtime ever
+  read it: …``). `tsc` refuses a literal in a typed position too — the key is off
+  `CurrencyConfig`'s input type.
+- **The `decimals` / `scale` aliases** — gone with their target. Each is now answered
+  with the same reason (`` `currencyConfig.scale` is not a currency configuration key,
+  and nothing replaces it: … ``) and no rename suggestion.
+- **The ISO 4217 contradiction check** (the `.superRefine`) and **the
+  default-materializing `.overwrite()`** — both existed only for this key and are
+  removed. `CurrencyConfigSchema.parse({})` now returns exactly
+  `{ currencyMode: 'dynamic', defaultCurrency: 'CNY' }`; `CurrencyConfigParsed` no
+  longer declares `precision`. The internal helpers `currencyPrecisionContradiction`
+  and `currencyFractionDigits` (never exported from a public entry) are removed; the
+  CLDR table they read stays, because the `iso_4217_currency` value domain reads its
+  key set.
+- **The field designer form** — the field-level `precision` row's help text read
+  "Decimal places (e.g., 2 for $10.50)", the one reading the contract refuses. It now
+  reads "Total digits", matching the key's describe and the object designer's row;
+  the zh-CN / ja-JP / es-ES translations follow (`@objectstack/platform-objects`).
+- **Registry** — `RETIRED_KEYS_BY_MAJOR[18]` gains `data/CurrencyConfig:precision`;
+  the protocol-18 step gains the D2 conversion `currency-config-precision-removed` and
+  its D3 entry `currency-config-precision-retired`, which states the two judgments the
+  strip cannot make: a width declared where the old check never looked (a `dynamic`
+  field, or a code with no known ISO 4217 minor unit) never applied, and code of your
+  own that read the served key must derive the width from the field's currency.
+
+## What an operator with STORED metadata sees
+
+Nearly every stored currency field carries this key without anyone having written it:
+the old `.overwrite()` baked `precision: 2` into parse output, so `sys_metadata`
+object rows and built artifacts hold it. Nothing breaks at read: the conversion
+`currency-config-precision-removed` is retired from the load path but replayed by the
+stored-row and artifact seams, which strip the key from every field's
+`currencyConfig` on objects and object extensions and serve the row canonical. The
+strip is lossless — the key never had an effect — and the field-level `precision` is
+never touched. `os migrate meta --stored --apply` rewrites the stored rows so the
+per-row notice stops.
+
+<!-- adr-0087: registered currency-config-precision-removed -->
@@ -10,12 +10,12 @@ fix(cli): what `os generate` writes now reaches the stack, or the command says i
 
 - `objectstack.config.ts` imports every directory `os generate` writes into (`src/objects`, `src/views`, `src/actions`, `src/flows`, `src/dashboards`, `src/apps`, `src/skills`) and hands each barrel's exports to `defineStack` under its key (`objects`, `views`, …). A file `os g` writes there is part of the stack with no edit to the config. The keys read the barrels through a small `exportsOf` helper declared in the config, because `Object.values` on an empty barrel does not type-check against `defineStack`'s collection types.
 - An `index.ts` containing only `export {};` for each directory the template puts nothing in. An `index.ts` that already exists is kept as it is and never overwritten.
-- `requires: ['automation', 'triggers']`. A flow that starts on a record change is fired by `triggers` and run by `automation`. Without `triggers`, `defineStack` refuses the config as soon as it holds such a flow. Without `automation`, the server loads the flow and never runs it.
+- `requires: ['automation', 'triggers']`. A flow that starts on a record change is fired by `triggers` and run by `automation`. If either one is missing, `defineStack` refuses the config as soon as it holds such a flow.
 
 **What `os generate` now does:**
 
-- After writing, it loads the project's config again and reports on the new item. Either the stack carries it, or it is **not wired** (the file is written, the config is left untouched, and the command prints the import and `defineStack` key to add), or it **cannot run** (a flow in a stack whose `requires` lacks `automation`: the command prints the whole `requires` list to use). It never edits the config.
-- It refuses a write that makes a config that loaded stop loading, for example an action or app bound to an object nobody declared, or a flow in a stack without `triggers`. It removes what it wrote, exits 1, and prints the stack's own reason. Generate the object first (`os g object customer`), then what binds to it. `dashboard` and `skill` now read the config too, so they can report, and they still generate when the config does not load.
+- After writing, it loads the project's config again and reports on the new item. Either the stack carries it, or it is **not wired** (the file is written, the config is left untouched, and the command prints the import and `defineStack` key to add). It never edits the config.
+- It refuses a write that makes a config that loaded stop loading, for example an action or app bound to an object nobody declared, or a flow in a stack without `triggers` or without `automation`. It removes what it wrote, exits 1, and prints the stack's own reason. Generate the object first (`os g object customer`), then what binds to it. `dashboard` and `skill` now read the config too, so they can report, and they still generate when the config does not load.
 - A view's own `name` is now the object it binds to, prefix included (`my_app_order_line`, not `order_line`). The server registers a view under its object and refused, at boot, a scaffold whose `name` disagreed. That never showed while the views barrel was not loaded.
 - The barrel step asks the compiler whether the barrel already exports the name, instead of searching the file's text. `os g view order` after `os g view order_line` had found `order` inside `orderLine` and exported nothing.
 - The `flow` scaffold's header states the `requires` it needs.
 
@@ -0,0 +1,57 @@
+---
+"@objectstack/objectql": minor
+---
+
+fix(objectql)!: a number, currency, percent, rating, slider or progress field refuses an array, a boolean or an object with `invalid_number` (#20309)
+
+Clause-②: no (narrowing)
+
+**BREAKING**: 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 below, never by the level). The
+narrowing: an array, a boolean or an object whose `Number()` is finite, such as
+`[500]`, `[]`, `true` or `false`, written to one of those fields is now refused
+with `400 VALIDATION_FAILED` / `invalid_number`. It used to be accepted and
+stored as sent.
+
+## What was wrong
+
+The record validator judged `Number(value)` on a number-typed field, but the
+write carried `value` itself. Every value that JavaScript coerces to a finite
+number therefore passed the check and reached the driver unchanged:
+
+- **SQLite** stored `[500]` as the TEXT `'[500]'`, which a read returned as the
+  string `"[500]"`; `[]` as the TEXT `'[]'`; and `true` / `false` as `1` / `0`.
+- **memory** stored the array or the boolean itself.
+
+`[5, 7]` and `{}` were already refused, because `Number()` of each is `NaN`.
+
+## What changes
+
+- On `number`, `currency`, `percent`, `rating`, `slider` and `progress`, a value
+  that is neither a number nor a string is refused with `invalid_number`: an
+  array, a boolean, a plain object, a `Date`. This holds on every engine, REST,
+  batch and import write door, because they all write through the same
+  validator.
+- A number is judged and stored exactly as before, and so are the `min`, `max`
+  and `scale` checks and their messages.
+- A string is also unchanged. It is still judged by `Number()` and stored as
+  sent. Which strings a number field accepts is a separate change.
+- `summary` is still not judged by this check (it is in the spec's
+  `COMPUTED_VALUE_TYPES`). A blank still becomes `null` before the check runs.
+
+## Rows already stored
+
+This refuses new writes only; a stored value is never re-read by the check.
+Rows written earlier on SQLite may hold such a value as TEXT in a numeric
+column. To find them, run this once per number-typed column:
+
+```sql
+SELECT id, "FIELD" FROM "OBJECT" WHERE typeof("FIELD") = 'text';
+```
+
+OBJECT is the object name and FIELD is the field name. A match is a cell that
+SQLite could not store as a number: an array written as TEXT, or a string such
+as `'0x10'`. Decide its number by hand; nothing here rewrites it.
+
+<!-- adr-0087: not-required (no-migration-prescription) Nothing authored moves: `packages/spec` is untouched and no metadata key is added, removed or reshaped, so `objectstack migrate meta` has nothing to rewrite and the ledger has no row to gain. What is refused is a caller-written VALUE (an array, a boolean or an object on a number-typed field) at the write door; stored rows are never re-read by the check, and a caller that sends a number, a string or a blank is unaffected. The other categories are closed on facts: the package publishes (not `unpublished`); no ADR-0087 id covers a write-door value check (not `registered` / `already-registered`); and the change is runtime behaviour, not a TypeScript declaration (not `runtime-interface-only` / `type-surface-only`). -->
@@ -0,0 +1,68 @@
+---
+'@objectstack/spec': minor
+---
+
+feat(spec)!: retire `rowLevelSecurity[].tags` — no mainstream platform tags a row-level policy, and nothing here ever read one (#20321)
+
+Clause-②: no (narrowing)
+
+**BREAKING** — shipped as `minor` under the launch-window convention
+(`check-changeset-no-major` refuses `major` until GA; breaking-ness is carried by
+this banner, the `(narrowing)` arm above and the ADR-0087 disposition below).
+
+`tags` is removed from the row-level security policy (`RowLevelSecurityPolicySchema`,
+the entries of a permission set's `rowLevelSecurity`). ADR-0049
+enforce-or-remove, graded RETIRE by the maintainer's criterion for
+declared-but-unenforced families — does a mainstream platform have the
+capability? None does: Salesforce sharing rules, Dataverse security roles and
+PostgreSQL RLS policies carry no tag attribute, and compliance reporting there
+keys on the rule itself.
+
+The key promised "categorization and reporting" for governance and compliance.
+Nothing ever read it. Measured before removal, each against a lit control: the
+RLS compiler reads a policy's `name`, `object`, `operation`, `positions`,
+`enabled` and predicates, never `tags`; objectui's permission preview renders
+the policy COUNT and its policy editor neither seeds nor reads the key; cloud
+has no reader. No example, default permission set or cloud source wrote it.
+
+### FROM → TO
+
+| removed | what to write instead |
+| --- | --- |
+| `rowLevelSecurity[].tags` | delete the key. To limit whom a policy applies to, list the positions in `positions` — a tag never did that. To say why a policy exists, use `description`. |
+
+**The one-line fix: delete `tags:` from every row-level security policy.**
+`os migrate meta --from 17` lists the mechanical edits for existing sources;
+apply them by hand.
+
+⚠️ Runtime behaviour is deliberately **unchanged**. No access decision ever
+depended on a tag, so removing the key removes no behaviour. What changes is the
+answer an author gets: a policy carrying `tags` is now refused at parse, with the
+prescription, instead of being stored with no effect. An author who wrote a tag
+such as `managers_only` believing it scoped the policy now learns that only
+`positions` does.
+
+### The retirement kit
+
+- **A `retiredKey()` tombstone** on `RowLevelSecurityPolicySchema` (the
+  `priority` posture one key over): `tsc` types the key `never`, and every parse
+  raises the prescription rather than a bare unknown-key verdict. The shape's
+  did-you-mean never offers it: a near-miss `tag` is refused as unknown.
+- **D2 conversion `permission-rls-tags-removed`** (step 18, retired from the load
+  path): a lossless delete over `permissions[].rowLevelSecurity[]`, so a stored
+  permission row that still carries the key replays clean through the
+  rehydration seam, while a live author is refused rather than rewritten.
+- **`RETIRED_KEYS_BY_MAJOR[18]`**: `security/RowLevelSecurityPolicy:tags`, and
+  the family's D3 entry `permission-rls-tags-retired`, which states what the
+  strip cannot decide — any report, audit filter or review process built on the
+  belief that policy tags were read needs another path.
+- **The liveness row stays**, `dead`, under its tombstone (the key is still in
+  the walked shape); `authorable-surface/security.json` carries it as
+  `security/RowLevelSecurityPolicy:tags [RETIRED]`, and the generated reference
+  pages print the prescription in place of the old describe.
+- **No deprecation window**, per the project's startup-stage posture.
+
+⚠️ **The out-of-repo consumer population is NOT MEASURED.** `@objectstack/spec`
+is published, so this is breaking for consumers no telemetry was consulted for.
+
+<!-- adr-0087: registered permission-rls-tags-removed, permission-rls-tags-retired -->