From Alex's review on #936:
Hard restriction: cannot compare one sector to another
A comparison needs at least one sector in common; without one there is no shared sector axis for the page to scope by.
Where it belongs
Enforcement is at selection time, in PathwayCard — the only place a pathway is added to the tray — plus a guard on ComparisonPage for a hand-edited or stale ?ids=, which is read straight from the query string and validated only for existence.
Not in ComparisonContext.addToComparison: that context is deliberately data-free, and ComparisonContext.test.tsx adds ids "a"–"d" that exist in no metadata, so a guard there would need pathwayMetadata plus an unknown-id tolerance clause purely to keep the existing tests green.
loadFromSession does need to clear a restored selection that is provably incompatible, or a set stored before the rule existed comes back with Compare enabled.
Two things to get right
- Intersect the whole running set, not pairwise against the first. With three pathways, A∩B ≠ ∅ and A∩C ≠ ∅ does not imply A∩B∩C ≠ ∅.
- Missing sector data is not a clash.
sectors is schema-required but carries no minItems, so sectors: [] is valid data. It must read as unknown, never as incompatible — a data gap must not look like a rule. Same for an id that resolves to no pathway.
Unverifiable against current data
All seven loadable pathways declare Power, so every pair shares at least three sectors and the restriction cannot fire in the running app today. It becomes reachable as the 49 v1 pathways migrate (#858). Until then it is provable only by fixture, and the code should say so or someone will read the branch as dead.
Note this touches PathwayCard and ComparisonContext rather than the comparison page itself.
From Alex's review on #936:
A comparison needs at least one sector in common; without one there is no shared sector axis for the page to scope by.
Where it belongs
Enforcement is at selection time, in
PathwayCard— the only place a pathway is added to the tray — plus a guard onComparisonPagefor a hand-edited or stale?ids=, which is read straight from the query string and validated only for existence.Not in
ComparisonContext.addToComparison: that context is deliberately data-free, andComparisonContext.test.tsxadds ids"a"–"d"that exist in no metadata, so a guard there would needpathwayMetadataplus an unknown-id tolerance clause purely to keep the existing tests green.loadFromSessiondoes need to clear a restored selection that is provably incompatible, or a set stored before the rule existed comes back with Compare enabled.Two things to get right
sectorsis schema-required but carries nominItems, sosectors: []is valid data. It must read as unknown, never as incompatible — a data gap must not look like a rule. Same for an id that resolves to no pathway.Unverifiable against current data
All seven loadable pathways declare Power, so every pair shares at least three sectors and the restriction cannot fire in the running app today. It becomes reachable as the 49 v1 pathways migrate (#858). Until then it is provable only by fixture, and the code should say so or someone will read the branch as dead.
Note this touches
PathwayCardandComparisonContextrather than the comparison page itself.