zames_pro 2.82.140 → 2.82.142

package/skills/systematic-debugging/SKILL.md

@@ -27,6 +27,13 @@ Shrink the failure to the smallest unit that still fails.
   remember writing.
 - Check the obvious causes FIRST: wrong file, stale build, cached state,
   different config, an earlier error swallowed by a catch.
+- In zames the evidence is already on disk: the transcript at
+  `~/.zames/logs/*.jsonl` (`/transcript` prints the exact path of THIS run),
+  the raw answer bodies under `~/.zames/net-log` when started with
+  `ZAMES_NET_DEBUG=1` (`npm run dev` sets it), and the per-send telemetry at
+  `~/.zames/logs/sends-<provider>.jsonl` (written in dev mode and when
+  `browser.sendTelemetry` is on). Read them BEFORE guessing — most "it hangs
+  / it stopped" reports are visible there.
 
 ## Phase 3 — Hypothesize (one at a time)
 

package/skills/test-driven-development/SKILL.md

@@ -32,3 +32,8 @@ RED → GREEN → REFACTOR. The order is the point, not a formality.
   CODE was wrong; do not just move the assertion.
 - If the code was written before its test, delete and rewrite it driven by
   the test — otherwise the test is shaped around the implementation.
+- A test that writes a temp dir or file cleans it up itself: in this repo
+  always go through `test/tmp-dir.ts` (`makeTmpDir(t, prefix)` /
+  `makeTmpDirSync`), which registers the `t.after` cleanup. On WSL a leaked
+  `os.tmpdir()` entry lives inside ext4.vhdx and never returns its space to
+  the Windows host, so an abandoned temp dir fragments the disk permanently.

package/skills/verification-before-completion/SKILL.md

@@ -24,6 +24,11 @@ from the real artifact — not from your intent.
 5. **State the evidence** in the final report — the exact command and its
    result — so the operator can reproduce it. "Tests pass" without the
    command is not evidence.
+6. **In zames the report is ONE `respond` call.** A long task may have
+   produced several findings along the way; the operator only ever reads the
+   LAST `respond` before the run stops, so put the complete evidence there —
+   never split it across intermediate messages, and never end a turn on a
+   bare text update with work still pending.
 
 ## The two failure modes this prevents
 

package/skills/writing-plans/SKILL.md

@@ -38,3 +38,15 @@ Because there is no separate plan file unless the operator asks for one, the
 plan lives in your reasoning and, for a long task, in a TodoWrite list — one
 entry per step, status updated as you go. Do not narrate the plan to the
 operator between tool calls; the todo list IS the visible plan.
+
+Two more constraints follow from the same design:
+
+- **A plan is not a report.** The operator sees ONLY the last `respond`
+  before the run stops, so the plan and the per-step evidence must not be
+  split across intermediate messages — put the final evidence in that one
+  `respond`.
+- **Subagents do not parallelise the plan.** A `Task` call runs in a FRESH
+  isolated chat and returns only a report; zames has ONE browser and ONE send
+  slot, so subagents are SEQUENTIAL. Use them to keep a broad read-only
+  investigation out of the main context — never to "go faster", and never for
+  a step that must be applied in order with the main chat.

package/dist/code-blocks.js

@@ -1,54 +0,0 @@
-// PURE extraction of fenced code blocks from a Markdown answer. It returns the
-// RAW fenced text: the highlighted render is full of ANSI and must never be
-// what gets copied out of the TUI.
-/**
- * Extract every fenced code block (``` or ~~~) from `md`, in order. Handles a
- * longer closing fence than the opening one and an unterminated final block
- * (the answer was truncated) — a half block is still copyable.
- */
-export function extractCodeBlocks(md) {
-    const lines = String(md ?? '').split(String.fromCharCode(10));
-    const out = [];
-    let i = 0;
-    let n = 0;
-    while (i < lines.length) {
-        // The info string may contain a BACKTICK (CommonMark forbids it, models
-        // write it anyway: ```` ```ts` ````, ```` ```c++ `std::vector` ````). The
-        // old `[^`]*` rejected such a line, so the block's own CLOSING fence was
-        // read as an OPENING one and the following prose became a bogus block.
-        const m = /^(\s*)(`{3,}|~{3,})\s*(.*)$/.exec(lines[i]);
-        if (!m) {
-            i++;
-            continue;
-        }
-        // A BACKTICK fence cannot carry a backtick in its info (that is what makes
-        // it unparseable for CommonMark); treat the trailing text as prose after a
-        // plain fence only when the line is exactly a fence. For our purpose the
-        // pragmatic rule is: any trailing text is the language label, backticks
-        // stripped.
-        const fence = m[2];
-        const marker = fence[0];
-        const minLen = fence.length;
-        const lang = (m[3] || '').replace(/`/g, '').trim();
-        i++;
-        const body = [];
-        let closed = false;
-        while (i < lines.length) {
-            // A closing fence is the SAME marker, at least as long, with nothing
-            // else on the line (whitespace allowed).
-            const c = new RegExp('^\\s*' + marker + '{' + minLen + ',}\\s*$');
-            if (c.test(lines[i])) {
-                closed = true;
-                i++;
-                break;
-            }
-            body.push(lines[i]);
-            i++;
-        }
-        if (body.length === 0 && closed)
-            continue;
-        n++;
-        out.push({ lang, text: body.join(String.fromCharCode(10)), index: n });
-    }
-    return out;
-}