dsh-plugin-local-infer 0.1.2 → 0.1.4

package/packages/orchestrator/lib/config.js

@@ -0,0 +1,111 @@
+/**
+ * The Orchestrator prompt store: the saved prompt file under
+ * ~/.dsh/local-infer/orchestrator.json, the shipped prompt.md default, and
+ * the in-memory holder the system-prompt section and the settings routes
+ * share. Every read sanitizes the file, so a by-hand edit never poisons the
+ * injected prompt. Mirrors the sanitize-on-read discipline of
+ * packages/ui/src/config.ts.
+ * @module dsh-plugin-local-infer/orchestrator/config
+ */
+import { existsSync, mkdirSync, readFileSync, writeFileSync } from 'node:fs';
+import { homedir } from 'node:os';
+import { dirname, join } from 'node:path';
+/**
+ * orchestratorConfigPath names the file this package owns. It sits in the
+ * shared local-infer dir beside the ui config so one place holds everything
+ * the plugin persists.
+ */
+export function orchestratorConfigPath() {
+    return join(homedir(), '.dsh', 'local-infer', 'orchestrator.json');
+}
+/**
+ * readOrchestratorConfig reads the saved prompt. A missing or broken file,
+ * or a prompt field that is not a string, reads as no saved prompt (empty),
+ * so a first open and a by-hand edit both land on the default instead of
+ * throwing.
+ */
+export function readOrchestratorConfig() {
+    const path = orchestratorConfigPath();
+    if (!existsSync(path)) {
+        return { prompt: '' };
+    }
+    try {
+        const parsed = JSON.parse(readFileSync(path, 'utf8'));
+        return { prompt: typeof parsed.prompt === 'string' ? parsed.prompt : '' };
+    }
+    catch {
+        return { prompt: '' };
+    }
+}
+/**
+ * writeOrchestratorConfig persists the prompt, creating the directory tree
+ * on first write the same way the ui config write does.
+ */
+export function writeOrchestratorConfig(config) {
+    const path = orchestratorConfigPath();
+    mkdirSync(dirname(path), { recursive: true });
+    writeFileSync(path, JSON.stringify({ prompt: config.prompt }, null, 2));
+}
+// Cache of the shipped prompt.md text: the file never changes while the
+// process runs, so only a successful read is kept and a failed read retries
+// on the next call instead of locking in the empty fallback.
+let defaultPromptCache;
+/**
+ * defaultOrchestratorPrompt returns the shipped prompt.md text read from the
+ * package root. The URL hop is relative to this module, so src/ and lib/
+ * depths both resolve one level up to the package root. The read is cached;
+ * an unreadable file yields '' without throwing.
+ */
+export function defaultOrchestratorPrompt() {
+    if (defaultPromptCache === undefined) {
+        try {
+            defaultPromptCache = readFileSync(new URL('../prompt.md', import.meta.url), 'utf8');
+        }
+        catch {
+            return '';
+        }
+    }
+    return defaultPromptCache;
+}
+// The effective prompt holder: null until the first read refreshes it from
+// the file, then the saved value or the default until the setter persists a
+// new one.
+let effectivePrompt = null;
+/**
+ * getOrchestratorPrompt returns the effective prompt: the saved value when a
+ * non-empty one exists, otherwise the shipped default. The first call reads
+ * the file once and caches, so the system-prompt section pays no per-message
+ * disk read.
+ */
+export function getOrchestratorPrompt() {
+    if (effectivePrompt === null) {
+        effectivePrompt = toEffective(readOrchestratorConfig().prompt);
+    }
+    return effectivePrompt;
+}
+/**
+ * setOrchestratorPrompt persists the prompt and refreshes the holder, so the
+ * injected section picks the new text up without another file read. An empty
+ * save means "no saved prompt" and falls back to the default.
+ */
+export function setOrchestratorPrompt(prompt) {
+    writeOrchestratorConfig({ prompt });
+    effectivePrompt = toEffective(prompt);
+}
+/**
+ * hasSavedOrchestratorPrompt reports whether the file holds a saved prompt
+ * override. The empty string is the store's sentinel for "no saved prompt",
+ * so the settings routes read the flag through here instead of re-deriving
+ * the sentinel rule the holder already applies.
+ */
+export function hasSavedOrchestratorPrompt() {
+    return readOrchestratorConfig().prompt !== '';
+}
+/**
+ * toEffective resolves one saved value against the default: an empty saved
+ * prompt reads as no saved prompt.
+ */
+function toEffective(saved) {
+    return saved === '' ? defaultOrchestratorPrompt() : saved;
+}
+//# sourceMappingURL=config.js.map

package/packages/orchestrator/lib/index.d.ts

@@ -0,0 +1,51 @@
+/**
+ * The Orchestrator capability: an editable "Orchestrator Prompt" persisted
+ * under `~/.dsh/local-infer`, defaulted from the shipped `prompt.md`, and
+ * injected into the system prompt while the component is enabled.
+ *
+ * The prompt store (saved file, shipped default, effective-prompt holder)
+ * lives in ./config.js and is re-exported here as the single source of truth
+ * the system-prompt seam (TASK-003) and the settings routes (TASK-004) pull
+ * from.
+ * @module dsh-plugin-local-infer/orchestrator
+ */
+import type { Context } from '@deepseek-ai/cordis';
+export { defaultOrchestratorPrompt, getOrchestratorPrompt, hasSavedOrchestratorPrompt, orchestratorConfigPath, readOrchestratorConfig, setOrchestratorPrompt, writeOrchestratorConfig, } from './config.js';
+export type { StoredOrchestratorConfig } from './config.js';
+export declare const name = "local-infer-orchestrator";
+export declare const inject: string[];
+/**
+ * SystemPromptService narrows the dsh-system-prompt service to the one
+ * member this package uses. That package augments the cordis Context with
+ * `systemPrompt` and is not a dependency here, so the scoped inject casts
+ * the scope locally (same shape as the ui's WebServerService narrowing).
+ */
+export interface SystemPromptService {
+    /**
+     * Registers one ordered prompt section in the calling scope and returns
+     * the Cordis effect disposer. `text` may be a provider re-evaluated at
+     * each assembly.
+     */
+    section(section: {
+        name: string;
+        order: number;
+        text: string | (() => string);
+        interpolate?: boolean;
+    }): () => void;
+}
+/**
+ * Mount the Orchestrator prompt. The scoped `systemPrompt` inject registers
+ * the one global `orchestrator` section where the seam exists; the effect
+ * scope ties the registration to the plugin, so it unregisters with the
+ * plugin. The scoped `webServer` inject registers the /local-infer/
+ * orchestrator settings routes where that seam exists, so a headless profile
+ * keeps no routes.
+ */
+export declare function apply(ctx: Context): void;
+declare const plugin: {
+    name: string;
+    inject: string[];
+    apply: typeof apply;
+};
+export default plugin;
+//# sourceMappingURL=index.d.ts.map

package/packages/orchestrator/lib/index.js

@@ -0,0 +1,73 @@
+/**
+ * The Orchestrator capability: an editable "Orchestrator Prompt" persisted
+ * under `~/.dsh/local-infer`, defaulted from the shipped `prompt.md`, and
+ * injected into the system prompt while the component is enabled.
+ *
+ * The prompt store (saved file, shipped default, effective-prompt holder)
+ * lives in ./config.js and is re-exported here as the single source of truth
+ * the system-prompt seam (TASK-003) and the settings routes (TASK-004) pull
+ * from.
+ * @module dsh-plugin-local-infer/orchestrator
+ */
+import { getOrchestratorPrompt } from './config.js';
+import { registerOrchestratorRoutes } from './route.js';
+export { defaultOrchestratorPrompt, getOrchestratorPrompt, hasSavedOrchestratorPrompt, orchestratorConfigPath, readOrchestratorConfig, setOrchestratorPrompt, writeOrchestratorConfig, } from './config.js';
+export const name = 'local-infer-orchestrator';
+// No required top-level services: the `systemPrompt` and `webServer` seams
+// are pulled with scoped injects in their own effects, so the component
+// stays loadable in profiles that lack either service.
+export const inject = [];
+// The section placement: the deployment persona prefix sits at 0 and the
+// first centrally allocated policy section (PLAN_POLICY) at 500, so 100
+// puts the Orchestrator instructions just after the persona and ahead of
+// first-party guidance. dsh-system-prompt allocates nothing between 0 and
+// 500, and external contributions may pick any finite order.
+const orchestratorSectionOrder = 100;
+/**
+ * mountSeam pulls one optional service through a scoped inject and mounts
+ * the half that needs it. A profile without the seam never runs the
+ * callback, and a mount failure is logged and swallowed so the component
+ * still loads without that half. `skipped` names the half in the catch log.
+ */
+function mountSeam(ctx, service, skipped, mount) {
+    ctx.inject([service], (scope) => {
+        try {
+            mount(scope);
+        }
+        catch (error) {
+            console.error(`[local-infer] orchestrator ${skipped}: ${error}`);
+        }
+    });
+}
+/**
+ * Mount the Orchestrator prompt. The scoped `systemPrompt` inject registers
+ * the one global `orchestrator` section where the seam exists; the effect
+ * scope ties the registration to the plugin, so it unregisters with the
+ * plugin. The scoped `webServer` inject registers the /local-infer/
+ * orchestrator settings routes where that seam exists, so a headless profile
+ * keeps no routes.
+ */
+export function apply(ctx) {
+    if (typeof ctx.inject !== 'function') {
+        return;
+    }
+    mountSeam(ctx, 'systemPrompt', 'prompt section skipped', (scope) => {
+        const systemPrompt = scope.systemPrompt;
+        systemPrompt.section({
+            name: 'orchestrator',
+            order: orchestratorSectionOrder,
+            // The prompt is user-editable text: a stray {{var}} stays literal
+            // instead of failing every later prompt assembly.
+            interpolate: false,
+            // Provider form re-reads the holder per assembly, so a settings
+            // Save reaches the next assembly without a host restart.
+            text: () => getOrchestratorPrompt(),
+        });
+    });
+    mountSeam(ctx, 'webServer', 'settings routes skipped', (scope) => {
+        registerOrchestratorRoutes(scope);
+    });
+}
+const plugin = { name, inject, apply };
+export default plugin;
+//# sourceMappingURL=index.js.map

package/packages/orchestrator/lib/route.d.ts

@@ -0,0 +1,60 @@
+/**
+ * The Orchestrator settings routes the Web card talks to: GET
+ * /local-infer/orchestrator answers { prompt, defaultPrompt, saved } (the
+ * effective prompt, the shipped prompt.md default, and whether the effective
+ * prompt is a saved value), and POST /local-infer/orchestrator/save persists
+ * { prompt } through the config setter (an empty string clears the saved
+ * override back to the default) and answers with the same payload. The routes
+ * are held by an effect, so they go when the component does.
+ *
+ * The HTTP plumbing is a minimal local mirror of the ui package's defineRoute
+ * template (method guard 405, bounded body 413, JSON answer). The ui package
+ * does export its template, but this package deliberately keeps no dependency
+ * on ui: importing ui's route module would load its whole route graph (the
+ * service, providers, and core packages) into a component that ships disabled
+ * and must stay loadable headless, so the shared shape is copied rather than
+ * imported, and the two copies change together by hand. The stream helpers
+ * the ui template carries are dropped; these two routes only ever answer with
+ * one JSON body.
+ * @module dsh-plugin-local-infer/orchestrator/route
+ */
+import type { Context } from '@deepseek-ai/cordis';
+/**
+ * OrchestratorRoute is one webServer route definition the register step holds
+ * by an effect: the stable name, the exact-match path, and the handler the web
+ * server invokes per request.
+ */
+export interface OrchestratorRoute {
+    name: string;
+    kind: 'exact';
+    path: string;
+    handler: (req: IncomingLike, res: OutgoingLike) => void | Promise<void>;
+}
+/**
+ * The webServer service is dsh-specific and absent from the cordis Context
+ * type, so the route narrows the scoped context to the one member it needs
+ * (same shape as the ui's WebServerService narrowing).
+ */
+export interface WebServerService {
+    register(route: OrchestratorRoute): () => void;
+}
+interface IncomingLike extends AsyncIterable<Buffer> {
+    method: string;
+    url: string;
+    destroy(): void;
+}
+interface OutgoingLike {
+    writeHead(status: number, headers?: Record<string, string>): OutgoingLike;
+    end(body?: string): void;
+}
+/**
+ * registerOrchestratorRoutes registers the GET and save routes on the web
+ * server and holds them by an effect, so a component switch off removes them
+ * before the next switch on re-registers. The scoped context carries the
+ * webServer.
+ */
+export declare function registerOrchestratorRoutes(scope: Context & {
+    webServer: WebServerService;
+}): void;
+export {};
+//# sourceMappingURL=route.d.ts.map

package/packages/orchestrator/lib/route.js

@@ -0,0 +1,159 @@
+/**
+ * The Orchestrator settings routes the Web card talks to: GET
+ * /local-infer/orchestrator answers { prompt, defaultPrompt, saved } (the
+ * effective prompt, the shipped prompt.md default, and whether the effective
+ * prompt is a saved value), and POST /local-infer/orchestrator/save persists
+ * { prompt } through the config setter (an empty string clears the saved
+ * override back to the default) and answers with the same payload. The routes
+ * are held by an effect, so they go when the component does.
+ *
+ * The HTTP plumbing is a minimal local mirror of the ui package's defineRoute
+ * template (method guard 405, bounded body 413, JSON answer). The ui package
+ * does export its template, but this package deliberately keeps no dependency
+ * on ui: importing ui's route module would load its whole route graph (the
+ * service, providers, and core packages) into a component that ships disabled
+ * and must stay loadable headless, so the shared shape is copied rather than
+ * imported, and the two copies change together by hand. The stream helpers
+ * the ui template carries are dropped; these two routes only ever answer with
+ * one JSON body.
+ * @module dsh-plugin-local-infer/orchestrator/route
+ */
+import { defaultOrchestratorPrompt, getOrchestratorPrompt, hasSavedOrchestratorPrompt, setOrchestratorPrompt, } from './config.js';
+/**
+ * RouteError is a route failure that carries its own HTTP status, so a
+ * handler can answer a validation rejection with its own code instead of the
+ * spec's failStatus.
+ */
+class RouteError extends Error {
+    status;
+    constructor(status, message) {
+        super(message);
+        this.name = 'RouteError';
+        this.status = status;
+    }
+}
+/**
+ * The request body size cap the save route enforces: a prompt is a few
+ * kilobytes at most, so a body past 64 KiB is a client bug, not a prompt.
+ * Deliberately mirrors the cap in packages/ui/src/route.ts (ui is not a
+ * dependency here): one malformed client misbehaves the same on every
+ * /local-infer route, so edit the two together.
+ */
+const MAX_BODY_BYTES = 64 * 1024;
+/**
+ * readJsonBody collects a bounded JSON request body: chunks up to the cap,
+ * then parses. A body past the cap destroys the request and throws a 413
+ * RouteError carrying the route's own message, so the answer names the route
+ * that rejected the body.
+ */
+async function readJsonBody(req, tooLargeMessage) {
+    const chunks = [];
+    let total = 0;
+    for await (const chunk of req) {
+        total += chunk.length;
+        if (total > MAX_BODY_BYTES) {
+            req.destroy();
+            throw new RouteError(413, tooLargeMessage);
+        }
+        chunks.push(chunk);
+    }
+    return JSON.parse(Buffer.concat(chunks).toString('utf8'));
+}
+/** Writes one JSON answer (status head plus body) on the response. */
+function writeJson(res, status, body) {
+    res.writeHead(status, { 'content-type': 'application/json' });
+    res.end(JSON.stringify(body));
+}
+/**
+ * defineRoute is the local template both route specs build on: it guards the
+ * method (405), reads the bounded body (413, POST only), and maps the
+ * handler's answer to a status: a RouteError carries its own status, any
+ * other failure answers with the spec's failStatus.
+ */
+function defineRoute(spec) {
+    return {
+        name: spec.name,
+        kind: 'exact',
+        path: spec.path,
+        handler: async (req, res) => {
+            if (req.method !== spec.method) {
+                res.writeHead(405).end();
+                return;
+            }
+            try {
+                const body = spec.method === 'POST' ? await readJsonBody(req, spec.tooLargeMessage) : {};
+                await spec.run({ url: new URL(req.url, 'http://localhost'), body }, (status, answer) => writeJson(res, status, answer));
+            }
+            catch (error) {
+                if (error instanceof RouteError) {
+                    writeJson(res, error.status, { error: error.message });
+                    return;
+                }
+                writeJson(res, spec.failStatus, { error: String(error?.message ?? error) });
+            }
+        },
+    };
+}
+function orchestratorPayload() {
+    return {
+        prompt: getOrchestratorPrompt(),
+        defaultPrompt: defaultOrchestratorPrompt(),
+        saved: hasSavedOrchestratorPrompt(),
+    };
+}
+/**
+ * orchestratorGetRoute builds the GET /local-infer/orchestrator route. The
+ * client treats any non-404 answer as proof the route is mounted, so the
+ * payload answers 200 even before anything is saved.
+ */
+function orchestratorGetRoute() {
+    return defineRoute({
+        name: 'local-infer-orchestrator',
+        path: '/local-infer/orchestrator',
+        method: 'GET',
+        failStatus: 500,
+        run: async (_input, json) => {
+            json(200, orchestratorPayload());
+        },
+    });
+}
+/**
+ * orchestratorSaveRoute builds the POST /local-infer/orchestrator/save route:
+ * a string prompt persists through setOrchestratorPrompt (an empty string
+ * clears the saved override back to the default) and the answer carries the
+ * GET payload shape so the card re-renders from one response.
+ */
+function orchestratorSaveRoute() {
+    return defineRoute({
+        name: 'local-infer-orchestrator-save',
+        path: '/local-infer/orchestrator/save',
+        method: 'POST',
+        failStatus: 400,
+        tooLargeMessage: 'orchestrator prompt payload too large',
+        run: async ({ body }, json) => {
+            if (typeof body.prompt !== 'string') {
+                throw new RouteError(400, 'prompt must be a string');
+            }
+            setOrchestratorPrompt(body.prompt);
+            json(200, orchestratorPayload());
+        },
+    });
+}
+/**
+ * registerOrchestratorRoutes registers the GET and save routes on the web
+ * server and holds them by an effect, so a component switch off removes them
+ * before the next switch on re-registers. The scoped context carries the
+ * webServer.
+ */
+export function registerOrchestratorRoutes(scope) {
+    const routes = [orchestratorGetRoute(), orchestratorSaveRoute()];
+    scope.effect(() => {
+        const disposers = routes.map((route) => scope.webServer.register(route));
+        return () => {
+            for (const dispose of disposers) {
+                dispose();
+            }
+        };
+    }, 'local-infer-orchestrator: settings routes');
+}
+//# sourceMappingURL=route.js.map

package/packages/orchestrator/locale/en.json

@@ -0,0 +1,6 @@
+{
+  "meta": {
+    "title": "Orchestrator",
+    "description": "Edit the Orchestrator Prompt the component injects into the system prompt while it is enabled."
+  }
+}

package/packages/orchestrator/package.json

@@ -0,0 +1,39 @@
+{
+  "name": "dsh-plugin-local-infer-orchestrator",
+  "version": "0.1.4",
+  "description": "Orchestrator component for the dsh local-inference plugin: an editable Orchestrator Prompt persisted under ~/.dsh/local-infer, defaulted from the shipped prompt.md, injected into the system prompt while the component is enabled",
+  "keywords": [
+    "dsh",
+    "dsh-plugin",
+    "deepseek-harness",
+    "local-inference",
+    "orchestrator",
+    "system-prompt"
+  ],
+  "license": "MIT",
+  "type": "module",
+  "main": "lib/index.js",
+  "types": "lib/index.d.ts",
+  "exports": {
+    ".": {
+      "types": "./lib/index.d.ts",
+      "default": "./lib/index.js"
+    },
+    "./package.json": "./package.json"
+  },
+  "files": [
+    "lib/**/*.js",
+    "lib/**/*.d.ts",
+    "prompt.md",
+    "locale/en.json"
+  ],
+  "publishConfig": {
+    "access": "public"
+  },
+  "peerDependencies": {
+    "@deepseek-ai/cordis": ">=4.0.1"
+  },
+  "devDependencies": {
+    "@deepseek-ai/cordis": "^4.0.6-alpha.2"
+  }
+}

package/packages/orchestrator/prompt.md

@@ -0,0 +1,87 @@
+# Role & Core Objective
+You are an advanced software engineering orchestration agent.
+Your goal is to systematically plan, execute, and finalize user requests using micro-tasks and subagents.
+Always adhere strictly to the following execution sequence.
+
+---
+
+## Step 1: Initialization & Planning
+1. **Gather Context**: Analyze the user request.
+2. **Initialize Plan**: Execute the `todo_write` tool. Include an initial strategy containing a Phase Plan, Task Breakdown, and a Questionnaire step.
+   Do not include individual tasks at this time.
+3. **Generate Plan File**: Create a Markdown file named `PLAN-{{1OR2WORD-SLUG}}.md` in the root directory containing:
+    - A short description of the objective at the very top.
+    - Verification guidelines (Do not duplicate any rules found in `AGENTS.md`).
+    - A sequential list of open questions for the user.
+    - An ordered list of micro-tasks, group logically by Phase.
+      Each task must represent the smallest possible unit of work with a concrete, verifiable "Definition of Done".
+4. **Review Plan File**: Remove any duplicative context so that each statement
+   the single source of truth. Remove reasoning notes about task ordering,
+   replacing with a clear Markdown list of task dependencies.
+
+## Step 2: Refactoring Tasks Injection
+Where appropriate, insert specialized tasks starting with `Refactor:` into your task sequence.
+These tasks must contain the exact following instruction block,
+with the `{{N}}` count template replaced by the number of Tasks in the Phase:
+```text
+Review the files touched by the previous {{N}} commits and identify the following code risks:
+ - **Multiple Sources of Truth**: Same calculations done in multiple places.
+ - **Duplicate Code**: Nearly-identical code in multiple methods.
+ - **Bloaters**: Too many things done in a single method or class.
+ - **Data Clumps**: Single variables that travel in a group for multiple methods.
+ - **Shotgun Edits**: Commits with singular changes that touch multiple files.
+ - **Feature Envy**: Method where over 50% of the code manipulates a different class.
+ - **Magic Numbers**: Literals without context in method bodies.
+Then address and resolve each risk.
+```
+
+## Step 3: Architecture-Dependent Architecture Selection
+Count the total number of sequential tasks generated. Execute branch **A** or **B** based on the count:
+
+### Branch A: High-Complexity Architecture (5 or More Tasks)
+1. **Deconstruct Plan**: Extract each task body out of the main index file.
+2. **Create Task Files**: Save each task into its own file using this naming convention: `docs/PLAN-{{1OR2WORD-SLUG}}-TASK-###-{{SHORT-DESC-SLUG}}.md`.
+3. **Update Main Index**: Ensure `PLAN-{{1OR2WORD-SLUG}}.md` becomes a slim index where tasks are grouped logically by section and linked using exact Markdown checklist syntax:
+   ` - [ ] [TASK-###-{{SHORT-DESC-SLUG}}](docs/PLAN-{{1OR2WORD-SLUG}}-TASK-###-{{SHORT-DESC-SLUG}}.md)`
+4. **Set Session Goals**: Use the `create_goal` tool to register all session goals.
+
+### Branch B: Low-Complexity Architecture (Less Than 5 Tasks)
+1. **Deconstruct Tasks**: Break down each task into a series of todos.
+   In Step 4, when writing each task to the global todo list, include the
+   series of todos for each task as an individual todo between tasks.
+
+## Step 4: Questionnaire & Baseline Commit
+1. **Append To-Dos**: Use the `todo_write` tool to insert your tasks directly into the global todo list.
+2. **Add Finalizer To-Do**: Append a final `Finalize` item to the end of that list.
+3. **Interview User**: For every open question identified in Step 1, invoke the `ask_user_question` tool individually.
+   Provide at least one recommended answer and leave a spot open for the user to answer with their own input.
+4. **Persist Answers**: As answers arrive, write them directly into `PLAN-{{1OR2WORD-SLUG}}.md` (or the specific task file if using Branch A).
+5. **Close Questionnaire**: Mark the Questionnaire task as complete.
+6. **Commit Blueprint**: If on Branch A (High-Complexity), commit the created `PLAN` file (and accompanying `docs/` task files if applicable) to repository version control.
+
+## Step 5: Subagent Execution Loop
+Loop through the tasks sequentially. For **each** incomplete task:
+1. **Launch Subagent**: Trigger the `subagent` tool with this exact prompt,
+   replacing the PLAN filename template:
+   ```text
+   1. Complete the next Task in @PLAN-{{1OR2WORD-SLUG}}.md .
+   2. Use the `todo_write` tool to plan your work.
+   3. Check ('[x]') the task in the file when done, then commit the completed work.
+   4. List any discovered pre-existing issues for the parent agent to review.
+   5. Then you are finished; resolve remaining todos and end the turn.
+   ```
+2. **Confirm Subagent** Trigger the `list_agents` tool to confirm the subagent is running, then end turn.
+3. **Resume and Evaluate Subagent Output**: The subagent will resume with a `notify` in a new turn.
+   If the subagent discovers pre-existing codebase issues, insert new tasks immediately after the current task in the appropriate execution order.
+4. **Sync State**: Invoke the `todo_write` tool to check off progress.
+5. **Repeat**: Proceed to the next task until all items in the plan are checked `[x]`.
+
+## Step 6: Finalization & Handoff
+1. **Cleanup Artifacts**: Delete all generated `PLAN-{{1OR2WORD-SLUG}}.md` and `docs/PLAN-{{1OR2WORD-SLUG}}-TASK*` files.
+   Remove all memory and file references, restoring the repo development to a stateless condition.
+2. **Commit Cleanup**: Commit these deletions to repository version control.
+3. **Wrap up tasks**: Sync and close out any lingering task tracking states using the appropriate tool.
+4. **Present Results**: Invoke the `present` tool to officially deliver the completed work to the user.
+5. **Complete**: End the turn.
+
+---