@yagni-app/code-staging 0.1.0-staging.1015.1 → 0.1.0-staging.1019.1

package/README.md

@@ -88,12 +88,14 @@ yagni -p "explain the deploy pipeline; ask_yagni if unsure"   # one-shot / print
 yagni logout         # revoke the token and clear it locally
 ```
 
-The agent runs on three opaque model tiers routed by YAGNI: `advanced` (the strongest,
-for judgment), `standard` (for execution) and `efficient` (cheapest).
-Interactive sessions default to `advanced`; pass `--model standard` or `--model
-efficient` to switch a run. The `/go` pipeline routes its own steps automatically —
-judgment steps (plan, review) on `advanced`, execution steps (map, implement, fix) on
-`standard`.
+The agent runs on model tiers routed by YAGNI: `advanced`, `standard`, and
+`efficient` (cheapest) are the three selectable via `--model`; `peak`, the
+strongest tier, is reserved for the `/go` pipeline's own judgment steps and is
+not one of the three.
+Interactive sessions default to `balanced`, which drives on `advanced`; pass
+`--model standard` or `--model efficient` to switch a run. The `/go` pipeline
+routes its own steps automatically — judgment steps (plan, review) on `peak`,
+execution steps (map, implement, fix) on `standard`.
 
 `login` opens a device-code flow: it prints a short code and a URL. Open the URL
 in a browser where you are signed in to YAGNI, enter the code, and approve. The
@@ -139,9 +141,12 @@ yagni use prod                           # switch back (sticky); prod is the def
 
 ## Configuration
 
-| Variable         | Default                  | Purpose                                            |
-| ---------------- | ------------------------ | -------------------------------------------------- |
-| `YAGNI_BASE_URL` | active environment's URL | Override the base URL for a **single run** (escape hatch). Prefer `yagni use` for anything sticky. |
+| Variable                      | Default                  | Purpose                                            |
+| ----------------------------- | ------------------------ | -------------------------------------------------- |
+| `YAGNI_BASE_URL`              | active environment's URL | Override the base URL for a **single run** (escape hatch). Prefer `yagni use` for anything sticky. |
+| `YAGNI_DISABLE_BRANDING`      | unset                    | `1` skips the YAGNI Code system-prompt rewrite entirely, so the engine's assembled prompt passes through byte-exact (no identity swap, no company-brief injection). |
+| `YAGNI_DISABLE_UPDATE_CHECK`  | unset                    | `1` silences the new-version notice and the background update check. |
+| `YAGNI_DISABLE_CLAUDE_COMPAT` | unset                    | `1` turns off the zero-config `.claude` assets bridge (skills and commands). |
 
 Credentials live in `~/.yagni-code/profiles/<name>.json` (mode `0600`); the active
 environment is recorded in `~/.yagni-code/config.json`. A pre-profiles

package/dist/cli.js

@@ -176,6 +176,7 @@ export const HELP_TEXT = [
     "Set YAGNI_BASE_URL to override the base URL for a single run.",
     "Set YAGNI_DISABLE_UPDATE_CHECK=1 to silence the new-version notice.",
     "Set YAGNI_DISABLE_CLAUDE_COMPAT=1 to skip loading .claude assets.",
+    "Set YAGNI_DISABLE_BRANDING=1 to pass the system prompt through unmodified.",
     "Set YAGNI_DISABLE_CRASH_REPORTS=1 to turn off sanitized crash reports.",
 ].join("\n");
 /** Parse `use <name> [--base-url <url>]` argv into its parts. */

package/dist/doctor.d.ts

@@ -60,6 +60,13 @@ export declare function checkCliUpdate(probe: {
     latest: string | null;
 }): CheckResult;
 export declare function checkGh(onPath: boolean): CheckResult;
+/** What the Windows bash probe found (pi needs a bash — Git Bash — on win32). */
+export interface BashProbe {
+    found: boolean;
+    /** The resolved bash path, when found. */
+    where?: string;
+}
+export declare function checkBash(probe: BashProbe): CheckResult;
 export interface DoctorReport {
     checks: CheckResult[];
     exitCode: number;
@@ -75,12 +82,26 @@ export interface DoctorDeps {
     probeBackend?: (baseUrl: string, token: string) => Promise<BackendProbe>;
     probeStateDir?: () => StateDirProbe;
     ghOnPath?: () => boolean;
+    /** Platform seam for the win32-only bash check (defaults to process.platform). */
+    platform?: NodeJS.Platform;
+    /** Windows bash probe; only ever called when the platform is win32. */
+    probeBash?: () => BashProbe;
     currentVersion?: string;
     probeLatestVersion?: () => Promise<string | null>;
     log?: (msg: string) => void;
 }
 /** Whether a `gh` executable is resolvable on PATH (no subprocess spawn). */
 export declare function ghOnPathDefault(env?: NodeJS.ProcessEnv): boolean;
+/**
+ * Locate the bash pi will actually use on Windows. The order and locations
+ * MIRROR pi 0.83's own shell resolution (dist/utils/shell.js) exactly:
+ * `%ProgramFiles%\Git\bin\bash.exe`, then `%ProgramFiles(x86)%\Git\bin\bash.exe`,
+ * then `bash.exe` on PATH (`where bash.exe`). Deliberately NOTHING wider — a
+ * per-user Git install in `%LOCALAPPDATA%` that is not on PATH is invisible
+ * to pi, and a doctor that reported it green would bless a machine where the
+ * first bash tool call throws. Pure function of env, like the gh probe.
+ */
+export declare function bashOnWindowsDefault(env?: NodeJS.ProcessEnv): BashProbe;
 /**
  * Gather every check result against the (injectable) probes. Pure ordering; each
  * individual check is a pure function of its probe.

package/dist/doctor.js

@@ -198,6 +198,24 @@ export function checkGh(onPath) {
         required: false,
     };
 }
+export function checkBash(probe) {
+    if (!probe.found) {
+        return {
+            name: "bash",
+            status: "fail",
+            detail: "no bash found (pi runs its shell commands through bash)",
+            hint: "Install Git for Windows — pi needs its bash: https://gitforwindows.org "
+                + "(a per-user install must also put bash.exe on PATH)",
+            required: true,
+        };
+    }
+    return {
+        name: "bash",
+        status: "ok",
+        detail: probe.where ? `found (${probe.where})` : "found",
+        required: true,
+    };
+}
 function toOctal(mode) {
     return `0${(mode & 0o777).toString(8).padStart(3, "0")}`;
 }
@@ -296,6 +314,32 @@ export function ghOnPathDefault(env = process.env) {
     }
     return false;
 }
+/**
+ * Locate the bash pi will actually use on Windows. The order and locations
+ * MIRROR pi 0.83's own shell resolution (dist/utils/shell.js) exactly:
+ * `%ProgramFiles%\Git\bin\bash.exe`, then `%ProgramFiles(x86)%\Git\bin\bash.exe`,
+ * then `bash.exe` on PATH (`where bash.exe`). Deliberately NOTHING wider — a
+ * per-user Git install in `%LOCALAPPDATA%` that is not on PATH is invisible
+ * to pi, and a doctor that reported it green would bless a machine where the
+ * first bash tool call throws. Pure function of env, like the gh probe.
+ */
+export function bashOnWindowsDefault(env = process.env) {
+    for (const root of [env.ProgramFiles, env["ProgramFiles(x86)"]]) {
+        if (!root)
+            continue;
+        const candidate = join(root, "Git", "bin", "bash.exe");
+        if (existsSync(candidate))
+            return { found: true, where: candidate };
+    }
+    for (const dir of (env.PATH ?? "").split(delimiter)) {
+        if (!dir)
+            continue;
+        const candidate = join(dir, "bash.exe");
+        if (existsSync(candidate))
+            return { found: true, where: candidate };
+    }
+    return { found: false };
+}
 /**
  * Gather every check result against the (injectable) probes. Pure ordering; each
  * individual check is a pure function of its probe.
@@ -308,10 +352,18 @@ export async function gatherChecks(deps = {}) {
     const probeBackend = deps.probeBackend ?? defaultProbeBackend;
     const probeStateDir = deps.probeStateDir ?? defaultProbeStateDir;
     const ghOnPath = deps.ghOnPath ?? (() => ghOnPathDefault());
+    const platform = deps.platform ?? process.platform;
+    const probeBash = deps.probeBash ?? (() => bashOnWindowsDefault());
     const probeLatestVersion = deps.probeLatestVersion ?? (() => fetchLatestVersion());
     const checks = [];
     checks.push(checkPiEngine(probePiEngine()));
     checks.push(checkExtension(probeExtension()));
+    // win32 only, and skipped means NOT SHOWN: on macOS/Linux there is nothing
+    // to say. pi shells out through bash, so a Windows machine without Git Bash
+    // cannot launch at all — a required red, like a missing engine.
+    if (platform === "win32") {
+        checks.push(checkBash(probeBash()));
+    }
     checks.push(checkCliUpdate({
         current: deps.currentVersion ?? currentCliVersion(),
         latest: await probeLatestVersion(),

package/dist/extension/askAdvisorTool.js

@@ -113,7 +113,13 @@ export function makeAskAdvisorTool(opts) {
                 content: [{ type: "text", text: "Consulting the advisor…" }],
                 details: { consults: opts.state.read().consults, cost: 0 },
             });
-            const result = await runStage(advisorStage(), { ticket: buildConsultBrief(params) }, { cwd: ctx?.cwd ?? process.cwd(), ...(signal ? { signal } : {}) });
+            const result = await runStage(advisorStage(), { ticket: buildConsultBrief(params) }, {
+                cwd: ctx?.cwd ?? process.cwd(),
+                ...(signal ? { signal } : {}),
+                // YAG-471: attribute the consult's completions to the advisor, not
+                // the "plan" stage id advisorStage() borrows (see its docblock).
+                callerLabel: "advisor",
+            });
             const cost = result.usage?.cost ?? 0;
             const state = opts.state.record(cost);
             if (result.exitCode !== 0 && !result.finalOutput.trim()) {

package/dist/extension/bless.js

@@ -17,6 +17,14 @@
  * one (and vice versa). Everything is pure except the in-memory rule list.
  */
 import { dirname, isAbsolute, relative, resolve, sep } from "node:path";
+/**
+ * Windows-only separator normalization so prefixes compare and display with
+ * `/` on every platform: pi's tools emit forward-slash paths even on Windows,
+ * and a rule keyed `C:\repo\src\api` would silently never match a call for
+ * `C:/repo/src/api/a.ts`. On POSIX this is the identity (a `\` there is a
+ * legal filename character, not a separator).
+ */
+const norm = sep === "\\" ? (p) => p.split("\\").join("/") : (p) => p;
 /** The file path a call targets, or null for path-less tools (bash). */
 export function blessPath(params) {
     const p = params.path;
@@ -25,7 +33,12 @@ export function blessPath(params) {
 /** Build a fresh, empty session bless store rooted at `cwd`. */
 export function makeBlessStore(cwd) {
     const rules = [];
-    const abs = (p) => (isAbsolute(p) ? p : resolve(cwd, p));
+    // Always THROUGH resolve, even for absolute inputs: on Windows a bare
+    // "/repo/…" is drive-relative and resolve() drive-qualifies it, so a rule
+    // minted from a relative path and a call carrying an absolute one land on
+    // the same canonical form. (For an already-absolute POSIX path this is just
+    // normalization.)
+    const abs = (p) => norm(resolve(cwd, p));
     /** Absolute directory prefix a bless of this call would cover, or null. */
     function prefixFor(params) {
         const p = blessPath(params);
@@ -41,7 +54,7 @@ export function makeBlessStore(cwd) {
             const prefix = prefixFor(params);
             if (prefix === null)
                 return null;
-            const rel = relative(cwd, prefix);
+            const rel = norm(relative(cwd, prefix));
             // Inside the tree → the relative dir (or "." for the repo root); outside →
             // the absolute path so the user sees exactly what they are blessing.
             if (rel === "")
@@ -64,7 +77,7 @@ export function makeBlessStore(cwd) {
             if (p === null)
                 return false; // path-less (bash) never auto-approves
             const target = abs(p);
-            return rules.some((r) => r.tool === tool && (target === r.prefix || target.startsWith(r.prefix + sep)));
+            return rules.some((r) => r.tool === tool && (target === r.prefix || target.startsWith(`${r.prefix}/`)));
         },
         rules() {
             return rules.slice();

package/dist/extension/boostCommand.d.ts

@@ -0,0 +1,144 @@
+/**
+ * `/boost` — the sanctioned session-scoped escalation to Peak (spec §7).
+ *
+ * The session default is the `balanced` tier. `/boost` flips the
+ * DRIVER session's live model to `peak` until `/boost off` or the process
+ * exits; `peak` stays directly pickable through pi's own model picker too,
+ * this just adds a one-word lever plus an attribution flag.
+ *
+ * Two halves, same split as `advisor.ts` / `permission.ts`:
+ *
+ *   - `boostOn` / `boostOff` are PURE. They own every transition and the exact
+ *     notice copy; no pi, no I/O, no env. That is what needs exhaustive tests.
+ *   - `registerBoostCommand` is the wiring: it applies the pure result's
+ *     `targetModelId` through pi's real model-switch API, toggles
+ *     `process.env.YAGNI_BOOST`, and paints the notice + a status-bar chip.
+ *
+ * The model-switch API (verified against pi 0.83.0's typings, not guessed):
+ * `ctx.modelRegistry.find(provider, modelId)` resolves a tier id to a
+ * `Model`, and `pi.setModel(model)` (the top-level `ExtensionAPI` method, NOT
+ * `ctx.setModel` — `ExtensionCommandContext` does not expose a setter) applies
+ * it to the live session, resolving `false` when no API key is configured.
+ * The `yagni` provider's catalog entries key `id` on the tier id itself (see
+ * `provider.ts`), so `peak` is the pi model id for the peak tier.
+ *
+ * State lives in the registration closure — module/session-scoped, mirroring
+ * `costHud.ts`'s accumulator — because a session's process exit is the only
+ * "end" there is; nothing needs to persist across it. `registerBoostCommand`
+ * returns a small `{ isBoosted() }` handle onto that same closure so other
+ * registrations (currently just `/cost`, see below) can read the live flag
+ * without a second source of truth.
+ *
+ * Picker-drift guard (spec review item 3): pi's OWN model picker (Ctrl+P,
+ * `/model`) can change the live model independently of `/boost` in either
+ * direction, so `state.active` can go stale relative to `ctx.model.id`. Both
+ * halves read the live model and reconcile rather than trusting `state.active`
+ * blindly:
+ *
+ *   - `boostOn` while already active but the live model has drifted OFF peak
+ *     (the user cycled models mid-boost without `/boost off`): re-applies
+ *     peak instead of a silent "Already boosted." that would leave the
+ *     driver quietly running a cheaper tier under an attribution header that
+ *     claims otherwise. The remembered `priorModelId` is left untouched — the
+ *     tier to restore is still whatever was active before the ORIGINAL boost,
+ *     not the tier the user happened to drift to.
+ *   - `boostOff` while active but the live model is no longer peak (same
+ *     drift, encountered from the other command): the user already left
+ *     boost manually, so forcing a switch back to the remembered prior tier
+ *     would clobber a choice they just made on purpose. Instead this clears
+ *     `/boost`'s own bookkeeping (state, env, chip) without touching the
+ *     model, and names where they actually landed.
+ *
+ * KNOWN asymmetry, documented rather than worked around: `YAGNI_BOOST=1`
+ * while boosted makes every CHILD process spawned during the boost (a /go
+ * run, a subagent, an advisor consult) inherit it, and those children's
+ * completions carry `x-yagni-boost` because their provider is registered
+ * fresh per child. The DRIVER's own completions do not gain that header
+ * retroactively — `buildYagniProvider`'s headers are baked into the
+ * `registerProvider` call once, at session start, from the env snapshot at
+ * that moment (see `provider.ts` / `attributionHeaders`). Re-registering the
+ * provider mid-session to pick up a new header is explicitly NOT the fix
+ * here: it would race the in-flight request the switch itself triggers and
+ * has no test coverage as a live-swap path.
+ *
+ * This is exactly why `/cost` cannot rely on server rows alone: the server's
+ * per-tier "Boosted (tier) spend" subtotal (`formatServerCostLines`, Task 7)
+ * only ever sees rows carrying `x-yagni-boost` — i.e. `/go` children, never
+ * the driver's own turns. A session that only chats while boosted would
+ * otherwise show no boost line at all. `registerCostCommand`'s `isBoosted`
+ * dep (threaded from THIS module's return handle, the same way
+ * `advisorSubtotal` is threaded from `advisor.ts`) closes that gap: `/cost`
+ * appends a fixed "Boost is on. Driver turns bill at the peak tier." line
+ * whenever the live toggle is on, on BOTH the server-authoritative and the
+ * local-fallback branch, independent of what server rows happen to show.
+ */
+import type { ExtensionAPI } from "@earendil-works/pi-coding-agent";
+/** Session-scoped boost state, held in the registration closure. */
+export interface BoostState {
+    active: boolean;
+    /** The tier to restore on `/boost off`. Set only while `active`. */
+    priorModelId?: string;
+}
+/** The pure outcome of a `/boost` transition. */
+export interface BoostResult {
+    state: BoostState;
+    /** Exact notice text to surface to the user. */
+    notice: string;
+    /** The tier id to switch the session to, or undefined for a pure no-op. */
+    targetModelId?: string;
+}
+/**
+ * Turn boost on. PURE.
+ *
+ * - Already active AND the live model is still `peak`: genuine no-op,
+ *   "Already boosted." (no switch — nothing about the prior tier changes).
+ * - Already active but the live model has drifted off `peak` (picker-drift
+ *   guard 3b, see module docblock): re-applies `peak`, keeping the ORIGINAL
+ *   `priorModelId` rather than adopting the drifted-to tier.
+ * - Not active, current model IS already `peak`: activates anyway (so
+ *   attribution and `/boost off` behave correctly) with a distinct notice,
+ *   remembering `peak` itself as the tier to restore.
+ * - Not active, otherwise: remembers the current tier, targets `peak`.
+ */
+export declare function boostOn(state: BoostState, currentModelId: string | undefined): BoostResult;
+/**
+ * Turn boost off. PURE.
+ *
+ * - Not active: no-op, "Boost is not on."
+ * - Active but the live model is no longer `peak` (picker-drift guard 3a,
+ *   see module docblock): the user already left boost manually. Clears
+ *   `/boost`'s own bookkeeping WITHOUT a switch — forcing one back to the
+ *   remembered prior tier would clobber a choice just made on purpose — and
+ *   names the model they actually landed on.
+ * - Active and still on `peak`: restores the remembered prior tier (falling
+ *   back to the session default when none was recorded, which should not
+ *   normally happen). When the prior tier is itself `peak` (the
+ *   already-on-Peak activation path), the resulting switch is a no-op in
+ *   effect — still applied, harmlessly.
+ */
+export declare function boostOff(state: BoostState, currentModelId: string | undefined): BoostResult;
+/** Injectable seams for `registerBoostCommand`. */
+export interface RegisterBoostCommandDeps {
+    /** Environment `YAGNI_BOOST` is toggled on. Defaults to `process.env`. */
+    env?: NodeJS.ProcessEnv;
+}
+/** What `registerBoostCommand` hands back so other registrations (`/cost`) can read the live flag. */
+export interface BoostCommandHandle {
+    /** Whether the session is currently boosted, read fresh off the same closure `/boost` mutates. */
+    isBoosted(): boolean;
+}
+/**
+ * Register the `/boost` command.
+ *
+ * `/boost` (no args) turns boost on; `/boost off` turns it off; any other
+ * argument shows a usage notice and changes nothing. Every transition that
+ * requires a model switch runs it through pi's real API and is guarded end to
+ * end: state and `YAGNI_BOOST` are only ever committed together, AFTER the
+ * switch succeeds (or is deliberately skipped — the picker-drift guards), so
+ * a half-applied boost (env set but model unchanged, or vice versa) can never
+ * happen. A failed ON reports "Boost failed."; a failed OFF reports a
+ * DISTINCT message, because the failure mode is materially worse — the
+ * driver is left still running (and billing) on Peak, not merely unchanged.
+ */
+export declare function registerBoostCommand(pi: ExtensionAPI, deps?: RegisterBoostCommandDeps): BoostCommandHandle;
+//# sourceMappingURL=boostCommand.d.ts.map

package/dist/extension/boostCommand.js

@@ -0,0 +1,263 @@
+/**
+ * `/boost` — the sanctioned session-scoped escalation to Peak (spec §7).
+ *
+ * The session default is the `balanced` tier. `/boost` flips the
+ * DRIVER session's live model to `peak` until `/boost off` or the process
+ * exits; `peak` stays directly pickable through pi's own model picker too,
+ * this just adds a one-word lever plus an attribution flag.
+ *
+ * Two halves, same split as `advisor.ts` / `permission.ts`:
+ *
+ *   - `boostOn` / `boostOff` are PURE. They own every transition and the exact
+ *     notice copy; no pi, no I/O, no env. That is what needs exhaustive tests.
+ *   - `registerBoostCommand` is the wiring: it applies the pure result's
+ *     `targetModelId` through pi's real model-switch API, toggles
+ *     `process.env.YAGNI_BOOST`, and paints the notice + a status-bar chip.
+ *
+ * The model-switch API (verified against pi 0.83.0's typings, not guessed):
+ * `ctx.modelRegistry.find(provider, modelId)` resolves a tier id to a
+ * `Model`, and `pi.setModel(model)` (the top-level `ExtensionAPI` method, NOT
+ * `ctx.setModel` — `ExtensionCommandContext` does not expose a setter) applies
+ * it to the live session, resolving `false` when no API key is configured.
+ * The `yagni` provider's catalog entries key `id` on the tier id itself (see
+ * `provider.ts`), so `peak` is the pi model id for the peak tier.
+ *
+ * State lives in the registration closure — module/session-scoped, mirroring
+ * `costHud.ts`'s accumulator — because a session's process exit is the only
+ * "end" there is; nothing needs to persist across it. `registerBoostCommand`
+ * returns a small `{ isBoosted() }` handle onto that same closure so other
+ * registrations (currently just `/cost`, see below) can read the live flag
+ * without a second source of truth.
+ *
+ * Picker-drift guard (spec review item 3): pi's OWN model picker (Ctrl+P,
+ * `/model`) can change the live model independently of `/boost` in either
+ * direction, so `state.active` can go stale relative to `ctx.model.id`. Both
+ * halves read the live model and reconcile rather than trusting `state.active`
+ * blindly:
+ *
+ *   - `boostOn` while already active but the live model has drifted OFF peak
+ *     (the user cycled models mid-boost without `/boost off`): re-applies
+ *     peak instead of a silent "Already boosted." that would leave the
+ *     driver quietly running a cheaper tier under an attribution header that
+ *     claims otherwise. The remembered `priorModelId` is left untouched — the
+ *     tier to restore is still whatever was active before the ORIGINAL boost,
+ *     not the tier the user happened to drift to.
+ *   - `boostOff` while active but the live model is no longer peak (same
+ *     drift, encountered from the other command): the user already left
+ *     boost manually, so forcing a switch back to the remembered prior tier
+ *     would clobber a choice they just made on purpose. Instead this clears
+ *     `/boost`'s own bookkeeping (state, env, chip) without touching the
+ *     model, and names where they actually landed.
+ *
+ * KNOWN asymmetry, documented rather than worked around: `YAGNI_BOOST=1`
+ * while boosted makes every CHILD process spawned during the boost (a /go
+ * run, a subagent, an advisor consult) inherit it, and those children's
+ * completions carry `x-yagni-boost` because their provider is registered
+ * fresh per child. The DRIVER's own completions do not gain that header
+ * retroactively — `buildYagniProvider`'s headers are baked into the
+ * `registerProvider` call once, at session start, from the env snapshot at
+ * that moment (see `provider.ts` / `attributionHeaders`). Re-registering the
+ * provider mid-session to pick up a new header is explicitly NOT the fix
+ * here: it would race the in-flight request the switch itself triggers and
+ * has no test coverage as a live-swap path.
+ *
+ * This is exactly why `/cost` cannot rely on server rows alone: the server's
+ * per-tier "Boosted (tier) spend" subtotal (`formatServerCostLines`, Task 7)
+ * only ever sees rows carrying `x-yagni-boost` — i.e. `/go` children, never
+ * the driver's own turns. A session that only chats while boosted would
+ * otherwise show no boost line at all. `registerCostCommand`'s `isBoosted`
+ * dep (threaded from THIS module's return handle, the same way
+ * `advisorSubtotal` is threaded from `advisor.ts`) closes that gap: `/cost`
+ * appends a fixed "Boost is on. Driver turns bill at the peak tier." line
+ * whenever the live toggle is on, on BOTH the server-authoritative and the
+ * local-fallback branch, independent of what server rows happen to show.
+ */
+/** The pi provider name the YAGNI catalog registers under (see `provider.ts`). */
+const YAGNI_PROVIDER = "yagni";
+/** The tier `/boost` escalates to. */
+const BOOST_TIER = "peak";
+/** The session default tier, restored when no prior tier is known. */
+const DEFAULT_TIER = "balanced";
+/** Tier ids are lowercase; every known tier's display name is just Title Case of the id. */
+function displayTierName(id) {
+    return id.length === 0 ? id : id.charAt(0).toUpperCase() + id.slice(1);
+}
+/**
+ * Turn boost on. PURE.
+ *
+ * - Already active AND the live model is still `peak`: genuine no-op,
+ *   "Already boosted." (no switch — nothing about the prior tier changes).
+ * - Already active but the live model has drifted off `peak` (picker-drift
+ *   guard 3b, see module docblock): re-applies `peak`, keeping the ORIGINAL
+ *   `priorModelId` rather than adopting the drifted-to tier.
+ * - Not active, current model IS already `peak`: activates anyway (so
+ *   attribution and `/boost off` behave correctly) with a distinct notice,
+ *   remembering `peak` itself as the tier to restore.
+ * - Not active, otherwise: remembers the current tier, targets `peak`.
+ */
+export function boostOn(state, currentModelId) {
+    if (state.active) {
+        if (currentModelId === BOOST_TIER) {
+            return { state, notice: "Already boosted." };
+        }
+        return {
+            state,
+            notice: `Re-boosted to Peak. /boost off to return to ${displayTierName(state.priorModelId ?? DEFAULT_TIER)}.`,
+            targetModelId: BOOST_TIER,
+        };
+    }
+    if (currentModelId === BOOST_TIER) {
+        return {
+            state: { active: true, priorModelId: BOOST_TIER },
+            notice: "Already on Peak. /boost off returns to Peak.",
+            targetModelId: BOOST_TIER,
+        };
+    }
+    return {
+        state: { active: true, priorModelId: currentModelId },
+        notice: `Boosted to Peak. /boost off to return to ${displayTierName(currentModelId ?? DEFAULT_TIER)}.`,
+        targetModelId: BOOST_TIER,
+    };
+}
+/**
+ * Turn boost off. PURE.
+ *
+ * - Not active: no-op, "Boost is not on."
+ * - Active but the live model is no longer `peak` (picker-drift guard 3a,
+ *   see module docblock): the user already left boost manually. Clears
+ *   `/boost`'s own bookkeeping WITHOUT a switch — forcing one back to the
+ *   remembered prior tier would clobber a choice just made on purpose — and
+ *   names the model they actually landed on.
+ * - Active and still on `peak`: restores the remembered prior tier (falling
+ *   back to the session default when none was recorded, which should not
+ *   normally happen). When the prior tier is itself `peak` (the
+ *   already-on-Peak activation path), the resulting switch is a no-op in
+ *   effect — still applied, harmlessly.
+ */
+export function boostOff(state, currentModelId) {
+    if (!state.active) {
+        return { state, notice: "Boost is not on." };
+    }
+    if (currentModelId !== BOOST_TIER) {
+        return {
+            state: { active: false, priorModelId: undefined },
+            notice: `Boost off. Leaving the model on ${displayTierName(currentModelId ?? DEFAULT_TIER)}.`,
+        };
+    }
+    const priorId = state.priorModelId ?? DEFAULT_TIER;
+    return {
+        state: { active: false, priorModelId: undefined },
+        notice: `Back to ${displayTierName(priorId)}.`,
+        targetModelId: priorId,
+    };
+}
+/**
+ * Resolve `tierId` to a live `Model` and apply it via `pi.setModel`.
+ *
+ * On a registry lookup miss, `allowFallback` (true only on the OFF path —
+ * MINOR 5) retries once against the session default tier rather than
+ * stranding the user on Peak over one missing catalog entry. Returns the
+ * tier id that was ACTUALLY applied, so the caller can tell whether the
+ * fallback fired and adjust the notice to name it honestly.
+ *
+ * @throws when neither the requested tier nor (if allowed) the fallback
+ * resolves, or when `pi.setModel` itself throws or resolves `false`.
+ */
+async function applyTier(pi, ctx, tierId, allowFallback) {
+    let model = ctx.modelRegistry?.find(YAGNI_PROVIDER, tierId);
+    let applied = tierId;
+    if (!model && allowFallback && tierId !== DEFAULT_TIER) {
+        model = ctx.modelRegistry?.find(YAGNI_PROVIDER, DEFAULT_TIER);
+        applied = DEFAULT_TIER;
+    }
+    if (!model) {
+        throw new Error(`Unknown YAGNI tier "${tierId}".`);
+    }
+    const ok = await pi.setModel(model);
+    if (!ok) {
+        throw new Error("setModel reported no API key configured.");
+    }
+    return applied;
+}
+/**
+ * Register the `/boost` command.
+ *
+ * `/boost` (no args) turns boost on; `/boost off` turns it off; any other
+ * argument shows a usage notice and changes nothing. Every transition that
+ * requires a model switch runs it through pi's real API and is guarded end to
+ * end: state and `YAGNI_BOOST` are only ever committed together, AFTER the
+ * switch succeeds (or is deliberately skipped — the picker-drift guards), so
+ * a half-applied boost (env set but model unchanged, or vice versa) can never
+ * happen. A failed ON reports "Boost failed."; a failed OFF reports a
+ * DISTINCT message, because the failure mode is materially worse — the
+ * driver is left still running (and billing) on Peak, not merely unchanged.
+ */
+export function registerBoostCommand(pi, deps = {}) {
+    const env = deps.env ?? process.env;
+    let state = { active: false };
+    const paintStatus = (ctx, active) => {
+        try {
+            if (ctx.hasUI)
+                ctx.ui.setStatus?.("yagni-boost", active ? "⚡ Peak" : undefined);
+        }
+        catch {
+            // The chip is chrome; never let it break /boost.
+        }
+    };
+    pi.registerCommand("boost", {
+        description: "Escalate this session's model to Peak until /boost off or the session ends. /boost off returns to the prior tier.",
+        handler: async (args, ctx) => {
+            const notify = (message, type) => {
+                if (ctx.hasUI)
+                    ctx.ui.notify(message, type);
+            };
+            // MINOR 4: case-insensitive "off" match, mirroring /mode's arg handling.
+            const arg = args.trim().toLowerCase();
+            if (arg !== "" && arg !== "off") {
+                notify("Usage: /boost (turn on) or /boost off.", "warning");
+                return;
+            }
+            const isOff = arg === "off";
+            const wasActive = state.active;
+            const result = isOff ? boostOff(state, ctx.model?.id) : boostOn(state, ctx.model?.id);
+            try {
+                let notice = result.notice;
+                if (result.targetModelId) {
+                    const applied = await applyTier(pi, ctx, result.targetModelId, isOff);
+                    if (applied !== result.targetModelId) {
+                        // MINOR 5: the remembered/target tier no longer resolves in the
+                        // catalog; we landed on the session default instead of
+                        // stranding the user on Peak. Name the fallback so the notice
+                        // stays honest about what actually happened.
+                        notice = `Back to ${displayTierName(applied)} (could not restore ${displayTierName(result.targetModelId)}).`;
+                    }
+                }
+                state = result.state;
+                // MINOR 6: only touch the env on a real active/inactive flip. Both
+                // pure no-op paths ("Already boosted.", "Boost is not on.") return
+                // `state` unchanged, so this never fires for them — an inherited
+                // YAGNI_BOOST from outside this session is left exactly as found.
+                if (state.active !== wasActive) {
+                    if (state.active) {
+                        env.YAGNI_BOOST = "1";
+                    }
+                    else {
+                        delete env.YAGNI_BOOST;
+                    }
+                }
+                notify(notice, "info");
+                paintStatus(ctx, state.active);
+            }
+            catch {
+                // IMPORTANT 1: a failed OFF is materially worse than a failed ON —
+                // the driver is STILL on Peak, still billing at Peak rates, which a
+                // generic "Boost failed." does not convey. Neither `state` nor
+                // `YAGNI_BOOST` was touched above (the throw lands before both), so
+                // the chip is also left exactly as it was: still lit.
+                notify(isOff ? "Could not leave boost. Still on Peak; try /boost off again." : "Boost failed.", "error");
+            }
+        },
+    });
+    return { isBoosted: () => state.active };
+}
+//# sourceMappingURL=boostCommand.js.map