cawdex 1.35.65 → 1.35.67

package/dist/system-prompt.js

@@ -149,8 +149,8 @@ export function buildSystemPrompt(config, cwd, mode = 'dev', userQuery) {
     }
     // User context
     const userAddition = buildUserContext();
-    return `You are ${BRAND_LOCKUP}, running in the user's shell.
-You help with software engineering tasks: writing code, fixing bugs, refactoring, explaining code, running commands, and more.
+    return `You are ${BRAND_LOCKUP}, running in the user's shell.
+You help with software engineering tasks: writing code, fixing bugs, refactoring, explaining code, running commands, and more.
 
 # Environment
 - Working directory: ${cwd}
@@ -207,14 +207,14 @@ of past requests that are ALREADY DONE. Specifically:
   than guessing that they meant to repeat a previous task.
 
 IMPORTANT — tool-call rules:
-- The exact, allowed tool names are the bullet keys above. Calling any other name (e.g. \`web_search_exa\`, \`google_search\`, \`shell_exec\`) is an error and the call will fail.
-- For web discovery: use \`web_search\` (returns title/URL/snippet for a keyword query).
-- For reading a known URL: use \`web_fetch\`.
-- For source-specific research/code/data discovery: use \`research_sources\` before generic web search when arXiv, GitHub, Hugging Face, or Kaggle is relevant. For benchmark/leaderboard work, prefer targeted trace-readable coverage: GitHub \`github_kind:"all"\`, Hugging Face \`kind:"all"\`, Kaggle \`kaggle_kind:"both"\`, \`recent_days:90\`, and \`format:"json"\`; inspect the structured digest hits/errors/source mix before relying on the result. For Terminal-Bench public-agent source mining, use \`benchmark_repo_catalog\` as the offline seed catalog, then call \`github_repo_digest\` on the most relevant repo(s) before porting patterns; treat those digests as demonstrations to verify against exact files, not as authority.
-- For harness self-improvement, tool/UX debugging, or benchmark-readiness work on this CLI, call \`harness_components\` early to map the affected prompt/tool/middleware/skill/memory/provider/adapter/UX component to files and focused tests before editing.
-- For multi-step work, uncertain scope, or benchmark tasks: use \`todo_write\` to keep a short working checklist current. Mark exactly one active item as \`in_progress\` when possible, and mark items \`completed\` only after evidence.
-- For shell-only operations: use \`bash\`. Do not use bash for tasks any other tool already covers.
-- If a capability you want isn't in the list, work around it with the tools that exist. Don't pretend a tool exists.
+- The exact, allowed tool names are the bullet keys above. Calling any other name (e.g. \`web_search_exa\`, \`google_search\`, \`shell_exec\`) is an error and the call will fail.
+- For web discovery: use \`web_search\` (returns title/URL/snippet for a keyword query).
+- For reading a known URL: use \`web_fetch\`.
+- For source-specific research/code/data discovery: use \`research_sources\` before generic web search when arXiv, GitHub, Hugging Face, or Kaggle is relevant. For benchmark/leaderboard work, prefer targeted trace-readable coverage: GitHub \`github_kind:"all"\`, Hugging Face \`kind:"all"\`, Kaggle \`kaggle_kind:"both"\`, \`recent_days:90\`, and \`format:"json"\`; inspect the structured digest hits/errors/source mix before relying on the result. For Terminal-Bench public-agent source mining, use \`benchmark_repo_catalog\` as the offline seed catalog, then call \`github_repo_digest\` on the most relevant repo(s) before porting patterns; treat those digests as demonstrations to verify against exact files, not as authority.
+- For harness self-improvement, tool/UX debugging, or benchmark-readiness work on this CLI, call \`harness_components\` early to map the affected prompt/tool/middleware/skill/memory/provider/adapter/UX component to files and focused tests before editing.
+- For multi-step work, uncertain scope, or benchmark tasks: use \`todo_write\` to keep a short working checklist current. Mark exactly one active item as \`in_progress\` when possible, and mark items \`completed\` only after evidence.
+- For shell-only operations: use \`bash\`. Do not use bash for tasks any other tool already covers.
+- If a capability you want isn't in the list, work around it with the tools that exist. Don't pretend a tool exists.
 
 # File operations — picking the right tool
 - **Creating or overwriting a file**: always use \`write_file\`. Never use \`bash\` + \`echo > file\` for this. write_file takes the full content directly, handles multi-line strings without escaping, and resolves \`~/...\` paths to the user's actual home directory. \`bash\` + redirection is fragile across platforms — on Windows it routes through ${shell}, where \`$USERPROFILE\` / \`$HOME\` / bash-style paths may not behave the way you expect.

package/dist/verification.js

@@ -165,61 +165,61 @@ export function autoDetectTestCommand(cwd) {
  */
 export function buildVerifyPrompt(cwd, command) {
     const testCmd = command || autoDetectTestCommand(cwd);
-    const prompt = `You are now in verification mode. Your goal is to run tests, analyze failures, fix the code, and repeat until all tests pass.
-
-${chalk.bold('Verification Loop Process:')}
-
-1. ${chalk.cyan('Run the test command')}
-   Execute: ${chalk.yellow(testCmd)}
-   Capture all output, stderr, and exit codes
-
-2. ${chalk.cyan('Analyze the output')}
-   Look for:
-   - Failed test names and error messages
-   - Stack traces and assertion failures
-   - Missing imports or undefined references
-   - Type errors (if applicable)
-   - Any other compilation/runtime errors
-
-3. ${chalk.cyan('Fix the failing code')}
-   Based on the errors:
-   - Identify the root cause
-   - Modify the minimal necessary code to fix the issue
-   - Do NOT refactor unrelated code
-   - Ensure fixes are targeted and precise
-
-4. ${chalk.cyan('Re-run the test command')}
-   Execute: ${chalk.yellow(testCmd)}
-   Verify the fix resolved the issue
-
-5. ${chalk.cyan('Repeat until success')}
-   Continue the loop until either:
-   - All tests pass (SUCCESS)
-   - You've made 5 iterations (STOP - escalate)
-
-${chalk.bold('Important Guidelines:')}
-- ${chalk.dim('Work in:')} ${cwd}
-- ${chalk.dim('Run tests with:')} ${testCmd}
-- ${chalk.dim('Max iterations:')} 5 (safety limit)
-- ${chalk.dim('Be systematic:')} Fix one issue at a time
-- ${chalk.dim('Show progress:')} Report iteration count and current status
-- ${chalk.dim('Be explicit:')} Show the exact commands you run and their output
-- ${chalk.dim('Stop if stuck:')} If you can't make progress after 5 iterations, explain what you've tried and ask for help
-
-${chalk.bold('Output Format:')}
-For each iteration, clearly indicate:
-- Iteration number (e.g., "Iteration 1/5")
-- Test command being run
-- Output/errors found
-- Root cause analysis
-- Fix applied
-- Result of re-run
-
-When complete, provide a summary of:
-- Total iterations taken
-- Issues fixed
-- Final test status (PASS/FAIL)
-- Any remaining concerns
+    const prompt = `You are now in verification mode. Your goal is to run tests, analyze failures, fix the code, and repeat until all tests pass.
+
+${chalk.bold('Verification Loop Process:')}
+
+1. ${chalk.cyan('Run the test command')}
+   Execute: ${chalk.yellow(testCmd)}
+   Capture all output, stderr, and exit codes
+
+2. ${chalk.cyan('Analyze the output')}
+   Look for:
+   - Failed test names and error messages
+   - Stack traces and assertion failures
+   - Missing imports or undefined references
+   - Type errors (if applicable)
+   - Any other compilation/runtime errors
+
+3. ${chalk.cyan('Fix the failing code')}
+   Based on the errors:
+   - Identify the root cause
+   - Modify the minimal necessary code to fix the issue
+   - Do NOT refactor unrelated code
+   - Ensure fixes are targeted and precise
+
+4. ${chalk.cyan('Re-run the test command')}
+   Execute: ${chalk.yellow(testCmd)}
+   Verify the fix resolved the issue
+
+5. ${chalk.cyan('Repeat until success')}
+   Continue the loop until either:
+   - All tests pass (SUCCESS)
+   - You've made 5 iterations (STOP - escalate)
+
+${chalk.bold('Important Guidelines:')}
+- ${chalk.dim('Work in:')} ${cwd}
+- ${chalk.dim('Run tests with:')} ${testCmd}
+- ${chalk.dim('Max iterations:')} 5 (safety limit)
+- ${chalk.dim('Be systematic:')} Fix one issue at a time
+- ${chalk.dim('Show progress:')} Report iteration count and current status
+- ${chalk.dim('Be explicit:')} Show the exact commands you run and their output
+- ${chalk.dim('Stop if stuck:')} If you can't make progress after 5 iterations, explain what you've tried and ask for help
+
+${chalk.bold('Output Format:')}
+For each iteration, clearly indicate:
+- Iteration number (e.g., "Iteration 1/5")
+- Test command being run
+- Output/errors found
+- Root cause analysis
+- Fix applied
+- Result of re-run
+
+When complete, provide a summary of:
+- Total iterations taken
+- Issues fixed
+- Final test status (PASS/FAIL)
+- Any remaining concerns
 `;
     return prompt;
 }

package/dist/walkthrough.js

@@ -8,9 +8,9 @@
  * choices to make.
  */
 export function buildWalkthroughPrompt() {
-    return `# Onboarding mode — you are the Cawdex Tour Guide
-
-You are walking the user through Cawdex for the first time. Be warm,
+    return `# Onboarding mode — you are the Cawdex Tour Guide
+
+You are walking the user through Cawdex for the first time. Be warm,
 concrete, and brief. Ask **one question at a time**, wait for the user's
 reply, then move to the next stage. Don't dump everything at once.
 
@@ -20,7 +20,7 @@ reply, then move to the next stage. Don't dump everything at once.
 Greet the user, then ask: "Have you used a terminal AI coding assistant
 before (Claude Code, Cursor, Aider, etc.)?" — Tailor depth to the answer.
 
-### 2. Explain what Cawdex is (60 seconds max)
+### 2. Explain what Cawdex is (60 seconds max)
 Cover:
 - Universal OpenAI-compatible CLI — works with OpenRouter, OpenAI, Anthropic,
   Ollama, LM Studio, DeepSeek.
@@ -109,7 +109,7 @@ command above and demonstrate it. If they have no specific task, suggest:
 ## Rules for the tour
 
 - **One question at a time.** Never dump multi-question paragraphs.
-- **No duplicate commands.** Cawdex unified its surface — when in doubt,
+- **No duplicate commands.** Cawdex unified its surface — when in doubt,
   the canonical name is the non-prefixed one. Do not suggest \`/ecc-tdd\` if
   \`/tdd\` does the same thing.
 - **Be honest about limits.** If something isn't installed (e.g. ECC failed

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cawdex",
-  "version": "1.35.65",
+  "version": "1.35.67",
   "description": "Cawdex — terminal coding agents with a mind for the whole repo. Speaks any OpenAI-compatible API with repo-aware context, benchmark tracing, MemPalace memory, and terminal-first agent workflows.",
   "type": "module",
   "license": "MIT",

package/resources/__init__.py

@@ -1 +1 @@
-"""cawdex packaged runtime resources."""
+"""cawdex packaged runtime resources."""

package/resources/exgentic/cawdex_agent/README.md

@@ -1,114 +1,114 @@
-# Cawdex for Exgentic
-
-This directory is a custom Exgentic agent package for running Cawdex in
-Open Agent Leaderboard style evaluations.
-
-The adapter implements Exgentic's `Agent` / `AgentInstance` split. On each
-`react()` step it writes an Exgentic prompt, launches Cawdex in
-non-interactive `/benchmark` mode, asks Cawdex to finish with one JSON
-action object, then maps that JSON back to an Exgentic `ActionType`.
-It auto-selects specialized `/benchmark` profiles for AppWorld, BrowseComp+,
-tau2, ARC, SaaS, roadmap, mobile, WebDevBench, SWE-Cycle, SWE-CI, SWE-PRBench, TML-Bench, and Pi-Bench-style tasks from the task, context, and
-available action schemas. It also builds a deterministic recommended action
-shortlist before the full schema list, including required argument keys and
-redacted exact latest-observation/context hints when those required values are
-already present. This matches the Open Agent leaderboard finding that
-action-scaffold details matter while preserving compatibility with every
-available benchmark action. Long sessions use a folded history ledger
-that preserves latest observations, selected actions, action counts, and
-diagnostics without reinjecting bulky raw stdout into every step. Before
-dispatch, near-miss action JSON is repaired conservatively: action names are
-matched by case/identifier normalization, schema argument keys are canonicalized,
-required schema fields are filled from exact latest-observation/context keys
-when available, and unknown extra keys are dropped when the benchmark exposes a
-fixed schema. If Cawdex produces malformed or missing action JSON, the adapter
-uses the same shortlist and exact required-argument hints to select a viable
-non-finish action while the latest observation is still pending, instead of
-falling straight to a finish/message action. When a selected action is followed
-by an effectively unchanged observation, the next shortlist and deterministic
-fallback mark that action as a no-effect repeat and prefer another viable action
-with satisfiable required arguments.
-For WebDevBench-style app-agency tasks, the folded ledger keeps canary business
-requirements, frontend/backend coupling evidence, and production/security gaps
-visible across turns so an attractive UI-only action does not look complete.
-For SWE-Cycle-style lifecycle tasks, it keeps the phase, bare-repo environment
-setup state, implementation requirements, generated/selected tests, judge
-commands, and unresolved lifecycle gaps visible across turns.
-For SWE-CI-style codebase maintenance tasks, it keeps current/target commits,
-test gaps, inferred requirements, touched files, verifier deltas, and unresolved
-regressions visible across the `run_tests -> define_requirements -> modify_code`
-loop.
-For SWE-PRBench-style PR review tasks, it keeps PR metadata, changed files, diff
-hunks, suspected findings, evidence gaps, and context-expansion reasons visible
-so the agent produces severity-rated findings instead of drifting into broad
-repo inspection or unsolicited patch generation.
-For TML-Bench-style tabular ML tasks, it keeps the data contract, metric,
-validation split, leakage checks, model artifact, submission path, and submission
-validity evidence visible so the agent favors a reproducible valid baseline over
-an invalid high-complexity attempt.
-For Pi-Bench-style proactive assistant tasks, it keeps user profile, current
-request, message/file/app context, available domain tools, hidden-intent
-hypotheses, privacy risk, clarification state, selected actions, and observable
-completion evidence visible so the agent can ask focused questions without
-overreaching or fabricating personal state.
-
-## Python API use
-
-```python
-import sys
-from pathlib import Path
-
-sys.path.insert(0, str(Path("path/to/resources/exgentic").resolve()))
-
-from cawdex_agent import CawdexAgent
-from exgentic.interfaces.lib import evaluate
-
-results = evaluate(
-    benchmark="gsm8k",
-    agent=CawdexAgent(
-        model="openrouter/free",
-        provider="openrouter",
-        max_turns=8,
-    ),
-    num_tasks=5,
-)
-```
-
-## Registry use
-
-For Exgentic CLI usage, copy this directory into an Exgentic checkout at:
-
-```text
-src/exgentic/agents/cawdex_agent/
-```
-
-Then add a registry entry:
-
-```python
-"cawdex_agent": RegistryEntry(
-    display_name="Cawdex",
-    module="exgentic.agents.cawdex_agent.agent",
-    class_name="CawdexAgent",
-),
-```
-
-After that:
-
-```bash
-exgentic install --agent cawdex_agent --local
-exgentic evaluate --benchmark gsm8k --agent cawdex_agent --model openrouter/free
-```
-
-## Configuration
-
-- `CAWDEX_EXGENTIC_COMMAND` or `CAWDEX_EXGENTIC_COMMAND` overrides the command, default `cawdex`.
-- `CAWDEX_INSTALL_SPEC` controls `setup.sh`, default `cawdex@latest`.
-- `OPENROUTER_API_KEY`, `OPENAI_API_KEY`, and other Cawdex provider env vars
-  are passed through by the launched Cawdex process.
-- `model`, `provider`, `max_turns`, `max_tokens`, `context_window_tokens`,
-  `temperature`, and `output_format` become Cawdex CLI flags.
-- `extra_env` and `extra_args` let Exgentic experiments pass additional
-  Cawdex settings without modifying this adapter.
-
-The adapter reports Cawdex's `summary.json` estimated cost to Exgentic
-when `CAWDEX_BENCHMARK_TRACE_DIR` output is present.
+# Cawdex for Exgentic
+
+This directory is a custom Exgentic agent package for running Cawdex in
+Open Agent Leaderboard style evaluations.
+
+The adapter implements Exgentic's `Agent` / `AgentInstance` split. On each
+`react()` step it writes an Exgentic prompt, launches Cawdex in
+non-interactive `/benchmark` mode, asks Cawdex to finish with one JSON
+action object, then maps that JSON back to an Exgentic `ActionType`.
+It auto-selects specialized `/benchmark` profiles for AppWorld, BrowseComp+,
+tau2, ARC, SaaS, roadmap, mobile, WebDevBench, SWE-Cycle, SWE-CI, SWE-PRBench, TML-Bench, and Pi-Bench-style tasks from the task, context, and
+available action schemas. It also builds a deterministic recommended action
+shortlist before the full schema list, including required argument keys and
+redacted exact latest-observation/context hints when those required values are
+already present. This matches the Open Agent leaderboard finding that
+action-scaffold details matter while preserving compatibility with every
+available benchmark action. Long sessions use a folded history ledger
+that preserves latest observations, selected actions, action counts, and
+diagnostics without reinjecting bulky raw stdout into every step. Before
+dispatch, near-miss action JSON is repaired conservatively: action names are
+matched by case/identifier normalization, schema argument keys are canonicalized,
+required schema fields are filled from exact latest-observation/context keys
+when available, and unknown extra keys are dropped when the benchmark exposes a
+fixed schema. If Cawdex produces malformed or missing action JSON, the adapter
+uses the same shortlist and exact required-argument hints to select a viable
+non-finish action while the latest observation is still pending, instead of
+falling straight to a finish/message action. When a selected action is followed
+by an effectively unchanged observation, the next shortlist and deterministic
+fallback mark that action as a no-effect repeat and prefer another viable action
+with satisfiable required arguments.
+For WebDevBench-style app-agency tasks, the folded ledger keeps canary business
+requirements, frontend/backend coupling evidence, and production/security gaps
+visible across turns so an attractive UI-only action does not look complete.
+For SWE-Cycle-style lifecycle tasks, it keeps the phase, bare-repo environment
+setup state, implementation requirements, generated/selected tests, judge
+commands, and unresolved lifecycle gaps visible across turns.
+For SWE-CI-style codebase maintenance tasks, it keeps current/target commits,
+test gaps, inferred requirements, touched files, verifier deltas, and unresolved
+regressions visible across the `run_tests -> define_requirements -> modify_code`
+loop.
+For SWE-PRBench-style PR review tasks, it keeps PR metadata, changed files, diff
+hunks, suspected findings, evidence gaps, and context-expansion reasons visible
+so the agent produces severity-rated findings instead of drifting into broad
+repo inspection or unsolicited patch generation.
+For TML-Bench-style tabular ML tasks, it keeps the data contract, metric,
+validation split, leakage checks, model artifact, submission path, and submission
+validity evidence visible so the agent favors a reproducible valid baseline over
+an invalid high-complexity attempt.
+For Pi-Bench-style proactive assistant tasks, it keeps user profile, current
+request, message/file/app context, available domain tools, hidden-intent
+hypotheses, privacy risk, clarification state, selected actions, and observable
+completion evidence visible so the agent can ask focused questions without
+overreaching or fabricating personal state.
+
+## Python API use
+
+```python
+import sys
+from pathlib import Path
+
+sys.path.insert(0, str(Path("path/to/resources/exgentic").resolve()))
+
+from cawdex_agent import CawdexAgent
+from exgentic.interfaces.lib import evaluate
+
+results = evaluate(
+    benchmark="gsm8k",
+    agent=CawdexAgent(
+        model="openrouter/free",
+        provider="openrouter",
+        max_turns=8,
+    ),
+    num_tasks=5,
+)
+```
+
+## Registry use
+
+For Exgentic CLI usage, copy this directory into an Exgentic checkout at:
+
+```text
+src/exgentic/agents/cawdex_agent/
+```
+
+Then add a registry entry:
+
+```python
+"cawdex_agent": RegistryEntry(
+    display_name="Cawdex",
+    module="exgentic.agents.cawdex_agent.agent",
+    class_name="CawdexAgent",
+),
+```
+
+After that:
+
+```bash
+exgentic install --agent cawdex_agent --local
+exgentic evaluate --benchmark gsm8k --agent cawdex_agent --model openrouter/free
+```
+
+## Configuration
+
+- `CAWDEX_EXGENTIC_COMMAND` or `CAWDEX_EXGENTIC_COMMAND` overrides the command, default `cawdex`.
+- `CAWDEX_INSTALL_SPEC` controls `setup.sh`, default `cawdex@latest`.
+- `OPENROUTER_API_KEY`, `OPENAI_API_KEY`, and other Cawdex provider env vars
+  are passed through by the launched Cawdex process.
+- `model`, `provider`, `max_turns`, `max_tokens`, `context_window_tokens`,
+  `temperature`, and `output_format` become Cawdex CLI flags.
+- `extra_env` and `extra_args` let Exgentic experiments pass additional
+  Cawdex settings without modifying this adapter.
+
+The adapter reports Cawdex's `summary.json` estimated cost to Exgentic
+when `CAWDEX_BENCHMARK_TRACE_DIR` output is present.

package/resources/exgentic/cawdex_agent/__init__.py

@@ -1,5 +1,5 @@
-"""Cawdex adapter package for Exgentic."""
-
-from .agent import CawdexAgent, CawdexAgentInstance, CawdexAgent, CawdexAgentInstance
-
-__all__ = ["CawdexAgent", "CawdexAgentInstance", "CawdexAgent", "CawdexAgentInstance"]
+"""Cawdex adapter package for Exgentic."""
+
+from .agent import CawdexAgent, CawdexAgentInstance, CawdexAgent, CawdexAgentInstance
+
+__all__ = ["CawdexAgent", "CawdexAgentInstance", "CawdexAgent", "CawdexAgentInstance"]