Merge origin/main into claude/issue-6479-patch-path-id-wins

Author: claude

.changeset/ai-temperature-step-removal.md

@@ -0,0 +1,5 @@
+---
+'@objectstack/service-settings': patch
+---
+
+Remove `step: 0.1` from the `ai.temperature` specifier (#6550). Since #6199 a declared `step` binds as a value constraint on both doors, and temperature's true domain is continuous on [0, 2]: the 0.1 grid refused legal values — `PUT /api/settings/ai` with `temperature: 0.15` was rejected and `OS_AI_TEMPERATURE=0.15` was loudly ignored. Both now work; `min: 0` / `max: 2` stay and keep binding (out-of-window values are still refused in the min/max vocabulary). #6199's grid machinery is untouched and still enforces any key that declares `step`.

.changeset/autonumber-builder-readonly.md

@@ -0,0 +1,48 @@
+---
+"@objectstack/spec": minor
+"@objectstack/metadata-protocol": patch
+---
+
+feat(spec): `Field.autonumber` declares the field `readonly: true` (#5628)
+
+`FieldSchema.readonly` is a **two-part** contract: "never editable in forms"
+AND server-enforced on both write paths. #5503 closed the server half for
+`autonumber` **by type** — a caller-supplied record number is stripped before
+any driver sees it, flag or no flag. The form half is keyed on the **flag**, and
+`Field.autonumber` never set it. So an authoring/rendering layer that decides
+editability from `field.readonly` drew an editable "record number" input whose
+value the server was already guaranteed to discard: the user types one, the
+create succeeds, and the record comes back carrying the number the sequence
+issued instead. Data was never at risk (that half has been enforced since
+#5503/#5627); what was wrong is what the form told the user.
+
+`Field.autonumber(...)` now emits `readonly: true`. The injection is applied
+**after** the author's config, so it cannot be spread away, and the authoring
+type rejects the one config that contradicts it — `Field.autonumber({ readonly:
+false })` is a **compile error** rather than a silently coerced value, because
+an "editable record number" is not a state the runtime can deliver. Restating
+`readonly: true` stays legal. A hand-written `{ type: 'autonumber' }` literal
+(YAML/JSON metadata, or a plain object in TS) is unchanged and unaffected: it is
+covered by the by-type server enforcement, which never depended on the flag.
+
+Two consequences worth knowing:
+
+- **A flow that writes an autonumber field is now caught at `os validate`.**
+  `flow-update-readonly-field` reads the static flag, so an `update_record` node
+  writing a builder-authored record number — already a silent no-op at run time
+  — is now reported at design time instead of in server WARN logs.
+- **The historical-import exemption is unchanged**, and stays that way by
+  construction. The DataProtocol create ingress (`stripReadonlyForInsert`,
+  #3043) knows only the `isSystem` exemption, while the engine's runtime-owned
+  strip also honours `preserveAudit` (#3493 — a migration reinstating legacy
+  record numbers). Now that the field carries the flag, the ingress would have
+  deleted that value *before* the engine could keep it, so the ingress skips
+  runtime-owned field types outright and leaves them to the engine strip, which
+  runs on every insert path (including the direct `engine.insert` callers the
+  ingress never sees). Author-declared `readonly` on every other field type is
+  stripped at the ingress exactly as wide as before.
+
+The set backing "which types the runtime owns" is now declared once in the
+protocol — `RUNTIME_OWNED_FIELD_TYPES`, exported from `@objectstack/spec/data`
+— and read by both consumers (objectql's write-path strips, the DataProtocol
+ingress) instead of each carrying its own literal.

.changeset/chart-aggregate-groupby-strict.md

@@ -0,0 +1,56 @@
+---
+"@objectstack/spec": minor
+"@objectstack/lint": patch
+---
+
+feat(spec): `ChartAggregateSchema` / `ChartGroupBySchema` reject unknown keys instead of dropping them (#5583, #4001 批 15's last two sites)
+
+`<ObjectChart aggregate={{ … }}>` is the react tier's object-bound chart binding,
+and until now a key it did not declare was **silently stripped by the parse**.
+`groupby` for `groupBy` degraded the chart to a single ungrouped point, `fn` for
+`function` fell back to the default, `dateGranularty` for `dateGranularity`
+turned off date bucketing — each with `os build` / `os validate` fully green.
+That is #4001's founding failure mode, on the surface an AI page author is most
+likely to write.
+
+Both object shapes are `strictObject` now, so an undeclared key is a named
+rejection carrying the surface, the offending key and a rename:
+
+```
+Unrecognized key(s) on this chart aggregate: `groupby`.
+Did you mean `groupby` → `groupBy`? Until #5583 an undeclared aggregate key was
+dropped at parse — …
+```
+
+Curated beyond edit distance where the near-miss is semantic rather than a typo:
+`fn` / `agg` / `aggregation` → `function`, `measure` → `field`, and the ADR-0021
+dataset vocabulary an author carries over from the other binding mode
+(`dimension` / `category` → `groupBy`). Wrong-LAYER keys get a prescription
+instead of a rename — `dateGranularity` written *beside* `groupBy` did nothing at
+all and now says where it belongs; `alias`, `filter`, `objectName` and a
+`measures` array are pointed at the surface that owns them.
+
+**Why this took two issues.** `.strict()` is a property of a PARSE, and until
+#5020 nothing parsed these schemas: the react-page publish gate re-derived the
+vocabulary by hand. Closing them first would have shipped a precisely-validated
+door with nothing behind it (#4583). #5020 wired the parse; this is the posture.
+
+**The zod-4 union collapse is load-bearing here.** `groupBy` is a union, so the
+`unrecognized_keys` its strict arm raises never reaches `error.issues` — zod
+reports one `invalid_union` whose own message is the bare string `"Invalid
+input"`. What carries the named rejection to the author is `packages/lint`'s
+`describeIssue` arm unpacking, pinned end to end on both sides.
+
+**`groupBy` stays REQUIRED — the product question this pair raised is answered,
+and the answer does not move the schema.** An ungrouped single-value chart is
+not a supported `<ObjectChart>` shape: the single-value need is served by the
+separate `object-metric` block, the example corpus authors zero ungrouped
+`<ObjectChart>` aggregates, and objectui's `schema.aggregate?.groupBy ||
+schema.xAxisKey` reads are optional-chained on `aggregate` itself — they serve
+charts with **no aggregate at all**, not ungrouped ones. #5020's `warning`-level
+tolerance for an absent `groupBy` therefore stays a tolerance rather than
+becoming a blessing; its hint now states the ruling.
+
+**Upgrading:** if a chart aggregate carried a key this schema does not declare,
+it was already being ignored — the rejection names it and prescribes the fix. No
+legal declaration changes meaning.

.changeset/dashboard-date-filter-preset-vocab.md

@@ -0,0 +1,53 @@
+---
+"@objectstack/spec": minor
+---
+
+feat(spec): make the dashboard date-range preset names a single vocabulary and check a date filter's `defaultValue` against it (#4614)
+
+A dashboard's built-in `dateRange` validated its preset name and a
+`globalFilters` entry of `type: 'date'` did not, so the same typo was an
+author-time error on one surface and a silent wrong answer on the other.
+
+`GlobalFilterSchema.defaultValue` is `string | number | boolean`, which makes a
+bare preset name the only spelling available for a date filter's default —
+and nothing checked it. An unrecognised name cannot be lifted to a range, so it
+fell through to "a bare string date means equality on that day" and reached the
+backend as `created_at = 'last_7_dayz'`: a condition no row matches, answered
+`200 OK` with a zero. Every tile read `0` while the filter bar showed
+"All time", so the dashboard looked deliberately empty rather than
+misconfigured — the failure mode that costs the most time to diagnose, and the
+one an AI author reads as a correct answer and builds on.
+
+- **`DATE_RANGE_PRESETS`** (+ the `DateRangePreset` type) is new in
+  `@objectstack/spec/ui` and is now the vocabulary's single source of truth.
+  The thirteen names existed three times before this: inline in
+  `dateRange.defaultRange`, as `PRESET_RANGES` in objectui's
+  `dashboard-filters` (the module that maps each name to its date-macro
+  bounds), and as a hand-written table in the dashboard docs.
+- **`DATE_RANGE_DEFAULT_RANGES`** (+ `DateRangeDefaultRange`) is the presets
+  plus the `custom` sentinel, and is what `dateRange.defaultRange` now reads.
+  `custom` is deliberately not a preset — it names no window, it opens the
+  picker — so it stays legal there and is rejected as a bare filter default,
+  which has no `from`/`to` for it to hand over. `defaultRange`'s accepted set
+  is otherwise unchanged by the extraction, and a test asserts that member for
+  member.
+- **`GlobalFilterSchema` gained a `superRefine`**: on `type: 'date'`, a
+  declared `defaultValue` must be a preset name, an ISO date (`2026-01-15`,
+  optionally with an instant), or a known date-macro token (`{today}`,
+  `{30_days_ago}`). The macro half asks `isDateMacroToken` rather than
+  restating its grammar, so there is one token vocabulary and no second dialect
+  to drift. The rejection quotes the offending value back and lists all three
+  legal spellings, because a dashboard with several date filters otherwise
+  gives no clue which one is wrong. Every other filter type is untouched — a
+  `select` filter's values are the author's own vocabulary.
+
+**Existing metadata is unaffected.** The tree's only date-filter default is
+`system_overview.dashboard.ts`'s `last_7_days`, which is a valid preset and is
+pinned by a test; a corpus scan of the three example apps and the docs found no
+misspelled preset name, so no ADR-0087 conversion is required. The accepted set
+is a strict superset of what objectui's renderer resolves today, so no
+declaration that used to render can stop parsing.
+
+The new exports and the `.describe()` on `defaultRange` are additive; the only
+authorable behaviour that changes is that a value which previously parsed and
+then silently resolved to nothing is now an author-time error.

.changeset/doctor-ledger-dir-authority.md

@@ -0,0 +1,13 @@
+---
+"@objectstack/cli": patch
+---
+
+fix(cli): `os doctor` stops guessing the installed-package ledger directory when the authority export is missing (#5996)
+
+Hardens a diagnosis boundary; not a live defect. `DEFAULT_INSTALLED_PACKAGES_DIR` — `@objectstack/cloud-connection`'s export, the single authority on what the ledger directory is called — exists in every version ever shipped, so the consumer-side `??` fallback this change deletes had never fired. It sat two lines above the #5413 comment forbidding exactly that tolerant read (Prime Directive #12), and it answered the wrong state: a reader that LOADS without declaring the export would have doctor silently reading a hard-coded path while the runtime keeps reading wherever the package decides — two reports, potentially two directories, no line saying so.
+
+Three changes, one authority:
+
+- The `??` fallback is gone. The export is type-checked before `path.join()` ever sees it, which also retires the old misreport where a non-string export was absorbed by the config `catch` and surfaced as "Could not load config for analysis".
+- A reader that loads without declaring the directory (as a string) is now its own named report row — "The installed-package ledger reader does not declare the ledger directory (installed packages NOT checked)" — the last cell of the edge #5644 carved: that issue split "present but unloadable" out of absence's silence; this row is "loaded but unrecognizable". While it shows, doctor reads no directory at all — guessed or otherwise — and the ADR-0120 D5e advisory withholds its `✓ Unique scope` line, because its ledger half never ran.
+- `installedPackageLedgerSkippedEntriesCheck`'s fix now quotes the directory doctor actually read — resolved from the real export and carried on the reading — instead of re-hardcoding the ``Under `.objectstack/installed-packages/`:`` literal, which was the same guess in prose.

.changeset/env-door-enforces-pattern.md

@@ -0,0 +1,14 @@
+---
+'@objectstack/service-settings': patch
+---
+
+The settings env door now enforces declared `pattern` constraints (#6580). An
+`OS_*` override whose value the specifier's `pattern` rejects is loudly
+reported (`error` log, once per var+value) and ignored — the key resolves from
+the next cascade layer and is not locked — exactly the #5204 contract the
+option-table, value-window/step and valueDomain families already honor. The
+write gate's judgment is hoisted into shared helpers (`declaredPattern` /
+`firstPatternMiss`) called by both doors, so `PUT /api/settings/:ns` behavior
+is unchanged byte-for-byte (same `invalid_format` envelope, same tolerance for
+uncompilable pattern declarations) and the two doors can no longer drift.
+Family ordering agrees between doors: options → pattern → valueDomain → bounds.

.changeset/functions-array-lowered-handler.md

@@ -0,0 +1,46 @@
+---
+"@objectstack/spec": minor
+"@objectstack/runtime": patch
+---
+
+fix(spec,runtime): `functions: [{ name, handler }]` survives `objectstack build` (#6238)
+
+The array form of the top-level `functions` collection could not pass its own
+build. `lowerCallables` has lowered the array branch the whole time — it rewrites
+both `handler` and `name` to the emitted ref — but the array member of the
+`functions` union in `stack.zod.ts` still demanded `handler: z.function()`. So
+`objectstack build` produced
+`[{ name: 'syncBilling', handler: 'syncBilling', effect: 'writes' }]` and then
+rejected it, with `invalid_union: Invalid input` and a path stopping at
+`functions`: no entry named, no key named, no reason given.
+
+This is the third time the same seam has parted, and the first two fixes are why
+this one only looks small. #4343 taught the union the bare lowered ref; #4976
+taught it the lowered *declaration*. Both only ever touched the **map** member —
+the array member is a separate inline record (an array entry names itself, so it
+carries `name` and an optional `packageId` and cannot be `FlowFunctionEntrySchema`
+in a list), and widening one never widened the other.
+
+**The fix.** The array member's `handler` now accepts the lowered string ref
+beside the authored callable. One widening covers both array spellings at once,
+unlike the map form's two separate members: `effect` is already optional on an
+array entry, so the bare and the declared entry differ only in whether that key
+is present. All four cells of map/array × bare/declared now round-trip.
+
+**The load seam, which the fix made reachable.** `mergeRuntimeModule` re-attaches
+each callable from the sibling ESM module to the declaration the JSON carried.
+Its array branch fell through to a map rebuild — `existing` was `{}` whenever
+`bundle.functions` was an array — so the merged bundle came back as a bare
+`{ name: callable }` map with `effect: 'writes'` dropped on the floor. The
+function still registered and still ran, and its writes were counted as none:
+#4396's silent un-declaring arriving by the other door, and exactly the state
+that keeps #4354's broken-sweep alert quiet on the one run that needed it. Since
+the parse rejected the array form until now, no built artifact had ever reached
+that branch; it is fixed in the same change rather than shipped as a live trap.
+The array shape is preserved, callables are attached per entry `name`, and a
+module function the artifact declared no entry for still registers — the map
+branch keeps those, and the array branch must not ship fewer functions than the
+bundle was built with.
+
+Authoring is unchanged and nothing narrows: this widens what the artifact form
+accepts. The map form is still the preferred spelling.

.changeset/resume-authority-fail-closed-by-omission.md

@@ -0,0 +1,75 @@
+---
+'@objectstack/service-automation': major
+'@objectstack/spec': major
+'@objectstack/runtime': patch
+---
+
+feat(automation)!: 未声明 `resumeAuthority` 的暂停节点改为 fail-closed —— 通用 resume 路由从「默认开门」变成「显式 `'any'` 才开门」(#5561 第二步)
+
+<!-- adr-0087: registered action-descriptor-resume-authority-default-flip -->
+
+**BREAKING**(仅影响注册了暂停型节点、且描述符未声明 `resumeAuthority` 的执行器 ——
+本仓内为零)。`AutomationEngine.resolveResumeAuthority` 对缺省值的解析由 `'any'` 翻成
+`'service'`:一个从未声明「谁可以续跑它产生的暂停」的节点类型,其暂停在通用路由
+`POST /automation/:name/runs/:runId/resume` 上被拒绝(`PERMISSION_DENIED` / 403),
+直到它的描述符把话说出来。通用 resume 门从此是描述符**主动 opt-in** 的一扇门,不是每个
+暂停节点**继承**来的默认。
+
+这是 ADR-0044 2026-07-28 修正案里「记录但刻意不在此建造」的第一项,分两步落地。
+第一步(#5561 / PR #5725,非 breaking)把 `ActionDescriptorSchema.resumeAuthority`
+的 Zod `.default('any')` 摘成 `.optional()`。那个默认值的问题不只是取值不对,而是它
+**抹掉了事实**:`defineActionDescriptor` 在任何消费者看到对象之前就把 key 填上了,于是
+「作者选了 `'any'`」和「作者从没考虑过」parse 出逐字节相同的描述符,遗漏根本无法被观测。
+默认值摘掉之后「缺省」才重新可见,注册告警与 `check:resume-authority-declared` CI 门也
+才写得出来。第二步就是本次改动:让缺省真正意味着 fail-closed。
+
+### 为什么往「拒绝」这个方向猜
+
+两种猜错的代价不对称,这就是全部理由。猜 `'any'`,会让一次 resume 走过一个**没有任何
+记录的决策**,而且悄无声息 —— #3823 就是这么发生的:ADR-0044 把审批的 `revise` 边指向
+了通用 `wait`,`wait` 本身声明 `'any'` 完全正确,而站在「服务持有」位置上的那个暂停
+继承了一个没人选过的 fail-open 值;实测代价是一次未经审计的重新提交,外加一个被销毁的
+远程 run。猜 `'service'`,则是返回一次拒绝,并把修好它的那一行原样交回作者手里。
+两种错误里只有一种能被犯错的人自己发现。
+
+### 迁移:`resumeAuthority` 未声明 → 显式声明(一行)
+
+只有**注册暂停型节点的插件作者**需要动手,处方是在描述符上加一行:
+
+```ts
+// FROM —— 依赖旧默认值,暂停可被通用路由续跑
+defineActionDescriptor({
+  type: 'my_pause', version: '1.0.0', name: 'My Pause',
+  supportsPause: true,
+});
+
+// TO —— 通用路由确实是这个暂停的正门时(screen 式收集输入、signal wait 式外部生产者)
+defineActionDescriptor({
+  type: 'my_pause', version: '1.0.0', name: 'My Pause',
+  supportsPause: true, resumeAuthority: 'any',
+});
+
+// TO —— 续跑是「某个服务必须先授权并记录的决策」的尾巴时
+defineActionDescriptor({
+  type: 'my_pause', version: '1.0.0', name: 'My Pause',
+  supportsPause: true, resumeAuthority: 'service',
+});
+```
+
+两个值都被接受,**只有沉默改变了含义**。三条运行时通道会指着同一件事说话:注册时按类型
+去重的一次告警、resume 被拒时那条点名缺省字段并给出处方的错误消息,以及本仓自有执行器的
+`check:resume-authority-declared` CI 门。
+
+⚠️ `supportsPause` 本身是一个没有任何执行路径强制的声明(#5703)—— run 会暂停是因为
+`execute()` 返回了 `suspend: true`。所以一个「会暂停但把 `supportsPause` 留成 false」
+的执行器,注册告警与 CI 门**都看不见它**,只有 resume 时的拒绝消息会带上同一份处方。
+请按同一条规则手工核一遍这类执行器。
+
+### 仓内零行为变化
+
+在册的六个暂停类型全部已显式声明:`screen` / `wait` / `subflow` / `map` 声明 `'any'`
+(第一步补齐),`approval` / `approval_revise` 声明 `'service'`。解析器测试与端到端测试
+都把这份清单和它们的解析结果一起断言 —— 一个只靠「什么都没注册」而变绿的零点名,和真的
+零点名是两回事。
+
+`@objectstack/runtime` 只是注释与路由账本(`route-ledger`)的记述同步,无行为改动。