feat(projects): GLOOK-25 home page project drill-down — Jiras/PRs/Commits tabs

[msogin]

Summary

Clicking any project card on the home page opens an inline drill-down panel showing exactly what the LLM attributed to that project.

What changed

LLM now sees all data: The project-insights route sends all 733 commits + 303 PRs + 362 Jiras. The LLM uses commit messages to correlate PRs and commits to projects — producing richer, more accurate clustering.

LLM enumerates what it attributed: Each project returns jira_keys, groups (epic themes), pr_numbers, and commit_shas. The backend enriches these with full DB details.

Inline drill-down on project cards:

• Click any project row to expand a panel with 3 tabs: Jiras / PRs / Commits
• Jiras grouped by LLM-named epic theme with cyan commit-count badges
• PRs and Commits tabs show attributed data (number, message, repo, lines)

Other row also expandable: Unattributed Jiras and PRs show Jiras and PRs tabs when clicked.

Cache version bumped to _v:3 — stale rows regenerate transparently on next load.

Test plan

• All 742 unit tests pass
• Home page project cards clickable — inline panel opens
• Jiras tab shows epic groupings with commit badges
• PRs and Commits tabs show attributed data
• Other row expandable with Jiras and PRs tabs
• Team page Current Projects card unaffected

🤖 Generated with Claude Code

[msogin]

Code Review — New Commits (review-loop × 2 personas + Smartling fullstack)

Reviewers: Sr. Full-Stack Engineer · Sr. React/Frontend Engineer · Smartling fullstack prompt
Intent: Safe to merge

---

🟡 Important — Fix before merge

I1 · projCommitMap uses inconsistent SHA key types → duplicate commits in drill-down

File: src/app/api/project-insights/route.ts (~line 260–268)

commitBySha is keyed by 7-char prefix. The LLM-SHA path inserts into projCommitMap with the 7-char key (projCommitMap.set(sha, c)), but the PR-based path inserts with the full DB SHA (projCommitMap.set(c.commit_sha, c)). If a commit appears in both llmShas and commitsByPr, it lands in projCommitMap twice under two different keys — inflating estimated_commits and the drill-down commit list.

Fix: Normalize to a single key space. Minimal change: use the full SHA as the dedup key in both paths:

// LLM path — use full sha as the map key
if (c) projCommitMap.set(c.commit_sha, c);

// PR path — already correct, no change needed
projCommitMap.set(c.commit_sha, c);

---

I2 · Jira key regex only captures the first key per commit message

File: src/app/api/project-insights/route.ts (~line 92)

.match(/[A-Z]+-\d+/) (no g flag) returns only the first match. A commit like "Fix BRZ-190 and BRZ-191" only increments linked_commits on BRZ-190. This undercount compounds across all Jira badge stats.

Fix:

const keys = (c.msg as string)?.match(/[A-Z]+-\d+/g) ?? [];
for (const key of keys) {
  // existing increment logic
}

---

I3 · otherDetails state typed any[] despite typed interfaces being imported

File: src/app/llm-findings.tsx (~line 46)

// Current
const [otherDetails, setOtherDetails] = useState<{ jira_details: any[]; prs: any[] } | null>(null);

JiraDetail and PrDetail are already imported in this file. The any[] typing hides contract mismatches between the API response and ProjectsCard's prop type at compile time.

Fix:

const [otherDetails, setOtherDetails] = useState<{ jira_details: JiraDetail[]; prs: PrDetail[] } | null>(null);

---

🔵 Suggestion

S1 · Import placed after interface declaration in llm-findings.tsx

File: src/app/llm-findings.tsx (~line 12)

The import type { JiraDetail, ProjectGroup, PrDetail, CommitDetail } line appears after the Highlight interface declaration. TypeScript hoists imports so this compiles, but import/first lint rules will flag it and it breaks file consistency.

Fix: Move the import to immediately after the existing imports at the top.

---

S2 · otherTab resets to 'jiras' on every toggle, including collapse

File: src/components/ProjectsCard.tsx (Other row click handler)

setOtherTab('jiras') fires on both expand and collapse. The named-project rows reset the tab only on expand. This means collapsing and immediately re-expanding the Other row always loses the active tab.

Fix:

onClick={() => {
  if (hasOtherDetail) {
    const expanding = !otherExpanded;
    setOtherExpanded(expanding);
    if (expanding) setOtherTab('jiras');
  }
}}

---

Deferred (not blocking merge)

#	Issue	Why deferred
D1	Shared activeTab across project rows	Architecturally fragile for multi-expand but fully correct today — each expand resets to firstTab
D2	noJiraData filter changed (commits-with-no-Jira → commits-with-no-PR) + inflightBlock sent without LLM instruction	Behavioral change worth validating empirically; not a correctness bug
D3	otherDetails arrays unbounded before caching to DB	Performance concern at scale, not a current blocker
D4	IIFEs in JSX for PRs/Commits tabs	Non-idiomatic but not incorrect; extract to named components in a follow-up
D5	showAll state not cleared on project collapse	Minor UX inconsistency on re-expand
D6	No unit tests for new enrichment logic (enrichKey, commitsByJiraKey, dedup)	Acknowledged in the plan doc; worth adding in a follow-up
D7	commitBySha silently drops 7-char SHA prefix collisions	Extremely rare in practice; log a warning when detected
D8	LLM context size guard missing	Acceptable at current data scale; add a cap/alert if report scope grows

---

Assessment: Not ready to merge as-is. I1 (SHA key collision) and I2 (regex single-match) are silent correctness bugs that affect drill-down data accuracy. I3 is a quick type-safety fix. S1–S2 are trivial. All four are straightforward changes.

[msogin]

Deferred: Missing tests for new enrichment logic

The existing test suite in src/lib/__tests__/unit/project-insights.test.ts validates the old LLM response shape (jira_count, estimated_commits, estimated_prs) but has no coverage for the new server-side enrichment added in this PR.

The enrichment logic is non-trivial and contains the two correctness bugs flagged in I1/I2 above — both of which would have been caught by tests. Suggested coverage:

• commitsByJiraKey multi-key extraction — verify a commit message with two Jira keys increments both entries (validates the regex g-flag fix)
• projCommitMap deduplication — verify a commit reachable via both a bare LLM SHA and a pr_number appears exactly once in projCommits
• enrichKey output shape — verify linked_commits and linked_prs counts are correct for a known set of Jira keys
• otherDetails computation — verify unattributed Jira/PR items are correctly separated from attributed ones

Not blocking merge, but worth adding before the next iteration on this route.