Repository navigation
Commit 1ff9944
![objectstack-fleet[bot]](https://avatars.githubusercontent.com/u/254823548?v=4&size=40){kind=avatar}
feat(cloud-connection,metadata-protocol): an unmanaged copy can take the package's sample data, owned by the installer (#31398)
domain:server#3 · os-project-manager · session_01FEkQ5pXkgNXVpCn2GZDjyy
Body: seat refresh (round 4) · 2026-11-08T08:16Z
<!-- claude-projects-attribution: {"github_login":"os-project-manager"}
-->
_Requested by **Leehom** · [project
thread](https://claude.ai/code/project/chan_01TenzsRopZj4jMbvjX8uz1X?thread=cmsg_01TenzsRopZj4jMbvjX8uz1XJZfATGni9GCmv2TJRug9bZ)_
Fixes #30808
Clause-②: yes (widening) — the install-local door accepts an optional
`seedSampleData` beside `installMode: 'unmanaged'`, and its answer may
carry `copyRecord` when the door's record of the copy was not kept; the
install-local purge door (`POST
/marketplace/install-local/:id/purge-sample-data`) now reaches an
unmanaged copy this door made, where it answered 404 for every id
without a ledger entry; and the `importUnmanagedPackage` verb takes a
door-stated `seedData`. The published
`ImportUnmanagedPackageRequestSchema` is unchanged
Metadata-protocol: none
## 维护者速读
1. 非托管安装新增可选开关 `seedSampleData`，默认关闭；关闭时行为与之前完全一致。
2. 打开后，示例数据以 `seed` 元数据项写入新的
base（即“种子回执”，存于环境元数据中），再由安装门以安装者身份一次性加载，`owner_id` 与 `created_by`
均为安装者；原包里不同角色拥有的行会合并为同一个拥有者。
3. 清除（purge）只对本安装门自己复制出的 base 生效（门在账本目录旁的 `unmanaged-copies/`
里私有记录每个副本，卸载时移除）；Studio 自建的 base 仍返回 404。记录绑定 base 实例：保存该 base 在
`sys_packages` 中那一行的 `version` 与 `created_at`，行不在或 `created_at` 不同（同 id
的后来 base）即返回 404。清除读取回执，按 `externalId` 精确删除复制的行，用户自建的行保留；base 已卸载时先答
404；记录读不到时返回 503 并指明要修复的本地文件；回执或包存储读不到时返回 503 请重试，均不删任何行。记录未能写入时，安装应答带
`copyRecord: { written: false, message }`。
遗留条件两条：没有 `package` 服务的运行时没有 base 行，记录只按 id 匹配；同一秒内卸载并以同 id 重建的 base 共享
`created_at`。
包存储的 `get` 遇到普通数据库错误（锁超时、连接断开）时记日志并返回 null，只有 seam 拒绝才抛出。因此普通错误在清除时答
404，在安装时则不写记录（`copyRecord` 会说明），两者都是失败即关闭；之后补写记录列为后续 #31425。
4. 重复安装仍返回 409；行间查找按加载顺序解析；`targetNamespace` 只改 `object` 名，记录与
`externalId` 原样保留。
5. 重启不会重新插入任何行（复制后、清除后都已用真实启动验证）；回执项单纯保存不加载任何行；发布时与任何环境 seed 项一样按
`externalId` 匹配、不重复加载；清除后再发布会按发布规则重新加载，这些行不带安装者为拥有者。
6. 无 spec
改动；前提更正：种子可携带文件字节（`files`，回执原样保留，副本上加载字节未经测试），框架本身没有记录配额；卸载前需先清除，否则行会留下；`seed`
列表读不出存储项的问题已立为 #31399。
## What changes
**The switch (`@objectstack/cloud-connection`, `POST
/marketplace/install-local`).** `seedSampleData` is accepted beside
`installMode: 'unmanaged'` and is off by default. Without it, an
unmanaged copy loads no row and answers the same `seeded: { mode:
'skipped', … }` as before. With `true`, the door loads the copy's
datasets once, inline, and answers `seeded: { mode: 'inline', inserted,
updated, skipped, errors }`. A value that is not a boolean, or one sent
with a managed install (which always loads its data), answers 400
`INVALID_REQUEST` before anything is written.
**Ownership.** Every copied row is owned by the person who installed it:
the door loads with the installer as the load's user and stamps
`owner_id` and `created_by` with that id (the #30324 option C / #30680
answer A rule). Rows the package wrote as different personas collapse to
that one owner; the copy keeps no record of the persona a row had. So
per-role answers in the customer's environment differ from the gallery's
per-persona transcripts.
**The seed receipt (`@objectstack/metadata-protocol`,
`importUnmanagedPackage`).** Asked with the door-stated `seedData: true`
(read off before the strict request parse, like `actor`), the verb
writes each `data` dataset as a `seed` item of the new base, in the
environment's own `sys_metadata`, after every other copied item:
`<object>_seed`, then `<object>_seed_2` for a second dataset of the same
object. This receipt is what the door loads from and what the purge
deletes by. Under `targetNamespace` only the dataset's `object` follows
the #30794 rename map; records and `externalId` are copied verbatim,
because the rename's free-text rewrite would otherwise reach record
values (a probe showed a record value `'crm_account'` rewritten to
`'mycrm_account'`), and a changed key would break both lookups and the
purge. A dataset that cannot be written (no `object`, no `records`
array, a name past the storage limit) is refused with 400 before any
write; a `seed` item the save door refuses rolls the whole copy back, as
every copied item does; `seed` not runtime-creatable on the target is a
finding on the key `data`. A re-run is still refused with 409.
Two receipt designs were weighed. A marker column on every seeded row
would need a schema change on every object the package seeds, and a row
the person later edits would still carry it. The receipt in the
environment ledger needs no column, survives restarts with the base, and
lets the purge run the same `externalId` match the managed purge already
uses. The receipt was chosen.
**Reading the receipt.** Each receipt item is read through the
protocol's by-name read (`getMetaItem`), scoped to the base. The list
read cannot serve it: a `seed` body declares no `name` (`SeedSchema` is
closed), and the list keys every stored item by its body's `name`, so
`getMetaItems({ type: 'seed' })` serves no stored seed item at all
(measured on the real showcase boot: 5 active rows in `sys_metadata`, 0
listed, each one served by name). On install the names come from the
import's own answer (`copied`); on purge they come from the base's
active `seed` rows in `sys_metadata`, read as the system for their names
only. An item that is not served, or is not a dataset, fails the whole
read.
**The door's record of its copies
(`packages/cloud-connection/src/marketplace-install-local-unmanaged-copies.ts`).**
Nothing a copy carries marks it as one: the base manifest holds only the
source identity plus `id`, `name` and `namespace`; `<sourceId>-copy` is
also the Studio duplicate's default id; and an unmanaged copy writes no
ledger entry. So the door records each copy it makes, with or without
sample data, as one JSON file per base under `unmanaged-copies/` in its
storage directory, beside the install ledger. The ledger reads only the
`.json` files at its own top level, so the record is never read as an
install entry. Lifetime:
- It is written in the same act as the copy, before any row is loaded. A
record that cannot be kept (its file cannot be written, or the package
store does not answer with the new base's row) leaves the copy
unreachable by the purge (404), never reachable by mistake. The install
still answers 200 and says so in `copyRecord: { written: false, message
}`, besides the log line; the answer carries no `copyRecord` when the
record was kept, so that answer's key set is unchanged. No door records
that copy later; re-recording is follow-up #31425.
- It is removed when the base is uninstalled, through a protocol
uninstall cleanup (`install-local:unmanaged-copy-record`). That
cleanup's outcome now appears in every uninstall answer's `cleanups`, `{
name: 'install-local:unmanaged-copy-record', success: true, removed: 0
}` for a package that is no recorded copy: the install-local `DELETE`,
the protocol's `deletePackage`, and `DELETE /packages/:id`
(`persisted.cleanups`, and the partial-failure 400). The shape of those
answers is unchanged; the changeset says so.
- It is lost with the ledger directory, as ledger entries are.
- A copy made before this record existed has none, and the purge does
not reach it.
**The record is tied to the base instance, not only to its id.** "This
door once copied this id" can outlive the base: a protocol without the
cleanup registry, a removal that failed, a base removed by another
replica, or an uninstall racing the record write. A later base under the
same id (a Studio duplicate also defaults to `<sourceId>-copy`) must not
inherit the purge. So the record also keeps `instance`: the `version`
and `created_at` of the base's row in the package store (`sys_packages`,
read through the `package` service's `get`). The store mints
`created_at` when it first inserts `(id, version)`, keeps it when the
same base is published again (the publish is an upsert), and an
uninstall deletes every row of the id, so a later base under the same id
gets a row of its own. The purge reads the row of the recorded version
again and answers 404 when it is gone or carries another `created_at`.
No spec key was added. The base manifest's `hash` was not used, because
it changes whenever the base is edited. Two conditions stay open, stated
in the changeset and in the module docblock:
- a runtime with no `package` service persists no base row, so its
record holds no `instance` and the purge's reach there is by id alone
(such a base does not survive a restart either);
- `created_at` is the store's `CURRENT_TIMESTAMP`, one-second
resolution, so a base uninstalled and re-created under the same id
within the same second shares it.
**A passing package-store error fails closed.** The package store's
`get` (`service-package`) catches an ordinary driver error (a lock
timeout, a dropped connection), logs it and answers `null`; it throws
only its seam-unreadable refusal (a query seam that ran no read). The
door cannot tell that `null` from a gone row. So at purge a passing
store error answers 404 and deletes nothing, and at install it leaves
the copy unrecorded, which `copyRecord` reports. Both fail closed. Only
the seam refusal reaches the purge as a 503. The store is not changed
here; re-recording an unrecorded copy is follow-up #31425.
**The purge (`POST /marketplace/install-local/:id/purge-sample-data`).**
When the install ledger has no entry for the id, the purge first asks
whether the base is still installed and writable (404 if not, before the
record is read), then whether the door's record names it and its
`instance` matches the package store's row (404 if not); every other id
keeps the 404, a Studio-authored writable base with published `seed`
items included. For a recorded copy made without the sample data it
answers 400 `NOTHING_TO_PURGE`, saying no sample data was copied.
Otherwise it reads the base's `seed` items and deletes exactly the rows
they name by `externalId`; a row the person wrote in the same object
survives. A record that cannot be read answers 503 `SERVICE_UNAVAILABLE`
naming the local record file to repair; a receipt that cannot be read,
or a package store whose query seam ran no read, answers 503 asking for
a retry, with no driver text in the answer. An ordinary package-store
error answers 404, as above. Neither deletes anything: an unread receipt
is never taken for "no sample data". The managed path is unchanged (the
shared body moved into `purgeSeedDatasets`).
**No double load.** A boot never applies the receipt: a restart after
the copy, or after the purge, inserts no row. A copied `seed` item saved
later writes metadata only, even with every row of it gone. Drafted and
published, it behaves as every environment `seed` item does:
create-only, matched by `externalId`, so the rows already loaded are
matched and none is inserted twice. Published after a purge, it loads
its rows again under the publish rule, not the installer's: the publish
names no person to the loader, so those rows carry no `owner_id` or
`created_by`.
## Tests
- `packages/metadata-protocol/src/package-unmanaged-install.test.ts`,
describe "the sample data, copied when the door asks — the seed receipt
(#30808)", 14 cases: off by default; planned after every other item,
named `<object>_seed`, records verbatim; under `targetNamespace` only
`object` renamed, records and `externalId` verbatim; `_seed_2` naming; a
dataset missing `records` or `object` answers 400 with no writes; `seed`
not runtime-creatable is a finding on `data`; the verb writes the seed
rows into the new base with no `organization_id` and the response parses
against `ImportUnmanagedPackageResponseSchema`; a refused `seed` item
rolls back the whole copy with `failedItem: { type: 'seed', name:
'crm_lead_seed' }`; a re-run answers 409 with no writes; an undeclared
key (`withSampleData`) answers 400; a dataset that carries `files` keeps
the map in the receipt verbatim; a copied `seed` item saved with every
row absent (the state after a purge) inserts nothing; drafted and
published while its rows are there it inserts none (`matched: ['a1',
'a2']`, `inserted: 0`); drafted and published after a purge it inserts
both rows with no `owner_id` or `created_by`.
-
`packages/cloud-connection/src/marketplace-install-local-install-modes.test.ts`,
describe "install-local — an unmanaged copy's sample data, asked for
with `seedSampleData` (#30808)", 17 cases, on the real
`SeedLoaderService`: off by default; asked for, 3 rows inserted,
`owner_id` and `created_by` the installer, a contact's `account` the id
of the account it names, no ledger entry and no registry package; the
purge deletes exactly 3 and keeps a user row, a second purge skips 3; a
restart after the copy and after the purge inserts nothing; a re-run
answers 409 with no new writes; a non-boolean value, or a managed
install, answers 400; an unknown id answers 404 and an unreadable
receipt answers 503 with no deletes; a Studio-authored writable base
with published `seed` items is refused at purge with 404 and nothing
deleted; a copy made before the record existed is refused with 404; the
record sits beside the ledger, never listed as an install entry, keeps
the base's `instance`, and an unreadable record answers 503 whose
message names the record file and asks for no retry; a removed base with
an unreadable record answers 404, not 503; a later base under the copy's
id (same version, another `created_at`) is refused with 404 and nothing
deleted, while the copy's seed items and rows are still there; at purge,
an ordinary store error (which the store double, like the real store,
answers `null`) answers 404, the store's seam refusal answers 503 naming
no file and carrying no store text, a gone row answers 404, and the same
row put back is reached again (3 deleted); with no `package` service the
record holds no `instance` and the purge reaches the copy by id alone
(the residual, pinned); a record that cannot be written, or a package
store that meets an ordinary error or the seam refusal at install, is
said in the install answer's `copyRecord` (no driver text) and the copy
then answers 404 at purge, while a kept record adds no key; a copy made
without the sample data answers that no sample data was copied; the
uninstall cleanup removes the record, after which the purge answers 404.
-
`packages/cloud-connection/src/marketplace-install-local-purge.test.ts`:
`seedDatasetOfReceiptItem` keeps every member `SeedSchema` declares,
`files` included, and answers `undefined` for anything that is not a
dataset. `marketplace-install-local-uninstall-meta-reads.test.ts`: its
`DELETE` answers now carry the copy-record cleanup's outcome (`removed:
0`).
-
`packages/qa/dogfood/test/install-local-unmanaged-seed-copy.dogfood.test.ts`
(new), on the real showcase with one database file across three boots:
the CRM example's copy answers 200 and loads its 28 rows inline; every
row is owned by the signed-in installer; an activity's `account`
resolves to the copied account it names; a restart inserts no row; the
purge deletes exactly the 28 and keeps a row the person wrote; a restart
after the purge inserts none back; the door's record keeps the base's
`instance` (`version`, `created_at`) and the answer carries no
`copyRecord`, and the purge in the second boot still reaches the copy,
so a restart keeps the row's `created_at`.
## Acceptance notes
- **File bytes (premise correction).** A seed can carry file bytes:
`SeedSchema` has a `files` map
(`packages/spec/src/data/seed-file.zod.ts`), and the loader mints a
`sys_file` per row from it. What is pinned: the receipt keeps a
dataset's `files` verbatim, and the door's projection hands it to the
loader. Loading those bytes on a copy is not exercised by a test here;
it goes through the same loader a managed install uses.
- **Personas.** Rows owned by different personas in the package collapse
to the installer, so per-role answers in the customer's environment
differ from the gallery's per-persona transcripts.
- **Quotas.** The framework enforces no record quota on a seed load; the
only quota-shaped setting found is `LifecycleService`'s in objectql,
which a seed load does not read. Whether a cloud deployment enforces one
on top is not verified here.
- **Uninstall.** Uninstalling the copy's base removes the receipt items
and the door's record with it, and leaves the rows. Purge before
uninstalling.
- **Residual of the instance tie.** On a runtime with no `package`
service the record holds no `instance` and the purge reaches a copy by
id alone; a base re-created under the same id within the same second
shares `created_at`. Both are stated in the changeset and the module
docblock; no spec key was invented.
- **Passing package-store errors.** An ordinary store error answers 404
at purge and leaves the copy unrecorded at install (`copyRecord` says
so); both fail closed. Re-recording is follow-up #31425.
- **Counting and reseeding.** The listing's `withSampleData` count and
the `reseed-sample-data` door read the install ledger, which an
unmanaged copy never writes, so neither covers a copy yet.
- **Walled posture.** An unmanaged install is still refused under a
walled posture; the door nonetheless loads in the caller's active
organization when a wall is on, and answers `refused` without one.
- **Out of scope: the `seed` list, filed #31399.** `GET /meta/seed` (and
`getMetaItems({ type: 'seed' })`) lists no stored `seed` item, whoever
wrote it, because the list keys items by a body `name` that `SeedSchema`
does not have. This PR works around it (reads by name) and does not
change the list.
- **Out of scope.** The comment on `data: 'door'` in
`packages/spec/src/kernel/unmanaged-install.ts` ("a copy of the metadata
cannot carry them") is now stale. It is spec text, so it is left for the
spec seat.
## Verification
**Round 4 (delta review 6719103217: S9), head `2c293d53`.**
- The door's package-store double now meets faults the way
`service-package`'s `get` does: an ordinary driver error is caught and
answered `null`, and only the seam refusal is thrown. The purge pin has
one row for each: ordinary error 404, seam refusal 503. The install pin
also has one row for each, and both answer `copyRecord` with no record
written. No production line changed this round, only docblocks and the
changeset, so there is no new ablation.
- `marketplace-install-local-install-modes.test.ts` 51 passed;
cloud-connection typecheck exit 0; eslint on the three changed files
exit 0. The changeset and engine-double gates were re-run on this head,
all exit 0: `check-changeset-no-major`, `check-empty-changeset` (and its
self-test), `check:error-code-provenance`,
`check:changeset-gate-self-tests`, `check:engine-double-contract`,
`check:error-status-conformance`.
**Round 3 (delta review 6718682580: S7, N3, N4), head `5d8c404b`.**
- **Ablations of the new pins** (`scripts/ablation-replace.mjs`, each
landed and restored to HEAD, each red):
- the `created_at` comparison → `if (!held) return null;`: the
later-base pin red;
- a gone row → `if (held && held.createdAt !== recorded.createdAt)
return null;`: the row-gone pin red;
- the `instance` in the written record → deleted: the record-content,
later-base and row-gone pins red;
- the order (record read before the base check, for an unreadable
record) → the removed-base pin red;
- the record file in the 503 → `const message = false`: the
unreadable-record pin red;
- the `copyRecord` key → `...(false`: the unkept-record pin red;
- the no-row failure at install → deleted: the unkept-record pin red.
- **Package suites:** cloud-connection 74 files, 992 passed.
metadata-protocol has no change this round. Typecheck (cloud-connection,
dogfood) exit 0. `pnpm lint packages/cloud-connection
packages/qa/dogfood` exit 0.
- **Dogfood** after a cloud-connection build:
`install-local-unmanaged-seed-copy`, `install-local-unmanaged-mode`,
`install-local-purge-sample-data`: 3 files, 35 passed. On the real boot
the record carries a `created_at` from the package store, and the boot-2
purge matches it.
- **Dispatch gates:** 83 commands, each exit captured before any pipe
and recorded as `<command> :: exit N`; `--ran`: `83 derived famil(ies)
accounted for — 83 run, 0 NOT-MEASURED (a DERIVED zero — all 83 recorded
an exit code and none of them is 3)`, all exit 0.
**Round 2 (contract review 6718084382), head `86246c5b`, origin/main
merged again (`3a0aa915` and the rest of main).**
- **Ablations of the new pins** (`scripts/ablation-replace.mjs`, each
landed and restored to HEAD):
- the record check in the purge → `const record = { entry: { seeded:
true } } as any;` (the old reach): the Studio-base pin red,
`{"success":true,"data":{"manifestId":"com.example.studio","deleted":1,…}}:
expected 200 to be 404`; the pre-record-copy pin red, `…"deleted":3…:
expected 200 to be 404`;
- the record write at install → a no-op: the copy-purge pin red, `No
marketplace install for com.example.crm-copy.: expected 404 to be 200`;
- the not-seeded answer → deleted: red, `expected 'The sample data
receipt of \'com.exam…' to contain 'No sample data was copied into
\'com.…'`;
- the uninstall cleanup's removal → `removed: 1` without removing: red,
`expected true to be false` (the record file still there);
- the unreadable-record failure → `return null`: red, `expected 404 to
be 503`.
- S2, S3 and the `files` pins hold behaviour this PR does not implement
(the save door, the publish loader, the receipt's verbatim copy), so
they have no production line of this PR to ablate.
- **Package suites:** cloud-connection 74 files, 987 passed;
metadata-protocol 326 files, 22573 passed, 26 skipped. Typecheck
(cloud-connection, metadata-protocol, dogfood) exit 0. `pnpm lint
packages/cloud-connection packages/metadata-protocol
packages/qa/dogfood` exit 0.
- **Dogfood** after a closure build on the merged tree:
`install-local-unmanaged-seed-copy`, `install-local-unmanaged-mode`,
`install-local-purge-sample-data`: 3 files, 34 passed. The real-boot
purge of the copy now goes through the door's record, and the
unmanaged-mode P1 pin "no install-ledger entry" still holds with the
record beside the ledger.
- **Dispatch gates:** 83 commands, each exit captured before any pipe;
`--ran`: `83 derived famil(ies) accounted for — 83 run, 0 NOT-MEASURED`,
all exit 0.
**Round 1, head `da697f3f`.**
- **Red on main first.** With the five production files restored to the
merge base `e2e6ec7d` and the new tests kept:
`package-unmanaged-install.test.ts -t 30808` 9 failed, 2 passed (the two
that pass guard behaviour main already has: off by default, and an
undeclared key answers 400), for example `AssertionError: expected [] to
deeply equal [ 'crm_account_seed', 'crm_lead_seed' ]` and `Error:
Invalid unmanaged install request: 1 issue — <root>
[unrecognized_keys]`; `marketplace-install-local-install-modes.test.ts
-t 30808` 5 failed, 2 passed, for example `expected 404 to be 503`; the
dogfood file 5 failed of 5 (dists rebuilt from base),
`{"mode":"skipped","reason":"an unmanaged install copies metadata, not
data: the package's sample data was not loaded"}` and `No marketplace
install for com.example.crm-copy.` Then green on head.
- **Ablations** (`scripts/ablation-replace.mjs`, each mutation landed
and the tree restored to HEAD after it):
- the `records` array check in `unmanagedSeedItems` → `if (false)`: red,
``expected 'The package\'s sample data cannot be …' to contain
'`data[0]` (object \'crm_lead\') has n…'``;
- the `seed` runtime-creatable finding → `&& false`: red, `expected
undefined to deeply equal [ ObjectContaining {"key": "data"} ]`;
- the rename skip for seed items in the verb → `if (rename ===
undefined)`: red, the copy rolled back with ``seed/acme_account_seed
failed spec validation: <root>: Unrecognized key(s) on this seed: `name`
`` (the rewrite reaches the body); the plan-level rename pin alone stays
green under this mutation, because the skip lives in the verb, so the
verb pin is the one that holds it;
- the non-boolean `seedSampleData` 400 → `if (false)`: red, `expected
200 to be 400`;
- the managed-install `seedSampleData` 400 → `if (false)`: red,
`expected 200 to be 400`;
- the purge's unread-receipt failure → `return { datasets:
receipt.datasets ?? [] }`: red, `expected 400 to be 503`;
- the installer as the load's owner → `userId: null`: red, `expected {
owner_id: undefined, …(1) } to deeply equal { owner_id: 'usr_installer',
…(1) }`.
- **Package suites:** `pnpm --filter @objectstack/metadata-protocol
--filter @objectstack/cloud-connection test` exit 0 on `5620dd94`:
metadata-protocol 326 files, 22570 passed, 26 skipped; cloud-connection
73 files, 976 passed. The cloud-connection door file was re-run on
`da697f3f` after the harness fix: 41 passed.
- **Typecheck:** `pnpm --filter @objectstack/cloud-connection --filter
@objectstack/metadata-protocol --filter @objectstack/dogfood run
typecheck` exit 0.
- **Dogfood:** `install-local-unmanaged-seed-copy`,
`install-local-unmanaged-mode` and `install-local-purge-sample-data`
together: 3 files, 34 passed, after a `@objectstack/dogfood^...` closure
build on the merged tree.
- **Lint:** `pnpm lint packages/cloud-connection
packages/metadata-protocol packages/qa/dogfood` exit 0.
- **Dispatch gates:** `node scripts/pm/dispatch-gates.mjs --commands
--repo objectstack-ai/objectstack`, each command run with its exit
captured before any pipe; `--ran`: `83 derived famil(ies) accounted for
— 83 run, 0 NOT-MEASURED`. The first pass found
`check:engine-double-contract` red (the new door harness's `update` /
`delete` did not route through `assertEngineUpdateDispatch` /
`assertEngineDeleteDispatch`); fixed in `da697f3f` with the ledger
written by `--write`, then exit 0. `check-plugin-teardown-shape
--self-test` needed its pinned fixture commit fetched on the shallow
clone, then exit 0. `check:dual-build-cjs-loads` first exited 3 (a
package without `dist/` while another build was running), then exit 0 on
rerun. The seven gates the ledger file added were run on `da697f3f`, all
exit 0.
---
_Generated by [Claude
Code](https://claude.ai/code/session_01FEkQ5pQJCx8STEq28nr3Ej)_
---------
Co-authored-by: Claude <noreply@anthropic.com>1 parent 6fcecb2 commit 1ff9944
13 files changed
Lines changed: 1743 additions & 46 deletions
File tree
- .changeset
- packages
- cloud-connection/src
- metadata-protocol/src
- qa/dogfood/test
- scripts
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
| 1 | + | |
| 2 | + | |
| 3 | + | |
| 4 | + | |
| 5 | + | |
| 6 | + | |
| 7 | + | |
| 8 | + | |
| 9 | + | |
| 10 | + | |
| 11 | + | |
| 12 | + | |
| 13 | + | |
| 14 | + | |
| 15 | + | |
| 16 | + | |
| 17 | + | |
| 18 | + | |
0 commit comments