Merge remote-tracking branch 'origin/main' into claude/issue-5930-step2-seam-lowering

Author: claude

.changeset/20234-liveness-ledger-provenance-anchors.md

@@ -0,0 +1,14 @@
+---
+'@objectstack/spec': patch
+---
+
+The `manifest`, `dataset` and `permission` liveness ledgers cite the commit that decided each note, or say the decision in words, instead of a tracker number that no longer resolves
+
+Clause-②: no
+
+Notes in these three ledgers named GitHub issues that no longer exist, so a reader could
+not tell why a row carries its verdict. Each such note now either names the commit that
+made the decision or, where the number alone carried the meaning, says what was decided. The
+`liveness/` ledgers ship in this package's tarball, which is why this is a release note at
+all. Note text only: no row's status, evidence, proof or date changes, and no schema,
+export or runtime behaviour changes.

.changeset/20596-trigger-schedule-provenance-anchors.md

@@ -0,0 +1,10 @@
+---
+'@objectstack/trigger-schedule': patch
+---
+
+Provenance comments in `trigger-schedule` were re-anchored
+
+Comment and docblock lines under `src/` that cited tracker numbers which no
+longer resolve on GitHub now cite the commit in this repository's history that
+decided the matter, and say in their own words what was decided. Comments
+only: no type, schema, export, log or refusal text, or runtime behaviour changes.

.changeset/20648-sys-migration-flag-point-lookup.md

@@ -0,0 +1,51 @@
+---
+'@objectstack/objectql': patch
+'@objectstack/platform-objects': minor
+'@objectstack/metadata-protocol': minor
+---
+
+fix(objectql,platform-objects,metadata-protocol)!: the platform's `sys_migration` primary-key lookups go through `findOne`, so an existing deployment no longer prints "Paged read of 'sys_migration' is NOT deterministic" on every boot and every `os migrate plan` (#20648)
+
+Clause-②: no (narrowing)
+
+<!-- adr-0087: not-required (runtime-interface-only packages/platform-objects/src/system/migration-flag.ts#MigrationFlagEngine, packages/metadata-protocol/src/migrations/seed-tenancy-backfill.ts#SeedTenancyLedger) two duck-typed engine interfaces, each the parameter type of a published helper, whose one read method moves from `find` to `findOne`. Neither is a Zod schema, a `packages/spec` declaration or an object definition, neither is a projection of a schema, and no metadata surface references either, so `objectstack migrate meta` has nothing to rewrite. The body carries no migration prescription. The only party affected is the TypeScript author of a hand-written stand-in, and that author's fix is carried by the compiler at their own call site, which names the missing `findOne`. The other categories are closed on facts: both packages publish (not `unpublished`); no ADR-0087 id covers an engine interface's method set, and this diff adds none (not `registered` / `already-registered`); and both interfaces were concretely typed at the merge base, not erased (not `type-surface-only`). This category, not the broader `no-migration-prescription`, because the positive reading it verifies is available here: the named symbols have no metadata surface. -->
+
+The deployment ledger is read one row at a time, by primary key. Five readers
+spelled that read as `find(sys_migration, { where: { id }, limit: 1 })`: the
+engine's migration-gate read (`readMigrationFlagVerified`, behind
+`haveFileColumnsMoved`, `isFileReferencesMigrationVerified` and
+`isValueShapesMigrationVerified`), the engine's deviation marker and
+creation-attestation revocation, `readDataMigrationFlag` in
+`@objectstack/platform-objects/system`, and the seed-tenancy repair's receipt.
+The SQL driver cannot tell that read from page one of a walk. The engine's gate
+read runs at boot before the schema pass registers `sys_migration` with the
+driver, and on a table the driver has not registered an unsorted paged read
+warns that its pages may repeat or skip rows. Measured on a SQLite database
+created by 17.4.0: every 17.5.0 boot and every `os migrate plan` printed that
+warning once, for a lookup that cannot return two rows. All five readers now use
+`findOne`, the single-row route the driver already exempts. The driver's check is
+unchanged: an unsorted `limit` read on a table the driver did not create still
+warns.
+
+**BREAKING**: this narrows what two published engine interfaces accept. The
+first is `MigrationFlagEngine` in `@objectstack/platform-objects/system`. It is
+the parameter type of `readDataMigrationFlag`, `isDataMigrationVerified`,
+`mayActIrreversibly`, `recordDataMigrationRun`, `recordFileColumnMove` and
+`attestFreshDatastore`, and part of `FilesToReferencesEngine` in
+`@objectstack/service-storage`. The second is `SeedTenancyLedger` in
+`@objectstack/metadata-protocol`, the type of a `SeedTenancySeam`'s `ledger`.
+Each now requires `findOne` where it required `find`, so a hand-written stand-in
+that provides only `find` no longer satisfies either type. It ships as `minor`
+under the launch-window convention for accept-set narrowings. The ObjectQL engine
+has both methods, so a host that passes the engine needs no change.
+
+**Your fix:** a stand-in that implemented `find` for these helpers implements
+`findOne(object, options)` instead, answering the row whose `where.id` matches,
+or `null`.
+
+At run time, a stand-in that still provides only `find` fails the read.
+`readDataMigrationFlag` then answers `null`, the same answer as a missing row, so
+the gates it feeds stay closed. `resolveSeedTenancySeam` now attaches a `ledger`
+only for a host that has `getObject`, `findOne`, `insert` and `update`. For a
+find-only host the seam's `ledger` is `undefined`, and when the seed-tenancy
+repair applies, it says at `warn` that it could not record its receipt.

.changeset/20731-metadata-protocol-packaged-view-base.md

@@ -0,0 +1,13 @@
+---
+'@objectstack/metadata-protocol': minor
+---
+
+fix(metadata-protocol): `getPackagedViewBase(name)` answers the view a code package ships, before any overlay (#20731)
+
+`ObjectStackProtocolImplementation` gains `getPackagedViewBase(name)`, the view twin of `getPackagedDashboardBase`. It returns the packaged (code-layer) declaration of a view, which is the `packagedBase` that `translateView` compares a served view against, so that a tenant's published overlay is not overwritten by the packaged translation catalog.
+
+`name` is the view's registry identity, the qualified `<object>.<viewKey>` that each view of a `defineView` container is registered under and that the overlay row and both reads carry. The bare view key that the catalog uses under its object is not an identity (another object may ship a view with the same key), and it answers `undefined`.
+
+It reads the artifact registry's code-package entry only, through the same lookup as `getPackagedDashboardBase`. An overlay that was hydrated under the plain registry key can therefore never be returned as the base it is compared against. It returns `undefined` for a view that no code package ships, for an unknown or empty name, and for a registry that cannot answer. A caller treats `undefined` as "no base known", and the catalog applies as before.
+
+The method is additive. No existing read changes answer, and `getPackagedDashboardBase` answers exactly as before. Nothing is removed or renamed.

.changeset/20731-spec-view-catalog-override.md

@@ -0,0 +1,19 @@
+---
+'@objectstack/spec': minor
+---
+
+fix(spec): `translateView` lets an explicit override beat the packaged catalog when it is handed the packaged view (#20731)
+
+`translateView` (`@objectstack/spec/system`) now follows the rule ADR-0029 D9.2a records for objects, and that `translateDashboard` already follows: an explicit override beats a packaged default. When the caller supplies `packagedBase` (the view as its code package ships it, before any tenant overlay), a catalog string replaces a served string only while that string still equals its packaged counterpart. It is the same comparison, not a second one.
+
+The comparison is made per string: the view `label` and `description`, each bulk-action def's `label`, `confirmText` and `confirmLabel`, and each of its params' `label`, `help` and `placeholder`. A def or param is matched by the `name` the bundle addresses it by, and one that the packaged view does not carry counts as authored, so its strings keep their values.
+
+Why: an org overlay on a packaged view (ADR-0126 Regime O) changed the label of the showcase's `showcase_task.in_progress` and published. The metadata protocol's item and list reads served the edit, but a `zh-CN` reader was served `进行中`, the catalog's translation of the label the package shipped. The catalog (`objects.<object>._views.<viewKey>`) translated the packaged view and was applied over the tenant's edit.
+
+What changes for a caller:
+
+- `translateView`'s third parameter is typed `TranslateDocumentOptions` (was `ResolveOptions`). That type is `ResolveOptions` plus the optional `packagedBase`, and `translateMetadataDocument` already passed it through. Every existing call compiles unchanged.
+- Without `packagedBase` (`undefined` or `null`), the output is byte-identical to before: the catalog applies. No serving layer in this release passes a view base yet, so no served view changes answer with this package alone.
+- An edit back to exactly the shipped string is a no-op: the catalog still translates it. A label written as an inline locale map is not an override either; only a string is compared.
+
+Nothing is removed or renamed, and there is nothing to migrate.