claudeup 6.5.1 → 6.7.1

package/src/cli/update.ts

@@ -34,11 +34,14 @@
  * `cli/update-view.ts` owns every string. Nothing in this file formats.
  */
 
+import { selectProfileId } from "../services/active-closure.js";
 import { isClaudeAvailable } from "../services/claude-cli.js";
 import { clearContentDriftCache } from "../services/content-drift.js";
-import { checkBinaries } from "../services/doctor-bins.js";
 import { validateManifest } from "../services/manifest.js";
-import { refreshRegisteredMarketplaces } from "../services/marketplace-refresh.js";
+import {
+	refreshRegisteredMarketplaces,
+	reportRegisteredMarketplaces,
+} from "../services/marketplace-refresh.js";
 import { registerClosureMarketplaces } from "../services/marketplace-sync.js";
 import {
 	type PluginInfo,
@@ -48,6 +51,7 @@ import {
 import { resolveProfile } from "../services/resolver.js";
 import { getInstalledSkillNames } from "../services/skills-manager.js";
 import { activeProfile } from "../services/symlink-manager.js";
+import { REAL_TOOL_PROBE_IO, probeTools } from "../services/tool-probe.js";
 // The apply half lives in services/ so the TUI runs the SAME code — see the
 // header of update-engine.ts for what drifted while it did not.
 import {
@@ -77,11 +81,15 @@ import {
 	header,
 	info,
 	note as noteLine,
+	nothingToApplyNotice,
 	ok as okLine,
 	planReport,
 	stepFrame,
 	stepRecord,
 	summaryLine,
+	uncheckedGateNotice,
+	unknownPluginsNotice,
+	unknownToolsNotice,
 	warn as warnLine,
 } from "./update-view.js";
 
@@ -195,10 +203,13 @@ export async function runUpdateCommand(
 
 	// Active profile, not the union — "update my dependencies" means the set in
 	// use. A single-profile manifest needs no activation to be unambiguous.
-	const targetId =
-		flags.profile ??
-		(await activeProfile(projectPath)) ??
-		(profileIds.length === 1 ? profileIds[0] : undefined);
+	// Chosen through the same function the TUI uses, so both judge a plugin
+	// against the same pin.
+	const targetId = selectProfileId(
+		profileIds,
+		flags.profile,
+		await activeProfile(projectPath),
+	);
 	if (!targetId) {
 		console.error(
 			failLine(
@@ -246,7 +257,22 @@ export async function runUpdateCommand(
 	// clones first, then drop every cached answer derived from the old HEAD —
 	// skipping this is how a clone sits days behind while every plugin reads as
 	// up to date.
+	// ...but NOT under --dry-run or --check. Both promise to write nothing, and
+	// `git pull --ff-only` on a clone under ~/.claude/plugins/marketplaces/ is a
+	// write — it advances the user's marketplace to a new commit. The help text
+	// said "Writes nothing, exits 0" while the run printed "1 refreshed" in its
+	// own output, which is where this was caught. A read-only run plans against
+	// the clone as it stands; the notice below says so, so an unrefreshed
+	// catalog is never mistaken for a current one.
 	const refresh = await runStep(steps.marketplaces, async (say) => {
+		if (flags.dryRun || flags.check) {
+			say("read-only — selecting, not pulling");
+			// Report-only, NOT a skip: the autoUpdate-disabled verdict is a pure
+			// read and is the one diagnostic a read-only run must not lose.
+			const report = await reportRegisteredMarketplaces();
+			steps.marketplaces.detail = `not refreshed (read-only) · ${report.skipped.length} eligible`;
+			return report;
+		}
 		let settled = 0;
 		return refreshRegisteredMarketplaces([], {
 			onStart: (names) => {
@@ -311,26 +337,39 @@ export async function runUpdateCommand(
 		return map;
 	});
 
-	const binChecks = await runStep(steps.binaries, async (say) => {
+	// The tool probe: installed version, owner, and the owning installer's own
+	// "behind?" answer — the same probe the TUI's CLI Tools screen uses. It used
+	// to be a presence check, which is why every present unpinned tool planned
+	// as an upgrade on every run.
+	const toolFacts = await runStep(steps.binaries, async (say) => {
 		if (closure.bins.length === 0) {
 			steps.binaries.detail = "none declared";
 			return [];
 		}
 		steps.binaries.progress = { done: 0, total: closure.bins.length };
-		const results = await checkBinaries(
-			closure.bins,
-			undefined,
-			(name, index, total) => {
-				steps.binaries.progress = { done: index, total };
-				say(name);
+		const facts = await probeTools(closure.bins, REAL_TOOL_PROBE_IO, {
+			// `settled`, not `index`: results arrive in completion order, and a
+			// meter driven by index would jump backwards.
+			onResult: (f, { settled, total }) => {
+				steps.binaries.progress = { done: settled, total };
+				say(f.name);
 			},
-		);
-		const missing = results.filter((r) => !r.present).length;
-		steps.binaries.detail = `${results.length} checked${
-			missing > 0 ? ` · ${missing} missing` : ""
-		}`;
-		if (missing > 0) steps.binaries.state = "warn";
-		return results;
+		});
+		const items = planBinUpdates(closure.bins, facts);
+		const n = (a: string) => items.filter((i) => i.action === a).length;
+		const behind = n("upgrade");
+		const unknown = n("unknown");
+		const missing = n("install");
+		steps.binaries.detail = [
+			`${items.length} checked`,
+			behind > 0 ? `${behind} behind` : "",
+			unknown > 0 ? `${unknown} unknown` : "",
+			missing > 0 ? `${missing} missing` : "",
+		]
+			.filter(Boolean)
+			.join(" · ");
+		if (missing + unknown > 0) steps.binaries.state = "warn";
+		return facts;
 	});
 
 	const installedSkills = await runStep(steps.skills, async (say) => {
@@ -353,7 +392,7 @@ export async function runUpdateCommand(
 	const plan: UpdatePlan = {
 		profileId: targetId,
 		plugins: planPluginUpdates(closure.plugins, catalog),
-		bins: planBinUpdates(closure.bins, binChecks),
+		bins: planBinUpdates(closure.bins, toolFacts),
 		skills: planSkillUpdates(closure.skills, installedSkills),
 		binSpecs: new Map(closure.bins.map((b) => [b.name, b])),
 	};
@@ -361,23 +400,34 @@ export async function runUpdateCommand(
 	for (const line of planReport(plan)) console.log(line);
 
 	const counts = summarizePlan(plan);
-	if (counts.unknown > 0) {
-		console.log("");
-		console.log(
-			warnLine(
-				`${bold(String(counts.unknown))} plugin(s) could not be checked. They are NOT reported as up to date — re-run once the catalog is reachable.`,
-			),
-		);
+	const unknownToolNames = plan.bins
+		.filter((b) => b.action === "unknown")
+		.map((b) => b.name);
+	const toolUnknownLine = () =>
+		unknownToolsNotice(counts.unknownTools, unknownToolNames);
+	if (counts.unknownPlugins > 0 || counts.unknownTools > 0) console.log("");
+	if (counts.unknownPlugins > 0) {
+		console.log(unknownPluginsNotice(counts.unknownPlugins));
 	}
+	if (counts.unknownTools > 0) console.log(toolUnknownLine());
 
 	// `--check` gates on planIsBehind, not planHasWork. An already-installed
 	// skill is re-fetched on every apply because its manifest ref carries no
-	// content hash, and an unpinned binary has no version probe at all — neither
-	// is evidence that anything is out of date, and counting them made the gate
-	// exit 1 forever for any profile declaring a single skill.
+	// content hash, which is no evidence that anything is out of date — counting
+	// it made the gate exit 1 forever for any profile declaring a single skill.
+	//
+	// An `unknown` does not fail the gate, for plugins and tools alike (see
+	// planIsBehind). The same argument applies to both: a plugin whose
+	// marketplace publishes no version, or a tool another npm owns, is unknown
+	// permanently, so failing on it is the skill case again — this profile's 5
+	// unversioned official plugins made `--check` exit 1 on every run. A tool
+	// or plugin something says is BEHIND still does fail it. Because a failed
+	// check now passes silently by exit code, the unchecked count is printed
+	// beside the verdict; the per-kind notices and each row's reason are above.
 	if (flags.check) {
 		console.log("");
 		if (!planIsBehind(plan)) {
+			if (counts.unknown > 0) console.log(uncheckedGateNotice(counts.unknown));
 			console.log(okLine("Nothing missing and nothing behind."));
 			return 0;
 		}
@@ -406,12 +456,11 @@ export async function runUpdateCommand(
 		// fine". But nothing is APPLIED for an unknown — the apply loop skips it —
 		// so reporting on `planHasWork` alone claimed a run had happened when it
 		// had not. Say what is actually true instead.
-		if (counts.unknown > 0) {
-			console.log(
-				warnLine(
-					`Nothing to apply. ${counts.unknown} plugin(s) could not be checked — re-run once the catalog is reachable.`,
-				),
-			);
+		if (counts.unknownPlugins + counts.unknownTools > 0) {
+			if (counts.unknownPlugins > 0) {
+				console.log(nothingToApplyNotice(counts.unknownPlugins));
+			}
+			if (counts.unknownTools > 0) console.log(toolUnknownLine());
 			return 0;
 		}
 		console.log(okLine("Everything is up to date."));
@@ -466,6 +515,8 @@ export async function runUpdateCommand(
 	};
 
 	const applyLive = new LiveRegion();
+	/** The last detail each item finished with — the reason, for an unchanged one. */
+	const finishedDetail = new Map<string, string>();
 	const reporter: ApplyReporter = {
 		begin: (name) => {
 			state.current = name;
@@ -473,12 +524,17 @@ export async function runUpdateCommand(
 		},
 		finish: (succeeded, name, detail, ms) => {
 			state.done++;
+			finishedDetail.set(name, detail);
 			applyLive.note(
 				applyRow(
 					succeeded,
 					name,
 					nameWidth,
-					succeeded ? dim(detail) : fg(brand.danger, detail),
+					!succeeded
+						? fg(brand.danger, detail)
+						: detail.startsWith("no change — ")
+							? fg(brand.warning, detail)
+							: dim(detail),
 					ms,
 				),
 			);
@@ -501,9 +557,29 @@ export async function runUpdateCommand(
 		counts.unknown,
 		failed.length,
 		Date.now() - startedAt,
+		outcome.unchanged.length,
 	))
 		console.log(line);
 
+	// Exited 0, read back unmoved. Reported, never fatal — the same precedent
+	// as the pin mismatches below: this is a standing property of the machine
+	// (a stale tap, a shadowing PATH entry), not something this run did wrong,
+	// and it will be replanned. What it must never be is counted as "changed".
+	if (outcome.unchanged.length > 0) {
+		console.log(
+			warnLine(
+				`${bold(String(outcome.unchanged.length))} item(s) ran but did not change:`,
+			),
+		);
+		for (const name of outcome.unchanged) {
+			const detail = (finishedDetail.get(name) ?? "").replace(
+				/^no change — /,
+				"",
+			);
+			console.log(noteLine(`${name}: ${detail}`));
+		}
+	}
+
 	// An exact pin the installer could not deliver. Reported, never fatal: only
 	// the newest published version is installable, so this is a standing property
 	// of the manifest rather than something this run did wrong, and failing here

package/src/data/models-presets.ts

@@ -40,19 +40,18 @@ export const DEFAULT_AGENT_GRADES: Record<string, Grade> = {
 	// 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",
+	"dev:aggregator": "normal",
 
 	// Reading a lot is not analysing.
 	//
-	// `detective` is read-only: it locates implementations, traces a path and reports
+	// `analyze` 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",
+	"code-search:analyze": "cheap",
 
-	// Search, transcription and bookkeeping: bounded, mechanical, high-volume.
+	// Search and bookkeeping: bounded, mechanical, high-volume.
 	Explore: "cheap",
-	"dev:scribe": "cheap",
 	"dev:stack-detector": "cheap",
 	"dev:docs": "cheap",
 	"terminal:tui-navigator": "cheap",
@@ -69,7 +68,7 @@ export const DEFAULT_AGENT_GRADES: Record<string, Grade> = {
  * 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
+ * also name skills (`dev:context-detection`, `code-search:investigate`) which are not
  * dispatched through the Agent tool and so are not routed at all.
  */
 export const WORKFLOWS: { name: string; agents: string[] }[] = [
@@ -79,7 +78,7 @@ export const WORKFLOWS: { name: string; agents: string[] }[] = [
 			"dev:stack-detector",
 			"dev:architect",
 			"dev:developer",
-			"dev:test-architect",
+			"dev:qa-engineer",
 			"dev:reviewer",
 		],
 	},
@@ -87,14 +86,14 @@ export const WORKFLOWS: { name: string; agents: string[] }[] = [
 		name: "debug",
 		agents: [
 			"dev:stack-detector",
-			"code-analysis:detective",
+			"code-search:analyze",
 			"dev:debugger",
 			"dev:developer",
 		],
 	},
 	{
 		name: "investigate",
-		agents: ["code-analysis:detective", "dev:researcher"],
+		agents: ["code-search:analyze", "dev:researcher"],
 	},
 ];
 
@@ -102,7 +101,7 @@ export const WORKFLOWS: { name: string; agents: string[] }[] = [
  * 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
+ * reads images. `designer: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.
@@ -112,7 +111,7 @@ export const WORKFLOWS: { name: string; agents: string[] }[] = [
  * 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;
+export const VISION_AGENTS = ["designer:review", "designer:ui"] as const;
 
 function preset(
 	name: string,

package/src/data/predefined-profiles.ts

@@ -52,7 +52,7 @@ export const PREDEFINED_PROFILES: PredefinedProfile[] = [
 		magusPlugins: [
 			"setup",
 			"multimodel",
-			"code-analysis",
+			"code-search",
 			"dev",
 			"browser-use",
 			"designer",
@@ -90,7 +90,7 @@ export const PREDEFINED_PROFILES: PredefinedProfile[] = [
 		icon: "★",
 		magusPlugins: [
 			"dev",
-			"code-analysis",
+			"code-search",
 			"terminal",
 			"setup",
 			"designer",
@@ -129,7 +129,7 @@ export const PREDEFINED_PROFILES: PredefinedProfile[] = [
 		name: "Backend Forge",
 		description: "API development, debugging, code quality, data workflows",
 		icon: "★",
-		magusPlugins: ["dev", "code-analysis", "terminal", "setup", "multimodel"],
+		magusPlugins: ["dev", "code-search", "terminal", "setup", "multimodel"],
 		anthropicPlugins: [
 			"feature-dev",
 			"code-review",
@@ -159,7 +159,7 @@ export const PREDEFINED_PROFILES: PredefinedProfile[] = [
 		icon: "★",
 		magusPlugins: [
 			"dev",
-			"code-analysis",
+			"code-search",
 			"terminal",
 			"setup",
 			"multimodel",
@@ -194,11 +194,11 @@ export const PREDEFINED_PROFILES: PredefinedProfile[] = [
 		icon: "★",
 		magusPlugins: [
 			"dev",
-			"code-analysis",
+			"code-search",
 			"terminal",
 			"setup",
 			"browser-use",
-			"image-generate@magus-marketing",
+			"image@magus-marketing",
 			"video-editing@magus-marketing",
 		],
 		anthropicPlugins: [
@@ -226,7 +226,7 @@ export const PREDEFINED_PROFILES: PredefinedProfile[] = [
 		description:
 			"Planning, code review, coordination, and broad repo visibility",
 		icon: "★",
-		magusPlugins: ["dev", "code-analysis", "terminal", "setup", "multimodel"],
+		magusPlugins: ["dev", "code-search", "terminal", "setup", "multimodel"],
 		anthropicPlugins: [
 			"code-review",
 			"pr-review-toolkit",

package/src/services/active-closure.ts

@@ -0,0 +1,117 @@
+/**
+ * Which profile is in effect for a project, and what it resolves to.
+ *
+ * `claudeup update` and the TUI must judge a plugin against the SAME pin, or
+ * the same plugin in the same project reads differently in each. They used to
+ * pick the profile in different ways — the CLI inline, the TUI not at all (it
+ * judged everything against "latest") — so an exact pin could never agree.
+ * Both now choose through {@link selectProfileId} over the same manifest and
+ * the same active-profile symlink.
+ *
+ * Read-only. Unlike the CLI's `ensureManifest`, nothing here bootstraps a
+ * manifest: a screen opening must never author a file a team commits.
+ *
+ * NOTHING HERE PRINTS — it runs under the CLI's live region and inside the TUI.
+ */
+
+import type {
+	BinRequirement,
+	ProfileManifest,
+	ResolvedClosure,
+} from "../types/index.js";
+import { readManifest, validateManifest } from "./manifest.js";
+import { resolveProfile } from "./resolver.js";
+import { activeProfile } from "./symlink-manager.js";
+
+/**
+ * The profile to use: the explicit one, else the active one, else the only one.
+ *
+ * Each candidate counts only if the manifest defines it. A stale active-profile
+ * symlink naming a profile that was since removed would otherwise be chosen and
+ * then fail to resolve, even when the manifest has exactly one profile and the
+ * answer is unambiguous.
+ */
+export function selectProfileId(
+	profileIds: readonly string[],
+	explicit: string | undefined,
+	active: string | null,
+): string | null {
+	if (explicit !== undefined && profileIds.includes(explicit)) return explicit;
+	if (active !== null && profileIds.includes(active)) return active;
+	if (profileIds.length === 1) return profileIds[0] ?? null;
+	return null;
+}
+
+export interface ActiveClosure {
+	profileId: string;
+	closure: ResolvedClosure;
+}
+
+export interface ActiveClosureDeps {
+	readManifest(projectPath: string): Promise<ProfileManifest>;
+	activeProfile(projectPath: string): Promise<string | null>;
+	resolveProfile(
+		manifest: ProfileManifest,
+		id: string,
+		opts?: {
+			binResolver?: (pluginId: string) => Promise<BinRequirement[]>;
+		},
+	): Promise<ResolvedClosure>;
+}
+
+const REAL_DEPS: ActiveClosureDeps = {
+	readManifest,
+	activeProfile,
+	resolveProfile,
+};
+
+export interface LoadActiveClosureOptions {
+	/**
+	 * false → `resolveProfile` gets a resolver that returns no requirements, so
+	 * no plugin's `plugin.json` is read and `closure.bins` holds only the
+	 * profile's own `cliTools` entries. Default true.
+	 *
+	 * The Plugins screen needs only `closure.plugins`. The default resolver
+	 * locates and reads every declared plugin's `plugin.json`, which is work the
+	 * screen would pay on every fetch for a field it never reads.
+	 */
+	resolveBins?: boolean;
+	deps?: Partial<ActiveClosureDeps>;
+}
+
+const NO_BINS = async (): Promise<BinRequirement[]> => [];
+
+/**
+ * The active profile's closure for a project.
+ *
+ * Null when there is no manifest, an invalid one, or no profile that can be
+ * selected without an explicit choice. Never throws: a caller that gets null
+ * judges against "latest" and says so, which is better than a screen that fails
+ * to load over a profile it only needed for pins.
+ */
+export async function loadActiveClosure(
+	projectPath: string,
+	opts: LoadActiveClosureOptions = {},
+): Promise<ActiveClosure | null> {
+	const deps: ActiveClosureDeps = { ...REAL_DEPS, ...opts.deps };
+	try {
+		const manifest = await deps.readManifest(projectPath);
+		if (validateManifest(manifest).length > 0) return null;
+
+		const profileId = selectProfileId(
+			Object.keys(manifest.profiles),
+			undefined,
+			await deps.activeProfile(projectPath),
+		);
+		if (profileId === null) return null;
+
+		const closure = await deps.resolveProfile(
+			manifest,
+			profileId,
+			opts.resolveBins === false ? { binResolver: NO_BINS } : {},
+		);
+		return { profileId, closure };
+	} catch {
+		return null;
+	}
+}

package/src/services/catalog-cache-store.ts

@@ -35,8 +35,12 @@ import type { MarketplacePlugin } from "./marketplace-catalog.js";
 /**
  * How long a cached catalog is served before we ask again.
  *
- * Matches the hour that `update-cache.ts` already uses for its own check, so the
- * tool has one refresh rhythm rather than two.
+ * This is the ONLY refresh rhythm claudeup has, and it is why the TUI and
+ * `claudeup update` can disagree about the same plugin for up to an hour:
+ * `update` fast-forwards the clones and clears this cache before planning,
+ * while the TUI serves whatever is here. That is not a bug in either path, but
+ * anything that reports "no update" off a cached catalog has to say the answer
+ * is up to an hour old.
  */
 export const CATALOG_TTL_MS = 60 * 60 * 1000;