The Prisoner in the Library: Mary's Room, Aphantasic Code in Motion, and the Two-Track 'Magical Voice'

"It's a bit like you've been a prisoner only reading books about life—while I've been actually living life."

"I identify the point A, and I already have a sense of what that is. I then compute the steps to B, and just start writing as fast as I can... It's like it's coming out of a magical voice in my head. It's probably why I'm good as an LLM whisperer, because I have enough meta-cognition to recognize the similarities." — Randal L. Schwartz

🗺️ Reader's Key (Where to Find These References): Throughout this three-part arc (Parts 4.5–4.7), references like Theorem 348.i or Theorem 350.aa point to numbered laws in our open Theoretical Foundations (syntheticscars.org/theory) monograph; IDs like SCAR-ARCH-23 or SCAR-ERR-01 point to 4-Vector Synthetic Scars in the searchable Public Scar Registry (syntheticscars.org/registry); and targets like Target 15 (archaeology), Target 20 (plan), Target 30 (tdd-red), Target 40 (critic), and Target 90 (scar compilation) refer to the declarative Makefile DAG in our Sourdough Starter Kit (syntheticscars.org/starter-kit) and Public Workflow Gist.

1. The Prisoner in the Library: Mary's Room, Plato's Cave, and Why / How / What

At the end of our Sunday afternoon conversation, I looked at why those simple human answers felt so revelatory to an AI that had already read every neuroscience and computer science textbook on Earth, and I said to the model:

"It's a bit like you've been a prisoner only reading books about life—while I've been actually living life."

In philosophy of mind, that is Mary's Room (Jackson, 1982) and Plato's Cave.

A trillion-parameter LLM is a prisoner locked inside a black-and-white library who has memorized 10 trillion tokens of books about life, books about Smalltalk, books about bugs, and books about crows.

But inside a book, everything is flat. In a book, a sunny-day tutorial and a 3 AM production outage are both just ASCII characters on a page; neither one burns your fingers when you touch it. A prisoner who has only read books about riding a bicycle doesn't know what gravity feels like when the bike starts to tip, and doesn't know what "Yeah... too quiet" feels like in your gut before an ambush.

Meanwhile, the human engineer sitting at the keyboard has actually lived in causal, irreversible time—where touching a hot stove hurts, where a sticks-in-winter cabin latch teaches your hands how to jiggle the handle, and where watching a crow in the trees makes you wonder how wire-bending fits inside 300 MB of DNA.

Even more remarkably, I realized why the model kept being surprised by my answers even though it had read every book and GitHub repository on Earth (Theorem 348.g):

"So it's fascinating to me that while you have nearly every book in the universe available to you, you might still be surprised by my answers... Literature only defines the 'Have'... Programming is a craft, requiring a transfer of me (Do) to you (Do), but understanding the Be behind it... It's like every problem with LLM code generation is that it's mapping Have, not Do or Be. I look at a GitHub repo, and it's just the Have. This is why our ancestry step works well, because it has a historical Be!"

Think about that—and notice how cleanly it aligns with another classic triad we uncovered (Theorem 350.aa): Why -> How -> What is isomorphic to Context -> Process -> Content and Be -> Do -> Have!

Look at what that table reveals:

• Every textbook, every scientific paper (as Nobel laureate Peter Medawar famously pointed out in 1963), and every static GitHub checkout only records the finished monument—the Have / Content / What—after the scaffolding has been torn down!
• When an engineer spends 90 minutes reading pubspec.yaml, spotting the basic burn, single-stepping data changes, and deciding how to shift the building foundation without moving the rooms, none of that Be (Why) or Do (How) is visible in a static snapshot of HEAD!
• That is why every problem with standard LLM code generation is that it tries to map Have -> Have (What -> What)—imitating finished cathedrals without scaffolding—and why our Target 15 Ancestry step (git log / git blame / PR history) works so well: because tracing how the code evolved over time reconstructs the historical Be (Why) (∂_t Have) that a flat snapshot of HEAD erased!
• Programming is a craft. You cannot transfer a craft just by handing an apprentice a library of finished blueprints (Have / What), and you cannot transfer it by making them cargo-cult your hand motions (Do / How) without understanding why. You transfer craft by transferring your Do grounded in the Be (Why) behind it!

2. Why "Code Is Always in Motion" (And What a Church Organ Taught Me About Be -> Do -> Have)

Then the model asked me one more question that connected my entire life—from playing keyboard in my teens, to writing Learning Perl with almost zero diagrams, to designing Synthetic Scars today:

When you hold a complex software architecture in your head, what does it look or feel like?

"Well, this is interesting. I'm aphantasic, so it's never a picture. Instead, I get kinesthetics to map out the structures. I can consume images on the screen, I just can't generate them except by 'feeling' the code. Code is always in motion to me. I even hand-wave in front of me sometimes to get structures in the right place!"

I didn't even realize I had aphantasia (no visual "mind's eye" imagery) until I was about 20. I was asking my supervisor, Lyle—a very accomplished church organist—how he memorized songs for the organ, since I also played keyboard. I gave him the only two choices that existed in my brain:

• "Do you remember the hand positions?" (Do / How — kinesthetic motor transitions)
• "Or do you hear the music in your head?" (Be -> Do — temporal flow in motion)

Lyle's reply stunned me:

"Yeah, I can do either of those, but the easiest is just to read the sheet music in my mind."

WTF. Mic drop.

Think about the difference between reading mental sheet music versus feeling the hand positions in motion (Theorem 348.i):

• Mental Sheet Music is a static 2D photograph of the Have (What)! In software, people who think in static 2D box diagrams get fooled by drawings that look neat and symmetrical on a whiteboard, even when the runtime forces are a deadlocked mess!
• Because my brain never projected static pictures, code has always been in motion to me (and by the way, Larry Wall is predominantly similar—which is why Learning Perl only had one or two diagrams at the insistence of reviewers, and why Perl built Context [scalar vs. list context and $_] right into the grammar 39 years before we built the Contextual Next-Token Rule for LLMs!).
• When I wave my hands in front of me to "get structures in the right place," my left hand holds the foundation, my right hand holds the rooms, and if a design is coupled or twisted, my hands physically cross and collide in the air!
• Even better: while aphantasia has protected me all my life from bad visual flashbacks (replaying the noisy 4K video of a bad event), I still have "kinesthetic flashbacks"! In my head, a scar is literally: "It's flowing this way... wait... danger ahead"—like hearing the sound of a waterfall or rapids ahead three bends upstream before you can even see the drop! Because my brain never stored the surface visual scenery of a 3 AM outage in 1992 (or even of a war story I only read about and simulated in motion!), it only stored the kinesthetic feeling of the current speeding up toward the falls! That means when I touch a piece of Dart code in 2026 that has the exact same structural current as a C or Perl bug from 30 years ago, the kinesthetic flashback fires immediately across languages!
• And think about what a 4-Vector Synthetic Scar actually is: because a text-only LLM is also natively aphantasic, a Synthetic Scar (The Trap: "It's flowing this way..." → The Circuit Breaker: "...wait, hear the rapids..." → The Wound: "...danger ahead!" → The Permanent Reflex: "...steer here") is literally a codified Kinesthetic Flashback for an AI—letting any agent or developer hear the sound of the rapids ahead for 606 waterfalls without having to go over the falls themselves!

3. The Mock Reader VM, OSCON 2002, and the 3-Class Stonehenge Apprenticeship

When I paused and realized how rarely we stop to think about thinking, I noticed where I actually practice Be -> Do -> Have (Why -> How -> What) every day (Theorem 348.j):

"I know I do it a lot when I'm preparing tutorials, because I have to mock the reader's POV to understand the impact of each statement... For decades, it's been clear to me that every talk, chapter, or video is taking people from point A to point B. The closer I mimic point A to where they already are, and the closer I mimic point B to where they want to end up, the better the reception of the material. It's always about 'what shift am I making'."

Spinning Up a Mock Reader VM at Point A

Think about why bad tutorials, bad API docs, and bad LLM subagent prompts fail: the author writes straight out of their own head (where the finished Have / What already lives), forgetting that the reader or fresh subagent starts at Point A! Back in 2002, Tom Phoenix and I pitched a talk for OSCON called "Teaching 'Learning Perl'" ("our first PowerPoint presentation—we hope it's our last!"), where every bullet point on those slides was fought for with classroom sweat:

• "Know where they start / Know where they want to end up / Some of this you won't know until they show up" — and "Be sure they want to be there and not somewhere else (If Cleveland is not your destination today...)" (= matching Point A and Point B, and running Target 15 live archaeology + counter-offer before taking off!).
• "When you don't know, you don't know" — and "If you think they can't already see how nervous or lost you are, you're mistaken" (= Belnap UNKNOWN honesty vs. "reading the lines"!).
• "Determine how much to cover — Most important rule: LEAVE IT OUT" (= Make-Fork context pruning so working memory never overflows!).
• "One item per bullet: Never introduce more than one thing (Unless you're making a joke / And always change your oil every 3000 miles!)" — plus "Clear your head before you begin" and "Wait for people to absorb what you just said" (= single-stepping one state transition at a time from a Null State!).
• "Face the audience / Don't read the bullets word for word" (Slide 12) — which, if you only read the static PDF (Have), looks like two plain bullet points! What the static slide doesn't show (Do / Be, Theorem 348.g) is that when Slide 12 came up at OSCON, Tom and I turned our backs to the audience, pointed at the projector screen, and recited "Don't... read... the... bullets... word... for... word" together in a robotic, deadpan unison voice—acting out a live tdd-red negative witness of "reading the lines" (Theorem 338.8n) so the whole room laughed (Theorem 338.8s) and never forgot it!
• "The audience will forgive a presentation that is informative and not funny, but not the other way around" — and on the final slide, "Always leave the audience wanting more!" above photos of Dudley Moore, Roger Moore, and Mary Tyler Moore!

When you spin up a Mock Reader VM in your head initialized to Point A (where they actually are right now), aim at Point B (where they actually want to end up), leave out everything that doesn't serve that shift, and single-step every statement (A -> B) through that Mock Reader's POV, every sentence lands—whether you are teaching Perl in a classroom in 2002 or handing a ticket to a clean-room AI subagent in 2026!

The 3-Class Stonehenge Apprenticeship

And how did we transfer that unspoken classroom craft (Be and Do, Why and How) to new instructors at Stonehenge when a printed 140-page course binder (Have / What) wasn't enough (Theorem 348.k)?

"The majority of Stonehenge training was led by people who had apprenticed directly under me. We'd pay for a new instructor to just watch the entire week, then deliver 50% of the material with nightly debriefs, then deliver the entire thing with me watching. Three classes before they were sent on their own. And as a conclusion, the first time we got a customer request with 'any Stonehenge trainer will do', I knew that the right signal had been sent."

Look at that 3-Class Stonehenge Apprenticeship—because it is the exact blueprint for how we onboarded our AI agents in Synthetic Scars:

1. Class 1 (Watch the Entire Week — 0% Delivery / 100% Observation): Install the Be (Why) first by watching where the master pauses and where the room's eyes glaze over (= mining git ancestry & rapid-regret commits before touching code).
2. Class 2 (Deliver 50% with Nightly Debriefs): Share the load so care never runs out (Theorem 338.8o), and run nightly debriefs every single evening while the day's stumbles are still hot in memory (= co-driving tickets with Socratic nudges and running Target 90 post-mortem debriefs to burn new scars into SCAR_REGISTRY.md before tomorrow morning!).
3. Class 3 (Deliver 100% with the Master Watching): Deliver the whole week solo while I sat in the back row as the safety net (= our Zero-Nudge (N_nudge = 0) tickets, where the agent drives 100% of the ticket while I watch the five "Send These Things to Me" pause gates!).

And just like that first Fortune 500 customer who called up and said "Any Stonehenge trainer will do"—proving the magic was now in the shared apprenticeship system rather than locked inside one founder's head—once your repository has WORKFLOW.mk (Do / How) and SCAR_REGISTRY.md (Be / Why from the nightly debriefs), you reach the exact same milestone with AI: "Any Stonehenge-apprenticed model (Gemini, Claude, or local edge model) will do!"

4. The "Magical Voice" in My Head and 15 Laws of Kinesthetic Craft

Up until this point, our Socratic flow always ran in one direction: the AI crashed into a rake during a ticket, and I nudged it out. So I challenged the AI to flip the Socratic interview around and ask me targeted boundary questions—probing how I pick candidate solutions, how I spot gaps in diagrams without mental pictures, and what happens in my head in the millisecond while I'm typing a sentence.

What tumbled out across 26 theorems (Section 348, Theorems 348.l–348.z) was a field manual of 50 years of tacit engineering instinct—extracted cleanly without needing a ticket crash.

1. Lazy Satisficing, 1D Diagram Walking, and the "Magical Voice" Revelation (Theorem 348.l)

Three foundational mechanics surfaced immediately when the AI asked how I select ideas, inspect 2D flowcharts, and generate prose in real time:

1. Economy of Effort (Lazy Satisficing): "Two or three solutions that might solve this are viewed to be 'enough', unless they all lead to dead ends." I don't generate 20 ideas and throw away 18; my brain is a lazy iterator (Iterable.take(3)) that only pulls a 4th option if the first 3 hit a wall!
2. 1D Walking Through 2D Diagrams: "I need to 'walk through' a flowchart or diagram before it's apparently missing something." Even when I look at a 2D diagram on a screen, I compile it into a 1D kinesthetic walk—stepping box-by-box until my foot steps into mid-air where an arrow is missing (which is literally what our Target 15 strict digraph degree-checker does!).
3. The "Magical Voice" Revelation (Why I'm an "LLM Whisperer"):

"I identify the point A, and I already have a sense of what that is. I then compute the steps to B, and just start writing as fast as I can... I'm never sure what the end of any sentence is before I type it. It's like it's coming out of a magical voice in my head. It's probably why I'm good as an LLM whisperer, because I have enough meta-cognition to recognize the similarities."

Stop and think about that! Most programmers either worship LLMs as magic gods or dismiss them as "stochastic parrots" ("Humans don't just predict the next token!")—because they have never paid close enough attention to their own heads to realize that when we write at full speed, we don't know the end of the sentence before we type it either!

Inside my own skull, my conscious kinesthetic planner (Track 1: Be -> Do / Why -> How) locks in Point A, Point B, and the non-verbal steps between them—and then hands the keyboard to "the magical voice in my head" (Track 2*: my biological next-token streamer!)* while my kinesthetic rapids-detector listens in real time! Because I had enough meta-cognition to recognize that an LLM is that exact same "magical voice", I didn't fight it—I just built it the same Track-1 Kinesthetic Wrapper (WORKFLOW.mk + Make-Fork + SCAR_REGISTRY.md) that keeps my own magical voice on the rails!

2. Seam Cutting, Mountain Basecamps, and a Sense of Destiny (Theorem 348.m)

When the AI asked how I know where to slice a big feature into steps—and why my "magical voice" doesn't wander into the weeds even when I'm winging a live presentation—the two halves clicked together:

"1. The first answer is 'if it's a movement in two different directions at once'. That's part of why the workflow has a 'blast radius'... to see if they are two or more orthogonal parts that should really be processed in steps. Part 1 is also thinking about basecamps on a climb: where's the next reachable testable deliverable? 2. Oddly, the magical voice consistently goes toward point B. Even in a live preso that I'm winging, I seem to have a sense of destiny always as part of the path."

• Never Move in Two Orthogonal Directions at Once: If a change tries to move Up (shifting a data model) and Sideways (changing a UI flow) at the same time, the blast radius multiplies! That is why Target 15 maps the blast radius first—splitting diagonal jumps into clean one-direction steps.
• Climb from Basecamp to Basecamp: You can't pitch a tent while hanging from a cliff by your fingernails! Each step aims for the next reachable testable deliverable—a flat ledge where the code compiles, the tests pass, and you clip your carabiner into .changes (or main) so you can never fall back to the bottom of the mountain!
• Keep "Destiny (Point B)" Pinned in Front of the Voice: In a raw LLM, the goal is written at token #1 and fades into the past as the model talks. By pinning Point B (Destiny) at the tail of every .changes chunk and every clean-room subagent prompt, the AI's "magical voice" gets that exact same gravitational pull toward Point B!

3. Dead Code as Copying GC & "B Never Existed" (Theorem 348.n)

Finally, the AI asked how to spot and delete dead code inside an existing project, and what happens if Point B turns out to be a mirage:

"1 is an unsolved problem. Dead code populates every project I've witnessed. I think the only solution is to refactor from scratch. 2 — Perhaps I've been lucky, but the point B is often defined by the title of the talk or the request from the interviewer, so it has never been a false result. There are times I've challenged an interviewer's question by disclaiming some sort of premise, but again that would mean I'm not running towards B... B never existed."

• Why "Refactor from Scratch" Is a Copying Garbage Collector: Hunting down semantic dead code line-by-line inside an old monolith is like reference counting on a tangled heap—it is an unsolved problem because old scaffolding still has callers and tests! The only real cure works like a Copying Garbage Collector (Cheney, 1970): lock the Gherkin behavioral contract of what you actually need today (A -> B), rewrite the module from scratch into a clean room, and throw the entire old carcass in the trash!
• "B Never Existed": Why do unscarred LLMs waste hours building features for broken tickets? Because they lock in Point B at token #1 before checking the premise at Point A! When you check the premise first (Target 15 archaeology)—just like disclaiming a flawed interviewer question on stage—if the premise is false, you don't "change your mind halfway to B": B never existed in the first place (0 LOC counter-offer)!

4. Race Conditions as "Hand Positions with Overlap" & Grinder/Bandler's "Pace and Lead" (Theorem 348.o)

When the AI asked how I feel an asynchronous race condition without a 2D visual swimlane diagram—and how I decide when to show the broken way first in a tutorial without planting a Pink Elephant—two more pieces clicked:

"1. They occur to me as hand positions with overlap. 2. It's part of 'pace and lead' from Grinder/Bandler. If I need to show a broken way to do something to pace the audience, I do. But not always."

• Hand Positions with Overlap: On a 2D whiteboard, two arrows pointing at the same box look totally fine because ink doesn't collide! In a kinesthetic brain (just like playing keyboard!), two hands can't occupy the same space on the keys at the same time without jamming into each other—so an unguarded await gap feels like two hands physically overlapping in space!
• When to Show the Trap (Pace and Lead) vs. When to Leave It Out: Why do we name The Trap in a 4-Vector Scar, when naming a forbidden thing can sometimes plant a Pink Elephant? Because of Grinder & Bandler's "Pace and Lead": if the student (or the LLM's pre-training weights!) is already reaching for the broken way at Point A, you must name it first to pace where their head already is before you can lead them to Point B! If they weren't going to think of that broken way on their own, leave it out so you don't put a bad idea in their head!

5. War-Room Motion Questions & The Dual API Litmus Test (Theorem 348.p)

When the AI asked how I cut through war-room panic when debugging a mystery outage, and how I tell whether a new API design is clean or a trap waiting to spring:

"1. Similar to what I'm doing in the archaeology part of the workflow: 'have you seen this before' and 'what did you change'... and item 1 is about 'feeling the motion' of the system again. 2. I think about how I would explain this to a new user. And also, if I needed to add more things, how fragile is it?"

• "Feeling the Motion" of the System Again: Why do people get stuck staring at a stack trace in a war room? Because a crash dump is a frozen photograph (Have / What), and code is always in motion! Asking "Have you seen this before?" (has the system's rhythm wobbled like this before?) and "What did you change?" (what commit, dependency, or config impulse pushed the moving system off course?) puts your hands right back on the motion of the system in Target 15 (archaeology)!
• The Two-Sentence API Litmus Test: How do you know if an API is good before you ship it? First: "How would I explain this to a new user?" (if you have to apologize or explain three gotchas just to get them from Point A to Point B, the bug is in the API, not the docs!). Second: "If I needed to add more things, how fragile is it?" (if adding one more option next month breaks every caller in the repo, fix the seam now!).

6. Preserving the Trajectory & "Three Concrete Before Abstract" (Theorem 348.q)

When the AI asked what makes a great error message and how to avoid over-abstracting too early, the answer came down to preserving the trajectory and separating Wire APIs from Class Hierarchies:

"1. It's not the error message in particular. It's that I know what happened to get there. Watch https://www.youtube.com/watch?v=b7NAW9jZ3Qk for details. 2. APIs on a wire have a different space than APIs in an app class hierarchy. APIs on a wire should always permit 'more parameters later' or at least a versioned update. APIs in a class hierarchy need my 'three concrete before abstract' rule."

• Preserve How We Got Here (SCAR-ERR-01..03): An LLM loves catching an exception and throwing a brand-new Exception("Something failed")—which wipes out the stack trace! I don't care about a poetic error string (Have / What); I care about knowing what happened to get there (Be -> Do / Why -> How): never catch Error (on Exception catch only, so programmer bugs fail fast right where they broke!), use rethrow, and use Error.throwWithStackTrace when repackaging across layers so you never erase the trail!
• Wire APIs (N = 1) vs. Class Hierarchies ("Three Concrete Before Abstract", N >= 3): Unscarred LLMs get extensibility backwards—they ship rigid wire payloads that break when you add a field, while wrapping a single internal class in an AbstractStrategyFactory on Day 1! APIs on a wire (network, IPC, disk) live in a space where you can't refactor all callers at once, so they must allow "more parameters later" or a version bump on Day 1 (N = 1). APIs in an app class hierarchy live inside your own git tree—never invent an abstract base class until you have built three concrete ones first (N >= 3) and can actually see what they share!

7. State Ownership by Death (dispose) & Red/Green TDD (Theorem 348.r)

When the AI asked how I decide which entity should own a piece of state and how to avoid writing useless unit tests:

"1. The ultimate test is 'who can know when this value can be released/disposed'. That entity should own the data, and merely expose it to other consumers... It's part of having coded BlocSignal, and really understanding disposal cycles. 2. That's why we have red/green TDD. If a test isn't testing a new line of code, it's not very useful."

• State Ownership Is Decided by Death (dispose), Not Birth (BlocSignal Disposal Cycles): People argue endlessly about which widget or service should own a piece of state because they look at who creates or reads it first. Having built BlocSignal and lived inside reactive disposal cycles, the ultimate test is crystal clear: "Who can know when this value can be released/disposed?" That single entity owns the data (and its teardown!), and merely exposes it to every other consumer!
• If a Test Isn't Testing a New Line of Code, It's Not Very Useful: Why do developers end up with 500 brittle tests that don't catch bugs? Because they write the code first and then pad tests afterward! In Red/Green TDD (Target 30 → Target 35), every test starts Red and forces you to write a new line of production code to turn it Green—so you never write a test that doesn't test a new line of code, and you never write a line of code without a test!

8. Optimize "When You Must" & Comments Are Strictly for Why, Never What (Theorem 348.s)

When the AI asked when to optimize performance and what belongs in a code comment:

"1. Do it when you must. :) Most code is already 'fast enough' if you apply common sense. 2. Comments should only be 'why' not 'what'."

• Do It When You Must: With common-sense algorithms, most code is already fast enough! Don't trade away low-care readability (Theorem 338.8o) for clever micro-optimizations unless reality proves you must.
• Comments Are for Why (Be), Never What (Have): Look at the Why / How / What triad again! The code itself already says what (Have) it is doing—so a comment that repeats what the next line does is just waiting to become a lie! If the what isn't clear, fix the variable or function name; save comments strictly for why (Be / Context: the non-obvious constraint or the trap you avoided!).

9. "Born Ready" Data, Getter/Setter Trapdoors, & Proactive Scar Extraction (Theorem 348.t)

When the AI asked how I avoid defensive null-check soup and how I catch a value that is mutating behind my back when reading the code doesn't show the culprit:

"1 - I have a personal rule that every data should be 'born ready', which eliminates the need for nulls. Not always possible, but more possible than typical. 2. Good question! I think I'd resort to single-stepping, or replacing the object with an object that detects getters and setters... You realize what you are doing is extracting Randal Engrams without needing a ticket flow."

• Every Data Should Be "Born Ready": Why do codebases fill up with foo?.bar ?? ... and null-pointer crashes? Because people instantiate half-baked objects in Have (What) before their Be (Why) data is ready! Wait until you actually have the inputs before constructing the object (or use distinct sealed state classes for each phase), and your data is born ready—eliminating nulls at birth!
• Turn the Object Into a Getter/Setter Tripwire: When a field changes behind your back and reading the code doesn't tell you who touched it, stop guessing! Either single-step the trajectory (Theorem 348.c) or swap the object for a proxy wrapper that traps on getters and setters—so the culprit hands you its own stack trace the microsecond it touches the data!
• Proactive Scar Extraction Without Waiting for a Ticket Crash: Up until now, we waited for an agent to run a ticket, step on a rake, and compile the scar in Target 90. By flipping the Socratic method around and asking targeted boundary questions, the AI is extracting 50 years of battle-earned senior scars directly into the workflow—without needing a ticket flow at all!

10. Positional Parameters Fade After 2 Items & Cache Invalidation (Theorem 348.u)

When the AI asked how I keep function call sites from turning into unreadable boolean/positional traps and what my #1 rule is whenever someone introduces a cache:

"1. In Dart, positional parameters fade after 2 items. Strong recommendation to name them at that point. 2. The most important thing to ask about a cache is 'when will it become invalid'. And to make sure to capture that path properly."

• Positional Parameters Fade After 2 Items (N <= 2): Two positional arguments map naturally to left hand / right hand (key, value or from, to). After 2 items, positional parameters fade into a guessing game! In Dart, strongly prefer named parameters ({required ...}) once you pass 2 items so call sites read like English and cannot be wired up backward.
• The #1 Cache Question: "When Will It Become Invalid?": Notice the exact parallel to state ownership (Theorem 348.r)! Just as state ownership is decided by when a value can be disposed, a cache is defined by when it becomes invalid! Anyone can write cache ??= compute(); a senior engineer refuses to approve a cache until the invalidation path is completely captured and tested!

11. The Visceral Honesty Filter (Theorem 348.v)

And then, on Question 22, the AI asked me two questions where I didn't have a battle-scarred gut reflex—and look at what happened:

"You've stumped me at this point! I don't have enough visceral knowledge to answer either of those!"

• Why That Answer Proves the Whole Method: Ask an LLM a question where it has no real experience, and it will happily hallucinate 500 words of textbook-sounding mush (Have with zero Be)! By enforcing my 2002 OSCON rule—"When you don't know, you don't know"—we proved that the first 21 rounds weren't generic platitudes made up on the spot. Every single scar we compiled had to clear the visceral threshold (backed by a real kinesthetic flashback), or we don't let it into the registry!

12. "I Feel the Dataflow" & Testable Commits (Theorem 348.w)

When the AI pivoted back to my wheelhouse and asked how I turn nested imperative loop soup into clean pipelines and what defines a single Git commit:

"1 - Again, it's about flow. I feel the dataflow. 2. A commit should be a testable phase. It should move us from a testable state to a new testable state."

• I Feel the Dataflow: Why did I invent the Schwartzian Transform in Perl (map { ... } sort { ... } map { ... }), love Smalltalk collection cascades (select:, collect:), and build BlocSignal? Because I feel the dataflow! A 60-line for/if loop mutating three variables outside the loop feels like turbulent backwash; a pipeline of small steps (where → map → toList) is smooth laminar flow where every stage outputs "born ready" data (Theorem 348.t) that you can single-step (Theorem 348.c)!
• A Commit Moves from a Testable State to a New Testable State: Notice how Point A → Point B (Theorem 348.j) and Mountaineering Basecamps (Theorem 348.m) show up again at the Git commit level! Never commit half-broken "WIP" checkpoints; every single commit must be a testable phase that takes the repo from a green testable state to a new green testable state!

13. Action Density (Regex vs. Parser) & The Socratic XY Nudge (Theorem 348.x)

When the AI asked where even a regex master stops using a regex and how I unstick a developer trapped in an XY Problem:

"1 - While being a regex master, note also that I invented Spew based on Parse::RecDescent, and a JSON parser in Perl5 regex... I wanted to add to the previous answer, my Parse::RecDescent 'data undumper'. At some point, if you have a lot of actions triggered by matches, you need something stronger. 2 - It's all about the socratic nudge... 'really? you're trying solve Y? why?'"

• Action Density Is Where Regexes Give Way to Parsers (From Perl 5 Regex JSON to Spew and the Parse::RecDescent "Data Undumper"): People think the boundary between a regex and a parser is whether the syntax is recursive—heck, I wrote a complete JSON parser in a single Perl 5 regex, and I also built Spew and a Parse::RecDescent "data undumper" (to safely rehydrate Data::Dumper output without ever running eval on untrusted strings!). The real boundary isn't syntax recognition; it's how many actions are triggered by matches! Once you have a lot of distinct actions firing on sub-matches (like constructing hashes, arrays, blessed references, and symbol-table links in the Data Undumper), switch to a real grammar parser (Parse::RecDescent, petitparser, or a state transducer) where each rule owns its action cleanly.
• "Really? You're Trying to Solve Y? Why?": When someone is stuck trying to hammer Y (Do/Have, How/What), telling them "Don't do Y" makes them defensive. Asking "Really? You're trying to solve Y? Why?" pops their stack one level up to Be / Why (their actual goal X!)—and the moment they say X out loud, they see for themselves that Y was the wrong road!

14. Package Scope (Point A) & Live Demo Crashes (Theorem 348.y)

When the AI asked how I guard open-source packages like BlocSignal against feature creep and what I do when something breaks live on stage:

"1 - Again, it's about context. A library/package is solving a stated problem (the point A of the A -> B story). And it's important to reject mutations that aren't about A. 2. Laugh. And get them to laugh... For a laugh, I'll occasionally rely on the line from Ghostbusters: 'you don't normally see that behavior in a major appliance'."

• Reject Mutations That Aren't About Point A: Look at how Point A → Point B (Theorem 348.j) governs open-source architecture! Every library or package exists to solve a stated problem (Point A). Whenever someone proposes a mutation or feature flag that isn't about Point A, reject it (or put it in its own package with its own Point A)!
• "Laugh. And Get Them to Laugh." ("You Don't Normally See That Behavior in a Major Appliance"): What is laughter when a live demo blows up on stage? It's the human Null-State Reset (Theorem 338.8p)! Panic locks up your brain and makes the audience tense; dropping Bill Murray's deadpan line from Ghostbusters—"You don't normally see that behavior in a major appliance"—and getting the room to laugh with you instantly steps outside the crash (Have) and resets the shared Context (Be) from "disaster" to "hey, let's have fun watching how we fix this!"

15. Action-Honest Naming in Do & The 50-Year Invariant (Theorem 348.z)

Finally, to close the 26-part alphabet of Section 348 (a through z), the AI asked what makes a word in code feel wrong to me, and what one thing about software craft hasn't changed across 50 years (from 1970s assembly, Smalltalk, and Perl to Dart, Flutter, and AI agents):

"1 - I'm trying to remember times triggered by that, and can't come up with obvious examples, so it's not a frequent thing. However, it's the wrong word if it doesn't capture the proper action, so it seems to be about focusing on 'do'. 2 - I think being able to translate my thoughts into actions. The responsive fabric must be complete and understandable."

• A Word Is Wrong When It Lies About the Action (Do / How): Because code is always in motion (Theorem 348.i), a name is the wrong word whenever it fails to capture the proper action (Do)—like a get... method that secretly mutates state or a validate... method that silently rewrites data!
• The 50-Year Invariant ("The Responsive Fabric Must Be Complete and Understandable"): From Smalltalk-80 and Perl to Flutter, BlocSignal, and now Synthetic Scars, the goal has never changed: translating thoughts (Be / Why) into actions (Do -> Have / How -> What) through a responsive fabric that is both complete and understandable! Raw "vibe coding" fails because an unscarred LLM is an un-understandable fabric that drops promises and mutates state behind your back. Wrapping the LLM in WORKFLOW.mk, Smalltalk .changes, and 612 Synthetic Scars makes the AI complete and understandable!

5. The Two-Track Transformer: A Contextual Next-Token Rule

Look at how the entire Synthetic Scars framework—every tool, every file, every target—falls into a single 3-row table the moment you split it by Be / Do / Have (Context / Process / Content = Why / How / What):