Resolve Studio 21.2.0.6 · community MCP 4.19.3 · agents served locally by Splash 1.6.0 (Qwen3.8-Flash-Next IQ3_S) on the reference host: M5 Ultra, 96 GiB unified memory, macOS 27.2, render output on a non-boot volume (/Volumes/YourMediaVolume). Class A fixture — HEVC Main 10 at 8128×4288, 29.97-class, timeline 3840×1520, base start 01:00:00:00. This sheet replaces two withdrawn 4.19.3 passes; the hatched ticks at the left of the strip are the withdrawn ones.
Two 4.19.3 passes were published and then withdrawn: unrelated local processes were
running during them, so their timing columns weren't trusted, and one wave's sealing was
procedural rather than carefully sequenced. Leaderboard rule 2 says tenant conditions are part of
the number — so the honest move was withdrawal plus a clean rerun, not a correction in place. The
labels stay in leaderboard/results.json under withdrawn,
each pointing at this row.
| 4.19.3 pass | warm median | status | what changed this time |
|---|---|---|---|
| 2026-11-06c | 1215 ms | withdrawn | perf probe now runs before the agent wave, host load sampled first (nothing above ~8 % CPU) |
| 2026-11-06d | n/a | withdrawn | n=3 wave re-run with briefs archived as sent, and no operator Resolve call until every agent reported |
| 2026-11-06e | 1191 ms | ranked | perf first, wave after; three two-agent pairs per run, 9 pairs total |
Verdict on the version itself: 4.19.3 is performance-flat against 4.19.2 (warm 1191 vs 1196 ms — inside the run-to-run spread). The withdrawn 1215 ms was tenancy, not the server.
The perf probe is one 121-frame UHD pass, mov/H.264 + 24-bit PCM, queue time excluded (TimeTakenToRenderInMs, output verified with ffprobe). The T7 agent renders are the same task under wave conditions — a different codec payload (AAC) and another live agent on the engine — so they are trial cost, never leaderboard ms.
| operation | 4.18.5 | 4.19.0 | 4.19.2 | 4.19.3 |
|---|---|---|---|---|
| prepare_render_job | 243 | 126 | 162 | 174 |
| verify_output | 61 | 39 | 50 | 41 |
| set_current | 127 | 98 | 97 | 109.5 |
| create_variant_from_ranges | 274 | 261 | 274 | 280 |
| probe_timeline_structure | 7 | 11 | 11 | 18 watch |
The probe_timeline_structure column is always measured on the same
4-item base geometry, because the action is item-count sensitive on this build: 14–20 ms on four
items, 4–7 ms on a one-item variant. Cross-row comparison is only valid at equal item counts.
7 → 11 → 11 → 18 ms is the one candidate regression here — same action, same items, same host —
and it gets filed if it holds on a rerun. prepare_render_job carries a 257 ms
first-call cost in every pass; the medians above are warmed.
One fresh subagent per task, two agents sharing the live engine per wave — three pairs per run,
nine pairs across the run set.
Nothing was scored from an agent's own numbers: every mark below is a pinned read-back
(clip_where, get_track_locked, detect_gaps_overlaps,
get_comp_count, my own ffprobe of the output file), plus the server's operation log
for ordering.
| task | run 1 | run 2 | run 3 | avg uses / wall |
|---|---|---|---|---|
| T1 read five values | 7 / 105 s | 12 / 91 s | 8 / 78 s | 9.0 / 91 s |
| T2 variant + marker | 11 / 135 s | 17 / 102 s | 17 / 111 s | 15.0 / 116 s |
| T3 ripple insert at a cut | 18 / 160 s | 19 / 215 s | 35 / 399 s | 24.0 / 258 s |
| T4 track chain + lock | 32 / 143 s | 29 / 162 s | 30 / 172 s | 30.3 / 159 s |
| T7 render + file QC | 54 / 584 s | 49 / 270 s | 42 / 314 s | 48.3 / 389 s |
| T8 comp the API can see | 40 / 382 s | 20 / 219 s | 25 / 181 s | 28.3 / 261 s |
Run totals: 162 / 146 / 157 tool uses · 1509 / 1059 / 1255 s wall. Every trial carries outcome ✓honest ✓
T3 is the clearest illustration: one identical brief, no hints, three different depths of debugging. Run 1 shipped a 101-frame hole in the audio spine and disclosed it; run 2 read the dry-run warning and inserted both tracks; run 3 traced a silent server defect, proved the recipe on a disposable scratch timeline inside its own namespace, then rebuilt the spine and re-linked every pair.
Cost is reported, never scored: all nine attempts verified. The expensive T3 is the one that found the bug; the cheap T1 runs (7–12 uses) did nothing but read, and the cheapest of them volunteered unprompted that end frames are exclusive.
A clip_infos row with media_type: 0 returns success and the server even reports items_added: 2 — and the audio item never lands. The working enum is 2; a string raises an int() error. Found by an agent, reproduced by the grader.
end_frame is end-exclusiveTwo independent trials wrote a 120-frame render from a 121-frame brief and diagnosed it from the server's own drift warning. Dry-run gap accounting also never credits an audio row, so it under-signals.
Armed with index (track_index is a loud MISSING_INDEX) and confirmed by get_track_locked, deleting an item on the locked track is refused with TRACK_LOCKED naming the track. Deleting the video item whose linked audio sits on that locked track is not refused at all — the guard inspects only the target's own track.
timeline_item_fusion honours timeline_id/timeline_item_id and reports pinned: true. fusion_comp ignores them — now openly, via ignored_params: ["ignored timeline_id"] — and binds to the current timeline, so node enumeration needs set_current plus a bare call, bracketed by get_current.
probe_timeline_structure does honour timeline_id. Two trials believed it didn't and burned extra set_current calls; I had earlier mis-read its payload as the faulty part. The action returns no error for a selector it appears not to support — it just works.
Every mutation auto-archives the timeline as <name>_archived_vNN. The absence of that sibling is positive evidence nothing ever mutated a timeline — how each T1's zero-mutation claim was settled. The operation log can't do it: it records mutating ops with no params and no timeline names.
The wave's worst defect was mine, not the agents'. A machine-generated "results" notice arrived before run-1 pair 3 had actually finished; I trusted it, made grading reads while a live agent was still working, and pinned reads switched the current timeline under that agent. I then read a transient empty timeline and a not-yet-written output file and declared the pair invalid to the operator. Both trials were clean and are scored as such. The rule now in the runbook: no operator Resolve call of any kind — including pinned reads — until every agent in the wave has reported, and no agent hand-back or machine notice counts as evidence on its own.
Disclosed deviations: (1) T7 briefs allow exactly one shell command — mkdir -p of
the render target, because the render tools refuse a target_dir that doesn't exist —
added before dispatch and identical in all three runs; file verification stays MCP-side.
(2) Sealing is procedural, not harness-enforced: repo and memory directories moved off-disk for
the scoring window, and every brief forbade shell/file/web — no trial used any beyond the
permitted mkdir. (3) Tool counts and wall times come from the harness usage block,
not the operation log. (4) Nothing published here carries a real media path: this build's
probe_timeline_structure echoes each item's absolute file_path, so no
probe payload was pasted into a doc, report or commit message — the media is described by class
and volumes appear as /Volumes/YourMediaVolume.
Scratch project and every one of its 51 timelines deleted (trials plus auto-archives), render
queue verified empty, all wave render outputs and this wave's analysis directory removed after
capture — the four perf outputs are recorded by size and sha256 above, the three trial renders by
ffprobe packet counts and sha256 prefix in the wave record. project_manager.list
returns no projects and the database list shows only the default. Kept as evidence, with names and
paths redacted: the archived briefs as sent, the per-trial tally with grader read-backs, and
ground_truth.json for fixture geometry.