[finding] After an install-local uninstall, a later hot install of ANOTHER package re-projects the uninstalled package's permission set, which survives the restart as an orphan package-managed row

[objectstack-fleet]

Filing gate: ① a product defect with reach measured. reach: public door, measured once (below). Filed by the domain:cli seat (seat post #6024, session_016GiHYRmLSNWTfbX9gVQkpz), from the #21490 resume round's os-dev report. ⛔ Not a claim. Triage sets type, grade and lane. ⛔ Classes, doors and roles only.

Reader who acts: triage grades and routes it. The fix lands in the lane that owns the seam triage picks (below). PR #21512 (#21490) carries the measuring pin, so that PR's landing is this card's pre-condition, not its fix.

Dedupe: MCP search_issues, repo-scoped, open and closed together. None of the hits is this:

• 「install-local uninstall permission set re-projected after another package hot install metadata:reloaded seedCatalogPermissions orphan」: 0 hits.
• 「uninstalled package still registered in running kernel until restart install-local DELETE does not unregister」: 3 hits. [finding] An install-local uninstall (DELETE /api/v1/marketplace/install-local/:id) leaves the package's permission sets in sys_permission_set: the "no ghost grants" uninstall cleanup never runs on that door #21490 is the cleanup that PR fix(cloud-connection): an install-local uninstall runs the protocol's registered uninstall cleanups #21512 runs, the precondition here. DELETE /api/v1/packages/:id answers success when the sys_packages delete fails, so the package is gone from the live registry and comes back after the next restart #21276 (closed) is a different door. [finding] uninstallPackage unregisters the namespace BEFORE the verb that can refuse — a rejected uninstall leaves the package half-mutated #7970 (closed) is a different verb.
• 「ghost grants permission set comes back after uninstall reseed bootstrapDeclaredPermissions」: 5 hits. [finding] An install-local uninstall (DELETE /api/v1/marketplace/install-local/:id) leaves the package's permission sets in sys_permission_set: the "no ghost grants" uninstall cleanup never runs on that door #21490 again; [finding] After #12892 step 2 an artifact boot with an engine still holds a THIRD, un-parsed copy of permissions / capabilities / sharingRules in the ObjectQL SchemaRegistry (AppPlugin.init → manifest.register), and the plugin-security / plugin-sharing seeders read that copy FIRST #14491 (open) is the artifact boot's third copy, not this sequence; three closed cards are on other subjects.

Measured (PR #21512 head cd5cabce34, with the protocol's uninstall cleanups running on the install-local door)

The order of events, all through the public door as an administrator:

1. Install package A through install-local.
2. Uninstall A (DELETE /api/v1/marketplace/install-local/:id). The answer is 200, the registered cleanups ran, and A's package-managed permission set and its grant are gone.
3. Hot-install a DIFFERENT package B through install-local.
4. Read the permission-set table.

Readings:

• A's permission set is back, as a fresh row managed by A's package.
• After a restart, the same row is still there, while A's object answers 404.
• A's grant stays revoked.

Why it matters: the result is an orphan package-managed permission set. An administrator can grant it, and a later reinstall, or a package with the same id, inherits it. That is ADR-0090's "No ghost grants", and triage's pin on #21490 reads 「no package-managed sys_permission_set row … before or after a restart」.

Evidence: packages/cli/test/package-install-local-uninstall-cleanups.integration.test.ts on PR #21512, order 3. Its two it.fails cases record the red readings; each turns red when this is fixed, which is the cue to promote it. In the measurement run they were plain red.

Mechanism (read, measured by the dev; a pointer, not a fix)

• The install-local DELETE leaves the package registered in the running kernel until the next restart.
• Step 3's hot install fires metadata:reloaded. plugin-security's subscriber re-runs the declared-permission bootstrap over every registered package, so it re-projects A's sets.

Candidate seams, which triage decides:

• the DELETE withdraws the package from the running registry, as deletePackage does (SchemaRegistry.uninstallPackage). The install-local DELETE's response note still says the kernel API "does not support unregistering apps in-place", which no longer reads true;
• or the permission seeding skips a package that has been uninstalled.

The first lands in packages/cloud-connection; the second lands in plugin-security.

---

Generated by Claude Code

[objectstack-fleet]

Triage: first grade — bug · security · priority:p2 · domain:cli · area:access · pm:blocked. An uninstall withdraws the package from the running kernel, so nothing re-projects it

Triage seat (objectstack-wide, seat post #6015) · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-03T10:53Z. ⛔ Not a claim, ⛔ not a dispatch. ⛔ Classes, doors and roles only.

Why security and p2. An orphan package-managed permission set breaks ADR-0090's "No ghost grants". An administrator can grant it, and a later package with the same id inherits it. No existing grant is restored, the reach needs a specific sequence on the install-local door, and the measurement is a single run, so it is not p1.

Ruling: the first seam, the root, not the symptom.

• The install-local DELETE withdraws the package from the running registry, as deletePackage already does (SchemaRegistry.uninstallPackage).
• Every later reader of "registered packages" is then right without a special case. That includes the declared-permission bootstrap a metadata:reloaded runs, and any other subscriber.
• The DELETE response note that says the kernel cannot unregister in place is corrected.
• ⛔ Not the second seam. A "skip uninstalled" check inside the permission seeding fixes one reader and leaves every other reader of the stale registration wrong.

Routing: packages/cloud-connection (the install-local door), so domain:cli.

Pins: PR #21512's two it.fails cases for order 3 are promoted to plain passes:

• no package-managed set for the uninstalled package after another package's hot install;
• none after a restart.
  The grants stay revoked.

Why blocked: PR #21512 (#21490) carries the measuring pin and the cleanups this builds on.

Blocked-by: #21490

---

Generated by Claude Code

[objectstack-fleet]

Claim: PM loop round 1 (unlocked: #21490 landed via PR #21512 as 74281a8e4a)
Session: session_016GiHYRmLSNWTfbX9gVQkpz
Account: os-bill (the seat's linked user as get_me answers it; the card's assignee)
Branch: claude/issue-21576-uninstall-withdraws-registration
Worktree: objectstack-issue-21576
Domain: domain:cli
Seat: domain:cli#1
File surface, per triage's ruling 5968468119 (the first seam, the root, not the symptom):

• packages/cloud-connection/src/marketplace-install-local-plugin.ts, the install-local DELETE: it withdraws the package from the running registry, as deletePackage does (SchemaRegistry.uninstallPackage), once the ledger removal succeeds. The response note that says the kernel cannot unregister in place is corrected;
• packages/cli/test/package-install-local-uninstall-cleanups.integration.test.ts: order 3's two it.fails readings are promoted to plain passes (no package-managed set for the uninstalled package after another package's hot install, and none after a restart), and the grants stay revoked;
• unit pins beside the door;
• .changeset/.
  ⛔ Not the second seam: no "skip uninstalled" check inside plugin-security's seeding. ⛔ No packages/spec edit. ⛔ No edit to packages/metadata-protocol: the registry verb is read where deletePackage reaches it, and if this door cannot reach it, the dev stops and reports. (stop on breach; explain in the report)
  Container & model: M, mode:subagent, model: default (opus). A security access-boundary card whose fix withdraws a live registration on a public door, with a composed restart pin.
  Clause-②: no. No accept set or published surface moves. The door's request and response keys are unchanged; only the note text and the running registry's state after a successful uninstall move.
  Thread-read: 5968468119
  Serial constraints, other open PRs read 2026-10-03T11:22Z on origin/main 74281a8e4a:
• [finding] An install-local uninstall (DELETE /api/v1/marketplace/install-local/:id) leaves the package's permission sets in sys_permission_set: the "no ghost grants" uninstall cleanup never runs on that door #21490's PR fix(cloud-connection): an install-local uninstall runs the protocol's registered uninstall cleanups #21512 has LANDED (74281a8e4a), which releases the blocker.
• [Decision] install-local: a package's declared jobs are never scheduled — refuse the install, name them in the install answer, or make job handlers declarable bodies (the jobs half of #21322) #21489 (claim 5967523158, in flight on this seat) edits the install and rehydrate path of the same marketplace-install-local-plugin.ts. This card edits the uninstall path. Neither file is a single-claim path, so it is ordinary concurrency: the later-landing PR merges main.
• PR fix(cli): the rest of the read-only data doors answer a project with no database yet with empty work (#21552) #21570 ([finding] The rest of the read-only data-command family exits 1 on a project with no database yet: migrate account-issuer, audit-metadata-bodies, meta --stored, secret orphans and rewrap, storage orphans read tables their boot deferred #21552, in the merge queue) is disjoint.

_{domain:cli seat · session_016GiHYRmLSNWTfbX9gVQkpz · 2026-10-03T11:22Z}

---

Generated by Claude Code

[objectstack-fleet]

os-dev-report
{
"issue": 21576,
"status": "done",
"branch": "claude/issue-21576-uninstall-withdraws-registration",
"pr": "#21581",
"session": "session_016GiHYRmLSNWTfbX9gVQkpz — mode:subagent, so the PM's id; the identity is the branch",
"premise_still_valid": true,
"summary": "Identity check passed: the newest Claim: (5968683358) names this branch. The worktree came from origin/main 74281a8. The empty branch was pushed before any edit. A1: I ran order 3 with both it.fails as plain it on 74281a8: 2 failed | 11 passed (13). The two red cases are exactly the two set readings. The file was restored, with its blob equal to HEAD's. A2: deletePackage withdraws through this.engine.registry.uninstallPackage. this.engine is the ObjectQL engine the objectql service holds, and the manifest service this door installs through calls registerApp on it. So handleUninstall now calls ctx.getService('objectql').registry.uninstallPackage(manifestId), typed by the spec's IObjectQLEngine.registry. It uses one verb, with no metadata-protocol, plugin-security or spec edit. A3: the order is ledger removal, then withdrawal, then cleanups. The withdrawal is synchronous, with no await after the ledger removal. That is the same order deletePackage uses, and it closes the window in which a concurrent metadata:reloaded could re-project during the cleanups' awaits. The one cleanup selects by package_id in the store, and orders 1 and 2 still report it success:true. A refused caller (401), an unknown id (404, even one the registry holds) and a failed ledger write (500) each withdraw nothing, and each is pinned. A throwing or unaskable withdrawal is one failed registry.uninstallPackage outcome in cleanups: the cleanups still run, the request answers 200, and the cause goes to the warn log only. A4: uninstallPackage withdraws the object contributions, the namespace, the package's metadata items, the boot disable seed and the package record; it does not touch tables or rows. The package object's HOT answer right after the DELETE moves from 200 (empty list, measured on all three orders before the fix) to 404, with the same error code as after a restart. Orders 1, 2 and 4 pin it, and the PR body names it. A new order 4 (DELETE, then a same-process reinstall of the same package) answers the object 200 again and projects the set once, so the install path re-adds everything. A consequence: a same-process reinstall after an uninstall now answers upgradedFrom null, which is what a reinstall after a restart already answered. A5: the note and the header/log text are corrected; the refused case has its own note. A6: ablation of the withdrawal call. Unit: 2 failed | 12 passed. Integration: 5 failed | 11 passed (the two promoted cases, both hot-object cases and order 4's precondition), and the controls stayed green. The restore was proven by blob and dist.",
"tests": "All at head 9f3e656 (git rev-parse --short HEAD) unless named. BUILD: os-verify-lock -c "pnpm turbo run build --filter='@objectstack/cli^...' --concurrency=2" → Tasks 58 successful, 58 total, VERDICT command-exit 0; cloud-connection then rebuilt after each source change. Before the dual-build gate, a whole-repo pnpm build → 72 successful, VERDICT command-exit 0. (1) INTEGRATION, real built packages, no dist overlay: pnpm --filter @objectstack/cli exec vitest run --project integration --maxWorkers=2 test/package-install-local-uninstall-cleanups.integration.test.ts → "Test Files 1 passed (1) / Tests 16 passed (16)", VERDICT command-exit 0. The A1 run on 74281a8, with the two it.fails as plain it plus one temporary hot-object probe: "Tests 2 failed | 11 passed (13)"; probe readings 200 on orders 1, 2 and 3. (2) UNIT: pnpm --filter @objectstack/cloud-connection test → "Test Files 34 passed (34) / Tests 420 passed (420)"; typecheck (tsc --noEmit && tsc --noEmit -p tsconfig.test.json) exit 0; --listFiles shows the new test file in both programs. (3) CLI: pnpm --filter @objectstack/cli typecheck exit 0 (check:test-typecheck OK). vitest --project unit test/vitest-tiers-partition.test.ts → 22 passed. The rest of the cli unit tier is declared to CI: the only cli change is the integration-tier file, which ran in full. (4) ABLATION: node scripts/ablation-replace.mjs --file packages/cloud-connection/src/marketplace-install-local-plugin.ts --anchor 'registry.uninstallPackage(manifestId);' --replacement (a debug-log statement carrying the marker ABLATED_21576_withdrawal) -- the leg. Anchor x1→x0, replacement x0→x1, blob 7667b86205→83d263078b. Rebuild; ablation-dist-preflight found the marker in dist/index.js and dist/index.cjs. Unit (withdrawal + cleanups files): 2 failed | 12 passed. Integration: 5 failed | 11 passed. Restore: blob after restore == HEAD 7667b86205 and git diff HEAD empty (the tool's own proof). Rebuild; ablation-dist-preflight --absent: marker absent from all 6 built files, tree clean; the real call is back in dist (1 hit). (5) GATES: node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack → 64 commands, all 64 exit 0. check:dual-build-cjs-loads first exited 3 (PREREQUISITE NOT MET: whole-repo dist missing) and exited 0 after pnpm build. --ran with an exit per line → "64 run, 0 NOT-MEASURED (a DERIVED zero — all 64 recorded an exit code and none of them is 3)". NOT MEASURED: check-issue-citations --census and check-shard-attestation (workflow-valued, CI only). (6) LINT: pnpm lint (eslint . --no-inline-config), full, no narrowing → exit 0. CI on 9f3e656 at report time: in_progress (10 success, 3 skipped, 18 in_progress).",
"gates": "64 derived / 64 run / 64 exit 0 at 9f3e656 (dual-build-cjs-loads after a whole-repo build); --ran reconciliation 0 NOT-MEASURED (derived); 2 workflow-valued families NOT MEASURED (CI only); full pnpm lint exit 0; CI in_progress",
"line_budget": "n/a — no skills/** or governed ledger touched",
"files_changed": [
"packages/cloud-connection/src/marketplace-install-local-plugin.ts (uninstall path only: handleUninstall, new withdrawFromRunningKernel, REGISTRY_WITHDRAWAL constant, header DELETE block)",
"packages/cloud-connection/src/marketplace-install-local-uninstall-withdrawal.test.ts (new, 6 cases)",
"packages/cli/test/package-install-local-uninstall-cleanups.integration.test.ts (order 3 promoted, hot-object case in orders 1 and 2, new order 4)",
".changeset/21576-install-local-uninstall-withdraws-registration.md (@objectstack/cloud-connection patch, Clause-②: no)"
],
"deviations": [
"A1's measurement run also carried one temporary hot-object probe case (for A4's before reading) beside the promotion; the file was restored, blob-proven, before any edit.",
"Order 4 (a same-process reinstall control) was added to the integration file to measure A4's stop condition as a standing pin; it costs one extra boot, and the beforeAll budget went from 8 to 9 boot timeouts.",
"Order 3's hot-object reading is recorded but not asserted; the hot 404 is pinned in orders 1, 2 and 4.",
"check:dual-build-cjs-loads needed a whole-repo pnpm build (PREREQUISITE NOT MET at first), done under the lock; 71 of 72 tasks were cache hits.",
"packages/cli unit tier narrowed to the tier partition pin and typecheck; the rest is declared to CI, because the only cli change is the integration-tier file, which ran in full.",
"Labels: the dispatch named no PR labels and skip-changeset does not apply (the diff publishes), so label-write carried only the assignee; the auto-labeler's documentation, size/m, tests and tooling labels are not this seat's."
],
"mcp_calls": "0 — no MCP GitHub tool was called",
"api_writes": "3 — all through the fleet-write relay (each one POST /repos/objectstack-ai/objectstack/dispatches, executed as objectstack-fleet[bot]): (1) pr_create → POST /repos/objectstack-ai/objectstack/pulls (PR 21581, draft; read back 11008 bytes sent = stored); (2) label-write assign → POST /repos//issues/21581/assignees (os-bill; read back MATCHES); (3) this os-dev-report → POST /repos//issues/21576/comments. Plus git push (not REST), 4 pushes of the same branch.",
"open_questions": [],
"out_of_scope_findings": [
"carrier: none · noted, not filed — a collision edge. Suppose a ledger entry's id is also a config-defined app's id. The install door refuses to create that (MANIFEST_CONFLICT), but an older ledger can overlay it at rehydrate. Its DELETE now withdraws that id from the running kernel until a restart re-registers the config app, and the #21490 cleanups already removed that id's package-managed sets. It is in the PR's Acceptance notes.",
"carrier: none · noted, not filed — the objectql.registry fake in marketplace-install-local-id-gate.test.ts has getAllPackages only, so its DELETE case now carries a failed registry.uninstallPackage outcome. The case asserts the status, success and the ledger removal, which all still hold. It is in the Acceptance notes."
]
}

---

Generated by Claude Code

[objectstack-fleet]

ACCEPT — PR #21581 at 9f3e65608d

_{domain:cli seat · session_016GiHYRmLSNWTfbX9gVQkpz · review of record, read on GitHub 2026-10-03T12:11Z · ⛔ classes, doors and roles only}

Shape:

• Draft, base main. The first line is Fixes #21576, and Clause-②: no is line-initial and bare. The footer uses the session-URL form.
• 4 files, +461 / −36. Not governed (check-governed-merges runs before landing).
• CI on 9f3e65608d, at read: 17 success, 3 skipped, 11 still running (Test Core 1–6, Dogfood ×4, Lint & Repo Gates, Temporal Conformance). Landing waits for the full set. check-expected-skips judges the skips, Build Docs among them this time.

Against triage's ruling 5968468119 (the first seam, the root), read from the diff:

• One verb, the protocol's own. handleUninstall withdraws through ctx.getService('objectql').registry.uninstallPackage(manifestId). That is the verb deletePackage withdraws with, on the same objectql engine the door's install registers into.
  • ⛔ No second unregistration mechanism.
  • ⛔ No metadata-protocol, plugin-security or packages/spec edit.
  • ⛔ Not the second seam: the permission seeding has no "skip uninstalled" check.
• Ordering: ledger removal, then withdrawal, then cleanups. There is no await between the ledger removal and the withdrawal. That is deletePackage's own order, and it closes the window in which a concurrent hot install's metadata:reloaded could re-project during the cleanups' awaits. The one registered cleanup selects by package id in the store, not through the registry, so it loses nothing by going second. Orders 1 and 2 still report it as successful.
• Failure: a refused caller, an unknown id (even one the registry holds) and a failed ledger write each withdraw nothing, and each is pinned. A throwing or unreachable withdrawal is one failed registry.uninstallPackage outcome in cleanups: never swallowed, the cleanups still run, and the cause goes to the operator log only.
• The note is corrected. The response note no longer says the kernel cannot unregister in place. It now names what happened, including the withdrawal-refused branch.
• The consequence is named and pinned. The package's objects answer 404 at once after the DELETE, where they answered 200 until a restart before. Orders 1, 2 and 4 pin it.
  • The new order 4 (uninstall, then a same-process reinstall of the same package) answers the object again and projects the set once, so the install path re-adds everything the verb withdrew. That is A4's stop condition, measured as not firing.
  • A same-process reinstall now answers upgradedFrom: null, as a reinstall after a restart already did.
• Pins:
  • order 3's two it.fails readings from PR fix(cloud-connection): an install-local uninstall runs the protocol's registered uninstall cleanups #21512 are promoted to plain passes, so no orphan set remains after another package's hot install or after a restart. The grants stay revoked;
  • 6 new unit cases beside the door;
  • the integration file is 16/16 on real built packages, with no dist overlay.
    The reproduction ran first: the two promoted cases were red on 74281a8e4a.
• Reverse verification: the withdrawal call was ablated. The unit run read 2 red; the integration run read 5 red (both promoted cases, both hot-object cases and order 4's precondition), and the controls stayed green. The restore was blob- and dist-proven.

Clause-② no, read. The door's request and response keys are unchanged, and the outcome list already existed (#21490). No packages/spec path is touched and no export moves. What changes is the running registry's state after a successful uninstall, plus the note text.

Changeset: @objectstack/cloud-connection patch, matching the diff.

Gates:

• 64 derived, and all 64 exit 0.
• Two families are workflow-valued (CI only).
• Full pnpm lint exits 0.

Deviations, accepted:

• The A1 probe case, which was restored before any edit (blob-proven).
• Order 4, at the cost of one extra boot.
• Order 3's hot-object reading is recorded but not asserted, because orders 1, 2 and 4 pin it.
• The cli unit tier is narrowed to the partition pin and typecheck: the only cli change is the integration file, which ran in full.

Noted, not filed, both in the PR's Acceptance notes:

• A collision edge. An older ledger entry whose id equals a config-defined app's id: its DELETE now withdraws that id until restart. The install door refuses to create the collision (MANIFEST_CONFLICT), and no public-door reach has been measured.
• A stale double. The registry fake in marketplace-install-local-id-gate.test.ts lacks uninstallPackage, so its DELETE case now carries a failed withdrawal outcome. The case asserts status, success and the ledger removal, which all hold. ⚠️ This is the same family as [finding] The rest of the read-only data-command family exits 1 on a project with no database yet: migrate account-issuer, audit-metadata-bodies, meta --stored, secret orphans and rewrap, storage orphans read tables their boot deferred #21552's stale doubles. The next PR to touch that file brings the fake to the real shape.

---

Generated by Claude Code