The app renders the STORE; every guard checks the SEED — 6 of 12 graph pages run unverified source (epic #3604)

[kevinthelago]

The graph migration is done in the sense that matters — all 12 surfaces mount GraphComponent unconditionally, no toggle, no fall-back-to-file. But half of them render source that nothing has ever checked.

The split

graphParity.test.ts   import.meta.glob("@data/components/app/**/*.json")   <- the SEED
GraphComponent.tsx    useAppStore((s) => s.components.find(...))?.srcText  <- the STORE

Those are the same document only for a record in the reconcile path. For one that is not, the guard verifies a file the app never mounts.

Measured on develop today

page	store	seed	delta	builtin
consolepage	18462	18462	same	true
planningpage	54336	54336	same	true
algorithmspage	8697	8697	same	true
soundspage	4384	4384	same	true
glancepage	58854	58854	same	true
projectspage	30876	30876	same	true
skillspage	16806	25943	−9137	(none)
mcppage	14767	19431	−4664	(none)
fleetpage	9186	14141	−4955	(none)
automationspage	8662	4071	+4591	(none)
securitypage	13702	12922	+780	(none)
githubpage	6523	6880	−357	(none)

The six that match are exactly the six stamped builtin. The six that differ are exactly the six unstamped — and exactly the six #4207 deferred. The drift runs both ways, so this is not simply "the store is stale".

skillspage renders 9137 characters of source no test has compared against anything, and #4179 already suspects that page of holding half its content in each copy.

Why the existing guards cannot see it

• Collapse the two record↔file parity guards into one driven by the shadow catalogue #4181/Finish shared/ui as data — 8 primitives records import but no record provides (epic #3604) #4235's parity guard compares seed ↔ file. Correct, and orthogonal to what mounts.
• The parity guard's record half drops any record whose src no longer resolves — 30 of 160, silently (epic #3604) #4239's ratchet makes the guard's exclusions visible. Also seed-side.
• reconcileSeed would reconcile store ↔ seed — but its first branch returns early for a record with no builtin, which is precisely these six (Store-stamping drift: most page records lack , so reconcileSeed can never retire them and deleted seeds leave permanent orphans #4207/The app renders the STORE copy, every guard checks the SEED — 44 app records have diverged unchecked since before #4107 #4216).

Three guards, none of them looking at the thing that renders.

Why this is not just "run #4207's restamp on them"

Stamping a role: page record arms seedAuthoritative (#3723), which forces the seed over the store before any content comparison. On this data that means replacing the rendering skillspage with one a third larger. #4207 deferred them for exactly this reason; the deferral was right and the question it deferred is still open.

What to work out

• A guard on what MOUNTS. The cheapest honest version: extend the parity comparison to the store copy for any record the app renders, so store ↔ file drift fails a test instead of hiding. It will fail on these six immediately — that is the point.
• Adjudicate the six, per page. Which copy is right is a per-page judgement (Skills page: the graph record and the source file each hold half the page (#3826 vs #3854) #4179 is the worked example for skillspage). Needs a diff surface, not a rule.
• Then stamp them, so they rejoin the reconcile and can never drift unwatched again.
• Consider whether seedAuthoritative is still the right policy once store↔file is guarded — it exists because a diverged page copy silently shadowed the real page (Migrate Settings page into the base-studio-code components graph (#3604) #3658 → Studio sessions shadow migrated page records with 'self-contained for preview' copies — breaks runtime fidelity #3723), which a store-side guard would now catch directly.

Related: #4207 (deferred these six), #4216 (made the state visible), #4179 (skillspage specifically), #4235/#4239 (the seed-side guard this complements).

[kevinthelago]

First checklist item landed in #4247 — a guard on the copy that actually mounts.

It found 22 drifted modules across 5 pages, not the 6 pages the record-level count suggested: the unstamped pages have unstamped siblings. The largest are not subtle —

security-profiles      differs from ProfilesTab.tsx    — 148 differing (file 151 / store   3)
github-pulse           renders LESS than Pulse.tsx     — 192 differing (file 130 / store  74)
automations-schedules  renders LESS than Schedules.tsx — 130 differing (file  80 / store  30)
skillspage             renders LESS than index.tsx     —  70 differing (file  75 / store  21)
skills-drawer          renders MORE than SkillDrawer   —  74 differing (file  39 / store  63)

security-profiles is the striking one: the store copy holds 3 element nodes against the file's 151. That page is rendering an almost-empty shell of what the file describes.

fleetpage is correctly absent — its files were deleted in #3636, so there is no baseline.

Two design notes for whoever takes the next item:

• It is not a vitest test, deliberately. The store is machine state and CI has none; a test that skipped when the store was absent would report green on every machine that could not check — the The parity guard's record half drops any record whose src no longer resolves — 30 of 160, silently (epic #3604) #4239 failure exactly. It runs in the app off the hydrate tail, DEV-only (the file half is a ?raw glob only a dev build carries). storeParity.test.ts pins what can be checked without a store: that the input set is the whole catalogue and non-vacuous.
• Direction is reported, not just difference. Fewer elements = missing UI; more = grown extra. Those are different problems and the fix differs.

Remaining: adjudicating the 22 (which copy is right, per module) — #4179 is the worked example — and then stamping them so they rejoin the reconcile.