Pieces B and C: Scene gains source_image (aspect-ratio reference only --
resolution itself stays a project.video setting, ImageTransformKJ's
"total_pixels" keep_proportion fits the picture's aspect into that budget)
and references (media ids, in order). Inspector's Scene tab gets pick/clear/
remove controls; picking routes through the existing Media bin via a small
pending-pick handshake in boot.js (one bin, one onPick, so "which field
asked" has to be tracked between the click that asked and the click that
answered).
References wire into MiniMaxH3ReferenceToVideo's ref_images autogrow input
dynamically, per run, only for what a scene actually has -- an unwired slot,
not an empty image, is what "not in use" means to that node. The target is
data on the role itself (wireTo), not a slot id boot.js would otherwise have
to know, keeping the "core never names an implementation" contract intact
one layer up into the app.
Verifying this exposed a second real core gap (after the MatchType one):
core/graph.py had no idea what an Autogrow (V3's io.Autogrow) input even
is -- "ref_images" reported as one opaque COMFY_AUTOGROW_V3 slot, its real
per-instance sockets (ref_image_0, ref_image_1, ...) invisible to
declared()/build(), so a wire naming one was refused as an input the node
does not have. Fixed generically in comfy_types.py (autogrow_instances())
and graph.py, confirmed against ComfyUI's own _io.py (finalize_prefix's
dotted join, build_nested_inputs's runtime un-nesting) -- not guessed, and
proven end to end with a real override()+build() test using the exact edit
boot.js makes.
Round 4 of adversarial review, both reproduced live:
1. removeButton's mousedown-only wiring (round 3's own fix) dropped keyboard
activation entirely -- Tab-to-focus, Enter/Space did nothing, silently.
onClick is wired back alongside the mousedown handler; a real mouse click
still fires both, but the removal it triggers is idempotent (see below),
so the second call is a safe no-op.
2. Deleting a row that ITSELF still has an uncommitted edit could corrupt a
DIFFERENT, already-saved row. removeButton's own synchronous redraw
detaches whatever field still has a pending edit; a browser fires `blur`
on a detached-while-focused element even with preventDefault() called on
the mousedown, and that reentrant commit -- firing INSIDE the very
setVariables() call still removing a row -- was still indexed against
the row's OLD numeric position in an array that had already shrunk by
one underneath it.
Both share one cause round 3's fix narrowed but didn't remove: every commit
and removal in this editor addressed a row by the numeric index a render
closed over, and a synchronous redraw can invalidate that index before a
still-in-flight commit reads it. Fixed by addressing rows by the row OBJECT
itself, found by reference in the CURRENT array at the moment a commit or
removal actually fires -- a row no longer there (already removed, whether by
the user's own click or a reentrant one) is a no-op instead of a slot number
that now means something else. Confirmed with two new Playwright tests:
editing then removing the SAME row leaves the neighbour untouched, and
Enter/Space on a focused ✕ removes it.
Round 3 of adversarial review, reproduced live: type an uncommitted edit
into one Variables row, then click a DIFFERENT row's own delete button
without blurring the first. The click's mousedown blurs the edited field,
which commits and triggers a full non-keyed redraw of the whole list
(inspector.js draw() -> node.replaceChildren()) -- destroying the delete
button mid-gesture, so the click that started on it never arrives. No
error, nothing removed, no sign anything happened.
Fixed with the same mousedown+preventDefault idiom this session's own
autocomplete.js already uses for the same reason: stop the browser's
default focus-move (and the blur/commit/redraw it would trigger) before it
can pull the target out from under its own pending click. Confirmed with a
Playwright test reproducing the exact sequence.
Round 2 of adversarial review found a real bug in the fix the previous
round's own review prompted: mutating the live project.variables array (and
its row objects) in place before calling setVariables() meant projects.js's
remember() -- which deep-clones the project for the undo stack BEFORE
applying the new value -- captured the already-edited state as the "before"
snapshot. Undo after any variable edit or removal was a silent no-op.
Fixed by never mutating what project.variables already points at: every
commit now reads project.variables fresh and hands setVariables a brand new
array, which is also what closes the SAME stale-closure race the in-place
version was built to fix in the first place (redraw-mid-edit still reads
whatever the previous commit already saved, since it reads live rather than
from a snapshot taken at render time). Also fixed core/prompt_build.py's
docstring, which claimed the opposite of what resolve-variables-last
actually does and what its own test already pinned.
A trigger->replacement library (core/shortcuts.py, a close port of v4's
apply_prompt_shortcuts/resolve_variables), a Settings section to manage it,
autocomplete on the real prompt textarea (composer.autocomplete.default, so
it outranks the Constructor modal it lives inside), and a stateless
/api/prompt/expand that combines anchor + shortcuts + $variables + postfix
at the moment a run is queued -- scene.text itself stays exactly what was
typed. Project gained anchor/postfix/variables editing UI on its own tab.
Along the way: a real layout bug in the Properties column (every composer
stack can flex-shrink below its own content, and once the Project tab grew
past a couple of rows the column started squeezing its own children's
content into each other and, at the outer level, into the sibling Generation
section below) -- fixed with flex-shrink:0 at each level that needs it,
caught by a Playwright regression test.
Most FunPack pipelines run at CFG 1, where a negative prompt does
nothing -- it was one more box beside the prompt every Generate reads,
for a field only worth touching occasionally. The reference pipeline's
negative role now targets "project.negative" instead of
"generation.prompt"; the inspector's Project tab hosts it, in a STABLE
node outside the part draw() tears down and rebuilds on every scene
selection, so a field mounted there survives normal use.
dev went binary on H3 and said why: the steering reads the SIGN of a rating
and never its size, so a ten-point scale was the UI claiming a precision
nothing downstream used -- and at the sample sizes this actually runs at, a
mediocre middle rating only diluted the direction. v5 had invented a
four-way scale of its own; it now stores what dev stores.
Pressing the one that is on takes it back. Without a way out a mis-click is
a permanent opinion, and "no opinion" is a real answer nothing should have
to guess at.
The surfaces v4 has that v5 did not. Each announces itself and each can be
absent without the rest noticing, which is the point of the exercise: the
frontend should read as v4, and nothing in it should be load-bearing for
anything else.
* SCENE AND PROJECT, in the column v4 keeps them in, which now says which
scene it is about. Length on the timeline is the scene's own CROP and says
outright that a regenerate reads the project's -- the rule that mixing the
two is how a per-scene value quietly becomes everyone's.
* RATINGS on a scene, and a clip carries its rating as a colour on its edge.
Stored, not yet read: nothing in v5 learns from them yet.
* A RULER, and clips as wide as they are long, so the strip reads as time
rather than a row of equal boxes. Both ends bounded -- one long clip must
not become the whole strip, and one short one must stay hittable.
* THE PICKER WHEEL, on the middle button anywhere. It shows whatever
announced itself to actions.js, so a part of the app that grew a new action
is in the wheel without the wheel being told, and a part that failed to
load is simply not among them. v4's three pinned buttons had a fixed idea
of what could go in them.
* THE WAY IN, and it closes -- on Escape, on the backdrop, on its own button.
v4's could only be completed: a page refresh was the only way out, which
makes it a trap rather than a wizard. Dismissing is a real answer.
* File > rename, and the listing moves with it rather than going stale until
a reload.
Two things the kit refused, correctly, and now nobody has to know: a wheel of
fewer than two items throws (there is nothing to aim between), so the shell
does not offer one; and a strip cell with no ceiling took the whole strip.
digital-garbage