Documentation · Releases · Cadmus

Cadmus — H.1.7

v.Chronos.Caduceus.0 — legacy v.H.1.19

Why “Cadmus”

Cadmus is the founder-king of Greek myth — the one who sowed the dragon’s teeth and raised the Spartoi from them, founded Thebes, and is credited with bringing the alphabet to Greece. He is the figure of foundational, generative naming: a scheme that lets everything after it be named consistently. The codename captures the shape of this release. Before Cadmus the project had a working coordinate model but no portable, self-describing grammar, no formal era-kind taxonomy, and no deterministic procedure that says exactly which coordinate a proposed change lands at. Cadmus lays that foundation: a portable grammar, the three era kinds, the Genesis-0 anchor that lets the scheme be adopted without rewriting a single shipped release, and a placement skill that makes the next-coordinate decision mechanical. And, like Cadmus founding the city he then lived in, this change founds the scheme and is itself the first node minted through it — dogfooded rather than merely asserted.

Headline changes

• The portable ChronVer grammar v.<era>.<named-patch>.<patch-number>-<hotfix> is the canonical display key. Every release identity reads as the era (the cycle the iteration shipped under), then the named-patch (a stable subsystem/capability codename), then the patch-number (the Nth refinement of that codename), then an optional -hotfix letter that advances within a patch-number. A base node renders with no trailing dash; a hotfix renders the dash plus the letter — never a dangling separator. The grammar is a display concern only: the structural ordinal identity is byte-stable and unperturbed.
• Two new era kinds — Chaos (ordered origin) and Gluon (orderless maintenance) — join the feature eras. Chaos is the single ordered primordial-origin era: everything built before the first codenamed era, its history grouped into faithful codenamed arcs that sort strictly before every feature era. Gluon is the single orderless cross-cutting maintenance era — no per-era ordinal, excluded from the feature strict-total-order, date-sorted for display only — with four by-KIND buckets (security/hardening, dependency/infrastructure, deploy/CI/release-plumbing, cleanup/dead-code/refactor-glue). The orderless model is an explicitly-sanctioned property, never a silent divergence.
• The Genesis-0 anchor model makes adoption rewrite nothing. Every codename’s entire prior history compacts to its patch-number 0 (“Genesis”) entry as lettered members, each displaying its original legacy version tokenalongside the new coordinate (dual display); the first future quick under any codename is patch-number 1. Nothing shipped is re-numbered or re-coordinatized — Genesis-0 is a pure read-side derivation. A reserved codename’s Genesis-0 may legitimately be empty— the audit-cycle codename is the canonical reserved-empty case, documented as intentional rather than “fixed”.
• Exactly two sanctioned migration-point folds — and no wholesale re-grouping. At the migration point precisely two individually-justified consolidations reclassify historically-mislabelled bands: Orpheus → Antikythera (a stale heading folded back onto the capability it actually refined) and Pythagoras → Gluon (a maintenance-only band that wore a feature codename, routed per-entry to the matching maintenance bucket). Every legacy token still resolves exactly as before. A wholesale retroactive re-grouping of shipped history is forbidden — it would break lossless-history and byte-stable guarantees en masse.
• The benchmark-rehaul codename Hipparchus is renamed Charon. This is a rename, not a slug re-draw and not a coordinate change: the node, its coordinate, and its legacy token are unchanged, and it adds zero redirects. The benchmark/scoring subsystem keeps its identity under the new name; future benchmark work is forever that codename at the next patch-number, never a new codename.
• A deterministic placement skill surfaces the single explicit append target. A test-pinned skill, backed by a pure exported classifier, runs the era-first → subsystem-ownership → four-branch-scale procedure and surfaces the one append target (era → codename → patch-number, or a maintenance bucket) for every future change, rejecting a request that resolves to more than one target. It is the mechanical projection of the ChronVer prose doctrine — the prose is the single source of truth, the classifier is its runnable form, and it cannot drift because its era rubric is single-sourced from the release roster.
• The change dogfoods its own scheme — it ships as the Cadmus node it minted. This release is itself versioned as a new node minted through the placement skill and the documented next-coordinate procedure — the Cadmus node at the new coordinate this page describes — with the build stamp re-derived from the model rather than hand-edited. The version stamp on this page is read live from @/lib/version, not frozen into the page.

For operators

Every version reference you see — the navbar, the footer badge, the docs, the changelog, the release pages — now reads the same ChronVer coordinate, derived from one model. Nothing you had bookmarked breaks: every historical legacy version token still resolves exactly as before and is displayed alongside its new coordinate (dual display), so old commit prose, issues, and notes never become dead ends. The grammar change is display-only — it renames how releases are shown, never their historical or structural identity, and it adds zero redirect churn because slugs are codename-based, not coordinate-based.

From here forward every change declares exactly one explicit append target through one of four governance channels — a spec mints the next codename, a feature quick increments the patch-number under the subsystem-owning codename, a hotfix advances a letter, and a maintenance / architectural quick lands in the matching Gluon bucket by KIND. To follow the scheme end to end, read the grammar explainer and the portable ChronVer specification linked below.

Related

• Versioning — the grammar explainer: the four-designator coordinate, the five era kinds, the retroactive-fix model, the codename-uniqueness invariant, and the five canonical governance rules (including the audit-cycle reserved-empty rule), all re-derived from the same canonical model.
• The canonical release forest — the unified page rendering the entire Release→Era→ Name→fix forest in one place, with every shipped codename at its canonical coordinate and its re-draw / legacy-token provenance inline.
• Perseus — H.1.6 — the immediately preceding arc; Cadmus opens nameSeq 8 of the Chronos Era 1 on top of Perseus v.H.1.6, carrying its single canonical coordinate-addressed forest forward and laying the portable ChronVer grammar, the era-kind taxonomy, and the placement skill on top of it.