pi-harness-runtime 1.1.390 → 1.1.392

package/AGENTS.md

@@ -494,36 +494,63 @@ bun run build && bun run start   # Server deployment
 ### 14. Workspace Environment Auto-Detection
 
 **At session start, the harness auto-detects:**
-- `.env` file presence → Dev environment evidence
+- `.env` / `.env.*` file variables → Dev environment evidence
 - `package.json` `dev` script → Hot reload capability
-- `NODE_ENV` value → development/production/test
+- The environment variable, in this order: the `NODE_ENV` of the process env
+  (it decides, also when it names no known mode), then the dotenv files of the
+  workspace: `NODE_ENV`, an environment shaped key whose value names a known
+  mode (`*_ENV`, `*_ENVIRONMENT`, `*_MODE`, `*_STAGE`, e.g. `AMOS_ENV`), then
+  any other environment shaped key - and only then an environment shaped key
+  of the process env → development/production/test
 - System RAM → Low RAM warning (<16GB total or <4GB available)
 - Running processes → dev/build server status
 
+The dotenv files are read from the WORKSPACE (not from the current working
+directory), the template files (`.env.example`, `.env.sample`,
+`.env.template`, ...) are ignored and a file bigger than 256 kB is not read.
+A value that is not provably harmless is masked (`<set>`): only the
+`NODE_ENV` of the process env and a value that IS the name of the mode are
+shown. A key that only looks like a branch (`BRANCH=production`) never
+decides the mode.
+
 **This info is shown in UI and delivered to agent context:**
 ```
-Workspace: DEVELOPMENT | dev server: running | build: not running (script available) | RAM: 10/16
+Workspace: ~/pi-harness-runtime | OS: Linux | mode: DEVELOPMENT (from AMOS_ENV in .env) | dev server: running | dev script: available | build script: available | RAM: 10/16
 ```
 
 The mode words are exactly what the detector emits: `DEVELOPMENT`, `PRODUCTION`,
-`TEST` or `UNKNOWN` (with its reason, e.g. `UNKNOWN (no explicit NODE_ENV)`).
-A dev/build script is a CAPABILITY, not a state: `not running (script available)`
-means the script exists, not that a server runs.
+`TEST` or `UNKNOWN` (with its reason, e.g.
+`UNKNOWN (no NODE_ENV or environment variable found)` or
+`UNKNOWN (AMOS_ENV in .env names no known mode)`). A known mode also
+names its source: `DEVELOPMENT (from AMOS_ENV in .env)`.
+A dev/build script is a CAPABILITY, not a state: `dev script: available` means
+the script exists, not that a server runs. The server state is separate and
+never claims more than it knows: `running`, `not detected` (a check ran and
+found nothing) or `not checked` (no check was possible, e.g. no `pgrep`).
+
+The OS is part of the line because it decides which command prints the
+working directory: `pwd` on Linux/macOS, `(pwd).Path` or `$pwd.Path` in
+PowerShell (the plain `pwd` there prints a "Path: " header), `cd` or
+`echo %cd%` in the Windows command prompt. The agent context names the
+command to use.
 
 **IMPORTANT Rules:**
 
 | State | Action |
 |-------|--------|
-| `Workspace: UNKNOWN (…)` | Explicitly ask user before build |
-| `Workspace: DEVELOPMENT` | Use `dev` mode, don't auto-build |
-| `Workspace: PRODUCTION` | Build allowed, but confirm with user |
+| `mode: UNKNOWN (…)` | Explicitly ask user before build |
+| `mode: DEVELOPMENT` | Use `dev` mode, don't auto-build |
+| `mode: PRODUCTION` | Build allowed, but confirm with user |
 | `Low RAM` | Never run parallel build + dev |
 | `Dev server running` | Reuse it, don't restart |
 
 **Decision flow:**
 ```
-Check process.env.NODE_ENV first
-Check .env file NODE_ENV second
+Check process.env.NODE_ENV first (it decides, also when it names no known mode)
+Check the .env and .env.* files of the workspace second
+  (NODE_ENV, then an environment shaped key whose value names a mode,
+   then any other environment shaped key)
+Only then an environment shaped key of the process env (e.g. AMOS_ENV)
 Presence of dev script = capability, not proof of mode
 UNKNOWN requires investigation, not auto-build
 Production detection ≠ deployment authorization

package/harness/startup-report.ts

@@ -59,7 +59,10 @@ export function oneLineError(error: unknown, maxLength = 160): string {
 			"$1<redacted>",
 		)
 		// A url path: "/bot123456:ABC-DEF/", "/token/abc12345".
-		.replace(/\bbot\d{4,}:[A-Za-z0-9_\-]{4,}/g, "<redacted>")
+		// The boundary is "not a digit" and not a word boundary, so a
+		// token that is glued to a word ("xbot123:ABC-DEF") is redacted
+		// as well.
+		.replace(/(^|[^0-9])\d{6,}:[A-Za-z0-9_\-]{4,}/g, "$1<redacted>")
 		.replace(
 			/(\/((?:access_token|api[-_]?key|token|secret)[=/]))[A-Za-z0-9_\-:]{4,}/gi,
 			"$1<redacted>",
@@ -177,6 +180,21 @@ export function lineConfigurationReport(options: {
 	telegramConfigured?: boolean;
 	/** The fix commands for the missing LINE credentials. */
 	fixes: string[];
+	/**
+	 * The fix commands for the channel access token only.
+	 *
+	 * The startup check validates the ACCESS TOKEN. The user id is only the
+	 * recipient of the messages, so a failed check must not point at
+	 * line-user-id.txt.
+	 */
+	accessTokenFixes?: string[];
+	/**
+	 * Why the channel did not start (from the adapter).
+	 *
+	 * It says WHICH problem it is - an invalid or revoked token, a LINE API
+	 * failure or a network failure - and it never contains a credential.
+	 */
+	channelDiagnostic?: string | null;
 }): StartupReport | null {
 	if (!options.clientKeyFilePresent) return null;
 	const channelState = options.channelState ?? "not-started";
@@ -204,15 +222,27 @@ export function lineConfigurationReport(options: {
 		}
 		if (channelState === "failed") {
 			// The credentials are there but the channel did not start - the
-			// credentials themselves are the likely cause.
+			// channel access token is what the startup check validates, so
+			// the user id must not be named as the cause.
+			const details = [
+				...(options.accessTokenFixes && options.accessTokenFixes.length > 0
+					? options.accessTokenFixes
+					: options.fixes),
+			];
+			if (options.channelDiagnostic) {
+				details.push(options.channelDiagnostic);
+			}
+			details.push(
+				"The startup check validates the channel access token - the user id is only the recipient of the messages.",
+			);
+			details.push(
+				"Fix the file, then reload Pi so the channel is checked again.",
+			);
 			return {
 				label: "LINE",
 				text: "configured but the LINE channel did not start",
 				status: "warn",
-				details: [
-					...options.fixes,
-					"Check the LINE credentials in ~/.pi-harness-runtime/keys/, then reload Pi.",
-				],
+				details,
 			};
 		}
 		// The credentials are there but the channel was never started in this

package/harness/telegram-auth.ts

@@ -90,6 +90,38 @@ export function getAllowedUserIds(): Set<number> {
 	return new Set();
 }
 
+/**
+ * Describe who may write into Pi through Telegram.
+ *
+ * The allow-list falls back to the chat id file, and a GROUP chat id is
+ * negative - it identifies a chat, not a person. A sender rule that only
+ * knows a group id lets nobody in, silently. The description makes that
+ * visible.
+ */
+export function describeInboundAccess(
+	allowedUserIds: Iterable<number>,
+	chatId?: string,
+): string {
+	const ids = [...allowedUserIds].filter((n) => Number.isFinite(n));
+	const users = ids.filter((n) => n > 0);
+	const groups = ids.filter((n) => n < 0);
+	if (users.length === 0) {
+		const known = groups.length > 0 ? ` (the allow-list holds the group chat id ${groups.join(", ")})` : "";
+		return `nobody may write in${known}`;
+	}
+	const chat = chatId ? ` in chat ${chatId}` : "";
+	return `user id(s) ${users.join(", ")} may write in${chat}`;
+}
+
+/**
+ * Decide whether a Telegram sender may write into Pi.
+ *
+ * The rule itself lives in the notification package
+ * (packages/notification/src/telegram-auth.ts) so that the adapter, this
+ * module and the remote webhook server all use ONE implementation.
+ */
+export { isAuthorizedTelegramSender } from "../packages/notification/dist/telegram-auth.js";
+
 /**
  * Check if a Telegram user ID is authorized
  */

package/harness/telegram-update.ts

@@ -0,0 +1,125 @@
+/**
+ * Map a relay "telegram_message" payload onto a Telegram update.
+ *
+ * The mapping lives in a pure module so that it can be tested without the
+ * harness: the relay carries the text, the adapter decides whether the
+ * sender is allowed to write in.
+ *
+ * Rules:
+ *  - the text is never put into an id field (ids are logged by the client)
+ *  - the real bot flag has to survive the transport, otherwise the adapter
+ *    could not refuse bot messages
+ *  - a payload without text produces no update
+ */
+
+export interface TelegramMessageUpdate {
+	message: {
+		message_id: number;
+		from: {
+			id: number;
+			is_bot: boolean;
+			first_name: string;
+			username?: string;
+		};
+		chat: { id: number };
+		text: string;
+	};
+}
+
+export interface TelegramMessagePayload {
+	userId: number;
+	username?: string;
+	messageId?: number;
+	chatId?: number;
+	text?: string;
+	isBot?: boolean;
+}
+
+export interface TelegramCallbackUpdate {
+	callback_query: {
+		id: string;
+		from: {
+			id: number;
+			is_bot: boolean;
+			first_name: string;
+			username?: string;
+		};
+		data: string;
+		message: {
+			chat: { id: number };
+			message_id: number;
+		};
+	};
+}
+
+/**
+ * Build the Telegram update for a relayed button callback.
+ *
+ * The real bot flag has to survive the transport: the adapter refuses
+ * messages and callbacks of a bot.
+ */
+export function buildTelegramCallbackUpdate(
+	payload: TelegramMessagePayload & {
+		action?: string;
+		targetId?: string;
+		callbackQueryId?: string;
+		id?: string;
+	},
+): TelegramCallbackUpdate | null {
+	const userId = Number(payload.userId);
+	if (!Number.isFinite(userId)) return null;
+	const chatId = Number(payload.chatId);
+	const effectiveChatId = Number.isFinite(chatId) ? chatId : userId;
+	return {
+		callback_query: {
+			id: payload.callbackQueryId || String(payload.id || ""),
+			from: {
+				id: userId,
+				is_bot: payload.isBot === true,
+				first_name: payload.username || "User",
+				username: payload.username,
+			},
+			data: `${payload.action || ""}:${payload.targetId || ""}`,
+			message: {
+				chat: { id: effectiveChatId },
+				message_id: Number(payload.messageId) || 0,
+			},
+		},
+	};
+}
+
+/**
+ * Build the Telegram update for a relayed text message.
+ *
+ * Returns null when the payload carries no text - there is nothing to
+ * forward and the adapter must not see an empty message.
+ */
+export function buildTelegramMessageUpdate(
+	payload: TelegramMessagePayload,
+): TelegramMessageUpdate | null {
+	const text = payload.text ?? "";
+	if (!text) return null;
+
+	const userId = Number(payload.userId);
+	if (!Number.isFinite(userId)) return null;
+
+	// A direct message has the chat id of the user; the remote always sends
+	// the real chat id, so the fallback is only for a DM.
+	const chatId = Number(payload.chatId);
+	const effectiveChatId = Number.isFinite(chatId) ? chatId : userId;
+
+	return {
+		message: {
+			message_id: Number(payload.messageId) || 0,
+			from: {
+				id: userId,
+				// The real flag: the adapter refuses bot messages.
+				is_bot: payload.isBot === true,
+				first_name: payload.username || "User",
+				username: payload.username,
+			},
+			chat: { id: effectiveChatId },
+			text,
+		},
+	};
+}

package/index.ts

@@ -28,6 +28,8 @@ import {
 	type KeyFileAuditResult,
 } from "./harness/key-file-audit.ts";
 import { renderDetailLines } from "./harness/startup-lines.ts";
+import { describeInboundAccess, getAllowedUserIds } from "./harness/telegram-auth.ts";
+import { buildTelegramCallbackUpdate, buildTelegramMessageUpdate } from "./harness/telegram-update.ts";
 import {
 	jevMissingKeyReport,
 	lineConfigurationReport,
@@ -163,6 +165,15 @@ let keyFileAuditDone = false;
  * startup line must not claim a green "configured".
  */
 let lineChannelState: "started" | "failed" | "not-started" = "not-started";
+/**
+ * Why the LINE channel did not start (from the adapter).
+ *
+ * The adapter knows the difference between an invalid or revoked token
+ * (401/403), a LINE API failure and a network failure - the startup
+ * summary shows it so the user knows what to fix. It never contains a
+ * credential.
+ */
+let lineChannelDiagnostic: string | null = null;
 let telegramChannelState: "started" | "failed" | "not-started" = "not-started";
 /** Did the relay client connect at least once in this extension load? */
 let relayStreamConnected = false;
@@ -1355,6 +1366,7 @@ async function initTelegram(pi: ExtensionAPI): Promise<void> {
 			return;
 		}
 
+		const allowedUserIds = [...getAllowedUserIds()];
 		const channels: Array<{
 			id: string;
 			type: string;
@@ -1365,10 +1377,27 @@ async function initTelegram(pi: ExtensionAPI): Promise<void> {
 				id: "telegram",
 				type: "telegram",
 				enabled: true,
-				config: { botToken, chatId },
+				config: { botToken, chatId, allowedUserIds },
 			},
 		];
 
+		// Who may write into Pi? A group chat id is not a user id: when the
+		// allow-list holds only a group id, the inbound path is closed - and
+		// that must be visible, not silent.
+		const inboundAccess = describeInboundAccess(allowedUserIds, chatId);
+		logStartup(`[pi-harness] Telegram inbound: ${inboundAccess}`);
+		if (inboundAccess.startsWith("nobody")) {
+			addHarnessMessage(
+				"Telegram",
+				"nobody may write in: the allow-list holds no user id",
+				"warn",
+				[
+					"Write your Telegram user id into ~/.pi-harness-runtime/keys/telegram-allowed-users.txt (a chat id of a group is not a user id).",
+					"Then reload Pi.",
+				],
+			);
+		}
+
 		// Add LINE channel if credentials exist
 		const lineChannelConfigured = Boolean(hasLineCredentials && lineAccessToken && lineUserId);
 		if (lineChannelConfigured) {
@@ -1398,9 +1427,13 @@ async function initTelegram(pi: ExtensionAPI): Promise<void> {
 		if (lineChannelConfigured) {
 			if (center.isChannelHealthy("line")) {
 				lineChannelState = "started";
+				lineChannelDiagnostic = null;
 				addHarnessMessage("LINE", "configured and enabled (tap Toggle LINE to disable)", "ok");
 			} else {
 				lineChannelState = "failed";
+				// Keep the reason: "the token is wrong" and "LINE is down"
+				// need different actions.
+				lineChannelDiagnostic = center.getChannelDiagnostic("line");
 			}
 		}
 		if (telegramChannelState !== "started") {
@@ -1574,7 +1607,9 @@ async function initTelegram(pi: ExtensionAPI): Promise<void> {
 				return;
 			}
 			
-			logToFile("[TelegramInbound]", `Forwarding message to Pi: "${text.slice(0, 50)}..."`);
+			// The user's own words stay out of the log files: only the length
+			// is recorded.
+			logToFile("[TelegramInbound]", `Forwarding message to Pi (${text.length} chars)`);
 			// Forward the message to Pi as a user message
 			await pi.sendUserMessage(text, { deliverAs: "steer" });
 		});
@@ -1631,7 +1666,32 @@ async function initTelegram(pi: ExtensionAPI): Promise<void> {
 			]);
 			return;
 		}
-		telegram?.startPolling();
+		// Polling and the remote webhook are mutually exclusive. Telegram
+		// rejects getUpdates while a webhook is active, and the rejected poll
+		// also terminates the getUpdates stream of every other poller of this
+		// bot, which delayed the inbound text messages by seconds.
+		if (telegram) {
+			// A 409 (a webhook or another poller owns this bot) stops the
+			// inbound path. The user must see it - a silent 409 looks like a
+			// working inbound path.
+			telegram.onPollStopped = (reason) => {
+				addHarnessMessage("Telegram", `inbound polling stopped: ${reason}`, "warn", [
+					"Telegram rejects getUpdates (409) while a webhook or another poller owns this bot.",
+					"Stop the other poller of this bot (or remove the remote webhook), then reload Pi.",
+				]);
+			};
+			if (!telegram.isWebhookConfigured()) {
+				telegram.startPolling();
+				// The poll may already have been rejected (a 409 fires the
+				// callback above); make the reason visible either way.
+				const stopReason = telegram.getPollStopReason();
+				if (stopReason) {
+					addHarnessMessage("Telegram", `inbound polling stopped: ${stopReason}`, "warn", [
+						"Stop the other poller of this bot (or remove the remote webhook), then reload Pi.",
+					]);
+				}
+			}
+		}
 		if (!telegram?.isGreetingVerified()) {
 			addHarnessMessage("Telegram", "Hi sent; tap Say Hi to verify inbound (tap Toggle Telegram to disable)", "wait");
 		}
@@ -1795,8 +1855,15 @@ function reportLineConfiguration(): void {
 		channelState: lineChannelState,
 		telegramConfigured: telegramIsConfigured(),
 		// The fallback makes sure that a warning always carries a command,
-		// even when the audit could not answer.
-		fixes: keyFileFixesOrFallback("LINE", ["channel access token", "user id"]),
+		// even when the audit could not answer. It names the ACCESS TOKEN
+		// only - the user id is the recipient of the messages, not the cause
+		// of a failed startup check.
+		fixes: keyFileFixesOrFallback("LINE", ["channel access token"]),
+		// The startup check validates the access token - the user id is only
+		// the recipient, so it must not be named as the cause.
+		accessTokenFixes: keyFileFixesOrFallback("LINE", ["channel access token"]),
+		// The reason the channel did not start (invalid token, LINE down, ...).
+		channelDiagnostic: lineChannelDiagnostic,
 		// Without Telegram the LINE channel cannot start - the user needs
 		// the Telegram commands, not only an explanation.
 		telegramFixes: keyFileFixesOrFallback("Telegram", ["bot token", "chat id"]),
@@ -1911,33 +1978,57 @@ async function initRelayStream(): Promise<void> {
 				logToFile("[RelayStream]", "Synchronized - receiving live events");
 			},
 			onCallback: async (callback: CallbackPayload) => {
-				logToFile("[RelayStream]", `Callback: ${callback.action} ${callback.targetId}`);
+				logToFile(
+					"[RelayStream]",
+					callback.type === "telegram_message"
+						? `Message from ${callback.username || callback.userId} (${(callback.text || "").length} chars)`
+						: `Callback: ${callback.action} ${callback.targetId}`,
+				);
 
 				// Forward Telegram callbacks to the adapter
 				if (callback.type === "telegram_callback" && _relayTelegramAdapter) {
-					// Convert relay callback to Telegram update format
-					const update = {
-						callback_query: {
-							id: callback.callbackQueryId || String(callback.id),
-							from: {
-								id: callback.userId,
-								is_bot: false,
-								first_name: callback.username || "User",
-								username: callback.username,
-							},
-							data: `${callback.action}:${callback.targetId}`,
-							message: {
-								chat: { id: callback.chatId || callback.userId },
-								message_id: callback.messageId || 0,
-							},
-						},
-					};
+					// The mapping is a pure function (harness/telegram-update.ts) so
+					// that it can be tested without the harness.
+					const update = buildTelegramCallbackUpdate({
+						id: callback.id,
+						action: callback.action,
+						targetId: callback.targetId,
+						callbackQueryId: callback.callbackQueryId,
+						userId: callback.userId,
+						username: callback.username,
+						messageId: callback.messageId,
+						chatId: callback.chatId,
+						isBot: callback.isBot,
+					});
+					if (update) {
+						try {
+							await _relayTelegramAdapter.handleWebhookUpdate(update);
+							logToFile("[RelayStream]", "Callback processed by Telegram adapter");
+						} catch (err) {
+							logToFile("[RelayStream]", `Adapter error: ${oneLineError(err)}`);
+						}
+					}
+				}
 
-					try {
-						await _relayTelegramAdapter.handleWebhookUpdate(update);
-						logToFile("[RelayStream]", "Callback processed by Telegram adapter");
-					} catch (err) {
-						logToFile("[RelayStream]", `Adapter error: ${err}`);
+				// Forward a Telegram TEXT message (the user typed it) to the adapter
+				if (callback.type === "telegram_message" && _relayTelegramAdapter) {
+					// The mapping is a pure function (harness/telegram-update.ts) so
+					// that it can be tested without the harness.
+					const update = buildTelegramMessageUpdate({
+						userId: callback.userId,
+						username: callback.username,
+						messageId: callback.messageId,
+						chatId: callback.chatId,
+						text: callback.text,
+						isBot: callback.isBot,
+					});
+					if (update) {
+						try {
+							await _relayTelegramAdapter.handleWebhookUpdate(update);
+							logToFile("[RelayStream]", "Message processed by Telegram adapter");
+						} catch (err) {
+							logToFile("[RelayStream]", `Adapter error: ${oneLineError(err)}`);
+						}
 					}
 				}
 			},
@@ -2688,8 +2779,10 @@ const HARNESS_LOG_FILE = "/tmp/pi-harness.log";
 /** Log a harness message to file (not stderr - bypasses Pi's cursor tracking) */
 function logToFile(...parts: string[]): void {
 	const msg = parts.join(" ");
+	// A timestamp makes the log usable for latency measurements.
+	const stamp = new Date().toISOString();
 	try {
-		appendFileSync(HARNESS_LOG_FILE, msg + "\n");
+		appendFileSync(HARNESS_LOG_FILE, `[${stamp}] ${msg}\n`);
 	} catch {
 		// Ignore file write errors
 	}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-harness-runtime",
-  "version": "1.1.390",
+  "version": "1.1.392",
   "description": "[BETA] Codex-style /usage status + autonomous coding harness for pi. Not production ready — expect breaking changes.",
   "type": "module",
   "scripts": {

package/packages/a2a-adapter/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi/a2a-adapter",
-  "version": "1.1.390",
+  "version": "1.1.392",
   "type": "module",
   "description": "Google Agent-to-Agent (A2A) protocol adapter for pi-harness",
   "main": "dist/index.js",

package/packages/agent-policy/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi/agent-policy",
-  "version": "1.1.390",
+  "version": "1.1.392",
   "description": "Agent policy runtime for pi-harness - enforces mandatory rule delivery and mutation gating",
   "type": "module",
   "main": "./dist/index.js",

package/packages/architecture-generator/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi-harness/architecture-generator",
-  "version": "1.1.390",
+  "version": "1.1.392",
   "description": "Generate ADR and Mermaid diagrams from project analysis",
   "type": "module",
   "main": "./dist/index.js",

package/packages/auth/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi-harness/auth",
-  "version": "1.1.390",
+  "version": "1.1.392",
   "description": "pi-harness-runtime — auth",
   "type": "module",
   "main": "./dist/index.js",

package/packages/autonomous-refactor/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi/autonomous-refactor",
-  "version": "1.1.390",
+  "version": "1.1.392",
   "type": "module",
   "description": "Autonomous refactoring engine",
   "main": "dist/index.js",

package/packages/autonomous-runtime/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi/autonomous-runtime",
-  "version": "1.1.390",
+  "version": "1.1.392",
   "description": "Autonomous Operations Runtime — task inbox, lease management, and worker lifecycle (RFC-0101)",
   "type": "module",
   "main": "./dist/index.js",

package/packages/cache-strategy/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi/cache-strategy",
-  "version": "1.1.390",
+  "version": "1.1.392",
   "type": "module",
   "description": "Smart caching with TTL and invalidation strategies (RFC-0022)",
   "main": "dist/index.js",

package/packages/capability-registry/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi-harness/capability-registry",
-  "version": "1.1.390",
+  "version": "1.1.392",
   "description": "Capability Registry for pi-harness-runtime — tracks model capabilities and enables capability-based routing",
   "type": "module",
   "main": "./dist/index.js",

package/packages/checkpoint/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi/checkpoint",
-  "version": "1.1.390",
+  "version": "1.1.392",
   "description": "Enhanced checkpoint system with incremental snapshots, diff-based storage, and recovery strategies",
   "type": "module",
   "main": "./dist/index.js",

package/packages/cli-plugin-sdk/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi/cli-plugin-sdk",
-  "version": "1.1.390",
+  "version": "1.1.392",
   "type": "module",
   "description": "CLI Plugin SDK for pi-harness — install, list, remove, update, invoke plugins",
   "main": "dist/index.js",

package/packages/clipboard/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi/clipboard",
-  "version": "1.1.390",
+  "version": "1.1.392",
   "type": "module",
   "main": "src/index.ts",
   "exports": {

package/packages/clipboard-plugin/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi/clipboard-plugin",
-  "version": "1.1.390",
+  "version": "1.1.392",
   "type": "module",
   "main": "src/index.ts",
   "exports": {

package/packages/code-generation/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi/code-generation",
-  "version": "1.1.390",
+  "version": "1.1.392",
   "description": "Code generation pipeline for pi-harness-runtime",
   "type": "module",
   "main": "./dist/index.js",