Hash semantic uniqueness — UX audit rules

Rule handbook metadata

Rule: DET.KS.HASH_SEMANTIC_UNIQUENESS · lane deterministic
Page status: current
page_version: 09a9534a9ea872d6602672b54effd6ccb25f6037030b33ec1f87d3d0c2e1e501
generated_at: 2026-05-28T20:30:00.000Z
registry_fingerprint: aef1de6082cf0f50d463783c843dee0ffb9132fbd5ed4ea6e5bb3f031f359c72

How this rule is fixed

Pilot deterministic fixer: plan_only · harness mode repo_overlay · verify expect_rule_clean.

See fixer module for plan_only in lib/ux-deterministic-fixers/.

Detection module: docs/design/ux-audit/deterministic-design-rules.md#det-ks-hash-semantic-uniqueness. Scroll down for Before / After examples and Evidence and remediation steps.

Purpose

Three-letter hashes identify one visual surface anatomy. Reusing hash Fsb for both a react-primitive banner and an unrelated section is a semantic collision unless documented in the catalog. Scope: KS-driven sites only.

Passing signals

Each hash maps to one (data-ks-type, data-ks-name) pair per page/build.

Failing signals

hash-semantic-collision — hash Fsb on react-primitive|forge-status-banner and section|unrelated-section.

Before example

Before (failing example)

After example

After (passing example)

Deterministic checks

DET.KS.HASH_SEMANTIC_UNIQUENESS — det-ks-hash-semantic-uniqueness.check.js.

Remediation

Allocate a new registry hash for the second surface or document intentional reuse in the family contract.