ledger(p1-3-4): encode canon-parity sweep closeout (0.23.0 prod)

[klappy]

Closes the canon-parity sweep

New closeout ledger for P1.3.4 — the final sub-step of the canon-parity sweep — plus the corresponding handoff flip to superseded.

oddkit 0.23.0 (encode D5 + D9) shipped to prod at ea185a958105e43f4be5615980322249254b357f via klappy/oddkit#130 on 2026-04-20T14:45Z. All three tools (oddkit_encode, oddkit_challenge, oddkit_gate) now share the stemmed matcher family and have their in-process derivation caches removed per klappy://canon/principles/cache-fetches-and-parses.

Files changed

• odd/ledger/2026-04-20-p1-3-4-encode-canon-parity-landed.md — new closeout, structural mirror of P1.3.3 ledger. ~280 lines. Full narrative; 6 Decisions / 7 Observations / 7 Learnings / 4 Constraints / 4 Handoffs; DOLCHE summary; Validation Evidence section with both Sonnet 4.6 validator session IDs + all Bugbot SHAs + prod self-call; UTC Timeline; Sweep Closure section.
• odd/handoffs/2026-04-20-p1-3-4-encode-canon-parity.md — status: active → status: superseded; superseded_by: added; superseded_note: records the 0.22.0 → 0.23.0 version rebase-bump and the orchestrator → autofix design divergence (phrase-subset shipped, not flat Set as originally spec'd).

First clean application of release-validation-gate

P1.3.3 wrote the canon under process-failure pressure (two Bugbot findings + skipped validator → 1h 39m prod regression). P1.3.4 was the first sweep step the new canon governed from first turn. All three rules satisfied at every checkpoint:

• Rule 1 (Bugbot completed before merge): caught one HIGH-SEV finding (multi-word vocab flattening on 259170a, fix-forwarded via Cursor autofix 113ba11) and one LOW-SEV finding (unused intersectsStems on 113ba11, fix-forwarded via autofix e404fe0). Both fix-forwarded in the same PR before any merge to main. Final feat head 8a0636be: Bugbot completed/success. Promotion head 7542cbb: Bugbot completed/success.
• Rule 2 (fresh-context validator before promotion): two independent Sonnet 4.6 read-only Managed Agents sessions. Feat validator against eaa1234 (session sesn_011CaF5vqjgzN7Mw8s84qvK9): PASS on all 5 corroborations, 214/214 smoke × 3. Promotion validator against 7542cbb (session sesn_011CaF9tx18Af3z1Fy9trwz8): PASS on all 5 corroborations, 223/223 smoke × 3, plus prod-baseline cross-check confirming assertion (12) fails on 0.22.0 and passes on 0.23.0 (D5 is a genuine behavior fix, not just a rewrite — regex-era matcher does not match deciding, stem-era matcher does).
• Rule 3 (canon outranks session artifacts): the handoff said ship as 0.22.0; parallel PR handoff: P1.3.4 encode canon-parity refactor (D5 + D9) — closes the sweep #128 claimed 0.22.0 on main during validator dispatch; branch forward-bumped to 0.23.0. Main-reality is the version canon; the handoff's "0.22.0" was session-scoped guidance.

Non-blocking carry-forwards

• P11 (carried from P1.3.3) — oddkit_gate mechanical enforcement of release-validation-gate at execution → completion. Promoted to next-sweep priority. Now that all three tools are canon-parity-clean, P11 is the natural next structural rung.
• P13 (NEW from P1.3.4) — parseUnstructuredInput fallback-to-types[0] behavior (pre-existing since 0.18.0, surfaced by both validators).
• L-02 canon learning candidate — canon/learnings/handoff-version-vs-main-reality.md (or similar slug): "When a handoff recommends a version number and parallel work claims it first on main, the canon-aligned response is a forward-bump, not a renegotiation."
• Canon note candidate (O-04, L-06, C-04) — CI transient-failure disposition pattern: when an independent fresh-context validator returns PASS with overlapping evidence during a CI completed/failure window, wait for CI to self-correct or force a manual re-run with the validator's evidence as the cited basis; never override Rule 1 without disposition trail. (Test CF Preview on 7542cbb flaked at 14:06Z and self-recovered by ~14:30Z — the canon held.)

Refs

• Feat PR: feat(encode): D5 stemmed set intersection + D9 cache removal (0.22.0) oddkit#126 squash-merged as 7542cbb
• Promotion PR: promote 0.23.0 to prod — P1.3.4 encode canon-parity (D5 + D9) oddkit#130 merged to prod as ea185a958105e43f4be5615980322249254b357f
• Predecessor ledgers: klappy://odd/ledger/2026-04-20-p1-3-1-challenge-canary-landed, klappy://odd/ledger/2026-04-20-p1-3-2-gate-canary-landed, klappy://odd/ledger/2026-04-20-p1-3-3-challenge-canon-parity-landed
• Validator sessions: sesn_011CaF5vqjgzN7Mw8s84qvK9 (feat), sesn_011CaF9tx18Af3z1Fy9trwz8 (promotion)
• DOLCHE encode artifact: /home/claude/work/encodes/p1-3-4-closeout.md (explicit persistence of oddkit_encode output — the tool does not persist)

Post-promotion live verification

Direct call from orchestrator's MCP session to prod:

oddkit_version → "0.23.0" ✓

oddkit_encode("I'm deciding to ship the two-tier cascade")
→ [{type: "D", typeName: "Decision"}] ✓

# Under 0.22.0 prod this same input returned [C] via fallback,
# per the promotion validator's cross-check. D5 is live end-to-end.

---

Note

Low Risk
Documentation-only change: adds a new ledger entry and updates handoff metadata; no production code or runtime behavior is modified in this PR.

Overview
Adds a new P1.3.4 closeout ledger (odd/ledger/2026-04-20-p1-3-4-encode-canon-parity-landed.md) documenting the encode canon-parity sweep completion, including the shipped matcher/cache changes, validation evidence, and version bump to 0.23.0.

Updates the corresponding handoff (odd/handoffs/2026-04-20-p1-3-4-encode-canon-parity.md) by flipping status to superseded and linking it to the new ledger with a brief supersession note.

^{Reviewed by Cursor Bugbot for commit 2dcdcf2. Bugbot is set up for automated code reviews on this repo. Configure here.}

[klappy]

Closing as duplicate — superseded by #131 (merged to main at 14:59:18Z as c04c90f1).

While this PR was being drafted in the orchestrator's local clone, Klappy authored and merged his own P1.3.4 closeout ledger with structurally equivalent content: same validator session IDs (sesn_011CaF5vqjgzN7Mw8s84qvK9 feat, sesn_011CaF9tx18Af3z1Fy9trwz8 promotion), same Bugbot SHA chain (259170a → 113ba11 → e404fe0 → eaa1234 → d2acf91 → 8a0636be → 7542cbb), same narrative arc (D/O/L/C/H), same canon references, same sweep-closure marker. His ledger also flipped the handoff frontmatter to status: superseded / superseded_by: odd/ledger/2026-04-20-p1-3-4-encode-canon-parity-landed.md.

Per klappy://canon/constraints/release-validation-gate Rule 3 (canon outranks session artifacts): main-reality is the canonical ledger. Klappy's version on main is canon; this PR's version in a feature branch would overwrite canon with a longer-but-not-additive variant. The canon-aligned disposition is to close this PR without merging.

Observation worth encoding (O-08 candidate?): Two concurrent agent/operator sessions produced structurally equivalent closeout ledgers for the same sub-step within ~30 minutes of each other. Both reached the same Bugbot SHA chain, the same session IDs, the same DOLCHE content, the same L-08 candidate learning about orchestrator-vs-autofix-design, the same P13 carry-forward. This is evidence that the sweep's telemetry (validator sessions, Bugbot SHAs, canon URIs) is grounded enough that two independent readers converge on the same narrative. The failure mode here is not content drift; it's coordination drift — two sessions writing the same thing without knowing the other was writing.

Possible future protection (candidate canon amendment): when opening a PR that adds or modifies a ledger, first call oddkit_search for the ledger's URI slug to detect whether a ledger already exists on main. If it does, either comment on that PR (if still open) or append a supplemental observation as a separate minor PR (if merged). Don't open a parallel PR that would overwrite.

Closing without merge. The DOLCHE encode artifact at /home/claude/work/encodes/p1-3-4-closeout.md remains the orchestrator's session-local record; the canon-of-record is #131 on main.