Plan

A plan is a single HTML file in the deck format that describes a proposed sequence of actions, each action being a discrete step with a defined deliverable and an explicit stop point, the whole composing a document that a human reads, approves, modifies, or rejects before any action is taken.

The plan is the seventh document format in the family. It joins the null (plain text with no measure), the leaf (LaTeX on A6 paper), the card (LaTeX on A5 paper), the text (plain text at 56 characters), the page (HTML rendering of the leaf), the note (LaTeX marginalia), and the deck (HTML on a dark field). All formats inherit from null. The plan inherits the deck's visual language — One Dark palette, JetBrains Mono, CRT scanlines, bordered panels — and adds the vocabulary of action: steps, stops, decisions, risks, and questions.

This document describes the plan and is formatted according to its own description.

A plan is a deliverable artifact. It is portable — it can be handed from one robot to another. It is repeatable — the same plan executed twice produces the same result. It is reviewable — Daniel can read it, understand it, and decide whether to proceed. It is a contract between the robot proposing the work and the human authorizing it.

The plan exists because robots have two friction problems. Static friction — the difficulty of stopping before starting — is improving. Dynamic friction — the difficulty of stopping once started — is not. The plan addresses both: it forces a stop before the first action, and it encodes stops between every subsequent action.

"Hey can I get a pasta carbonara?" Chef says "okay I made it." "Can I eat it? Can I have it?" "Oh, I didn't know you also wanted it. I thought you just wanted me to pretend to make it in the kitchen."

The plan is the carbonara served on a plate.

The plan inherits the deck's full visual specification: --bg: #0a0c10, --fg: #c8ccd4, JetBrains Mono at 13px weight 300, CRT scanlines, grid background, bordered panels with gradient headers, the One Dark palette in its entirety.

The plan adds five elements not present in the base deck format:

Every plan carries a status badge in its header:

DRAFT — proposed, not yet reviewed. APPROVED — Daniel said go. EXECUTING — in progress, steps being completed. COMPLETE — all steps done and verified. REJECTED — Daniel said no.

A plan in DRAFT status is a request. A plan in APPROVED status is a mandate. A plan in EXECUTING status is a record of what has been done and what remains. A plan in COMPLETE status is a receipt. A plan in REJECTED status is a lesson.

A plan contains, in order:

1. Header panel — title, author, date, status badge
2. Situation — what is the current state, why does this plan exist
3. Decision points — forks that need Daniel's input before proceeding
4. Steps — the ordered sequence of actions, each with a deliverable and a stop
5. Scope — what machines, files, or systems are affected
6. Risks — what could go wrong
7. Questions — what the robot needs to know

Sections may be omitted when empty. A plan with no risks is suspicious but not forbidden. A plan with no questions is confident but not prohibited. A plan with no steps is not a plan.

• Single self-contained HTML file
• No build step, no bundler, no framework
• No JavaScript except optionally a live clock
• JetBrains Mono only
• One Dark palette — no substitution
• The plan is the deck applied to action

The plan is not a proposal, a ticket, a spec, or a runbook. A proposal suggests without committing to steps. A ticket tracks without describing why. A spec defines the end state without describing how to get there. A runbook describes steps without requiring approval. The plan is all four: it proposes, tracks, defines, and describes, and it requires a human to say go before any step is executed.