dxkit-learnlisted

# dxkit-learn This skill explains how dxkit works. Reach for it when the user asks about dxkit concepts before they take an action. ## Mental model dxkit measures a codebase along **6 dimensions** (Security, Code Quality, Tests, Documentation, Maintainability, Developer Experience) using deterministic scanners (gitleaks, semgrep, cloc, jscpd, graphify, ruff, eslint, …). Findings are anchored to a **baseline** (`.dxkit/baselines/main.json`) so today's pre-existing issues don't block tomorrow's PR. A **guardrail check** diffs current state against the baseline and blocks net-new regressions; two additive contract gates ride the same check when configured — **flow** (net-new broken UI→API integrations) and **schema drift** (breaking data-model changes, opt-in). Hooks + CI wire the guardrail into the developer's workflow. The three contracts to remember: 1. **Baseline = the brownfield anchor**. Pre-existing findings are recorded once; future scans only block on *additions*. 2. **Hooks fire fast (pre-push); CI fires thorough**. Both use the same guardrail logic. 3. **Reports are deterministic** — same code + same baseline = same findings. The salt mode (`deterministic` vs `random`) controls per-finding identity stability across runs. ## Discovering the full capability set (don't rely on this list staying complete) dxkit's capabilities grow. Rather than trust a hand-written list, read the **live capability registry** — the single source of truth for what dxkit can do: ```ba