Problem
With @unbrained/pm-cli 2026.8.1, an installed extension can register a custom item type and create an item of that type through the host-injected context.sdk.client, but core mutation commands cannot locate the resulting item. Read commands can.
Observed while real-life testing pm-rl with a registered Run type.
Reproduction
- Install an extension that registers:
api.registerItemTypes([{ name: "Run", folder: "runs", aliases: ["rl-run"] }]);
- From an extension command, create one through the injected client:
await context.sdk!.client.create({
id: "training-seed-7",
title: "training-seed-7",
type: "Run",
status: "in_progress",
});
- Reads succeed:
$ pm get e2e-training-seed-7 --path <tracker>
item:
id: e2e-training-seed-7
type: Run
status: in_progress
- Both mutation paths fail:
$ pm close e2e-training-seed-7 --reason done --path <tracker>
Error: Item ID not found
$ pm update e2e-training-seed-7 --status closed --close-reason done --path <tracker>
Error: Item ID not found
The package command calling context.sdk.client.close(id, reason) fails identically after its preceding client.get(id) succeeds.
Expected
Every store/mutation path should resolve the same active extension item-type registry as get, list, and create. close, update, notes, delete/restore, update-many, linked artifacts, and workspace transactions should all accept items located in extension-contributed folders.
Please add an installed-package E2E that creates a custom-type item and exercises the full read/mutation lifecycle. A unit test with a persisted schema type will not reproduce this because persisting the type masks the active-extension registry gap.
Problem
With
@unbrained/pm-cli2026.8.1, an installed extension can register a custom item type and create an item of that type through the host-injectedcontext.sdk.client, but core mutation commands cannot locate the resulting item. Read commands can.Observed while real-life testing
pm-rlwith a registeredRuntype.Reproduction
The package command calling
context.sdk.client.close(id, reason)fails identically after its precedingclient.get(id)succeeds.Expected
Every store/mutation path should resolve the same active extension item-type registry as
get,list, andcreate.close,update,notes, delete/restore, update-many, linked artifacts, and workspace transactions should all accept items located in extension-contributed folders.Please add an installed-package E2E that creates a custom-type item and exercises the full read/mutation lifecycle. A unit test with a persisted schema type will not reproduce this because persisting the type masks the active-extension registry gap.