@unbrained/pm-cli 2026.6.22 → 2026.6.23

package/docs/EXTENSIONS.md

@@ -87,7 +87,7 @@ Package roots declare resources in `package.json` under `pm`:
 
 Installation activates `pm.extensions`. `pm.docs`, `pm.examples`, `pm.assets`, and `pm.prompts` are catalog metadata (metadata-only — they are discovered and surfaced in the catalog but not executed). Declare agent-facing prompt/slash-command markdown under `pm.prompts` and non-code assets (images, skills, fixtures) under `pm.assets`; their conventional roots are `prompts/` (also `.agents/pm/prompts/`) and `assets/` (also `.agents/pm/assets/`).
 
-`pm package init` emits a root extension (`"extensions": ["."]`) so local package installs can activate without dependency bootstrapping. The default `--capability commands` scaffold registers a starter command and a colocated `node:test` suite. `--capability hooks` keeps the starter command and adds an `after_command` lifecycle hook plus SDK testing coverage with `assertRegisteredHook` and `runRegisteredHookForTest`, giving package authors a runnable template for reacting to pm mutations when project management is context management. `--capability search` keeps the starter command and adds a deterministic search provider/vector-store adapter pair plus SDK tests with `assertRegisteredSearchProvider`, `assertRegisteredVectorStoreAdapter`, `runRegisteredSearchProviderForTest`, and `runRegisteredVectorStoreAdapterForTest`, giving retrieval packages a copyable context-management primitive without external services. `--capability importers` keeps the starter command and adds paired import/export command registrations plus SDK tests with `assertRegisteredImporter`, `assertRegisteredExporter`, `runRegisteredImporterForTest`, and `runRegisteredExporterForTest`, giving integration packages a copyable context-movement primitive for synchronizing external project systems; the generated manifest declares both `importers` and `schema` because the starter includes schema-governed flag metadata. Starter manifests use the same least-privilege policy metadata as pure first-party command packages: `trusted: true`, `sandbox_profile: "strict"`, and explicit `false` permissions for `fs_read`, `fs_write`, `network`, `env_read`, `env_write`, and `process_spawn`. Larger packages may point at nested extension directories after declaring runtime dependencies, relaxing only the permissions they actually need, and validating with `pm package doctor`.
+`pm package init` emits a root extension (`"extensions": ["."]`) so local package installs can activate without dependency bootstrapping. The generated entrypoint stays import-free for that first local install, while the generated package README shows how to graduate exported command/hook definitions to the SDK [define* builders](../.agents/pm/decisions/pm-3mph.toon) after `npm install` materializes the peer SDK. The default `--capability commands` scaffold registers a starter command and a colocated `node:test` suite. `--capability hooks` keeps the starter command and adds an `after_command` lifecycle hook plus SDK testing coverage with `assertRegisteredHook` and `runRegisteredHookForTest`, giving package authors a runnable template for reacting to pm mutations when project management is context management. `--capability search` keeps the starter command and adds a deterministic search provider/vector-store adapter pair plus SDK tests with `assertRegisteredSearchProvider`, `assertRegisteredVectorStoreAdapter`, `runRegisteredSearchProviderForTest`, and `runRegisteredVectorStoreAdapterForTest`, giving retrieval packages a copyable context-management primitive without external services. `--capability importers` keeps the starter command and adds paired import/export command registrations plus SDK tests with `assertRegisteredImporter`, `assertRegisteredExporter`, `runRegisteredImporterForTest`, and `runRegisteredExporterForTest`, giving integration packages a copyable context-movement primitive for synchronizing external project systems; the generated manifest declares both `importers` and `schema` because the starter includes schema-governed flag metadata. Starter manifests use the same least-privilege policy metadata as pure first-party command packages: `trusted: true`, `sandbox_profile: "strict"`, and explicit `false` permissions for `fs_read`, `fs_write`, `network`, `env_read`, `env_write`, and `process_spawn`. Larger packages may point at nested extension directories after declaring runtime dependencies, relaxing only the permissions they actually need, and validating with `pm package doctor`.
 
 Package tests can pair `readPmPackageManifest(packageRoot)` with
 `assertPackageManifest(manifest, { resources: ... })` from
@@ -334,11 +334,12 @@ surface guarantees.
 
 ## Lifecycle Commands
 
-Explore installed runtime entries:
+Explore installed runtime entries, or describe exactly what each loaded package registers (commands, hooks, item types, providers, overrides) as a by-name surface map:
 
 ```bash
 pm package explore --project
-pm package explore --project --json
+pm package describe --project          # every loaded package
+pm package describe my-extension       # one package's surface map
 ```
 
 Run diagnostics:
@@ -416,12 +417,14 @@ Third-party packages should import only stable public SDK subpaths:
 
 ```js
 import { defineExtension, createPmCliExpectedError } from "@unbrained/pm-cli/sdk";
-import { activateExtensionForTest, assertRegisteredCommandContract } from "@unbrained/pm-cli/sdk/testing";
+import { createExtensionTestHarness, activateExtensionForTest } from "@unbrained/pm-cli/sdk/testing";
 ```
 
 Use `createPmCliExpectedError(message, { exitCode, context })` for expected user/action failures from package commands. It creates an `Error` named `PmCliError` with a structural `exitCode`, so separately installed package code still gets expected-error handling and Sentry filtering.
 
-Use `activateExtensionForTest(module)` in package unit tests when you need an `activation.registrations` or `activation.hooks` object for assertion helpers. Then `runRegisteredCommandForTest(activation.commands, { command })` invokes a registered command handler through pm's real dispatch engine to assert behavior, not just wiring; the matching `runRegisteredHookForTest` (lifecycle hooks), `runRegistered{Parser,Preflight,Command,Renderer,Service}OverrideForTest` (override surfaces), and `runRegistered{SearchProvider,VectorStoreAdapter,Migration,Importer,Exporter}ForTest` (executable registrations — the importer/exporter helpers take the whole `activation` and resolve by name, deriving the command path internally) helpers extend that invoke verb to every other runtime surface. Keep `pm package doctor --project --detail deep --trace` and runtime contracts for integration tests against installed packages.
+Prefer the `define*` builders for exported registration definitions (`defineCommand`, `defineFlag`, `defineSearchProvider`, `defineAfterCommandHook`, and the matching override/import/export/hook helpers; see ADR [pm-3mph](../.agents/pm/decisions/pm-3mph.toon)). They are zero-cost identity functions that preserve object literal types and contextually type function parameters before the definitions reach `api.register*`; runtime validation remains in the loader, and behavior validation remains in `sdk/testing`.
+
+Prefer `createExtensionTestHarness(module, { capabilities })` in package unit tests: it activates the module once and returns a fluent fixture whose `assert*`/`run*` methods are already bound to the right activation sub-registry (so you never thread `activation.registrations` vs `activation.commands` vs `activation.hooks` by hand), plus a `deactivate()` that runs the real teardown engine — e.g. `harness.assertCommandContract({ command })`, `await harness.runCommand({ command })`, `await harness.deactivate()`. The methods do not use `this`, so they are safe to destructure. For finer control, the standalone helpers remain public: `activateExtensionForTest(module)` returns the raw `activation`, then `runRegisteredCommandForTest(activation.commands, { command })` invokes a registered command handler through pm's real dispatch engine to assert behavior, not just wiring; the matching `runRegisteredHookForTest` (lifecycle hooks), `runRegistered{Parser,Preflight,Command,Renderer,Service}OverrideForTest` (override surfaces), and `runRegistered{SearchProvider,VectorStoreAdapter,Migration,Importer,Exporter}ForTest` (executable registrations — the importer/exporter helpers take the whole `activation` and resolve by name, deriving the command path internally) helpers extend that invoke verb to every other runtime surface. Keep `pm package doctor --project --detail deep --trace` and runtime contracts for integration tests against installed packages.
 
 `PM_CLI_PACKAGE_ROOT` is first-party only. Bundled packages in this repository use it to find the running CLI's `dist/sdk/runtime.js` before they are published or installed independently. External packages must not read this environment variable or import from `dist/` or `src/core`; use `@unbrained/pm-cli/sdk`, `@unbrained/pm-cli/sdk/runtime`, and `@unbrained/pm-cli/sdk/testing`. During `pm install npm:<package>`, pm links the installed package's `@unbrained/pm-cli` dependency back to the running host CLI so SDK imports resolve without a duplicate nested CLI install.
 

package/docs/SDK.md

@@ -36,6 +36,8 @@ Source of truth:
 Common authoring exports:
 
 - `defineExtension`
+- `composeExtension` / `deriveExtensionCapabilities`
+- `describeExtensionBlueprint` (static surface map of a blueprint) / `lintExtensionBlueprint` (author-time preflight)
 - `EXTENSION_CAPABILITIES`
 - `EXTENSION_CAPABILITY_CONTRACT`
 - `EXTENSION_CAPABILITY_CONTRACT_VERSION`
@@ -48,6 +50,14 @@ Common authoring exports:
 - `createPmCliExpectedError`
 - `isPmCliExpectedError`
 
+Registration builders (`define*`, zero-cost identity — see [Authoring Builders](#authoring-builders)):
+
+- `defineCommand` / `defineFlag` / `defineItemType` / `defineItemField` / `defineMigration`
+- `defineSearchProvider` / `defineVectorStoreAdapter`
+- `defineCommandOverride` / `defineParserOverride` / `definePreflightOverride` / `defineServiceOverride` / `defineRendererOverride`
+- `defineImporter` / `defineExporter`
+- `defineBeforeCommandHook` / `defineAfterCommandHook` / `defineOnWriteHook` / `defineOnReadHook` / `defineOnIndexHook`
+
 Package manifest exports:
 
 - `PM_PACKAGE_RESOURCE_KINDS` (`extensions`, `docs`, `examples`, `assets`, `prompts`)
@@ -73,6 +83,7 @@ Command/action contract exports:
 
 Testing helper exports (also under `@unbrained/pm-cli/sdk/testing`):
 
+- `createExtensionTestHarness`
 - `activateExtensionForTest`
 - `deactivateExtensionForTest`
 - `runRegisteredCommandForTest`
@@ -105,6 +116,23 @@ Testing helper exports (also under `@unbrained/pm-cli/sdk/testing`):
 - `assertRegisteredServiceOverride`
 - `assertRegisteredMigration`
 - `assertExtensionCapabilityUsage`
+- `assertExtensionBlueprint` (throwing preflight; pairs with `lintExtensionBlueprint`)
+- `describeExtensionActivation`
+- `describeExtensionBlueprint` / `lintExtensionBlueprint` (also surfaced here for the full author → describe → preflight → test loop)
+
+`createExtensionTestHarness(module, options)` is the recommended entry point and
+the ergonomic capstone over every standalone helper below: it activates the
+module once and returns a fluent `ExtensionTestHarness` whose `assert*`/`run*`
+methods are pre-bound to the correct activation sub-registry, so a package author
+never threads `activation.registrations` vs `activation.commands` vs
+`activation.hooks` (etc.) by hand — picking the wrong one is a common footgun that
+surfaces as a confusing `available: (none)` error. Write
+`const ext = await createExtensionTestHarness(module, { capabilities: ["commands"] })`,
+then `ext.assertCommandContract({ command })`, `await ext.runCommand({ command })`,
+and `await ext.deactivate()`. The methods do not use `this`, so they remain safe
+to destructure (`const { runCommand } = ext;`), and the raw `ext.activation`
+stays public as an escape hatch to the standalone helpers for any surface a
+convenience method does not cover.
 
 `assertExtensionCapabilityUsage(activation, { declared })` is the least-privilege
 counterpart of the per-surface `assertRegistered*` helpers: pass the same
@@ -208,6 +236,51 @@ importer / exporter is registered (and, for providers and adapters, implements t
 requested operation), so a typo surfaces as a descriptive error rather than a
 silent no-op. All invoke helpers are `async`, so a test always `await`s them.
 
+`describeExtensionActivation(activation, { extensionName })` is the **describe**
+(enumerate-all) verb that complements the `assertRegistered*` (verify-one) and
+`runRegistered*ForTest` (invoke-one) helpers. The activation result already
+carries per-surface *counts*; this returns the *names*. It walks every
+sub-registry once and returns a flat `ExtensionActivationSummary` whose arrays
+are de-duplicated and locale-sorted (except `hooks`, emitted in canonical
+lifecycle order to mirror `hook_counts`) of every registered surface's
+identifiers — command paths, hook kinds, item-type /
+field names, migration ids, importer / exporter / provider / adapter names,
+overridden service names and renderer formats, flag target-commands, and the
+preflight-override count — plus the `capabilities` those surfaces exercise. Two
+uses:
+
+```ts
+import { describeExtensionActivation } from "@unbrained/pm-cli/sdk/testing";
+
+const summary = describeExtensionActivation(activation);
+// Least-privilege check: assert the WHOLE registration surface in one deepEqual.
+assert.deepEqual(summary.commands, ["greet hello"]);
+assert.deepEqual(summary.hooks, ["after_command"]);
+assert.deepEqual(summary.capabilities, ["commands", "hooks"]);
+```
+
+Without `extensionName` the summary unions every extension in the activation;
+with it (matched case-insensitively after trimming, like
+`collectUsedExtensionCapabilities`) only that extension's registrations
+contribute. The three command fields capture distinct dimensions and can
+overlap: `commands` lists definitions declared via `registerCommand(definition)`,
+`command_handlers` lists every command path backed by an extension handler (a
+superset that also includes the synthesized `"<name> import"` / `"<name> export"`
+importer/exporter paths), and `command_overrides` lists built-in commands
+replaced via `registerCommand(name, override)`. For agents, one call returns the
+entire surface instead of traversing fifteen-plus sub-registries — keeping the context
+window lean ("project management = context management").
+
+The same verb is reachable from the CLI and MCP without writing a test:
+`pm extension describe [name]` / `pm package describe [name]` (and `pm_run` with
+`action: "extension"`/`"package"` and `describe: true`) activate the workspace's
+extensions and return each loaded extension's `ExtensionActivationSummary` under
+`details.extensions[].surfaces`, plus a deduplicated `details.union`. Omit the name
+to map every loaded package; pass one to scope to it. This is the agent-facing answer
+to "what does this installed package add to my context?" — distinct from
+`pm package doctor` (errors/policy) and `pm package manage` (update metadata), which
+report only command/action paths, not the full registration surface.
+
 Commander option contract exports:
 
 - `CREATE_COMMANDER_OPTION_REGISTRATION_CONTRACTS`
@@ -243,6 +316,7 @@ the registration surfaces a package actually exercises at activation):
 Common types:
 
 - `ExtensionApi`
+- `ExtensionActivationSummary`
 - `ExtensionManifest`
 - `ExtensionManifestEngines`
 - `CommandDefinition`
@@ -320,26 +394,18 @@ assertPackageManifest(manifest, {
 ```
 
 Package tests can also assert extension registrations without importing private
-loader internals. Use `activateExtensionForTest` plus the targeted assertion for
-the surface your package owns:
+loader internals. Prefer `createExtensionTestHarness` — its `assert*`/`run*`
+methods bind to the right sub-registry for you:
 
 ```ts
-import {
-  activateExtensionForTest,
-  assertRegisteredCommandContract,
-  assertRegisteredFlags,
-} from "@unbrained/pm-cli/sdk/testing";
+import { createExtensionTestHarness } from "@unbrained/pm-cli/sdk/testing";
 
-const activation = await activateExtensionForTest(extensionModule);
+const ext = await createExtensionTestHarness(extensionModule, { capabilities: ["commands", "schema"] });
 
-assertRegisteredCommandContract(activation.registrations, {
-  command: "incident triage",
-  flags: ["--severity"],
-});
-assertRegisteredFlags(activation.registrations, {
-  targetCommand: "list",
-  flags: ["--incident-filter"],
-});
+ext.assertCommandContract({ command: "incident triage", flags: ["--severity"] });
+ext.assertFlags({ targetCommand: "list", flags: ["--incident-filter"] });
+const { result } = await ext.runCommand({ command: "incident triage", options: { severity: "high" } });
+await ext.deactivate();
 ```
 
 For provider-safe schemas, use `PM_PROVIDER_TOOL_PARAMETERS_SCHEMA`. It is flat and avoids advanced schema constructs such as root `oneOf`.
@@ -560,6 +626,153 @@ import { createPmCliExpectedError } from "@unbrained/pm-cli/sdk/runtime";
 
 `PM_CLI_PACKAGE_ROOT` is reserved for first-party packages bundled inside this repository. Those packages use it to locate the running CLI's `dist/sdk/runtime.js` before they are installed as independent npm packages. External packages must not depend on `PM_CLI_PACKAGE_ROOT`, `dist/` paths, or `src/core/...`; declare `@unbrained/pm-cli` as a dependency or peer dependency and import the public SDK subpaths instead. When pm installs a registry package, it links that dependency to the running host CLI so the package gets the active SDK without downloading a second CLI copy into the project.
 
+## Authoring Builders
+
+Tracked: [pm-12tj](../.agents/pm/features/pm-12tj.toon) (design rationale: ADR [pm-3mph](../.agents/pm/decisions/pm-3mph.toon)).
+
+The `define*` builders are the authoring half of the `author → register → test`
+loop: they type a registration definition where you write it, before it ever
+reaches `api.register*`. Each is a zero-cost identity function (it returns its
+argument unchanged), exactly like `defineExtension` and the wider
+`defineConfig`/`defineComponent` ecosystem convention — the value is entirely at
+the type level.
+
+This matters most in **plain-JavaScript packages** (the default `pm package init`
+scaffold). A bare `const cmd = { ... }` is unchecked because JS has no type
+annotations; wrapping it in a builder restores full contract checking and infers
+the nested handler's `context` parameter through the editor's TypeScript language
+service. It also lets you colocate, export, reuse, and unit-test a definition
+apart from `activate`:
+
+```js
+import { defineCommand, defineAfterCommandHook } from "@unbrained/pm-cli/sdk";
+
+// `context` is inferred even though this is a .js file with no annotations.
+export const greetCommand = defineCommand({
+  name: "greet hello",
+  action: "greet-hello",
+  description: "Say hello.",
+  run: (context) => ({ greeting: `hi ${context.args[0] ?? "world"}` }),
+});
+
+export const auditHook = defineAfterCommandHook((context) => {
+  if (!context.ok) return;
+  // react to context.affected — "project management = context management"
+});
+
+export function activate(api) {
+  api.registerCommand(greetCommand);
+  api.hooks.afterCommand(auditHook);
+}
+```
+
+Object-definition builders (`defineExtensionManifest`, `defineCommand`,
+`defineFlag`, `defineItemType`, `defineItemField`, `defineMigration`,
+`defineSearchProvider`, `defineVectorStoreAdapter`) preserve the narrow literal
+type. `defineExtensionManifest` additionally contract-checks the in-module
+manifest mirror where it is authored and pairs with `deriveExtensionCapabilities`
+(see [Declarative Authoring](#declarative-authoring)). Function-definition
+builders (`defineCommandOverride`, `defineParserOverride`,
+`definePreflightOverride`, `defineServiceOverride`, `defineRendererOverride`,
+`defineImporter`, `defineExporter`, and the five hook builders
+`defineBeforeCommandHook` / `defineAfterCommandHook` / `defineOnWriteHook` /
+`defineOnReadHook` / `defineOnIndexHook`) are non-generic so a bare arrow's
+parameter is contextually typed instead of falling back to `any`. The
+[`assertRegistered*`](#testing-helpers) helpers below verify these same
+definitions once registered.
+
+## Declarative Authoring
+
+Tracked: [pm-iqq0](../.agents/pm/features/pm-iqq0.toon).
+
+`composeExtension` is the capstone of the `author → register → test` loop. Instead
+of hand-wiring each `api.register*` call inside an imperative `activate(api)`
+body — calling the right method, in the right order, without forgetting one —
+describe **what** to register as a plain `ExtensionBlueprint` object and let the
+SDK generate the `activate` for you. Every field is optional; populate the
+surfaces you use (ideally with `define*`-authored definitions) and leave the rest
+out:
+
+```js
+import { composeExtension, defineCommand, deriveExtensionCapabilities } from "@unbrained/pm-cli/sdk";
+
+const echo = defineCommand({
+  name: "command-kit echo",
+  action: "command-kit-echo",
+  description: "Echo a message as structured output.",
+  run: (context) => ({ message: context.args.join(" ") }),
+});
+
+const blueprint = {
+  commands: [echo],
+  parsers: { "command-kit echo": (context) => ({ options: context.options }) },
+  flags: { list: [{ long: "--kit-note", value_type: "string", value_name: "text" }] },
+};
+
+// The generated `activate` registers commands → overrides → flags → parsers →
+// renderers → services → preflights → item types → item fields → migrations →
+// search providers → vector store adapters → importers → exporters → hooks, then
+// awaits any imperative `activate` you also pass (an escape hatch run last).
+export default composeExtension(blueprint);
+```
+
+`deriveExtensionCapabilities(blueprint)` returns the exact least-privilege
+capability set the blueprint exercises (sorted, de-duplicated), so you can author
+`manifest.json` `capabilities` with zero declared-but-unused or used-but-undeclared
+drift. It is the author-time inverse of the runtime
+[`reconcileExtensionCapabilityUsage`](#capability-requirements) check, and the set
+it returns is the set `composeExtension`'s generated `activate` requires — they
+agree by construction:
+
+```js
+deriveExtensionCapabilities(blueprint); // ["commands", "parser", "schema"]
+```
+
+The blueprint's record-keyed fields (`commandOverrides`, `flags`, `parsers`,
+`renderers`, `services`) map a routing key to its handler, mirroring the
+two-argument `api.register*` overloads; `hooks` groups the five lifecycle kinds.
+`composeExtension` is a pure assembler: it does not validate definitions —
+per-surface contract enforcement stays in `api.register*` and the loader, so a
+malformed definition surfaces the same activation diagnostic as a hand-written
+`activate`. The bundled first-party packages intentionally keep import-free
+hand-written `activate` bodies so they load in extension-only installs; reach for
+`composeExtension` in npm package-mode authoring where the SDK is a dependency.
+
+### Author-time introspection and preflight
+
+Tracked: [pm-tlpv](../.agents/pm/features/pm-tlpv.toon),
+[pm-9ect](../.agents/pm/features/pm-9ect.toon),
+[pm-4oio](../.agents/pm/decisions/pm-4oio.toon).
+
+Two pure, no-activation helpers complete the loop, so a blueprint is fully
+inspectable and verifiable before it is ever loaded — the author-time inverse of
+the runtime guardrails (the same discipline as `deriveExtensionCapabilities`
+inverting [`reconcileExtensionCapabilityUsage`](#capability-requirements)):
+
+```js
+import { describeExtensionBlueprint, lintExtensionBlueprint } from "@unbrained/pm-cli/sdk";
+
+// describeExtensionBlueprint returns the same ExtensionActivationSummary shape as
+// the runtime describeExtensionActivation — but from the blueprint data alone, no
+// activation. It is to the named surfaces what deriveExtensionCapabilities is to
+// the capability set.
+describeExtensionBlueprint(blueprint).command_handlers; // ["command-kit echo", ...]
+
+// lintExtensionBlueprint preflights for the footguns activation would otherwise
+// surface late: a capability a surface exercises but the manifest omits is an
+// `error` (the loader throws extension_capability_missing); a declared-but-unused
+// capability, a duplicate command, a command/override conflict, and a present-but-
+// empty surface are `warning`s. Pass declaredCapabilities or set manifest.capabilities.
+const report = lintExtensionBlueprint(blueprint, { declaredCapabilities: ["commands", "parser", "schema"] });
+report.ok;       // false if any error-severity finding
+report.findings; // [{ code, severity, message, capability?/command?/field? }, ...]
+```
+
+Both read only the declarative data, so the imperative `activate` escape hatch is
+invisible to them — a blueprint that registers everything through that hatch
+summarizes as empty and lints clean. In a package test, `assertExtensionBlueprint`
+(below) turns the lint into a one-line CI guard.
+
 ## Testing Helpers
 
 Package tests can assert registration contracts without depending on Vitest-specific
@@ -607,6 +820,22 @@ guardrails, but it does not discover files or install packages. Use it for unit
 tests of extension registration shape; keep `pm package doctor` and runtime
 contracts in integration tests.
 
+For declarative (`composeExtension`) packages, `assertExtensionBlueprint(blueprint, options?)`
+is the `assert*` family member that preflights the blueprint *without* activating
+it — it runs `lintExtensionBlueprint` and throws if any finding is error-severity
+(today: a capability a surface exercises but the declared set omits, which would
+fail activation with `extension_capability_missing`). It returns the full
+`ExtensionBlueprintLintResult` on success so a test can still inspect advisory
+warnings:
+
+```ts
+import { assertExtensionBlueprint } from "@unbrained/pm-cli/sdk/testing";
+
+// Throws if the blueprint and its declared capabilities have drifted; otherwise
+// returns the lint result (including any non-blocking warnings) for inspection.
+const report = assertExtensionBlueprint(blueprint);
+```
+
 Invoke a registered command handler to assert its behavior (not just that it was
 registered). `runRegisteredCommandForTest` dispatches through pm's real engine and
 returns the `CommandHandlerResult`:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@unbrained/pm-cli",
-  "version": "2026.6.22",
+  "version": "2026.6.23",
   "description": "Git-native project management CLI for humans and agents.",
   "type": "module",
   "author": "unbrained",

package/dist/cli-bundle/chunks/activity-NEOI45NX.js

@@ -1,18 +0,0 @@
-import {
-  _testOnly,
-  runActivity
-} from "./chunk-QQWEROGS.js";
-import "./chunk-YRLLL5TY.js";
-import "./chunk-J2TSPY5L.js";
-import "./chunk-PJS2J7Z4.js";
-import "./chunk-GNDHOR64.js";
-import "./chunk-AJXYOYJV.js";
-import "./chunk-CR7KFPAQ.js";
-import "./chunk-3VLPDG3J.js";
-import "./chunk-4JXWVHMN.js";
-import "./chunk-RZZMSY4P.js";
-export {
-  _testOnly,
-  runActivity
-};
-//# sourceMappingURL=activity-NEOI45NX.js.map