Merge remote-tracking branch 'origin/main' into claude/issue-20301-list-tabs-retired

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

Author: claude

.changeset/19886-sharing-rule-list-holding-field-comparison-authoring.md

@@ -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. -->

.changeset/19992-currency-config-precision-retired.md

@@ -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 -->

.changeset/20215-generate-scaffolds-reach-stack.md

@@ -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.

.changeset/20289-os-test-names-tags.md

@@ -0,0 +1,17 @@
+---
+'@objectstack/cli': minor
+'@objectstack/core': minor
+'@objectstack/spec': patch
+---
+
+`os test` reports the suite and scenario names an author writes, and selects scenarios with `--tags` (#20289)
+
+Clause-②: no
+
+A Quality Protocol suite's `name`, each scenario's `name` and `description`, and scenario `tags` were parsed at load and then read by nothing: the report headed each suite with its file's basename, printed every scenario by its `id`, and `os test --tags critical` failed with `Nonexistent flag: --tags`.
+
+- **Names in the report.** The suite heading is now the suite's `name` followed by its file — `📄 Running suite: Accounts smoke (accounts.test.json)` — and each scenario line is its `name` with the `id` in brackets — `✅ Scenario: An account can be created [acct-create] (12ms)` (the id alone when the two are equal). A failed scenario's `description` is printed under its line, before the error. A suite whose file fails to load is still headed by the file alone, since no name was parsed.
+- **`--tags TAG[,TAG...]`** runs only the scenarios carrying AT LEAST ONE of the listed tags (any-of, exact, case-sensitive) — the comma-list reading of Odoo's `--test-tags` and the everyday use of Playwright's `--grep @a|@b`. With the flag, an untagged scenario is left out. Left-out scenarios are **deselected**: not run, counted on the summary (`--tags smoke selected 1 of 4 scenarios; 3 deselected (not run, not counted as passed).`), never counted as passed. A requested tag that no loaded scenario carries is named on the summary. An empty entry (`--tags smoke,`) is refused before anything runs. Without the flag nothing changes: every scenario runs.
+- **Exit status.** A selection that matches no scenario takes the posture an empty pattern already has: exit `0` with `No scenario matched --tags …`, and exit `1` under `--fail-on-empty`, whose description now covers both cases. The `Found N test suites.` line and the `SUCCESS: All N scenarios passed.` / `FAILED: …` summary lines keep their spelling.
+- **`@objectstack/core`:** `QA.TestResult` gains `scenarioName` and `description` on every result, and `suiteName` on every result `runSuite` produces (absent only from a lone `runScenario` call, which has no suite).
+- **`@objectstack/spec`:** `TestScenario.requires` (`params`, `plugins`) is still checked by nothing — its describe() now says **NOT CHECKED** instead of reading as a guard, so a scenario that declares a plugin the target lacks still runs, and the unmet requirement surfaces only as whatever failure it causes, if any. The liveness ledger (`liveness/qa.json`) moves the four keys above to `live`, citing their readers.

.changeset/20291-expression-refusal-codes.md

@@ -0,0 +1,17 @@
+---
+'@objectstack/formula': minor
+'@objectstack/spec': minor
+---
+
+Expression refusals now carry a stable `code` and typed `params` beside their English `message`, so a localized author surface can render its own words: `validateExpression` (every entry in `errors[]` and `warnings[]`), `collectCelRootIdentifiers` (its `ok: false` arm), `predicateSlotRefusal` and `structuralConditionRefusal` (#20291)
+
+Clause-②: yes
+
+Until now the only thing a refusal said was an English sentence, and a designer running in another locale could only show it verbatim, beside its own translated headings. Each refusal now also names its code — one of a closed, kebab-case set — and the values its sentence interpolates, so a consumer keys a catalogue row to the code and fills it from the params. The `message` is the same sentence, byte for byte; nothing is removed or renamed, so no existing reader changes.
+
+- `@objectstack/formula` exports `EXPRESSION_REFUSAL_CODES` (the closed set as a frozen list) and the types `ExpressionRefusalCode`, `ExpressionRefusalParams` (code → params), `ExpressionRefusal`, `ExprValidationCode`, `CelRootsRefusalCode`, `CelFieldRole`, `ExpressionSourceKind` and `CelRootIdentifiersResult`. `ExprValidationError` gains `code` and `params`.
+- `@objectstack/spec/automation` exports `FLOW_SLOT_REFUSAL_CODES` (the closed set of both flow-slot refusal producers, as a frozen list) and the types `FlowSlotRefusalCode`, `FlowSlotRefusalParams` (code → params), `PredicateSlotRefusalCode`, `PredicateSlotRefusal`, `PredicateSlotValueKind`, `StructuralConditionRefusalCode`, `StructuralConditionRefusal` and `StructuralConditionValueKind`. `predicateSlotRefusal` returns `PredicateSlotRefusal` and `structuralConditionRefusal` returns `StructuralConditionRefusal`; each is its previous `{ message, source }` plus `code` and `params`.
+- Narrowing on `code` narrows `params`. A code never changes once published: a reworded message keeps its code, and a new refusal gets a new one.
+- A `detail` param is the CEL or template engine's own diagnostic, in English, passed through as the message carries it.
+- These are authoring diagnostics returned as values, not ADR-0112 request error codes, which is why they are kebab-case.
+- The `validate_expression` MCP tool forwards `validateExpression`'s `errors` and `warnings` as they are, so each entry in its answer now also carries `code` and `params`.