Quality Tooling Rollout

[MatiasOS]

Summary

The repo already has Biome linting, broad Playwright E2E coverage, Dependabot for GitHub Actions only, and a custom npm audit workflow. Unit tests pass locally, but there is no dedicated unit-test CI gate, coverage reporting, code scanning, or secret scanning.

Priority order for this repo:

1. Add hard CI gates for typecheck and unit tests.
2. Add code scanning with GitHub CodeQL.
3. Add secret scanning with Gitleaks.
4. Extend dependency security with npm Dependabot + GitHub Dependency Review.
5. Add Vitest coverage reporting for unit tests.
6. Optional: Snyk as one paid security platform after the GitHub-native baseline.
7. Optional: SonarCloud/SonarQube after coverage is flowing. This improves maintainability and “new code” quality gates.

Implementation Changes

1. Core gates first

• Fix the current TypeScript drift so npm run typecheck passes again; this is the highest-signal missing gate today.
• Add required GitHub workflows for:
  • typecheck
  • unit-tests
  • coverage
• Keep existing E2E jobs as-is; do not replace them with unit coverage metrics.

2. Security scanning

• Add a codeql.yml workflow for JavaScript/TypeScript and GitHub Actions scanning.
• Add a gitleaks.yml workflow to fail PRs that introduce secrets.
• Expand .github/dependabot.yml to cover npm dependencies in the repo root and worker/.
• Add GitHub Dependency Review on pull requests so vulnerable or risky dependency diffs are visible before merge.
• Keep the current audit.yml temporarily, but treat it as secondary to Dependency Review plus Dependabot because the current npm audit flow is a Bun workaround, not the main policy layer.

3. Coverage and reporting

• Enable Vitest coverage output in vitest.config.ts with text, html, and lcov reporters.
• Scope coverage to unit-testable app code; do not include Playwright E2E in the percentage.
• In phase 1, publish coverage as a PR artifact/summary without failing the build on a global threshold.
• In phase 2, after one stable baseline cycle, enforce thresholds on new code only; do not block on legacy uncovered files immediately.

4. Optional vendor layer

• If adding exactly one paid tool, choose Snyk first.
  • Use it for dependency alerts, license visibility, and PR blocking on critical/high issues.
  • This repo has many third-party packages plus multiple provider integrations, so supply-chain risk is more immediate than maintainability dashboards.
• Add SonarCloud later if you want PR decoration for code smells, duplication, and “new code” quality gates.
  • Prefer SonarCloud over self-hosted SonarQube unless you specifically need self-hosting or on-prem compliance.

Public Interfaces / Config Impact

• No runtime public API changes.
• New/updated CI and repo config only, mainly under:
  • .github/workflows/
  • .github/dependabot.yml
  • vitest.config.ts
  • package.json

Test Plan

• PR introducing a TypeScript contract drift must fail on typecheck.
• PR introducing a leaked key or token must fail on Gitleaks.
• PR bumping a vulnerable package must surface a failing dependency/security signal.
• PR must show unit-test coverage output in the checks UI or as an artifact.
• CodeQL findings must appear in GitHub Security or annotate the PR when applicable.
• Existing lint and E2E workflows must continue to run unchanged.

Assumptions and Defaults

• Recommendation is optimized for a lean GitHub-native setup, not a vendor-heavy stack.
• The repo should block merges on correctness and security before adding dashboard-oriented tooling.
• Coverage should start as visibility-only because current unit-test breadth is still small relative to the codebase.
• If budget allows only one external platform, default to Snyk before Sonar.