Slop Audit result
openhonest/slop-audit
How many end-to-end test cases would fully cover this code?
Can be fully verified.
Full verification is possible here because no function shares mutable state. This means that we can count every possible state change. The Slop Audit builds the graph of every branch the code can reach and finds the fewest paths that walk all of it. 205 test cases cover every path, both the taken and the not-taken side of each decision. There is no need to test every theoretically possible combination of functions because we can determine which ones call which other ones.
Can this code be verified?
The finite-testability indicators. These have no compliance-framework mapping on purpose: they are the ceiling on what every other control below can ever prove.
-
0.0%How much depends on hidden state L1.18 · mutable-state ratioClean
The share of functions whose behavior depends on state outside their inputs. Each one pulls in shared state that can be changed by another part of the code at any time, which is why this code can never be exhaustively tested. It is also the single number that predicts race conditions, order-dependent test failures, and stale-cache bugs.
-
414Decisions that could be exhaustively checked L1.19 · decision-space coverageNo data
How many finitely-enumerable decisions (dispatch keys, match arms, enum branches) exist in the code. What fraction your tests actually cover is the real L1.19 number, and it requires running your test suite, which this tool never does. Run the CLI on your machines to get the coverage figure.
How it maps to your audit
Each signal below is cross-indexed to the Slop Audit's enterprise dimensions and the compliance controls they answer to.
-
11.01/klocEscapes from the type system L1.15 · type-escape densitySlop
How often the code opts out of its own type checker (any, # type: ignore, interface{}, dynamic) per thousand lines. Each escape is a spot the compiler can no longer protect, so a test has to cover it by hand.
Counts toward Dependency injection · 4.12 NIST SA-11 · ISO/IEC 25010 (testability) -
0.0%“God-files”, files too big to hold in your head L1.17 · god-file concentrationClean
The share of files over 1,000 lines, an AI smell. AI assistants pile new code into the biggest file they can find; without a reviewer forcing a split, these grow until every change touches them and merge conflicts multiply.
Counts toward Tech-debt management · 4.17 NIST CM-8 / SA-15 · SOC 2 CC7.1 · ISO/IEC 25010 -
0.0%Indications that a human ever edited the file L1.16 · trailing-whitespace densityClean
Harmless on its own, but an AI smell: lines left with trailing whitespace mean no editor or formatter touched the file between 'the AI wrote it' and 'it landed on main', which usually means no human reviewed it either.
Counts toward SDLC with AI safeguards · 4.16 NIST SA-3 / SA-8 · SOC 2 CC8.1 · OSFI B-13 §4.1.3 -
1Automated build-and-test pipelines L1.10 · CI/CD pipelinesCaution
How many pipelines build, test, and gate each change before it ships. Zero means every merge is a manual act of faith.
Counts toward CI/CD · 4.10 NIST SA-11 / SA-15 / CM-3 · SOC 2 CC8.1 · OSFI B-13 §4.7 · SSDF PW.7 -
absentA reproducible environment L1.11 · containerizationSlop
Whether the repo ships a container or orchestration config so it runs the same on every machine. The container is the constraint that keeps an AI's environment-coupling habits from becoming the classic 'it works on *my* machine.'
Counts toward Containerization · 4.11 NIST SP 800-190 · SP 800-53 SA-11 / SI-7 -
presentChecks that run before every commit L1.9 · pre-commit hooksClean
Whether automated checks run before code can even be committed, the first gate that catches AI output before a human ever sees it.
Counts toward CI/CD · 4.10 + SDLC safeguards · 4.16 NIST SA-11 · SOC 2 CC8.1