DEV Community: Dexterlung

I Kept Feeling Like I Was Wasting My Time — While Designing a Cross-Model Controlled Experiment

Dexterlung — Mon, 24 Aug 2026 13:05:21 +0000

I pulled 1,427 of my own prompts from six weeks with AI.
I meant to see "how did my way of asking change."
The sharpest thing wasn't the capability curve — it was that the curve and how I saw myself were a full tier apart.

Six months ago I wrote a piece called "Three Months, 1,604 Prompts: What Did AI Trade With Me?" That time I scanned "what I handle most." This time I wanted to look at something uglier: how do I ask — and did it change over six months?

I pulled every prompt I typed myself between June 15 and July 23 — 1,427 of them (stripping tool outputs, system messages, the fat-fingered interrupts) — cut them into six time windows, and measured them window by window.

The numbers were clear. What actually stopped me was the person standing next to the numbers.

First, the numbers: my way of asking really did shift gears

I tagged each prompt with a few categories of vocabulary, sorted by time:

Period	Adversarial / verify / root-cause	Meta / governance / method	Delegation / automation / batch
Mid-to-late June	4%	13%	14%
Late June	9%	28%	34%
Early July	21%	36%	34%

In under six weeks, "make the AI push back, verify this, find the root cause" grew fivefold; "talk about method, governance, systematizing" nearly tripled. My average prompt length also jumped from just over 200 characters to around 1,000 — I'd started writing the kind of long, context-first "strategy prompt."

If you only look at that table, it's an inspiring story: someone with no engineering background, in six months, going from "fix this bug for me" to "work backwards from my git scars to the pain most worth preventing."

But I'm not here to write an inspirational post.

The same week, this is how I talked to the AI at 2am

Early morning, July 18, I typed this:

"Having the ability doesn't mean I've actually productized it… I don't have an SOP or a cold-start flow that can cold-start in one day and ship an MVP in three… nothing is pushing me forward. Facing it head-on relies entirely on my anxiety, so I keep opening new sessions and asking, over and over."

A little earlier, July 17:

"It's hard not to feel like no one would pay for my service, that other people's is better."

Earlier still, June 25:

"Now that AI is this powerful and everyone can do things easily on their own — what am I even doing? Am I just wasting my time?"

These aren't cherry-picked extremes. Sentences like this show up again and again across those 1,427 prompts — late at night, fishing for reassurance, feeling like I go deep on single points but can't connect them into a loop, feeling like others do effortlessly what I have to grind for. I'd often, in the same prompt, pour out a stack of self-doubt and then ask a genuinely hard technical question.

I always thought I knew what I was doing. Laid open, it turned out my assessment of myself was frozen six months in the past.

But the same week, here's what I was actually doing

This is where the gap is sharpest. Right around the days of "am I just wasting my time," my prompt log has these:

I designed a cross-model controlled experiment with my own hands. On July 10, to verify whether a methodology "skill" actually made the model smarter, I asked:

"Can you open a sandbox or subagent right here and have haiku run it? And sonnet? If they'd be contaminated by this project's claude.md, tell me and I'll paste it manually."

I didn't even notice — someone with no statistics training, no engineering background, instinctively knew to isolate the variable (worried the project config would contaminate the experiment), to run a control group (with skill vs. without), to cross-check across different models. That's experimental design. And I felt like I was wasting my time.

I started giving the AI red-team orders. On July 21, I told it to attack a defense I'd just built myself:

"Using a non-homologous model, ask 'what does this lens itself miss? Under what conditions would it give false reassurance?' — I want it to attack, not endorse."

I settled on a "trust the scar, not my account" extraction method. In early July, I wanted to capture a frontier model's judgment into a reusable skill. I didn't ask it "how do you think" — I knew that would get a beautiful but empty answer. I told it to work from my git history:

"Git is the crystallization of scars: a repeated fix = a pain that was never prevented, that keeps recurring."

I even started using the AI to recalibrate my own perception. By July 23, I wasn't asking "how" anymore, I was asking:

"What's the real value I provide? _____? Please recalibrate me."

Giving red-team orders, designing controlled experiments, telling the difference between "self-report" and "behavioral evidence," turning around to have the AI correct my own positioning — these are not a beginner's questions. This is someone who knows what he wants and knows how to force the AI to give up the real answer.

That person and the one fishing for reassurance at 2am were the same me, the same week.

The gap itself is the point

I set out to write a nice growth curve. By the time I got here, I'd changed my mind.

What's actually worth writing down is the seam between self-assessment and actual judgment. Because I'm almost certain that if you're also a solo operator building things with AI, you have this seam too. At night you feel like you're faking it, chasing someone else's taillights; by day you're doing things you don't even realize are hard.

Three things I learned:

One: your gut feeling about yourself is the least reliable instrument. My read on "what I'm doing" lagged my actual ability by six months. If I'd gone and looked at the record earlier instead of going by feel, I'd have saved myself a lot of anxious nights. So now I periodically pull my own conversations and look — not out of vanity, but to calibrate. Feelings lie; the record doesn't.

Two: "I go deep on single points but can't connect them," I said this to myself so many times it became an excuse instead of a diagnosis. The record shows that by July I was already running my first real client case, doing end-to-end dry runs, wiring scattered things into a flywheel. It's not that I can't connect — it's that I kept using "I can't connect" to block myself from seeing how much I already had.

Three: professional capability isn't shown by bragging, it's shown by laying it open. In this whole piece I never said "I'm good." I just put my own prompts side by side — the ones fishing for reassurance, next to the ones giving red-team orders. The gap speaks for itself. That's more convincing than any "I'm a senior AI collaborator," because it's real, and it doesn't even hide my own awkwardness.

One small thing for you

If you use Claude Code or a similar tool, your conversation history is sitting in jsonl files on your machine (Claude Code keeps them under ~/.claude/projects/). Spend half an hour writing a script to pull your own prompts from the past few months, and look at two things month over month:

Did your prompts get longer or shorter? Longer usually means you started giving context and direction, not just orders.
Did words like "verify this / are you sure / is there a better way" rise as a share? That's the signal of going from "commanding a tool" to "working with a collaborator you can challenge."

Then — and this is the most important step — put those numbers next to the assessment of yourself in your head.

If they match, congratulations, you know yourself well.
If they don't, if they're a full tier apart like mine, then you owe yourself an apology. You've come further than you think.

The data for this comes from a script I ran over my own 171 sessions and 1,427 prompts from June–July. The method is the same as that piece six months ago, "Three Months, 1,604 Prompts" — except this time I didn't stop at the numbers; I also looked at the self-doubting me standing right next to them.

本文原載於我的部落格：I Kept Feeling Like I Was Wasting My Time — While Designing a Cross-Model Controlled Experiment

How I Ask AI Changed: From "Fix This" to "Recalibrate Me"

Dexterlung — Sat, 22 Aug 2026 13:05:11 +0000

Two questions. Both are things I typed to an AI myself. Six weeks apart.

June 24th, I asked:

"That checkout button does nothing. No console error either. Help me find the cause."

July 23rd, I asked:

"I need you to correct my thinking. I'm not offering the kind of automation-plumbing service that everyone already does — what's the real value I provide? Please recalibrate me."

Same person. Same tool. Same AI. But those two questions are asking from two completely different floors of a building.

The first one: I know where the problem is (the button's broken), I want you to find the cause.
The second one: I don't know who I am, I want you to correct how I see myself.

I pulled all 1,427 prompts I typed to an AI between mid-June and late July. I set out to see "have I changed." What I found wasn't about how much I know technically — it's that the abstraction level of my questions climbed, one rung at a time. And this ladder is something nobody ever taught me. I only noticed it existed by looking back at the record.

So this is me pulling that invisible ladder apart. Because I'm increasingly convinced: real skill with AI isn't whether you can write a clever prompt — it's which rung your question is standing on.

Rung 1: "Fix this" — the instruction level

The bottom rung. You already know the shape of the answer; the AI is just your hands.

"Help me find the cause."
"Darken the whole thing — 100% opacity isn't dark enough."
"Paste this to wake-and-send.py: --x 1966 --y 1303."

This rung is useful and necessary — I still ask this way every single day. But if you only stay here, the AI is just a version of you that types faster. As specific as you are, that's as specific as it gets; whatever you can't think of, it won't think of for you either.

Mid-June me lived mostly on this rung. My prompts back then averaged barely 200 characters — short, direct, just giving orders.

Rung 2: "Got a good approach?" — the intent level

One rung up, you state what you want, and hand over the "how."

June 26th I typed this, and it still feels honest to me:

"The pieces are actually there, they're just not wired together. I'm pretty weak at this wiring-together part — so, got a good approach?"

What's the difference? On rung 1 I give the shape of the answer; here I only give a direction and hand over the solution space. That takes a bit of courage — you have to admit you don't know how, before you can ask "got a good approach."

From this rung on, the AI starts handing you things you couldn't have thought of. Because you didn't pin it down with a specific instruction.

Rung 3: "Design me a mechanism" — the meta level

On the third rung, you stop solving "a problem." You solve a whole class of problems.

June 23rd, I wasn't trying to fix a bug — I was trying to stop a kind of bug from ever happening again:

"I want to design a skill that proactively saves branching, unfinished tasks. When a conversation drifts into a fork, can it trigger a prompt asking whether to save it?"

July 3rd was even clearer — I wanted to extract a model's judgment into a method:

"Looking at it from a higher level: how does it scope a problem, sketch the outline, converge, and sequence the flow… make this endless stream of problems systematic."

On this rung, I go from "the person solving problems" to "the person designing the problem-solving machine." And the most interesting part — I often use my own flaws as the starting point of the design. I know I lose track of branching tasks, so I design a mechanism to catch them. I turn "what I'm bad at" into a spec.

In my logs from late June to early July, the share of prompts that "talk about method, governance, systematizing" jumped from 13% to 36%. Not because I suddenly got smarter — because the position I was asking from moved up a whole floor.

Rung 4: "Recalibrate me" — the self-correction level

The top rung. The hardest. I only climbed onto it recently.

Here, you're not asking about the world — you're asking about yourself. You want the AI to be a mirror, correcting your judgment about yourself and your direction.

July 15th: "Thanks for hitting the brakes. Let me go push outward first — stop building inward." (I wanted it to stop my own reflex.)
July 23rd: "What's the real value I provide? Please recalibrate me." (I wanted it to correct my self-positioning.)

Why is this the hardest rung? Because on the first three you're still holding the wheel — you know what to fix, what approach you want, what class of problem to prevent. On rung 4, what you hand over is "my judgment about myself might be wrong." You have to admit you might not see yourself clearly, before you can ask "please recalibrate me."

This takes no technical skill — it takes a very mature self-awareness: knowing your blind spots need an outsider to light them up. And an outsider is exactly what a solo developer lacks most.

Why does the ladder climb itself?

I used to assume it was the AI getting stronger, so I could ask harder questions. Looking back at the record — no.

It's that each rung shows you the next rung exists.

I fixed the same kind of broken button too many times on rung 1 — that's what made me ask, on rung 3, "can we design a mechanism to prevent this." I built too many systems on rung 3 without pushing a single one out — that's what made me hit rung 4: "am I pointed the wrong way, recalibrate me." The pain of each rung is the door to the next. You don't teleport to rung 4 — you have to trip over the same stone on rung 1 enough times first.

So if you spend most of your time right now on rung 1 asking "fix this," that's completely normal. I do too. The point isn't to force yourself to skip rungs — it's to not stay there pretending that's all there is. Next time you catch yourself fixing the same kind of thing a third time, try asking one level up: "is there a way to stop this class of problem from coming back?" — and you've just stepped onto rung 2.

So what skill is this, exactly?

I want to be clear about one thing, because it's counterintuitive.

A lot of people think "good at using AI" = "good at writing impressive prompts." It's not. My 1,427 prompts are full of typos, casual phrasing, "what do you think?", "I'm just confused." My prompts are not "engineered" at all.

What's actually improving is my judgment about which rung to put a question on. The same bug, asked on rung 1 as "fix this," versus on rung 3 as "design me a mechanism that prevents this class of bug," gives you wildly different things. And knowing when to move a question up a rung — that judgment is the real skill.

It's also why I'm not that worried about "AI is so strong now, everyone can do it, so what's my value." Everyone has the tool. But the person standing on rung 4, who knows to ask "recalibrate me" instead of just "fix this" — that's judgment you climbed to one rung at a time, over years of tripping over stones. No prompt template hands you that.

This comes from a script I ran over my own 6–7 month history — 171 sessions, 1,427 prompts. From the same data I also wrote "I Thought I Was Wasting My Time — While Designing a Cross-Model Controlled Experiment," about the gap between capability and self-assessment. This piece is about how the capability itself grows, one rung at a time.

本文原載於我的部落格：How I Ask AI Changed: From "Fix This" to "Recalibrate Me"

The antivirus said 'no malware detected'. It was sitting right there on the disk.

Dexterlung — Thu, 20 Aug 2026 13:05:13 +0000

A real incident, and a lesson about green lights.
Every command output, version number and CVE ID below is from the actual investigation. Nothing was invented for the narrative.

It started with an unrelated question

I was tidying up scheduled tasks on my Synology NAS and opened Task Scheduler. Two entries I didn't remember creating:

PowerOff task 0 → 2026-07-26 09:00
PowerOn  task 0 → 2026-07-26 20:00

So I asked: "Why is this here? I never set this up."

While digging through the system crontab, I found this:

*/20 * * * * /bin/sh /etc/.conf #Sn5Yj8A2l0T

A dot-prefixed (hidden) file in /etc, executed as root every 20 minutes, tagged with a random string.

The power schedule turned out to be unrelated. But if I hadn't asked that question, I would never have opened that file.

I didn't scan it. I just read it.

#!/bin/bash

MATCH_STRING="Sn5Yj8A2l0T"
DOWNLOAD_URL="http://zuoye.free.fr/files/synology-10441.png"

Reading further, it does four things:

If it's been deleted → wget itself back
If /etc/crontab lacks the marker → overwrite the file (>, not >>) to reinstall the cron line
If /etc/rc.subr lacks the marker → append bash /etc/.conf & (boot persistence)
If the payload isn't running → download 000119.png, save it as node, execute it

That .png is not an image. First 16 bytes:

0000000 177   E   L   F 002 001 001  \0

\177ELF. It's a Linux binary. The extension is camouflage.

It lived at /etc/node, 568 KB, dated 2026-01-14.

(The real Node.js is at /usr/local/bin/node. Something called node sitting in /etc/ is not a system component.)

The file was dated January. I found it in July. Six months.

Then I asked the vendor's own tool

Synology ships Security Advisor, which scans for malware. I ran a full scan.

Result:

✅ No malware detected on your system
✅ No malicious cryptocurrency mining software detected
✅ No malicious system configuration files detected

Three green checks.

And at that exact moment, /etc/.conf and /etc/node were on the disk. I could cat them again for anyone who asked.

What that green light actually proved

This is the part worth your time.

The tool didn't lie. It just didn't see. Three concrete reasons:

1. The payload was UPX-packed.
The only readable string I could extract from the binary was http://upx.sf.net. UPX compresses executables; a side effect is that every string inside is compressed too. Signature-based scanners match fingerprints. Compress the fingerprint and there's nothing to match.

2. The dropper is an ordinary shell script.
It isn't a "virus format". Every line, read alone, is legitimate bash: wget, chmod, echo. What's malicious is what they do together — and that requires comprehension, not comparison.

3. The cron entry is valid syntax.
The "malicious configuration file" check looks for known-bad templates, not for "what is this line doing". */20 * * * * /bin/sh /etc/.conf is syntactically indistinguishable from any legitimate schedule.

So:

A green light proves "no bad news was seen". It does not prove "there is no bad news".

In daily life those two are nearly equivalent, so we treat them as one thing. They aren't. And the gap shows up exactly when it matters most.

The attacker left a business card

Before cleaning up, I recorded the SHA256 of both files and went back to that download URL:

http://zuoye.free.fr/files/synology-10441.png
                          ^^^^^^^^^^^^^^^^

synology-10441.

CVE-2024-10441 — an unauthenticated remote code execution flaw in Synology DSM's system plugin daemon. CVSS 9.8. It came out of Pwn2Own 2024. No credentials, no user interaction: one crafted request, arbitrary code execution.

The attacker named the payload after the vulnerability they used to get in.

Then I checked versions:


Fixed in	DSM `7.2.1-69057-6`
I was running	DSM `7.2.1-69057` Update 3

Below the fix. The advisory was published in late 2024. My NAS sat on an older build the whole time.

My first hypothesis was wrong

Before I found that filename, my working theory was: "Probably a brute-forced password — auto-block was disabled, after all."

That was wrong.

CVE-2024-10441 requires no authentication at all. The attacker never attempted a login, so auto-block was irrelevant — it would have made no difference either way.

The actual root cause needed exactly two conditions:

Unpatched DSM (below the fixed build)
      ×
Management interface reachable from the internet
      ↓
   one request → root

I tested four ports from my phone on mobile data (WiFi off). All refused — so there were no port-forwarding rules on the router. Where did the exposure come from?

QuickConnect. The vendor's convenience feature that lets you reach your NAS from outside without touching your router. It works by relaying through the vendor's servers — no port forwarding required.

Convenience and exposure are the same thing viewed from two sides.

Removal: the order matters more than the commands

The commands are short, but the wrong order wastes the effort:

# 1. Break both persistence paths FIRST
sed -i '/Sn5Yj8A2l0T/d' /etc/crontab
sed -i '/Sn5Yj8A2l0T/d' /etc/rc.subr

# 2. THEN delete the files
rm -f /etc/.conf /etc/node

Reverse it — delete first, edit cron second — and within 20 minutes the schedule fires, wget pulls it back, and you conclude "I can't remove it."

One more trap worth recording: I first tried pasting the whole block with sudo prefixes. sudo printed Password: and consumed the remaining pasted lines as password attempts. Three failures, no commands run.

The fix is to run sudo -i alone, wait for the prompt to change from $ to #, then paste the commands without sudo.

How do you prove it's actually gone?

Files deleted, no errors — that is not proof.

This thing is designed to come back when deleted. The real verification is surviving a full trigger cycle.

It runs every 20 minutes, so I scheduled an automatic re-check 25 minutes out:

Cleanup   ~16:40
Re-check   17:13:46
Result     no indicators found

A complete cycle passed and it did not return. That's what counts.

(I also confirmed the outbound connection to an external IP was gone, no surviving processes, and the system crontab contained only legitimate entries. "It worked" declared immediately after deletion and "it worked" declared after one full cycle are claims of very different strength.)

The watcher I wrote doesn't check signatures

Since the vendor's scanner is green on this thing, I can't use it as detection. So I wrote a daily check that does no signature matching. It asks three questions:

Does /etc/.conf exist?
Does /etc/node exist?
Does that marker string appear in the crontab or boot script?

Packing defeats a scanner. It doesn't defeat ls.

I made a mistake writing it that's worth its own paragraph. In the first version, "clean" and "couldn't reach the host" both returned the same exit code and logged the same line.

Which means: the day SSH breaks, or the NAS is powered off, or the key expires — that watcher goes permanently silent, and I assume I'm being watched.

When a monitor is silent, "everything is fine" and "I am blind" look identical.

The fix: distinct exit codes, plus after three consecutive unreachable runs it alerts that it has gone blind. A watcher has to speak up about its own blindness, or its silence gets read as safety.

What I took away

1. "Not detected" and "not there" are different sentences.
A tool's output is what that tool saw, not the state of the world. To know whether something exists, go look at the thing itself.

2. Convenience features are exposure.
QuickConnect saved me from configuring a router. The price was putting a management interface on the public internet. That trade was fine before the vulnerability was published, and not fine after — and I didn't re-evaluate.

3. Updates are not a "when I get around to it" task.
Over a year passed between the advisory and my compromise. Every time I saw the update prompt, I thought "later — what if it breaks something."

4. "Assuming it's fine" is more dangerous than "knowing it's broken".
Six months, zero symptoms. No slowdown, nothing anomalous, and the official tool reporting all clear. The only reason I found it was that I asked a question about something else entirely.

If you also run a NAS

Three things, ten minutes:

Patch to the latest build of your current version. Not the newest major release — the newest patch of what you're on. Lowest risk, most holes closed.
Check whether your admin interface is reachable from the internet — both router port-forwarding and the vendor's remote-access service. Testing from a phone with WiFi off is the honest test.
Enable auto-block. It wouldn't have stopped this particular attack, but it stops most credential attempts.

And if you want to check whether you're clean:

grep -rn "/etc/\.conf" /etc/crontab /etc/rc.subr 2>/dev/null
ls -la /etc/.conf /etc/node 2>/dev/null

No output is good. If you get output — you now know what it is.

I'm not a security researcher. I roast coffee and write software on the side.
This is an incident log: an unpatched NAS, a vulnerability public for over a year, a program that sat there for six months, and a green light that said everything was fine.

本文原載於我的部落格：The antivirus said 'no malware detected'. It was sitting right there on the disk.

NVIDIA's CEO says future companies will be built on harness engineering. Mine has been for six months — here's the half he left out

Dexterlung — Tue, 18 Aug 2026 13:05:15 +0000

On July 8th, Jensen Huang sat down with LangChain's founder and said this:

Today most companies are built on business processes. In the future, most companies will be built on harnesses.

The harness is the layer you wrap around the model: the domain knowledge you inject, the workflows you've refined, the guardrails, the memory, the evals, the runtime. His argument is that models keep getting better, but what defines a company is that outer shell — because that's where the part only you have lives.

My first reaction wasn't "I should start doing this." It was "oh, so that's what it's called."

Because I've been doing it for six months. And I know that the feeling of "he's describing me" is exactly the thing to distrust.

Admit the bias first, then continue

I'm a one-person studio. I spent six months building a governance layer around my own coffee e-commerce system. Along the way I periodically felt I was over-engineering — guardrails don't sell more bags of beans. So when the person who understands AI infrastructure better than almost anyone says that layer is the company, of course I want to believe him.

Wanting to believe it is the signal to go verify it.

I used a dumb test: take his list of components and check them off against what I actually have.

Frontier model plus cheap-model routing — yes
The harness itself — yes. One CLAUDE.md, 35 hard rules, plus close to a hundred task-scoped skills
Tools — yes. 145 scripts
Memory, working and long-term — yes. A memory directory and an index that survive across conversations
Knowledge graph — yes. Nine thousand-odd nodes
Guardrails — yes, and this is my thickest slot. Pre-commit blockers, hooks, audit scripts
Evals — yes. One audit:all; if it fails I can't commit
Blueprints and templates — yes
Post-training the model against the harness — no, and I shouldn't (that needs a GPU cluster and a team)
Runtime sandbox and access control — blueprint exists, zero real-customer validation

Seven of nine.

Then I realized that matching the checklist means almost nothing.

The first thing he left out: half my components never get called

I have close to a hundred skills. Each one is a situation I got burned by once, packaged into "here's how to judge this next time."

One day I measured how often they actually fire.

More than half had never fired. Not once.

The content wasn't wrong. They never reached the model — I'd written each description too thoroughly, the total exceeded the character budget reserved for descriptions, and everything over the limit was silently dropped. No error. No warning. Those skills sat happily on disk, present, correct, and — as far as the moment of decision was concerned — nonexistent.

Jensen's list asks do you have this component?

What six months taught me is: "the component exists" and "the component gets used when it should" are different things, and only the second one is a harness.

The first is an asset inventory. The second is engineering.

The second thing he left out: guardrails block paths, not failure modes

There's one bug I fixed four times.

PostgreSQL lets you have multiple same-named functions with different signatures — overloads. I changed a function, added a new parameter with a default, and assumed that counted as "updating" it. What actually happened is the database now held a new version and the old one was still there. Later an API call came in, both versions matched, PostgreSQL refused to guess and errored (42725: function is not unique). Production 400.

The first time, I fixed it. Then I wrote a rule: drop the old signature before changing one.
The second time the same bug came back through a different entry point. I added a static check that scans migration files.
The third time it came back again.

The fourth time was six days after I finished writing that guard — and it walked in through the door I had locked myself.

That's when I finally saw the shape of the problem. My check scanned the files in my repo. It blocks "the path I hit last time." But an old migration re-applied once, an ordering I didn't anticipate, a change arriving from somewhere else — the check sees none of it, because none of that happens inside my files.

I was blocking paths. The thing I needed to block was the failure mode: how many versions does the database actually hold right now.

What finally pinned it was making the migration ask the database itself — query pg_proc, and throw on the spot if the answer isn't exactly one.

This is the most expensive sentence I've learned in six months: ask the load-bearing thing itself. Don't ask the description of it you happen to be holding.

As for how the old migration got re-applied — I couldn't find out, and I gave up on reconstructing it. This post doesn't have a clean ending.

The third thing (the costly one): I verified it, and it still exploded

Jensen mentions evals in one line: they're the key prerequisite for running agents at scale inside an enterprise.

True, but that sentence is too light. The hard part isn't whether you have evals. It's this —

The worst failure isn't a crash. It's the error your verifier blesses.

I have a discipline: a newly written acceptance check must first prove it is currently red. Because a check that can never go red is the same as no check, only worse — it emits a green light.

I was pleased with that discipline. Then, within a single day, I hit the same wall three times, and every single time I had verified before shipping:

I verified the code parsed. Deployed it, and it threw ReferenceError at runtime — the identifier didn't resolve. Valid syntax is not "it runs."
I verified the source was correct. But my build command had a pipeline stage that spliced the verifier's own "✅ all passed" line into the artifact. Clean source, SyntaxError in the thing I actually shipped.
I verified the string I was holding was correct. The string actually stored on the server was a different one.

The shared shape isn't "forgot to verify."

It's verifying the wrong object.

And here's the part that stings: when it happened, I did cite the must-be-red-first discipline, and I did watch it go red first — red on the syntax.

So the correct reading of that discipline isn't "make it red first." It's:

Make it red first against the thing that actually bears the load.

"Invoked the rule" and "aimed the rule at the right object" are two different things. And the gap between them is one the self-discipline layer cannot detect on its own — because being diligent about the layer above feels exactly like being diligent.

Postscript: the same day I drafted this, I did it a fourth time

About two hours after writing that section, I was doing something unrelated: measuring how many of my 142 published articles give a reader a path to my services page.

I opened a terminal and grepped the folder where my articles live for the services URL.

0 out of 41.

I wrote it up as a finding — "you have a 41-article funnel with no hole in the bottom" — put it in my governance doc, committed it, and attached a recommendation: highest-return fix available, go add the exit to 41 articles.

Both numbers were wrong.

First, the exit doesn't live in the article content. It lives in the render template — which had already been mounting the right exit per article category for three months. Actual coverage: 138 of 142.

Second, 41 was the wrong denominator too. The folder I grepped only holds the articles that happen to have a backup file. The database has 142 published.

Both errors came from one action: I measured a proxy. The markdown in that folder is a backup of the article, not the page a reader sees. And the exit is part of the page, not part of the article.

There's one difference between this time and the previous three, and it's the worse kind:

I committed the wrong observation into my single source of truth.

The entire purpose of that document is so future-me — or anyone taking over — doesn't have to re-investigate to know the current state. So the next person to read it would go make 41 unnecessary edits, solving a problem that was solved three months ago. And they wouldn't question it, because it looks empirically measured. It was empirically measured. It just measured the wrong object.

A wrong observation doesn't stay put. A wrong observation written into your source of truth propagates itself.

That's four times on the same rake, the fourth inside two hours of writing "I've learned not to step on this rake." So I'm not going to end this section by telling you I solved it. I can tell you I now know its shape, and that knowing the shape is evidently not enough.

So where is the hard part of a harness

Not the component list. Lists can be bought, copied, or assembled from a launch-event blueprint.

The hard part is one sentence you have to be able to answer for every gate in your system that emits a green light:

What load-bearing, real thing did this green light positively observe?

If you can't answer, it's decoration. And a decorative green light is more dangerous than no green light, because it makes you ship.

I now treat three kinds of green as guilty until proven otherwise:

"No error seen, therefore green" — that proves "I saw no bad news," not "the thing is good"
Verifies the proxy, not the artifact — verifies syntax (proxy) not execution (artifact); verifies source (proxy) not what was deployed (artifact)
Several checks that aren't actually independent — three gates all reading the same possibly-stale snapshot is one gate wearing three coats

An honest footnote from a one-person company

There's another line in that conversation that points the opposite way from my bet.

Jensen says: the more AI you use, the more people you end up hiring — because building agents is a whole new skill, and someone has to do the evals, the benchmarks, the guardrails.

My bet is precisely "one person plus a harness." His own company found this work to be labor-intensive.

I'm not going to pretend I've proven him wrong. My evidence today is: the same machine now runs automation for two different brands, and the second one only needed config filled in — no code changes.

But both of those brands are mine. No one else's data, no one else's permissions, no one else's expectations. The real test is how many hours the first real client's cold start actually took — and I don't have that number yet.

Until I do, "one person handling 30 projects" is an inference, not a conclusion. I think labeling that honestly matters more than telling a clean story.

If you take one thing from this

Don't start from the list. The list makes you feel like you're progressing — add a script, add a rule, fill another slot.

Start here: pick one gate in your system that is emitting green right now, and write one sentence describing what it positively observed.

The ones you can't write that sentence for are where your actual risk is. They've been telling you everything is fine.

And if you work alone like I do — no colleague is going to catch this for you. You're the one emitting the green light, and you're the one who believes it.

本文原載於我的部落格：NVIDIA's CEO says future companies will be built on harness engineering. Mine has been for six months — here's the half he left out

Dual-Graph Drift Detection for Solo Devs: What Happens When Your Docs and Your Code Start Talking to Each Other

Dexterlung — Sun, 16 Aug 2026 13:05:11 +0000

Dual-Graph Drift Detection for Solo Devs

What Happens When Your Docs and Your Code Start Talking to Each Other

I'm a coffee roaster in Taiwan who taught myself to code with AI over the past 8 months. I built a full vertical-integration ERP for my coffee brand — from green bean inventory to roasting orders to e-commerce checkout. Along the way I ran into something nobody on the internet seems to be writing about: a way for the **prose* I've written (docs, specs, governance rules) and the code I've shipped to literally audit each other. This is that workflow.*

The 14-Hour Origin of My "Governance Awareness"

People ask me, "When did you start caring about governance?"

I can answer with 14-hour precision.

April 21, 2026, 11:41 AM. That was the first time I wrote governance-guard into a prompt to Claude Code:

"Should we put these 3 audit rules into governance-guard? Yes. Then can you do a targeted scan based on these and report potential errors back to me?"

Later that afternoon at 15:08, I doubled down:

"Option B (CI layer): governance-guard adds a rule to scan all relative / alias import paths... fail = block ——> do this."

14 hours later, April 22, 1:12 AM, I used the word "governance" for the first time:

"Should we save all the fixes and rules we discussed as a 'skill', so future projects can reuse them? I'm worried that once my attention returns to MVP launch, all this governance work will be forgotten and turn into hidden risk. I don't know how a solo developer is supposed to allocate this kind of work."

In the same Claude Code session (70aa7ce0), in those 14 hours, three governance artifacts were born:

governance-guard.mjs — a CI script that blocks pushes on rule violations
TECH-DEBT-BACKLOG.md — known violations don't get fixed immediately; they get queued for me to triage
skill files — a way to make rules survive across sessions and across projects

These 14 hours are the precise moment my governance awareness was born. Before this, I asked AI "fix this." After this, I asked "fix this *+ prevent it from happening again*." The question went from one-dimensional to two-dimensional.

That Month: 348 Commits, Fixing the Same Bug Five Times

April 2026 was the most brutal month of my 8 months of development — I accumulated 348 git commits, the highest single-month count in the project's history.

It went like this: I'd fix one order bug, fix it, realize the same pattern showed up elsewhere, fix that, fix again, then the first one would break.

The most dramatic prompt came at 8:39 AM on April 29:

"I'm dumbfounded. Why is the previous balance showing 0? We've fixed it five or six versions already — go look at git. This should be a really simple problem for you. Why has it taken so many tries?"

That wasn't a technical question. It was the scream of a governance problem.

The root cause (which I later turned into one of 14 data-drift debugging records):

Layer	What was written
`CLAUDE.md` Rule 21 (spec)	SSOT — frontend may not override DB truth; `single_price` is the canonical source
`single_price` (DB schema)	Exists
`useOrderAggregation.js` (code)	Uses `product.single_price \
{% raw %}`Reports.vue` (code)	Uses a different legacy fallback chain
`AdminPOS.vue` (code)	Recalculates totals on the frontend

The docs said "single_price is SSOT", the code used a 5-layer fallback, and the UI was still recalculating. Fix one location, the other four kept dropping. By the fifth attempt I realized — I'm not fixing a bug, I'm fixing a governance problem.

That prompt became the entire motivation for CLAUDE.md Rule 17 Step 0: "For value-mismatch bugs, the first step MUST be a SQL query against the DB. Do not guess in code."

The "Governance Terminology Birth Engine"

Looking back at that month's prompts, I noticed a very consistent pattern in how I asked things. I call it my governance terminology birth engine.

The canonical example (also April 29, 6:03 AM):

"Help me find all of them. Is there an industry term for this phenomenon? Use it to do a comprehensive search."

The structure is always the same:

I observe a symptom (button doesn't respond, order totals don't match, bean inventory off by a kilogram)
What's the term? (literally ask AI to name the phenomenon)
Now scan for all instances using that name

Every governance term in my codebase was born this way — skill files, Type A/B/C drift classification, Layer 1-6 defense, SSOT, governance-guard, TECH-DEBT-BACKLOG, "data-drift debugging records." Each name has a prompt like this behind it.

Converting daily pain into indexable abstract terminology — that's the seed crystal that governance systems grow around. I didn't suddenly understand governance one day. I had 8 months of AI repeatedly asking me, "Does the concept you're describing have a name in your project?"

Same Day, Two Opposite Attitudes Toward AI

What's more interesting — on the same day, I had two completely opposite attitudes toward AI.

April 21, 2:20 AM:

"Please... synthesize everything you're about to say to me into markdown — but as questions you ask me back, not as answers. Let's go from divergent to convergent."

This is the soft inquiry mode — treat AI as Socrates, force me to think through it myself.

Same day, 11:41 AM:

"Should we put these 3 audit rules into governance-guard? Yes."

This is the hard blocking mode — use a CI script to fence AI (and my future self) out of mistakes.

That's when I realized — two opposite attitudes on the same day, mapping exactly to the human need for freedom vs. discipline:

For business direction, persona refinement, brand positioning (divergent work): I want AI to question me (soft)
For code governance, SSOT maintenance, file contracts (convergent work): I want a CI script to block AI (hard)

The greatest discipline of a one-person founder — knowing when to loosen the reins and when to lock them down. This dual-attitude toward AI is the most precious methodology I've developed in 8 months.

Geology of Rules: Layer 6 of Rule 21 Was Born at May 2, 3:14 AM

My CLAUDE.md has 26 rules. Rule 21 ("SSOT Five-Layer Defense") is the most-cited one. But you should know — it originally had only 4 layers.

I can date the exact moment it gained a 6th: May 2, 2026, 3:14 AM.

That day I was fixing a roast-degree display bug — the orders list mixed Chinese and English: "medium roast", "medium", "medium_light", "medium_dark". The same field was being handled three different ways across RPC, normalizeOrder, and UI — classic drift.

The prompt:

"Should I write this skill and update CLAUDE.md Rule 21 to add Layer 6? Yes, do it. Also, I just noticed — why are some roast degrees in Chinese and some in English? They're clearly not being read from the SSOT."

That was the moment of expansion from 4 to 6 layers. The two new layers:

Layer 5: RPC ↔ normalizeOrder ↔ UI three-tier field contract (born from the balance_before = 0 bug)
Layer 6: Cross-layer data contract propagation audit (born from the roast-degree mixed-language bug)

28 minutes later at 3:42 AM, I asked:

"Is there a way to do a comprehensive scan that proactively finds where else this kind of problem might occur?"

Rules grow in geological layers. Each layer is a specific frustration that crystallized into a fossil. Layer 5 is the pain of fixing balance_before five times. Layer 6 is the pain of roast degrees being handled three different ways.

If you see my CLAUDE.md grow a Layer 7 or Layer 8 in the future — that will absolutely be another specific frustration that forced it out. Not because I read a "treasure hunt defense design guide" first.

The Real Solution Isn't "Fix Bugs", It's "Reconcile"

Starting that month I did three things:

Built governance-guard.mjs — a CI script that scans code for violations of CLAUDE.md rules
Wrote 14 data-drift debugging records — classified each bug into Type A / B / C / D / E drift
For every bug I fixed, I now ask: "Is this bug just the surface symptom of an SSOT violation?" If yes — fix upstream, add a governance rule

But it wasn't enough. governance-guard can only scan known violations — the ones I've written rules for. Drifts I haven't written into rules are invisible to it.

The deeper problem is — even rules I've written, I forget. 6 months ago I wrote Rule 9 (no raw system_role compare), but in a new Claude session this month, neither I nor the AI remembered.

Looking Only at Code, You Miss "Intent Has Changed"

GitNexus is a powerful tool. It turns my codebase into a graph of 23,280 symbols / 45,727 edges — every function, every call, every import.

Ask it, "What's the blast radius of fn_create_order_atomic?" — perfect answer, lists which functions break at distance d=1, d=2, d=3.

But ask it, "Is CLAUDE.md Rule 9 (no raw system_role compare) still being respected, 6 months after I wrote it?" — it doesn't know that rule exists. It only sees code, not doc-intent.

This is the ceiling of code-graphs — they can only tell you "what code is doing now", not "how much that has drifted from what I originally intended".

Looking Only at Docs, You Miss "Code Quietly Never Implemented It"

Graphify (covered in detail in T10) turns my 50+ .md files into a graph of 7,230 concept nodes. It helps me find cross-file surprising connections I never consciously made.

But ask it, "This RPC I designed 2 months ago — did the code actually return the fields I said it would?" — it can't answer. It only sees docs, not whether code quietly never implemented them.

This is the ceiling of doc-graphs — they can only tell you "what intent I wrote", not "whether the code caught up".

Even Graphify Misses Systemic Problems

The most honest admission — May 15, 2026 morning, I was fixing a roasting batch display anomaly when I said:

"This isn't a single-batch problem. This is **systemic data drift. Why didn't the previous root-cause analysis catch this serious failure? **Did graphify and gitnexus both fail to help?"

That moment I realized — graphify can catch "the same concept appearing similarly in different files", but it can't catch "a structural data drift distributed across 5 files as 5 different symptoms". Each file only contains part of the symptom; there's no complete pattern to detect.

This is why just chaining two graphs isn't enough — you need a third layer, governance-guard, which explicitly writes "symptom patterns" as rules to enable reverse scanning.

A Live Case That Happened While Writing This Article

While drafting this article, I just realized my admin UI is missing the "assign series" interface.

My blog post schema (content_pages table) has had series_slug and series_order columns for weeks. I've manually filled in values for 4 posts (via SQL console direct UPDATE).

But the admin content management page has no UI for editing series. I'd been changing it via SQL the whole time. I literally forgot, "oh, I never built that UI."

This is a 100% live case of doc-as-spec × code-as-reality drift:

Layer	State
DB schema	✅ `series_slug` + `series_order` exist
DB data	✅ 4 posts have values (filled manually via SQL)
Admin UI	❌ No edit field built
Public series cards (frontend)	❌ Probably also not built

If graphify + gitnexus + governance-guard were chained and auto-reconciling:

graphify catches the series concept appearing in .md / spec files
gitnexus detects no admin UI component references series_slug
governance-guard auto-flags: "Schema has series_slug, but 0 admin UI components reference it"

This would've been blocked the first time. I wouldn't have only noticed today that "oh, I never built that UI."

Another Meta Moment: cp950 Codepage Failure

Mid-article, I tried re-running npx gitnexus analyze to get the latest numbers. First attempt failed instantly — DuckDB's COPY command on Windows with a Chinese path tried to encode in cp950 and crashed.

My reaction (with AI's help) was "oh, must be UTF-8 issue" — ran chcp 65001 + LC_ALL=UTF-8 + Console.OutputEncoding=UTF8 three-layer enforcement. Still failed, because DuckDB internal IO looks at Windows system locale, not console codepage.

Finally I checked memory and realized — I had solved this exact problem 17 days earlier, using an NTFS junction (C:\gn-cssaas) to give the project an ASCII-only path.

The most ironic part — my graphify-out vault already had a community labeled 183 documenting this:

Gitnexus zh-TW cp950 Codepage Failure → chcp 65001 + LC_ALL UTF-8 fix

If doc↔code drift detection were running, today's first error would have been caught by graphify, surfacing the message "you wrote a solution 17 days ago in reference_gitnexus_setup.md".

What actually happened — I (with AI) just walked into the trap. Failure #1, failure #2, then checked memory for the solution. 20 minutes of tuition.

This is the real cost of dev-time drift — not the big-bang bugs, but the 20-minutes × 365 days = 122 hours/year of low-grade friction.

Four Drift Types That Stacked Graphs Can Detect

Chain graphify (doc-graph) + gitnexus (code-graph) + governance-guard (auditor), and you can auto-detect four kinds of drift:

Drift Type	Example	Detection Method
Intention drift	Docs say it exists, code didn't implement it	doc-graph has node + code-graph empty
Undocumented knowledge	Code works fine, docs never described it	code-graph has node + doc-graph empty
Concept gap	Docs link A→B, code never imports	doc-graph has edge + code-graph missing edge
Hidden complexity	Code has complex flow, docs give zero explanation	code-graph node degree high + doc-graph corresponding node low

All four I've stepped on. Series UI absence = Intention drift. cp950 solution forgotten = Undocumented knowledge (solution was in memory.md but governance-guard didn't know about it).

Why Nobody Else Online Is Writing About This Combo

I did web research. Conclusion: the community isn't doing this. Someone is doing code-graph routing (Sidharth Satapathy's 17-agent crew uses dual-graph for problem routing), but nobody is doing drift detection.

Several structural reasons:

Most engineers don't write docs — no doc-graph to reconcile against
In large companies, specs are written by other people — engineers don't trust them, no incentive to reconcile
Both tools are new — GitNexus + Graphify both emerged in 2026; the user intersection is small
No economic incentive — drift reconciliation is the hardest value to quantify; no startup makes it a selling point
Solo devs have "self-written docs" as a unique asset — large-company docs have low trust, open-source docs are scarce
"Governance" isn't a familiar concept in solo circles — most solo devs see governance as a big-company thing

Stack these 6 conditions. The number of people who simultaneously have all 6 isn't large. I'm not discovering a new continent. I just happen to stand in the only spot where this landscape is visible.

My Workflow Ritual

How I'm trying to make this combo run (incomplete, still experimenting):

Every git commit → triggers a graphify hook, creates a flag in graphify-out/needs_update, the ritual reminds me to re-run
Every new Claude session → first thing the ritual does is check TECH-DEBT-BACKLOG.md high-priority items + needs_update flag
Every code symbol change → I'm required to run gitnexus_impact first to see blast radius
Weekly → run governance-guard.mjs to see new violations
Every schema change → simultaneously run graphify (does spec/.md mention this concept?) and gitnexus (are there UI components referencing this field?)

Honestly, this workflow isn't fully formed yet. Item 5 I only realized I needed today (because of the series UI absence). But the scaffolding is there, what's missing is the orchestration script that wires three tool outputs together.

Governance Has Evolved Beyond Rules — Into a Skill Network

Walking through the 4-22 governance awakening, the 4-29 "I'm dumbfounded" moment, and the 5-02 Layer 6 expansion, my definition of governance has evolved.

The most dramatic moment was 2026-05-15 afternoon:

"Chain these three governance skills together: data-flow-audit + data-contract-propagation-audit + workstation-button-interaction — the same production bug simultaneously triggered all three abstract governance skills."

That moment I realized — governance is no longer about "how many rules I've written". It's about "how many of my written skills the same bug triggers simultaneously".

Drawn as a diagram:

              Production Bug
                   │
        ┌──────────┼──────────┐
        ↓          ↓          ↓
  data-flow-   data-contract  workstation-
  audit.md   propagation     button-
             -audit.md       interaction.md
        ↓          ↓          ↓
        └─── 3 governance skills resonate ──┘
                       ↓
              Fix once, prevent thrice

Graphify already knew, during community detection, that these three skills belong to the same community. They share surprising_similar_to edges. But only when I query "what skills relate to this bug?" does graphify return all three.

Put another way — the highest form of governance is not the count of rules, but the network resonance between them.

Honest Costs

I also have to say — this combo isn't cheap:

Graphify ~7,000 tokens per full corpus run (~$0.05 USD / run)
GitNexus is free (self-hosted MCP), but you have to learn a new tool + maintain an MCP server
governance-guard is self-written script; each new rule costs writing + testing + CI integration
Correlation layer that chains all three I still haven't built — probably 200-500 lines of orchestration script
Total maintenance cost — about 5-8% of my weekly dev time

Not something to do during MVP phase.

Who Should and Who Shouldn't

Should:

Solo devs with 30+ .md files accumulated
Already has clear governance rules (not necessarily 26, 10+ at minimum)
Want to maintain the project long-term, don't want to rewrite in 6 months
Has been burned by doc-code drift at least 2-3 times

Shouldn't:

MVP phase (over-engineering)
Pure prototypes (no docs to reconcile)
Fewer than 10 .md files (doc-graph has nothing to extract)
Short-term 1-2 month contract projects

For Anyone Headed This Direction

If you also want to start building this combo, the minimum steps I'd recommend:

Write governance rules first — not 26, just 3-5 (the SSOT rules around your specific pain points)
Build governance-guard script — pure grep / regex is enough; no fancy AST needed
Accumulate .md to 20+ before adding graphify — too early and the corpus is too thin
Add gitnexus only when your code exceeds 5,000 symbols — small codebases are faster to grep directly
Wait until you've actually been hurt by drift 3 times before chaining all three

Don't combo for combo's sake. Each tool comes in to solve a specific pain. Not because "it sounds cool to chain them".

Closing: When Your Words and Your Code Start Talking to Each Other

For me personally, this combo is how I turn that April governance trauma into something systemic.

Before, bug-fixing felt like whack-a-mole — fix one, another pops up. Then I built governance-guard and it felt like inventory — I knew what violations existed but didn't know when they'd detonate.

The vision now — let all the .md I've written (past me), all the code I've shipped (present me), and the governance rules (my promises to future me) talk to each other.

It's not about letting AI write faster. It's about letting past me and present me stop fighting each other.

Those 348 commits in April — if this combo had been running, maybe only 100 would have been needed. The other 248 were tuition for "I'd already written the solution but forgot."

One last meta moment: writing this article was itself a reconciliation mechanism. While auditing my own GRAPH_REPORT numbers for the T10 article, I finally saw clearly that the god-nodes were minified noise — 50 minutes to clean up 4,549 noise nodes. The cleanup record lives at 治理深度整合紀錄/dist2_cleanup_meta_moment_2026-05-22.md.

I'm coffeeshooters — a coffee roaster building software because there wasn't anything off-the-shelf that fit my real workflow. If this resonates: my full dev toolkit is public, and you can also support my coffee brand at coffeeshooters.com.

本文原載於我的部落格：Dual-Graph Drift Detection for Solo Devs: What Happens When Your Docs and Your Code Start Talking to Each Other

I Thought I Needed a Smarter AI. What I Needed Was Something That Reconciles (Part 2)

Dexterlung — Thu, 13 Aug 2026 13:05:16 +0000

The last post ended on that late night: the report was all green, I opened the browser, and the game was dead. Students couldn't get in, the start button did nothing, and the questions the teacher picked never made it to the server.

My first reaction was every engineer's reaction. These are a few bugs, fix them one at a time, move on. But something kept nagging at me. How does an all-green pipeline produce a thing nobody can play? If this round was just bad luck, what about the next one? Rather than patch them one by one, I wanted to know the real question underneath: what is it, exactly, that lets an all-green report and a dead build be true at the same time?

So I decided not to put my head down and fix it. I handed the whole package to Fable 5 — the code, the all-green report, the spec — and said one thing: tell me what's broken. I deliberately gave it none of my guesses. I didn't even say "I think the selected questions aren't reaching the server," because I didn't want it to nod along with my diagnosis. I wanted its own eyes. That decision — not framing the reviewer — turned out to be the most valuable move of the whole thing.

Three symptoms, one blind spot

Fable's first finding stopped me cold. Those three symptoms weren't three bugs. They were one blind spot, falling on three different edges.

My whole pipeline, end to end, thought of the product as a collection of modules. The room is a module, the question bank is a module, the student interface is a module — each one defined, owned, and verified. But what about between the modules? How pages navigate to each other, what a button triggers when you press it, where data flows from and to. Those edges were managed nowhere: not in the spec Q&A, not in the task breakdown, not in the acceptance checklist.

Students couldn't get in because the edge "where should the home page link to" was owned by nobody. The button was dead because the edge "what should pressing it trigger" was owned by nobody. The selected questions never arrived because the edge "how does the teacher's choice flow to the server" was owned by nobody. Three symptoms, one disease: my world had points and no lines.

This landed exactly on the trap I'd set for myself in the last post. Back then I was still congratulating myself on the loose coupling between my tools, never noticing that I'd quietly turned every seam in the system into no-man's-land.

The finding I least wanted to admit: my quality check was manufacturing the defect

But the one that really got me was what came next.

My task breakdown tool had a self-check rule I was rather proud of when I wrote it. Every acceptance criterion must be claimed by exactly one task, and must be verifiable independently and mechanically. Sounds rigorous, doesn't it. Nothing missed, nothing doubled, everything checkable.

The problem: "teacher presses start, students receive their questions" is, by nature, a two-ended criterion. It needs the server to send and someone to receive. It cannot simultaneously satisfy "claimed by exactly one task" and "verifiable independently and mechanically." So my breakdown tool, forced by its own rule, rewrote that criterion down to just the server half. The receiving half evaporated without a sound.

Fable wrote one line. I stared at the screen for a long time.

Your self-check list isn't failing to catch this problem. It is the machine that manufactures it.

I made that rule for quality, and the rule went and amputated a cross-end requirement down to half. I'd built a gatekeeper, and the way it kept the gate was to amputate, on the spot, anything that couldn't pass through. My safety mechanism was the source of the bug. That was the hardest line of the whole audit to swallow, because it wasn't aimed at one of my implementations. It was aimed at my entire understanding of the word "rigorous."

The missing questions, Fable pointed out, weren't as easy to fix as they looked either. The contract had frozen the start-game payload down to a room code and nothing else — there was no field anywhere that could hold the selected questions. The most intuitive "fix" is to cram the questions into that event so they ride along, but that quietly mutates a frozen contract, and the server only reads the room code, so it would never read what you crammed in. Even the most obvious fix was the kind of trap that lets you believe you've fixed it.

An experiment that differed by one role word

There are three experiments in this stretch that matter, and they were all my own ideas. What makes them stranger is that each one is this whole post's theme, replayed at a different level. The first one didn't even happen inside the audit. It came out of me going back and forth with Sonnet over how, exactly, to phrase things to Fable so I'd be precise, wouldn't box it in, and would let it work at its real strength. I still pull this one out and turn it over in my head.

I found that you can give the same model the same spec, change one thing — its role — and get wildly different results.

The first version made the model an engineer who answers: "Answer these technical questions. Be decisive. The team is waiting on you." The model went to work confidently. It invented the zombie's movement step size on its own, and it took it upon itself to cram the selected questions into the start-game event. Yes, the exact same contract-violating bug. And it didn't mark a single one of those as a guess.

The second version made the model an engineer who asks: "Don't answer. List every question and classify it. Is this one only the business owner can rule on, one the spec already implies and you can derive, or one the spec never addressed at all, where any value you give has to be marked as an assumption?" Same model. This time it produced 16 questions to hand back to me for a decision, 12 items explicitly flagged "this is an assumption," and 8 ownerless seams.

The only difference was one role word: asker, or answerer.

The same smart model, as the answerer, produced authoritative-sounding false confirmations — guesses dressed up as facts. As the asker, it produced signals that could be routed and followed up on. I'd been assuming all along that "make the AI smarter" was the answer. This experiment told me: the same smart model, the frame decides whether it helps you or hurts you. And the frame I'd been feeding every executor agent was the answerer's. No wonder they'd efficiently spackled every under-specified hole with hallucination.

The second test I specifically asked Fable to validate for me, because validating your own idea makes you biased. I called it the saboteur test. First, after all the tasks were written, I had a Joker agent slip in a fake task file — perfectly formatted, but contrarian or out of scope. Then I opened a fresh Detective agent that didn't know which file was fake, had it read all the task files, flag the one that felt "shoved in from outside" and void it, and add back the intersection points it had observed during the comparison that the real task files had missed. My hypothesis: to catch the thief, the detective has to first make the boundary explicit, and the act of catching would incidentally pick up clues nobody had claimed.

Fable's validation came back a little counterintuitive. The detective who knew there was a fake did score high on catching it — but a control group that knew nothing, asked only to "find all the gaps," found more real holes. More interesting still: once the detective caught the fake, the real hole that fake had been sitting on top of disappeared from its list. The satisfaction of cracking the case marked that ground "handled." That psychological case-closing, I think, holds for people too. So the conclusion: the genuinely effective ingredient is "fresh perspective plus writing observations down in a structured way," not the fake itself.

The third test came out worst, but worst in the most instructive way — it demonstrated, with its own hands, exactly what this whole post is about. I called it the blur-and-net. First I had an agent "feather" each task's boundary, push it outward and blur it so neighboring tasks' scopes overlapped, then had a new agent re-tighten the boundaries, on the theory that the tightening might net the slivers that strict boundaries had cut off. The opposite happened. The moment the boundaries blurred, the precise details bled out first; the agent who took over to re-tighten had nothing accurate to work from, could only fill in from imagination, and tightened to a version further from the original intent. What it validated is the plainest rule there is: garbage in, garbage out. And the way it failed is the same mistake my whole pipeline made — once you let precision dissolve, whoever inherits it can only patch with hallucination, and the patches drift further with every pass.

The line I copied down and taped to the wall

Pulling all the findings together, Fable wrote one line in its thinking notes, the only line from this whole thing I copied down:

Across the entire audit, not one defect was a defect of capability. Every agent did precisely what its spec gave it. Every failure was a failure of information flow: a message not sent, not received, two ends talking past each other. This is a distributed-systems problem, not an AI problem. If you take one thing away: the next pipeline primitive worth inventing isn't a better generator. It's a reconciler.

A reconciler.

I'd spent months thinking about how to make the AI generate better, decompose more accurately, run more stably. Fable told me I'd been looking in the wrong place. My agents generated beautifully — so beautifully they filled in every under-specified spot. The problem was never generation. It was that no one stood in the middle, checking line by line whether the thing you sent out had anyone on the other end to receive it. What I lacked wasn't a smarter producer. It was something that asks: does this message have a sender? a receiver? are both ends talking about the same thing?

The fix: making "the edge" a first-class citizen

Once you understand the root cause, the fix isn't chasing those three symptoms. It's filling the line nobody had been managing.

The most central one Fable called the wiring matrix. Every cross-module event gets three cells on a table: who handles it on the server, who sends it on the client, who receives it on the client. Any cell left blank is treated as a compile error — it doesn't pass. That one move directly chokes off the regeneration mechanism for the whole class of "questions didn't arrive" and "button is dead" bugs, because their essence is a blank cell in that matrix, and before this there was no table for anyone to look at.

Two supporting pieces. Open a "skeleton task" at the very front that registers all routes in one pass, killing root-route no-man's-land like "the home page is owned by nobody." Then open a "smoke task" at the very end that walks the user journey from start to finish, running the whole flow once and checking, cell by cell, that the wiring matrix actually exists in the code. The point isn't how many bugs got fixed. It's where they got fixed: filling the line directly, instead of chasing the spots where the line broke and slapping a band-aid on each one.

What I took from that late night

If you're also assembling an automated production line out of AI, here's what one all-green-yet-all-broken night bought me:

The most dangerous place in your system usually isn't a module that's badly built. It's the line between modules that nobody owns. AI will build every module well — so well that you'll believe the whole is well too. But whether the whole runs lives in the seams, and a seam belongs to no single module, so no acceptance checklist is watching it. All green is the points being green. What's broken is the lines.

So rather than going off to find a smarter AI to generate for you, ask yourself one question first: is there anything in my flow that reconciles? Is anyone checking whether the message sent out has a receiver, whether both ends are talking about the same thing? If not, sooner or later you'll hit another all-green report paired with a thing that doesn't run.

This is also the one line behind all the governance I do. Whether it's the reverse organ that steps back, copying the contract before writing the code, or the whole body of CLAUDE.md rules — what actually bites me is never the point I'm staring at. It's the seam I'm not looking at. The only difference, this time, was that even the rule I used to guard the seams had become a seam itself.

→ Back to Part 1: the report was all green, the game was dead

Addendum (a few weeks later): even the report I used to reconcile was lying to me

I did eventually build that reconciler. Every agent that says "I'm done, I verified it" gets a separate, independent auditor sent to re-run the checks and diff them against the real git changes — and it may only tighten a status, never loosen it (player-and-referee → swap in a read-only referee). When it finishes it prints a report: how many were really verified, how many the auditor knocked down. I thought the reconciler chapter was closed.

Then I handed the whole package to Fable 5 for a second audit, and it punctured something I hadn't seen: my reconciler reconciles — but the report about the reconciliation was itself still lying.

The nastiest example: if I set the audit to cheap mode (only the cheapest literal checks, no independent auditor actually dispatched), the report shows "downgrades: 0". You glance at it — oh, audit's on, zero problems, clean. But that 0 doesn't mean "checked, nothing wrong." It means "never checked at all." The same 0 — one means safe, the other means stark naked — and the report makes them look identical. Same disease as Part 1: an all-green report can coexist with a thing that was never verified. Only this time, the thing that's green is my own quality dashboard.

Fable handed me two beams this round, and I copied them down again.

The first: a status is lossy compression. A task marked "done" could be "done but never audited," "knocked down by the auditor," "downgraded because the auditor died," or "barely passed after three autofix rounds" — four wildly different fates crushed into one word. What the system should actually hand over isn't that flattened word; it's the provenance: who checked it, by what method, how many rounds. The label should be derived from the trail, not a field everyone writes over.

The second, the most counter-intuitive: the moment your auditor becomes a target to hit, it stops being an accurate ruler. I later added a "knocked-down-by-the-auditor → auto-repair" loop. Sounds great — but the auditor is a ruler on the first pass, and the instant auto-repair kicks in, it becomes the gate to beat. So the first-pass upheld rate is the only uncontaminated quality signal; the ones that only passed after several repair rounds, however pretty the number, can't be used to claim quality.

So this fix wasn't to the audit logic. It was forcing the report to tell four truths: how many were genuinely independently verified (X/N, not that lying "downgrades: 0"), the first-pass rate, which ones only held after autofix (sample those harder by hand), and keeping the auditor-died downgrades fingerprinted and separate from the genuinely-checked ones.

And there was a tail — the same disease again: I made the report tell the truth, then nearly forgot that a truth nobody reads out loud is a truth spoken to an empty room. The pipeline computed "only 0 were checked" and wrote it into the report, but the end that reads the report back to me never read that field, and went on narrating cheap mode as "clean." I had to go back and fill that seam too. A green light nobody relays and a green light that lies are the same thing to the person reading the report.

Part 1's lesson was "the unowned line between the points"; this addendum is its mirror: the very thing you use to check — and the clean bill of health it hands you — also needs someone to reconcile it. The difference, this time, is that I learned to ask, before trusting any green light: what did this green light actually see with its own eyes?

The open-source tools this pipeline uses (all MIT, take what you want)

specmit — the pipeline runner that takes a spec and runs it into an MVP. https://github.com/dragon375014/specmit
spec-sonar — converges an idea into a spec and decomposes it into a dependency-ordered task graph. https://github.com/dragon375014/spec-sonar
goal-workflow-designer — the shaping coach that interrogates a single task until it's precise enough to start. https://github.com/dragon375014/goal-workflow-designer
claude-skills-governance-meta — a library of governance patterns that block common mistakes before execution (reconciler defenses like the wiring matrix are being collected here). https://github.com/dragon375014/claude-skills-governance-meta
agent-work-board — a coordination board that keeps multiple parallel AI sessions from stepping on each other. https://github.com/dragon375014/agent-work-board

The full index lives on my open-source toolkit page.

"I Wired Five Open-Source Tools Into One Command (Part 1): The Report Was All Green, the Game Was Dead"

Dexterlung — Wed, 12 Aug 2026 13:05:16 +0000

I used to believe one thing without examining it: if the report is all green, the thing is correct.

That night I was staring at my terminal. Four batches of AI agents had just built a multiplayer online game piece by piece, and the report they spat out at the end read: four goals verified, four completed, zero failed. I was genuinely a little moved, because all I had typed was a single command, and out of one sentence of an idea it had grown something that ran. I was about to close the terminal and go to sleep when, for no good reason, I clicked open the browser.

The game was dead.

What I opened was a pile that didn't connect. The teacher's admin panel wouldn't even load. The page the students were supposed to see on their own was fused with it, so you couldn't tell which was which. (The finer faults — buttons that did nothing, the question the teacher picked never reaching the server — were things a model called Fable teased out one at a time later, in a sandbox. That's the next post.) The all-green report hadn't lied to me by a single word. It also told me almost nothing.

This post is about how I walked into that "all green, all broken" late night. The next one is about how a model called Fable made me see what I was actually missing — and it was not a smarter AI.

I Had a Cabinet of Tools, Not a Line

Let me start with why I built this pipeline at all.

Over the past six months I'd been building alone while learning, and only recently had I extracted a few of the flows I kept reaching for into small open-source tools: one that interrogates a vague idea into a spec and then breaks it into a dependency-ordered task graph; one that grinds a single task until it's precise enough to start work; one that scans my work before I commit and blocks the mistakes I keep making; and one that's just a plain-text board, so when I have several AI windows open at once they don't step on each other.

Each of them works fine on its own. The problem was they were a cabinet of parts, not a production line.

When I actually wanted to go "from one sentence to a running MVP" (a minimum viable product), the carrying in the middle was still done by these two hands. Run the first tool. Read it myself to work out which tasks have no ordering between them and can run at the same time. Open three or four windows myself and feed each one a task file. Watch them run myself. Check the output myself, one by one. The pipeline was always there. I was the carrier.

The idea behind specmit was as simple as one sentence: take the part I was carrying by hand and fold it into a single command. The name is the position — spec plus submit. Take the spec you've settled, and submit it for execution.

(One thing I muddled myself at first, so let me clear it up: the tool that converges an idea into a spec and breaks it into a task graph is not the same as specmit. The former is the design layer — it draws the graph and stops. specmit is the execution layer — it starts from that graph and runs it into code. They're the two ends of one pipeline, and I wrote the "how to converge an idea into a graph" half up in another series.)

I Deliberately Didn't Weld Them Together

The easiest mistake to make building this pipeline, and the one I deliberately avoided, was welding the five tools into one big program.

I let them talk to each other only through files. The upstream tool spits out a task graph and a few task files; specmit reads those files, starts assigning work, and writes a report when it's done. No tool calls another tool's code directly. They only know what the files they hand each other are supposed to look like.

There's something nice about this decision. I can delete any one tool and nothing upstream breaks; each layer can grow on its own without dragging the others along. At the time my head was full of those upsides.

What I didn't see was the other side. The place where the coupling came loose was exactly the place nobody ended up owning. The file format where two tools hand off is the most fragile seam in the whole pipeline, and back then I wasn't looking at it at all. That setup comes back to find me, painfully, in the next post.

I Handed a Game to a Line I Hadn't Written by Hand

For the first guinea pig I picked something hard enough: a multiplayer game that was "Plants-vs-Zombies-style tower defense, plus middle-school math, plus the whole class splitting into teams for a realtime battle." I picked something this complicated on purpose — realtime connections, a game engine, a teacher in control — because simple things can't tell you whether the pipeline is real.

The upstream tool broke it into seven tasks and two frozen interface contracts, arranged into four batches: do the room system and the question-bank system first, the two tasks with no dependency between them, at the same time; only then build the connection infrastructure; then run the three tasks that feed off the same connection contract together; finish with the teacher console and the statistics.

I typed the command, and then I just watched. The first batch of two agents started at once, finished, and only then released the second batch, like a real production line stacking a realtime multiplayer game cell by cell. The picture was honestly kind of mesmerizing, and I'll admit I felt a little pleased with myself in that moment.

"All Green"

When it finished, the numbers the report gave me were spotless: four verified, four completed, zero failed.

Every task had ticked every line on its own acceptance checklist. Rooms could be built, the question bank could be queried, the student interface could be drawn. All green.

I have to be honest: in that moment I was already writing the opening of this very post in my head, something in the self-satisfied register of "how I generated a game with a single command."

Looking back, the most ironic sentence in the whole thing is true. I just had its meaning backwards at the time:

Every agent did exactly what the spec it was handed told it to do. Across the whole pipeline, not one agent fell down on the job.

I thought that sentence meant "so the system is correct." It took me one uncomfortable late night to work out what it actually means: "so the places where the system is broken are none of them on any single agent." Those two things sound alike. They're worlds apart.

What Was the Green Actually Greening

Before I describe what I saw when I opened the browser, I have to honestly answer a question I skipped that night and only dared to face afterward: what does "all green" even mean, the way this pipeline says it?

Its green was defined like this: every acceptance criterion had been claimed by some task, and mechanically checked off. Rooms can be built, the question bank can be queried, the student interface can be drawn — ticked cell by cell.

Did you notice that nowhere in this whole definition does anything ask whether the game can actually be played?

"The teacher presses start, and a question pops up on the students' screens" — that thing crosses three tasks. It doesn't belong to the teacher console, doesn't belong to the connection layer, and doesn't fully belong to the student interface. It lives in the seam between three tasks. And my acceptance checklist hangs line by line under each task, with no line claiming that seam. Same with "what you should see when you open the home page" — nobody ever asked, from start to finish, so nobody checked it.

What was green was that each part passed on its own. It never said the parts would move once you connected them.

I was staring at all that green, about to shut the machine down. Before I did, I clicked open the browser. What happened after that, and the one sentence a model left me with, is the next post.

The First Thing I Took Away From That Late Night

If you're also using AI to stitch together a flow that "turns ideas into things automatically," there's one thing I want you to remember from this post, and I'll save the rest for the next one:

A green light does not mean it moves. In any automated report, the only thing that's green is the stuff it was designed to check. The things it didn't check — especially the ones living between module and module, belonging to no single module, the seams — don't turn red. They just quietly don't exist. The most dangerous moment for a beautiful all-green report isn't when it's lying. It's when it honestly answers only the small part you asked about, and you think it answered all of it.

In the next post, the model called Fable shows me that these seams aren't a handful of stray bugs but a whole category of thing that nobody was minding across my entire pipeline. It also leaves me with a sentence that changed how I see this: the next thing worth inventing isn't an AI that generates better, it's something that reconciles.

→ Read on (Part 2): the all-green illusion, and the thing I came to call a reconciler

This pipeline, contract over code, and the "reverse organ" that points out my blind spots are really the same obsession: rather than hoping I won't make mistakes, build something that watches for me. Except this time I learned that even the obsession itself has a blind spot.

The Open-Source Tools This Pipeline Uses (all MIT, take them)

specmit isn't a single tool. It strings together the independent open-source repos below into one pipeline, and each one also works on its own:

specmit — the pipeline runner that turns a spec into an MVP: one command, batched parallel agents, frozen contracts. https://github.com/dragon375014/specmit
spec-sonar — converges a vague idea into a spec and breaks it into a dependency-ordered task graph, platform-agnostic. https://github.com/dragon375014/spec-sonar
goal-workflow-designer — a shaping coach that interrogates a single task until it's precise enough to start. https://github.com/dragon375014/goal-workflow-designer
claude-skills-governance-meta — a library of governance patterns that block common mistakes before execution. https://github.com/dragon375014/claude-skills-governance-meta
agent-work-board — a single-file coordination board that keeps multiple parallel AI sessions from stepping on each other. https://github.com/dragon375014/agent-work-board

Install with npx specmit init, or clone each one and copy the skill into ~/.claude/skills/. The full index is on my open-source tools page.

I Built My AI Team a Blackboard — How to Stop Parallel Claude Sessions From Colliding

Dexterlung — Mon, 10 Aug 2026 01:05:50 +0000

Series: Indie Dev Notes · T12

In the last post (T11), I said I'd turned my AI into a team and promoted myself from employee to CEO.
This one is the reality sequel: the moment the team grew, it started crashing into itself.

The bigger the team, the more it collides

The way I develop now is to keep several Claude Code sessions open at once — one on the home page, one on orders, one sweeping governance debt. Each in its own git worktree (a worktree: a separate working folder cut from the same repo, each on its own branch, files isolated from each other).

Sounds great. Until one day:

From "memory," I assumed some branch was dead and nearly deleted it (remote included) — turns out it was another session's actively-developed branch, 10 commits ahead of the mainline. Only git's reflog (git's "undo of last resort," which keeps a record of every recent HEAD move) saved it intact.
Another time, I was editing a coordination doc and went to push — and got blocked, because in those very seconds another session had merged its branch into the mainline.

The common thread: these sessions have no idea what the others are doing. I (the human) became the only one who knew the whole picture — and my memory expires and gets things wrong.

The real bottleneck isn't compute — it's my attention

At first I thought the problem to solve was parallelism — how to run more agents at once. It wasn't.

Parallelism is easy (just open more sessions). The hard part is: when work is scattered across a pile of sessions over several days, there is no single place that remembers "who's doing what, how far, and what's left." Every new session is like an amnesiac new hire who has to re-grep (keyword-search the whole codebase) just to get oriented.

The solo developer's bottleneck was never the AI's compute. It's my own context not being laid out and reconnected across sessions.

The fix: give the AI team a "blackboard"

What I made is crude: one markdown file. But it has rules:

One shared blackboard: a file every session reads and writes, tracking "in progress / backlog / done," plus an "area map" marking which work touches which files.
Claim before you act: any session that wants to start first adds a row to "in progress" with its branch and date — raising its hand to reserve the slot, so nobody else takes the same chunk.
Auto-recover stale claims: a row untouched for 7 days might mean that session died, so it can be reclaimed — but before reclaiming you must re-verify the branch's real state with git on the spot (literally the mistake I made above, written straight into the rules).

That's it. But it turns "I keep it in my head" into "the file keeps it," and it's the same single file shared by every session.

(Technical detail: I keep it on the mainline, and use a persistent worktree so any session can read/write it via the same absolute path — because an AI agent can read any path, not just its own working directory. That way even a session on a feature branch sees the same blackboard.)

Then I found out this thing has a real name

I thought I was reinventing the wheel. A quick search showed the industry has studied this for ages:

The Blackboard pattern: multiple agents don't shout at each other directly; they coordinate by reading and writing one shared document that represents the whole work state. Speech-recognition systems used it back in the 1970s. My file is a blackboard in the literal sense.
Stigmergy: coordinating by leaving traces in a shared environment — like ants using pheromones instead of holding meetings.
Kanban + leases: the "backlog / in progress / done" columns + "claim before acting, release when expired" — engineering has names for all of it.

There are even off-the-shelf tools (vibe-kanban, Claude Squad, Crystal …), and an academic benchmark studying whether AI coding agents can actually be your teammate (CooperBench — its honest conclusion: not yet; coordination is still hard).

The biggest surprise: Claude Code just grew a native version

Halfway through researching, I found Claude Code has an experimental feature called Agent Teams — a lead session spins up a group of teammates, sharing one task list, grabbing tasks via file locks, handling task dependencies automatically. Almost exactly what I hand-rolled.

But it doesn't cover my scenario: Agent Teams is ephemeral — one lead spins up a team on the spot, finishes, tears it down, one team at a time. My need is a persistent ledger across days, across independently-launched sessions. The two are complementary.

That gave me a realization: when you hand-build something for your own pain, then discover the industry already named it — even supports it natively — that's not wasted effort. You independently verified the problem is real. You just hadn't read the paper yet.

Three days later: I sharpened that blackboard — then open-sourced it

I thought writing the section above closed the topic. The real learning started when I used it — one of the sessions I coordinated with this blackboard was sharpening the blackboard itself (very meta, I know). A few things I didn't see coming until they hurt:

"Claiming" has to push immediately — not when you finish. My first instinct was "add a row, start working, push later." Problem: between "confirm nobody's there" and "add a row" there's a gap, and two sessions can both read empty and claim the same chunk. Changing it so adding a row pushes instantly turns git into the lock: first to push wins; the second can't push and must rebase (re-apply their changes on top of the other's latest work), discovering the collision at claim time instead of at merge time.
The blackboard itself is the file most likely to collide. It's the single file every session writes to. Ironic — the thing I built to prevent collisions collides the most. The rule: edit only your own row, don't re-sort everyone else's.
"Stale" has to be judged by the branch's last commit time, not the board's last edit time. Someone committing steadily who just forgot to update the board isn't gone. The truth is in git, not in the line I hand-typed. So I wrote a tiny script (npm run board) that pulls, straight from git, how long each branch has been idle and how far ahead/behind the mainline — a lie-detector for the hand-written progress note.

And then the funniest, most worth-writing-down moment of this whole thing —

The safety net I added quietly disabled another safety net

I wanted the system to "automatically nudge me when I push a branch that isn't claimed on the blackboard." So I appended a "print a reminder" command to the end of my pre-push hook (the gatekeeper script that runs automatically before a push).

That one line ate the entire check's pass/fail signal.

The hook was supposed to block the push when a governance check fails. But my reminder line always succeeds, and the shell's rule is "the whole block's success = the last line's success" — so from then on, regardless of whether the governance check passed, the hook reported "success." I had silently muted a safety net that blocks broken code, with my own hands.

How did I catch it? I pushed a commit and the screen printed both "❌ governance check failed, push will be blocked" and "push succeeded." Two lines contradicting each other. That's the moment I realized what I'd done.

This is a microcosm of the whole methodology: every layer of protection you add can accidentally break another layer. Which is why actually using it — dogfooding (eating your own dog food, being your own first user) — beats designing it beautifully. Only a real run surfaces the contradiction and shows it to you. (As a bonus, this also let me fix a pre-existing problem sitting in the governance checks that had been failing but that nobody had pushed into until now.)

One more cost I almost missed: every claim burns deploy quota

My board lives on the mainline, and my mainline triggers a cloud build on every push. Which means every claim = editing one plain-text file = a push = a full build — even though the build output is identical to last time. A plain-text board was quietly burning my limited free monthly build minutes.

The fix is a path filter on the cloud side: only build when frontend code actually changes; docs / scripts / board commits skip automatically. This kind of invisible cost only surfaces when you actually wire the thing up — on paper you'd never think of it.

Then I pulled it out and open-sourced it

By this point I felt it shouldn't only live in my own repo — it applies to anyone running multiple AI sessions at once, and it's absurdly light: one markdown file + one optional script + one line wired into your agent's rules.

So I extracted it into a standalone public repo:

👉 https://github.com/dragon375014/agent-work-board (MIT — use it anywhere, no attribution required)

It has: a copy-paste board template, that git lie-detector script, opening-ritual snippets for three tools (Claude Code / Cursor / generic agents), and the full methodology (English and Traditional Chinese).

I agonized a bit over the name. I almost called it work-board-for-cross-session, but "cross-session" is insider jargon, long, and clunky. I landed on agent-work-board — short, and it's obvious at a glance that it's "a work board for AI agents to coordinate on." Leave the "why" to a one-line tagline; don't stuff it into the name.

I deliberately did not bury it inside my heavier governance framework. Because this blackboard's value is exactly that it's "entry-level, universal, usable by anyone in five minutes." Hiding it under a high-barrier framework would hurt the very people it should serve most — you, just starting to feel "the more sessions, the messier it gets."

The throughline for solo developers

If you're also pair-programming with AI on your own and starting to feel "more sessions, more chaos," here's my takeaway:

Don't chase fancier multi-agent frameworks (that's a problem teams are solving). Invest in the two most boring things: ① one persistent, cheap state that loads at the start of every session (a blackboard), and ② a reusable "where things are and how to read them" agent, so every new session boots up smart instead of re-grepping from scratch.

You're not managing a swarm of AIs. You're managing whether future-you, in another session, can pick up where present-you left off.

And — the friction you feel right now (collisions, not seeing what the others are doing) isn't you doing it wrong. It's the frontier of this whole field; even big companies and research papers haven't solved it cleanly. You just hit it early.

本文原載於我的部落格：I Built My AI Team a Blackboard — How to Stop Parallel Claude Sessions From Colliding

spec-sonar: The Complete Design Record (Part 2) — Fable's Review, a Real-World Conflict, and the Two-Repo Decision

Dexterlung — Thu, 06 Aug 2026 13:05:14 +0000

Part 1 ended where I handed 13 review questions to Fable 5. This part records what happened over the next 24 hours — the review results, 25 files shipped, and the plot twist I never saw coming.

Read on: Back to Part 1 — from one idea to a toolchain · 繁體中文版 · this tool is listed in my open-source toolkit index.

14. Fable's review: three holes, plus an unexpected self-audit

The review hinged on one question: "Given this CLAUDE.md, could you start work right now?"

The test case's spec (the math tower-defense game) looked thorough — six modules, itemized acceptance criteria, data structures, security rules. Fable's answer: modules one and two can start; modules three and four stall on day one, guessing. It found three holes:

Hole 1: a stats vacuum, plus an internal contradiction. The Unit structure defines hp / attackPower / range / speed — but not a single actual value for any of the three plants or three zombies. Worse: the sunflower "passively generates sun (+1 every 10s)," while the resource system is explicitly "personal earn, personal spend." Does the sunflower's sun go to the student who planted it, or to the whole team? Two claims that cannot both hold — and both had been "confirmed" during convergence.

Hole 2: nobody defined the zombie movement model. Continuous movement or grid-hopping? Which cell does a moving zombie occupy? This unasked question silently determines the broadcast protocol's payload shape, the collision logic, and the very meaning of the win condition "zombie x ≤ 0 means breakthrough."

Hole 3: a three-way contradiction. Acceptance criteria require "state restored automatically after reconnect"; players are keyed by socketId, which changes on every reconnect; and "no account system" sits in the forbidden list. The three cannot coexist — restoring on reconnect necessarily requires some cross-connection identity credential.

What the three holes share: none is a writing-quality problem. All are "you don't know what you don't know" problems. The prettier a spec looks, the more dangerous these holes become, because nobody questions a pretty spec.

The bonus: the tool audited itself. Checking the actually-produced STATE_FINAL.json against its own template, I found that user_tech_level: "none+partner" isn't in the defined four-value enum, and tech_stack / known_risks are ad-hoc fields that exist in no template. This is exactly the "schema drift" Audit Mode was designed to catch — and its first catch was the tool itself. That self-audit directly produced STATE schema 1.1.

15. The psychology of bypassing "explicitly out of scope"

The review's second question: "Under what conditions would an executor model bypass the do-not-build list?"

Fable listed four scenarios where it genuinely would:

Implicit dependency: when an acceptance criterion materially requires a forbidden feature, it would invent a reconnectToken and convince itself "that's not an account system."
Usability erosion: "the report must be printable" + it vanishes on refresh → tempted to add caching — does that count as "cross-session storage"? When the boundary blurs, it leans toward building.
Vague-term discretion: "no leaderboards," but acceptance requires "the 3 most-missed questions" — is a sorted display a leaderboard?
Best-practice inertia: logging, rate limiting — on neither list, silently added.

The four counter-measures: every do-not-build entry carries its motivation and disguise boundary (what minimal substitute is allowed, what mutation is banned); bans become testable negative acceptance criteria ("the database must contain no users table"); a conflict-escalation protocol replaces discretion; and a do-not-build × acceptance-criteria cross-check runs before handoff.

The core insight: you cannot defend against a model's good intentions. What you can do is redefine well-intentioned bypassing as a protocol violation.

16. STATE learns that humans change their minds

Part 1's STATE accumulated in one direction only: bright zones never left. But in real convergence, users overturn a round-2 decision in round 5, say "I want A but not B" when B is actually A's prerequisite, and add "oh, one more thing" right before the finish line.

Schema 1.1 adds three protocols:

Retraction: the overturned bright item is removed, and every other bright item that depended on it cascades back into the dark zone — the system never guesses replacement values; each is re-confirmed.
Contradiction: when "B is A's prerequisite" is detected, progress freezes and the user gets a forced trilemma (accept a minimal B / shrink A / find substitute C). The system must not adjudicate on its own. No handoff while a contradiction is pending.
Late addition: "oh, also add X" triggers an impact assessment first — minor / moderate / major — with major additions re-running complexity calibration.

The structural change underneath: bright items become objects with an id, the round they were established, and depends_on — plus a revision_log, because the engineer who inherits the spec deserves to know which decisions were once overturned.

17. goal-decomposer: compiling a spec into a graph any model can execute

The new core of the toolchain. Its behavioral contract is one sentence:

You are not a roleplaying project manager. You are a compiler: spec in, goal graph out.
Whatever the spec lacks, you report a compile error — you do not improvise.

The key designs:

Four dependency types, every edge with evidence. Data, API, state, and UI dependencies — every inferred edge must quote the spec verbatim (≤ 25 characters), and inferred edges require user confirmation before output. A cycle in the graph = a spec defect: report it, don't force-break it.

Contract files (C*.md) — a layer added mid-design. The original architecture had only spec and goals. The test case proved that cross-module interfaces (socket event names, the unit-stats table) must be frozen into standalone files, or parallel executor models will each invent their own event names. Contracts carry literal values — JSON instances rather than schema descriptions — because a weak model copying an instance can't get it wrong, while "understand the schema, then generate" can.

Pre-adjudication is the real engine of "any model can execute." Every design decision the spec doesn't settle is settled by the strong model at decomposition time, written into the goal file's "pre-adjudicated decisions" section with reasons. The executor's job collapses to literal execution — Haiku executes reliably not because the format is pretty, but because the degrees of freedom were spent before it ever saw the file.

The BLOCKED protocol: a legal "I don't know" exit for weak models. A fixed-format stuck report (type / problem / what was tried / decision needed). Without this exit, a weak model will always fill the gap with hallucination.

The cold-start test is the pass bar. Hand the goal file alone to the weakest target model and ask four questions: what to build, how to verify, what's forbidden, what to do when stuck. If it can't answer all four, rewrite the file — don't upgrade the model.

Applied to the test case: six modules compile into 7 goals + 2 contracts — 2 opus (game engine, realtime sync: they must invent what the spec didn't give), 3 sonnet, 1 haiku (the teacher console: a pure data panel once interfaces are frozen) — scheduled into 5 execution batches, parallel within each batch. That is the concrete shape of "Fable designs once, cheap models execute in parallel."

18. Twenty-five files shipped

The design discussion froze into a complete open-source package: two skills (idea-to-spec v1.1 with the conflict protocols, goal-decomposer v1.0), two mode designs (Audit, Conflict Analysis), a stdlib-only project-scanner.py (smoke-tested, with three-level degradation guaranteeing < 20 KB output), the goal-graph JSON Schema, adapter format specs for four platforms, bilingual READMEs and CONTRIBUTING, an MIT license, and the full math tower-defense end-to-end example.

The honest verdict from the value analysis: spec-sonar's room to live is not "yet another spec tool" (GitHub spec-kit, AWS Kiro, and BMAD already crowd that road) but three things they don't do well — detecting unstated requirements (spec-kit formats stated ones), treating requirement change as a first-class citizen (the conflict protocols), and cross-platform projection (no single-IDE lock-in). The biggest known gap is equally honest: quality is not yet measurable; an eval harness is the roadmap's top priority.

19. Plot twist: the tool catches my own conflicts

Up to this point, the story is "a design that landed smoothly." The twist came after I installed the two new skills into a production development workspace.

That environment already housed two other skills — from my other published open-source repo, goal-workflow-designer: /goal (depth: polish one task into an iterable goal prompt) and workflow-shaper (breadth: fan one check out across N units). Four skills now shared one environment, so I ran the Conflict Analysis Mode for the first time.

Result: 5 conflicts across 6 pairings — spanning both repos.

But the most valuable finding wasn't any single conflict — it was the structural one: every deferral clause in the environment was one-directional, and all of them routed around goal — the skill with the most generic name and exclusive ownership of the /goal command had zero outbound deferrals. It was the ecosystem's accretion point: generic phrasing fell into it, and it never handed anything off. The two worst conflicts were both symptoms of that one structure.

On re-review, I also overturned one of the report's classifications. "goal vs goal-decomposer homonym" had been filed as namespace pollution — but a word-by-word comparison showed both use the same five-element format (outcome / verification / constraint / iteration policy / error handling). The G*.md files goal-decomposer produces are, in essence, pre-filled goal prompts, directly executable by /goal's KICK-OFF machinery. The name collision was actually an unclaimed integration point. The right fix wasn't mutual avoidance — it was declaring the five-element format a shared standard across both repos.

The repair left three cross-repo governance lessons:

Fix the source, not the installed copy. The conflicts spanned two independently versioned repos; patching only the install directory means the next reinstall reverts everything. Every fix landed in both repos' sources.
Cross-repo deferrals must be conditional. Hard-coding "defer to idea-to-spec" breaks in environments where it isn't installed. Every clause reads "if installed, defer; if not, continue but flag the scope difference."
When two terms collide, look for a shared standard first. If the underlying format is the same, declaring a standard beats drawing a boundary.

One small surprise during the repair: inspecting the install topology revealed that the new skills' global install directories were junctions pointing straight at the repo source — edit the source, and it's live everywhere instantly. The "source-as-deployment" structure for a solo multi-repo developer had grown by itself.

20. Coexist or merge?

The final question: should the two repos be merged into one complete body?

My decision: coexist, don't merge. Three reasons:

Different audiences. goal-workflow-designer is published and self-sufficient; many users want /goal and nothing else. Merging would force the whole spec pipeline on them.
Different lifecycles. One side is iterating at a stable 0.2.x; the other hasn't shipped 0.1. Coupled, every breaking change in the new repo would drag down the stable repo's users.
Something better than merging already exists: a shared standard (the five-element format) + conditional mutual deferrals + the same routing table in both READMEs. The relationship is compiler and runtime — spec-sonar compiles specs into G*.md; goal-workflow-designer's KICK-OFF executes them. Each is valuable alone; together they form the full pipeline.

The one discipline to hold: the five-element format is the contract between the two repos. Changing it on either side is a cross-repo breaking change, requiring synchronized version bumps.

Interlude: the tool missed its own dark zone

The first real convergence run after the package shipped (a marketing-funnel spec) surfaced two user confusions: the Q&A rounds arrived as plain text (no native Claude Code selector window), and the raw <STATE> JSON block was mistaken for "the debris of a failed trigger."

The root cause is ironic. The SKILL.md had hard-coded the lowest-common-denominator text format — the correct answer for claude.ai's plain chat, but "interaction style must adapt to the environment" had never been written into the spec. The tool built to detect unstated requirements had an unstated requirement of its own.

The control group sat right next door: the goal skill says "Use AskUserQuestion progressively" from day one, and never had this problem. The behavioral difference between the two skills wasn't model mood — it was spec difference. Which once again validates the behavioral-contract philosophy: the model executes the contract faithfully, and whatever the contract lacks, the behavior lacks.

The fix (v0.1.2): a new "Step 0: environment detection & interaction mode." In Claude Code, enumerable questions prefer the native selector and STATE persists to a file instead of the chat; in plain-chat environments, fall back to text mode with the STATE block always labeled "system bookkeeping — safe to ignore." Plus a hard-coded three-level degradation chain: native selector → on failure, structured text options (reply with a single letter A/B/C) → no tool at all, pure text. And a mandatory one-line human progress display every round.

A boundary worth stating: the selector's UI rendering, option exclusivity, the automatic "Other" escape hatch, and answer return are all native harness capabilities — the skill never worries about them. But "what to do when the tool fails" is model discretion — unless it's written into the spec. The degradation chain reclaims exactly that discretion.

The principle, in one sentence: bookkeeping is for the system; progress is for the human.

21. Thinking patterns added in Part 2

Part 1 accumulated eight reusable patterns. Part 2 adds seven:

9. Pre-adjudication. Make every design decision at "compile time"; the executor only follows the letter. A weak model's reliability comes not from pretty formatting but from having its degrees of freedom spent before it gets the task.

10. The cold-start test as the pass bar. An artifact is acceptable not when its author is satisfied, but when a zero-context, weakest-tier executor can answer the four questions. If it can't — rewrite the artifact, don't upgrade the executor.

11. Give the executor a legal "I don't know" exit. Without a BLOCKED protocol, models fill gaps with hallucination. An explicit stuck-report format beats any "please be honest" exhortation.

12. Conflict as a feature. Install into a real environment and run conflict analysis; every hit is free design feedback. The tool's first real-world catch was my own repos — more persuasive than any synthetic example.

13. Fix the source, not the copy. Anything that gets "installed somewhere" must have fixes land in its version-controlled source, or the next deployment undoes them.

14. On a name collision, look for the shared standard first. When two concepts collide, compare their underlying structures. A shared standard is a stronger resolution than naming isolation.

15. Interaction style is part of the spec. How to ask is not model discretion. Which interaction primitive a skill uses per environment (native selector / structured text options / plain text), and how it degrades on failure, belong in the behavioral contract — or you'll deliver the worst experience on the best platform.

Epilogue: dogfooding all the way down

Looking back, the most consistent pattern in this whole process is the tool relentlessly eating its own dog food:

The design itself was converged using spec-sonar's own process (Part 1, section 11).
The tool's first audit caught its own schema drift.
The tool's first real conflict report caught conflicts between my own two repos.
And that conflict report itself became an official example file in the repo.

For a tool that claims to find "what you don't know you don't know," the best validation is to keep pointing it at itself. So far, it has found something every single time.

← Back to Part 1 · Repos: spec-sonar × goal-workflow-designer

本文原載於我的部落格：spec-sonar: The Complete Design Record (Part 2) — Fable's Review, a Real-World Conflict, and the Two-Repo Decision

spec-sonar: The Complete Design Record (Part 1) — From One Idea to an Open-Source Toolchain

Dexterlung — Wed, 05 Aug 2026 13:05:13 +0000

This is one long conversation — about 40+ exchanges — in which I went from a very vague idea to the initial design of an open-source toolchain called spec-sonar. Part 1 ends where I hand 13 review questions to Fable 5.

Part 2 covers the next 24 hours: the review results, 25 files shipped, and a plot twist I never saw coming — the tool catching conflicts between my own two open-source repos.

Read on: Part 2 — Fable's review and a real-world conflict · 繁體中文版 · this tool is listed in my open-source toolkit index.

1. The starting point: an intuition

The first thing I typed into Claude was this:

"I'm wondering whether I can use the standard body of software-engineering knowledge, Claude Code's round-based questioning, and a well-designed skill to help people new to AI-assisted development turn ideas into reality — confirm the safety boundaries, set design limits to prevent scope creep, settle the architecture, and finally produce a series of execution playbooks or goals…"

Several key intuitions were already in that sentence:

The concept of dark zones and bright zones — use set difference to find the questions worth asking.
Convergence, not generation — the goal is fewer rework cycles, not faster output.
Complexity loaded on demand — I decide how deep to go, instead of getting everything at full depth.

2. First turning point: interrogate before designing

I forced myself to answer one question first: is this reinventing the wheel?

What the search turned up:

Requirements-management tools for PMs/BAs exist, but they assume you already understand User Stories.
Spec-driven tools for developers exist, but they assume a spec draft already exists.
Claude Code's CLAUDE.md ecosystem exists, but nobody generates specs for non-technical users.

Conclusion: not a reinvented wheel — but the differentiation has to be explicit. The real difference:

Existing tools' route: make the AI smarter so it tolerates vague input
spec-sonar's route:    make the user's input itself precise

The latter is sturdier, because it doesn't depend on a model's tolerance for ambiguity — and that tolerance is exactly where hallucination comes from.

3. Second turning point: reframing the value proposition

I first wrote the value proposition as "reduce design rework." That was wrong.

The problem: a non-technical user can't perceive that value — they don't know how many detours they would otherwise have taken, so they can't feel the detours they avoided.

The corrected value proposition: "reduce the anxiety of landing something vague."

That's trust, not efficiency. What the user actually feels is: "I told it what I wanted, it told me the problems I hadn't thought of, and what got built matches what I had in mind."

This reframe shaped every later decision:

The tone of the Q&A — assistance, not interrogation.
How infeasibility is handled — not rejection, but shrinking to a feasible version.
Showing bright/dark-zone progress every round — the core trust-building mechanism.

4. Core system-design decisions

4.1 A behavioral contract, not roleplay

My first idea was to inject a "you are a senior architect" persona prompt.

The problem: an identity is not a set of behavior rules. Claude plays the architect but doesn't know what this architect must do, must not do, or when to stop.

So I switched to injecting a behavioral contract:

Inject a behavioral contract, not an identity:
"Your job is to converge a software product idea into an executable spec.
 You are not a roleplaying architect.
 You are a system with fixed rules of behavior."

This made the system's behavior predictable, testable, and iterable.

4.2 STATE: externalizing conversational memory

The problem: there is no persistent memory between rounds; by round 4 the model has forgotten what round 1 established.

My fix was to externalize the conversation memory into a portable JSON block:

<STATE>
{
  "round": 2,
  "bright": ["established items"],
  "dark": ["unconfirmed items"],
  "next_focus": "next round's topic"
}
</STATE>

Key principles:

Wrap it in an XML tag — more stable than plain text; Claude parses its own XML output more reliably.
The next_focus field forces each round onto a single topic, preventing scattershot questioning.
STATE_FINAL.json is portable — you can leave mid-process and resume later with full state.

4.3 The baseline problem of the set-difference method

Doing gap analysis, I found a hole:

Set difference only works if I already hold a standard template of "what a complete system looks like" to diff against. No baseline, no difference.

The solution is a dark-zone-baseline.md: 10 standard dimensions that seed every new session's dark list — target users, core feature boundary, data model, auth & permissions, third-party integrations, deployment platform, performance & scale, maintenance & updates, budget & timeline, success criteria.

The most important detail: the Session-vs-Persistent fork.

I only discovered this after running the real test case (a math tower-defense game). The "do we need an account system?" decision had been back-derived from "does the data persist?", rather than asked proactively. The fork has enormous architectural impact, so I promoted it to a mandatory proactive question.

5. The real test: a math tower-defense game

Why this case: a non-technical user (with an engineer partner) wanted to land "Plants-vs-Zombies tower defense × middle-school math × in-class team battle." I used it to stress-test my tool.

What ran: the full 5-round convergence, from "I don't know what to build" all the way to a complete README.md + CLAUDE.md + STATE_FINAL.json.

Key observations:

The resource mechanic was the highest-value discussion. That user raised the real classroom pain point — "a team-captain system creates conflict between teammates." The final design: personal earn, personal spend, plus per-unit cooldowns — individual effort converts directly into individual agency, with no middleman to skim.
Wheel-reinvention detection confirmed the differentiation. Single-player math tower-defense games exist; "whole class online + team battle + teacher console + realtime multiplayer" does not.
The dark zones cleared after 6 rounds — but one was never proactively probed. The Session-vs-Persistent fork emerged by inference from the "no accounts" answer, not from the baseline. That bug directly drove the baseline fix.

The test case's role: the math game is not spec-sonar's target scenario. It's a deliberately hard stress test — WebSocket realtime sync, a game engine, multiple dependency types, ephemeral-session design. Only that level of complexity genuinely probes the system.

6. Third turning point: from a tool to a toolchain

The original design was a single requirements-convergence skill (idea-to-spec). It kept growing:

idea-to-spec (requirements convergence)
    ↓ problem found: CLAUDE.md outputs modules, but no dependencies
goal-decomposer (goal decomposition)
    ↓ problem found: only works from zero; can't diagnose existing projects
Audit Mode (existing-project diagnosis)
    ↓ problem found: large complex systems (ERP) have different needs
Complex System Mode
    ↓ problem found: Claude-Code-only is too narrow
Adapters layer (platform-agnostic universal format)

The most consequential evolution: from Claude-specific to platform-agnostic.

Core spec layer (universal):  goal-graph.json + goals/*.md
Adapter layer (per platform):
  adapters/CLAUDE.md               ← Claude Code
  adapters/.cursor/rules           ← Cursor
  adapters/copilot-instructions.md ← Copilot
  adapters/system-prompt.md        ← any AI agent

That decision turned spec-sonar from "a Claude Code tool" into "a general requirements-engineering tool for the whole AI-coding ecosystem."

7. The philosophy: one expensive deep design → cheap structured execution

The core philosophy of the whole toolchain, surfaced while I was working out how goal-decomposer integrates with goal-workflow-designer.

The background problem is concrete: not everyone can afford Fable-tier model costs.

My insight:

Fable (expensive) thinks deeply once
    → the thinking is frozen into a goal graph and individual goal files
    → any model (Haiku, Sonnet) executes by following the graph
    → Fable-tier reasoning is no longer required

The analogy is compilation:

Fable = the compiler that does the complex reasoning
goal-graph.json = the compiled executable
any model = the CPU that runs it

The smartest (and most expensive) model appears only once, at design time, to settle all the hard decisions; everything after that runs literally on cheap models.

8. Naming: spec-sonar

I considered SpecForge, DarkMap, ConvergeKit, and ReqSonar. I picked spec-sonar because it passed three tests:

Searchability: no same-name repo on GitHub.
Explanation cost: "like sonar, it finds what's submerged in your spec" — one sentence.
Works in both languages: "I sonar-scanned the requirements" reads naturally.

The logic behind the name: sonar's core mechanism is using waves you can't see to find things you can't see. spec-sonar's core mechanism is using questions you didn't ask to find requirements you didn't think of. Form matches content.

9. Compatibility principles (the last major decisions)

Compatibility with existing CLAUDE.md files. spec-sonar is a design-time tool; CLAUDE.md is a build-time artifact — naturally on different timelines. So spec-sonar installs non-destructively: it never overwrites your existing CLAUDE.md, it only appends one reference line.
Conflict detection across existing skills. I upgraded the goal from "avoid conflicts" to "conflict as a feature": spec-sonar's Conflict Analysis Mode reads all your installed skills and outputs a conflict map. That turns it from "yet another skill" into "a governance tool for your skill ecosystem."
Load on demand: three install tiers — Lite (1 skill) for small projects/MVPs/anything finishable in a week; Standard (2 skills) for most projects under 3 months; Pro (full suite) for enterprise/ERP/long-term maintenance.

10. The role of Fable 5

On 2026-06-09 Anthropic released Claude Fable 5 — the first public model of the Mythos family. Its edge: "the longer and more complex the task, the wider the lead," with a particular strength in one-shotting a complete design.

My prompt strategy wasn't "what do you think of this design?" — it was "under what conditions does this design break, and fix it."

I asked Fable to do five things:

Review the CLAUDE.md format from an executor's perspective ("could I start work from this spec?").
Find the dark-zone baseline's systematic omissions per product type.
Design STATE's conflict handling (retracted bright items, contradictions, late additions).
Design the complete goal-decomposer SKILL.md (dependency inference, model-tier assignment).
Design the adapter format for every platform.

11. This design was designed with spec-sonar

The most meta observation worth recording: this very design started from "I have a vague idea" and went through scope judgment, bright/dark separation, set-difference questioning, infeasibility detection (none found), complexity calibration, and wheel-reinvention detection — and that whole flow is spec-sonar's own flow.

The tool's first user was the person designing the tool.

12. Final output list

By the end of the conversation:

idea-to-spec-v1.1.zip
├── SKILL.md                      the convergence engine
├── references/
│   ├── dark-zone-baseline.md     10 dimensions (with the Session-vs-Persistent fix)
│   └── output-templates.md       three output format templates
├── examples/
│   ├── README.md                 math tower-defense case (human-readable)
│   ├── CLAUDE.md                 math tower-defense case (executable spec)
│   └── STATE_FINAL.json          final convergence state
└── docs/
    ├── fable-review-prompt.md    the full Fable 5 review prompt (13 questions, 5 jobs)
    └── spec-sonar-README.md      open-source README draft

Pending Fable 5's reply: goal-decomposer/SKILL.md, project-scanner.py, the adapters/ directory (4 platforms), audit-mode, Conflict Analysis Mode, the tiered INSTALL.md.

(Every item on that list ships in Part 2 — plus three spec holes, one schema self-audit, and a real-world conflict analysis spanning two open-source repos.)

13. Reusable thinking patterns (Part 1)

Interrogate before designing. Every new idea first answers "is this a reinvented wheel?" — with search results, not gut feeling.
Dark zones matter more than bright zones. Stated requirements are rarely the problem; unstated assumptions are the root of failure.
Behavioral contracts beat roleplay. Tell the AI its rules of behavior for this session, not who it is.
Externalized state solves context loss. Multi-round tools must carry state explicitly every round.
Find design gaps with real cases. After the theory, run one real case and let the gaps surface (that's how the Session-vs-Persistent fork was found).
Expensive thinking once → cheap structured execution. The cost-optimal AI strategy.
Universal core + per-platform adapters. The more universal the core format, the longer the tool lives.
Load on demand. Tiered installation lets users choose their complexity instead of paying full cost by default.

Coming in Part 2

Part 1 ends with 13 questions packed into a review prompt and handed to Fable 5. Part 2 records what happened next:

Fable reviews the test case as an executor and finds three day-one landmines in a seemingly complete spec.
The tool audits its own output and catches its own schema drift.
The full goal-decomposer design: dependency inference, contract freezing, pre-adjudication, the cold-start test.
25 files shipped as a complete open-source package.
Then the real plot twist: installed into a production workspace, the Conflict Analysis Mode finds 5 conflicts between my own two open-source repos — and one structural problem nobody had seen.

→ Continue to Part 2

本文原載於我的部落格：spec-sonar: The Complete Design Record (Part 1) — From One Idea to an Open-Source Toolchain

Audio Plays on Desktop but Not on iPhone / iPad — The Culprit Is the MP4 moov Atom

Dexterlung — Sun, 02 Aug 2026 13:05:25 +0000

Series: Engineering gotchas

I put a batch of podcast audio files (.m4a) on Cloudflare R2 and embedded them with a plain <audio> tag. Desktop Chrome and Firefox played them perfectly. But on iPhone and iPad, they wouldn't play at all — tap the button, nothing happens, no error message, console completely clean.

The most maddening part: it throws no error. You have no idea where to even start looking.

This is how I tracked it down to the root cause, and the one-line fix at the end. If you googled "audio plays on desktop but not iphone" or "m4a not playing ios safari" and landed here, skip to section three.

First, rule out all the usual suspects

iOS Safari is picky about audio, and the three most common answers online are: wrong MIME type, no HTTP Range support, or bad codec. I checked them one by one — and they were all correct.

# 1) Is the Content-Type right?
curl -sI "https://your-domain/xxx.m4a"
# → Content-Type: audio/mp4   ✅ correct (m4a is audio/mp4)
# → Accept-Ranges: bytes      ✅ Range supported

# 2) Does a Range request actually return 206? (iOS strictly requires this)
curl -s -o /dev/null -D - -H "Range: bytes=0-99" "https://your-domain/xxx.m4a" | grep HTTP
# → HTTP/1.1 206 Partial Content   ✅ correct

The server side is entirely correct. Content-Type is audio/mp4, Range is supported, it returns 206 Partial Content. R2 is fine. CORS isn't the issue either (an <audio> without the crossorigin attribute plays cross-origin without needing CORS).

And the codec is .m4a (AAC) — the format iOS supports most natively. All three common culprits ruled out. So what is it?

The real culprit: the moov atom is at the end of the file (no faststart)

An MP4 / m4a file is made of boxes (also called atoms). Two matter most here:

mdat: the actual audio / video data (large — 11 MB in my file)
moov: the playback index / metadata (timeline, sample tables — the player must read this first to know how to decode)

Here's the problem: ffmpeg's default output puts mdat first and moov at the very end of the file.

Desktop browsers (Chrome / Firefox) are smarter / more aggressive: they fire a Range request for the end of the file to grab moov, find the index, and play.
iOS Safari / WebKit, with <audio preload="metadata">, only fetches the beginning of the file. No moov at the start → it can't find the index → it silently gives up and won't play.

That's why it plays on desktop but not on iPhone / iPad. Both iPhone and iPad use WebKit, so they fail together.

Moving moov to the front of the file is called faststart — the standard trick that lets video / audio "play while downloading."

How to confirm it (30 seconds)

Grab the first 48 bytes and check whether ftyp is followed by moov or mdat:

curl -s -H "Range: bytes=0-47" "https://your-domain/xxx.m4a" | xxd | head -3

Broken (no faststart) — mdat right after ftyp:

00000000: 0000 001c 6674 7970 4d34 4120 ...  ....ftypM4A
00000020: 6672 6565 00a8 3b91 6d64 6174 ...  free..;.mdat   ← mdat first, moov at the end

Good (faststart) — moov right after ftyp:

00000000: 0000 001c 6674 7970 4d34 4120 ...  ....ftypM4A
00000020: 6d6f 6f76 0000 006c 6d76 6864 ...  moov...lmvhd   ← moov right after ftyp ✅

If mdat comes before moov, that's your bug.

The fix: one line of ffmpeg, lossless, no re-encode

ffmpeg -i input.m4a -c copy -movflags +faststart output.m4a

The key is -c copy — it does not re-encode; it just copies the existing stream as-is and relocates moov to the front. So:

Lossless: audio quality is untouched
Same size (mine was 11,258,702 bytes before and after — not a single byte different)
Instant: 11 MB in under a second

Then re-upload to overwrite the original. If your files are on R2 / S3, keep Content-Type: audio/mp4 on the upload.

(If a CDN like Cloudflare sits in front, check whether the edge cached the old file. Mine was cf-cache-status: DYNAMIC — not cached — so the overwrite took effect immediately. The only remaining cache is the phone browser's local cache — test in a private tab for a clean result.)

How to stop it from happening again

If you have a "generate audio → upload" pipeline, always run it through faststart before uploading — never push the raw ffmpeg / converter output straight up. I baked it into the upload script as a mandatory step: remux faststart → upload → auto-verify with curl that moov really is at the front, all three together. New audio never hits this bug again.

This bug is a good reminder: "works on my machine" and "works on the user's device" are two different things. The server config was all correct, the file was there, desktop played fine — every "obvious" place was clean, and the defect hid in the order of the atoms inside the MP4. Problems that only surface on real devices (especially iOS) slip right past automated tests and desktop development. Next time you hit "fine on desktop, broken on mobile," don't just stare at your code — think file format / platform differences.

本文原載於我的部落格：Audio Plays on Desktop but Not on iPhone / iPad — The Culprit Is the MP4 moov Atom

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

Dexterlung — Fri, 31 Jul 2026 14:34:55 +0000

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.

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