# Series reading guide — How to pick which of these 9 Trace Lock posts to read

> Source: <https://dev.to/dexterlung/series-reading-guide-how-to-pick-which-of-these-9-trace-lock-posts-to-read-48jm>
> Published: 2026-07-31 14:34:55+00:00

**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*