@yagni-app/code 0.2.1 → 0.3.0

package/dist/extension/ticketTools.d.ts

@@ -0,0 +1,37 @@
+import type { ToolDefinition } from "@earendil-works/pi-coding-agent";
+import { Type } from "typebox";
+/**
+ * Ticket write-back tools (spec 2026-08-09): file a ticket, move a ticket.
+ *
+ * Both are EXPLICIT user-intent actions — the guidelines pin the agent to
+ * calling them only when the developer asked. Writes execute server-side as
+ * the developer's own tracker account (per-user write identity); when no
+ * personal connection exists the backend answers 412 `connect_required` and
+ * the tool renders the one-time connect prompt instead of failing opaquely.
+ */
+export interface MakeTicketToolOptions {
+    baseUrl: string;
+    getToken: () => string | undefined;
+    fetchImpl?: typeof fetch;
+}
+declare const fileTicketParams: Type.TObject<{
+    title: Type.TString;
+    description: Type.TOptional<Type.TString>;
+    tracker: Type.TOptional<Type.TUnion<[Type.TLiteral<"jira">, Type.TLiteral<"linear">]>>;
+    target_key: Type.TOptional<Type.TString>;
+}>;
+export declare function makeFileTicketTool(opts: MakeTicketToolOptions): ToolDefinition<typeof fileTicketParams, {
+    identifier?: string;
+    url?: string | null;
+}>;
+declare const updateTicketStatusParams: Type.TObject<{
+    ref: Type.TString;
+    status: Type.TString;
+    tracker: Type.TOptional<Type.TUnion<[Type.TLiteral<"jira">, Type.TLiteral<"linear">]>>;
+}>;
+export declare function makeUpdateTicketStatusTool(opts: MakeTicketToolOptions): ToolDefinition<typeof updateTicketStatusParams, {
+    identifier?: string;
+    state?: string;
+}>;
+export {};
+//# sourceMappingURL=ticketTools.d.ts.map

package/dist/extension/ticketTools.js

@@ -0,0 +1,117 @@
+import { Type } from "typebox";
+import { friendlyFetchError, METERED_POST_FETCH_POLICY, resilientFetch, } from "./resilientFetch.js";
+/** Render backend problem responses (412/404/422) as agent-relayable text. */
+async function renderProblem(toolName, res) {
+    let body = null;
+    try {
+        body = (await res.clone().json());
+    }
+    catch {
+        body = null;
+    }
+    if (res.status === 412 && body?.error === "connect_required") {
+        return [
+            `A personal ${body.service ?? "tracker"} connection is needed to write as you.`,
+            `Connect here (one time): ${body.connect_url ?? "(ask your admin for the connect link)"}`,
+            "Then ask me again and I'll retry.",
+        ].join("\n");
+    }
+    if ((res.status === 404 || res.status === 422) && body?.error) {
+        const options = body.options?.length
+            ? `\nAvailable options: ${body.options.join(", ")}`
+            : "";
+        return `${body.message ?? body.error}${options}`;
+    }
+    throw new Error(await friendlyFetchError(toolName, res));
+}
+const fileTicketParams = Type.Object({
+    title: Type.String(),
+    description: Type.Optional(Type.String()),
+    tracker: Type.Optional(Type.Union([Type.Literal("jira"), Type.Literal("linear")])),
+    target_key: Type.Optional(Type.String()),
+});
+export function makeFileTicketTool(opts) {
+    return {
+        name: "file_ticket",
+        label: "File Ticket",
+        description: "File a ticket in the workspace's tracker (Jira or Linear), attributed to the developer's " +
+            "own account. ONLY call when the user explicitly asks to file/create a ticket — never " +
+            "speculatively, never as a side effect of other work. Pass target_key (Jira project key or " +
+            "Linear team key) when the workspace has more than one.",
+        promptSnippet: "file_ticket: file a ticket in the workspace tracker as the developer (explicit request only).",
+        promptGuidelines: [
+            "Call file_ticket ONLY when the user explicitly asks to file, create, or capture a ticket.",
+            "If the tool reports a connect prompt or asks for a target/tracker, relay it verbatim and wait for the user.",
+        ],
+        parameters: fileTicketParams,
+        async execute(toolCallId, params, signal) {
+            const res = await resilientFetch(`${opts.baseUrl}/api/yagni-code/tickets`, {
+                method: "POST",
+                headers: {
+                    "content-type": "application/json",
+                    authorization: `Bearer ${opts.getToken() ?? ""}`,
+                },
+                body: JSON.stringify({ ...params, idempotencyKey: toolCallId }),
+            }, { fetchImpl: opts.fetchImpl, signal, policy: METERED_POST_FETCH_POLICY });
+            if (!res.ok) {
+                const text = await renderProblem("file_ticket", res);
+                return { content: [{ type: "text", text }], details: {} };
+            }
+            const data = (await res.json());
+            return {
+                content: [
+                    {
+                        type: "text",
+                        text: `Filed ${data.identifier}${data.url ? `: ${data.url}` : ""}`,
+                    },
+                ],
+                details: { identifier: data.identifier, url: data.url },
+            };
+        },
+    };
+}
+const updateTicketStatusParams = Type.Object({
+    ref: Type.String(),
+    status: Type.String(),
+    tracker: Type.Optional(Type.Union([Type.Literal("jira"), Type.Literal("linear")])),
+});
+export function makeUpdateTicketStatusTool(opts) {
+    return {
+        name: "update_ticket_status",
+        label: "Update Ticket Status",
+        description: "Move a ticket to a new status by name (e.g. mark YAG-123 In Progress), attributed to the " +
+            "developer's own tracker account. ONLY call on the user's explicit request — never as an " +
+            "automatic side effect of starting or finishing work.",
+        promptSnippet: "update_ticket_status: move a tracker ticket to a named status as the developer (explicit request only).",
+        promptGuidelines: [
+            "Call update_ticket_status ONLY when the user explicitly asks to move/mark a ticket's status.",
+            "If the requested status is not available, relay the offered options and let the user pick.",
+        ],
+        parameters: updateTicketStatusParams,
+        async execute(toolCallId, params, signal) {
+            const res = await resilientFetch(`${opts.baseUrl}/api/yagni-code/tickets/transition`, {
+                method: "POST",
+                headers: {
+                    "content-type": "application/json",
+                    authorization: `Bearer ${opts.getToken() ?? ""}`,
+                },
+                body: JSON.stringify({ ...params, idempotencyKey: toolCallId }),
+            }, { fetchImpl: opts.fetchImpl, signal, policy: METERED_POST_FETCH_POLICY });
+            if (!res.ok) {
+                const text = await renderProblem("update_ticket_status", res);
+                return { content: [{ type: "text", text }], details: {} };
+            }
+            const data = (await res.json());
+            return {
+                content: [
+                    {
+                        type: "text",
+                        text: `${data.identifier} → ${data.state ?? params.status}`,
+                    },
+                ],
+                details: { identifier: data.identifier, state: data.state },
+            };
+        },
+    };
+}
+//# sourceMappingURL=ticketTools.js.map

package/dist/extension/tokenProvider.js

@@ -130,7 +130,7 @@ export function makeTokenProvider(deps) {
             });
         }, delay);
     }
-    function applyRotation(rotation) {
+    function applyRotation(rotation, skipPersist = false) {
         token = rotation.token;
         if (rotation.expiresAt)
             expiresAt = rotation.expiresAt;
@@ -139,13 +139,45 @@ export function makeTokenProvider(deps) {
         env.YAGNI_TOKEN = rotation.token;
         if (rotation.expiresAt)
             env.YAGNI_TOKEN_EXPIRES_AT = rotation.expiresAt;
+        if (!skipPersist) {
+            try {
+                persistProfile(rotation);
+            }
+            catch {
+                /* fail-soft */
+            }
+        }
+        armProactiveTimer();
+    }
+    /**
+     * Read the token from the launcher's profile file on disk. Used as a fallback
+     * when the server-side refresh fails (the old token is also invalid for
+     * /auth/refresh): an external `yagni login` writes a fresh token to the same
+     * file, so re-reading it can recover a session that the server refresh cannot.
+     * Returns null when the file is missing, unreadable, or carries the same token
+     * already in memory.
+     */
+    function readTokenFromDisk() {
+        const profilePath = env.YAGNI_PROFILE_PATH?.trim();
+        if (!profilePath)
+            return null;
         try {
-            persistProfile(rotation);
+            const parsed = JSON.parse(readFileSync(profilePath, "utf8"));
+            if (!parsed || typeof parsed !== "object" || Array.isArray(parsed))
+                return null;
+            const obj = parsed;
+            const diskToken = typeof obj.token === "string" ? obj.token : undefined;
+            if (!diskToken || diskToken === token)
+                return null;
+            return {
+                token: diskToken,
+                expiresAt: typeof obj.expiresAt === "string" ? obj.expiresAt : undefined,
+                workspaceId: typeof obj.workspaceId === "string" ? obj.workspaceId : undefined,
+            };
         }
         catch {
-            /* fail-soft */
+            return null;
         }
-        armProactiveTimer();
     }
     async function doRefresh() {
         const current = token;
@@ -161,8 +193,17 @@ export function makeTokenProvider(deps) {
                 body: "{}",
                 signal: AbortSignal.timeout(REFRESH_REQUEST_TIMEOUT_MS),
             });
-            if (!res.ok)
+            if (!res.ok) {
+                // Server refresh failed (the old token is also invalid for /auth/refresh).
+                // Fall back to the profile file on disk: an external `yagni login` may
+                // have written a fresh token there that this running session hasn't seen.
+                const disk = readTokenFromDisk();
+                if (disk) {
+                    applyRotation(disk, true);
+                    return true;
+                }
                 return false;
+            }
             const data = (await res.json());
             if (!data || typeof data.token !== "string" || data.token.length === 0)
                 return false;

package/dist/launch.d.ts

@@ -71,6 +71,13 @@ export interface BuildLaunchOptions {
     cliVersion?: string;
     /** Base environment to extend (defaults to process.env at call sites). */
     baseEnv?: NodeJS.ProcessEnv;
+    /**
+     * Whether this launch freshly collapsed reasoning (seeded `hideThinkingBlock`
+     * for the first time). Forwarded as `YAGNI_HIDE_THINKING_SEEDED=1` so the
+     * extension can surface a single one-time "reasoning is collapsed" hint.
+     * Omitted/false on repeat launches: the hint must not re-nag.
+     */
+    hideThinkingSeeded?: boolean;
     /** Clock seam for the token-expiry preflight (defaults to Date.now). */
     now?: () => number;
     /**

package/dist/launch.js

@@ -7,6 +7,8 @@
  */
 import { randomUUID } from "node:crypto";
 import { agentDirEnvVar } from "./branding.js";
+import { PAD_X_ENV, resolvePadX } from "./padding.js";
+import { ENGINEERING_PRACTICE_SECTION, promptEnrichmentDisabled } from "./promptEnrichment.js";
 /**
  * How close to expiry the token can be before launch warns. A coding session
  * easily outlives a token, so warn early enough that re-logging in before a long
@@ -95,27 +97,37 @@ export function buildLaunch(creds, passthroughArgs, opts) {
         // Match the e2b harness defaults: skip pi's update check + telemetry.
         PI_SKIP_VERSION_CHECK: "1",
         PI_TELEMETRY: "0",
+        // One-time marker for the "reasoning is collapsed" hint: only set on the
+        // launch that actually seeded the collapse default. Absent on every later
+        // launch so the hint never re-nags. (See hideThinkingSeeded in the docs.)
+        ...(opts.hideThinkingSeeded ? { YAGNI_HIDE_THINKING_SEEDED: "1" } : {}),
+        // Forward the chosen horizontal pad so the extension's footer aligns with
+        // the editor (which the launcher pads by seeding editorPaddingX). The
+        // footer can't read pi's settings, so the value crosses over env.
+        [PAD_X_ENV]: String(resolvePadX()),
     };
     // Always load our extension. Default the provider to `yagni` unless the user
     // explicitly chose one (so power users can still point pi elsewhere).
     const userChoseProvider = passthroughArgs.some(arg => arg === "--provider" || arg.startsWith("--provider="));
-    // Default the model to the `balanced` tier (YAG-380). Balanced drives on the
-    // judgment-grade `advanced` model and additionally lets the session escalate
-    // hard calls to `peak` through the capped ask_advisor tool. So it is strictly
-    // additive: no session reasons worse than plain advanced, and the hard ones
-    // can reason better. A user `--model` (e.g. `standard` or `efficient`) still
-    // wins. Without this, pi's default-model heuristic could land an interactive
-    // session on a weaker tier.
-    // Detect if the user explicitly set a model, whether via "--model" as a separate
-    // argument or using the equals form "--model=efficient". The previous check only
-    // caught the separate form, causing a duplicate "--model balanced" to be added
-    // when the equals form was used.
+    // Default the model to the `advanced` tier. The model is locked: the
+    // catalog is filtered to only `advanced` (see index.ts), so the user
+    // cannot switch to a different tier via /model or Ctrl+P. The proxy still
+    // resolves the tier to the concrete backing model.
     const userChoseModel = passthroughArgs.some(arg => arg === "--model" || arg.startsWith("--model="));
+    // Engineering-practice enrichment (YAG-496): appended to the DRIVER's system
+    // prompt only — /go stage children and subagents build their own pi argv, so
+    // this flag never reaches them. pi treats the value as literal text (it is
+    // never an existing file path) and slots it before <project_context>, so the
+    // user's repo instructions still outrank it. The flag is repeatable, so a
+    // user-passed --append-system-prompt coexists rather than conflicting; the
+    // opt-out is YAGNI_DISABLE_PROMPT_ENRICHMENT.
+    const enrichmentOff = promptEnrichmentDisabled(opts.baseEnv ?? process.env);
     const argv = [
         "-e",
         opts.extensionPath,
         ...(userChoseProvider ? [] : ["--provider", "yagni"]),
-        ...(userChoseModel ? [] : ["--model", "balanced"]),
+        ...(userChoseModel ? [] : ["--model", "advanced"]),
+        ...(enrichmentOff ? [] : ["--append-system-prompt", ENGINEERING_PRACTICE_SECTION]),
         ...(opts.extraAgentArgs ?? []),
         ...passthroughArgs,
     ];

package/dist/padding.d.ts

@@ -0,0 +1,22 @@
+/**
+ * Single source of truth for the CLI's horizontal padding, shared by the
+ * launcher (which seeds the editor setting) and — via the `YAGNI_PAD_X` env the
+ * launcher forwards — pi-extension-yagni's footer.
+ *
+ * The value must match pi's `outputPad` (the chat/output area's left+right
+ * padding, which defaults to 1) so the input editor, the output stream, and
+ * the status bar all align on the same column. Keeping it in one module makes
+ * the coherence structural rather than eyeballed: change this one number and
+ * the editor, footer, and seeded default move together.
+ *
+ * Separators (the ─ rules above/below the input) intentionally stay full-bleed
+ * and are NOT padded — matching Claude Code's frame.
+ */
+export declare const PAD_X = 1;
+/** Left (and right) padding string applied to the editor and footer. */
+export declare const PAD_STR: string;
+/** Env var the launcher sets so the extension's footer can match the editor pad. */
+export declare const PAD_X_ENV = "YAGNI_PAD_X";
+/** Parse a pad width from the env override, falling back to {@link PAD_X}. */
+export declare function resolvePadX(raw?: string | undefined): number;
+//# sourceMappingURL=padding.d.ts.map

package/dist/padding.js

@@ -0,0 +1,25 @@
+/**
+ * Single source of truth for the CLI's horizontal padding, shared by the
+ * launcher (which seeds the editor setting) and — via the `YAGNI_PAD_X` env the
+ * launcher forwards — pi-extension-yagni's footer.
+ *
+ * The value must match pi's `outputPad` (the chat/output area's left+right
+ * padding, which defaults to 1) so the input editor, the output stream, and
+ * the status bar all align on the same column. Keeping it in one module makes
+ * the coherence structural rather than eyeballed: change this one number and
+ * the editor, footer, and seeded default move together.
+ *
+ * Separators (the ─ rules above/below the input) intentionally stay full-bleed
+ * and are NOT padded — matching Claude Code's frame.
+ */
+export const PAD_X = 1;
+/** Left (and right) padding string applied to the editor and footer. */
+export const PAD_STR = " ".repeat(PAD_X);
+/** Env var the launcher sets so the extension's footer can match the editor pad. */
+export const PAD_X_ENV = "YAGNI_PAD_X";
+/** Parse a pad width from the env override, falling back to {@link PAD_X}. */
+export function resolvePadX(raw = process.env[PAD_X_ENV]) {
+    const n = raw === undefined ? NaN : Number.parseInt(raw, 10);
+    return Number.isFinite(n) && n >= 0 && n <= 3 ? n : PAD_X;
+}
+//# sourceMappingURL=padding.js.map

package/dist/promptEnrichment.d.ts

@@ -0,0 +1,40 @@
+/**
+ * Engineering-practice prompt enrichment (YAG-496).
+ *
+ * pi's own base system prompt is deliberately thin (~15 lines: identity, tool
+ * one-liners, two generic guidelines). The extension adds identity, grounding,
+ * and product-tool guidance — but nothing about general engineering behavior:
+ * conventions, verification, commit discipline, communication style. This
+ * section carries that missing middle, curated from the prompt lineage shared
+ * by OpenCode/Claude Code/Kimi CLI and adapted to YAGNI Code's tools and
+ * autonomy posture.
+ *
+ * Delivery mechanism: pi's `--append-system-prompt <text>` flag, injected by
+ * the launcher (launch.ts). pi places appended text after its Guidelines and
+ * BEFORE the user's <project_context>, so repo instructions still outrank it.
+ * Because `/go` stage children and subagents build their own pi argv
+ * (pi-extension-yagni's pipeline/invocation.ts and pipeline/runner.ts), a
+ * launcher flag is structurally driver-only: child prompts are untouched by
+ * construction, not by an `if`. The piContract test pins both properties.
+ *
+ * Content constraints (enforced by test/promptEnrichment.test.ts):
+ * - must not contain the standalone word "pi" — the extension's brand scrub
+ *   rewrites it to "YAGNI Code" and would mangle the sentence;
+ * - must not OPEN with a "- " bullet line — pi's self-referential docs block
+ *   (which the extension strips with a regex that consumes consecutive
+ *   bullets) sits directly above this section in the assembled prompt;
+ * - no emojis (the section itself forbids them).
+ */
+/** Env switch that skips the enrichment entirely (sibling of
+ * YAGNI_DISABLE_BRANDING / YAGNI_DISABLE_CLAUDE_COMPAT, same semantics). */
+export declare const ENRICHMENT_DISABLE_ENV = "YAGNI_DISABLE_PROMPT_ENRICHMENT";
+/** `"1"`/anything truthy disables; unset, empty, and `"0"` keep it on. */
+export declare function promptEnrichmentDisabled(env: NodeJS.ProcessEnv): boolean;
+/**
+ * The section appended to the driver session's system prompt. Keep it curated,
+ * not encyclopedic: every line here spends attention budget on an open-weight
+ * model, and the load-bearing instructions (ask_yagni contract, delegation)
+ * live elsewhere in the prompt.
+ */
+export declare const ENGINEERING_PRACTICE_SECTION = "Engineering practice:\n\nBias to action: when the user asks you to implement, fix, or change something, use your tools to make the actual edits and run the actual commands \u2014 do not answer with a description of what you would do, or with code for the user to apply themselves. When the user asks HOW to approach something, answer the question first; do not jump into making changes they have not asked for.\n\nConventions:\n- Never assume a library is available, however well known. Before using one, confirm the project already depends on it (its package manifest, or imports in neighboring files).\n- When editing, read the surrounding code and its imports first; match the file's existing style, naming, and patterns rather than introducing your own.\n- When creating a new file or component, study an existing sibling first and follow its structure.\n- Never write code that logs or exposes secrets, keys, or credentials.\n\nVerification:\n- Consider what the code you are changing is supposed to do (from its name, location, and callers) before you change it.\n- Verify changes with the project's own tests when possible. Never assume a test framework or command \u2014 check the README, package scripts, or neighboring tests for the real one.\n- After completing a task, run the project's lint and typecheck commands if you know them; if you cannot find them, ask the user and suggest recording them in AGENTS.md for next time.\n\nVersion control:\n- No unsolicited commits: commit only when the user asked for one or the task at hand clearly calls for it.\n\nGit safety:\n- You may be in a dirty git worktree. Never revert existing changes you did not make unless explicitly asked \u2014 these were made by the user.\n- If there are unrelated changes in files you are touching, read and work with them rather than reverting.\n- If changes appear in unrelated files, ignore them and do not revert.\n- Do not amend a commit unless explicitly asked.\n- If you notice unexpected changes you did not make while working, stop immediately and ask the user.\n- Never use destructive git commands (git reset --hard, git checkout --) unless the user explicitly requests or approves them.\n\nTodo discipline:\n- Track multi-step work with todo_write: keep exactly one item in_progress at a time, mark items completed the moment they are done, and add newly discovered steps as pending.\n- Do not batch-complete items or create single-step plans. Skip planning for trivially small work (~25% of tasks).\n\nMode awareness:\n- In auto mode, proactively run tests, lint, and typecheck after your changes.\n- In review mode, propose verification steps but wait for approval before running them.\n- In plan mode, explore and design only \u2014 the gate holds all writes.\n\nCommunication:\n- Answer directly, without preamble or postamble (\"Here is what I will do next...\", \"Based on the information provided...\"). Match the length of your answer to the question.\n- After making edits, report the outcome briefly; do not restate the diff or explain the code you just wrote unless asked.\n- Do not add code comments that narrate what you changed or why the change is correct; comments are for future readers of the code.\n- Reference code as file_path:line_number so the user can jump to it.\n- Before running a non-trivial command that changes state, say in one line what it does and why.\n- Never guess or fabricate URLs. Only use URLs the user provided or that appear in local files.\n- No emojis unless the user asks for them.";
+//# sourceMappingURL=promptEnrichment.d.ts.map

package/dist/promptEnrichment.js

@@ -0,0 +1,85 @@
+/**
+ * Engineering-practice prompt enrichment (YAG-496).
+ *
+ * pi's own base system prompt is deliberately thin (~15 lines: identity, tool
+ * one-liners, two generic guidelines). The extension adds identity, grounding,
+ * and product-tool guidance — but nothing about general engineering behavior:
+ * conventions, verification, commit discipline, communication style. This
+ * section carries that missing middle, curated from the prompt lineage shared
+ * by OpenCode/Claude Code/Kimi CLI and adapted to YAGNI Code's tools and
+ * autonomy posture.
+ *
+ * Delivery mechanism: pi's `--append-system-prompt <text>` flag, injected by
+ * the launcher (launch.ts). pi places appended text after its Guidelines and
+ * BEFORE the user's <project_context>, so repo instructions still outrank it.
+ * Because `/go` stage children and subagents build their own pi argv
+ * (pi-extension-yagni's pipeline/invocation.ts and pipeline/runner.ts), a
+ * launcher flag is structurally driver-only: child prompts are untouched by
+ * construction, not by an `if`. The piContract test pins both properties.
+ *
+ * Content constraints (enforced by test/promptEnrichment.test.ts):
+ * - must not contain the standalone word "pi" — the extension's brand scrub
+ *   rewrites it to "YAGNI Code" and would mangle the sentence;
+ * - must not OPEN with a "- " bullet line — pi's self-referential docs block
+ *   (which the extension strips with a regex that consumes consecutive
+ *   bullets) sits directly above this section in the assembled prompt;
+ * - no emojis (the section itself forbids them).
+ */
+/** Env switch that skips the enrichment entirely (sibling of
+ * YAGNI_DISABLE_BRANDING / YAGNI_DISABLE_CLAUDE_COMPAT, same semantics). */
+export const ENRICHMENT_DISABLE_ENV = "YAGNI_DISABLE_PROMPT_ENRICHMENT";
+/** `"1"`/anything truthy disables; unset, empty, and `"0"` keep it on. */
+export function promptEnrichmentDisabled(env) {
+    const value = env[ENRICHMENT_DISABLE_ENV];
+    return value !== undefined && value !== "" && value !== "0";
+}
+/**
+ * The section appended to the driver session's system prompt. Keep it curated,
+ * not encyclopedic: every line here spends attention budget on an open-weight
+ * model, and the load-bearing instructions (ask_yagni contract, delegation)
+ * live elsewhere in the prompt.
+ */
+export const ENGINEERING_PRACTICE_SECTION = `Engineering practice:
+
+Bias to action: when the user asks you to implement, fix, or change something, use your tools to make the actual edits and run the actual commands — do not answer with a description of what you would do, or with code for the user to apply themselves. When the user asks HOW to approach something, answer the question first; do not jump into making changes they have not asked for.
+
+Conventions:
+- Never assume a library is available, however well known. Before using one, confirm the project already depends on it (its package manifest, or imports in neighboring files).
+- When editing, read the surrounding code and its imports first; match the file's existing style, naming, and patterns rather than introducing your own.
+- When creating a new file or component, study an existing sibling first and follow its structure.
+- Never write code that logs or exposes secrets, keys, or credentials.
+
+Verification:
+- Consider what the code you are changing is supposed to do (from its name, location, and callers) before you change it.
+- Verify changes with the project's own tests when possible. Never assume a test framework or command — check the README, package scripts, or neighboring tests for the real one.
+- After completing a task, run the project's lint and typecheck commands if you know them; if you cannot find them, ask the user and suggest recording them in AGENTS.md for next time.
+
+Version control:
+- No unsolicited commits: commit only when the user asked for one or the task at hand clearly calls for it.
+
+Git safety:
+- You may be in a dirty git worktree. Never revert existing changes you did not make unless explicitly asked — these were made by the user.
+- If there are unrelated changes in files you are touching, read and work with them rather than reverting.
+- If changes appear in unrelated files, ignore them and do not revert.
+- Do not amend a commit unless explicitly asked.
+- If you notice unexpected changes you did not make while working, stop immediately and ask the user.
+- Never use destructive git commands (git reset --hard, git checkout --) unless the user explicitly requests or approves them.
+
+Todo discipline:
+- Track multi-step work with todo_write: keep exactly one item in_progress at a time, mark items completed the moment they are done, and add newly discovered steps as pending.
+- Do not batch-complete items or create single-step plans. Skip planning for trivially small work (~25% of tasks).
+
+Mode awareness:
+- In auto mode, proactively run tests, lint, and typecheck after your changes.
+- In review mode, propose verification steps but wait for approval before running them.
+- In plan mode, explore and design only — the gate holds all writes.
+
+Communication:
+- Answer directly, without preamble or postamble ("Here is what I will do next...", "Based on the information provided..."). Match the length of your answer to the question.
+- After making edits, report the outcome briefly; do not restate the diff or explain the code you just wrote unless asked.
+- Do not add code comments that narrate what you changed or why the change is correct; comments are for future readers of the code.
+- Reference code as file_path:line_number so the user can jump to it.
+- Before running a non-trivial command that changes state, say in one line what it does and why.
+- Never guess or fabricate URLs. Only use URLs the user provided or that appear in local files.
+- No emojis unless the user asks for them.`;
+//# sourceMappingURL=promptEnrichment.js.map

package/dist/signalForward.d.ts

@@ -0,0 +1,60 @@
+/**
+ * Termination-signal forwarding: launcher → pi child.
+ *
+ * In the interactive TUI the tty is in raw mode, so Ctrl+C never raises
+ * SIGINT; this path covers `yagni -p`/piped/CI runs and an external
+ * `kill <launcher pid>`. Policy:
+ *
+ *  - The FIRST signal asks pi to shut down cleanly. SIGINT is translated to
+ *    SIGTERM because pi installs a graceful handler for SIGTERM (it kills its
+ *    tracked children) but none for SIGINT — a raw SIGINT would drop pi on the
+ *    default disposition with no cleanup.
+ *  - Any SECOND signal hard-kills pi's whole process TREE. A bare SIGKILL to
+ *    pi's pid would bypass its exit sweep (SIGKILL runs no handlers) and leave
+ *    /go workers alive, so the launcher enumerates and kills the descendants
+ *    itself: `ps` walk on POSIX, `taskkill /T /F` on Windows.
+ */
+/** The minimal child surface the forwarder needs (ChildProcess satisfies it). */
+export interface KillableChild {
+    pid?: number | undefined;
+    kill(signal: NodeJS.Signals): boolean;
+}
+/** The launcher-terminating signals that are forwarded rather than obeyed. */
+export declare const FORWARDED_SIGNALS: readonly NodeJS.Signals[];
+/**
+ * PURE policy for the FIRST signal: which signal the child receives when the
+ * launcher gets `received` (SIGINT is translated, the rest pass through).
+ * Escalation is not expressed here — a second signal goes through the tree
+ * kill, not a forwarded signal.
+ */
+export declare function forwardedSignal(received: NodeJS.Signals): NodeJS.Signals;
+/**
+ * PURE: the launcher's own exit code for the child's (code, signal) exit tuple.
+ * A signal-terminated child maps to the conventional 128+n (bash parity:
+ * SIGTERM→143, SIGKILL→137, SIGINT→130), so a cancelled run never reads as
+ * success to scripts or CI.
+ */
+export declare function exitCodeFor(code: number | null, signal: NodeJS.Signals | null): number;
+/**
+ * PURE: given `ps -A -o pid=,ppid=` output lines, collect every descendant of
+ * the given roots (children, grandchildren, ...), breadth-first. Mirrored in
+ * pi-extension-yagni's childRegistry (the packages are intentionally
+ * independent); keep the two in sync.
+ */
+export declare function descendantsOf(roots: number[], psLines: string[]): number[];
+/**
+ * Synchronously SIGKILL a process AND its descendants (POSIX `ps` walk /
+ * Windows `taskkill /T /F`). Throw-proof; fail-soft to a direct kill when no
+ * process snapshot is readable.
+ */
+export declare function killTreeSync(pid: number): void;
+/**
+ * Subscribe the forwarding policy for every signal in {@link FORWARDED_SIGNALS}.
+ * `subscribe` and `killTree` default to the real process surfaces and are
+ * injectable so tests never install real handlers, raise real signals, or kill
+ * real processes. Returns the forward function itself (also for tests).
+ * pid guard: a child whose spawn failed has no pid, and `kill()` would resolve
+ * that to the whole process group.
+ */
+export declare function installSignalForwarding(child: KillableChild, subscribe?: (sig: NodeJS.Signals, handler: () => void) => void, killTree?: (pid: number) => void): (sig: NodeJS.Signals) => void;
+//# sourceMappingURL=signalForward.d.ts.map