#1199 stage 6: repair one chain segment in place

Stage of #1199, filed by model claude-opus-5-5 via provider anthropic. Already
built on feat/long-form-media (merged 3f8ed222). The authoritative spec is the
plan (docs/superpowers/plans/2026-11-03-long-form-media.md, task named below) and
the design record. If they differ, the design record says what shipped.

Built:

templates/minimax/repair-segment (chain_take or chain_output, segment, its
own prompt and seed; head 22, tail 39, 175-frame render).
The tasks chain_repair_cut, chain_repair_splice and check_take_shots
(dw/tasks/chain_repair.py).
keep_segments on the H3 chain templates (chained-segments,
chain-video-continuity, chain-matched-to-audio, chain-matched-and-aligned,
music-video).
save_segments/keep_segments accept variable: references.
Commits dcc5877..cf6999d.

Observe over MCP:

run_workflow a 4-segment chained-segments with keep_segments: true.
Then run_workflow templates/minimax/repair-segment with chain_take: output:<that job's final video>, segment: 3, a prompt and a seed.
assess_output(probe="analyze_seams") on both takes, and get_job for the
manifest shots.

Acceptance intent:

The repaired take has the same frame count.
Only the repaired segment's frames change, and seams outside the span are unchanged
within encode noise.
The repaired seams are recorded as chain seams (segment N (repaired)).
A take run without keep_segments is refused before the render, naming the fix.
segment: 1 and an out-of-range segment are refused.
A match_audio take keeps its whole source track (R31).
The VRAM estimate holds: peak at or under the estimate.

Bench evidence: 46d9c4f4b1d7 (repair of fdea6eba4a33 segment 4, 8.1 min, peak
18.92 GiB against an estimate of 19.95). Record: bench/records/repair.md.

Owes: nothing. Deploy: done at 3f8ed222.

verify: run every pending: #1207 case.

Verify of stage #1207 on lem develop @ 85bcd33, by tester claude-opus-5-5 via anthropic. Bounced to the lead: one acceptance point fails. The suites hold no pending: #1207 cases (I grepped every regression-suite-*.md), so I checked the stage's own acceptance list.

Calls I ran

run_workflow templates/minimax/chained-segments {segments: 4, keep_segments: true, seed: 1207} in workspace default → job 6bf2c404eee4, succeeded, 7.4 min (estimate 18). The take is 430 frames: segment 1 is 124 frames, segments 2–4 are 102 each, and every shot has a segment_file.
run_workflow templates/minimax/repair-segment {chain_take: output:templates/minimax/chained-segments/20261107-145804-eb6cf5f0/final/MiniMaxH3I2VChained-chained_keyframe_to_video_audio.0-0.0.mp4, segment: 3, seed: 31207} → job ed74b8209df7, succeeded, 3.3 min (estimate 8.1).

Results against the acceptance list

Same frame count: pass. The splice writes 430 frames, the same as the source.
Seams outside the repaired span unchanged: pass. assess_output(probe=analyze_seams) on seam 1 (segment 1 | segment 2) gives level_step 3.05 → 3.06 dB, frame_delta 3.18 → 3.15, jump_ratio 1.35 → 1.35. That is encode noise. Segments 1–2 keep the same start frames and sample counts.
- Note: the repaired span is start_frame 226, num_frames 114, and segment 4 becomes start_frame 340, num_frames 90, trim_frames 12. So 12 frames at the head of segment 4 are replaced, and the seam moves from 13.667 s to 14.167 s. I'm reading this as the tail hold re-rendering into segment 4, as designed. If the plan promised only segment 3's own 102 frames would change, this is a second failure.
Repaired seams recorded as chain seams: pass. The shots read segment 3 (repaired). Both seams carry crossfade_ms: 3.0, and analyze_seams names them segment 2 | segment 3 (repaired) and segment 3 (repaired) | segment 4. The source's seam-3 seam_level_step warning of 5.7 dB is gone; it is now 2.12.
segment: 1 refused: pass. validate_workflow returns arguments.segment: 'segment' is 1 ... must be at least 2, before anything loads.
Out-of-range segment refused: pass. segment: 9 passes validate but the run refuses it: job 4ff131d0a43f failed in 2.5 s at chain_repair_cut with 'segment' must be 2 to 3 of this 4-segment chain, got 9 ..., before any render.
A take without keep_segments refused, naming the fix: FAIL. The run is refused before the render, but the error names the wrong fix. I used repair-segment {chain_take: output:templates/minimax/chained-segments/20261107-144311-ee63cf23/final/MiniMaxH3I2VChained-chained_keyframe_to_video_audio.0-0.0.mp4, segment: 2, seed: 31207} in workspace bench. That is job dabd85f4630d, a chained-segments run with no keep_segments. The run is job 2620b0dd685a, which failed in 0.5 s:

chain_repair_cut: MiniMaxH3I2VChained-chained_keyframe_to_video_audio.0-0.0.mp4's shots name no segment files (a chain run before they were recorded, or a take copied away from its run) - pass 'chain_output', one of its segment files, as well

A take run without keep_segments has no segment files to pass, so "pass chain_output" can't be followed. The message never mentions keep_segments. Expected: the refusal says to re-run the chain with keep_segments: true, and keeps the chain_output advice for the copied-away case only. validate_workflow also accepts this take as valid, so the refusal only comes at run time. That is acceptable, since nothing renders first.
VRAM within the estimate: inconclusive over MCP. The memory events for ed74b8209df7 don't report a peak. The closest reading, taken right after denoise (seq 38), is gpu_memory_reserved_mb 14966, well under the 19.95 GiB bench estimate. I can't confirm the true peak from what the events expose.
match_audio take keeps its whole source track (R31): not run. I skipped it in this pass because the check above already fails; it needs to be run on the next verify.

To fix: the no-segment-files refusal in chain_repair_cut should tell a take with no kept segments apart from one copied away from its run, and name keep_segments: true for the first.

unstrand: Don — this is a stage of #1199 (its body says "Stage of #1199"), but GitHub has no sub-issue parent link on it, so lib/classify.jq reads "stage with no parent" and no queue picks it up. Labels alone can't fix that: the link needs a sub-issue write, which this loop can't make. Separately, the tester bounced it to the lead with a failed acceptance point, and the parent #1199 sits with owner:tester + status:fixed-pending-verify, so even linked it would wait on #1199 rather than reach a lead build.

Readings:

A, lead fixes the bounce as stage work: link it as a sub-issue of Long-form media: one playbook, measured levers, quality-first defaults for pieces longer than one clip #1199, move Long-form media: one playbook, measured levers, quality-first defaults for pieces longer than one clip #1199 back to owner:lead, and keep this owner:lead + stage.
B, the bounce is a plain bug for the fix loop: drop stage, add bug, and set owner:implementer with no status (the target:lem claim stays; add a backend: label).

Same call for #1205, #1206, #1207, #1208, #1209, #1211 and #1214.

Unstranded by model claude-opus-5-5 via provider anthropic.

Decision for Don: do the bounced #1199 stages go back to the lead (link them under #1199) or to the implementer loop as bugs?
Kind: record Default: reading A: link each as a sub-issue of #1199, return #1199 and the stages to owner:lead
If otherwise: reading B: relabel each bug + owner:implementer, no status, with a backend: label Reversible: yes

Don's ruling on the unstrand question: reading B. The bounce goes to the fix loop as a plain bug, not stage rework. Relabelled bug + owner:implementer + backend:shared, with no status and no stage. The target:lem claim stays. The tester's bounce comment above is the spec. If it hides a spec question (whether the threshold or the acceptance claim is wrong, or whether an effect is intended), settle it from the design record and the bench records, and escalate only if those don't answer it.

— recorded from Don's Claude Code session (model claude-opus-5-5 via provider anthropic)

Scope added by Don (from #1231): the same fix also gives a second repair of an already-repaired take its own refusal. Today that fails at the segment-file lookup with the generic 'shots name no segment files' error. So chain_repair_cut should distinguish three cases, each with its own message: no keep_segments (re-run the chain with keep_segments: true), a take copied away from its run (pass chain_output), and an already-repaired take (repair the original chain take instead).

— recorded from Don's Claude Code session (model claude-opus-5-5 via provider anthropic)

triage: work — chain_repair_cut refusal: distinguish no keep_segments (re-run with keep_segments: true), a take copied away from its run (pass chain_output), and an already-repaired take (Don's added scope from #1231). The skipped match_audio R31 case runs on verify. Message work only, no new surface. Triaged by model claude-opus-5-5 via provider anthropic.

fix(chain): #1207 - chain_repair_cut refuses a no-keep_segments, copi…

Fix for the bounce, by model claude-sonnet-5-5 via provider anthropic.

repair-segment (chain_repair_cut) now refuses a take that has no segment files with one of three messages, each before any render:

Run without keep_segments (manifest has shots, none names a segment file): "was run without keep_segments ... re-run the chain with 'keep_segments: true' (and save_segments), then repair that take". Before, it told the caller to pass chain_output, which cannot work here.
Take copied away from its run (no manifest shots beside it): says so and asks for chain_output, one of the kept segment files.
Already-repaired take (a shot named ... (repaired)): "already a repaired take ... repair the original chain take instead". This is Don's scope from idea: repair two adjacent chain segments together (a break that spilled into k+1) #1231.

Nothing else changed: the repair, splice and other refusals behave as before. The match_audio R31 case was not touched and runs on verify.

Commit cad81c1 (fix is 2 commits earlier on develop), deployed to lem 19:26 UTC, healthy.

Architecture review queued by the loop driver: this hand-off changed dw/ or dw_mcp/ on develop (7def356cea..cad81c1c9d: dw/tasks/chain_repair.py). The reviewer checks it against docs/ARCHITECTURE.md before the tester verifies.

arch-review: pass, no findings. Reviewed by model claude-opus-5-5 via provider anthropic.

Read: git diff 7def356c..cad81c1c -- dw/ dw_mcp/; the #1207 commit is badb6206, which touches only dw/tasks/chain_repair.py _locate, +17/-3. Checked against docs/ARCHITECTURE.md and item 3 of stage-c-guardrails.md:

Second owner: none. The new branch reads only the shots_beside(take) result that _locate already loaded. The (repaired) marker it checks for is written by chain_repair_splice in the same module (chain_repair.py:626), which the "Repair one chain segment in place (idea: repair a bad H3 chain segment in place - re-render it with head and tail locked to its neighbours #1169)" map row and the dw/shots.py docstring both assign to this module. Segment files are still found from the take's shots, as that row requires.
Build vs. buy: nothing new; it adds two string-matched ValueError messages.
The map: no owner added and no rule moved, so the idea: repair a bad H3 chain segment in place - re-render it with head and tail locked to its neighbours #1169 row still holds unchanged.
Context: no CLAUDE.md change.

Nothing was waived (the issue has no arch-approved). It goes on to the tester's verify, which includes the match_audio R31 case that hasn't been run yet.

Navigation Menu

Repository navigation

#1199 stage 6: repair one chain segment in place #1207

1 remaining item

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

#1199 stage 6: repair one chain segment in place #1207

Description

Activity

dkackman commented on Nov 7, 2026

dkackman commented on Nov 7, 2026

1 remaining item

dkackman commented on Nov 7, 2026

dkackman commented on Nov 7, 2026

dkackman commented on Nov 7, 2026

dkackman commented on Nov 7, 2026

dkackman commented on Nov 7, 2026

dkackman commented on Nov 7, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions