# Git-Safety Verification Coverage

Use this reference when hardening or reviewing the finance repo Git-safety scan and tests.

## Verification pattern after a file-mutation/verifier warning

If a verifier says a test file was not changed but the prior report says it was:

1. Check the exact commit, not memory:
   ```bash
   git show --name-status --oneline <commit> -- tests/unit/test_git_safety.py
   git show --stat --patch <commit> -- tests/unit/test_git_safety.py | sed -n '1,220p'
   ```
2. Read the current test and scanner source:
   ```bash
   sed -n '1,240p' tests/unit/test_git_safety.py
   sed -n '1,240p' src/jarvis_finance/quality/git_safety.py
   ```
3. If coverage is incomplete, add explicit tests rather than relying on broad aggregate assertions.

## Minimum Git-safety test coverage for FinanceManager

`tests/unit/test_git_safety.py` should explicitly cover:

- files named like `Github_token*` are blocked;
- GitHub PAT content patterns such as `github_pat_...` are blocked;
- `ghp_...` / related GitHub token prefixes are blocked;
- private key blocks are detected;
- CSV/JSON outside allowed paths are blocked;
- top-level runtime/data/export/report directories are blocked;
- synthetic CSV/JSON under `examples/synthetic/` are allowed;
- synthetic CSV/JSON under `tests/fixtures/` are allowed;
- `config.example/` is allowed;
- normal source-code files under `src/` do not false-positive, even when package names include `imports` or code contains ordinary variable names like `token_name`.

## Important implementation notes

- The Git-safety scanner should block top-level runtime/data directories, not source package directories with the same words (for example `src/jarvis_finance/imports`).
- After `compileall` or pytest, remove/ignore generated caches before running Git-safety:
  ```bash
  find . -type d \( -name __pycache__ -o -name .pytest_cache \) -exec rm -rf {} +
  PYTHONPATH=src python -m jarvis_finance.cli.main git-safety-scan .
  ```
- When staging tests that intentionally contain secret-like marker strings, exclude only the scanner/test files from ad-hoc staged secret grep. Do not weaken the production scanner itself.
- In reports, distinguish whether a file was actually changed in the target commit from whether the coverage was sufficient. Both can be true: the file changed, but the test matrix still needed hardening.