claudeup 6.7.1 → 6.8.0

package/src/ui/screens/ModelsScreen.tsx

@@ -1,4 +1,6 @@
 import React, { useCallback, useEffect, useMemo } from "react";
+import { areMatesAvailable } from "../../services/mate-availability.js";
+import { loadMateCatalog } from "../../services/mate-catalog.js";
 import {
 	applyModelPreset,
 	clearModels,
@@ -72,6 +74,65 @@ export function ModelsScreen() {
 
 	const snapshot = asyncValue(modelsState.data) ?? null;
 
+	/**
+	 * Whether the mate slots have anything to serve them.
+	 *
+	 * Its OWN effect, deliberately outside the `fetchData` pair above. That pair is two file
+	 * reads and lands in milliseconds; this one goes through the plugin registry and the
+	 * marketplace resolution behind it, which does network work with its own timeouts.
+	 * Awaiting it in the same `Promise.all` would hold the whole screen — the presets, the
+	 * tier table, the status — on a question that decides three rows.
+	 *
+	 * App state rather than `useState`, and NOT only to satisfy the rule: `Router` swaps the
+	 * component type on a tab change, so a local flag dies on `0 → 1 → 0` and this is the one
+	 * piece of this screen's state that is expensive to fetch again. Held here, the lookup
+	 * happens once per session instead of once per visit.
+	 *
+	 * It starts false and the rows appear when the answer lands. False is also what a failure
+	 * yields (`areMatesAvailable` fails closed), so both render identically: the screen
+	 * exactly as it was before mates existed.
+	 */
+	useEffect(() => {
+		let live = true;
+		areMatesAvailable(state.projectPath).then((available) => {
+			// The screen can be left while this is in flight. Dispatching into a reducer that
+			// outlives the component is harmless, but re-dispatching a stale answer after the
+			// project path changed is not.
+			if (live) dispatch({ type: "MODELS_MATES_AVAILABLE", available });
+		});
+		return () => {
+			live = false;
+		};
+	}, [state.projectPath, dispatch]);
+
+	/**
+	 * claudish's live model catalogue, for the staleness advisory.
+	 *
+	 * A third effect rather than a branch of the second, even though both are about mates:
+	 * this one spawns a process and the other reads a registry, and chaining them would make
+	 * the advisory wait on a plugin lookup it does not depend on. Neither blocks the screen.
+	 *
+	 * NOT gated on `matesAvailable`. The catalogue answers "is this bound id real", which is
+	 * worth knowing about a committed config whether or not this particular machine has the
+	 * plugin installed — and gating it would make the note appear only on machines that need
+	 * it least. The lookup is cached per session, so it costs one spawn either way.
+	 *
+	 * No project path in the deps: a model catalogue is a property of the world, not of the
+	 * project. `loadMateCatalog` caches it for the session, so this re-runs into a resolved
+	 * promise on every remount.
+	 */
+	useEffect(() => {
+		let live = true;
+		// Failure is already [] — `loadMateCatalog` never rejects — so there is no `.catch`
+		// here to swallow. If one becomes necessary the module's contract has been broken.
+		loadMateCatalog().then((catalog) => {
+			if (live) dispatch({ type: "MODELS_CATALOG_LOADED", catalog });
+		});
+		return () => {
+			live = false;
+		};
+	}, [dispatch]);
+
 	// ── Status line ───────────────────────────────────────────────────────────
 
 	/**
@@ -333,6 +394,9 @@ export function ModelsScreen() {
 		</text>
 	) : undefined;
 
+	// The file's `preset` string is deliberately not shown beside the state: it records what
+	// was last APPLIED, so a config edited afterwards would wear a built-in's name here while
+	// the list correctly calls it `Custom`.
 	const routingState = snapshot?.status.state ?? null;
 	const statusContent = (
 		<text fg={theme.colors.text}>
@@ -341,18 +405,13 @@ export function ModelsScreen() {
 				fg={
 					routingState === "on"
 						? theme.colors.success
-						: routingState === "stale"
-							? theme.colors.warning
-							: routingState === "off" || routingState === null
-								? theme.colors.muted
-								: theme.colors.danger
+						: routingState === "off" || routingState === null
+							? theme.colors.muted
+							: theme.colors.danger
 				}
 			>
 				{routingState ?? "reading…"}
 			</span>
-			{snapshot?.status.preset ? (
-				<span fg={theme.colors.info}>{` │ ${snapshot.status.preset}`}</span>
-			) : null}
 			{modelsState.isApplying ? (
 				<span fg={theme.colors.warning}> │ writing…</span>
 			) : null}
@@ -450,7 +509,6 @@ export function ModelsScreen() {
 					    while you are choosing. */}
 						{allItems.length > 0 &&
 							renderModelsSummary({
-								items: allItems,
 								selected: selectedItem,
 								status: snapshot?.status ?? null,
 								configPath: snapshot?.path ?? null,
@@ -468,7 +526,13 @@ export function ModelsScreen() {
 				);
 			}}
 			detailPanel={(detailWidth) =>
-				renderModelDetail(selectedItem, snapshot?.status ?? null, detailWidth)
+				renderModelDetail(
+					selectedItem,
+					snapshot?.status ?? null,
+					detailWidth,
+					modelsState.matesAvailable,
+					modelsState.mateCatalog,
+				)
 			}
 			detailKey={selectedItem?.id ?? ""}
 		/>

package/src/ui/state/reducer.ts

@@ -84,6 +84,14 @@ export const initialState: AppState = {
 		data: { status: "idle" },
 		status: null,
 		isApplying: false,
+		// False until the plugin lookup answers, and false again if it fails. Both cases
+		// render the screen as it was before mates existed, which is the honest drawing of
+		// "we do not know yet" — see `areMatesAvailable`.
+		matesAvailable: false,
+		// Empty until the catalogue lands, and empty for good if it cannot be read. Both
+		// render identically — no advisory at all — which is exactly the contract
+		// `unknownBindings` holds to: say nothing about a catalogue you could not reach.
+		mateCatalog: [],
 	},
 };
 
@@ -748,6 +756,18 @@ export function appReducer(state: AppState, action: AppAction): AppState {
 		case "MODELS_APPLY_END":
 			return { ...state, models: { ...state.models, isApplying: false } };
 
+		case "MODELS_MATES_AVAILABLE":
+			return {
+				...state,
+				models: { ...state.models, matesAvailable: action.available },
+			};
+
+		case "MODELS_CATALOG_LOADED":
+			return {
+				...state,
+				models: { ...state.models, mateCatalog: action.catalog },
+			};
+
 		// =========================================================================
 		// Modals
 		// =========================================================================

package/src/ui/state/types.ts

@@ -1,3 +1,4 @@
+import type { CatalogModel } from "../../services/mate-catalog.js";
 import type { ModelsConfig, ModelsStatus } from "../../services/models-core.js";
 import type { PluginInfo } from "../../services/plugin-manager.js";
 import type {
@@ -286,6 +287,33 @@ export interface ModelsScreenState {
 	 * two of those running at once would interleave writes to the same files.
 	 */
 	isApplying: boolean;
+	/**
+	 * Is `multimodel@magus` installed — i.e. is there anything to serve a mate?
+	 *
+	 * App state for the reason the two fields above are, plus one of its own. The screen
+	 * unmounts on a tab switch, so a local flag would be destroyed by `0 → 1 → 0`; and unlike
+	 * the two file reads the screen does on mount, THIS answer costs a marketplace resolution
+	 * with network timeouts behind it. Re-asking it on every visit to the tab would pay that
+	 * cost again for an answer that cannot change while the TUI is open.
+	 *
+	 * Starts false, which is also what a failed lookup yields (`areMatesAvailable` fails
+	 * closed): both render as the screen exactly as it was before mates existed, rather than
+	 * as three rows put there by an error.
+	 */
+	matesAvailable: boolean;
+	/**
+	 * claudish's live model catalogue, or [] when it could not be read.
+	 *
+	 * App state for the reasons above, plus the one that matters most here: reading it spawns
+	 * a process. Held per session, it is spawned once; held in the component it would be
+	 * spawned on every visit to the tab.
+	 *
+	 * [] is deliberately NOT distinguished from "not yet loaded". Every consumer treats an
+	 * empty catalogue as "unknown" and says nothing, so the loading frame, a machine without
+	 * claudish, and a lookup that timed out all draw the same screen — bound ids as written,
+	 * with no annotation. Advisory only: nothing here ever changes what is routed.
+	 */
+	mateCatalog: CatalogModel[];
 }
 
 // ============================================================================
@@ -467,6 +495,9 @@ export type AppAction =
 	| { type: "MODELS_STATUS_CLEAR" }
 	| { type: "MODELS_APPLY_START" }
 	| { type: "MODELS_APPLY_END" }
+	// Dispatched once, when the plugin lookup behind the mate slots lands.
+	| { type: "MODELS_MATES_AVAILABLE"; available: boolean }
+	| { type: "MODELS_CATALOG_LOADED"; catalog: CatalogModel[] }
 
 	// Data refresh - triggers screens to refetch
 	| { type: "DATA_REFRESH_COMPLETE" };

package/src/ui/theme-mode.ts

@@ -102,11 +102,32 @@ export const COMPONENT_BADGE = {
 export type ComponentBadgeKind = keyof typeof COMPONENT_BADGE;
 
 /**
- * Badge and chart colours for the four Claude models, plus `inherit`.
+ * Badge and chart colours for the four Claude models, the three external-model slots, and
+ * `inherit`.
  *
- * Three strengths, because a badge and a bar cannot share an ink: twenty characters of a
+ * Four strengths, because a badge and a bar cannot share an ink: twenty characters of a
  * colour weigh far more than six, so what reads as a label reads as a slab when it is a
- * chart. `bg`/`fg` are the chip; `bar` is the distribution bar's fill.
+ * chart. `bg`/`fg` are the chip; `bar` is the distribution bar's fill; `label` is the ink a
+ * word takes when it is written ON that fill.
+ *
+ * ## Why `label` exists, and why `fg` could not do its job
+ *
+ * A segment of the workflow chart is one block of one colour with its model's name written
+ * on it. The name used to be drawn as the CHIP — `fg` on `bg`, inset into the bar — which
+ * put a second, visibly different rectangle inside a block that is supposed to read as one
+ * thing. Reported exactly that way: "do not add additional background colour to model
+ * segments".
+ *
+ * Deleting the chip and keeping `fg` was not an option: MEASURED, `fg` on the same model's
+ * `bar` runs 1.74:1 (sonnet dark) to 2.99:1 (haiku dark), which is a smudge rather than a
+ * word. `fg` is built to sit on `bg`, and `bg` is not what a bar is painted with.
+ *
+ * So each model owns a fourth ink, chosen against its OWN bar and nothing else. Every one is
+ * the model's own hue taken deep — the same family, not a fifth palette — and every one
+ * clears 4.5:1 with margin; the measured value is on each line below. `inherit` is the one
+ * that runs the other way: its bar is a dark recessive grey rather than a bright mid-tone,
+ * so its label is near-white on the dark page. That is forced by the fill, not a stylistic
+ * exception.
  *
  * ## The two pages are built differently, deliberately
  *
@@ -129,29 +150,120 @@ export type ComponentBadgeKind = keyof typeof COMPONENT_BADGE;
  *
  * Hues stay far apart for the same reason the scope squares' do: one or two characters of
  * colour carry no readable hue SHIFT, only a readable hue DIFFERENCE.
+ *
+ * ## The mates are ONE hue family, and that is the exception that proves the rule
+ *
+ * `mate1`, `mate2` and `kangaroo` are three different external models, so they need three
+ * distinguishable inks — but they all mean the same thing (someone else's model, reached
+ * through claudish), and four unrelated hues would say the opposite. They therefore share a
+ * warm outback band nothing else on this screen occupies: measured hue angles 39° / 23° / 6°
+ * on the dark page and 41° / 25° / 10° on the light one — ochre, terracotta, red earth. The
+ * four Claude models sit at teal 190°, green 150°, purple 265° and grey, so a mate cannot be
+ * mistaken for one of them at a glance, and a mate cannot be mistaken for another mate
+ * either, because ~17° of hue at full saturation is a readable difference where ~17° of
+ * LUMINANCE would not be.
+ *
+ * Measured contrast, ink on its own fill (the number the chip has to clear):
+ *
+ *   mate1     light 5.60:1   dark 4.82:1
+ *   mate2     light 5.82:1   dark 4.96:1
+ *   kangaroo  light 5.98:1   dark 5.68:1
+ *
+ * And the dark fills against every plausible dark ground — pure black,
+ * `CONTRAST_REFERENCE_KEYS.dark`, One Dark's `#282C34` — plus the cream page a mis-detected
+ * theme would put them on:
+ *
+ *   mate1     4.09 / 3.32 / 2.73   cream 4.81
+ *   mate2     3.83 / 3.10 / 2.55   cream 5.14
+ *   kangaroo  3.31 / 2.68 / 2.21   cream 5.94
+ *
+ * which is the same band the four Claude fills occupy, so a mate chip carries the same weight
+ * as the models beside it rather than reading as a second-class one.
+ *
+ * There is a FOURTH warm entry, `mates`, and it is not a slot: it is the family's own ink,
+ * worn by the one collapsed segment a workflow bar draws for all external work at once. Its
+ * own note below says why a slot's ink could not do that job.
  */
 export const MODEL_BADGE = {
 	opus: {
-		light: { bg: "#D3E7EC", fg: "#0E5F73", bar: "#92CEDC" },
-		dark: { bg: "#0E7C94", fg: "#F0FDFF", bar: "#48C8E0" },
+		/** label 4.88:1 on its bar */
+		light: { bg: "#D3E7EC", fg: "#0E5F73", bar: "#92CEDC", label: "#125463" },
+		/** label 4.93:1 on its bar */
+		dark: { bg: "#0E7C94", fg: "#F0FDFF", bar: "#48C8E0", label: "#044B58" },
 	},
 	sonnet: {
-		light: { bg: "#D6EEDD", fg: "#166534", bar: "#93D9B2" },
-		dark: { bg: "#12804F", fg: "#EFFFF6", bar: "#4FD98F" },
+		/** label 4.84:1 on its bar */
+		light: { bg: "#D6EEDD", fg: "#166534", bar: "#93D9B2", label: "#145D34" },
+		/** label 4.84:1 on its bar */
+		dark: { bg: "#12804F", fg: "#EFFFF6", bar: "#4FD98F", label: "#07572C" },
 	},
 	haiku: {
-		light: { bg: "#E6E6E0", fg: "#4B5563", bar: "#C9CCD2" },
-		dark: { bg: "#697180", fg: "#F8FAFC", bar: "#8A92A2" },
+		/** label 4.81:1 on its bar */
+		light: { bg: "#E6E6E0", fg: "#4B5563", bar: "#C9CCD2", label: "#4B5362" },
+		/** label 4.91:1 on its bar — the dark grey bar is the dimmest of the four, so
+		 *  its label is the closest to black of them. */
+		dark: { bg: "#697180", fg: "#F8FAFC", bar: "#8A92A2", label: "#21252E" },
 	},
 	fable: {
-		light: { bg: "#E9DCF5", fg: "#6B21A8", bar: "#C3A6EC" },
-		dark: { bg: "#7B4CD6", fg: "#F6F0FF", bar: "#A87BE8" },
+		/** label 4.86:1 on its bar */
+		light: { bg: "#E9DCF5", fg: "#6B21A8", bar: "#C3A6EC", label: "#520FB0" },
+		/** label 4.81:1 on its bar */
+		dark: { bg: "#7B4CD6", fg: "#F6F0FF", bar: "#A87BE8", label: "#310570" },
+	},
+	/** Ochre. The first external slot, and the lightest step of the warm family.
+	 *  label 4.87:1 light / 4.81:1 dark, each on its own bar. */
+	mate1: {
+		light: { bg: "#F6E6C4", fg: "#7A5210", bar: "#E2C27A", label: "#654909" },
+		dark: { bg: "#926511", fg: "#FFF7E8", bar: "#D8A445", label: "#533807" },
+	},
+	/** Terracotta — the middle step, a clear ~17° of hue from either neighbour.
+	 *  label 4.80:1 light / 4.83:1 dark, each on its own bar. */
+	mate2: {
+		light: { bg: "#F7DDCB", fg: "#8A3E12", bar: "#EAB08A", label: "#793406" },
+		dark: { bg: "#A8501B", fg: "#FFF1E8", bar: "#E08A52", label: "#552404" },
+	},
+	/** Red earth. The third slot wears the reddest step, and it is still nowhere near
+	 *  `theme.colors.danger` — this is a desaturated earth tone, not a warning.
+	 *  label 4.86:1 light / 4.82:1 dark, each on its own bar. */
+	kangaroo: {
+		light: { bg: "#F6D6D0", fg: "#8E2F26", bar: "#E5A096", label: "#7B1C0E" },
+		dark: { bg: "#A83A2E", fg: "#FFEFEC", bar: "#E07A6C", label: "#571107" },
+	},
+	/**
+	 * THE FAMILY, not a fourth slot — the ink of the collapsed `mates` bar segment.
+	 *
+	 * A workflow bar draws every mate-routed agent as ONE run, because the question a bar
+	 * answers is "how much of this workflow leaves Claude Code" and that is one number. That
+	 * run cannot wear a slot's ink: painting a two-slot segment in `mate1`'s ochre says the
+	 * work went to `mate1`, and painting it in whichever slot contributes most makes the same
+	 * segment change colour when a count changes — the identical label in two hues down one
+	 * chart. So the family gets an ink of its own: honey amber, hue 35° light / 31° dark.
+	 *
+	 * It does NOT try to be a fourth distinguishable step, and it could not be. The warm band
+	 * is 0–50° and already holds three slots at ~17° spacing, so the widest gap left is about
+	 * 11° — under the separation the slots themselves needed. It does not have to be: the
+	 * family tone and the slot tones never appear in ONE graphic. The chart and the colour key
+	 * under it use only this; the tier table and the agent table use only the slots.
+	 *
+	 * MEASURED, same battery as the slots above:
+	 *   label on its own bar   light 4.97:1   dark 4.78:1
+	 *   fg on its own bg       light 5.87:1   dark 4.83:1
+	 *   dark bg vs grounds     4.03 (black) / 3.27 (#1C1C1E) / 2.69 (#282C34)   cream 4.88
+	 */
+	mates: {
+		light: { bg: "#F6E3C9", fg: "#80480F", bar: "#E5B77F", label: "#6B3D07" },
+		dark: { bg: "#9E5D16", fg: "#FFF5E8", bar: "#DB9A4C", label: "#553106" },
 	},
 	/** Not a model — the absence of a routing decision. Grey on both pages, so it never
-	 *  reads as a fifth choice sitting beside four real ones. */
+	 *  reads as another choice sitting beside the real ones. A mate is NOT this: a mate is
+	 *  a decision to route elsewhere, which is why it gets a colour and this does not.
+	 *
+	 *  Its label is a NEUTRAL grey at 4.82:1 light / 4.83:1 dark, and on the dark page it
+	 *  is the only label that is pale rather than deep — this is the one bar that is itself
+	 *  dark, so nothing darker could be read on it. */
 	inherit: {
-		light: { bg: "#EFEFE6", fg: "#8A8A80", bar: "#DEDED2" },
-		dark: { bg: "#4A4A54", fg: "#D0D2D8", bar: "#4E4E58" },
+		light: { bg: "#EFEFE6", fg: "#8A8A80", bar: "#DEDED2", label: "#5E5E57" },
+		dark: { bg: "#4A4A54", fg: "#D0D2D8", bar: "#4E4E58", label: "#C6C6CA" },
 	},
 } as const;
 
@@ -161,6 +273,8 @@ export interface ModelInk {
 	bg: string;
 	fg: string;
 	bar: string;
+	/** Ink for a word written ON `bar`. Never `fg` — see the note above `MODEL_BADGE`. */
+	label: string;
 }
 
 /**