fix(ui): resolve the slop/duplicate trend legends' latest week per series

[rsnetworkinginc]

Closes #8667

Problem

latestWeekWithSignal (apps/loopover-ui/src/components/site/app-panels/slop-duplicate-trend-card-model.ts) finds the single most recent week with either signal present, and slop-duplicate-trend-card.tsx reuses that one shared latest week for BOTH legends — latest?.slopBandLabel / latest?.slopFlagRatePct on the slop side and latest?.duplicateFlagRatePct on the duplicate side. SlopDuplicateTrendWeek types the two rates as independently nullable, so if the most recent signal-bearing week has one series populated and the other null, the null series' legend silently renders latest: — / no band even when an earlier week holds real data for it. Latent today (the backend generator's shared openPullRequests denominator gate keeps both series' null-ness in lockstep), but the helper is written generically and its own type signature permits divergence — a waiting defect for any backend change or new caller.

Fix

latestWeekWithSignal is now parameterized by series ("slop" | "duplicate") and scans for that series' own most recent non-null week. The card resolves latestSlop and latestDuplicate independently and each legend reads only its own result. For lockstep-null data (today's production shape) both lookups return the same week the old code returned, so rendered output is unchanged — only the divergent-null case is corrected.

Tests (new coverage for a branch that had none)

Added to apps/loopover-ui/src/components/site/app-panels/slop-duplicate-trend-card.test.tsx, red on main before the fix:

Deliverable	Test	Before (main)	After
Slop legend uses its own latest week	renders the card with the newest signal week slop-null/duplicate-populated and an earlier week at 40%/band elevated; asserts the slop legend shows latest band: elevated, not latest: —	failed: legend rendered latest: —	passes
Duplicate legend uses its own latest week (reverse divergence)	newest signal week duplicate-null/slop-populated, earlier week duplicate 25%; asserts latest: 25% renders	failed: legend rendered latest: —	passes
Per-series model lookup	direct latestWeekWithSignal(weeks, series) assertions: divergent weeks resolve to different weeks per series	failed: expected '2026-06-09' to be '2026-06-02'	passes
Series-independent null	a series with no signal anywhere returns null even when the other series has data; [] returns null	failed: returned the other series' week	passes
Lockstep unchanged	lockstep-null weeks resolve to the same (newest) week for both series; all 4 pre-existing card tests (including the lockstep one-series-empty and all-null cases) untouched and passing	passes	passes

Full file run: 10/10 passing; whole apps/loopover-ui suite: 88 files / 623 tests passing; tsc --noEmit clean; eslint/prettier clean on all changed files; git diff --check clean. apps/** is codecov-excluded; the new tests exercise the previously zero-coverage divergent-null-per-series branch directly per the issue's coverage requirement.

UI Evidence

The /app/maintainer console's "Slop + duplicate trend" card, served locally (vite dev, preview session per the contributor skill) with GET /v1/app/maintainer-dashboard answered at the network boundary by a fixture in the issue's divergent-null shape — the only way to exercise this branch, since it is unreachable with today's lockstep backend data: the newest signal-bearing week has a real duplicate rate (12.5%) but a null slop rate, while the latest week with real slop data (40%, band elevated) is two weeks older. Look at the slop legend: before, it renders latest: — (the shared week's null) as if there were no recent slop signal; after, it renders latest band: elevated in the warning tone from its own latest signal week. The duplicate legend (latest: 12.5%) and both chart panels are identical in both columns. The UI is a dark-mode-only build, so the Light and Dark rows (captured under emulated prefers-color-scheme) render identically by design.

Viewport · Theme	Before	After
Desktop · Light
Desktop · Dark
Tablet · Light
Tablet · Dark
Mobile · Light
Mobile · Dark

[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-26 04:49:25 UTC}

3 files · 1 AI reviewer · no blockers · readiness 95/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This correctly fixes the shared-latest-week bug by parameterizing latestWeekWithSignal per series ("slop" | "duplicate") and resolving latestSlop/latestDuplicate independently in the card component, so each legend now reads only its own series' most recent non-null week instead of a single shared lookup that could hide real data behind the other series' null. The fix is at the correct layer (the helper function itself, not a symptom patch in the render logic), closes #8667 as claimed, and the diff is well-scoped to exactly this change. Test coverage is thorough, including both divergent-null directions, the lockstep case, an empty-series case, and a sparse-array hole case that exercises the `if (!week) continue` guard.

Nits — 4 non-blocking

• The block comments in slop-duplicate-trend-card-model.ts:47-49 and slop-duplicate-trend-card.tsx:27-28 are a bit verbose for a straightforward parameterization — a single line would convey the same rationale.
• slop-duplicate-trend-card.tsx no longer needs the `hasSlop`/`hasDuplicate` distinct-from-`latestSlop`/`latestDuplicate` naming clarified anywhere in a comment, but the pattern of using `hasDuplicate` (boolean) alongside `latestDuplicate` (week-or-null) for the same conceptual check is slightly asymmetric versus the slop legend which uses `latestSlop?.slopBandLabel` directly — worth a consistency pass if this pattern grows a third series.
• Consider extracting the two nearly-identical `latestWeekWithSignal(trend.weeks, series)` calls plus their consumption pattern into a small hook/helper if a third series is ever added, to avoid triplicated call sites.
• The PR description states this is closing fix(ui): slop/duplicate trend card conflates two independently-nullable series into one shared 'latest week' reference #8667 — confirm the issue is correctly linked in the actual PR (not verifiable from the diff alone).

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	#8667
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: 58 registered-repo PR(s), 24 merged, 3 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	rsnetworkinginc; Gittensor profile; 58 PR(s), 3 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Linked issue satisfaction

Addressed
The diff parameterizes latestWeekWithSignal by series and resolves latestSlop/latestDuplicate independently in the card, exactly matching the requested per-series lookup, and adds tests covering both the divergent-null case (each legend showing the earlier week's real value) and the lockstep-null case for regression safety.

Review context

• Author: rsnetworkinginc
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: TypeScript
• Official Gittensor activity: 58 PR(s), 3 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]

LoopOver approves — the gate is satisfied and CI is green.