apps/dottie: cap Ollama generations, default qwen3:8b, fix file_ops CRLF on Windows

[jcdavis131]

Two fixes in apps/dottie, both found by the 2026-09-27 local-LLM A/B (dottie-main-evals/llm-ab-20260927, DEVIATIONS.md follow-ups (a) and (b)). Local models only; no paid API, no key.

1. Cap every Ollama generation (dottie/policy.py)

OllamaPolicy._chat sent no num_predict. llama-server runs with --context-shift, so a degenerate generation is bounded only by the server. In the A/B (Amendment 2, 13:07), granite4.2:3b at T0.2 ran 708 s to 81,920 tokens on task 8, done_reason=length, with repeated context shifts (-c 8192). The research loop runs the same code on CPU, where that runaway would hold the call until its 1800 s read timeout.

Every /api/chat call now sends options.num_predict. Knobs, each explicit argument > env > default:

env	default	notes
DOTTIE_OLLAMA_NUM_PREDICT	2048	0 or negative sends no cap (the old behavior)
DOTTIE_OLLAMA_TEMPERATURE	0.2 (unchanged)	a per-call complete(temperature=...) still wins, so ideation/implementation keep their own
DOTTIE_OLLAMA_NUM_CTX	not sent	unset, 0 or negative = today's request

A value that doesn't parse raises ValueError naming the variable, so a typo can't quietly run uncapped.

Does 2048 clip the live research loop? On the 4080 box's ledger (177 experiments) the longest stored implementation code is 4,369 characters, with p99 at 2,990. At the 3 to 4 characters per token typical for code, that's roughly 1.1k to 1.5k tokens (an estimate; I had no tokenizer to count them), so the longest completion fits under 2048. All the A/B arms ran with this cap: 603 calls, and the runaways it stopped were 3 to 5 calls per Granite arm, none for qwen3:8b.

Caveat: thinking tokens count against num_predict. I didn't measure this, since every arm and the live loop run THINK=false. It follows from the mechanism: the <think> block comes out of the same decode as the answer. With DOTTIE_OLLAMA_THINK unset, a long qwen3 thought can use up the cap and end the turn inside an unclosed <think>. The research loop runs THINK=false and so did the A/B. If you need thinking on for the CodeAct path, raise DOTTIE_OLLAMA_NUM_PREDICT. This PR doesn't detect done_reason=length; that's a possible follow-up.

DEFAULT_OLLAMA_MODEL and the compose default change from qwen3:32b to qwen3:8b. ollama list on the 4080 box shows qwen3:8b and no qwen3:32b, and the research loop already pins qwen3:8b through research_env.local.ps1. The README, runbooks, crontab example and status note that named 32b as the default now say 8b.

2. file_ops scored the host's newlines, not the content (dottie/tasks.py)

On Windows, open('report.txt', 'w') stores every \n as \r\n. A model that hashes the bytes it really wrote reports the CRLF digest, and the verifier only knew the LF one. In the A/B, the file_ops family scored 0/10 on all five arms (report.json), and none of the 50 file_ops finals carried the LF digest (lf_hit false in every row of report_amend1.json's audit).

Fix: the verifier also accepts sha256[:12] of the same expected content with CRLF line endings (VerifiedTask.alt_expected, exposed in verifier_detail). That digest can only come from the exact expected lines, so wrong content still scores 0. expected stays the LF digest, so API/harness readers are unchanged.

Re-scoring the A/B's 50 file_ops finals with the new verifier reproduces Amendment 1 row for row:

arm	frozen (old verifier)	this PR	Amendment 1
qwen3-8b@T0.2	0/10	6/10	6/10
granite4.2-3b@T0.2	0/10	6/10	6/10
granite4.2-3b@T1.0-p0.95	0/10	3/10	3/10
granite4.2-8b@T0.2	0/10	10/10	10/10
granite4.2-8b@T1.0-p0.95	0/10	9/10	9/10

The baseline's overall success rate moves 0.6933 → 0.8133 under that scoring.

Why the verifier and not newline='' in the sandbox. The verifier's own contract is "proves the derived content, not the write", and the CRLF form is that content. The sandbox is the shared factory substrate (apps/ava-factory/dottie/rl/codeact_sandbox.py). A newline shim there would also change what w+/r+ reads return, for every consumer and not just this family. Rewording the prompt to ask for binary mode would change the task, while this change keeps every prompt byte-identical: a digest of all 5 families × seeds 0–999 (prompt + LF expected + tool sources) is 907531785ca2… before and after. The no-leakage guard, and its test, now check every accepted token, not only expected.

Tests

New tests, written first and seen failing on the old code:

• test_tasks.py::test_file_ops_scores_windows_text_mode_crlf_bytes (15 seeds): the CRLF digest scores 1.0 and CRLF digests of wrong content score 0.0. It fails on the old verifier on any OS (assert 0.0 == 1.0).
• test_verified_engine.py::test_scripted_file_ops_text_mode_write_scores: a text-mode solver runs through the real sandbox. It fails on the old verifier on Windows (r_task 0.0) and asserts which digest the FINAL carried on each OS.
• test_policy.py: a fake httpx.post (no network). Covers the default cap on the CodeAct and complete() paths, env and argument precedence for all three knobs, blank and garbage values, and the compose default matching the policy default.

What I ran (Windows 11, Python 3.11):

• apps/dottie, which isn't in CI. Its own env was a scratch venv built from apps/dottie/pyproject.toml[dev] plus numpy, pyyaml, torch 2.14 CPU and ruff 0.15.22 on PATH, with AVA_FACTORY_ROOT=<worktree>/apps/ava-factory. pytest tests: 319 passed, 3 skipped. On origin/main with the same env it was 297 passed, 3 skipped; the 22 new tests are the difference. Without AVA_FACTORY_ROOT, test_climb::test_missing_prereqs... fails the same way it does on main.
• ruff check on apps/dottie, with its own config: 624 findings before and after. The only one in a touched file is the existing N818 in policy.py. ruff format --check is clean on the touched .py files.
• Root workspace (uv sync --all-groups --frozen): pytest packages/ava-open-harness gives 44 passed, 4 skipped. test_dottie_assistant.py alone runs the engine and file_ops verifier: 10 passed, 1 skipped (no ava checkpoint).
• These all exit 0: gate_audit --check, check_declared_capabilities --check, dag_next --check, store_symmetry_audit --check, check_todos_timestamps, check_handoff_fresh --check, check_resolver_fallbacks --check, check_cli_path_args --check, check_shell_true --check, check_documented_counts --check, the leaks working-tree scan, python -m factory check and python -m harness --help.
• Not run locally: the scout-cli suite. apps/dottie is excluded from the uv workspace, so this PR can't affect it; CI runs it. factory/tests has 2 local-only failures, a Windows process-tree cancel and the RAM/disk preflight on this box. Both are in factory/, which this PR doesn't touch.

🤖 Generated with Claude Code

https://claude.ai/code/session_014LHC4Z5q8HGJxLCSG3h8Db

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
arxiviq	Building	Preview	Sep 27, 2026 7:26pm UTC
dottie-os-console	Ready	Preview	Sep 27, 2026 7:26pm UTC

[cursor]

Approved. Cursor Bugbot was not present after the first check poll, so that signal was skipped. No reviewers were assigned.

  

_{Sent by Cursor Approval Agent: Pull Request Router and Approver}