@yagni-app/code 0.2.1 → 0.3.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (77) hide show
  1. package/dist/cli.d.ts +30 -0
  2. package/dist/cli.js +135 -3
  3. package/dist/doctor.d.ts +1 -1
  4. package/dist/doctor.js +1 -1
  5. package/dist/extension/advisor.d.ts +4 -4
  6. package/dist/extension/advisor.js +6 -7
  7. package/dist/extension/approvedPrefixes.d.ts +92 -0
  8. package/dist/extension/approvedPrefixes.js +252 -0
  9. package/dist/extension/askAdvisorTool.d.ts +2 -2
  10. package/dist/extension/askAdvisorTool.js +5 -5
  11. package/dist/extension/askYagniTool.js +49 -0
  12. package/dist/extension/branding.d.ts +24 -3
  13. package/dist/extension/branding.js +71 -10
  14. package/dist/extension/chipEditor.d.ts +30 -9
  15. package/dist/extension/chipEditor.js +173 -59
  16. package/dist/extension/claudeRules.d.ts +0 -2
  17. package/dist/extension/claudeRules.js +0 -8
  18. package/dist/extension/cmux/dispatcher.d.ts +25 -0
  19. package/dist/extension/cmux/dispatcher.js +266 -0
  20. package/dist/extension/cmux/hooks.d.ts +12 -0
  21. package/dist/extension/cmux/hooks.js +192 -0
  22. package/dist/extension/cmux/index.d.ts +3 -0
  23. package/dist/extension/cmux/index.js +155 -0
  24. package/dist/extension/cmux/naming.d.ts +5 -0
  25. package/dist/extension/cmux/naming.js +23 -0
  26. package/dist/extension/cmux/state.d.ts +33 -0
  27. package/dist/extension/cmux/state.js +142 -0
  28. package/dist/extension/config.d.ts +32 -1
  29. package/dist/extension/config.js +36 -4
  30. package/dist/extension/costHud.d.ts +16 -22
  31. package/dist/extension/costHud.js +8 -47
  32. package/dist/extension/crashReport.js +1 -3
  33. package/dist/extension/execPolicy.d.ts +119 -0
  34. package/dist/extension/execPolicy.js +805 -0
  35. package/dist/extension/footer.d.ts +111 -0
  36. package/dist/extension/footer.js +294 -0
  37. package/dist/extension/guardian.d.ts +129 -0
  38. package/dist/extension/guardian.js +213 -0
  39. package/dist/extension/index.d.ts +15 -4
  40. package/dist/extension/index.js +250 -24
  41. package/dist/extension/permission.d.ts +123 -10
  42. package/dist/extension/permission.js +586 -40
  43. package/dist/extension/pipeline/childRegistry.d.ts +41 -0
  44. package/dist/extension/pipeline/childRegistry.js +118 -0
  45. package/dist/extension/pipeline/finish.js +5 -1
  46. package/dist/extension/pipeline/goCommand.d.ts +1 -1
  47. package/dist/extension/pipeline/goCommand.js +35 -6
  48. package/dist/extension/pipeline/goStatusCommands.d.ts +10 -0
  49. package/dist/extension/pipeline/goStatusCommands.js +61 -1
  50. package/dist/extension/pipeline/personas.js +25 -0
  51. package/dist/extension/pipeline/runRegistry.d.ts +14 -0
  52. package/dist/extension/pipeline/runRegistry.js +35 -0
  53. package/dist/extension/pipeline/runner.js +4 -0
  54. package/dist/extension/pipeline/verify.d.ts +4 -0
  55. package/dist/extension/pipeline/verify.js +48 -26
  56. package/dist/extension/redact.d.ts +20 -0
  57. package/dist/extension/redact.js +64 -0
  58. package/dist/extension/rerouteNotice.d.ts +3 -4
  59. package/dist/extension/rerouteNotice.js +20 -11
  60. package/dist/extension/subagentRender.d.ts +129 -0
  61. package/dist/extension/subagentRender.js +441 -0
  62. package/dist/extension/subagents.d.ts +4 -7
  63. package/dist/extension/subagents.js +103 -33
  64. package/dist/extension/ticketTools.d.ts +37 -0
  65. package/dist/extension/ticketTools.js +117 -0
  66. package/dist/extension/tokenProvider.js +46 -5
  67. package/dist/launch.d.ts +7 -0
  68. package/dist/launch.js +24 -12
  69. package/dist/padding.d.ts +22 -0
  70. package/dist/padding.js +25 -0
  71. package/dist/promptEnrichment.d.ts +40 -0
  72. package/dist/promptEnrichment.js +85 -0
  73. package/dist/signalForward.d.ts +60 -0
  74. package/dist/signalForward.js +130 -0
  75. package/package.json +5 -5
  76. package/dist/extension/boostCommand.d.ts +0 -144
  77. package/dist/extension/boostCommand.js +0 -263
@@ -0,0 +1,130 @@
1
+ /**
2
+ * Termination-signal forwarding: launcher → pi child.
3
+ *
4
+ * In the interactive TUI the tty is in raw mode, so Ctrl+C never raises
5
+ * SIGINT; this path covers `yagni -p`/piped/CI runs and an external
6
+ * `kill <launcher pid>`. Policy:
7
+ *
8
+ * - The FIRST signal asks pi to shut down cleanly. SIGINT is translated to
9
+ * SIGTERM because pi installs a graceful handler for SIGTERM (it kills its
10
+ * tracked children) but none for SIGINT — a raw SIGINT would drop pi on the
11
+ * default disposition with no cleanup.
12
+ * - Any SECOND signal hard-kills pi's whole process TREE. A bare SIGKILL to
13
+ * pi's pid would bypass its exit sweep (SIGKILL runs no handlers) and leave
14
+ * /go workers alive, so the launcher enumerates and kills the descendants
15
+ * itself: `ps` walk on POSIX, `taskkill /T /F` on Windows.
16
+ */
17
+ import { spawnSync } from "node:child_process";
18
+ import { constants as osConstants } from "node:os";
19
+ /** The launcher-terminating signals that are forwarded rather than obeyed. */
20
+ export const FORWARDED_SIGNALS = ["SIGINT", "SIGTERM", "SIGHUP"];
21
+ /**
22
+ * PURE policy for the FIRST signal: which signal the child receives when the
23
+ * launcher gets `received` (SIGINT is translated, the rest pass through).
24
+ * Escalation is not expressed here — a second signal goes through the tree
25
+ * kill, not a forwarded signal.
26
+ */
27
+ export function forwardedSignal(received) {
28
+ return received === "SIGINT" ? "SIGTERM" : received;
29
+ }
30
+ /**
31
+ * PURE: the launcher's own exit code for the child's (code, signal) exit tuple.
32
+ * A signal-terminated child maps to the conventional 128+n (bash parity:
33
+ * SIGTERM→143, SIGKILL→137, SIGINT→130), so a cancelled run never reads as
34
+ * success to scripts or CI.
35
+ */
36
+ export function exitCodeFor(code, signal) {
37
+ if (code != null)
38
+ return code;
39
+ if (signal)
40
+ return 128 + (osConstants.signals[signal] ?? 15);
41
+ return 0;
42
+ }
43
+ /**
44
+ * PURE: given `ps -A -o pid=,ppid=` output lines, collect every descendant of
45
+ * the given roots (children, grandchildren, ...), breadth-first. Mirrored in
46
+ * pi-extension-yagni's childRegistry (the packages are intentionally
47
+ * independent); keep the two in sync.
48
+ */
49
+ export function descendantsOf(roots, psLines) {
50
+ const childrenByParent = new Map();
51
+ for (const line of psLines) {
52
+ const m = line.trim().match(/^(\d+)\s+(\d+)$/);
53
+ if (!m)
54
+ continue;
55
+ const pid = Number(m[1]);
56
+ const ppid = Number(m[2]);
57
+ const list = childrenByParent.get(ppid) ?? [];
58
+ list.push(pid);
59
+ childrenByParent.set(ppid, list);
60
+ }
61
+ const found = [];
62
+ const queue = [...roots];
63
+ while (queue.length > 0) {
64
+ const next = queue.shift();
65
+ for (const child of childrenByParent.get(next) ?? []) {
66
+ found.push(child);
67
+ queue.push(child);
68
+ }
69
+ }
70
+ return found;
71
+ }
72
+ /**
73
+ * Synchronously SIGKILL a process AND its descendants (POSIX `ps` walk /
74
+ * Windows `taskkill /T /F`). Throw-proof; fail-soft to a direct kill when no
75
+ * process snapshot is readable.
76
+ */
77
+ export function killTreeSync(pid) {
78
+ if (process.platform === "win32") {
79
+ try {
80
+ spawnSync("taskkill", ["/pid", String(pid), "/T", "/F"], { stdio: "ignore" });
81
+ }
82
+ catch {
83
+ /* best effort */
84
+ }
85
+ return;
86
+ }
87
+ let descendants = [];
88
+ try {
89
+ const ps = spawnSync("ps", ["-A", "-o", "pid=,ppid="], { encoding: "utf8" });
90
+ if (ps.status === 0 && typeof ps.stdout === "string") {
91
+ descendants = descendantsOf([pid], ps.stdout.split("\n"));
92
+ }
93
+ }
94
+ catch {
95
+ /* no snapshot: fall through to the direct kill */
96
+ }
97
+ for (const target of [pid, ...descendants]) {
98
+ try {
99
+ process.kill(target, "SIGKILL");
100
+ }
101
+ catch {
102
+ /* already dead */
103
+ }
104
+ }
105
+ }
106
+ /**
107
+ * Subscribe the forwarding policy for every signal in {@link FORWARDED_SIGNALS}.
108
+ * `subscribe` and `killTree` default to the real process surfaces and are
109
+ * injectable so tests never install real handlers, raise real signals, or kill
110
+ * real processes. Returns the forward function itself (also for tests).
111
+ * pid guard: a child whose spawn failed has no pid, and `kill()` would resolve
112
+ * that to the whole process group.
113
+ */
114
+ export function installSignalForwarding(child, subscribe = (sig, handler) => process.on(sig, handler), killTree = killTreeSync) {
115
+ let received = 0;
116
+ const forward = (sig) => {
117
+ const prior = received;
118
+ received += 1;
119
+ if (!child.pid)
120
+ return;
121
+ if (prior > 0)
122
+ killTree(child.pid);
123
+ else
124
+ child.kill(forwardedSignal(sig));
125
+ };
126
+ for (const sig of FORWARDED_SIGNALS)
127
+ subscribe(sig, () => forward(sig));
128
+ return forward;
129
+ }
130
+ //# sourceMappingURL=signalForward.js.map
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@yagni-app/code",
3
- "version": "0.2.1",
3
+ "version": "0.3.0",
4
4
  "description": "YAGNI Code: a terminal coding agent that already knows your company. One YAGNI login routes the model and grounds the agent in your team's context.",
5
5
  "license": "SEE LICENSE IN LICENSE.md",
6
6
  "author": "YAGNI, Inc. <jack@yagni.app> (https://yagni.app)",
@@ -34,9 +34,9 @@
34
34
  "main": "./dist/cli.js",
35
35
  "types": "./dist/cli.d.ts",
36
36
  "dependencies": {
37
- "@earendil-works/pi-coding-agent": "0.83.0",
38
- "@earendil-works/pi-tui": "0.83.0",
39
- "typebox": "^1.1.38"
37
+ "@earendil-works/pi-coding-agent": "0.84.1",
38
+ "@earendil-works/pi-tui": "0.84.1",
39
+ "typebox": "^1.3.11"
40
40
  },
41
- "yagniSourceSha": "33b62c8a01064f7681085e441aa00b02693b13c7"
41
+ "yagniSourceSha": "7542705a2c99f19849bf98bbd5c2e712f5f47fd3"
42
42
  }
@@ -1,144 +0,0 @@
1
- /**
2
- * `/boost` — the sanctioned session-scoped escalation to Peak (spec §7).
3
- *
4
- * The session default is the `balanced` tier. `/boost` flips the
5
- * DRIVER session's live model to `peak` until `/boost off` or the process
6
- * exits; `peak` stays directly pickable through pi's own model picker too,
7
- * this just adds a one-word lever plus an attribution flag.
8
- *
9
- * Two halves, same split as `advisor.ts` / `permission.ts`:
10
- *
11
- * - `boostOn` / `boostOff` are PURE. They own every transition and the exact
12
- * notice copy; no pi, no I/O, no env. That is what needs exhaustive tests.
13
- * - `registerBoostCommand` is the wiring: it applies the pure result's
14
- * `targetModelId` through pi's real model-switch API, toggles
15
- * `process.env.YAGNI_BOOST`, and paints the notice + a status-bar chip.
16
- *
17
- * The model-switch API (verified against pi 0.83.0's typings, not guessed):
18
- * `ctx.modelRegistry.find(provider, modelId)` resolves a tier id to a
19
- * `Model`, and `pi.setModel(model)` (the top-level `ExtensionAPI` method, NOT
20
- * `ctx.setModel` — `ExtensionCommandContext` does not expose a setter) applies
21
- * it to the live session, resolving `false` when no API key is configured.
22
- * The `yagni` provider's catalog entries key `id` on the tier id itself (see
23
- * `provider.ts`), so `peak` is the pi model id for the peak tier.
24
- *
25
- * State lives in the registration closure — module/session-scoped, mirroring
26
- * `costHud.ts`'s accumulator — because a session's process exit is the only
27
- * "end" there is; nothing needs to persist across it. `registerBoostCommand`
28
- * returns a small `{ isBoosted() }` handle onto that same closure so other
29
- * registrations (currently just `/cost`, see below) can read the live flag
30
- * without a second source of truth.
31
- *
32
- * Picker-drift guard (spec review item 3): pi's OWN model picker (Ctrl+P,
33
- * `/model`) can change the live model independently of `/boost` in either
34
- * direction, so `state.active` can go stale relative to `ctx.model.id`. Both
35
- * halves read the live model and reconcile rather than trusting `state.active`
36
- * blindly:
37
- *
38
- * - `boostOn` while already active but the live model has drifted OFF peak
39
- * (the user cycled models mid-boost without `/boost off`): re-applies
40
- * peak instead of a silent "Already boosted." that would leave the
41
- * driver quietly running a cheaper tier under an attribution header that
42
- * claims otherwise. The remembered `priorModelId` is left untouched — the
43
- * tier to restore is still whatever was active before the ORIGINAL boost,
44
- * not the tier the user happened to drift to.
45
- * - `boostOff` while active but the live model is no longer peak (same
46
- * drift, encountered from the other command): the user already left
47
- * boost manually, so forcing a switch back to the remembered prior tier
48
- * would clobber a choice they just made on purpose. Instead this clears
49
- * `/boost`'s own bookkeeping (state, env, chip) without touching the
50
- * model, and names where they actually landed.
51
- *
52
- * KNOWN asymmetry, documented rather than worked around: `YAGNI_BOOST=1`
53
- * while boosted makes every CHILD process spawned during the boost (a /go
54
- * run, a subagent, an advisor consult) inherit it, and those children's
55
- * completions carry `x-yagni-boost` because their provider is registered
56
- * fresh per child. The DRIVER's own completions do not gain that header
57
- * retroactively — `buildYagniProvider`'s headers are baked into the
58
- * `registerProvider` call once, at session start, from the env snapshot at
59
- * that moment (see `provider.ts` / `attributionHeaders`). Re-registering the
60
- * provider mid-session to pick up a new header is explicitly NOT the fix
61
- * here: it would race the in-flight request the switch itself triggers and
62
- * has no test coverage as a live-swap path.
63
- *
64
- * This is exactly why `/cost` cannot rely on server rows alone: the server's
65
- * per-tier "Boosted (tier) spend" subtotal (`formatServerCostLines`, Task 7)
66
- * only ever sees rows carrying `x-yagni-boost` — i.e. `/go` children, never
67
- * the driver's own turns. A session that only chats while boosted would
68
- * otherwise show no boost line at all. `registerCostCommand`'s `isBoosted`
69
- * dep (threaded from THIS module's return handle, the same way
70
- * `advisorSubtotal` is threaded from `advisor.ts`) closes that gap: `/cost`
71
- * appends a fixed "Boost is on. Driver turns bill at the peak tier." line
72
- * whenever the live toggle is on, on BOTH the server-authoritative and the
73
- * local-fallback branch, independent of what server rows happen to show.
74
- */
75
- import type { ExtensionAPI } from "@earendil-works/pi-coding-agent";
76
- /** Session-scoped boost state, held in the registration closure. */
77
- export interface BoostState {
78
- active: boolean;
79
- /** The tier to restore on `/boost off`. Set only while `active`. */
80
- priorModelId?: string;
81
- }
82
- /** The pure outcome of a `/boost` transition. */
83
- export interface BoostResult {
84
- state: BoostState;
85
- /** Exact notice text to surface to the user. */
86
- notice: string;
87
- /** The tier id to switch the session to, or undefined for a pure no-op. */
88
- targetModelId?: string;
89
- }
90
- /**
91
- * Turn boost on. PURE.
92
- *
93
- * - Already active AND the live model is still `peak`: genuine no-op,
94
- * "Already boosted." (no switch — nothing about the prior tier changes).
95
- * - Already active but the live model has drifted off `peak` (picker-drift
96
- * guard 3b, see module docblock): re-applies `peak`, keeping the ORIGINAL
97
- * `priorModelId` rather than adopting the drifted-to tier.
98
- * - Not active, current model IS already `peak`: activates anyway (so
99
- * attribution and `/boost off` behave correctly) with a distinct notice,
100
- * remembering `peak` itself as the tier to restore.
101
- * - Not active, otherwise: remembers the current tier, targets `peak`.
102
- */
103
- export declare function boostOn(state: BoostState, currentModelId: string | undefined): BoostResult;
104
- /**
105
- * Turn boost off. PURE.
106
- *
107
- * - Not active: no-op, "Boost is not on."
108
- * - Active but the live model is no longer `peak` (picker-drift guard 3a,
109
- * see module docblock): the user already left boost manually. Clears
110
- * `/boost`'s own bookkeeping WITHOUT a switch — forcing one back to the
111
- * remembered prior tier would clobber a choice just made on purpose — and
112
- * names the model they actually landed on.
113
- * - Active and still on `peak`: restores the remembered prior tier (falling
114
- * back to the session default when none was recorded, which should not
115
- * normally happen). When the prior tier is itself `peak` (the
116
- * already-on-Peak activation path), the resulting switch is a no-op in
117
- * effect — still applied, harmlessly.
118
- */
119
- export declare function boostOff(state: BoostState, currentModelId: string | undefined): BoostResult;
120
- /** Injectable seams for `registerBoostCommand`. */
121
- export interface RegisterBoostCommandDeps {
122
- /** Environment `YAGNI_BOOST` is toggled on. Defaults to `process.env`. */
123
- env?: NodeJS.ProcessEnv;
124
- }
125
- /** What `registerBoostCommand` hands back so other registrations (`/cost`) can read the live flag. */
126
- export interface BoostCommandHandle {
127
- /** Whether the session is currently boosted, read fresh off the same closure `/boost` mutates. */
128
- isBoosted(): boolean;
129
- }
130
- /**
131
- * Register the `/boost` command.
132
- *
133
- * `/boost` (no args) turns boost on; `/boost off` turns it off; any other
134
- * argument shows a usage notice and changes nothing. Every transition that
135
- * requires a model switch runs it through pi's real API and is guarded end to
136
- * end: state and `YAGNI_BOOST` are only ever committed together, AFTER the
137
- * switch succeeds (or is deliberately skipped — the picker-drift guards), so
138
- * a half-applied boost (env set but model unchanged, or vice versa) can never
139
- * happen. A failed ON reports "Boost failed."; a failed OFF reports a
140
- * DISTINCT message, because the failure mode is materially worse — the
141
- * driver is left still running (and billing) on Peak, not merely unchanged.
142
- */
143
- export declare function registerBoostCommand(pi: ExtensionAPI, deps?: RegisterBoostCommandDeps): BoostCommandHandle;
144
- //# sourceMappingURL=boostCommand.d.ts.map
@@ -1,263 +0,0 @@
1
- /**
2
- * `/boost` — the sanctioned session-scoped escalation to Peak (spec §7).
3
- *
4
- * The session default is the `balanced` tier. `/boost` flips the
5
- * DRIVER session's live model to `peak` until `/boost off` or the process
6
- * exits; `peak` stays directly pickable through pi's own model picker too,
7
- * this just adds a one-word lever plus an attribution flag.
8
- *
9
- * Two halves, same split as `advisor.ts` / `permission.ts`:
10
- *
11
- * - `boostOn` / `boostOff` are PURE. They own every transition and the exact
12
- * notice copy; no pi, no I/O, no env. That is what needs exhaustive tests.
13
- * - `registerBoostCommand` is the wiring: it applies the pure result's
14
- * `targetModelId` through pi's real model-switch API, toggles
15
- * `process.env.YAGNI_BOOST`, and paints the notice + a status-bar chip.
16
- *
17
- * The model-switch API (verified against pi 0.83.0's typings, not guessed):
18
- * `ctx.modelRegistry.find(provider, modelId)` resolves a tier id to a
19
- * `Model`, and `pi.setModel(model)` (the top-level `ExtensionAPI` method, NOT
20
- * `ctx.setModel` — `ExtensionCommandContext` does not expose a setter) applies
21
- * it to the live session, resolving `false` when no API key is configured.
22
- * The `yagni` provider's catalog entries key `id` on the tier id itself (see
23
- * `provider.ts`), so `peak` is the pi model id for the peak tier.
24
- *
25
- * State lives in the registration closure — module/session-scoped, mirroring
26
- * `costHud.ts`'s accumulator — because a session's process exit is the only
27
- * "end" there is; nothing needs to persist across it. `registerBoostCommand`
28
- * returns a small `{ isBoosted() }` handle onto that same closure so other
29
- * registrations (currently just `/cost`, see below) can read the live flag
30
- * without a second source of truth.
31
- *
32
- * Picker-drift guard (spec review item 3): pi's OWN model picker (Ctrl+P,
33
- * `/model`) can change the live model independently of `/boost` in either
34
- * direction, so `state.active` can go stale relative to `ctx.model.id`. Both
35
- * halves read the live model and reconcile rather than trusting `state.active`
36
- * blindly:
37
- *
38
- * - `boostOn` while already active but the live model has drifted OFF peak
39
- * (the user cycled models mid-boost without `/boost off`): re-applies
40
- * peak instead of a silent "Already boosted." that would leave the
41
- * driver quietly running a cheaper tier under an attribution header that
42
- * claims otherwise. The remembered `priorModelId` is left untouched — the
43
- * tier to restore is still whatever was active before the ORIGINAL boost,
44
- * not the tier the user happened to drift to.
45
- * - `boostOff` while active but the live model is no longer peak (same
46
- * drift, encountered from the other command): the user already left
47
- * boost manually, so forcing a switch back to the remembered prior tier
48
- * would clobber a choice they just made on purpose. Instead this clears
49
- * `/boost`'s own bookkeeping (state, env, chip) without touching the
50
- * model, and names where they actually landed.
51
- *
52
- * KNOWN asymmetry, documented rather than worked around: `YAGNI_BOOST=1`
53
- * while boosted makes every CHILD process spawned during the boost (a /go
54
- * run, a subagent, an advisor consult) inherit it, and those children's
55
- * completions carry `x-yagni-boost` because their provider is registered
56
- * fresh per child. The DRIVER's own completions do not gain that header
57
- * retroactively — `buildYagniProvider`'s headers are baked into the
58
- * `registerProvider` call once, at session start, from the env snapshot at
59
- * that moment (see `provider.ts` / `attributionHeaders`). Re-registering the
60
- * provider mid-session to pick up a new header is explicitly NOT the fix
61
- * here: it would race the in-flight request the switch itself triggers and
62
- * has no test coverage as a live-swap path.
63
- *
64
- * This is exactly why `/cost` cannot rely on server rows alone: the server's
65
- * per-tier "Boosted (tier) spend" subtotal (`formatServerCostLines`, Task 7)
66
- * only ever sees rows carrying `x-yagni-boost` — i.e. `/go` children, never
67
- * the driver's own turns. A session that only chats while boosted would
68
- * otherwise show no boost line at all. `registerCostCommand`'s `isBoosted`
69
- * dep (threaded from THIS module's return handle, the same way
70
- * `advisorSubtotal` is threaded from `advisor.ts`) closes that gap: `/cost`
71
- * appends a fixed "Boost is on. Driver turns bill at the peak tier." line
72
- * whenever the live toggle is on, on BOTH the server-authoritative and the
73
- * local-fallback branch, independent of what server rows happen to show.
74
- */
75
- /** The pi provider name the YAGNI catalog registers under (see `provider.ts`). */
76
- const YAGNI_PROVIDER = "yagni";
77
- /** The tier `/boost` escalates to. */
78
- const BOOST_TIER = "peak";
79
- /** The session default tier, restored when no prior tier is known. */
80
- const DEFAULT_TIER = "balanced";
81
- /** Tier ids are lowercase; every known tier's display name is just Title Case of the id. */
82
- function displayTierName(id) {
83
- return id.length === 0 ? id : id.charAt(0).toUpperCase() + id.slice(1);
84
- }
85
- /**
86
- * Turn boost on. PURE.
87
- *
88
- * - Already active AND the live model is still `peak`: genuine no-op,
89
- * "Already boosted." (no switch — nothing about the prior tier changes).
90
- * - Already active but the live model has drifted off `peak` (picker-drift
91
- * guard 3b, see module docblock): re-applies `peak`, keeping the ORIGINAL
92
- * `priorModelId` rather than adopting the drifted-to tier.
93
- * - Not active, current model IS already `peak`: activates anyway (so
94
- * attribution and `/boost off` behave correctly) with a distinct notice,
95
- * remembering `peak` itself as the tier to restore.
96
- * - Not active, otherwise: remembers the current tier, targets `peak`.
97
- */
98
- export function boostOn(state, currentModelId) {
99
- if (state.active) {
100
- if (currentModelId === BOOST_TIER) {
101
- return { state, notice: "Already boosted." };
102
- }
103
- return {
104
- state,
105
- notice: `Re-boosted to Peak. /boost off to return to ${displayTierName(state.priorModelId ?? DEFAULT_TIER)}.`,
106
- targetModelId: BOOST_TIER,
107
- };
108
- }
109
- if (currentModelId === BOOST_TIER) {
110
- return {
111
- state: { active: true, priorModelId: BOOST_TIER },
112
- notice: "Already on Peak. /boost off returns to Peak.",
113
- targetModelId: BOOST_TIER,
114
- };
115
- }
116
- return {
117
- state: { active: true, priorModelId: currentModelId },
118
- notice: `Boosted to Peak. /boost off to return to ${displayTierName(currentModelId ?? DEFAULT_TIER)}.`,
119
- targetModelId: BOOST_TIER,
120
- };
121
- }
122
- /**
123
- * Turn boost off. PURE.
124
- *
125
- * - Not active: no-op, "Boost is not on."
126
- * - Active but the live model is no longer `peak` (picker-drift guard 3a,
127
- * see module docblock): the user already left boost manually. Clears
128
- * `/boost`'s own bookkeeping WITHOUT a switch — forcing one back to the
129
- * remembered prior tier would clobber a choice just made on purpose — and
130
- * names the model they actually landed on.
131
- * - Active and still on `peak`: restores the remembered prior tier (falling
132
- * back to the session default when none was recorded, which should not
133
- * normally happen). When the prior tier is itself `peak` (the
134
- * already-on-Peak activation path), the resulting switch is a no-op in
135
- * effect — still applied, harmlessly.
136
- */
137
- export function boostOff(state, currentModelId) {
138
- if (!state.active) {
139
- return { state, notice: "Boost is not on." };
140
- }
141
- if (currentModelId !== BOOST_TIER) {
142
- return {
143
- state: { active: false, priorModelId: undefined },
144
- notice: `Boost off. Leaving the model on ${displayTierName(currentModelId ?? DEFAULT_TIER)}.`,
145
- };
146
- }
147
- const priorId = state.priorModelId ?? DEFAULT_TIER;
148
- return {
149
- state: { active: false, priorModelId: undefined },
150
- notice: `Back to ${displayTierName(priorId)}.`,
151
- targetModelId: priorId,
152
- };
153
- }
154
- /**
155
- * Resolve `tierId` to a live `Model` and apply it via `pi.setModel`.
156
- *
157
- * On a registry lookup miss, `allowFallback` (true only on the OFF path —
158
- * MINOR 5) retries once against the session default tier rather than
159
- * stranding the user on Peak over one missing catalog entry. Returns the
160
- * tier id that was ACTUALLY applied, so the caller can tell whether the
161
- * fallback fired and adjust the notice to name it honestly.
162
- *
163
- * @throws when neither the requested tier nor (if allowed) the fallback
164
- * resolves, or when `pi.setModel` itself throws or resolves `false`.
165
- */
166
- async function applyTier(pi, ctx, tierId, allowFallback) {
167
- let model = ctx.modelRegistry?.find(YAGNI_PROVIDER, tierId);
168
- let applied = tierId;
169
- if (!model && allowFallback && tierId !== DEFAULT_TIER) {
170
- model = ctx.modelRegistry?.find(YAGNI_PROVIDER, DEFAULT_TIER);
171
- applied = DEFAULT_TIER;
172
- }
173
- if (!model) {
174
- throw new Error(`Unknown YAGNI tier "${tierId}".`);
175
- }
176
- const ok = await pi.setModel(model);
177
- if (!ok) {
178
- throw new Error("setModel reported no API key configured.");
179
- }
180
- return applied;
181
- }
182
- /**
183
- * Register the `/boost` command.
184
- *
185
- * `/boost` (no args) turns boost on; `/boost off` turns it off; any other
186
- * argument shows a usage notice and changes nothing. Every transition that
187
- * requires a model switch runs it through pi's real API and is guarded end to
188
- * end: state and `YAGNI_BOOST` are only ever committed together, AFTER the
189
- * switch succeeds (or is deliberately skipped — the picker-drift guards), so
190
- * a half-applied boost (env set but model unchanged, or vice versa) can never
191
- * happen. A failed ON reports "Boost failed."; a failed OFF reports a
192
- * DISTINCT message, because the failure mode is materially worse — the
193
- * driver is left still running (and billing) on Peak, not merely unchanged.
194
- */
195
- export function registerBoostCommand(pi, deps = {}) {
196
- const env = deps.env ?? process.env;
197
- let state = { active: false };
198
- const paintStatus = (ctx, active) => {
199
- try {
200
- if (ctx.hasUI)
201
- ctx.ui.setStatus?.("yagni-boost", active ? "⚡ Peak" : undefined);
202
- }
203
- catch {
204
- // The chip is chrome; never let it break /boost.
205
- }
206
- };
207
- pi.registerCommand("boost", {
208
- description: "Escalate this session's model to Peak until /boost off or the session ends. /boost off returns to the prior tier.",
209
- handler: async (args, ctx) => {
210
- const notify = (message, type) => {
211
- if (ctx.hasUI)
212
- ctx.ui.notify(message, type);
213
- };
214
- // MINOR 4: case-insensitive "off" match, mirroring /mode's arg handling.
215
- const arg = args.trim().toLowerCase();
216
- if (arg !== "" && arg !== "off") {
217
- notify("Usage: /boost (turn on) or /boost off.", "warning");
218
- return;
219
- }
220
- const isOff = arg === "off";
221
- const wasActive = state.active;
222
- const result = isOff ? boostOff(state, ctx.model?.id) : boostOn(state, ctx.model?.id);
223
- try {
224
- let notice = result.notice;
225
- if (result.targetModelId) {
226
- const applied = await applyTier(pi, ctx, result.targetModelId, isOff);
227
- if (applied !== result.targetModelId) {
228
- // MINOR 5: the remembered/target tier no longer resolves in the
229
- // catalog; we landed on the session default instead of
230
- // stranding the user on Peak. Name the fallback so the notice
231
- // stays honest about what actually happened.
232
- notice = `Back to ${displayTierName(applied)} (could not restore ${displayTierName(result.targetModelId)}).`;
233
- }
234
- }
235
- state = result.state;
236
- // MINOR 6: only touch the env on a real active/inactive flip. Both
237
- // pure no-op paths ("Already boosted.", "Boost is not on.") return
238
- // `state` unchanged, so this never fires for them — an inherited
239
- // YAGNI_BOOST from outside this session is left exactly as found.
240
- if (state.active !== wasActive) {
241
- if (state.active) {
242
- env.YAGNI_BOOST = "1";
243
- }
244
- else {
245
- delete env.YAGNI_BOOST;
246
- }
247
- }
248
- notify(notice, "info");
249
- paintStatus(ctx, state.active);
250
- }
251
- catch {
252
- // IMPORTANT 1: a failed OFF is materially worse than a failed ON —
253
- // the driver is STILL on Peak, still billing at Peak rates, which a
254
- // generic "Boost failed." does not convey. Neither `state` nor
255
- // `YAGNI_BOOST` was touched above (the throw lands before both), so
256
- // the chip is also left exactly as it was: still lit.
257
- notify(isOff ? "Could not leave boost. Still on Peak; try /boost off again." : "Boost failed.", "error");
258
- }
259
- },
260
- });
261
- return { isBoosted: () => state.active };
262
- }
263
- //# sourceMappingURL=boostCommand.js.map