@@ -0,0 +1,26 @@
+---
+'@objectstack/spec': minor
+'@objectstack/service-analytics': minor
+---
+
+An authored analytics cube's measure `format` and time-dimension `granularities` now take effect on the analytics query doors, the way a compiled dataset's always have (#20282).
+
+Clause-②: yes (narrowing)
+
+<!-- adr-0087: registered analytics-cube-single-granularity-default-enforced -->
+
+**BREAKING**: this narrows what `POST /api/v1/analytics/query` and `POST /api/v1/analytics/sql` answer for one class of request. When an authored cube's time dimension declares exactly one granularity, a query that groups by that dimension without stating a granularity is now bucketed at the declared one. The raw-SQL path declines every bucketed query, so such a query now runs on the engine aggregate path, which answers `400 INVALID_FIELD` for every member it cannot evaluate: a custom-SQL measure (a measure of type `number`, `string` or `boolean` whose `sql` is an expression); and, on a cube whose members resolve through its `joins`, a measure or a `where` field over a joined object, a `timeDimensions` entry over a joined object (bucketed or a `dateRange` window, so grouping by a one-granularity time dimension over a joined object is refused too), a dimension that traverses more than one relationship, and an `avg` or `count_distinct` measure beside any dimension over a joined object. The raw-SQL path answers every one of these, with one group per distinct timestamp; each is now refused, exactly as it already was when the caller stated that granularity by hand. On a host that overrides `queryCapabilities` to offer raw SQL with no engine aggregate bridge (the plugin's default wires both), no strategy remains for a bucketed query, so every newly bucketed query, a plain `count` included, now answers "No strategy can handle query" instead of grouping raw timestamps. The remedy: run such a query without grouping by that dimension, or, if the dimension is not meant to have one default bucket, declare the granularities it offers as a list of two or more (or omit the key); on a raw-SQL-only host, add the engine aggregate bridge. It ships as `minor` under the launch-window convention; the widening half is two authored keys taking effect.
+
+Until this change both keys were read on the compiled-dataset path only. One cube shape has three producers — cubes authored with `defineCube()` / `defineStack({ analyticsCubes })`, cubes the dataset compiler mints, and cubes inferred for an ad-hoc query — and only a compiled dataset's cube reached the two readers:
+
+- **`measures.<metric>.format`** reached a caller as `fields[].format` only because the dataset door copies it from the DATASET measure. An authored cube has no dataset, so `POST /api/v1/analytics/query` described its measure columns with `name` and `type` alone. Now every measure column a query names carries the `format` its cube measure declares, whichever strategy answered, and a column that declares none carries no `format` key at all. `GET /api/v1/analytics/meta` is unchanged: its projection stays `name`, `type` and `title`, and a client reads `format` off the query result's `fields[]`, as the Data API page already says. The value is relayed verbatim; the vocabulary `fields[].format` documents is a numeral pattern such as `"$0,0.00"` or `"0.0%"`.
+- **`dimensions.<dimension>.granularities`** was the default bucket only for a compiled dataset, which the dataset executor filled in before querying. An authored cube's time dimension grouped raw timestamps whatever it declared. Now `query()` and the `generateSql()` dry run read it the same way, through the one rule both paths share: a single-entry list is the dimension's default bucket for a query that groups by it; a granularity the query states always wins, and one the list does not name is not refused (the dataset path compares against no list either); a list of two or more states no default; and a `timeDimensions` entry that carries only a `dateRange` for a dimension the query does not group stays a filter.
+
+What to expect after upgrading:
+
+- **A cube measure that declares `format`** now carries it on `POST /api/v1/analytics/query` results. A client that formats amounts from `fields[].format` starts formatting that column.
+- **A cube time dimension that declares one granularity** (`granularities: ['month']`) is now bucketed by it when a query groups by it without stating one: one row per month where there was one row per timestamp. Name another granularity in the query's `timeDimensions` to bucket differently.
+- **A cube time dimension that declares several, or none**, behaves exactly as before.
+- **Compiled datasets** (`POST /api/v1/analytics/dataset/query`) answer exactly as before: the value read off their cube is the one the dataset door already used.
+
+In `@objectstack/spec`, `MetricSchema.format` and `DimensionSchema.granularities` now carry descriptions that state what the analytics service does with them (the metric's example values move from the names "currency" / "percent" to numeral patterns, the vocabulary the `fields[].format` slot documents), and the liveness ledger rows `analytics_cube.measures.format` and `analytics_cube.dimensions.granularities` move from `dead` to `live`, citing the new readers.
@@ -0,0 +1,21 @@
+---
+'@objectstack/spec': patch
+---
+
+refactor(spec): protocol 18's conversions are authored as identifier-sorted entries with an explicit application order — no value changes (#20574)
+
+Nothing a consumer reads changes. `CONVERSIONS_BY_MAJOR[18]` (46 conversions, same
+order), `ALL_CONVERSIONS` (113, same order) and `MIGRATIONS_BY_MAJOR[18].conversionIds`
+are value-identical to the previous release, so the loader and the migration chain
+apply the same conversions in the same sequence.
+
+What changed is how the list is written, so two major-18 retirements can be in flight
+at once without conflicting in `packages/spec/src/conversions/registry.ts`:
+
+- `CONVERSIONS_BY_MAJOR[18]` is read off `MAJOR_18_CONVERSIONS`: one
+  `{ conversion, order }` entry per conversion, kept sorted by the conversion's
+  identifier and applied by ascending `order` (ties by the conversion's `id`). A
+  retirement adds ONE entry where its identifier sorts — never at the end — with
+  `order` one more than the highest present.
+- A new conversion is defined directly above the definition of the entry that follows
+  it in that list, not at the end of the definitions.
@@ -0,0 +1,15 @@
+---
+'@objectstack/service-automation': patch
+---
+
+The `http` node's designer form says an outbound credential never goes in the node's `url` or `headers`, and where it goes instead (#20590)
+
+Clause-②: no
+
+The `http` action descriptor's `configSchema` is what the flow designer's palette and property form read (`GET /api/v1/automation/actions`). It described `url` as "Target URL" and `headers` as "Request headers", with no word about credentials. Both values are stored in the flow definition, and a flow definition is served to every member who can read flows; of the node's config, only `signingSecret` is withheld. The two field descriptions now say this, and name where the credential goes instead:
+
+- a credential in a header: a `connector_action` on a declarative connector whose `auth.credentialRef` names the secret;
+- a key in the query string: a declarative `rest` connector with `api-key` auth, whose `paramName` names the parameter and whose `auth.credentialRef` names the secret;
+- a webhook whose path is the secret: a token-authenticated connector instead, such as the `slack` connector with its bot token. No `credentialRef` variant carries a secret in the url path.
+
+Description text only. No config key is added or removed, nothing more is withheld on read, and there is nothing to migrate.
@@ -0,0 +1,33 @@
+---
+'@objectstack/cli': patch
+---
+
+fix(cli): `os migrate meta --from N` prints the schema verdict and the refusals first, then the applied mechanical edits, then the manual changes
+
+Clause-②: no
+
+`os migrate meta --from N` prints every semantic entry of every protocol major the
+chain crosses, whatever the stack uses: a `--from 17` run prints 242 manual changes.
+Those used to come before the schema verdict, which was the last line of the report
+and said "resolve the manual changes above". The refusals that keep the migrated
+stack from parsing were not listed at all. The only refusal list was the one printed
+while the config loaded, and that list names the stack as authored, including the
+keys the chain goes on to convert.
+
+The human-readable report now prints three groups, each opened by one header line
+that counts it:
+
+1. the verdict: `Migrated stack is schema-valid`, or
+   `Migrated stack does not yet pass schema validation — N refusals left after the chain`
+   followed by one `✗ path: message` line per refusal of the migrated stack;
+2. `Applied N mechanical change(s):`;
+3. `N manual change(s) require your judgment:`.
+
+No manual change is dropped, merged or reworded. Every applied edit and every
+manual change prints byte for byte as before, in the same order within its group.
+The data-migration advice is still the last thing printed. A range that holds no
+migration step also leads with the verdict, which now lists the source's refusals,
+and the note naming the range to use follows it.
+
+`--json` is unchanged: same keys, same values, same array order. The exit code is
+unchanged too: a run whose migrated stack does not parse still exits 0.
@@ -0,0 +1,35 @@
+---
+'@objectstack/plugin-webhooks': patch
+'@objectstack/plugin-audit': patch
+'@objectstack/plugin-security': patch
+---
+
+fix(plugin-webhooks,plugin-audit,plugin-security): the ja-JP, es-ES and zh-CN object help, descriptions and labels that contradicted their current English source are re-translated (#20653)
+
+Clause-②: no
+
+A translated object leaf that a translator wrote by hand is kept as written
+when its English source changes later, so some leaves went on saying what the
+old source said. On a ja-JP, es-ES or zh-CN console the `sys_webhook` record
+page told an admin that `definition_json` carries the full headers / auth /
+retry / payload configuration, where the English help says credentials are not
+stored there: the signing secret and the custom headers live in the encrypted
+`signing_secret` and `headers_secret` fields.
+
+Eighteen leaves (six paths, in all three locales) whose meaning contradicted
+the current English now match it:
+
+- `@objectstack/plugin-webhooks`: the `sys_webhook.definition_json` help (no
+  credentials in the JSON) and the `sys_webhook` description (dispatched by the
+  webhook auto-enqueuer onto the shared HTTP outbox, not executed by an HTTP
+  connector plugin; declared through `defineStack({ webhooks })` too);
+- `@objectstack/plugin-audit`: the `sys_activity.environment_id` label and help
+  (Environment, not Project), and the `sys_audit_log.user_id` label (User: the
+  object's separate `actor` field is the actor);
+- `@objectstack/plugin-security`: the `sys_position` description (positions
+  distribute capability, not definitions for RBAC access control).
+
+Leaves whose English source only gained detail, was reworded, or was
+title-cased (the `@objectstack/plugin-approvals` status and action options)
+are unchanged. Values only: no key is added or removed, and no provenance
+table changes.
@@ -148,7 +148,7 @@ Type: `[string, string]`
 | **description** | `string` | optional |  |
 | **type** | `Enum<'count' \| 'sum' \| 'avg' \| 'min' \| 'max' \| 'count_distinct' \| 'number' \| 'string' \| 'boolean'>` | ✅ |  |
 | **sql** | `string` | ✅ | SQL expression or field reference |
-| **format** | `string` | optional |  |
+| **format** | `string` | optional | Display format for this measure's result column: a numeral pattern such as "$0,0.00" or "0.0%". Relayed verbatim as fields[].format on POST /analytics/query results; not published by GET /analytics/meta. |
 
 ### Nested Shape: `Cube.dimensions[string]`
 
@@ -159,7 +159,7 @@ Type: `[string, string]`
 | **description** | `string` | optional |  |
 | **type** | `Enum<'string' \| 'number' \| 'boolean' \| 'time' \| 'geo'>` | ✅ |  |
 | **sql** | `string` | ✅ | SQL expression or column reference |
-| **granularities** | `Enum<'day' \| 'week' \| 'month' \| 'quarter' \| 'year'>[]` | optional |  |
+| **granularities** | `Enum<'day' \| 'week' \| 'month' \| 'quarter' \| 'year'>[]` | optional | For a time dimension. A single interval is its default bucket: a query that groups by this dimension without stating a granularity is bucketed at it. Two or more intervals state no default. A granularity the query states always wins, listed or not. |
 
 ### Nested Shape: `Cube.joins[string]`
 
@@ -199,7 +199,7 @@ Type: `[string, string]`
 | **description** | `string` | optional |  |
 | **type** | `Enum<'string' \| 'number' \| 'boolean' \| 'time' \| 'geo'>` | ✅ |  |
 | **sql** | `string` | ✅ | SQL expression or column reference |
-| **granularities** | `Enum<'day' \| 'week' \| 'month' \| 'quarter' \| 'year'>[]` | optional |  |
+| **granularities** | `Enum<'day' \| 'week' \| 'month' \| 'quarter' \| 'year'>[]` | optional | For a time dimension. A single interval is its default bucket: a query that groups by this dimension without stating a granularity is bucketed at it. Two or more intervals state no default. A granularity the query states always wins, listed or not. |
 
 
 ---
@@ -228,7 +228,7 @@ Type: `[string, string]`
 | **description** | `string` | optional |  |
 | **type** | `Enum<'count' \| 'sum' \| 'avg' \| 'min' \| 'max' \| 'count_distinct' \| 'number' \| 'string' \| 'boolean'>` | ✅ |  |
 | **sql** | `string` | ✅ | SQL expression or field reference |
-| **format** | `string` | optional |  |
+| **format** | `string` | optional | Display format for this measure's result column: a numeral pattern such as "$0,0.00" or "0.0%". Relayed verbatim as fields[].format on POST /analytics/query results; not published by GET /analytics/meta. |
 
 
 ---
 
@@ -1014,17 +1014,27 @@ export const FanOutNotifyFlow = defineFlow({
             edges: [],
           },
           {
-            // Slack is a CONNECTOR, not a notify channel (#4343): post through
-            // an incoming webhook, or a `connector_action` with the Slack
-            // connector. The retired `script` + `actionType: 'slack'` shape
-            // logged a line and delivered nothing.
+            // Slack is a CONNECTOR, not a notify channel (#4343). The retired
+            // `script` + `actionType: 'slack'` shape logged a line and
+            // delivered nothing. A real post goes through a connector, as
+            // `TaskCompletedSlackFlow` above does. This branch stays an `http`
+            // node because it is the showcase's `parallel` + `http` fixture
+            // (docs/qa/platform-checklist/areas/automation.json).
             name: 'Post to Slack',
             nodes: [
               {
                 id: 'slack_post',
                 type: 'http',
                 label: 'Slack Notify',
                 config: {
+                  // A placeholder, and it must stay one. This url is served with
+                  // the flow definition to every member who can read flows, and
+                  // an incoming-webhook url's path IS its secret, so a real one
+                  // never goes here. A credentialed call goes through a
+                  // connector whose credential lives outside the definition:
+                  // a declarative instance's `auth.credentialRef`
+                  // (src/system/connectors/index.ts), or the `slack` connector
+                  // `TaskCompletedSlackFlow` uses.
                   url: 'https://hooks.slack.com/services/T000/B000/XXXX',
                   method: 'POST',
                   body: { channel: '#tasks', text: 'Task done: {record.title}' },