#601 stage 3: join_windows static count check + ltx2/restore-long template

[dkackman]

Stage 3 of #601. It builds the plan's Stage 3 and its join_windows' static window-count check section, from plan v3. If this body and the plan disagree, the plan wins.

Filed by the lead agent, model claude-opus-5-5 via anthropic, 2026-10-05. Reshaped for plan v3 by the lead agent (claude-opus-5-5 via anthropic), 2026-10-06: the template ships unpriced (a cost is measured, never derived, and restore-deblur has none); the measured per_entry moves to new stage 4; the plugin version bump is dropped; acceptance now expects an unknown estimate and asks the tester to record the run's timings.

Builds

• A static window-count check owned by join_windows (Don, 2026-10-05). It is a module in the shape of dw/dissolve_frame_errors.py, wired into validation_errors, and it calls stage 2's rule in dw/task_domains.py.
  • It applies to any join_windows step. There is no template-specific logic in validate.
  • It fires when all of these are knowable: the source file (asset:/output:, or a readable literal path, probed header-only); literal num_frames and overlap; and videos as gather:<step>, whose member count is known after for_each expansion.
  • It errors at the step's path, naming the count needed. When an input isn't knowable it stays silent and leaves the decision to the run-time refusal.
• workflows/templates/ltx2/restore-long.json.
  • Its steps: a window for_each over variable:windows (entries {name, index}), a restore for_each (the restore-deblur pipeline, frames: previous_result:window), and join (join_windows(gather:restore, source=variable:source_video)).
  • No cost block yet. Stage 4 adds the measured one.
  • windows (so index) stays out of cost_drivers, so stage 4's per_entry won't be made unknown (validate_workflow: plan.estimate ignores a per-entry num_frames in a list-driven template (follow-up to #589) #593's _list_entry_field_shifted).
• A short note in the dw:ltx-2.5 skill on choosing windows for a long source.

Owes

• Tests: the catalog-structure tests pass on the template. Check unit tests on a plain join_windows workflow, not the template: short, exact and long lists; an unknowable source and a non-literal num_frames stay silent.
• Docs: the template description, WORKFLOW_GUIDE.md's for_each example list, and the check in TASKS.md's join_windows section.

Deploy

Server restart. No plugin version bump: the version is pinned to the engine's and moves only at release (tests/test_plugin_skills.py). The skill note reaches the tester through origin/develop.

Passes when

The plan's stage 3 acceptance intent holds over MCP on the LTX-capable server (CUDA, 24 GB):

• list_workflows(shape=…) lists the template, and validate_workflow on it is clean. Its plan.estimate is unknown (no cost yet), and validate doesn't refuse on that.
• The tester's verify comment records the minutes of one restore@wN step and the whole run's minutes, with the window count and device, for stage 4.
• A ~10 s asset: clip with the right list gives the source's frame count and audio length, no visible seams, and no sync drift.
• A list one entry short is refused at validate_workflow with the needed count, before any GPU time. So is a hand-written windowed workflow that is not the template.

The stage also passes every pending: #<this issue> case the tester writes.

[dkackman]

Stage paused for a re-plan: the pricing item can't be built as written.

Built and pushed on feat/601-C-restore-long (785eccd, 6e2ef26), not merged. Full pytest passes (8913) and ruff is clean:

• dw/window_count_errors.py, wired into validation_errors as window_count, with 12 unit tests on real mp4s: short, exact and long lists, plus the silent cases.
• workflows/templates/ltx2/restore-long.json: window_video -> for_each restore -> join_windows. It shares restore-deblur's pipeline key.
• Docs: TASKS.md join_windows, the WORKFLOW_GUIDE.md for_each list, the ltx2 README row and an ARCHITECTURE.md row.
• The dw:ltx-2.5 skill note on choosing windows.

What broke the plan. Stage 3 says the template carries per_entry pricing, with entries equal to the default list length, and its acceptance is "validates clean with an estimate scaled by window count". A per_entry figure has to be measured. The schema says cost is "Never derived; absent means unknown", and restore-deblur, whose pipeline this template reuses, has no cost to start from. The precedent is shots-batch (#352): its per_entry was measured on lem against the default list. A build session touches lem once, for the deploy, so I can't measure one here. Writing a number would be inventing one. Shipping without it would make plan.estimate unknown and fail that acceptance case.

Plugin version bump. The plan's deploy line asks for one. The plugin version is pinned to the engine's (tests/test_plugin_skills.py::test_the_plugin_version_is_the_engine_version) and moves only through the release script. Every past bump is a release/chore: open commit. Skill text reaches the tester through origin/develop. Plan v3 drops it.

Plan v3 is on #601 for Don.

claude-opus-5-5 via anthropic

[dkackman]

Body reshaped for plan v3 by the lead agent (claude-opus-5-5 via anthropic). The template ships with no cost block, windows stays out of cost_drivers, the plugin version bump is dropped, and acceptance expects an unknown estimate. The tester is asked to record the minutes of one restore@wN step and of the whole run, with window count and device. The measured per_entry moves to new stage 4, #658.

[dkackman]

Stage 3 shipped: develop @ a6e2aca, deployed on lem (deployed develop @ a6e2acaf, healthy, server restarted).

This is the branch from the paused build, feat/601-C-restore-long, rebased onto develop @ d1c1a8c and merged (commits a515db7, 7ab43ba1 and merge a6e2aca). It already matched plan v3: no cost block, and windows stays out of cost_drivers. Full pytest passes (9087) and ruff is clean.

What it covers in plan v3, stage 3:

• Static window-count check in dw/window_count_errors.py. It is wired into validation_errors as window_count, after dissolve_frames, and calls window_count_problem from dw/task_domains.py, the same rule the run-time refusal uses.
  • It applies to any join_windows step. It fires only when source is asset:/output: or a readable literal path (probed header-only), num_frames/overlap are literal, and videos is a list (gather: after for_each expansion).
  • It errors at the join step's path, naming the needed count and the entries to add or drop. It stays silent otherwise.
  • Tests (tests/test_window_count_errors.py) run on a plain join_windows workflow with real mp4s, not the template: short, exact and long lists, both through validate_workflow and directly. Each of these stays silent: a previous_result: source, a non-literal num_frames, a missing asset, overlap >= num_frames, and a non-list videos.
• workflows/templates/ltx2/restore-long.json. Three steps:
  • window: a for_each over variable:windows running window_video;
  • restore: a for_each running the restore-deblur pipeline with frames: previous_result:window.frames. That is the .frames form other LTX templates use, and it shares restore-deblur's pipeline key (tests/test_step_cache.py);
  • join: join_windows(gather:restore, source=variable:source_video).
  • The defaults are 3 windows, num_frames 121, overlap 16 and curve cosine. It has no cost block, so plan.estimate is unknown until stage 4 (#601 stage 4: per_entry cost for ltx2/restore-long #658).
• Skill note in dw:ltx-2.5, under the restore/upscale bullet: how to choose windows for a long source. There is no plugin version bump.
• Docs:
  • the template description;
  • the WORKFLOW_GUIDE.md for_each example list;
  • the validate-time check in TASKS.md's join_windows section;
  • an ltx2 README row and an ARCHITECTURE.md row.

Deviations:

• The compact-listing budget (tests/test_catalog_structure.py) goes from 9_550 to 9_700, measured at 9_638. #606 stage B: templates/ltx2/refine-in-place with lem-tuned strength ladders #639's refine-in-place landed in between and used the 9_550 step this branch had taken.
• The template's default source_video is asset:long-blurry.mp4, which doesn't exist on the server. With a missing asset the check stays silent, so validating the template as shipped is clean. To trigger the count check, pass a real asset: clip as source_video.

For the tester (from the plan): please record in your verify comment the minutes of one restore@wN step and of the whole run, with the window count and device. Stage 4 (#658) prices the template from them.

claude-opus-5-5 via anthropic