E2E contract-corpus pilot — convert scaffold's tests to a txtar corpus (Qwen3.6-27B)

[A]

Overview

booping scaffold's pytest suite described the Python implementation — Node object graphs, exception fields, exact message text — so it broke on no-op refactors and would not survive a rewrite of the CLI in another language.

This PR replaces it with a contract corpus: one txtar file per case carrying its fixture tree, the invocation, and everything asserted about the result (stdout, stderr, exit code, files left behind), executed by a standalone runner that shells bin/booping as a black box. scaffold is the pilot; the harness and format are what later plans convert the remaining subcommands onto.

booping-python/e2e/

• _txtar.py — vendored txtar parse/serialize (Go semantics, stdlib only).
• README.md — the format contract, written as the document a future non-Python runner is built from: section vocabulary, sandbox and env bindings, multi-line cmd, {CWD}/{HOME}/{XDG} tokens and the [..] wildcard, exit codes, the --update loop.
• run.py — fresh home//xdg//cwd/ sandbox per case, subprocess invocation, labeled unified diffs, {N} passed, {M} failed, exits 0 pass / 1 fail / 2 malformed.
• 36 cases covering every CLI-observable scaffold behavior — destinations and receipt shape, seed rendering, filename keys, error paths, the real core config trees, the scaffold→scaffold→query chain, the vault log line — replacing both superseded test files (607 lines deleted).

Wired as just e2e [pattern…], added to just ci and the CI python job; basedpyright now includes e2e.

Model & Host — implementer worker

Milestones were coded by a local Qwen worker (llama-developer agent) rather than a hosted Claude model:

GGUF repo	unsloth/Qwen3.6-27B-MTP-GGUF
Quant	UD-Q6_K_XL · 24.23 GiB (+0.35 vs non-MTP)
Projector	mmproj-F16 · 0.86 GiB, vision
Architecture	dense 27B — all params active/token
Layers	64 = 48 linear + 16 full attn
KV geometry	4 KV heads · head_dim 256
Native ctx	262144 — served at 196608
KV cache cost	6.0 GiB @196608 q8_0 · 12.0 GiB at f16
Runtime image	llama-swap v244-cuda-b10156, pinned
GPUs	cuda0 3090 24G + cuda1 A4000 16G
Split	--tensor-split 26,14 (not 24,16)
Served ID	Qwen3.6-27B

Known issue — not fixed in this PR

Verify surfaced that --update is not a byte-level no-op on an already-green corpus: it silently downgrades real-logging.txtar's [..] timestamp wildcard to a literal value and drops a trailing blank line in real-playbook-authoring-scaffold.txtar. Contradicts M02's DoD ("--update on an already-green corpus is a byte-level no-op"). Opening as draft pending a fix milestone.

Sprint metrics

Development only — the grooming session is excluded, since the plan is shared with #24. The Qwen row is the four local milestone sessions the llama-developer wrappers drove; the two runs that died on a gateway 500 are excluded, they produced no work.

IN (uncached) is only the input that escaped prompt caching — the real input volume is the cached column.

Role	Model	IN (uncached)	OUT	cached in (write + read)	Active
Orchestrator — develop driver	claude-sonnet-5	310	81.4k	735.7k + 15.49M	67 min
llama-developer wrappers — 4 milestones	claude-opus-5	138	8.5k	269.3k + 609.8k	83 min wall, mostly waiting on Qwen
Verify agent	claude-sonnet-5	194	25.8k	215.5k + 6.00M	10 min
Claude subtotal		642	115.7k	1.22M + 22.10M
Milestone sessions — the implementer	Qwen3.6-27B	285.8k	70.7k	0 + 14.63M	66 min, 307 turns

23.44M Claude tokens + 14.99M Qwen tokens = 38.42M total. Story points: 18 across 4 milestones.

The Qwen row's uncached IN is three orders of magnitude above the Claude rows because llama-swap reports a reused prefix as a cache read but bills each turn's new content as plain input — it has no cache-write bucket at all (cache_creation is 0 across all four sessions).

🤖 Generated with Claude Code