63 Posts Shipped After I Stopped Working From Memory

In March 2026 I had three half-written posts. By May the count was 63 shipped.

The drafts folder in March held three posts in various states of half-doneness. One was a “quick post” started over breakfast. One was an “I should finish this” piece from two weeks earlier. None shipped that month. By 2026-05-15 the published count was 63 and the drafts folder was empty.

The change was not “I tried harder.” It was a 5-state machine that lives on disk, not in my head. The pattern below names what shipped, what got cut, and the four ADHD-specific rules that keep the state machine intact under cognitive load.

TL;DR

Content has five states (IDEA, OUTLINED, DRAFTED, GATED, PUBLISHED) and each lives in exactly one home on disk. Transitions are atomic. One active draft at a time. 90-minute writing time-box max. Writing and editing happen in separate sessions. Pillar check gates entry to OUTLINED. Result on this site: 63 posts shipped in 60 days.

Three half-written drafts was not a discipline failure. It was a state-machine failure.

ADHD working memory caps at roughly 3-4 items under cognitive load. Holding “what state is post A in” plus “where did I leave post B” plus “what idea for post C” plus “what am I writing now” exceeds the cap. One thread drops silently, usually the one that would have been your best post by next week.

The reflex when this happens is to blame execution. The reality is the system asked the brain to do something the brain cannot do. The fix is structural: move the indices out of working memory and onto disk, where each post’s state is one file at one path, and the brain only needs to remember “go look at the drafts folder,” not “what state are my 3 posts in?”

Three concrete symptoms of the working-memory-as-index failure (look for these in your own workflow):

1. You can name the topic of every in-progress post but not where each is in your process. State has fallen out of memory; topic stuck around because topic is one item, state was four.
2. You open a draft and don’t recognize the argument. Past-you outlined it but the present-you’s mental model of the post has drifted. Without an externalized outline you cannot diff present-vision against past-outline.
3. You finish a draft, get distracted, come back, can’t tell if it’s actually done. No structured gate; the “done” state is a vibe, not a file flag.

If you nod at all three, your state machine is implicit. Externalize it.

“Just push through and finish them” is exactly what failed for six months before this

The reflex when a drafts folder fills with abandoned threads is to allocate a focused weekend to “finally finish them.” This fails for ADHD operators because the weekend hits the same working-memory ceiling that produced the half-drafts. Drafts get reopened, re-read, partially edited, then abandoned again — same cap, same outcome.

Other failure modes I tried before externalizing the state machine:

• Pomodoro on each draft in rotation. Same cap problem; rotation forces context-switching, which costs the most under ADHD executive load. Output: fewer half-drafts, same zero shipped.
• Set a public deadline. RSD-adjacent failure mode: the deadline becomes pressure that triggers avoidance, not motivation. Output: missed deadline, more half-drafts.
• Hire an accountability partner. Works for the appointment slot itself; collapses on the days between. Cost-per-shipped-post much too high.
• Just write longer drafts. Word count is not the bottleneck; state-tracking is. Adding more body text to a draft you cannot find next week makes the problem worse, not better.
• Switch to a different editor / tool. Tool churn is procrastination disguised as setup. The state-machine logic is not in the tool.

What compounds the failure: each abandoned draft adds entropy. By draft 3, opening the drafts folder feels like an indictment. The folder becomes a place to avoid, which makes shipping anything from it harder. Three half-drafts in March 2026 was not a coincidence; it was the predictable end-state of running the state-machine in working memory.

The 5-state SOP fixes this at the storage layer. Each draft has exactly one home at one path. Opening the drafts folder shows zero or one in-progress files. The folder cannot be an indictment of three abandoned threads because there cannot be three threads.

The mechanism: 5 states, 1 home per state, atomic transitions, 4 ADHD-specific rules

The state machine has five states. Each state has exactly one home on disk. A piece of content lives in exactly one home at a time; when it moves, the prior home empties. The atomicity is load-bearing: without it, working memory has to track which copy is canonical, exactly the index-in-head problem this exists to fix.

State	Home on disk	Exit criterion
1: IDEA	chudi-blog/ideas.json (one-line capture)	Ratified as “I will actually write this” -> State 2; ideas not ratified within 30 days are archived (not deleted)
2: OUTLINED	chudi-blog/drafts/<slug>.md with frontmatter + section headings only	Outline passes self-review (hook + 4-6 H2s + original-data claim named)
3: DRAFTED	Same drafts/<slug>.md with body filled	Complete end-to-end + em-dash-free + answers the capsule test
4: GATED	Same draft, review: true flag in frontmatter	Zero gate violations from /blog-seo-gate + /blog-body-framework + voice-DNA check + original-data verification
5: PUBLISHED	chudi-blog/content/posts/<slug>.md (draft removed from drafts/)	Live on chudi.dev; cross-posted; tracked in posted.json

The atomicity is load-bearing. A post cannot be simultaneously in drafts/ and content/posts/. If disk shows both, one is stale and must be reconciled before any further editing. Without atomic moves, working memory has to track “which copy is canonical” — exactly the index-in-head problem the SOP exists to solve.

# State 4 -> State 5 transition is one filesystem move plus one frontmatter flip
mv drafts/post-slug.md content/posts/post-slug.md
sed -i '' 's/^draft: true$/draft: false/' content/posts/post-slug.md
# (No copy. The drafts file ceases to exist the moment the post is published.)

The four ADHD-specific rules that protect the state machine under cognitive load:

1. One active draft at a time. Never two posts in State 3 concurrently. The brain cannot sustain two narrative threads simultaneously. If a second post urgently needs drafting, the first moves back to State 2 (delete body, keep frontmatter and outline) or forward to State 4 (gate review).
2. Writing session time-box: 90 minutes max. ADHD attention has a peak window. Past 90 minutes, output quality drops faster than it looks from inside the session. The post that took 4 hours of session time is usually worse than the same post in 90 minutes.
3. Separate writing from editing sessions. Do not edit during State 3. Write the full draft, close the laptop, open it later for State 4 gating. Editing during writing engages the critical voice that kills the drafting voice; one session per mode, never both.
4. Pillar check before State 2. A post that cannot be assigned to a pillar (per content-pillar-portfolio: AI-Visible Web Architecture / Agent Tooling / Quant-Trading / ADHD-Engineering) does not enter State 2. This prevents the “I had an idea, I outlined something that fits no pillar” drift that produces unpublishable orphans.

These rules are not ergonomic suggestions. Each one fails in a specific way I have empirically hit before the rule existed. They are guardrails on the failure modes of the operator the SOP exists for: me, on a 3-item-working-memory budget, on a Tuesday.

The proof: 63 posts shipped, 0 drafts pending at audit, March-to-May trajectory

The chudi.dev content/posts/ folder held 63 markdown files as of 2026-05-14 audit. The drafts/ folder held 0 files. By 2026-05-15 (the day the third codex-driven post landed via this same SOP), the count was 66 published, still 0 drafts pending. The state machine empties drafts as fast as the operator can author.

Metric	March 2026 (pre-SOP)	May 2026 (SOP shipping)
Posts published	(mid-month count omitted; baseline before consolidation)	63 (audited 2026-05-14) -> 66 (after codex-driven posts D7, D7+1, D7+2)
Half-written drafts pending	3	0
Single-active-draft rule violations	observed weekly	0 in last 30 days
Posts that crossed all 4 gates (seo-gate + body-framework + voice-DNA + original-data)	discipline did not exist	every published post (63 of 63)
Median time idea -> published	indefinite	7-14 days per post when the slot is active

Two things this table does NOT prove:

• The SOP causes the shipping rate. I do not have a counterfactual. The SOP correlates with the shipping ramp but other variables (codex-to-blog skill, AI-assisted drafting, content-pillar clarity) compounded over the same window.
• The SOP is universal. It is calibrated to ADHD working-memory load specifically. A neurotypical operator might find the time-box rules overly tight or the one-active-draft rule restrictive. Adapt the rules to your own observed failure modes.

What the table does prove: the failure mode that produced 3-half-drafts-in-March is no longer the failure mode that produces 0-drafts-in-May. State has moved from working memory to disk, and the disk pattern has held under real load.

FAQ: 5-state content SOP

Five questions I get most often about the SOP, paired with self-contained answers. Each answer makes sense without reading the rest of the post. AI engines extract these capsules; humans skim them as a recap; both audiences served by the same shape. The fifth question is the one most operators do not ask but should.

Why exactly five states and not three or seven?

Three states (idea / drafting / published) underspecifies the gating step where most quality failures land. Seven states overspecifies and creates more transition friction than the working-memory savings provide. Five is the load-bearing minimum: idea capture, outline structure, body drafting, quality gating, and publication. Each state has a single exit criterion that the operator can verify without leaving the file.

What if I use Notion or Linear instead of files on disk?

The SOP works with any storage that supports atomic moves and per-state queries. Notion databases work; Linear’s status pipeline works. The load-bearing constraint is that “what state is this in” must be queryable in one click, not held in working memory. Filesystem markdown is just the lowest-friction implementation for a single-operator solo workflow.

Does the 90-minute time-box work if I am hyperfocused and the words are flowing?

Yes, even then. Hyperfocus produces output that feels brilliant inside the session but trends toward overwrought when re-read 24 hours later. The 90-minute cap forces a separation between the drafting voice (in the moment, generous, exploratory) and the editing voice (cold, structural, cutting). Both voices are needed; they cannot share a session without the editing voice killing the drafting voice mid-flow.

Can I batch multiple posts in State 4 (GATED) before publishing them?

Yes, with one caveat: gated posts in queue can stay there indefinitely without becoming stale, BUT each one consumes a slot in the publishing-cadence schedule. At 3-5 posts per 2-week window (per publishing-cadence codex node), a queue larger than 5 gated posts means the oldest will be stale by publication date. Keep the gated queue at 3-5 maximum; if you have more, ship some via /chudi-blog-deploy rather than letting them age.

How do I migrate from a messy drafts folder to this SOP without losing half-finished work?

Audit your drafts folder once. For each in-progress post: pick the ONE you will finish today; move the others back to State 2 (delete the body, keep frontmatter + section headings) OR archive entirely if you no longer believe in the topic. Set a 90-minute timer on the one you picked. Write to completion or fail honestly; do not edit during the timer. After timer ends, you have one shipped post (or one honest fail) and an empty drafts folder. The migration cost is ~90 minutes; the steady-state savings are weekly.

What to do next

Three actions, ordered fastest-to-slowest. The first runs in 5 minutes and surfaces whether the working-memory-as-index pattern is in your own workflow. The second runs in 30 minutes and is the lowest-friction adoption path. The third compounds over 60 days. Each is independent; pick whichever matches your state today; the others wait.

1. Open your drafts folder right now and count the in-progress files. If the number is 0 or 1, you have the SOP discipline already; the rest of this post is reinforcement. If the number is 2+, you have the working-memory-as-index pattern, and the migration steps from FAQ question 5 apply.
2. Run the AVR framework against your content pipeline. The framework I shipped at chudi.dev/framework covers AI visibility; the pillar-mapping pattern surfaces whether your content is on-brand. The citability.dev scan is the testing surface for the visibility side; the pillar-check rule in this SOP is the testing surface for the brand side.
3. Adopt the 90-minute writing time-box for the next 4 posts. Track output quality (re-readability after 24 hours, gate-pass rate, time-to-publish). If the numbers improve, the time-box earned its keep. If not, the failure mode is upstream of the time-box and worth investigating separately.

The harder version of this work is the 4 ADHD-specific rules above. Externalization is the easy part; the rules are the discipline that protects the externalization from the working-memory drift that produced 3 half-drafts in the first place.

---

Drafted from codex node content-sop-chudi (confidence: inferred) on 2026-05-15 via /codex-to-blog-draft v2.2. voice-dna.json not yet populated (D5 of chudi-dev-autoblogging-phase-1-plan); voice fidelity is approximate. All hook + results + gate data sourced from the codex node body (zero [FILL] anchors required this time).