Canonical Serialization Fixtures

Reference test vectors for the YAML → JSON → JCS → blake3 pipeline declared in spec §10.9.

Each test case has three files with the same basename:

file	role
*.yaml	input contract (canonical YAML 1.2 Core schema, no anchors/tags)
*.canonical.json	expected output after step 3 (JCS, RFC 8785). Diff-able byte-by-byte.
*.blake3	expected blake3 digest of canonical.json, hex-encoded, no b3: prefix

CI uses these fixtures in two ways:

1. Cross-language parity. Each implementation (Rust pulse-core, TS Directus extension, Python validate.py) reads *.yaml, produces canonical JSON, compares byte-for-byte with *.canonical.json, then blake3-hashes and compares with *.blake3. Any divergence — CI red.

2. Regression guard. Any change to canonicalization rules (rare; only on canonicalization_version bump) must also regenerate every fixture set. PR review surfaces the diff.

Fixtures included

basename	description
minimal_telemetry	Smallest valid Telemetry contract (1 category, 1 event)
minimal_action	Smallest valid Action contract (1 action)
minimal_semantic_layer	Smallest valid Semantic Layer (1 dimension)
minimal_consent_purposes	Smallest valid consent-purposes registry (1 purpose)

Note: the actual blake3 hash in *.blake3 is initially set to a placeholder PLACEHOLDER_TO_BE_COMPUTED_BY_FIRST_IMPLEMENTATION. The first implementation to pass byte-level parity on *.canonical.json MUST commit the real digest in the same PR. After that, the value is frozen and any change is treated as a breaking change of the canonicalization rules.