~/onlyascii.dev$ onlyascii.dev

The Philosophical Developer — Chapter 3.5: Designing Traceability

2026-07-01 · 2 min read

#The-Philosophical-Developer #Methodology #Steering #Git #Master-Padawan

Steering note — designing the trace tag pattern.

After mini-clap, I had another problem. The code was good. The LSP tether worked. But when I looked at the repository, I could not see the reasoning. I saw one commit: “feat: CLI argument parser.” Where were the ten cycles? Where was the RED phase? Where was the refactor?

An AI does not explain itself. It produces. If I could not reconstruct the reasoning from the repo, how could anyone else?

I sat down and designed a pattern. I wrote it out:

1. Branch per feature: git checkout -b feature/<name>
2. TDD per cycle, commit per cycle: git commit -m "Cycle N: <behavior>"
3. Feature complete: squash merge into main
4. Tag the trace: git tag trace/<name> <branch-name>
5. Delete the branch. The tag survives.

I gave this to my padawan as a specification — the steering dial at “Tight.” I wanted the pattern implemented exactly. The reasoning was mine. The execution was his.

I asked him: “Before you start the task-tracker experiment, read this pattern. Tell me what is missing.”

He came back with a question: “What happens when a cycle discovers that the next test already passes because the previous cycle accidentally covered it? Do I still commit as ‘Cycle 3: confirm’?”

Good question. The pattern did not cover that edge case. I added: “Document it honestly as a confirm-only cycle. Do not force a fake RED-GREEN loop. The trace is about truth, not performance.”

That exchange is the master-padawan dynamic at its best. I design the framework. The padawan stress-tests it. I adjust. The result is stronger than either of us could produce alone.

The trace tag pattern became the backbone of every experiment from Chapter 04 onward. A reviewer can open any repo and run git log trace/<feature> to see the complete reasoning chain. Main shows what shipped. Trace shows how we got there.

The difference between trust and verification:

  • Trust: “The AI wrote the code, it compiles, the tests pass.”
  • Verification: “I can see the test that failed first, the code that made it pass, and the refactor that cleaned it up.”

Trust is necessary. Verification is better.

Repos: