fix(metadata): revertPackage finds a code-shipped package's members by the _packageId stamp

[objectstack-fleet]

Fixes #22113

Clause-②: no

What changes

ADR-0070 D2 makes a code or installed package read-only. The two package-wide doors now refuse one with the door's existing 422 WRITABLE_PACKAGE_REQUIRED, through the same requireWritablePackage predicate that PATCH /packages/:id/disable and DELETE /packages/:id already ask. This follows triage's answer on the card: Q1 is A, Q2 is B.

• POST /api/v1/packages/:id/publish refuses a non-writable package before MetadataManager.publishPackage runs.
• POST /api/v1/packages/:id/revert refuses a non-writable package after the protocol's stored-row answer (revertStoredPackage). A stored row bound to a code package, such as an organization overlay draft, keeps the protocol's answer.
• MetadataManager.publishPackage and revertPackage find a package's members through one private helper, collectPackageMembers. It reads packageId, package and the private _packageId stamp.
  • The stamp has two producers: the artifact loader writes it through applyProtection, and the ObjectQL object bridge copies getAllObjects()'s owner tag onto every object it registers.
  • publishPackage takes the helper only because the publish door now refuses a read-only package in front of it. MetadataManager has no notion of package kind. Before the guard existed, the helper in publishPackage was measured publishing a platform package's objects (0edb299), which is why cffca05 held it back. The only in-repo caller of publishPackage is this door.

Measured at the door

These readings come from an objectstack dev --fresh boot of examples/app-showcase. Base is 51290bc; head is 434d074.

door	base	head
revert, all 26 packages GET /packages lists (com.objectstack.setup and 6 other registry-only packages, 18 platform packages that ship objects, com.example.showcase)	25 × 404 "No metadata items found"; the showcase 409 "has never been published"	26 × 422 WRITABLE_PACKAGE_REQUIRED
publish com.objectstack.setup, …platform-objects, …service.job	200, success: false, "No metadata items found"	422 WRITABLE_PACKAGE_REQUIRED
publish com.example.showcase	200, success: true, itemsPublished: 2 (writes onto two read-only capabilities)	422 WRITABLE_PACKAGE_REQUIRED
unknown id com.example.no_such_package	revert 404; publish 200, success: false	unchanged
writable package com.example.repairs (created through POST /packages, one view draft-saved and published through publish-drafts)	publish 200, success: false, "No metadata items found"; revert 200	unchanged

Overlay drafts (triage's premise for Q1), measured at both base and head. An organization overlay draft of showcase_task.grid, bound to com.example.showcase, gave the same sequence on both builds except for the first step:

1. /publish of the showcase.
   • At base it answered 200 with itemsPublished: 2, and the overlay draft was still pending afterwards. So this door never published overlay drafts.
   • At head it answers 422, and the draft is still pending.
2. /revert while the draft is pending: 409 RESOURCE_CONFLICT "Package 'com.example.showcase' has never been published, so there is no published version", the protocol's stored-row answer (packages: POST /packages/{id}/revert answers 404 "No metadata items found" for a Studio-authored package that has published items #22090).
3. /publish-drafts: 200, publishedCount: 1. The draft is gone and the overlay label serves.
4. /revert with the overlay published and no draft pending: 200.

Overlay drafts publish through publish-drafts and the per-item publish door, and neither passes the guarded branch.

Pins

• packages/runtime/src/package-revert-code-shipped-members.integration.test.ts. This uses a real ObjectQL over better-sqlite3, the real protocol, the real MetadataManager and HttpDispatcher, and the real producers of the stamp. Each refusal asserts 422 and WRITABLE_PACKAGE_REQUIRED plus the sentence's head.
  • A scope: 'system' package that ships objects: revert and publish both answer 422 (flipped from the 409 this PR first pinned), and nothing is snapshotted.
  • A scope: 'system' package the metadata service never holds, the setup shape: revert and publish both answer 422.
  • A booted package, the showcase shape, including an authored-packageId capability: publish and revert both answer 422, and the capability is not snapshotted.
  • Controls:
    • an unknown id: revert 404, publish 200 with success: false;
    • a writable package with authored packageId members: publish, edit and revert answer 200, and the snapshot is restored;
    • a writable base whose members carry only the stamp: revert 409 before a publish, then publish 200 (itemsPublished: 1), then revert 200;
    • a stored draft row bound to a booted package: revert keeps the protocol's 409.
• packages/runtime/src/package-revert-stored-members.integration.test.ts. Its two showcase (d) cases are flipped. Each now boots the showcase manifest and asserts 422 WRITABLE_PACKAGE_REQUIRED; the "published then edited" case also asserts that nothing is restored.
• packages/metadata/src/metadata-service.test.ts.
  • The revert pins hold: a stamped-only package answers 409 with the exact sentence, and membership is any of the three keys.
  • The publish pin is flipped: a stamped-only item is now a member and is snapshotted.

Verification (head 434d074)

• pnpm --filter @objectstack/metadata typecheck: exit 0.
• pnpm --filter @objectstack/metadata test: 58 files, 870 tests passed.
• pnpm --filter @objectstack/runtime typecheck, which includes check:test-typecheck: exit 0, debt ledger held at 27 files / 190 errors / 68 signatures.
• pnpm --filter @objectstack/runtime test (the local project): 334 files, 4717 passed, 19 skipped.
• Reverse verification on the committed head, each leg through scripts/ablation-replace.mjs with the restore proved by blob:
  • (A1) Without the publish guard, 3 refusal pins went red ("expected 200 to be 422").
  • (A2) Without the revert guard, 5 went red: 3 here and the 2 flipped (d) pins ("expected 409 / 404 / 200 to be 422").
  • (A3) With the revert guard moved before the protocol's stored-row answer, the stored-row control went red ("expected 422 to be 409"). The first A3 attempt was refused as a no-op, because its replacement still contained the anchor; it was re-run with a new anchor.
  • (A4) With publishPackage back on two keys (metadata rebuilt, dist preflight hit in 4 files), the flipped unit pin and the stamped writable-base door pin went red.
  • Restore leg: both files matched their HEAD blobs, git diff HEAD was empty and the tree was clean; after a rebuild the suites read 6/6 unit and 16/16 door.
• node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack (no paths) derived 64 families, and all 64 exited 0. --ran reconciliation: 64 derived, 64 run, 0 NOT-MEASURED (a derived zero). The new family since the revert-only head is check:route-envelope.
• Narrowed lint: eslint --no-inline-config --format json over the 5 touched .ts files found 5 files, 0 errors, 0 warnings. eslint.config.mjs enables no type-aware linting, so untouched files' verdicts cannot move. The full pnpm lint is CI's.

Acceptance notes

• A revert of a flat (non-envelope) published item writes metadata: publishedDefinition, a nested copy of the whole item, because publish snapshots data.metadata ?? data. It is reachable only for a writable package's flat items now. Carrier: the claimant; no card.
• MetadataManager.unregisterPackage and query({ packageId }) still match on the old keys. unregisterPackage has no production caller in this repository. Carrier: the claimant; no card.
• objectui's PackagesPage calls both doors. On a code package it now receives a 422 with a worded message instead of a 200 or a 404/409. The response shapes are unchanged, so the Console pin is not affected.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 2 package(s): @objectstack/metadata, @objectstack/runtime, touching 9 documentable anchor(s).

7 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/declarative-endpoints.mdx (via publishPackage (symbol, a method of class MetadataManager))
• content/docs/concepts/metadata-lifecycle.mdx (via MetadataManager (symbol, a top-level class))
• content/docs/kernel/cluster.mdx (via MetadataManager (symbol, a top-level class))
• content/docs/kernel/contracts/metadata-service.mdx (via publishPackage (symbol, a method of class MetadataManager), revertPackage (symbol, a method of class MetadataManager))
• content/docs/permissions/system-context.mdx (via handlePackagesRequest (symbol, a top-level function))
• content/docs/plugins/adding-a-metadata-type.mdx (via MetadataManager (symbol, a top-level class))
• content/docs/protocol/kernel/metadata-service.mdx (via MetadataManager (symbol, a top-level class))

⛔ 2 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/implementation-status.mdx (via MetadataManager (symbol, a top-level class))
• content/docs/releases/v17/17-0.mdx (via MetadataManager (symbol, a top-level class))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• the SDK route bridge reached 54 of 206 client-bound route-ledger rows — the other 152 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 152: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 97 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 36 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json ef1fcb26a24ff3842e00226186477db8f4850fbf → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 21587bd0bc0c3c876258d536a3334756bd8f0624 — the merge of head 434d0745e722e5a88d8cce92435c5edaefab842e into base ef1fcb26a24ff3842e00226186477db8f4850fbf, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 21587bd0bc0c3c876258d536a3334756bd8f0624 && git checkout 21587bd0bc0c3c876258d536a3334756bd8f0624
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin ef1fcb26a24ff3842e00226186477db8f4850fbf 434d0745e722e5a88d8cce92435c5edaefab842e && git checkout -B drift-repro ef1fcb26a24ff3842e00226186477db8f4850fbf && git merge --no-ff 434d0745e722e5a88d8cce92435c5edaefab842e

node scripts/docs-audit/affected-docs.mjs --json ef1fcb26a24ff3842e00226186477db8f4850fbf

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs ef1fcb26a24ff3842e00226186477db8f4850fbf → pass the list as
args.docs, on the commit named under Which tree this was computed on.