The six profiles

A profile is a pack of lenses. Each lens is one adversarial question, asked by its own finder agent. The profile decides what gets asked; it never decides what gets believed - every lens in every profile runs through the same refute panel.

Profile	Invocation	Hunts
project	audit (the default)	per artefact type - PRD, TRD, TSD, personas, epics and stories, code, design and RFCs - plus cross-artefact traceability
repo	audit --profile repo	architecture, code quality, defensive security
code	audit --profile code	correctness, security smells, pattern violations, drift between code and its acceptance criteria
test	audit --profile test	can it fail, does it reach the code, does the docstring match the assertion, is it incidentally green
process	audit --profile process	how the work was produced: path-from-memory, count-by-hand, accepted-without-running, repair-without-plan, skipped-preflight
skill	audit --profile skill	over-engineering, token economy, determinism, external benchmark

# see a pack's lenses and its refute threshold before launching
readiness.py profile --name repo

A name no profile declares is refused, and the refusal names the ones that exist. An audit never runs an empty lens set.

repo - the one to start with

Three lenses, no adoption required, and one binding rule worth stating plainly:

Caution

Security findings are remediation-only, by design. They report location, weakness class, realistic impact and a concrete fix. No proof-of-concept exploits, no payloads. A committed secret is reported by its location plus rotation instructions, and the value is left where it is - never copied into a finding, an index or a report.

That is a constraint on the output format, not a disclaimer. An audit that pastes your secret into a markdown file has leaked it a second time.

test - the tests that prove nothing

The most expensive kind of green is the kind that was never earned. This pack reads source and tests together and asks four questions a passing suite cannot answer about itself:

• Can it fail? Break the code on purpose - does the test die?
• Does it reach the code? A test that never executes the branch it claims to cover is decoration.
• Does the docstring match the assertion? A test named for one behaviour and asserting another will mislead the next reader for years.
• Is it incidentally green? Passing for a reason unrelated to the thing under test.

process - the pack that hunts vibe coding

The most on-brand thing in the toolchain, and it exists for an uncomfortable reason.

This project’s own description is the antidote to vibe coding. In one recorded run, its author vibe-coded repeatedly - ten repair rounds written by reading a finding and immediately editing, no plan, no approach weighed, and every round from the third onwards found a defect the previous repair had created. A path was written from memory with the wrong prefix six times, twice inside artefacts about that very defect.

The failure was not ignorance. The rule had just been written down. So the pack looks for the shape rather than trusting the discipline:

Lens	The question it asks
path-from-memory	was this path, id or field resolved against the tree, or written from memory?
count-by-hand	is this count kept by hand beside a mechanism that already derives it?
accepted-without-running	did this check execute, or was a green read off something that never ran?
repair-without-plan	was this repair attacked as an approach before it was written?
skipped-preflight	was a cheaper, scoped or already-existing form of this work looked for first?

The class is uniform: work done before the contract it depends on was established.

Tip

A tool that claims to be the antidote to vibe coding and cannot detect it in its own delivery is making a claim it does not check. That is why this pack was written.

Every lens declares its detector, or admits it has none

This is the part that keeps a lens pack honest. Each lens must name the signature that finds it - a runnable detector, naming a path that is actually on disk - or explicitly declare itself manual and state why no search can single the class out.

Two of the five process lenses are honestly manual. repair-without-plan is manual because a plan is not kept in the tree a search can reach. skipped-preflight is manual because whether somebody looked for a cheaper form first is a choice that leaves no artefact behind.

Saying so is the point. A reader can tell a detector from a hope.

readiness.py profile --validate            # hold every pack to its contract
readiness.py profile --name code --validate

It exits non-zero on any breach and names the pack and the lens. Run it after adding a lens of your own - packs are extensible, and a new lens is held to the same bar as the shipped ones.

Where to next

• How it verifies - the refute panel that decides what survives.
• Audit overview - the pipeline and the cost gate.
• Mutation testing - the mechanical cousin of the test pack.