Tests Sanity

Two structural harnesses guarding the parts of the package that runtime tests can't reach: the editor files and the package itself. They're generated-per-target rather than numbered groups, so this page describes what each category of check protects.

html-sanity.js (49 checks)

Editor .html files can't execute in a harness, but their structure is checkable — and, more importantly, their agreement with the runtime is checkable. Per node type:

Check	Why it exists
Three blocks present, correctly named	Every editor file must contain a registration script, a config template, and a help panel whose data-* names match the node type — a mismatch means a node that installs but can't be configured.
Registration JavaScript parses	The embedded editor JS is syntax-validated (parsed, not executed) — a typo here breaks the whole palette silently.
Registers the correct type, with the agreed ports	Port counts are pinned per node (4/3/1/1 outputs) — the output model is public API, and an accidental port change breaks users' wired flows.
Family orange	All four nodes carry the same #F0954F — cosmetic, but family identity is part of the product.
Defaults ↔ runtime keys	The editor's defaults must exactly match the config keys the runtime actually reads (mirrored from the runtime harness configs) — this is the check that catches "added a config option in the code but forgot the dialog" and its inverse, in both directions.
Form fields ↔ defaults	Every node-input-* field must have a default and every default a field — no phantom inputs, no unconfigurable options.
Control help documents every command	Cross-file: the control node's help panel must contain every command in the runtime's COMMANDS array — when mute/unmute were added, this check made undocumented commands impossible.

package-sanity.js (24 checks)

The package-level guard, formalizing checks that began as ad-hoc build validation:

Check	Why it exists
Registered node files exist; four types registered	A manifest pointing at a missing file means an install that half-works.
npm test names every harness	Self-enforcing suite completeness: a new harness dropped into test-scripts/ fails the build until it's wired into npm test — including this harness itself.
files whitelist ships nodes, lib, examples	The npm tarball must contain what the runtime requires — a packaging regression here only surfaces after publish otherwise.
Every example flow parses, one tab each, info text present	Examples are product; a broken import or an unexplained tab is a first-impression failure.
Wire integrity; nodes belong to their tab	Every wire in every example must resolve to a node in that flow — the check that catches a renamed id leaving a dangling wire.
Control targets and tap scopes reference real ids	An example whose cockpit points at nothing, or whose tap watches a nonexistent tab, demos nothing.
Example reports are message-only	The zero-setup-imports principle encoded as a test: no shipped example may require a directory to be configured before it works.
Tab labels unique	All examples share one import menu; duplicate labels make them indistinguishable.

Together these two harnesses mean the package has a specification, not just the code — the editor dialogs, the manifest, and every shipped flow are held to contracts the same way the runtime is.