# Offensive audit — How to periodically audit a whole business flow (for self-taught developers)

> Source: <https://dev.to/dexterlung/offensive-audit-how-to-periodically-audit-a-whole-business-flow-for-self-taught-developers-45f1>
> Published: 2026-07-28 15:25:33+00:00

**May 2026** · Series "Trace Lock — Governance notes from pairing with AI to write code" · Post 3 of 9

The previous post ([A1 Defensive](https://./trace-lock-a1-defense-en.md)) covered "locking down a known cross-layer relationship" (defensive, reactive). This post covers the opposite direction: **proactively running an audit pass to find unprotected chain nodes across a whole business flow, then fixing them all at once** (offensive, proactive).

The two mental modes are complementary: A1 is "lock it down after you trip on it," this post is "patrol regularly to find unexploded bombs."

This post is still the plain-language version for self-taught developers. Engineering details (6-piece fix pattern templates, how to write a governance rule, how to run SQL tests) go into B2 (engineer-facing).

May 25th, midday. Customer screenshot: "The roasting station's 'complete' button is frozen, showing 'roast level mismatch' error."

I stared at the screen for 30 seconds. Should I fix it the usual way? One line, comment out the RAISE statement, done.

But this was the 5th "cross-layer contract drift" bug in 6 months. Each one took 3-5 hours, totaling 15-25 hours. Every fix I thought "this should be the last one," then the next month another one appeared.

I asked Claude one question:

"I've fixed 5 of these in 6 months. Should I stop and look for

all leaks of the same shape, fix them all at once?"

Claude proposed: **Spend 1 hour auditing the whole business flow first. List which chain nodes are unprotected. Then decide what to fix first.**

Claude and I sketched out the "order to shipment" business flow, listing 11 chain nodes (every step from customer order to shipped package that touches data).

For each node, I asked 3 questions:

After running through:

The 4 BLOCKERs were:

Each one was a "next customer to trip on this costs me 3-5 hours" landmine.

While listing the BLOCKERs, I noticed something easy to miss: **these BLOCKERs are BLOCKERs not because the code is broken, but because "how the business should work" isn't written down**.

Take "should refund go back to cash first or bonus first":

So the first output of the audit **isn't fixing code**. It's **formally writing down these 4 business decisions**:

`created_at ASC`

order; inventory invariant: total before minus total after equals consumedOnce written down, these decisions transform from "my personal preference" to "system contract." Anyone (future me, AI included) who wants to change them will see them.

I gave this step a working name: "**Decision Pinning**" (working name, my own).

When fixing the 4 BLOCKERs, each one applied the same 6-step template:

The first BLOCKER took 2 hours to get familiar with the template. Second: 1.5 hours. Third: 1 hour. Fourth: 45 minutes (excluding one special detail for a new category). **Marginal cost decreases each iteration**.

The whole sprint took 7 hours for 4 BLOCKERs, including writing the sprint summary. Compared to the "fix one at a time" mode (estimated 12-20 hours), **direct-time ROI is about 2-3x**. But the audit path also prevents N future bugs, so equivalent ROI I estimate at **5-8x**.

After fixing each BLOCKER, I did one thing: **deliberately break the helper to confirm the test actually fails red, and remove the caller exemption to confirm the governance rule actually blocks the commit**.

Sounds redundant? It caught me twice writing "locks that are too loose":

**Reverse verification is the lock for the lock.** Protection without reverse verification might be "tested but doesn't actually test," worse than no test (gives false confidence).

The process of fixing all 4 also surfaced "things not to step on next audit":

`sql-only-trace`

`\S{5,}`

doesn't necessarily match 5 consecutive Chinese characters)I wrote these 7 into the sprint summary so the next business-flow audit can reuse them directly.

If you're a solo dev who pairs with AI a lot:

Don't wait for the next bug to surface. By the time a bug surfaces, a customer has already tripped on it. The audit catches things before customers do.

With only A1 (reactive lock-down of known traces), protection always trails the bugs. At best you break even.

With only B1 (proactive audit), the BLOCKERs you find rot if not turned into trace locks. Next month they reappear.

Used together:

That's the "dual-blade" approach covered in C1 Offense + Defense combined.

This post is an organized record of conversations I had with Claude (an AI pair-programming tool)

during May 2026. I noticed some patterns worth keeping for my own future reference,

so I asked Claude to help structure them into writing.

A few things I'm **not** claiming:

If a professional engineer spots misuse, or there's already a more standard name for any of these concepts, **I genuinely welcome corrections**.

*本文原載於我的部落格： Offensive audit — How to periodically audit a whole business flow (for self-taught developers)*