Closes #123 Implemented: Canonical severity ordering invariants for config_version_hash determinism #123

[Promise278]

• Add pub fn canonical_severity_order() as single source of truth
• Refactor compute_config_version_hash to consume canonical_severity_order
• Add 8 regression tests for severity ordering invariants and hash determinism
• Add .config-version-hash.baseline for CI regression guard
• Document severity iteration order as public ABI in event_schema.rs and CODEX_CONTEXT.md

Problem

compute_config_version_hash iterated an inline literal array of severity symbols ([critical, high, medium, low]). Nothing in the test suite enforced that this ordering was load-bearing — a contributor re-ordering those four symbols would silently break backend parity forever. There was also no test asserting that adding a 5th severity wouldn't break the determinism guarantee.

Changes

Single source of truth (lib.rs):

• Added pub fn canonical_severity_order() -> [Symbol; 4] as the authoritative canonical ordering
• Refactored compute_config_version_hash and canonical_severities to consume it — no inline literal duplicates

Regression tests (tests.rs — 8 new tests):

• test_canonical_severity_order_is_critical_high_medium_low — anchors exact ordering
• test_canonical_severity_order_length_is_four — guards against accidental additions
• test_canonical_severity_order_adjacent_pairs — catches pairwise swaps
• test_config_version_hash_deterministic_under_reorder — hash identical across repeated reads
• test_config_version_hash_changes_when_any_severity_field_changes — any field mutation changes hash
• test_config_version_hash_visible_ordering_invariant — visible ordering, not literal identity, is the invariant
• test_config_version_hash_not_affected_by_custom_severity_in_map — custom severities don't alter hash
• test_config_version_hash_baseline — regression guard against algorithm/config changes

CI baseline (.config-version-hash.baseline):

• Records expected hash 1417728228875630226 for default config

[usmanimamu17-create]

Thanks for working through this — a canonical severity ordering is a nice piece of determinism work! Currently the Checks tab shows no completed runs for the four CI jobs that gate contracts here: client-checks, e2e-tests, fuzz-tests, provenance-hashes (all defined in .github/workflows/ci.yml).

That almost always means the per-PR workflow has not fired yet. Pushing a rebase (or an empty commit) onto latest main reliably re-triggers it; for first-time contributors the Checks tab sometimes needs a maintainer to click "Approve and run". Once all four are green I will merge immediately. 🚀

[Promise278]

Thanks for working through this — a canonical severity ordering is a nice piece of determinism work! Currently the Checks tab shows no completed runs for the four CI jobs that gate contracts here: client-checks, e2e-tests, fuzz-tests, provenance-hashes (all defined in .github/workflows/ci.yml).

That almost always means the per-PR workflow has not fired yet. Pushing a rebase (or an empty commit) onto latest main reliably re-triggers it; for first-time contributors the Checks tab sometimes needs a maintainer to click "Approve and run". Once all four are green I will merge immediately. 🚀

Boos You need to click the "Approve and run" button on the Checks tab. for all four jobs to fire automatically.

[usmanimamu17-create]

@Promise278 your CI cannot ru because you have conflicts, this isn't an approval issue.

[Promise278]

@Promise278 your CI cannot ru because you have conflicts, this isn't an approval issue.

conflicts solved