95% coverage thresholds are configured but CI runs plain `npm run test`, so they never gate anything

[Jagadeeshftw]

Priority: Medium  ·  Area: CI / test coverage  ·  Est. effort: 5–8 h

📌 Problem

vitest.config.ts:17-21 configures coverage thresholds of 95% for branches and lines. package.json provides a test:coverage script.

.github/workflows/ci.yml:31 runs npm run test — the plain runner. grep -c 'test:coverage' .github/workflows/ci.yml returns 0.

So the thresholds have never gated anything across 59 test files, and actual coverage is unknown. There is already evidence of real gaps: src/hooks/useAsync.ts and src/lib/wallet.ts are the only modules in their directories with no test file at all (each tracked separately), so the true figure is very likely below 95%.

🎯 Design decision required

State and defend:

1. What is the current coverage? Run it and report per-metric numbers against the configured 95%. Everything else follows from that figure.
2. Gate scope. If the repo misses the threshold, do you gate globally at the current level as a ratchet that may only rise, or gate only changed files? Argue which will actually stay enabled — a gate that blocks every PR on pre-existing debt gets removed.
3. Which metrics block. Branch coverage is the one that catches untested error paths; say whether you weight it differently from lines.

🧩 Requirements and context

• Do not lower the configured 95% thresholds to make the gate pass. If they are unreachable today, keep them and narrow what is gated, then say so explicitly.
• The coverage run must replace or supplement the existing test step without losing the plain test signal.
• Report the added CI wall-clock cost — coverage instrumentation is slower.
• Coordinate with the useAsync and wallet.ts test issues: if those land first, the baseline improves. Say how you sequenced.
• All 59 test files must pass.

🛠️ Suggested execution

1. Run npm run test:coverage; paste the full per-metric report.
2. Identify the least-covered modules and list them — that inventory is useful beyond this PR.
3. Implement your gating decision.
4. Prove it fires — delete a test on a scratch branch, show coverage dropping below the floor and the job failing, revert.
5. Report runtime cost.

✅ Acceptance criteria

• The PR reports current coverage per metric against the configured 95%.
• The least-covered modules are listed.
• Coverage is enforced in CI, with the ratchet floor documented if the target is not yet met.
• The gate is proven to fail when coverage drops (link the run).
• The configured thresholds were not lowered.
• Added CI wall-clock time is reported.
• All 59 test files pass.

🚫 Out of scope

• Writing tests for useAsync or wallet.ts — separate issues.
• Adding the typecheck gate — separate issue.
• Changing threshold values.

🧪 Verification

npm ci
npm run test:coverage
npm run lint && npm run build

📤 What your PR must include

1. The full per-metric coverage report.
2. The least-covered module inventory.
3. Your gate-scope and metric-weighting decisions.
4. A link to a run failing on a coverage drop, plus runtime cost.
5. Closes #<n>.

🔒 Security notes

Branch coverage is the metric that tracks untested error paths — the code that runs when a wallet call is rejected, an API request fails, or data is missing. On a financial interface those are the paths where an untested regression becomes user-visible fastest, and they are exactly the branches an unenforced threshold lets erode.

📋 Guidelines

• Minimum 95% test coverage on changed lines
• Clear documentation
• Timeframe: 96 hours from assignment
• One logical change per commit; no merge commits

---

💬 Join our community

Working on this, or want to sanity-check your approach before you start? Come and ask — the maintainers are there and happy to help.

Telegram: https://t.me/Grainlify

[Mitch5000]

Can i work on this?