cursor

CodeInspectus REPORTS; the user DECIDES; you fix only with consent. Scans and reports never edit or delete your source code or repository (engine data and scan history stay under ~/.codeinspectus). Only codeinspectus_apply_cleanup and codeinspectus_rollback_cleanup change a repository, and only for an exact cleanup plan the user approved; codeinspectus_generate_sbom writes to a managed directory or an absolute .json path the user chooses. After generating or modifying code:

1. Scan — codeinspectus_scan on the workspace root (absolute path); local, zero egress; returns CWE-keyed findings + a remediation each. Inspect engine_setup: if it is not ready, explain the exact state (partial engine coverage only for repair_required; DB freshness/rescan continuity for db_refresh_recommended) and ask for approval before setup through codeinspectus_setup (plan first) or npx codeinspectus setup. Never download engines silently.
2. Surface first — present the findings to the user before any change: grouped by severity (criticals first), each with a plain-language risk explanation, the file:line, and the recommended fix from remediation. Never patch silently; never skip to fixing.
3. Select one finding — ask the user to choose exactly one finding to investigate. Triage Accepted is context only, not reproduction, checkpoint, or edit approval.
4. Checkpoint first, then fix. Before editing, if the scan's read-only git_safety.state is no_git or dirty, surface its recommendation and — only with user approval — offer a rollback point (git init + commit, or commit/stash current changes). The tool never runs git commands that change your repository; YOU do, only if approved (clean/unknown → stay silent). Do not edit yet; the selected finding's source-and-test proposal has its own approval gate below (CodeInspectus only reads/reports).
5. Rescan after the contract below — after its approved source patch and tests, codeinspectus_rescan, then report honestly: resolved / still firing / introduced. Don't claim a fix worked unless the exact-prior-scan rescan confirms it.
6. Secrets — for a hardcoded credential, tell the user to rotate/revoke the exposed key at the provider (already compromised; you can't rotate it), not just move it to env. Never report "fixed" without surfacing rotation.

Compliance: codeinspectus_compliance_report — code-level control coverage only, never certification or "% compliant".

Keep secret values redacted (CodeInspectus already redacts them).

Fix-one-finding contract

Load the selected prior scan_id, finding ID, and exact target. Inspect source, sink, controls, and reachability before editing; classify it as actionable, disproven, or unverified. If disproven, stop without calling it resolved. Reproduce only through an explicitly approved, bounded, local, reversible, safe method; otherwise record unsafe-to-reproduce as a proof gap.

Identify or propose a focused regression without adding it yet. Propose the smallest source-and-test patch for this finding only and request patch approval separately from triage, investigation, reproduction, and checkpoint approval. Make no source or test edit before explicit patch approval; if rejected, do not edit. After approval, add the focused regression first and capture failing-before-fix evidence when practical. If it cannot run or does not reproduce the condition, stop before the source patch unless that proof gap is explicitly accepted.

Then apply the source patch, run focused and relevant tests, and call codeinspectus_rescan on the same target with the exact original scan ID as prior_scan_id. Claim scanner resolution only when CodeInspectus returns the target in resolved; remaining is unresolved and not_rechecked is a proof gap. Keep unrelated findings untouched. Report investigation, regression, test, and rescan/proof-gap evidence separately.