@selesai/code 0.13.12 → 0.13.13

package/dist/extensions/pi-subagents/async-retention-discovery-worker.mjs

@@ -1,180 +0,0 @@
-import * as fs from "node:fs";
-import * as path from "node:path";
-import { parentPort } from "node:worker_threads";
-
-const ACTIVE_RUN_INDEX_DIR = ".active-runs";
-const RESULT_TOMBSTONE_PREFIX = ".deleting-result-";
-
-function compareRelative(left, right) {
-	if (left < right) return -1;
-	if (left > right) return 1;
-	return 0;
-}
-
-function insertSmallest(entries, candidate, limit) {
-	if (limit <= 0) return;
-	const index = entries.findIndex((entry) => compareRelative(candidate.relative, entry.relative) < 0);
-	if (index === -1) entries.push(candidate);
-	else entries.splice(index, 0, candidate);
-	if (entries.length > limit) entries.pop();
-}
-
-function streamDirWindow(dir, limit, after, relativePath, usable) {
-	if (limit <= 0) return { entries: [], rawReads: 0, exhausted: true, cursorCleared: false };
-	let handle;
-	try {
-		handle = fs.opendirSync(dir);
-		const next = [];
-		const wrapped = [];
-		let rawReads = 0;
-		while (true) {
-			const entry = handle.readSync();
-			if (!entry) break;
-			rawReads += 1;
-			const relative = relativePath(entry);
-			if (!usable(entry, relative)) continue;
-			const candidate = { relative, name: entry.name };
-			insertSmallest(wrapped, candidate, limit);
-			if (after === undefined || compareRelative(relative, after) > 0) insertSmallest(next, candidate, limit);
-		}
-		const cursorCleared = after !== undefined && next.length === 0;
-		return { entries: cursorCleared ? wrapped : next, rawReads, exhausted: true, cursorCleared };
-	} catch (error) {
-		if (error?.code === "ENOENT") return { entries: [], rawReads: 0, exhausted: true, cursorCleared: false };
-		throw error;
-	} finally {
-		handle?.closeSync();
-	}
-}
-
-function discover(request) {
-	const startedAt = Date.now();
-	const cursor = structuredClone(request.cursor);
-	const raw = { reads: 0, exhausted: {} };
-	const record = (source, scan) => {
-		raw.reads += scan.rawReads;
-		raw.exhausted[source] = scan.exhausted;
-	};
-	const runScan = streamDirWindow(
-		request.asyncDirRoot,
-		request.runBudget,
-		cursor.runAfter,
-		(entry) => entry.name,
-		(entry) => entry.isDirectory() && entry.name !== ACTIVE_RUN_INDEX_DIR,
-	);
-	record("runs", runScan);
-	if (runScan.cursorCleared) delete cursor.runAfter;
-	const runCandidates = runScan.entries.slice(0, request.runBudget);
-	for (const candidate of runCandidates) cursor.runAfter = candidate.relative;
-
-	const resultCandidates = [];
-	const sourceLimit = Math.max(1, Math.ceil(request.resultBudget / 4));
-	const addFiles = (dir, kind, cursorTarget, source, budget = sourceLimit) => {
-		const remaining = Math.min(budget, request.resultBudget - resultCandidates.length);
-		if (remaining <= 0) return 0;
-		const before = resultCandidates.length;
-		const after = cursorTarget.type === "pending"
-			? cursor.resultPendingAfterBySession?.[cursorTarget.session]
-			: cursor[cursorTarget.key];
-		const scan = streamDirWindow(
-			dir,
-			remaining,
-			after,
-			(entry) => path.relative(request.resultsDir, path.join(dir, entry.name)),
-			(entry) => entry.isFile() && (entry.name.startsWith(RESULT_TOMBSTONE_PREFIX) || entry.name.endsWith(".json")),
-		);
-		record(source, scan);
-		if (scan.cursorCleared) {
-			if (cursorTarget.type === "pending") delete cursor.resultPendingAfterBySession?.[cursorTarget.session];
-			else delete cursor[cursorTarget.key];
-		}
-		for (const candidate of scan.entries.slice(0, remaining)) {
-			const tombstone = candidate.name.startsWith(RESULT_TOMBSTONE_PREFIX);
-			resultCandidates.push({
-				name: candidate.name,
-				relative: candidate.relative,
-				kind: tombstone ? "tombstone" : kind,
-				cursor: cursorTarget,
-			});
-			if (cursorTarget.type === "pending") {
-				cursor.resultPendingAfterBySession ??= {};
-				cursor.resultPendingAfterBySession[cursorTarget.session] = candidate.relative;
-			} else cursor[cursorTarget.key] = candidate.relative;
-		}
-		return resultCandidates.length - before;
-	};
-
-	addFiles(request.resultsDir, "public", { type: "result", key: "resultPublicAfter" }, "results.public");
-	const pendingRoot = path.join(request.resultsDir, "result-pending");
-	const pendingRemaining = Math.min(request.resultBudget, sourceLimit, request.resultBudget - resultCandidates.length);
-	const pendingScan = streamDirWindow(
-		pendingRoot,
-		pendingRemaining,
-		cursor.pendingSessionAfter,
-		(entry) => entry.name,
-		(entry) => entry.isDirectory(),
-	);
-	record("results.pendingSessions", pendingScan);
-	const livePendingSessions = new Set(pendingScan.entries.map((entry) => entry.relative));
-	if (cursor.resultPendingAfterBySession) {
-		let pruned = 0;
-		for (const session of Object.keys(cursor.resultPendingAfterBySession).sort()) {
-			if (pruned >= request.resultBudget) break;
-			if (!livePendingSessions.has(session) && !fs.existsSync(path.join(pendingRoot, session))) {
-				delete cursor.resultPendingAfterBySession[session];
-				pruned += 1;
-			}
-		}
-		if (Object.keys(cursor.resultPendingAfterBySession).length === 0) delete cursor.resultPendingAfterBySession;
-	}
-	if (pendingScan.cursorCleared) delete cursor.pendingSessionAfter;
-	const pendingSessions = pendingScan.entries.slice(0, pendingRemaining);
-	let pendingFileBudget = Math.min(sourceLimit, request.resultBudget - resultCandidates.length);
-	for (const session of pendingSessions) {
-		if (pendingFileBudget <= 0) break;
-		cursor.pendingSessionAfter = session.relative;
-		pendingFileBudget -= addFiles(
-			path.join(pendingRoot, session.name),
-			"pending",
-			{ type: "pending", session: session.relative },
-			`results.pending.${session.name}`,
-			pendingFileBudget,
-		);
-	}
-	addFiles(path.join(request.resultsDir, "completion-replay"), "replay", { type: "result", key: "resultReplayAfter" }, "results.replay");
-	addFiles(path.join(request.resultsDir, "output-archives"), "archive", { type: "result", key: "resultArchiveAfter" }, "results.archive");
-
-	const cursorOps = [];
-	for (const key of ["runAfter", "resultPublicAfter", "resultReplayAfter", "resultArchiveAfter", "pendingSessionAfter"]) {
-		if (cursor[key] === request.cursor[key]) continue;
-		cursorOps.push(cursor[key] === undefined ? { type: "delete", key } : { type: "set", key, value: cursor[key] });
-	}
-	const oldPending = request.cursor.resultPendingAfterBySession ?? {};
-	const nextPending = cursor.resultPendingAfterBySession ?? {};
-	for (const session of new Set([...Object.keys(oldPending), ...Object.keys(nextPending)])) {
-		if (oldPending[session] === nextPending[session]) continue;
-		cursorOps.push(nextPending[session] === undefined
-			? { type: "delete-pending", session }
-			: { type: "set-pending", session, value: nextPending[session] });
-	}
-	return {
-		type: "result",
-		passId: request.passId,
-		discoveryDurationMs: Math.max(0, Date.now() - startedAt),
-		rawReads: raw.reads,
-		sourceExhausted: raw.exhausted,
-		runCandidates,
-		resultCandidates,
-		cursorOps,
-	};
-}
-
-if (!parentPort) throw new Error("Async retention discovery requires a worker parent port.");
-parentPort.on("message", (request) => {
-	const passId = request?.passId;
-	try {
-		parentPort.postMessage(discover(request));
-	} catch (error) {
-		parentPort.postMessage({ type: "error", passId, error: error instanceof Error ? error.message : String(error) });
-	}
-});

package/dist/extensions/pi-subagents/docs/agents.md

@@ -1,375 +0,0 @@
-# Agents
-
-An agent is a markdown file: YAML frontmatter on top, a system prompt below. The frontmatter defines the specialist that runs in the child Pi process.
-
-```yaml
----
-name: scout
-description: Fast codebase recon
-tools: read, grep, find, ls
----
-
-Your system prompt goes here.
-```
-
-## Where agents live
-
-Lowest to highest priority:
-
-| Scope | Path |
-|-------|------|
-| Builtin | `~/.selesai/agent/extensions/subagent/agents/` |
-| Installed package | `package.json` `pi-subagents.agents` or `pi.subagents.agents` |
-| User | `~/.selesai/agent/agents/**/*.md` |
-| Project | Project config `agents/**/*.md` (`.selesai/agents/**/*.md` in standard Pi) |
-
-Discovery notes:
-
-- Project discovery also reads legacy `.agents/**/*.md` files. If both `.agents/` and the project config agents directory define the same parsed runtime agent name, the project config directory wins.
-- Nested subdirectories are discovered recursively. `.chain.md` files do not define agents.
-- Installed Pi packages can expose agent directories from either `{"pi-subagents":{"agents":["./agents"]}}` or `{"pi":{"subagents":{"agents":["./agents"]}}}` in their package manifest. Package agents load above builtins and below user/project agents.
-- Use `agentScope: "user" | "project" | "both"` to control discovery. `both` is the default, and project definitions win runtime-name collisions.
-
-## Builtin agents
-
-Builtins load at the lowest priority, so a user or project agent with the same name overrides them. They do not pin a provider model; they inherit your current Pi default model unless you set `subagents.defaultModel` or `subagents.agentOverrides.<name>.model` (see [models.md](models.md)).
-
-| Agent | Use it when you want... |
-|-------|--------------------------|
-| `scout` | Fast local codebase recon: relevant files, entry points, data flow, risks, and where another agent should start. |
-| `researcher` | Web/docs research with sources: official docs, specs, benchmarks, recent changes, and a concise research brief. |
-| `worker` | Implementation work, including approved oracle handoffs. It edits files, validates, and escalates unapproved decisions instead of guessing. |
-| `reviewer` | Code review and small fixes. It checks the implementation against the task/plan, tests, edge cases, and simplicity. |
-| `oracle` | A second opinion before acting. It challenges assumptions, catches drift, and recommends the safest next move without editing. |
-| `delegate` | A lightweight general delegate when you want a child agent that behaves close to the parent session. |
-
-Rule of thumb: `scout` before you understand the code, `researcher` before you trust external facts, `worker` to implement, `reviewer` to check, and `oracle` when the decision itself feels risky.
-
-`oracle` is an advisory reviewer that critiques direction and proposes an execution prompt without editing files. `advisor` is the same bundled role under the Claude Code-compatible name.
-
-### Optional Surf integration
-
-When `surf-cli` is installed and loaded, Surf can expose a `gpt-pro` package agent through the `surf-oracle` external-job provider. It starts through the same `subagent({ agent: "gpt-pro" })` mental model as any other agent, but Surf owns the package agent and provider. Surf maps `model: pro` to ChatGPT GPT-5.6 Sol Pro web mode. pi-subagents does not own that model mapping.
-
-If you disabled the old bundled `gpt-pro` workaround with `agentOverrides.gpt-pro.disabled`, remove that override before using Surf's package agent.
-
-The Pi async run remains the source of truth for status, artifacts, wake/wait, mission attachment, retention, and diagnostics.
-
-### Advisory runner data boundary
-
-External CLI agents use their own runner contract. Do not pass native Pi child options such as model override, structured output, acceptance/agent contract, tool budgets, fast mode, fork context, skills, or native Pi tools unless the adapter explicitly implements them.
-
-The bundled code-owned external adapters (`codex-exec`, `claude-code`, `cursor-agent` and their writer variants) were removed in favor of the built-in Pi agents. A custom agent with `runner.type: external-cli` (no adapter) still runs the generic one-shot stdin contract: `command` is executed with the prompt on stdin, and the bounded final output is treated as untrusted text.
-
-### External-job state table
-
-| Durable file | Owner | States | Release predicate | Rollback predicate | Stale-head behavior | Fail-closed cases |
-|--------------|-------|--------|-------------------|--------------------|---------------------|-------------------|
-| `status.json` step `runner` and `externalJob` | pi-subagents async runner | `queued`, `running`, `completed`, `failed`, `stopped`, `blocked` | Provider `result` returns terminal data and the async result is written | Provider start/follow-up/status/result/reattach returns an error | If a status file already has a provider job id, recovery calls `reattach` and `result`; it refuses to start a new prompt when the provider, prompt digest, parent job id, request id, request digest, or options differ | Missing provider, unsupported follow-up provider, capacity conflict, malformed provider response, bridge timeout, prompt digest mismatch, parent conversation missing |
-| `result.json` or session result payload | pi-subagents async runner | `complete`, `failed`, `stopped` | All steps reach terminal state and result publication succeeds or is recoverably indexed | Result write fails and pending result repair records the terminal state | Stale status can repair from an existing result file | Unindexed sessionless stale failure |
-| `external-job-requests/` and `external-job-responses/` | Host-mediated provider bridge | pending request, terminal response | Host process writes a matching response and removes the request | Bridge timeout or malformed request response | Requests are operation-scoped. Recovery sends `reattach`/`result`, not `start` or `follow-up`, when job metadata exists. `start` and `follow-up` use durable dispatch claims | Provider not registered, host bridge not loaded, malformed request, provider exception, ambiguous dispatch without a provider job id |
-| Provider artifact path | External provider | provider-defined terminal artifact | Provider returns `artifactPath`, or Pi writes returned text to `external-job-<index>.result.md` | Provider reports failure or no result | Existing artifact path is retained in `status.json` | Missing artifact with no text output returns a terminal message instead of inventing content |
-
-The `researcher` builtin uses `web_search`, `fetch_content`, and `get_search_content`. Those require [pi-web-access](https://github.com/nicobailon/pi-web-access):
-
-```bash
-pi install npm:pi-web-access
-```
-
-## Overriding builtins
-
-You can override selected builtin fields without copying the whole agent. Overrides live in settings:
-
-- User: `~/.selesai/agent/settings.json`
-- Project: project config settings file (`.pi/settings.json` in standard Pi)
-
-```json
-{
-  "subagents": {
-    "agentOverrides": {
-      "reviewer": {
-        "description": "Independent review tier",
-        "inheritProjectContext": false
-      }
-    }
-  }
-}
-```
-
-Supported override fields: `description`, `output`, `outputMode`, `defaultReads`, `model`, `defaultProvider`, `fallbackModels`, `thinking`, `systemPromptMode`, `inheritProjectContext`, `inheritGlobalContext`, `inheritSkills`, `defaultContext`, `acceptanceRole`, `disabled`, `skills`, `tools`, and `systemPrompt`.
-
-- `description` replaces the discovered description for builtin and custom agents, which lets list output show deployment-specific routing or model metadata.
-- Use `output: false`, `defaultReads: false`, `defaultContext: false`, or `acceptanceRole: false` to clear an inherited value.
-- Use `tools: "inherit"` on a builtin when that one role should omit its bundled tool allowlist and receive Pi's normal builtins and ambient extensions. This keeps strict tools as the default for other builtins.
-- Project overrides beat user overrides.
-- Matching user and project agents also receive override fields that their frontmatter leaves unset, so a shared project config agent can keep the persona while local settings choose the model.
-
-Disable and restore:
-
-- `disabled: true` hides a builtin from runtime discovery and agent-facing `subagent({ action: "list" })` output.
-- `subagents.disableBuiltins: true` disables all builtins at once.
-- `subagent({ action: "disable", agent: "reviewer" })` writes the override without editing settings by hand; `subagent({ action: "enable", agent: "reviewer" })` removes it.
-- `subagent({ action: "eject", agent: "reviewer" })` copies a bundled builtin or package agent verbatim into the user or project agent dir (default `user`) as an editable custom file that shadows the original.
-- `subagent({ action: "reset", agent: "reviewer" })` deletes the scope's custom agent file and/or settings override entry, restoring the bundled default. It refuses if no bundled default exists (use `delete` for purely custom agents).
-
-`eject`, `disable`, `enable`, and `reset` accept `agentScope: "user" | "project"` and operate in one scope at a time. Project overrides still win over user ones, so a project-scope disable survives a user-scope `enable` until you target the project scope.
-
-## Prompt assembly
-
-Subagents are narrow by default. Custom agents start with a clean system prompt and only the context you intentionally give them. They do not automatically inherit Pi's whole base prompt, project instruction files, or discovered skills catalog.
-
-Use these fields when an agent should see more:
-
-| Field | Effect |
-|-------|--------|
-| `systemPromptMode: append` | Append the agent prompt to Pi's normal base prompt. |
-| `inheritProjectContext: true` | Keep inherited repository instructions from files like `AGENTS.md` and `CLAUDE.md`. |
-| `inheritGlobalContext: true` | Also keep the operator's global context file from the Pi config agent directory (such as `~/.selesai/agent/AGENTS.md`). Defaults to `false`. |
-| `inheritSkills: true` | Let the child see Pi's discovered skills catalog. |
-| `defaultContext: fork` | Prefer forked session context when a launch omits `context`; if the parent has no persisted session file or current leaf yet, the implicit default falls back to `fresh` without a failed first attempt. Explicit `context: "fork"` remains strict, and explicit `context: "fresh"` still wins. |
-
-Builtin agents opt into repository instruction inheritance by default so they follow repo-specific rules out of the box, but global context remains excluded unless `inheritGlobalContext: true` is set. This changes the behavior of existing agents that previously received global context as part of `inheritProjectContext: true`. `delegate` also uses append mode because its job is orchestration inside the parent workflow.
-
-## Frontmatter reference
-
-A full example:
-
-```yaml
----
-name: scout
-# Optional: registers this as code-analysis.scout while preserving name: scout
-package: code-analysis
-description: Fast codebase recon
-aliases: explorer, code-scout
-tools: read, grep, find, ls, bash, mcp:chrome-devtools
-extensions:
-subagentOnlyExtensions: ./tools/child-only-search.ts
-model: claude-haiku-4-5
-fallbackModels: openai-codex/gpt-5.6-luna:low, anthropic/claude-sonnet-4
-thinking: high
-systemPromptMode: replace
-inheritProjectContext: false
-inheritGlobalContext: false
-inheritSkills: false
-skills: safe-bash, review-checklist
-skillPath: ./skills, ../shared-skills
-output: context.md
-defaultReads: context.md
-defaultProgress: true
-async: true
-timeoutMs: 900000
-toolTimeoutMs: 600000
-acceptance: {"level":"none","reason":"lightweight lookup"}
-acceptanceRole: read-only
-completionGuard: false
-interactive: true
-maxSubagentDepth: 1
-allowNestedSubagents: true
----
-
-Your system prompt goes here.
-```
-
-Simple-scalar list fields accept either a comma-separated form or a newline block list with one `- item` per line. This applies to `tools`, `defaultReads`, `skill`/`skills`, `skillPath`, `fallbackModels`, `extensions`, and `subagentOnlyExtensions`:
-
-```yaml
-tools:
-  - read
-  - mcp:github/search_repositories
-fallbackModels:
-  - openai-codex/gpt-5.6-luna:low
-  - anthropic/claude-sonnet-4
-```
-
-Field notes:
-
-| Field | Notes |
-|-------|-------|
-| `package` | Optional package identifier. A file with `name: scout` and `package: code-analysis` registers as `code-analysis.scout`; serialization keeps `name` and `package` separate. |
-| `aliases` | Optional comma-separated or block-list names that resolve to this agent for selection and explicit `agent` and task inputs. Runtime status, persistence, and config still use the canonical `name`. Exact canonical names take precedence over aliases, and alias collisions between distinct canonical agents fail as ambiguous. |
-| `tools` | Strict child tool allowlist. Named extension tools must also have their provider loaded. `mcp:` entries select direct MCP tools when `pi-mcp-adapter` is installed. |
-| `allowNestedSubagents` | Set `true` to authorize the child-safe nested `subagent` runtime without making omitted `tools` an allowlist. Inherited depth and capability ceilings remain authoritative. |
-| `extensions` | Omitted means normal extensions; empty means no extensions; list values allowlist specific extensions. |
-| `subagentOnlyExtensions` | Extension paths loaded only in spawned child sessions for this agent. Tools registered there are unavailable to the main agent unless also installed through normal Pi extension configuration. |
-| `model` | Default model. Bare ids prefer the current provider when possible, then unique registry matches. |
-| `fallbackModels` | Ordered backup models for provider/model failures such as quota, auth, provider-reported timeout, or unavailable model. Expiration of the run-level `timeoutMs` / `maxRuntimeMs` deadline is terminal and does not trigger fallback. Ordinary task failures do not trigger fallback. |
-| `thinking` | Appended as a `:level` suffix at runtime unless a suffix is already present. |
-| `systemPromptMode` | `replace` by default; `append` keeps Pi's base prompt. |
-| `inheritProjectContext` | Keeps or strips inherited repository instruction blocks. |
-| `inheritGlobalContext` | Keeps or strips the operator's global context file from the Pi config agent directory (e.g. `~/.selesai/agent/AGENTS.md`). It has an effect only when `inheritProjectContext` is `true`; otherwise all context files are already disabled. Defaults to `false`. |
-| `inheritSkills` | Keeps or strips Pi's discovered skills catalog. |
-| `defaultContext` | Optional `fresh` or `fork` launch-context preference. An implicit `fork` falls back to `fresh` when the parent has no persisted session file or current leaf; an explicit launch `context: "fork"` remains strict. |
-| `skills` | Selects specific skills for the child, regardless of `inheritSkills`. |
-| `skillPath` | Invocation-private skill files or discovery directories. Relative paths resolve from the agent definition file. Local matches take precedence, while unresolved or unreadable matches fall back to normal skill discovery. This field discovers candidates only; `skills` still selects what the child receives. |
-| `output` | Default single-agent output file. |
-| `defaultReads` | Files to read before running the agent. |
-| `defaultProgress` | Maintain `progress.md`. |
-| `async` | Default a single-agent launch to background (`true`) or foreground (`false`) when the call omits `async`. Explicit call values and `forceTopLevelAsync` win. |
-| `timeoutMs` | Positive integer default runtime deadline in milliseconds for single-agent launches. Foreground launches use 30 minutes when neither the call nor agent provides a timeout; explicit `timeoutMs`/`maxRuntimeMs` and agent defaults win. |
-| `toolTimeoutMs` | Optional positive integer hard per-tool-call deadline in milliseconds. An explicit call value wins, then this agent default, global `toolTimeoutMs`, and `SELESAI_SUBAGENT_TOOL_TIMEOUT_MS`. When omitted, known-fast built-in tools get a five-minute default; long-running tools get attention notices but no hard default. It does not extend the run-level deadline; `contact_supervisor`, `intercom`, `bg_wait`, and the deprecated `subagent_wait` alias are exempt. |
-| `acceptance` | Acceptance default for single-agent launches. Use a scalar level such as `checked` or an inline/block YAML map such as `{ level: "none", reason: "lightweight lookup" }`. Explicit call values win; chain and parallel acceptance remains task/step configuration. |
-| `acceptanceRole` | Optional `read-only` or `writer` role for automatic acceptance inference. Explicit task mutation or no-edit intent wins; otherwise the declared role replaces agent-name guessing. This does not grant or revoke tools. |
-| `mutationTools` | Comma-separated extension tool names whose calls count as mutation attempts for the completion guard. This declares evidence only; list and load each tool through `tools` and its extension provider as usual. |
-| `completionGuard` | Set `false` only for non-implementation agents that may mention implementation words while using mutation-capable tools such as `bash`. |
-| `interactive` | Parsed for compatibility but not currently enforced. |
-| `maxSubagentDepth` | Tightens nested delegation for this agent's children. |
-| `memory` | Opt-in role-specific persistent memory. See below. |
-
-## Per-agent persistent memory
-
-A recurring custom agent can opt into a durable, role-specific memory scope with the `memory` frontmatter field:
-
-```yaml
-memory:
-  scope: project
-  path: security-reviewer
-```
-
-This is independent of Pi's own parent/session/project memory system and writes nothing to it. Memory lives under a dedicated `agent-memory/` namespace so the two never collide.
-
-How it works:
-
-- On each run, the first 200 lines of `MEMORY.md` in the resolved memory directory are injected into the child system prompt, so the agent can recall accumulated role notes such as threat-model entries, release gotchas, or verified commands.
-- Agents with write tools (`edit`, `write`, or `bash`, or no `tools` allowlist at all) are told they may append concise dated entries to the file.
-- Agents without write tools receive a read-only memory block and are not instructed to edit it. A read-only reviewer can recall prior notes without gaining write capability.
-- The memory directory is never created eagerly. The agent's own `write` tool creates it (and `MEMORY.md`) on the first persist.
-- Memory paths are validated against `.`/`..` traversal and symlink escape. An unsafe or unresolvable scope is silently skipped rather than breaking the run.
-
-Scopes:
-
-- Project: resolves under `<project>/.selesai/agent-memory/<path>` and travels with the repo.
-- User: resolves under `~/.selesai/agent/agent-memory/<path>` and is shared across projects for that agent.
-
-## Refinement overlays
-
-A refinement overlay is bounded, project-local guidance layered on top of one agent's system prompt without editing the agent file. Use it when an agent repeatedly stumbles on the same project-specific issue and recent run evidence shows what to correct.
-
-```text
-/subagents-refine reviewer
-```
-
-```ts
-subagent({ action: "refine", agent: "reviewer" })
-subagent({ action: "refine.show", agent: "reviewer" })
-subagent({ action: "refine.rollback", agent: "reviewer" })
-```
-
-How it works:
-
-- `refine` collects bounded evidence from that agent's recent runs in the project (statuses, errors, review findings, residual risks, output tails), then launches a fresh read-only proposal child to draft small guidance edits from that evidence.
-- Proposed guidance is validated before it is written. Edits that try to override safety, policy, tool, output, acceptance, developer, or system instructions are rejected, as are edits that target all agents or base agent files.
-- The accepted overlay is stored at `.pi-subagents/refinements/<agent>.md` with revision metadata and snapshots. Each `refine` or `refine.rollback` adds a snapshot, and `refine.rollback` restores the previous revision.
-- At launch, the current overlay is injected into that agent's child system prompt as a `<pi-subagents-refinement>` block scoped to this project. The base agent definition is never modified.
-
-`refine.show` prints the current overlay and revision history. Delete the overlay file to remove the refinement entirely.
-
-## Tool and extension selection
-
-How `tools` behaves:
-
-- `tools` omitted: `pi-subagents` does not pass `--tools`, so the child gets Pi's normal builtin tools.
-- `tools` present: regular tool names become an explicit allowlist.
-- `tools:` empty: emits `--no-tools`.
-- `allowNestedSubagents: true`: explicitly enables child-safe nested fanout without turning omitted `tools` into an allowlist. Depth and inherited capability ceilings still apply.
-
-An allowlisted name does not load the extension that registers it. Load that provider through normal Pi extension discovery, `extensions`, `subagentOnlyExtensions`, or a path-like `tools` entry.
-
-More rules:
-
-- `mcp:` entries are split out and forwarded as direct MCP selections without granting normal builtins unless those builtins are also listed.
-- Path-like `tools` entries, such as extension paths or `.ts`/`.js` files, are treated as tool-extension paths rather than tool names.
-- Internal runtime tools such as `structured_output` are added to an explicit allowlist only when their contract is active.
-- Unknown extension tool calls count as mutation attempts only when their names are listed in `mutationTools`; undeclared unknown tools keep the no-edit guard active.
-- Agents that declare only known read-only builtin tools skip the implementation completion guard. `bash`, unknown tools, and MCP tools stay mutation-capable. Use `completionGuard: false` for bash-enabled validators or advisors that should never be judged as implementation agents.
-
-Examples:
-
-- `tools` omitted and `extensions` omitted: normal builtins and normal extensions.
-- `tools: mcp:chrome-devtools`: only the resolved direct Chrome DevTools MCP tools.
-- `tools: read, bash, mcp:chrome-devtools`: only `read` and `bash` as builtins, plus direct Chrome DevTools MCP tools.
-- `tools: subagent, read`: a child-safe `subagent` tool is available inside that child so it can run explicitly assigned nested fanout.
-- `allowNestedSubagents: true` with `tools` omitted: normal builtin tools and ambient extensions remain inherited, and the child-safe nested `subagent` runtime is added.
-- `tools: read, fixture_search` plus `subagentOnlyExtensions: ./tools/fixture-search.ts`: the provider loads only in this agent's child process, and the registered `fixture_search` name survives the strict allowlist.
-
-Direct MCP tools require [pi-mcp-adapter](https://github.com/nicobailon/pi-mcp-adapter). Subagents only receive direct MCP tools when `mcp:` entries are listed in their frontmatter; global `directTools: true` in `mcp.json` is not enough by itself. The generic `mcp` proxy tool can still be used for discovery when available. The adapter caches tool metadata at startup, so after connecting a new MCP server for the first time, restart Pi before relying on direct tools. Server `includeTools` and `excludeTools` policies are enforced while resolving cached metadata for children: both accept exact names and `*`/`?` glob patterns against raw, generated-resource, and server/short/none-prefixed names, with `excludeTools` taking precedence. An `mcp:` entry named `subagent` does not authorize nested fanout; declare the builtin `subagent` tool or set `allowNestedSubagents: true`. If a resolved direct MCP name is missing from the child registry, pi-subagents keeps the launch failed under the strict allowlist and identifies the condition as a host/pi-mcp-adapter registration problem; verify that the adapter registers the selected tools before child startup.
-
-`extensions` controls child extension loading:
-
-```yaml
-# Omitted: all normal extensions load
-
-# Empty: no extensions
-extensions:
-
-# Allowlist
-extensions: /abs/path/to/ext-a.ts, /abs/path/to/ext-b.ts
-```
-
-When `extensions` is present, normal discovered extensions are disabled. The listed extensions, path-like `tools` entries, required pi-subagents runtime extensions, and `subagentOnlyExtensions` still load.
-
-Use `subagentOnlyExtensions` when a custom extension tool should exist only inside child sessions. It is scoped by agent config: every run of that agent receives those extension paths, while other agents do not unless they declare the same field. The current model does not have a separate named-subagent audience inside one agent definition.
-
-To apply the same `extensions` allowlist to every agent that does not declare its own, set `subagents.defaultExtensions` in user or project settings (see [configuration.md](configuration.md)).
-
-Before the first model turn, the child runtime compares every explicit tool name with Pi's final filtered registry. A missing provider fails the run with the unavailable names and concrete `subagentOnlyExtensions`/`extensions` guidance, instead of letting a direct or chained child silently continue without its requested tools.
-
-## Skills
-
-Skills are `SKILL.md` files made available to an agent. The prompt includes skill metadata and the file location; the agent reads the full skill file only when the task matches.
-
-Discovery uses project-first precedence:
-
-1. Project config `skills/{name}/SKILL.md` (`.pi/skills/{name}/SKILL.md` in standard Pi)
-2. Project packages and project settings packages via `package.json -> pi.skills`
-3. Current task cwd package via `package.json -> pi.skills`
-4. Project config `settings.json -> skills`
-5. `~/.selesai/agent/skills/{name}/SKILL.md`
-6. User packages and user settings packages via `package.json -> pi.skills`
-7. `~/.selesai/agent/settings.json -> skills`
-
-Use agent defaults, override them at runtime, or disable them:
-
-```ts
-{ workflowScript: `return runs.run("main", { agent: "scout", task: "..." })` }
-{ workflowScript: `return runs.run("main", { agent: "scout", task: "...", skill: "tmux, safe-bash" })` }
-{ workflowScript: `return runs.run("main", { agent: "scout", task: "...", skill: false })` }
-```
-
-For chains, `skill` at the top level is additive. A step-level `skill` overrides that step; `false` disables skills for that step.
-
-Available skills use this shape in the child prompt:
-
-```xml
-The following configured skills are available to this subagent.
-Use the read tool to load a skill's file when the task matches its description.
-When a skill file references a relative path, resolve it against the skill directory (parent of SKILL.md / dirname of the path) and use that absolute path in tool commands.
-
-<available_skills>
-  <skill>
-    <name>safe-bash</name>
-    <description>Run shell commands safely.</description>
-    <location>/absolute/path/to/safe-bash/SKILL.md</location>
-  </skill>
-</available_skills>
-```
-
-If an agent has an explicit `tools` allowlist and resolved skills, `read` is added for that child run so the listed skill files can be loaded on demand.
-
-Missing skills do not fail execution. The result summary shows a warning.
-
-Agent-local `skillPath` candidates never enter Pi's parent/global skills catalog. Pair `inheritSkills: false` with explicit `skills` and `skillPath` when a child should receive only its selected private skills.
-
-## The bundled pi-subagents skill
-
-The package bundles a `pi-subagents` skill that is automatically available to the parent agent when the extension is installed. It is for the orchestrating parent only: child subagents never receive it, and their context is explicitly filtered to strip parent-only orchestration instructions.
-
-What it covers:
-
-- **Delegation patterns**: when to launch which agent, whether to use single, parallel, chain, or async mode, and whether to use fresh or forked context.
-- **Prompt workflow recipes**: how to apply the packaged techniques directly with `subagent(...)` when the user describes the workflow in natural language instead of invoking a slash command. This includes parallel review, review-loop, parallel research, parallel context-build, parallel handoff-plan, gather-context-and-clarify, and parallel cleanup.
-- **Role-agent prompting guidance**: compact contract prompts instead of long scripts, what to include in role-specific meta prompts, and retrieval budgets for researchers.
-- **Safety boundaries**: child agents must not run subagents unless their resolved builtin tools explicitly include `subagent`, must not invent intercom targets, and must escalate unapproved decisions.
-- **Intercom conventions**: when to ask vs send, and how parent-side supervisor/result delivery works through the native channel.
-- **Control and diagnostics**: attention signals, soft interrupts, status, and the `doctor` action.
-
-If you are writing an agent that orchestrates subagents, the bundled skill helps it behave correctly without guessing the patterns. If you are a human user, you do not need to read it; the README and prompt shortcuts encode the same workflows in user-facing form.