@cruxy/cli 1.9.0 → 1.11.0

package/dist/config/schema.js

@@ -2,7 +2,24 @@ import { z } from "zod";
 import { LOG_LEVELS } from "../utils/logger.js";
 import { MODEL_TIERS } from "../brand/voice.js";
 import { TASK_CLASSES } from "../routing/types.js";
-export const ProviderSchema = z.enum(["cruxy", "openai", "custom"]);
+/**
+ * The backends a session can run on. ONE, deliberately.
+ *
+ * This used to be `["cruxy", "openai", "custom"]`. Neither extra value could
+ * ever produce a working session: `createProvider` implements `cruxy` and
+ * throws {@link NotImplementedError} for anything else, so `provider: "openai"`
+ * passed config validation and then failed at session start — a promise the
+ * schema made and the SDK refused. `OpenAICompatibleProvider`, the only code
+ * that could have honoured it, was removed in #260; "reserved for the future"
+ * is not a claim this enum can support when the implementation it named is
+ * gone.
+ *
+ * Rejecting them HERE is the point: a bad provider is now a config-load error
+ * that names the valid values, instead of a NotImplementedError thrown after
+ * onboarding has already run. Adding a backend means adding the value back
+ * together with the provider that serves it — never ahead of it.
+ */
+export const ProviderSchema = z.enum(["cruxy"]);
 export const ModelConfigSchema = z
     .object({
     provider: ProviderSchema.default("cruxy"),
@@ -220,6 +237,73 @@ export const CheckpointConfigSchema = z
     retention: z.number().int().positive().default(10),
 })
     .strict();
+/**
+ * The floor under `sessions.retention`.
+ *
+ * The `--resume` picker (`PICKER_LIMIT`) and the TUI sidebar
+ * (`SIDEBAR_SESSIONS`) each offer ten rows. A retention below that would let
+ * both surfaces list sessions a later prune has already decided are
+ * expendable — offering a row and then deleting it is worse than never showing
+ * it. `session/retention-floor.test.ts` pins this against the two constants
+ * themselves, so raising either surface without raising the floor fails.
+ *
+ * Rejected rather than silently raised: a config that says 5 and behaves as 10
+ * is a config that lies, and `loadConfig` already treats a bad value as a hard
+ * error everywhere else.
+ */
+export const SESSION_RETENTION_FLOOR = 10;
+/**
+ * Session persistence and retention (#257).
+ *
+ * The stores either side of this one have always bounded themselves —
+ * checkpoints at 10, run history at 50 — and sessions did not. Every session
+ * file ever written was still on disk, and nothing could turn recording off.
+ *
+ * WHY AGE IS THE PRIMARY BOUND AND COUNT IS THE BACKSTOP. "Old sessions I will
+ * never resume" is how people actually think about this, and once a session
+ * that recorded nothing stops being written at all (the lazy-meta change that
+ * had to land first), every remaining file is a real conversation for which age
+ * is the honest signal. The count cap stays because age alone does not protect
+ * a directory where someone runs forty sessions a day.
+ *
+ * WHY NOT BYTES. `statSync` hands us the size for free, so cost is not the
+ * objection — meaning is. Pruning on bytes makes whether YOUR session survives
+ * depend on how chatty an unrelated one was, which is not a rule anyone can
+ * hold in their head. `cruxy sessions` reports bytes, because seeing where the
+ * disk went is exactly what a report is for; nothing prunes on them.
+ *
+ * PER PROJECT, matching `projectDir` and how listing already works. A global
+ * cap would need the cross-project scan #172 item 2 declined.
+ */
+export const SessionsConfigSchema = z
+    .object({
+    /**
+     * Master switch. When false nothing is recorded: no file, no `--resume`,
+     * no sidebar. The session runs entirely in memory.
+     */
+    enabled: z.boolean().default(true),
+    /**
+     * How many sessions to keep per project; older ones are pruned oldest-first.
+     * Never below {@link SESSION_RETENTION_FLOOR} — see the note there.
+     */
+    retention: z
+        .number()
+        .int()
+        .min(SESSION_RETENTION_FLOOR, {
+        message: `sessions.retention must be at least ${SESSION_RETENTION_FLOOR} — ` +
+            `the --resume picker and the TUI sidebar both offer that many rows, and ` +
+            `a lower retention would list sessions that are already marked for deletion`,
+    })
+        .default(50),
+    /**
+     * Prune sessions untouched for this many days. Measured on the file's
+     * MTIME, never on `meta.startedAt`: a conversation begun forty days ago and
+     * resumed this morning is live, and an age check on when it BEGAN would
+     * delete it out from under the user.
+     */
+    maxAgeDays: z.number().int().positive().default(30),
+})
+    .strict();
 /**
  * Test-execution loop (C.13): how the agent runs the project's test suite and
  * iterates on failures. The command is detected from package.json when unset;
@@ -307,13 +391,47 @@ export const JobsConfigSchema = z
      */
     maxJobs: z.number().int().positive().default(5),
     /**
-     * How many of a job's most-recent log lines are retained in its ring buffer
-     * for `cruxy logs <id>`. Bounded so a chatty job can't grow memory without
-     * limit; older lines roll off oldest-first. Default 1000.
+     * How many of a job's most-recent log lines are retained in its IN-MEMORY
+     * ring buffer, which is what `/logs <id>` and the Tasks view read while the
+     * session is alive. Bounded so a chatty job can't grow memory without
+     * limit; older lines roll off oldest-first and `/logs` says how many.
+     * Default 1000.
+     *
+     * This is no longer the only copy: {@link logFileLines} bounds the
+     * persisted one, which `cruxy logs <id>` reads back after the fact.
      */
     logBufferLines: z.number().int().positive().default(1000),
+    /**
+     * How many lines of a job's output are written to its file under
+     * `~/.cruxy/projects/<project>/subagents/` (#172 item 1). Past this the log
+     * records one honest `truncated` marker and stops; the job runs on.
+     *
+     * WHY A SECOND, LARGER BOUND rather than reusing {@link logBufferLines}.
+     * The file exists precisely to remove the ring buffer's drop-on-overflow,
+     * so a file bounded at the buffer's size would persist the same truncated
+     * tail and buy nothing — which is why this is FLOORED at `logBufferLines`
+     * rather than allowed to sink below it (see the refinement below).
+     *
+     * WHY IT IS BOUNDED AT ALL. `sessions.retention` bounds how many session-
+     * shaped things the tree keeps; nothing bounds how big ONE of them gets,
+     * and a background job is the first writer here that can produce unbounded
+     * output unattended — it runs a full agent loop off screen, and a job stuck
+     * in a tool-call loop emits lines for as long as its budget lasts with
+     * nobody watching. Streaming that to disk uncapped is the second unbounded
+     * writer under `~/.cruxy` that #257 exists to prevent.
+     *
+     * 20000 is 20x the in-memory buffer: roughly 2 MB for a worst-case job, and
+     * the sweep drops a `done` job's log at the next start, so the steady-state
+     * cost of the default is near zero.
+     */
+    logFileLines: z.number().int().positive().default(20000),
 })
-    .strict();
+    .strict()
+    .refine((j) => j.logFileLines >= j.logBufferLines, {
+    message: "jobs.logFileLines must be at least jobs.logBufferLines — the persisted log " +
+        "exists to remove the ring buffer's drop-on-overflow, and a file that kept " +
+        "fewer lines than memory would make persisting strictly worse than not persisting",
+});
 /**
  * Sandbox / container execution (C.16): defense-in-depth beneath the U.3 gate.
  * When enabled, `run_command` and `run_tests` execute inside an isolated,
@@ -377,17 +495,25 @@ export const HooksConfigSchema = z
 /**
  * Multi-model routing (C.30): map declared task classes to tiers so mechanical
  * work runs on a cheap tier and hard reasoning on a strong one. Fully opt-in —
- * with an empty `map` and no `default`, every task class routes to the session's
- * single tier and behavior is unchanged (routing stays inert until configured).
- * Only tier names appear here; upstream model names never do (U.8). Keys are the
- * fixed {@link TASK_CLASSES}, so a mistyped class is rejected at config load.
+ * with an empty `map` and no `default` the whole table is inert and nothing
+ * about a session changes. Only tier names appear here; upstream model names
+ * never do (U.8). Keys are the fixed {@link TASK_CLASSES}, so a mistyped class
+ * is rejected at config load.
+ *
+ * A PARTIAL TABLE STAYS PARTIAL. Writing `map` without `default` routes exactly
+ * the classes named and leaves every other one to the gateway (`auto`) — it does
+ * not pin them to some tier chosen on your behalf. The exception is a
+ * `model.model` that names a tier: that is a session-wide model choice, and the
+ * unnamed classes inherit it rather than being handed back to the gateway.
  */
 export const RoutingConfigSchema = z
     .object({
-    /** Tier for any task class not in `map`. Unset → the tier implied by
-     * `model.model` (a real tier, or the auto-fallback tier). */
+    /** Tier for any task class not in `map`. Unset → the tier `model.model`
+     * names, if it names one; otherwise the class is not routed here at all and
+     * goes out as `auto` for the gateway to route. */
     default: z.enum(MODEL_TIERS).optional(),
-    /** Per-task-class tier overrides; anything omitted takes `default`. */
+    /** Per-task-class tier overrides; anything omitted takes `default`, or
+     * `auto` when there is no `default` to take. */
     map: z.record(z.enum(TASK_CLASSES), z.enum(MODEL_TIERS)).default({}),
 })
     .strict();
@@ -517,7 +643,11 @@ export const UsageConfigSchema = z
  * arguments over the network (https + cert-validated + pinned to a public IP; http
  * only for a loopback dev server) and treats its responses as untrusted data. A
  * url's trust also binds its resolved IP set at trust time, so a later IP-set
- * change re-gates (weaker than a local binary fingerprint — see `mcp/types.ts`).
+ * change re-gates. NEITHER transport's fingerprint covers the server's CODE —
+ * both hash the invocation (command/args/env, url, credential ref, header names),
+ * so a trusted server that later ships different code is still trusted. Trust
+ * means "I accept running this", not "this is still what I trusted"; see
+ * `mcp/types.ts`.
  */
 export const McpServerSchema = z
     .object({
@@ -577,6 +707,40 @@ function isHttps(url) {
  * model names scrubbed, and results are NEVER persisted. The tool list a server
  * advertises is bounded (count + per-tool description/schema size) so a hostile
  * server can't blow the context budget.
+ *
+ * THE THREE BOUNDS HAVE CEILINGS OF THEIR OWN (#237). Each was `positive()` with
+ * no maximum, which made the protection exactly as good as the number the user
+ * typed: `maxSchemaBytes: 100000000` validated cleanly, and a cap whose docstring
+ * says a hostile server "can't flood context" then does not do that. The failure
+ * moved downstream to a provider request-size rejection or a blown context
+ * budget — a much worse place to find out than config load, where the answer is
+ * one line.
+ *
+ * These ceilings are a SANITY BOUND, NOT A PROTOCOL LIMIT, and the difference
+ * matters because `MAX_SCHEMA_DEPTH` (`tools/schema-depth.ts`) bounds the same
+ * schemas and is the opposite kind of number. That one mirrors a real gateway
+ * constraint: exceed it and the
+ * whole request fails, so it is not ours to choose and must never be raised to
+ * make a config work. These three mirror nothing upstream — no external validator
+ * enforces them and no request breaks at 65 KiB. They are a statement about what
+ * configuration is worth honoring, so they are picked to be obviously generous
+ * (8x, 16x, and 8x the shipped defaults) rather than tight. Different numbers in
+ * the same spirit would be just as correct; having no number at all was not.
+ *
+ * Rejected rather than silently clamped, on `SESSION_RETENTION_FLOOR`'s rule: a
+ * config that says 100000000 and behaves as 65536 is a config that lies. The cost
+ * is that an over-ceiling value is a hard `loadConfig` error, and the schema is
+ * `.strict()`, so it fails the whole CLI rather than just MCP. That is affordable
+ * HERE and would not be everywhere: these keys are documented nowhere, are not
+ * env-settable, and `initConfig` writes the defaults — so every generated config
+ * passes, and `setValue` rejects an over-ceiling `cruxy config set` at the write
+ * with the path and the bound named. Contrast `UsageConfigSchema`, which refuses
+ * the same hard error for the opposite reason: those keys were a documented
+ * feature people really had set, so rejecting them would hand a working user a
+ * CLI that will not start.
+ *
+ * The two timeouts above are deliberately left unbounded: a long timeout costs
+ * patience rather than memory, and a user may have a legitimately slow server.
  */
 export const McpConfigSchema = z
     .object({
@@ -592,15 +756,24 @@ export const McpConfigSchema = z
     /** Fail a single `tools/call` if the server does not respond within this many
      * ms — the connection is kept, only the one call errors. */
     requestTimeout: z.number().int().positive().default(30000),
-    /** Max tools accepted from ONE server; extras are dropped with a visible note
-     * (a hostile server can't advertise thousands of tools to flood context). */
-    maxToolsPerServer: z.number().int().positive().default(32),
+    /**
+     * Max tools accepted from ONE server; extras are dropped with a visible note
+     * (a hostile server can't advertise thousands of tools to flood context).
+     *
+     * PER SERVER, which is not the number that decides the context budget. Ten
+     * trusted servers at the default advertise up to 320 tools between them, and
+     * nothing caps that sum — this bound stops one server flooding the list, not
+     * a large `servers` map adding up. Configuring many servers is a deliberate
+     * act with a visible cost, so it is bounded by the user rather than here.
+     */
+    maxToolsPerServer: z.number().int().positive().max(256).default(32),
     /** Max characters kept from a single tool's description; the rest is truncated
-     * with a visible marker. */
-    maxDescriptionChars: z.number().int().positive().default(1024),
+     * with a visible marker. A description past the 16 KiB ceiling is not one. */
+    maxDescriptionChars: z.number().int().positive().max(16_384).default(1024),
     /** Max bytes kept from a single tool's advertised JSON input schema; an
-     * over-cap schema is replaced with a permissive one and a visible note. */
-    maxSchemaBytes: z.number().int().positive().default(8192),
+     * over-cap schema is replaced with a permissive one and a visible note. One
+     * tool's schema at the 64 KiB ceiling is already ~16k tokens of context. */
+    maxSchemaBytes: z.number().int().positive().max(65_536).default(8192),
 })
     .strict();
 /**
@@ -660,6 +833,7 @@ export const CruxyConfigSchema = z
     index: IndexConfigSchema.default({}),
     lsp: LspConfigSchema.default({}),
     checkpoint: CheckpointConfigSchema.default({}),
+    sessions: SessionsConfigSchema.default({}),
     subagent: SubagentConfigSchema.default({}),
     jobs: JobsConfigSchema.default({}),
     test: TestConfigSchema.default({}),

package/dist/constants.js

@@ -26,8 +26,18 @@ export const CONFIG_FILE_NAME = "config.json";
 export const CREDENTIALS_FILE_NAME = "credentials.json";
 /** Onboarding state + completion marker under the global dir (U.6). */
 export const ONBOARDING_FILE_NAME = "onboarding.json";
-/** Where a user creates a Cruxy gateway key (printed during onboarding). */
-export const CREATE_KEY_URL = "https://app.cruxy.in";
+/**
+ * Where a user creates a Cruxy gateway key (printed during onboarding).
+ *
+ * `cruxy.ai`, not `app.cruxy.in` — the app moved and the old host now only
+ * `308`s here. Printed verbatim into the terminal, where a redirect buys
+ * nothing: a URL a user copies by hand or reads aloud should be the one that
+ * serves the page, and this one outlived the redirect that was covering for it.
+ *
+ * Deliberately NOT `api.cruxy.in`. The gateway did not move, and nothing in
+ * this package that names it should be changed alongside this.
+ */
+export const CREATE_KEY_URL = "https://cruxy.ai";
 /** Project-level config filenames, checked in order. */
 export const PROJECT_CONFIG_FILENAMES = [
     "cruxy.config.json",

package/dist/errors/constructors.js

@@ -1,4 +1,4 @@
-import { ApiError, AuthError, BudgetExhaustedError, InvalidRequestError, NetworkError, OverloadedError, RateLimitError, } from "@cruxy/sdk";
+import { ApiError, AuthError, BudgetExhaustedError, InvalidRequestError, NetworkError, OverloadedError, RateLimitError, ToolSchemaRejectedError, } from "@cruxy/sdk";
 import { scrubModelNames } from "../brand/index.js";
 // Imported from the leaf module DIRECTLY, not via `config/index.js`:
 // `config/credentials.ts` imports this file, so going through the barrel would
@@ -109,14 +109,47 @@ export function configParse(path, underlying) {
         meta: { path },
     });
 }
+/**
+ * `--config <path>` named a file that does not exist.
+ *
+ * Loud by construction: the alternative is falling back to discovery or to
+ * defaults, which produces exactly the behaviour the user would have got
+ * without the flag, and so is indistinguishable from success (#289). Raised
+ * only for an EXPLICIT path — a missing global or project config is ordinary.
+ */
+export function configNotFound(path) {
+    return new CruxyError({
+        code: ErrorCode.ConfigNotFound,
+        title: `config file not found: ${path}`,
+        cause: "`--config` named a file that does not exist",
+        nextSteps: [
+            "check the path (it is resolved as given, relative to the current directory)",
+            "omit `--config` to use the discovered project config, or `~/.cruxy/config.json`",
+        ],
+        meta: { path },
+    });
+}
 export function configInvalid(issues, path) {
     return new CruxyError({
         code: ErrorCode.ConfigInvalid,
-        title: "the configuration is invalid",
+        // NAME THE FILE, as `configParse` above already does. The path was carried
+        // in `meta` alone, and the terminal formatter renders title/cause/steps/code
+        // — not meta — so the caller's choice of which file to blame reached nobody
+        // and "correct the reported field(s)" left the user to guess between the
+        // global, project and explicit configs (#289).
+        //
+        // It is the HIGHEST-PRECEDENCE file in effect, not necessarily the one
+        // holding the bad key: the config is a merge, and a resolved value cannot
+        // be traced to a layer from here. Hence "start with" and the pointer to
+        // `config path` — an honest lead, not a claim about which line to edit.
+        title: path
+            ? `the configuration is invalid (${path})`
+            : "the configuration is invalid",
         cause: issues,
         nextSteps: [
             "correct the reported field(s)",
-            "see valid keys with `cruxy config list`",
+            ...(path ? [`start with ${path}, the last file merged`] : []),
+            "see valid keys with `cruxy config list`, or the files in effect with `cruxy config path`",
         ],
         meta: path ? { path } : undefined,
     });
@@ -245,16 +278,32 @@ export function apiError(underlying) {
  * moment", and they point at the issue tracker with a code to quote, because a
  * report is the one action that actually moves this forward.
  *
- * The gateway's message names the offending tool when a tool is at fault (its
- * validator emits `tool "<name>": ...`), and that name is the single most useful
- * token in the whole error — it turns "cruxy is broken" into a filed issue
- * someone can act on. It is lifted out of the SCRUBBED message, never the raw
- * one, so the U.8 gag can never be undone by this path.
+ * WHEN A TOOL IS AT FAULT the gateway now says so in fields rather than in
+ * prose. A schema over one of its caps answers `invalid_tool_schema` carrying
+ * `tool`, `bound` and `limit`, which the SDK reads onto
+ * {@link ToolSchemaRejectedError} — so the tool name, the cap that was hit and
+ * the number to fit under are all read off the structured half of a contract
+ * whose `code` MAY NOT change, rather than parsed back out of English that MAY.
+ *
+ * That name is the single most useful token in the whole error: it turns "cruxy
+ * is broken" into a filed issue someone can act on, and `bound`/`limit` turn the
+ * report into one a fix can start from. All three ride in `meta` for exactly
+ * that reason, and all three are optional — the gateway omits them when no cap
+ * was reached, and an older one omits them entirely.
+ *
+ * The name is still passed through the model-name scrub before it is shown. It
+ * is our own harness's function name and cannot plausibly be an upstream model
+ * id, but the U.8 gag holding BY CONSTRUCTION on every path out of here is worth
+ * more than the one call it costs — this used to be true only because the name
+ * was cut out of an already-scrubbed string.
  */
 export function apiRequestRejected(underlying) {
     const status = underlying instanceof ApiError ? underlying.status : undefined;
     const cause = scrubbedMessageOf(underlying);
-    const tool = toolNamedIn(cause);
+    const rejected = underlying instanceof ToolSchemaRejectedError ? underlying : undefined;
+    const tool = rejected?.tool === undefined ? undefined : scrubModelNames(rejected.tool);
+    const bound = rejected?.bound;
+    const limit = rejected?.limit;
     return new CruxyError({
         code: ErrorCode.ApiRequestRejected,
         title: tool
@@ -273,46 +322,11 @@ export function apiRequestRejected(underlying) {
         meta: {
             ...(status !== undefined ? { status } : {}),
             ...(tool !== undefined ? { tool } : {}),
+            ...(bound !== undefined ? { bound } : {}),
+            ...(limit !== undefined ? { limit } : {}),
         },
     });
 }
-/**
- * The tool name in a gateway rejection, if it named one.
- *
- * The gateway's tool-schema validator prefixes its complaint with the offending
- * function — `tool "apply_patch": parameters nests deeper than 8 levels` — so
- * one quoted token after the word `tool` is the whole pattern. Anything else
- * yields `undefined` and the caller falls back to generic wording: a WRONG tool
- * name in a bug report is worse than none, so this never guesses.
- *
- * ── TEMPORARY COUPLING, AND IT IS THE WRONG KIND ────────────────────────────
- *
- * This reads the gateway's `error` MESSAGE, and the gateway's own contract
- * (cruxy-ai/api, `internal/httpx/errcode.go`) says the message MAY change while
- * the `code` MAY NOT. So this parses the half that is explicitly allowed to move
- * under us — the exact coupling the code/message split exists to prevent.
- *
- * It is deliberate and bounded: today the code is the generic `invalid_request`,
- * shared with bad JSON, a missing field and an unknown model, so the message is
- * the ONLY thing distinguishing "this build's tool harness is permanently
- * unusable" from "this one request was malformed". The tool name is the single
- * most actionable token in the error and it is worth having; a regex that fails
- * closed is the cheapest way to have it.
- *
- * Failing closed is what makes the risk acceptable. If the gateway rewords, this
- * returns `undefined`, the caller drops to generic wording, and the error is
- * still correct — less specific, never wrong. Nothing downstream branches on it.
- *
- * The real fix is server-side and filed as cruxy-ai/api#183: a distinct 400 code
- * for harness-bound rejections (the `invalid_schema` precedent already exists
- * for `response_format`), with the tool name as a STRUCTURED FIELD rather than a
- * message prefix. When that lands, match on the code, read the field, and delete
- * this function — do not "improve" the regex.
- */
-function toolNamedIn(message) {
-    const match = /\btool "([^"]+)"/.exec(message ?? "");
-    return match?.[1];
-}
 export function apiRateLimit(underlying) {
     const retryAfterMs = underlying instanceof RateLimitError ? underlying.retryAfterMs : undefined;
     return new CruxyError({
@@ -1604,3 +1618,27 @@ export function classifyProviderError(underlying, ctx = {}) {
         return apiError(underlying);
     return null;
 }
+/**
+ * The typed pool denial behind an error, or `null` if it is not one.
+ *
+ * LIVES HERE BECAUSE IT HAS TWO CALLERS (cli#245). It was written for the
+ * fan-out seam (cli#243) and is needed byte-for-byte by the background-job
+ * executor, which flattened the same 429 into a message string and lost
+ * `window`, `resetAt` and `miraAvailable` — the three fields that make a denial
+ * actionable, and the last of which is the only one that unblocks someone now.
+ * A second copy of this in `jobs/` would be two places that decide what a pool
+ * denial is, and they would disagree the first time the SDK grows a class.
+ *
+ * Two shapes reach here and both are the same fact: the raw SDK
+ * `BudgetExhaustedError` from the run's own request, and — when a caller that
+ * already converted one re-throws — the {@link CruxyError} it produced. Mapping
+ * goes through {@link classifyProviderError} so there is still ONE place that
+ * knows which SDK class means what.
+ */
+export function poolDenial(err) {
+    if (CruxyError.is(err)) {
+        return err.code === ErrorCode.BudgetExhausted ? err : null;
+    }
+    const typed = classifyProviderError(err);
+    return typed?.code === ErrorCode.BudgetExhausted ? typed : null;
+}

package/dist/errors/types.js

@@ -29,6 +29,11 @@ export const ErrorCode = {
     // config (exit 3)
     ConfigParse: "CRUXY_E_CONFIG_PARSE",
     ConfigInvalid: "CRUXY_E_CONFIG_INVALID",
+    /** A config file named with `--config` does not exist. DISTINCT from
+     * {@link ConfigParse}: nothing was malformed, the file simply is not there,
+     * and the advice is to check the path rather than the JSON. Only an EXPLICIT
+     * path can raise it — a missing global or project file is the normal case. */
+    ConfigNotFound: "CRUXY_E_CONFIG_NOT_FOUND",
     // auth (exit 4)
     AuthMissingKey: "CRUXY_E_AUTH_MISSING_KEY",
     AuthInvalid: "CRUXY_E_AUTH_INVALID",
@@ -311,6 +316,7 @@ const EXIT_CODES = {
     [ErrorCode.RoutingTierUnavailable]: 2,
     [ErrorCode.ConfigParse]: 3,
     [ErrorCode.ConfigInvalid]: 3,
+    [ErrorCode.ConfigNotFound]: 3,
     [ErrorCode.AuthMissingKey]: 4,
     [ErrorCode.AuthInvalid]: 4,
     [ErrorCode.AuthExpired]: 4,

package/dist/jobs/index.js

@@ -1,5 +1,6 @@
 export * from "./types.js";
 export * from "./log-buffer.js";
+export * from "./log-store.js";
 export * from "./log-renderer.js";
 export * from "./approval-queue.js";
 export * from "./manager.js";

package/dist/jobs/log-renderer.js

@@ -18,9 +18,14 @@ const OFFSCREEN_CAPS = {
 };
 /**
  * A {@link StreamRenderer} for a background job (C.28) that captures activity into
- * the job's log buffer and writes NOTHING to any terminal — a job runs
+ * the job's log sink and writes NOTHING to any terminal — a job runs
  * non-interactively, off screen, and its foreground session owns the terminal.
- * `cruxy logs <id>` (a REPL `/logs`) reads back what was captured here.
+ *
+ * What was captured here is read back from two different copies: the in-session
+ * `/logs <id>` and the Tasks view read the ring buffer while the session lives,
+ * and `cruxy logs <id>` reads the persisted file afterwards (#172 item 1).
+ * Everything this renderer emits goes through the one `JobManager.log` sink, so
+ * both copies see exactly the same lines.
  *
  * Assistant text is accumulated and flushed a line at a time on `endSegment`;
  * committed chrome notes and tool-call completions are captured verbatim. The
@@ -94,9 +99,9 @@ export class JobLogRenderer {
         this.planSteps = steps.map((s) => ({ ...s }));
     }
     /**
-     * A job's test run is exactly the kind of outcome `cruxy logs` exists to
-     * show. Plain text, no theme glyphs, matching this log's `[ok]`/`[fail]`
-     * style — and no count this renderer was not given.
+     * A job's test run is exactly the kind of outcome a job log exists to show.
+     * Plain text, no theme glyphs, matching this log's `[ok]`/`[fail]` style —
+     * and no count this renderer was not given.
      */
     testResult(report) {
         const counted = report.total !== undefined