Ledger Correction

The prior ledger entry (8d1a99f) recorded the file-tier-vs-index-tier wiring as [O-open]. At the moment that ledger was being drafted, PR #139 at klappy/oddkit had already been merged independently — the maintainer shipped the cleanest of the three options I had surveyed (extend the setter to recognize file:* labels), with first-wins preserved and file-r2:* (R2 miss spans) excluded by an explicit source !== "miss" guard. Test count went from 18 to 22 passing.

I missed it because I was working in parallel on the ledger entry while PR #139 was landing. The ledger merged at 8d1a99f and was technically wrong at the moment of write — the open item it documented as open was, in code, already closed. This is a real "validate before assuming" miss in the same session that named the principle as a learning.

This correction records two things: that the original [O-open] is closed at the code level (PR #139, e2912f3), and that a new observation has surfaced from production verification — the deployed worker is reporting the pre-PR-139 behavior 13+ minutes after Workers Builds completed.

---

Original claim (in odd/ledger/2026-04-26-telemetry-and-canon-integration-session, section Opens):

[O-open: getFile-tier vs index-tier wiring] — Three options surveyed during the session: (a) extend the setter to recognize "file" labels, (b) each action explicitly sets a primary tier via a new setPrimaryTier() method, (c) add a separate file_tier blob10. Filing for follow-up; not blocking.

Correction: PR #139 at klappy/oddkit (squash-merged 2026-04-26T03:04:22Z as e2912f3) shipped option (a) — extend the setter to recognize file:* labels alongside index / index-build. First-wins guard preserved (!this._indexSource check), source !== "miss" guard added to exclude file-r2:* miss spans. The implementation is in workers/src/tracing.ts:48-56:

if (!this._indexSource && source && source !== "miss") {
  if (
    label === "index" ||
    label === "index-build" ||
    label.startsWith("file:")
  ) {
    this._indexSource = source;
  }
}

Test coverage: 4 new regression tests (file:* recognition, index-wins preserved, miss-spans excluded, original behavior unchanged). Test count: 18 → 22 passing. Local run on merged main confirms 22/22.

The original ledger's [O-open] for file-tier wiring is hereby corrected to [O-closed: PR #139, e2912f3] at the code level.

---

A new observation replaces the closed open. Production verification 13+ minutes after PR #139's Workers Builds completion (build completed 2026-04-26T03:04:49Z; verification queries at 03:13-03:17Z) shows the deployed worker is still serving the pre-PR-139 setter:

Evidence:

• oddkit_version returns 0.23.1. The package.json and workers/package.json on main both report 0.24.0 (bumped at d023ad6, four commits before PR #139). The deploy mechanism is supposed to inject ODDKIT_VERSION from package.json per the comment in workers/wrangler.toml: # ODDKIT_VERSION injected at deploy time from root package.json.
• Three independent oddkit_get calls to klappy:// URIs (the fast path that PR #139 specifically targets) returned debug traces with the expected file:* spans and non-"miss" sources (r2, build), but index_source: "none" in the trace summary. With PR #139's setter, those traces should report index_source: "r2" and index_source: "build" respectively.
• Telemetry query (SELECT blob9 AS cache_tier, blob8 AS worker_version FROM oddkit_telemetry WHERE blob3='oddkit_get' AND timestamp > NOW() - INTERVAL '15' MINUTE) confirms 6/6 oddkit_get calls in the post-deploy window record cache_tier="none" with worker_version="0.23.1". No exceptions.

Possible explanations:

• Workers Builds completed but the actual edge-rollout to production is taking longer than the typical 2–5 minute window. Most likely.
• The CF deploy mechanism does not actually update ODDKIT_VERSION from package.json despite the wrangler.toml comment, and the env var was last set to 0.23.1 manually. This explains the version mismatch but does not directly explain why the trace setter behavior is still pre-#139.
• The build artifact deployed by Workers Builds is somehow not the source on main. Less likely; would imply a deeper CI/CD issue.

Why this entry exists: the prior ledger's correction is itself a small fact, but the new observation deserves recording because it is the kind of finding the next session will want to start from. If oddkit_get continues recording cache_tier="none" 30+ minutes after PR #139's Workers Builds completed, the deploy mechanism itself is suspect, not the code.

---

[O-open: deploy-propagation-or-version-skew on klappy/oddkit production worker] Workers Builds reported completed/success at 2026-04-26T03:04:49Z for PR #139's merge SHA e2912f3. As of 03:17:44Z (12m 55s later), the production worker still reports oddkit_version="0.23.1" and oddkit_get calls still record cache_tier="none" with worker_version="0.23.1" in telemetry. The source on main is 0.24.0 and the merged setter clearly recognizes file:* spans. Either (a) edge propagation is taking longer than expected, or (b) the deploy mechanism is not actually picking up main for some reason, or (c) ODDKIT_VERSION is a static env var unrelated to the deployed bundle and the bundle is fresh but the version reporting is stale (which would not explain the still-"none" cache_tier on file:* spans). Suggested next probe: re-query telemetry 30+ minutes after the build-complete timestamp to see whether oddkit_get cache_tier values shift, and inspect the Cloudflare dashboard for the actual deployed bundle version.

[O-still-open from prior ledger: P11 mechanical enforcement of canon-integration-audit] Unchanged from the prior ledger. Tool-side wiring deferred.

---

[L: validate before assuming, even when the assumption is your own ledger draft] The same principle this session named as a Learning (klappy://canon/principles/validate-before-assuming-equivalent observation) was violated by the act of writing the ledger that documented it. The ledger's [O-open] for file-tier wiring was authored on the assumption that no follow-up had been merged in the few minutes between the prior verification query and the ledger's drafting. That assumption was wrong: PR #139 merged 4 minutes after the previous ledger PR's commit timestamp. The corrective is structural, not motivational: any session ledger that records [O-open] items should re-query the relevant repos for newer merges immediately before the ledger PR is opened. A small git fetch && git log --oneline origin/main against each tracked repo, run at ledger-PR time, would have caught this.

The deeper learning: a session ledger is itself a claim about state. Per Axiom 4 ("You Cannot Verify What You Did Not Observe"), the claim "this is open" requires a fresh observation that it is open at write-time, not a memory from earlier in the session. The prior ledger drew on a memory from ~25 minutes earlier; in fast-moving sessions, that's enough lag for the claim to be wrong.

---

[H] Two corrections to odd/ledger/2026-04-26-telemetry-and-canon-integration-session (8d1a99f):

1. [O-open: getFile-tier vs index-tier wiring] is closed at the source level by PR #139 at klappy/oddkit (squash-merged e2912f3). 22/22 tests pass on merged main.
2. A new [O-open] is recorded: 13+ minutes after Workers Builds completion, the production worker reports worker_version="0.23.1" (main is 0.24.0) and oddkit_get still records cache_tier="none". Either edge propagation is slower than expected, or there's a deploy-mechanism issue worth probing on the next session.

The prior ledger's other open (P11 mechanical enforcement of canon-integration-audit) is unchanged. Working copies remain at /home/claude/work/oddkit (synced to e2912f3) and /home/claude/work/klappy.dev (synced to 8d1a99f plus this branch).