# Tracked release-gate inventory

Use this read-only audit when asked to inventory test and release gates from a repository without inspecting runtime/private data or changing the tree.

## Scope discipline

1. Freeze the allowed tracked surfaces (typically workflows, Makefile, `pyproject.toml`, package manifests, scripts, and tests).
2. Identify the exact snapshot with `git rev-parse HEAD`, branch, and status. Report whether untracked files exist; do not treat `git diff --check` as candidate-completeness evidence.
3. Read only tracked gate definitions. Do not open databases, reports, exports, logs, credentials, or productive runtime directories.
4. Do not claim a suite is green when only collection or static inventory ran. Label counts as collected, statically derived, or executed.

## Inventory method

- Map every Make/package target to its literal underlying command and execution order.
- Map each CI trigger, job, environment guard, install step, test command, timeout, count floor, migration check, lint/compile check, and repository-safety check.
- Compare current collected test counts with CI labels and floors. A passing exit code is not deletion protection; explicitly note suites with no numeric floor.
- For parameterized frontend tests, count expanded cases rather than only textual `it(`/`test(` calls. Prefer the test runner's list/collection mode when dependencies are available; otherwise state that the count is a tracked-source derivation.
- Inspect release/operations scripts separately from CI. A restart script is not a deployment pipeline unless it proves exact SHA, install/build, backup, migration, rollback, readiness, and post-start smoke.

## High-value baseline risks

Check for these recurring gaps:

- stale test-count labels/floors;
- one suite protected by a floor while another only checks process exit;
- Make variables that do not govern all subprocesses (for example `PYTHON=...` while a target invokes bare `pytest`);
- aggregate gates that omit CI-only lint, migration, compile, or security checks;
- different local and CI command scopes;
- build-before-safety ordering where generated output may be rejected by the safety scanner;
- `git diff --check` without an untracked-file check;
- partial-file lint presented as repository-wide lint;
- CI that runs only on pull requests/manual dispatch and provides no post-merge signal;
- operational scripts that kill listeners, bind broadly, or target a hard-coded checkout without release provenance;
- filename/secret-pattern scanning presented as semantic privacy verification.

## Reporting contract

Return:

1. snapshot and tree state;
2. current backend/frontend counts and how each was established;
3. exact local commands;
4. exact CI jobs and commands;
5. safety/privacy gates;
6. PR/CI/merge/deploy coverage, explicitly marking missing tracked automation;
7. concise baseline risks;
8. files modified (normally none for an inventory).

Do not invent publication commands and call them repository-defined. Separate tracked commands from recommended hardening.