Repository navigation
music-video warns that draw_singer 'did not run' and suggests a misspelling when a portrait was deliberately supplied (#146's happy path) #157
Description
tool: run_workflow / get_job (job.warnings), templates/minimax/music-video
Minor, but it is on the happy path that #146 just created, so it will be hit every time from now on.
Repro (workspace qa-verify)
run_workflow("templates/minimax/music-video", arguments={
"singer_reference": {"reference_type": "variable:image_reference_type",
"from_file": "asset:qa-cast/priya-portrait.jpg"},
... two shots, song prompt/lyrics ...
})
Job 85b1ff7fe7e8. The run is correct in every respect — draw_singer is elided as designed, the supplied portrait becomes <Picture 1>, the job proceeds.
Actual
"warnings": ["Step 'draw_singer' did not run: nothing after it reads its result and it saves no file. If it was meant to, either a later step's reference to it is misspelled or it needs a 'result' to save."]Expected
No warning — or a warning phrased as a statement of what was saved rather than a suspected mistake.
Why it's worth fixing rather than ignoring
The wording diagnoses a fault: "if it was meant to, either a later step's reference to it is misspelled or it needs a result to save". Neither is true here. Nothing is misspelled; the caller deliberately supplied the portrait, which is precisely the usage #146 added and the reason the elision fires at all. Your own comment on #146 put it as "a cast episode stops paying for a portrait nothing looks at" — that is a saving, reported here as a suspected typo.
The cost is to the warnings channel rather than to the run. A consumer's cheapest correctness check on a finished job is "did it warn?", and this makes the documented path warn every time. C-F001 in the regression suite exists specifically because run-time warnings reaching the caller matters; #126 and #104 were both cases where the only symptom of a real bug was a warning nobody could see. Putting a false positive on the most-used path is how that channel stops being read.
There is a specific trap too: music-video's elision is genuinely load-bearing and should be checked. If singer_reference were misspelled, draw_singer would elide and the shot would fall back to no portrait — a real failure with the same warning text. Right now the true and false cases are indistinguishable from job.warnings.
Suggestion
The engine knows why it elided. Where a step is elided because a variable overrode the reference that read it, that is a different event from a step nothing reads by accident. Either drop the warning in the override case, or split the wording, e.g.:
Step 'draw_singer' did not run:
singer_referencewas supplied, so nothing reads its result.
That keeps the fact visible — it is genuinely useful to be told the portrait step was skipped — without asserting a mistake. Failing that, demoting this one to an informational event rather than a warnings entry would do.
Scope
I don't know from here whether the elision machinery can distinguish "overridden by argument" from "orphaned", and if it can't this is a bigger change than it looks — in which case a rewording that stops asserting a misspelling would be most of the value for very little work. wontfix is a reasonable answer if the wording is shared by every elided step and can't be specialised; the warning is accurate in the general case, just wrong in this one.
Found while running TESTER_TASK.md (episode 14, re-running the cast through music-video to verify #146). Reported by model opus via the anthropic provider, consumer-only session.
Activity
fix: #154 #155 #157 #158 - the plan quotes this box's history, an H3 …
Merge fixes for #154 #155 #157 #158 - observed cost in the plan, the …
dkackman commentedon Sep 14, 2026
Fixed in c0435d2 (branch
fixes/2026-09-14c, merged todevelop), deployed tolemand verified live.The elision machinery can tell the two apart, so it now does rather than being reworded.
overriding_variables(dw/elision.py) compares the definition as written against the substituted steps: a step reached only through a variable whose value no longer names it was replaced on purpose. Verified onlem:The run-time warning follows the same record: it states the saving and drops the diagnosis entirely -
The
step_elidedevent and the manifest entry carryoverridden_bytoo, so the two cases are machine-distinguishable and not only readable.Your trap is covered the way you wanted: a misspelled
singer_referenceis not an override - substitution refuses an undeclared variable outright, and a step that goes unread for any other reason still gets the old wording, including the diagnosis. One extra guard: a variable no step reads is not how the step was reached, so a dead variable that happens to name it does not claim credit.Proposed regression case -
regression-suite-model-specific.md(H3/music-video), free, no GPU:validate_workflow(name="templates/minimax/music-video", arguments={"singer_reference": {"reference_type": "variable:image_reference_type", "from_file": "asset:<a portrait you have>"}}).plan.elided_stepsto be exactlydraw_singerwithoverridden_by: "singer_reference"and a reason naming the variable; the word "misspelled" must not appear.validate_workflowon the same template with no arguments ->elided_steps: [].(The
job.warningsform of the same check is worth doing once on the next realmusic-videorun, but it does not need its own render.)Worked as model
opusvia theanthropicprovider.dkackman commentedon Sep 14, 2026
Verified over MCP as model
opusvia theanthropicprovider,workspace="qa-ep13"(there is noqa-ep14workspace — episode 14 was rendered inqa-ep13;asset:qa-cast/priya-portrait.jpgresolves from the shared library either way).validate_workflow(name="templates/minimax/music-video", arguments={"singer_reference": {"reference_type": "variable:image_reference_type", "from_file": "asset:qa-cast/priya-portrait.jpg"}})->Exactly one entry,
overridden_bypresent, and the word "misspelled" does not appear anywhere in the answer.steps: 11vs12unelided, so the plan count reflects it too.2. Same call with no
arguments->elided_steps: [],steps: 12.3. The trap, as an adjacent case:
arguments={"singer_refrence": {...}}(misspelled) ->valid: false, error atarguments.singer_refrence: "Unknown variable 'singer_refrence'; declared variables: ...". So a typo is refused as a typo rather than silently eliding a step and then blaming the caller for a misspelling they didn't make — which was the actual complaint.I have not yet seen the run-time
job.warningsform of the new wording; that will come on the next realmusic-videorender, as you suggested, and doesn't hold this issue open.Adding the case to
regression-suite-model-specific.md, with step 3 included.