May 2026 · Series "Trace Lock — Governance notes from pairing with AI to write code" · Post 5 of 9
This series has 9 posts total. They're an organized record of conversations I had with Claude between late April and end of May 2026.
After writing the first 4, I re-read them and noticed a problem: readers won't know where to start. The difficulty range goes from beginner to advanced. The content jumps from personal narrative to engineering implementation details. Reading from post 1 to post 9 in order will probably make you give up by post 3.
So this post is a map, not content. If you only read this one and leave, that's fine with me.
What this series is about
In one sentence: when pairing with AI to write code, cross-layer bugs kept happening, so Claude and I worked out two governance patterns that pair together.
Both patterns are working names I gave them myself (not industry-standard terminology):
- Defensive Trace Lock: after tripping on a cross-layer bug once, lock down that relationship so it doesn't rot later
- Offensive audit: proactively audit a business flow (e.g. "order to shipment"), find all unprotected chain nodes, fix them in one pass
Combined, they form what I call the "dual-blade" approach. The 9 posts spread these 2 patterns across 3 layers: plain-language version, engineering version, and meta reflection.
Map of the 9 posts
| Post | Topic | Series category | Difficulty | Word count | Who it's for |
|---|---|---|---|---|---|
| E | Meta: how the methodology emerged from conversations with AI | Cross-field diary | beginner | EN 1300 / ZH 1700 | Wants to know how the whole thing came together |
| This post | Series reading guide | Cross-field diary | beginner | EN 700 / ZH 900 | Wants to decide which posts to read |
| A1 | Defensive Trace Lock plain-language intro | Indie dev notes | intermediate | EN 2000 / ZH 2500 | Already hit cross-layer bugs, wants to see how to lock them down |
| B1 | Offensive audit plain-language intro | Indie dev notes | intermediate | EN 1600 / ZH 2100 | Wants to know how to audit a whole business flow in one pass |
| C1 | Offense + Defense combined | Indie dev notes | intermediate | EN 2000 / ZH 2500 | Wants to see how the two pair up + where this doesn't apply |
| A2 | Defensive engineering version | Engineer diary | advanced | EN 2000 / ZH 2500 | Wants the 5-artifact implementation details |
| B2 | Offensive engineering version | Engineer diary | advanced | EN 2000 / ZH 2500 | Wants the 6-piece fix pattern template |
| C2 | Cross-project reuse matrix | Engineer diary | advanced | EN 2000 / ZH 2500 | Wants to port this to their own project, needs to know what transfers |
| D | sql-only-trace | Engineer diary | advanced | EN 2000 / ZH 2500 | How to test pure-DB logic |
Three reading paths
"I only have 30 minutes"
Read E meta (how the whole thing came together) plus this guide. That's enough.
You don't need to look at the specific patterns. E meta compresses the whole journey into one post. After reading it you'll know "this kind of thing exists, here's the context it fits." That's fine.
"I'm not a software engineer but I'm curious about how AI pair programming gets governed"
Order: E meta → A1 → B1 → C1.
Skip the 4 engineering posts. The 3 plain-language posts cover the full thinking, real time costs, and where the approach doesn't apply. After reading you'll have a sense of "is there an analogue to this in my own work." If you're a designer, product manager, or like me a self-taught coder, this path fits best.
"I'm an engineer, I want implementation details"
Order: A1 (shared baseline) → A2 → B2 → C2 → D.
A1 is required reading because the engineering posts assume you know what the 5 artifacts are. A2/B2/C2/D are where the code examples, governance rule templates, and pure-SQL test gotchas live.
If you only want one technical angle:
- "How is the protection rule written" → A2
- "How does the cross-layer audit actually run" → B2
- "Can I port this to my project" → C2
- "How do I test pure-DB logic" → D
Who this series is not for
In C1 I listed 5 scenarios where trace lock doesn't apply. Extending that to "who can skip this whole series":
- Your project is pure read-only reporting / pure frontend without DB. The whole approach doesn't fit
- You don't pair with AI to write code. The series premise doesn't hold
- You're on a 5+ person team with strong code review culture. Defensive may overlap with human review, value drops
- You're looking for "best practices" or "industry standards." This series doesn't offer those. I name things myself, estimate time myself, list where it doesn't apply myself. No authority claims
- You want to read just one post and leave. Apart from this guide, the others assume context, so cherry-picking only works in the order I suggested above
Shared vocabulary: the working names
Names that recur across the series (none of them are industry-standard terminology):
| Name | Meaning | First appears |
|---|---|---|
| Trace Lock | Locking a cross-layer relationship with 5 artifacts | A1 |
| Offensive / Defensive | The two audit modes | A1 / B1 |
| Dual-blade | The closed loop where both modes pair up | C1 |
| Decision Pinning (business contract freeze) | Writing the rule down explicitly before fixing a BLOCKER | B1 |
| 6-piece fix pattern | The 6 steps for fixing one BLOCKER | B1 / B2 |
| sql-only-trace | The trace category for pure-DB logic | D |
| 5 artifacts | The 5 things every defensive trace must contain | A1 / A2 |
If you hit an unfamiliar term in any post, come back here.
Why I wrote these 9 posts
Not because I think the patterns "need to be known by the industry." Because I tripped on the same shape of bug for half a year, the conversations with Claude when sorting it out got long, and I was afraid of forgetting. The blog version is partly for my own future re-reading, partly so that if a professional engineer sees me misusing something they can correct me.
There's no "teaching" stance when I was writing. I noticed I'd written 9 posts only after they were done, so I laid them out and put them on the blog.
Related posts
- E · Meta: how the methodology emerged from conversations with AI (series starting point)
- C1 · Offense + Defense combined (dual-blade overview, read this before deciding whether to go into A2/B2/C2/D)
- 中文版
About this post
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:
- Terms used in this post (Trace Lock / Offensive / Defensive / Dual-blade / Decision Pinning / 6-piece fix pattern / sql-only-trace / 5 artifacts) are working names I gave them myself, not industry-standard terminology
- My system has a specific shape (solo-maintained, many cross-layer dependencies, ambiguous business contracts). These patterns may not apply to your context
- I'm not a software engineer, just a barista who pairs with AI to write code
If a professional engineer spots misuse, or there's already a more standard name for any of these concepts, I genuinely welcome corrections.
本文原載於我的部落格：Series reading guide — How to pick which of these 9 Trace Lock posts to read
Top comments (0)