ci(frontend): add react-doctor check for landing site

[harshitsinghbhandari]

Summary

Adds a CI job that runs react-doctor against the Next.js 15 + React 19 landing site at `frontend/src/landing/`.

Why it earns its place

• Real React surface, no current lint. `frontend/src/landing/` has 29 `.tsx` components (Next.js 15 + React 19 + fumadocs). There is no ESLint config there, and the only frontend-related CI today is the `schema.ts` drift check in `go.yml`. React Doctor produces signal that nothing else in this repo catches: state-and-effects bugs, perf footguns, a11y, and security rules tailored for React/Next.js.
• Actively maintained, MIT, no auth, fast. v0.4.0 published 2026-06-06, commits today, MIT-licensed, no API keys, runs in ~5s on this codebase via oxlint.
• Non-disruptive baseline. Default `--blocking=error` surfaces findings without failing CI on warnings. Current state: 0 errors, 58 warnings (24 bugs, 11 perf, 5 a11y, 1 security, 17 maintainability). The check is green on day one; the warning backlog can be triaged separately, and we can tighten to `--blocking warning` later.
• Telemetry off. `--no-telemetry` keeps CI runners from pinging react.doctor.

What triggers it

Pull requests that touch `frontend/src/landing/**` or the workflow file itself; also pushes to `main`. Backend-only PRs do not pay for this check.

Example output (current main)

```
React Doctor v0.4.0

All 58 issues

Security › 1 warning
Bugs › 24 warnings
Performance › 11 warnings
Accessibility › 5 warnings
Maintainability › 17 warnings
```

Files

• `.github/workflows/react-doctor.yml` — new workflow, path-filtered.
• `frontend/src/landing/package.json` — adds `react-doctor` devDep and `doctor` script.
• `frontend/src/landing/package-lock.json` — refreshed via `npm install`.

Test plan

• CI `React Doctor / doctor` job is green.
• Existing `Go`, `CLI E2E`, and `gitleaks` jobs unaffected.
• Locally: `cd frontend/src/landing && npm ci && npm run doctor` exits 0.

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

This PR adds a new GitHub Actions workflow that runs the react-doctor composite action against the Next.js 15 + React 19 landing site at frontend/src/landing/, path-filtered to fire only when landing-site files or the workflow itself change.

• New workflow (.github/workflows/react-doctor.yml): triggers on push to main (path-filtered) and on pull_request; runs millionco/react-doctor@v2 with pull-requests: write and statuses: write to post inline annotations and a sticky PR comment.
• Action pinning: the action is referenced via the mutable floating tag @v2 while holding write permissions; the upstream docs explicitly recommend SHA pinning in this case to guard against supply-chain risk.
• Checkout version: actions/checkout@v4 is used, whereas the react-doctor v2 migration guide calls for @v5 with a deeper checkout for accurate diff-scoped scanning.

Confidence Score: 4/5

Safe to merge after pinning the action to a commit SHA — the workflow logic is correct and path-filtering works as intended.

The workflow grants pull-requests: write and statuses: write to a third-party composite action referenced only by the mutable floating tag @v2. If that tag is ever moved to a different commit, arbitrary code runs with write access to PR comments and commit statuses. Pinning to the current SHA resolves this; everything else in the workflow is straightforward.

.github/workflows/react-doctor.yml — specifically the millionco/react-doctor@v2 step which should be pinned to a full commit SHA.

Security Review

• Supply chain risk via mutable action tag (.github/workflows/react-doctor.yml line 30): millionco/react-doctor@v2 is a floating tag. Because the job holds pull-requests: write and statuses: write, any future movement of that tag — malicious or accidental — could execute arbitrary code with write access to PRs and commit statuses. The upstream docs explicitly recommend SHA pinning in this scenario.

Important Files Changed

Filename	Overview
.github/workflows/react-doctor.yml	New CI workflow that runs the react-doctor composite action; uses a mutable floating tag (@v2) while holding pull-requests: write and statuses: write, which the upstream docs flag as requiring SHA pinning.

_{Reviews (3): Last reviewed commit: "ci(frontend): use react-doctor GitHub Ac..." | Re-trigger Greptile}

[github-actions]

No React Doctor issues found. 🎉

_{Reviewed by React Doctor for commit 9d33710.}

[greptile-apps]

Unpinned mutable action tag with write permissions

millionco/react-doctor@v2 is a floating tag; if the upstream repo moves that tag to a new commit (accidentally or due to a supply-chain compromise), arbitrary code will run with pull-requests: write and statuses: write on every triggered workflow. The react-doctor docs explicitly call out this exact scenario: "For hardened CI — recommended whenever the workflow is granted pull-requests: write — pin to a full commit SHA instead and let Dependabot or Renovate keep it current." Pinning to the SHA of the current v2 head and adding a Dependabot/Renovate entry for the action removes the risk while keeping the version current.