QDL 1 identity and future upgrades

Quinelings — Living Thoughts. QDL 1 freezes qdl-kernels-1 at registry digest 43c66b7022fb73e3ffb2cb53cf4ad2181106a55ed95480bc83e9e656da5e6cf3 for bounded deterministic simulation-only computation. SDK 1.0.0 exposes the stable profile through explicit v1 entry points; legacy/default APIs and ranch policies remain experimental. This policy preserves historical source identities across future upgrades.

A source pins format, version, canonical, registry and registryDigest inside both constructor quotations. Its artifact ID hashes the complete canonical source. The registry manifest binds the operation contract and implementation files. A changed implementation pin produces different compiled source, even if a particular task produces the same output.

A change to the frozen semantics, signature, limits, diagnostics or pinned implementation requires a new reviewed registry identity, a recorded reason and new conformance fixtures; it must not reuse this digest or silently replace its implementation. The twelve legacy golden examples are immutable and come from repository revision 10f3cfd3a1b69b40cb006abeaa4091861b8ba46e; future registry changes must never rebaseline them. Normal checks run node scripts/build-v1-registry.cjs --check, which checks both the executable registry and JSON sidecar. CI must not run a generator to make a failing pin check disappear.

Release designation qdl-v1.0.0 reserves releases/qdl-v1.0.0 for the matching source checkout/archive, registry manifest, golden sources and exact genomes, and SDK 1.0.0 tarball. These artifacts and their recorded hashes must remain immutable under the matching release/tag. The SDK is not published to npm; installing the retained tarball is the package distribution path. A newer interpreter must either advertise and test support for that exact historical pin or refuse it with unsupported-registry; recognizing a version:1 marker alone grants no compatibility. The current interpreter supports only its exact current pin. No multi-registry loader is implemented.

Upgrade is an explicit construction of a new artifact:

1. Inspect the old source with its matching archived interpreter, verifying its canonical constructor and pins. Recover its complete authored declaration, normalized node types, task, design and repeat count. Source-only verification runs no task. 2. Review the target registry contract and diagnostics. Keep units symbolic; do not infer conversions, replace evidence policies or invent lost declarations. Retain constants unless a selected migration explicitly turns them into ports. 3. Under the target interpreter, construct with the reviewed {name,thought,task,design,repeats}. It supplies the target pin. If a signature, design model or effect rule has changed, author an explicit repair; unknown fields and unsupported operations refuse. 4. Review old/new complete source hashes and genomes, typed ports, declaration references, effects and body ownership. Compare independently authored input/output fixtures by explicit runs in separate sessions. Equality on those fixtures is finite evidence, not general program equivalence. 5. Explicitly admit the new source. Preserve the old artifact and record the old/target pins, transformation, expected semantic differences and fixture evidence separately. A conversion record does not establish historical authorship, social birth or outside-world work.

Do not transfer old request keys into a new source's execution ledger. The original key binds the original complete request and retained record. A new source uses a new explicit request key; imported historical records remain assertions. Do not restore an incompatible whole-session snapshot by silently substituting new source or registry pins.

The shipped migrateLegacy helper handles the experimental legacy task constructor → QDL 1 transition only. It requires explicit thought/type/port/evidence declarations and returns a passive preview. It is not a universal future-version translator. The matching-runtime inspection and reviewed build workflow above provides an upgrade path without promising an automatic migration engine.