dxkit-checkslisted

# dxkit-checks A **custom check** is any repo command dxkit runs as a first-class gate citizen. Two sources feed one seam: - **User checks** you declare in `.dxkit/policy.json:checks` — a project invariant (`check:no-cross-layer-imports`, `make lint`, a license audit, `scripts/arch-gate.sh`). - The **built-in lint gate** — each active language pack's linter (eslint, ruff, golangci-lint, rubocop, clippy, ktlint, dotnet analyzers), enabled with one policy flag. Both normalize to the *same* runner and inherit the *same* machine every native finding gets: fingerprint → baseline → git-aware matcher → brownfield classify → allowlist → guardrail verdict. So the guardrail blocks only a **net-new** failure and **grandfathers pre-existing debt** — you can turn on a lint gate against a repo with a thousand existing warnings and it will only ever block the error *this change* introduced. It is **opt-in, default-off**. A repo that declares nothing pays nothing (the runner spawns no process). ## See what's configured ```bash npx vyuh-dxkit checks # list configured user checks + active lint gates npx vyuh-dxkit checks --json # the same, machine-readable (agent-queryable) npx vyuh-dxkit checks run # DRY-RUN: execute each check, show pass/fail/skip + findings npx vyuh-dxkit checks run --json ``` `checks run` is a diagnostic — it runs the checks and shows *what the gate would see right now*, but it never blocks and never touches the baseline. Net-new-ness is decide