/**
 * Build the argv for a governed descendant pi process.
 *
 * 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,
 * 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.
 */
import { type Capability } from "./resolve.ts";
export interface SpawnPlanInput {
    effective: Capability[];
    prompt: string;
    model?: string;
    provider?: string;
    thinking?: string;
    /** Session file path, or omit for an ephemeral child. */
    sessionFile?: string;
    /**
     * `context: fork` (ADR-0078): the parent session to fork, and the private directory the fork is written to.
     *
     * These replace `sessionFile` rather than joining it, because pi refuses `--fork` beside `--session` or
     * `--no-session` (measured in its own argument validation). `--session-id` is accepted beside `--fork`, and it is
     * what makes the forked file findable afterwards: pi names it `<timestamp>_<id>.jsonl` inside the session
     * directory, and only the id half is ours to choose.
     */
    forkFrom?: {
        sessionPath: string;
        sessionDir: string;
        sessionId: string;
    };
    /**
     * Fenced context from the parent, appended to the child's system prompt after the definition body (ADR-0078).
     *
     * Separate from `systemPrompt` because the two have different provenance and the child is told so: a definition
     * body is operator-authored text the grant names, this is what the parent chose to pass on. Kept as its own
     * `--append-system-prompt`, which pi accepts more than once.
     */
    contextPrompt?: string;
    /** Non-interactive by default: a governed child should not prompt a human. */
    print?: boolean;
    /**
     * Absolute path per skill NAME (`review` -> `/…/review`), as the catalog discovered them.
     *
     * R-32. Only skills named by a `skill:` capability in `effective` are passed, and a granted skill
     * absent from this map is reported in `unresolvedSkills` rather than dropped.
     */
    skillPaths?: Record<string, string>;
    /**
     * Let the child load `AGENTS.md` / `CLAUDE.md`. **Default false** — see the `--no-context-files`
     * note in `planSpawn`.
     */
    contextFiles?: boolean;
    /**
     * Instructions appended to the child's system prompt — a definition's `SKILL.md` body (ADR-0016).
     *
     * Appended rather than replacing, so pi's own coding-assistant prompt survives underneath and a
     * definition only has to describe its own job.
     */
    systemPrompt?: string;
}
export interface SpawnPlan {
    args: string[];
    /** The tool names pi will allow, for the ledger. `null` means no tools at all. */
    allowlist: string[] | null;
    /** Skill paths handed to the child, for the ledger. */
    skills: string[];
    /**
     * Granted `skill:` capabilities with no known path. **Non-empty means the caller should refuse**:
     * the child would silently lack a capability its grant says it holds.
     */
    unresolvedSkills: Capability[];
}
/**
 * Produce `pi` arguments enforcing `effective`.
 *
 * Note the `--no-tools` branch: pi rejects an empty `--tools` list, and passing no flag at all would
 * silently fall back to pi's defaults — which is the opposite of a zero grant. An empty grant must be
 * expressed explicitly.
 */
export declare function planSpawn(input: SpawnPlanInput): SpawnPlan;
//# sourceMappingURL=spawn.d.ts.map