ops: #1947 phases 2.5/3/5 are unrunnable — gptoss_rerun.sh, requant_sweep.sh and slots_sweep.sh were never committed and did not survive the rebuild

[Xore]

The 2026-09-03/04 host rebuild wiped /mnt-1/benchmarks/. Three scratch scripts that the #1947 phase chain execs are gone and cannot be recovered:

script	run by	phase
gptoss_rerun.sh	chain2b.sh	2.5 — re-measure empty-answer models under the harmony-aware harness (#2279)
requant_sweep.sh	chain2b.sh (exec)	3 — self-requantisation sweep (#2245)
slots_sweep.sh	chain3.sh (exec)	5 — sessions + Rev·Deck slots across the roster

Not in the hermes mirror, not in /mnt-1/benchmarks/scripts-copy/, not anywhere on the host, and never committed to this repo. sweep_extra.sh and preseed_ollama_config_blob.sh were committed under #2728 for precisely this reason ("so a script driving multi-hundred-GB pulls and real benchmark runs is reviewable and isn't one rm away from being lost") — these three were missed.

The 2026-09-04 resume launched chain2b.sh and chain3.sh anyway. They did not fail; they waited. chain2b.sh polls up to 14 days for EXTRA_COMPLETE, chain3.sh polls up to 14 days for a REQUANT_SWEEP_COMPLETE marker nothing can write. Both reported as running processes for five hours while being structurally incapable of doing anything.

Already done (2026-09-05)

• chain2b.sh / chain3.sh now abort at launch when their downstream script is absent, instead of queueing behind an unwritable marker.
• resume_phases.sh launches only the waiters whose scripts exist, and prints SKIP chain2b/SKIP chain3 otherwise.
• Recorded in /mnt-1/benchmarks/STATE-2026-09-05-fix-stage.md.

Phase 2 (sweep_extra.sh) is unaffected and running.

Scope

• Rewrite the three scripts from their issues' own descriptions (Next benchmark round: re-run gpt-oss cells under the harmony request shape before comparing across rounds #2279 for the harmony re-run, Research: quantize bigger bases to fit the Supermicro — is large-model-low-bit a real gain over the current slots? #2245 for the requant sweep, One benchmark, every model, every aspect: rebuild the model matrix on current hardware with error bars #1947 phase 5 for slots) — they are not literally recoverable, so this is a rewrite, not a restore.
• Commit them under analysis/ghidra/benchmarks/corpus/ beside sweep_extra.sh, with the same "operational copy lives at /mnt-1/benchmarks/..., keep in sync by hand" header.
• Audit /mnt-1/benchmarks/*.sh for anything else operational and uncommitted (preseed.sh, recreate-local-tags.sh, shutdown_watcher.sh, resume_phases.sh, chain*.sh are all in-tree nowhere).

[Xore]

Two of the three rewritten and merged; one still missing

requant_sweep.sh (phase 3) landed in PR #3042, plus chain_phase3.sh which
replaces the chain2b.sh/chain3.sh pattern rather than restoring it.

script	phase	state
requant_sweep.sh	3 — quantization ladder (#2245)	✅ rewritten, merged, running
chain_phase3.sh	chaining	✅ rewritten, merged, armed (replaces chain2b/chain3)
gptoss_rerun.sh	2.5 — harmony re-run (#2279)	❌ still missing
slots_sweep.sh	5 — sessions + Rev·Deck slots	❌ still missing

The chain pattern was replaced, not restored

The old chains polled for EXTRA_COMPLETE. That marker is written
unconditionally at the end of the roster loop no matter how many entries failed,
and it has now produced a false completion three separate times — on the pull
path, on the Tier B path (#2971), and when 12 models died to container DNS in
four minutes and the sweep declared itself finished anyway (#3031).

So chain_phase3.sh waits on what is actually true or false: every roster entry
has both tier files or an explicit UNMEASURED marker, and no sweep process
is alive. It also refuses to start when more than 25% of the roster is
unmeasured — that is an infrastructure failure to investigate, not a green light
to spend GPU hours. Guard verified live: at 38+2/52 it aborted with the counts.

That is #3031's requested guard, applied at the consumer rather than waiting
for the producer to be fixed.

Phase 3 is already producing

The first ladder is built and the numbers are interesting on their own:

Ornith-1.0-35B, clean f16 -> our own ladder
  Q4_K_M  21 GB  spills   (matches the published 22 GB — the control)
  Q3_K_M  16 GB  at the ~16-17 GB weights budget
  Q3_K_S  15 GB  fits
  IQ3_M   15 GB  fits

Ornith scored 67/69 on ghidra Tier B in #1805-c — the highest in that cohort —
and was unusable because its only published quant spills. Three levels that fit
now exist.

Two findings worth carrying into the estimate for the remaining scripts:

1. Conversion is not mechanical. Ornith converted clean; gemma-4-26B-A4B
   failed 20 frames deep in transformers because the repo ships
   extra_special_tokens as a bare list where a dict is required. The ladder
   needed a normalization layer, not just a pipeline. Community fine-tunes ship
   broken metadata often enough that this should be assumed, not hoped against.
2. The roster overlap is a free control. Four of phase 2's remaining models
   are the published Ornith Q3_K_M and gemma Q3_K_M/Q4_K_M/Q5_K_M — the
   same levels the ladder built from f16. That yields a same-base, same-level,
   same-scorer published-vs-self-quantized A/B that nobody planned.

Still open on this issue

gptoss_rerun.sh and slots_sweep.sh. Both are short next to phase 3:
#2279's re-run is four rows against an already-merged harness fix, and phase 5
is the sessions/Rev·Deck slots across the roster under the cold protocol. Neither
is started.

[Xore]

slots_sweep.sh landed (round-7 driver leg, PR #3117) — drives evaluate-models.py --slots sessions,revdeck. The unrun part of this issue's slots leg is covered by #3087's execution gate.