@danypops/pi-packed 0.27.2 → 0.27.4

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@danypops/pi-packed",
-  "version": "0.27.2",
+  "version": "0.27.4",
   "description": "Pi package lifecycle, validation, daemon, tools, profiles, and TUI",
   "type": "module",
   "bin": {
@@ -33,7 +33,7 @@
     "@danypops/vehicle-client": "^0.10.0",
     "@danypops/vehicle-client-pi": "^0.40.1",
     "@danypops/vehicle-core": "^0.15.0",
-    "@danypops/vehicle-server": "^0.24.1",
+    "@danypops/vehicle-server": "^0.24.2",
     "jiti": "^2.7.0",
     "malevich-tui-components": "^0.21.1",
     "publint": "0.3.22",

package/service/src/daemon/daemon-service.ts

@@ -161,6 +161,39 @@ function resolveDependencyCandidate(depDir: string, depName: string): ResolvedDa
 	return undefined;
 }
 
+/** Strips a leading "pi-" from an unscoped package name, e.g. "pi-papyrus" -> "papyrus", "pipes" ->
+ * "pipes" unchanged. Mirrors the real, universal naming convention every pi-* extension in this
+ * house follows for its own namesake daemon package (pi-lector/lector, pi-jittor/jittor,
+ * pi-tickets/tickets, pi-pipes/pipes, pi-web-spider/web-spider, pi-papyrus/papyrus). */
+function namesakeDaemonName(unscopedPackageName: string): string | undefined {
+	return unscopedPackageName.startsWith("pi-") ? unscopedPackageName.slice("pi-".length) : undefined;
+}
+
+/** Resolves every dependency-name candidate for one dependency, across both its nested and
+ * hoisted layout (see resolveDependencyCandidate) -- factored out so detectVehicleDaemonService
+ * can collect candidates across EVERY dependency name before picking one, instead of returning
+ * on the first name that resolves at all. */
+function resolveDependencyNameCandidate(
+	packageDir: string,
+	depName: string,
+	hoistedNodeModulesDir: string | undefined,
+): ResolvedDaemonEntrypoint | undefined {
+	const candidateDirs = [join(packageDir, "node_modules", depName), ...(hoistedNodeModulesDir ? [join(hoistedNodeModulesDir, depName)] : [])];
+	const resolved = candidateDirs
+		.map((depDir) => resolveDependencyCandidate(depDir, depName))
+		.filter((entry): entry is ResolvedDaemonEntrypoint => entry !== undefined);
+	if (resolved.length === 0) return undefined;
+	if (resolved.length === 1) return resolved[0];
+	// Nested and hoisted both resolved for the same dependency (the real jittor incident:
+	// a stale nested copy always won just because it's checked first). Prefer the newer
+	// version; a genuine tie keeps the nested result, preserving papyrus's intentional case.
+	let best = resolved[0]!;
+	for (const candidate of resolved.slice(1)) {
+		if (versionAtLeast(candidate.version, best.version) && candidate.version !== best.version) best = candidate;
+	}
+	return best;
+}
+
 export function detectVehicleDaemonService(
 	packageDir: string,
 	fallbackName: string,
@@ -174,26 +207,24 @@ export function detectVehicleDaemonService(
 		return { binPath: join(packageDir, ownBin), args: ["serve"], name: unscopedName(own.name ?? fallbackName), version: own.version };
 	}
 
+	// A pi-X package can carry OTHER Vehicle-shaped dependencies for unrelated reasons (e.g.
+	// pi-papyrus depends on @danypops/jittor only for Context Hub types) -- confirmed live: a
+	// naive "first dependency name that resolves" scan returned jittor's spec for pi-papyrus
+	// (dependencies happened to list "@danypops/jittor" before "@danypops/papyrus"), silently
+	// mis-registering pi-papyrus's own Armada vehicle as another package's daemon entirely. Collect
+	// every resolvable candidate across ALL dependency names first, then prefer the one whose own
+	// resolved vehicle name matches this package's namesake convention (pi-X -> X) before falling
+	// back to the first-found candidate for a package that doesn't follow that convention.
+	const byName = unscopedName(own.name ?? fallbackName);
+	const wantedNamesake = namesakeDaemonName(byName);
+	const candidates: ResolvedDaemonEntrypoint[] = [];
 	for (const depName of Object.keys(own.dependencies ?? {})) {
-		const candidateDirs = [
-			join(packageDir, "node_modules", depName),
-			...(hoistedNodeModulesDir ? [join(hoistedNodeModulesDir, depName)] : []),
-		];
-		const resolved = candidateDirs
-			.map((depDir) => resolveDependencyCandidate(depDir, depName))
-			.filter((entry): entry is ResolvedDaemonEntrypoint => entry !== undefined);
-		if (resolved.length === 0) continue;
-		if (resolved.length === 1) return resolved[0];
-		// Nested and hoisted both resolved for the same dependency (the real jittor incident:
-		// a stale nested copy always won just because it's checked first). Prefer the newer
-		// version; a genuine tie keeps the nested result, preserving papyrus's intentional case.
-		let best = resolved[0]!;
-		for (const candidate of resolved.slice(1)) {
-			if (versionAtLeast(candidate.version, best.version) && candidate.version !== best.version) best = candidate;
-		}
-		return best;
+		const resolved = resolveDependencyNameCandidate(packageDir, depName, hoistedNodeModulesDir);
+		if (!resolved) continue;
+		if (wantedNamesake !== undefined && resolved.name === wantedNamesake) return resolved;
+		candidates.push(resolved);
 	}
-	return undefined;
+	return candidates[0];
 }
 
 /**

package/service/src/daemon/daemon.ts

@@ -127,6 +127,19 @@ export function daemonOptions(options: StartPackedDaemonOptions): StartDaemonOpt
 			intervalMs: envMs(ENV.RECONCILE_SECS, RECONCILE_INTERVAL_DEFAULT_MS),
 			run: async () => {
 				const result = await reconcileAllDaemonServices(piHome, undefined, daemonServiceInstaller);
+				// A package updated through a route pi-packed never sees at all (e.g. the generic,
+				// daemon-unaware `pi update --extension` / pkg_update path -- see
+				// pkg-update-never-restarts-vehicle-daemon) leaves this as the ONLY thing that ever
+				// notices and restarts the stale daemon. Logging only on failure made every silent
+				// success indistinguishable from "this never ran" -- there was no way to confirm a
+				// restart this task performed actually happened, short of checking the process's own
+				// PID by hand.
+				if (result.reconciled.some((entry) => entry.installed) || result.pruned.length > 0) {
+					logger.info("vehicle-reconcile applied changes", {
+						reconciled: result.reconciled.filter((entry) => entry.installed).map((entry) => entry.vehicleName),
+						pruned: result.pruned.map((entry) => entry.vehicleName),
+					});
+				}
 				if (result.failed.length > 0) {
 					logger.warn("vehicle-reconcile completed with failures", {
 						reconciled: result.reconciled.length,
@@ -171,28 +184,23 @@ export function daemonOptions(options: StartPackedDaemonOptions): StartDaemonOpt
 	};
 }
 
-function runInitialMaintenance(maintenanceTasks: MaintenanceTask[] | undefined): void {
-	for (const task of maintenanceTasks ?? []) {
-		void Promise.resolve(task.run()).catch((error) =>
-			logger.error(`maintenance task failed: ${task.name}`, { error: error instanceof Error ? error.message : String(error) }),
-		);
-	}
-}
-
+// startDaemon() itself now runs every maintenance task once immediately at startup (in
+// addition to its own interval) -- see @danypops/vehicle-server's own daemon.ts. This used to
+// be a bespoke wrapper here (runInitialMaintenance(), called after startDaemon() returned, or
+// from serveMain()'s onListen) working around a bare setInterval() never firing until its full
+// interval first elapsed; kept here would now double-run every task on every startup. Every
+// OTHER vehicle-server-based daemon (lector, jittor, papyrus, pipes, tickets,
+// web-spider-daemon) never had this workaround at all and now gets the same fix for free from
+// the shared implementation, instead of needing to independently reinvent it.
 export async function startPackedDaemon(options: StartPackedDaemonOptions = {}): Promise<RunningDaemon> {
-	const configured = daemonOptions(options);
-	const running = await startDaemon(configured);
-	runInitialMaintenance(configured.maintenanceTasks);
-	return running;
+	return startDaemon(daemonOptions(options));
 }
 
 export function serveMain(): void {
-	const configured = daemonOptions({});
 	runDaemonProcess({
-		...configured,
+		...daemonOptions({}),
 		onListen: ({ host, port }) => {
 			logger.info("listening", { host, port });
-			runInitialMaintenance(configured.maintenanceTasks);
 		},
 	});
 }

package/service/src/shared/constants.ts

@@ -52,7 +52,17 @@ export const INDEX_OPERATION_TIMEOUT_MS = 10 * 60_000;
 export const WATCH_INTERVAL_DEFAULT_MS = 30 * 60_000; // updates diff cadence
 export const CATALOG_INTERVAL_DEFAULT_MS = 6 * 3_600_000; // full mirror TTL
 export const INDEX_INTERVAL_DEFAULT_MS = 6 * 3_600_000; // static index regeneration TTL, same cadence as the catalog mirror it reads from
-export const RECONCILE_INTERVAL_DEFAULT_MS = 30 * 60_000; // Vehicle-service drift sweep cadence -- catches an out-of-band npm install/update a running daemon never picked up
+// Vehicle-service drift sweep cadence -- catches an out-of-band npm install/update a running
+// daemon never picked up (e.g. a plain `pkg_update`/`pi update --extension`, which has no way to
+// notify Armada/pi-packed at all -- see pkg-update-never-restarts-vehicle-daemon). Now that
+// startDaemon() also runs every maintenance task once immediately at startup (see
+// vehicle-server's own daemon.ts), a restart of pi-packed itself no longer waits out this
+// interval at all -- this cadence now only bounds the OTHER case: an out-of-band update that
+// lands while pi-packed's own daemon is already running and stays up. 30 minutes was tuned for
+// a background safety net, not an interactive "I just updated something" workflow; 5 minutes
+// keeps the same self-healing guarantee at a much more reasonable latency for a per-pass cost
+// that's still just a handful of cheap native-service inspections for a fleet this size.
+export const RECONCILE_INTERVAL_DEFAULT_MS = 5 * 60_000;
 export const IDLE_BUDGET_DEFAULT_MS = 10 * 60_000; // on-demand self-exit
 export const WATCHDOG_TICK_MS = 15_000;
 

package/service/test/daemon-maintenance.test.ts

@@ -226,6 +226,33 @@ describe("startPackedDaemon's own maintenance-task wiring (self-heals Vehicle dr
 		}
 	});
 
+	/**
+	 * Regression guard for the double-execution risk this file's own daemon.ts (startPackedDaemon/
+	 * serveMain) used to carry: a bespoke runInitialMaintenance() wrapper called explicitly, on top
+	 * of what startDaemon() (vehicle-server) itself now already does since it started running every
+	 * maintenance task once immediately at startup. Removed entirely -- this proves it stayed
+	 * removed, not just that a task runs at least once (the test above already covers that).
+	 */
+	it("runs each maintenance task exactly once at startup, never twice", async () => {
+		const piHome = fakePiHome([]);
+		const paths = fakePaths();
+		let runs = 0;
+		const task: MaintenanceTask = {
+			name: "probe-exactly-once",
+			intervalMs: RECONCILE_INTERVAL_DEFAULT_MS,
+			run: () => {
+				runs++;
+			},
+		};
+		const running = await startPackedDaemon({ paths, reg: registry, inst: installer, piHome, maintenanceTasks: [task] });
+		try {
+			await new Promise((resolve) => setTimeout(resolve, 30));
+			expect(runs).toBe(1);
+		} finally {
+			await running.stop();
+		}
+	});
+
 	it("does not reconcile Armada before the daemon has published its readiness handle", async () => {
 		const piHome = fakePiHome(["npm:@danypops/pi-packed", "npm:@danypops/probe"]);
 		const paths = fakePaths();

package/service/test/daemon-service.test.ts

@@ -189,6 +189,38 @@ describe("resolveDaemonServiceSpec", () => {
 		expect(result.spec.name).toBe("papyrus");
 	});
 
+	it("prefers the dependency matching its own pi-X -> X namesake convention over an unrelated Vehicle-shaped dependency listed first -- the real live incident: pi-papyrus's own dependency scan resolved to jittor (a Context Hub-types-only dependency) instead of papyrus, because 'jittor' sorted before 'papyrus' in the dependencies object", () => {
+		const piHome = fakePiHome();
+		const extDir = join(piHome, "npm", "node_modules", "@danypops/pi-papyrus");
+		// Real on-disk order: @danypops/jittor genuinely does sort before @danypops/papyrus.
+		writeRawPackage(extDir, {
+			name: "@danypops/pi-papyrus",
+			version: "1.0.0",
+			dependencies: { "@danypops/jittor": "^0.18.0", "@danypops/papyrus": "^0.54.0" },
+		});
+		const jittorDir = join(extDir, "node_modules", "@danypops/jittor");
+		writeRawPackage(jittorDir, {
+			name: "@danypops/jittor",
+			version: "0.18.0",
+			bin: { jittor: "src/cli.ts" },
+			dependencies: { "@danypops/vehicle-server": "^0.24.0" },
+		});
+		const papyrusDir = join(extDir, "node_modules", "@danypops/papyrus");
+		writeRawPackage(papyrusDir, {
+			name: "@danypops/papyrus",
+			version: "0.54.0",
+			bin: { papyrus: "src/cli.ts" },
+			dependencies: { "@danypops/vehicle-server": "^0.24.0" },
+			packed: { daemonService: { binPath: "src/cli.ts", args: ["serve"], handleFilename: "vehicle-handle.json" } },
+		});
+
+		const result = resolveDaemonServiceSpec(piHome, "npm:@danypops/pi-papyrus");
+		expect(result.ok).toBe(true);
+		if (!result.ok) throw new Error("expected ok");
+		expect(result.spec.name).toBe("papyrus");
+		expect(result.spec.binPath).toBe(join(papyrusDir, "src/cli.ts"));
+	});
+
 	it("honors a nested dependency's own explicit packed.daemonService manifest, not just bin+dependency convention -- confirmed live: papyrus's real handle file is 'vehicle-handle.json', not the 'daemon.json' convention guess, and papyrus is only ever discovered this way (one level into pi-papyrus's own dependencies), never installed directly by name", () => {
 		const piHome = fakePiHome();
 		const extDir = join(piHome, "npm", "node_modules", "@danypops/pi-papyrus");