security-review/checkers/fixtures/compliance-drift/README.md

# compliance-drift canary fixtures

Planted-drift corpus for `checkers/compliance-drift.sh --canary` (offline, no network/token).
The checker asserts the total drift count equals `EXPECTED_DRIFT_COUNT` (anti-complacency floor,
design §6.4). If a check regresses (stops firing), the count drops and the canary FAILS (exit 3).

Fixtures (each a real git checkout so the tracked-`.env` / `ls-files` checks work):

| Fixture | Planted drift | Count |
|---|---|---|
| `clean-repo` | none — kebab name, README, ci.yaml, dependabot.yml, `.env` is **gitignored** (must NOT fire) | 0 |
| `BadName_repo` | non-kebab name; no README; no ci.yaml; has `package.json` but no `dependabot.yml`; tracked `.env` with values | 5 |
| `docs-repo` | docs-only (CI skipped via DOCS_ONLY_REPOS), kebab name, no README | 1 |

Total = **6** (`EXPECTED_DRIFT_COUNT`). The canary pins `DOCS_ONLY_REPOS=docs-repo` and
`COMPLIANCE_EXEMPT=""` internally so it is deterministic regardless of the operator's env.

**Secret-fixture naming:** `BadName_repo`'s planted tracked-secret env file is committed as
`dotenv.fixture`, NOT `.env`. The repo's root `.gitignore` lists `.env`, so a literal `.env`
fixture would silently never be committed — on a fresh clone the `secrets-committed` drift would
vanish and the count would drop to 5 (this regression was caught by this very canary). The
`--canary` materialization renames `dotenv.fixture` → `.env` in its temp work area; the
`dotgit/` index already TRACKS `.env`, so `git ls-files` still reports it. This mirrors the
`.fixture`-suffix convention the `dependency-cve` fixtures use for their manifests. Keep any new
committed secret fixture under a non-gitignored name and rename it in the canary.

When you add/remove a check or fixture, update both the fixture and `EXPECTED_DRIFT_COUNT`
in the same commit (the canary edit is itself caught on the next run — design §6.4).