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. 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. ## The 6 dimensions Each dimension is a 0-100 score with letter grade (A≥80, B≥60, C≥40, D≥20, E<20): | Dimension | What scores it down | |---|---| | **Security** | Secret leaks (gitleaks), SAST findings (semgrep), dependency vulns (osv-scanner / npm-audit / pip-audit / etc.), TLS-bypass patterns | | **Code Quality** | Lint findings (eslint / ruff / golangci-lint / clippy / detekt / rubocop / dotnet-format), hig