fix(web-ui): resolve react-hooks/exhaustive-deps warnings (#682)

[frankbria]

Closes #682.

What

Resolves the remaining react-hooks/exhaustive-deps warnings and enforces zero-warnings in CI lint.

Scope note: The issue listed 7 warnings. By the time this ran (after #658's eslint-10 + react-hooks plugin upgrade, which the issue explicitly sequenced before this work), only 3 remained — the 4 useMemo warnings in StressTestModal / GitHubIssueImportModal were already cleared by that upgrade.

Changes

File	Fix
proof/[req_id]/page.tsx	Add reqId to the mount effect deps (setters are stable; correctly reloads session filters if the route param changes)
BatchExecutionMonitor.tsx	Hoist const batchStatus = batch?.status and depend on it — preserves the original "re-run the poll only when status changes" intent
DiscoveryPanel.tsx	Reorder startNewSession before initSession (no back-dependency) and add it to initSession's deps, avoiding a TDZ reference
package.json	lint now runs eslint . --max-warnings 0 to prevent regressions (issue's optional acceptance criterion)

All changes are behavior-preserving.

Verification (outcome evidence)

• npm run lint → exit 0, 0 warnings (was 3 before)
• npm test → 1020 passed / 91 suites
• npm run build → succeeds

Acceptance criteria

• All remaining warnings resolved without regressions
• --max-warnings 0 enforced in the lint step

Known limitations

None. The 2 deliberate eslint-disable lines for mount-only effects (BatchExecutionMonitor initial fetch, DiscoveryPanel auto-init) are pre-existing and intentionally left as-is.

Summary by CodeRabbit

• Bug Fixes

  • Fixed filter state restoration when switching between different requirement IDs, preventing stale filters from persisting.

• Chores

  • Strengthened code quality standards by enforcing stricter linting rules.
  • Improved internal polling and hook dependency management for better stability.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 80a9a57f-7c22-4a1c-acee-a20a10ebf264

📥 Commits

Reviewing files that changed from the base of the PR and between a80d527 and 51d0ed6.

📒 Files selected for processing (4)

• web-ui/package.json
• web-ui/src/app/proof/[req_id]/page.tsx
• web-ui/src/components/execution/BatchExecutionMonitor.tsx
• web-ui/src/components/prd/DiscoveryPanel.tsx

---

Walkthrough

Three react-hooks/exhaustive-deps warnings are resolved: the proof page filter-restoration effect gains reqId as a dependency, BatchExecutionMonitor derives a batchStatus variable to use in its polling effect dependencies, and DiscoveryPanel moves startNewSession before initSession and adds it to initSession's dependency array. The lint npm script is hardened with --max-warnings 0.

Changes

ESLint Warning Fixes and Lint Gate Hardening

Layer / File(s)	Summary
useEffect/useCallback dependency corrections web-ui/src/app/proof/[req_id]/page.tsx, web-ui/src/components/execution/BatchExecutionMonitor.tsx, web-ui/src/components/prd/DiscoveryPanel.tsx	Adds reqId to the filter-restoration effect dependency array; derives batchStatus from batch?.status and uses it in the polling effect deps; relocates startNewSession before initSession and adds it to initSession's dependency array.
Lint script hardening web-ui/package.json	Changes the lint script from eslint . to eslint . --max-warnings 0, making any remaining ESLint warning a build failure.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• frankbria/codeframe#681: Re-enables npm run lint in CI, which this PR now tightens by adding --max-warnings 0 to the lint script and clearing the warnings that would fail under that gate.

Poem

🐇 Hop hop, the deps were missing,
Effects ran stale without a hissing.
reqId, batchStatus, startNewSession too —
Now every warning's bid adieu!
--max-warnings 0, the gate is sealed,
No sneaky lint shall go concealed. 🌿

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and specifically describes the main change: resolving react-hooks/exhaustive-deps ESLint warnings in the web-ui.
Linked Issues check	✅ Passed	The PR fully addresses issue #682 by resolving all 3 active react-hooks/exhaustive-deps warnings and enforcing --max-warnings 0 in the lint step as required.
Out of Scope Changes check	✅ Passed	All code changes are directly related to fixing react-hooks/exhaustive-deps warnings and enforcing linting as specified in issue #682.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/682-exhaustive-deps-warnings

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[claude]

Code Review

Good, focused PR. Four small changes, all behavior-preserving. Here is the breakdown.

package.json — Adding --max-warnings 0 is solid CI hygiene. Enforcing zero warnings prevents future regressions. No concerns.

BatchExecutionMonitor.tsx — Hoisting batchStatus = batch?.status is semantically identical to using batch?.status inline in the dep array. String primitives are compared by value, so polling behavior is unchanged. Clean linter fix.

proof/[req_id]/page.tsx — Adding reqId to the session-filter restore effect is the correct fix. Without it, navigating directly from one proof requirement to another (same component, new route param) would not reload filter state for the new req. This was a latent bug the linter caught correctly.

DiscoveryPanel.tsx — The reorder is correct and the reasoning is sound. The TDZ situation is real: with const, the declaration is not hoisted, so including startNewSession in initSession's dep array would throw a ReferenceError on first render if startNewSession appeared after initSession. The fix — declare startNewSession first, then add it to initSession deps — is the right approach.

Confirming the "no back-dependency" claim: startNewSession only calls discoveryApi.start and updates local state; it does not reference initSession. The dep chain is linear: workspacePath → startNewSession → initSession. No circular risk. The indirect dep chain means initSession re-runs whenever workspacePath changes, which is exactly correct.

Summary

File	Assessment
package.json	Good enforcement, no concerns
BatchExecutionMonitor.tsx	Correct linter-satisfying refactor
proof/[req_id]/page.tsx	Fixes a real latent bug
DiscoveryPanel.tsx	Correct reorder, deps are accurate

Verification evidence (0 warnings, 1020 tests passing, build succeeds) matches the scope of the changes. Ready to merge.