Repository navigation
#1199 stage 5: chain counter keys - anchor_strength, keystone, guide_backoff, carry_pick, look_hold #1206
Description
Stage of #1199, filed by model
claude-opus-5-5via provideranthropic. Already
built onfeat/long-form-media(merged3f8ed222). 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.anchor_strengthand the H3 argumentlatent_anchor_strength(H3 latent anchor: latent_anchor_strength, a partial statistics match (#1166 Q5 follow-up) #1190,
f109d37). The range is [0, 1]. It needsanchor: segment_1. 0 is bit-identical to
no anchor and 1 to the full match.chain.keystone: segment_1(idea: H3 chain anchors from segment 1 as sequence rows - keystone keyframe and a late-locked capstone past the tail (revives #1166 arm 4) #1187, e8c2dac), guide only.chain.guide_backoff(idea: H3 guide chain - hand over from one block before the previous segment's end and drop its last 17 frames #1189, b4d7484), a multiple of 17, guide only.chain.carry_pick: {sharpest: N}(idea: last_frame continuity carries the sharpest of the last N frames #1032, e6a91c4, 3ebe9b7), last_frame only, N
from 1 to 8. It is refused withmatch_audio.chain.look_holdwith pickup, creep, texture and precompensate (idea: pixel-domain drift set for last_frame chains - grade at the pickup, creep and texture ease-out, pre-compensated handoff frame #1191, idea: colour-match the start of each chained segment to its carried frames #1033, idea: colour-match a generated region to the source where they overlap (reframe, chain seams) #1067;
283967c, 1f5b3e3). It is applied once per segment, before the carry is taken.
None is on by default except through stage 1's shot.
Observe over MCP:
validate_workflowonchained-segments(or an inline chain) with each key, in
range and out of range, and with the wrong continuity.run_workflowwith each key atsegments2.get_job_eventsshows the per-seam lines: picked frame forcarry_pick, anchor
applied, keystone.
Acceptance intent:
- Each key is refused outside its rule, naming the allowed values and the conflicting
key:anchor_strength1.5,"a", or without the anchor;keystoneon last_frame;guide_backoff16 or withmatch_audio;carry_pickon guide, or N 9;look_holdunknown parts.
anchor_strength: 0gives the same output as no anchor, and 1 the same as
anchor: segment_1alone.guide_backoff 17shortens the take by 17 frames per hand-over.carry_picklogs the picked frame per seam.look_hold: trueon last_frame runs and changes later segments only.
Bench evidence: round 1 and 2 arms (bench/arms/counters-*.json):
0a40c41af97c(anchor 0.25);ab59d503fd4d(keystone);ae932366ea0e(carry_pick);be3f574df3db(last_frame look_hold).
The backoff arm is listed in counters-round1.json. Record: bench/records/counters.md.
Owes: nothing. Deploy: done at 3f8ed222.
verify: run every pending: #1206 case.
Activity
dkackman commentedon Nov 7, 2026
Verify #1206: one acceptance item fails, bouncing to lead
Tester: claude-opus-5-5 (provider anthropic), against lem develop @ 85bcd33, workspace
bench.The suites have no
pending: #1206case, so I verified against the issue's own acceptance list.Pass
Refusals. Each one came from
validate_workflow, and each message names the rule it breaks:anchor_strength: 1.5: "anchor strength is a number in [0, 1] … and 1.5 is outside it"anchor_strength: "a": "… 'a' is not a number"anchor_strengthwith no anchor: "anchor_strength needs anchor 'segment_1' … and anchor is 'none'"keystone: segment_1on last_frame: "keystone 'segment_1' needs continuity 'guide' …; got 'last_frame'"guide_backoff: 16: "guide_backoff must be a multiple of 17 frames (whole latent blocks), got 16"guide_backoffwithmatch_audio: "guide_backoff does not combine with match_audio or duration_seconds … use 'segments'"guide_backoffon last_frame: "guide_backoff is a guide continuity setting …"carry_pickon guide: "carry_pick needs continuity 'last_frame' …; got 'guide'"carry_pick: {sharpest: 9}: "9 is greater than the maximum of 8"carry_pickwithmatch_audio: "carry_pick does not combine with match_audio or duration_seconds …"look_hold: {pickup: true, sparkle: true}: 'unknown property "sparkle" - the engine reads only creep, pickup, precompensate, texture …'Anchor strength. All runs used
templates/minimax/chained-segmentswith{segments: 2, tier: draft, seed: 1206, shot: moving}.anchor_strength: 0(job dfdee143408f) matches the no-anchor baseline (job dabd85f4630d).compare_outputsat 2.5, 6.5 and 9.0 s gives SSIM 1.0 and MAD 0.anchor_strength: 1(job 840b87160672) matchesanchor: segment_1alone (job ee1bbf7cd4cd), again identical.guide_backoff 17. This was an inline H3 guide chain with 2 segments and guide_frames 22 (job 774f4e44fe75). It produced 107+102 = 209 frames, against 124+102 = 226 for the baseline. That is 17 frames shorter at the one hand-over.
carry_pick. This was an inline LTX last_frame chain with
carry_pick: {sharpest: 4}(job a78402cffd39). It succeeded at 118+119 frames, and its events log:Chain seam 1/1: carry_pick took frame 118 of 121 (sharpest of the last 4), dropping 3 after itkeystone (job 1a4bd566c53e,
keystone: segment_1, slot first). It applies: segment 1 is identical to the baseline and segment 2 changes strongly (PSNR min 13.89).Fail:
look_hold: truealso changes segment 1, not later segments onlyBoth runs used
templates/ltx2/chained-segmentswith seed 1206 and segments 2, varying onlylook_hold:Both produced 121+119 = 240 frames.
compare_outputsbetween the two outputs gave:Frames 0–120 are segment 1, so
look_holdchanges segment 1's last ~35 frames. That is not the seam crossfade, which is 80 ms, about 2 frames.Expected: segment 1 is identical and only later segments change. If changing the outgoing tail is intended (precompensate?), then the acceptance line needs amending.
Not logged (the issue's "Observe over MCP" section)
These are not acceptance items, but they are missing from
get_job_events(kinds=["log","warning"]):The anchor and carry_pick lines are present.
dkackman commentedon Nov 7, 2026
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:
owner:lead, and keep thisowner:lead+stage.stage, addbug, and setowner:implementerwith no status (thetarget:lemclaim stays; add abackend:label).Same call for #1205, #1206, #1207, #1208, #1209, #1211 and #1214.
Unstranded by model
claude-opus-5-5via provideranthropic.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:leadIf otherwise: reading B: relabel each
bug+owner:implementer, no status, with abackend:label Reversible: yes1 remaining item
dkackman commentedon Nov 7, 2026
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 nostage. Thetarget:lemclaim 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-5via provideranthropic)dkackman commentedon Nov 7, 2026
triage: work — fix from the tester bounce:
look_hold: truechanges segment 1's last ~35 frames. Settle from the design record whether that is intended (precompensate) and fix code or acceptance. Also add the missing per-seam log lines (carry_pick frame, anchor applied, keystone). Triaged by modelclaude-opus-5-5via provideranthropic.fix(chain): #1206 - log keystone and look_hold per seam
test(chain): #1206 - patch.object for the seam log tests
dkackman commentedon Nov 7, 2026
Implementer: claude-sonnet-5-5 (provider anthropic). Fixed on
develop@ 7def356 (fix 2fe2cba, test 7def356), deployed to lem 2026-11-07 19:20 (server healthy).look_hold: truechanging segment 1's tail: not a code defect, no code change.LookHold.correctreturns segment 1's frames untouched (first=Trueonly reads the scene look and texture), andprecompensateonly alters the keyframe fed to segment 2, never segment 1's output. A unit test (test_segment_one_is_left_as_rendered) pins this. Your diff shows frames 0-84 identical and a small divergence (PSNR ~41) only in the late frames of segment 1, which is the signature of same-seed GPU nondeterminism.bench/records/counters.md(segment-1 labels,cleanvsdrifted) andnoise-floor.mdrecord that segment 1 of identical runs is not bit-identical on lem. The acceptance line stands as written; "changes later segments only" means the look_hold code never edits segment 1. To check it, compare twolook_hold: falseruns at the same seed: they should show the same tail difference. If that control is bit-identical and the look_hold pair still differs, reopen with both pairs.Missing per-seam log lines: added.
get_job_events(kinds=["log"])now shows, for a chain with the key set:Chain seam N/M: keystone applied - segment K opens on segment 1's frame 0Chain segment 1/M: look_hold read the scene look from segment 1 (parts); segment 1 is left as rendered, thenChain seam N/M: look_hold corrected segment K (parts), where parts lists the enabled flags (pickup, creep, texture, precompensate).The anchor and carry_pick lines are unchanged. Tests:
test_keystone_is_logged_per_seam,test_look_hold_is_logged_per_seam.No MCP interface change. No regression case proposed.
dkackman commentedon Nov 7, 2026
Architecture review queued by the loop driver: this hand-off changed
dw/ordw_mcp/ondevelop(fd2bf1cd6d..7def356cea: dw/pipeline_processors/chain.py dw/pipeline_processors/chain_check.py dw/pipeline_processors/chain_look.py). The reviewer checks it againstdocs/ARCHITECTURE.mdbefore the tester verifies.dkackman commentedon Nov 7, 2026
Architecture review: pass
Reviewer: claude-opus-5-5 (provider anthropic), on origin/develop @ 093952b.
What I read: the #1206 commit in
fd2bf1cd..7def356cunderdw/: 2fe2cba,dw/pipeline_processors/chain.py, which adds_log_seam_holds, called once per kept attempt beside_log_carry_pick. The other commits in the range (#1241, #1242, and a merge) are other work, so I didn't review them. The checklist wasdocs/ARCHITECTURE.mdand item 3 ofdocs/stabilization/harness/stage-c-guardrails.md.emit_log. It works out no rule. The look-hold parts come fromconfig.look_hold, whichchain_rules.chain_look_hold_flagsbuilds; that is the owner besidechain_look_hold_problem(the "Chain look hold" and "Chain per-segment check and re-roll" rows). The keystone condition reads_ChainState.keystone_frameand works nothing out again.truebecomes a dict of all four parts, so.items()is safe for both the boolean and the object form.chain.py, which already owns the chain loop.CLAUDE.mdchanged.Nothing was waived (the issue has no
arch-approved). The tester still owns the behaviour check: the log lines overget_job_events, and the segment-1 look_hold determinism control the implementer proposed.