CD · Project Lock

Every multi-shot video project I've ever seen dies a quiet death because the same facts live in five different places. The title is in the filename. The aspect ratio is whatever the first sampler happened to be set to. The fps is a guess someone made in a comment node three weeks ago. Then the fifth shot comes out 16:9 when the first four were 9:16, and nobody can say when it broke. CDProjectLock is the author's answer to that: one node that pins the project-level facts down as a single, hash-linked record every other node in the pack can reference.

It's part of Continuity Director, a 20-node pack for repeatable AI video production, and this is the node the whole thing hangs off. The name is honest about what it does: it "locks" project state so a change anywhere is detectable everywhere.

What you actually set

Only a handful of fields matter, and they're all on the widget:

• project_id - your identifier, like project-001. It gets normalized (spaces and junk become dashes), so it's your stable key.
• aspect_ratio - a dropdown of the usual suspects: 16:9, 9:16, 1:1, 4:3, 21:9.
• fps - an integer from 1–240, default 24.
• interface_language - en, zh-CN, or bilingual. This is a nice touch: the pack's whole UI is bilingual, and the choice is recorded in the project record rather than only in browser settings.
• title and notes are just human-readable context.

How the "lock" actually works

Under the hood it calls a build_lock helper that wraps your data into a small structured record - schema, kind, id, data - and then computes a SHA-256 hash of the whole thing. That hash is the lock. Every node in the pack that produces a record does this, and it's the same trick you use for reproducible anything: any change to the data, even whitespace, changes the hash, so a drifted setting stops being invisible.

You get three outputs: project (a CD_PROJECT wire that only connects to other Continuity Director nodes - that's the point), project_json (the record as text, your escape hatch to any other part of the workflow), and project_hash (the fingerprint). Feed project into CDManifestBuilder and, optionally, into CDShotLock; keep project_json around if you want to log or compare it with CDContinuityReport.

Installing it

Continuity Director is a dependency-light install - which in this ecosystem is worth celebrating. There are no model files, no API keys, and its requirements.txt literally reads "No mandatory third-party Python dependencies." It's pure standard library.

In ComfyUI Manager, search "Continuity Director" under Install Custom Nodes and restart. Or, from a terminal:

cd ComfyUI/custom_nodes
git clone https://github.com/xinjian0101/continuity-director.git ComfyUI-ContinuityDirector

Restart ComfyUI and you'll find the nodes under their CD · names, plus a Continuity Director sidebar with an "Add starter chain" button that lays out the full production path for you. To update later: cd ComfyUI/custom_nodes/ComfyUI-ContinuityDirector && git pull.

Where people get burned

The habit to break: editing the lock mid-run and expecting the rest of the chain to silently keep up. Because everything is hash-linked, changing fps here changes the project hash, which ripples into any manifest that referenced it. That's not a bug - it's the change detection working. If you need to evolve a project cleanly, do it deliberately and re-export, rather than tweaking a widget in a live graph.

One honest caveat about the whole pack: it's young (v0.8.42, actively maintained preview), so treat its JSON records as the source of truth and keep exported packages, since public node behavior can shift between minor versions. It's a planner and a record-keeper - it will not make your model pixel-perfect. But as the top of the chain, it's the difference between a production you can reproduce and one you can only remember.