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.
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):
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.
| 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 |
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.
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.
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: In C1 I listed 5 scenarios where trace lock doesn't apply. Extending that to "who can skip this whole series":
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. 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.
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. 本文原載於我的部落格： Series reading guide — How to pick which of these 9 Trace Lock posts to read