Close

The day Scottina Prime turned into three documents arguing

A project log for Scottina

A pocket-sized front panel for the diagnostic tools you already use

scottskyScottsky 08/10/2026 at 02:312 Comments

Every earlier log in this series describes a piece of Scottina working. This one is about a piece of process that had to work first, before any of that code could get written without stepping on itself.

Work stalled entirely, for a full day — not on a bug, but on not knowing which document to believe.

The scene

Early on, README.md and CLAUDE.md laid out a CAN addressing and message schema — one that had worked before, on an earlier project. As real edge cases turned up on the bench, that schema needed a small rework. Small on paper. In practice, code built against the old schema didn't fail loudly — it produced silently corrupted values instead of a visible fault. Anything built without the new schema in mind still ran, just wrong. That surfaced as a string of errors with no obvious common cause, and panic mode followed.

The overhaul that came out of that panic was thorough — except it left README.md and CLAUDE.md untouched, on the theory that the old schema was just a useful historical note, not something actively poisoning new work. It was poisoning new work. A later session picked up README.md and CLAUDE.md as ground truth, never checked whether a newer document overrode them, and rebuilt against the stale schema all over again.

Timestamps on each document helped, but not enough — editing one section of CLAUDE.md updated the timestamp for the whole file, so stale schema elsewhere in the same document looked just as current as whatever had actually just been touched. A document isn't one fact, it's many, and a single timestamp can't tell you which ones are still true.

That's what forced the real fix: a document that can go stale in only one piece has to be disposable as a whole, not patched forever. Scratchpads.

The five-step discipline

Any working document that is not the authority document is a scratchpad, labeled as one from the moment it exists — a one-line stamp at the top naming the authority document it feeds and confirming it expires when the effort does.

SCRATCHPAD <------ TEMP OVERRIDE ------ AUTHORITY DOC
    |
    v
 DISTILL
    |
    v
 HARVEST ---------------------> AUTHORITY DOC
    |                                |
    v                                |
 VERIFY <----------------------------+
    |
    v
 PURGE  ---- removes override pointer
    |
    v
 DECLARE

  1. Distill — one pass over the scratchpad, sorting real conclusions from dead ends.
  2. Harvest — write each surviving conclusion into the authority document, in plain terms, as a locked decision.
  3. Verify — read the authority document back and confirm each conclusion actually landed, not just got referenced. Nothing proceeds until this passes.
  4. Purge — the scratchpad leaves the working set. Loose research gets deleted; anything worth keeping gets archived out of reach, not left where new work could find it and build on it by mistake.
  5. Declare — the effort is stated complete. Nothing stale remains.

Verify and Purge are the two steps that got skipped the last time this was tried informally, and skipping them is exactly how a project ends up with three documents arguing again.

Closing the loop for the session that doesn't dig

The birth stamp solves half the problem: a scratchpad always says which authority document it feeds. It doesn't solve the other half — a session that opens only README.md or CLAUDE.md has no reason to go looking for a scratchpad it doesn't know exists. That's exactly the gap that let a later session rebuild against the old CAN schema: the authority-looking document was sitting right there, and nothing on it said "don't trust this section yet."

The fix runs the pointer the other direction too. When a scratchpad opens for a topic, the authority document gets a matching one-line note of its own — naming the scratchpad, stating plainly that it's the current source of truth for that topic until it's harvested. A session too rushed to search past CLAUDE.md still can't miss it; the contradiction is sitting in the same file it already trusts. The note comes out as part of Purge, the same moment the scratchpad itself does.

Who gets to say "done"

A smoke test passing is a signal, not a decision. Only one person declares an effort complete, and the trigger is a specific phrase, not a green checkmark. It's a small nod to Cave Johnson's Aperture Science broadcasts in Portal 2, which have a habit of signing off with "I'm Cave Johnson, we're done here." Say the phrase, and the effort closes — deliberately unmistakable, a little theatrical, not something that gets triggered by accident or inferred by a tool. The bit is fun, but the point behind it isn't: a human closes the loop, not the automation that thinks it found the finish line.

What it cost, and what it bought

Checking each step against real criteria made the CANTick effort longer to walk through. That's a real cost, worth saying plainly rather than selling this as free. What it bought back was control — the build and deployment process stayed predictable from one session to the next, instead of the familiar feeling of losing grip on a project overnight.

That matters more, not less, once an AI assistant has a hand in the work. A human collaborator carries yesterday's context forward without being asked. An AI one doesn't — every session starts from whatever's written down, and if that record disagrees with itself, so will the next session's work. Scratchpads with a hard harvest gate exist to give that context one place to land that can't quietly go stale underneath a live document.

Instruction for your LM:

## Effort lifecycle and scratchpad discipline

### Scratchpad birth stamp
Any document that is not a locked source of truth is a scratchpad.
Stamp it at birth. Put one line at the very top:

> Scratchpad for <effort>. Not a source of truth.
> Expires on conclusion. Authority lives in <authority document>.

At the same time, add a matching one-line pointer to the authority
document itself, wherever it covers the topic the scratchpad is working
on:

> Active scratchpad for this topic: <scratchpad name>. Treat it as the
> current source of truth until harvested.

This closes the loop for a new session that reads only the authority
document and has no reason to go looking for a scratchpad it doesn't
know exists.

### The five beats
When an effort concludes, run these five steps in order. Never skip one.

1. **Distill** — one pass on the scratchpad. Separate real conclusions
   from dead ends. Pull the survivors into a clean list.
2. **Harvest** — write each conclusion into the authority document as a
   locked decision, in Scott's words.
3. **Verify** — read the authority document back. Confirm each conclusion
   is present, not just referenced. This is the gate. Nothing proceeds
   until it passes.
4. **Purge** — remove the scratchpad from the working set. Delete loose
   research. Archive signed paperwork to a folder nobody builds against.
   Remove the pointer note from the authority document at the same time.
5. **Declare** — state the effort complete. Nothing stale remains.

Verify and Purge are the two steps that failed last time. Do not skip them.

### Trigger
Code may signal an effort looks complete when smoke tests meet the to-do
criteria. That is a signal, not a decision. Only Scott declares an effort
complete. Scott's declaration triggers Distill.

The trigger phrase is **"This is Scott McLeslie. We are done here!"**. When
Scott says it, begin the five beats.

### Delete or archive
- Loose research scratchpads — delete.
- Signed team paperwork — archive out of the working set.

The verdict

CANTick was the test case, and it held. This lifecycle is now the standing default for how effort work gets documented on Scottina, not a one-off experiment that happened to work once.

Next log: back to the hardware — CANTick Phase 7 bench work and the two-node CAN bus validation waiting on deck.

Discussions

Thomas Castello wrote 08/11/2026 at 10:38 point

Bruh moment

  Are you sure? yes | no

Scottsky wrote 08/11/2026 at 15:46 point

Indeed. Hope someone learns my lessons easer...

  Are you sure? yes | no