Stop using hundreds of tiny cards

Proposal·Blueprint·Card 271·Discussion

Stop using hundreds of tiny cards.

Write one proper document per workstream instead.

Raised by
Sam & Claude
Date
26 May 2026
Owner
Joint
Status
Awaiting board meeting
We’ve ended up with 200 cards because we’ve been working bit by bit. No human can hold that in one head.
Why this exists

The card model fragments thinking that’s actually joined-up.

Today, the Decision Queue holds 200 cards spread across 22 projects. Each card is a fragment — a thought, an idea, an open question. The Client Docker Template project alone has 140 cards. They’re not 140 different things. They’re 140 facets of one thing.

Humans don’t process fragments well. We need narrative to hold a picture in mind. Reading 200 cards is fatigue. Reading 12 documents is comprehension. Paul has the same problem. Sam noticed it today when the Course Development project showed only 3 cards even though we’d been working on the course for a week — the rest were scattered across other projects, invisible as a whole.

The synthesis act itself is where the value sits. Writing 80 cards into one narrative forces the writer to resolve incompatibilities that hide when the cards live separately.

The proof it works

The May 9 CEO brief.

On 9 May 2026 we wrote a single coherent document covering the whole new stack — principles, architecture, client journey, delivery model, skill library, billing, migration, open items. Twenty-two pages. An appendix proving every input was absorbed.

Both Sam and Paul read it once and had the full mental model. That’s the format we’re proposing for every workstream.

The plan

Seven steps. Repeated per workstream.

01Pick a workstream.

Client Docker Template is the natural first — everything else depends on it.

02Claude does a deep read.

All the cards for that workstream, plus the canon, plus what’s actually been built on guidancegate.com, plus the May 9 parent brief.

03Surface questions and contradictions first.

Claude comes back with the sharp questions Sam and Paul need to answer, and any conflicts between sources. Already done for Client Docker Template — 14 questions, 9 contradictions, ready to discuss.

04Board meeting answers the questions.

Sam and Paul sit, work through the list. Claude writes the workstream document — same format as May 9. Emailed as PDF. Also saved in the brain. Also a page like this one.

05Sam and Paul sign it off.

Read it. Lock it. Or send it back for changes. Nothing builds until it’s locked.

06Claude plans the build.

Says which subagents go and do what, in parallel where possible. Each subagent gets a child brief, scoped from the parent.

07Subagents build it.

Self-verify against the document. Playwright screenshots, test submissions, link checks. Three-retry cap then escalate. Report back when done.

What changes after

The dashboard becomes handleable.

Today

  • 200 cards across 22 projects
  • 140 fragments under Client Docker Template alone
  • Course work scattered across 6 different projects
  • Each card needs an individual signoff
  • Impossible to hold the full picture in mind
  • Paul cycles through them one by one

After

  • One card per workstream — roughly 12 in total
  • Each card represents a full brief document
  • Status: drafting · reviewing · locked · building · done
  • Paul’s 12-card ceiling becomes natural at this scale
  • Nothing dropped — every input cited in the brief’s appendix
  • One sign-off per brief, not per fragment
A note on this card

This is a meta card. It proposes ending the pattern this card itself is using. Treat it as the last card-shaped card on this topic. After greenlight, the next thing that lands on the dashboard for Client Docker Template will be one brief, not the 140 fragments there now.

StatusAwaiting Sam & Paul board meeting greenlight
View card 271 →