@ducci/jarvis 1.0.38 → 1.0.39

package/docs/findings/010-checkpoint-field-type-safety.md

@@ -1,121 +0,0 @@
-# Finding 010: Non-String `checkpoint.remaining` Crashes Zero-Progress Detection
-
-**Date:** 2026-03-01
-**Severity:** High — caused "Sorry, something went wrong" in Telegram with no useful context; crashed the handoff loop mid-run
-**Status:** Fixed
-
----
-
-## Observed Session
-
-The session ran 13+ agent runs working on OWASP ZAP installation. Runs 8–13 were consecutive `checkpoint_reached` handoffs. On entry 14 (immediately after entry 13), the server logged:
-
-```
-status: error
-response: "An unexpected server error occurred: (run.checkpoint.remaining || "").trim is not a function"
-```
-
-The Telegram user received:
-
-```
-Sorry, something went wrong: (run.checkpoint.remaining || "").trim is not a function
-```
-
----
-
-## Bug Chain
-
-### Step 1 — Wrap-up call returns non-string `remaining`
-
-At iteration limit, `runAgentLoop` sends the `WRAP_UP_NOTE` and parses the model's JSON response. The model returned `checkpoint.remaining` as a non-string value (array or object) instead of a plain text string. `parsedWrapUp.checkpoint` was stored and returned with no type validation.
-
-### Step 2 — Zero-progress detection crashes on `.trim()`
-
-In `_runHandleChat`, finding 007 introduced zero-progress detection:
-
-```js
-const currentRemaining = (run.checkpoint.remaining || '').trim();
-```
-
-The `|| ''` guard only catches falsy values (null, undefined). A truthy non-string (array, object) passes through the `||` and `.trim()` is called on a non-string:
-
-```
-TypeError: (run.checkpoint.remaining || "").trim is not a function
-```
-
-### Step 3 — Outer catch logs the error and re-throws
-
-The `try/catch` at the top of the handoff loop caught the TypeError, wrote an `error` status log entry, and re-threw. The Telegram handler surfaced the raw error message.
-
----
-
-## Secondary Issues
-
-**`resumeContent` (line 520)**: `run.checkpoint.remaining || 'Continue with the task.'` — if `remaining` is a truthy non-string, it would be pushed directly into `session.messages` as the next user message content. The message API expects a string, so this would produce a malformed conversation message.
-
-**`failedApproaches` spread (lines 461–463)**: If the model returns `failedApproaches` as a non-array (string, object), `push(...value)` would spread wrong data. A string spreads individual characters; an object spreads its enumerable values.
-
----
-
-## Root Cause
-
-Same class of bug as finding 009 (non-string `response` field). Finding 009 hardened `response` and `logSummary` extraction, but the `checkpoint` sub-object fields were not included in that hardening pass. Models — especially smaller/free models under iteration-limit pressure — sometimes return structured data (arrays, objects) in fields the system prompt specifies as plain text strings.
-
----
-
-## Fix
-
-### `src/server/agent.js` — normalize checkpoint fields at source
-
-Added a normalization block immediately inside the `if (parsedWrapUp.checkpoint)` branch, before any checkpoint field is accessed downstream:
-
-```js
-const cp = parsedWrapUp.checkpoint;
-// remaining must be a string — used as the next run's resume prompt
-if (typeof cp.remaining !== 'string') {
-  cp.remaining = Array.isArray(cp.remaining)
-    ? cp.remaining.map(String).join('\n')
-    : cp.remaining != null ? JSON.stringify(cp.remaining) : '';
-}
-// failedApproaches must be an array of strings — spread into session metadata
-if (!Array.isArray(cp.failedApproaches)) {
-  cp.failedApproaches = [];
-} else {
-  cp.failedApproaches = cp.failedApproaches.map(item =>
-    typeof item === 'string' ? item : JSON.stringify(item)
-  );
-}
-```
-
-**Array coercion for `remaining`**: when the model returns an array (e.g., `["install Java", "create symlink"]`), elements are joined with newlines rather than JSON-stringified — producing a natural readable resume prompt rather than raw JSON syntax.
-
-**Centralized normalization**: fixing at source (right after parse) rather than at each use site means lines 469 and 520 need no change. Any future use of `checkpoint.remaining` or `checkpoint.failedApproaches` is automatically safe.
-
-### `src/server/agent.js` — update `WRAP_UP_NOTE`
-
-Added explicit type constraints to the `remaining` field description and a trailing instruction:
-
-```
-"remaining": "What still needs to be done — as a plain text string, never an array or object."
-...
-remaining must be a plain text string. failedApproaches must be a JSON array of strings.
-```
-
----
-
-## What Was Not Changed
-
-- `agent.js` lines 469 and 520 — no changes needed; normalization at source makes them safe
-- `src/channels/telegram/index.js` — finding 007 and 009 already added `.catch(() => {})` and type guards on delivery
-- `sessions.js`, `tools.js` — no changes needed
-
----
-
-## Outcome
-
-| Fix | Files changed |
-|-----|--------------|
-| Normalize `checkpoint.remaining` to string and `checkpoint.failedApproaches` to string array at source | `src/server/agent.js` |
-| Add explicit type constraints to WRAP_UP_NOTE | `src/server/agent.js` |
-
-**Effect**: instead of a `TypeError` crash mid-handoff-loop, the model's non-string `remaining` value is coerced to a readable string and used as the resume prompt. The session continues normally.

package/docs/findings/011-empty-model-response.md

@@ -1,157 +0,0 @@
-# Finding 011: Empty Model Response Causes Generic Telegram Error
-
-**Date:** 2026-03-01
-**Severity:** High — user sees generic "please try again" with no actionable information
-**Status:** Fixed
-
----
-
-## Observed Session
-
-Session `33a50dfe-38ea-4972-adac-498ef0525b0c`, run 16 of 17 (session.jsonl line 16):
-
-```
-status=format_error
-model=nvidia/nemotron-3-nano-30b-a3b:free
-iteration=4
-userInput='Ok. Kannst du bitte jetzt das shell script ausführen mit der domain...'
-logSummary='Model returned non-JSON final response after recovery attempts.'
-rawResponse=''
-response=''
-```
-
-The Telegram user received:
-
-```
-The agent encountered an error and could not produce a response. Please try again.
-```
-
----
-
-## What Happened
-
-The agent executed a ZAP scan (`./scan.sh juice-shop.herokuapp.com`). The tool result was a large ZAP startup log, truncated at 4000 characters. Two subsequent tool calls failed:
-
-- `pkill -f zaproxy || true` → exit 1 (no process to kill)
-- `zaproxy -help | grep -i shutdown -A5` → failed (`libtiff.so.5` missing)
-
-On iteration 4, the model returned `assistantMessage.content = null` with no `tool_calls`. This is the "went silent" case: the model produced neither a response nor another tool call.
-
----
-
-## Bug Chain
-
-### Step 1 — Model returns null content
-
-```js
-let content = assistantMessage.content || '';
-// content = ''
-```
-
-### Step 2 — Recovery chain falls through on empty content
-
-The existing format recovery chain was designed for *non-empty, non-JSON* responses:
-
-1. `JSON.parse('')` → throws
-2. Retry with fallback model (same messages, no nudge) → also `''`
-3. Retry with nudge "Your previous response was not valid JSON" → technically wrong for empty content; model still returns `''`
-4. Give up
-
-### Step 3 — Empty `response` propagates to Telegram
-
-```js
-response = content; // ''
-```
-
-`handleChat` returns `{ response: '', ... }`. In `telegram/index.js`:
-
-```js
-const rawResponse = typeof result.response === 'string' ? result.response : ...;
-// rawResponse = ''
-const text = rawResponse.trim() || 'The agent encountered an error...';
-// '' → fallback shown
-```
-
-The user sees the generic Telegram fallback instead of any information about what happened or what to do.
-
----
-
-## Root Causes
-
-**Primary**: The `format_error` path set `response = content` without a fallback for the empty string case. An empty `response` triggers the Telegram handler's last-resort fallback message, giving the user no context.
-
-**Secondary**: The format recovery chain was designed for non-empty non-JSON responses. When `content` is empty, the nudge message "Your previous response was not valid JSON" is inaccurate — the model produced nothing, not invalid JSON. A targeted nudge for the empty case increases the chance of recovery.
-
-**Model-level cause**: The free model `nvidia/nemotron-3-nano-30b-a3b:free` can fail to produce any output after processing a heavily truncated tool result followed by consecutive tool failures. This is a model quality limitation that the recovery layer must account for.
-
----
-
-## Difference from Finding 009 and 010
-
-| Finding | Model produces... | Bug manifests at... |
-|---------|-------------------|---------------------|
-| 009 | Non-string `response` field (array/object) | Telegram `.trim()` crash |
-| 010 | Non-string `checkpoint.remaining` | Zero-progress `.trim()` crash |
-| 011 | Empty/null content (no text, no tool calls) | Telegram generic fallback (no crash, but useless to user) |
-
-Finding 011 is the third in the same class: model output type does not match what the system expects.
-
----
-
-## Fix
-
-### `src/server/agent.js` — two changes
-
-**1. Empty-content detection with targeted nudge**
-
-When `content` is empty, skip the standard recovery chain (designed for non-JSON text) and apply a targeted nudge that accurately describes the situation:
-
-```js
-if (!content.trim()) {
-  // Model returned no content at all — use a targeted nudge instead of the
-  // standard JSON recovery chain (designed for non-empty non-JSON responses).
-  try {
-    const emptyNudge = [
-      ...preparedMessages,
-      { role: 'user', content: 'You returned an empty response. ' + FORMAT_NUDGE },
-    ];
-    const nudgeResult = await callModelWithFallback(client, config, emptyNudge, toolDefs);
-    const nudgeContent = nudgeResult.choices[0]?.message?.content || '';
-    parsed = JSON.parse(nudgeContent);
-    content = nudgeContent;
-  } catch {
-    // Give up — fall through to !parsed handler below
-  }
-} else {
-  // Non-empty content — use the existing 3-step JSON recovery chain
-  try { parsed = JSON.parse(content); } catch {
-    // Step 1: fallback model...
-    // Step 2: nudge...
-  }
-}
-```
-
-**2. Non-empty fallback on format_error**
-
-```js
-if (!parsed) {
-  // Ensure response is never empty so the delivery layer can show something
-  // meaningful rather than its generic fallback message.
-  response = content.trim() || 'The model did not produce a response. Please try again.';
-  logSummary = 'Model returned non-JSON final response after recovery attempts.';
-  status = 'format_error';
-  return { ... };
-}
-```
-
----
-
-## Outcome
-
-| Scenario | Before | After |
-|----------|--------|-------|
-| Model returns empty content, nudge succeeds | format_error (3 wasted API calls) | Clean recovery (1 targeted API call) |
-| Model returns empty content, nudge fails | Telegram generic fallback | "The model did not produce a response. Please try again." |
-| Model returns non-JSON text, all recovery fails | Telegram generic fallback (if text was empty) | Raw model output shown to user |
-
-**Effect on the debugging session**: instead of the generic Telegram fallback, the user would have received "The model did not produce a response. Please try again." — a clear signal that the model failed, not their message. In the best case, the new targeted nudge would have elicited a valid JSON response.

package/docs/findings/012-empty-nudge-loses-recovery-text.md

@@ -1,121 +0,0 @@
-# Finding 012: Empty-Content Nudge Includes Tools and Loses Recovery Text
-
-**Date:** 2026-03-02
-**Severity:** Medium — user sees generic error when model produces a partial recovery response
-**Status:** Fixed
-
----
-
-## Observed Session
-
-Session `21fb43a7-2b11-4208-99fb-e6b54fddc07b`, entry 9 in session.jsonl:
-
-```
-status=format_error
-model=nvidia/nemotron-3-nano-30b-a3b:free
-iteration=3
-userInput='Ok. Read the results folder. Is there anything?'
-logSummary='Model returned non-JSON final response after recovery attempts.'
-response='The model did not produce a response. Please try again.'
-```
-
-The user received: **"The model did not produce a response. Please try again."**
-
----
-
-## What Happened
-
-1. The agent executed two tool calls:
-   - `list_dir /root/.jarvis/projects/cybersecurity/results` → success
-   - `exec "list_dir /root/.jarvis/projects/cybersecurity/results/dviet.de"` → exit 127 (`list_dir: not found`)
-     - The model confused the `list_dir` jarvis tool with a shell command
-
-2. After the failed exec, the model returned `assistantMessage.content = null` with no `tool_calls` — it "went silent"
-
-3. Finding 011's empty-content nudge was triggered
-
-4. The nudge **also failed** — no valid JSON response was produced
-
-5. The agent fell through to `format_error` with the fallback message
-
----
-
-## Bug Chain
-
-### Bug 1 — toolDefs included in empty nudge
-
-```js
-const nudgeResult = await callModelWithFallback(client, config, emptyNudge, toolDefs);
-```
-
-When the model is confused after a tool failure, it may respond to the nudge with **another tool call** instead of text. If it does:
-
-```
-nudgeResult.choices[0].message.content = null
-nudgeContent = ''
-JSON.parse('') → throws
-catch: // Give up — content stays ''
-```
-
-The model had an opportunity to call more tools instead of producing a text response — the wrong behavior for a recovery nudge.
-
-### Bug 2 — content assigned after parse
-
-```js
-const nudgeContent = nudgeResult.choices[0]?.message?.content || '';
-parsed = JSON.parse(nudgeContent);   // ← throws on non-JSON or empty
-content = nudgeContent;              // ← only reached if parse succeeded
-```
-
-If the model responds to the nudge with non-empty but non-JSON text (e.g. a plain English answer), `JSON.parse` throws and `content` is **never updated**. The non-JSON text is discarded. The `!parsed` handler then shows the fallback message instead of the model's actual text.
-
----
-
-## Difference from Finding 011
-
-| Finding | Problem | Trigger |
-|---------|---------|---------|
-| 011 | Empty model response propagates to Telegram | Initial empty content, no recovery chain |
-| 012 | Recovery nudge discards best-effort text; model can respond with tool call | Recovery nudge called with toolDefs + content assigned after parse |
-
-Finding 012 is a refinement of the recovery path introduced in Finding 011.
-
----
-
-## Fix
-
-### `src/server/agent.js` — empty-content nudge block
-
-**Before:**
-```js
-const nudgeResult = await callModelWithFallback(client, config, emptyNudge, toolDefs);
-const nudgeContent = nudgeResult.choices[0]?.message?.content || '';
-parsed = JSON.parse(nudgeContent);
-content = nudgeContent;
-```
-
-**After:**
-```js
-// No tools: force text response, prevent model from calling another tool
-const nudgeResult = await callModelWithFallback(client, config, emptyNudge, []);
-const nudgeContent = nudgeResult.choices[0]?.message?.content || '';
-// Persist before parsing — if JSON parse throws, content still carries the
-// model's best-effort text so the !parsed handler can show it to the user
-if (nudgeContent.trim()) {
-  content = nudgeContent;
-}
-parsed = JSON.parse(nudgeContent);
-```
-
----
-
-## Outcome
-
-| Nudge response | Before | After |
-|---|---|---|
-| Valid JSON | Clean recovery | Clean recovery (no change) |
-| Non-JSON text | Text discarded, fallback shown | Text shown to user |
-| Tool call (no content) | content='', fallback shown | Less likely; content='', fallback shown |
-| Empty again | content='', fallback shown | content='', fallback shown (no change) |
-
-The user in the observed session would have received the model's best-effort text about the results folder contents, rather than "The model did not produce a response. Please try again."

package/docs/findings/013-stderr-visibility-and-truncation.md

@@ -1,59 +0,0 @@
-# Finding 013 — stderr Visibility and Output Truncation
-
-## Observed Behaviour
-
-During a multi-run ZAP security scan session, the agent repeatedly failed to diagnose and fix the root cause of scan failures. It issued `pkill`/`kill` variants dozens of times, burned through 6 iteration limits and 2 handoffs, and ultimately gave up without producing results.
-
-Post-mortem analysis of the debug session logs revealed two compounding problems.
-
-## Root Causes
-
-### 1. Head-only truncation buried errors at the end of output
-
-`MAX_TOOL_RESULT = 4000` was applied as a simple head slice: `resultStr.slice(0, 4000)`. ZAP produces verbose startup logs (JVM init, add-on loading, database migration) that easily exceed 4000 characters. Five separate ZAP exec results were truncated exactly at the limit, cutting off during database migration messages. Any errors that appeared later in the output — after the verbose preamble — were silently dropped before the model ever saw them.
-
-### 2. Model ignored stderr even when it was visible
-
-In one un-truncated result (810 chars), the critical error was plainly present:
-
-```
-g_module_open() failed for libpixbufloader-tiff.so: libtiff.so.5: cannot open shared object file: No such file or directory
-```
-
-The model's subsequent response ignored it entirely and concluded only that "no results were found in the output directory." There was no mechanism forcing the model to re-examine stderr before forming its conclusion or retrying.
-
-Similarly, all `pkill`/`kill` commands returned `exitCode: 1` with clear stderr — yet the model continued issuing variations of the same commands without diagnosing why process termination was failing.
-
-## Fixes
-
-### Fix 1 — Head + tail truncation (`agent.js`)
-
-Replace head-only truncation with a head+tail strategy:
-
-```js
-// Before
-resultStr.slice(0, MAX_TOOL_RESULT) + '\n[...truncated]'
-
-// After
-resultStr.slice(0, 2000) + `\n[...${resultStr.length - 4000} chars truncated...]\n` + resultStr.slice(-2000)
-```
-
-The first 2000 chars preserve startup context; the last 2000 chars preserve the diagnostic tail where errors typically appear. The marker in the middle shows how much was dropped. Total budget stays at 4000 chars.
-
-### Fix 2 — Stderr nudge injection (`agent.js`)
-
-After each iteration's tool-call loop, if any tool failed (`status === 'error'`) with non-empty `stderr`, inject a system message:
-
-```
-[System: A command failed and produced stderr output. Examine the stderr field in the tool result carefully — it likely describes the root cause of the failure. Do not retry the same command without first addressing what stderr reports.]
-```
-
-This creates an active forcing function — the model cannot continue to the next iteration without the nudge appearing in its context. The nudge is suppressed if loop detection already fired (to avoid contradictory instructions).
-
-## Known Gap
-
-The stderr nudge only fires when `toolFailed` is true (i.e., `exec` returned `status: 'error'`). Commands that return `exitCode: 0` but still emit meaningful errors to stderr (e.g., a shell script that succeeds but a subprocess inside it fails) will not trigger the nudge. Catching that case without generating noise from normal stderr usage (npm warnings, apt-get progress) requires more context than is available at this level. Documented as a known limitation.
-
-## Files Changed
-
-- `src/server/agent.js` — truncation strategy + stderr nudge injection

package/docs/findings/014-exec-stderr-artifact-and-malformed-tool-args.md

@@ -1,202 +0,0 @@
-# Finding 014: exec stderr Artifact and Malformed Tool Call Arguments
-
-**Date:** 2026-03-02
-**Severity:** Medium — caused spurious context noise (spurious nudges), agent confusion on malformed args, and silent loss of failedApproaches across user turns
-**Status:** Fixed
-
----
-
-## Observed Session
-
-Session `d97070f7-e50f-4d9e-a38b-b68e7b27e7b7`. User asked Jarvis to set up an OWASP ZAP web security scanning project. The session ran 4 runs (40 total iterations) without completing the task. The snap-installed ZAP does not include `zap-baseline.sh` (which only ships in the ZAP Docker image); the agent never discovered that `zaproxy -cmd -quickurl` is the correct snap-native CLI equivalent.
-
-Three compounding issues were identified that degraded the agent's ability to self-correct.
-
----
-
-## Issue 1: exec Tool Injects Node.js Error Message into `stderr` Field
-
-### What happened
-
-Commands like `which zap-cli` (not installed), `grep` returning no matches, and piped `find | grep` with no results all return exit code 1. In each case the actual process wrote nothing to stderr. But the exec tool result showed:
-
-```json
-{"status":"error","exitCode":1,"stdout":"","stderr":"Command failed: which zap-cli\n"}
-```
-
-The `"Command failed: ..."` string is not from the process — it is `e.message` from Node.js's `execAsync` error object, injected via `e.stderr || e.message`.
-
-The stderr nudge check in `agent.js` fires on any non-empty `resultObj.stderr`:
-
-```js
-if (resultObj && resultObj.stderr) {
-  stderrErrorInIteration = true;
-}
-```
-
-This triggered the nudge "Examine the stderr field carefully — it likely describes the root cause of the failure" 3–4 times per run, when there was nothing actionable to examine in stderr.
-
-### Root cause
-
-In the exec seed tool (`src/server/tools.js`, line 76):
-
-```js
-return { status: "error", exitCode: e.code || 1, stdout: e.stdout || "", stderr: e.stderr || e.message };
-```
-
-The `|| e.message` fallback was designed to show something when `e.stderr` is empty. But it conflates process-generated stderr with Node.js meta-messages about the process exiting non-zero.
-
-### Fix
-
-```js
-// Before:
-return { status: "error", exitCode: e.code || 1, stdout: e.stdout || "", stderr: e.stderr || e.message };
-
-// After:
-return { status: "error", exitCode: e.code || 1, stdout: e.stdout || "", stderr: e.stderr || "" };
-```
-
-`status: error` and `exitCode` already signal failure. The "Command failed: ..." Node.js string is not diagnostic and should not appear in the stderr field.
-
-**File**: `src/server/tools.js` — exec seed tool code (propagates via seedTools() on next server start)
-
----
-
-## Issue 2: Malformed Tool Call JSON Arguments Silently Swallowed
-
-### What happened
-
-The model sent a tool call with malformed arguments (missing opening `{`):
-
-```json
-{"name": "exec", "arguments": "\"cmd\": \"find /snap/zaproxy/current -type f -name '*.sh' | head -10\"}"}
-```
-
-`JSON.parse` threw, the catch block silently used `toolArgs = {}`, and the exec tool failed with:
-
-```
-{"status":"error","exitCode":"ERR_INVALID_ARG_TYPE","stdout":"","stderr":"The \"command\" argument must be of type string. Received undefined"}
-```
-
-The model saw `ERR_INVALID_ARG_TYPE` / "Received undefined" — no indication that the JSON formatting was wrong. The stderr nudge also fired (Issue 1 compounding: `err.message` put in stderr).
-
-### Root cause
-
-In `src/server/agent.js`:
-
-```js
-try {
-  toolArgs = JSON.parse(toolCall.function.arguments || '{}');
-} catch {
-  toolArgs = {};
-}
-```
-
-The JSON parse error is swallowed. The tool is called with empty args. The resulting type error is cryptic and doesn't tell the model to fix its JSON.
-
-### Fix
-
-Detect the parse failure early, push an explicit error tool result, and skip execution:
-
-```js
-let toolArgs;
-let argParseError = null;
-try {
-  toolArgs = JSON.parse(toolCall.function.arguments || '{}');
-} catch (e) {
-  argParseError = e;
-}
-
-if (argParseError) {
-  const errorContent = JSON.stringify({
-    status: 'error',
-    error: `Tool arguments could not be parsed as JSON: ${argParseError.message}. Ensure arguments are a valid JSON object, e.g. {"key": "value"}.`,
-  });
-  session.messages.push({ role: 'tool', tool_call_id: toolCall.id, content: errorContent });
-  runToolCalls.push({ name: toolName, args: {}, status: 'error', result: errorContent });
-  consecutiveFailures++;
-  continue;
-}
-```
-
-The model immediately sees "Tool arguments could not be parsed as JSON" instead of an opaque `ERR_INVALID_ARG_TYPE`. It can fix its JSON and retry.
-
-**File**: `src/server/agent.js` — inner tool execution loop
-
----
-
-## Issue 3: Accumulated failedApproaches Cleared on New User Message
-
-### What happened
-
-In multi-run sessions where multiple checkpoint handoffs accumulate `session.metadata.failedApproaches`, the next user message resets this list to `[]`:
-
-```js
-session.metadata.handoffCount = 0;
-session.metadata.failedApproaches = [];
-```
-
-This was designed to give the model a clean slate after human review. But "Ok do it" is not a review — it's a continuation. The model loses knowledge of what was already tried and can repeat the same failed strategies in the new round of runs.
-
-(Note: in this specific session run 1 ended with `ok`, so `failedApproaches` was empty at reset time anyway. But in sessions where checkpoint runs accumulate a list, the reset discards it entirely.)
-
-### Fix
-
-Embed accumulated `failedApproaches` into the incoming user message before resetting:
-
-```js
-let userMessageWithContext = userMessage;
-if (session.metadata.failedApproaches && session.metadata.failedApproaches.length > 0) {
-  userMessageWithContext += `\n\n[System: The following approaches were tried and failed in previous runs — consider them exhausted:\n${session.metadata.failedApproaches.map((a, i) => `${i + 1}. ${a}`).join('\n')}]`;
-}
-session.messages.push({ role: 'user', content: userMessageWithContext });
-session.metadata.handoffCount = 0;
-session.metadata.failedApproaches = [];
-```
-
-The model enters the new round with awareness of what has already been exhausted. If the user's message implies a fresh task, the model can ignore the list; if it's a continuation, it benefits from the context.
-
-**File**: `src/server/agent.js` — `_runHandleChat`, before user message push
-
----
-
-## Issue 4: WRAP_UP_NOTE Did Not Require Verified Progress Claims
-
-### What happened
-
-Runs 2 and 3 claimed to have created project directories and files in the `progress` field of their checkpoints — but their tool calls contained no file creation commands. The model fabricated progress, causing subsequent resume messages to start from false premises.
-
-### Fix
-
-Updated the `progress` field description in `WRAP_UP_NOTE`:
-
-```
-// Before:
-"progress": "What has been fully completed so far.",
-
-// After:
-"progress": "What has been fully completed — only include items confirmed by tool output (e.g., successful exec with exit code 0, or verified by ls/cat). Do not report planned steps as completed.",
-```
-
-**File**: `src/server/agent.js` — `WRAP_UP_NOTE` constant
-
----
-
-## Secondary Observations (Not Fixed)
-
-**zap-baseline.sh does not exist in snap ZAP**: This script is part of the ZAP Docker image. The snap installation provides `zaproxy -cmd -quickurl <url> -quickout <file>` instead, which is visible in `zaproxy -help` output. The agent saw this output but never connected it to the need for a baseline scan. This is a model knowledge gap.
-
-**Zero-progress detection correctly did not fire**: Runs 2 and 3 had genuinely different `remaining` strings (run 3 claimed partial progress). The detection works as designed; the circumvention was through model hallucination of progress, not a code bug.
-
-**failedApproaches from `ok`-status runs are not captured**: Run 1 ended with `status: ok` despite having 10 iterations of failed searches. The `failedApproaches` mechanism only captures failures from `checkpoint_reached` runs. Capturing failures from `ok`-status runs would require the model to include a `failedApproaches` field in its final response — a more significant protocol change left for a future finding.
-
----
-
-## Files Changed
-
-| File | Change |
-|------|--------|
-| `src/server/tools.js` | exec seed tool: `e.stderr \|\| ''` instead of `e.stderr \|\| e.message` |
-| `src/server/agent.js` | Malformed JSON args: inject error tool result instead of silent `{}` |
-| `src/server/agent.js` | Preserve failedApproaches in user message before resetting |
-| `src/server/agent.js` | Strengthen WRAP_UP_NOTE `progress` field description |