Julien Gautier f35045f3e8
CI / commits (pull_request) Successful in 1m52s
CI / check (pull_request) Successful in 2m1s
CI / scan (pull_request) Successful in 2m3s
CI / a11y (pull_request) Successful in 2m15s
CI / perf (pull_request) Successful in 4m40s
fix(ci): run scanners before pnpm install to avoid node_modules false positives
First successful gitleaks run flagged 381 "leaks" — all of them
inside `node_modules/` and `.pnpm-store/`, populated by the
`pnpm install --frozen-lockfile` step that runs earlier in the
job. Upstream packages routinely embed demo RSA keys / fake API
tokens in their READMEs and test fixtures, and gitleaks
(correctly, by its rules) flags them all. This is the same class
of false-positive Trivy hit before us in #49.

Move both scanners (Trivy + gitleaks) to BEFORE `pnpm install`:

- Trivy scans `pnpm-lock.yaml` for vulns; the lockfile is
  committed, no install required.
- Gitleaks scans the working tree (`--no-git --source .` in
  ci.yml; deep history in security-scheduled.yml). Without
  `pnpm install`, the only files present are our own source
  code, which is what we actually want to scan.
- `pnpm audit` reads `pnpm-lock.yaml` against the advisory DB —
  also doesn't need node_modules. The install before audit
  remains for the workspace-integrity sanity check.

Net result: clean scans, no allowlist file to maintain, scanners
run faster (smaller tree to walk).

The ordering rationale is documented inline at the top of each
job's `steps:` block so a future contributor doesn't innocently
shuffle the steps and re-introduce the false-positive flood.

Apply the same reordering to `security-scheduled.yml` for
consistency, even though its deep-history gitleaks scan does not
suffer the same false positives (history does not contain
node_modules; gitignored from day one).
2026-05-08 00:17:02 +02:00

Documentation index

This is the entry point to all project documentation. It is maintained automatically: any addition, rename, or removal of a .md file under docs/ must be reflected here in the same change.

Conventions

  • Documentation is written in English.
  • One topic per file. Group related files into a folder when there are three or more.
  • Cross-reference with relative links so they keep working in GitHub, IDEs, and exported sites.
  • For architectural decisions, do not add them here — they belong in decisions/ as MADR 4.0.0 ADRs.

Sections

Daily development

  • development.md — repo layout, prerequisites, initial setup, daily commands, dependency updates (Renovate), conventional commit cycle. Day-to-day reference for working on the project.

Architecture

  • architecture.md — cross-cutting Mermaid diagrams: C4 system context, C4 containers, Nx module boundaries, CI/CD pipeline. Single-decision diagrams (auth sequence, ERD, etc.) live inline in their ADR.

Onboarding & environment

Setup guides for new contributors:

Operations & runbooks

Empty — to be populated when we deploy.

Security, performance, accessibility

Empty — placeholders to be filled with rationale docs alongside their corresponding ADRs.

S
Description
No description provided
Readme 42 MiB
Languages
TypeScript 85.3%
JavaScript 5.4%
SCSS 4.3%
HTML 3.9%
Shell 0.8%
Other 0.3%