claudeup 4.29.0 → 4.31.0

package/src/services/profile-materializer.ts

@@ -21,11 +21,26 @@ import { profileDir } from "./symlink-manager.js";
  * enabled, merged with the profile's declared settings. The profile's settings
  * win over the derived enabledPlugins only if it explicitly sets that key
  * (it normally won't).
+ *
+ * `allPluginIds` is the manifest-wide union of plugins across every profile.
+ * Plugins in the union that this profile does NOT want are written as an
+ * explicit `false`, which is what makes `profile switch` exclusive rather than
+ * additive. Claude Code resolves enabledPlugins **per plugin id**, walking from
+ * the highest-precedence scope down and taking the first scope that mentions
+ * the id — an id a scope omits falls through to the next one. Since
+ * `claudeup install` installs the union at user scope, every non-member would
+ * otherwise inherit that user-scope `true` and stay enabled while a profile
+ * that excludes it is active. Omitting the union (the default) preserves the
+ * old additive behavior for callers that have no cross-profile view.
  */
 export function buildProfileSettings(
 	closure: ResolvedClosure,
+	allPluginIds: readonly string[] = [],
 ): Record<string, unknown> {
 	const enabledPlugins: Record<string, boolean> = {};
+	for (const pluginId of allPluginIds) {
+		enabledPlugins[pluginId] = false;
+	}
 	for (const pluginId of Object.keys(closure.plugins)) {
 		enabledPlugins[pluginId] = true;
 	}
@@ -39,6 +54,37 @@ export function buildProfileMcp(
 	return { mcpServers: { ...closure.mcpServers } };
 }
 
+/**
+ * Seed a profile's skills/ dir from the project's pre-existing `.claude/skills/`.
+ *
+ * Activating a profile replaces `.claude/skills` with a symlink into the profile
+ * dir, and replacing means `fs.remove` first. A project that committed its own
+ * skills before adopting profiles would lose them at that moment. So the first
+ * time a profile's skills/ dir is created, any real (non-symlink) project skills
+ * are copied in — every profile inherits what the project already had, and the
+ * link swap destroys nothing.
+ *
+ * Only runs when the profile's skills/ dir does not exist yet, so it never
+ * fights a later `skills-manager` install or re-adds a skill the user removed.
+ */
+async function seedSkillsFromProject(
+	skillsDir: string,
+	projectPath?: string,
+): Promise<void> {
+	if (await fs.pathExists(skillsDir)) return;
+
+	const projectSkills = path.join(projectPath ?? process.cwd(), ".claude", "skills");
+	try {
+		// lstat, not pathExists: an existing profile symlink is not a source.
+		const stat = await fs.lstat(projectSkills);
+		if (!stat.isDirectory() || stat.isSymbolicLink()) return;
+		if ((await fs.readdir(projectSkills)).length === 0) return;
+		await fs.copy(projectSkills, skillsDir, { dereference: true });
+	} catch {
+		// No project skills dir (or unreadable) — nothing to carry over.
+	}
+}
+
 /**
  * Write `_profiles/<name>/` from a resolved closure. Idempotent: overwrites
  * settings.json / mcp.json and ensures skills/ exists. Returns the dir path.
@@ -47,15 +93,20 @@ export async function materializeProfile(
 	name: string,
 	closure: ResolvedClosure,
 	projectPath?: string,
+	allPluginIds: readonly string[] = [],
 ): Promise<string> {
 	const dir = profileDir(name, projectPath);
 	await fs.ensureDir(dir);
-	await fs.writeJson(path.join(dir, "settings.json"), buildProfileSettings(closure), {
-		spaces: 2,
-	});
+	await fs.writeJson(
+		path.join(dir, "settings.json"),
+		buildProfileSettings(closure, allPluginIds),
+		{ spaces: 2 },
+	);
 	await fs.writeJson(path.join(dir, "mcp.json"), buildProfileMcp(closure), {
 		spaces: 2,
 	});
-	await fs.ensureDir(path.join(dir, "skills"));
+	const skillsDir = path.join(dir, "skills");
+	await seedSkillsFromProject(skillsDir, projectPath);
+	await fs.ensureDir(skillsDir);
 	return dir;
 }