Problem
The backend's `/api/v1/scan` response schema is hand-mirrored in three separate places with no shared definition and no CI check catching drift:
- `cli/src/types.rs` (Rust)
- `frontend/src/types/scan.ts` (TypeScript)
- `vscode-extension/src/types.ts` (TypeScript)
`SKILLS.md` already flags this risk explicitly: "Changing the finding schema: if `app/api/v1/scan.py`'s response model changes, update `src/types.ts` in lockstep (mirrors the same contract used by `frontend/src/types/scan.ts` and `cli/src/types.rs`)." — currently enforced only by convention/documentation, not tooling.
Proposed fix
Options to evaluate:
- Generate an OpenAPI schema from the FastAPI backend (`app.openapi()`) and codegen the TS/Rust types from it in CI, failing the build if committed types don't match
- At minimum, add a CI check that fails if `scan.py`'s response model changes without corresponding changes to all three consumer type files (even a rough heuristic — e.g. flag the PR for manual review — beats silent drift)
Problem
The backend's `/api/v1/scan` response schema is hand-mirrored in three separate places with no shared definition and no CI check catching drift:
`SKILLS.md` already flags this risk explicitly: "Changing the finding schema: if `app/api/v1/scan.py`'s response model changes, update `src/types.ts` in lockstep (mirrors the same contract used by `frontend/src/types/scan.ts` and `cli/src/types.rs`)." — currently enforced only by convention/documentation, not tooling.
Proposed fix
Options to evaluate: