Interactive field guide

The /module-audit sweep

Before a finished module ships, it gets swept: every form in it read through four lenses at once, ten cross-cutting checks across the whole thing, and every finding attacked and then verified against one frozen commit before it reaches you. The point is a fix list you can trust.

This is the heaviest pipeline we run, and the verification floor is deliberately strict. If it feels like too much machinery for the payoff, tell us where. Reply on LinkedIn.

How to read this map

Each card is a stage of the sweep, in order. The two tucked-in cards are half-stages: the adversarial pass and the final verification.

The colour on each card's edge tells you what kind of work it is: recon, the matrix, filtering, or fixing.

Open any card for the full, plain-language walkthrough at that stage.

Pick a stage to walk, or start at the top

Get this command /plugin marketplace add fire-farmer/red-line-toolkit view source →

The walkthrough, as text

Every stage of the interactive walkthrough above, as plain readable text. Each stage has its own link.

Stage 0Freeze one commit, map the formsThe coherence anchor

Recon

Before any auditing, one scout reads the module, freezes the exact commit it's about to audit, and lists every form component in scope. That frozen commit is the anchor: every finding later gets checked against it, so nobody audits one version and reports on another.

A recon pass freezes a single audit commit and maps the module's form components. That frozen commit is what every finding is later verified against.

What happens

The scout enumerates the module's forms, counts how stale each is, and freezes the current commit as the AUDIT_SHA. Everything downstream reads and reports against that one commit.

Two gates fire here. If the working tree is dirty, the audit stops and asks you to commit or stash first, because auditing uncommitted edits while verifying against a frozen commit is exactly what produces false findings. And if the module has fewer than three forms, it redirects you to the per-page pipelines, which are cheaper for small work.

Who acts

module-recon, agent: Freezes the audit commit and maps the forms in scope.
AskUserQuestion, command: The dirty-tree gate, the too-small gate, and a cost confirmation before the fan-out.

The rules

One frozen commit, start to finish. The AUDIT_SHA is set once and carried through; the final verifier checks against it, not against a moving HEAD.
Clean tree, or stop. Uncommitted edits break the link between what was audited and what gets verified; the audit will not proceed on a dirty tree by default.
Three forms or more. Below that, the per-page pipelines are the right tool and this heavy sweep is overkill.

In: A module name. Out: A frozen audit commit and a mapped list of the forms in scope.

Stage 1Run the whole matrix at onceForms times lenses, plus axes

The matrix

Now the breadth. Every form is read through four different lenses, and ten cross-cutting checks are run across the whole module, all dispatched at the same time. For a four-form module that is dozens of independent reads, each blind to the others, so no single angle is the only one that looked.

Each form is audited through four lenses (architecture, security, performance, data-integrity); ten cross-cutting axes sweep the module. All in one parallel pass.

What happens

The per-form lenses are architecture, security, performance, and data-integrity, each capped so it reports only its strongest findings. The ten cross-cutting axes cover things no single form owns: dependencies, bundle size, types, observability, migrations, cost, reversibility, tier-gating, test coverage, and static accessibility.

Everything runs in parallel and blind. Breadth is the point: a real problem tends to show up under more than one lens, and running them together is what surfaces the overlap the next stages lean on.

Who acts

module-lens-critic, agent: One per form per lens; reports that lens's strongest findings.
module-cross-cut-critic, agent: One per axis; audits the whole module on that single axis.

The rules

Blind and parallel. No critic sees another's findings, so none anchors on the others; the overlap that survives is a real signal.
Capped findings. Each lens reports only its strongest few, which keeps the synthesis honest instead of drowning it.

In: The frozen commit and the mapped forms. Out: A large pile of raw findings, one set per lens and per axis.

Stage 1.5Attack the findingsRed-team, steelman, repro

Adversarial · half-stage

Before the findings are trusted, three adversaries go at them. One hunts for what the critics missed. One writes the strongest defense of each must-fix, so weak findings show themselves. One sketches a test that would prove the worst findings are real.

An adversarial layer: a red-team finds misses, a steelman defends each must-fix, and a repro-sketcher drafts tests for the highest-severity findings.

What happens

The red-team reads every finding and looks for the gaps: chains between findings, a lens nobody applied, scope that crept. The steelman writes a one-sentence defense of each must-fix, which is how an inflated finding gets caught, by how weak its defense reads.

The repro-sketcher takes the high-severity findings with a concrete failure and writes a test sketch you could later promote to a real test. Nothing here is executed; it is all about pressure-testing the findings before they cost anyone a fix.

Who acts

module-red-team, agent: Finds up to five things the critics missed.
module-steelman, agent: Writes the strongest defense of each must-fix finding.
module-repro-sketcher, agent: Sketches tests for the highest-severity findings.

The rules

Steelman the must-fixes. A finding whose strongest defense reads thin is probably inflated; the defense is the tell.
Sketches, not tests. Repro sketches are for review, not execution; you decide later which become real tests.

In: The raw findings. Out: The findings, plus their misses, defenses, and repro sketches.

Stage 2Dedupe into one listMany angles, one finding each

Synthesis

All those parallel reads produce the same problem seen several ways. One pass merges the duplicates, tags what's left, and turns the pile into a single clean list ready for the referee. The merge is the product as much as the finding of it.

One synthesiser dedupes the findings across every lens and axis, tags them, and emits a single canonical list for adjudication.

What happens

The synthesiser reads every finding from the matrix and the adversarial layer, collapses the ones that are the same problem under different names, and tags what remains by kind and severity.

A healthy audit dedupes a large share of its raw findings here; if it barely dedupes, that is a signal the critics were generating non-overlapping noise rather than converging on real problems.

Who acts

module-audit-synthesizer, agent: Dedupes and tags every finding into one canonical list.

The rules

The same problem is one finding. Duplicates across lenses collapse to a single entry; the overlap is what proves it real, not what inflates the count.
Dedup rate is a health signal. A low dedup rate means the critics found unrelated noise, not a shared truth.

In: The findings and their adversarial notes. Out: One deduped, tagged list of findings.

Stage 3Referee, then your callKeep, ditch, or modify

Adjudicate

The same referee from the change-heavy pipeline marks each finding keep, ditch, or modify against the project's own standards. Then it stops and asks you which findings to actually absorb into the fix plan. This checkpoint is not skippable.

The Adjudicator marks each finding KEEP, DITCH, or MODIFY, then a mandatory checkpoint asks which to absorb into the fix plan.

What happens

The referee reads the deduped list and rules on each finding against the project's real standards, with a security-asymmetric bias so a plausible security finding is kept even when it is uncertain. Its own field guide walks how it judges.

Then the hard stop: you choose the absorption scope, must-fix plus high, must-fix only, everything, a specific list, or export the findings with no fix plan. Deferred findings can be routed to the backlog. Nothing gets planned without this call.

Who acts

the Adjudicator, agent: Marks each finding KEEP, DITCH, or MODIFY. Has its own guide.
AskUserQuestion, command: The non-skippable checkpoint: which findings to absorb.

The rules

Your checkpoint is non-negotiable. The audit never decides the absorption scope for you; that stop is always yours.
Security findings get the benefit of the doubt. A plausible security finding is kept even when uncertain; the cost of a miss is too high.

In: The deduped list. Out: A ruled, filtered set of findings you chose to absorb.

Stage 4Sequence the fixesOrdered, grouped, separated

Fix plan

From the findings you absorbed, one pass writes a fix plan: the work in dependency order, grouped into commits, with problems the audit introduced kept separate from problems that were already there. It plans the fixes; it does not make them.

A fix planner turns the absorbed findings into a sequenced, commit-grouped plan, separating newly introduced issues from pre-existing ones.

What happens

The planner orders the fixes so nothing depends on work that comes later, groups them into sensible commits, and separates issues the module introduced from issues that predate it, because the two deserve different urgency.

This stage only runs if you absorbed at least one finding. The plan is a document; the audit writes no code itself.

Who acts

module-audit-fix-planner, agent: Writes the sequenced, commit-grouped fix plan.

The rules

Intro'd versus pre-existing. Problems the module introduced are separated from ones that were already there; they carry different urgency.
A plan, not a change. The fix plan is the only write product; no source code is touched by the audit.

In: The findings you absorbed. Out: A sequenced, commit-grouped fix plan.

Stage 4.5Verify against the frozen commitThe trust floor

Verify · half-stage

The last guard. A verifier re-checks a sample of the findings against the frozen commit from step zero, using the exact code at that commit, not whatever HEAD is now. If too many findings don't hold up, the pipeline halts and refuses to hand you the fix plan.

A verifier checks the findings against the frozen AUDIT_SHA with git show, not HEAD. Below the trust floor, the pipeline halts.

What happens

The verifier reads each sampled finding's cited file at the frozen commit and confirms the described problem is actually there. A cheap first check catches findings that cite a line past the end of the file at that commit, a sure sign of incoherence.

Two rates come out: how many findings verified, and how many were snapshot mismatches. A high mismatch rate means the wrong commit was frozen or the tree drifted mid-run. Below the floor on either, the fix plan is not presented as actionable until it is re-verified.

Who acts

module-audit-verifier, agent: Verifies a stratified sample against the frozen commit, not HEAD.

The rules

Verify against the SHA, not HEAD. Findings are checked against the exact code that was audited, so a later fix or refactor cannot read as a false miss.
A floor that halts. If too few findings verify, or too many are snapshot mismatches, the audit stops rather than hand over a fix list it cannot stand behind.

In: The fix plan and its findings. Out: A verified fix plan, or a halt below the trust floor.

Stage ✓A fix list you can trustBreadth, then proof

Swept

What you end with is not just a long list of findings, but a short one that survived being attacked, deduped, judged, and verified against the exact code it was found in. That is the difference between an audit and a pile of opinions.

The sweep trades breadth for trust: many angles in, a verified fix plan out.

What happens

Every finding was read from several angles, stripped of duplicates, refereed against the project's standards, and checked against the frozen commit before it reached you. The floor means a fix plan is only handed over if it holds up.

This is the heaviest pipeline in the set, reserved for finishing a whole module. For a single page use the page pipelines; for a refactor use change-heavy; for one cleanup use cleanup-light.

The rules

Trust is the deliverable. The value is not the number of findings but that the surviving ones are verified against the code they were found in.

In: A module ready to ship. Out: A verified fix plan, or an honest halt.