pi-daddy 0.32.0 → 0.32.1

package/src/kernel/routing-authority.ts

@@ -36,7 +36,7 @@ export interface RoutingRefusal {
  * Checked before anything is said about the target, for the reason `maySpawnDefinition` is: it is a
  * governance question about the SESSION. Before ADR-0035 nothing checked it — the registry inherited into
  * every governed child and a child routed to `staging` could route its grandchild to `prod` (R-131, measured
- * in `docs/probes/g36-workspace-attenuation`).
+ * in probe `g36-workspace-attenuation`).
  *
  * **Well-formedness first, because `workspace_id` is a model-facing tool parameter** and the next step turns
  * it into a capability id. `workspace_id: "prod,tool:bash"` produced a `WORKSPACE_NOT_AUTHORIZED` whose

package/src/kernel/skill-packages.ts

@@ -92,7 +92,7 @@ export function isSafeName(name: string): boolean {
  * grants), which is right for the enforcement path — the catalog refuses what it does not know — and is
  * exactly why the check has to be here, at the boundary that *generates* rather than the one that enforces.
  *
- * The grammar is the one `docs/SPEC.md` documents: `tool:<name>`, `skill:<name>`, `agent:<name>`,
+ * The grammar is the one the README documents: `tool:<name>`, `skill:<name>`, `agent:<name>`,
  * `workspace:<id>`, and `ext:<pkg>/<tool>` where `<pkg>` may be npm-scoped. No wildcards — those are refused
  * separately and loudly, because "you tried to grant yourself everything" is a different fact from "that is
  * not a name".

package/src/kernel/spawn.ts

@@ -3,7 +3,7 @@
  *
  * The enforcement point is pi core, not this package: `--tools` and `--no-tools` hard-block extension
  * tools, and an explicitly `-e`-loaded extension cannot re-add its tool past them (verified,
- * docs/probes/pi-fabric-eval probes 9–11). So governance reduces to "compute the allowlist correctly
+ * probe `pi-fabric-eval` probes 9–11). So governance reduces to "compute the allowlist correctly
  * and hand it to pi", with no runtime inside the descendant.
  */
 
@@ -77,7 +77,7 @@ export function planSpawn(input: SpawnPlanInput): SpawnPlan {
 
   // R-32. `--no-extensions` governs EXTENSIONS ONLY — measured, not assumed: a child spawned with
   // `--tools read` still loaded all eight of the operator's skills and `CLAUDE.md`
-  // (`docs/probes/g16-herdr` §4-5). Skills are injected into the system prompt rather than passed as
+  // (probe `g16-herdr` §4-5). Skills are injected into the system prompt rather than passed as
   // tools, so `--tools` cannot reach them and the `skill:` namespace enforced nothing at all.
   //
   // `--no-skills` is unconditional and `--skill` is added on top, because that is exactly how pi
@@ -133,7 +133,7 @@ export function planSpawn(input: SpawnPlanInput): SpawnPlan {
  *  - `@…` is resolved as a file and its contents injected into the child's prompt — absolute paths, `~`
  *    expansion, no sandbox. This happens in `main.js` before any tool is constructed, so `--tools` and
  *    `--no-tools` never apply to it. A child granted nothing at all still reads the file. Verified
- *    against pi 0.83.0 (review finding A-C1 / B-C7, and `docs/probes/g1-argv`).
+ *    against pi 0.83.0 (review finding A-C1 / B-C7, and probe `g1-argv`).
  *  - `-…` is parsed as a flag, and pi ships `--approve` ("trust project-local files for this run").
  *
  * The task comes from the model, so this is the one place in the package where a model-authored string

package/src/kernel/workspace.ts

@@ -22,7 +22,7 @@ export interface WorkspaceRegistryFile {
   /**
    * Where this was loaded from, carried so a refusal can NAME it.
    *
-   * `docs/SPEC.md` claimed an unregistered id is refused "with `WORKSPACE_NOT_REGISTERED`, which names the
+   * The README claimed an unregistered id is refused "with `WORKSPACE_NOT_REGISTERED`, which names the
    * file", and `catalog.ts` justified exempting the whole namespace from the unknown check on the strength of
    * that — *"a second, weaker check here can only turn that precise refusal into a misleading one"*. The
    * refusal named no file: the registry object had no idea where it came from. Carried on the object rather