mirror of
https://github.com/Comfy-Org/ComfyUI_frontend.git
synced 2026-07-11 01:28:03 +00:00
95ced4c6ef
Architecture documentation for the custom-node regression suite, written as design views rather than an implementation dump: - eight responsibility-level views: system context, building blocks, the node-definition pipeline, the execution flow, the persistence check, event attribution, the evidence model, and the CI deployment view; every diagram box names a responsibility or concept, arrows carry meaning, and decision points read in plain English - a one-minute What/Why/How opening with the three explicit non-goals (output semantics, frontend-virtual nodes, hour-scale soak) and a clearly labeled scale snapshot so instance numbers never read as properties of the design - a 12-row design-decisions table with honest trade-offs (why a real browser at all, why the backend serves the built frontend, one worker, disabled execution cache, pinned pack versions, one-row extensibility, per-tier renderer policy, mechanism-carrying exceptions, the two-way baseline, batch+bisect, and the scope line), plus the curated-workflow fixture named as the deliberate extension seam - a 14-item gotchas reference, each entry in symptom / root cause / defense / which-team-concern-it-answers form, with named nodes kept only as worked examples of their class - one implementation map section where architecture names meet code symbols, covering every building block including the orchestrator and the evidence ledgers - the workflow's rotted sharding comment fixed (suite duration and the real shard trigger) Grounded on the C4 model's published guidance, reviewed by an independent architect pass (two view-coherence gaps found and fixed) after three earlier Opus review passes on content accuracy. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
GitHub Workflows
Naming Convention
Workflow files follow a consistent naming pattern: <prefix>-<descriptive-name>.yaml
Category Prefixes
| Prefix | Purpose | Example |
|---|---|---|
ci- |
Testing, linting, validation | ci-tests-e2e.yaml |
release- |
Version management, publishing | release-version-bump.yaml |
pr- |
PR automation (triggered by labels) | pr-claude-review.yaml |
api- |
External Api type generation | api-update-registry-api-types.yaml |
i18n- |
Internationalization updates | i18n-update-core.yaml |
Documentation
Each workflow file contains comments explaining its purpose, triggers, and behavior. For specific details about what each workflow does, refer to the comments at the top of each .yaml file.
For GitHub Actions documentation, see Events that trigger workflows.