@kici-dev/compiler 0.7.0 → 0.8.0

package/dist/cli.js

@@ -7,7 +7,7 @@ import { realpathSync } from "node:fs";
 import { Argument, Command } from "commander";
 import pc from "picocolors";
 //#region src/cli.ts
-const version = "0.7.0";
+const version = "0.8.0";
 /**
 * Top-level commands that were removed, mapped to their current equivalent.
 * Consulted when the CLI hits an unknown command so the user gets a precise
@@ -312,7 +312,7 @@ Environment variables:
 		],
 		[
 			"logs",
-			"Print the local dev plane orchestrator log path",
+			"Print the local dev plane log paths and rotation policy",
 			"localLogsCommand"
 		],
 		[

package/dist/commands/local.d.ts

@@ -5,7 +5,7 @@
  * orchestrator plus a local Postgres (embedded, with a podman fallback) that
  * `kici run --local` dispatches through. `up` boots or reuses the plane,
  * `status` reports it plus the control commands, `down` stops it, and `logs`
- * prints the orchestrator log path.
+ * prints the plane log paths and rotation policy.
  */
 import type { PlaneStatus, PlaneMode } from '../local-plane/plane-manager.js';
 import type { PlaneState } from '../local-plane/plane-liveness.js';
@@ -52,7 +52,14 @@ export declare function localStatusCommand(options?: {
 }): Promise<boolean>;
 /** Stop the local dev plane, reporting success only once the port is released. */
 export declare function localDownCommand(): Promise<boolean>;
-/** Print the local dev plane orchestrator log path. */
+/**
+ * Print the local dev plane orchestrator log path, plus the rotation policy.
+ *
+ * The path is the only line this command writes to stdout — the policy note
+ * goes to stderr — so a caller reading stdout never has to strip prose from
+ * it. The CLI version banner still precedes it, as for every command, so
+ * `$(kici local logs)` is NOT a bare path: read the last stdout line.
+ */
 export declare function localLogsCommand(): Promise<boolean>;
 /**
  * Attach the local dev plane to the hosted Platform so `kici run --local` uses

package/dist/commands/local.js

@@ -1,5 +1,6 @@
 import "../rolldown-runtime-ClRpJifh.js";
 import { loadGlobalConfig } from "../remote/config.js";
+import "../local-plane/plane-log.js";
 import { attachPlane, detachPlane, planeDown, planeLogPath, planeStatus } from "../local-plane/plane-manager.js";
 import { resolvePlaneForRun } from "../local-plane/resolve-plane.js";
 import pc from "picocolors";
@@ -12,14 +13,14 @@ import { toErrorMessage } from "@kici-dev/core";
 * orchestrator plus a local Postgres (embedded, with a podman fallback) that
 * `kici run --local` dispatches through. `up` boots or reuses the plane,
 * `status` reports it plus the control commands, `down` stops it, and `logs`
-* prints the orchestrator log path.
+* prints the plane log paths and rotation policy.
 */
 /** Print the control commands a user needs once the plane is running. */
 function printControlHints() {
 	console.log("");
 	console.log(pc.dim("Control commands:"));
 	console.log(`  ${pc.cyan("kici local status")}   Show plane status`);
-	console.log(`  ${pc.cyan("kici local logs")}     Print the orchestrator log path`);
+	console.log(`  ${pc.cyan("kici local logs")}     Print the plane log paths and rotation policy`);
 	console.log(`  ${pc.cyan("kici local down")}     Stop the plane`);
 }
 /**
@@ -147,9 +148,18 @@ async function localDownCommand() {
 	console.log(pc.green("✓") + " Local dev plane stopped.");
 	return true;
 }
-/** Print the local dev plane orchestrator log path. */
+/**
+* Print the local dev plane orchestrator log path, plus the rotation policy.
+*
+* The path is the only line this command writes to stdout — the policy note
+* goes to stderr — so a caller reading stdout never has to strip prose from
+* it. The CLI version banner still precedes it, as for every command, so
+* `$(kici local logs)` is NOT a bare path: read the last stdout line.
+*/
 async function localLogsCommand() {
-	console.log(planeLogPath());
+	const logFile = planeLogPath();
+	console.log(logFile);
+	console.error(pc.dim(`Rotated to ${logFile}.1 when it reaches 50 MB, at the next plane start. When the plane runs embedded PostgreSQL, its log sits beside it at ${logFile}.pg and rotates the same way.`));
 	return true;
 }
 /**

package/dist/commands/report/identity.js

@@ -19,7 +19,7 @@ import { PROTOCOL_VERSION } from "@kici-dev/engine";
 */
 function collectIdentity(probe) {
 	const identity = {
-		kiciCliVersion: "0.7.0",
+		kiciCliVersion: "0.8.0",
 		nodeVersion: process.version,
 		platform: process.platform,
 		arch: process.arch,

package/dist/commands/run-routed.js

@@ -151,6 +151,9 @@ async function runRouted(options) {
 				action: dispatch.action,
 				clientPayload: dispatch.clientPayload
 			}
+		}, {
+			repoBasePath: workdir.dir,
+			logPath: planeLogPath()
 		});
 		if (!quiet) logger.info(pc.green(`Run started: ${runId}`));
 		const outcome = await followRun(plane.url, plane.adminToken, runId, {

package/dist/commands/run.js

@@ -9,6 +9,7 @@ import { buildEncryptedSecrets } from "../remote/secret-upload.js";
 import { createOverlayTarball, getSizeWarning, uploadTarball } from "../remote/uploader.js";
 import { formatJsonResult } from "../remote/output/json.js";
 import { formatJunitResult } from "../remote/output/junit.js";
+import { unwrapStoredLogLine } from "../remote/output/streaming.js";
 import { formatErrorHighlight, formatMultiFixtureSummary, formatSummary } from "../remote/output/summary.js";
 import { compileFixtures, filterFixtures } from "../fixtures/compiler.js";
 import { describeEvent } from "../fixtures/describe-event.js";
@@ -500,7 +501,8 @@ async function pollRunToCompletion(ctx, runId, fixtureId, options) {
 				throw err;
 			}
 			runSeen = true;
-			for (const line of logs.lines) {
+			for (const raw of logs.lines) {
+				const line = unwrapStoredLogLine(raw);
 				if (!options.quiet) process.stdout.write(line + "\n");
 				tailLines.push(line);
 				while (tailLines.length > MAX_TAIL) tailLines.shift();
@@ -585,7 +587,8 @@ function jobsFromStatus(status) {
 	if (!status) return [];
 	return status.jobs.map((j) => ({
 		name: j.jobName,
-		status: j.status
+		status: j.status,
+		...typeof j.durationMs === "number" && { durationMs: j.durationMs }
 	}));
 }
 /**

package/dist/commands/runs/logs.js

@@ -1,6 +1,7 @@
 import "../../rolldown-runtime-ClRpJifh.js";
 import { DashboardClient, DashboardClientError } from "../../remote/dashboard-client.js";
 import { colorStatus } from "../../remote/render.js";
+import { unwrapStoredLogLine } from "../../remote/output/streaming.js";
 import pc from "picocolors";
 import { logger, toErrorMessage } from "@kici-dev/core";
 import { TERMINAL_RUN_STATES } from "@kici-dev/engine";
@@ -31,7 +32,7 @@ async function printAllLogs(client, runId, jobs, jobFilter) {
 	for (const j of selectJobs(jobs, jobFilter)) for (const s of j.steps ?? []) {
 		console.log(pc.bold(`\n=== ${j.jobName} › ${s.stepName} `) + colorStatus(s.status) + pc.bold(" ==="));
 		const logs = await client.getStepLogs(runId, j.jobId, s.stepIndex);
-		for (const line of logs.lines) console.log(line);
+		for (const line of logs.lines) console.log(unwrapStoredLogLine(line));
 	}
 }
 async function collectAllLogs(client, runId, jobs, jobFilter) {
@@ -50,7 +51,7 @@ async function followLogs(client, runId, jobFilter) {
 			const seen = printed[key] ?? 0;
 			if (logs.lines.length > seen) {
 				if (seen === 0) console.log(pc.bold(`\n=== ${j.jobName} › ${s.stepName} ===`));
-				for (const line of logs.lines.slice(seen)) console.log(line);
+				for (const line of logs.lines.slice(seen)) console.log(unwrapStoredLogLine(line));
 				printed[key] = logs.lines.length;
 			}
 		}

package/dist/llm-context/llms-architecture.txt

@@ -1465,7 +1465,7 @@ KiCI uses three WebSocket layers for real-time communication.
 
 ### Platform ↔ Orchestrator
 
-The orchestrator connects outbound to the Platform WebSocket endpoint. After authentication (API key validated via SHA-256 hash lookup), the connection is used for webhook relay, execution telemetry (events, status, logs), source registration, and peer discovery. The Platform can also relay `job.reroute` messages between orchestrators that cannot reach each other directly.
+The orchestrator connects outbound to the Platform WebSocket endpoint. After authentication (API key validated via SHA-256 hash lookup), the connection is used for webhook relay, execution telemetry (events, status, logs), source registration, and peer discovery. Peer discovery is matchmaking only: the Platform pushes a `peer.update` membership list to every orchestrator sharing a routing key, and the orchestrators then connect to each other directly. Inter-orchestrator traffic such as `job.reroute` never transits the Platform.
 
 ### Orchestrator ↔ Orchestrator (P2P)
 

package/dist/llm-context/llms-cli-remote.txt

@@ -761,7 +761,7 @@ In interactive mode (TTY), `kici init` prompts you to:
 
 **Standalone vs workspace integration:** by default `kici init` scaffolds a self-contained `.kici/` with its own `package.json`. When run inside a pnpm, npm, or yarn workspace, it offers an **integrate** option (or pass `--workspace`): `.kici/` joins the workspace, `@kici-dev/sdk` is added to your workspace-root `package.json`, and your workflows can `import` your other workspace packages (e.g. shared build or deploy utilities). In this mode there is no `.kici/package.json` — the workspace root manages dependencies, and the root install resolves the SDK. Your workflows resolve sibling packages through the workspace-root `node_modules`: under npm and yarn every workspace member is hoisted there automatically, while pnpm links only your root's declared dependencies, so under pnpm add the package you want to import to your workspace-root `dependencies` (this is how KiCI's own repository imports its packages from workflows). Pass `--standalone` to force the self-contained layout even inside a workspace. In CI / non-interactive runs the default is standalone; use `--workspace` to opt in explicitly. `--workspace` and `--standalone` are mutually exclusive, and `--workspace` errors if no workspace is found at or above the current directory.
 
-**Development mode:** When `KICI_DEV=true` or `package.json` has `"kici": { "development": true }`, the generated `package.json` uses prerelease-compatible version ranges (`>=0.0.1-0`) so npm resolves Verdaccio's prerelease builds.
+**Development mode:** When `KICI_DEV=true` or `package.json` has `"kici": { "development": true }`, the generated `package.json` pins `@kici-dev/sdk` to the `latest` dist-tag so npm resolves Verdaccio's newest prerelease build.
 
 ### kici org
 
@@ -1707,6 +1707,18 @@ Secrets are always sourced from your real `.kici/` directory, not from the isola
 
 Pass `--in-place` to run against the real working directory instead — useful when you explicitly want in-tree execution. `--in-place` requires no git repository; the default isolated mode does, and fails with an actionable error pointing at `--in-place` when the directory is not a git repository.
 
+**If the trigger times out:**
+
+The command waits up to 60 seconds for the local dev plane to create the run. If nothing appears in that window it stops and names the cause it read back from the plane:
+
+| Message                                                                   | What it means                                                                                                                                                     |
+| ------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `plane is not leader yet (election grace period)`                         | The plane had not finished electing itself. A single-machine plane elects within seconds; if it does not, read the plane log (`kici local logs`).                 |
+| `no kici.lock.json at <commit> in <path>`                                 | The plane resolved no lock file for the commit the run packed, so nothing matched. Commit `.kici/kici.lock.json`, or make sure it is present in the working tree. |
+| `the plane recorded delivery <id> as "<status>"`                          | The plane processed the trigger and wrote down a terminal status for it without creating a run. The status names the stage that stopped.                          |
+| `no run appeared for delivery <id> — see <log>`                           | Neither the plane's cluster state nor its delivery record explained the timeout. The named log is the next place to look.                                         |
+| `no run appeared for this trigger — the plane never accepted the webhook` | Every webhook POST came back without a delivery id, so the plane never queued the trigger. Check the plane is up (`kici local status`), then read the named log.  |
+
 **Examples:**
 
 ```bash

package/dist/llm-context/llms-cli.txt

@@ -1365,7 +1365,7 @@ Manage the **local dev plane** — the warm, per-user orchestrator (plus its own
 kici local up [--offline | --connected]   # Start, or reuse an already-running plane
 kici local status [--json]                 # Port, pid, PostgreSQL backend, attachment mode, readiness
 kici local down                            # Stop the orchestrator and its PostgreSQL, verifying the port is freed
-kici local logs                            # Print the orchestrator log file path
+kici local logs                            # Print the plane log paths and rotation policy
 kici local attach                          # Attach to the Platform (hybrid mode)
 kici local detach                          # Return the plane to offline (independent) mode
 kici local trust-root <file>               # Export the dev-signed trust root for offline verification
@@ -1382,6 +1382,8 @@ The plane runs in one of two modes:
 
 `kici local status` reports a plane whose process is alive but whose readiness probe fails — for example when its PostgreSQL has stopped — as running but not ready, together with its readiness checks, rather than as not running. When the holder is a KiCI plane orchestrator that this config directory did not start — a plane belonging to another `KICI_CONFIG_DIR`, or one whose record here was lost — status names it as such rather than as not ready, since its readiness is never probed, and points at `kici local down`, which does reclaim it. When the port is held by a process that is not a KiCI plane orchestrator, `kici local status` names that holder instead and points at `KICI_LOCAL_ORCH_PORT`, because `kici local down` will not stop it.
 
+The plane writes its orchestrator log to `orchestrator.log` in its state directory and, when it runs embedded PostgreSQL, the PostgreSQL log to `orchestrator.log.pg` beside it. `kici local logs` prints their location. Each is rotated to a `.1` sibling when it reaches 50 MB, at the next plane start — the plane keeps the current log and one previous generation, so neither can grow without bound.
+
 Pass `--json` for machine-readable output. It prints one object and exits 0 for
 every state, including when the plane is stopped — the state is in the payload,
 not the exit code:
@@ -1674,7 +1676,7 @@ Synopsis: `kici local down`
 
 ### `kici local logs`
 
-Print the local dev plane orchestrator log path
+Print the local dev plane log paths and rotation policy
 
 Synopsis: `kici local logs`
 

package/dist/llm-context/llms-features-execution.txt

@@ -607,7 +607,7 @@ The KiCI CLI reads the following environment variables to customize its behavior
 
 | Variable            | Description                                                                                                                                                                | Default |
 | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
-| `KICI_DEV`          | Enable development mode. When `true`, uses prerelease-compatible version ranges (`>=0.0.1-0`) for dev dependencies and skips npm version resolution.                       | unset   |
+| `KICI_DEV`          | Enable development mode. When `true`, pins `@kici-dev/sdk` to the `latest` dist-tag (so a dev registry's prerelease build resolves) and skips npm version resolution.      | unset   |
 | `KICI_DEV_REGISTRY` | npm registry the `@kici-dev` scope points at when `KICI_DEV` is set. `kici init` writes it into `.npmrc`; with no value it writes no `.npmrc`.                             | unset   |
 | `KICI_DEBUG`        | Enable debug logging. When `true`, prints verbose diagnostics (SDK alias resolution, step-level debug logs, stack traces on errors). Equivalent to the `--debug` CLI flag. | unset   |
 

package/dist/llm-context/llms-full.txt

@@ -590,7 +590,7 @@ Point to a local SDK checkout for IDE autocompletion:
 {
   "name": "my-project-kici",
   "devDependencies": {
-    "@kici-dev/sdk": ">=0.0.1-0"
+    "@kici-dev/sdk": "latest"
   },
   "kici": {
     "sdkPath": "../../packages/sdk"
@@ -602,7 +602,7 @@ The `sdkPath` field tells the compiler where to resolve TypeScript path mappings
 
 ### KICI_DEV environment variable
 
-Set `KICI_DEV=true` to use a prerelease-compatible version range (`>=0.0.1-0`) in generated files, which resolves prerelease builds from a local Verdaccio registry:
+Set `KICI_DEV=true` to pin the SDK to the `latest` dist-tag in generated files, which resolves prerelease builds from a local Verdaccio registry:
 
 ```bash
 KICI_DEV=true npx kici init
@@ -6502,6 +6502,17 @@ interface StepContext<TInputs = Record<string, unknown>> {
   provider?: string;
   /** Whether this execution was triggered by `kici run remote` (developer-initiated remote run) */
   isTestRun: boolean;
+  /** The job's own checked-out repository (present for every job that checks out); `withWrite` opens a write window for it — see [Git credentials](https://docs.kici.dev/user/patterns/git-credentials/) */
+  repo?: {
+    identifier: string;
+    path: string;
+    ref?: string;
+    sha?: string;
+    withWrite(
+      opts: { permissions?: Record<string, string>; credential?: string },
+      fn: () => Promise<void>,
+    ): Promise<void>;
+  };
   /** Registering repo of a global workflow (undefined for non-global workflows) */
   workflowRepo?: RepoInfo;
   /** Repo where the triggering event occurred (undefined for non-global workflows) */
@@ -8573,7 +8584,7 @@ Manage the **local dev plane** — the warm, per-user orchestrator (plus its own
 kici local up [--offline | --connected]   # Start, or reuse an already-running plane
 kici local status [--json]                 # Port, pid, PostgreSQL backend, attachment mode, readiness
 kici local down                            # Stop the orchestrator and its PostgreSQL, verifying the port is freed
-kici local logs                            # Print the orchestrator log file path
+kici local logs                            # Print the plane log paths and rotation policy
 kici local attach                          # Attach to the Platform (hybrid mode)
 kici local detach                          # Return the plane to offline (independent) mode
 kici local trust-root <file>               # Export the dev-signed trust root for offline verification
@@ -8590,6 +8601,8 @@ The plane runs in one of two modes:
 
 `kici local status` reports a plane whose process is alive but whose readiness probe fails — for example when its PostgreSQL has stopped — as running but not ready, together with its readiness checks, rather than as not running. When the holder is a KiCI plane orchestrator that this config directory did not start — a plane belonging to another `KICI_CONFIG_DIR`, or one whose record here was lost — status names it as such rather than as not ready, since its readiness is never probed, and points at `kici local down`, which does reclaim it. When the port is held by a process that is not a KiCI plane orchestrator, `kici local status` names that holder instead and points at `KICI_LOCAL_ORCH_PORT`, because `kici local down` will not stop it.
 
+The plane writes its orchestrator log to `orchestrator.log` in its state directory and, when it runs embedded PostgreSQL, the PostgreSQL log to `orchestrator.log.pg` beside it. `kici local logs` prints their location. Each is rotated to a `.1` sibling when it reaches 50 MB, at the next plane start — the plane keeps the current log and one previous generation, so neither can grow without bound.
+
 Pass `--json` for machine-readable output. It prints one object and exits 0 for
 every state, including when the plane is stopped — the state is in the payload,
 not the exit code:
@@ -8882,7 +8895,7 @@ Synopsis: `kici local down`
 
 ### `kici local logs`
 
-Print the local dev plane orchestrator log path
+Print the local dev plane log paths and rotation policy
 
 Synopsis: `kici local logs`
 
@@ -9747,7 +9760,7 @@ In interactive mode (TTY), `kici init` prompts you to:
 
 **Standalone vs workspace integration:** by default `kici init` scaffolds a self-contained `.kici/` with its own `package.json`. When run inside a pnpm, npm, or yarn workspace, it offers an **integrate** option (or pass `--workspace`): `.kici/` joins the workspace, `@kici-dev/sdk` is added to your workspace-root `package.json`, and your workflows can `import` your other workspace packages (e.g. shared build or deploy utilities). In this mode there is no `.kici/package.json` — the workspace root manages dependencies, and the root install resolves the SDK. Your workflows resolve sibling packages through the workspace-root `node_modules`: under npm and yarn every workspace member is hoisted there automatically, while pnpm links only your root's declared dependencies, so under pnpm add the package you want to import to your workspace-root `dependencies` (this is how KiCI's own repository imports its packages from workflows). Pass `--standalone` to force the self-contained layout even inside a workspace. In CI / non-interactive runs the default is standalone; use `--workspace` to opt in explicitly. `--workspace` and `--standalone` are mutually exclusive, and `--workspace` errors if no workspace is found at or above the current directory.
 
-**Development mode:** When `KICI_DEV=true` or `package.json` has `"kici": { "development": true }`, the generated `package.json` uses prerelease-compatible version ranges (`>=0.0.1-0`) so npm resolves Verdaccio's prerelease builds.
+**Development mode:** When `KICI_DEV=true` or `package.json` has `"kici": { "development": true }`, the generated `package.json` pins `@kici-dev/sdk` to the `latest` dist-tag so npm resolves Verdaccio's newest prerelease build.
 
 ### kici org
 
@@ -10693,6 +10706,18 @@ Secrets are always sourced from your real `.kici/` directory, not from the isola
 
 Pass `--in-place` to run against the real working directory instead — useful when you explicitly want in-tree execution. `--in-place` requires no git repository; the default isolated mode does, and fails with an actionable error pointing at `--in-place` when the directory is not a git repository.
 
+**If the trigger times out:**
+
+The command waits up to 60 seconds for the local dev plane to create the run. If nothing appears in that window it stops and names the cause it read back from the plane:
+
+| Message                                                                   | What it means                                                                                                                                                     |
+| ------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `plane is not leader yet (election grace period)`                         | The plane had not finished electing itself. A single-machine plane elects within seconds; if it does not, read the plane log (`kici local logs`).                 |
+| `no kici.lock.json at <commit> in <path>`                                 | The plane resolved no lock file for the commit the run packed, so nothing matched. Commit `.kici/kici.lock.json`, or make sure it is present in the working tree. |
+| `the plane recorded delivery <id> as "<status>"`                          | The plane processed the trigger and wrote down a terminal status for it without creating a run. The status names the stage that stopped.                          |
+| `no run appeared for delivery <id> — see <log>`                           | Neither the plane's cluster state nor its delivery record explained the timeout. The named log is the next place to look.                                         |
+| `no run appeared for this trigger — the plane never accepted the webhook` | Every webhook POST came back without a delivery id, so the plane never queued the trigger. Check the plane is up (`kici local status`), then read the named log.  |
+
 **Examples:**
 
 ```bash
@@ -13664,7 +13689,7 @@ The KiCI CLI reads the following environment variables to customize its behavior
 
 | Variable            | Description                                                                                                                                                                | Default |
 | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
-| `KICI_DEV`          | Enable development mode. When `true`, uses prerelease-compatible version ranges (`>=0.0.1-0`) for dev dependencies and skips npm version resolution.                       | unset   |
+| `KICI_DEV`          | Enable development mode. When `true`, pins `@kici-dev/sdk` to the `latest` dist-tag (so a dev registry's prerelease build resolves) and skips npm version resolution.      | unset   |
 | `KICI_DEV_REGISTRY` | npm registry the `@kici-dev` scope points at when `KICI_DEV` is set. `kici init` writes it into `.npmrc`; with no value it writes no `.npmrc`.                             | unset   |
 | `KICI_DEBUG`        | Enable debug logging. When `true`, prints verbose diagnostics (SDK alias resolution, step-level debug logs, stack traces on errors). Equivalent to the `--debug` CLI flag. | unset   |
 
@@ -17394,7 +17419,7 @@ KiCI uses three WebSocket layers for real-time communication.
 
 ### Platform ↔ Orchestrator
 
-The orchestrator connects outbound to the Platform WebSocket endpoint. After authentication (API key validated via SHA-256 hash lookup), the connection is used for webhook relay, execution telemetry (events, status, logs), source registration, and peer discovery. The Platform can also relay `job.reroute` messages between orchestrators that cannot reach each other directly.
+The orchestrator connects outbound to the Platform WebSocket endpoint. After authentication (API key validated via SHA-256 hash lookup), the connection is used for webhook relay, execution telemetry (events, status, logs), source registration, and peer discovery. Peer discovery is matchmaking only: the Platform pushes a `peer.update` membership list to every orchestrator sharing a routing key, and the orchestrators then connect to each other directly. Inter-orchestrator traffic such as `job.reroute` never transits the Platform.
 
 ### Orchestrator ↔ Orchestrator (P2P)
 

package/dist/llm-context/llms-getting-started.txt

@@ -588,7 +588,7 @@ Point to a local SDK checkout for IDE autocompletion:
 {
   "name": "my-project-kici",
   "devDependencies": {
-    "@kici-dev/sdk": ">=0.0.1-0"
+    "@kici-dev/sdk": "latest"
   },
   "kici": {
     "sdkPath": "../../packages/sdk"
@@ -600,7 +600,7 @@ The `sdkPath` field tells the compiler where to resolve TypeScript path mappings
 
 ### KICI_DEV environment variable
 
-Set `KICI_DEV=true` to use a prerelease-compatible version range (`>=0.0.1-0`) in generated files, which resolves prerelease builds from a local Verdaccio registry:
+Set `KICI_DEV=true` to pin the SDK to the `latest` dist-tag in generated files, which resolves prerelease builds from a local Verdaccio registry:
 
 ```bash
 KICI_DEV=true npx kici init

package/dist/llm-context/llms-sdk-runtime.txt

@@ -1332,6 +1332,17 @@ interface StepContext<TInputs = Record<string, unknown>> {
   provider?: string;
   /** Whether this execution was triggered by `kici run remote` (developer-initiated remote run) */
   isTestRun: boolean;
+  /** The job's own checked-out repository (present for every job that checks out); `withWrite` opens a write window for it — see [Git credentials](https://docs.kici.dev/user/patterns/git-credentials/) */
+  repo?: {
+    identifier: string;
+    path: string;
+    ref?: string;
+    sha?: string;
+    withWrite(
+      opts: { permissions?: Record<string, string>; credential?: string },
+      fn: () => Promise<void>,
+    ): Promise<void>;
+  };
   /** Registering repo of a global workflow (undefined for non-global workflows) */
   workflowRepo?: RepoInfo;
   /** Repo where the triggering event occurred (undefined for non-global workflows) */

package/dist/llm-context/llms.txt

@@ -15,7 +15,7 @@ Each bundle below is a self-contained markdown file for one authoring task. Fetc
 - [sdk](https://docs.kici.dev/llms-sdk.txt) (131 KB) — Core authoring API: workflow/job/step factories, triggers, rules, matrix, dynamic jobs, cross-job outputs
 - [sdk-runtime](https://docs.kici.dev/llms-sdk-runtime.txt) (115 KB) — Runtime and advanced authoring: step runtime context, event payloads, host fan-out, idempotent steps, caching, artifacts, waiting
 - [cli](https://docs.kici.dev/llms-cli.txt) (97 KB) — Running the CLI locally: compile, test, run local, hooks, lock-file drift, common failures
-- [cli-remote](https://docs.kici.dev/llms-cli-remote.txt) (109 KB) — Auth, org and orchestrator selection, runs, approvals, notifications, diagnostics, and the MCP server a coding agent connects to
+- [cli-remote](https://docs.kici.dev/llms-cli-remote.txt) (111 KB) — Auth, org and orchestrator selection, runs, approvals, notifications, diagnostics, and the MCP server a coding agent connects to
 - [features](https://docs.kici.dev/llms-features.txt) (97 KB) — Deployment contexts, scoped secrets, private registries, approvals, provenance, dashboard and account access
 - [features-execution](https://docs.kici.dev/llms-features-execution.txt) (124 KB) — Concurrency, dynamic values, events, container jobs, environment variables, global workflows, idempotent steps
 - [providers](https://docs.kici.dev/llms-providers.txt) (35 KB) — Connecting sources: GitHub App, universal-git (Forgejo/Gitea/GitLab), local file://

package/dist/local-plane/orchestrator-process.js

@@ -1,5 +1,6 @@
 import "../rolldown-runtime-ClRpJifh.js";
 import { planePaths, planePorts } from "./paths.js";
+import { rotatePlaneLogIfOversized } from "./plane-log.js";
 import { createRequire } from "node:module";
 import fs from "node:fs";
 import { spawn } from "node:child_process";
@@ -48,6 +49,7 @@ function spawnOrchestratorProcess(databaseUrl, opts) {
 	const { logFile, root, cacheDir } = planePaths();
 	fs.mkdirSync(root, { recursive: true });
 	fs.mkdirSync(cacheDir, { recursive: true });
+	rotatePlaneLogIfOversized(logFile);
 	const out = fs.openSync(logFile, "a");
 	const baseEnv = {};
 	for (const [key, value] of Object.entries(process.env)) if (!key.startsWith("KICI_")) baseEnv[key] = value;
@@ -58,6 +60,7 @@ function spawnOrchestratorProcess(databaseUrl, opts) {
 		KICI_AGENT_AUTH: "none",
 		KICI_HOST: "127.0.0.1",
 		KICI_AUTO_MIGRATE: "true",
+		KICI_CLUSTER_SINGLE_NODE: "true",
 		KICI_DATA_DIR: root,
 		KICI_BOOTSTRAP_ADMIN_TOKEN: opts.adminToken,
 		KICI_SECRET_KEY: opts.secretKey,

package/dist/local-plane/paths.d.ts

@@ -33,6 +33,7 @@ export declare function planePaths(): {
     pidfile: string;
     stampFile: string;
     logFile: string;
+    pgLogFile: string;
     socketDir: string;
     adminTokenFile: string;
     platformTokenFile: string;

package/dist/local-plane/paths.js

@@ -48,6 +48,7 @@ function planePaths() {
 		pidfile: path.join(root, "plane.pid"),
 		stampFile: path.join(root, "stamp.json"),
 		logFile: path.join(root, "orchestrator.log"),
+		pgLogFile: path.join(root, "orchestrator.log.pg"),
 		socketDir: path.join(root, "sock"),
 		adminTokenFile: path.join(root, "admin-token"),
 		platformTokenFile: path.join(root, "platform-token"),

package/dist/local-plane/plane-log.d.ts

@@ -0,0 +1,27 @@
+/**
+ * Size at which a local dev plane log is rotated on the next plane start.
+ *
+ * The plane's orchestrator writes one JSON line per request and per
+ * scheduled-job tick, and nothing truncates the file between boots, so an
+ * unrotated log grows without bound. 50 MB is roughly 200k lines — more history
+ * than a local debugging session reads.
+ */
+export declare const PLANE_LOG_MAX_BYTES: number;
+/** The cap expressed in whole megabytes, for the messages that name it. */
+export declare const PLANE_LOG_MAX_MB: number;
+/**
+ * Rotate `file` to `<file>.1` once it reaches `PLANE_LOG_MAX_BYTES`, keeping two
+ * generations: any previous `.1` is discarded.
+ *
+ * Call this only where nothing holds the file open. A rename under a live
+ * writer leaves that writer appending to the renamed inode, so the live log
+ * would stay empty for the rest of the process's life.
+ *
+ * Every failure is swallowed on purpose. Both callers are on a plane-boot path:
+ * `startPlanePostgres` reads a throw as "embedded Postgres is unavailable" and
+ * silently falls back to a Podman container, and `spawnOrchestratorProcess`
+ * would fail the boot outright. A log that cannot be rotated must not cost the
+ * user their plane.
+ */
+export declare function rotatePlaneLogIfOversized(file: string): void;
+//# sourceMappingURL=plane-log.d.ts.map

package/dist/local-plane/plane-log.js

@@ -0,0 +1,39 @@
+import "../rolldown-runtime-ClRpJifh.js";
+import fs from "node:fs";
+//#region src/local-plane/plane-log.ts
+/**
+* Size at which a local dev plane log is rotated on the next plane start.
+*
+* The plane's orchestrator writes one JSON line per request and per
+* scheduled-job tick, and nothing truncates the file between boots, so an
+* unrotated log grows without bound. 50 MB is roughly 200k lines — more history
+* than a local debugging session reads.
+*/
+const PLANE_LOG_MAX_BYTES = 52428800;
+/** The cap expressed in whole megabytes, for the messages that name it. */
+const PLANE_LOG_MAX_MB = PLANE_LOG_MAX_BYTES / 1048576;
+/**
+* Rotate `file` to `<file>.1` once it reaches `PLANE_LOG_MAX_BYTES`, keeping two
+* generations: any previous `.1` is discarded.
+*
+* Call this only where nothing holds the file open. A rename under a live
+* writer leaves that writer appending to the renamed inode, so the live log
+* would stay empty for the rest of the process's life.
+*
+* Every failure is swallowed on purpose. Both callers are on a plane-boot path:
+* `startPlanePostgres` reads a throw as "embedded Postgres is unavailable" and
+* silently falls back to a Podman container, and `spawnOrchestratorProcess`
+* would fail the boot outright. A log that cannot be rotated must not cost the
+* user their plane.
+*/
+function rotatePlaneLogIfOversized(file) {
+	try {
+		if (fs.statSync(file).size < 52428800) return;
+		fs.rmSync(`${file}.1`, { force: true });
+		fs.renameSync(file, `${file}.1`);
+	} catch {}
+}
+//#endregion
+export { PLANE_LOG_MAX_BYTES, PLANE_LOG_MAX_MB, rotatePlaneLogIfOversized };
+
+//# sourceMappingURL=plane-log.js.map

package/dist/local-plane/plane-manager.js

@@ -19,8 +19,8 @@ import { generateKeyPairSync, randomBytes } from "node:crypto";
 */
 function currentBuildIdentity() {
 	return {
-		version: "0.7.0",
-		buildCommit: "31843a21c"
+		version: "0.8.0",
+		buildCommit: "57712173f"
 	};
 }
 /**

package/dist/local-plane/plane-trigger.d.ts

@@ -11,6 +11,9 @@
  * The source's bundle hot-reload is debounced, so a first trigger can land
  * before the plane has registered the (re-pointed) local source. This resends
  * the webhook after a grace window until a run appears or the timeout elapses.
+ * When the budget still runs out, the timeout is explained rather than merely
+ * reported: the plane's own Raft role and its event-log record for this
+ * delivery decide which cause is named.
  */
 /** A minimal admin-read client (AdminApiClient.get) — injectable for tests. */
 export interface RunDiscoveryClient {
@@ -58,7 +61,32 @@ export interface TriggerRunOptions {
     pollIntervalMs?: number;
     resendAfterMs?: number;
     timeoutMs?: number;
+    /** Workdir the plane's local source points at — named in the lock-file diagnosis. */
+    repoBasePath?: string;
+    /** Plane log path — named when nothing else explains the timeout. */
+    logPath?: string;
 }
+/** What the diagnosis knows about the trigger that just timed out. */
+export interface TriggerTimeoutContext {
+    /** Routing-key-scoped delivery id, or null when the plane never accepted the webhook. */
+    deliveryId: string | null;
+    orgId: string;
+    /** Commit the synthetic push carried (the workdir's overlay commit). */
+    sha: string;
+    /** Absolute path the plane's local source points at — the run's workdir. */
+    repoBasePath?: string;
+    /** Plane log path, named in the fallback so the developer has somewhere to look. */
+    logPath?: string;
+}
+/**
+ * Explain a trigger timeout in one line, from what the plane itself recorded.
+ *
+ * Ordered most-specific-first, and every branch is a fact read back off the
+ * plane rather than an inference: the Raft role it reports, then the status it
+ * wrote for THIS delivery, then the delivery id + log path so the developer has
+ * a thread to pull even when neither surface answered.
+ */
+export declare function diagnoseTriggerTimeout(client: RunDiscoveryClient, ctx: TriggerTimeoutContext): Promise<string>;
 /**
  * Trigger the run and resolve its runId. Sends the synthetic push, then polls
  * the admin runs list filtered by this webhook's routing-key-scoped delivery id