magus-cli 7.1.0 → 7.3.0

package/src/services/update-plan.ts

@@ -34,6 +34,7 @@ import {
 	type PluginInfo,
 	compareVersions,
 	isBehind,
+	isRepairablyBehind,
 } from "./plugin-manager.js";
 import {
 	type ToolFacts,
@@ -54,6 +55,23 @@ export type PluginUpdateAction =
 	| "repair"
 	/** Already on the right version. */
 	| "current"
+	/**
+	 * BROKEN: the right version is installed, but Claude Code's loader will
+	 * resolve an OLDER one — so the session runs stale code while every version
+	 * magus records looks correct.
+	 *
+	 * A REINSTALL DOES NOT FIX IT (measured). `claude plugin install` writes a
+	 * row for this project, and the row that wins belongs to another one — often
+	 * a worktree that no longer exists, whose registry entry nothing prunes.
+	 *
+	 * It IS applied, by `repairStaleLoad` (services/claude-settings.ts), which
+	 * moves those rows forward onto the installed version rather than reinstalling
+	 * anything. `target` is therefore the version installed here — the one whose
+	 * cache directory exists — and not what the catalog offers. `scopes` stays
+	 * empty because this is not a per-scope install: one registry rewrite covers
+	 * every row, whichever scope or project each belongs to.
+	 */
+	| "stale-load"
 	/** The catalog check failed; we cannot claim either way. */
 	| "unknown";
 
@@ -78,6 +96,8 @@ export type PluginReason =
 	| "content-stale"
 	/** update: a scope is provably behind. */
 	| "behind"
+	/** stale-load: the loader resolves an older version than the one installed. */
+	| "older-version-loads"
 	/** current|update: an exact pin differs from what the marketplace offers. */
 	| "pin-undeliverable"
 	/** current: every installed scope is at (or ahead of) the target. */
@@ -89,6 +109,16 @@ export interface PluginUpdateItem {
 	pinned: string;
 	/** Highest version installed in any scope, or null when absent. */
 	installed: string | null;
+	/**
+	 * The version Claude Code's loader will ACTUALLY load in this project, or
+	 * null when it will load nothing (and when the registry was unreadable).
+	 *
+	 * A separate column from `installed` because they answer different questions
+	 * and routinely disagree — see services/plugin-resolution.ts. `installed` is
+	 * what the settings file and this project's registry rows record; `loaded` is
+	 * what runs.
+	 */
+	loaded: string | null;
 	/** Version the marketplace catalog offers, or null when unknown. */
 	available: string | null;
 	/** Version this item would move to. Null for `current`/`unknown`. */
@@ -142,6 +172,40 @@ function highestInstalled(info: PluginInfo | undefined): string | null {
 	);
 }
 
+/**
+ * The highest installed version THE PIN PERMITS — the ceiling a stale-load
+ * repair may aim at. Null when no installed version qualifies.
+ *
+ * Under "latest" that is simply {@link highestInstalled}: nothing caps it, and
+ * the newest version on this machine is the one to converge on.
+ *
+ * Under an EXACT pin it is the highest installed version at or below the pin.
+ * `installed` reaches across every scope and `scopesNeeding` never downgrades, so
+ * a scope sitting above an exact pin is a normal, permanent state — not something
+ * to plan toward. Comparing the stale-load branch against the uncapped
+ * `installed` made a plugin loading exactly its pinned version read as BROKEN,
+ * and the repair then moved the pinned rows off the pin.
+ *
+ * A version that cannot be ORDERED against the pin (a commit sha, the literal
+ * "unknown") is excluded rather than assumed to qualify: "cannot tell" must never
+ * license a registry rewrite, which is the same rule {@link isRepairablyBehind}
+ * applies one step later.
+ */
+function highestPermittedInstalled(
+	info: PluginInfo | undefined,
+	pin: string,
+): string | null {
+	if (pin === "latest") return highestInstalled(info);
+	const permitted = scopeVersions(info)
+		.map(([, v]) => v)
+		// pin >= v, i.e. v is at or below the pin. Null (unorderable) fails this.
+		.filter((v) => (compareVersions(pin, v) ?? -1) >= 0);
+	if (permitted.length === 0) return null;
+	return permitted.reduce((a, b) =>
+		(compareVersions(a, b) ?? -1) >= 0 ? a : b,
+	);
+}
+
 /**
  * Scopes that are strictly BEHIND `target`.
  *
@@ -277,6 +341,7 @@ export function classifyPlugin(
 		pluginId,
 		pinned: pin,
 		installed,
+		loaded: info?.loadedVersion ?? null,
 		available,
 		beforeVersions: Object.fromEntries(scopeVersions(info)) as Partial<
 			Record<PluginScope, string>
@@ -375,6 +440,112 @@ export function classifyPlugin(
 		};
 	}
 
+	// Installed and listed — but the loader will resolve an OLDER version than
+	// what is installed here, so this session runs stale code.
+	//
+	// Decided BEFORE every branch below, and that ordering is the whole fix.
+	// Those branches compare the REGISTERED version against the catalog, and the
+	// registered version is precisely the one that is not loading: a plugin at
+	// the newest version in every scope classified `current` while Claude Code
+	// loaded a two-versions-old copy. The report was green about code that was
+	// not running — which is worse than no report, because magus is the tool
+	// relied on to stay current.
+	//
+	// `loaded` is the loader's own answer (services/plugin-resolution.ts), not
+	// magus's registry resolution. Null means we could not establish it, and
+	// "cannot tell" never becomes a finding here — the plugin falls through to
+	// the ordinary comparisons below.
+	//
+	// `target` is what is INSTALLED here, never `available`. The repair points
+	// registry rows at a cache directory, and only the installed version's cache
+	// is on disk — aiming at the catalog version would name a directory that does
+	// not exist, which `repairStaleLoad` refuses. When the install is also behind
+	// the catalog, the next run plans the ordinary `update` on top, so the two
+	// steps converge instead of competing.
+	//
+	// `scopes` stays empty: one registry rewrite covers every row, so there is no
+	// per-scope work to enumerate. `pluginNeedsWork` says so directly.
+	//
+	// `isRepairablyBehind`, NOT `isBehind` — the one predicate `findStaleLoads`
+	// asks too, so this header's count and the startup popup's count are the same
+	// question. `isBehind` calls two differing commit shas "behind", which is the
+	// right answer to ITS question and the wrong one to this: moving rows forward
+	// between two unordered shas is a guess, not a repair. That difference alone
+	// made the popup claim 8 broken plugins where this header said 6.
+	//
+	// INSTALLED against LOADED — never `available` against loaded. This state is
+	// "what is installed HERE is not what runs here", and the catalog is not a
+	// party to it. Asking the catalog question here was wrong in both directions,
+	// measured against this module:
+	//
+	//  - installed 7.1.0, loaded 7.1.0, catalog 7.2.0 — an ordinary pending
+	//    release, nothing stale at all — classified `stale-load` with an empty
+	//    `scopes`, so no installer ran, `repairStaleLoad` found no row behind
+	//    7.1.0, wrote nothing, and its post-write assertion passed because the
+	//    loader already resolved 7.1.0. The engine counted that as a success and
+	//    7.2.0 was never installed. Every run classified identically while
+	//    `planIsBehind` stayed true, so `magus update --check` failed forever over
+	//    something `magus update` could not clear — the un-greenable gate the note
+	//    on `planIsBehind` argues must not exist. It fired on any machine with a
+	//    pending release, which is the normal state for this marketplace.
+	//  - a marketplace publishing NO version (278 of the 292 official plugins)
+	//    leaves `available` null, so `isRepairablyBehind` answered false and a
+	//    genuine stale load classified `current` — green about a session running
+	//    old code, the exact defect this state exists to end.
+	//
+	// The two formulas agree whenever `available` equals `installed`, which is
+	// every machine with nothing pending — which is why it held up by hand and why
+	// the parity fixture in stale-load-repair.test.ts had to be changed to be able
+	// to fail at all.
+	//
+	// BOTH AT ONCE — stale-loaded AND behind the catalog — is deliberately NOT
+	// folded together, and neither fact is dropped. This branch wins (what runs is
+	// the more consequential fact, and a reinstall is measured not to clear it),
+	// `target` stays an installed version because only an installed version's cache
+	// directory exists, and the pending catalog version is named in the note rather
+	// than left for the user to infer from a column. `magus update` then converges
+	// over consecutive runs: repair the load, then install the update once the load
+	// is no longer stale. It is not collapsed into one run because the two are
+	// different mechanisms — a registry rewrite and an installer — and the apply
+	// engine runs one action per item; interleaving them silently would make a
+	// failed half look like a whole success.
+	//
+	// CAPPED AT THE PIN, which is why the comparison is against `staleTarget` and
+	// not `installed`. `installed` is the highest version in ANY scope, and
+	// `scopesNeeding` deliberately never downgrades, so a scope legitimately sits
+	// ABOVE an exact pin. Measured: pin 0.3.0, project scope at 0.3.0 and loading,
+	// user scope at 0.5.0 — `installed` is 0.5.0, so an uncapped comparison called
+	// a plugin loading exactly what its pin asked for a broken load, and the repair
+	// then succeeded (this repo's row is writable, and 0.5.0's cache exists because
+	// user scope installed it), moving a pinned plugin off its pin and reporting
+	// success. An exact pin is a request, not a starting point: this branch may
+	// never plan past it, for the same reason the pin branch below refuses to plan
+	// toward something the marketplace cannot deliver.
+	//
+	// A pin naming a version installed NOWHERE at or below it leaves `staleTarget`
+	// null and the branch silent. That is the honest answer rather than a quiet
+	// promotion: the only versions on disk are above the pin, so there is no repair
+	// this may perform, and the pin branch below reports the pin state instead.
+	const staleTarget = highestPermittedInstalled(info, pin);
+	if (isRepairablyBehind(staleTarget, base.loaded)) {
+		// Only ever under "latest". Under an exact pin the catalog is not what this
+		// plugin is judged against, so naming a newer published version as something
+		// "available once the load is repaired" would advertise a move the pin
+		// forbids.
+		const pending =
+			pin === "latest" && isRepairablyBehind(available, installed);
+		return {
+			...base,
+			target: staleTarget,
+			action: "stale-load",
+			reason: "older-version-loads",
+			scopes: [],
+			note: pending
+				? `loads v${base.loaded}, installed v${staleTarget}; v${available} is available once the load is repaired`
+				: `loads v${base.loaded}, installed v${staleTarget}`,
+		};
+	}
+
 	// An exact pin is planned against what can ACTUALLY be delivered.
 	//
 	// This is dependency management, not a package manager: there is no
@@ -563,6 +734,12 @@ export interface PluginStateCounts {
 	update: number;
 	repair: number;
 	current: number;
+	/**
+	 * Its own count, never folded into `current`. The installed version being
+	 * right is exactly what makes this state dangerous: counted as current, the
+	 * header would report a clean bill of health for a session running old code.
+	 */
+	"stale-load": number;
 	unknown: number;
 }
 
@@ -575,6 +752,7 @@ export function countPluginStates(
 		update: 0,
 		repair: 0,
 		current: 0,
+		"stale-load": 0,
 		unknown: 0,
 	};
 	for (const item of items) counts[item.action]++;
@@ -762,6 +940,14 @@ export function planHasWork(plan: UpdatePlan): boolean {
  * binary had no version probe and "upgrade" meant "re-run the installer"; it
  * now means the owning installer says the tool is behind, which is drift.
  *
+ * A `stale-load` plugin DOES count. It was excluded while it was report-only, on
+ * the un-greenable-gate argument above: nothing magus ran could clear it, so a
+ * gate that failed on it would have failed forever. `repairStaleLoad` clears it
+ * now, and `magus update` applies that, so the gate closes — and leaving it out
+ * would mean `--check` printing "nothing behind" over a plugin whose session
+ * loads a version nobody installed, which is the deception the state exists to
+ * end.
+ *
  * NEITHER an `unknown` plugin NOR an `unknown` tool counts. "We could not check
  * this" is not evidence of drift, and most unknowns are structural and
  * permanent rather than transient: a plugin whose marketplace publishes no
@@ -784,7 +970,8 @@ export function planIsBehind(plan: UpdatePlan): boolean {
 			(p) =>
 				p.action === "install" ||
 				p.action === "update" ||
-				p.action === "repair",
+				p.action === "repair" ||
+				p.action === "stale-load",
 		) ||
 		plan.bins.some((b) => b.action === "install" || b.action === "upgrade") ||
 		plan.skills.some((s) => s.action === "install")

package/src/types/index.ts

@@ -295,26 +295,33 @@ export interface ClaudeMdConventions {
 
 // ─── Plugin Profile Types ──────────────────────────────────────────────────────
 
-export interface Profile {
-	name: string;
-	plugins: Record<string, boolean>;
-	createdAt: string;
-	updatedAt: string;
-}
-
-export interface ProfilesFile {
-	version: number;
-	profiles: Record<string, Profile>;
-}
-
-/** A profile with its id and scope, as used in UI lists */
-export interface ProfileEntry {
+/**
+ * A profile with its id and scope, as used in UI lists.
+ *
+ * This IS a v2 manifest entry. There is no separate TUI profile shape: both
+ * surfaces read one `.claude/profiles.json`, so a second type describing the
+ * same file is a second answer to one question. The earlier `Profile` /
+ * `ProfilesFile` pair required `createdAt`/`updatedAt` and typed `plugins` as
+ * booleans, which is a v1 file — handed a v2 file written by `magus update`,
+ * the list sort dereferenced a missing `updatedAt` and threw, so the Profiles
+ * tab reported an error for anyone who had ever run the CLI.
+ */
+export interface ProfileEntry extends ProfileManifestEntry {
 	id: string;
-	name: string;
-	plugins: Record<string, boolean>;
-	createdAt: string;
-	updatedAt: string;
 	scope: "user" | "project";
+	/**
+	 * This profile is the one the project is actually running.
+	 *
+	 * Derived from the `.claude/settings.json` symlink, not stored — see
+	 * `activeProfile`. Carried on the entry because a list of profiles with no
+	 * mark on the live one cannot answer the first question anybody asks of it:
+	 * the Profiles tab showed two identical-looking rows straight after
+	 * activating one of them.
+	 *
+	 * Only ever true for a `project` profile; a user-scope profile is a template,
+	 * and nothing links to it.
+	 */
+	active?: boolean;
 }
 
 // NOTE: The built-in profile type lives with its data in
@@ -324,11 +331,11 @@ export interface ProfileEntry {
 
 // ─── Team Profile Manifest (v2, committed .claude/profiles.json) ────────────────
 //
-// The v1 `Profile`/`ProfilesFile` above are the TUI's saved presets (plugins
-// only). The v2 manifest below is the committed, team-shared source of truth:
-// a superset that also carries marketplaces, MCP servers, CLI tools, skills,
-// settings, and env requirements. A v1 profile is a structural subset of a v2
-// entry, so v1 files migrate forward by a version bump alone.
+// The ONE shape of `.claude/profiles.json`, read by the TUI and the CLI alike.
+// It carries marketplaces, MCP servers, CLI tools, skills, settings and env
+// requirements as well as plugins. A v1 file — the TUI's old plugins-only
+// preset — is a structural subset, so it is read as a v2 entry whose optional
+// fields are simply absent, and rewritten as v2 on the next save.
 
 /** A marketplace a profile depends on (registered before its plugins install). */
 export interface ProfileMarketplaceRef {
@@ -385,6 +392,20 @@ export interface ProfileManifest {
 	version: 2;
 	/** When true, `install --check` fails on any plugin version drift. */
 	strictVersions?: boolean;
+	/**
+	 * Which profile this project wants, by id. Committed with the manifest.
+	 *
+	 * Without it a manifest says which profiles exist and never which one to
+	 * use, so every teammate cloning the repo is asked to choose and has nothing
+	 * to choose by — the repo knows the answer and had no way to write it down.
+	 *
+	 * It is intent, not state: the profile that is ACTUALLY active is the symlink
+	 * (see `activeProfile`), which is per-developer and gitignored. This field is
+	 * what a fresh clone activates so nobody is asked at all.
+	 *
+	 * Must name a profile that exists; `validateManifest` rejects it otherwise.
+	 */
+	default?: string;
 	profiles: Record<string, ProfileManifestEntry>;
 }
 

package/src/ui/App.tsx

@@ -1,10 +1,13 @@
 import fs from "node:fs";
 import { useRenderer } from "@opentui/react";
 import React, { useEffect, useState } from "react";
+import { activePluginPins } from "../services/active-closure.js";
 import { isClaudeAvailable } from "../services/claude-cli.js";
 import {
+	findStaleLoads,
 	migrateMarketplaceRename,
 	recoverMarketplaceSettings,
+	repairAllStaleLoads,
 } from "../services/claude-settings.js";
 import { checkGitignore } from "../services/gitignore-check.js";
 import {
@@ -13,6 +16,11 @@ import {
 } from "../services/gitignore-service.js";
 import { repairAllMarketplaces } from "../services/local-marketplace.js";
 import { autoAddMissingMarketplaces } from "../services/marketplace-sync.js";
+import {
+	type ProfileStartupNeed,
+	detectProfileStartupNeed,
+	needsNothing,
+} from "../services/profile-startup.js";
 import {
 	type VersionCheckResult,
 	checkForUpdates,
@@ -22,6 +30,11 @@ import { ProgressBar } from "./components/layout/ProgressBar.js";
 import { ModalContainer } from "./components/modals/index.js";
 import { useGitignoreModal } from "./hooks/useGitignoreModal.js";
 import { useKeyboardHandler } from "./hooks/useKeyboardHandler.js";
+import { useProfileStartupModal } from "./hooks/useProfileStartupModal.js";
+import {
+	staleLoadRepairSummary,
+	useStaleLoadModal,
+} from "./hooks/useStaleLoadModal.js";
 import {
 	AliasScreen,
 	CliToolsScreen,
@@ -128,6 +141,23 @@ function GlobalKeyHandler({
 			return;
 		}
 
+		// Ctrl+C quits from ANYWHERE, including from under an open modal, and is
+		// checked before the guard below rather than beside `q` further down.
+		//
+		// Every modal used to be dismissable, so Escape-then-Ctrl+C always worked
+		// and this ordering never mattered. The profile gate cannot be dismissed —
+		// by design, since there is nothing to carry on to — which left Ctrl+C
+		// swallowed by the guard and no interrupt at all. A terminal app that
+		// ignores Ctrl+C is indistinguishable from one that has hung.
+		//
+		// `q` deliberately does NOT get the same treatment: a modal may want it
+		// (the select list's own cancel), and it is a printable character an input
+		// modal has to receive.
+		if (key.ctrl && input === "c") {
+			onExit();
+			return;
+		}
+
 		// Don't handle keys when modal is open or searching
 		if (state.modal || state.isSearching) return;
 
@@ -364,7 +394,17 @@ function AppContent({ onExit }: AppContentProps) {
 		violationCount: number;
 		safeCount: number;
 	} | null>(null);
+	const [profileNeed, setProfileNeed] = useState<ProfileStartupNeed | null>(
+		null,
+	);
 	const gitignoreModal = useGitignoreModal();
+	const [brokenPluginCount, setBrokenPluginCount] = useState<number | null>(
+		null,
+	);
+	const staleLoadModal = useStaleLoadModal();
+	// The profile modal cannot be dismissed, so it needs the app's own exit: its
+	// only non-action is to leave.
+	const profileModal = useProfileStartupModal(onExit);
 
 	// Check for updates on startup, then re-check periodically (force-bypassing
 	// the session cache) so the banner reflects a release that lands while
@@ -407,6 +447,89 @@ function AppContent({ onExit }: AppContentProps) {
 		setGitignoreData(null);
 	}, [gitignoreData, gitignoreModal, state.modal, state.projectPath]);
 
+	// Show the broken-plugin modal — same "wait for the modal slot" rule as the
+	// gitignore one above, so two startup findings queue instead of one stomping
+	// the other.
+	useEffect(() => {
+		if (brokenPluginCount === null) return;
+		if (state.modal) return;
+		staleLoadModal.show({
+			brokenCount: brokenPluginCount,
+			// Re-surveys before repairing, like the gitignore fixer: the registry may
+			// have moved between the startup scan and the user pressing Enter, and
+			// repairing from the stale count would act on rows that are no longer
+			// there. `repairAllStaleLoads` is the same `repairStaleLoad` the Plugins
+			// screen's `a` key drives through the apply engine.
+			//
+			// The pins are re-read with it, from the same helper the survey used: a
+			// repair that capped at a different ceiling than the offer was counted
+			// against would move rows the dialog never mentioned.
+			onFix: async () =>
+				staleLoadRepairSummary(
+					await repairAllStaleLoads(
+						state.projectPath,
+						undefined,
+						await activePluginPins(state.projectPath),
+					),
+				),
+		});
+		setBrokenPluginCount(null);
+	}, [brokenPluginCount, staleLoadModal, state.modal, state.projectPath]);
+
+	// Does this project load an older plugin than it installed? Detection only;
+	// nothing is written until the user chooses Fix.
+	//
+	// Its own effect for the same reason the profile check below has one: the
+	// marketplace block returns early on `--no-refresh`, which is about network
+	// calls, and this question is answered from the local registry alone. Sharing
+	// that effect let the flag silently disable the check — observed, while this
+	// was still inside it.
+	useEffect(() => {
+		(async () => {
+			try {
+				const broken = await findStaleLoads(
+					process.cwd(),
+					undefined,
+					await activePluginPins(process.cwd()),
+				);
+				if (broken.length > 0) setBrokenPluginCount(broken.length);
+			} catch {
+				// non-fatal: the Plugins tab still shows the same rows
+			}
+		})();
+	}, []);
+
+	// Show the profile modal on the same terms as the gitignore one: only once
+	// the modal slot is free, so two startup checks that both found something do
+	// not stomp on each other. Gitignore is asked first simply because its
+	// effect is declared first; whichever the user dismisses, the other follows.
+	useEffect(() => {
+		if (!profileNeed) return;
+		if (state.modal) return;
+		profileModal.show(profileNeed);
+		setProfileNeed(null);
+	}, [profileNeed, profileModal, state.modal]);
+
+	// Is this project actually running a profile? Detection only — nothing is
+	// written until the user picks something in the modal. The Profiles tab could
+	// list two profiles while the project ran neither, and nothing anywhere said
+	// so.
+	//
+	// Its own effect, NOT part of the marketplace block below: that one returns
+	// early on `--no-refresh`, which is about network calls to marketplaces and
+	// has no bearing on whether this project is on a profile. Sharing the effect
+	// would let that flag silently disable this question.
+	useEffect(() => {
+		(async () => {
+			try {
+				const need = await detectProfileStartupNeed(process.cwd());
+				if (!needsNothing(need)) setProfileNeed(need);
+			} catch {
+				// non-fatal: the Profiles tab still works by hand
+			}
+		})();
+	}, []);
+
 	// Auto-refresh marketplaces on startup
 	useEffect(() => {
 		const noRefresh = process.argv.includes("--no-refresh");

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

@@ -1,4 +1,5 @@
 import type React from "react";
+import { hintChip } from "../../theme-mode.js";
 import { theme } from "../../theme.js";
 
 /** One footer hint: a key (or key group) and the action it performs. */
@@ -28,11 +29,12 @@ export function joinKeys(keys: string[]): string {
 // 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 —
-// the new colours simply never reached it. Anything chip-shaped uses theme.hints.
-const KEY_BG = theme.hints.defaultBg;
-const KEY_FG = theme.hints.fg;
-const LABEL_FG = theme.colors.muted;
-const GAP = "   ";
+// the new colours simply never reached it. Anything chip-shaped uses the theme.
+//
+// `hintChip()` rather than `theme.hints`: the chip is two fills that must sit a
+// measured step apart, and "a step quieter" is only definable against a page.
+// The static palette cannot express it; `theme-mode` resolves it.
+const GAP = "  ";
 
 /**
  * Render a row of footer hints as key badges + labels:
@@ -45,25 +47,35 @@ const GAP = "   ";
 export function FooterHints({
 	hints,
 }: { hints: FooterHint[] }): React.ReactNode {
+	const ink = hintChip();
 	const nodes: React.ReactNode[] = [];
 	hints.forEach((hint, i) => {
 		// A hint is identified by its key chord plus label, not its position.
 		const id = `${joinKeys(hint.keys)}:${hint.label}`;
 		if (i > 0) {
 			nodes.push(
-				<span key={`gap-${id}`} fg={LABEL_FG}>
+				<span key={`gap-${id}`} fg={theme.colors.muted}>
 					{GAP}
 				</span>,
 			);
 		}
+		// The two halves butt together with no separator: the key's fill ends
+		// exactly where the label's begins, so the pair reads as one chip with a
+		// bright end rather than as a badge followed by a word.
+		//
+		// Both halves are padded on BOTH sides. The label used to carry a trailing
+		// space only, which left its first letter hard against the boundary between
+		// the two fills — the key's own trailing space sits on the bright fill, so
+		// there was no quiet gap on the label's side at all and `↑↓ select` read as
+		// one cramped word.
 		nodes.push(
-			<span key={`k-${id}`} bg={KEY_BG} fg={KEY_FG}>
+			<span key={`k-${id}`} bg={ink.keyBg} fg={ink.keyFg}>
 				{` ${joinKeys(hint.keys)} `}
 			</span>,
 		);
 		nodes.push(
-			<span key={`l-${id}`} fg={LABEL_FG}>
-				{` ${hint.label}`}
+			<span key={`l-${id}`} bg={ink.labelBg} fg={ink.labelFg}>
+				{` ${hint.label} `}
 			</span>,
 		);
 	});

package/src/ui/components/modals/ModalContainer.tsx

@@ -121,6 +121,7 @@ export function ModalContainer() {
 						defaultIndex={selectIndex}
 						onSelect={modal.onSelect}
 						onCancel={modal.onCancel}
+						cancellable={modal.cancellable}
 					/>
 				);