ba39cb3658
* refactor(nodes): drop keyframe_batch alias from Easy Image Batch The keyframe_batch input was a deprecated alias of keyframes_insert, added in 0.4.1 during PR #246 review to keep pre-rename workflows loading. The old name only ever existed in unreleased dev builds before the rename, so no published workflow depends on it and the alias only cluttered the node with a second IMAGE input. Remove the input, its parameter, and the alias-routing fallback; the node now exposes a single keyframes_insert insert input. Tests and the behavior spec updated; CHANGELOG notes the removal under [Unreleased]. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * docs(policy): make backward compatibility opt-in for Koolook nodes Invert the default: backward compatibility is no longer a standing constraint for Koolook-created nodes (the root k_*.py custom nodes). By default, make the cleanest change — rename/drop/reorder IDs, inputs, and outputs freely, no deprecation aliases or _v2 suffixes. Compatibility with saved workflows is only preserved when the maintainer explicitly says "check backward compatibility". Forks are explicitly excluded: anything under forks/ (including the Koolook-original nodes exposed via SKIP_VERSION_SUFFIX) keeps full back-compat discipline by default, no request needed. The __koolook_vX_Y_Z collision suffix always applies. Scoped across the binding instruction files and skills: CLAUDE.md, copilot-instructions, node-versioning.md, versioning.md, and the preflight-release / add-external-fork / tdd skills. The preflight workflows check is reframed as a drift detector for Koolook IDs and a hard back-compat gate for fork IDs. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * docs: clarify keyframe_batch alias removal * fix: retain keyframe_batch compatibility alias --------- Co-authored-by: AI Machine <ai.machine@x.baconcph.com> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Design Proposals
Small, reviewable UI mockups for decisions that benefit from visual comparison before they land in the runtime sidebar.
| File | Purpose |
|---|---|
sidebar-icon-proposals.html |
Side-by-side icon direction mockup for the Kforge Labs sidebar action rows |
sidebar-icon-proposals.png |
Rendered preview of the current icon proposal state |
update-banner.html |
Footer banner layout proposal for a discreet "Update Available" release-notes link |
snapshot-dialogs-redesign.md |
Scope sketch + Mermaid flow for consolidating Settings cog into Save / Load dialogs (+ autosave-newest fix) |
snapshot-dialogs.html |
Side-by-side mockups: current vs. proposed Snapshot toolbar, Save dialog, Load dialog, and autosave YES/NO modal |
How these mockups are used
These files are the visual spec for any implementing PR. When code lands that implements one of these designs, the agent doing the work must:
- Render the implementation in a real browser —
dev-syncto the live ComfyUI install, or a local static server (e.g.python3 -m http.server) for standalone HTML. - Screenshot every state shown in the corresponding mockup (default, hover, expanded, selected, error, …).
- Visually diff the screenshots against the mockup before requesting review. Either match the design or document the deviation with a rationale.
The maintainer is never the first reviewer of rendered output — visual verification is a precondition for review, not something to ask the maintainer to do. See the project CLAUDE.md under "Visual verification for design-driven implementation" for the full rule.