test(ui): cover snapshot-replay privacy boundary (#8386)

[jsdevninja]

Summary

• Add apps/loopover-ui/src/lib/snapshot-replay.test.ts covering buildSnapshotReplayView public stripping of reason/facts/assumptions, authenticated pass-through, missing/partial snapshots, stale triggers, repo filtering, and confidence/freshness narrowing.
• Add apps/loopover-ui/src/components/site/snapshot-replay.test.tsx covering the audience toggle leak-guard, missing-status notice-only render, and withheldPrivateFields footer.
• Closes snapshot-replay.ts's public/authenticated privacy boundary has zero test coverage #8386.

Test plan

• npm --workspace @loopover/ui run test -- src/lib/snapshot-replay.test.ts src/components/site/snapshot-replay.test.tsx (17 tests)
• Prettier on the new test files
• CI / ui:test green on the PR

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-24 13:00:42 UTC}

2 files · 1 AI reviewer · no blockers · readiness 93/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This is a pure test-only PR adding coverage for the public/authenticated privacy boundary in buildSnapshotReplayView and the SnapshotReplay/SnapshotReplayCard components — no changes to src/lib/snapshot-replay.ts or src/components/site/snapshot-replay.tsx are shown or implied. The tests exercise real assertions (leak-checking via JSON.stringify scan plus per-field checks, audience toggle interaction, missing/stale status branches, repo filtering case-insensitivity, and confidence/freshness narrowing) rather than fabricated payloads, and they align with the stated intent of closing #8386. All CI checks passed on this commit, and the tests appear to target the actual public API surface (buildSnapshotReplayView, SnapshotReplay, SnapshotReplayCard) rather than mocking around it.

Nits — 5 non-blocking

• The privacy-leak check in expectNoPrivateLeak (apps/loopover-ui/src/lib/snapshot-replay.test.ts) only asserts against the three PRIVATE_* constants via JSON.stringify — consider also asserting the full alternative object shape (e.g. no unexpected extra keys) so a future field addition to the private payload can't silently leak without failing this test.
• The repeated large `INSTALL_PREVIEW`/`preview()`-style fixture pattern isn't used here, but the new baseView()/baseSnapshot() overrides pattern in both test files duplicates a fair amount of boilerplate between the two files — consider sharing fixture builders if snapshot-replay gets more test files.
• Comment style `// (snapshot-replay.ts's public/authenticated privacy boundary has zero test coverage #8386) ...` at the top of both files is a nice touch for traceability but is otherwise undocumented as a repo convention; verify this matches how other PRs annotate issue-linked test files.
• Consider adding one test asserting that `sources`/`scoringModelId` pass through unchanged for both public and authenticated viewers, since the diff exercises privacy-sensitive fields (reason/facts/assumptions) but not adjacent provenance fields that also appear in the view model.
• In snapshot-replay.test.tsx (component test), consider adding a case where `authenticated` and `publicSafe` props are swapped/undefined to confirm the toggle degrades gracefully, if such a codepath exists in SnapshotReplayCard.

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ✅ Gate result — Passing (No configured blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#8386
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 215 registered-repo PR(s), 130 merged, 39 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	jsdevninja; Gittensor profile; 215 PR(s), 39 issue(s).
Improvement	ℹ️ Insufficient signal	risk: clean · value: insufficient-signal · LLM: moderate

Linked issue satisfaction

Addressed
The PR adds both required test files with coverage matching essentially every bullet in the requirements: public stripping and withheldPrivateFields (both non-empty and empty cases), authenticated pass-through, missing/malformed snapshot and missing-provenance carry-through, all three stale triggers plus the all-clear populated case, case-insensitive repo filtering (including null target keeping a

Review context

• Author: jsdevninja
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: not available
• Official Gittensor activity: 215 PR(s), 39 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Triage stale or unlinked PRs.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

Visual preview

Route	Viewport	Before (production)	After (this PR's preview)	Diff
/	desktop	before /	after /	—
/	mobile	before / (mobile)	after / (mobile)	—

Click any thumbnail to open the full-size screenshot. Before = production · After = this PR's preview deploy.

Scroll preview

Route	Before (production)	After (this PR's preview)
/	before / (scroll)	after / (scroll)

A short scroll-through clip (desktop) — click either thumbnail to open the full animation. Evidence for scroll-linked behavior a single screenshot can't show.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[loopover-orb]

This pull request changes UI/visual code but its screenshot evidence is incomplete. Every required viewport × theme combination needs its own before/after image pair in a labeled table row (e.g. "Desktop · Light | before | after"). Still missing: Desktop · Dark, Tablet · Dark, Mobile · Dark.

Please resubmit with the remaining rows filled in.

See https://github.com/JSONbored/loopover/blob/main/.claude/skills/contributing-to-loopover/SKILL.md for the exact format and examples. This is an automated maintenance action.