preserve-canonical-hash-byte-law

Preserves the frozen canonical-JSON byte law governing event hashing, signing, and chain verification.

Updated Jul 9, 2026
One-click install
npx skills add https://github.com/shuddl/shuddl-os --skill preserve-canonical-hash-byte-law-shuddl
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: preserve-canonical-hash-byte-law
Source: https://github.com/shuddl/shuddl-os/tree/main/.claude/skills/preserve-canonical-hash-byte-law
Command: npx skills add https://github.com/shuddl/shuddl-os --skill preserve-canonical-hash-byte-law-shuddl

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Silent byte drift in the canonical JSON serializer or in code that reconstructs hashed structures (like reading events back from D1) invalidates the entire hash chain, causing every event to fail verification. This Skill prevents well-meaning edits — such as assigning a SQL NULL column directly or 'optimizing' the serializer — from breaking the SHUDDL ledger's cryptographic integrity. ## Core Features & Use Cases - Frozen serializer rules: Documents the five load-bearing rules of the JCS-based canonicalizer (integer-only numbers, sorted keys, omitted undefined vs emitted null, literal Unicode, no sparse arrays) pinned by a snapshot test. - SQL NULL read-back guard: Enforces mapping SQL NULL columns to omitted keys (never literal null) in rowToEvent so recomputed hashes match stored hashes. - Dual-view and lockstep contracts: Defines hashView vs clientView field sets, the CODE:{json} RPC error envelope convention, and the byte-identical requirement between canonicalPositionBytes and the positions ingest route. - Use Case: Before editing canonical.ts, lens.ts, chain.ts, sign.ts, or anchor.ts, consult this Skill to verify your change against the byte law, then run the ledger test suite to prove the chain still verifies. ## Quick Start Before editing any event hashing, signing, or D1 read-back code in the ledger package, read this Skill and then run the canonical, roundtrip, chain, lens, sign, and anchor tests to confirm the byte law held.

Frequently Asked Questions about preserve-canonical-hash-byte-law

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I safely edit canonical JSON serialization code without breaking hash verification?▼

Treat the canonicalizer as frozen: keep integer-only numbers, UTF-16 sorted keys, omitted undefined members, and emitted null values exactly as specified. After any nearby change, run the canonical, roundtrip, chain, lens, sign, and anchor tests; a snapshot diff is a Critical break, not a snapshot to update.

Why do events read back from D1 fail chain verification?▼

The usual cause is mapping a SQL NULL column to a literal null instead of an omitted key. The canonicalizer emits null but omits undefined, so e.shipment_id = r.shipment_id injects "shipment_id":null and the recomputed hash drifts; guard with if (r.x !== null).

What is the difference between hashView and clientView in event signing?▼

hashView covers the full envelope minus sig and the stored hash, so any tampering breaks the next chain link. clientView is the smaller offline field set a device can sign, excluding source, confidence, and party_refs, which are hash-locked server-side after append.

Can I refactor gate errors into structured exception objects?▼

No. Gate refusals cross a Durable Object to Workers RPC hop that preserves only Error.name and Error.message, so machine-readable detail must stay encoded in the message as CODE:{json}, such as GATE_BLOCKED:{...} or VALIDATION_FAILED:{...}.

Why must canonicalPositionBytes and the positions ingest route stay in lockstep?▼

canonicalPositionBytes is the Merkle leaf for a position and must produce the exact bytes the ingest route hashed as the row's integrity anchor. Both conditionally include accuracy_m and speed_cms only when present; changing one side alone makes daily anchors stop matching ingested rows.