Merge main into the wait-timeout retirement branch

Resolves the protocol-18 rationale conflict in `migrations/registry.ts`:
main added the `QueryAST.fields` paragraph (#4196) and this branch added the
`wait` timeout pair (#4158). Both are kept and `conversionIds` is the union.

Ordering is load-bearing. Main's paragraph says "Like the two above it is a
request shape", which is only true while `requireAuth` and `validateOnly` are
the two that precede it — so it stays third and the incoming paragraph goes
fourth, renumbered from "The third of the same kind" to "The fourth".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: os-zhuang

.changeset/adr-0104-advertise-open-gates.md

@@ -0,0 +1,34 @@
+---
+"@objectstack/objectql": patch
+"@objectstack/cli": patch
+---
+
+feat(migrate,objectql): the upgrade path names the data migrations that are still open here (#3438, ADR-0104 2026-07-30)
+
+Both value-shape gates fail toward leniency: a deployment that never runs its
+migration keeps warning instead of rejecting, and keeps every released file
+forever. That default is right — and completely silent, so the gate could sit
+open for the life of a deployment without anyone learning that one command ends
+it. A gate nobody is told about is served by nobody.
+
+Two announcements, each where an upgrade actually looks:
+
+- **`os migrate meta --from 16`** now ends by naming the data migrations a
+  chain crossing into 17 leaves behind — `files-to-references`, `value-shapes`
+  — with what each unlocks, scoped to the field classes the author's own
+  metadata declares (an app with no media field is never told about the file
+  migration). `--json` carries the same list as `dataMigrations`. The command
+  reads no database, so it reports what remains *to do*, never what a given
+  deployment has *done*.
+- **The server logs one line per open gate at boot**, naming the command that
+  closes it. Only the lax posture announces itself — a verified gate already
+  logs that it is enforcing, and an app declaring neither class of field costs
+  nothing and says nothing. This is the half that can speak to a deployment's
+  actual data, because it is the half with the database.
+
+Nothing about enforcement changes: same gates, same flags, same fail-toward-
+leniency default. The advisory runs on `kernel:bootstrapped` rather than
+`kernel:ready`, deliberately — the answer depends on the storage service's own
+ready handler, which registers `sys_migration` and may attest a store it just
+created, and racing it would tell a brand-new deployment its gates are open
+moments after they closed.

.changeset/adr-0104-attestation-adr-note.md

@@ -0,0 +1,4 @@
+---
+---
+
+docs(adr-0104): record the fresh-datastore attestation seam as implemented — driver-reported created-vs-found table counts, not "sys_migration is missing" (which is the 16→17 trap) — and note that born-attested dogfood now exercises the #3459 collection path on every boot. Releases nothing.

.changeset/adr-0104-d2-strict-by-default.md

@@ -0,0 +1,53 @@
+---
+"@objectstack/runtime": major
+---
+
+feat(runtime)!: action params are enforced by default, and the opt-in is gone (#3438, ADR-0104 D2)
+
+A request bag that violates an action's declared `params[]` — a missing
+`required` param, a value outside its `options`, a scalar where `multiple`
+declares an array, a non-id where a `reference` declares one, or a key the
+action never declared — is now **rejected before the handler runs**:
+`400 VALIDATION_FAILED` on REST, a thrown error on MCP. It used to be logged
+and passed through.
+
+```diff
+- OS_ACTION_PARAMS_STRICT_ENABLED=1   # removed — enforcement is the default
++ OS_ALLOW_LAX_ACTION_PARAMS=1        # escape hatch: warn and pass, as before
+```
+
+**What breaks.** Only calls that were *already* wrong. The declaration was a
+complete contract that informed nothing but the client dialog, so a bag the
+server accepted could still have been silently ignored by the handler — which
+is exactly how a correctly-intended `reference: 'sys_user'` degraded into a
+paste-a-UUID box (#3405) with a success envelope on top. Those calls now fail
+loudly instead of quietly. Actions declaring no `params` are untouched, and the
+dispatcher's own `recordId` / `objectName` are allowlisted
+(`ACTION_PARAM_BUILTIN_KEYS`), so the keys dispatch itself merges in were never
+candidates for the unknown-key error.
+
+**Fixing a rejection** takes one edit at the call site: the message names the
+offending param and the declared list. If an integration you cannot reach in
+time is affected, set `OS_ALLOW_LAX_ACTION_PARAMS=1` to restore the old
+pass-through — the violation still logs once per action, so the drift stays
+visible rather than becoming invisible again.
+
+**Why 17.0 rather than a warn window in 17 and the flip in 18.** R3 asked for
+warn-then-error, and ADR-0104's 2026-07-30 addendum declined it on the merits
+rather than postponing. What a violation strands is a **caller**, not data: the
+rejection reaches a developer or an agent who can fix it in one edit, no stored
+row is made unwritable, and the escape hatch makes it reversible in a restart.
+Deferring that by a major would have charged every deployment a second upgrade
+ceremony — 16→17 is already a substantial, tested migration — to postpone a
+break that costs one edited call. v17 already carries harsher zero-window
+flips (`allowExport` unset now means denied; an undeclared action handler 404s
+with no opt-out at all), so holding the milder change to a stricter standard
+would have been inconsistent rather than cautious.
+
+For AI and MCP callers specifically — the population D2 was built for — a 400
+is corrective feedback consumed in-loop, while a server-side warning is
+feedback nobody ever reads.
+
+D1's value-shape half went the opposite way for the opposite reason: it rejects
+on the basis of **stored data**, which an author cannot edit their way out of,
+so it stays gated per deployment on that deployment's own migration evidence.

.changeset/adr-0104-d2-typed-action-handlers.md

@@ -25,12 +25,13 @@ read an untyped bag. D2 makes the declaration enforced and typed.
   required presence, per-type value shape, and unknown keys (the dispatcher's
   own `recordId` / `objectName` are allowlisted).
 
-**Warn-first rollout (ADR-0104 R3).** A violation is **logged and passes** by
-default — params that were silently wrong before keep working while the drift
-becomes visible. Set `OS_ACTION_PARAMS_STRICT_ENABLED=1` to reject with a
-`400 VALIDATION` (REST) / an error (MCP). Actions that declare no `params` are
-untouched (nothing to validate against). The flip to strict-by-default rides a
-later minor once telemetry is quiet.
+**Enforced by default.** A violation is rejected with a `400 VALIDATION_FAILED`
+(REST) / an error (MCP) before the handler runs. Actions that declare no
+`params` are untouched — there is nothing to validate against. This landed
+warn-first behind an `OS_ACTION_PARAMS_STRICT_ENABLED` opt-in during the 17.0
+RC line; that variable does **not** exist in 17.0 — see the companion entry
+"action params are enforced by default, and the opt-in is gone" for the
+reasoning and the `OS_ALLOW_LAX_ACTION_PARAMS` escape hatch.
 
 Not included: file/image params becoming `sys_file` references — that depends
 on file-as-reference (ADR-0104 D3). Per-name static typing of `ctx.params` from

.changeset/adr-0104-d3w2-pr5b-enable-collection.md

@@ -0,0 +1,36 @@
+---
+"@objectstack/service-storage": minor
+---
+
+feat(storage): released field files enter collection on deployments that verified their file migration — ADR-0104 D3 wave 2 PR-5b (#3459)
+
+The gated, final step of the file-as-reference sequence. On a deployment whose
+`adr-0104-file-references` flag is verified (`os migrate files-to-references
+--apply`, #3617), releasing a field file's ownership — clearing the field, or
+deleting the owning record — now also tombstones the file
+(`status='deleted'` + `deleted_at`), which starts the `sys_file` lifecycle's
+declared 30-day grace window and, at its end, hands the row to the reap sweep.
+Re-referencing the id inside the window revives it, exactly like re-attaching
+an attachment.
+
+**The two halves ship together, deliberately.** The same change extends the
+reap guard's sweep-time re-verify beyond `sys_attachment` join rows to the
+ownership columns: a tombstoned file whose `ref_*` columns name a current
+owner (re-claimed in the window, or a release/claim race) is un-tombstoned and
+vetoed. Tombstoning released files without that re-verify would have turned
+every release into a *guaranteed* byte delete — the guard's old check consults
+a table that is always empty for field files. This pairing was the standing
+hard constraint on #3459, locked by regression tests on both halves.
+
+**Nothing changes for a deployment that has not migrated.** Release keeps
+clearing the ownership columns only, and released files are retained forever.
+Every way of not knowing — no flag row, an unreadable table, an engine that
+cannot be asked — reads as "not verified": the gate fails closed, toward
+retention. And the guard re-reads the flag *fresh* at sweep time (not the
+release path's memoized read), so a later failing migration run — a database
+that has drifted — closes the gate for already-written tombstones too, without
+a restart. Attachments-scope collection is unchanged and needs no flag.
+
+The irreversible moment is therefore per deployment: day 30 after *that*
+deployment verified its migration and released a file — never the upgrade
+itself.

.changeset/adr-0104-d3w2-pr5b-engine-flag-read.md

@@ -0,0 +1,14 @@
+---
+"@objectstack/objectql": minor
+---
+
+feat(objectql): `engine.isFileReferencesMigrationVerified()` is public — one memoized flag read for both in-process consumers (#3459 PR-5b)
+
+The memoized per-deployment read of the `adr-0104-file-references` migration
+flag was private to the engine's media value-shape enforcement. The storage
+service's release path now asks the same question — may a released field file
+be tombstoned? — so the method is public and the release hooks reach it as an
+optional duck-typed member (an older engine or a test fake reads as "not
+verified", failing closed). One read, one invalidation
+(`invalidateDataMigrationFlags()`), no way for the two consumers to see
+different answers.

.changeset/adr-0104-fresh-datastore-attestation.md

@@ -0,0 +1,47 @@
+---
+"@objectstack/spec": minor
+"@objectstack/platform-objects": minor
+"@objectstack/objectql": minor
+"@objectstack/driver-memory": minor
+"@objectstack/driver-sql": minor
+"@objectstack/service-storage": minor
+---
+
+feat(migrate): a datastore created from empty attests its data migrations at creation (#3438, ADR-0104 2026-07-30 addendum)
+
+Deployment-level migration flags could only be recorded by running
+`os migrate`. That left a hole at the other end of a deployment's life: a
+database created on a version that already ships the migrations started **lax**
+and stayed lax until someone thought to run a command that, for them, converts
+nothing and finds nothing. Every new deployment re-entered the warn regime, so
+the warn regime would never die out — and, since #3459, every new deployment
+also kept every released file forever.
+
+A store the platform **creates from empty** now records
+`adr-0104-file-references` and `adr-0104-value-shapes` at that moment. Nothing
+to run; enforcement and collection are live from the first boot.
+
+**This is not version-gating in disguise.** The fact recorded — no legacy value
+is stored here — is *observed*: the store had no history at all. The platform
+attests only what it watched itself create, and the test is deliberately
+strict: every table made by this boot and **none found already present**. One
+pre-existing table anywhere, one datasource that was already there, one driver
+that cannot account for its schema sync — any of those and the deployment
+attests nothing and produces its evidence by scan, exactly as before. "Found
+empty" and "created empty" are not the same claim, and only the second is an
+observation.
+
+**New surfaces.** `IDataDriver.getSchemaSyncStats?()` (optional, purely
+observational: tables created vs found since connect — implemented by the SQL
+and in-memory drivers), `engine.wasDatastoreCreatedFromEmpty()`,
+`attestFreshDatastore()` in `@objectstack/platform-objects/system`, and
+`VALUE_SHAPES_MIGRATION_ID` / `CREATION_ATTESTED_MIGRATION_IDS` in
+`@objectstack/spec/system`. Attestation never overwrites an existing flag row
+and never throws into a boot: a failure leaves the deployment lax, which a
+migration run can still fix.
+
+**Upgrading changes nothing for an existing database.** It is non-empty when
+the platform reaches it, so it is never attested — run
+`os migrate files-to-references --apply` as before. Importing legacy values
+into an attested deployment is rejected loudly at the write path;
+`OS_ALLOW_LAX_MEDIA_VALUES=1` re-opens leniency while you diagnose.

.changeset/adr-0104-gate-announcement-tells-the-truth.md

@@ -0,0 +1,40 @@
+---
+"@objectstack/objectql": patch
+---
+
+fix(objectql): the boot gate announcement stops firing where it is false, and stops counting fields nothing enforces (#3438)
+
+The startup line that names an open value-shape gate (#4253) fired on every
+deployment there is, and said something untrue on any deployment that had
+already settled the question with an environment switch. Both are the same
+failure — an advisory that speaks where it does not apply is how readers learn
+to ignore it — and neither is reachable from the suite that shipped with it,
+because `engine.test.ts` mocks the registry away and a mocked registry hands
+the engine exactly the fields the test wrote.
+
+`objectHasCoveredValueField` — the dormancy short-circuit that is supposed to
+spare an object with no covered field the flag query — tested raw type
+membership, while the real registry INJECTS covered-type fields into every
+object it registers: `organization_id` and `owner_id` (both `system`),
+`created_by` and `updated_by` (both in `SKIP_FIELDS`), four `lookup`s.
+`validateRecord` skips every one of them before it reaches the value-shape
+check, so the short-circuit answered `true` for literally every object, never
+fired, and its WeakMap memoized a constant. Counting is now by the validator's
+own `isScannableValueShapeField`, the predicate the scanner already imports —
+three readings of "a covered field" drifting by one clause is how a gate ends
+up governing fields nothing enforces.
+
+The announcement also consulted no environment switch, while both postures it
+reports on short-circuit ahead of the deployment flag. Under
+`OS_DATA_VALUE_SHAPE_STRICT_ENABLED` enforcement is already on for both
+classes, so "checked but NOT enforced here" was simply false; under either
+opt-out the operator chose leniency deliberately, so naming a migration that
+cannot change what they get is noise. Each gate now consults its own pair
+(`mediaPostureSetByEnv` / `valueShapePostureSetByEnv`, siblings for the reason
+`mediaStrictEffective` and `valueShapeStrictEffective` are siblings), since the
+opt-outs are per-class while the opt-in opens both. Cheapest test first, so a
+kernel with nothing to say still reaches no flag query.
+
+Enforcement is unchanged: same gates, same flags, same default. The flag read
+was already memoized per process, so what this corrects is the property
+ADR-0104 states, not a user-visible cost.

.changeset/adr-0104-remaining-flips-evidence.md

@@ -1,4 +1,4 @@
 ---
 ---
 
-docs(adr): ADR-0104 addendum — evidence for the remaining #3438 strict flips (D1 references/structured JSON gate on a per-deployment `os migrate value-shapes` scan; fresh datastores attest both flags at creation; the D2 action-param flip rides the 18.0 major with an escape hatch) — releases nothing.
+docs(adr): ADR-0104 addendum — evidence for the remaining #3438 strict flips (D1 references/structured JSON gate on a per-deployment `os migrate value-shapes` scan, advertised on the 16→17 upgrade path; fresh datastores attest both flags at creation; D2 action params flip strict-by-default in 17.0, `OS_ACTION_PARAMS_STRICT_ENABLED` deleted before it reaches `latest`, `OS_ALLOW_LAX_ACTION_PARAMS` as the escape hatch) — releases nothing.

.changeset/adr-0104-remaining-flips-revision.md

@@ -0,0 +1,4 @@
+---
+---
+
+docs(adr): revise the ADR-0104 2026-07-30 addendum — D2 action params flip strict-by-default in 17.0 (opt-in env var deleted before it reaches `latest`, `OS_ALLOW_LAX_ACTION_PARAMS` escape hatch); D1 non-media keeps the per-deployment scan gate, now advertised on the 16→17 upgrade path — releases nothing.