claudeup 6.3.0 → 6.4.0

package/src/data/models-presets.ts

@@ -0,0 +1,281 @@
+/**
+ * Built-in presets and the shared agent → tier table.
+ *
+ * Hand-written constants rather than a glob over data files, for the same reason
+ * `src/data/styles/index.ts` hand-lists its embedded presets: a glob cannot resolve at
+ * `bun build --compile` time, and this module has to survive into the compiled binary — the
+ * hook path reads a project's own `models.json`, but `claudeup models list` and the TUI read
+ * these.
+ *
+ * Tiers name what a subagent is FOR, on one axis: `smart`, `normal`, `cheap`, plus `main` for
+ * the orchestrator. Which model serves each is the PRESET's call, and `smart` is not always
+ * its largest spend: `fable-advisor` sends the judgement calls to a different model (fable at
+ * `medium`) rather than a harder-working one. What holds everywhere is the other half: the
+ * thread dispatching the work is never strictly the biggest spend in the preset.
+ */
+import type { Grade, ModelsConfig } from "../services/models-core.js";
+
+/**
+ * Which tier each subagent gets, shared by every preset.
+ *
+ * Keys are `subagent_type` strings exactly as the Agent tool receives them: bare names for
+ * Claude Code's built-ins, `plugin:name` for plugin agents. A name absent from this table
+ * falls to the preset's `fallback`, so a newly installed plugin routes sensibly on day one
+ * instead of silently inheriting the orchestrator's model.
+ */
+export const DEFAULT_AGENT_GRADES: Record<string, Grade> = {
+	// `smart` is for JUDGEMENT — work where the agent decides something a person would
+	// argue about, and where being wrong is expensive to undo.
+	Plan: "smart",
+	"dev:architect": "smart",
+	"dev:reviewer": "smart",
+	"dev:debugger": "smart",
+	"multimodel:deep-analyst": "smart",
+
+	// `normal`: transforms material it is GIVEN. Real work, bounded judgement.
+	//
+	// `spec-writer` reads an interview log and writes it up as a spec — the decisions were
+	// made during the interview, and this turns answers into structure. `synthesizer` merges
+	// reviews it is handed into one report against thresholds it is handed. Neither decides
+	// what is true; both were on `smart` because "writes an important document" got confused
+	// with "makes an expensive judgement".
+	"dev:spec-writer": "normal",
+	"dev:synthesizer": "normal",
+
+	// Reading a lot is not analysing.
+	//
+	// `detective` is read-only: it locates implementations, traces a path and reports
+	// file:line. That is high-volume retrieval with light inference — the same shape as
+	// `Explore`, with more structure in the output. It sat on `smart` because "investigates"
+	// sounds like thinking; what it actually does is look.
+	"code-analysis:detective": "cheap",
+
+	// Search, transcription and bookkeeping: bounded, mechanical, high-volume.
+	Explore: "cheap",
+	"dev:scribe": "cheap",
+	"dev:stack-detector": "cheap",
+	"dev:docs": "cheap",
+	"terminal:tui-navigator": "cheap",
+	"gtd:gtd-reviewer": "cheap",
+	"statusline-setup": "cheap",
+};
+
+/**
+ * The three workflows the `dev` plugin actually runs, and the agents each one dispatches.
+ *
+ * A single "17 agents" bar counts every agent claudeup has ever heard of, weighted equally —
+ * which is not how a session spends anything. Nobody runs all seventeen; they run ONE of
+ * these, and what it costs depends on which handful it reaches for. `/dev:investigate`
+ * touching two cheap agents and `/dev:dev` touching five across three tiers are different
+ * answers to "what will this preset cost me", and the lump sum shows neither.
+ *
+ * Read out of `plugins/dev/commands/{dev,debug,investigate}.md` — agents only. Those files
+ * also name skills (`dev:context-detection`, `code-analysis:investigate`) which are not
+ * dispatched through the Agent tool and so are not routed at all.
+ */
+export const WORKFLOWS: { name: string; agents: string[] }[] = [
+	{
+		name: "dev",
+		agents: [
+			"dev:stack-detector",
+			"dev:architect",
+			"dev:developer",
+			"dev:test-architect",
+			"dev:reviewer",
+		],
+	},
+	{
+		name: "debug",
+		agents: [
+			"dev:stack-detector",
+			"code-analysis:detective",
+			"dev:debugger",
+			"dev:developer",
+		],
+	},
+	{
+		name: "investigate",
+		agents: ["code-analysis:detective", "dev:researcher"],
+	},
+];
+
+/**
+ * Agents whose model is a CAPABILITY choice, not a spend choice.
+ *
+ * The three tiers answer "how much model", and that is the wrong question for an agent that
+ * reads images. `designer:design-review` compares a rendered screen against a reference and
+ * `designer:ui` audits a screenshot for usability: what they need is the model that SEES
+ * best, which is not a point on a cheap-to-smart line and does not move when the preset
+ * changes.
+ *
+ * They are deliberately absent from the tier table above and from this map until the model
+ * is chosen from the live catalogue rather than from memory. Absent means they fall to the
+ * preset's `fallback`, which is a defensible default and an honest one; pinning them to a
+ * model id guessed here is neither.
+ */
+export const VISION_AGENTS = ["designer:design-review", "designer:ui"] as const;
+
+/**
+ * `seo:editor` is the one agent in this marketplace whose own frontmatter sets a model.
+ * Routing it to `inherit` keeps that authoring decision visible and working instead of
+ * silently overriding it — per-invocation beats frontmatter, so without this the author's
+ * choice would vanish with no error.
+ */
+const FRONTMATTER_RESPECTED: Record<string, { model: "inherit" }> = {
+	"seo:editor": { model: "inherit" },
+};
+
+function preset(
+	name: string,
+	main: ModelsConfig["main"],
+	grades: ModelsConfig["grades"],
+): ModelsConfig {
+	return {
+		version: 1,
+		preset: name,
+		main,
+		grades,
+		agents: { ...DEFAULT_AGENT_GRADES, ...FRONTMATTER_RESPECTED },
+		fallback: "normal",
+	};
+}
+
+/**
+ * What each preset is CALLED on screen.
+ *
+ * The id (`fable-advisor`) is the machine name: it is what `models use` takes, what lands in
+ * the committed config, and what must never change. The label is what a person reads, and it
+ * says which model leads and which one helps — the thing you actually choose between. Kept
+ * beside the presets rather than in the UI so the CLI and the TUI cannot disagree.
+ */
+export const PRESET_LABELS: Record<string, string> = {
+	"fable-advisor": "Opus with Fable help",
+	"fable-lead": "Fable main",
+	"fable-top": "Fable top",
+	"opus-lead": "Opus main",
+	"sonnet-economy": "Sonnet",
+};
+
+/** The screen name for a preset id, falling back to the id for a hand-edited config. */
+export function presetLabel(id: string): string {
+	return PRESET_LABELS[id] ?? id;
+}
+
+/**
+ * The shipped presets.
+ *
+ * Effort is set per seat and reaches subagents through `modelSettings` — measured by
+ * `benches/agent-model-routing/` (AMR-1), which found alias keys honoured and a routed
+ * subagent running at its model's effort while the main thread kept its own.
+ *
+ * ## Effort belongs to the MODEL, so a preset gets one value per model
+ *
+ * `modelSettings` is keyed by model. Two seats naming the same model therefore cannot carry
+ * different efforts, and the validator rejects that rather than letting one silently win.
+ * That is the only cross-seat rule here: **within one preset, a model appears at exactly one
+ * effort.** Which effort is a per-preset choice — `fable-lead` runs fable at `medium` and
+ * `fable-top` runs it at `xhigh`, and that difference is the whole distinction between them.
+ *
+ * Presets never collide with each other, because only one is ever applied to a project.
+ *
+ * ## The levelling these presets apply
+ *
+ * Each one fixes every model it names at a single effort, which is what makes it writable:
+ *
+ *   opus      xhigh wherever it appears
+ *   fable     medium in `fable-lead`, xhigh in `fable-top`
+ *   sonnet    high in the `cheap` seat, xhigh when it holds the whole preset
+ *   haiku     not used
+ *
+ * A tier therefore differs from its neighbour by MODEL, not by a throttle on one model. That
+ * is not a style choice: a ramp like "fable xhigh on `smart`, fable low on `cheap`" is exactly
+ * what the `modelSettings` keying cannot express.
+ */
+export const BUILT_IN_PRESETS: ModelsConfig[] = [
+	// The default: opus runs everything except the judgement calls, which go to fable.
+	//
+	// Opus takes `main` and `normal` at `xhigh`, fable takes `smart` at its ordinary `medium`,
+	// and sonnet picks up the cheap seat at `high`. The id says what fable DOES here — it
+	// advises on the hard work rather than running the thread.
+	preset(
+		"fable-advisor",
+		{ model: "opus", effort: "xhigh" },
+		{
+			smart: { model: "fable", effort: "medium" },
+			normal: { model: "opus", effort: "xhigh" },
+			cheap: { model: "sonnet", effort: "high" },
+		},
+	),
+
+	// Fable runs everything it can, at its ordinary `medium`, with sonnet on the cheap seat.
+	//
+	// "Fable on the main orchestrator" — the request, literally, extended to the tiers it
+	// dispatches. Paired with `fable-top` below: the same model on `main` and `smart`, one
+	// effort apart.
+	preset(
+		"fable-lead",
+		{ model: "fable", effort: "medium" },
+		{
+			smart: { model: "fable", effort: "medium" },
+			normal: { model: "fable", effort: "medium" },
+			cheap: { model: "sonnet", effort: "high" },
+		},
+	),
+
+	// Fable at full stretch on the thread and the judgement calls; opus does the building.
+	//
+	// `fable-lead` runs fable at `medium` in three seats; this runs it at `xhigh` in two and
+	// hands `normal` — the highest-volume tier, since it is also the `fallback` — to opus.
+	// The difference between the two presets is fable's effort, which is why it has to BE two
+	// presets rather than one with a ramp.
+	preset(
+		"fable-top",
+		{ model: "fable", effort: "xhigh" },
+		{
+			smart: { model: "fable", effort: "xhigh" },
+			normal: { model: "opus", effort: "xhigh" },
+			cheap: { model: "sonnet", effort: "high" },
+		},
+	),
+
+	// Opus everywhere it is reached at all, at `xhigh`; sonnet only on the cheap seat.
+	//
+	// `main`, `smart` and `normal` are one spend decision wearing three names. That is legal
+	// precisely because they agree on effort, and it is the point of the preset rather than a
+	// compromise: the only thing NOT on opus is the searching and transcription.
+	preset(
+		"opus-lead",
+		{ model: "opus", effort: "xhigh" },
+		{
+			smart: { model: "opus", effort: "xhigh" },
+			normal: { model: "opus", effort: "xhigh" },
+			cheap: { model: "sonnet", effort: "high" },
+		},
+	),
+
+	// Sonnet, at `xhigh`, in all four seats.
+	//
+	// This preset deliberately has no tier differentiation: its saving is the model, and the
+	// effort is not throttled on top of it. Every routed agent runs sonnet at `xhigh`,
+	// including `cheap` — so the hook still pins the model (a session started on opus does
+	// not leak into its subagents) while the tier table itself makes no distinction.
+	preset(
+		"sonnet-economy",
+		{ model: "sonnet", effort: "xhigh" },
+		{
+			smart: { model: "sonnet", effort: "xhigh" },
+			normal: { model: "sonnet", effort: "xhigh" },
+			cheap: { model: "sonnet", effort: "xhigh" },
+		},
+	),
+];
+
+export const DEFAULT_PRESET = "fable-advisor";
+
+export function findPreset(name: string): ModelsConfig | undefined {
+	return BUILT_IN_PRESETS.find((p) => p.preset === name);
+}
+
+export function presetNames(): string[] {
+	return BUILT_IN_PRESETS.map((p) => p.preset);
+}

package/src/data/predefined-profiles.ts

@@ -1,3 +1,5 @@
+import type { ModelsConfig } from "../services/models-core.js";
+
 export interface PredefinedProfile {
 	id: string;
 	name: string;
@@ -7,6 +9,13 @@ export interface PredefinedProfile {
 	anthropicPlugins: string[];
 	skills: string[];
 	settings: Record<string, unknown>;
+	/**
+	 * Per-subagent model routing a profile inherits via `extends`. None of the
+	 * profiles below declare one — routing is chosen per project by `claudeup
+	 * models use`, not bundled with a plugin set — but the field is here so the
+	 * inheritance path in `resolveExtends` is real rather than notional.
+	 */
+	models?: ModelsConfig;
 }
 
 export const PREDEFINED_PROFILES: PredefinedProfile[] = [
@@ -15,7 +24,7 @@ export const PREDEFINED_PROFILES: PredefinedProfile[] = [
 		name: "Must Have",
 		description: "Essential plugins every Claude Code user should have",
 		icon: "★",
-		magusPlugins: ["statusline", "multimodel"],
+		magusPlugins: ["setup", "multimodel"],
 		anthropicPlugins: [
 			"claude-code-setup",
 			"claude-md-management",
@@ -41,7 +50,7 @@ export const PREDEFINED_PROFILES: PredefinedProfile[] = [
 			"Must Have + full dev toolkit: code analysis, browser, terminal, design, review",
 		icon: "▶",
 		magusPlugins: [
-			"statusline",
+			"setup",
 			"multimodel",
 			"code-analysis",
 			"dev",
@@ -84,7 +93,7 @@ export const PREDEFINED_PROFILES: PredefinedProfile[] = [
 			"dev",
 			"code-analysis",
 			"terminal",
-			"statusline",
+			"setup",
 			"designer",
 			"browser-use",
 			"multimodel",
@@ -125,7 +134,7 @@ export const PREDEFINED_PROFILES: PredefinedProfile[] = [
 			"dev",
 			"code-analysis",
 			"terminal",
-			"statusline",
+			"setup",
 			"multimodel",
 			"gtd",
 		],
@@ -160,7 +169,7 @@ export const PREDEFINED_PROFILES: PredefinedProfile[] = [
 			"dev",
 			"code-analysis",
 			"terminal",
-			"statusline",
+			"setup",
 			"multimodel",
 			"gtd",
 			"browser-use",
@@ -197,7 +206,7 @@ export const PREDEFINED_PROFILES: PredefinedProfile[] = [
 			"dev",
 			"code-analysis",
 			"terminal",
-			"statusline",
+			"setup",
 			"seo@magus-marketing",
 			"browser-use",
 			"image-generate@magus-marketing",
@@ -232,7 +241,7 @@ export const PREDEFINED_PROFILES: PredefinedProfile[] = [
 			"dev",
 			"code-analysis",
 			"terminal",
-			"statusline",
+			"setup",
 			"multimodel",
 			"gtd",
 		],

package/src/data/settings-catalog.ts

@@ -66,6 +66,7 @@ export const SETTINGS_CATALOG: SettingDefinition[] = [
 			{ label: "Low", value: "low" },
 			{ label: "Medium", value: "medium" },
 			{ label: "High", value: "high" },
+			{ label: "Extra high", value: "xhigh" },
 		],
 		storage: { type: "setting", key: "effortLevel" },
 	},
@@ -135,14 +136,20 @@ export const SETTINGS_CATALOG: SettingDefinition[] = [
 	{
 		id: "model",
 		name: "Default Model",
-		description: "Override the default model for Claude Code",
+		// Aliases, never pinned ids. A pinned id in a shipped list goes stale the
+		// day Anthropic moves the alias, and goes stale SILENTLY — the setting
+		// keeps naming a model that is a release behind, and nothing reports it.
+		// The alias always names whatever that tier currently is.
+		description:
+			"Override the default model for Claude Code. Aliases track the current model for each tier",
 		category: "models",
 		type: "select",
 		options: [
 			{ label: "Default", value: "" },
-			{ label: "Sonnet", value: "claude-sonnet-4-6" },
-			{ label: "Opus", value: "claude-opus-4-6" },
-			{ label: "Haiku", value: "claude-haiku-4-5-20251001" },
+			{ label: "Opus", value: "opus" },
+			{ label: "Sonnet", value: "sonnet" },
+			{ label: "Haiku", value: "haiku" },
+			{ label: "Fable", value: "fable" },
 		],
 		storage: { type: "setting", key: "model" },
 	},

package/src/main.tsx

@@ -1,29 +1,68 @@
 #!/usr/bin/env bun
 
-import { RGBA, createCliRenderer } from "@opentui/core";
-import { createRoot } from "@opentui/react";
 // Static import so `bun build --compile` embeds package.json into the binary;
 // a dynamic require("../package.json") is not resolvable inside the bunfs root.
 import pkg from "../package.json";
-import { route } from "./cli/router.js";
 import { loadProjectDotenv } from "./services/dotenv.js";
-import { App } from "./ui/App.js";
-import { setThemeMode } from "./ui/theme-mode.js";
-import { resolveTheme, snapshotThemeEnv } from "./ui/theme-resolve.js";
 
 export const VERSION = (pkg as { version: string }).version;
 
 // Note: OpenTUI renderer handles alternate screen buffer automatically
 // No need for manual ANSI escape codes
+//
+// NOTHING in this file may statically import @opentui/* or ./ui/*. `claudeup
+// hook …` runs on every matching Claude Code tool call, and a static import
+// would load the whole TUI module graph before the hook could answer. The TUI
+// (./tui.js), the router (./cli/router.js, which reaches @opentui through
+// cli/update.ts → ui/theme.ts) and the hook itself are all imported on demand,
+// after the branch that decides which one is needed.
+// Pinned by __tests__/hook-import-policy.test.ts.
+
+/**
+ * `hook` as the first non-theme token → the argv the hook command should see.
+ * Anything else → null.
+ *
+ * A leading `--theme light|dark` (or `--theme=…`) pair is skipped so this
+ * matches the router's own dispatch, which drops the theme tokens before
+ * looking at the command. Deliberately NOT `parseThemeFlag` from the router:
+ * importing that module is the cost this branch exists to avoid, and a hook
+ * has no use for a validated theme.
+ */
+function hookArgv(argv: string[]): string[] | null {
+	let i = 0;
+	while (i < argv.length) {
+		const token = argv[i] as string;
+		if (token === "--theme") {
+			i += 2;
+		} else if (token.startsWith("--theme=")) {
+			i += 1;
+		} else {
+			break;
+		}
+	}
+	return argv[i] === "hook" ? argv.slice(i + 1) : null;
+}
 
 async function main(): Promise<void> {
 	// FIRST, before anything can touch process.env: the theme is read from the
 	// environment claudeup was started with, never from a project's .env. The
 	// dotenv load below merges into process.env, so the only thing separating
 	// the two is that this line runs before it (pinned by theme-env.test.ts).
+	const { snapshotThemeEnv } = await import("./ui/theme-resolve.js");
 	const themeEnv = snapshotThemeEnv();
 	const args = process.argv.slice(2);
 
+	// Hooks answer here and go no further. This runs BEFORE loadProjectDotenv()
+	// on purpose: a hook must never open a project's .env, because that file is
+	// often a symlink to a 1Password FIFO and reading one BLOCKS until a human
+	// approves it — on every tool call. The hook needs no .env, so it never
+	// touches one.
+	const hookRest = hookArgv(args);
+	if (hookRest !== null) {
+		const { runHookCommand } = await import("./cli/hook.js");
+		process.exit(await runHookCommand(hookRest));
+	}
+
 	// Load the project's .env ourselves. Bun's standalone autoload is compiled OFF
 	// (scripts/build-binaries.ts) because it killed claudeup outright wherever
 	// .env was a symlink to a FIFO — the shape 1Password uses — exiting 1 with no
@@ -44,6 +83,7 @@ async function main(): Promise<void> {
 	// Dispatch non-interactive subcommands (claude, update, install, …) and
 	// top-level flags (--version/--help). A bare invocation falls through to
 	// the interactive TUI below.
+	const { route } = await import("./cli/router.js");
 	const outcome = await route(args, VERSION);
 	if (outcome.handled) {
 		process.exit(outcome.exitCode ?? 0);
@@ -54,85 +94,14 @@ async function main(): Promise<void> {
 	const isInteractive =
 		process.stdin.isTTY === true && process.stdout.isTTY === true;
 
-	// Create OpenTUI renderer (handles alternate screen buffer automatically).
-	//
-	// The background is the terminal's own, not a colour of ours: painting an
-	// absolute fill would box the UI into whatever theme we guessed. OpenTUI's
-	// built-in default for unstyled cells is truecolor white, which is why every
-	// element now names an adaptive colour explicitly — see src/ui/theme.ts.
-	// The mouse is ON, everywhere — it carries real features now: the wheel
-	// scrolls the pane under the cursor, and a drag selects text from ONE pane
-	// at a time (terminal-native selection is a screen-wide rectangle that
-	// grabs both columns), OSC 52-copied on release below.
-	//
-	// This deliberately includes tmux. Two earlier revisions got this wrong in
-	// opposite directions: one disabled the mouse everywhere on the theory that
-	// capture breaks tmux-level pane clicking, the next kept it off only inside
-	// tmux. Both dated from when claudeup had no mouse features, so disabling
-	// cost nothing. MEASURED on a heavily tmux'd machine: tmux forwards mouse
-	// to a pane application that asks for it (htop in the same session took
-	// clicks and wheel fine while claudeup sat inert), and tmux's own `mouse`
-	// option keeps governing pane management. Terminal-native selection stays
-	// reachable via Shift+drag in most terminals.
-	//
-	// enableMouseMovement (mode-1003 "report all motion") stays off — selection
-	// needs only button-held drag events, which button reporting delivers.
-	const renderer = await createCliRenderer({
-		backgroundColor: RGBA.defaultBackground(),
-		useMouse: true,
-		enableMouseMovement: false,
-	});
-
-	// Mouse selection → system clipboard, on release. OSC 52 survives SSH;
-	// terminals that block it simply ignore the sequence. Never fires where the
-	// mouse is off, so the tmux path pays nothing.
-	renderer.on("selection", (selection: { getSelectedText(): string }) => {
-		const text = selection?.getSelectedText() ?? "";
-		if (text.length > 0) renderer.copyToClipboardOSC52(text);
-	});
-
-	// Resolve light vs dark once: --theme, CLAUDEUP_THEME, TERM_THEME, the OSC
-	// probe, COLORFGBG, dark — see src/ui/theme-resolve.ts. Only the disabled-row
-	// tint and the chips need this (src/ui/theme-mode.ts explains why that one
-	// case cannot be solved the way the rest of the palette is).
-	//
-	// The renderer sends OSC 10/11 at creation regardless: @opentui/core 0.1.107
-	// has no option to suppress it. So the rule "TERM_THEME skips the probe" is
-	// satisfied by NOT AWAITING — when steps 1-3 answer, `probe` is never called,
-	// `waitForThemeMode(250)` never runs, first paint is not delayed, and
-	// `renderer.themeMode` is never read anywhere in claudeup. Any late reply the
-	// terminal sends is consumed by OpenTUI's own handleSequence and ignored here.
-	const { mode } = await resolveTheme({
-		flag: outcome.theme,
+	// Last possible moment: this is the import that pulls in @opentui and the
+	// whole ui/ tree. Everything above runs without them.
+	const { startTui } = await import("./tui.js");
+	await startTui({
+		theme: outcome.theme,
 		env: themeEnv,
 		isInteractive,
-		probe: () => renderer.waitForThemeMode(250).catch(() => null),
 	});
-	setThemeMode(mode);
-
-	const root = createRoot(renderer);
-
-	// Cleanup function to restore terminal
-	const cleanup = () => {
-		root.unmount();
-		renderer.destroy(); // CRITICAL: Never use process.exit() directly
-	};
-
-	// Handle cleanup on exit signals
-	const handleExit = () => {
-		cleanup();
-		// Exit after cleanup completes
-		process.exit(0);
-	};
-
-	process.on("SIGINT", handleExit);
-	process.on("SIGTERM", handleExit);
-
-	// Render the OpenTUI app with exit handler
-	root.render(<App onExit={handleExit} />);
-
-	// Wait indefinitely (app runs until user exits)
-	await new Promise(() => {});
 }
 
 main().catch((error) => {