pi-harness-runtime 1.1.394 → 1.1.395

package/AGENTS.md

@@ -36,6 +36,56 @@ bd list --status pending
 
 **Why**: Agent often builds/commits without checking todos. This causes incomplete tasks to be forgotten.
 
+## Staged Validation & Test-Cost Discipline (CRITICAL)
+
+A task with a cheap tier and an expensive tier MUST use the cheap tier while the code is still changing. Repeating an expensive regression after every fix is the most common way an autonomous run burns an entire night.
+
+1. **Declare the tiers.** Put the plan in the todo metadata (`metadata.validationPlan`):
+
+   ```json
+   {
+     "metadata": {
+       "validationPlan": {
+         "fast": { "command": "bun test tests/fast", "expectedDurationMs": 18000, "datasetSize": 100 },
+         "full": { "command": "bun test tests/full", "expectedDurationMs": 2400000, "datasetSize": 10000 },
+         "budgetMinutes": 90,
+         "finalTierRequired": true
+       }
+     }
+   }
+   ```
+
+   The harness never guesses a tier from a command string. Without a declared plan the current behaviour is unchanged.
+
+2. **Iterate on the fast tier.** After every code edit, rerun the fast tier plus the focused unit/type checks the edit touches.
+
+3. **Run the full tier once.** Run the full tier as the final acceptance check, when the implementation and the fast tier are stable.
+
+4. **Do not repeat the full tier blindly.** Never rerun the full tier after an edit that cannot affect the behavior it covers. If it genuinely must be repeated, say why in one line.
+
+5. **Make the cost visible.** Report each validation run compactly: `[TEST] fast: bun test tests/fast - passed (18s, 100 records)`. A test that is not reported cannot be budgeted.
+
+6. **No false completion.** A todo whose `finalTierRequired` plan is set must not be marked completed while that tier is pending or failed. Pause instead and report what passed, what is pending, and why.
+
+7. **Respect the time budget.** `budgetMinutes` is a soft budget. When it is reached, stop at a safe boundary, report completed and skipped checks, and leave the work open. Never kill a destructive or non-interruptible test mid-run.
+
+8. **The fast tier must be representative.** A small fixture keeps the shape of the data (optional fields, relations, uniqueness, boundary values, aggregates under test), not just the row count. Use deterministic data with cleanup so repeated runs do not accumulate rows.
+
+9. **Record every tier run in the ledger.** The harness never runs the tests, so the run is recorded by whoever knows the result:
+
+   ```bash
+   bun scripts/validation-run.ts --item 12 --tier fast --status passed --duration 18s --dataset 100
+   bun scripts/validation-run.ts --item 12 --tier full --status passed --duration 41m -- "bun test tests/full"
+   ```
+
+   The ledger is plain NDJSON under `~/.pi-harness-runtime/logs/validation-runs.jsonl` (inspectable with `tail` or `jq`) and every record is mirrored into the central logging pipeline. The harness reads it to know which tier already passed, so an unreported run looks like a run that never happened.
+
+**What the harness does with the plan:**
+
+- The continuation message carries the plan, the recorded tier state and the remaining budget, so the agent never re-runs a tier that already passed.
+- When `budgetMinutes` is spent, the item pauses at a safe boundary: nothing is dispatched, the work stays open, and the reason is reported.
+- When a todo with `finalTierRequired` is marked complete while that tier is pending or failed, the completion report is suppressed and the item is named instead. A todo may not be reported as done on the strength of an unreported run.
+
 ## Versioning Convention
 
 **Only patch-level updates (`0.10.x`)** — no minor/major bumps until the app is fully functional.
@@ -502,6 +552,9 @@ bun run build && bun run start   # Server deployment
   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
+- The facts about the repository (only when NO variable names the environment
+  at all) → a published source repository without a runtime of its own is a
+  development checkout; a `develop`/`development` branch is the fallback
 - System RAM → Low RAM warning (<16GB total or <4GB available)
 - Running processes → dev/build server status
 
@@ -513,8 +566,26 @@ A value that is not provably harmless is masked (`<set>`): only the
 shown. A key that only looks like a branch (`BRANCH=production`) never
 decides the mode.
 
+**Session variables of a desktop are not environment selectors.**
+`GNOME_SHELL_SESSION_MODE`, `XDG_*`, `DESKTOP_*`, `DBUS_*`, ... name the
+desktop session, never the environment of a workspace. Some of them end in
+`_MODE` or `_ENV`, so they are excluded from the candidates by NAMESPACE,
+not by value: their value ("ubuntu", "wayland") says nothing about the mode.
+
+**The repository tier (last resort, never production).** It runs only when
+no variable names the environment at all. A published package (a
+`package.json` with a name, a version and declared content - `files`,
+`bin` or `publishConfig`) without a deployment configuration (no Dockerfile,
+compose file, Procfile, fly.toml, render.yaml, railway.json, vercel.json,
+netlify.toml, serverless.yml, app.yaml, pm2 ecosystem file, no deploy
+workflow) and without a running server is SOURCE CODE that the user runs on
+their own machine → `DEVELOPMENT (source-only repository)`. A branch named
+`develop` or `development` is the fallback → `DEVELOPMENT (git branch
+develop)`. A production branch is NEVER a development checkout, and this
+tier never claims production.
+
 **This info is shown in UI and delivered to agent context:**
-```
+```text
 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
 ```
 
@@ -522,7 +593,8 @@ The mode words are exactly what the detector emits: `DEVELOPMENT`, `PRODUCTION`,
 `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)`.
+names its source: `DEVELOPMENT (from AMOS_ENV in .env)` or
+`DEVELOPMENT (source-only repository)`.
 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
@@ -545,12 +617,15 @@ command to use.
 | `Dev server running` | Reuse it, don't restart |
 
 **Decision flow:**
-```
+```text
 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)
+Only then the facts about the repository
+  (a published source repository without a runtime of its own,
+   or a develop/development branch)
 Presence of dev script = capability, not proof of mode
 UNKNOWN requires investigation, not auto-build
 Production detection ≠ deployment authorization
@@ -561,3 +636,50 @@ Production detection ≠ deployment authorization
 ```
 ~/.pi-harness-runtime/workspace-env.sqlite
 ```
+
+## Centralized Application Logging
+
+All application logs can be shipped to **Cloudflare R2** (durable archive) and to the
+**unified webhook server** (live path). The pipeline lives in `packages/logging`
+(`@pi-harness/logging`); the harness uses the process-wide singleton from it.
+
+**Delivery order** (first success wins, the rest are skipped):
+
+```text
+producer -> redact -> sample -> buffer -> R2 -> webhook -> local spool (~/.pi-harness-runtime/logs/spool)
+```
+
+- The local spool is the fallback: if every transport fails the batch is written to
+  disk as NDJSON and re-shipped on the next successful flush. Nothing is lost, only delayed.
+- The local log files (`~/.pi-harness-runtime/logs/*.jsonl`, `harness/*.log`) stay the
+  source of truth. The centralized pipeline is a copy for the archive.
+
+**Configuration** (environment first, then `~/.pi-harness-runtime/keys/`):
+
+| Variable | Meaning | Default |
+|----------|---------|---------|
+| `PI_LOG_SINK` | `off` \| `auto` \| `r2` \| `webhook` \| `r2+webhook` | `auto` |
+| `PI_LOG_LEVEL` | Minimum level that is shipped | `info` |
+| `PI_LOG_SAMPLE_RATE` | Share of `debug` records kept (0..1) | `0.1` |
+| `PI_LOG_RATE_LIMIT` | Max records per source+event per minute | `60` |
+| `PI_LOG_BATCH_SIZE` | Records per batch | `100` |
+| `PI_LOG_BUFFER_SIZE` | Records held in memory | `1000` |
+| `PI_LOG_FLUSH_INTERVAL_MS` | Automatic flush interval | `15000` |
+| `PI_LOG_WEBHOOK_URL` | Ingest URL of the webhook server | unset |
+| `PI_LOG_WEBHOOK_TOKEN` | Bearer token for the ingest endpoint | unset |
+| `PI_LOG_R2_BUCKET` / `PI_LOG_R2_ENDPOINT` / `PI_LOG_R2_ACCESS_KEY_ID` / `PI_LOG_R2_SECRET_ACCESS_KEY` | R2 credentials | key files |
+| `PI_LOG_SPOOL_DIR` | Local spool directory | `~/.pi-harness-runtime/logs/spool` |
+
+R2 credentials are read from the key files `r2-bucket-name.txt`, `r2-endpoint.txt`,
+`r2-access-key-id.txt`, `r2-secret-access-key.txt` and `r2-account-id.txt`.
+
+**Rules for producers:**
+
+- Emit through the singleton: `centralInfo/centralWarn/centralError(source, event, message?, fields?)`.
+  The `source` identifies the component, the `event` is a dotted name.
+- Redaction is automatic (key names, credential patterns, truncation), but producers must
+  not pass user content: prompts, raw model output and message bodies are dropped by the
+  redactor, so shipping them is pointless.
+- Never put a credential in a log message. The redactor is a safety net, not a licence.
+- The webhook server exposes `POST /api/logs` for the ingest path. Set `LOG_INGEST_TOKEN`
+  to require a bearer token; the server re-redacts every batch and relays it to R2.

package/harness/glm-quota-logger.ts

@@ -15,6 +15,8 @@
 import { appendFileSync, existsSync, mkdirSync } from "node:fs";
 import { join } from "node:path";
 import { homedir } from "node:os";
+// Centralized pipeline (R2 / webhook) - a copy of the local log.
+import { centralError, centralInfo, centralWarn } from "../packages/logging/dist/index.js";
 
 export type LogLevel = "INFO" | "WARN" | "ERROR";
 
@@ -55,6 +57,21 @@ function writeLog(
 		// Non-fatal - just log to console
 		console.error(`[GLMQuotaLogger] Failed to write log: ${message}`);
 	}
+
+	// Ship a copy to the centralized pipeline. The job id is an identifier,
+	// not content, so it is safe to include.
+	try {
+		const fields = { jobId: jobId ?? "system" };
+		if (level === "ERROR") {
+			centralError("harness.glm-quota", "quota", message, fields);
+		} else if (level === "WARN") {
+			centralWarn("harness.glm-quota", "quota", message, fields);
+		} else {
+			centralInfo("harness.glm-quota", "quota", message, fields);
+		}
+	} catch {
+		// Logging must never break the quota flow
+	}
 }
 
 // --- Public API ---

package/harness/langchain/planner-logger.ts

@@ -14,6 +14,8 @@
 import { mkdirSync, appendFileSync, existsSync } from "node:fs";
 import { join } from "node:path";
 import { homedir } from "node:os";
+// Centralized pipeline (R2 / webhook) - a copy of the local log.
+import { centralInfo } from "../../packages/logging/dist/index.js";
 
 export interface PlannerDecision {
 	timestamp: string;
@@ -179,6 +181,19 @@ export async function logPlannerDecision(decision: PlannerLogEntry): Promise<voi
 	appendFileSync(LOG_FILE, fileLog);
 	console.log(fileLog);
 
+	// Ship a copy to the centralized pipeline. Only the decision itself is
+	// shipped - the request and the raw planner output stay local.
+	try {
+		centralInfo("harness.planner", "decision", undefined, {
+			provider: decision.provider,
+			escalate: decision.escalate,
+			escalateReason: decision.escalateReason,
+			userInputType: decision.userInput?.type ?? null,
+		});
+	} catch {
+		// Logging must never break the planner flow
+	}
+
 	// Send to Telegram (async, non-blocking for main flow)
 	const telegramMsg = formatTelegramMessage(decision);
 	// Fire-and-forget: don't await, let it run in background

package/harness/service-diagnostics.ts

@@ -8,6 +8,9 @@
 import { appendFileSync, existsSync, mkdirSync } from "node:fs";
 import { join } from "node:path";
 import { homedir } from "node:os";
+// Centralized pipeline (R2 / webhook). The local JSONL file stays the
+// source of truth; the shipper is a copy for the archive.
+import { centralError, centralInfo, centralWarn } from "../packages/logging/dist/index.js";
 
 export type ServiceLevel = "info" | "warn" | "error" | "debug";
 export type ServiceName = "jev" | "honcho" | "qdrant";
@@ -41,16 +44,44 @@ function ensureLogDir(): void {
  * Sensitive fields (keys, tokens, full content) are never logged.
  */
 export function logServiceEvent(event: ServiceEvent): void {
+	let safeEvent: Record<string, unknown> = { ...event };
 	try {
 		ensureLogDir();
 
 		// Redact sensitive fields
-		const safeEvent = redactSensitive(event);
+		safeEvent = redactSensitive(event);
 
 		appendFileSync(LOG_FILE, JSON.stringify(safeEvent) + "\n");
 	} catch {
 		// Silently fail if logging fails - don't crash the service
 	}
+
+	shipServiceEvent(safeEvent);
+}
+
+/**
+ * Send a service event to the centralized pipeline.
+ *
+ * The event was already redacted above; the shipper redacts again, which
+ * is cheap and keeps the guarantee local to one place.
+ */
+function shipServiceEvent(event: Record<string, unknown>): void {
+	try {
+		const level = typeof event.level === "string" ? event.level : "info";
+		const fields: Record<string, unknown> = { ...event };
+		delete fields.level;
+		delete fields.ts;
+
+		if (level === "error") {
+			centralError("harness.service-diagnostics", String(event.operation ?? "event"), undefined, fields);
+		} else if (level === "warn") {
+			centralWarn("harness.service-diagnostics", String(event.operation ?? "event"), undefined, fields);
+		} else {
+			centralInfo("harness.service-diagnostics", String(event.operation ?? "event"), undefined, fields);
+		}
+	} catch {
+		// Never let shipping break the service
+	}
 }
 
 /**

package/index.ts

@@ -100,6 +100,10 @@ import {
 	hasPaperclipConfig,
 	PaperclipWatcher,
 } from "./packages/paperclip-integration/dist/index.js";
+// Centralized application logging: R2 (durable archive) + webhook (live),
+// with a local spool as the fallback. Optional - without credentials the
+// logs simply stay local.
+import { centralInfo, initCentralLogging } from "./packages/logging/dist/index.js";
 
 // --- Jev Auto-Continue: Agent autonomous decision-making --------------------
 // Lazy import - only loads when packages/jev-judge exists and API key available
@@ -642,12 +646,29 @@ async function initAutoContinue(pi: ExtensionAPI): Promise<void> {
 
 				// Get task context from local todo controller (not bd)
 				const snapshot = await (todoContinuationController?.getSnapshot() ?? Promise.resolve({ items: [] }));
+				// An item whose final tier is still pending is NOT done, even when
+				// it is already marked completed. The judge must see it as
+				// remaining work, otherwise the session ends on a false
+				// completion.
+				const pendingFinalTier = validationLedger
+					? snapshot.items.filter((item) => validationLedger?.isFinalTierPending(item))
+					: [];
+				const pendingFinalTierIds = new Set(pendingFinalTier.map((item) => item.id));
+				if (pendingFinalTier.length > 0) {
+					logToFile(
+						"[auto-continue]",
+						"Final tier still pending for:",
+						pendingFinalTier.map((item) => `${item.id}:${item.subject}`).join(", "),
+					);
+				}
 				const taskContext = {
 					completed: snapshot.items
-					.filter((item: { status?: string; subject?: string }) => item.status === "completed")
+					.filter((item: { id?: number; status?: string; subject?: string }) =>
+						item.status === "completed" && !(item.id !== undefined && pendingFinalTierIds.has(item.id)))
 					.map((item: { status?: string; subject?: string }) => item.subject ?? ""),
 					remaining: snapshot.items
-					.filter((item: { status?: string; subject?: string }) => item.status !== "completed")
+					.filter((item: { id?: number; status?: string; subject?: string }) =>
+						item.status !== "completed" || (item.id !== undefined && pendingFinalTierIds.has(item.id)))
 					.map((item: { status?: string; subject?: string }) => item.subject ?? ""),
 					total: snapshot.items.length,
 				};
@@ -729,11 +750,35 @@ async function initAutoContinue(pi: ExtensionAPI): Promise<void> {
 
 		// --- todo continuation: Retain one controller per session ----------
 		let todoContinuationController: import("./packages/jev-judge/dist/continuation-controller.js").TodoContinuationController | null = null;
+		// Ledger of the validation runs: it is the only mechanical source for
+		// "did the final tier pass?" and therefore guards the completion report.
+		let validationLedger: import("./packages/jev-judge/dist/validation-ledger.js").ValidationLedger | null = null;
 
 		// Create controller on session_start with proper dispatch callback
 		pi.on("session_start", async (_event, ctx) => {
 			try {
 				const { TodoContinuationController } = await import("./packages/jev-judge/dist/continuation-controller.js");
+				const { ValidationLedger } = await import("./packages/jev-judge/dist/validation-ledger.js");
+				// The ledger records which validation tier ran. The controller
+				// uses it to tell the agent what already passed and whether the
+				// final tier is still pending.
+				validationLedger = new ValidationLedger({
+					onRecord: (record) => {
+						centralInfo(
+							"validation",
+							"tier.run",
+							`${record.tier} tier ${record.status}`,
+							{
+								itemId: record.itemId,
+								tier: record.tier,
+								status: record.status,
+								durationMs: record.durationMs,
+								datasetSize: record.datasetSize,
+								command: record.command,
+							},
+						);
+					},
+				});
 				// SAFETY: ctx is ExtensionContext with sessionManager, isIdle, hasPendingMessages
 				// dispatch uses pi.sendUserMessage for actual message delivery
 				todoContinuationController = new TodoContinuationController(
@@ -742,6 +787,7 @@ async function initAutoContinue(pi: ExtensionAPI): Promise<void> {
 						dispatch: async (content: string) => {
 							await pi.sendUserMessage(content, { deliverAs: "steer" });
 						},
+						validationLedger,
 					}
 				);
 				logToFile("[auto-continue]", "Todo continuation controller initialized");
@@ -988,6 +1034,26 @@ async function initAutoContinue(pi: ExtensionAPI): Promise<void> {
 						const isNoPendingTasks = reason === "No pending tasks";
 
 						if (isNoPendingTasks) {
+							// A todo whose final tier is still pending must not be
+							// reported as complete. The item may already be marked
+							// completed by the agent - the ledger is the check that
+							// catches it.
+							const snapshot = await todoContinuationController.getSnapshot();
+							const pendingFinalTier = validationLedger
+								? snapshot.items.filter((item) => validationLedger?.isFinalTierPending(item))
+								: [];
+							if (pendingFinalTier.length > 0) {
+								const details = pendingFinalTier
+									.map((item) => `${item.id}:${item.subject}`)
+									.join(", ");
+								logToFile(
+									"[auto-continue]",
+									"Completion suppressed - final tier still pending for:",
+									details,
+								);
+								updateAutoContinueStatus("ERROR", "final tier pending");
+								return;
+							}
 							// Check if there's a pending question - suppress completion if so
 							if (pqController.hasPendingQuestion()) {
 								logToFile("[auto-continue]", "Suppressing completion - pending question exists");
@@ -1005,7 +1071,6 @@ async function initAutoContinue(pi: ExtensionAPI): Promise<void> {
 							_completedNotifiedFor = completionKey;
 
 							// Get full todo list for notification
-							const snapshot = await todoContinuationController.getSnapshot();
 							const todoList = snapshot.items
 								.map((item) => {
 									const status = item.status === "completed" ? "[DONE]" : "[PENDING]";
@@ -2883,6 +2948,14 @@ function logToFile(...parts: string[]): void {
 	} catch {
 		// Ignore file write errors
 	}
+
+	// Mirror the line into the centralized pipeline. The sampler keeps the
+	// volume bounded; the local file above stays the source of truth.
+	try {
+		centralInfo("harness", "log", msg);
+	} catch {
+		// Logging must never break the caller.
+	}
 }
 
 /** Log a harness startup message to file and track for UI */
@@ -3330,6 +3403,22 @@ export default async function (pi: ExtensionAPI) {
 	const mirrorStore = new MirrorStore();
 	ensureHarnessDir();
 
+	// --- central-logging: ship structured logs to R2 / the webhook server ---
+	// The pipeline is opt-in by configuration, never by code: without R2
+	// credentials and without a webhook URL nothing leaves the machine.
+	try {
+		const logConfig = initCentralLogging();
+		if (logConfig?.enabled) {
+			logToFile(
+				"[CentralLogging]",
+				"enabled -",
+				logConfig.notes.length > 0 ? logConfig.notes.join("; ") : "no transport configured",
+			);
+		}
+	} catch (e) {
+		logToFile("[CentralLogging]", "init failed:", String(e));
+	}
+
 	// Collect async init promises so we can wait for them before showing startup notification
 	const asyncInitPromises: Promise<unknown>[] = [];
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-harness-runtime",
-  "version": "1.1.394",
+  "version": "1.1.395",
   "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.394",
+  "version": "1.1.395",
   "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.394",
+  "version": "1.1.395",
   "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.394",
+  "version": "1.1.395",
   "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.394",
+  "version": "1.1.395",
   "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.394",
+  "version": "1.1.395",
   "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.394",
+  "version": "1.1.395",
   "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.394",
+  "version": "1.1.395",
   "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.394",
+  "version": "1.1.395",
   "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.394",
+  "version": "1.1.395",
   "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.394",
+  "version": "1.1.395",
   "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.394",
+  "version": "1.1.395",
   "type": "module",
   "main": "src/index.ts",
   "exports": {

package/packages/clipboard-plugin/package.json

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

package/packages/code-generation/package.json

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

package/packages/code-review/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi/code-review",
-  "version": "1.1.394",
+  "version": "1.1.395",
   "description": "Automated code review engine for pi-harness-runtime",
   "type": "module",
   "main": "./dist/index.js",

package/packages/codex-adapter/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi/codex-adapter",
-  "version": "1.1.394",
+  "version": "1.1.395",
   "type": "module",
   "description": "OpenAI Codex provider adapter for pi-harness",
   "main": "dist/index.js",

package/packages/codex-watcher/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi-harness/codex-watcher",
-  "version": "1.1.394",
+  "version": "1.1.395",
   "description": "Watches Codex CLI sessions and emits visible messages for PING-PONG monitoring",
   "type": "module",
   "main": "./dist/src/index.js",

package/packages/config-capture/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@moocoding/config-capture",
-  "version": "1.1.394",
+  "version": "1.1.395",
   "description": "Auto-capture API-fetched configuration values to AGENTS.md",
   "type": "module",
   "main": "src/index.ts",

package/packages/connection-runtime/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi-harness/connection-runtime",
-  "version": "1.1.394",
+  "version": "1.1.395",
   "type": "module",
   "description": "Connection management with jittered exponential backoff for pi-harness",
   "main": "./dist/index.js",

package/packages/context-compiler/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi/context-compiler",
-  "version": "1.1.394",
+  "version": "1.1.395",
   "description": "Bounded context selection engine for pi-harness-runtime",
   "type": "module",
   "main": "./dist/index.js",

package/packages/context-discovery/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi/context-discovery",
-  "version": "1.1.394",
+  "version": "1.1.395",
   "type": "module",
   "main": "src/index.ts",
   "exports": {

package/packages/context-manager/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pi-harness/context-manager",
-  "version": "1.1.394",
+  "version": "1.1.395",
   "description": "Context Window Manager — prevents model context overflow via compaction and resume prompts (RFC-0010)",
   "type": "module",
   "main": "./dist/index.js",