main.ts awaited nineteen separate import() calls before registering the
extension. Each became its own chunk, and every module two of them shared
became another, so an empty canvas fetched 43 JS files (166.5 KB gzip)
before the extension could register.
The widget glue still has to be loaded before registration: ComfyUI does
not wait on a Promise from getCustomWidgets, and init runs right after
extension loading, so there is nothing to gain by deferring it. Instead:
- src/boot.ts gathers everything registration needs behind one import, so
it ships as one chunk and the lazy chunks import from it.
- The toast stack mounts on the first toast, the Display playground on
first open, the subgraph badge module when the graph has a subgraph node.
- The template editor's RichTextInput is lazy, like every other widget SFC.
Empty canvas: 2 JS files, 92.1 KB gzip. Total js/ 409.9 → 397.4 KB gzip.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017zVr7mDVkhk2bo1yRPVVZa
The page took its headline from the cached update check, which survives an
update for up to six hours. After updating to 2.17.0 it still said
"Release notes for v2.15.3" while the earlier-releases list below already
had 2.17.0. The headline now uses the newest release either source knows,
and a cached check or history older than the running build is refetched.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0129KsfAu5bvhBAnCS8AsyoN
Self-review fixes:
- A bundle nested in a bundle now runs its modules, expanded inline the
way the canvas insert does, instead of being skipped.
- A run that finishes after switching scenarios no longer shows its
result on the new scenario; its summary still lands on its own.
- A stack of bundles picks a default output from the combine (or last
binding) inside them.
- Scenario runs execute in a worker thread so a large run doesn't stall
ComfyUI's event loop.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Xwq95EvrKu6WgE9D5rahKy
The release job built js/ + web/ before semantic-release stamped the new
version, so the release zip carried a bundle one version behind its
pyproject.toml and the new update notice would never clear.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0137To3tFTPKen2wYqEo3wme
A combine whose template has no variables, references or choices
renders the same text on every run with no warning. Its stack card now
says so, and the Outputs note explains why the output never varies.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Xwq95EvrKu6WgE9D5rahKy
Samples always has a column for the output variable, so a one-module
stack no longer shows a table of bare seeds.
The seed trace now shows the nested @{ref} picks each module made, as a
tree, with what each ref expanded to. The engine records them only when
the caller seeds ctx["__wp_ref_log__"] (the Test Runner does; canvas runs
don't), and nested picks count toward their wildcard's pick totals.
A stack card now says when it reads a $var that no pin and no earlier
item sets, which is the usual reason a combine keeps producing the same
text, and the Outputs tab points at it when the output never changes.
The trace no longer shows "no change" under a module that wrote values.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Xwq95EvrKu6WgE9D5rahKy
Stack cards are cleaner: a step number, a small on/off switch, and a
remove button that shows on hover. Cards reorder by drag, or Alt + arrow
keys, instead of a row of arrow buttons. Switching a card off and on
again no longer marks the scenario as changed.
The output flag and badge are gone. Which variable counts as the output
is now picked in the Outputs tab, where the choice shows its effect.
The seed control is a Range/Random switch with plain number fields, and
the header, pinned values strip and variable bars are tightened.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Xwq95EvrKu6WgE9D5rahKy
The Test Runner page is now a workbench on the real engine: a rail of
saved scenarios, a stack builder that lines library modules and bundles
up like a Context node, pinned values, a seed range, and results in
Variables, Outputs, Samples and Warnings tabs with a per-seed trace.
Every run goes through POST /wp/api/test/run, so the numbers match what
the canvas produces for the same seeds. Send to Test Runner opens an
unsaved quick run and runs it straight away.
The old single-module sampler and its in-browser simulator are removed:
the /wp/api/test route, api.test, TestRequest/TestResponse and
utils/resolver.ts.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Xwq95EvrKu6WgE9D5rahKy
Migration 018 adds a test_scenarios table, and /wp/api/test/scenarios
gives it list/get/create/update/delete. A scenario stores its stack
(library modules and bundles referenced live by id), pinned $var
values, seed spec and output variable, plus two JSON blobs the Test
Runner writes: a baseline to compare against and the latest run
summary. Listing can filter to the scenarios that use a given module
or bundle, for the "used in N scenarios" hint.
Scenarios are local only. They are not part of Import/Export or the
community, and this is a row-level table, so no schema_version bump.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Xwq95EvrKu6WgE9D5rahKy
Add POST /wp/api/test/run. A scenario is a stack of library modules and
bundles, optional pinned $var values and a seed spec (a range, N random
seeds or an explicit list). Each seed is one real PipelineEngine run, so
seed N here is seed N on a canvas Context node with the same modules.
The response carries per-variable counts of fully expanded values,
per-option pick counts, constraint hit totals, engine warnings grouped
with the seeds they fired on, and the first N samples with their trace.
Missing modules are reported and skipped so saved scenarios keep working
after a delete.
The engine side lives in engine/scenario.py (no ComfyUI or DB imports).
The client gets api.testRun and its types; the page moves to it in a
later change, together with removing the old /wp/api/test sampler.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Xwq95EvrKu6WgE9D5rahKy
ComfyUI lists every **/*.js under WEB_DIRECTORY in /api/extensions and
the frontend imports each one, so every lazy chunk loaded on every page,
even with no WP node on the canvas (62 files, 1.73 MB raw). Only main.js
keeps .js now; an empty canvas loads 42 files, 576 KB raw.
The size gate counts .mjs and reports it under the old .js names so base
and head still diff. The stale-asset prune matches .mjs, and on the first
start after updating it deletes the old .js chunks.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0137To3tFTPKen2wYqEo3wme
/wp responses now carry X-WP-Version (the installed pyproject version).
The manager's stale banner names the new version, and the canvas shows a
one-time toast with a Refresh button, when it differs from the version
the page was loaded with.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0137To3tFTPKen2wYqEo3wme
The canvas constraint editor now shows the same Linked note as the
manager, following instance mode overrides, disabled rows and extras.
The manager's exceptions table reads source_value/target_value first,
matching the engine, so rows written with the newer keys no longer load
blank.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0137To3tFTPKen2wYqEo3wme
The cell popover, matrix legend, SPA exceptions picker and canvas
exceptions cycle all gain Only. Neutral cells in a row that has an Only
rule show a faint x, since they are shut out at run time. The SPA
exceptions table says which source values are linked.
The canvas matrix now stores a neutral override as `allow`, the engine's
name for it; it used to store `neutral`, which failed the constraint.
Docs: add a Linking picks section, and correct Allow, which the docs said
keeps only the matching options when it has always meant no change.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0137To3tFTPKen2wYqEo3wme
A payload with an `only` rule anywhere (library matrix or exceptions,
instance extra exceptions, instance mode overrides) now stamps
CONSTRAINT_ONLY_SCHEMA_VERSION (6) in both the TS publish path and the
Python exporter, and MAX_KNOWN_SCHEMA_VERSION moves to 6. An older engine
rejects the unknown mode outright, so the stamp makes that extension refuse
the pack and ask for an update. Additive: no migrator, CURRENT stays 2.
Needs community catalog v6 deployed first (server-first ordering).
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0137To3tFTPKen2wYqEo3wme
A constraint rule with mode `only` turns its row into an allow-list: when
the source fires, a target with no rule of its own in that row is excluded.
On an exception it links literal values (maid forces frilled apron); in a
matrix row it links tags. Before, a link needed an exclude rule for every
other target, and a target added later slipped through.
The rule itself weighs 1.0 and targets with any other rule keep it. A matrix
`allow` cell does not count as a rule because the editors show it as
Neutral. The axis-menu probe ignores value-level `only` so a tag link in
the same constraint still pins an accepts roll. Python and TS folds stay in
step through new constraint-corpus cases.
Also reads a legacy `neutral` cell mode override as `allow`: the canvas
matrix stored that value, and the engine rejected it, failing the whole
constraint.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0137To3tFTPKen2wYqEo3wme
When the picked option carried no tag on a declared accepts axis, the run
warned "$outfit has no 'SHOES' axis — is that tag group marked
'accepts'?", sending users to fix a group that was fine. Wildcards now
record which accepts axes they declare (`__wp_axis_decl__`, carried across
nodes and held seeds like `__wp_axes__`), so the resolver can tell the
cases apart: an untagged pick becomes an info note, and a genuinely
unknown axis names the axes that do exist.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BxeNnfTMTyaKQwCYWA6frg
Renaming an accepts tag group to a name `$var.NAME` cannot parse used to
demote it to classify without a word, silently emptying every
`$var.AXIS` read of it. The rename is now refused with a toast (same rule
as promoting such a name), and the input puts the old name back. A name
colliding with another group now does the same instead of leaving the
input showing a name that was never stored.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BxeNnfTMTyaKQwCYWA6frg
New Docs page "Chips & references" (How it connects): what a chip is, its
three states (resolved, filtered, broken), how to make a placeholder $var
chip, the four-segment @{uuid#name:filter!null} form versus plain @name, and
the sub-category filter grammar (not / and / or / comma, parentheses,
precedence, reserved words, null as a flag). Registered with keywords so a
docs search for "chip" or "filter" finds it. Glossary gains Chip, Reference
and Filter expression; the wildcard and variable-pipeline pages link to it.
Claude-Session: https://claude.ai/code/session_012LhbKjx2xyGYREkvcShihy
Co-authored-by: Claude <noreply@anthropic.com>
The assembler preview filled every `$var.AXIS` with the axis's first
tag, independent of the option the preview had picked, so it could show
"sandals | robe | red stilettos". /wp/api/preview/resolve now returns
the rolled `__wp_axes__` beside the values and the preview reads it
with the same shaping as the engine, falling back to the first-tag
guess only until the run answers. Also accepts the axis-first
`$var.AXIS.K` order the engine already parses.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011fQ7Lkc8AxwXqsRZrFBxE9
`$outfit.K.AXIS` compacted away picks whose option has no tag on the
axis, so every later index slid down and `$outfit.0.SHOES` could print
pick 1's shoe beside pick 0. Both the resolver (`get_axis`) and the
derivation condition reader now keep one slot per pick.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011fQ7Lkc8AxwXqsRZrFBxE9
build_export_payload always stamped CURRENT_SCHEMA_VERSION (2), so a file
export using range multi-picks, a non-default constraint target_select or
an accepts tag axis went out as v2 and an older extension installed it
while misreading or dropping those features.
Port the TS schemaVersionForPayload logic to engine/migrations/stamping.py
(same SP2b regex, reach and tag-axis walks) and stamp the export from all
buckets, auto-included inner bundles included. The SP2B / SP3 / TAG_AXES
constants now also live in engine/migrations beside MAX_KNOWN.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0174Xsr85WVPSVjSREXkSi5a
The vitest parity suite checks the TS validators against fixtures that
scripts/dump_engine_shapes.py writes, but nothing re-ran the script, so a
handler shape change left the fixtures silently stale. A pytest now
re-runs the dump in memory and compares.
CLAUDE.md's schema section pointed at files that don't exist
(import-export/validators/, migration-machine.ts, ENGINE_SCHEMA_VERSION).
It now names the real files and spells out CURRENT vs MAX_KNOWN vs the
content stamp, plus the additive-bump procedure.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0112KkzW3unDU8PGrTpTDL7r
A wildcard whose tag_group_kinds marks a group accepts now publishes as
v5 (TAG_AXES_SCHEMA_VERSION) instead of v2, and MAX_KNOWN_SCHEMA_VERSION
moves to 5 in TS and Python. An older extension strips tag_group_kinds
on install, silently turning accepts axes back into classify groups; the
v5 stamp makes it refuse the pack and ask for an update instead.
Additive like v4: no migrator, CURRENT_SCHEMA_VERSION stays 2.
Needs community catalog v5 deployed first (server-first ordering).
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0112KkzW3unDU8PGrTpTDL7r
wrapAsEngineExport pinned schema_version 1 and the dependency downloader
pinned 4. installEnvelope migrates from that number, so every community
update re-ran the v1->v2 migration over already-current content, and a
genuinely old dependency would have skipped the migration it needed.
Both now carry the download's own schema_version.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0112KkzW3unDU8PGrTpTDL7r
Backlog P1 "Text input instability on Firefox" asked for a clean repro of
the reported path on the current build: two-option wildcard, add a third,
Ctrl+A Ctrl+X an option into the empty one, twice. Driven in Firefox 153
against 2.14.0 across five variants (cut/paste chains, back-and-forth,
hammered without waits, cut twice in one field). None crashed, bricked the
field or logged an error; the fragment-anchor repairs from 2.13.x hold.
One real defect did reproduce, and it is the content-loss half of the
report. Ctrl+A on an empty field selects nothing but the ZWSP caret pad.
`onHostCut` / `onHostCopy` saw an empty raw selection and returned without
preventDefault, so the browser performed the cut itself and put the pad on
the clipboard, overwriting the text the user had just cut. The following
paste then wrote U+200B into the option value, where it is invisible and
effectively undeletable.
- Cut and copy now swallow a non-collapsed selection that covers no value,
leaving the clipboard untouched. A collapsed caret still falls through
to the browser as before.
- Paste strips ZWSPs from incoming data, so a clipboard that already holds
a pad (from an older build) cannot smuggle one into a value.
Re-measured in Firefox on the rebuilt manager: the double cut now pastes
"red dress" back, and all five variants stay clean.
Three QA screenshots (accepts-icon-candidates.png, accepts-mark-live.png,
refchip-card.png) were git-added by accident in fd6642b2 and landed on
main via the tag-axes merge. pack-release.mjs asserts every top-level git
path is either in SHIP_PATHS or DEV_ONLY, so these unclassified captures
failed the 2.14.0 release in the prepare step (no tag or release was cut).
Remove them and anchor `/*.png` in .gitignore: root-level PNGs are always
scratch QA captures here, while every real image lives under public/. The
anchor keeps public/images/** untouched and stops this recurring.
Wildcard page: correct the accepts fold description (one rolled tag, not an OR
over the menu). Variable-pipeline: $var.AXIS / $var.K.AXIS accessor row.
Constraints concept: an accepts-axis source keys on the rolled tag, an accepts
target OR-folds, and the two agree under a diagonal. Glossary + warning-types:
axis/accepts/classify terms and the two tag-axis warnings. next.md: tag axes
leads the highlights.
An accepts axis rolls one tag per pick (read as $var.AXIS), but a constraint
sourced from it folded over the option's whole menu instead of that rolled tag,
so $outfit.SHOES and the constrained $shoes could disagree. The source now
sends only the rolled winner; a target accepts axis OR-folds so a multi-tag
option survives when any alternative is allowed, then its own roll is pinned to
the allowed tag -- $source.AXIS == $target.AXIS under a diagonal. Classify
groups are unchanged (multiply).
The assembler also rendered $var.AXIS empty: __wp_axes__ crosses the socket on
ContextPayload.internals but the node only merged the internal-flag map; it now
merges the whole carve-out so the accessor resolves.
Import: the community validators silently dropped tag_group_kinds (and the
constraint target_select) because the lenient payload object never listed them,
degrading a shared accepts axis to classify. Both are now in the v2/v1
validators + the engine-parity fixtures, with preservation tests. Engine math
mirrored in TS via the shared corpus.
An accepts axis only yields a value for options that carry one of its tags; an
option with none makes $var.AXIS render empty when it's picked, with no other
symptom. The wildcard editor's sub-category panel now shows a non-blocking
amber note per accepts group when some options don't cover it ("N options carry
no SHOES tag — $outfit.SHOES is empty when it's picked"). Silent when the axis
is fully covered or the group is classify; the null option is excluded (it
deliberately produces nothing). Verified live both directions.
The constraint matrix showed an accepts group (SHOES) exactly like an ordinary
tag group — the editor tells them apart via its accepts button, but the matrix
couldn't. Plumb tag_group_kinds through to the grid (SPA ConstraintMatrix + the
canvas MatrixSection, both wired from their editor/modal) and mark an accepts
band with a small amber pi-sync after the axis name, keeping the group's own hue
so it never collides with an amber group. A hover tooltip and a MatrixLegend row
(shown only when the matrix has an accepts axis) explain the mark. Verified live:
mark on SHOES, none on a classify-only source, legend row appears/hides with it.
The exception mode dropdown clipped its labels and overlapped the selected
row's tick with a scrollbar. Two real causes, both in Select:
- `.wp-select__option-label` was `flex: 1` (basis 0), so it split the row 50/50
with the always-present spacer and squeezed a short nowrap option to
half-width, clipped by overflow:hidden even with room. `flex: 0 1 auto` sizes
it to content and lets the spacer do the filling; a long option still shrinks
into the 2-line clamp.
- The "Type to filter" hint showed for any list of 2+, and its height pushed the
4-item menu past its cap into a scrollbar that overlaid the tick. New
`filterable` prop (default on) turns the hint + type-to-filter off; the mode
picker sets it false, so 4 options render as a clean menu — no hint, no scroll.
The mode Select sits in a table cell that collapses the trigger narrow, and the
Select sizes its menu to the trigger — so the nowrap mode chips clipped to
"N / Exc / Boo / Red". Floor the control at 132px so Neutral / Exclude / Boost /
Reduce each fit. (This is the constraints-mode.mp4 report.)
The nested-ref hover card was 10px mono and pointer-events:none — the report's
"unnecessarily small", and un-clickable by design. Bumped to 12px and made it
interactive with a hover bridge (leave the chip, enter the card, it stays — the
GitHub-hovercard pattern), so a footer of actions is reachable: Copy id (with a
"Copied" tick) and Open (the linked module's SPA editor in a new window; full
phrasing in the title). Copy works even for a broken ref; Open is gated on the
ref resolving. The chip's own click is untouched, so no clash with the template
editor's click-to-edit-filter.
Two backlog items.
- The wildcard editor's sub-category panel now opens on load per a new
"Sub-categories panel" display-pref (Settings → Editing): "Expanded when it
has groups" (default), "Always expanded", or "Always collapsed". Resolved once
per load so collapsing it and adding a tag doesn't yank it back open. (Also
dropped a duplicated tag_group_kinds assignment in the load path.)
- "Send to Test Runner" jumps to the runner with a module/bundle preselected via
?kind=&module=, which TestRunner reads on mount. Added as an icon row action on
every list view (and All items, keyed by row.kind) and a labelled button in
every module editor header. New shared SendToTestRunner.vue.
The Save button and the validation banner sit at opposite ends of a long
editor, so clicking Save on a wildcard with 30 options did nothing the user
could see — a reporter clicked it five times before finding the banner off
screen. EditorFrame now watches its `errors` prop and, on the empty→populated
edge (the "tried to save while invalid" moment every editor already gates on),
scrolls the first offending field into view via the existing scrollToField.
Guarded to that one edge so re-validation on each keystroke while fixing it
doesn't yank the scroll. Covers all five editors at once.
Two backlog QoL fixes.
- duplicate_module dropped content_rating, so copying an 18+ module produced a
SFW copy that slipped out from under the filter. Forward it.
- Icon-only Buttons carried an aria-label (screen-reader name) but no title, so
a sighted user hovering a bare icon got nothing. Mirror the label into title
when there's no visible text — fixes every icon button at once.
Shift for seed lock and Alt for bypass didn't match the reflex — users reach
for Ctrl to bypass and Alt to lock. Swap to Ctrl-click (Cmd on macOS, where a
Ctrl-click is a right-click and never reaches the handler) for bypass and
Alt-click for the seed lock; Shift is freed. Plain click still selects (Loop)
or locks (Seed List, no cursor). Legend + tooltips + the three widget test
suites updated. Verified on the live canvas: ctrl→bypass, alt→lock, shift no-op.
Two bugs the modal-only testing missed, both verified in the live canvas.
1. Assembler template (and every inline `.wp-rt-var` render) mis-parsed an
index-first accessor. `varSpanAttrs` hand-rolled the axis extraction with a
`.replace(/\.\d+$/,"")` that only strips a TRAILING index, so
`$outfit.0.SHOES` produced axis "0.SHOES", matched no declared axis, and
painted a valid reference with the unknown-axis warning — the yellow
squiggle in the screenshot. Replaced with the one shared `varAccessorParts`
grammar (index + axis, either order), and split the inline tail into a
neutral index span and an amber axis span to match the settled chip. The
canvas CSS copy (rich-text-canvas.css) had no accessor rule at all, so the
amber never applied there — added it.
2. `instance.internal` was add-only in three places (engine pipeline, the
graph.ts kinds walk, the static resolver), so a var written internal then
overridden by a PUBLIC module stayed hidden from the assembler forever.
Made all three last-write-wins: whichever module writes the var LAST decides
its internal-ness, exactly like its value. Verified both directions live —
internal→public shows "public value", public→internal hides it.
A var chip's accessor is two unrelated things — a pick index (.0) and a tag
axis (.SHOES) — and both were rendered in one amber span. So `$outfit.0.SHOES`
painted the .0 amber too, and since amber is the axis accent it read as "the
index is an axis / the index is flagged". Worse for the exact case the user
hit: the index only means anything on a multi-pick source, and whether a
source is multi-pick is a runtime fact no static surface can know, so the
editor has no business colouring it at all.
Split the accessor into its own index span (neutral, dimmed, the chip's own
colour) and axis span (amber, or the unknown-axis warning). Only the axis —
the one part that names a library concept — carries a colour now.
The assembler preview walked the template with a regex that stopped at the
numeric accessor, so `$outfit.SHOES` matched `$outfit`, printed its value and
left ".SHOES" as literal text beside it. It now matches the whole reference
and resolves an axis against the chain's accepts axes — passed down from the
same walk that already feeds the resolved map — falling back to the raw
reference when the chain declares no such axis, so a typo is visible rather
than silently dropped.
Separately: `upstreamVars` is `Object.keys(fresh)`, and the API branch merged
the run ctx in without filtering, so every engine table rendered as a variable
chip. The fallback branch had always filtered; the API branch never did, which
is why the chips appeared as soon as a table existed to leak.
The preview tokenizer never carried the axis accessor, so every consumer
rendered the variable and left ".SHOES" beside it as text — which is why both
the PREVIEW and RESOLVED lines read "a white t-shirt and denim skirt.SHOES".
It now carries `axis` the same way it already carried `index`, and the combine
editor resolves an axis read to a tag rather than to the variable's value. An
axis the producer does not declare stays verbatim: swallowing it would delete
text the user typed.
Also undoes the leak from the previous commit. strip_internals' result IS the
variable surface — the assembler's variables panel enumerates it, so keeping
__wp_axes__ / __wp_picks__ there listed them as $__wp_axes__ chips. The tables
are re-attached by with_resolver_tables at the one call site that needs them.
Three separate places dropped an axis read on the floor:
- The producer map replaced a variable's record wholesale on every later
write, so a derivation or injector rebinding $outfit erased the wildcard's
axes. The engine keys __wp_axes__ by binding at pick time and a rebind
never clears it, so the axes must survive the override. Carried forward in
both the graph walk and the same-node sibling merge.
- The static preview resolver knew only the numeric .K accessor, so
"$outfit.SHOES" substituted $outfit and stranded ".SHOES" — the preview and
resolved lines both read "a white t-shirt and denim skirt.SHOES". It now
resolves an axis to its first tag, the same deterministic convention @{uuid}
expansion already uses, and leaves an accessor it cannot resolve verbatim
rather than deleting text.
- strip_internals runs at the prompt-render boundary and dropped every
__-prefixed key, __wp_axes__ and __wp_picks__ included. The assembler
therefore rendered "$outfit.SHOES" and "$outfit.0" as literal text while the
identical template resolved one node upstream. Those two tables are read by
key, never as variables, so keeping them cannot leak a $var.
Committing an autocomplete suggestion bumps hostEpoch, which replaces the
host element. In a browser that removes the node the caret is in, so the
browser fires blur on the way out — and onHostBlur treated it as the user
leaving: it read the already-detached host as "", saw that differ from the
atoms just applied, and re-applied the empty parse. Every $var commit wiped
the whole template, on the canvas and in the SPA alike.
Flag the swap and let blur skip it. jsdom does not fire blur on removal,
which is why the existing tests never saw this; the new ones dispatch the
blur the browser would, in the window before the swap settles.
allVarProducers merges the graph walk with siblingVarInfo.producers, and a
variable written in the same Context node takes the sibling entry wholesale.
Only the graph walk carried axes, so `$var.AXIS` completion went missing for
the most common layout of all: the wildcard and the template that reads it
sitting in one node.
Read the axes off the module's own payload snapshot rather than the library,
so the node offers what it will actually run.
A canvas node carries its own payload SNAPSHOT of each module, so a wildcard
added before its group was promoted has tag_groups but no tag_group_kinds at
all. The warning treated that as 'declares no axes' and put a wavy underline
under $outfit.SHOES - a reference that resolves perfectly well, and will look
fine again the moment the node's snapshot is refreshed.
Absence of the key means UNKNOWABLE, not empty. The mark is now claimed only
when the producer declares SOME axes and this is not among them, which is the
one case where the read is known to be wrong. Same rule on both the chip and
the flat-text surface.
Does not fix the missing axis ROWS on canvas: those come from the same stale
snapshot and need the node's module refreshed from the library, which is the
existing drift flow rather than something to paper over here.
Was the axis group's own hue, matching the pills in the wildcard editor.
That made one meaning look different from variable to variable - SHOES came
out teal in one wildcard and purple in another - when an accessor is the same
KIND of thing everywhere it appears. Now a single --wp-axis token used by both
the chip and the suggestion row.
Amber-400 deliberately, not --wp-warn amber-500, which marks an UNDECLARED
axis: a valid accessor must never read as the warning.
Also restores the accessor style block itself. Both earlier attempts anchored
on a .wp-refchip__label rule that does not exist in this file, so neither the
colour nor the unknown-axis mark had ever actually shipped - the class was on
the element with no rule behind it. Verified in the running SPA: accessor
rgb(251,191,36) against the chip's rgb(34,197,94).
Typing $outfit.0. closed the popover: the flat pool is substring-filtered,
and no entry contains 'outfit.0.'. $outfit. only ever appeared to work by
luck - the pool holds 'outfit.SHOES', which happens to contain 'outfit.'.
From the first dot the question changes from 'which variable' to 'which
axis', so the pool does too: it offers that variable's axes, narrowed by the
fragment after the dot, and preserves a pick index the user already typed
($outfit.0. -> $outfit.0.SHOES). Verified in the running SPA.
Found by driving the real SPA with Playwright; jsdom could not see it. One
Backspace after typing $mo turned it into a chip, closed the popover and
threw the caret onto the host root - three separate reports, one cause.
The modelValue watcher guards against our own echo with
'next === lastEmittedValue && readHostAsText() === next'. But the
atom-direct edit paths sync the host DOM imperatively AFTER updating the
model, so at emit time readHostAsText() still returned the PRE-edit string.
The guard missed, the watcher re-parsed through parseForSurface, and that
chipifies. emitValue now claims the single round-trip it is about to cause,
released on the next tick so an uncontrolled parent cannot strand the claim.
Also fixed, both verified live:
- the axis segment now takes its group's hue on the chip, not just in the
suggestion row; it was styled with opacity/weight only and rendered plain
chip-green. A pick index deliberately stays neutral - it is positional,
not semantic.
- the stale-results dimming applied to $var popovers, which have no async
fetch, so rowsQuery never advanced and the list read stale from the first
keystroke and never recovered.
- the axis row indent lost to a later padding SHORTHAND; now specificity-
based so source order cannot undo it.
QA sweep over axis authoring found the real fault under the reported
symptoms: the ATOM model had no accessor at all. VarAtom carried name and
index but no axis, and tokenToChipAtom never copied one, so $outfit.SHOES
round-tripped as $outfit - silent data loss, not a cosmetic issue. My
earlier fix was to inlineTokenHtml, a different layer, which is why the chip
still looked wrong.
Four hand-rolled var serialisers existed and one had already drifted:
parseForSurface wrote '$' + name and dropped a .K index, so $mood.0 lost
its accessor on the assembler surface today, independent of this feature.
All four now route through one serialiseVarAtom.
Also fixed from the sweep:
- the chip label was built from name alone, so the accessor never rendered
- a dangling dot ($outfit.) killed the trigger, closing the popover at the
moment the axis list was most wanted
- the axis row's padding-left was reset by a later padding SHORTHAND on the
base rule, so the indent never applied
- an undeclared axis was unmarked on chip surfaces; the warn styling had
only landed on the flat text path
Two reported symptoms did NOT reproduce and are not fixed here: caret jumps,
and backspace committing a chip. The Backspace handler deletes and
preventDefaults correctly - an early version of this test deleted twice and
manufactured the failure.
The reference stays ONE .wp-rt-var atom - caret math and deletion are
unchanged - but the .AXIS / .K tail gets its own span so it reads as a
qualifier rather than part of the name.
Also fixes a real bug behind it: varSpanAttrs checked the WHOLE string against
varSuggestions, so $outfit.SHOES matched nothing and every valid axis read
wore the unknown-variable error styling. Scope is a property of the base
variable, so the check now uses the base.
A base that resolves with an axis that does not is warn-coloured rather than
silent, matching the unknown_tag_axis conflict rule. The engine renders an
undeclared axis as an empty string, so without a mark the only symptom is a
word quietly missing from the prompt.
Typing 'out' now lists outfit and, indented under it, outfit.SHOES and
outfit.EXPOSES with the tags each will roll from. One Enter commits the whole
reference, so a committed chip no longer seals the variable before you can
reach its axis.
Flattened into the existing list rather than a second picker like @{uuid}
uses: that picker exists because a ref needs a typed filter expression and a
toggle, which cannot live in a list row. An axis is just a name, so a second
popover would be machinery the problem does not call for - and it would tax
every axis-bearing variable, including the times you wanted the plain $outfit.
The member tags are shown because they are what tell SHOES from EXPOSES. The
accessor segment takes its group's own hue via axisHueAt, indexed over ALL
groups rather than the accepts ones so it matches the colour that group wears
in the wildcard editor.
No index rows: pick_min/pick_max are per-instance, so a library-authored
template has no range to offer and any number shown would be true for one use
and wrong for the next.
Both surfaces already thread varProducers to RichTextInput, so axes ride on
that rather than a parallel map: the canvas reads them from the wildcard
payload during its graph walk, the SPA from the module catalog.
Read from the PAYLOAD deliberately. A group's kind is a library fact shared
by every instance, so completing against it is always correct - unlike
pick_min/pick_max, which live on the instance, so a library-authored
template has no pick range to offer and index completion is not
expressible at all.
Only accepts groups qualify: a classify group is not addressable as
$var.NAME, so suggesting one would complete to a reference the engine
renders as an empty string.
Two defects, both from the accessor grammar landing without the editor being
told about it.
varBaseName stripped a numeric .0 and nothing else, so outfit.SHOES matched
no known variable and never became a chip - the reference resolved fine at
runtime but looked like dead text while authoring. It now understands every
accessor shape and leaves genuinely invalid ones (two indices, three
segments) alone, since reducing those would claim a reference the engine
will not resolve.
The sigil probe walked back over SHOES, met a dot it did not recognise, and
gave up; the booru-tag probe then took the caret and offered shoe TAGS,
none of which are insertable there. It now skips up to two accessor
segments - one index and one axis, either order - and stops, so dotted prose
is not chewed backwards looking for a sigil.
An earlier version faded the classify capsule in on header hover to keep the
default state quiet. That optimised for ink over discovery: a control you
only see by accident is one most people never learn exists, and this is a
capability nobody is looking for yet.
Every group now states its kind. The dim weight keeps it from competing with
the axis name.
The pills this control governs are hue-tinted capsules; the control was a
flat grey square borrowed from the ungroup button, which is the vocabulary
of a utility ACTION. On a piece of state it read as a stray control and the
hover landed as a hard block unrelated to anything near it.
Now the same capsule recipe as the pills - hue fill, 999px, 1px hue border -
so it reads as a property of the axis, and hover deepens the tint already
there rather than adding a second colour. It is also labelled, where an icon
needed a tooltip before anyone knew what it toggled.
A classify group shows nothing until its header is hovered, so the default -
every group that exists today - costs no ink; only the promoted state, which
is real information, is permanently visible. Hidden with opacity rather than
display, so it keeps its place in the tab order and :focus-visible reveals it
for keyboard users.
The first version was a raw <select> with hand-rolled sizing - a 10.5px font,
a 4px radius and a 1px border, none of which exist in the design system. It
tripped both the typography and radius token audits and read as a foreign
form control in a header made entirely of icon buttons.
Now a 24px icon toggle with the same shape and hover as the ungroup button
beside it, tokens throughout, tinted with the group's own hue when promoted.
A classify group - which is every group that exists today - carries no extra
chrome at all; the promoted state is what earns the ink.
Being a toggle also removes the select-reset hack: the button renders from
tagGroupKinds, so a refused promotion can no longer leave the control
displaying a state that was never stored.
_pick_weighted returned options[0] when every weight was zero. That looked
like a working pick - a real option, right shape, right place - and stayed
wrong silently until the list was reordered and the choice changed. It hid
both over-narrowed constraints and a wildcard whose options were all
disabled.
Now returns None, which every caller already turned into an empty binding.
That is what the null option means, so the engine had the vocabulary for
this already.
Applies to all three pools that constraints can zero: the chain handler, the
nested-@{} path in the resolver, and the SPA preview. The inline {a|b}
branch weights are left alone - a user writing {0::a|0::b} is a different
situation and constraints never touch it.
Three tests asserted the old behaviour and are rewritten to state the new
one; the constraint_excludes_all_options warning stays, and now
distinguishes an over-narrowed pool from a legitimate null roll.
A user who had read the docs several times still expected $tag_name to
work, which was a documentation finding independent of any feature. Tags now
have two kinds, so the obligation got larger rather than smaller.
Teaches $outfit.0.SHOES as the one spelling. $outfit.SHOES.0 is accepted
but undocumented - offering both would hand the reader a choice with no
consequence.
The engine renders an undeclared axis as empty, so without a signal the
only symptom is a word silently missing from the prompt. Commonest cause is
a group that exists but still says classify; second is an axis renamed after
the read was written.
Deliberately conservative: the scanner runs per node and receives upstream
variables as names only, never payloads, so a read is checked only when a
wildcard in THIS node writes that binding. Guessing about an unseen upstream
producer would fire on correct workflows, and under-reporting beats a
warning nobody can act on.
The producer map is built before the module loop because a read can sit
above the wildcard that feeds it - resolution is by ctx, not by position.
A select on each group header, defaulting to classify. Only accepts entries
are ever stored and the payload key is omitted when nothing is promoted, so
an untouched wildcard saves byte-identically.
The name check runs here rather than at save: an accepts group is read as
$var.NAME, and hearing about it after the work is done is too late. On
refusal the select is put back explicitly - the bound value never changed,
so Vue has no reason to re-render, and it would otherwise sit showing a
state we just declined to store.
Rename carries the kind across and ungroup drops it, since a kind naming no
group is invalid payload. renameGroup's comment claimed axis names were not
part of any grammar; that stopped being true with $var.AXIS.
The reported failure: an outfit option tagged sneakers, high_heels and
sandals excluded every shoe in the constrained target, the pool summed to
zero, and _pick_weighted fell through to options[0] forever - looking like a
working pick until the list was reordered.
The kind map is derived from the pick records rather than passed down from a
payload, since a pick only carries an axes entry when its source declared
that group accepts. That keeps combine_constraint_factor pure and makes a
legacy pick with no axes take the unchanged flat-product path.
Also fixes the SPA preview resolver, which mirrors the applier: it dropped
axes when building its per-pick list, so the preview would have shown a
narrower pool than the run actually produced.
Conditions store condition.var as raw text rather than tokens, so this path
parses the accessor itself via parse_var_reference. _ctx_set is left on
split_var_accessor: an action writing to $outfit.SHOES should still target
the base var rather than pretend to write an axis.
_ctx_has checks the axes bucket rather than ctx, since $outfit.SHOES can
exist while outfit is unbound and vice versa.
Action values needed no work - they already route through resolve_text.
get_axis sits beside get_var as a plain dict lookup over a projection
build_resolve_ctx makes at frame construction, so the resolver stays a pure
consumer with no ctx dependency. Keyed by binding, matching what the
reference addresses.
Branches before the var lookup: $outfit.SHOES must resolve even when
nothing bound $outfit itself, and must not trip unknown_var on the way
past. Never routes through deref_var_value either - an axis value is not a
ListVar, so the SP2a accessor contract is untouched.
A missing axis renders empty and warns unknown_tag_axis rather than
failing, matching how every other unresolvable reference behaves.
A reference now carries at most one pick index and one axis, in either
order - $o.0.SHOES and $o.SHOES.0 name the same value. Accepting both is
deliberate: $o.0 is already meaningful on its own, so appending .SHOES is
composition rather than a second syntax, and rejecting it would make the
natural spelling the broken one.
Two mirrored regex alternatives, so .0.1 and .SHOES.BELTS reject by not
matching their second segment and the tail stays literal text - no
validation pass. Both tokenizers normalise to one (name, index, axis)
triple immediately, so nothing downstream learns which spelling was used.
Replaces the var_nondigit_accessor_is_text corpus case, which pinned the
behaviour this changes, with cases for both orders and both nonsense forms.
A held wildcard early-returns before recording, so its axis vanished on
iteration 2+ and every read rendered empty. Carries the frame-0 roll forward
the way picks already are, but keyed by binding rather than module id, since
that is the namespace a var read addresses.
setdefault semantics, not assignment: a wildcard that never asked to hold
still re-rolls each iteration, which the third test pins by running six
seeds over a two-tag menu.
Two consumers address a pick differently, so each gets the key it addresses
by. The constraint fold needs a tag-to-axis map and binds by module uuid, so
that rides on the pick entry. A $var.SHOES read binds by variable, so the
rolled winner goes to __wp_axes__ keyed by binding - which also means the
read never inherits the uuid-bucket collision.
Rolled at pick time, never on read: that is what makes two modules, or two
nodes, agree. The draw happens AFTER the option draw on the same rng, so an
existing locked_seed still reproduces its option.
Multi-select rolls per pick in pick order, so $outfit.SHOES mirrors the
shape of $outfit.
A group may declare itself classify (the default, and what every stored
payload means) or accepts. Only an accepts name has to satisfy the
identifier rule, because only an accepts axis is addressable as $var.AXIS;
a classify group keeps whatever name it has today.
Also narrows the constraint weight multiply with isinstance rather than
sentinel identity, which the newly-typed fold made unprovable.
Same three phases in the same order as the Python side: an exception pair
short-circuits the pick, unclaimed tags multiply, each accepts axis
contributes its max and an all-zero axis excludes. Graded against the same
corpus so the two cannot drift.
An option tagged with several tags from one group means those tags are
alternatives it offers, not statements that are all true at once. The fold
multiplied across them, so any sibling's exclude zeroed the option and a
source carrying three shoe tags excluded every shoe in the target pool.
Tags inside a group the source declared 'accepts' now fold with max.
Everything else still multiplies, and the path is unreachable without
axis_kinds, so a payload predating the feature folds byte-identically -
locked by the corpus case that omits the kind map.
Also replaces the bare object() sentinel with a narrowable class: 'is
EXCLUDE' never narrowed, leaving every 'factor *= r' unprovable.
The two rows around the variable strip go; the strip itself is untouched, being
the part that earns its space.
The standing hint row ("click → insert $var · Ctrl+click → remove · right-click
→ more") is deleted rather than shrunk, because the chips it describes ALREADY
carry that exact text in their own `title` — it was a permanent row duplicating
something one hover away. Removing it outright would have cost the only clue
that Ctrl+click removes, which is genuinely undiscoverable; it does not, because
that clue was never in the row alone.
Load / Save / Clear become icon-only. Each already had a `title` and an
`aria-label`, so the visible word was the only thing dropped, and three words
were most of the row's width. Kept as visible buttons rather than folded into
the context menu: an affordance you cannot see is one you do not know exists,
which is the mistake the hint row was compensating for.
`<lora:…>` and `embedding:…` now carry one fixed colour each — lavender and
cyan, matching the popover's own section icons — in the editor AND in the
resolved preview. The preview needed its own wiring: those two resolve to
themselves rather than to a variable, so they fell into `literal` tokens and
were the last place the syntaxes appeared uncoloured. It calls the same
`modelSyntaxHtml` the editor does, so the two cannot drift.
The colour is applied INLINE, which two independent facts each force. The SPA's
`rich-text.css` is not loaded on the canvas — the canvas has its own
`rich-text-canvas.css` carrying a "keep in sync" note — so a rule would have
had to be written twice. And these spans come from `v-html`, so they never
receive the `data-v-*` scope attribute a rule in a `<style scoped>` block
needs. The first attempt did it with a stylesheet rule and rendered plain #ddd
on both hosts; caught by reading the computed colour rather than the diff.
Verified on canvas: embedding rgb(103,232,249), lora rgb(196,181,253), `$camera`
still its hashed orange, hint row absent, three icon-only buttons. The preview
half is NOT verified — the helper freezes mid-`<Transition>` in this harness,
where `transitionend` never fires, so the preview never mounts.
Turning a completion source on did nothing until the page was reloaded.
`completionSourceEnabled` asks ComfyUI's settings store (or localStorage)
directly, and neither is a Vue reactive source — so the `computed` gating the
popover cached on its other dependencies and never re-evaluated. Readers stay
where they are, because they are the single place that knows how to answer per
host; a version counter is now bumped by every writer and read by the gate.
A counter rather than mirroring each value into its own ref: there is one
question here — did any of this change — and nothing to keep in sync.
Both hosts notify: the canvas switches from their `wp-switch` handler, the
native separator boolean through ComfyUI's own `onChange`, and the manager from
`uiStore`'s single `writeFlag`. The first test in the new file asserts the BUG
— a computed over the raw reader going stale — so the fix cannot be quietly
undone.
`<lora:…>` and `embedding:…` now render in their own fixed colours, matching
the `loras` and `embeddings` section icons in the suggestion popover, so the
thing being inserted and the thing on the page read as the same kind. Fixed
per kind rather than hashed like `$var`: there are arbitrarily many variables
and the colour is how you tell two apart, but exactly two of these and they
always mean the same thing, so one colour each is learned once instead of
decoded each time.
Deliberately not a tokenizer kind. `tokenizeRich` is shared with the
engine-parity resolver and the atomic editor model, and neither has any
business knowing ComfyUI prompt syntax — this is a rendering concern and it
stays in the renderer, decorating text tokens on the way out. A half-typed
`<lora:` highlights too, since that is exactly when it is being written.
The flicker on the last letter typed, from the screen recording. Two causes,
one of them mine.
The sources settled INDEPENDENTLY, which I chose deliberately so the popover
would never be held at the speed of the slower one. That optimised for a
latency that does not exist — both endpoints are in-process on localhost — and
paid for it with a visible double reflow on every keystroke: tag rows landed
and rendered, then model rows landed, appended their sections and re-capped the
tags, so the list rebuilt twice within a few tens of milliseconds. One settle
now, via `allSettled` so one source failing still shows the other.
Frame-stepping the recording also turned up something worse than flicker. At
2.60s the field and the header both read `lazy` while the third row was `laser`
(from the alias `lazer`) — not a `lazy` prefix at all. Those were the results
for `laz`: the header renders `acQuery`, which updates synchronously on every
keystroke, while the rows arrive from a debounced fetch, so there is a window
where the popover confidently shows the PREVIOUS query's results under the
CURRENT query's label. Pressing Enter there commits a row chosen from a list
that no longer matches what was typed.
The rows are deliberately still not cleared while the next fetch is in flight —
blanking on every keystroke flickers far worse than briefly-stale content — so
instead the popover says so: the header shows "searching…" and the rows dim
while `rowsQuery` differs from `acQuery`. That turns an unexplained reflow into
an obvious "still looking", and makes the stale window visible rather than
silent.
Also moved the GitHub star prompt directly under the hero. It sat at the very
bottom of the dashboard, below the stats, the quick-create row AND the full
recents list, so it could not be seen without deliberately scrolling to the end
of a page nobody scrolls to the end of. The reasoning for putting it last — a
favour belongs below what someone came for — was half right and produced
something invisible; an aside nobody can see is not tactful, it is absent. The
concern behind it still shapes the new spot: ABOVE the hero it was louder than
the product's own welcome, so under the hero keeps the welcome first and the
favour second.
You cannot find a model by typing its name unless you also reproduce its
punctuation, and nobody remembers where the punctuation fell. `2xko` could not
find `2X-KO_more_-ill_r1` at all — reported exactly that way.
Matching now folds `-`, `_`, `.`, `/`, spaces and brackets out of BOTH sides
before comparing, in three tiers: an exact prefix still outranks a folded one,
which outranks a folded substring. So `2xko`, `2x-ko` and `2XKO` all reach
`2X-KO_more_-ill_r1`, `spritepixel` reaches `8.0-sprite pixel art style by
skormino`, and someone who typed a name exactly is never reordered beneath a
fuzzier match. Free to do here: the model list is tens of entries, not the
tag list's 286k.
Tag search is deliberately left alone — it is a bisect over a sorted array of
286,337 names and prefix-only is what every booru autocomplete does.
Sections were not delivering what I claimed for them. Tags lead, `lazy` matches
twenty of them, and the embedding section existed but sat entirely below the
fold — the user could not filter to their own models without scrolling a list
they were not looking for. The leading section is now capped to 6 rows WHEN a
model also matched, which is what actually makes the others reachable. A query
matching nothing but tags still gets the full twenty.
The LoRA and embedding settings move to the same hand-built switch as the tag
one, for the reason that control exists: a count beside the toggle. "50 LoRAs
found" answers the question a bare switch raises — is there anything for this
to suggest? — and it is the question that otherwise sends people to the manager
to check.
And the pill now reads PrimeVue's own `--p-toggleswitch-*` custom properties
for every dimension, not just its colours. Those are injected when their
component first mounts, which has always happened by the time ours renders,
because our row sits in their dialog among their switches — so at render time
this IS their pill and follows their theme. Aura's defaults remain as
fallbacks. Handle travel became a `calc()` over the same tokens rather than a
fixed 16px, so a differently-sized track still lands the knob flush.
Read off the screen recording rather than guessed at — ffmpeg frames of the
real settings dialog, which is the first time this control has been seen next
to the ones it has to sit among.
THE SWITCH WAS THE WRONG SIZE. 34x18 with a 14px knob, against PrimeVue's Aura
preset of 40x24 with a 16px handle, which is what ComfyUI renders and what the
frames measure. Beside three real toggles it read as visibly smaller and
duller.
IT WAS ALSO IN THE WRONG PLACE. The note and the switch were appended in that
order inside a flex row, so the control floated mid-row while every neighbour
sat flush against the right edge. A row that does not line up reads as broken
before it reads as ours. Note first, switch last.
AND THE KNOB TELEPORTED. `paint()` rewrote `style.cssText` on every change,
which replaces the `transition` declaration mid-flight — the browser then has
nothing to animate between. That is the visual glitch: the static styling is
now written once and only the properties that actually change are touched, so
the slide runs.
Colour and timing come from `--p-primary-color` and `--p-transition-duration`,
which ComfyUI publishes on `:root`, so both track their theme. The rest of
PrimeVue's `--p-toggleswitch-*` tokens are injected lazily when the component
first mounts and do not exist until the dialog has been opened once — so they
are read with fallbacks rather than relied on. Still not borrowing
`.p-toggleswitch` itself: those are ComfyUI's internals, and reusing them buys
a perfect match today and a control that renders as nothing the day they
restyle.
In the manager, the counts move onto the control's own row as a tinted pill
pushed to the far edge. First they were appended to the dim `hint`, where the
one fact worth reading was the least readable thing on the card; then they got
their own line, where they crowded the explanation above them. The whole badge
is tinted rather than just its dot — at 11px a dot alone is easy to miss, and
"none found" is the case that most needs noticing.
Verified live: badge on the same row as its toggle, pushed right, no overlap
with the hint, green tint, "50 found" and "17 found".
Three things from a QA pass on the restarted server.
The model counts were appended to the `hint`, which is dim by design — so the
one fact on the card worth reading was the least readable thing on it. Each
source now gets its own status line at normal text colour with the same
green/amber dot the tag card uses, so "is this usable?" reads identically on
both cards.
The tag setting kept rendering a checkbox while every other boolean in the
panel is a pill switch. It cannot be a plain `type: "boolean"` — it disables
itself when no tag list is installed, and a native boolean has no way to say
"on is not available" — so it gets a switch of its own: 34x18 pill, sliding
knob, `role="switch"`, space and enter, dimmed and non-interactive in the
disabled state.
Styled inline and namespaced rather than borrowing PrimeVue's classes. Those
are ComfyUI's internals; reusing them buys a pixel-perfect match today and a
control that silently looks like nothing the day they restyle or upgrade.
Typing a bare `<lora:` offered nothing. The endpoint refuses an empty query so
that a stray keystroke cannot dump the whole models folder into a popover —
correct for a bare word, and exactly wrong inside a reference, where the marker
IS the request and "show me what I have" is the main way these get used. The
client now sets `all=1` only when the caret is inside a reference, where the
intent is unambiguous, and the server lists the first N by name.
QA notes from the same pass, all verified against the live server:
- `/wp/api/models/*` serves: 50 loras, 17 embeddings.
- The data-folder migration ran and logged its own decision:
"left in place — wildcard-pipeline.db (already present at destination)".
The destination already held the real 1.13MB library, so the never-overwrite
rule preserved the older loose copy instead of clobbering it, and the server
resolves to the correct file. Working as designed.
- The two reported completion failures now return exactly one correct match
each: the completed `embedding:style\lazyhand-e12c.safetensors` path, and a
LoRA name carrying both spaces and dots.
- Sections render: "tags · embeddings" with per-source headers, tags first, and
no header when only one source has hits.
Both halves of the low-end-hardware note, measured first as it asked.
PROFILE. An 8-node Context chain carrying 96 variables costs 0.591ms per
refresh. That is small alone and it is not what it costs: every node walks its
WHOLE upstream chain, so a series chain — the shape people actually build — is
quadratic in total work, and nine nodes already produce a visible long task
when the refreshes are forced back to back.
Two loops were paying it forever: `reactive.ts` at 400ms per WP node, and
`subgraph-badge.ts` at 800ms per SubgraphNode, each rescanning regardless of
whether anything could have changed. Neither stopped for a hidden tab and
neither backed off.
They now share `startAdaptivePoll`, which was extracted rather than written
twice — the two had already drifted into having nothing in common but the bug.
It gates on two things that both cost nothing while the user is working:
A hidden tab does no work at all. Nobody can observe a stale widget on a tab
they are not looking at, so this was work being done precisely when it was
least useful. One catch-up refresh runs on the way back to visible, so an edit
made elsewhere is never missed.
A still canvas backs off 3x then 8x after ~4s of no pointer, key or wheel
activity AND no observed change. The fallback exists for upstream edits that
fire no event, which cannot happen while nobody is editing. Any real change or
any user activity snaps it straight back. One shared document listener feeds
every node — N listeners for a single global fact would repeat the mistake the
per-node intervals already make.
The event paths are untouched: `onConnectionsChange`, the mode intercept and
graph load all still fire instantly. Only the fallback slows, and only while
nothing is happening.
FONTS. We shipped a 48 KB Inter that ComfyUI already serves, declared
identically — same family, same `font-weight: 100 900` variable axis, same
latin woff2, same `font-display: swap` — from its main stylesheet, so it is
loaded on every page a canvas widget can appear on.
The note wanted the removal risk measured before taking this, so: added
2025-09-16 in Comfy-Org/ComfyUI_frontend 4ff18fd ("Add Inter font used by
Figma designs", #5535) and untouched since — one commit in its entire history.
It is the typeface of their whole UI, so dropping it means restyling their
product rather than removing an optional asset.
The coupling is also weaker than the note assumed. We depend on the FAMILY
NAME, not their URL: our stack names `Inter` and the browser resolves it
against whatever `Inter` face is loaded, so a rename, re-subset or re-hash is
invisible to us. Their copy lives in `public/fonts/`, which Vite serves
un-hashed exactly so URLs stay stable. And the failure mode is the one the
stack already shows on every cold load — fall through to `-apple-system`.
JetBrains Mono stays; ComfyUI ships no monospace face.
Verified live: zero requests for our Inter, their `inter-latin-normal.woff2`
loaded, `document.fonts.check("16px Inter")` true.
Three leftovers from fields that used to be `<textarea>` and became
RichTextInput in ca87384b and 8aea38dd. The markup changed; the CSS written for
the textarea stayed, still matching because the class moved onto the
component's root.
`.row__value` declared `overflow-y: auto` and `max-height` on that root, and
the component's own `.wp-rt__host` already declares both — so a capped,
scrolling box sat inside a capped, scrolling box and a fixed-values row showed
TWO vertical scrollbars. Reported in the bundle snapshot editor, but it was
every fixed-values row everywhere. `min-height`, `line-height` and
`white-space` were the same mistake without a visible symptom. Only
`word-break` survives — a long unbroken value is a row-layout concern, not an
editor one.
`.row__grip` and `.row__value-wrap--more::after` reimplemented the drag grip
and the overflow fade, which existed here only because a textarea cannot carry
either. Both now belong to RichTextInput, and the markup that used these went
with the textarea — the rules had been matching nothing since.
`.ibm__template` kept `resize: vertical`, which put the browser's native
resizer in the same corner as the component's own grip: two handles, one of
which the component cannot clamp. That is the class of bug `startResize` exists
to avoid.
Also from the same report: the SPA's template editor was a plain Textarea, so
it was the one place a PromptAssembler template could be written with no tag,
LoRA or embedding completion at all — despite templates being saved here and
loaded into the assembler. It uses RichTextInput on the `assembler` surface
now, so both ends agree on what the syntax means.
Four things, all of them the same feature being genuinely usable rather than
merely present.
The completion could not see a filename. `probeTagWord` bounds a word with the
character class `[a-zA-Z0-9_'-]`, which contains no dot and no path separator —
so a caret at the end of `embedding:style\lazyhand-e12c.safetensors` walked back
only as far as the dot and searched for `safetensors`, matching every model on
disk and nothing that was meant. Real names carry dots, separators and spaces
(`8.0-sprite pixel art style by skormino`), and no character class can bound
that.
So the new `probeModelRef` bounds by SYNTAX instead: everything between
`<lora:` or `embedding:` and the caret. Unambiguous, and it describes names a
class never could. It stops at a comma, newline or `>` so a completed reference
earlier in the prompt cannot claim a caret that has moved on, and past a LoRA's
second colon, which is a weight and not a name.
It also takes precedence over the bare word and RESTRICTS the search to the one
kind being named — a reference names exactly one by construction, so offering
the other, or offering tags, was offering something that could not legally be
inserted there. That is the "caret in the embedding, popup full of LoRAs"
report. Committing inside a reference now inserts the bare path, since the
marker is already typed.
Server side, the query is separator-normalised like the stored paths, and a
full path now ranks as a PREFIX hit — otherwise a completed reference sorted
below unrelated substring matches.
The canvas settings use plain `type: "boolean"`, which is what renders
ComfyUI's own pill toggle; the checkboxes came from the hand-built renderer.
The tag setting keeps its custom control because it DISABLES itself when no
list is installed, which no native type can express — the two model sources
have no such state, so there is nothing to express.
New opt-in setting appends `", "` after a completion. Suppressed inside a
reference, where a comma would terminate the thing being completed. Applied on
both the keyboard and mouse commit paths, because a preference that lands on
one of them is worse than not having it.
And the gap I left last time: the model sources had no SPA surface at all —
canvas settings and playground mirrors only, with nothing anywhere writing
their storage keys, so outside the canvas they could not be switched on.
`ModelSourcesCard` adds the toggles, the counts, and the Refresh that
`/wp/api/models/refresh` was built for and nothing called. `uiStore` gains the
writers; `tagSetting.ts` stays the reader, because the canvas has no Pinia.
`enabledCompletionSources` is deleted — it was referenced only by its own test.
Maintainer call after three failed rounds: drop the in-editor grip, let
ComfyUI's node corner own the height, and make the editor scroll instead of
growing to fit its content.
That is the right call and my argument against it was wrong. I rejected
`fillHost` on the grounds that the assembler has TWO widgets, so
node-drives-widget would stretch the chip strip and preview alongside the
editor. Measured, it does not — the helper carries `autoHeight`, which pins it
to its content, so every pixel of slack goes to the editor:
node 390 -> editor 70, helper 178
node 700 -> editor 168, helper 178
node 1000-> editor 273, helper 178
node 300 -> clamps to 420, editor back to 70
Shrinking works again too: 1000 -> 300 clamps at the widgets' legitimate 420
floor rather than springing back to fit the text, and the box scrolls
(scrollHeight 928 against clientHeight 98) instead of inflating the node.
The root cause of all of it was two resize authorities over one box. Each round
found and fixed a genuine defect — `autoHeight` discarding the user's height,
grip-follow mutating scroll from inside the resize flush, a lifted height cap
outliving its drag, a lost `pointerup` stranding `dragging` — and none of them
was the symptom, because arbitrating between two authorities cannot make them
agree. Removing one can.
`fillHost` also skips the content-size ResizeObserver entirely and takes the
subtree out of flow, so the template can no longer push the node at all. That
is the auto-scaling half of the report.
New `fill` prop on the editor: hides the grip, drops the 14rem cap (which
exists to bound AUTO-growth, and would otherwise cut a node the user
deliberately dragged tall), and sets `min-height: 0` on both the root and the
host. That last part is load-bearing — both are flex items, and a flex item
defaults to `min-height: auto` and refuses to shrink below its content, which
is exactly how the payload used to push the node.
The grip stays everywhere else. The SPA's modals and pages have no node corner
to drag, so there the in-editor handle is the only control there is — and the
stuck-drag fix in 25527c37 still matters for them.
`.releaserc.js` renders no commit sections (`transform: () => false`), so
this file IS the release body. Without it the release ships with only a
header and a compare link — the blank-changelog outcome that 2.13.0 hit.
Written for users rather than maintainers: what broke, what it looked
like, and which installs were affected. semantic-release clears the file
on release, so it leaves no net change on main.
`migrate()` skips everything `<= MAX(version)`, which made an integer
the entire identity of a schema. It is not, and two failures followed
from that, both silent:
1. A database migrated by a NEWER build. Every migration is already
"applied", so the runner does nothing and the caller reads a schema
it has never seen. Additive columns survive; a shape change does not.
2. A database at the SAME version but a different shape, because a
migration file changed after it had already run somewhere — a
revised migration, a hand-edited file, an abandoned branch. Version
numbers match, so nothing compared anything.
Both corrupt cumulatively: every subsequent write goes through code
whose assumptions about the row shape are wrong, and the user has no
signal until something much later fails for an unrelated-looking reason.
Migration 017 adds a nullable `checksum` column; the runner records the
sha256 of the file it actually executed. `assert_schema_compatible`
checks both failure modes and runs at the top of `migrate()`, so no
caller can forget it.
NULL is treated as "unknown", never "mismatched". Rows applied before
017 existed cannot retroactively grow a checksum, and backfilling them
from the files on disk would assert exactly the compatibility the check
exists to verify. So the version-ahead half protects every database
immediately; the divergence half protects migrations from 018 onward.
`SHIP_PATHS` omitted `locales/`, which ComfyUI reads from
`custom_nodes/<pack>/locales/<lang>/` for node display names,
descriptions and settings labels (app/custom_node_manager.py). We ship
main.json, nodeDefs.json and settings.json there.
The registry archive already included it, because `comfy node publish`
ships everything git-tracked that `.comfyignore` does not exclude. The
zip is a hand-maintained list, so the two artifacts silently disagreed
about what a complete install is. Nothing installs from the zip today,
which is the only reason this has not bitten anyone.
The omission is the symptom; two hand-maintained lists of the same thing
with nothing tying them together is the cause. `assertShipListIsTotal`
now fails the pack when a top-level tracked path is neither in
SHIP_PATHS nor explicitly listed as dev-only, so the next runtime
directory someone adds cannot go missing the same way.
Also names the missing-`zip` case: on Windows the packer reported
"exited with status null", which says nothing about `zip` not being on
PATH.
Second report, same wound, different door: Ctrl+A then Ctrl+X inside an
option value bricked the field on Firefox — typing, Backspace and even
Save and Cancel stopped responding — with `insertBefore: Child to insert
before is not a child of this node` and the `g is null` unmount cascade.
`onHostCut` already routes the deletion through `applyAtoms` so the
browser never removes the spans itself (2.13.1). But the atom list still
shrinks from N to 1, and shrinking a keyed list unmounts the surplus
`<template v-for>` Fragments. With the fragment anchors normalised away
by Firefox that teardown walks off the end of the child list, exactly as
the ref-picker path did — reached from a call site nobody had flagged.
Marking individual call sites `rebuild` was a whitelist, and the
whitelist kept missing entries: three separate crashes now, three
separate patches. Ask the DOM instead.
`hostAnchorsIntact()` counts the empty text nodes Vue uses to delimit its
Fragments — a healthy host holds exactly `2N + 2` of them, verified
against the live bundle. `isStructuralApply()` marks the applies that
add, remove or re-branch an atom, which are the only ones that touch an
anchor. When both hold, the host is replaced instead of patched, and all
thirteen `applyAtoms` call sites are covered at once.
Costs nothing on Chromium, where the anchors are never missing, and
nothing on the same-shape applies that carry ordinary typing — a test
pins that a chip settle still lands on the very same host element.
Save/Cancel and Backspace needed no separate fix; both were the dead
subtree left behind by the first throw.
Inserting a nested `@` reference took the whole editor down behind the
error boundary with `can't access property "nextSibling", e is null`,
followed by the unmount cascade (`g is null`). Firefox only.
`<template v-for>` mounts each atom inside a Fragment, and Vue delimits a
Fragment in the DOM with two EMPTY TEXT NODES. Those anchors sit inside
the contenteditable host, which the browser owns — and Firefox normalises
empty text nodes away as the user types. Chromium keeps them, which is
why this never reproduced here.
The picker-Apply path then re-keyed the atom v-for to force a clean
remount. Vue's `removeFragment` walks `nextSibling` from the start anchor
until it reaches the end anchor; with the end anchor gone the walk runs
off the last child and derefs null.
`hostDomIsStale()` could not catch it: it counts `[data-atom-index]`
ELEMENTS, and what the browser destroyed were anchors, so it reported a
healthy DOM and the re-key path was taken.
Both rebuild routes now go through the host ELEMENT swap that already
existed for the stale-DOM case. Unmounting an element vnode is a single
`hostRemove(el)` on a node that IS still attached, and its children come
down with `doRemove: false`, so no missing anchor and no detached child
el is ever touched; the new tree then mounts into an empty element with
nothing to insert before. The v-for key drops back to the plain index.
A host swap also replaces the element the ResizeObserver was watching, so
`useGrowableField.attach()` is now idempotent and RichTextInput re-attaches
on every swap — otherwise the overflow fade and grip-follow died silently
for the rest of the session on any field that had ever repaired itself.
Reported as "the resize is linked to my mouse and resizes as I move my mouse
around without holding, and can't be interrupted no matter what I do or press."
That is one state — `dragging` stuck true — and it was reachable whenever a
single `pointerup` was missed. Three things combined:
`setPointerCapture` reads like the right call and is what stranded the drag.
Capture retargets every later pointer event to the grip, INCLUDING `pointerup`.
The editor re-renders while it resizes, and a captured element that gets
replaced is detached — so the `pointerup` was delivered to a node no longer in
the tree and never bubbled to `window`. Removed: the listeners are on `window`,
which sees the events regardless of what is under the cursor, so capture bought
nothing here.
The listeners were in bubble phase, so a `stopPropagation()` anywhere between
the target and the window hid the release too. ComfyUI's node layer does exactly
that to stop the canvas panning under a widget. All three are capture phase now,
which fires before anything downstream can swallow them.
Nothing ever cleared `dragging` afterwards, which is the "can't be interrupted"
half — there was no path back to a stopped state at all. Now `pointerdown`,
`blur` and Escape all end a drag, and `onResizeMove` bails when `ev.buttons` is
0. That last one is the one that cannot be outsmarted: every pointermove reports
which buttons are down, so a move with none held means the release was lost
whatever swallowed it. It ends the state even for a cause we have not found.
Two existing tests drove a drag with a synthetic `PointerEvent` whose `buttons`
defaults to 0, which the new guard correctly reads as a release. They now pass
`buttons: 1`, which is what a held drag actually reports and what they meant to
simulate.
This is separate from bc8421fe. Those three fixes are in and correct — they
addressed the node fighting the editor over height. This is the drag never
ending, which no amount of height policy would have cured.
Two more completion sources for a bare word, each behind its own setting.
Far cheaper than the tag list: ComfyUI already enumerates both folders for its
own node combos, so there is nothing to download, cache, byte-cap or parse, and
the security surface that dominated the tag work does not exist here.
Sections rather than one ranked list, because the sources have no common
ranking key. A tag ranks by post count in the tens of thousands; a model has no
count at all — you either have the file or you do not. Any flat ordering has to
invent a comparison between "12,000 posts" and "a file on disk", and whichever
is invented, tags win on weight of numbers and the user's own models sink below
the fold. Sections also let each source cap its own rows, so 20 tags cannot
crowd out 3 matching LoRAs.
The rows stay ONE FLAT ARRAY internally even though they render grouped,
because `acActive` indexes it. Grouping the state would put the keyboard
selection in charge of two coordinates and make "skip the header" a case to
handle; flat, a header simply is not in the array and cannot be selected. The
header also only appears when more than one source has hits — with a single
group it would cost a row to say what the group already says.
A model row inserts its FULL RELATIVE PATH, not the display name. Two folders
can hold the same filename and ComfyUI resolves by path, so inserting the short
name would silently pick a different file from the one on screen. The folder is
shown as the row subtitle for the same reason.
Icons are `pi-asterisk` for lora and `pi-code` for embedding — the only two
candidates from the shortlist with zero existing uses in `src/`. That check is
the method: `pi-tags` was chosen for booru tags precisely because `pi-tag`
singular is already the fixed_values module kind.
Each source is independently switchable. Someone writing danbooru prompts may
have no LoRAs at all; someone with 200 of them may find the tag list noise.
`tagSetting.ts` generalises to answer per source, keeping its host-aware split —
the canvas reads ComfyUI's settings store, the SPA reads localStorage directly
because this is called on every keystroke probe.
The settings parity test earned its keep again: it failed the moment the two
new canvas settings existed without playground mirrors.
Sources settle independently rather than being awaited together, so the popover
is never held at the speed of the slower one — the model lookup is an
in-process list scan, the tag lookup walks a multi-megabyte index.
The new routes need a ComfyUI restart before they serve. Verified that until
then the 404s degrade silently: settings persist and read back, tag suggestions
are unaffected, nothing throws.
The previous commit only restyled the chip — box off, colour on, atom intact —
and that is not what "coloured text" means. It still behaved like an object:
one Backspace deleted the whole token, the caret could not enter it, it kept a
pointer cursor and its leading `⌘` glyph. Looking like text is not being text.
The mechanism for this already existed and I missed it. `parseForSurface` has a
per-surface COLLAPSE SET that keeps a token as literal text instead of turning
it into an atom — `wildcard` collapses `var`, `fixed_values` collapses both. The
assembler simply was not in it. Adding it there makes `$name` ordinary editable
text, which is the whole fix: caret enters it, Backspace takes one character,
no glyph, no atom.
Colour then comes from `inlineTokenHtml`, which already emits editable
`<span class="wp-rt-var">` sub-spans — it was being told to collapse `var` to
bare text. `textAtomHtml`'s always-collapse rule has a documented rationale
("the ABSENCE of a chip already signals not-committed, so an inline colour
would only compete with the settled chip palette"), and the assembler is the
one surface where it does not hold: there are no var chips there at all, so
nothing is being competed with and the colour is the only signal.
Per-variable colour rides on an inline `style` from a new `varAttrs` hook,
because `.wp-rt .wp-rt-var` already sets a colour at higher specificity than
the global `.var-N` palette classes. Unbound names keep the danger colour and
wavy underline, still only claimed where the host walked a graph.
The hand cursor was unrelated to any of this and is fixed separately: nothing
ever set a cursor on `.wp-rt__host`, so it inherited from the surrounding
chrome — on the canvas that is ComfyUI's node wrapper carrying `cursor-grab`
for dragging. A grab hand over an editable field reads as "you cannot type
here". Never visible in the SPA, which is why it survived.
`RichTextPreview` gets the same surface rule, or the same template would render
with chips read-only and without them in the editor.
`RefChip`'s `flat` prop and its test are deleted rather than left in place —
with vars collapsed to text on the only surface that used it, the whole path is
unreachable. One insert test asserted the assembler chipifies, which this makes
false by design; it now asserts the rendering that replaced it, with a sibling
case proving chipping surfaces are untouched.
Verified live: 0 chips, cursor `text`, `$quality` → `$qualit` on one Backspace,
colours unchanged from the strip.
Three defects, each independently wrong, all pushing on the same thing. Keeping
the grip rather than moving to `fillHost`: the assembler has TWO widgets, and
`fillHost` means the node's size drives the widget — with two of them sharing
the node height, dragging the corner would stretch the chip strip and preview
too. Debug gets away with it because it is the only widget on its node.
`autoHeight` was copied onto the template editor from the Context and Injector
widgets without their reason for it. Those need it because a node stuck at a
manually-set tall height breaks their collapse animation; this widget has no
collapse animation. And the flag is precisely the branch that discards a user's
height:
const userControlsHeight = !options.autoHeight && …
const rawTargetH = userControlsHeight ? Math.max(cur[1], min[1]) : min[1];
With it off, the default path already does what a template editor wants —
preserve the height the user settled on, grow only when content needs more. The
mechanism was there; the flag was switching it off.
`followGrip` now runs only while a grip is actually held, which is what its name
always implied — it exists to keep the handle under the cursor. Ungated it also
fired on content-driven growth, so typing a long enough template scrolled the
page out from under you, and it made the resize flush mutate scroll position.
That moves the element the observer is measuring: a resize handler that can
change its own input is the shape a runaway needs.
`capLifted` now re-arms on pointerup. It guards a one-time "pin the current
height, release the max-height cap" step, and leaving it set meant the release
outlived the explicit height that bounded it — `applyAtoms` replaces the host
element on a rebuild, dropping the inline height but not the flag, so the next
drag found an uncapped, unpinned box.
Both new tests confirmed to fail with their fix reverted. Still not reproduced
end to end: the harness here runs the page as a hidden tab where neither rAF nor
ResizeObserver fires, so the drag cannot be exercised. Each change stands on
inspection; which of them was the reported symptom is for a real pointer to say.
The "sometimes the highlight at the bottom of an input doesn't render" report.
Deterministic once the font is identified as the variable.
These fields are typed in `--wp-font-mono`, a bundled webfont declared
`font-display: swap`. So the first paint lays the text out in the system
fallback (Consolas / Monaco), the real face swaps in later, and the two stacks
have different metrics. `useGrowableField` measured `scrollHeight` once at
mount, via a single rAF — against type that was about to be replaced — and
nothing re-measured after the swap.
That produces exactly the reported intermittency: wrong on a cold load, correct
on a warm cache where the face is already there, and corrected by accident by
any later scroll, input or resize, since all three re-measure. Nothing in the
codebase waited on `document.fonts.ready` anywhere.
`attach()` now re-runs the overflow hint and the autosize once fonts settle.
Resolves once, no-ops when the font was already cached, and guarded for hosts
that expose no font-loading API.
Stated plainly: this is a strong hypothesis, not a confirmed reproduction. The
harness available here runs the page as a hidden tab where rAF never fires, so
the fade could not be observed either way. The mechanism is real and the fix is
correct regardless of whether it turns out to be the whole of what was seen.
Both files sat loose in ComfyUI's user directory next to ComfyUI's own. That
was fine with one of them and stopped being fine at two. One folder is also one
thing to back up and one thing to delete.
The subfolder alone would have read as data loss: every existing install has a
real library at the old path, and the extension would have come up empty while
the file sat one level up. So `engine/db/relocate.py` moves them in, once, on
first boot.
Four constraints shaped the mover:
Never overwrite. A file at the destination means either a finished migration
or something the user put there; both outrank anything we could infer, so the
legacy file is left alone and reported as skipped.
Run before the database is opened. SQLite keeps `-wal` and `-shm` sidecars
beside the main file and moving that set out from under an open connection
corrupts it. The call sits in `__init__.py` ABOVE the node imports, which can
reach the DB — placement is load-bearing, not stylistic.
Move the sidecars with it. A `-wal` holds committed transactions not yet
checkpointed into the main file, so moving the `.db` alone silently drops the
most recent writes.
Never raise. This runs at extension import; a throw would take the whole
extension down over housekeeping. Failures are collected into a report the
caller logs, and the degraded state is "keep using the old location".
`shutil.move` rather than `Path.rename` because a user directory that is a
mount or a symlink elsewhere would make rename fail with EXDEV.
`TAG_FILE_NAME` is duplicated in `relocate.py` rather than imported from
`wp_api/tags.py`: the directory contract keeps `engine/` free of ComfyUI-facing
imports, and that module pulls in aiohttp.
Five existing path assertions moved to the new location. They were asserting
the behaviour this changes, and now carry a note saying why the subfolder is
expected so nobody "fixes" them back.
The template editor and the variable strip under it disagreed about what
colour a variable is. `.wp-refchip--var` painted every var the same
`--wp-success` green; the strip ran each name through `varColorClass()` and got
eight. So `$quality` was green in the editor and blue in the strip, six pixels
apart, in one node.
Chips go, on this surface only. A border and a fill advertise "this is an
object you can act on" — true in the module editors, where clicking a ref chip
re-picks its wildcard, and false in a prompt template, which is prose you are
writing. Font size steps up to the surrounding text too: chips ran 10px inside
12px because a box has to sit within the line, and without the box a token a
size smaller than its own sentence just reads as misaligned.
Refs keep their box everywhere. A `@{uuid}` really is a clickable object with a
picker behind it.
The colour is applied inline rather than via the `.var-N` class. Those live in
`theme.css` at the same specificity as `.wp-refchip--var`, and this component's
scoped block is injected after it, so the class lost the cascade and every
token still rendered green — caught by measuring the computed style rather
than by reading the diff.
Dropping the box cost the one cue that separated a broken var from a working
one: with a chip, `$typo` still read as a chip. `resolved` cannot recover it
(for a var it is only `name.length > 0`, so a typo is "resolved"), so the state
comes from `inScope`, and only where the host actually walked a graph — in the
SPA every var is out of scope because there is no graph to be in. Unbound vars
get the danger colour and a wavy underline instead of a palette colour.
The `$` popover now takes the variable's colour rather than its module kind's,
so a row and a strip chip can be matched by looking. The glyph still carries
the kind, exactly as the strip does. `@` rows keep `kindTint` — there the kind
IS the identity of the thing being picked.
Verified live: `$quality` rgb(147,197,253), `$camera` rgb(253,186,116),
`$scene` rgb(249,168,212), identical in editor and popover, and `$typo_here`
red with a wavy underline.
Note on the preview I sent: it proposed raising the editor line-height from
1.55 to 1.75. The real value is already 1.9, so that part was wrong and is not
applied. The strip's gap and padding do move onto the `--wp-space-*` scale.
`startResize` called `setPointerCapture` before attaching its `pointermove`
and `pointerup` listeners. That call throws `NotFoundError` for any id with no
active pointer, and an uncaught throw there meant the listeners were never
attached — a grip that visibly does nothing when dragged.
Capture is only an optimisation here: it keeps move events coming when the
pointer outruns the 16px grip. The listeners are on `window` and work without
it, so a failure should cost nothing. Wrapped, and left after the listener
attach path so ordering can't matter again.
Found while trying to reproduce the reported resize bugs. Not yet confirmed to
be the cause of either — the harness available here runs the page as a hidden
tab, where `requestAnimationFrame` and `ResizeObserver` never fire, and the
whole autosize path is built on both. This fix stands on inspection regardless.
Two reports against the assembler's editor, both fixed at the source.
The suggestion popover never closed when clicking away. The dismiss listener
was bound to `mousedown` only, and litegraph drives the canvas from pointer
events and calls `preventDefault()` on `pointerdown` to suppress native
text-selection and drag — a prevented `pointerdown` also suppresses the
browser's compatibility `mousedown`, so the listener never heard the click.
On a node graph the canvas is most of the screen, which is why this read as
"it never closes". Now bound to `pointerdown` too, which fires first and
cannot be taken away downstream. `mousedown` stays as the fallback for hosts
with no PointerEvent (jsdom, older webviews); closing twice is idempotent.
Presses inside the popover still don't dismiss, so rows (which commit on
mousedown to beat the host blur) and the scrollbar keep working.
The `$` list also offered variables the assembler cannot render. It runs
`strip_internals` over the render context before resolving, so `$var` naming
a user-flagged internal variable substitutes to nothing — yet the popover
listed 52 matches, most of them `$iteration` and `*_bool` toggles. Those names
legitimately cross the socket for Combine and Derivation to read, so the fix
is not to drop them from the walker but to give the PROMPT surface its own
list: `collectUpstreamRenderableVariables`.
The internal-flag parse existed already as a private copy inside
`widgets/assembler.ts`. Extracted to `internalVarNames` and shared, because
the two surfaces on this same node have to agree about which names the prompt
will render, and they would have drifted with one copy each.
`resolveChainStatic` iterated `m.entries` with no guard and read
`e.variable_name` with no type check. A library payload that carries
`payload.values` but no `entries` mirror — which is every row installed
straight from the library, since `entries` only appears once a module has been
edited inline — threw "m.entries is not iterable".
The blast radius is the reason this matters. The walker runs inside
`onConnectionsChange` via `extension/reactive.ts`, so the throw does not
degrade to an empty preview: it escapes into litegraph's connection handling,
and one bad module takes out canvas interaction for the whole graph.
The other two `entries` readers in this file already used `?? []`; this one
was the outlier. Found while hand-writing test fixtures for the assembler
editor — hit it twice before recognising it as the code's problem rather than
the fixture's.
The template input now renders through RichTextInput, so it has the booru tag
autocomplete, `$var` chips with producer attribution, and the same editing
behaviour as every other WP text surface.
No payload transition. It is the SAME `template` widget: same name, same
position in `widgets_values`, same plain string value — only the renderer
changed. A workflow saved before this loads its template back untouched;
verified by loading a hand-written pre-change workflow JSON.
The seam is `widgetType`. The frontend picks a widget constructor with
`t.widgetType ?? t.type` while the socket keeps `t.type`, so tagging the input
spec routes the lookup to us without touching what the socket accepts. It has
to go through `extra_dict`: V3's `widget_type=` parameter would ALSO change
the socket, because `WidgetInput.get_io_type` returns widget_type when set —
the input would stop being STRING and no upstream STRING output could feed it.
`extra_dict` is merged last in `Input.as_dict` and never consulted by
`get_io_type`. The new schema test asserts both halves together, since either
one alone passes while the feature is broken.
Keeping the link input needs one more thing: ComfyUI only calls
`addInput(name, spec.type, {widget})` when the widget the factory returns has
no `socketless` flag, and `createDomWidgetHost` hardcoded `socketless: true`.
Hence the new `socketed` option — correct for every other WP widget, exactly
wrong for this one. While a link IS connected the editor goes read-only with
a placeholder saying so, matching the stock multiline widget. Derived from the
link rather than the widget's `computedDisabled`, which is recomputed lazily
during a draw and still read `true` a second after the link was removed.
Why a separate file and not `assembler.ts`: the helper widget must stay
socketless (it is an editor, not a value), and the two widgets need opposite
answers to that one question.
The helper's template mutators lose their `inputEl` branches. Those had been
dead for a while — the frontend moved widget values into a store, so the
textarea at `widget.inputEl` is detached and unrendered, and each of those
functions was really working through the `w.value` write sitting next to it.
Insert is the exception: it needs a caret, so it asks the editor through a
WeakMap hook instead of replacing the whole string.
Verified live on frontend 1.48.6 with Vue Nodes on: legacy value restores,
STRING link connects and disconnects, serialize round-trips, clear / remove /
insert all propagate, `$` autocomplete lists upstream vars with attribution,
tag autocomplete and its legend work, and a full Context → assembler chain
previews correctly.
Two changes to RichTextInput, both needed by the assembler's template editor
but neither specific to it.
The echo guard on the `modelValue` watcher compared only the string:
if (next === lastEmittedValue) return;
`lastEmittedValue` seeds from the value present at mount. Every canvas widget
mounts empty — ComfyUI restores the saved workflow value AFTER the widget is
built — so `lastEmittedValue` stays `""` until the user types, and every
later external `""` looked like the editor's own echo and was dropped. The
assembler's Clear template button is exactly that write: the widget value went
to `""` and the old template stayed on screen. The guard's real question is
"does the DOM already show this?", so ask that instead. Non-empty writes were
never affected, which is why this survived this long.
`insertTextAtCaret` is the component's first public method. The assembler's
chip strip is a SEPARATE widget on the same node, so it cannot splice into
this editor's DOM; it used to splice into the native `<textarea>` at
`widget.inputEl`, which no longer renders. Writing `widget.value` instead
works but replaces the whole string and drops the caret.
It separates on BOTH sides. Leading-only was the old textarea's behaviour and
was already subtly wrong: inserting `$mood` before `portrait` yields
`$moodportrait`, which re-parses as a variable named `moodportrait`, so the
insert quietly changed what it inserted. Caught in the browser, then pinned
with a test that drives a real jsdom Selection — the other cases exercise the
end-of-text fallback, which cannot reach the trailing branch.
Both regression tests were confirmed to fail with their fix reverted.
One slot now says both things: the glyph says "booru tag", its tint says which
category. The separate 4px colour bar goes.
`pi-tags` PLURAL is deliberate. `pi-tag` singular is already the fixed_values
module kind in KIND_ICON_MAP, so a booru tag row would have rendered
identically to a library module row. Checked every `pi-*` in the source before
choosing: `pi-sparkles` is the wildcard kind, `pi-sliders-h` the injector's
sampler, `pi-palette`/`pi-hashtag` are taken too. `pi-tags` is unused.
Neutral grey is `general`, which is most rows -- colouring every line would
make the coloured ones stop meaning anything.
Three defects caught by measuring the rendered result rather than reading the
diff: `artist` and `meta` kept `background:` because extra alignment
whitespace defeated the edit, so both fell back to inherited dim; the legend
icon lost its `pi pi-tags` classes and rendered as a coloured but glyph-less
box; and the legend swatch kept `width: 4px; height: 10px` from the bar it
replaced, squashing the icon to a sliver. Verified live: 20/20 row icons at
12px in the primeicons font, and legend glyphs at 11px in character green,
artist orange and general grey.
The canvas fixed-values row was a bare <textarea>, so booru tag autocomplete
never reached it. It is a RichTextInput now.
`$` and `@` stay off there, and that is the ENGINE's rule rather than a UI
preference. `fixed_values_handler.py` says the surface is a binding PRODUCER,
not a consumer: a fixed value DEFINES what `$name` resolves to, so `resolve_text`
gates var reads and `@{}` refs off and renders such a token as literal text
with a warning.
The frontend did not encode that. It hardcoded `surface === "wildcard"` in the
`$` gate, which made the SPA's fixed-values editor MORE permissive than the
engine -- offering `$` autocomplete for tokens the engine would never resolve,
while `parseForSurface` already collapsed those same vars to literal text. The
gate now derives from the producer/consumer split the engine defines, so both
surfaces agree and the existing SPA divergence closes with it.
No machinery was lost in the swap: RichTextInput uses the SAME
`useGrowableField` composable ValueRow did, so auto-grow, the overflow fade and
the drag grip come with it, and ValueRow's duplicate copy goes.
A Vue prop-casting trap cost two RichTextInput tests on the way, and the fix is
the interesting part. `allowVars?: boolean` is inferred as a Boolean prop, and
Vue casts an ABSENT Boolean prop to `false` rather than undefined -- so
`props.allowVars ?? <surface default>` never reached the default and EVERY
surface silently lost `$`. It is now `"auto" | "on" | "off"`, which no
prop-casting rule can quietly rewrite. Two existing tests caught it; without
them this ships as "$ autocomplete stopped working everywhere".
ValueRow's tests updated: the "is a TEXTAREA" assertion became "is multiline
and grows", which is the requirement the tag name was standing in for.
The binding modal's template was a bare <textarea>, so it had no `$`
autocomplete at all -- reported as "the $ variable autocomplete does not work
in the context injector". Nothing was broken; the machinery had simply never
been attached to that field.
The suggestion pool was already sitting next to it. `insertOptions` builds the
"+ $ref" menu from this row's own references -- a socket row can reference only
its own slot, the general row can reference every socket -- and the
autocomplete now reads the SAME list, so the menu and the popover cannot drift.
Deliberately not the library's variables: nothing in this modal can resolve
one, and offering them would suggest bindings that silently do nothing.
Surface is `assembler` because this composes a template. Explicitly not
`wildcard`, which suppresses `$` on purpose.
`insertSlotRef` no longer splices at the caret. RichTextInput is
contenteditable with atom spans, so `selectionStart` does not exist and the old
path had nothing to splice into; it appends instead. Honest about what it does,
and the menu is the fallback now that typing `$` opens the same list in place.
Tests updated rather than worked around: seven drove the field as an
HTMLTextAreaElement. The modal's own suite stubs RichTextInput in its mount
helper the way the combine editor's tests do, and the two widget-level tests
drive the component directly, since jsdom does not implement contenteditable
editing and those tests care that the value reaches the persisted JSON rather
than how the caret moved.
Managing the file meant opening a file manager, which is how the maintainer
had to remove it to test the disabled state.
Refresh re-reads the path. The server already notices an mtime change on its
own, but nothing tells the PAGE to go and look, so a file copied in by hand
stayed invisible until a reload. Both actions also drop the cached
availability the editors hold, so an open editor picks up a list that appeared
or disappeared without a reload.
Remove deletes it. Same shape as the download for the same reason: no caller
input reaches the path, and a symlink there is refused rather than followed --
otherwise this unlinks whatever it points at.
The setting I added last commit was wrong three ways, all visible in one
screenshot of the panel: filed under "2. Sizing" when it is behaviour, in a
bespoke `editing.` namespace matching none of the three the playground routes,
and absent from the Display Playground entirely.
Now `wildcardPipeline.behavior.tagAutocomplete`, under "7. Runtime behavior",
registered in the playground store's routing set and bound to a control in the
modal.
The real fix is the fourth change. `playground-store.ts` carries a comment
asking the next person to "keep this routing in sync if a new key is added",
and a comment is not a mechanism -- it is a note that gets read after the
divergence, by whoever is looking for the cause. `playground-parity.test.ts`
reads both sources and asserts, for every registered setting, that it uses a
routable namespace, that the store knows its key, and that the modal binds a
control to it. 18 settings, three checks each.
That test caught its own bug on first run: the id regex matched `id:` sites
only, and most entries reference a `SETTING_ID_*` constant, so it found exactly
one setting. The "finds them at all" assertion exists for precisely that and
fired immediately -- a parity test that silently checks nothing is worse than
no parity test, because it reports success.
Playground rows for behaviour settings have nothing to preview on the right.
It is listed anyway: the playground is where users expect the settings
mirrored, and "has no preview" is not a reason to be absent from the list.
The canvas editors were bundled and rendering-ready but the feature never
fired there. Cause: the setting was read via `useUiStore()` behind a try/catch,
and NO Pinia is installed in the canvas widget mounts at all -- so it threw,
returned false, and stayed silently off. The try/catch I added to fix 113 tests
was hiding a missing implementation rather than handling an edge case.
Each host now answers for itself. `utils/tagSetting.ts` reads ComfyUI's own
setting when `app.extensionManager.setting` exists and the persisted SPA value
otherwise, so neither host depends on the other's machinery. The two switches
are deliberately independent: wanting suggestions in the full manager does not
mean wanting them while squinting at a node on a canvas.
The ComfyUI setting is hand-rendered rather than a plain boolean so it can
DISABLE itself when no tag list is installed, saying where to get one. A
checkbox that switches on and does nothing is the exact failure this feature
keeps having to design around -- a control implying a capability it does not
have.
Scope is unchanged and worth stating: RichTextInput only ever mounts inside
this extension's own widgets, so nothing here touches ComfyUI's text widgets or
another extension's. That is a property of where the component is used, and the
obvious future "improvement" of hooking ComfyUI's generic textarea would throw
it away.
Also fixes arrow navigation. The header and legend are sticky, so they overlay
the scrollport rather than shrinking it, and `scrollIntoView({block:"nearest"})`
only knows about the scrollport -- arrowing to the first or last row parked it
under a pinned band, selected and invisible. `scroll-margin` on the rows is the
mechanism for exactly that. Verified: arrowing to the last row leaves it fully
above the legend, and back to the first leaves it clear of the header.
Two reported by the maintainer from a screenshot, both specific.
The `general` swatch rendered as nothing. Legend swatches carried only a
modifier class, and `--general` was never defined -- the row bars get their
neutral grey from the base `.wp-rt-tag__cat` rule, which the legend markup did
not use. Swatches now have their own base class and `general` is stated
explicitly rather than inherited by accident, since it is a real category and
not an absence.
A scrolling row showed through beneath the legend band. The popover root has
`padding-bottom`, and `bottom: 0` sticks the legend to the CONTENT box, leaving
that padding transparent below it. The legend is now pulled down over it with a
negative offset and matching padding.
Verified live at full scroll: no blank swatches, and no row pixels below the
legend -- the only gap left is the 1px border.
The legend was designed, described and never built -- rows shipped with a
colour bar and nothing saying what the colours meant.
It appears only when more than one category is in the CURRENT results. On an
all-general query every bar is the same neutral grey, and a legend naming four
colours none of which are on screen is a row of height explaining nothing.
Verified live: a `mik` query renders "character artist general" -- the three
kinds actually present, not the full five.
Also pins the header and the legend. `overflow-y: auto` sits on the popover
root, so everything inside scrolled together: the query you are refining
scrolled out of view as you moved down the list. That was already true of the
`$`/`@` popover and is fixed for both. Sticky rather than a flex wrapper
because the row list has no container element -- restructuring the existing
markup would have put the working sigil popover at risk for no gain. Negative
margins cancel the root's horizontal padding so the pinned bands span the full
width instead of leaving a gutter for rows to show through.
Verified in the running SPA: scrolling the list 691px leaves both the header
and the legend visible while the rows move, and a field 189px from the bottom
of the viewport flips the popover above the caret rather than overflowing the
screen, legend included.
Completes #27. Typing a word in an option value now suggests tags; `$` and `@`
are untouched.
Non-interference is structural, not coordinated. The tag mode is a third value
on the SAME `acTrigger` state, so only one popover can exist -- two independent
popovers could both open over one caret, which is the behaviour this feature
was not allowed to introduce. And it is probed only where `probeAutocomplete`
already declined the caret, so the sigil probe gets first refusal on every
keystroke. `probeTagWord` re-checks for a preceding sigil as a second lock, and
19 tests assert the two probes never both claim a caret.
Commit inserts PLAIN TEXT. `$`/`@` build chips because they carry engine
meaning; a tag is just characters in a prompt. Deliberately not a branch inside
`insertChipAtCaret` -- its defensive re-derivation scans backwards for a
`$`/`@` run, which is exactly wrong for a sigil-less word.
Rows follow the design pass: the line that gets INSERTED is always primary, so
an alias hit reads `head_tuft` with `from blue_head_tuft` beneath rather than
leading with the alias, which is not what Enter produces. The category bar
appears only when the loaded file has categories, and the legend only when the
results actually differ -- a column of identical grey bars explains nothing.
Three bugs found by QA against the real SPA, none of which any test caught:
- `useUiStore()` at setup scope threw in 113 existing tests, which mount this
component without Pinia. Every other setting arrives as a prop, so the store
dependency was the odd one out as well as the broken one; it is now resolved
lazily and degrades to "off" when Pinia is absent.
- The popover renders on `acOpen && acItems.length > 0`, and tag mode returns
no `acItems` by design, so it could never appear. Now gated on the row count
for whichever mode is active.
- The "shared" status promise was a `let` inside `<script setup>`, which
compiles into `setup()` and is therefore per-instance: 135 identical requests
on a 133-option wildcard. Moved to a real module -- measured 135 -> 1.
Verified in the running SPA: the popover opens with 20 real rows from a
286,337-entry list, Enter completes `blue_h` to `blue_hair` as plain text with
zero chips, and typing `$mood` shows no tag rows at all.
Client half of #27, minus the editor wiring. Adds the API client namespace,
the types, the persisted on/off setting, and the Settings card.
The card separates two facts that look like one: whether the user WANTS
suggestions, and whether a tag list exists to make them from. The toggle owns
the first, the status row owns the second. Conflating them produces a switch
that silently does nothing, which is why /wp/api/tags/status reports
`available` independently of the setting.
Off by default -- the feature needs a list the user has to fetch first, so
defaulting it on would advertise a capability that is not there.
Four states the card renders honestly: nothing installed, installed and on,
downloading, and a two-column file that works but cannot colour-code. The last
reports "no categories" rather than pretending, because the dropdown will
visibly differ.
The path is shown even when nothing is installed -- it is the answer to "where
do I put my own?", which is the supported alternative to downloading ours.
The card states in the UI that Download fetches from GitHub, and that it is
the only thing this extension fetches. The README says so too, but someone
deciding whether to press a button should not have to read the README first.
Follows the Updates card shape (Field + Toggle, then a status row with an
action) because it is the same interaction: tell me the state, give me the
verb. Designed against the real tokens with real rows from a 286k index, not
mock data.
The only outbound request this extension makes, and only on an explicit click
in Settings. Documented in the README under "Network access" -- a user should
be able to find out that a plugin talks to the internet without reading its
source.
ComfyUI serves its API unauthenticated, so "fetch a URL and write it to disk"
is the most abusable endpoint shape available. Each capability is therefore
removed rather than checked at the door:
- The URL is a module constant. The request body is ignored entirely, so there
is no parameter to smuggle `http://169.254.169.254/` or an internal host
through.
- Redirects are validated per hop against a fixed host list. GitHub serves
release assets via a CDN so the chain must leave github.com -- to those hosts
and nowhere else, https only.
- The destination is computed from ComfyUI's user dir plus a fixed filename, so
no caller input reaches the path. A symlink there is refused rather than
followed, so the write cannot be redirected.
- The body is size-capped while streaming. Content-Length is checked when
present but never trusted as the only guard, since it is whatever the server
chose to say.
- A single-flight lock means repeat triggering gets "already running" instead
of N concurrent multi-megabyte fetches.
- The payload is parsed BEFORE it replaces anything, then moved atomically. A
response that is not a readable tag list leaves the existing one intact, and
an interrupted download cannot leave a half-written file in place.
- No proxy or cookie handler on the opener: one public asset, no ambient
credentials.
21 tests, one per removed capability, because a comment claiming a capability
is absent is worth nothing on its own. Includes the metadata-address and
suffix-confusion hosts (`github.com.evil.example.com`), a Content-Length that
lies about a body over the cap, and a symlinked destination.
What is deliberately not claimed: this does not defend against a compromise of
our own release. It is a tag list, parsed into strings and never executed, so
the worst a bad file achieves is bad suggestions.
Data source for the optional value autocomplete (#27). Replaces the
community script this started from, which walked all 1000 allowed pages and
kept only `name,post_count`.
Three changes, each from something measured against the live API on
2026-08-06.
A post-count floor instead of a page count. `search[order]=count` sorts
strictly descending ACROSS pages:
page 1: first 8,244,950 last 55,918
page 100: first 68 last 67
page 800: first 1 last 1
so a popular tag cannot hide on a later page and stopping early provably
loses nothing. Walking to page 1000 spends ~900 requests and a quarter of an
hour collecting single-post tags. The default floor of 20 lands near what
other extensions ship.
Aliases, from the separate `tag_aliases.json` endpoint. `tags.json` carries
none, and aliases are what let someone type `hires` and land on `highres` --
demonstrably the most valuable field after the names.
Category is kept. The API returns it and the old script discarded it; it is
what lets the UI tell an artist tag from a character tag.
Also retries with backoff rather than aborting on the first non-200, which
over a 100-request run means one blip no longer discards everything.
The User-Agent is pinned to bare `product/version` and must stay that way --
Danbooru's bot filter 403s a bare token, a longer description, or anything
containing a URL. Adding a contact URL is the usual courtesy for a scraper and
is exactly what breaks it, so the reasoning is recorded next to the constant.
MANUAL ONLY. The list describes Danbooru, not this project, and goes stale
slowly: a two-year-old file still autocompletes correctly because staleness
moves post counts and therefore ranking, while tag names barely change. That
is not an argument for a timer against someone else's API. Output goes to a
fixed non-semver `tag-list` tag, replaced in place, so the download URL is
stable and the SPA can hardcode it -- and so semantic-release ignores it.
Server half of the optional value autocomplete (#27). No UI yet.
The tag list is a file the user supplies at one path we own, under ComfyUI's
user dir -- not the package folder, which a reinstall replaces and the asset
pruner walks. Reading other extensions' tag files was considered and rejected:
it couples us to layouts they are free to change. Our own CI workflow will
generate the list instead.
Bundling was never viable regardless -- a usable list is 2-6 MB against a
420 KB gzipped budget -- and the file is not sent to the browser either.
Prefix search runs here and the client gets ~20 rows per keystroke, which is
the drift-poll lesson applied before making the mistake rather than after.
Both shapes in the wild are accepted:
name,post_count ComfyUI-Custom-Scripts
name,category,post_count,"aliases" Danbooru API export
with no header to switch on, so they are told apart by magnitude: a category
is a small enum, a post count is not.
Built on the FIRST SUGGEST REQUEST, never at plugin import. Benchmarked on a
real 286,337-entry file: 785 ms to load, 5-950 us to query. Paying that at
startup would slow every ComfyUI launch for a feature most users leave off --
the exact problem this cycle just finished fixing.
Two defects the benchmark caught, both alias-related:
- `1girl` matched both itself and the alias `1girls`, which resolves back to
`1girl`, so the same row rendered twice. Results are now deduplicated by the
tag that would actually be inserted, and a direct hit beats an alias hit for
the same canonical.
- An alias match displayed only its canonical, so `ka` returned `pokemon` with
nothing to explain it. The response now carries `matched` alongside `name`
so the UI can render `kalos -> pokemon`.
Prefix-only by design. Substring matching over 200k tags buries the wanted tag,
and every booru autocomplete users already know behaves this way.
Also exposes `comfyui_user_dir()` from engine.db.connection -- the detector
chain already existed there but only as private helpers behind the DB path,
and reaching across modules for underscore names to find it was the wrong
shape.
Investigating slow ComfyUI page loads on a real install turned up this
project as the single largest contributor, by a wide margin.
js/ 518 files 36.0 MB 179 stale chunk copies
web/ 1256 files 22.0 MB 1120 stale chunk copies
ComfyUI fetches EVERY *.js under WEB_DIRECTORY at page load, so that install
requested 237 of our chunks where 58 were live: 9.9 MB, 42% of all extension
bytes on the page and 27% of all extension requests. Twelve copies of `about`,
nine of `ContextWidget`.
Two independent causes, both ours.
Chunks are content-hashed, so every release emits new filenames, and Manager
installs an update by extracting over the installed folder without deleting
what the new version dropped. Each mechanism is reasonable alone. Together
they never remove anything. It stayed invisible for a dozen releases because
`emptyOutDir` wipes the output directory on every local build -- only installs
that UPDATE accumulate, and a maintainer never sees one.
And `sourcemap: "hidden"` still WRITES every .map, omitting only the
`sourceMappingURL` comment, so 22.5 MB of maps shipped that no browser had
ever requested. `pack-release.mjs` excluded them from the GitHub zip, but the
registry package comes from pyproject's `includes = ["js", "web"]`, which has
no exclusion -- so the fix has to be not emitting them.
Now: each build writes `.wp-assets.json` listing what it produced, and the
plugin prunes anything hashed and unlisted at import, before ComfyUI scans
WEB_DIRECTORY. Self-healing -- existing installs clean themselves on the next
start with no user action.
Deliberately conservative, because deleting a live file breaks an install
while missing a stale one only costs disk: no manifest, an empty manifest or a
corrupt one all mean do nothing; only bundler-shaped names are candidates
(hashed chunks, plus any .map -- the entry map is unhashed, which the hash
pattern alone walked straight past); every failure is swallowed.
Verified against a copy of the real install, updated the way Manager would:
1,881 files -> 302, 60 MB -> 10.9 MB, 1,579 removed. All 551 relative module
imports across the surviving chunks still resolve, and every asset
`web/index.html` references is intact.
The constraint and derivation filters inherited the fixed-values threshold of
"more than 8 rows" unexamined, and it hid the feature outright. Measured
against a real library: 53 derivations with at most 3 rules, 21 constraints
with at most 2 exceptions. Nobody would ever have seen either filter.
Rules now appear above 2, exceptions above 5. Not merely to make them visible
-- a derivation rule is a whole card rather than a table row, so three of them
already scroll, while a fixed-value row is short enough that eight fit.
The prop's doc comment now says thresholds are the caller's call, sized from
how tall that surface's rows are, so the next surface does not inherit 8 by
accident too.
Reported by the maintainer: the editor accepted the same source/target
combination more than once with contradictory modes and factors. Only one ever
applied. `combine_constraint_factor` files exceptions into a dict keyed by the
pair, so the last one in the list wins and every earlier one is discarded.
Verified against the pure math, and the alarming direction is real:
[boost x3, reduce x0.5] -> 0.5 not the combined 1.5
[reduce x0.5, boost x3] -> 3.0 order decides the result
[boost x3, exclude] -> EXCLUDE
[exclude, boost x3] -> 3.0 the exclusion is thrown away
That last line contradicts the documented model in CLAUDE.md, which says
constraints combine "with `exclude` (factor 0) absorbing". Within duplicate
exceptions it neither combines nor absorbs, and the deciding factor is list
position -- which no surface displays and nothing lets you edit.
Enforced at the AUTHORING boundary, not in `validate_payload`. `resolve` calls
that on every graph run, so a rule there would turn an already-stored payload
into a hard failure mid-execution -- strictly worse than the silent
misbehaviour it replaces, and unreachable for a user who cannot open the editor
without the graph running. Handlers may now expose an optional
`validate_authoring`, called by the module create/update paths and by bundle
child validation; existing rows stay executable.
Engine math is deliberately unchanged. Making duplicates combine would have
been defensible -- it is what the docs describe -- but it silently alters
re-weighting for anyone who already has them, and "you cannot create this
anymore" achieves the same end without touching anyone's output.
Scanned the maintainer's library first: 21 constraints, 0 duplicate pairs, so
nothing existing is affected either way.
`_startup_id_middleware` is registered on ComfyUI's application, not on a
sub-app, and had no path check despite a docstring claiming it tagged
"/wp/api/*". It therefore stamped X-WP-Startup-Id on every response the whole
server sent: ComfyUI's index, /api/extensions, image outputs, other
extensions' routes. Found by a remote probe during the 2026-08-06 session --
`GET /` came back carrying it.
Nothing depended on the wider scope. The only consumer is
manager/api/client.ts, which talks exclusively to /wp/api/*.
Same principle CLAUDE.md's extension-isolation section applies to CSS
selectors and litegraph node properties, extended to response headers: being a
guest in someone else's application means not writing on their responses.
`drift-store.ts` polls /wp/api/modules/hashes and /wp/api/bundles/hashes every
5 seconds. Both the SPA and the in-graph WP_Context subscribe, so a ComfyUI tab
with a Context node on the graph polls these whether or not the manager is ever
opened.
Measured against a live 2.13.1 install on 2026-08-06: 33,008 bytes per poll, no
ETag, no Cache-Control, no Last-Modified, and 0 of 39 observed requests served
from cache. That is ~24 MB/hour per open tab on an idle page. Invisible on
localhost; over Tailscale it was the largest thing this extension does.
Producing it was not cheap either, despite the docstring's "lightweight ...
without measurable cost" -- that described the response, not the work.
`ModuleRepository.list()` is `SELECT *` plus a json.loads of every payload in
the library, and the handler kept three fields per row and discarded the rest.
Two changes:
- Conditional responses. `json_ok_revalidated` emits an ETag plus
`Cache-Control: no-cache` -- store it, but revalidate -- and returns a bodied
304 when `If-None-Match` matches. Nothing changes for the client: the browser
serves the cached body as a 200, so `fetch().then(r => r.json())` is
untouched and the saving is entirely on the wire.
- A cheap stamp behind the ETag. `library_stamp()` is
COUNT/SUM(version)/MAX(updated_at) -- one aggregate row, no payloads. The
expensive map is built only when the stamp moves, which is the whole point:
computing an ETag from the response body would have done all the work anyway
and then thrown it away.
Also narrows the map builders. `list_hash_rows` selects the columns the drift
map needs instead of every column via `_row_to_module`/`_row_to_bundle`, which
parse `tags` (and `children`, for bundles) per row for a map that wants
neither. Bundles get the bigger win -- `payload_hash` is a stored column there,
so that path now parses nothing at all. Modules still parse `payload` because
their hash is computed rather than stored; removing that needs a schema
migration, and the stamp makes it moot in the steady state.
Stamp precision, both directions verified: `set_community_origin` writes
without a version bump and cannot change the map, so the ETag correctly holds.
A favourite toggle goes through `update()`, whose single statement always does
`version = version + 1`, so it does move the ETag and costs one refetch of an
identical map. Accepted rather than fixed -- a rare user action against a second
counter tracking payload-affecting columns only -- and pinned by a test that
says so, and says a future failure would be an improvement.
Same bug as fa9cde05 fixed in the three simpler editors, carried
independently here because this editor predates `useBulkSelection` and was
never migrated onto it. `selectableOptions` was the full option list while the
table rendered `visibleOptionRows`, so select-all reached rows the filter was
hiding.
Worse blast radius than the fixed-values case. Bulk actions here are delete,
set-weight, and tag add/remove. Delete at least changes the row count;
`setWeightSelected` rewrote every weight in the list with no visible signal at
all, and a hand-tuned distribution has no undo.
`toggleSelectAll` now adds or removes only the visible ids, matching the
composable's semantics: a selection survives the user retyping the filter, and
`selectedCount` still reports the honest total.
Also migrates FixedEditor onto ui/ListFilter (the follow-up fa9cde05 deferred)
and drops the ~50 lines of markup and CSS it duplicated. `test-prefix="fv"`
keeps its data-test hooks byte-identical, so its tests are unchanged.
Two layout fixes found by QA, not by tests:
- ListFilter had no flex growth, so it never claimed the card header's slack
the way the fixed-values filter it was extracted from did. Ported the
`flex: 1000 1 auto` and its rationale.
- `.wp-card__header` could not wrap, so a crowded header shaved its flexible
child instead. The derivation card has four buttons and squeezed the filter
input to 18px in a narrow window. The header now wraps and the filter has a
220px floor; measured 18px -> 194px, with every other card header on the
page unchanged at 42-50px and nothing overflowing.
Verified on a 133-option wildcard: filtering to 20 and selecting all reports
20, not 133; clearing the filter keeps those 20; selecting all under a second
filter adds 15 more; deselecting under that filter returns to 20 with the
first selection intact.
The wildcard and fixed-values editors grew a filter; these two never did,
which had it backwards. A constraint's exception list is routinely longer
than the wildcard it filters, and a rule card is tall enough that a dozen
rules is already a scroll.
Extracted `ui/ListFilter.vue` rather than copy the fixed-values markup a
third time, and `utils/listFilter.ts` for the two haystack builders, since
"what does this row match on?" is the part worth testing and mounting an
editor to assert it would test the wiring instead.
Both surfaces match on what the row READS AS, not what it stores. An
exception matches its resolved source/target labels -- the stored values are
frequently `@{uuid}` tokens and nobody searches for a uuid they cannot see.
A rule matches every variable, operator, mode and literal across its branches
and its else, but never its generated id.
Rows carry their ORIGINAL index through the filter. Both editors address rows
by position (`removeRule(idx)`, `exceptions.value[idx]`), so a plain filtered
array would edit and delete the wrong row, and the rule cards would renumber
under a filter and claim Rule 5 is Rule 1.
Also fixes a pre-existing destructive bug in the fixed-values editor, found
while porting the pattern: `useBulkSelection` scoped select-all to every row,
not the visible ones. Filtering 40 values to 3 and hitting the header checkbox
selected all 40, and the delete that usually follows removed 37 rows the user
never saw. It takes an optional second getter for the visible ids; toggleAll
and the header state now read that, while count and selectedIds stay global so
a selection survives the user retyping the filter.
Verified against a running ComfyUI on temporary modules, since nothing in the
library was long enough to trigger either filter: filtering 8 rules to 1 keeps
its card labelled Rule 5, select-all under that filter reports 1 selected
rather than 8, and deleting a filtered exception removes that row -- confirmed
by the surviving rows' mode sequence, not by row text. The temporary modules
were deleted afterwards.
Vite library mode ignores `build.assetsInlineLimit` and inlines every asset
unconditionally, so both woff2 files were base64'd into a chunk: 88,660 bytes
of font became a 118,896-byte JS file, awaited in main.ts's top-level
`Promise.all` and therefore parsed as JavaScript before ComfyUI could finish
registering the nodes.
fonts.ts believed the opposite -- its comment claimed `new URL(path,
import.meta.url)` kept the woff2 as separate assets. That transform is exactly
what Vite intercepts in lib mode, so the intent never held.
The fonts now leave the module graph entirely. `src/assets/fonts/wp-fonts.css`
is a real source file copied verbatim to `js/assets/fonts/` by copy-fonts.mjs;
fonts.ts <link>s it at a URL resolved against its own chunk, and the browser
resolves each woff2 relative to the stylesheet. No path arithmetic in JS, and
a renamed install directory still works.
The href is assembled from array parts on purpose: Vite's asset transform fires
on `new URL(<string literal>, import.meta.url)`, so a literal here would
silently re-inline the stylesheet with no build error and no failing test.
Measured with the gate's own method: 492,407 -> 403,055 bytes gzipped. Total
bytes on a cold cache are about unchanged -- gzip recovers base64's overhead --
so the win is latency and caching, not payload: registration no longer waits,
90 KB left the JS parse path, and the fonts stop being re-downloaded on every
release when the enclosing chunk's hash changes.
TOTAL_LIMIT tightened 490 -> 420 KB. Re-inlining costs ~90 KB, which fits under
490 KB and would have regressed unnoticed; it does not fit under 420 KB.
Verified against a running ComfyUI: the stylesheet and both woff2 serve 200 and
are fetched as fonts, and document.fonts.check() passes for JetBrains Mono,
which only this stylesheet provides.
The registry publish for 2.13.0 failed:
400 {"message":"The node version already exists"}
The empty 2.13.0 cut earlier today was deleted from the registry, but
deleting frees the LISTING, not the number — version records are
immutable there, the same model as PyPI and npm, and the publisher
requires each new version to be greater than every existing one. So
2.13.0 can never be published again, whatever it now contains.
The consequence is worse than an untidy version history: 2.13.0 carries
the `pending_move` containment fix, it reached GitHub, and it did NOT
reach anyone installing through ComfyUI Manager. Those users are still on
2.12.0 with the unauthenticated file copy/move reachable.
Restores the 2.13.0 notes so this release ships with them rather than the
empty body an emptied `next.md` would produce, plus a line for people
already on 2.13.0 saying the two are the same build.
The page rendered only the newest release, so updating across two
versions meant the middle one's notes were unreachable. That is not
hypothetical: 2.12.0 — the largest release in months — was current for
about an hour before 2.13.0 replaced it, so anyone updating from 2.11.0
would never have seen it.
The last three releases now appear beneath the current one, collapsed,
each with its own notes and a link to its release page. Three because the
gap is small but real; more and the page becomes a changelog, which the
compare link already does better.
Fetched through the same throttle and rate-limit lockout as the update
check — a second GitHub call on a shared 60/hr anonymous quota, on a page
someone may open repeatedly, is exactly what the caching work existed to
prevent. Cached under its own key with the same TTL, and skipped
entirely while a lockout is in force.
Also fixes the "All releases" button, which preferred the current
release's own URL and so went to a single release whenever the release
check had resolved — the common case. It now goes to the releases index,
which is what it says.
`PUT /wp/api/database/config` accepted `pending_move.from` and `.to` as
any absolute paths. `execute_pending_move` then runs `shutil.copy2` or
`shutil.move` on them at plugin load, as whoever runs ComfyUI. Every
ComfyUI route is unauthenticated by default, so anyone able to reach the
port could schedule:
* an arbitrary file read — copy a target into `web/`, which this plugin
serves at `/wp/<path>`, turning our own static server into the
exfiltration channel;
* an arbitrary overwrite or deletion — move any file anywhere.
Fixed with an allowlist rather than a sanitiser. The database can
legitimately live in exactly three server-computed locations under one
fixed filename, so there is no reason to accept a client-supplied path.
The live path is also allowed, since WP_DB_PATH / COMFYUI_USER_DIR can
place the file elsewhere and those users must still be able to migrate
off it.
Both paths are `resolve()`d before the membership test, so neither `..`
nor a symlink planted at an allowed location can smuggle a different
target past it, and the resolved values are what get stored — what
executes is what was validated.
`spa.py` already did this correctly (`resolve()` + `relative_to()` + 403);
this route simply missed the pattern.
Adds 7 containment tests covering arbitrary source, arbitrary
destination, the exfiltration-into-`web/` chain, traversal, and a no-op
move — plus one asserting a legitimate relocation still works, since a
guard that breaks the feature it protects is its own bug.
2.13.0 shipped as an empty release. Three commits touching only
`scripts/` and `.github/` were typed `feat(announce)` and
`fix(announce)`; both are release-triggering, so semantic-release did
exactly what it was told, and every user on 2.12.0 was offered an update
with a blank changelog.
The discipline fix — remember to type tooling commits `ci:` — had already
failed once within an hour of the rule being written down, so this is the
structural one. `paths-ignore` means those paths cannot cut a release
whatever the commit type says.
Neither path is part of what a user installs: `scripts/` is dev tooling,
`.github/` is CI. GitHub skips the run only when EVERY changed file
matches, so a push touching shipped code alongside a workflow still
releases normally.
`docs/**` is deliberately excluded from the list: `docs(readme)` is
configured to bump a patch, and `docs/release-notes/next.md` IS the
release body.
publish.yml needs no change — it fires on a published release, so no
release means no registry publish.
2.13.0 shipped nothing. It was cut because `feat(announce)` and
`fix(announce)` are release-triggering types, but those commits only
touched `scripts/` and `.github/` — dev tooling that is not part of what
users install. They should have been `ci:`, which is `release: false`.
The result was a version bump with an empty body: every user on 2.12.0
would have seen an update prompt with a blank changelog.
Release and tag are deleted; this restores package.json, pyproject.toml
and CHANGELOG.md to 2.12.0.
`[skip ci]` is load-bearing. Without it this push runs release.yml, which
would analyse the same commits against the now-latest tag v2.12.0 and cut
2.13.0 straight back.
Note that 2.13.0 will be used again by the next REAL release: the
`feat(announce)` commits stay in history and still count toward the bump.
That is the intended outcome — the number is reused for a release that
actually contains something, rather than being burned on an empty one.
Unset and empty were already safe. A MALFORMED id was not: any truthy
string went straight into `<@&…>`, so a stray space in the secret produced
a literal `<@& >` and a pasted mention produced `<@&<@&123>>` — visible
junk at the top of the most public message the project sends.
`normalizeRoleId` is now the single decision point, applied inside
`buildPayload` rather than at the call site so every caller gets the same
guarantee. It trims, unwraps a pasted `<@&123>`, and requires a 17-20
digit snowflake. Anything else is rejected rather than guessed at: a ping
that silently does not happen is a far smaller problem than a broken one
that does.
`allowed_mentions.roles` is derived from the same normalised value, so
the two can never disagree — a content string naming a role the payload
does not permit would be a mention that renders but never notifies.
The CLI warns when a non-empty id was supplied and rejected. Dropping it
silently would leave someone wondering why the ping never fired.
One webhook meant the choice was all-or-nothing: either every release
announced itself to everyone, or nothing was automated. Two channels,
deliberately asymmetric:
staff posts AUTOMATICALLY on every release
public ONLY from a deliberate manual dispatch
The staff copy carries a link back to this workflow with the inputs
spelled out. That is what makes it a review step rather than a duplicate
feed: the post being read IS the post that will go out, and the button to
send it is attached to it. Otherwise "now go publish it" is a separate
instruction living in someone's head.
The public copy does not get that field — an announcement should not tell
its readers how to re-send it. Returned as `undefined` rather than an
empty array, since an empty field block renders as dead space.
Guarded twice. The workflow only passes `--channel public` on a manual
dispatch, AND the script refuses public when `GITHUB_EVENT_NAME=release`.
One of those is enough; both are cheap, and the failure mode is
announcing to everyone with nobody having read it.
Only the public post pings the role. A ping in the staff channel on every
release is noise in a room that exists to watch releases.
`DISCORD_WEBHOOK_STAFF` / `DISCORD_WEBHOOK_PUBLIC`, with the existing
`DISCORD_WEBHOOK_URL` kept as a staff fallback so the current
single-webhook setup keeps working untouched.
v2.12.0 went out as "Captain Hook" with a placeholder avatar — a webhook
posts under whatever name and image it was created with, and Discord's
default is a generic pair.
`username` and `avatar_url` override that per message, so the identity
lives in the payload rather than in a webhook's settings. It then stays
right if the webhook is ever rotated or recreated, and it is the same in
every channel the automation posts to.
Avatar is the 512px manifest icon, fetched from raw.githubusercontent by
Discord server-side. It has to be raster — an SVG will not render, which
rules out the repo's favicon.svg, and that failure mode is silent. Pinned
to `main` rather than a tag so replacing the logo needs no code change.
`DISCORD_USERNAME` / `DISCORD_AVATAR_URL` override both. An empty value
falls through to the defaults rather than blanking the identity and
handing the post back to the webhook's name.
The dry run now prints both, since identity is invisible in the embed
body and is exactly what was wrong the first time.
The v2.12.0 announcement failed before it ran a line of script:
Unable to locate executable file: pnpm
`actions/setup-node` sniffs the lockfile, sees pnpm, and tries to prime
its cache — but this job never installs pnpm. It does not need to: the
announce script has no dependencies at all, just plain ESM and the global
fetch built into Node 18+. Nothing is installed, so there is nothing to
cache.
Caught only in the real run because the failure is in the runner's
toolchain setup, not in anything a local invocation of the script
exercises.
`FrameChips.vue` imported `theme.css` into its scoped style. The sheet
declares its tokens on `:root`, so one copy anywhere in the document
serves everything — and this component only ever renders inside
ContextLoopWidget or SeedListWidget, both of which already import it.
Being a shared component, its chunk then carried the whole 521-line sheet
a third time. Removed, with literal fallbacks added to the two
declarations that lacked them so the component still renders if it is
ever used somewhere unthemed.
The gzip win is small (~0.3 KB) because the chunk it lands in already
contained the sheet via SeedListModal, and gzip dedupes the repetition
well. Worth doing anyway: the duplication would start costing real bytes
the moment these modules split into different chunks.
Note for anyone reading the bundle report on this PR: `FrameChips.js` is
listed as a new 10.70 KB chunk and `SeedListModal.js` as removed at
8.33 KB. That is one chunk being RENAMED, not 10.70 KB of new code —
Rollup names a shared chunk after one of its modules, and adding
FrameChips to the chunk that already held SeedListModal and SeedLockRow
changed which name it picked. Real new weight is closer to 2 KB.
Brings in the 2.11.0 release commit. Only conflict was
docs/release-notes/next.md: main cleared it when 2.11.0 shipped, this
branch holds the unreleased v2.12 notes. Kept ours — clearing it would
ship a release with an empty body.
Ten commits landed after `next.md` was written and none of them were in it.
Anything left out of that file simply does not ship in the notes.
No new highlights. The cap is 4-5 and it was already at 5 — per the file's
own rule, if a sixth feels essential something else was not a highlight.
Per-frame lock and bypass is a shortcut to something the seeds dialog
already did, so it goes in the tail rather than displacing anything.
Tail gains six entries in two new groups: the frame chips and collapsible
grid on the Loop and Seed List, the broken-reference fix, the what's-new
page, and the update check that was burning GitHub's hourly allowance.
Count corrected 20 → 26, which the update dialog computes independently
from the same bullets.
Also fixes a real bug in the announcement transform, caught by previewing
it against this file: `splitBody` stripped `<details>` BEFORE counting the
tail. The "Also in this release" bullets live inside that block, so it
counted nothing real — while the authoring guidance in the trailing HTML
comment contributed bullets of its own. A 26-change release announced
itself as 3. Comments are stripped, details are not.
README gets the Nodes 2.0 line. Renderer support is a compatibility fact
people check before installing, it was the single largest piece of work in
this release, and the README did not mention it anywhere. The "switching
between them with a workflow already open" clause is deliberate: that is
what repeatedly broke and is now specifically handled.
Announcements were written by hand, which is why they went out "only once
a few versions" -- the cost was never posting, it was composing a second
piece of prose about a release that had already been written up once.
Nothing new has to be written. `docs/release-notes/next.md` is already
curated by hand per release and already IS the GitHub release body, so
the announcement is a transform of it rather than a fresh document.
`scripts/lib/discord-notes.mjs` handles the gaps between GitHub markdown
and Discord, which are specific rather than general:
- masked links render ONLY inside an embed, so the notes go in an embed
and the message content stays a bare ping
- there are no tables; rows become bullets
- <details> shows as raw tags
- headings render, but an embed `##` outsizes the embed title above it,
so headings become bold
- the description caps at 4096, and truncation cuts at a bullet
boundary -- a hard slice can land inside a link and render as broken
markup, which is worse than saying less
It cuts at the same `<!-- /modal -->` marker the in-app update dialog
uses, for the same reason: an announcement is an interruption. The tail
is counted rather than dropped, so a three-bullet post over a forty-change
release does not read as a quiet week.
`allowed_mentions` is always explicit. Release notes are not written with
`@everyone` in mind and a webhook will happily resolve one that slipped
in; only a configured role id can ping.
Two entry points. `release: published` posts automatically. A manual
`workflow_dispatch` takes `--since <tag>` and rolls several releases into
one post -- the catch-up case that actually happens -- and defaults to a
dry run so a manual trigger cannot surprise anyone. Dry run is also the
CLI default: `pnpm announce --version v2.11.0` prints and posts nothing.
Kept as a separate workflow from release.yml on purpose: a Discord
outage, a rotated webhook or a rate limit must never fail a release that
has already shipped.
Also widens the vitest include to `scripts/**/*.test.mjs`. A broken
announcement transform is otherwise only noticed after it has been
posted.
The broken-ref card told every surface to "click the chip to point it at
another module". Only `RichTextInput` listens for `remap`.
`RichTextPreview` renders the same chips read-only, and the canvas
derivation modal's summary column is a preview -- so on the surface where
the card was most likely to be read, the one instruction it gave did
nothing.
`remappable` is now an explicit prop, set by the editable input alone.
Read-only surfaces point at the SPA editor instead, which is where the
value can actually be repointed. It defaults to false because a caller
that forgets the prop is precisely the caller with no handler wired:
promising nothing is the safe direction.
Nothing shipped stale -- `web/` is a gitignored local build artifact --
but it is worth recording that a change under `src/manager/` is invisible
in the running SPA until `pnpm build:manager`, and the pre-commit hook
only builds the extension (for the size gate). Touch the SPA, rebuild it
before judging what you see.
A ref to a module deleted from the library went on looking fine: right
name, right colour, resolved-ref glyph, and a hover card quoting the
option count the module had BEFORE it was deleted. The node badge said
BROKEN REF while the chip inside the modal disagreed -- the two read
different sources, and only one of them was right.
ROOT CAUSE. When the server confirms a uuid is gone -- a 404, or a 200
that omits it -- `fetchBundle` stamped a permanent tombstone but left the
cached snapshot in place, so `lookup()` kept answering from it and no
consumer ever learned the ref had broken. The rule it was following
("keep the stale value so a label never flickers back to a raw uuid") is
right for a TRANSIENT failure, where the old value is our best guess at
the current one. Once the server says the module is gone, the old value
is not a guess, it is a false statement. Confirmed-missing uuids now
evict; transient ones still keep their snapshot. `lookup` also refuses a
permanently-tombstoned uuid outright, so the fact beats any cache entry
whatever wrote it.
`atomIsResolved` already documented exactly this case -- "a ref pointing
at a deleted library entry should still render unresolved (red chip) even
when the cached label survives" -- and was correct; it just asked a
`lookup` that was lying to it.
THE CHIP. Two more places assumed a resolved ref. `optionStats` counted
from whatever snapshot was cached regardless, and outranks the broken
branch in the template, so a gone module reported "2 options" and hid the
explanation. `poolLabel` printed "pool: library" because that is
`resolvePoolFor`'s fallback for an unknown uuid -- a fallback, not a
finding -- which put "not in the library" and "pool: library" in the same
card. Both now return null for an unresolved ref.
The broken chip keeps the name rather than collapsing to a bare "?": the
`@{uuid#name}` syntax preserves what the target was called when the
reference was written, so it renders as a red `? test` and the hover
names the missing module, says it is not in the library, and says
clicking will remap it. Phrased as "was", since a name we can no longer
verify is exactly what the old card was wrong about.
The toggle reset to open on every reload, which made it close to
pointless: someone who collapses a 100-frame grid to get their node back
wants it collapsed tomorrow too.
State lives on `node.properties.wp_frame_chips_collapsed`. That is the
workflow-JSON serialization root, and the only place per-node UI state
survives a save -- a WeakMap would be lost on reload, which is exactly
what we are fixing. Key is `wp_`-prefixed per the extension-isolation
convention.
`FrameChips` takes it as a `defineModel`, so it stays usable standalone
(local fallback) while the widget glue owns the value in the app. The
glue keeps a ref as the render source of truth and writes through to
properties, so a toggle repaints immediately instead of waiting on a
poll.
The re-sync in `onValueRestored` is load-bearing: `create()` runs BEFORE
ComfyUI applies a workflow's saved properties, so the first read always
sees nothing. Without it a collapsed grid would come back open and the
persistence would look broken in precisely the case it exists for.
The collapsed header keeps reporting `N locked · N bypassed`. That
mattered when collapse was per-session; it matters more now that the grid
can stay hidden indefinitely, because a forgotten lock is a confusing run
with no visible cause.
The chips are the inline view of what the per-iteration seeds modal
lists, so sitting above its button made them read as an unrelated
section. Below it they read as its expansion, and the two nodes now
agree: the Context Loop already ordered them this way.
Extracts the Loop's per-frame chips into a shared `FrameChips` component
and gives WP_SeedList the same surface, because the two nodes were
already showing the same information through different code.
CLICK SEMANTICS DIFFER ON PURPOSE. The Loop has an edit cursor, so a
plain click selects the frame to edit and the state toggles need
modifiers. The Seed List has no cursor and nothing else a chip could do,
so a plain click toggles the lock directly -- making someone hold Shift
for the only available action would be ceremony.
Bypass is asymmetric for the same kind of reason. The Loop OWNS its
bypass set, so Alt-click toggles it. The Seed List only MIRRORS the
bypass of the loop wired into its `loop_config`, so its chips show the
state and refuse to change it: editing there would mean writing to a
different node. Alt-click is inert rather than absent, and the tooltip
names where the setting actually lives, so a click that does nothing does
not read as a bug.
Both nodes now show locked frames too. That state existed and was only
visible inside the modal, which defeats the point of reading it off the
node.
COLLAPSE + BOUNDED HEIGHT. A 100-frame loop previously grew the node
until the chips owned the canvas. The grid now caps at roughly four rows
and scrolls; the wheel shield already installed on every widget host is
what keeps that scroll from zooming the canvas under Nodes 2.0.
The header keeps a `N locked · N bypassed` summary while collapsed --
hiding the grid must not also hide the fact that frames are set, since a
forgotten lock is a confusing run. Only in-range frames are counted: an
out-of-range lock has no chip here, and naming it would point at a frame
that is not on screen.
Collapse is deliberately NOT persisted. Surviving a workflow save would
mean a hidden grid staying hidden across sessions, which is the same
forgotten-lock trap. Re-opening costs one click.
Test ids for the chrome are pluralised (`loop-frames-grid`) so they do
not collide with the chips' own `loop-frame-` prefix, which suites count
with a prefix selector.
Both states were already VISIBLE on the frame chips -- a dashed border for
bypassed -- but only CHANGEABLE from the per-iteration seeds modal, which
is two clicks away and covers the node you were reading. Flipping one or
two frames is the common case, so it should not cost a round trip through
a dialog.
Shift-click toggle the frame's seed lock
Alt-click toggle bypass
Ctrl is deliberately unused: on macOS Ctrl-click IS a right-click, so the
combo would open a context menu instead of firing. Alt for bypass follows
the idiom already in the seed modal, where Alt-click on Copy takes the
locked-only variant.
A chip-lock writes the seed the frame WOULD have used, from the same
`deriveLoopSeeds` series the modal's "Lock all" writes, so the two agree
-- a lock that froze a different value than the one displayed would be
worse than no lock.
Bypassing the last running frame is refused, mirroring the modal's own
rule, and says why with a toast. A silent no-op would read as a broken
click, and nothing on the chip hints at the reason.
A modifier click never also moves the edit cursor. Jumping the editor to
another frame as a side effect of locking one is the kind of surprise
that makes people stop trusting a shortcut. `base` takes no modifiers at
all: it has no seed to lock and nothing to bypass.
Locked frames now get a corner dot -- the chips are ~20px tall so a
padlock glyph would be mud, and the tooltip carries the actual seed. The
dot survives bypass, or unlocking later would look like it did nothing.
Every chip is `position: relative` whether locked or not, so toggling one
cannot reflow the grid.
The combos are printed under the grid rather than left to tooltips. An
undiscoverable shortcut is the same as no shortcut, and that line is
where the reader is already looking.
As a dashboard card it held the top of the home view permanently to
deliver something read once, and competed with the hero for the first
thing a returning user sees. A topbar button with an unread dot costs a
few pixels, says "there is something here" just as clearly, and -- unlike
a dismissible card -- is still there next week when someone wants to
check what changed.
That last part fixes a gap the card could not. The update pill renders
only while a NEWER release exists, so once you were current there was no
way back to the notes for the version you are actually running. This page
is now the permanent home for them, which is what makes the unread dot
safe to clear on sight: nothing is lost by not reading it today.
The page shows the full notes, including the "Also in this release" tail
the update dialog cuts. The dialog cuts it because it is an interruption
and should stay short; a page the reader chose to open is not, and
withholding half the notes there would just send them to GitHub. The
per-commit dump stays stripped in both -- that is for people reading git.
Icon is a megaphone, with the dot moved to the BOTTOM-right rather than
the icon changed to suit the dot. Top-right is the conventional corner
but it is also where the horn is, so the dot merged into the glyph and
stopped reading as a marker; bottom-right is the one corner the shape
leaves empty. Tried and rejected: `pi-gift` (says reward), `pi-bell`
(promises actionable alerts this does not deliver) and `pi-sparkles`
(the wildcard kind icon everywhere else).
Also restores mocks between AppTopbar tests. The update-pill test spies
on `useReleaseCheck` and pins `current` to a fixed version; module spies
outlive the test that made them, so every later test in the file was
silently running against that stub. The new dot tests failed on it while
passing in isolation, which is the visible symptom of a hazard that was
already there.
Verified in the running SPA: 13 checks covering the dot lighting on a
version change, clearing on visit and staying clear across a reload, the
page rendering the tail the dialog omits, and the no-notes-cached state.
Three defects, found by opening the page instead of reading the diff.
RATE LIMITING. The launch check was spending far more of the anonymous
60/hr-per-IP allowance than "once per session" implied, in two
independent ways.
The `sessionFetched` guard is a module-level binding, so it dies with the
page: the real cadence was one request per RELOAD, and a day of working
on the SPA is easily sixty. Freshness is now judged from the persisted
`checked_at` the cache was already writing and never reading, with a
6-hour TTL. `checkNow()` still ignores it, because the user asked.
Worse, the guard was set only once a response LANDED. Every consumer
mounting in the same tick -- topbar pill, Dashboard, Settings -- read it
as false and opened its own request, so a single load cost three units,
not one. It is now set on attempt, and concurrent callers share one
in-flight promise.
When GitHub does refuse us, the reset it hands back in X-RateLimit-Reset
is honoured rather than retried against, and persisted, so the reload
that follows a 403 does not immediately spend another request. The
previously cached release survives a refusal -- forgetting the version we
already knew because the quota ran out would be a second failure on top
of the first.
WHAT'S NEW WAS STRUCTURALLY DEAD. `hasUnseenRelease` needs a previously
recorded version, and the only writer was the card's own dismiss button,
which never renders until the card shows. A closed loop with no entry
point -- it could not have fired for anyone, ever. The running version is
now recorded on first sight, so the NEXT upgrade has a baseline. Tests
that seeded `seenVersion` by hand never exercised the path the app takes,
which is why they passed against a feature that could not run.
STYLING. Both cards styled themselves from scratch in `--wp-node` -- the
CANVAS node palette, teal -- which is the graph's colour language, not the
manager's. They now use the same Card/Button/Icon primitives and accent
purple as everything around them, and the what's-new list gets an
explicit `list-style` because the app reset clears it globally and the
entries were running together unmarked.
The star prompt also moves to the BOTTOM of the dashboard. Above the hero
it was the first thing on the page, louder than the product's own
welcome -- the layout of an ad rather than of an aside. The eligibility
rule already selects a returning user; it does not need the best seat.
Verified in the running SPA, not just in jsdom: 15 checks covering both
dismiss buttons persisting across reload, the snooze expiring, the
what's-new dismiss, four reloads making zero GitHub calls, and a stale
cache making exactly one.
Two Dashboard cards, both inline and dismissible. Neither blocks
anything and neither is a modal — the extension already raises an update
dialog, and a second one on the next SPA open is the same news twice.
WHAT'S NEW reuses the release body the update check already fetches, cut
at the modal marker, so it shows the same highlights-only slice for the
same reason. Silent on a fresh install: someone who has never recorded a
version has no "new" to hear about. It also only renders when the fetched
release matches the INSTALLED version — while an update is pending the
body describes changes the user does not have yet, and presenting that
as "what's new in your version" would be a lie.
THE STAR PROMPT is a favour, so it behaves like one. The obvious
triggers were all first-touch — "created N modules", "ran the starter",
"first test run" — and every one fires on someone still poking at the
thing: ten modules can be ten empty rows, and the starter bundle is by
definition the moment before you understand anything. Those measure
curiosity, not value.
So it needs two signals, both: five distinct calendar days with the
manager open (not sessions -- a reload is not a return; not consecutive
-- life happens), AND a library carrying real content. Either alone is a
false positive.
Existing users are credited on first run: without it, tracking starts at
zero for everyone and a three-month user waits another five days, which
is backwards. The credit is deliberately short of the threshold, so they
still have to come back -- being asked the instant you update reads as a
reward for updating.
"Maybe later" hides it for a fortnight then lets it return, because a
button that visibly does nothing is a broken button and "later" is not
"no". "Don't ask again" is permanent and survives upgrades. The star
count is not shown: social proof cuts both ways, and at a low number it
argues against starring.
25 tests on the eligibility rule, which is the whole feature -- fire
early and it is adware, never fire and it is dead code.
The dialog cuts at the modal marker, so it shows the headline and
highlights and then simply stops — a five-change release and an
eighty-change one look identical from inside it, which is the opposite
of what the cut was for.
`tailChangeCount` counts the bullets below the marker and the dialog
renders "+ N smaller changes" beneath the notes. Zero for releases
published before the marker existed, so nothing is claimed about them.
Verified against the real next.md: 20 counted, matching the 20 written
by hand in the <details> summary on the GitHub side. The template now
notes that the GitHub number is manual and the dialog's is computed, so
if they ever disagree the hand-written one is the wrong one.
The CSS this mirrors is `radial-gradient(120% 100% at 0% 0%, …)` — an
ellipse 120 percent of the WIDTH by 100 percent of the HEIGHT, anchored
top-left, so it falls off across the whole panel. I had applied a
`scale(1, h/w)` transform, which squashed it into a flat smear along the
top edge; on an 880x202 frame that reads as a tinted corner with three
quarters of the figure left flat.
Now `r=1` with `scale(1.2 1)`, which is the CSS geometry directly, and a
three-stop falloff so the tint carries further before it disappears.
Three things, all of them fidelity to the SPA figure rather than taste.
The frame lost its wash. PipelineDiagram paints
`radial-gradient(120% 100% at 0% 0%, node 6%, transparent 60%)` over
bg-1; dropping it left a flat slab. Reproduced as a radial gradient with
themed stops.
The connectors lost their fade. `.wp-doc-diagram__arrow-ln` is a
gradient that fades in and out at both ends, so a connector reads as
flow rather than a drawn border -- which is most of why these felt dead.
They are RECTS, not lines: a horizontal <line> has a zero-height
bounding box, so an objectBoundingBox gradient on it collapses and the
line vanishes, leaving an arrowhead pointing at nothing. Caught that in
the render, not in review.
And the loop diagram was topologically incomplete. WP_ContextLoop has a
`loop_config` side-output; WP_SeedList takes it as an optional input and
mirrors the loop's count, strategy and base seed from it. That link is
exactly WHY the two fan out in lockstep, and the old figure -- and my
first rebuild -- drew them as unrelated sources, leaving the caption's
claim unexplained.
The icon extractor rewrote `fill` attributes to `currentColor`. Almost
no PrimeIcon HAS a fill attribute -- of the ones these figures use, only
`sparkles` declares one -- so a rewrite-what-exists pass left every
other glyph at SVG's default black.
That is why the feeder pills looked right while every node icon came out
black: the feeders happened to use icons carrying fills.
Concrete fills are now stripped and the wrapping group carries
`fill="currentColor"`, so anything without its own fill inherits the
group colour. `fill="none"` is preserved -- on the icons that use it, it
marks the deliberately hollow part, and filling it would blob the glyph.
Verified rendered in both themes: WP nodes teal, external nodes muted,
feeder pills in their per-kind colours.
The two figures were hand-drawn SVG that had drifted from the app: flat
horizontal cards, approximated icon shapes, a violet accent the product
does not use, and — in the loop diagram — the assembled prompt running
straight into KSampler. It does not go there. Text is encoded first and
only conditioning reaches the sampler; seeds are the one thing that
arrives directly.
Both are now generated from the real component. PrimeIcons ships
`raw-svg/`, the same paths the webfont is built from, so the README
carries the actual glyphs rather than lookalikes, and every value is
lifted from PipelineDiagram.vue and theme.css instead of eyeballed:
teal `--wp-node` accent, `--wp-bg-2` cards at radius 10, vertical
icon/name/mono-subtitle layout, kind-coloured feeder pills, per-chip
accent borders, 9.5px uppercase connector labels.
A `prefers-color-scheme` block mirrors the SPA's light theme, so the
figures follow the reader's GitHub theme rather than sitting as a dark
slab on a light page. `pnpm docs:figures` regenerates them.
The SPA components are untouched — they already theme correctly.
Also: the release-notes tail moves into a <details>. On a release this
size it would otherwise double the page. The summary carries the count
so the reader knows what they are opening; the cost, noted in the
template, is that collapsed text is not reliably reachable by
find-in-page. The modal is unaffected — it already cuts above this.
The old body was a flat curated list followed by the per-commit
changelog inside a <details>. Two problems, both visible on 2.11.0.
The commit list restated the curated notes. Hidden types were already
filtered out, so what remained WAS the user-facing changes -- the same
content at lower quality, growing linearly with the release. Dropped in
favour of a compare link, which is one line and strictly more useful:
diffable, searchable, and the real archive is git anyway.
The curated list had no hierarchy, so "long values wrap in a text box"
sat at the same weight as a correctness fix, and length scaled with the
release. It is now:
Headline
### Highlights 4-5, capped
<!-- /modal -->
### Also in this release grouped one-liners
### Upgrade notes only when the reader must act
The cap is the mechanism -- it is what keeps a 6-commit release and an
80-commit release roughly the same height. next.md carries the
selection rules as comments so the next writer does not have to
re-derive them.
The modal now stops at the marker. It has a 320px scroll box and one
job -- answer "is this worth clicking Update now" -- and was rendering
the entire body into it, slicing a paragraph mid-sentence. Bodies with
no marker still render whole, so every published release is unaffected.
Also replaces the stale next.md, which still held the already-published
2.11.0 text and would have shipped again verbatim. It now describes the
81 unreleased changes on this branch: 5 highlights, 20 grouped
one-liners, 291 words to the modal against 686 for the page.
The cleaner treats a prompt as prose or as a comma-separated tag list.
That is right for tags and wrong for the few tokens that are ADDRESSES
rather than words: `embedding:name` and `<lora:name:1.0>` resolve to a
file, so one edited character changes what the sampler loads, or loads
nothing.
Two rules were provably destructive:
embedding:bad_prompt_ -> embedding:bad_prompt
embedding:badhandv4, embedding:badhandv5 -> embedding:badhandv4
`_` and `-` are in the stripped punctuation set, and `bad_prompt_` is a
real published shape. Versioned names sit far above the hardcoded 0.9
fuzzy threshold while naming different files. Both failures are silent:
ComfyUI resolves a missing embedding to nothing, and the dropped tag
only shows up in a generic "N removed" count.
engine/cleaner/atoms.py marks both forms -- LoRA included, since it has
the identical failure mode and excluding it would have been an
arbitrary line. Punctuation stripping skips atoms; fuzzy dedupe falls
back to exact comparison when either side is one.
This widens the cleaner's remit from "text" to "knows a little prompt
syntax", which the findings named as the cost. The alternative was a
rule that renames a file reference without saying so.
Narrow, and the narrowness is tested: ordinary tags still get trimmed,
ordinary near-duplicates still merge, exact repeats of an embedding
still collapse, and text mode still trims a leading edge -- it only
holds back the trailing trim when the prompt ENDS in an atom.
reactiveFromGraph installs a 400ms poll per call site, and a single
WP_Context node installs TEN of them. Every walk re-read the node's
wp_modules widget and re-parsed it from scratch -- on a real workflow
that string is ~294 KB, so the parse cost MORE than the traversal it
fed (JSON.parse 4.64 ms/call against 4.02 ms for the whole of
collectUpstreamProducers). Ten pollers parsed the identical string ten
times per cycle; five nodes made it ~21% of a core.
Cache keyed on the raw string, so it self-invalidates when the widget
is edited, and bounded at 24 entries because every keystroke in an
editor mints a new 294 KB key.
The findings flagged the hazard: callers now share one object instead
of each getting a private copy. That is why this lives in graph.ts as a
module-private helper rather than inside parseWidgetJson, whose other
callers (ContextWidget) legitimately mutate what they get back. The
read-only contract is enforced, not assumed -- graph.parse-cache.test.ts
puts the cache in freeze mode and runs every walker, so a write throws
instead of silently corrupting the next reader.
Measured on the same 5 x 18 x 133 graph as before:
collectUpstreamProducers 3.67 ms -> 0.06 ms
collectUpstreamVariables 9.39 ms -> 1.99 ms
collectUpstreamWildcardUuids 3.69 ms -> 0.01 ms
per cycle, 5 nodes 83.79 ms -> 10.33 ms
~21% core -> ~2.6%
Collapsing the ten polls per node into one shared walk stays
un-attempted; this may make it unnecessary.
Every commit ran the whole CI suite -- lint, typecheck, the full 4000-test
vitest run, a build, the size gate, ruff and the full pytest suite --
regardless of what the commit touched. Measured on this machine that is
about 4.5 minutes, and since the habit was to run the same gates by hand
first, the real cost per commit was closer to nine.
The hook now looks at the staged paths and runs only the halves that can
be affected, with vitest scoped to the changed sources via `vitest
related` (30s against 150s; it still walks the import graph, so a shared
module pulls in its dependents). WP_FULL=1 forces everything.
This is only safe because CI now runs on every branch push rather than
just main -- a feature branch previously had no remote verification at
all until a PR existed.
Three corrections, all of them to my own earlier attempt.
Option chips: these were hand-rolled spans that only MIRRORED RefChip's
styling, so they were the one surface in the editor with no hover card.
The previous commit made that worse by bolting on plain `title`
tooltips instead of using the component we already have. Now they ARE
RefChips, so they get the same card as every other chip. Two test
expectations move to RefChip's conventions, which is the point of the
change: `@` is prefixed only once a ref resolves, and the filter
expression lives in the card rather than a native title.
Derivations: rule-summary chips said "binds at runtime" for variables
with an obvious producer. RuleValueChips rendered RichTextPreview with
only value/uuid-to-name/surface, and RichTextPreview had no producer
props at all, so every var chip below it fell back. Producers now flow
RulesSection -> RuleValueChips -> RichTextPreview -> RefChip, and the
same chain is wired for wildcard option chips
(ModuleEditModal -> WildcardInstanceModal -> PoolSection -> OptionRow).
Combine already worked, which is why the symptom looked
derivation-specific.
Type-to-filter hint: shipped behind a six-option threshold, which hid
it on exactly the menus being checked -- a three-option dropdown showed
nothing. Threshold is now two, so it appears wherever there is anything
to filter.
Two discoverability fixes.
Chips inside a wildcard option had no hover text in the ordinary case.
A nested-ref chip only carried a `title` when it was unresolved or
filtered, and `$var` chips carried none at all -- so a resolved ref,
which is the common case, gave no way to see which library entry it
points at. The chip label is abbreviated to `@name` with no uuid, so
there was nothing else to go on either. Ref chips now always describe
themselves (name, uuid, and any filter), and var chips say what they
are.
Every Select menu has always filtered as you type, but the only sign of
it was the "Filtering:" line, which appears AFTER the user has already
guessed the feature exists -- as a user put it in Discord, "perhaps it
should be telegraphed better". The menu now says "Type to filter" up
front, on lists of six or more where filtering is worth reaching for,
and gives way to the live filter line on the first keystroke. Dropdowns
that already carry their own search field are separate components and
are untouched.
The Nodes 2.0 toggle does not reload the page, so every widget alive at
that moment was built against the other renderer. The damaging piece of
staleness is the autosize bookkeeping: pushSize compares the node's
current height against the last height WE set and treats a mismatch as
"the user dragged this, leave it alone". A renderer flip changes node
height without going through us, so from that instant every widget
decides the user owns its height and stops auto-collapsing.
That is the same trigger behind the Debug node's jump, and it explains
why WP_VarToInt/Float stay tall after their dropdown closes but only
following a LIVE switch -- after a page refresh they are fine.
One watcher, driven by the DOM churn the flip itself causes, tells every
widget to forget its baseline and re-fit. It is not specific to the two
nodes reported: any widget that autosizes was exposed.
Not reproduced end-to-end: the var picker only grows enough to show the
bug when it has upstream variables to list, and an unwired node's menu
is empty. The mechanism is covered by unit tests instead -- a flip
triggers a re-fit, a non-flip does not -- and the browser checks confirm
no regression in either renderer.
Two small ones.
The modal footers rendered a hardcoded `⌘↵`, which reads as a Mac-only
binding to the overwhelming majority of ComfyUI users. The handler has
always been `(ev.ctrlKey || ev.metaKey) && Enter`, so only the LABEL was
wrong -- it now says `Ctrl+↵` off Apple platforms. Detection prefers the
UA-CH platform hint and falls back to the user-agent string, avoiding
the deprecated navigator.platform.
The bundle header's child-count summary ("9 mods") was 10px in
--wp-text-dim, which resolves to #666 on the dark theme and sat right at
the edge of legibility against the bundle frame tint -- the one thing
telling you how big a collapsed bundle is. Now the muted token at 11px
with a faint pill, so it reads as a value rather than a watermark.
The root-level shield only sees keys TARGETED inside the overlay. Click
the button that opens a modal and focus stays on that button, which is
outside the overlay, so keystrokes go straight from it to window and the
shield never runs. Measured on the Blocklist modal: pressing a, a, r
with the modal open put ["a","a","r"] on window.
Two additions:
- focus the overlay when it opens, unless something inside already has
focus (an autofocused field must keep it);
- guard at the document for keys targeted outside the open modal, since
a modal owns the keyboard while it is up. Document bubble runs before
window, where ComfyUI's keybindHandler lives.
Escape still passes through, so close handlers keep working.
Verified in a browser, Blocklist modal open:
before focus BUTTON (the trigger), keys to window ["a","a","r"]
after focus moves into the overlay, keys to window []
typing "abc" still lands in the textarea, nothing leaks
Pressing `r` inside an edit modal ran ComfyUI's Refresh Node Definitions
and froze the page.
ComfyUI binds `useEventListener(window, 'keydown', keybindHandler)`, and
the handler only bails for text-editing targets:
const target = event.composedPath()[0]
if (keyCombo.isReservedByTextInput &&
(target.tagName === 'TEXTAREA' || target.tagName === 'INPUT' ||
target.contentEditable === 'true' || ...)) return
A plain letter pressed while focus sits on a button or a div inside a
modal is not reserved by text input, so it runs the global keybinding.
Its other guard -- skip global keybindings while a dialog is open -- keys
off ComfyUI's OWN dialog stack, which our modals never enter.
useModalKeyShield binds keydown/keyup to the modal ROOT in bubble phase.
Everything inside the modal has already had its turn by then, so inner
handlers, input defaults and IME are untouched; the event simply stops
before it can climb to window. stopPropagation only -- never
preventDefault -- so typing still works.
The corollary is that a modal's own key handling can no longer live on
window: a window listener sits ABOVE the shield and would never see keys
pressed inside its own modal. ModalShell now re-emits them, and the two
consumers that had window listeners are moved onto it:
- ModuleEditModal (Ctrl+Enter to save)
- BundlePickerModal (arrow/Enter/"/" navigation)
ModalShell keeps a window listener for Escape only, which covers the
case where focus is OUTSIDE an open modal.
ModulePickerModal already used a capture-phase window listener, which
runs before the shield, so it is unaffected.
Verified in a browser: keys pressed inside a ModalShell modal no longer
reach window, and Escape still closes it.
Switching the renderer from the menu does not reload the page, so a
widget built under legacy never ran any construction-time isVueNodes()
branch, and the fill observer's bounded retry (~10s of frames, looking
for a node element that does not exist yet in legacy) had long since
given up. Toggling with content on screen therefore left the layout
unapplied: measured, the node jumped from 380 to 1200 and could no
longer be resized. Reproducing it needed a wait past the retry budget,
which is why the earlier reload-based test showed it passing.
Two changes:
- Apply the out-of-flow layout at construction, in BOTH renderers, and
stop stripping it in the legacy branch. The push needs only one frame,
so there must be no window at all. Legacy is indifferent -- it gives
the host a definite box either way, and its numbers are unchanged
(host 354u, scroller engaged, 500x240 floor, wheel scrolls 0 -> 300).
- Replace the bounded retry with a registry driven by one document-level
observer, so a node element that appears minutes later is still
picked up.
Verified: toggling live after the old budget would have expired now
keeps size at 380, the scroller engaged, and manual resize working.
Two follow-ups to 27685706, which fixed the Debug node inflating but by
pinning the host to a pixel height computed from node.size.
1. The pin was the wrong lever. The node element's height is
authoritative, so the correction term sat at roughly zero: the host
never grew with the node and drifted a couple of pixels smaller on
every resize. The box stopped tracking the node and shrank each time
it was dragged.
The real cause is narrower than "the percentage height does not
resolve". Every ancestor between us and the node DOES have a definite
height tracking node.size -- measured 238 / 638 / 838 as the node
went 330 / 730 / 930. What breaks is that we are a flex item, and a
flex item defaults to min-height: auto, which refuses to shrink below
its content. The payload grew our box, which pushed the chain, which
the layout store wrote back into node.size.
Three parts, each needed:
- min-height on the host so it can shrink below content. Fixed, not
content-derived: the host clamps a resize with
measureMinContentHeight(), which MEASURES our content, and with the
content out of flow that measured zero and took the floor with it
(dragged to 62u where legacy stops at 240).
- content out of flow. Our own min-height is not sufficient because
EVERY ancestor is also min-height: auto, so the push propagates
past us -- measured, the node still inflated 300 -> 870.
- both applied at widget construction, not on a deferred sync: Vue
paints content before any observer of ours runs, and one frame of
in-flow content is enough for the store to record an inflated size
that then sticks across a renderer switch.
2. The wheel zoomed the canvas instead of scrolling our widgets. The
canvas yields a wheel only to a widget that declares
data-capture-wheel="true" AND currently holds focus; a read-only
viewer never qualifies. A bubble-phase stopPropagation on our own
element does not reach that decision either. Measured over the Debug
scroller:
legacy scrollTop 0 -> 300 scale 0.900 -> 0.900
Nodes 2.0 scrollTop 0 -> 0 scale 0.900 -> 0.818
Absorb it at window capture, which runs before every other listener,
using stopPropagation alone so the browser still performs the native
scroll. Ctrl+wheel is left to the canvas: that is pinch zoom. Applied
to every widget host, not just the Debug viewer.
Verified in a real browser, both renderers:
host tracks the node 238 / 638 / 838 for node 330 / 730 / 930
payload does not push size[1] holds at 400 for 3, 20 and 60 vars
scroller engages pre 289/1089
wheel scrollTop 0 -> 300, scale unchanged
renderer switch size stays 380, no jump to content height
floors Nodes 2.0 390x262, legacy 500x240
Legacy numbers are identical to before the change.
fillHost means the user owns the node's height and the widget scrolls
whatever overflows. That rests on `height: 100%` resolving -- and a
percentage height against an INDEFINITE container computes to `auto`.
Legacy gives the host a definite box so it resolves. Nodes 2.0 lays
nodes out from content, so it does not: the flex column sizes to
content, .wp-dbg-pre (flex: 1 1 0%; min-height: 0) is handed its full
content height instead of being compressed, overflow: auto never
engages, and the node inflates to the whole payload -- which the layout
store then syncs back into node.size.
Measured with node.size[1] pinned at 400:
payload legacy host / pre Nodes 2.0 host / pre
3 vars 354u 305/305 338u 289/289
20 vars 354u 305/429 scrolls 477u 429/429 never scrolls
60 vars 354u 305/1089 scrolls 1138u 1089/1089 never scrolls
One mechanism, three reported symptoms: the dead scrollbar, the node
that cannot be dragged shorter, and the absurdly tall node.
Pinning a pixel height alone is NOT enough. The Nodes 2.0 parent is
.flex.flex-col.*:flex-1, and that `*:flex-1` hits every child including
us; with flex-basis 0% and flex-grow 1 the main-axis size comes from
flexing and an explicit height is ignored. Measured: host pinned to
308px still rendered 1024px. So opt out of flexing too.
Height comes from node.size[1], which is authoritative in both
renderers, via an error-correcting step rather than a modelled chrome
constant -- compared against size[1] + header, because the host's own
sync notes that layout size excludes the title.
Width: legacy gets its floor free from computeSize, which Nodes 2.0
never calls, so the node could be squeezed to MIN_NODE_WIDTH (225)
against a widget declaring 494. Its resize interaction reads the floor
from the node element's inline min-width, so publish ours there --
writing node.size[0] does not work, the layout store owns the rendered
size and syncs one-way.
After, Nodes 2.0 matches legacy: size[1] holds at 400 for every payload,
the pre scrolls (283/1089), and dragging shrinks to a 390x348 floor
instead of 225.
Only WP_Debug sets fillHost, so nothing else is affected.
Four defects in the Vue-renderer wire merge, all from the same place:
the merge is DOM state, and it was bound to one element at one instant.
1. Merged rows printed their labels too. They are zero-height and
stacked on the kept row, so "input_1"/"input_2"/"input_3" piled on
top of the unified "inputs xN" and rendered as a smear. They keep the
label override -- it has to be ready the moment they expand -- so
suppress only their generated text.
2. No clearance under the merged pin. Zeroing the merged rows reclaimed
all their vertical space, leaving the incoming wires running into the
top edge of the widget body. Reserve some back on the last merged
row: they share a y, so only its bottom margin moves what follows.
3. Switching renderers while collapsed came back expanded. At attach
time the node's element usually does not exist yet -- the workflow is
restored before Vue mounts nodes -- so the one-shot lookup bailed and
nothing was left watching.
4. Focusing a collapsed node expanded its wires while the button still
read "collapsed". Vue REPLACES the node element on re-render, so the
per-element observer was watching a detached tree.
3 and 4 are both fixed by registering nodes and re-applying from a
single observer on a stable root. childList only: our own writes are
class and style attributes, which that never sees, so there is no
feedback loop.
Labels also now publish in BOTH states, not just while collapsed. Vue
renders slot names from its own snapshot and never sees a slot.label
write, which breaks the restore too: a legacy collapse serializes the
placeholders into the workflow, so reloading under Vue showed "inputs
xN" and " " forever, even expanded.
Verified in a real browser. Legacy collapse -> switch renderer -> reload:
collapsed 4 pins at 1 distinct y, label "inputs x3", 12px clearance
expanded 4 pins at 4 distinct y, labels input_0..input_3 restored
focus stays merged, 1 distinct y
The wire merge was a canvas paint-time trick: override getInputPos and
every matched pin reports the first pin's position. Nodes 2.0 paints no
canvas for slots. It renders one .lg-slot--input row per node.inputs
entry and feeds those elements' measured rects to the layout store,
which is what the link renderer draws to, so the override moves nothing
there.
Measured with four wires merged: every pin reported the same
getInputPos while the DOM dots stayed 18px apart. Half the mechanism
did work -- mutating slot.label writes to the data model -- which is why
the node read "inputs xN" while the wires stayed fanned out.
The host has this feature internally: NodeSlots.vue takes a `unified`
prop that grid-stacks every dot into one cell. It is wired only to
whole-node collapse, with no per-node opt-in, so reproduce the effect on
the rows we own. Zero the merged rows' height so they share one centre
line, and pull the first up half a row to land on the kept pin. Height
rather than display: useSlotElementTracking discards any slot measuring
zero area, so hiding a row would drop its link endpoint instead of
moving it.
The label needs the same treatment for the same reason -- Vue renders
slot names from its own VueNodeData snapshot and never sees the
slot.label write (measured: model "inputs x4", rendered "input_0") --
so the collapsed label is published as a custom property and printed
from CSS.
Verified in a real browser, both renderers. Nodes 2.0, four wires:
expanded 5 dynamic pins at 5 distinct y [270,288,306,324,342]
collapsed 5 dynamic pins at 1 distinct y [270] upstream stays 252
expanded 5 dynamic pins at 5 distinct y (round trip restores)
Also guard CSS.escape, which is absent in some environments.
The focus-flash border mapped graph coords to screen itself
(canvasRect + (pos + ds.offset) * ds.scale, plus a TITLE_PAD constant).
That derives the box from node.size, and under ComfyUI's Nodes 2.0
renderer node.size is a hint rather than a fact: the node is laid out
from its DOM content and never clamped back. A node declaring 400 wide
measured 490 graph units, so at 0.9 zoom the border came out 81px too
narrow and cut through the node.
Measure instead of recompute. Nodes 2.0 gives each node a
[data-node-id] element whose rect is the box, title bar included, which
also retires the TITLE_PAD estimate. The legacy renderer paints nodes on
the canvas and has no such element, so it keeps the transform maths --
which is correct there: both renderers agreed on position to the pixel,
only the width was wrong.
Verified through the real path (Assembler with an unresolved $var ->
warning toast -> Focus click) in both renderers:
Nodes 2.0 overlay 584,320 432x291 node 584,320 432x291 (exact)
legacy overlay 584,325 432x247 (transform-maths fallback)
Two reproducible probes backing the P3 investigations. Neither changes
behaviour; both exist so the findings can be re-run rather than re-argued.
`src/extension/__perf__/poll-cost.test.ts` times the graph walkers on a graph
shaped like the reported workflow — 5 Context nodes, 18 modules each, 133
options. It measures rather than asserts: the thresholds are loose so a busy
machine cannot turn it red, and the console output is the deliverable.
It shows the 400ms interval is not the expensive part. A Context node installs
TEN `reactiveFromGraph` polls, each re-reading the node's `wp_modules` widget
through `parseWidgetJson`, which is a bare `JSON.parse` with no memoisation.
That JSON is 294 KB per node, and parsing it costs slightly MORE than the
traversal it feeds — so the same string is parsed ten times per node per cycle
for nothing. Three of the ten polls across five nodes come to 84 ms every
400 ms, about a fifth of a core.
`tests/engine/cleaner/test_embedding_roundtrip.py` pins what the Prompt Cleaner
does to `embedding:` syntax. The engine itself never touches it — one unrelated
comment is the only hit in `engine/` — so the cleaner is the whole hazard, and
two of its rules damage embeddings:
- Punctuation stripping trims `_` and `-` from a tag's trailing edge, so
`embedding:bad_prompt_` becomes `embedding:bad_prompt`. ComfyUI resolves a
missing embedding to nothing, so the prompt quietly stops working.
- Fuzzy dedupe at its hardcoded 0.9 threshold treats `badhandv4` and
`badhandv5` as the same tag and drops one. Different files, different
training, no warning beyond the generic removed-count.
Those two tests assert the CURRENT behaviour and say so in their names, because
whether to teach the cleaner about prompt syntax is a design decision — and the
same argument would apply to LoRA tags, which have the same shape.
Written up in full, with the Nodes 2.0 and capability-survey findings, at
docs/investigations/p3-findings.md (untracked, per the docs allowlist).
The previous attempt capped the menu's own height at `100vh - 24px`, which
cannot work: whether a menu fits depends entirely on where its top edge landed.
A 400px menu opened at y=700 overflows however small that cap is, because the
cap never knew about the 700. The height is now measured from the trigger to
the edge of the window.
That alone made it fill the whole page on a tall window, which is worse than
the overflow it fixed — one menu burying the page behind it, and a dozen tags
spread over 800px are harder to scan, not easier. So the viewport is the LIMIT
and 340px is the target: roughly a dozen rows plus the search box, shrinking
only when there is less room than that, with a 140px floor below which it
scrolls instead.
The filter menu also flips above its trigger when the room below is genuinely
worse, which the per-option picker already did. In practice the filter never
flips — its button lives in a sticky header near the top — but the row-level
picker does, and both now stay inside the window.
Measured at 1000 / 760 / 620 / 500px viewport heights, on both hosts: 340px
where there is room, 294px at 500px tall, and the row picker flipping to
12–312px at 620px tall. The inner list carries no cap of its own any more — it
is the part that gives, and a fixed 240px there fought the menu's own bound and
won.
**The tag menu lost its axis colours** when the picker became a shared
component: I rewrote its stylesheet instead of porting it, and the rules
consuming `--chip-hue` went with it. The hue is what makes the menu read as the
same colour clusters as the pills and chips everywhere else; a flat grey list
loses the only cue saying which axis a tag belongs to. Ported properly this
time.
**It was cut off at the bottom** whenever the list behind it was short — an
empty filter result leaves almost no page to sit on. Capped to the viewport,
with `min-height: 0` on the inner list so it shrinks and scrolls instead of
pushing the menu past the edge.
**It closed the moment the filter emptied the list.** Any layout change fired a
scroll, and the handler that keeps the teleported menu glued to its trigger
treated that as a reason to dismiss. It re-measures now, and only closes once
the trigger has actually left the viewport.
**Select's menu could not be scrolled by its scrollbar** — reported on the test
runner, present on every Select in the app. The menu is teleported to <body>,
so it is not inside the trigger's wrapper, and the outside-click guard checked
only that wrapper: a mousedown on the menu's own scrollbar counted as an
outside click and dismissed it. The wheel worked, which is why it read as "the
scrollbar is dead" rather than "the menu closes". The guard now excludes the
menu, as its comment always claimed it did.
Audited the rest, since this class of bug is easy to repeat: every other
teleported surface with an outside-click dismissal — IconPicker, ContextMenu,
the sub-category picker — already excludes its own panel. Select was the only
one that did not.
**Fixed Values had the grip before the checkbox** in the body and after it in
the header, so the two disagreed. Body now matches.
**Select-all skipped the null option.** `selectableOptions` still filtered it
out from when it could not be selected at all; selection drives moves, weight
and delete, all of which it takes part in. Tag actions still skip it — the
engine refuses tags there.
**Bulk add appended past the starter blanks.** A new wildcard or fixed-values
module opens with empty rows so the table is not a void; a first bulk add left
them sitting above everything just added, and they fail validation on save (an
option's value must be a non-empty string). An untouched blank is scaffolding
and is consumed by the incoming batch. One the user tagged or re-weighted is
NOT untouched — they were working on it — so only a fully default row
qualifies.
Three from testing the merged toolbar.
**The search box was a quarter of the width it should be.** Two nested flex
competitions, both lost the same way. Card's header puts a `.wp-spacer`
(`flex: 1`) between the title and the actions slot, and the filter block had
`flex: 1` too, so the two split the free space evenly; a far larger grow factor
gives the block effectively all of it. Inside the block a second `.wp-spacer`
was right-aligning the count and taking half of what was left — it is gone, and
the count now sits beside the tag button it describes. Measured 267px → 523px
of an 1122px header.
**The tag menu closed the moment you scrolled it.** The scroll listener that
keeps the teleported menu glued to its trigger fired for scrolls INSIDE the
menu too, so reaching for the wheel or the scrollbar dismissed it before you
could read past the first axis. Scrolls originating within a teleported picker
are now ignored: that is the user reading its own list. A scroll of the page
underneath still dismisses it, since the trigger has moved.
**Bulk edit was giving the null option tags.** It has no chips of its own — the
row renders a dash — so the tags went in invisibly, and the engine would have
refused the save: "null option must have no sub_categories"
(wildcard_handler.py). Its participation is governed solely by `exclude_null`,
so a tag on it could not affect anything even if it were allowed. Apply and
Remove now skip it. Set weight and Delete still include it, because it has a
weight and can be deleted — and it stays selectable, since selection also
drives the moves it took part in as of the previous commit.
So: no, null should not carry tags. The engine has always said so; the UI was
quietly disagreeing.
Five follow-ups from testing the options filter.
**The tag menu is now one component.** The filter had grown its own dropdown
while the per-option picker had another — same job, two implementations, and
they would have drifted within a release. `TagPickerMenu.vue` is the picker,
extracted: teleported past the `overflow: auto` scrollers that clipped it,
search pinned above a scrolling list, axis headings, checkboxes. Both callers
use it.
**It closes when you click away.** The filter menu was teleported to <body> but
never registered with `closeAllMenus`, so it stayed open until its own button
was clicked again. It joins the outside-click and Escape dismissal the
per-option picker already had, and closes on scroll rather than hanging in
space once its trigger has moved.
**One row, not two.** Bulk edit / Add null / Add option sat on one line and the
filter on another, which made the header taller than the first option in the
list. They all act on the same table; they belong together. The filter takes
the flexible width, the buttons keep their intrinsic size.
**The null option is a row like any other.** It could not be selected in bulk
edit and could not be reordered, because `hoistNullFirst` re-pinned it to index
0 on every save and any move would have silently undone itself. That pin was
never needed: the engine locates the null option by the `is_null` FLAG and
never by position — "the flag is the source of truth", wildcard_handler.py, and
`resolve` filters with `[o for o in options if not o.get("is_null")]`. The
function is gone, and the row now has a checkbox and a grip.
**Fixed Values gets the filter and the reorder.** No tag menu — those rows
carry no tags — so the text box searches BOTH halves, the binding and the
content, because you look for either and matching one would send you back to
scrolling half the time. Grip column, Alt+↑/↓, and Top / Bottom on the
selection toolbar, with drag disabled under a filter for the same reason as in
the options list.
The per-option picker's test hooks changed shape with the extraction —
`opt-tag-{id}-toggle-{tag}` rather than `opt-tag-toggle-{id}-{tag}` — since the
component namespaces every hook uniformly off one prefix.
A wildcard here carries 133 options. Until now the only way to reach one was
to scroll and read, and the only way to order them was to have added them in
the right sequence.
**Filter.** Text over the value plus a tag multi-select, pinned in the sticky
subheader so it survives the scroll. Text and tags AND together, and multiple
tags AND with each other — adding a second constraint should narrow the result,
and OR would widen it, which reads as the control being broken. The count sits
idle ("133 options") until a filter is on, because "133 of 133" reports a
success nobody asked for. The empty state says all 133 are still there: an
empty table in a list you can also delete rows from is an alarming thing to be
shown.
Rows keep their ORIGINAL index through the filter. Every row action addresses
its option by position — `removeOption(i)`, the `wc-opt-row-${i}` hooks — so
renumbering them under a filter would delete the wrong row.
**Folded tags get promoted.** A row shows four tags and folds the rest behind
`+N`. Filter by a tag sitting in that remainder and the row appeared with no
visible reason for being there, the evidence hidden behind the very pill saying
there was more. Matched tags are now promoted into the visible slots — tags are
a set, so their order carries no meaning and promoting one is free. Auto-
expanding instead would reflow every matching row at once, a lot of movement
for a small clarification. When matches remain folded even so, the pill itself
is tinted and says why.
**Reorder,** three ways, because no single one covers the range:
- A grip in its own column, hover-revealed. The only pointer affordance the
value cell's contenteditable does not poison — a press there is a text
selection, and the two gestures are indistinguishable at mousedown.
- Alt+↑/↓ on the focused grip. The only one that stays usable at 133 rows,
where a drag becomes an auto-scroll fight.
- Bulk edit ▸ Top / Bottom / Move here. Select, then move as a block.
**Drag is disabled while filtered; the bulk moves are not.** Dropping row 3
above row 47 says nothing about the 43 hidden rows between them, so there is no
honest position to compute. The bulk moves have no such problem because their
destination is absolute — "top" means the top of the whole list, "here" means
beside one specific visible row. So search ▸ tick ▸ move is exactly the
workflow that stays well defined under a filter.
Two behaviours worth stating, both asserted:
- A scattered selection collapses into one contiguous block in the relative
order it already had. There is no other coherent answer, but it surprises the
first time, so the result is reported rather than discovered.
- The null option never moves and is never a landing point. `hoistNullFirst`
re-pins it to index 0 on every save, so any move it joined would silently
undo itself.
Ordering and set logic live in `utils/option-list-ops.ts`, out of the 2.4k-line
editor and directly assertable.
Two reported losses of work.
**Bulk add was easy to throw away.** Users reach for the PAGE's Save and Cancel
instead of the panel's own "Add options" / Cancel — the page pair is larger and
in the place muscle memory expects — and the typed batch went with it. Two
guards, and deliberately no new dialog for the common case:
- Save is greyed while the panel is open, so the only Save-shaped control that
responds is the panel's own commit. The button carries a tooltip saying why;
a greyed control with no stated reason reads as a broken one, and the reason
is exactly what the user needs in order to clear it.
- Un-added text now counts as unsaved work, so the route guard that already
covers Cancel, the back link and every other navigation picks it up for free.
Only the wording changes: "Discard un-added options?" rather than the generic
unsaved-changes copy.
Both editors that have a bulk-add panel — wildcard options and fixed values.
Constraint and derivation have bulk EDIT but no bulk add, so nothing to guard.
**Empty tag groups vanished on save.** A "+ Group" box created and not yet
filled was dropped, which reads as the editor deleting work the user did on
purpose. Dropping stays the default, because it is also what clears up boxes
made by accident, but the choice is now theirs: Settings › Editing › Keep empty
tag groups.
Stored as a preference rather than a payload field. An empty axis is already
representable as `{axis: []}`, a shape the engine's validator accepts — the
loop over members simply does not run — so keeping one needs no new field, no
validator, no migrator and no schema bump. What varies per user is the
DECISION; the RESULT is recorded in the payload like any other edit.
Note on the ref declaration: the guard's predicate runs during setup, so
`bulkPending` is declared above it rather than beside the panel state it
belongs with. Putting it in the obvious place threw "Cannot access
'bulkPending' before initialization" on every editor mount.
`.wp-refchip` carried `user-select: none`, which excludes an element from
selection RENDERING. Ctrl+A, or dragging across a value, highlighted the text
on either side and left the chip looking untouched — so the selection appeared
to stop at the chip even though it never did. Confirmed in Firefox 153:
`Selection.containsNode` reported the chip inside the selection the whole
time, and the selected string always contained its label. Only the paint was
missing, which made a correct selection look like a broken one.
Chips are atomic for EDITING because they are `contenteditable="false"`, not
because of `user-select`, so dropping it costs nothing there. Added an explicit
`::selection` colour as well: a chip carries its own tint, and the default
highlight washed it out.
Re-measured the whole interaction matrix afterwards, since making chips
selectable could plausibly change how edits fall across them — Ctrl+A followed
by Backspace, Delete, Shift+Delete, cut, paste and typing; undo, redo, bold,
italic, underline, Enter, double- and triple-click, Home/End deletes and
Ctrl+Backspace; each with and without a chip in the field. 40 cases, all
intact, no formatting elements injected, no page errors, and clicking a chip
still opens its filter picker.
The rule is asserted against the stylesheet source rather than a computed
style: it lives in a scoped <style> block, which jsdom does not apply, so a
computed-style check would have passed no matter what the rule said.
Reported: cutting an option's text and pasting it into another leaves the
field broken, after which Cancel does nothing and sometimes links stop working
too. Reproduced in Firefox 153 and measured.
A Ctrl+A selection is anchored on the HOST element, not inside a text span. Cut
was the one clipboard verb with no handler, so the browser performed the
deletion itself — and that deletion took the `wp-rt__text` spans with it, the
very elements Vue's vnodes point at. Measured directly after the cut: zero atom
spans left, one child node, the value a stray newline. The field still accepted
typing, but nothing chipped and nothing coloured, because there was no atom
span left to hold any of it, and the vdom now referenced detached nodes. That
is the state a later patch throws `insertBefore: Child to insert before is not
a child of this node` from — the DOMException reported separately.
Cut now runs through `applyAtoms` exactly as paste already did, so the
structure stays Vue's.
Copy was quietly lossy in the same way. A ref chip's DOM text is its display
label, so the browser's own copy turned `red @{955bb6fa} tail` into `red tail`
and the ref vanished on paste — measured, every time. Copy now puts the SOURCE
text on the clipboard, and a chip survives the round trip.
Third, a general repair: any edit made against a host-anchored selection can
delete the atom spans, not merely their text — Ctrl+A then typing a character
did it too. `applyAtoms` already knows how to recover (it swaps the host
element when the DOM has gone stale) but nothing reached it from the typing
path, which deliberately avoids re-applying atoms to keep the caret steady.
`onHostInput` now re-applies when, and only when, the structure is actually
gone.
Measured across the full matrix — Ctrl+A followed by Backspace, Delete, cut,
typing, and paste, each with and without a chip in the field. Before: two of
ten cases left the field with no atom spans and one silently dropped a chip.
After: ten of ten intact, and the chip round-trips.
Not a bug, for the record: Cancel refusing to navigate while there are unsaved
edits is the route guard working — it raises "Discard unsaved changes?" and
waits. It only reads as a dead button when the render loop has already thrown,
which is what the cut corruption above led to.
Two user-reported Firefox bugs, both in the same rescue path. The host parks
the selection on ITSELF rather than inside a `wp-rt__text` span whenever the
caret is at the very start of the field — pressing Home, or clicking before
the first character. Firefox does this most readily, which is why both reports
came from there. `onHostBeforeInput` redirects such a caret into a span before
the browser inserts, and it was redirecting to the wrong place twice over.
**Typing at the start went to the end.** With no chip adjacent, the fallback
picked the LAST span and put the caret at the END of its text. Typing `{` in
front of `skirt` produced `skirt{`. On the host root the offset is a CHILD
INDEX, so it already says where the caret is; the fallback now scans forward
from it for a span and lands at that span's START, falling back to the end of
the preceding span only when there is nothing after.
**Typing over a selection did not replace it.** The rescue ran for ranges as
well as carets and unconditionally collapsed the selection, so the browser
never deleted what was selected — select-all then typing one letter over
`yellow` left `yellowy` instead of `y`. A range is exactly the case the
browser already handles correctly, so the rescue now returns early for one.
This is the mangling behind the `yyellow` in the first report's video.
Verified against Firefox 153.0 — the reported version — driving the real
browser: `skirt{` → `{skirt`, `yellowy` → `y`. Regression tests go through the
DOM Selection API rather than component internals, since the bugs live in the
interaction between the browser's own insertion and our redirect; both were
confirmed to fail against the previous code before being kept.
Not reproduced, and NOT fixed here: the report also mentions Ctrl+A + Backspace
failing to clear the field and a paste doing nothing. Both work in Firefox 153
before and after this change. An early test of mine appeared to show the paste
failing, but that was the synthetic ClipboardEvent delivering no data — a real
Ctrl+C/Ctrl+V round trip replaces the selection correctly. The `yyellow` state
in the video is explained by the selection bug above, so these may well be the
same defect seen from the other side; if it recurs after this lands, it needs a
fresh repro.
`overrides N` was wrong in both directions.
**Inflated.** Several call sites fan out — a derivation writes once per branch,
a fixed_values once per row — because which branch fires is not knowable
statically and every reachable `target_var` has to appear in the var list.
Counting each of those as an override meant a rule with twelve branches all
targeting `$env_fx` reported "overrides 11", when at most ONE branch fires.
Worse, it reported it when nothing upstream wrote `$env_fx` at all: the module
that CREATES a variable was described as overriding eleven writes that never
existed.
`shadowed` now counts distinct PRODUCERS. Identity is passed in by the caller
rather than derived from the producer record, because `moduleId` is the library
uuid — the same module dropped into two Context nodes shares it while being two
genuinely competing writers. Callers key on the node plus the module's
per-instance `_uid`. Injector rows and loop vars have no module and fall back to
the node plus kind, so two rows of one injector binding the same name read as a
single writer; that is the honest summary, since the injector as a whole is what
binds the name.
**Lost.** The sibling producer map added for same-node attribution counted only
siblings and started from zero, and the merge was a plain object spread — which
replaced the upstream entry outright, taking its count with it. With `$outfit`
written by an upstream wildcard, rewritten by an upstream derivation, then
rewritten again by a module in this node, the row showed no badge at all. A
sibling that displaces an upstream writer has overridden that writer plus
everything it had already overridden, and the merge now says so.
Also: `WP_DEBUG_MAPS=1 pnpm build:extension` links the sourcemaps. They are
built either way, but `sourcemap: "hidden"` writes no `sourceMappingURL`
comment, so browsers never load them and every canvas stack trace arrives as
frame after frame of minified Vue runtime naming no component of ours. Off by
default — the comment ships to every install and the maps are large.
The node-vs-library marker landed on the ref chip and the filter header, but
not on the suggestion rows — which is the one place it is actually load-bearing.
By the time the chip carries it you have already chosen; the point of the mark
is to tell you WHICH of two same-named wildcards you are about to reference,
and whether it will resolve against this node's snapshot or the library row.
`@` rows carry it now, styled exactly like the filter header's so the fact
reads the same in all three places.
Injected `$var`s had no icon. `collectUpstreamProducers` reports WP_ContextInjector
rows as `kind: "injector"`, and `KIND_ICON_MAP` had no entry for it, so every
one of them fell through to the generic `pi-circle` and rendered as an empty
ring next to properly-marked siblings. Added `pi-sign-in` — the arrow-into-a-
door mark, matching "inject a value into the context". `--wp-kind-injector`
already existed in the canvas palette, so the tint was there waiting for a
glyph to put it on.
Two guards on the icon map itself, which had none:
- Every entry must name a glyph the installed PrimeIcons actually ships. A
missing glyph renders an empty ring, which reads as "this kind has no icon"
rather than as a mistake, so nobody reports it — exactly how `brush` shipped
broken in the icon picker. The stylesheet is the authority, parsed rather
than mirrored in a list that would go stale on the next upgrade.
- Every kind a canvas producer can emit must resolve to something other than
the fallback circle. That is the assertion that would have caught `injector`.
Three things the canvas could not say that the SPA could.
**$var suggestions were bare.** `collectUpstreamProducers` walks the node
chain and deliberately excludes the point-of-view node, so it can only
attribute vars produced further upstream. In the normal shape — one Context
node carrying most of the modules — nearly every name in the dropdown had no
writer at all, and the rows rendered as a bare list while the SPA showed a
full attribution line for the same names. It looked like the canvas was not
walking the graph; it was, and then discarding the half that mattered.
The node's own modules now produce a matching map, built in the same pass as
the sibling name list so the two cannot disagree about which module owns a
name. Siblings override upstream writers, which is what the engine does, so
the row names the module whose value actually survives. Their tail reads
"this node" rather than a node label, because every sibling would give the
same answer.
Separately, the combine template editor never received producers at all —
`ModuleEditModal` forwarded them only to the derivation modal — so that one
was bare regardless of where the vars came from. Threaded through.
**Nested refs never said whose pool they use.** A ref resolves against this
node's snapshot of a wildcard when it has one, and that snapshot can hold
different options from the library row of the same uuid. Until now the only
way to discover that was to open the hover card. The chip carries a small
marker when the node supplies the pool, and the filter panel's header carries
the matching one, so "this is the node's copy — these counts describe it"
reads the same in both places. The library case stays unmarked: it is the
default, and marking both turns a signal into decoration. Origin is decided by
presence in the node's pool map, which is exactly how `resolvePoolFor` already
picks the winner for the hover card.
**One more unbounded preview.** A wildcard option's value in the pool list had
no line cap, so a paragraph-length option grew taller than the rest of the
pool put together and pushed every other option off the panel. Clamped to
three lines with the full value on hover — with `overflow: hidden`, without
which `-webkit-line-clamp` silently does nothing.
Four things, all in the way of editing a wildcard with a real tag vocabulary.
Escape threw away the edit. The editor pages run a window-level Escape
shortcut that cancels the edit and routes back to the list. It opts out when
focus sits in an `input, textarea, [contenteditable]` — which covers the filter
panel's expression field but NOT its tag buttons, so pressing Escape after
clicking a tag navigated off the page. That is why it only happened sometimes.
The picker now takes Escape in the capture phase and stops it there, so while
it is open the key cannot reach anything else.
The per-option tag menu was clipped. It was `position: absolute` inside
`.wp-editor__body`, an `overflow: auto` scroller, so rows past that container's
edge were simply cut — measured 34px lost near the foot of the page. It is
teleported to <body> now and positioned from the trigger's rect, which is what
every other popover here already does. It re-anchors on scroll and resize
rather than closing: closing was the first attempt and was wrong, because the
browser scrolls a partly-visible button into view as part of clicking it, so
opening a menu near either edge closed it in the same gesture. Once the trigger
leaves the viewport entirely there is nothing to anchor to, and it does close.
Scrolling it moved the page. The menu's list now carries
`overscroll-behavior: contain`, so reaching either end stops there instead of
handing the leftover delta to the editor behind it. Same fix applied to the
filter panel's tag list. The cap and the scrolling also moved off the menu and
onto the list inside it, so the new search box stays pinned while the tags
scroll under it.
Everything is searchable, and the axes fold. 30+ checkboxes in a menu is
not something you scan; the picker gains type-to-filter, and the sub-categories
editor gains a per-axis fold so you can shut the four axes you are not working
on. A folded axis still shows its tag count, so folding never hides the fact
that something is there. The caret is its own button rather than the whole
header, because the header also holds the rename input and making the row the
toggle would fold the group every time you clicked in to edit the name.
The option-tag tests now query the document: teleporting the menu puts it
outside the wrapper's element tree, so `w.get()` cannot reach it.
The panel had an expression field, a reads-as line and a flat chip palette.
Authoring anything real with it meant holding the wildcard's tag vocabulary in
your head, and the two states that matter most were invisible.
The expression is now syntax-coloured: terms in accent, operators in blue,
parens dim, and an undeclared word underlined in red AS you type rather than
after the validator finishes the sentence. A textarea cannot colour its own
text, so the paint is a mirror element beneath a textarea whose glyphs are
transparent; every metric that decides where a glyph lands is declared once
and inherited by both layers, because if they disagree the colours slide off
the characters. The field also wraps, grows and drags — a single line clipped
anything past ~40 characters, and a real expression is longer than that.
The palette is grouped by axis, each foldable, with a search over the tags.
A folded axis still reports "2 used" / "1 negated", so folding never hides
state. Chips take their state from the parsed AST — lit when included, struck
when negated, dashed when the wildcard declares a tag that no option carries —
so the palette stays a VIEW of the expression rather than a second source of
truth for it. Only the tag list scrolls; putting the scrollbar on the popover
would push the expression and Apply out of view exactly when a long list makes
them most useful.
Two states that were previously silent:
- Valid but matching nothing. `skin-tone and pastel` is well-formed over
declared tags; it just happens no option carries both. That applied silently
and you found out at run time with the ref resolving to nothing.
- An unknown term now offers the nearest declared tag, and applying it
rewrites that word in place rather than re-serialising the expression, so a
one-character typo fix does not reformat the line you are writing.
The count now includes the null option and drops it when Exclude null is
ticked. `optionTagSets` carries only non-null options, so the popover
advertised "132 options" while this panel counted against 131, and ticking the
flag changed nothing on screen.
Also: a header naming the wildcard being filtered — a breadcrumb back to the
suggestions on the insert flow, a plain title on chip-edit — with Escape
matching what that header promises. The whole Exclude null row is a click
target, not just the 13px box.
Popover rows gain the same treatment: the glyph sits in a tile tinted with its
OWN kind's colour, since a `$var` can be written by a fixed_values or a combine
as easily as by a wildcard; facts are discrete tiles; and the producer line
keeps the module name separate so it can be highlighted, because that name is
the identifying half of the sentence.
Both popovers rendered one line of text per hit — a name, and for `@` a
trailing "12 opts · a1b2c3d4". That distinguishes entries whose names already
differ, and nothing at all when they don't, which is precisely the case that
sends someone to the popover in the first place. A library here has two
wildcards called `act_plan`; the old rows were byte-identical.
Rows are now built from what the thing actually is:
- `@` rows carry the wildcard's option count, its axes and its tag count,
with the uuid kept as the last-resort tiebreaker for entries that match on
every other fact. A funnel marks rows where Tab opens a filter, shown on
the active row only — on every row it is a column of noise, and the
affordance is unreachable for rows you are not on.
- `$` rows name the writer. The canvas walked a graph so it reads "written by
Style FX · ember-marten" and can honestly say a write "overrides 2"; the
library has no execution order, so the same count reads "2 others bind
this" instead. That distinction is resolved in one place, so the popover
and RefChip's hover card cannot drift into telling different stories about
the same variable.
The header now reports how many entries MATCHED, and says "· showing 50" when
the row cap hid the rest. It first reported `acRows.length`, which is the
post-cap figure — "50 matches" for a query that hit 89. A silent truncation is
how you conclude the wildcard you are looking for does not exist.
Row models live in `utils/suggestion-rows.ts`: pure data-to-data, out of the
2.8k-line editor that hosts them, and directly assertable.
Bundle budget 468 -> 490 KB. The previous bump left 179 bytes free, so every
change since has had to argue with the gate; this one is sized to also cover
the filter panel that follows.
The picker built its rows as `{ value: id, label: name }`, so a library
holding two pools both called "Lighting" — which is what you get, because it
is the obvious name for the indoor one and the outdoor one — rendered two
identical lines with no way to tell which was which. The fields that would
have distinguished them were projected away one computed earlier, where
`filteredItems` narrowed whole rows down to `{ id, name }`.
Rows now stay whole, and each option carries its category, its payload
summary, and — only when the bare name is genuinely ambiguous — a short uuid,
appended last so it reads as a tiebreaker rather than as the row's identity.
The detail comes from `entitySubtitle`, the same function the Import and
Export pickers use, so a row reads the same wherever it is offered.
The builder lives in `utils/entity-select-options.ts` rather than inline in
the view: it is pure data-to-data, and when a uuid appears is worth asserting
directly instead of through a mounted component.
Two fixes in Select itself, both about the same failure:
- `meta` now repeats in the CLOSED trigger. Disambiguating rows only while
the menu is open solves half the problem — pick one of five identical
"Outfit" rows and the trigger collapses back to "Outfit", so the choice you
just made carefully becomes unverifiable again.
- The icon/dot gutter is reserved for every row in a list where any row has
one. Mixed lists rendered a ragged left edge, and that indent reads as a
hierarchy that does not exist. Width is measured off the widest marker
actually present, so a dots-only list does not pay for icon width.
Categories are fetched OUTSIDE the `Promise.all` that loads modules and
bundles. Joining them would let a failure fetching what is purely icon-and-
colour reject the whole batch and leave the runner with an empty module list.
The four histograms put a label, a bar and a count on one row, several rows
deep, with nothing between them. Rows are also variable height — a clamped
label is one line or three — so there is no steady rhythm to help the eye
carry a label across to its own count.
Banding, not highlighting. Two details decide which one it reads as:
- The container's `gap` is gone. With a gap, tinted rows cannot touch their
neighbours, so each one floats as a discrete filled block and the fill
reads as "this row is selected". The spacing now lives inside each row as
padding, so the stripes are contiguous. This is the change that matters;
contrast alone cannot fix a gapped stripe.
- No border-radius, and a negative inline margin matching the card body's
14px so each stripe bleeds to the inner edge. A rounded, inset fill is a
pill, and a pill on a row is the universal shape of selection.
The tint is `color-mix` against `--wp-text`, so it inverts with the theme
for free — verified rendered in both wp-theme-dark and wp-theme-light.
Swept the project for user text rendered with no bound on its size, after the
Test Runner histogram turned a paragraph-length option value into a forty-line
label that pushed every other bar off the screen.
Static analysis flagged 168 interpolation sites, but most are fixed labels or
sit inside a parent that already clips — the useful signal was 54 genuinely
unbounded free-text renders, of which three are reachable today:
* TestRunner `.wp-hist__template` — used by three of the four histogram
types; only the fourth had ever been given `wp-truncate`.
* Templates `.wp-tpl-full` — `max-width` but no height bound, so one long
template pushed every row below it away.
* InjectorRow `.wp-inj-summary__template` — a collapsed one-line summary
that a long template silently stretched.
Each gets the treatment its ROLE calls for rather than one blanket rule:
* histogram label — a preview beside a bar, so a two-line clamp (three for
bundle rows, which show several modules at once) plus `title` for the rest.
One line loses the difference between near-identical option values.
* template detail pane — opened deliberately to READ it, so cap and scroll;
clamping would defeat the point of expanding.
* injector summary — one line is the whole contract, so a hard ellipsis.
Caught while verifying the BUILT css, not the source: a later rule reset
`.wp-hist--bundle .wp-hist__template` to `overflow: visible`, which silently
disables `-webkit-line-clamp` — the clamp would have shipped doing nothing.
That rule exists to let bundle labels wrap, which `white-space: normal` already
handles, so it keeps the wrapping and drops the overflow reset.
Two follow-ups to the grip.
**Shape.** The replacement grip was a filled square of hatching, which read as
a button. Clipping it to a bottom-right triangle puts the stripes parallel to
the hypotenuse — the shape the browser's own resizer draws, and the one users
already recognise as "drag me".
**Floor.** The canvas fixed-values rows never declared a `min-height`, so the
computed value was `auto`, which `parseFloat` turns into NaN and the old
`|| 0` turned into a floor of zero. With the native resizer that was masked by
the browser's intrinsic minimum; taking it over exposed it, and the rows could
be dragged away to a sliver with no way to see what you were editing.
Fixed at both levels, because they answer different questions. `.row__value`
now declares `min-height: 28px` — CSS stays authoritative about what a given
field's floor should be. `useGrowableField` additionally falls back to a hard
28px whenever CSS declares nothing usable, so a future caller that forgets can
not reach zero either.
Your detail — "it gets stuck when the bottom edge touches the first character"
— was the box reaching one line, i.e. its `min-height`. Same fight as the
`max-height` cap fixed in the previous commit, at the other end, and the reason
three earlier attempts all missed it.
The native `resize` computes `startHeight + (pointerY - startY)` from an origin
it captures at pointerdown, and clamps to nothing. Drag past a limit and that
sum keeps running while the rendered box stays pinned, so dragging back moves
nothing until the invisible total walks all the way home.
Measured, collapsing past a 34px floor then expanding:
native resize, floor 34px ........ 13 / 23 frames dead
native resize, floor lifted to 0 . 10 / 23 (intrinsic minimum remains)
rewriting style.height each frame 13 / 23 (browser ignores it)
own grip, clamped ABSOLUTE math .. 13 / 23 (input already accumulated)
own grip, incremental delta ...... 0 / 23
Nothing outside the resizer can fix it: writes to `style.height` are discarded
because the browser recomputes from its own origin, and clamping the result
does not help when the accumulated input is what overshot. So the native
resizer is gone, replaced by a grip that applies each move's DELTA to the
current height and clamps to the CSS floor. No history, nothing to unwind — the
first pixel back off a limit moves the box.
Verified on the live SPA field with the reported sequence (scroll to the end,
over-collapse, expand): 0 / 19 dead frames.
The grip sits in the corner the overflow fade already leaves clear, and is
drawn like the native one it replaces. Also removes the `clampInlineHeight`
helper from the previous commit — disproven by the table above, and its
docblock claimed a fix it did not deliver.
Measured this one instead of guessing at it. A real Playwright drag on a
capped field versus an uncapped one, sampling height against pointer position:
capped down: 60 70 … 190 192 192 192 192 192 192 192 192 192 192 192
up: 192 192 192 192 192 192 192 192 192 192 192 190 180 …
frozen while dragging up: 10 / 25 frames
uncapped frozen: 0 / 25
`max-height` and `resize` fight each other. Drag past the cap and the inline
height keeps climbing while the rendered box stays pinned; drag back and
nothing moves until the inline value falls under the cap again. That dead zone
is the reported "gets stuck, then starts working", and it bites exactly AT the
cap — which is also where the overflow fade appears, which is why the fade kept
looking like the culprit.
It was never the fade, the pointer events, or the ResizeObserver. My three
previous attempts all treated symptoms.
The cap exists to stop AUTO-grow eating the screen; a deliberate drag is the
user overriding that, so it now yields. On a pointerdown in the grip zone the
current rendered height is pinned and `max-height` is dropped — pinning first
because removing the cap from an `auto`-height box would otherwise let it leap
to full content height the moment the handle is touched. Grip-zone detection
keeps a plain click in the text from pinning the box and killing auto-grow.
Same harness re-run against the fix: 0 / 25 frozen frames, tracking identical
to the uncapped control.
Also restores live grip-follow. Deferring it to pointerup was part of the
previous wrong theory and just made the field slide off-screen for the whole
drag; scrolling by the overshoot moves the element up by exactly that much,
landing its bottom edge where the pointer already is.
The drag still seized the moment the fade appeared, on both targets. The fade
was the tell, not the cause: crossing the overflow threshold is simply when the
observer callback starts doing work, and the work was the problem.
Two things ran synchronously inside the ResizeObserver callback:
* `updateOverflowHint` read `scrollHeight` / `clientHeight` and wrote a
reactive ref, so every frame of a resize dirtied layout inside the very
callback the browser uses to report layout. That is the ResizeObserver-loop
case: the engine throttles and skips delivery for a frame, which the user
feels as the drag locking up until they release and re-grab.
* `followGrip` scrolled the container mid-drag, sliding the element out from
under a pointer the browser anchors its resize tracking to. My own fix from
the previous commit, adding a second stall on the way out.
The callback now only schedules; all measuring, state writes and scrolling
happen in the following animation frame. Grip-follow additionally waits for
`pointerup` — the field still ends up on screen after a drag past the fold,
without anything moving while the handle is held. Listeners sit on `window`,
since a resize drag routinely ends with the pointer outside the field.
The regression test asserts the invariant that actually matters rather than the
symptom: with rAF stubbed out, invoking the observer callback must read layout
zero times.
Three defects in the same field, two of which never reached the canvas because
I fixed them in the wrong component. `RichTextInput` and the fixed-values
`ValueRow` had each grown their own copy of "capped, resizable, auto-growing
text field", and the copies had diverged.
**Auto-grow stomped the manual resize.** `ValueRow.autosizeValue` wrote
`height = scrollHeight` on every input AND on every external value change, so a
box the user had dragged smaller sprang straight back open on the next
keystroke. That is the reported "hold it to collapse, it gets stuck, then
starts working" — the drag was working, the auto-fit was undoing it.
`useGrowableField` now records that the user has taken control and stops
auto-fitting from that point on, distinguishing its own writes from a drag with
an `autoDriven` guard so the first fit does not lock the field immediately.
**The fade hid the grip.** The bottom hint band is exactly as tall as the
native resize handle and sat right on top of it, so the handle was invisible:
aim, miss, re-grab. It is `pointer-events: none`, so it never blocked the drag
— it hid the target. The band now stops 16px short of the right edge. Fixed in
both components; previously only `RichTextInput` got it, which is why the
canvas fixed-values modal still looked wrong after a rebuild.
**Nothing followed the grip off-screen.** Dragging a field taller than the
space below it moves the box, not the pointer, so the handle slides out of view
and the drag goes blind. The shared helper scrolls by exactly the overshoot,
pinning the bottom edge to the viewport. Walks computed `overflow-y` for the
real scroller rather than assuming the page scrolls — on the canvas it does
not, and `window.scrollBy` would have been a no-op. Deliberately not
`scrollIntoView`, which this project bans for moving every ancestor.
Extracted rather than fixed twice: a third copy was about to be written for the
sub-category filter's expression box.
Groundwork for the sub-category picker redesign. The palette's chips need to
show what the expression currently does with each tag — and that has to be read
from the parsed AST, not from what the user clicked, or the chips desync the
moment an expression is typed, pasted or hand-edited. The palette is a view of
the expression, never a second source of truth for it.
`collectTermPolarity` walks the AST tracking `not` parity, so `not (warm or
cool)` marks both negative and `not (not warm)` comes back positive. A tag
appearing both ways lets positive win: the chip reads as participating, and the
negation stays visible in the expression text.
`livingTags` separates DECLARED tags from tags any option actually carries.
A declared tag no option uses is offerable and guaranteed to match nothing —
the exact shape of the nested-ref bug — so it gets its own `dead` state rather
than looking selectable. It does NOT outrank `in`/`negated` though: once a tag
is in the expression the chip shows that, because the zero-match warning
already covers the consequence and two alarms for one mistake is noise.
`nearestTerm` backs the validator's did-you-mean with a length-scaled edit
budget — `colde`→`cold` yes, `magenta`→anything no. A wrong guess is worse
than no guess.
Scrolling inside a capped, resizable field and reaching either end let the
remaining delta chain to the ancestor, so the modal — or the whole editor page
— lurched while the pointer was still over the field. Worst at the TOP edge,
where a small upward flick past the first line jumps the page.
`overscroll-behavior: contain` on every field that both caps its height and
scrolls: RichTextInput's `--wrap` and `--multi` hosts plus the nine other
resizable textareas across the assembler, cleaner, combine, fixed-values,
push-to-library, injector, bulk-add and import surfaces.
Applied per-rule rather than as one `textarea { … }` global: an unprefixed
element selector is exactly what `pnpm check:css-isolation` blocks, and on the
canvas it would reach into ComfyUI's own DOM. The pattern already exists in
five places (SelectionToolbar, UnmetDepsDialog, PickerSection…) — this brings
the input surfaces in line with it.
Two halves of the same gap, left over from the nested-ref fix.
**The sub-category picker offered the wrong pool's tags.** Its checkbox list
came from `buildWildcardRefData(catalog)` — a library fetch — while the engine
filters the ref against THIS node's snapshot whenever the uuid is a module
here. On a drifted snapshot the picker listed a tag no option in the running
pool carries: pick it, and the ref resolves to nothing, with the checkbox list
itself being the thing that misled you.
`overlayContextPools` applies the same precedence `resolvePoolFor` already
gives the hover card, so card, picker and engine now describe one pool.
`ContextPool` grew the declared vocabulary (`subCategories`, `tagGroups`,
`hasNull`) the picker needs — distinct from `tagSets`, which is what options
actually carry; a declared tag no option uses is offerable but matches
nothing. `uuidToName` is deliberately NOT overlaid: it holds the variable
binding a chip labels itself with, not a display name.
Only the derivation modal needed it. The constraint modal already builds from
node modules, and the SPA editors have no node, where the overlay is a no-op.
**"Matched no options" told you nothing.** The engine emitted
`ref_subcategory_empty_pool` all along, but `WARNING_LABELS` had no entry, so
Debug rendered the raw slug — and even read, the message could not distinguish
a wrong filter from a right filter aimed at a stale copy. That ambiguity is
exactly what made this bug a hunt.
`_stamp_pool_provenance` records, per catalog entry, whether the pool came
from this node or the library, plus the library's option count when a node
copy has drifted. The warning now reads:
@{05c54db9:test} matched no options — searched this node's copy
(1 option); the library now has 2
with `pool_origin`, `pool_total` and the pool's `available_sub_categories` in
`detail` — the tags it DOES offer being the whole explanation. Labels added
for the two nested-ref warnings and `ref_out_of_surface`.
Provenance is runtime-only: `__wp_catalog__` is stripped at the socket and the
workflow-embedded snapshot is built elsewhere, so neither key reaches saved
JSON. The extra reads are one per embedded wildcard on an already-open
connection, and the stamping never raises — diagnostic garnish must not take a
graph run down.
Follow-up to the pool-source card. Naming the library as the source is honest
but leaves the obvious question unanswered: the pool is right there on the
canvas, in a node the user can see, so why isn't the ref using it?
Because a `@{}` ref only ever sees its OWN node's modules plus the library —
`__wp_catalog__` is rebuilt per node and is not among the cross-node internals,
so a catalog never crosses the socket. That is the exact opposite of how
`$vars` behave, which is what makes it a trap: move a pool one node upstream
and the ref silently switches to the library with nothing to explain it.
The card now says "also in dusk-marten — other nodes don't share pools" (or
"N other nodes" past one), in info blue rather than the drift amber, because
nothing is wrong — the ref is behaving correctly and the user simply cannot
see why from anywhere else.
`findWildcardHomesElsewhere` walks the whole graph, subgraphs included: a node
holding the uuid off to one side is exactly as irrelevant to the ref, and just
as confusing to look at. It is injected as a FUNCTION and called once per card
open rather than exposed as a reactive map — the walk is graph-wide and only an
open card ever reads the answer, so polling it on the 400ms cadence would burn
work nobody reads.
Wired through the same reader-prop path the other graph walkers use
(`wildcardHomesReader` in the mount glue), so the component stays mountable
headless with no graph.
The exclusion test — the asking node must not report itself, since its own
modules ARE the ref's pool — was checked to FAIL when the guard is removed.
Hovering a chip raised two popups at once: the chip's own hover card, and the
native tooltip belonging to whichever container it sat in — the derivation
rule/branch summaries put the full row text on a `title` so a clamped value
stays readable. They landed on top of each other.
The chip only rendered a `title` when it was filtered, so an unfiltered chip
had none and the browser walked up to the container's. An EMPTY title is not
the same as no title: per HTML it means "this element has no advisory
information" and stops that walk. So the chip now always carries `title=""`.
Nothing is lost — the filter's "reads as" and the excluded-null note already
render inside the hover card, so the native tooltip was duplicating them. The
seven tests that asserted the old title now assert the card instead, which is
where a user actually reads it.
The card read the live library unconditionally, but the engine resolves a
nested ref against the Context node's own frozen snapshot whenever the uuid is
also picked there, and only falls back to the library otherwise. So a node
holding a drifted snapshot reported the library's numbers while the graph ran
the snapshot's — "the SPA says 1 of 11 options match, the graph says 0 of 10".
Both counts were right about a different pool, and nothing said which, so
neither could be checked against what actually happened.
`extension/context-pools.ts` mirrors the engine's precedence: the node's pool
wins when present, the library answers otherwise. The card now counts against
whichever won, and names it — "pool: this node · Pose pool" vs "pool: library".
When the loser disagrees it adds "library has N — refresh to use it", so a
differing number is explained rather than hidden; silently showing only the
effective pool would have left the original confusion intact, just quieter.
Disabled modules are deliberately KEPT in the map. Disabling a module stops it
binding its own `$var`; it does not remove the pool the engine still resolves
nested refs against, and dropping it here would make the card disagree with the
engine in precisely the case where a user is already unsure where a value came
from.
Wired by provide/inject rather than a seventh threaded prop: RefChip sits six
components below the widget (row → edit modal → section → value chips →
preview → chip) and not one layer between has any business knowing about
option pools. Absent injection — the SPA library views — every ref reads the
library, which is correct there since there is no node.
The three tests that pin the precedence were checked to FAIL when the context
branch is disabled.
Type a space after a `$style_fx` chip, delete it, and the caret settles flush
against the chip's trailing edge — which reopened the suggestion popover even
though nothing was being filtered and the chip already existed. Both surfaces.
A committed chip serialises back into raw text as exactly what the user would
have typed to create it, so `probeAutocomplete` — which works on raw text —
scans back from the caret, finds the chip's own `$`, and reports a live query.
From the string alone the two cases are identical; only the DOM distinguishes
them, because a chip is an atom element and in-progress text is not.
`chipRawSpans` carries that distinction into the raw coordinate space by
measuring each rendered chip with the SAME `childRawLen` the caret mapping
uses (hoisted rather than copied — two measurements of the same thing drift).
A trigger landing inside one of those spans suppresses the popover.
Surfaced by the earlier deletion re-probe fix: before it, deletion never
re-probed at all, so this path could not fire. The regression test asserts
zero suggestion rows after the exact reported sequence, and was checked to
FAIL (2 rows) with the guard disabled — otherwise it proves nothing.
Two previous attempts solved the wrong problem. The rule/branch summaries were
forced onto a single line — first with a gradient mask, then with
`text-overflow: ellipsis` — and both destroyed the thing that made the row
useful. The mask faded every pixel including the ref chips; the ellipsis
version was worse still, because the children were `inline-flex` and an
inline-flex box is ATOMIC: the browser cannot clip through it, so a value that
did not fit whole was dropped entirely and replaced by a bare `…`.
The layout was never the problem. Wrapping is what lets a four-chip branch
show all four chips, and that is the readable, wanted behaviour. The only
actual complaint was that one paragraph-length override ran to dozens of lines
and pushed the rest of the modal off screen.
So the layout goes back to exactly what it was (`display: flex; flex-wrap:
wrap`), byte for byte, and the cap moves to the VALUE: `clampPreviewValue`
cuts at 120 characters. Normal rows are untouched — every chip value in a real
derivation is well under the limit — and only the outlier gets cut. `title`
still carries the full text on hover.
The clamp never splits a `@{...}` token: half a token renders as literal text
rather than a chip, which reads as corruption rather than truncation, so a
token that would straddle the limit is dropped whole.
A nested ref in a derivation resolved to empty whenever the wildcard it points
at was not ALSO picked into the same Context node — no matter what the live
library held, and no matter how the ref was filtered.
Root cause is discovery, not resolution, which is why it looked like a
resolution bug. The catalog is synthesised from wildcard modules only, and
`walk_transitive_refs` was seeded from those uuids and followed refs found in
wildcard payloads only. A `@{uuid}` is legal on other surfaces too — most
importantly a derivation rule's action value, and the per-instance
`action_value_overrides` the edit modal writes when a user retargets a branch
on the canvas. Neither was ever scanned.
So such a ref's target reached the catalog only by coincidence: when the user
happened to also have that wildcard picked in the node. Removing it — a
reasonable thing to do once a derivation references it by uuid — dropped it
with nothing to put it back, and the ref became `unknown_ref` → empty string.
`ref_seed_uuids` (engine/modules/snapshot.py) now collects refs from every
module's `payload` AND `instance`, and both catalog builders seed the walk
with them. The instance half matters on its own: a canvas-side retarget lives
there and is not part of the library payload the walker would otherwise see.
Both builders are fixed, not just the graph one. `wp_api/preview.py` had the
same seeding, so the SPA preview resolved against a pool the engine would not
use — that is precisely how "the SPA says 1 of 11 options match, the graph
says 0 of 10" arose. Fixing one and not the other would have left the two
disagreeing in the opposite direction.
Embedded-first precedence is unchanged: a picked module still shadows the
library, so drift detection and workflow reproducibility hold. This only adds
targets that were previously absent entirely. An unresolvable uuid still warns
and resolves to empty rather than raising.
The gradient mask was the wrong tool. `text-overflow: ellipsis` is ignored on
a flex container, so the previous fix reached for `mask-image` to signal "cut
off" — but a mask fades every pixel under it, chips included, so the tail of
each summary went unreadable rather than merely clipped. The user could no
longer see the ref chips that are the most informative part of the row.
Switching the summary to `display: block` puts it in an inline formatting
context, where the browser draws a real `…` at the clip point and leaves
everything before it at full opacity. Children become `inline-flex` so they
still sit on one line, with a margin standing in for the flex `gap`.
Four things the user caught in one screenshot pair.
**`brush` is not a PrimeIcons glyph.** It rendered as an empty grid cell, which
reads as a layout bug rather than a typo — an unknown `pi-` class produces no
warning and no error, just nothing. Replaced with `sliders-h` ("tune the look";
the set has no brush/paint glyph at all, and `palette` already carries "art
style").
The durable part is `icon-catalog.ts` + its test: the curated list moved out of
the SFC so a spec can check every name against the installed `primeicons.css`,
which is the authority. Parsing the stylesheet beats hard-coding a name list
that would go stale on the next PrimeIcons bump. Verified live afterwards —
all 40 cells resolve a glyph.
**Category icons sat above their label in Select options.** The option row is
`align-items: flex-start` (deliberate — a 2-line label must keep the tick at
the top), so a 14px icon aligned to the TOP of an 18.75px label box rather than
to its first line. Measured 2.38px high before, 0 after. Fixed by centring the
icon and the colour dot against one line box, published as
`--wp-select-line-h` and used by both the label's `line-height` and the icon's
`height` — a `1.5em` on each would have meant two different heights, since the
icon runs at 12px and the label at 12.5px. Scoped to the option: the trigger
row is `align-items: center` and would be thrown off by the same rule.
**The icon-picker trigger jumped when a glyph was picked.** An em-dash and an
icon have different advance widths and baselines; both now share one fixed
16px slot. Grid cells got `line-height: 1` for the same reason — the icon
font's line box is taller than the mark and pushes it off centre inside an
otherwise centred flex cell.
**Import quick-select presets had no icons** where Export's do. Wiring them up
exposed that `category` had no row in `KIND_ICON_MAP` and was falling through
to the generic `pi-circle` on BOTH tabs; it now maps to `pi-bookmark`, matching
the Categories page's own empty state.
Categories have carried an `icon` column since the picker landed, but only the
Categories page ever showed it. Everywhere else a category still reduced to an
8px colour dot — which stops disambiguating anything once a library holds more
categories than there are hues a user can tell apart at that size.
Icons now render in the category dropdowns (filter + bulk-assign), in the row
chips on every list view, on the dashboard, and in both import/export pickers.
The icon replaces the dot rather than sitting beside it, tinted with the
category's colour so nothing is lost; a category with no icon still shows the
dot exactly as before.
Getting there meant collapsing three sets of copy-paste, because each would
otherwise have needed the same edit applied by hand N times — the failure mode
being that one gets missed and quietly renders the old way:
- `utils/category-options.ts` replaces thirteen identical
`categoryStore.items.map(...)` expressions across nine files. The two
variants differ only in the null choice ("All categories" vs "(none)"), so
that is the only parameter.
- `components/CategoryChip.vue` replaces ten hand-written
`<span class="wp-cat-chip" :style="catChipStyle(...)">` blocks.
- `ui/select-types.ts` holds `SelectOption`, which lived in `<script setup>`
and so was invisible to plain `.ts` importers (they see the `*.vue` ambient
shim, whose only export is the component). Select.vue re-exports it, so every
existing `from "./Select.vue"` import keeps resolving. ModuleListView's
hand-mirrored copy of that shape is gone with it — the copy had already gone
stale against `icon`.
Also reorders the Categories page: icon and colour now come before the name, in
the form and in the table. They compose the chip the user is building, and
left-to-right now matches how the chip actually renders.
The export picker grew a search box and subtitle lines when a 261-item
library made it a scroll-hunt. The import picker had the same problem the
moment anyone re-imported a whole-library export: duplicate display names,
and no way to jump to a known id.
Both sides now share the machinery instead of carrying two copies:
- `picker-subtitle.ts` — the per-kind detail line (`$outfit · 12 options`,
`3x4 matrix`, `2 modules · 1 nested`). Extracted from ExportTab verbatim.
Typed structurally rather than against `api/types`, because Export feeds
it live library rows while Import feeds it migrated payload rows that are
shape-validated but never narrowed to those interfaces; both satisfy the
loose shape, so neither side needs a cast. Adds `entitySubtitle(kind, row)`
for Import, which walks all 8 buckets in one v-for and so cannot pick the
right function at the call site the way Export's per-bucket builders can.
- `PickerSearch.vue` — the box itself. Presentation only; each host owns its
query and decides what "matches" means for its own rows.
Filter scope follows the same split Export settled on, because it is a
correctness question rather than a cosmetic one:
- section select-all acts on VISIBLE rows, so deselecting a filtered
section cannot silently drop picks the user can no longer see;
- quick-select presets stay unfiltered — "select all wildcards" means the
kind, not the current search result;
- a section with matches force-opens, since a hit hidden behind a
collapsed header reads as no hit at all.
Test fixtures for the new specs nest `variable_name` / `options` under
`payload`, matching what the server actually exports — `_row_to_module`
nests them and every migrator preserves that nesting. A first draft
invented a flat shape and produced empty subtitles.
The truncation fix did not work. Setting `white-space: nowrap` on
`.rule-head__summary` was necessary but not sufficient: the value chips render
through RichTextPreview, which declares `white-space: pre-wrap` on `.wp-rtp`
and `.wp-rtp__text` THEMSELVES. A direct declaration beats what those elements
would inherit from an ancestor, so the paragraph kept wrapping to hundreds of
lines. `ui/Select.vue` already carried this exact workaround for its trigger
label; the derivation summaries needed the same `:deep(...) !important` push
down the tree.
Diagnosed from a live DOM dump rather than assumed: the `title` attribute
added by the previous commit was present in it, which ruled out the stale-
bundle theory I had reached for and pointed at cascade instead.
Also accents the context-menu action that matches the row's current state, so
the menu points at the fix for the badge the user just saw:
missing -> Push to library (re-link or add)
drifted -> Reset / Refresh from library (pull the newer version)
modified -> Push to library (save local edits up)
States are ranked so exactly one library action accents — a row can be several
at once, and two competing accents say nothing. Each accented item also gains
a subtitle naming the reason.
Reported: a bundle showed MODIFIED while the push modal said it wasn`t linked
to any library entry. Modified against what?
`isBundleMissingFromLibrary` early-returned false when the bundle had no
`library_id`, so MISSING only ever meant "had a link and it is gone" — an
unlinked bundle could not raise it. That left MODIFIED as the only badge, and
MODIFIED compares the children against `snapshot_fingerprint`, a baseline
captured from a library entry that is not there. It was diffing against a
ghost. Same class of gate as the re-link bug: a check that assumed the
library_id case was the only way to lose a link.
MISSING now covers both shapes — a `library_id` the poll no longer knows, and
no `library_id` at all. MODIFIED is suppressed for the second: with no insert,
there is nothing for the children to have diverged from. The deleted-entry case
keeps MOD, where the local snapshot IS a real baseline.
Badge tooltip and the context-menu subtitle stop asserting the entry was
DELETED — an absent id reads identically whether it was deleted, re-imported
under a new id, or arrived in a shared workflow. They now state the observable
fact and name Re-link before save-as-new, which is the recovery the old copy
steered users away from.
Bundles already had a re-link path — my earlier claim that they were scoped
out was wrong, twice: I read a comment about bundle FINGERPRINT VERIFICATION
during import as if it covered re-link. What they actually had was the same
gate modules had, requiring a stored `inserted_at_hash`, so a bundle that lost
its link had nothing to match on.
`computeBundleFingerprint` cannot serve here: it folds in per-instance `_uid`,
`meta` and `instance` to answer "have MY children been edited since insert", so
a fresh insert never matches the library row it came from. Adds
`bundleContentKey`, the ordered list of children`s `(type, payload_hash)` —
only what survives an insert, so a workflow bundle and its library row agree.
Child order is significant (a bundle IS an ordered range) and a hash-less child
still occupies a slot rather than vanishing from the shape.
Gate widened to `needsRelink` to mirror the module modal, and the "deleted
upstream" note replaced with the observable fact plus a pointer at Re-link,
in an informational rather than danger tone.
Re-link was gated on the row carrying a `payload_hash`. A row without one was
read as "never library-tracked, nothing to re-link to" — true for a module
authored in the widget, wrong for the cases that actually bite: a workflow
shared by someone else, or a row whose stored hash was lost. Those still
correspond to a library entry, and the user was pushed to "Save as new entry",
which is how duplicates got made.
`moduleFingerprint` cannot help here — it takes `payload_hash` as an INPUT, so
it says nothing about a row missing one. Adds `localPayloadFingerprint`, which
hashes the payload CONTENT instead. It deliberately does not mirror the
engine`s hashing: both sides are computed locally from live payloads, so
self-consistency is the only requirement and cross-language canonicalisation
never enters the picture. Object keys are sorted recursively (JSON key order
is not meaningful and payloads round-trip through APIs that reorder them);
array order is preserved, since option and rule order IS meaningful.
Matching now runs strongest-signal-first: server `payload_hash`, then the
local content key (hash-less drafts only), then name. A present-but-different
hash still reads as "content differs" — a stale content key must never upgrade
a real difference to identical. The cross-kind gate is unchanged. Matches made
without a server hash are tagged `matchedByContent` and labelled
"identical (content)" so the UI never implies the authoritative hash agreed.
The note also stops asserting a cause it cannot know. "has been deleted
upstream" was one explanation among several that look identical from here; it
now states the observable fact — the id isn`t in the library — and points at
Re-link when a match exists, in an informational rather than danger tone. Red
plus a "Save as new entry" recommendation was actively steering users into the
duplicate.
Bundles still have no re-link path; that is the remaining half of this issue.
Canvas var chips gained producer attribution; the SPA still said only
"binds at runtime". It has no chain to walk, but it does have the catalog —
and with several near-identical modules binding the same name, "which module
is this?" is exactly the question the library editors raise.
Adds `buildLibraryVarProducers`: the same per-kind extraction
`collectLibraryVarHints` already does, but keeping module identity instead of
deduping it away. A module that binds one var from several places — a
derivation with three branches writing `$pose`, a fixed_values sheet with a
repeated row name — counts ONCE, otherwise the card claims three modules bind
a name only one does.
Deliberately no ranking. The library has no execution order, so which producer
wins depends entirely on how they are later arranged in a Context node. The
card names the first and reports how many others share the name, via a
`siblingLabel` that swaps the canvas`s "overrides N earlier writes" for
"N other library modules bind this name". Same reason `nodeLabel` is now
optional: with no graph there is no node to name, so the clause is omitted
rather than filled with something invented.
Wired into the Derivation and Combine editors, the two SPA surfaces with
`$var` chips.
The var-chip hover could only confirm a name existed. With near-identical
modules bound to the same var across several nodes, that is not actionable —
the question is always WHICH one wins.
Adds `collectUpstreamProducers`: the same chain walk and last-write-wins
ordering as `collectUpstreamKinds`, widened to keep identity instead of
discarding it. Covers all three producer sources — WP_Context modules,
WP_ContextInjector rows, and the WP_ContextLoop iteration vars (`$name` +
`$name_total`). Muted / bypassed nodes are skipped, matching runtime.
Node identity follows what each node actually has: WP_Context nodes report
their stable `adjective-noun` codename, the same one their header shows;
the Injector and Loop have no codename scheme, so they use a user-set title
and fall back to a plain kind label.
The card now reads "wildcard · Outfit · in dusk-marten" with the module id,
and adds two states worth surfacing: "overrides N earlier writes" (runtime is
last-write-wins, so it names the winner and says others exist) and "internal —
stripped from the final prompt", which is the most confusing state a var can
be in.
`graphAware` is an explicit prop rather than inferred: a graph-aware host that
finds no writer must say "no upstream producer", while the SPA — which has no
chain to walk — must not make that claim at all.
Raises the bundle budget 461 -> 468 KB. Approved standing: the maintainer
asked for the budget to move rather than features to be trimmed to fit.
Rule head + branch summary: the two-line max-height clamp stopped the modal
blowing out but sliced the last line through the middle, which read as broken,
and there was no way to see the rest. Now a clean single line with a fading
trailing edge (flex containers ignore `text-overflow`) plus a `title` carrying
the full plain-text rendering — `branchSummaryText` / `ruleSummaryText`.
Hover cards moved to their own tier (10030) above the popover tier (10020).
Raising popovers earlier put dropdown menus ABOVE these cards, so an `@ref`
chip inside a constraint-exception Select option had its hover card drawn
underneath the very menu it belongs to. A chip can live inside a popover, so
its card has to clear it. Applies to RefChip and PairBadge.
Select option rows now wrap to two lines instead of clipping at one. An
unscoped `white-space: nowrap !important` was forcing single-line rich content
in the menu, which cut exception values — a phrase plus a nested `@ref` —
exactly where they stop being distinguishable. The trigger keeps its
single-line clip: it has a fixed height and wrapping there blows up the row.
Fixed values: Enter inserts a newline again. Swallowing it was parity with the
single-line `<input>` this replaced, for its own sake — the engine stores the
value verbatim, multi-line round-trips, and the modal saves on Cmd/Ctrl+Enter,
so plain Enter was free all along.
Update dialog: release bodies end with a `<details>` block holding the raw
per-commit list. GitHub collapses it behind a click; `normalizeReleaseHtml`
unwrapped it inline and dumped every commit message into the preview, burying
the human-written "What`s new" the dialog exists to show. It is now stripped
before render, along with the `---` that introduced it. Matched on the summary
text rather than stripping every `<details>`, so a future collapsible still
unwraps as before. The dialog already links out to the full changelog.
Derivation rule previews: a rule head and a branch summary are PREVIEWS, but
neither was clamped, so one paragraph-length action value wrapped to hundreds
of lines and pushed every other rule, the runtime row and the footer buttons
off screen. Capped at two / three lines; the expanded body and the override
inputs still hold the full value.
Overflow fade: it only appeared once a field was typed into — never on a box
the user can scroll but not edit. A mount-time measure runs before the
max-height cap applies, reads `scrollHeight === clientHeight`, and concludes
there is nothing below. Measurement now happens after layout via rAF, and a
ResizeObserver keeps it honest across manual resizes and reflows. Applied to
both RichTextInput and the ComfyUI fixed-values row, and the fixed-values row
gained the fade it was missing entirely.
Dead CSS: drops the `.wp-tpl__menu*` selectors — Combine`s TemplateSection has
no insert menu, so they matched nothing (`.wp-tpl__reset` IS still live and
stays). Removing them exposed that their `.ibm__menu*` partners were only
passing `check:css-isolation` because a wp-prefixed selector shared the rule,
so those are now `.wp-ibm__menu*` and the check passes on its own merits.
The "more below" fade read wrong on both counts it was meant to get right.
Its 1px side insets left a visible seam down the left edge where the band
stopped short of the border, and blending toward the field background painted
an opaque strip that washed out the line underneath instead of hinting at it.
Now full-bleed (`inset: auto 0 0 0`), clipped by the wrapper`s own overflow +
radius so there is no seam, and the gradient runs to a TRANSPARENT accent so
text keeps showing through. A 1px inset accent line along the bottom does the
actual attention-getting, which lets the wash stay light.
Derivation branch headers (SPA) now toggle from anywhere on the bar. The
chevron was a ~14px target on a full-width header that already looked
pressable. Clicks originating inside a control are ignored, so the chevron
does not double-toggle and the enable checkbox / delete action keep their own
behaviour.
Templates: drops the Template column. A template string is a whole prompt
skeleton, so a table cell only ever showed a truncated fragment while stealing
the width the name needed; the row expansion already shows it in full. The
column now carries length + distinct `$var` count.
Nav: Wiki loses its sidebar entry — it duplicates Documentation`s content on
GitHub and sat directly above View Source. It now lives at the foot of the
Documentation view`s own nav. "Report an issue" becomes "Feedback & support",
opening a modal that offers Discord (noted as faster) and GitHub, since most
feedback is a feature request rather than a bug. Discord also gets a permanent
topbar icon.
Export: sections with search matches auto-expand — a filtered but collapsed
section gave no clue whether the query had found anything. Every entity kind
now carries row detail, not just wildcards: values / rules / matrix size +
exceptions / children + nested / template length. Combine reads `output_var`
and `input_vars` (an earlier guess of `output_variable` matched nothing, so
combine rows showed nothing at all). Detail is right-aligned in the name
column so it forms one scannable run. Kind presets carry their kind glyph.
Constraints: source/target dropdown meta gains tag + axis counts — that IS the
matrix about to be built, so the grid size is worth knowing before picking.
Inputs: max auto-grow drops from 40vh to 12rem (wrap) / 14rem (multiline) —
40vh let one field eat half the viewport before it scrolled. ComfyUI
fixed-values gains the manual resize handle it was missing, and the SPA
derivation value fields gain `wrap`, so both match combine/derivation
behaviour. Adds a restrained accent-tinted bottom fade when a capped box is
hiding content below the fold.
Wildcards (SPA): per-option tag chips cap at 4 behind a `+N`, mirroring the
canvas OptionRow, and the Sub-Categories section collapses via a `+`/`x` in
its header with a tag/axis count while shut. A fully tagged wildcard pushed
the options table off screen.
Select: hover titles on the trigger and option rows, so a value clipped by a
fixed-width trigger is still readable — constraint exception sources run long.
Two separate defects, both making a visible dropdown unusable.
Scrolling closed the list. `onWindowScroll` was a capture-phase listener on
window that closed the popover on ANY scroll — including scrolls originating
INSIDE the popover. So wheeling over the list closed it, and dragging its
scrollbar closed it mid-drag, leaving a half-typed reference behind. It now
ignores scrolls inside the popover, and a genuine outside scroll re-anchors
via `positionPopup` instead of closing: losing an in-progress token because
the page moved is a worse outcome than following the input. Matches what the
injector menu and VarAutocompleteInput already do.
Popovers rendered behind modals. Every teleported popup sat at z-index 9999
while modal overlays run from 9999 (ModalShell) to 10010
(InjectorBindingModal). At equal z-index the popover won only on DOM order,
so inside any 10000+ modal it was buried — the reported "injector ref
dropdown appears behind the modal". Moves the whole popover tier to 10020:
the autocomplete popover, the shared `.ibm__menu` / `.wp-tpl__menu` insert
menu, the subcategory filter picker, `ui/Select`, and IconPicker.
Also: the Pool collapse chevron was a 9px glyph with no hit area, so nobody
could tell it was pressable — now an 18px target with a hover box. And the
seed-list modal goes 486px to 560px, since its toolbar and per-row toggles
were being squeezed into near-square boxes to fit.
Reported repro: type `@act` (4 matches), narrow to `@act_` (2), delete the
`_`, and `@act` still shows 2. The list never followed a deletion, on either
surface.
Backspace and Delete both `preventDefault()` and perform the deletion
themselves via `deleteRawRange`. Suppressing the native delete means no
`input` event fires — and `onHostInput` is the only other caller of
`refreshAutocompleteFromHost`. So `acQuery` kept its pre-deletion value and
`acItems`, computed off it, stayed frozen at whatever it had narrowed to.
That is also the real cause of the earlier "type something unmatched and you
must clear the whole field" report: the field was fine, the list was stale.
Both delete branches now re-probe. The call sits in a SECOND `nextTick`
because `restoreCursorAtChar` ends with `host.focus()` and `onHostFocus`
schedules its own tick that can reposition the caret — probing in the first
tick reads the pre-settled caret at offset 0, the probe returns null, and the
popover closes instead of re-filtering. Verified: probing one tick earlier
left the list empty where an equivalent input event produced 3 rows.
Also reverts the earlier partial-brace / space handling in
`probeAutocomplete`. That was built on a misreading: `@{uuid#name}` is an
internal serialisation the user never types, wildcards are addressed by
variable binding rather than display name, and a space is the settle
delimiter that commits a chip — so neither is a valid query shape and the
bare-identifier scan was already correct.
The 60s freshness window was the only thing invalidating cached snapshots, so
after editing a wildcard in the SPA you sat and waited for the canvas to
agree. The window was arbitrary — it existed because the canvas and the SPA
are separate pages with no shared invalidation event to subscribe to.
There IS an observable signal: the user coming back. They edit in the SPA
tab, switch to the ComfyUI tab, and expect the canvas to be current.
`markAllStale` now runs on `focus` (clicking between windows) and on
`visibilitychange` (tab switch), so the refresh happens exactly when they
look at it.
The mark is cheap and the refetch stays lazy — driven by whatever `ensure()`
the next reactive tick makes — so a focus event on a graph with no `@{}` refs
costs nothing. Only the freshness stamps are dropped, never the cached
values, so nothing flickers back to a raw uuid mid-refresh. Transient failure
tombstones clear too, since an explicit "check again" should retry rather
than wait out RETRY_TTL_MS; permanent 404s stay.
The 60s timer stays as a backstop for the case where focus never changes —
two visible windows on one desktop.
Copy exists so a module can be shared WITHOUT walking the Export tab, which
means what lands on the clipboard has to be paste-able into Import. It was a
bare engine row, and `parsePayload` rejects that outright — it requires
`{schema_version, bundles, wildcards, fixed_values, combines, derivations,
constraints, categories}` and never gets as far as looking at the entity.
`buildCopyableRow` now emits a complete export envelope carrying the one
entity in its own bucket, with the siblings empty. Bundles (which have
`children` and no `type`) go to `bundles`. `schema_version` still comes from
the same `schemaVersionForPayload` the publish paths use, so a copied entity
and a published one can never disagree about their shape.
An unrecognised entity kind is now refused rather than copied: an envelope
with every bucket empty reads as "copy worked" and then imports nothing,
which is worse than a visible failure.
Scope: this carries the one entity, not its dependency closure. A wildcard
nesting `@{uuid}` refs still imports with those dangling, and the Import
tab`s missing-dependency UI reports them; shipping the closure stays the
Export tab`s job since it has the UI to show what is being dragged along.
Tests round-trip the copied JSON through the REAL `parsePayload` rather than
asserting a hand-written shape.
The extension rendered in light mode on top of a dark ComfyUI. Not a broken
light theme — it was STUCK in light.
ComfyUI moved the `dark-theme` class between frontend releases. Verified
against two live builds on this machine:
1.45.21 -> <body class="litegraph grid dark-theme ...">, <html> bare
1.47.10 -> <html class="dark-theme">, body no longer carries it
`hasDarkClass` only read `document.body`, so on any current build the check
returned false and `detectInitialTheme` reported "light" — the extension then
painted its light tokens onto ComfyUI`s dark chrome. Evaluated against the
live 1.47.10 DOM, the old predicate returns false where the new one returns
true.
Now checks EITHER element and observes both, so a theme switch is caught
whichever element the running frontend mutates and older builds keep working
unchanged. Light is still the genuine signal when neither carries the class.
Tests pin both eras plus the html-side switch.
The canvas and the SPA disagreed about the same derivation: the SPA reported
"1 of 11 options match" while the ComfyUI instance reported "0 of 10".
`ensure()` short-circuited on `cache.has(u)` and nothing but the test seam
ever cleared the map, so a SUCCESSFUL snapshot lived for the lifetime of the
page. Failures already had a 30s retry TTL; successes had none. The canvas
therefore kept whatever a wildcard looked like the first time it was
referenced — add an option in the SPA and the canvas reported the old count
until a full reload. The two surfaces are separate pages with no shared
invalidation event, so freshness has to be time-based.
Adds a 60s freshness window, tracked in a sibling `cachedAt` map so the
public `PreviewLookup` shape stays free of bookkeeping. The stale entry is
deliberately KEPT while the refresh is in flight, and kept even if the
refresh fails, so a resolved label never flickers back to a raw uuid. The
permanent-failure check moved ahead of the staleness check so a stale entry
whose refresh 404s cannot re-enter the queue on every 400ms reactive tick.
Also switches the SPA wildcard option value to `wrap`. It was a fixed 34px
single-line field with a horizontal scroll, so a long option value — the
paragraph-length ones users actually write — was effectively invisible.
Seed-list modal: a locked row carries three fixed-width toggles plus a hard
178px seed input and a roll button. On the 486px modal that overran the panel
— the input clipped at the right edge and the roll button was pushed out of
view entirely. The value column now shrinks (`min-width: 0`, 178px as a max
rather than a fixed width), and a long derived seed ellipsis-clips instead of
shoving the DERIVED tag off the edge.
Module picker: the selected-module chip rendered its name as a bare text
node, so a long name like "Accent piece (color-neutral)" wrapped onto a
second line inside a chip fixed at 22px tall and spilled out of its own pill.
Wrapped in a span that ellipsis-clips, with the full name on hover.
Display playground banner: the header scrim was hardcoded to a near-black
rgba over the brand gradient. Under the light theme the band stayed dark
while `--wp-text` flipped to a dark ink — dark text on a dark banner. The
scrim now follows the theme, keeping the same 0.85 knock-back either way.
Two problems in the canvas wildcard modal, both worst on exactly the
well-authored wildcards the extension is for.
Option rows: a fully tagged option carries 8+ sub-categories (hue,
temperature, tone, saturation, several suitability flags). Wrapped inside the
96px CATEGORY column they stacked into eight lines, making ONE row taller
than the option list was worth. Shows the first three behind a `+N` pill that
expands per row — the tags stay reachable, they just stop dominating.
Tag pool: 40-odd pills pushed the option list, the thing the user came to
edit, most of a screen down. The section now collapses from the header, and
reports how many tags are ticked while collapsed. Starts open so the pool
stays discoverable.
Probability: the modal rendered `Math.round(p * 100)`, so with 30+ options
every entry below 0.5% read as a flat "0%" — a legitimately weighted option
looked impossible. Now delegates to the SPA`s `formatProbability`, which
already existed for exactly this reason, so both editors agree digit for
digit.
The `icon` column has existed end-to-end — engine column, `_UPDATABLE_FIELDS`
in wp_api/categories.py, `CategoryRow.icon` in the TS types — with no UI to
set or display it, so every category rendered under the same generic bookmark.
Adds `IconPicker`, a teleported grid of curated PrimeIcons grouped by the
kinds of things people actually categorise prompt modules by (subject, style,
scene, structure, signals), plus a "No icon" reset. PrimeIcons ships ~300
glyphs; offering all of them would need its own search UI and most of the set
is chrome (chevrons, spinners, media transport) that means nothing as a
library label.
Glyph names are stored unprefixed ("palette"), matching what the column
already held. Wired into both the new-category form and the row editor, with
an Icon column in the table.
Users routinely paste an entire sentence into a value, and the fields showed
a sliver of it with no way to see the rest.
- Fixed values, ComfyUI modal: the value was a single-line `<input>`. Now an
auto-growing `<textarea>` that wraps, sized to content and capped at 30vh
before it scrolls. Enter is swallowed — a fixed value is one string and the
engine has no meaning for an embedded newline — so it still behaves like the
input it replaced.
- Fixed values, SPA: swaps the fixed 2-row `multiline` box for `wrap`, the
existing grow-to-fit mode (one row minimum, 40vh cap, manual resize handle).
A fixed height either wasted space or hid most of a long value.
- RichTextInput `--multi`: adds the 40vh cap + scroll that `--wrap` already
had. Uncapped, pasting a paragraph grew the box to thousands of pixels and
pushed every control below it off-screen.
- Combine editor: the output variable moved out of its 220px column beside the
template to its own full-width row ABOVE it. That column squeezed the field
that actually needs room to grow, and read as a footnote to the template
rather than as the thing the combine produces.
A 261-item library made the export picker a scroll-hunt, and because many
entities share a display name (five wildcards all called "Outfit"), scrolling
was the only way to find a specific one — and it still could not tell you
which was which.
Adds a search box matching name, short id, and the new row subtitle, plus a
`subtitle` on PickerRow rendering "$outfit · 31 options" — the two facts that
actually distinguish same-named modules. Mirrors what the canvas
ModulePickerModal rows already show.
Section counts and select-all read the VISIBLE rows so the header checkbox
describes what the user is looking at, but select-all leaves rows hidden by
the search untouched: silently dropping a filtered-out selection on a
"deselect all" click would lose work the user cannot see. The footer counter
still reports the true export size.
A long Context chain produces dozens of upstream vars and the picker menu was
an unfiltered scroll — the only dropdown in the extension without search.
Adds a sticky filter field that focuses on open, matching with or without the
leading `$` so typing `see` finds `$seed`. Enter picks the sole remaining
match (the common case after a few characters) and Escape closes without
changing the selection. An empty result now says so rather than rendering a
blank menu.
A library routinely holds several wildcards under one display name — five
"Outfit" entries authored at different times — and the constraint source /
target dropdowns offered five identical rows with no way to tell which was
which.
Adds an optional `meta` to `SelectOption`, rendered dim and right-aligned,
and wires the constraint editor to pass "N opts · <short uuid>". The
type-to-filter now matches `meta` as well as `label`, so pasting a uuid jumps
straight to its row — without that the duplicates stay unreachable by typing,
since their labels are identical.
Also gives the option label `min-width: 0` + ellipsis so a long module name
clips inside the row instead of forcing the menu past its max-width and
pushing the meta and tick off the edge.
A 66-child scene-composer bundle dumped every child inline on expand, so one
row buried the rest of the list.
Caps the rendered children at 8 behind a "Show all N" / "Show fewer" toggle,
and leads with a kind breakdown ("15 wildcards · 5 constraints", dominant
kind first) so a collapsed list still says what the bundle is MADE of rather
than only how many rows it has.
Expanded-in-full state is keyed by bundle id rather than a per-row flag, so
it survives re-sorting and re-filtering the list.
The Discord invite existed ONLY inside the community embed`s offline
fallback, so it was reachable exactly when the community failed to load and
invisible the rest of the time. There was no route to the issue tracker at
all.
Adds both to the Get Started section, with `GITHUB_NEW_ISSUE` joining the
link registry so a repo rename keeps touching one line. The issue link lands
on the chooser rather than a prefilled template — picking bug vs feature is
the reporter`s call, and a wrong prefill is more friction than none.
Also stamps `data-nav-id` on the external-anchor branch, which the button and
parent branches already carried.
The var-chip hover read `resolved ? "produced upstream" : "binds at
runtime"`, but for a var `resolved` is merely `name.length > 0` — deliberately
permissive in `atomIsResolved` so a legitimate runtime-bound var never renders
as a broken red chip. The upshot: EVERY var claimed an upstream producer.
Meaningless in the SPA, which has no graph at all, and unverified on the
canvas.
Adds an explicit `inScope` prop bound from the host`s suggestion pool
(upstream + siblings on the canvas, the library catalog in the SPA) and
reworded to "in scope" / "binds at runtime" — surface-neutral, and it claims
membership rather than production, which is the only thing the chip can
actually know.
`resolved` keeps its permissive meaning so chip STYLING is untouched.
`inScope` defaults to false, so a caller that passes no pool makes no claim
and falls back to "binds at runtime", which is always true.
Copy Payload wrote the bare engine row, which says nothing about which
payload shape it is in — and the shape is what decides whether a consumer
can read it. Publish already stamped the version (buildPublishBody, and the
publishToCommunity hash), so a copied row and the same row published to the
community carried different information about themselves.
Adds `buildCopyableRow`, leading the JSON with `schema_version` derived from
the SAME `schemaVersionForPayload` the publish paths use, so the two can
never disagree — including the feature bumps (SP2b range syntax, SP3
non-default constraint reach).
Note this is a single engine ROW, not an import envelope: `parsePayload`
wants `{schema_version, wildcards: [], bundles: [], categories: [], …}`, so
the clipboard JSON remains for inspection, sharing, and the community
publish form rather than for pasting into the Import tab.
Selecting a dozen entities out of a 261-item library meant a dozen precise
clicks on an 18px checkbox. Worse, the constraint reach pick rows already
carried `cursor: pointer`, so they LOOKED clickable and silently were not.
Both surfaces now toggle on a click anywhere in the row. Clicks originating
inside an interactive descendant are ignored, so the control and the row
never double-toggle and cancel each other out — the picker excludes buttons,
inputs, the checkbox wrapper and `.wp-id` (whose `cursor: copy` advertises a
different action), and the reach list excludes `.wp-check`.
Keyboard behaviour is deliberately unchanged on both: the checkbox stays the
single focusable control per row, so this adds no second tab stop for
keyboard or screen-reader users.
Replaces the TargetReachSection comment that documented the old
checkbox-only behaviour as intentional.
The menu was `position: absolute` inside the binding modal, so the modal`s
scroll container CLIPPED it — open it from a row near the bottom and the list
vanished below the fold. It also had no outside-click dismissal at all: once
open, the only exits were picking an item or closing the whole modal.
Teleports the menu to <body> with `position: fixed` viewport coords measured
off the trigger button, flipping above when there is no room below, matching
the strategy RichTextInput`s autocomplete popover already uses. Adds a
capture-phase mousedown listener that closes on any click outside both the
menu and its button, keeps the menu positioned across scroll/resize, and
tears every listener down on close and unmount.
Escape now dismisses the menu before falling through to cancel, so a stray
open dropdown can no longer cost the user their whole draft. The teleported
node mirrors the host`s resolved theme class, since it escapes the
`.wp-theme-*` scope the tokens hang off.
Tests query the teleported node through the document and unmount their
wrappers between cases — clearing document.body under a live component
detaches Vue`s teleport anchor and the next patch throws on a null parent.
The popover capped matches at 8 rows. With 100+ wildcards sharing near
identical display names, a query like `pose` silently truncated to the first
8 and the rest were simply unreachable — and because 8 rows never overflowed
the popover`s 240px max-height, no scrollbar ever appeared. That reads to the
user as "the scrollbar does not work".
Raises the cap to 50 in both RichTextInput and VarAutocompleteInput so the
list genuinely overflows and `overflow-y: auto` earns its keep, and scrolls
the keyboard-selected row into view on every `acActive` change. Without the
latter, ArrowDown past the last visible row moved the selection but left the
popover scrolled at the top, so the highlight vanished and the list looked
frozen.
Typing the `{` that the canonical `@{uuid#name}` syntax calls for killed the
suggestion popover outright, and it only came back after deleting the entire
run — the reported "dropdowns break if you type something that cannot be
found and you need to delete the whole text and start typing again".
`probeAutocomplete` only scanned back through `[a-zA-Z0-9_]`, so `{`, and
every space or dash inside a display name ("Pose pool — presenting"), ended
the scan on a non-trigger char and returned null. The INSERT half of the same
feature already understood the form: `insertChipAtCursor`s cut regex allows
`\{[0-9a-fA-F:,_ -]*\}?`. The two halves simply disagreed about what a
half-typed ref looks like.
Probes the partial brace form first, before the bare-identifier scan. A `{`
not preceded by `@` stays an inline brace block (`{a|b|c}`), and a `}` already
present before the caret means the ref is complete so the popover stays shut.
Alt-tabbing mid-token in the ComfyUI edit modal froze the page with
`DOMException: Node.insertBefore: Child to insert before is not a child of
this node`, followed by a cascade of null derefs (`emitsOptions of null`,
`parentNode of null`) that left the editor dead until a page refresh.
Root cause: the host is `contenteditable`, so the BROWSER owns its child
nodes and may replace them wholesale — select-all + retype, IME commit,
undo, some paste paths. Vue then holds detached `el` pointers in its child
vnodes. Blur fires a full re-parse via `onHostBlur`, and patching the new
atom structure over the wreckage derefs a dead node.
The existing `renderEpoch` rebuild does NOT cover this — verified against a
repro probe: bumping the v-for key still walks every stale `el` during
teardown and throws on `nextSibling` of null. The only safe repair is
discarding the host ELEMENT vnode, which Vue unmounts with a single
`hostRemove(el)` on a node that is still attached, tearing children down
with `doRemove: false` so no stale child is ever touched.
Adds `hostDomIsStale()` (live `[data-atom-index]` count below
`atoms.value.length`) plus a `hostEpoch` key on the host element. The check
is deliberately `<` and not `!==`: EXTRA top-level nodes are the normal
typing case and must not remount, which would eat the caret mid-keystroke.
Covers both directions with regression tests — the destroyed-children crash
and the orphan-text-node non-regression.
`resetChildToBundleSnapshot` fetched `api.bundles.get(bundle.library_id)`
without checking the bundle is actually linked. An unlinked or broken-link
BundleInstance carries an empty `library_id`, so the request built
`/wp/api/bundles/`, whose trailing slash normalizes to the collection
route — surfacing as `Reset failed: No such API route: /wp/api/bundles`,
which reads like a missing endpoint rather than a missing link.
Adds the same up-front guard its sibling `resetBundleToLibrary` already
had, and routes both catch blocks through `bundleResetErrorMessage` so a
404 (library row deleted or re-imported under a new uuid) names re-linking
as the recovery instead of leaking raw API text.
The chip hover cards and the self-contained Select styles push the canvas
bundle past the previous 453 KB ceiling. Entry budget is untouched (main.js
stays ~4 KB of the 30 KB allowance); this only moves the total.
Raised deliberately rather than trimming further — the remaining headroom is
~8 KB, so new canvas CSS/JS still needs to stay lean.
Every search box was name-only, so pasting an 8-hex uuid — the one identifier
that is unambiguous when two entries share a display name — returned nothing.
Server side: the module, bundle and template `_build_where` clauses now match
`(name LIKE ? OR id LIKE ?)`. Client side: the remap-ref, bundle-reattach and
constraint-reattach pickers filter on uuid as well as name, which is the
reliable way to pick the right target among same-named candidates.
Hovering a `@{uuid}` chip now shows what it actually resolves to: the uuid,
the sub-category filter read back in plain language, and "N of M options
match" computed LIVE against the library via preview-resolver (extended with
per-option tag sets) rather than from a stale embedded copy — so the count
moves when the library changes. Variable chips show their binding state.
The popover teleports from INSIDE the chip span so the component keeps a
single root (a second root silently broke `wrapper.classes()` in every
existing RefChip test). "Not in library" is gated on the resolver actually
missing the uuid — constraints have no option tag sets, and keying off that
made valid entries claim they were missing.
Nested `@{uuid}` refs and `$vars` inside `{a|b}` braces rendered as raw text
on the derivation rule-value and constraint-exception surfaces. Root cause was
hand-rolled `tokenizeRich` renderers dumping `dp-brace` verbatim — the shared
`atomicEditorModel.parse` already decomposes those, so both surfaces now
delegate to RichTextPreview instead of re-tokenising.
Exception "extras" also regain a real picker: a Select of concrete option
values with chipped #label/#option slots, rather than free text.
Select.vue ships self-contained styles for this: its `.wp-select*` rules lived
only in the manager-global tokens.css, which is NOT in the canvas bundle, so
on canvas the control rendered unstyled with its menu behind the modal. Any
manager UI component reused on canvas needs its own styles. Also pins rich
content to a single line inside the trigger/options, gives the SPA exception
table a fixed layout so nowrap cells can't overflow, and isolates the matrix
grid's stacking context so its sticky headers stop painting over the dock.
Two debugging aids for the instance edit modals:
- InstanceIdChip: a click-to-copy monospace chip in every per-kind modal
header showing the library uuid (the id that @{} refs, constraint
source/target and library rows all match on), with the per-instance _uid
in the tooltip. Makes drift/linkage problems traceable at a glance instead
of requiring a workflow-JSON dig.
- RichTextInput gains a `wrap` prop so single-line surfaces wrap + auto-grow
instead of clipping. Applied to the derivation rule override boxes, whose
values were unreadable once they exceeded the field width.
Completes D3b. The mechanism landed in 5dbe7c3c but nothing could produce a
`link` decision, because a content duplicate raises NO uuid collision and so
never reached ConflictModal.
- findLinkableDuplicates: the subset worth offering a link for — content
matches an existing row under a DIFFERENT uuid AND the incoming id isn't
itself a collision (that's the batch-conflict path's question).
- New per-item issue kind `content-duplicate` (+ ContentDuplicateDetail),
built in ImportExport.buildPerItemIssues from the live library rows.
- ConflictModal renders it with a dim IN LIBRARY badge, names the existing
entry, and offers "Link to existing" / "Import anyway". Never auto-applied:
the row counts as unresolved until the user chooses.
- PerItemDecision gains kind "link" + target_id. partitionSelection drops a
linked row like skip; runCommit folds old->target into the same remap table
the renames use, so every @{} ref + constraint source/target follows to the
existing entry instead of dangling on a uuid that never lands.
An incoming entity whose uuid does NOT collide still installs as a brand-new
row even when byte-identical content already exists under a DIFFERENT uuid.
Re-importing an iterated pack that way multiplies duplicate rows and splits
references across two identical entries.
Adds the mechanism:
- findContentDuplicates (pure): maps incoming id -> existing library id when
EXACTLY ONE same-kind row shares the moduleFingerprint under a different
uuid. Zero matches = genuinely new; 2+ = ambiguous, left to the user. A
match at the SAME id is an ordinary collision classifyOne already handles.
- CollisionDecision gains { kind: "link", target_id }. applyCollisionDecisions
drops the incoming entity and records old->target in the SAME renameMap the
rename path uses, so the existing walkRemap pass re-points every @{oldId}
ref + constraint source/target at the row that's already there.
Never automatic and never overwrites — import still defaults to create-as-new
(spec decision #2). Additive: with no producer of a `link` decision yet, every
existing path is unchanged. Surfacing it in the ImportPicker (content
duplicates raise no uuid collision, so they never reach ConflictModal) is the
remaining last-mile step.
Bundle-side sibling of the module re-link. A workflow BundleInstance is
detached when its library_id is absent from the polled bundleHashes map (a
re-import minted a fresh uuid). Its `inserted_at_hash` IS the library bundle's
payload_hash at insert time, so a content-identical library bundle under a
DIFFERENT uuid matches on exactly that — letting the bundle side reuse the
same pure findRelinkCandidates/autoRelinkTarget helpers as modules.
PushBundleToLibraryModal gains the re-link section (auto-picks a sole
identical match, else a ranked picker searchable by name or id, with
identical vs "content differs" badges) and emits mode:"relink".
ContextWidget.onBundlePushSaved folds "relink" into the existing rebind
branch, swapping library_id + inserted_at_hash + name and re-snapping the
fingerprint. No write happens — it points at an entry that already exists.
resetBundleToLibrary fetched the library snapshot and replaced the live
children unconditionally. When the instance's library_id was empty (an
unlinked/detached bundle) or the fetch resolved to an empty/mis-shaped
children array, it committed an EMPTY replacement — wiping the bundle's
modules with no warning (reported as "reset gave me an empty wildcard").
Two invariant guards, before the destructive commit:
- refuse when the instance has no library_id (not linked) — tell the user to
re-link first, instead of fetching an empty snapshot;
- refuse when the fetched snapshot has no children (broken link / wrong shape)
— abort rather than wipe the live children.
Both surface an error toast and leave the bundle untouched. Valid reset (a
linked bundle with a populated snapshot) is unchanged.
matchStateOf bailed on any falsy payload_hash, so a workflow module whose uuid
IS in the live library but whose local payload_hash is "" (a malformed/legacy
copy, or one a builder emitted with payload_hash: "") was verdict-less — no
drift dot, no "Edit library entry in SPA", and re-link couldn't fire either
(isLibraryMissing needs a truthy hash). The library link was never lost, only
the local hash was blank.
Now: when the uuid is present in libraryHashes, an empty local hash reads as
drift (conflict) so the existing bulk "refresh drifted" button relinks it in
one click. A genuinely inline module (fresh uuid, not in the library) stays
verdict-less exactly as before. All truthy-hash paths (missing/drift/silent-
skip/type-conflict) are unchanged, so D3a re-link's detached detection is intact.
Surfaces a re-link path in PushToLibraryModal when a workflow module is
detached (library-tracked but its uuid is absent from the live library — a
re-import minted a fresh id) AND a content-identical library row exists under
a different uuid. Picks the sole identical row automatically, else shows a
ranked picker (identical vs "content differs", searchable by name or id).
Confirming emits mode:"relink"; both save paths apply it:
- right-click -> ContextWidget.onPushSaved: applyRelink swaps the row id +
payload_hash and walks every module so sibling @{} refs + constraint
source/target follow the library uuid.
- edit-modal -> ModuleEditModal stamps _relinkFrom (old id) before the swap;
ContextWidget.saveEditedModule runs the same ref remap once committed.
Import stays create-as-new (no install.ts change) — re-link is the reconnect
path, never a silent overwrite. Bundle re-link is a separate follow-on.
Two pure helpers for D3a module library re-linking:
- relink-match: findRelinkCandidates ranks live-library rows against a
detached draft by (type, payload_hash) content identity, then (type, name);
autoRelinkTarget yields the sole content-identical row or null (ambiguous /
none). Never auto-links on name alone.
- relink-apply: applyRelink swaps the detached instance's own id + payload_hash
and walkRemaps every module's payload + instance so nested @{uuid} refs and
constraint source/target follow to the new uuid. Reuses walkRemap verbatim.
A held wildcard copies its frozen value from the pipeline hold base pass and
early-returns before _record_pick, so its frame-0 pick never landed in the real
ctx. Constraints keyed on a held source then mis-fired (spurious source_missing
/ never_applied warnings), and a cross-node constraint whose source is held left
its held target UNCONSTRAINED across frames (held outfit drifted: kimono at
frame 0, unconstrained pick on frames 2+).
Fix: after the per-node hold base pass, merge the base pass's __wp_picks__ (for
held modules) + __wp_constraint_hits__ into the real ctx, before the module
loop. The held source is then registered for this node's constraints and the
registration flows downstream into the next node's base pass, keeping cross-node
held targets constrained. Value-freeze path untouched.
Four fixes to the in-app updater shipped in 2.10.0:
- DOWNGRADE (critical): Update Now sent ComfyUI Manager selected_version:'latest' + mode:'cache', so 'latest' resolved against Manager's STALE cached catalog and could install an OLDER version over a newer one. Now pins the exact target version the check found (e.g. 2.10.1), uses mode:'remote' for a fresh catalog, and hard-guards against installing anything not strictly newer than what's running.
- Check Now now lights the topbar pill immediately. useReleaseCheck kept per-consumer refs, so a manual check in Settings never reached the topbar until reload; the reactive state is now a module-level singleton shared by every consumer.
- Release notes render properly: the renderer unwraps <details>/<summary>/<b> into markdown instead of showing literal tags (raw HTML still escaped).
- Changelog is human-readable: .releaserc.js now prepends a curated, plain-language highlights section (docs/release-notes/next.md) above the collapsed per-commit list, cleared automatically on each release.
Sub-category rename hand-rolled a weaker check than the add path, so a name with a space (or other invalid char) slipped through the cascade rename dialog until save. Combine output-var renames weren't validated at all. Root cause: each name-entry surface reached for its own validator/regex and they drifted.
Add a single canonical validator module (src/manager/validation/names.ts) exposing validateSubcatName (re-exported from the engine-parity subcatFilter), validateRefGrammarName, and validateVariableName/isValidVariableName. Route every name-entry site through it: subcategory add+rename, wildcard/module display-name ref-grammar check (was triplicated inline), combine output_var save+rename, fixed-value var names, var binding, and validateModule. Add + rename now share the exact same function and cannot diverge again.
Harden applyLatest against malformed/legacy cache blobs and a missing __APP_VERSION__ so a bad cache degrades to no-update instead of throwing; mock useReleaseCheck in the pre-existing Settings suite.
- Each rule card gets inline collapse-all / expand-all buttons for its own
conditions (IF/ELIF/ELSE branches), shown while the card is open.
- Branches now start COLLAPSED on open (newly-added branches still open
expanded for immediate editing), and rules are collapsed by default
regardless of count — so opening a derivation shows a compact overview.
The WP_SeedList already emits only kept frames; now its widget shows WHICH.
The host glue reads the wired loop's bypass_frames (when Override count from
loop is on) and passes them to the widget: a "N bypassed" badge on the seeds
button + read-only dimmed/struck rows in the per-iteration modal (no toggle —
bypass is owned by the loop). Adds a `bypassReadonly` mode to the shared
SeedListModal so the same modal is interactive for the loop, read-only here.
A WP_SeedList wired to a bypassing loop still emitted the full `count`
seeds, so the sampler ran 18 times against the loop's 3 kept prompts.
WP_ContextLoop now publishes `kept_indices` (the 0-based frames it actually
emits) in its loop_config side output; WP_SeedList, when taking its count
from the loop (override_count), emits one seed per kept frame — drawn from
the full series so per-frame locks still land. Backward compatible: a
loop_config without kept_indices (or a full/empty list) leaves the emit
unchanged.
Addresses the minor findings from the whole-branch review:
- TS bypass_frames parse now type-guards before accepting (no Number()
coercion), so it drops true/"3"/null identically to the Python parser
(the spec requires the two to agree on corrupt input).
- Add execute tests for bypassing frame 0 and for an out-of-range index
re-applying once count grows past it (both spec-listed behaviors).
- Document seedAt's i>=1 precondition; pass :previous to inactive bypass
rows so their "lock previous" button matches the active rows.
Adds `bypass_frames: number[]` to ContextLoopConfig + its recovery parse
(sorted, deduped, non-negative ints, out-of-range kept — mirrors the Python
_parse_config). Bumps the js/ gzip budget 450 -> 453 KB: the config field
alone landed 34 bytes over 450, and the headroom covers the loop-bypass UI
added in the following tasks.
`payloadEntityCount` summed seven buckets but omitted templates, so the
Import tab's "Loaded · N entities" bar under-reported any payload containing
templates (a template-only import read "0 entities"). Add the templates
bucket to the sum.
Building on the existing rule-card collapse (rules default-collapsed when
>1):
- Each IF / ELIF / ELSE branch now has its own collapse chevron. Collapsing a
branch hides its condition/action editors and shows a one-line
`$cond → $target` peek in the branch head, so a rule with many branches
stays scannable.
- The Rules card gains Collapse-all / Expand-all buttons (shown when >1
rule). They broadcast a `collapseCommand` (nonce + state) that every rule
card adopts; individual cards can still be toggled afterwards.
Verified live: per-branch chevron hides the body + shows the peek;
Collapse-all / Expand-all toggle every rule card.
Section order is now Identity → Wildcards → Target reach → Rule matrix →
Exceptions. The "how many downstream targets does this constraint cover"
decision now reads before the per-pair rule grid, matching the top-down
authoring flow (pick wildcards → decide reach → fill the matrix).
The JS resolver's `expandInlineChoices` only understood single-pick
`{a|b|c}`. A multi-pick block like `{1-2$$, $$smirk|smug|half-closed eyes}`
matched the brace regex but got split naively on `|`, so the `1-2$$, $$`
prefix stuck to the first branch and leaked into renders as raw
`1-2$$, $$smirk` (the Test Runner samples + histogram).
Mirror the engine's `_resolve_multi_pick` (engine/syntax/resolve.py):
detect the `N$$sep$$` / `N-M~$$sep$$` prefix, parse the count range, the
`~` independent flag (draw WITH replacement vs unique), and the separator;
then pick k weighted branches (via a `pickKUnique` port of the engine's
`pick_k_unique`) and join by sep. A fixed count skips the RNG draw, matching
the engine's seed behaviour. Single-pick `{a|b|c}` is unchanged.
Tests cover fixed/range counts, empty separator, independent-with-repeats,
and the exact user repro string.
Export quick-select bar now has a preset per kind (Bundles, Wildcards, Fixed
values, Combines, Derivations, Constraints, Categories, Templates) alongside
Full library + Favorites, via a generic `presetKindOnly` (replaces the lone
"Wildcards only"). Each per-kind button is disabled when the library has none
of that kind.
The Import picker now mirrors the bar after a payload loads from file/paste:
"All" + the same per-kind presets, operating on the loaded payload's
entities (disabled per empty bucket). The `.wp-preset-btn` atom moved to
tokens.css so both bars share it; each bar keeps its own layout wrapper.
Verified live: Export "Wildcards" → 56 of 132; Import "Wildcards" → 3 of 5,
"All" → 5 of 5, with empty-kind buttons correctly disabled on both.
The Import tab now accepts a dropped .json export file, not just a file-pick
or paste. The pick/paste buttons sit inside a dashed dropzone that advertises
"or drag & drop a .json export file here"; dragging a file over it lights the
frame accent and switches the hint to "Drop to import"; dropping reads the
file and runs it through the same parse pipeline as the file picker (a shared
`readAndParse` helper). Non-JSON drops fall through to the existing inline
"Invalid payload" error, so there's no silent failure.
Verified live: the dropzone highlights on drag-over; unit tests cover the
drop→payload-ready path and the highlight toggle.
#12 — imported modules kept the exporter's original creation date (shown
"1mo old" instead of just-imported). The engine importer's insert paths use
`entity.get("created_at", now)`, so a client-supplied date is copied
verbatim. The rename path already stripped lifecycle fields for this reason;
extract that into a shared `stripLifecycle` helper and apply it to the `add`
path too, so the server stamps a fresh created_at (identity/`id` preserved).
#7 — the sidebar template + category count badges went stale after an
import, because the post-commit / post-undo refresh in ImportExport only
reloaded the module + bundle stores. Refresh `templateStore.fetchCatalog()`
and `categoryStore.fetchAll()` alongside them so the counts update live.
Bundles were excluded from import collision detection on the premise that a
`bundle-fingerprint.ts` MOD-detection flow handled them downstream — but that
file was never built. So an imported bundle whose id already existed:
- never appeared in the conflict modal (missing from the conflict count),
- fell through to a blind `add` decision,
- was rejected by the server with 400 "id collision on add",
- which failed the whole commit and the bundles never imported.
Bundles live in the same id→snapshot_fingerprint library map as modules, so
route them through the SAME `detectCollisions`: identical → silent-skip,
present-but-changed / no library fingerprint → conflict / exists-unknown,
both of which surface in the conflict modal for Replace / Rename / Skip —
exactly like a colliding module. Fixed in `buildSelectedEntities`
(the commit orchestrator) and mirrored in `ImportPicker`'s inline badges so
an existing bundle reads MODIFIED / EXISTING / DUPLICATE / NEW consistently.
Removed the stale `bundle-fingerprint.ts` references from the comments.
Verified live: re-importing an existing bundle now opens the conflict modal
("1 existing" → Skip / Replace / Import as new) instead of 400-ing.
Two polish fixes flagged before starting Batch C:
- Sticky header bleed: the editor scroll container's top can land on a
fractional device pixel (measured 152.39 at dpr 1), so pinning the sticky
region exactly at top:0 left a sub-pixel sliver above the opaque header
through which the scrolled content behind showed as a faint ghost line.
Overlap the scroll edge by 1px (top:-1px, clipped by the container overflow
and absorbed by the header's 12px top padding) so the bg covers the seam at
any DPR; the sticky <thead> tracks the same -1px to stay flush.
- Confusing weight tooltip: the option-weight input carried `min="0.01"
step="0.1"`, so a default weight of 1 is off the native step grid and the
browser popped up "Please select a valid value. The two nearest valid
values are 0.91 and 1.01." The native step is validation-only here — arrow
keys, the wheel, and the custom chevrons all route through bump(), which
reads props.step itself. Input now emits native step="any" for number
inputs (no grid validation), while bump() keeps stepping by props.step.
Extends the shared useBulkSelection + BulkDeleteToolbar pattern to the last
two editors:
- ConstraintEditor exceptions (a table): a "Bulk edit" toggle adds a
checkbox column + select-all to the editable exceptions table and a delete
toolbar in the sticky subheader. Exceptions carry no persisted id, so
selection keys off a WeakMap-backed transient uid (stable across edits and
single-row removals, never written to the payload).
- DerivationEditor rules (a card list): the checkbox rides to the left of
each rule card; select-all + the delete toolbar sit in the sticky
subheader. Rules already have a stable id, so selection keys off it.
The bulk-edit toggle stays reachable while bulk mode is active even after
every row is deleted, so the user can always leave bulk mode.
Adds a shared `useBulkSelection` composable + lean `BulkDeleteToolbar`
(count + Delete + Clear) for editors whose rows have nothing to bulk-set,
then wires them into FixedEditor: a "Bulk edit" toggle reveals a per-row
checkbox column + select-all, and the sticky subheader shows the delete
toolbar once ≥1 row is picked. Deletion is in-memory (marks the editor
dirty; committed on Save), and the existing bulk-ADD panel is untouched.
Bulk-edit Apply/Remove sub-category menus (#3, #4):
- Apply now lists only tags that would change something — every tag EXCEPT
those already on all selected rows (commonTags).
- Remove now lists only tags the selection actually carries (presentTags,
the union across selected rows); empty selection-tags → empty menu.
- Menu items show an axis-hue swatch via the shared `tagHue`, so a
sub-category reads with the same colour here as in the pills / row chips.
Dropdown scroll-trap (#3):
- `overscroll-behavior: contain` on the menu list stops wheel scroll at its
top/bottom edge from chaining to the editor body ("nudged the page").
- Scrolling the page behind an open menu now closes it (capture-phase scroll
listener that ignores scrolls originating inside the menu's own list).
WildcardEditor computes commonSelectedTags / presentSelectedTags /
selectedTagHues and passes them to SelectionToolbar. New props are optional
and fall back to the old all-tags behaviour, so nothing else breaks.
The four tests skipped pending the tasks 15-17 handler migration now assert
the current dispatcher-based trace shape:
- writes always carry an `overwrite` flag (first write = False)
- disabled modules emit a `skipped_disabled` trace row (writing nothing)
- unknown module types emit a `skipped_unknown_type` row + a warning log
- rng is threaded via `ctx["__wp_rng__"]` (HANDLERS dict removed), seeded
deterministically from the `seed` arg
Batch A stuck only the card header; the bulk-edit toolbar (BulkAddPanel +
SelectionToolbar) lived below it in the card body as a separate flow
element, so scrolling a long option list left it behind. Wrap the header
and a new `subheader` slot in one `.wp-card__sticky` region and stick that
region as a unit. Card.vue now measures the whole region for
`--wp-card-header-h`, so the sticky <thead> auto-offsets below it as the
toolbar appears/disappears. Move the `.wpc-bulk-controls` block into the
subheader slot in WildcardEditor + FixedEditor.
Long option / value / rule / exception lists scrolled their toolbar and
column header out of view, so "Add option" (and friends) were unreachable at
the bottom -- exactly where new rows land. Add a reusable `sticky-header`
option to Card: it pins the card header to the top of the editor scroll
region and publishes the measured header height (`--wp-card-header-h`, via
ResizeObserver) so a sticky <thead> can offset right below it. Chromium wont
scroll-anchor a table cell here, so the <thead> ELEMENT is stuck instead.
Applied to Wildcard options, Fixed-values, Derivation rules, and Constraint
exceptions. Verified live: header + column header pin, Add option reachable.
reorderInjectorRows reassigned slot_name by position, but the object spread
carried the OLD slot_label along with the moved row -- so swapping two pins
left both rows showing the same stale label (the row that landed on a socket
did not pick up that socket's label). A custom label belongs to the physical
socket, which stays put on reorder (only the binding/template moves), so
snapshot socket->label before moving and assign each row the label of the
socket it lands on.
In the binding modal $ref / $slot dropdown, the type pill (e.g. "string")
sat next to the name on rows WITHOUT a label instead of right-aligned like
labelled rows -- the margin-left:auto lived on the label, which is v-if'd
out when absent. Give the type pill margin-left:auto too, and reset it to 0
when a label precedes it (the flex gap spaces them), so the pill lines up on
every row whether or not it has a label.
THE root cause of "rules clipped, no scrollbar": the rule cards are flex
children of the flex-column .rules__list, so they SHRANK to fit its
max-height and `.rule-card overflow:hidden` then clipped their branches. The
list never overflowed -> never scrolled -> no scrollbar ever appeared (each
rule showed only ~2 branches no matter how many it had). Add flex-shrink:0
to .rule-card so the cards keep full height; the list then truly overflows
calc(80vh - 20rem) and scrolls with its scrollbar, while header / identity /
runtime / footer stay pinned.
Verified live in ComfyUI via devtools: cards render ALL branches (clipped:
false), list scrollHeight 804 in a 336 cap (SCROLLS: true), modal does not
scroll, dock fully visible.
After the last fix the MODAL scrolled (overflow-y:auto) while the rule list
did not -- and the sticky dock then covered the bottom rules on scroll, so
you still could not see the full rules. Force the scroll onto the rule list:
.dvm overflow:hidden (the modal cannot scroll, so header + identity stay
pinned at the top and the dock at the bottom) + the rule list capped at
calc(80vh - 20rem) (the modal budget minus the fixed chrome, padded so the
dock never clips) with overflow-y:auto. The rule list is now the only
scroller. Measured the chrome (~15rem) vs the budget in a devtools mock:
modal does not scroll, dock fully visible, list caps + scrolls.
My previous attempt used .dvm overflow:hidden + rules flex:1 1 auto, which
CLIPPED the rules with no scrollbar in the real app: the modal overlay
parents carry only max-height:100% (no definite height), so the flex-fill
child collapses instead of scrolling. A mock with a fixed-height container
masked it.
Match the wildcard modal's proven approach: .dvm overflow-y:auto + the rule
list capped with an ABSOLUTE max-height that scrolls in place. Cap is
calc(80vh - 16rem) -- the modal budget minus the fixed chrome (header +
identity + rules head + runtime/footer dock) -- so list + chrome never
exceeds 80vh: ONE scrollbar (the rule list), no outer modal bar, dock always
visible. Prominent scrollbar (12px, brighter than the subtle app default) so
it's unmistakably there.
The derivation instance modal double-scrolled: the modal body (.dvm,
overflow-y:auto, max-height 80vh) AND the inner rule list (max-height 44vh)
both scrolled, so long rule lists clipped between the identity row and the
runtime/footer dock with no clear scrollbar -- "cannot see the full rules".
Make .dvm overflow:hidden and let the RULES region (flex:1 1 auto, content
basis so short lists still size naturally) fill the space and OWN the
scroll. Header + identity stay pinned at the top, the runtime/footer dock at
the bottom, and the rules scroll in between with a visible themed scrollbar
(matches the ModulePickerModal --wp-scrollbar-thumb convention).
Hold was replaying the derivation's frame-0 OUTPUT, which froze WHICH branch
fired -- wrong. A derivation is a transform: the condition should still pick
the branch from the current inputs each iteration; only the random roll
inside a branch should freeze. Now hold resolves with the constant hold seed
keyed PER BRANCH (rule:branch), so each branch's inline {a|b} / @{} value is
frozen to its frame-0 roll independent of which other branches fired -- but a
varying input still switches IF->ELIF and uses THAT branch's frozen value
(== what that branch would have rolled at frame 0).
Drops the now-unused __wp_module_outputs__ capture from pipeline.run (the
freeze-output replay was its only consumer). wildcard / combine /
fixed_values still freeze the whole resolved VALUE via __wp_hold_base_ctx__,
because a constraint can reshape their pool so a frozen seed isn't enough --
a derivation branch's pool is fixed, so per-branch seed freeze suffices.
The last fix reverted renamed pins to input_N on expand: the only copy of
the custom label lived in litegraph slot.label, which collapse overwrites
with a placeholder ("inputs xN" / " ") and serializes. So the label was
lost on reload, and the collapsed row tag even showed "inputs xN".
Persist it durably instead (new InjectorRow.slot_label). Capture the live
pin labels into the row on collapse -- the last tick they're readable --
and have the collapse module's expandedLabel reconstruct from it on expand
(replacing the () => undefined name-fallback). computeSlotLabels no longer
surfaces the placeholder while collapsed, and the row tag prefers
row.slot_label over the live slotLabels, so a collapsed / reloaded node
shows the real label, not the placeholder.
Existing already-corrupted saves can't be recovered (the label was
overwritten before this code ran) -- rename once + collapse to re-capture.
A derivation is a transform that writes a DYNAMIC set of vars (whichever
rules fire), so it can't reuse the single-binding hold path. The pipeline
now captures each module's frame-0 output dict keyed by per-instance uid
during the hold base pass (__wp_module_outputs__); the derivation handler
replays its captured dict verbatim on hold. The captured values are
post-resolve, so inline {a|b} picks AND nested @{} refs freeze too -- and
the output stays frozen even when the derivation's INPUT varies (the same
value-freeze trade-off a constrained wildcard makes).
Adds derivation to HOLD_KINDS + a "Hold across run" toggle on the
derivation RuntimeSection. The row right-click Hold item picks it up for
free via HOLD_KINDS.
The collapse label stash is an in-memory WeakMap that does not survive a
reload. A node saved collapsed serialized the placeholder ("inputs xN" /
" ") into slot.label, so on reload the stash was empty and expand restored
the placeholder onto input_0/1/2 instead of the names. The earlier
pre-attach reset ran BEFORE litegraph configure() restored the
placeholders, so it was a no-op -- which is why the bug persisted.
Add an opt-in expandedLabel resolver to attachCollapsableConnections: in
that mode the module skips the stash and reconstructs each matched slot's
expanded label from durable data on expand -- for EVERY matched slot,
stashed or not, which is what heals a reloaded node. The injector passes
() => undefined since its pins are name-derived (input_N). Existing broken
saves self-heal on the next expand.
Tradeoff: a custom pin label set via the slot context menu no longer
survives a collapse cycle (reverts to input_N) -- it was never persisted
durably anyway, so it was already lost on reload.
The Hold sections described only the Runtime-settings path; add the
two-click row context-menu shortcut alongside it on the WP Context node
page and the Seeds & loops concept page.
Right-click a wildcard / combine / fixed-values row and "Hold across
run" now flips instance.seed_scope without opening the editor (4 clicks
to 2). The item swaps to "Release hold" when held, mirrors the editor's
base-only rule (disabled with a hint while a loop edit-frame is active),
and is gated to HOLD_KINDS so derivation/constraint rows -- whose
handlers ignore seed_scope -- never see it.
Bumps the extension bundle ceiling 449 -> 450 KB (measured 133 B over).
An older build serialized the collapse PLACEHOLDER labels ('inputs xN' on the
first input pin, ' ' on the rest) into the workflow JSON. On reload the slots
are fresh objects, so applyCollapsedLabels stashed those placeholders as the
'original' label — and expanding then restored the placeholder instead of the
real name (input_0 -> 'inputs xN', siblings blank, input_3 dangling).
The injector's input pins are always name-derived (input_N), so clear any
persisted label before attachCollapsableConnections runs, making the stash
capture the correct name-fallback original. Self-healing on every load, so
existing corrupted saves recover too. Regression tests in
collapse-connections.test.ts cover the repair contract + the bug it guards.
seed_scope=hold previously swapped in a constant seed and re-picked each
iteration. That failed two ways: (1) a held wildcard whose pool is reshaped by
a constraint (varying source) picks a different option from the same seed; and
(2) under Override seed, the 'hold' seed equalled the per-iteration derived[k]
(effective_chain_seed returns an override verbatim, ignoring loop_index=0), so
hold was a no-op. Nested @{} refs in a held value also re-rolled.
Now hold freezes the frame-0 RESOLVED value. context_node computes a constant
hold seed from the loop's derived-series head; pipeline runs a throwaway base
pass at loop_index=0 when a loop drives + any module holds, and the
wildcard/combine/fixed-values handlers copy their resolved value from that base
context verbatim — skipping the pick AND resolve_text, so a constrained or
@{}-bearing held wildcard stays frozen (green jeans stays green jeans).
Tests: constrained held wildcard + nested-ref held wildcard each stay constant
across iterations while their vary counterparts move.
Adds a 'Per-iteration overrides' concept page (edit-frame, per-frame
override/enable/seed-lock) and expands seeds-and-loops + the WP Context Loop /
WP Seed List / WP Context node pages with seed scope (vary/hold), the
per-iteration seed modal, and the lock-previous button. Mirrors the wiki
update. Held off main so it doesn't cut a standalone release.
The earlier frame-chip wrap fix put the grid + ellipsis on the shared
.wp-loop__chips/.wp-loop__chip rules, which also style the 3 strategy chips —
truncating 'sequential' to 'seq...'. Move the grid to a .wp-loop__chips--frames
modifier on the edit-frame row only and drop the ellipsis, so the strategy
chips keep full labels on one row while the frame chips still wrap.
A standalone constraint references its source/target wildcards by id but
carries no axis grouping of its own — so the community preview rendered its
matrix flat + uncoloured when the wildcards weren't also published. Backfill
each wildcard's tag_groups into the published constraint as source_groups /
target_groups (sibling of the existing axis-name backfill), making the
grouping self-contained. Preview-only inner-payload metadata; the constraint
validator's inner z.object strips it on a consumer's install.
The Context Loop + Seed List seed modals show the UPCOMING derived series
(deriveLoopSeeds of the CURRENT base); under control_after_generate=randomize
that won't reproduce the last run. Add a per-frame Prev button that fills +
locks the seed the frame ACTUALLY used last run, greyed out when there's no
captured previous (no prior run, or the Loop wasn't driving seeds).
The nodes emit their executed per-iteration series as loop_seeds in the node
UI; a shared _seed-capture helper captures it on the executed event (mirroring
WP_Context) and the glue threads it through the widgets -> SeedListModal ->
SeedLockRow.
The runtime frame-active hint read as if it scoped the Lock pick (the one
control that IS per-frame editable); reword it to name Hide-from-prompt and
Hold-across-run — the toggles it actually disables. And switch the Context
Loop edit-frame chips from a non-wrapping flex row to an auto-fill grid so 15+
frames wrap instead of overflowing the node.
- add `disabled_frames?: number[]` to `ModuleEntry` (_shared.ts)
- engine gate reads the field (dict + object branches) and skips the
module at the listed loop indices with status `skipped_frame`
- `toggleEnabled` becomes frame-aware: when a frame is active it
adds/removes the frame index from `disabled_frames` instead of
flipping the base `enabled` flag; empties the array to remove the key
- add `isDisabledOnFrame` helper to `ContextWidget` + `ModuleRowCtx`
- checkbox reflects effective enabled at the frame; adds an `off #k` badge
- TDD: 3 engine tests + 4 ModuleRow.test.ts cases
The real bleed source (the border-collapse fix was necessary but not
sufficient): the scroll frame had `padding: 6px`. position:sticky pins the
frozen headers at the padding edge, but overflow still renders the scrolling
cells INSIDE that padding — so a 6px strip of scrolled cells stayed visible on
the top/left scroll-start sides, just outside the sticky row/column headers.
Live-diagnosed on the SPA editor: exaggerating the padding to 30px grew the
bleed strip to 30px; setting it to 0 removed it entirely. Set padding:0 on both
scroll containers (SPA ConstraintMatrix + canvas MatrixSection); the frame's
1px border + border-radius give the visual edge, content sits flush, and the
4px inter-cell gap (th/td padding) is unaffected.
position:sticky header cells under border-collapse:collapse hit a Chromium
paint bug: scrolled data cells show through the frozen row/column headers
instead of being covered. Switch both matrices (SPA ConstraintMatrix + canvas
MatrixSection) to border-collapse:separate with border-spacing:0; the 4px
inter-cell gap still comes from the th/td padding, so the layout is unchanged
while the sticky backings now paint opaquely.
The ComfyUI instance-modal matrix (MatrixSection) was still flat while the SPA
ConstraintMatrix had grown grouped axes. Bring it to parity:
- Extract the pure grouping logic (order-by-axis, contiguous groups, bucket
detection, labels, per-axis hue) into a shared components/shared/matrix-axis
module so the two grids stay identical; refactor the SPA matrix to import it.
- Port MatrixSection: column bands name each target axis, row header chips name
each multi-tag source axis, a solo axis folds its name into an eyebrow, and
the leftover run is labelled "uncategorized" (neutral, dashed) — not blank.
Headers + tag column + group chips + corner freeze while the grid scrolls on
both axes. All per-instance cell logic (overrides, popover, stranded) is
unchanged; cells stay keyed by tag name so the reorder is safe.
- ConstraintInstanceModal threads each wildcard's tag_groups into the matrix.
Cross-context refs resolved only via the preview-resolver cache (which has no
tag_groups) degrade to flat — the common sibling/chain case groups.
- Bump the extension bundle budget 432 -> 435 KB for the ~1.1 KB net growth.
The leftover run of sub-categories with no axis (or an empty axis name)
rendered as a blank band over its columns and no chip above its rows — it
read as a layout gap. It now gets the same treatment as a real axis: a
band ("uncategorized") over the columns and a header chip over the rows,
tinted neutral grey (distinct from the per-axis palette) with a dashed
edge so it still reads as the catch-all bucket rather than a named axis.
Gated on the matrix having at least one named axis: a fully-flat matrix
(no tag_groups at all) keeps the legacy source/target-tinted flat headers
and grows no "uncategorized" label. Ordering is unchanged — only the
bucket's label + colour change.
Same-named library entries were indistinguishable in the broken-reference
pickers (two "mood", two "color" with nothing to choose between). Each
candidate now surfaces the disambiguating data:
- Constraint reattach: 8-hex uuid + option count + declared sub-categories.
- @{} remap popup: 8-hex uuid alongside the existing option count.
- Bundle child reattach: 8-hex id beside the name.
The uuid is the definitive tiebreaker; the option/sub-category line gives a
human-readable one when the hex alone is opaque.
Redesign the constraint matrix headers so each sub-category axis reads as
one coloured group on both axes:
- Columns grow a band row naming each axis, spanning its tags; flat
(ungrouped) columns keep the single header row.
- Multi-tag row groups get a pinned header chip (left-frozen, full axis
name always readable however long); solo grouped axes fold the name in
as an eyebrow over the value instead of wasting a header row.
- Per-axis hues come from the shared axisHueAt palette; ungrouped tags
keep the legacy source/target tint.
- Column band, tag column, group chips and corner stay frozen while cells
scroll on both axes; the tag row sticks at the measured band height.
ConstraintEditor passes the source/target wildcard tag_groups through so
the matrix can order and colour by axis.
While a Select menu is open, printable keystrokes build a query that filters options (case-insensitive substring); Backspace trims, a "Filtering:" row shows the query, and an empty result shows "No matches". Arrow/Enter navigate the filtered set. Small dropdowns look unchanged until you type, so every Select gains autocomplete with no per-call-site change.
The bundle editor hard-disabled Save unless editing an existing bundle, so a new bundle could be opened but never saved ("create from Context" only). Save is now gated on validation (a name) for both modes; in create-mode it POSTs a new bundle and routes into its edit page. The add-child picker already builds save-valid children, so authoring here is safe.
Bundle children were deduped by id on create + update, silently dropping the second+ copy — but multi-instance bundles repeat a module id on purpose (one wildcard used as garment/hair/eyes). Removed _dedupe_children from both paths; per-instance disambiguation happens at Context-insert time via _uid, not at bundle-store time. Inverts the former QA-hardening dedup tests to assert preservation.
Option probabilities rounded to "0%" for anything below 0.5% — misleading when a wildcard has many options. New utils/percent.ts formatProbability keeps large values as integers and grows decimals for small ones (0.01%) so a nonzero weight never reads as zero.
Sub-category group colors repeated: the per-component AXIS_HUES palette held two near-identical purples and wrapped with % length. Extracted one shared components/shared/axis-color.ts (axisHueAt) with a de-duplicated, order-separated palette plus a golden-angle fallback so every group is distinct; OptionRow, PoolSection, and WildcardEditor now share it.
2026-06-22 02:04:04 +03:00
534 changed files with 53446 additions and 5833 deletions
--notes "Autocomplete data for ComfyUI-Wildcard-Pipeline. Rebuilt on demand; not a product release. Download it from the manager's Settings page rather than by hand." \
- **Faster startup.** Opening ComfyUI used to download 43 of the extension's files before the canvas finished loading, even with no Wildcard Pipeline node on it. It now downloads 2 (166 KB → 92 KB gzipped). The toast stack, the Display playground, the template editor and the subgraph conflict badge now load the first time you use them.
- **What's new shows the release you are running.** After an update, the page could keep showing the notes of an older release for a few hours ("Release notes for v2.15.3 — you are running v2.17.0"), because it trusted a release check cached before the update. It now headlines the newest release it knows about, and a cached check older than your version is fetched again.
- **Link one wildcard's pick to another's with the new Only rule.** A constraint rule set to **Only** turns its row into a short list. An exception *maid → frilled apron* in Only mode means that whenever the source rolls "maid", the target can only roll "frilled apron", and an outfit you add to the target later is shut out too. Before, the same link needed an Exclude rule for every other outfit, and any outfit added afterwards slipped through. In the matrix, an Only cell links subcategories the same way, and the other cells in that row show a faint × so you can see what is shut out. Only is in the cell popover, the exceptions mode picker and the canvas instance editor. Constraints that use it publish as schema version 6, so an older extension refuses them and asks you to update instead of failing the constraint.
### Fixes
- **Setting a matrix cell back to Neutral on the canvas no longer breaks the constraint.** Overriding a library rule to Neutral in a Context node's constraint editor saved a value the engine didn't accept, so the whole constraint stopped applying when the graph ran. The editor now saves it correctly, and workflows saved with the old value run again.
- **The constraint docs described Allow wrongly.** They said Allow keeps only the matching options. Allow has always meant "no change" (it shows as Neutral in the matrix). The docs now say so, and the keep-only behaviour they described is what Only does.
New docs for chips, references and the filter grammar.
### Highlights
- **Docs: Chips & references.** A new page in the manager's Docs tab (How it connects → Chips & references) explains the chips you see in text fields and their three states (resolved, filtered, broken), how to make a placeholder `$var` chip before anything produces it, the full `@{uuid#name:filter!null}` reference form and why plain `@name` stays text, and the sub-category filter grammar: `not`, `and`, `or` (or a comma) and parentheses, e.g. `not warm and (low or high)`. Searching the docs for "chip" or "filter" now finds it.
- **`$outfit.1.SHOES` now reads the second pick's shoe.** On a wildcard that picks several options, an indexed axis read skipped any pick whose option carries no tag on that axis, so every later index slid down by one: with `robe, jeans` picked, `$outfit.0.SHOES` printed the jeans' boots beside the robe and `$outfit.1.SHOES` came out empty. Each index now names the same pick as `$outfit.1`, in templates and in derivation conditions alike. The bare `$outfit.SHOES` read was already right and is unchanged.
- **The Prompt Assembler preview shows the tag that was actually rolled.** The preview filled `$outfit.SHOES` with the first tag of the group whatever the option, so it could read `sandals | robe | red stilettos` for an outfit with no shoes and a pair of heels. It now reads the same roll as the values beside it, and matches what the prompt will say.
- **Library file exports now record the schema version their content needs.** Exporting from the library always wrote schema version 2 into the file, even when it held range multi-picks like `{1-3$$…}`, constraints with a narrowed reach, or wildcards with an **accepts** tag axis. An older extension would then import the file and silently misread or drop those features. Exports now say 3, 4 or 5 when they use those features, so an older extension refuses the file and asks you to update. Files without them still export as version 2.
- **Shared wildcards with accepts tag axes now say when your extension is too old for them.** A wildcard whose tag group is marked **accepts** is now published as schema version 5. Before, it went out as version 2, and an extension from before 2.14 installed it without complaint while quietly dropping the accepts setting, so `$outfit.SHOES` read empty and constraints lost the rolled tag. That older extension now refuses the pack and asks you to update. Wildcards without an accepts group publish exactly as before.
- **Updating a community item no longer re-runs the old tag conversion on it.** "Update" and "Install as new entry" labelled every download as the oldest schema version, so each install ran the version 1 to 2 upgrade again over content that was already current. Downloads now keep the version the community recorded for them, and so do dependencies fetched from a constraint's "download missing" action.
- **Cutting an already-empty field no longer wipes your clipboard.** Cut an option's text, press Ctrl+A Ctrl+X again on the now-empty field, and the text you meant to paste was gone: the editor let the browser cut an invisible caret marker, which replaced what was on the clipboard. The second cut now leaves the clipboard alone, and a paste never writes that invisible character into a value.
Read a wildcard's chosen tag as a variable, a much faster ComfyUI start, and a bulk-delete fix worth reading.
### Highlights
- **Tag groups can now be axes you read as variables.** Mark a wildcard's tag group **accepts** and it becomes an *axis*: the wildcard rolls exactly one of its tags each pick, and you can read that tag anywhere with **`$var.AXIS`**. An `$outfit` wildcard with an accepts group `SHOES` exposes **`$outfit.SHOES`** as the shoe it chose this run — the same value in every template, combine, derivation and chained node, because it is rolled once when the option is picked rather than each time it is read. Groups left **classify** (the default) behave exactly as before, so nothing already in your library changes.
Where it pays off is constraints. When an accepts axis is the **source** of a constraint, the rule keys on the single rolled tag rather than every tag the option happens to carry — so a diagonal "same tag wins" matrix pins the target to exactly what was rolled, and `$outfit.SHOES` and the shoe that gets picked agree every run. If the **target** is also an accepts axis, it stays in the pool when the source allows any of its alternatives and then rolls the matched one, so the two wildcards never disagree on the axis. The editor marks accepts groups in the constraint matrix, warns when an option carries none of its axis's tags, and offers a wildcard's axes in the `$` autocomplete.
- **Optional booru tag autocomplete.** Turn it on in Settings → Tag autocomplete and typing a few letters into an option value suggests danbooru tags, ranked by how often they are actually used, colour-coded by kind (character, copyright, artist, meta) and resolving aliases — type `hires` and it offers `highres`, naming what it matched so the jump is never mysterious.
It stays out of the way of everything you already use: `$` variables and `@` references always win the caret, and suggestions never appear while you are typing one. Off unless you switch it on.
The tag list is a file you install once — press **Download** in Settings to fetch it from this project's GitHub release, or drop your own CSV at the path shown there. **This is the only thing this extension ever fetches from the internet**, it only happens when you press the button, and the [README](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline#network-access) documents exactly what that request does and the restrictions around it.
- **This extension was making ComfyUI slow to load, and it will clean up after itself on the next start.** Our frontend files carry a content hash in their names, so every release produced new filenames — and ComfyUI Manager installs an update by writing the new files over the old ones without removing what the new version no longer ships. Nothing ever deleted the previous version's files, so they piled up with every update.
On a real install that had been updated a dozen times: **1,774 files taking 60 MB, where about 300 were live.** ComfyUI requests every JavaScript file an extension exposes when the page loads, so that install was fetching 237 of our chunks instead of 58 — nearly 10 MB, which was 42% of all extension code on that page and by a wide margin the largest single contributor to its load time.
This release records what each build produces and deletes anything left over from an older version when ComfyUI starts. **No action needed — the first start after updating does the cleanup**, and it is conservative: only files this project's build system generates are ever removed. On the install measured above it freed 52 MB and removed 1,579 files.
- **Sourcemaps are no longer shipped.** They were being written on every build and included in the package, but never linked, so no browser had ever requested one — 22.5 MB of files that existed only to be ignored. Debug builds can still produce them.
- **"Select all" now means the rows you can see.** With a filter active, the header checkbox selected *every* row, not the filtered ones — so narrowing a list down to a handful, selecting all and deleting removed the whole list, most of it never on screen and with no warning. This affected the **wildcard** and **fixed-values** editors, and on wildcards it reached bulk weight and tag changes too: setting a weight on a filtered selection silently rewrote every option's weight, with no change in row count to hint at it. Select-all is now scoped to what the filter is showing, in both directions. If you have ever lost options or had a weight distribution flattened, this was why.
- **A constraint can no longer hold two rules for the same pair.** Adding the same source/target combination twice — say `rain → sandals` as both *exclude* and *boost ×3* — looked like two active rules, but only one ever applied: whichever came last in the list. Order decided the outcome, nothing showed you the order, and in the worst case a deliberate **exclude was silently thrown away** by a later duplicate. Saving or importing a constraint with a repeated pair is now refused, naming the pair so you know which one to remove. Existing constraints keep working exactly as before — nothing already in your library is rejected, and no generation changes.
- **Constraint exceptions and derivation rules have a filter bar.** The wildcard and fixed-values editors got one previously; these two did not, which was backwards — an exception list is routinely longer than the wildcard it filters. Type to narrow the list, with a count and a clear button.
Rules keep their real numbers while filtered, so "Rule 5" stays Rule 5 instead of renumbering to 1, and editing or deleting a filtered row acts on that row rather than the one that happens to share its position.
- **The library-change check stopped re-downloading your whole library every five seconds.** Both the manager and the in-graph Context node watch for library edits made elsewhere, by polling a list of module hashes. That list was re-sent in full on every tick with no caching headers — 33 KB every five seconds on a real library, roughly **24 MB an hour per open tab**, sitting idle. Producing it also re-read and re-parsed every module payload in the database each time.
The check now answers "nothing changed" with an empty response the browser already knows how to handle, and works that out from a cheap row count rather than by rebuilding the list. On a local install this was invisible; if you reach ComfyUI over Tailscale, a VPN or any metered connection, it was the largest thing this extension did.
- **The webfonts are no longer bundled into JavaScript.** Both fonts were being base64-encoded into a code file that ComfyUI had to download and parse *before* it could finish registering this extension's nodes — about 90 KB of JavaScript that was never really JavaScript. They are now ordinary font files the browser fetches on its own, in the background, while everything else carries on. Node registration no longer waits for them.
Two things follow from that. Text appears sooner on a slow CPU, because 90 KB stopped going through the JavaScript parser. And the fonts now stay cached when you update — previously every release changed the code file they were hidden inside, so your browser re-downloaded them every time.
Total download on a fresh install is roughly unchanged: the encoding overhead and the compression that undid it cancel out. The gain is in *when* the work happens, not how much of it there is.
<!-- /modal -->
### Upgrade notes
Nothing to do beyond updating. If the interface renders briefly in a system font on the first load after this update, that is the fonts arriving in the background as intended — it settles within a moment and does not recur.
A security fix for the database location setting. Update when you can.
> **Already on 2.13.0?** This is the same release. 2.13.0 reached GitHub but not the
> ComfyUI Registry, so it never arrived for anyone installing through ComfyUI Manager.
> 2.13.1 is that same build under a version number the registry will accept — nothing
> in it differs.
### Highlights
- **The "move the database" setting could be abused to touch other files.** Changing the database location schedules a file copy or move that runs the next time ComfyUI starts. The two paths were only checked for being absolute, not for being database locations — so a request sent to your ComfyUI port could have scheduled a copy or move between any two files on the machine, including reading a file by copying it somewhere this plugin serves over HTTP. ComfyUI's API has no authentication, so anything that can reach the port could do this. Both paths are now restricted to the three locations the database is actually allowed to live in. Moving your database between those locations works exactly as before.
- **What's new now shows the releases you skipped.** The page only ever showed the newest release, so updating across two versions meant the middle one's notes were simply gone — 2.12.0 was current for about an hour before this release replaced it. The last few releases are now listed underneath, collapsed, each with its own notes. **All releases** also goes to the releases index now instead of to the single release it was labelled against.
<!-- /modal -->
### Upgrade notes
Nothing to do beyond updating. No settings change, and any database move you had queued still runs normally.
If you expose ComfyUI beyond your own machine, this one is worth taking promptly — the affected setting is reachable without a login on every install of 2.11.0 and 2.12.0.
<!--
HOW TO WRITE THIS FILE
Order, and nothing else:
Headline one sentence, what this release is about
### Highlights 4-5 max
<!- /modal -> the update dialog stops rendering here
<details> Also in this… grouped one-liners, collapsed
### Upgrade notes only when the reader must act; delete otherwise
— keep this OUTSIDE the <details>, it needs seeing
This file IS the release body — the compare link is appended automatically and
the per-commit list is deliberately not included. It is consumed at release
time and cleared afterwards, so anything left here ships.
RULES
1. Highlights are capped at 4-5. The cap is the mechanism: it is what keeps a
6-commit release and an 80-commit release roughly the same height. If a
sixth feels essential, something else was not a highlight.
2. A highlight passes one of three tests:
- new capability — you can do something you could not before
- wall removed — something that blocked you now works
- surprising — behaviour changed in a way you should not meet alone
Polish, truncation, layout and invisible perf fail all three.
3. Commit count is NOT a test. The categories icon picker was two commits and a
real feature; `ui` was nine commits and almost entirely polish.
4. The tail is grouped by area, one line each, no bold-lead paragraphs. Group
names are free-form — use whatever the release actually contains. It sits in
a <details> so a long release does not double the page; put the count in the
summary so the reader knows what they are opening. That number is written by
hand here and can drift — the update dialog computes its own from the same
bullets, so if the two disagree, this one is wrong. Note also that collapsed
text is not reliably reachable by browser find-in-page, which is the cost.
5. Write what changed for the user, not what changed in the code. Name the
symptom, not the fix: "the field went blank" beats "guarded a null deref".
6. Perf belongs in the tail WITH its numbers, so the people it affects
A security fix for the database location setting. Update when you can.
### Highlights
- **The "move the database" setting could be abused to touch other files.** Changing the database location schedules a file copy or move that runs the next time ComfyUI starts. The two paths were only checked for being absolute, not for being database locations — so a request sent to your ComfyUI port could have scheduled a copy or move between any two files on the machine, including reading a file by copying it somewhere this plugin serves over HTTP. ComfyUI's API has no authentication, so anything that can reach the port could do this. Both paths are now restricted to the three locations the database is actually allowed to live in. Moving your database between those locations works exactly as before.
- **What's new now shows the releases you skipped.** The page only ever showed the newest release, so updating across two versions meant the middle one's notes were simply gone — 2.12.0 was current for about an hour before this release replaced it. The last few releases are now listed underneath, collapsed, each with its own notes. **All releases** also goes to the releases index now instead of to the single release it was labelled against.
<!-- /modal -->
### Upgrade notes
Nothing to do beyond updating. No settings change, and any database move you had queued still runs normally.
If you expose ComfyUI beyond your own machine, this one is worth taking promptly — the affected setting is reachable without a login on every install of 2.11.0 and 2.12.0.
<!--
HOW TO WRITE THIS FILE
Order, and nothing else:
Headline one sentence, what this release is about
### Highlights 4-5 max
<!- /modal -> the update dialog stops rendering here
<details> Also in this… grouped one-liners, collapsed
### Upgrade notes only when the reader must act; delete otherwise
— keep this OUTSIDE the <details>, it needs seeing
This file IS the release body — the compare link is appended automatically and
the per-commit list is deliberately not included. It is consumed at release
time and cleared afterwards, so anything left here ships.
RULES
1. Highlights are capped at 4-5. The cap is the mechanism: it is what keeps a
6-commit release and an 80-commit release roughly the same height. If a
sixth feels essential, something else was not a highlight.
2. A highlight passes one of three tests:
- new capability — you can do something you could not before
- wall removed — something that blocked you now works
- surprising — behaviour changed in a way you should not meet alone
Polish, truncation, layout and invisible perf fail all three.
3. Commit count is NOT a test. The categories icon picker was two commits and a
real feature; `ui` was nine commits and almost entirely polish.
4. The tail is grouped by area, one line each, no bold-lead paragraphs. Group
names are free-form — use whatever the release actually contains. It sits in
a <details> so a long release does not double the page; put the count in the
summary so the reader knows what they are opening. That number is written by
hand here and can drift — the update dialog computes its own from the same
bullets, so if the two disagree, this one is wrong. Note also that collapsed
text is not reliably reachable by browser find-in-page, which is the cost.
5. Write what changed for the user, not what changed in the code. Name the
symptom, not the fix: "the field went blank" beats "guarded a null deref".
6. Perf belongs in the tail WITH its numbers, so the people it affects
Full support for ComfyUI's Nodes 2.0 renderer, and a pass over everything to do with knowing where a value came from.
### Highlights
- **Every node works under Nodes 2.0.** ComfyUI's new Vue renderer changed how nodes are laid out, sized and scrolled, and our widgets were built against the old one. Nodes now render, resize, scroll and merge their wires correctly under both renderers — including switching between them with a workflow already open.
- **See where a variable or reference comes from.** Hover any `$var` or `@{ref}` chip and the card names the module that writes it, the node it lives in, and — for references — the pool it resolves against and how many options currently match. Variables produced by a Context Injector, by a sibling module, or by another node are all attributed instead of reading "binds at runtime".
- **The `@` and `$` pickers were rebuilt.** Rows carry an identity so two similarly-named entries are tellable apart, pools supplied by a node are marked as such, and the sub-category filter panel is redesigned — chips reflect the parsed expression, and exception values get a picker of real option values instead of a free-text box.
- **Wildcard options and fixed values became editable at scale.** A pinned search bar, tag filtering, drag-to-reorder, and bulk edit that can move rows to top or bottom and add or remove sub-categories across a selection.
- **Text editing in options no longer breaks.** Cut, paste and select-all could leave a field stuck, mangled, or typing into the wrong place, and a selection would skip over chips. Keystrokes also no longer escape a modal into ComfyUI's global shortcuts — pressing a plain letter could trigger a node-definition refresh and freeze the page.
<!-- /modal -->
<details>
<summary><b>Also in this release</b> — 26 smaller changes</summary>
**Sequences and seeds**
- Lock a frame's seed or bypass it straight from its chip on the Context Loop — shift-click to lock, alt-click to bypass — instead of opening the per-iteration seeds dialog
- The Seed List gets the same frame chips; clicking one locks its seed, and frames bypassed by a wired Context Loop are shown but not editable there, since that setting belongs to the loop
- The frame grid collapses, and scrolls once it outgrows four rows, so a hundred-frame loop no longer owns the canvas. Collapsed state is saved with the workflow, and the header keeps reporting how many frames are locked or bypassed
**Library and organisation**
- Categories get an icon picker, and the icon follows the category everywhere it appears
- Export and import pickers gain cross-bucket search and per-row detail (`$variable`, option counts)
- Copy payload emits an importable envelope, stamped with its schema version
- Re-link matches bundles on child content rather than only a stored hash, and offers itself for modules that have no hash at all
- An unlinked bundle now reads as missing rather than modified, and reset-to-snapshot refuses to empty one
**Chips and references**
- Nested `@{uuid}` references are discovered even when written outside a wildcard payload
- Reference hovers name the pool they counted and flag drift against the library
- Wildcard option chips get the same hover card as every other surface
- Sub-category filter state is derived from the parsed expression, so the chips match what the filter actually does
- A reference to a module you have deleted from the library now reads as broken. It used to keep the deleted module's name and colour, and its hover card quoted the option count the module had before it was deleted — the node badge said the reference was broken while the chip inside the editor disagreed
**The manager**
- **What's new** moved to its own page, reached from the topbar with a dot when there is something unread. It is also the only place to read the notes for the version you are running — the update pill only exists while a newer one is available
- The update check no longer burns through GitHub's hourly allowance. It was making one request per page load per consumer, so a few dozen reloads could exhaust the quota for everything else on that connection; results are now reused for six hours and a refusal is honoured rather than retried
**Editing and layout**
- Fixed-value and combine fields grow with their content, with a corner grip that stays reachable and a manual drag that overrides the auto height
- A scrollable field no longer hands its scroll to the page behind it
- Rule previews truncate with an ellipsis instead of being clipped or faded, and long values wrap
- Tag menus stay inside the viewport, keep their own scroll, and fold by axis
- Dropdowns say "type to filter", which they have always supported
- The save shortcut reads `Ctrl` on Windows and Linux instead of a Mac-only glyph
- Test-runner histogram rows are banded so a row reads across its columns, and its module picker survives duplicate names
**Performance and correctness**
- Canvas polling is roughly eight times cheaper on a large graph — the walkers now share one parse instead of re-parsing a 294 KB widget value ten times per node every cycle (~21% of a core down to ~2.6%)
- Wildcard snapshots refresh when the window regains focus instead of waiting out a timer, and expire so the canvas stops drifting from the library
- The Prompt Cleaner no longer rewrites `embedding:name` or `<lora:name:1.0>` references — punctuation stripping renamed embeddings ending in `_`, and fuzzy dedupe dropped one of two versioned files
- Variable override counts report writers rather than write statements, so a module that creates a variable is no longer described as overriding writes that never happened
</details>
<!--
HOW TO WRITE THIS FILE
Order, and nothing else:
Headline one sentence, what this release is about
### Highlights 4-5 max
<!- /modal -> the update dialog stops rendering here
<details> Also in this… grouped one-liners, collapsed
### Upgrade notes only when the reader must act; delete otherwise
— keep this OUTSIDE the <details>, it needs seeing
This file IS the release body — the compare link is appended automatically and
the per-commit list is deliberately not included. It is consumed at release
time and cleared afterwards, so anything left here ships.
RULES
1. Highlights are capped at 4-5. The cap is the mechanism: it is what keeps a
6-commit release and an 80-commit release roughly the same height. If a
sixth feels essential, something else was not a highlight.
2. A highlight passes one of three tests:
- new capability — you can do something you could not before
- wall removed — something that blocked you now works
- surprising — behaviour changed in a way you should not meet alone
Polish, truncation, layout and invisible perf fail all three.
3. Commit count is NOT a test. The categories icon picker was two commits and a
real feature; `ui` was nine commits and almost entirely polish.
4. The tail is grouped by area, one line each, no bold-lead paragraphs. Group
names are free-form — use whatever the release actually contains. It sits in
a <details> so a long release does not double the page; put the count in the
summary so the reader knows what they are opening. That number is written by
hand here and can drift — the update dialog computes its own from the same
bullets, so if the two disagree, this one is wrong. Note also that collapsed
text is not reliably reachable by browser find-in-page, which is the cost.
5. Write what changed for the user, not what changed in the code. Name the
symptom, not the fix: "the field went blank" beats "guarded a null deref".
6. Perf belongs in the tail WITH its numbers, so the people it affects
A correctness fix for held modules on multi-frame runs, plus a set of tools for reconnecting workflow items to your library.
- **Held modules stay held for the whole run.** On a multi-frame sequence, a module set to **Hold across run** could quietly re-roll after the first frame — a held outfit or location would change mid-sequence — and every frame after the first filled the debug panel with constraint warnings. Held picks now carry through every frame, so constraints that depend on them keep applying, cross-node holds stay put, and the warning flood is gone.
- **Re-link items that lost their library connection.** When a re-import gives a library entry a new id, the copy in your workflow stops matching it: no drift, no **Edit library entry in SPA**, and saving creates a duplicate. **Push to library** now offers **Re-link to an existing library entry** when it finds one holding the same content — picking it automatically when there's exactly one match, or letting you choose from a list you can search by name *or* id. Works for bundles too.
- **Disconnected items now show as drifted** instead of looking like local-only rows. That means the **refresh drifted** button reconnects them in one click, and the library link, drift dot and refresh action all start working again.
- **"Reset to library snapshot" can no longer empty a bundle.** If the bundle wasn't linked to a library entry, or the snapshot came back empty, reset used to replace your modules with nothing. It now refuses and explains why, leaving the bundle untouched.
- **Importing content you already have offers to link it.** When an import contains an item identical to one already in your library under a different id, it's flagged **IN LIBRARY** with the matching entry named, and you can either link to it — references follow to the existing entry — or import the copy anyway. Nothing is linked or overwritten without you choosing.
- **Every edit modal shows the item's id.** A small chip in the header, click to copy — the same id that `@{...}` references, constraint sources and library rows all match on.
- **Nested references and variables render as chips** in derivation rule values and constraint exceptions, instead of showing raw text inside `{a|b}` braces. Exception values also get a proper picker of real option values rather than a free-text box.
- **Hover any reference chip** to see what it resolves to: its id, its sub-category filter in plain language, and how many options currently match — read live from your library, so the count moves when the library does.
- **Search by id.** Pasting an 8-character id into a search box now finds the item, in the manager lists and in the remap / reattach pickers. Previously only names matched, which was useless when two entries shared one.
- **Long values wrap** in the derivation override boxes instead of being clipped at the edge of the field.
---
<details>
<summary><b>📋 Full changelog</b> — click to expand the per-commit list</summary>
* Merge pull request #11 from DumiFlex/fix/held-constraint-registration ([fd4c501](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/fd4c501)), closes [#11](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/issues/11)
* chore(size): raise total bundle budget to 461 KB ([3f45b26](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/3f45b26))
* fix(bundle): never let "Reset to library snapshot" silently empty a bundle ([78297c4](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/78297c4))
* fix(chips): render nested refs + vars in derivation and exception surfaces ([a64e56d](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/a64e56d)), closes [label/#option](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/issues/option)
* fix(engine): carry held modules' frame-0 constraint state to later frames ([1b32a8a](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/1b32a8a))
* fix(linkage): surface drift for a library-uuid module with an empty local hash ([bb5f6b8](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/bb5f6b8))
* fix(search): match modules, bundles and templates by id as well as name ([44d0ca2](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/44d0ca2))
* feat(chips): hover card on nested-ref and variable chips ([699deda](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/699deda))
* feat(editors): show module identity in edit-modal headers + wrap long values ([5a83e61](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/5a83e61))
A bug-fix release for the in-app updater and name validation.
- **Fixed an updater downgrade.** On 2.10.0, clicking **Update Now** could install an *older* version — it asked ComfyUI Manager for "latest" against a stale cache. The updater now installs the exact new version and refuses to ever move backwards.
- **The update badge appears right away** after **Check now** — no page refresh needed.
- **Cleaner release notes** in the update dialog (proper formatting instead of raw `<details>` tags).
- **Names are validated as you rename them.** Renaming a sub-category or a variable now enforces the same rules as creating one, so invalid names (spaces, reserved characters) are caught immediately instead of failing later on save.
---
<details>
<summary><b>📋 Full changelog</b> — click to expand the per-commit list</summary>
* Merge pull request #10 from DumiFlex/fix/updater-downgrade ([a2e93fe](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/a2e93fe)), closes [#10](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/issues/10)
* fix(manager): resolve inline multi-pick {N-M$$sep$$…} in the test runner ([8dcef0f](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/8dcef0f))
<summary><b>📋 Full changelog</b> — click to expand the per-commit list</summary>
* fix(derivation-modal): absolute max-height for the rules scroll (revert flex) ([5d715fb](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/5d715fb))
* fix(derivation-modal): pin rule cards so the rule list actually scrolls ([fc9d8a8](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/fc9d8a8))
* fix(derivation-modal): scroll the rule LIST, not the whole modal ([6f664ce](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/6f664ce))
* fix(engine): derivation hold freezes each branch roll, not the branch choice ([df76abd](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/df76abd))
* fix(engine): hold the resolved VALUE across iterations, not just the seed ([58c5b27](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/58c5b27))
* fix(injector): keep custom pin labels with the socket on drag-reorder ([41fae1e](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/41fae1e))
* fix(injector): reconstruct collapsed-wire labels from data, not the dead stash ([0ede205](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/0ede205))
* fix(injector): repair collapse-wire labels corrupted across a reload ([0281b8e](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/0281b8e))
* fix(injector): right-align the type pill on label-less ref/slot rows ([bf61f64](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/bf61f64))
* docs(spa): describe hold as a value freeze (constrained picks + nested refs) ([1b3e4aa](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/1b3e4aa))
<summary><b>📋 Full changelog</b> — click to expand the per-commit list</summary>
* fix(context): add hover states to the per-kind edit modal footer buttons ([b292699](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/b292699))
* fix(context): capture the loop's per-frame seeds so the lock pins the previous roll ([b33afd8](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/b33afd8))
* fix(context): clear redundant frame lock-null override when the base unlocks ([f38a316](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/f38a316))
* fix(context): coerce disabled_frames to int set and guard frame toggle ([65683ae](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/65683ae))
* fix(context): modal lock button pins the rolled seed via injected resolver ([e56fd22](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/e56fd22))
* fix(context): name the disabled toggles in the per-frame runtime hint + wrap loop frame chips ([2fb853f](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/2fb853f))
* fix(context): per-frame enable overrides base enabled (frame_enabled) ([6eb4b73](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/6eb4b73))
* fix(context): per-frame seed lock captures that frame's own rolled seed ([25388b4](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/25388b4))
* fix(context): per-frame seed lock computes the frame's real seed from the loop ([1f164df](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/1f164df))
* fix(context): restrict per-frame overrides to an allowlist of meaningful fields ([bb5e84d](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/bb5e84d))
* fix(context): resync editor draft on frame revert + restyle the banner for readability ([39fdb6f](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/39fdb6f))
* fix(context): scope the wrapping grid to the frame chips only ([c48aafb](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/c48aafb))
* fix(context): stack the frame banner above the editor card instead of beside it ([3c492f1](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/3c492f1))
* fix(context): sweep redundant frame lock-null when base unlocks via the modal ([e1885a3](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/e1885a3))
* fix(engine): apply iteration_overrides for generic-object modules ([942834d](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/942834d))
* fix(engine): include disabled_frames in the generic-object snapshot keys ([03796c5](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/03796c5))
* fix(engine): stop double-shifting the per-iteration override seed ([3527ada](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/3527ada))
* fix(extension): read loop seed and count as numbers for per-frame seed lock ([67a09df](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/67a09df))
* feat(context): add hold-across-run toggle to the runtime sections ([9663636](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/9663636))
* feat(context): add lock-previous-seed to the iteration-seed modals ([c7c867e](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/c7c867e))
* feat(context): add pure frame-override helpers ([7b416ad](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/7b416ad))
* feat(context): disable run-level controls while editing a frame ([1822297](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/1822297))
* feat(context): frame banner with revert-to-base in the module editor ([79cf385](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/79cf385))
* feat(context): held and per-frame override row badges ([e93f7ba](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/e93f7ba))
* feat(context): make the row quick-lock act on the active frame ([21f2850](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/21f2850))
* feat(context): per-frame enable/disable via disabled_frames ([8a9dc9e](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/8a9dc9e))
* feat(context): redirect edits into iteration_overrides when a frame is active ([4e71e04](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/4e71e04))
* feat(engine): combine honors hold seed_scope ([8871a28](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/8871a28))
* feat(engine): fixed_values honors hold seed_scope ([15c1ade](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/15c1ade))
* feat(engine): thread a hold seed and loop index into the pipeline run ([0f7aaab](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/0f7aaab))
* feat(engine): wildcard honors hold seed_scope, locked_seed still wins ([072e4e7](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/072e4e7))
* feat(manager): snapshot source/target tag_groups into published constraints ([ff4d8fa](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/ff4d8fa))
* feat(types): add seed_scope and iteration_overrides to module config ([8910b98](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/8910b98))
* revert(context): drop per-frame seed capture, superseded by double-shift fix ([91b5f75](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/91b5f75))
* refactor(context): unify frame-hint markup and add false-case coverage ([8f696d6](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/8f696d6))
* feat(seedlist): add paste-to-replace locks from copied text ([fa73750](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/fa73750))
* feat(seedlist): alt-click copy to grab only the locked seeds ([589f45e](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/589f45e))
* feat(seedlist): apply per-iteration seed locks to the output series ([fd2cdcb](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/fd2cdcb))
* feat(seedlist): flash a copied indicator on the modal copy button ([34ec18f](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/34ec18f))
* feat(seedlist): preview effective base/count/strategy from the wired loop ([68910bf](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/68910bf))
* feat(seedlist): show out-of-range locks dimmed but still editable ([b49a579](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/b49a579))
* feat(shared): ts mirror of loop seed derivation with py-ts parity corpus ([cc64ca3](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/cc64ca3))
<summary><b>📋 Full changelog</b> — click to expand the per-commit list</summary>
* fix(api): keep duplicate children when creating or updating bundles ([c1f45a3](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/c1f45a3))
* fix(constraint): drop matrix scroll-container padding that leaked scrolled cells ([d3e25b7](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/d3e25b7))
* fix(constraint): stop scrolled cells bleeding through the frozen matrix headers ([4098009](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/4098009))
* fix(manager): decimal option probabilities and distinct sub-category group colors ([11d205b](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/11d205b))
* feat(constraint): group the canvas matrix axes like the SPA ([538db06](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/538db06))
* feat(manager): author and save bundles directly in the manager ([a77e60b](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/a77e60b))
* feat(manager): group constraint matrix axes with header chips and column bands ([c0f354c](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/c0f354c))
* feat(manager): label the matrix ungrouped axis run as "uncategorized" ([eac852f](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/eac852f))
* feat(manager): show uuid + option meta in reattach pickers to tell duplicates apart ([0bbf150](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/0bbf150))
* feat(manager): type-to-filter all dropdowns ([b3537ad](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/commit/b3537ad))
- **Subgraph badges** — `extension/subgraph-badge.ts` attach `LGraphBadge` (via `window.LGraphBadge`) to any SubgraphNode containing WP nodes. Badge surface worst inner conflict severity with human label (e.g. `missing $foo`, `2 conflicts`). Wire via `nodeCreated` + `loadedGraphNode` hooks — `beforeRegisterNodeDef` does NOT fire for SubgraphNodes.
- **Conflict scanner** — advisory only; never block execution. Runtime last-write-wins. Rule types: `shadows_upstream` (info), `duplicate_variable` (warning), `missing_template_variable` (warning), `constraint_source_missing` / `constraint_target_missing` (warning — uuid not in catalog), `constraint_orphan_source` (warning — no source instance UPSTREAM), `constraint_orphan_target` (warning — the constraint's reach selector covers ZERO reachable downstream instances; per-selector, NOT count-aware — overlapping constraints may freely share an instance). Engine emits runtime warnings `constraint_never_applied` (the reach matched nothing at runtime) and `constraint_partial_reach` (a `next N` / `pick` reach matched fewer instances than requested).
- **Constraint reach (SP3)** — each constraint carries a `target_select` reach selector: `{mode: "first"|"next"|"all"|"pick", count?, picks?}`, default `all`. Every constraint whose reach covers a firing downstream target instance applies, COMBINED — per-pick × per-tag × per-constraint multiply, with `exclude` (factor 0) absorbing. No more one-shot/consumed-set: the engine counts per-constraint downstream hits in `ctx["__wp_constraint_hits__"]`. Reach is downstream-relative (counts from the constraint's own chain position) and cross-node + transitive (resolves `@{uuid}` at any depth). `pick` selects specific instances by `_uid` (direct top-level) or carrier `_uid` + option id (nested). The re-weight math is the pure `engine/modules/_constraint_math.py::combine_constraint_factor`, mirrored in TS at `src/manager/utils/constraint-math.ts` via the shared `tests/fixtures/constraint-corpus.json`. Published payloads using a non-default `target_select` stamp `schema_version = 4` (additive; community catalog v4).
- **Constraint reach (SP3)** — each constraint carries a `target_select` reach selector: `{mode: "first"|"next"|"all"|"pick", count?, picks?}`, default `all`. Every constraint whose reach covers a firing downstream target instance applies, COMBINED — per-pick × per-tag × per-constraint multiply, with `exclude` (factor 0) absorbing. Mode `only` (linked picks, schema v6) turns its row into an allow-list: when the source fires, a target with no rule of its own in that row is excluded (by value on an exception, by tag in a matrix row; a matrix `allow` cell is NOT a mention because editors show it as Neutral). No more one-shot/consumed-set: the engine counts per-constraint downstream hits in `ctx["__wp_constraint_hits__"]`. Reach is downstream-relative (counts from the constraint's own chain position) and cross-node + transitive (resolves `@{uuid}` at any depth). `pick` selects specific instances by `_uid` (direct top-level) or carrier `_uid` + option id (nested). The re-weight math is the pure `engine/modules/_constraint_math.py::combine_constraint_factor`, mirrored in TS at `src/manager/utils/constraint-math.ts` via the shared `tests/fixtures/constraint-corpus.json`. Published payloads using a non-default `target_select` stamp `schema_version = 4` (additive; community catalog v4).
- **Bundle-size gate** — entry `main.js` must stay ≤ 30 KB gzipped; total `js/` ≤ 250 KB. Pre-commit run `pnpm build:extension && pnpm size`. Raising budget require explicit PR discussion.
- **Coverage gate** — vitest v8 coverage with thresholds (lines/statements 50%, functions 40%, branches 65%). Anchored to current baseline; ratchet up alongside new tests.
- **Caching** — `WP_Context` + `WP_Debug` set `not_idempotent=True` so seed cycling always re-executes.
@@ -58,12 +58,13 @@ ruff check . # Python lint
## Frontend overview
- **Entry** `src/main.ts` → `js/main.js` (~1.6 KB gzip). Top-level await preload widget chunks so `getCustomWidgets` factories run sync (Promise return → `{widget: undefined}` and widget never mount). Register extension + lazy-import widget code only when ComfyUI hand matching node.
- **Lazy chunks** `src/widgets/{context,debug,assembler}.ts` — one mount glue per widget. Each `import()` become own asset chunk, plus sibling SFC chunk (`ContextWidget`, `DebugViewer`, `AssemblerHelper`).
- **Shared** `src/widgets/_shared.ts` expose `createDomWidgetHost`, JSON helpers (`parseWidgetJson`, `parseWidgetJsonWithRecovery` for corrupt-workflow recovery path), shared types. Largest shared chunk (`_shared`, ~33 KB gzip) is Vue runtime + plugin-vue helper, pulled in by every widget on first use.
- **Entry** `src/main.ts` → `js/main.js` (~4 KB gzip). One top-level `await import("./boot")` preload widget glue so `getCustomWidgets` factories run sync (Promise return → `{widget: undefined}` and widget never mount; ComfyUI does not await an async `getCustomWidgets`).
- **Boot chunk** `src/boot.ts` — everything registration + node creation need, re-exported from ONE module so it ship as ONE chunk (empty canvas = `main.js` + `boot-*.mjs`). Before, each preload was own `import()` and shared deps split out: 43 files. Only add what registration needs; anything reached by user action (modal, toast stack, subgraph badge) gets a `load*` helper in `boot.ts`, not an `import()` in `main.ts` (a chunk loaded from `main.ts` makes Rollup split vue + stores back out).
- **Widget glue** `src/widgets/*.ts` — one mount glue per widget, in the boot chunk. Each loads its SFC via `defineAsyncComponent` (`ContextWidget`, `DebugViewer`, `AssemblerHelper`, `RichTextInput`, …) so SFC chunks download only when a matching node exists.
- **Shared** `src/widgets/_shared.ts` expose `createDomWidgetHost`, JSON helpers (`parseWidgetJson`, `parseWidgetJsonWithRecovery` for corrupt-workflow recovery path), shared types. Lives in boot chunk with Vue runtime.
- **Graph + conflicts** `src/extension/{graph,conflicts,subgraph-badge,reactive,graph-events}.ts` — pure logic, no DOM. Imported by widgets, easy to unit-test isolated.
- **Reactivity** `extension/reactive.ts:reactiveFromGraph` — wires `onConnectionsChange` chain + 400ms polling fallback + `afterConfigureGraph` re-sync so widgets recompute on graph edits + workflow loads without flashing stale state.
- **Adding new widget**: (1) write SFC under `src/components/<name>/`, (2) add `src/widgets/<name>.ts` exposing `create(node, inputName)` that return `createDomWidgetHost(...)`, (3) wire in `src/main.ts` — either as `getCustomWidgets` entry (for inputs declared with matching widget-type) or via `beforeRegisterNodeDef → onNodeCreated` (for free-floating helpers). Use `import("./widgets/<name>")` so stay out of entry chunk + size gate keep holding.
- **Adding new widget**: (1) write SFC under `src/components/<name>/`, (2) add `src/widgets/<name>.ts` exposing `create(node, inputName)` that return `createDomWidgetHost(...)`, (3) re-export it from `src/boot.ts` and wire in `src/main.ts` — either as `getCustomWidgets` entry (for inputs declared with matching widget-type) or via `beforeRegisterNodeDef → onNodeCreated` (for free-floating helpers). SFC via `defineAsyncComponent`, never static import, so boot chunk stay small.
-`tolerant_drift_status TEXT` — `none` | `tolerant` | `strict`. Set by parseTolerantAsCurrentShape during install.
-`schema_migrated_at TEXT` — wall-clock stamp of last lazy migration step.
**Which number goes where** (three constants, one job each — don't collapse them):
- **`CURRENT_SCHEMA_VERSION` = 2** (`src/manager/import-export/migrations.ts`, mirrored in `engine/migrations/__init__.py`): head of the migration chain. Stays 2 because v3–v6 are additive and need no migrator.
- **`MAX_KNOWN_SCHEMA_VERSION` = 6** (same two files): the highest version this runtime reads + writes natively. Advertised to the community as `window.__wpcRuntime.schemaVersion` (`src/manager/main.ts`) and the ceiling above which `migrateImportEnvelope` refuses a pack.
- **Content stamp** (`schemaVersionForPayload` in `src/manager/import-export/single-row-publish.ts`): what publish sends — the LOWEST version the payload's features need (2 baseline, 3 SP2b range/`~` grammar, 4 non-default constraint `target_select`, 5 a wildcard `accepts` tag axis, 6 a constraint `only` rule).
A pack arriving from the community keeps the stamp the server stored for it (`CommunityDownload.schema_version`, fed to `wrapAsEngineExport` / the dependency downloader) so install migrates it from where it actually is. Never stamp a received pack with a constant. Local round-trips of live rows (e.g. `BundleEditor` extract) stamp `MAX_KNOWN_SCHEMA_VERSION`.
**The machine**:
- **Validator registry** (`src/manager/import-export/validators/`): one Zod validator per known`schema_version`. Strict at `≤ CURRENT_SCHEMA_VERSION`; future versions go through `parseTolerantAsCurrentShape` (additive-strip).
- **Validator registry** (`src/validators/index.ts:getValidator`): one Zod validator per shape-changing`schema_version` (v1, v2). v3–v6 didn't change a shape, so they validate against v2. Tolerant mode (`.strip()`) is for installing newer payloads (`parseTolerantAsCurrentShape`).
- **`parseTolerantAsCurrentShape(raw, currentVersion)`** (`src/manager/import-export/tolerant-parse.ts`): strips fields the current shape doesn't know, returns the projection that matches `currentVersion`. Used at install when source `schema_version > CURRENT`.
- **`migratePayload(payload, from, to)`** (`src/manager/import-export/migration-machine.ts`): forward-only chain. Each step is a registered function in the migrators map. `from > to` is illegal — no downgrades.
- **`migratePayload(payload, from, to)`** (`src/manager/import-export/migrations.ts`, beside the envelope-level `migrateImportEnvelope`): forward-only chain. Each step is a registered function in the migrators map. `from > to` is illegal — no downgrades.
- **`lazy_migrate_row(row, currentVersion, migrators, validators)`** (`engine/db/lazy_migrate.py`): reads `original_payload_json` (or `payload` if absent), walks the migrator chain to `currentVersion`, validates, writes back. Bulk-at-boot runner is eager iteration of this routine.
- **Install decision tree** (`src/manager/import-export/install.ts`): branches on `source_schema_version` vs `CURRENT_SCHEMA_VERSION`:
-`>` and tolerant-only diff: parseTolerantAsCurrentShape, mark `tolerant_drift_status='tolerant'`, insert.
-`>` and breaking-future diff (per catalog `is_breaking_from_previous` AND-fold across the interval): refuse install with a clear error.
**Server probe**: `engine-export-wrap.ts:ENGINE_SCHEMA_VERSION`is the sister's pinned CURRENT — it ships in the sister bundle, not fetched from server. The host bridge install path reads it from `window.__wpcRuntime.schemaVersion`. Server-first deploy ordering (see community CLAUDE.md) means the community catalog always reflects shapes ≥ sister's CURRENT.
**Server probe**: the host bridge advertises `MAX_KNOWN_SCHEMA_VERSION`as `window.__wpcRuntime.schemaVersion`; it ships in the sister bundle, not fetched from server. The community embed refuses to install a pack stamped above it. Server-first deploy ordering (see community CLAUDE.md) means the community catalog always reflects shapes ≥ sister's MAX_KNOWN.
### Bumping `schema_version` (the proper way)
When a payload shape change lands (not a row-column change — those don't bump schema):
1.**Add the new shape's validator.** New file under `src/manager/import-export/validators/v<N>.ts` exporting a Zod schema. Register in `validators/index.ts`.
2.**Add the migrator step.** In `src/manager/import-export/migration-machine.ts`, register `migrators[N-1 → N]: (payload) => ...`. Forward-only. The function is pure — no side effects.
3.**Add fixtures.**`src/manager/__tests__/import-export/fixtures/v<N>/` — at minimum: a `valid-strict.json`, a `from-v<N-1>-migrated.json` round-trip case, and one `breaking-shape.json` if the bump is breaking.
4.**Bump the constant.**`CURRENT_SCHEMA_VERSION` lives in the validator registry. Bump it to `N`. Also bump `ENGINE_SCHEMA_VERSION` in `src/manager/components/engine-export-wrap.ts`.
**Additive bump** (an optional field, new enum value or new text grammar an old runtime can safely lack — v3, v4, v5, v6 all were):
1.**Add the version constant** next to `TAG_AXES_SCHEMA_VERSION` / `CONSTRAINT_ONLY_SCHEMA_VERSION` in `migrations.ts` (and `engine/migrations/__init__.py`), with a comment saying what triggers it.
2.**Teach `schemaVersionForPayload`** AND its Python mirror `engine/migrations/stamping.py` to return it only when the payload actually uses the feature (structural walk, bundle children + instance overrides included), and add cases to `src/manager/__tests__/import-export/publish-stamping.test.ts` + `tests/engine/test_schema_stamping.py`.
3.**Bump `MAX_KNOWN_SCHEMA_VERSION`** in `migrations.ts` AND `engine/migrations/__init__.py`, and update the drift guard in `schema-version-fork.test.ts` to exercise the new highest stamp.
4.**Make sure the strict validator keeps the new field** (it strips unknown keys) — `src/validators/module/v2.ts` + the engine-parity test.
5.**Catalog row** — step 7 below. `CURRENT_SCHEMA_VERSION` does not move.
**Shape-changing bump** (needs a migrator):
1.**Add the new shape's validator.** New file under `src/validators/module/v<N>.ts` (and `bundle/` if needed). Register every subtype at `N` in `src/validators/index.ts`.
2.**Add the migrator step.** In `src/manager/import-export/migrations.ts`, add to `MIGRATION_CHAIN` (envelope) and/or `registerMigrator` (per row), and mirror it under `engine/migrations/`. Forward-only. The function is pure — no side effects.
3.**Add fixtures.** Under `src/validators/fixtures/v<N>/` — at minimum a strict-valid module per subtype, plus a migrated-from-v<N-1> round-trip case in `src/manager/__tests__/import-export/migration-machine.test.ts`.
4.**Bump the constants.**`CURRENT_SCHEMA_VERSION` and `MAX_KNOWN_SCHEMA_VERSION` to at least `N`, in both `migrations.ts` and `engine/migrations/__init__.py`.
5.**Write the migration test.**`tests/engine/db/test_lazy_migrate.py` should cover v<N-1>→v<N> round-trip + the breaking-future path if applicable.
6.**Run `pytest tests/engine/ -q && pnpm test` until green.** Sister pre-commit hook (~2 min) also runs lint + typecheck + build + size; expect that wait.
7.**Coordinate the community-side catalog row.** Community web's `schema_catalog` table gets the matching `(version, is_breaking_from_previous, notes)` row + a deploy that lands BEFORE sister's PR merges. See community CLAUDE.md "Bumping the schema" for the server side.
8.**Sister deploys after server.** Once catalog HEAD ≥ sister's CURRENT, sister can safely refuse breaking-future shapes.
8.**Sister deploys after server.** Once catalog HEAD ≥ sister's MAX_KNOWN, sister can safely publish the new stamp and refuse breaking-future shapes.
### Validator ↔ engine parity (DON'T skip)
@@ -122,6 +141,9 @@ this:
shape to `src/validators/fixtures/engine-parity/*.json`.
-`src/validators/__tests__/engine-parity.test.ts` asserts the **strict**
community validator accepts every one of those fixtures.
-`tests/test_engine_parity_fixtures.py` re-runs the dump in memory and fails
pytest when a committed fixture is stale, so forgetting the script is
caught in CI.
**Any time you change an engine module payload shape** (a `*_handler.py`
`validate_payload`, or what the editor stores), run
<img src="public/images/docs/flow-intro.svg" alt="Wildcard, Fixed Values, Combine, Derivation and Constraint modules resolve inside WP Context, which emits named $variables that fill the WP Prompt Assembler template, which CLIP Encode turns into conditioning" />
</p>
## What it does
@@ -33,6 +33,7 @@ Stock ComfyUI prompt nodes either take a single literal string or pick from a fl
- **Persistent library** — a manager SPA backed by SQLite stores reusable modules, frozen bundles, prompt templates, and a category tree. Browse / edit / fork / push from the canvas.
- **Inspector** — `WP Debug` shows the post-run snapshot, per-module trace, per-wildcard picks, and the conflict-scanner warnings.
- **Type-coercion helpers** — `WP Var → Int / Float / Bool` parse typed values out of any `$variable` so wildcards can drive image width, step count, sampler cfg, conditional switches.
- **Works on both renderers** — the legacy canvas and ComfyUI's Nodes 2.0 Vue renderer, including switching between them with a workflow already open.
## Installation
@@ -105,7 +106,7 @@ Full module reference: [Modules wiki page](https://github.com/DumiFlex/ComfyUI-W
## Looping a chain — one click, N coherent prompts
<p align="center">
<img src="public/images/docs/flow-loop.svg" alt="WP Context Loop + WP Seed List → KSampler — both lists fan out in lockstep" />
<img src="public/images/docs/flow-loop.svg" alt="WP Context Loop drives WP Context and the Prompt Assembler; CLIP Encode turns each prompt into conditioning for KSampler, while WP Seed List supplies the matching seed directly" />
</p>
Drop `WP Context Loop` before your `WP Context` and pair it with `WP Seed List` for distinct sampler seeds. Both lists fan out in lockstep so iteration N's prompt always pairs with seed N. Each iteration carries its own `$iteration` / `$iteration_total` for in-template labelling (`frame 1 of 4 — a fox`). See [Concepts → Seeds and loops](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/wiki/Concepts#seeds-and-loops).
@@ -143,9 +144,30 @@ See [Nodes → WP Debug](https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline/w
This extension works entirely offline. It makes **one** outbound request, and only when you ask for it:
| What | When | Where to |
| --- | --- | --- |
| Booru tag list for the optional value autocomplete | Only when you click **Download** in Settings → Tag autocomplete | `github.com` → `objects.githubusercontent.com`, our own release asset |
Nothing is fetched at startup, on a schedule, or as a side effect of anything else. Delete the file and the feature simply turns off. The update check in Settings talks to the GitHub releases API on the same terms — you can switch it off, and it never runs without you.
Because ComfyUI serves its API without authentication, that download endpoint is deliberately built with nothing to steer:
- **The URL is a constant.** There is no URL parameter — the request body is ignored — so it cannot be pointed at your internal network or a cloud metadata address.
- **Redirects are checked at every hop** against a fixed host list, because GitHub serves release assets via a CDN. A redirect anywhere else is refused mid-chain.
- **The destination is computed server-side** from ComfyUI's user directory plus a fixed filename. No caller input reaches the path, and a symlink sitting at that path is refused rather than followed.
- **The response is size-capped while streaming**, so a hostile or corrupted reply cannot fill your disk. `Content-Length` is checked but never trusted alone.
- **One download at a time**, so the endpoint cannot be used to start many large fetches at once.
- **The file is parsed before it replaces anything.** A reply that is not a readable tag list leaves your existing one untouched, and the final move is atomic.
The reasoning is kept next to the code in [`wp_api/_tag_download.py`](wp_api/_tag_download.py), and each restriction has a test in [`tests/wp_api/test_tag_download.py`](tests/wp_api/test_tag_download.py).
## Status
Active development. Versioned releases with [semantic-release](https://github.com/semantic-release/semantic-release) — every merged commit on `main` either ships a release or stays as `next` until the next breaking / feature change rolls one. Bundle-size + test gates run on every PR.
Active development. Versioned releases with [semantic-release](https://github.com/semantic-release/semantic-release) — every merged commit on `main` either ships a release or stays as `next` until the next breaking / feature change rolls one. Bundle-size + test gates run on every branch push and PR.
<svgxmlns="http://www.w3.org/2000/svg"viewBox="0 0 880 202"width="880"height="202"role="img"aria-label="Wildcard, Fixed Values, Combine, Derivation and Constraint modules resolve inside WP Context, which emits resolved dollar-variables that fill the WP Prompt Assembler template, which CLIP Encode turns into conditioning">
<svgxmlns="http://www.w3.org/2000/svg"viewBox="0 0 980 240"role="img"aria-label="WP Context Loop emits N prompts and feeds WP Seed List N seeds; both fan out into KSampler in lockstep">
<svgxmlns="http://www.w3.org/2000/svg"viewBox="0 0 880 286"width="880"height="286"role="img"aria-label="WP Context Loop drives WP Context and the Prompt Assembler to produce N prompts, CLIP Encode turns them into conditioning for KSampler, and WP Seed List supplies the matching seed for each iteration directly to KSampler">
"Wildcard, Fixed Values, Combine, Derivation and Constraint modules resolve inside WP Context, which emits resolved dollar-variables that fill the WP Prompt Assembler template, which CLIP Encode turns into conditioning",
"WP Context Loop drives WP Context and the Prompt Assembler to produce N prompts, CLIP Encode turns them into conditioning for KSampler, and WP Seed List supplies the matching seed for each iteration directly to KSampler",
<spanv-if="ctx?.isHeld(module)" class="wp-mod-badge wp-mod-badge--clash" data-test="mod-held" title="Held across the run">held</span>
<spanv-if="ctx?.isOverriddenOnFrame(module)" class="wp-conflict-badge wp-conflict-badge--warning" data-test="mod-override" title="Overridden on this frame">override#{{(ctx.currentFrame.value??0)+1}}</span>
<spanv-if="ctx?.frameEnableOverride(module) === 'off'" class="wp-mod-badge wp-mod-badge--missing" data-test="mod-frame-disabled" title="Disabled on this frame">off#{{(ctx.currentFrame.value??0)+1}}</span>
<spanv-else-if="ctx?.frameEnableOverride(module) === 'on'" class="wp-mod-badge wp-mod-badge--on" data-test="mod-frame-enabled" title="Enabled on this frame">on#{{(ctx.currentFrame.value??0)+1}}</span>
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.