pi-daddy 0.28.0 → 0.32.1

package/dist/capabilities.d.ts

@@ -1,136 +0,0 @@
-/**
- * Capability ids: their grammar, and the two authority predicates over them.
- *
- * Split out of `delegate.ts` when ADR-0024 pushed that file past the 400-line ceiling and
- * `test/file-size.test.ts` refused it — for the second time, and answered the same way as the first: split
- * the file the way the failure message says rather than raise the cap on the guard.
- *
- * The seam is not arbitrary. Three modules outside `delegate.ts` already imported these
- * (`extensions/session.ts` for `DELEGATE_CAPABILITY`, `extensions/delegation.ts` and
- * `extensions/run-delegation.ts` for `maySpawnDefinition`), which is the evidence that they were a separate
- * concern living in the wrong file: *what an id means and who may use it* is a different question from
- * *what one delegation does*.
- */
-import { type Capability } from "./resolve.ts";
-/** The capability that authorises spawning a definition (ADR-0017). `tool:*` satisfies any of them. */
-export declare const agentCapability: (name: string) => Capability;
-/**
- * May this grant spawn that definition? (ADR-0017.)
- *
- * `resolve()` is exact-match plus subsumption and has no wildcard rule — a wildcard session works only
- * because `deriveOwnGrant` *enumerates* its observed tools alongside `tool:*`. Definitions are not tools,
- * so nothing enumerates them, and the wildcard has to be honoured here explicitly. Without that an
- * UNGOVERNED session would stop being able to spawn, and "governance is opt-in" is the one rule this
- * package must never break by accident.
- */
-export declare function maySpawnDefinition(ownGrant: Capability[], name: string): boolean;
-/** The tool name that confers the ability to delegate further. */
-export declare const DELEGATE_CAPABILITY: Capability;
-/**
- * Every namespace a capability id may carry, as its literal prefix.
- *
- * **One list, because there were three and adding a namespace only updated some of them.** ADR-0035 taught
- * `normaliseCapability` about `workspace:` and left `ceilingForDefinition` (which mangled it into
- * `tool:workspace:<id>`) and `isSafeCapability` (which called it malformed) behind. The two places that parse
- * an id's namespace read this, so a fifth namespace is one entry rather than a third divergence.
- *
- * **Not every prefix decision in the package.** Inline `startsWith("` tests on a capability namespace are
- * scattered across `src/` and `extensions/`; this list is read by two of them. **No number is written here,
- * and the history is why:** SPEC first claimed the list was "what every site reads"; a correction said "six"
- * while its own enumeration listed seven; this docstring then said "nine" in the sentence claiming it gave no
- * number; and the correction to *that* said "fourteen", which counted every file containing any
- * `startsWith("` — CLI flags, `git worktree list` parsing, an assurance sentinel and node_modules entries
- * among them. Four numbers, four wrong. The command, so nobody has to quote a predecessor:
- *
- *     grep -rl 'startsWith("\(tool:\|ext:\|agent:\|skill:\|workspace:\)' src extensions
- *
- * Consolidating the sites is a separate change, and a count nobody re-derives is the defect this list exists
- * to prevent.
- *
- * `docs/SPEC.md`'s grammar section is the prose statement of the same list and is kept in step with it.
- */
-export declare const CAPABILITY_NAMESPACE_PREFIXES: readonly ["tool:", "ext:", "skill:", "agent:", "workspace:"];
-/** Accept `read` or `tool:read` or `ext:pkg/tool` and normalise to a capability id. */
-export declare function normaliseCapability(raw: string): Capability;
-/** The capability that authorises routing a child to one registered workspace (ADR-0035). */
-export declare function workspaceCapability(workspaceId: string): Capability;
-/**
- * May this session route a child to workspace `id`?
- *
- * Mirrors `maySpawnDefinition` deliberately — same shape, same wildcard handling, same reason. Routing was
- * the one governance dimension that did not attenuate (R-131, measured in
- * `docs/probes/g36-workspace-attenuation`): the registry inherited into every child and nothing checked the
- * caller's authority, so a child routed to `staging` could route its grandchild to `prod`.
- *
- * `tool:*` satisfies it because governance is opt-in — an ungoverned session holds the wildcard and must
- * keep working exactly as before.
- */
-export declare function mayRouteToWorkspace(ownGrant: readonly Capability[], workspaceId: string): boolean;
-/** False when an id would be read as more than one capability by any channel that carries it. */
-export declare function isWellFormedCapability(id: string): boolean;
-/**
- * The STRICT grammar: a whitelist of what a capability id may look like, not a blocklist of what it may not.
- *
- * **Two consumers, and they are two different reasons for the same rule.** It lives here rather than in
- * either of them because it shipped in one and was needed by both:
- *
- *  1. `skill-packages.ts` — the boundary that GENERATES a grant. R-77/R-78: a package declaring
- *     `allowed-tools: Read,ext:x";touch /tmp/pwned;PI_GRANTS_GRANT="` produced a `.pi/grants.env` that ran
- *     arbitrary code the moment an operator sourced the line `init` prints.
- *  2. `workspace.ts` — the operator registry, since ADR-0035 made a registry id the tail of a capability id
- *     (`workspace:<id>`). That made the registry an input to this grammar, and it got the LOOSE
- *     `isWellFormedCapability` blocklist instead, which review showed costs three things:
- *     an id of literally `*` loaded and minted `WORKSPACE_WILDCARD`, so an operator naming ONE worktree held
- *     routing authority over every id in the registry including ones added later;
- *     an id containing a space became TWO capabilities, because `ceilingForDefinition` splits `allowed-tools`
- *     on `[\s,]+` — `allowed-tools: read, workspace:prod bash` measured as
- *     `['tool:bash','tool:read','workspace:prod']`, i.e. routing over production plus a shell, neither typed
- *     by anyone (0.18.1's comma, one namespace over);
- *     and quote/`$()`/backtick ids reached the `ROUTABLE WORKSPACES` block of the generated file, whose own
- *     instructions tell the operator to paste them into `PI_GRANTS_GRANT`.
- *
- * **A blocklist was the wrong shape for this and the comment on `isWellFormedCapability` says why it is the
- * right shape THERE**: that one guards the enforcement path, which must keep accepting whatever ids operators
- * already have. A registry is a file the operator writes and can rename, so refusing a hostile id costs
- * nothing — and `grant-env.ts`'s standing warning applies to it exactly: *"the third channel — whatever it
- * turns out to be — should cost a refusal rather than an injection."* The registry was the third channel.
- */
-/**
- * A workspace registry id, which is NOT a tool name and needed its own rule.
- *
- * `isSafeCapability` was reused here first, and that was the error: it is the grammar for a *tool* name, and
- * it refused ids that published 0.18.1 accepted — `feature/x` above all. Git worktrees are routinely named
- * after their branch, so a slash is the ordinary case, and a slash splits nothing: not the comma-separated
- * grant, not `allowed-tools`' `[\s,]+`. Refusing it bought no safety and broke the common setup.
- *
- * What is refused, and why each one earns it:
- *  - **whitespace** — `ceilingForDefinition` splits `allowed-tools` on `[\s,]+`, so `workspace:prod bash`
- *    measured as `['tool:bash','tool:read','workspace:prod']`: routing over production plus a shell, neither
- *    typed by anyone. 0.18.1's comma, one namespace over.
- *  - **comma, CR, LF, NUL** — split a grant.
- *  - **`*`** — collides with `WORKSPACE_WILDCARD`, so registering a worktree as `*` and granting
- *    `workspace:*` believing it named that one root minted routing authority over the whole registry.
- *  - **quotes, `$`, backticks, `;`, `&`, `|`, `<`, `>`, `(`, `)`, `\`, `#`** — reach the ROUTABLE WORKSPACES
- *    block of a generated `.pi/grants.env`, whose own instructions tell the operator to paste the id into
- *    `PI_GRANTS_GRANT`. Sourcing the file was safe; following its instructions executed. R-77/R-78.
- *  - **control characters and non-ASCII** — the generated file is reviewed in an editor and `/grants` prints
- *    these; backspace and ANSI escapes let one id render as another. This is the one refusal that costs a
- *    legitimate user something (a non-English worktree name), and it is a deliberate trade recorded as
- *    breaking rather than asserted to cost nothing.
- */
-export declare function isSafeWorkspaceId(id: string): boolean;
-export declare function isSafeCapability(id: Capability): boolean;
-/**
- * The write-side backstop, for every channel that joins capabilities into one string.
- *
- * `covered()` already refuses to GRANT a malformed id, so this should be unreachable — which is exactly
- * why it exists. `grant-env.ts` says it better than I can: "the third channel — whatever it turns out to
- * be — should cost a refusal rather than an injection. A guard that depends on my enumeration being
- * complete is not a guard." The propagation channel turned out to be that third channel, and it had no
- * backstop while the file-writing channel did.
- *
- * Loud rather than silently filtered: a malformed id here means something upstream admitted one, and
- * dropping it quietly would hide the defect that produced it.
- */
-export declare function assertCapabilitiesArePropagatable(grant: readonly Capability[]): void;
-//# sourceMappingURL=capabilities.d.ts.map

package/dist/capabilities.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"capabilities.d.ts","sourceRoot":"","sources":["../src/capabilities.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;GAYG;AAEH,OAAO,EAAsC,KAAK,UAAU,EAAE,MAAM,cAAc,CAAC;AAInF,uGAAuG;AACvG,eAAO,MAAM,eAAe,GAAI,MAAM,MAAM,KAAG,UAA6B,CAAC;AAE7E;;;;;;;;GAQG;AACH,wBAAgB,kBAAkB,CAAC,QAAQ,EAAE,UAAU,EAAE,EAAE,IAAI,EAAE,MAAM,GAAG,OAAO,CAShF;AAED,kEAAkE;AAClE,eAAO,MAAM,mBAAmB,EAAE,UAA4B,CAAC;AAE/D;;;;;;;;;;;;;;;;;;;;;;GAsBG;AACH,eAAO,MAAM,6BAA6B,8DAA+D,CAAC;AAE1G,uFAAuF;AACvF,wBAAgB,mBAAmB,CAAC,GAAG,EAAE,MAAM,GAAG,UAAU,CAI3D;AAED,6FAA6F;AAC7F,wBAAgB,mBAAmB,CAAC,WAAW,EAAE,MAAM,GAAG,UAAU,CAEnE;AAED;;;;;;;;;;GAUG;AACH,wBAAgB,mBAAmB,CAAC,QAAQ,EAAE,SAAS,UAAU,EAAE,EAAE,WAAW,EAAE,MAAM,GAAG,OAAO,CAKjG;AAwBD,iGAAiG;AACjG,wBAAgB,sBAAsB,CAAC,EAAE,EAAE,MAAM,GAAG,OAAO,CAE1D;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;GA0BG;AACH;;;;;;;;;;;;;;;;;;;;;;GAsBG;AACH,wBAAgB,iBAAiB,CAAC,EAAE,EAAE,MAAM,GAAG,OAAO,CAErD;AAED,wBAAgB,gBAAgB,CAAC,EAAE,EAAE,UAAU,GAAG,OAAO,CAcxD;AAED;;;;;;;;;;;GAWG;AACH,wBAAgB,iCAAiC,CAAC,KAAK,EAAE,SAAS,UAAU,EAAE,GAAG,IAAI,CAWpF"}

package/dist/capabilities.js

@@ -1,203 +0,0 @@
-/**
- * Capability ids: their grammar, and the two authority predicates over them.
- *
- * Split out of `delegate.ts` when ADR-0024 pushed that file past the 400-line ceiling and
- * `test/file-size.test.ts` refused it — for the second time, and answered the same way as the first: split
- * the file the way the failure message says rather than raise the cap on the guard.
- *
- * The seam is not arbitrary. Three modules outside `delegate.ts` already imported these
- * (`extensions/session.ts` for `DELEGATE_CAPABILITY`, `extensions/delegation.ts` and
- * `extensions/run-delegation.ts` for `maySpawnDefinition`), which is the evidence that they were a separate
- * concern living in the wrong file: *what an id means and who may use it* is a different question from
- * *what one delegation does*.
- */
-import { AGENT_WILDCARD, WORKSPACE_WILDCARD } from "./resolve.js";
-import { WILDCARD } from "./pi-tools.js";
-import { GovernanceRefusal, refusal } from "./refusals.js";
-/** The capability that authorises spawning a definition (ADR-0017). `tool:*` satisfies any of them. */
-export const agentCapability = (name) => `agent:${name}`;
-/**
- * May this grant spawn that definition? (ADR-0017.)
- *
- * `resolve()` is exact-match plus subsumption and has no wildcard rule — a wildcard session works only
- * because `deriveOwnGrant` *enumerates* its observed tools alongside `tool:*`. Definitions are not tools,
- * so nothing enumerates them, and the wildcard has to be honoured here explicitly. Without that an
- * UNGOVERNED session would stop being able to spawn, and "governance is opt-in" is the one rule this
- * package must never break by accident.
- */
-export function maySpawnDefinition(ownGrant, name) {
-    // ADR-0023 adds the middle case. `tool:*` is authority to grant every tool and satisfies this too;
-    // `agent:*` is authority to spawn any definition and grants no tools at all, which is the configuration
-    // an operator wanting "any of our definitions, narrow tools" previously had to fake with `tool:*`.
-    return (ownGrant.includes(WILDCARD) ||
-        ownGrant.includes(AGENT_WILDCARD) ||
-        ownGrant.includes(agentCapability(name)));
-}
-/** The tool name that confers the ability to delegate further. */
-export const DELEGATE_CAPABILITY = "tool:delegate";
-/**
- * Every namespace a capability id may carry, as its literal prefix.
- *
- * **One list, because there were three and adding a namespace only updated some of them.** ADR-0035 taught
- * `normaliseCapability` about `workspace:` and left `ceilingForDefinition` (which mangled it into
- * `tool:workspace:<id>`) and `isSafeCapability` (which called it malformed) behind. The two places that parse
- * an id's namespace read this, so a fifth namespace is one entry rather than a third divergence.
- *
- * **Not every prefix decision in the package.** Inline `startsWith("` tests on a capability namespace are
- * scattered across `src/` and `extensions/`; this list is read by two of them. **No number is written here,
- * and the history is why:** SPEC first claimed the list was "what every site reads"; a correction said "six"
- * while its own enumeration listed seven; this docstring then said "nine" in the sentence claiming it gave no
- * number; and the correction to *that* said "fourteen", which counted every file containing any
- * `startsWith("` — CLI flags, `git worktree list` parsing, an assurance sentinel and node_modules entries
- * among them. Four numbers, four wrong. The command, so nobody has to quote a predecessor:
- *
- *     grep -rl 'startsWith("\(tool:\|ext:\|agent:\|skill:\|workspace:\)' src extensions
- *
- * Consolidating the sites is a separate change, and a count nobody re-derives is the defect this list exists
- * to prevent.
- *
- * `docs/SPEC.md`'s grammar section is the prose statement of the same list and is kept in step with it.
- */
-export const CAPABILITY_NAMESPACE_PREFIXES = ["tool:", "ext:", "skill:", "agent:", "workspace:"];
-/** Accept `read` or `tool:read` or `ext:pkg/tool` and normalise to a capability id. */
-export function normaliseCapability(raw) {
-    const value = raw.trim();
-    if (CAPABILITY_NAMESPACE_PREFIXES.some((prefix) => value.startsWith(prefix)))
-        return value;
-    return `tool:${value}`;
-}
-/** The capability that authorises routing a child to one registered workspace (ADR-0035). */
-export function workspaceCapability(workspaceId) {
-    return `workspace:${workspaceId}`;
-}
-/**
- * May this session route a child to workspace `id`?
- *
- * Mirrors `maySpawnDefinition` deliberately — same shape, same wildcard handling, same reason. Routing was
- * the one governance dimension that did not attenuate (R-131, measured in
- * `docs/probes/g36-workspace-attenuation`): the registry inherited into every child and nothing checked the
- * caller's authority, so a child routed to `staging` could route its grandchild to `prod`.
- *
- * `tool:*` satisfies it because governance is opt-in — an ungoverned session holds the wildcard and must
- * keep working exactly as before.
- */
-export function mayRouteToWorkspace(ownGrant, workspaceId) {
-    const held = new Set(ownGrant);
-    return held.has(WILDCARD)
-        || held.has(WORKSPACE_WILDCARD)
-        || held.has(workspaceCapability(workspaceId));
-}
-/**
- * Characters that make a capability id mean something OTHER than one capability.
- *
- * A capability id is never a list. `PI_GRANTS_GRANT` is comma-separated and `parseList` trims and splits
- * it, so a comma inside a single id means the child reads it as several — including ones nothing granted.
- * Newlines are here for the same reason one level out: the grant travels through an environment variable
- * and, via `assertGrantIsWritable`, a shell-sourced file.
- *
- * **Measured, on the published 0.18.0.** A root holding `agent:*` (or `tool:*`) that requested
- * `agent:x,tool:bash` had it admitted by the wildcard's prefix rule, written verbatim into the child's
- * grant, and split by the child into `agent:x` + `tool:bash` — minting a capability the root never held,
- * with `denied: []` so nothing recorded an escalation and the ledger line looked clean.
- *
- * Deliberately a blocklist of structurally dangerous characters rather than the full grammar whitelist in
- * `isSafeCapability`. That whitelist is right where it lives — the boundary that GENERATES a grant — but
- * this is the enforcement path, which must keep accepting whatever ids operators already have. A security
- * patch to a released version should close the hole without inventing a new way to refuse a legitimate
- * setup. `grant-env.ts` predicted this channel: "the third channel — whatever it turns out to be — should
- * cost a refusal rather than an injection."
- */
-const CAPABILITY_ID_SEPARATORS = /[,\r\n\0]/;
-/** False when an id would be read as more than one capability by any channel that carries it. */
-export function isWellFormedCapability(id) {
-    return id.length > 0 && !CAPABILITY_ID_SEPARATORS.test(id) && id.trim() === id;
-}
-/**
- * The STRICT grammar: a whitelist of what a capability id may look like, not a blocklist of what it may not.
- *
- * **Two consumers, and they are two different reasons for the same rule.** It lives here rather than in
- * either of them because it shipped in one and was needed by both:
- *
- *  1. `skill-packages.ts` — the boundary that GENERATES a grant. R-77/R-78: a package declaring
- *     `allowed-tools: Read,ext:x";touch /tmp/pwned;PI_GRANTS_GRANT="` produced a `.pi/grants.env` that ran
- *     arbitrary code the moment an operator sourced the line `init` prints.
- *  2. `workspace.ts` — the operator registry, since ADR-0035 made a registry id the tail of a capability id
- *     (`workspace:<id>`). That made the registry an input to this grammar, and it got the LOOSE
- *     `isWellFormedCapability` blocklist instead, which review showed costs three things:
- *     an id of literally `*` loaded and minted `WORKSPACE_WILDCARD`, so an operator naming ONE worktree held
- *     routing authority over every id in the registry including ones added later;
- *     an id containing a space became TWO capabilities, because `ceilingForDefinition` splits `allowed-tools`
- *     on `[\s,]+` — `allowed-tools: read, workspace:prod bash` measured as
- *     `['tool:bash','tool:read','workspace:prod']`, i.e. routing over production plus a shell, neither typed
- *     by anyone (0.18.1's comma, one namespace over);
- *     and quote/`$()`/backtick ids reached the `ROUTABLE WORKSPACES` block of the generated file, whose own
- *     instructions tell the operator to paste them into `PI_GRANTS_GRANT`.
- *
- * **A blocklist was the wrong shape for this and the comment on `isWellFormedCapability` says why it is the
- * right shape THERE**: that one guards the enforcement path, which must keep accepting whatever ids operators
- * already have. A registry is a file the operator writes and can rename, so refusing a hostile id costs
- * nothing — and `grant-env.ts`'s standing warning applies to it exactly: *"the third channel — whatever it
- * turns out to be — should cost a refusal rather than an injection."* The registry was the third channel.
- */
-/**
- * A workspace registry id, which is NOT a tool name and needed its own rule.
- *
- * `isSafeCapability` was reused here first, and that was the error: it is the grammar for a *tool* name, and
- * it refused ids that published 0.18.1 accepted — `feature/x` above all. Git worktrees are routinely named
- * after their branch, so a slash is the ordinary case, and a slash splits nothing: not the comma-separated
- * grant, not `allowed-tools`' `[\s,]+`. Refusing it bought no safety and broke the common setup.
- *
- * What is refused, and why each one earns it:
- *  - **whitespace** — `ceilingForDefinition` splits `allowed-tools` on `[\s,]+`, so `workspace:prod bash`
- *    measured as `['tool:bash','tool:read','workspace:prod']`: routing over production plus a shell, neither
- *    typed by anyone. 0.18.1's comma, one namespace over.
- *  - **comma, CR, LF, NUL** — split a grant.
- *  - **`*`** — collides with `WORKSPACE_WILDCARD`, so registering a worktree as `*` and granting
- *    `workspace:*` believing it named that one root minted routing authority over the whole registry.
- *  - **quotes, `$`, backticks, `;`, `&`, `|`, `<`, `>`, `(`, `)`, `\`, `#`** — reach the ROUTABLE WORKSPACES
- *    block of a generated `.pi/grants.env`, whose own instructions tell the operator to paste the id into
- *    `PI_GRANTS_GRANT`. Sourcing the file was safe; following its instructions executed. R-77/R-78.
- *  - **control characters and non-ASCII** — the generated file is reviewed in an editor and `/grants` prints
- *    these; backspace and ANSI escapes let one id render as another. This is the one refusal that costs a
- *    legitimate user something (a non-English worktree name), and it is a deliberate trade recorded as
- *    breaking rather than asserted to cost nothing.
- */
-export function isSafeWorkspaceId(id) {
-    return /^[A-Za-z0-9][A-Za-z0-9._/-]*$/.test(id);
-}
-export function isSafeCapability(id) {
-    const segment = "[A-Za-z0-9][A-Za-z0-9._-]*";
-    // `workspace:` delegates to the WORKSPACE grammar rather than reusing `segment`, and that is the fifth
-    // site of the same defect. `isSafeWorkspaceId` allows a slash because a git worktree is routinely named
-    // after its branch; `segment` does not, so this function refused `workspace:feature/x` — dropping the whole
-    // definition, exiting 1, and telling the operator "a capability id is tool:/skill:/agent:<name> or
-    // ext:<pkg>/<tool>", which does not even mention the namespace. Meanwhile the CHANGELOG told them slashes
-    // are fine. **The boundary that GENERATES grants could not emit the id shape the release advertises**, so
-    // the migration path for a breaking change was closed by the commit that documented it as open.
-    if (id.startsWith("workspace:"))
-        return isSafeWorkspaceId(id.slice("workspace:".length));
-    return (new RegExp(`^(tool|skill|agent):${segment}$`).test(id) ||
-        new RegExp(`^ext:(@${segment}/)?${segment}/${segment}$`).test(id));
-}
-/**
- * The write-side backstop, for every channel that joins capabilities into one string.
- *
- * `covered()` already refuses to GRANT a malformed id, so this should be unreachable — which is exactly
- * why it exists. `grant-env.ts` says it better than I can: "the third channel — whatever it turns out to
- * be — should cost a refusal rather than an injection. A guard that depends on my enumeration being
- * complete is not a guard." The propagation channel turned out to be that third channel, and it had no
- * backstop while the file-writing channel did.
- *
- * Loud rather than silently filtered: a malformed id here means something upstream admitted one, and
- * dropping it quietly would hide the defect that produced it.
- */
-export function assertCapabilitiesArePropagatable(grant) {
-    const malformed = grant.filter((c) => !isWellFormedCapability(c));
-    if (malformed.length === 0)
-        return;
-    throw new GovernanceRefusal(refusal("GRANT_ID_MALFORMED", `refusing to build a child environment: ${JSON.stringify(malformed)} contain characters that are not ` +
-        `part of a capability id. The grant is comma-separated, so a child would read these as several ` +
-        `capabilities — including ones nothing granted. Report this: a malformed id reached propagation, ` +
-        `which means a guard upstream admitted it.`, { malformed: malformed.join(" ") }));
-}
-//# sourceMappingURL=capabilities.js.map

package/dist/capabilities.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"capabilities.js","sourceRoot":"","sources":["../src/capabilities.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;GAYG;AAEH,OAAO,EAAE,cAAc,EAAE,kBAAkB,EAAmB,MAAM,cAAc,CAAC;AACnF,OAAO,EAAE,QAAQ,EAAE,MAAM,eAAe,CAAC;AACzC,OAAO,EAAE,iBAAiB,EAAE,OAAO,EAAE,MAAM,eAAe,CAAC;AAE3D,uGAAuG;AACvG,MAAM,CAAC,MAAM,eAAe,GAAG,CAAC,IAAY,EAAc,EAAE,CAAC,SAAS,IAAI,EAAE,CAAC;AAE7E;;;;;;;;GAQG;AACH,MAAM,UAAU,kBAAkB,CAAC,QAAsB,EAAE,IAAY;IACrE,mGAAmG;IACnG,wGAAwG;IACxG,mGAAmG;IACnG,OAAO,CACL,QAAQ,CAAC,QAAQ,CAAC,QAAQ,CAAC;QAC3B,QAAQ,CAAC,QAAQ,CAAC,cAAc,CAAC;QACjC,QAAQ,CAAC,QAAQ,CAAC,eAAe,CAAC,IAAI,CAAC,CAAC,CACzC,CAAC;AACJ,CAAC;AAED,kEAAkE;AAClE,MAAM,CAAC,MAAM,mBAAmB,GAAe,eAAe,CAAC;AAE/D;;;;;;;;;;;;;;;;;;;;;;GAsBG;AACH,MAAM,CAAC,MAAM,6BAA6B,GAAG,CAAC,OAAO,EAAE,MAAM,EAAE,QAAQ,EAAE,QAAQ,EAAE,YAAY,CAAU,CAAC;AAE1G,uFAAuF;AACvF,MAAM,UAAU,mBAAmB,CAAC,GAAW;IAC7C,MAAM,KAAK,GAAG,GAAG,CAAC,IAAI,EAAE,CAAC;IACzB,IAAI,6BAA6B,CAAC,IAAI,CAAC,CAAC,MAAM,EAAE,EAAE,CAAC,KAAK,CAAC,UAAU,CAAC,MAAM,CAAC,CAAC;QAAE,OAAO,KAAK,CAAC;IAC3F,OAAO,QAAQ,KAAK,EAAE,CAAC;AACzB,CAAC;AAED,6FAA6F;AAC7F,MAAM,UAAU,mBAAmB,CAAC,WAAmB;IACrD,OAAO,aAAa,WAAW,EAAE,CAAC;AACpC,CAAC;AAED;;;;;;;;;;GAUG;AACH,MAAM,UAAU,mBAAmB,CAAC,QAA+B,EAAE,WAAmB;IACtF,MAAM,IAAI,GAAG,IAAI,GAAG,CAAC,QAAQ,CAAC,CAAC;IAC/B,OAAO,IAAI,CAAC,GAAG,CAAC,QAAQ,CAAC;WACpB,IAAI,CAAC,GAAG,CAAC,kBAAkB,CAAC;WAC5B,IAAI,CAAC,GAAG,CAAC,mBAAmB,CAAC,WAAW,CAAC,CAAC,CAAC;AAClD,CAAC;AAED;;;;;;;;;;;;;;;;;;;GAmBG;AACH,MAAM,wBAAwB,GAAG,WAAW,CAAC;AAE7C,iGAAiG;AACjG,MAAM,UAAU,sBAAsB,CAAC,EAAU;IAC/C,OAAO,EAAE,CAAC,MAAM,GAAG,CAAC,IAAI,CAAC,wBAAwB,CAAC,IAAI,CAAC,EAAE,CAAC,IAAI,EAAE,CAAC,IAAI,EAAE,KAAK,EAAE,CAAC;AACjF,CAAC;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;GA0BG;AACH;;;;;;;;;;;;;;;;;;;;;;GAsBG;AACH,MAAM,UAAU,iBAAiB,CAAC,EAAU;IAC1C,OAAO,+BAA+B,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;AAClD,CAAC;AAED,MAAM,UAAU,gBAAgB,CAAC,EAAc;IAC7C,MAAM,OAAO,GAAG,4BAA4B,CAAC;IAC7C,uGAAuG;IACvG,wGAAwG;IACxG,4GAA4G;IAC5G,mGAAmG;IACnG,0GAA0G;IAC1G,0GAA0G;IAC1G,gGAAgG;IAChG,IAAI,EAAE,CAAC,UAAU,CAAC,YAAY,CAAC;QAAE,OAAO,iBAAiB,CAAC,EAAE,CAAC,KAAK,CAAC,YAAY,CAAC,MAAM,CAAC,CAAC,CAAC;IACzF,OAAO,CACL,IAAI,MAAM,CAAC,uBAAuB,OAAO,GAAG,CAAC,CAAC,IAAI,CAAC,EAAE,CAAC;QACtD,IAAI,MAAM,CAAC,UAAU,OAAO,MAAM,OAAO,IAAI,OAAO,GAAG,CAAC,CAAC,IAAI,CAAC,EAAE,CAAC,CAClE,CAAC;AACJ,CAAC;AAED;;;;;;;;;;;GAWG;AACH,MAAM,UAAU,iCAAiC,CAAC,KAA4B;IAC5E,MAAM,SAAS,GAAG,KAAK,CAAC,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,sBAAsB,CAAC,CAAC,CAAC,CAAC,CAAC;IAClE,IAAI,SAAS,CAAC,MAAM,KAAK,CAAC;QAAE,OAAO;IACnC,MAAM,IAAI,iBAAiB,CAAC,OAAO,CACjC,oBAAoB,EACpB,0CAA0C,IAAI,CAAC,SAAS,CAAC,SAAS,CAAC,mCAAmC;QACtG,gGAAgG;QAChG,kGAAkG;QAClG,2CAA2C,EAC3C,EAAE,SAAS,EAAE,SAAS,CAAC,IAAI,CAAC,GAAG,CAAC,EAAE,CACnC,CAAC,CAAC;AACL,CAAC"}

package/dist/catalog.d.ts

@@ -1,98 +0,0 @@
-/**
- * Live capability catalog — what *can* be granted, enumerated at runtime.
- *
- * Until now grants were checked against agent-type files alone, which covers `tool:` capabilities and
- * nothing else. That leaves two gaps: extension tools are invisible (so `ext:` grants cannot be
- * validated), and **skills were ungovernable** despite "skills and tools" being half the requirement.
- *
- * Sources, and why each is trusted:
- *  - **tools** — the `tools` array of a live provider request. Authoritative: it is exactly what pi sent
- *    the model, so it includes extension-registered tools and reflects any `--tools` allowlist already in
- *    force. Nothing else can see the real surface.
- *  - **skills** — `SKILL.md` directories and top-level `.md` files under pi's skill roots.
- *  - **definitions** — spawnable `SKILL.md` agents (ADR-0016), as `agent:<name>`.
- *
- * Provenance note: a provider payload gives tool NAMES, not owning packages, so extension tools cannot be
- * qualified as `ext:<pkg>/<tool>` from that source alone. They are catalogued as `tool:<name>` — which is
- * also how pi's `--tools` matches — and marked `kind: "extension"` for display. `ext:` ids remain
- * supported for hand-authored grants; `deriveOwnGrant` already matches them by bare name.
- */
-import { type SkillDefinition } from "./definitions.ts";
-import { type Capability } from "./resolve.ts";
-import { type WorkspaceRegistryFile } from "./workspace.ts";
-export type CapabilityKind = "builtin" | "extension" | "skill" | "agentType" | "workspace";
-export interface CatalogEntry {
-    capability: Capability;
-    kind: CapabilityKind;
-    /** Where it was found, for display and debugging. */
-    source?: string;
-}
-export interface Catalog {
-    entries: CatalogEntry[];
-    /** Every capability id in the catalog. */
-    all: Capability[];
-    byKind(kind: CapabilityKind): Capability[];
-    has(capability: Capability): boolean;
-}
-/** Split observed tool names into pi built-ins and extension-provided tools. */
-export declare function classifyToolNames(observed: string[]): CatalogEntry[];
-/** Skill roots pi discovers, project first. */
-export declare function skillDirs(cwd: string): string[];
-/** Enumerate the same enabled Pi resource paths as definitions, preserving resolver precedence. */
-export declare function loadSkills(cwd: string): Promise<CatalogEntry[]>;
-/**
- * Spawnable definitions, as `agent:<name>` capabilities.
- *
- * A definition is BOTH a skill (loadable into a session) and an agent (spawnable as a child) — ADR-0016
- * collapsed those into one file — so the same `SKILL.md` legitimately appears twice in the catalog under
- * two capability ids. That is not duplication: `skill:review` means "may load these instructions" and
- * `agent:review` means "may spawn a child running them", and a grant can hold either without the other.
- */
-export declare function definitionEntries(definitions: Map<string, SkillDefinition>): CatalogEntry[];
-/**
- * Registered workspaces, as `workspace:<id>` capabilities (ADR-0035).
- *
- * For DISPLAY and SCAFFOLDING only — `/grants` listing what this session may route to, and `init` offering
- * the ids without choosing among them (ADR-0028). It is deliberately **not** what `unknownCapabilities`
- * checks against; see the comment there.
- *
- * The operator registry is the authority on which ids exist, exactly as it is at `resolveWorkspace`. This
- * enumerates it; it does not decide anything.
- */
-export declare function workspaceEntries(registry: WorkspaceRegistryFile, source?: string): CatalogEntry[];
-/** Assemble a catalog from parts. Pure, so it is testable without a filesystem. */
-export declare function makeCatalog(entries: CatalogEntry[]): Catalog;
-/** Build the live catalog. `observedTools` comes from a provider payload; null when not yet seen. */
-export declare function buildCatalog(input: {
-    cwd: string;
-    observedTools: string[] | null;
-    /** Operator workspace registry (`PI_GRANTS_WORKSPACE_REGISTRY`). Absent or unreadable yields no entries. */
-    registryPath?: string;
-}): Promise<Catalog>;
-/**
- * Capabilities requested that the catalog does not contain.
- *
- * Reported separately from `denied` because the causes differ and so do the fixes: `denied` means the
- * delegator lacks authority, `unknown` means the capability does not exist here — usually a typo or a
- * stale grant referring to an uninstalled package. Silently treating unknown as denied hides that.
- */
-export declare function unknownCapabilities(requested: Capability[], catalog: Catalog): Capability[];
-/**
- * The capability an unknown one was most likely meant to be, or null when nothing is close enough.
- *
- * Two sources, in order. A known foreign name wins outright — `Glob` is not a typo for `find`, so no
- * distance metric would ever connect them, and that is exactly the case worth naming. Otherwise the
- * nearest catalog entry within a small edit distance, which catches `raed`/`serach` and stops well short
- * of guessing: the threshold scales with the name's length and never exceeds two.
- */
-export declare function suggestForUnknown(unknown: Capability, catalog: Catalog): Capability | null;
-/**
- * Skill name -> absolute path, for `planSpawn`'s `--skill` flags (R-32).
- *
- * Derived from the catalog's own `source` field rather than re-scanning, so what a child is handed
- * cannot drift from what was discovered and offered. A skill entry without a source is omitted, which
- * makes it *unresolvable* rather than silently absent — `planDelegation` refuses on that, because a
- * grant naming a skill the child never receives is a ledger line that lies.
- */
-export declare function skillPathsFromCatalog(catalog: Catalog): Record<string, string>;
-//# sourceMappingURL=catalog.d.ts.map

package/dist/catalog.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"catalog.d.ts","sourceRoot":"","sources":["../src/catalog.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;GAkBG;AAKH,OAAO,EAAmB,KAAK,eAAe,EAAE,MAAM,kBAAkB,CAAC;AAEzE,OAAO,EAAsC,KAAK,UAAU,EAAE,MAAM,cAAc,CAAC;AACnF,OAAO,EAAyB,KAAK,qBAAqB,EAAE,MAAM,gBAAgB,CAAC;AAGnF,MAAM,MAAM,cAAc,GAAG,SAAS,GAAG,WAAW,GAAG,OAAO,GAAG,WAAW,GAAG,WAAW,CAAC;AAE3F,MAAM,WAAW,YAAY;IAC3B,UAAU,EAAE,UAAU,CAAC;IACvB,IAAI,EAAE,cAAc,CAAC;IACrB,qDAAqD;IACrD,MAAM,CAAC,EAAE,MAAM,CAAC;CACjB;AAED,MAAM,WAAW,OAAO;IACtB,OAAO,EAAE,YAAY,EAAE,CAAC;IACxB,0CAA0C;IAC1C,GAAG,EAAE,UAAU,EAAE,CAAC;IAClB,MAAM,CAAC,IAAI,EAAE,cAAc,GAAG,UAAU,EAAE,CAAC;IAC3C,GAAG,CAAC,UAAU,EAAE,UAAU,GAAG,OAAO,CAAC;CACtC;AAED,gFAAgF;AAChF,wBAAgB,iBAAiB,CAAC,QAAQ,EAAE,MAAM,EAAE,GAAG,YAAY,EAAE,CAMpE;AAED,+CAA+C;AAC/C,wBAAgB,SAAS,CAAC,GAAG,EAAE,MAAM,GAAG,MAAM,EAAE,CAE/C;AAED,mGAAmG;AACnG,wBAAsB,UAAU,CAAC,GAAG,EAAE,MAAM,GAAG,OAAO,CAAC,YAAY,EAAE,CAAC,CAOrE;AAED;;;;;;;GAOG;AACH,wBAAgB,iBAAiB,CAAC,WAAW,EAAE,GAAG,CAAC,MAAM,EAAE,eAAe,CAAC,GAAG,YAAY,EAAE,CAM3F;AAED;;;;;;;;;GASG;AACH,wBAAgB,gBAAgB,CAAC,QAAQ,EAAE,qBAAqB,EAAE,MAAM,CAAC,EAAE,MAAM,GAAG,YAAY,EAAE,CAIjG;AAED,mFAAmF;AACnF,wBAAgB,WAAW,CAAC,OAAO,EAAE,YAAY,EAAE,GAAG,OAAO,CAY5D;AAED,qGAAqG;AACrG,wBAAsB,YAAY,CAAC,KAAK,EAAE;IACxC,GAAG,EAAE,MAAM,CAAC;IACZ,aAAa,EAAE,MAAM,EAAE,GAAG,IAAI,CAAC;IAC/B,4GAA4G;IAC5G,YAAY,CAAC,EAAE,MAAM,CAAC;CACvB,GAAG,OAAO,CAAC,OAAO,CAAC,CAgCnB;AAED;;;;;;GAMG;AACH,wBAAgB,mBAAmB,CAAC,SAAS,EAAE,UAAU,EAAE,EAAE,OAAO,EAAE,OAAO,GAAG,UAAU,EAAE,CAgC3F;AA6DD;;;;;;;GAOG;AACH,wBAAgB,iBAAiB,CAAC,OAAO,EAAE,UAAU,EAAE,OAAO,EAAE,OAAO,GAAG,UAAU,GAAG,IAAI,CAuB1F;AAED;;;;;;;GAOG;AACH,wBAAgB,qBAAqB,CAAC,OAAO,EAAE,OAAO,GAAG,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAO9E"}