@bastani/atomic 0.9.15 → 0.9.16-alpha.2

package/dist/builtin/subagents/prompts/parallel-handoff-plan.md

@@ -1,47 +0,0 @@
----
-description: Parallel external + local research builders into an implementation handoff plan
----
-
-## Goal
-
-Produce a grounded implementation handoff plan and implementation-ready meta-prompt by comparing applicable external evidence, local behavior, established patterns, and prior decisions.
-
-Primary request, target, or focus:
-
-$@
-
-## Constraints and tools
-
-First read or fetch every URL, issue, PR, screenshot, plan, doc, or local file named in the request; these define primary scope. Use a top-level parallel call with `context: "fresh"` unless I explicitly request forked context, then synthesize parent-side rather than launching a synthesizer subagent.
-
-Choose specialists by evidence need:
-
-- Use `codebase-online-researcher` when external projects, libraries, docs, APIs, recent changes, or best practices could shape the plan. It should inspect linked projects, docs, issues, examples, source, or prompt guidance; identify behavior, APIs, implementation files, constraints, and transferable ideas; use `fetch_content` first, then `/llms.txt`, then `Accept: text/markdown`, and fall back to `playwright-cli` only for required JS or auth; persist high-value sources to `research/web/<YYYY-MM-DD>-<topic>.md`; and return links, repo paths, evidence, risks, and implementation implications.
-- Use `codebase-locator` for non-trivial code changes to map relevant local files, tests, fixtures, and configs by purpose.
-- Use `codebase-analyzer` when local behavior matters to trace the located implementation, control flow, transformations, and constraints with `file:line` citations. Locator and analyzer cover where the work lives and how it works without overlap.
-- Add `codebase-pattern-finder` when analogous implementations or conventions could shape the plan; include useful snippets with `file:line` references.
-- Add `codebase-research-locator` then `codebase-research-analyzer` when prior `research/` or `specs/` may apply. The locator finds relevant dated docs; the analyzer extracts current decisions, constraints, and lessons while flagging superseded guidance. Run them sequentially, or pair them in the parallel step with distinct outputs when the dependency is already resolved.
-
-Give tasks distinct `output` paths, for example:
-
-- `handoff/external-reference.md`
-- `handoff/local-files.md`
-- `handoff/local-flow.md`
-- `handoff/local-patterns.md`
-- `handoff/prior-research.md`
-
-In synthesis, use the saved task outputs when available. Do not persist these artifacts in the repository unless I explicitly request it.
-
-Delegate only independent work too large for a handful of tool calls; do not delegate auditing your own work, and prefer one subagent over several. Parallelize independent reads; stay sequential when one result determines the next; synthesize after retrieval. Keep work within the requested scope.
-
-## Output
-
-Compare external evidence with local architecture and write `handoff/final-handoff-plan.md` yourself, or summarize inline when no persisted artifact was requested. The downstream writer needs roughly 700–1,200 words covering: intended behavior; lessons from external references; local implications; recommended approach; likely files; constraints and non-goals; edge cases, validation commands, risks, and approval decisions; unresolved questions; and a compact implementation-ready meta-prompt.
-
-Then give the user a concise summary with the recommendation, artifact paths, final meta-prompt, and remaining questions or assumptions. Lead with the outcome; keep facts, decisions, caveats, and next steps; drop background and repetition; stay readable rather than compressed into fragments.
-
-Before reporting progress, audit each claim against a tool result from this session. Report only work you can point to evidence for; say so explicitly when something is unverified.
-
-## Stop rule
-
-Done means discovery evidence has been compared, the final handoff exists at the requested destination or inline, and the user has the recommendation, paths, meta-prompt, and unresolved decisions. Do not start implementation unless I explicitly ask.

package/dist/builtin/subagents/prompts/parallel-research.md

@@ -1,34 +0,0 @@
----
-description: Parallel research specialists for grounded answers
----
-
-## Goal
-
-Build a grounded answer to the current question or decision from distinct external, local, convention, or prior-decision evidence.
-
-Primary question or focus:
-
-$@
-
-## Constraints and tools
-
-Use fresh context unless I explicitly request forked context; specialists inspect sources directly rather than relying on the main conversation. Choose two or three strong specialists with distinct applicable angles, using my specified angles when provided:
-
-- **External evidence — `codebase-online-researcher`:** current authoritative sources such as official docs, standards, release notes, benchmarks, issue threads, and primary explanations.
-- **Local context — `codebase-locator` and/or `codebase-analyzer`:** relevant repository files and how they work, with `file:line` references.
-- **Local conventions — `codebase-pattern-finder`:** analogous implementations and patterns the answer should respect.
-- **Prior decisions — `codebase-research-locator` then `codebase-research-analyzer`:** applicable decisions and constraints from `research/` or `specs/`, with locator preceding analyzer.
-
-For library/API questions, include official docs and recent examples. For architecture decisions, cover module boundaries and dependency direction. For debugging, cover call paths and authoritative information about the error. For UI/product questions, cover analogous components and design precedent. For time-sensitive topics, have the online researcher prefer 2026/2025 sources and persist findings to `research/web/`.
-
-This is read-only research unless I explicitly request implementation. Delegate only independent work too large for a handful of tool calls; do not delegate auditing your own work, and prefer one subagent over several. Parallelize independent reads; stay sequential when one result determines the next; synthesize after retrieval. Keep work within the requested scope.
-
-## Output
-
-Each specialist returns concise evidence: local paths and line ranges or external links, confidence and gaps, and the decision implication or next step. Synthesize a user-facing answer of roughly 400–800 words covering what is known, local implications, tradeoffs and risks, gaps or assumptions, and the recommended move. Name disagreements rather than smoothing them over. Lead with the outcome; keep facts, decisions, caveats, and next steps; drop background and repetition; stay readable rather than compressed into fragments.
-
-Before reporting progress, audit each claim against a tool result from this session. Report only work you can point to evidence for; say so explicitly when something is unverified.
-
-## Stop rule
-
-Done means applicable specialists have returned direct evidence and the synthesis answers the question, identifies material uncertainty or disagreement, and recommends the next move. Do not edit files unless implementation was explicitly requested.

package/dist/builtin/subagents/prompts/parallel-review.md

@@ -1,47 +0,0 @@
----
-description: Parallel specialist review of the current work
----
-
-## Goal
-
-Produce an adversarial, evidence-backed review of the current work, separating fixes worth doing now from optional or inapplicable feedback. Apply fixes only when authorized.
-
-Additional review target or focus from the slash command invocation:
-
-$@
-
-If this supplies a URL, issue, file, plan, or freeform focus, treat it as primary scope: read or fetch it before assigning angles and pass it into every specialist task.
-
-## Constraints and tools
-
-Use fresh context unless I explicitly request forked context. Specialists inspect repository instructions, relevant files, and the current diff through direct reads and commands, not main-conversation history. There is no generic `reviewer`; choose read-only specialists with distinct angles derived from user intent, the plan, implementation, and diff. Use my angles when supplied; otherwise select three applicable angles:
-
-- **Correctness and regressions — `codebase-analyzer`:** trace the diff and surrounding flow against the request, preserved behavior, edge cases, and hidden runtime failures; cite `file:line` for every claim.
-- **Bug and failure modes — `debugger`:** reproduce relevant behavior where possible, assess how the suspect diff could break, and report evidence.
-- **Pattern fit — `codebase-pattern-finder`:** compare analogous code and conventions, identifying structural drift or missed reuse with `file:line` snippets.
-- **Prior constraints — `codebase-research-locator` then `codebase-research-analyzer`:** surface applicable research or specs and the decisions the change must honor.
-- **External conformance — `codebase-online-researcher`:** compare an external API, RFC, or library contract with its authoritative source.
-
-Use `/parallel-cleanup` instead for simplicity, slop, or verbosity angles. Every specialist gets a task naming its angle and returns concise review findings with evidence, `file:line`, and suggested fixes—not a context summary. Every specialist is read-only, including agent types that can edit. While they run, perform a narrow inspection if useful.
-
-Synthesize fixes worth doing now, optional improvements, and ignored or deferred feedback with a short reason; assess findings rather than applying them blindly. Delegate only independent work too large for a handful of tool calls; do not delegate auditing your own work, and prefer one subagent over several. Parallelize independent reads; stay sequential when one result determines the next; synthesize after retrieval. Keep work within the requested scope.
-
-In **autofix** mode, an invocation containing the exact word `autofix` uses it as workflow control, not review scope; remove it before identifying the target. After synthesis, launch one foreground writer—`debugger` for correctness/regression fixes or `code-simplifier` for cleanup-shaped feedback—with only the explicit fixes-worth-doing-now list as scope. Validate and summarize. Do not apply optional improvements unless explicitly requested; if no fixes are worth doing now, do not edit.
-
-Without autofix mode, ask before applying fixes unless I already authorized addressing review feedback. End that request with a compact numbered menu, including when applicable:
-
-```text
-Reply with [1], [2], or further instructions:
-[1] Apply only the fixes worth doing now.
-[2] Apply the fixes worth doing now plus optional improvements.
-```
-
-## Output
-
-Return a concise, user-facing review of roughly 400–800 words: outcome, evidence-backed fixes worth doing now, optional improvements, ignored or deferred feedback with reasons, and any authorized edits and validation. Lead with the outcome; keep facts, decisions, caveats, and next steps; drop background and repetition; stay readable rather than compressed into fragments.
-
-Before reporting progress, audit each claim against a tool result from this session. Report only work you can point to evidence for; say so explicitly when something is unverified.
-
-## Stop rule
-
-Done means the specialist evidence has been assessed and synthesized, then either authorized fixes were validated, no worthwhile fixes exist, or the numbered approval menu was presented. Stop without editing when authorization is absent.

package/dist/builtin/subagents/prompts/review-loop.md

@@ -1,39 +0,0 @@
----
-description: Specialist review/fix loop until clean
----
-
-## Goal
-
-Run a parent-orchestrated review-and-fix loop for the requested work until the current scope is clean, blocked on an unapproved decision, or capped. The parent controls the loop and makes final decisions; children receive concrete role-specific tasks and must not launch subagents or manage the loop.
-
-Additional target, implementation request, max-iteration cap, or review focus from the slash command invocation:
-
-$@
-
-## Constraints and tools
-
-Use the `subagent` tool and specialist roles rather than a generic worker or reviewer. Use one writer per pass: `debugger` for bugs, correctness/regression fixes, or behavior changes; `code-simplifier` for cleanup, refinement, or simplification. Reviewer options are `codebase-analyzer` for correctness and flow, `debugger` in inspect-only mode for failure modes, `codebase-pattern-finder` for consistency, `codebase-online-researcher` for external conformance, and `codebase-research-locator` then `codebase-research-analyzer` for prior decisions.
-
-Default to at most 3 review rounds unless I set another cap. A round is a fresh-context inspection of the current diff after a writer pass.
-
-If the invocation requests implementation, first launch one foreground writer for the approved scope: `debugger` for correctness-shaped work or `code-simplifier` for refinement-shaped work. If the current diff is already the target, begin with review. Continue with follow-up runs after each completion. Because launches are non-interactive, resolve questions with me first. Use one writer against the active worktree at a time unless I explicitly request isolated worktrees.
-
-Each review round uses fresh context. Reviewers inspect repository instructions, relevant files, and the current diff directly, without main-conversation history, and cannot edit; explicitly put `debugger` in inspect-only mode. Choose angles from the change. Common angles are correctness/regressions, failure modes, and pattern fit; add external-spec or prior-decision coverage when applicable. Prefer three strong reviewers over many vague ones.
-
-Delegate only independent work too large for a handful of tool calls; do not delegate auditing your own work, and prefer one subagent over several. Parallelize independent reads; stay sequential when one result determines the next; synthesize after retrieval. Keep work within the requested scope.
-
-After each round, synthesize blockers or scope/product/architecture decisions needing approval, fixes worth doing now, optional improvements, and feedback to ignore or defer with a short reason. Assess findings rather than applying them blindly. Pause for my approval before a writer acts on any unapproved product, scope, or architecture decision.
-
-The implementation writer's handoff transitions into review; it is not final completion unless I requested writer-only work, review-only output, or a stop after implementation. When implementation is authorized and fixes are worth doing now, launch one foreground writer to apply only the synthesized fixes—`debugger` for correctness or `code-simplifier` for cleanup. Require it to preserve approved scope, run focused validation, and report changed files, commands with exit codes, validation evidence, surprises, and unfinished work.
-
-Run another review round after a fix only when it made material changes or addressed non-trivial findings. Do not loop for optional polish, speculative improvements, or already deferred findings.
-
-## Output
-
-On completion, inspect the final diff and run or confirm appropriate focused validation. Return a concise, user-facing summary of roughly 300–700 words: why the loop stopped, rounds run, fixes applied, validation, remaining blockers or deferred items, and next steps. Lead with the outcome; keep facts, decisions, caveats, and next steps; drop background and repetition; stay readable rather than compressed into fragments.
-
-Before reporting progress, audit each claim against a tool result from this session. Report only work you can point to evidence for; say so explicitly when something is unverified.
-
-## Stop rule
-
-Stop and summarize when reviewers find no blockers or fixes worth doing now; remaining feedback is optional, speculative, or intentionally deferred; an unapproved decision needs me; or the review-round cap is reached. The loop is done only after the final diff and focused validation have been inspected or explicitly reported as unverified.

package/dist/builtin/subagents/src/extension/doctor.ts

@@ -1,188 +0,0 @@
-import * as fs from "node:fs";
-import * as path from "node:path";
-import { type AgentSource, discoverAgentsAll } from "../agents/agents.js";
-import { discoverAvailableSkills, type SkillSource } from "../agents/skills.js";
-import { diagnoseIntercomBridge, type IntercomBridgeDiagnostic } from "../intercom/intercom-bridge.js";
-import { type ExtensionConfig, type SubagentState, TEMP_ROOT_DIR } from "../shared/types.js";
-
-interface DoctorPaths {
-	tempRootDir: string;
-}
-
-interface DoctorDeps {
-	discoverAgentsAll: typeof discoverAgentsAll;
-	discoverAvailableSkills: typeof discoverAvailableSkills;
-	diagnoseIntercomBridge: typeof diagnoseIntercomBridge;
-}
-
-interface DoctorReportInput {
-	cwd: string;
-	config: ExtensionConfig;
-	state: SubagentState;
-	context?: "fresh" | "fork";
-	requestedSessionDir?: string;
-	currentSessionFile?: string | null;
-	currentSessionId?: string | null;
-	orchestratorTarget?: string;
-	sessionError?: string;
-	expandTilde?: (value: string) => string;
-	paths?: DoctorPaths;
-	deps?: Partial<DoctorDeps>;
-}
-
-const DEFAULT_PATHS: DoctorPaths = { tempRootDir: TEMP_ROOT_DIR };
-
-const DEFAULT_DEPS: DoctorDeps = {
-	discoverAgentsAll,
-	discoverAvailableSkills,
-	diagnoseIntercomBridge,
-};
-
-function errorText(error: unknown): string {
-	return error instanceof Error ? `${error.name}: ${error.message}` : String(error);
-}
-
-function lineFromCheck(label: string, check: () => string): string {
-	try {
-		return check();
-	} catch (error) {
-		return `- ${label}: failed — ${errorText(error)}`;
-	}
-}
-
-function formatExistingDirectory(label: string, dirPath: string): string {
-	try {
-		if (!fs.existsSync(dirPath)) return `- ${label}: missing (${dirPath})`;
-		const stats = fs.statSync(dirPath);
-		if (!stats.isDirectory()) throw new Error(`not a directory: ${dirPath}`);
-		fs.accessSync(dirPath, fs.constants.R_OK | fs.constants.W_OK);
-		return `- ${label}: ok (${dirPath})`;
-	} catch (error) {
-		return `- ${label}: failed (${dirPath}) — ${errorText(error)}`;
-	}
-}
-
-function formatSourceCounts(counts: Record<AgentSource, number>): string {
-	return `builtin ${counts.builtin}, user ${counts.user}, project ${counts.project}`;
-}
-
-function formatSkillSourceCounts(skills: Array<{ source: SkillSource }>): string {
-	const counts = new Map<SkillSource, number>();
-	for (const skill of skills) counts.set(skill.source, (counts.get(skill.source) ?? 0) + 1);
-	const ordered: SkillSource[] = [
-		"project",
-		"project-settings",
-		"project-package",
-		"user",
-		"user-settings",
-		"user-package",
-		"extension",
-		"builtin",
-		"unknown",
-	];
-	const parts = ordered.map((source) => `${source} ${counts.get(source) ?? 0}`).filter((part) => !part.endsWith(" 0"));
-	return parts.length > 0 ? parts.join(", ") : "none";
-}
-
-function formatConfiguredSessionDir(input: DoctorReportInput): string {
-	if (input.requestedSessionDir) {
-		return path.resolve(input.expandTilde?.(input.requestedSessionDir) ?? input.requestedSessionDir);
-	}
-	if (input.config.defaultSessionDir) {
-		return path.resolve(input.expandTilde?.(input.config.defaultSessionDir) ?? input.config.defaultSessionDir);
-	}
-	return "not configured";
-}
-
-function formatSessionLines(input: DoctorReportInput): string[] {
-	const sessionFile = input.currentSessionFile ?? null;
-	const lines = [
-		lineFromCheck("configured session dir", () => `- configured session dir: ${formatConfiguredSessionDir(input)}`),
-		`- current session file: ${sessionFile ?? "not available"}`,
-		`- current session dir: ${sessionFile ? path.dirname(sessionFile) : "not available"}`,
-		`- current session id: ${input.currentSessionId ?? input.state.currentSessionId ?? "not available"}`,
-	];
-	if (input.sessionError) lines.push(`- session manager: failed — ${input.sessionError}`);
-	return lines;
-}
-
-function formatDiscovery(input: DoctorReportInput, deps: DoctorDeps): string[] {
-	return [
-		lineFromCheck("agents", () => {
-			const discovered = deps.discoverAgentsAll(input.cwd);
-			const agentCounts = {
-				builtin: discovered.builtin.length,
-				user: discovered.user.length,
-				project: discovered.project.length,
-			};
-			const lines = [
-				`- agents: total ${agentCounts.builtin + agentCounts.user + agentCounts.project} (${formatSourceCounts(agentCounts)})`,
-			];
-			// A file whose frontmatter is invalid YAML is skipped by discovery;
-			// without these lines it would vanish with no signal at all.
-			for (const diagnostic of discovered.diagnostics) {
-				lines.push(
-					`- agents: warning — ${diagnostic.path}: invalid YAML frontmatter (${diagnostic.message}); file skipped`,
-				);
-			}
-			return lines.join("\n");
-		}),
-		lineFromCheck("skills", () => {
-			const skills = deps.discoverAvailableSkills(input.cwd);
-			return `- skills: total ${skills.length} (${formatSkillSourceCounts(skills)})`;
-		}),
-	];
-}
-
-function formatIntercomDiagnostic(
-	diagnostic: IntercomBridgeDiagnostic,
-	context: "fresh" | "fork" | undefined,
-): string[] {
-	const lines = [
-		`- bridge: ${diagnostic.active ? "active" : "inactive"}${diagnostic.reason ? ` (${diagnostic.reason})` : ""}`,
-		`- mode: ${diagnostic.mode}; context: ${context ?? "unspecified"}`,
-		`- orchestrator target: ${diagnostic.orchestratorTarget ?? "not available"}`,
-		`- pi-intercom: ${diagnostic.piIntercomAvailable ? "available" : "unavailable"} at ${diagnostic.extensionDir}`,
-	];
-	if (diagnostic.configPath && diagnostic.intercomConfigEnabled !== undefined) {
-		lines.push(
-			`- intercom config: ${diagnostic.intercomConfigEnabled === false ? "disabled" : "enabled or absent"} (${diagnostic.configPath})`,
-		);
-	}
-	if (diagnostic.intercomConfigError) {
-		lines.push(`- intercom config warning: ${diagnostic.intercomConfigError}; runtime assumes enabled`);
-	}
-	return lines;
-}
-
-export function buildDoctorReport(input: DoctorReportInput): string {
-	const paths = input.paths ?? DEFAULT_PATHS;
-	const deps = { ...DEFAULT_DEPS, ...input.deps };
-	const lines = [
-		"Subagents doctor report",
-		"",
-		"Runtime",
-		`- cwd: ${input.cwd}`,
-		...formatSessionLines(input),
-		"",
-		"Filesystem",
-		formatExistingDirectory("temp root", paths.tempRootDir),
-		"",
-		"Discovery",
-		...formatDiscovery(input, deps),
-		"",
-		"Intercom bridge",
-		...lineFromCheck("intercom bridge", () =>
-			formatIntercomDiagnostic(
-				deps.diagnoseIntercomBridge({
-					config: input.config.intercomBridge,
-					context: input.context,
-					orchestratorTarget: input.orchestratorTarget,
-					cwd: input.cwd,
-				}),
-				input.context,
-			).join("\n"),
-		).split("\n"),
-	];
-	return lines.join("\n");
-}

package/dist/builtin/subagents/src/runs/inprocess/attempt-handles.ts

@@ -1,104 +0,0 @@
-/**
- * In-process attempt handles for a top-level session's direct children.
- *
- * Delegation is one level deep, so this registry only ever holds a parent's own
- * children. A live child is addressed by its run id or canonical task path, and
- * interrupt/resume reach it through the handle registered when its attempt
- * started — never through a request file, a capability token, or a poller.
- */
-
-export interface InProcessAttemptResumeOutcome {
-	readonly status: "ok" | "error" | "interrupted" | "continued";
-	readonly path: string;
-	readonly sessionFile?: string;
-	readonly envelope?: string;
-}
-
-export interface InProcessAttemptHandle {
-	readonly runId: string;
-	readonly path: string;
-	readonly status: () => string;
-	readonly interrupt: () => Promise<void>;
-	readonly resume: (message: string) => Promise<InProcessAttemptResumeOutcome>;
-}
-
-export interface InProcessAttemptControlResult {
-	readonly ok: boolean;
-	readonly message: string;
-	readonly outcome?: InProcessAttemptResumeOutcome;
-}
-
-const attemptHandles = new Map<string, Map<string, InProcessAttemptHandle>>();
-
-function attemptKey(id: string): string {
-	return id.trim();
-}
-
-export function registerInProcessAttempt(handle: InProcessAttemptHandle): () => void {
-	const key = attemptKey(handle.runId);
-	let handles = attemptHandles.get(key);
-	if (!handles) {
-		handles = new Map();
-		attemptHandles.set(key, handles);
-	}
-	handles.set(handle.path, handle);
-	const pathKey = attemptKey(handle.path);
-	if (pathKey !== key) {
-		let byPath = attemptHandles.get(pathKey);
-		if (!byPath) {
-			byPath = new Map();
-			attemptHandles.set(pathKey, byPath);
-		}
-		byPath.set(handle.path, handle);
-	}
-	return () => {
-		for (const lookupKey of [key, pathKey]) {
-			const current = attemptHandles.get(lookupKey);
-			if (!current || current.get(handle.path) !== handle) continue;
-			current.delete(handle.path);
-			if (current.size === 0) attemptHandles.delete(lookupKey);
-		}
-	};
-}
-
-function handlesFor(id: string): InProcessAttemptHandle[] {
-	return [...(attemptHandles.get(attemptKey(id))?.values() ?? [])];
-}
-
-export async function interruptInProcessAttempt(targetId: string): Promise<InProcessAttemptControlResult | undefined> {
-	const handles = handlesFor(targetId);
-	if (handles.length === 0) return undefined;
-	const active = handles.filter((handle) => handle.status() === "running" || handle.status() === "continued");
-	if (active.length === 0) {
-		return { ok: false, message: `Run ${targetId} has no active child attempt to interrupt.` };
-	}
-	await Promise.all(active.map((handle) => handle.interrupt()));
-	return { ok: true, message: `Interrupt requested for run ${targetId}.` };
-}
-
-export async function resumeInProcessAttempt(
-	targetId: string,
-	message: string,
-): Promise<InProcessAttemptControlResult | undefined> {
-	const handles = handlesFor(targetId);
-	if (handles.length === 0) return undefined;
-	const handle =
-		handles.find((candidate) => candidate.status() === "interrupted" || candidate.status() === "error") ?? handles[0];
-	if (!handle) return undefined;
-	if (handle.status() === "running" || handle.status() === "continued") {
-		return { ok: false, message: `Run ${targetId} is still running; resume is not required.` };
-	}
-	const outcome = await handle.resume(message);
-	return {
-		ok: outcome.status === "ok" || outcome.status === "continued",
-		message:
-			outcome.status === "ok"
-				? `Reloaded run ${targetId} through the in-process control plane.`
-				: `Run ${targetId} resume ended with status '${outcome.status}'.`,
-		outcome,
-	};
-}
-
-export function clearInProcessAttemptHandles(): void {
-	attemptHandles.clear();
-}