§6 — dd-path dedup residual ✓ landed 2026-07-05

Evergreen: catalog-naming-followups §6 (followup f-cnf-003). Acceptance gate: dd_path_uniqueness_check (codex cafbb397) must return zero over the accepted corpus.

Ground truth vs the authored estimate

The plan estimated "1 remaining duplicate path + 6 momentum-family base-carrier inconsistencies". A live-graph audit (read-only, 2440 accepted names) corrected both:

Root cause — a property, not an edge

Both violations traced to ONE name: x_direction_unit_vector_of_pellet_injector. Its source_paths LIST PROPERTY (which dd_path_uniqueness_check reads) claimed all three injection_direction/{x,y,z} leaves, while the actual HAS_STANDARD_NAME edges were already correct 1:1 (x_→/x, y_→/y, z_→/z). So the classification's "A-bucket detach" was a stale-property trim, not an edge delete (an edge delete would have matched 0 rows).

Fix (surgical, reversible, durable)

MATCH (sn:StandardName {id:'x_direction_unit_vector_of_pellet_injector'})
SET sn.source_paths = [p IN sn.source_paths WHERE NOT p IN
    ['dd:spi/injector/injection_direction/y','dd:spi/injector/injection_direction/z']]

Guarded before/after (assert the 2 drops present + /x present before; assert after == [/x], delta == 2). No node deleted, no edge changed, y_/z_ names untouched. Durable with no re-export: source_paths is pipeline-only graph state — it is neither emitted to the ISNC YAML (export.py:512-514) nor written on import (catalog_import.py never sets it), so a re-import cannot restore the over-attach.

Verification

Parked for §4

y_direction_/z_direction_unit_vector_of_pellet_injector each still carry a shatter_cone/direction/{y,z} path in source_paths while those shatter_cone StandardNameSource nodes are vocab_gap with no HAS_STANDARD_NAME edge — a property/edge inconsistency to resolve when §4 handles the shatter_cone family.