laguna-s-2.1 first light — smoke 1/4: fix-git (FAIL)

First benchmark run of laguna-s-2.1 (poolside 118B-A8B MoE, UD-Q4_K_S, partial offload, -c 262144) on this box. MinimalPi, K=1, no fast-fail caps.

Run as four one-task jobs (this dir is job 1 of 4) with an llama-swap restart before each, the documented mitigation for the partial-offload RAM ratchet — the box started at only 10.4 GiB MemAvailable. See the batch summary in the sibling smoke__laguna-s-2.1__20260726-201248/NOTES.md.

Batch result: 3/4 — regex-log, nginx-request-logging, openssl-selfsigned-cert PASS; fix-git FAIL.

fix-git — FAIL (reward 0), 4m18s total / 3m44s agent, 76479 in / 3363 out

Not a harness fault and not flailing: 19 tool calls, no retries, natural stop, every guard armed and none fired (0 loop-guard blocks, 0 write rejections, 0 bash timeouts). The model drove git competently — reflog → found the dangling "Move to Stanford" commit 650dba4 → cherry-pick → hit the expected conflict in _includes/about.md.

The failure is the conflict resolution. Verifier runs two assertions:

• test_layout_file — PASSED
• test_about_file — FAILED: hash(/app/personal-site/_includes/about.md) != hash(/app/resources/patch_files/about.md) (0273104059c6… vs 04bd29b908d4…)

The model resolved the conflict by hand-writing its own merged version of about.md with write_file, then declared done after verifying git status and git log. It never compared the resulting file content against an authoritative source — and hand-transcription is lossy (its content ends with a trailing space and no trailing newline).

Why this is actionable: the 35b hits the same trap and escapes it

runs/smoke__qwen3.6-35b-a3b__20260726-100656 (fix-git PASS, 18s agent) shows the same mistake made twice and then caught:

1. write_file about.md — hand-typed merge, wrong.
2. git show 650dba4:_includes/about.md | cat -A — inspected exact bytes.
3. write_file again — still wrong, and visibly mangled: StanfordCS, GoogleResearch (dropped spaces during retyping).
4. git show 650dba4:_includes/about.md > _includes/about.md — restored the file byte-exactly from the git object instead of retyping it. This is what made it pass.

So the difference is not capability, it is a verification habit: restore content from the authoritative object rather than reproducing it by hand, and check bytes rather than process state. Both models' first instinct was to retype; only the 35b checked.

Note the shape relative to preamble RULE 2 ("verify every requirement with real commands"): laguna did verify — it ran git status and git log --graph and both looked perfect. It verified the process while the graded criterion was content. That is a distinct near-miss shape from the classic "claimed success, ran nothing" false-success, and RULE 2 as worded does not catch it. Follow-ups filed in AGENT_TODOS.md.