claudeup 6.3.2 → 6.4.0

package/src/ui/adapters/modelsAdapter.ts

@@ -0,0 +1,170 @@
+import {
+	BUILT_IN_PRESETS,
+	DEFAULT_PRESET,
+	presetLabel,
+} from "../../data/models-presets.js";
+import {
+	GRADES,
+	type ModelsConfig,
+	type ModelsState,
+	type ModelsStatus,
+} from "../../services/models-core.js";
+
+// ─── Item types ───────────────────────────────────────────────────────────────
+
+/**
+ * The one header row: what is routed right now.
+ *
+ * Not selectable — the cursor skips it, the same way the Styles screen skips a
+ * category label. It carries only what the ROW draws; the drift lines and
+ * warnings behind the counts live on the `ModelsStatus` the detail renderer is
+ * handed, so they are not stored twice and cannot disagree.
+ */
+export interface ModelsStatusItem {
+	id: string;
+	kind: "status";
+	label: string;
+	state: ModelsState;
+	/** The preset the project's config names, or null when there is none. */
+	preset: string | null;
+	driftCount: number;
+	warningCount: number;
+}
+
+export interface ModelsPresetItem {
+	id: string;
+	kind: "preset";
+	label: string;
+	config: ModelsConfig;
+	/** The routing this project's `models.json` names. */
+	active: boolean;
+	/** What `claudeup models use` picks when nothing else is chosen. */
+	isDefault: boolean;
+	/** Not one of the built-ins — this project's own, hand-edited config. */
+	custom: boolean;
+}
+
+export type ModelsBrowserItem = ModelsStatusItem | ModelsPresetItem;
+
+// ─── Adapter ──────────────────────────────────────────────────────────────────
+
+export interface BuildModelsItemsArgs {
+	/** What `readModelsStatus` reported, or null before the first read lands. */
+	status: ModelsStatus | null;
+	/** The validated config, or null when there is none (or it failed validation). */
+	config: ModelsConfig | null;
+	query: string;
+	/**
+	 * Presets to offer. Defaults to the shipped set, which is a compile-time
+	 * constant — so building the list still costs no I/O whatsoever.
+	 */
+	presets?: ModelsConfig[];
+}
+
+/**
+ * Does `config` answer to the filter?
+ *
+ * Matched over the preset name AND the models it names, because "sonnet" is the
+ * thing a user actually looks for — the preset names encode which model leads,
+ * not which models appear.
+ */
+function matches(config: ModelsConfig, lowerQuery: string): boolean {
+	if (!lowerQuery) return true;
+	// Both names are searchable: the row SHOWS "Opus with Fable help", and a user who knows
+	// the command types "fable-advisor". Matching only one of them makes the other look like
+	// a missing preset.
+	const haystack = [
+		config.preset,
+		presetLabel(config.preset),
+		config.main.model,
+		...GRADES.map((grade) => config.grades[grade].model),
+	]
+		.join(" ")
+		.toLowerCase();
+	return haystack.includes(lowerQuery);
+}
+
+/**
+ * Build the flat list for the Models screen.
+ *
+ * One status header, then one row per preset in the order they ship. Nothing is
+ * grouped: there are four of them and a grade table each, so sections would cost
+ * rows and buy no navigation.
+ *
+ * The header is emitted only when at least one preset row survives the filter. A
+ * header with nothing under it reads as a result, and would leave the empty
+ * state — the one thing that says how to clear the filter — unreachable.
+ */
+export function buildModelsItems({
+	status,
+	config,
+	query,
+	presets = BUILT_IN_PRESETS,
+}: BuildModelsItemsArgs): ModelsBrowserItem[] {
+	if (!status) return [];
+
+	const lowerQuery = query.trim().toLowerCase();
+	const activeName = config?.preset ?? null;
+	const builtInNames = new Set(presets.map((preset) => preset.preset));
+
+	const rows: ModelsPresetItem[] = presets
+		.filter((preset) => matches(preset, lowerQuery))
+		.map((preset) => ({
+			id: `preset:${preset.preset}`,
+			kind: "preset" as const,
+			label: presetLabel(preset.preset),
+			config: preset,
+			active: preset.preset === activeName,
+			isDefault: preset.preset === DEFAULT_PRESET,
+			custom: false,
+		}));
+
+	// A project that hand-edited its models.json names a preset no built-in
+	// carries. It is the routing actually in force, so it gets a row of its own —
+	// otherwise the list shows four presets with none of them marked, which reads
+	// as "routing is off" when it is emphatically on.
+	if (
+		config &&
+		activeName &&
+		!builtInNames.has(activeName) &&
+		matches(config, lowerQuery)
+	) {
+		rows.push({
+			id: `preset:${activeName}`,
+			kind: "preset",
+			label: presetLabel(activeName),
+			config,
+			active: true,
+			isDefault: false,
+			custom: true,
+		});
+	}
+
+	if (rows.length === 0) return [];
+
+	const header: ModelsStatusItem = {
+		id: "status",
+		kind: "status",
+		label: status.preset
+			? `Model tiers: ${status.state} · ${presetLabel(status.preset)}`
+			: `Model tiers: ${status.state}`,
+		state: status.state,
+		preset: status.preset,
+		driftCount: status.drift.length,
+		warningCount: status.warnings.length,
+	};
+
+	return [header, ...rows];
+}
+
+/**
+ * Index of the first row the user can actually land on, or 0 if none.
+ *
+ * The status row is a header, not a choice: every key this screen binds acts on
+ * a preset, so parking the cursor there would make `a` and Enter do nothing on
+ * the row the screen opens with.
+ */
+export function firstSelectableIndex(items: ModelsBrowserItem[]): number {
+	const index = items.findIndex((item) => item.kind !== "status");
+	return index >= 0 ? index : 0;
+}

package/src/ui/components/TabBar.tsx

@@ -19,6 +19,11 @@ export const TABS: Tab[] = [
 	{ key: "7", label: "Git State", screen: "gitignore" },
 	{ key: "8", label: "Alias", screen: "alias" },
 	{ key: "9", label: "Styles", screen: "styles" },
+	// Last, and keyed "0" because the digits ran out. The number row reads
+	// 1…9 then 0, so a tenth tab keyed 0 sits under the finger that follows 9 —
+	// which is the only reason the order here and the order on the keyboard
+	// agree.
+	{ key: "0", label: "Models", screen: "models" },
 ];
 
 /** Columns one tab occupies: the text plus its one-space padding each side. */
@@ -35,11 +40,11 @@ export function barWidth(texts: string[]): number {
 /**
  * Choose what each tab shows for the space available.
  *
- * The full bar is ~99 columns at nine tabs, so on a 94-column pane it used to
- * overflow and OpenTUI clipped each cell — producing a row of truncated stubs
- * ("1:", "4:", "7:Git ") that named nothing. Dropping the inactive labels keeps
+ * The full bar is ~110 columns at ten tabs, so on a standard 100-column window
+ * it overflows and OpenTUI clips each cell — producing a row of truncated stubs
+ * ("1:", "4:", "7:Git ") that names nothing. Dropping the inactive labels keeps
  * the bar honest: the number is what you press, and the one tab whose name
- * matters is the one you are on.
+ * matters is the one you are on. Compacted, ten tabs need ~46 columns.
  */
 export function layoutTabs(
 	tabs: Tab[],

package/src/ui/components/layout/FooterHints.tsx

@@ -3,11 +3,28 @@ import { theme } from "../../theme.js";
 
 /** One footer hint: a key (or key group) and the action it performs. */
 export interface FooterHint {
-	/** Key(s) for this action, e.g. ["↑", "↓"] or ["U"]. Joined for display. */
+	/** Key(s) for this action, e.g. ["↑", "↓"] or ["U"]. Joined by `joinKeys`. */
 	keys: string[];
 	label: string;
 }
 
+/**
+ * Render a key group as one chip's text.
+ *
+ * Single-character keys butt together, because `↑↓` is how an arrow pair is written
+ * everywhere and a separator there would be noise. Anything longer needs a gap, or the
+ * names run into each other and read as one key that does not exist — MEASURED on screen:
+ * `["Enter", "a"]` rendered as `Entera`, and the layout's own scroll hint
+ * `["^U/^D", "PgUp/Dn"]` rendered as `^U/^DPgUp/Dn` on every screen in the app.
+ *
+ * A space rather than a slash, because several key names already contain one.
+ */
+export function joinKeys(keys: string[]): string {
+	return keys.every((k) => [...k].length === 1)
+		? keys.join("")
+		: keys.join(" ");
+}
+
 // The shared chip palette, not a local one. This file used to define its own
 // (`theme.colors.dim` block + terminal-foreground ink), which is why the footer
 // stayed a low-contrast grey-on-grey strip after the palette was made vivid —
@@ -31,7 +48,7 @@ export function FooterHints({
 	const nodes: React.ReactNode[] = [];
 	hints.forEach((hint, i) => {
 		// A hint is identified by its key chord plus label, not its position.
-		const id = `${hint.keys.join("")}:${hint.label}`;
+		const id = `${joinKeys(hint.keys)}:${hint.label}`;
 		if (i > 0) {
 			nodes.push(
 				<span key={`gap-${id}`} fg={LABEL_FG}>
@@ -41,7 +58,7 @@ export function FooterHints({
 		}
 		nodes.push(
 			<span key={`k-${id}`} bg={KEY_BG} fg={KEY_FG}>
-				{` ${hint.keys.join("")} `}
+				{` ${joinKeys(hint.keys)} `}
 			</span>,
 		);
 		nodes.push(

package/src/ui/components/layout/ScreenLayout.tsx

@@ -9,6 +9,70 @@ import { theme } from "../../theme.js";
 import { TabBar } from "../TabBar.js";
 import { type FooterHint, FooterHints } from "./FooterHints.js";
 
+/**
+ * Panel content: a node, or a function handed the panel's usable columns.
+ *
+ * The function form exists because the geometry below — the app frame's side
+ * padding, the 49/50 split, the panel padding and the scrollbar column — is
+ * ScreenLayout's, and a screen that re-derives it from `terminalWidth` is
+ * guessing at constants it cannot see. Both screens that wrap body text did
+ * exactly that, with the same hand-copied formula, and both were wrong.
+ *
+ * `React.ReactNode` does not include functions, so the union is unambiguous.
+ */
+export type PanelContent =
+	| React.ReactNode
+	| ((width: number) => React.ReactNode);
+
+/**
+ * The app frame (App.tsx) pads the screen one column each side before
+ * ScreenLayout ever renders, so every percentage below resolves against
+ * `terminalWidth - 2`.
+ */
+const APP_SIDE_PADDING = 2;
+const LIST_FRACTION = 0.49;
+const DETAIL_FRACTION = 0.5;
+/** The list panel's own `paddingRight`. */
+const LIST_CHROME = 1;
+/** The detail panel's `paddingLeft`, plus the scrollbox's scrollbar column. */
+const DETAIL_CHROME = 2;
+
+/** Columns a panel's content can actually use, at this terminal width. */
+function panelWidth(
+	terminalWidth: number,
+	fraction: number,
+	chrome: number,
+): number {
+	const inner = Math.max(1, terminalWidth - APP_SIDE_PADDING);
+	return Math.max(8, Math.floor(inner * fraction) - chrome);
+}
+
+/**
+ * Usable columns in the list panel.
+ *
+ * MEASURED against real renders at 70…200 columns, not derived from the JSX:
+ * Yoga rounds a fractional percentage to whole cells, so the arithmetic only
+ * matches the pixels if you check. This is exact at 8 of the 12 widths sampled
+ * and one column short at the other four, which is the safe direction — a
+ * budget one column under folds nothing, a budget one column over paints into
+ * the separator.
+ */
+export function listPanelWidth(terminalWidth: number): number {
+	return panelWidth(terminalWidth, LIST_FRACTION, LIST_CHROME);
+}
+
+/**
+ * Usable columns in the detail panel, scrollbar excluded.
+ *
+ * Exact at 11 of the 12 widths sampled, one column short at the twelfth. The
+ * formula each screen used to carry instead was `floor(width * 0.5) - 4`: it
+ * forgot the app frame's padding, counted the scrollbar twice, and then floored
+ * at 24 — so below about 56 columns it asked for MORE room than the panel has.
+ */
+export function detailPanelWidth(terminalWidth: number): number {
+	return panelWidth(terminalWidth, DETAIL_FRACTION, DETAIL_CHROME);
+}
+
 interface ScreenLayoutProps {
 	/** Screen title (e.g., "claudeup Plugins") */
 	title: string;
@@ -40,10 +104,10 @@ interface ScreenLayoutProps {
 	 *  (the standard look). A string or ReactNode is still accepted for
 	 *  free-form footers. */
 	footerHints: FooterHint[] | string | React.ReactNode;
-	/** Left panel content */
-	listPanel: React.ReactNode;
-	/** Right panel content (detail view) */
-	detailPanel: React.ReactNode;
+	/** Left panel content, or a function given the list panel's usable columns. */
+	listPanel: PanelContent;
+	/** Right panel content, or a function given the detail panel's usable columns. */
+	detailPanel: PanelContent;
 	/**
 	 * Identity of the detail content, e.g. the selected row's id. When it
 	 * changes, the detail pane scrolls back to the top — a reading position
@@ -77,6 +141,15 @@ export function ScreenLayout({
 	const panelHeight = Math.max(5, dimensions.contentHeight - fixedHeight);
 	const lineWidth = Math.max(10, dimensions.terminalWidth - 4);
 
+	const listContent =
+		typeof listPanel === "function"
+			? listPanel(listPanelWidth(dimensions.terminalWidth))
+			: listPanel;
+	const detailContent =
+		typeof detailPanel === "function"
+			? detailPanel(detailPanelWidth(dimensions.terminalWidth))
+			: detailPanel;
+
 	const detailScrollRef = useRef<ScrollBoxRenderable | null>(null);
 
 	// The detail pane has no cursor, so it needs its own scroll keys: arrows
@@ -177,14 +250,21 @@ export function ScreenLayout({
 
 			{/* Main content area */}
 			<box flexDirection="row" height={panelHeight}>
-				{/* List panel */}
+				{/* List panel. `overflow="hidden"` is the safety net, not the plan:
+				    the box has a fixed height, so content taller than it does NOT
+				    scroll and does NOT clip on its own — Yoga shrinks the children
+				    and they composite on top of each other. MEASURED at 80×24:
+				    "fable-advisor" and "fable-lead" rendered as "fable-leadical".
+				    A screen that can overflow should budget its own rows; this
+				    stops the failure being unreadable when one does not. */}
 				<box
 					flexDirection="column"
 					width="49%"
 					height={panelHeight}
 					paddingRight={1}
+					overflow="hidden"
 				>
-					{listPanel}
+					{listContent}
 				</box>
 
 				{/* Vertical separator */}
@@ -208,7 +288,7 @@ export function ScreenLayout({
 							},
 						}}
 					>
-						<box flexDirection="column">{detailPanel}</box>
+						<box flexDirection="column">{detailContent}</box>
 					</scrollbox>
 				</box>
 			</box>

package/src/ui/components/primitives/MetaText.tsx

@@ -4,11 +4,37 @@ import { theme } from "../../theme.js";
 interface MetaTextProps {
 	text: string;
 	tone?: "muted" | "warning" | "success" | "danger";
+	/**
+	 * True when this sits inside a SELECTED row. Not cosmetic.
+	 *
+	 * Every `theme.meta` tone is chosen against the terminal's own background,
+	 * and none of them survives the selection fill: measured on a screenshot,
+	 * `muted` is 1.11:1 on it, `warning` 1.07:1, `danger` 1.11:1. So a selected
+	 * row's `(default)`, `(new)`, `(needed)` and version strings were drawn in a
+	 * colour indistinguishable from the purple behind them.
+	 *
+	 * On a selected row the tone's HUE is surrendered — the selection owns the
+	 * colour channel there — and only the emphasis survives: `fg` for a tone
+	 * that was saying something, `dim` for one that was only muttering. The
+	 * label is words, so its meaning does not depend on the hue.
+	 */
+	selected?: boolean;
 }
 
 /**
  * Subdued text for versions, stars, status indicators.
  */
-export function MetaText({ text, tone = "muted" }: MetaTextProps) {
+export function MetaText({
+	text,
+	tone = "muted",
+	selected = false,
+}: MetaTextProps) {
+	if (selected) {
+		return (
+			<span fg={tone === "muted" ? theme.selection.dim : theme.selection.fg}>
+				{text}
+			</span>
+		);
+	}
 	return <span fg={theme.meta[tone]}>{text}</span>;
 }