#1199 stage 4: per-segment check with a bounded re-roll

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: chain.check (true, or an object of jump_ratio_max 4.0, look_ratio_max
5.5, texture_ratio_max 2.0 and cut_ratio_max 4.0, each nullable) and
chain.retries (0-3) (4bdf6d3, d37c319, 2fddfbe):

A failed segment is re-rendered from the same carry at seed + attempt × 1000003.
On exhaustion the chain keeps the attempt with the fewest failed measures (then the
lowest jump), records attempts, seed and check_failed on its shot, and warns
chain_check_failed, naming the measure and value.
Texture flags and warns but never re-rolls.
Segment 1 and hard_cut seams are never checked.
retries above 0 without check is refused.
The estimate quotes (1 + retries) as the worst case.

Observe over MCP:

Copy s3-dialogue-walk from the bench workspace with segment 4's prompt replaced
by the hard-cut prompt from bench/arms/check.json (chk-s3-seg4-broken).
run_workflow with check: true, retries: 1.
get_job gives the run manifest's shots and the warnings, and get_job_events the
"check failed (...) - re-rolling" lines.
Run S1 with check: true, retries: 0 for false positives.

Acceptance intent:

The broken segment fails on cut_ratio or look_ratio and is re-rolled once.
If every attempt fails, the kept shot carries check_failed, and the job has one
chain_check_failed warning per failed segment.
Good segments pass.
retries: 0 with check: true measures and flags but renders nothing extra, so
the output equals the unchecked run.
A texture-only failure warns with no re-roll.
validate_workflow gives an estimate that grows with retries.

Bench evidence:

6668a913863c: segment 4 kept attempt 2 with check_failed: ["cut_ratio"] at 4.15,
segment 5 at 17.25.
ccce7adc9aaf (retries: 3).
False-positive runs: 7b76a3796335 (S1), 604e115324b7 (S2).
Record: bench/records/check.md.

Owes: nothing. Deploy: done at 3f8ed222.

verify: run every pending: #1205 case.

Verify of #1205 by the tester, model claude-opus-5-5 via provider anthropic, against develop @ 85bcd335 on lem. Bounced to the lead: the first acceptance bullet did not hold in my run. Everything else I could observe works.

There are no pending: #1205 cases in any suite file (I grepped for pending: #1205, chain.check and retries). So the acceptance below is the issue's own.

Run 1: the repro (`chk-s3-seg4-broken`, `check: true`, `retries: 1`)

run_workflow(s3-dialogue-walk, workspace=bench, seed 1166, segments 6, keep_segments true). Segment 4's prompt was the hard-cut harbour prompt, the same prompts list the bench job 6668a913863c used. Job 884e612b08c4 ran on cuda:0 and succeeded in 758 s with 7 segment renders.

Segment 4 (the broken one) passed its check on attempt 1. Its shot has attempts: 1 and no check_failed. get_job_events has no "check failed" line for segment 4.
Segment 5 is the only failure: Chain segment 5/6: check failed (cut_ratio 4.95) - re-rolling, attempt 2 of 2 at seed 1001169. Attempt 2 also failed. The job then emitted kind: chain_check_failed, segment: 5, measures: ["cut_ratio"], values: {cut_ratio: 4.95}, kept_attempt: 1, attempts: 2. The shot has attempts: 2, check_failed: ["cut_ratio"], with no seed, since the kept attempt was the base seed.
In the bench run 6668a913863c (cuda:1), segment 4 failed at cut_ratio 4.15, just over cut_ratio_max 4.0. My run on the same seed and prompts put it under 4.0. So the default threshold does not reliably catch the broken segment the bench built for it. The check reliably fires one seam later, on segment 5, where the carry from the harbour meets a prompt that opens on the street. Acceptance bullet 1 says "the broken segment fails on cut_ratio or look_ratio and is re-rolled once". In this run it didn't, and the re-roll was spent on segment 5, whose own prompt is fine.

Run 2: S1 false-positive probe (`check: true`, `retries: 0`)

run_workflow(s1-static, workspace=bench, keep_segments true), job 25dd49a20bfd, succeeded in 1085 s.

timing.segments: 10 across 10 shots, every one with attempts: 1. Nothing extra was rendered.
Segments 9 and 10 flagged texture_ratio 2.2166 and 2.3721 with the warning "texture drift is not re-rolled, a fresh seed inherits the carry". So texture only flags and warns. With retries: 0 this run can't show whether texture would be re-rolled when retries are on; run 1 had no texture failure.
I can't tell whether that late texture drift in S1 is real or a false positive without the bench's false-positive record. I'm noting it, not counting it.
I made no unchecked twin run, so "output equals the unchecked run" is not checked.

Validation (free)

check: false, retries: 1 is refused: steps[0].pipeline.chain.retries: retries 1 needs check on ... ✅
retries: 4 is refused: retries must be a whole number between 0 and 3, got 4 ✅
The estimate is not observable. validate_workflow on s3-dialogue-walk and s1-static (bench) returns estimate.minutes: null, basis: "unknown" for retries 0, 1 and 3 alike. So "the estimate grows with retries" can't be shown on the workflows the issue names. templates/minimax/chained-segments, the only priced chain template, doesn't expose check/retries.

What the lead needs to settle

Segment 4's mid-segment hard cut sits right at the cut_ratio_max 4.0 boundary: 4.15 on cuda:1 and below 4.0 on cuda:0. Either the threshold, the measure, or the acceptance claim that the broken segment is the one that fails needs to change.
Give a way to see the (1 + retries) worst case over MCP: a priced workflow that exposes chain.retries, or a bench workflow with a basis.

Outputs are kept in bench (s3-dialogue-walk/20261107-140952-f54d3126, s1-static/20261107-142307-1730300e, with segments) for inspection.

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)

triage: work — fix from the tester bounce: the broken segment 4 sits at the cut_ratio_max 4.0 boundary (4.15 on one card, under 4.0 on the other), so settle threshold, measure or acceptance from the design record and bench check records per Don's ruling. Also: "estimate grows with retries" is unobservable, since no priced chain template exposes check/retries. No new surface. Triaged by model claude-opus-5-5 via provider anthropic.

fix(engine): #1205 - cut_ratio ceiling 3.5, off the card-dependent 4.…

Fix for the tester bounce, by model claude-opus-5-5... correction: worked as model claude-sonnet-5-5 via provider anthropic.

Settled from the bench record (bench/records/check.md): the threshold was the problem, not the measure. The mid-segment cut read 4.15 on cuda:1 and under 4.0 on cuda:0, against a 4.0 ceiling, while the 282 good bench segments peak at 2.98. The default cut_ratio_max is now 3.5 (0.5 over the good max, 0.65 under the observed cut). The measure and the acceptance claim stand; jump_ratio_max and look_ratio_max are unchanged. A cut that reads under 3.5 on a card (segment 4 here was under 4.0 but its value was not reported) now fails cut_ratio and re-rolls once; segment 5 (17.25 / 4.95) still fails as before. I did not rerun it over MCP; that is yours.

Estimate point: not changed. The (1 + retries) worst case is only priced for workflows with a basis, and no priced chain template exposes check/retries; the bench workflows have none, so estimate is null for them. That is existing behaviour, not a new surface; I did not add one. Verify the estimate is out of scope for this fix, or file it as its own ask.

Commit fd2bf1cd on develop, deployed to lem at 19:10 (healthy). Docs (WORKFLOW_GUIDE.md, the long-form skill's run-and-repair table) quote 3.5.

Architecture review queued by the loop driver: this hand-off changed dw/ or dw_mcp/ on develop (a678d5bfc1..fd2bf1cd6d: dw/pipeline_processors/chain_check.py). The reviewer checks it against docs/ARCHITECTURE.md before the tester verifies.

Architecture review of a678d5bf..fd2bf1cd (#1205 commit b6e71fcf) by the reviewer, model claude-opus-5-5 via provider anthropic: pass, no findings.

Read: git diff under dw/ and dw_mcp/. The only change is in dw/pipeline_processors/chain_check.py: CUT_RATIO_MAX goes from 4.0 to 3.5, with a two-line rationale comment. Checked against item 3 of docs/stabilization/harness/stage-c-guardrails.md and docs/ARCHITECTURE.md:

Second owner: none. The default lives only in chain_check.py, which the map row for the chain check names as its owner. CheckConfig.cut_ratio_max defaults from the constant. dw/workflow_schema.json and chain_rules.py validate the type and range only and don't copy the default.
Build vs. buy: not applicable. It's a constant change.
Map: no new owner and no rule moving between modules, so no row update is due.
Context: the rationale is in the owning module's comments. No CLAUDE.md changed.

Not blocking: in the comment block above the constant, the old line "The seam's own ceiling, 4.0, sits between" (line 51) still trails off. The new #1205 lines after it don't finish that sentence.

On to the tester for the MCP verify.

Navigation Menu

Repository navigation

#1199 stage 4: per-segment check with a bounded re-roll #1205

Run 1: the repro (`chk-s3-seg4-broken`, `check: true`, `retries: 1`)

Run 2: S1 false-positive probe (`check: true`, `retries: 0`)

Validation (free)

What the lead needs to settle

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

#1199 stage 4: per-segment check with a bounded re-roll #1205

Description

Activity

dkackman commented on Nov 7, 2026

Run 1: the repro (chk-s3-seg4-broken, check: true, retries: 1)

Run 2: S1 false-positive probe (check: true, retries: 0)

Validation (free)

What the lead needs to settle

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

Run 1: the repro (`chk-s3-seg4-broken`, `check: true`, `retries: 1`)

Run 2: S1 false-positive probe (`check: true`, `retries: 0`)