Contract G2a round three: Push-4a listing debt, and the ladder order

TransposeInterval is missing from both Core normative listings, which carry the
older Transpose and never gained its successor at kind 30. So the vocabulary
has drifted from its normative listings for two tranches, not one, and both
listings need four additions rather than two. The contract's grep list gains
TransposeInterval, and names the signature worth hunting: a spelled-out count
that disagrees with the enumeration beside it.

for_major does not return {major, 0} unconditionally -- V0 is {0, 1}, and only
V1 through V3 carry minor 0. Corrected in the contract, the plan, and P13-S14.
The finding is unchanged: the function accepts only a major, so no per-kind
additive minor can reach it.

Ladder order is now explicit as G2a -> G-minor -> G2b, with the reason. The
sweep is scoped to kinds 24-33, which is what exists once G2a lands; running
G2b first appends kind 34 and would either grow the sweep mid-flight or ship 34
carrying the defect the rung exists to retire.

Core is five live-text edits plus one historical annotation, not five edits.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QjsEnYhm1gPpf6ii2iFxFV

spec/CONTRACT_GENESIS_G2A_SETTINGS.md

@@ -75,8 +75,10 @@ one must not anticipate it in any way.
    raise the chunk schema minor when it emits a discriminant appended after the
    minor it declares, so an unknown-discriminant decode failure is attributable
    to skew rather than corruption. `SchemaVersion::for_major`
-   (`bundle/src/ids.rs:204`) returns `{major, 0}` unconditionally and takes no
+   (`bundle/src/ids.rs:204`) maps a major to a **fixed constant** — note `V0` is
-   minor, and both staging paths derive only the major
+   `{0, 1}`, not `{0, 0}` (`ids.rs:173`), while `V1`/`V2`/`V3` carry minor 0 —
+   and, decisively, **accepts only a major**, so no per-kind additive minor can
+   reach it. Both staging paths likewise derive only the major
    (`testkit/src/bundle_harness.rs:25`, `textproj/src/serialize.rs:183`). So
    kinds 24–31 already have no additive-version record, and **G2a knowingly
    takes that from eight kinds to ten.** Filed as **P13-S14** and ruled
@@ -177,8 +179,9 @@ changelog paragraphs: one retroactively recording G1's `CreateInstrument`
 section as the 0.10.0 entry's first half (flag it explicitly as a G1 omission
 being repaired, not as new work), and the two new `\section`s for this packet.
 
-**`spec/core_spec.tex`** — five edits. The first is a doctrine amendment and
+**`spec/core_spec.tex`** — **five live-text edits plus one historical
-must be done exactly as pinned; the rest are corrections of fact:
+annotation**. The first is a doctrine amendment and must be done exactly as
+pinned; the rest are corrections of fact:
 
 * `:5114` — the Pass-12 K8 doctrine paragraph, which still reads *"genesis is
   the creation of an empty score together with its bundle, **outside the
@@ -190,10 +193,13 @@ must be done exactly as pinned; the rest are corrections of fact:
   is only the claim that the score's **contents** arrive outside the operation
   set. Cite the ruling.
 * `:6899` — the `pub enum OperationKind` listing, introduced by its own prose
-  as **normative for the core**. It is missing `CreateInstrument` (G1 debt) as
+  as **normative for the core**. It needs **four** additions, not two:
-  well as both new kinds. Add all three in the listing's existing grouped-by-
+  `TransposeInterval` (kind 30, **Push-4a debt** — the listing carries the older
-  comment style.
+  `Transpose` and never gained its successor), `CreateInstrument` (kind 31, G1
-* `:11862` — the `OperationKindTag` listing, same treatment, same three.
+  debt), and both new setters. Add them in the listing's existing
+  grouped-by-comment style.
+* `:11862` — the `OperationKindTag` listing, same treatment, **the same four**.
+  It likewise has `Transpose` and no `TransposeInterval`.
 * `:12186` — correct the sentence naming which values reach only the
   non-canonical snapshot. Do not restructure the surrounding schema-major-1
   narrative.
@@ -227,13 +233,20 @@ work above, two live-text repairs:
   minimal-stamping list that follows. Same rule as `core_spec.tex:12207`:
   recount from the list you write.
 
-**That is eleven normative sites across four documents, of which five are G1
+**That is eleven normative sites across four documents, and most of the work is
-debt.** Two independent reviews each found sites the other missed, so treat the
+not this packet's own:** five sites are G1 debt, and the two core listings are
-list as a floor, not a ceiling: **grep for the load-bearing phrases** —
+additionally **Push-4a debt** — they carry `Transpose` and never gained
-`CreateInstrument`, `layout_defaults`, `SpellingPrecedence`, "outside the
+`TransposeInterval`, appended at kind 30 in 2026-07. So the vocabulary has been
-operation set", "snapshot-only", and every spelled-out payload count — and
+drifting from its normative listings for two tranches, not one.
-report anything the list does not already name rather than silently fixing or
+
-silently skipping it.
+Three independent reviews each found sites the previous ones missed, so treat
+the list as a floor, not a ceiling: **grep for the load-bearing phrases** —
+`CreateInstrument`, `TransposeInterval`, `layout_defaults`,
+`SpellingPrecedence`, "outside the operation set", "snapshot-only", and every
+spelled-out payload count — and report anything the list does not already name
+rather than silently fixing or silently skipping it. **A count that disagrees
+with the enumeration beside it is the signature to look for**; two such counts
+are already known (`core_spec.tex:12207`, `binary_format.tex:2604`).
 
 ## The companion version bump
 

spec/PASS13_CANDIDATES.md

@@ -91,4 +91,4 @@ visible — a value with a wire form and no canonical carrier to reach it.)
 | P13-S11 | **`AnchorPoint`, referenced by `AccidentalEngraving.anchor`, is defined nowhere.** `core_spec.tex:3166` names `pub anchor: AnchorPoint`; no struct or enum of that name exists in the spec, and `epiphany-core` (whose `Cargo.toml` has no `epiphany-layout-ir` dependency) cannot borrow any layout-ir type even if one shared the name — the same core-native requirement that forced `EngravingBoundingBox`. An undefined leaf frozen onto the wire is the `KeyContext`-shaped gap. Compounding it: the bounding box is documented "relative to the glyph's anchor point" (`:3160`), so freezing an anchor with no defined coordinate frame freezes a point with an undefined origin | this file (verified 2026-07-23; `AnchorPoint` appears once in `core_spec.tex`, defined nowhere; `epiphany-core/Cargo.toml` lists no layout-ir) | **resolved** (ratified: core-native `AnchorPoint { x: SpaceUnit, y: SpaceUnit }`, over the same `SpaceUnit` as `advance_width` and `EngravingBoundingBox`. **Plus one normative sentence pinning the frame**: x/y in canonical space units, y-up, relative to the glyph's coordinate origin — matching the repo's existing Bravura outline convention — so the anchor and the box it anchors share an unambiguous origin. Freezes in tranche 3b) |
 | P13-S12 | **`SmuflVersion` is undefined, and its obvious representation orders SMuFL's real history backwards.** `SmuflVersionRequirement` (`core_spec.tex:3269`) carries `minimum`/`authored_against` of type `SmuflVersion`, which Chapter 4 references but does not define (it exists only as a **Chapter 7 / layout-ir** type, `glyph.rs:29`, with literal-minor encoding — see the resolution). Ordering is load-bearing (`SmuflVersionRequirement.minimum`, `:3271`, gates the fallback of `req:tuning:smufl-version-fallback`), and the type is dual-purpose — it also anchors Chapter 9's `GlyphCatalog::smufl_version()` / `GlyphCatalogIdentity` (`:10420`, `:10460`), so this freeze touches layout-conformance identity, not just tuning. The trap: SMuFL versions are decimal fractions — 1.12 (2015), 1.18, 1.20 (2016), 1.3 (2019), 1.4 (2021) — that succeed by fraction (0.12 < 0.18 < 0.20 < 0.30 < 0.40). A `{ major: u16, minor: u16 }` storing literal digits with derived `Ord` orders the minors 3 < 4 < 12 < 18 < 20, placing 1.3 and 1.4 **before** 1.12; old fonts declaring 1.18-era versions exist forever | this file (verified 2026-07-23 against `core_spec.tex:3269-3274` and SMuFL's published release history) | **resolved** (ratified shape `SmuflVersion { major: u16, minor_centi: u16 }`, **literal-minor storage rejected**: the minor is stored **fraction-normalized to hundredths** — 1.12→(1,12), 1.18→(1,18), 1.20→(1,20), 1.3→(1,30), 1.4→(1,40), rule normative, release table a note. Derived `Ord` is then correct across the whole real history and collapses the 1.2/1.20 ambiguity (both → (1,20)). **Correction on filing: the leaf is NOT undefined — it exists in `epiphany-layout-ir/src/glyph.rs:29` as `SmuflVersion { major, minor }` with LITERAL minor (`{1,4}`) and derived `Ord`, so the backwards-ordering bug is LIVE there today (1.3 < 1.12), and it is a direct field of `GlyphCatalogIdentity` — conformance identity.** `epiphany-core` cannot depend on layout-ir, and `SmuflVersionRequirement` is core, so the type MUST be defined in core and layout-ir must reuse it — a **unification**, not a fresh definition, which moves `GlyphCatalogIdentity` (`{1,4}`→`minor_centi 40`). Tranche 3a defines `core::SmuflVersion` for the tuning use and leaves layout-ir's alone (a bounded, core-invisible homonym since core can't import layout-ir's); tranche 3b performs the unification and the deliberate `GlyphCatalogIdentity` move. **Correction (2026-07-23, tranche 3b-ii): "with golden/vector regen" above was verified false before that tranche's dispatch.** No golden, baseline, or vector is pinned to the catalog identity — every assertion on `ResolvedLayoutIR::canonical_bytes()` is relative (stability, determinism, and a `metrics_hash[0] ^= 1` sensitivity check that never touches `smufl_version`), and the committed SVG/PNG goldens do not embed it. The move changes the catalog's emitted bytes (`encode_catalog`'s minor field: `04 00` → `28 00`) in *value*, with nothing to regenerate. The hundredths scale is blocking for 3b, free to adjust in 3a) |
 | P13-S13 | **The score tuning context has no canonical persistence path: it can be saved, but never authored, replicated, or merged.** Schema major 3 (Push 4b tranche 3b-i) put `smufl` and `overrides` on the wire, but the only *persisted* carrier that embeds a `ScoreTuningContext` is the **acceleration snapshot**, which Chapter 8 makes explicitly non-canonical and regenerable and which the bundle may discard and rebuild at will. No **canonical** carrier embeds it at all: no operation authors it (`epiphany-ops` has no tuning-context payload anywhere — the vocabulary's only `tuning` references are the per-pitch `TuningReference::Inherit`), and `MaterializedState` carries effects, conflicts, anomalies, objects, spellings, breaks, page-breaks, and pending, but no tuning context. So a user who selects a tuning system or sets a per-voice override has authored something the format cannot durably represent, and `req:tuning:tuning-resolution-order`'s scopes 2–4 (`overrides`) are in practice unreachable from any document a replica could exchange | this file (found 2026-07-24 while scoping text-projection parity; verified by searching the whole `epiphany-ops` operation vocabulary and `MaterializedState`'s field list) | **resolved by the genesis tranche** — `spec/RULING_GENESIS_PERSISTENCE.md` (ratified 2026-07-24, 011c68a) reverses Pass-12 K8 and absorbs genesis into the operation set, naming `SetTuningContext` in its §2 settings table. **This was not a tuning-specific defect and did not get a tuning-specific fix:** the operation arrives as one of nine surfaces in a single coordinated tranche, and the wire layout is untouched. **The disposition, and the evidence that produced it:** `spec/ANALYSIS_GENESIS_PERSISTENCE.md` maps the same gap across the whole `Score`: **eight fields have no operation that can produce them** — `canvas.layout_defaults`, `instruments`, `staff_groups`, `parts`, `tuning_context` (this entry, its field 10), `spelling_precedence`, `analysis_layers`, `views`, plus `identity` — and one more (`decomposition_attachments`) can only be pruned back, never authored. Independently re-verified against the working tree: each field's sole `reduce.rs` mention is a read-only base-seed read. Of the four dispositions weighed there (a canonical genesis block; closing the op-coverage gap; promoting the canonical base to carry graph values; scope-limiting), **the second was taken** — every mutable `Score` field becomes operation-authored — so S13 closes when that tranche lands and is tracked *there*, not here. **One cost this entry contributes as evidence:** the per-field operation route is not the free schema-minor it appears. Blocks stamp *minimally*, at the lowest major whose layouts decode them, and `bundle.rs`'s `max_supported_major` currently caps `OperationEnvelopeBlock` at **2** on the explicit ground that no operation payload embeds the tuning context. A `SetTuningContext`-style operation would make its blocks stamp v3, dragging a role accept-set raise along with the kind append — for one field of eight. That is a concrete instance of the analysis's closing constraint, that any option enumerating fields must be re-audited against its table whenever `Score` gains a field. **This cost is now paid deliberately rather than avoided — but NOT amortised, as first written.** The ruling's "one accept-set raise, spent once" implied a single batch landing every new kind at `OperationEnvelopeBlock` major 3, spreading the raise across nine surfaces. Re-derived 2026-07-28 against the working tree, that is wrong: minimal stamping is a pure function of each payload's value, so the other eight surfaces stamp at major 0, 2, or 2 and never reach the raised bound at all. `SetTuningContext` is the sole payload born at v3, so the raise is charged to **exactly this surface** after all — which is why `spec/PLAN_GENESIS_OPS.md` §4 splits G2 and isolates it in **G2b**. **And the closure argument is not the canonical base:** the base is role-bound to major 0 (`mis_stamped_canonical_base`) and is a `MaterializedState`, which embeds no graph values for *any* field — including `metadata`, op-authored since M2d and durable purely through its operations. S13 closes on that precedent: the op log is canonical, and G2b makes an operation author the tuning context. Consequence to carry forward: once G2b lands, pruning would discard *authored* genesis state rather than merely re-derivable state, so the standing prohibition on pruning (blocked on disposition C) gains real teeth. Note `bundle.rs` documents the cap of 2 *with the tuning-context rationale in prose*, so that comment must move with the cap. Note the wire layouts themselves are already frozen and correct under every disposition: this was never about how the tuning context encodes, only about which carrier embeds it. Not a regression — nothing ever worked; major 3 made the gap visible by giving the value a wire form and no way to reach it) |
-| P13-S14 | **The chunk schema *minor* is a normative MUST that no writer has ever honoured, so every appended operation discriminant is unattributable to version skew.** `binary_format.tex:2330` requires a writer to raise the chunk schema minor when it emits any discriminant appended after the minor it otherwise declares, with a stated rationale: so that a decode failure on an unknown appended discriminant is attributable to a version skew rather than to corruption. `SchemaVersion::for_major` (`bundle/src/ids.rs:204`) returns `{major, 0}` unconditionally — it takes only a major and has no minor input — and **both** writer-side staging paths derive nothing but the major (`testkit/src/bundle_harness.rs:25`, `textproj/src/serialize.rs:183`, each mapping `max(OperationEnvelope::schema_major)` through `for_major`). So every kind appended after the initial vocabulary has no additive-version record: **24–27** (Phase-3 first tranche), **28–29** (the schema-major-2 repeat revision), **30** (Push 4a `TransposeInterval`), and **31** (genesis G1 `CreateInstrument`). The requirement's own failure mode is exactly what the gap produces: a reader meeting kind 31 from a newer writer cannot distinguish "my vocabulary is stale" from "these bytes are damaged" | this file (found 2026-07-28 during G2a contract review; verified against the working tree — `for_major`'s signature admits no minor, and neither staging path computes one) | **open, and deliberately extended.** Ruled 2026-07-28: the fix is its own rung, sequenced **after** G2a. G2a appends kinds 32/33 and takes the violation from eight kinds to ten, knowingly — the debt is already eight deep, the +2 is immaterial against it, and one retroactive sweep over 24–33 is strictly less work than 24–31 now and 32–33 later. **What the rung owes:** a minor-assignment policy (which minor each past append belongs to — this is a retroactive judgement, not a derivation), a per-kind `schema_minor()` or equivalent, block minor = max over payloads, a `for_major` replacement that accepts one, and both staging paths. **Check before scoping it** whether the chunk header's minor reaches any pinned corpus, since that decides whether this is a vector-moving change. Note this is orthogonal to the *major* accept-set: `OperationEnvelopeBlock` stays at 2 through G2a and rises to 3 only at G2b |
+| P13-S14 | **The chunk schema *minor* is a normative MUST that no writer has ever honoured, so every appended operation discriminant is unattributable to version skew.** `binary_format.tex:2330` requires a writer to raise the chunk schema minor when it emits any discriminant appended after the minor it otherwise declares, with a stated rationale: so that a decode failure on an unknown appended discriminant is attributable to a version skew rather than to corruption. `SchemaVersion::for_major` (`bundle/src/ids.rs:204`) maps a major to a fixed constant — `V0` is `{0, 1}`, not `{0, 0}` (`ids.rs:173`), and `V1`/`V2`/`V3` carry minor 0 — and, decisively, **takes only a major**, so no per-kind additive minor can reach it — and **both** writer-side staging paths derive nothing but the major (`testkit/src/bundle_harness.rs:25`, `textproj/src/serialize.rs:183`, each mapping `max(OperationEnvelope::schema_major)` through `for_major`). So every kind appended after the initial vocabulary has no additive-version record: **24–27** (Phase-3 first tranche), **28–29** (the schema-major-2 repeat revision), **30** (Push 4a `TransposeInterval`), and **31** (genesis G1 `CreateInstrument`). The requirement's own failure mode is exactly what the gap produces: a reader meeting kind 31 from a newer writer cannot distinguish "my vocabulary is stale" from "these bytes are damaged" | this file (found 2026-07-28 during G2a contract review; verified against the working tree — `for_major`'s signature admits no minor, and neither staging path computes one) | **open, and deliberately extended.** Ruled 2026-07-28: the fix is its own rung, sequenced **after G2a and before G2b** — G2b appends kind 34, so running it first would either grow this sweep mid-flight or ship 34 with the very defect the rung retires. G2a appends kinds 32/33 and takes the violation from eight kinds to ten, knowingly — the debt is already eight deep, the +2 is immaterial against it, and one retroactive sweep over 24–33 is strictly less work than 24–31 now and 32–33 later. **What the rung owes:** a minor-assignment policy (which minor each past append belongs to — this is a retroactive judgement, not a derivation), a per-kind `schema_minor()` or equivalent, block minor = max over payloads, a `for_major` replacement that accepts one, and both staging paths. **Check before scoping it** whether the chunk header's minor reaches any pinned corpus, since that decides whether this is a vector-moving change. Note this is orthogonal to the *major* accept-set: `OperationEnvelopeBlock` stays at 2 through G2a and rises to 3 only at G2b |

spec/PLAN_GENESIS_OPS.md

@@ -166,7 +166,8 @@ added**; adding them to the `=> 2` arm would be the bug. No `epiphany-bundle`
 change of any kind.
 
 **G2b — `SetTuningContext` alone**, carrying the raise, the `bundle.rs` prose,
-and the S13 close. `bundle.rs:58` documents the current cap **with the
+and the S13 close. **Sequenced after G-minor, not immediately after G2a** — see
+that section: G2b appends kind 34, and the sweep is scoped to 24–33. `bundle.rs:58` documents the current cap **with the
 tuning-context rationale in prose** — "no operation payload embeds the tuning
 context, so no op block is ever born at v3". G2b is precisely what falsifies
 that sentence, so the comment must move with the number. Same for
@@ -228,15 +229,25 @@ operation normalizes the field away at construction and refuses a non-empty
 one. Decide that in the G2b contract, not in its implementation. Does not block
 G2a.
 
-### G-minor — the schema-minor sweep (ruled 2026-07-28, sequenced after G2a)
+### G-minor — the schema-minor sweep (ruled 2026-07-28)
+
+**Ladder order is G2a → G-minor → G2b, and the order is load-bearing.** The
+sweep is scoped to kinds 24–33, which is exactly what exists once G2a lands. Run
+G2b first and it appends kind 34 into a vocabulary the sweep has already been
+scoped against, so either the sweep grows mid-flight or 34 ships with the same
+defect the rung exists to retire. G2b therefore sequences *after* G-minor and
+inherits working machinery — the same reasoning that put the accept-set raise in
+its own packet.
 
 `binary_format.tex:2330` requires a writer to raise the chunk schema **minor**
 when it emits a discriminant appended after the minor it declares — a MUST with
 a stated rationale, so that an unknown-discriminant decode failure is
 attributable to version skew rather than corruption. No writer has ever done
-it: `SchemaVersion::for_major` (`bundle/src/ids.rs:204`) returns `{major, 0}`
+it: `SchemaVersion::for_major` (`bundle/src/ids.rs:204`) maps a major to a fixed
-unconditionally and accepts no minor, and both staging paths derive only the
+constant — `V0` is `{0, 1}`, not `{0, 0}` (`ids.rs:173`); `V1`/`V2`/`V3` carry
-major (`testkit/src/bundle_harness.rs:25`, `textproj/src/serialize.rs:183`).
+minor 0 — and, decisively, **accepts only a major**, so no per-kind additive
+minor can reach it. Both staging paths likewise derive only the major
+(`testkit/src/bundle_harness.rs:25`, `textproj/src/serialize.rs:183`).
 
 So kinds **24–27**, **28–29**, **30**, and **31** already carry no additive
 record, and G2a takes that to **32–33** knowingly. Filed as **P13-S14**. Ruled: