Operating · Lesson 16 — Plan-mode discipline
O16Operating
Operating · Lesson 16● live

Plan-mode discipline

When to skip Plan, when to triple it, the exit ritual.

16 min read · 30 min applyprereq: Foundations 10 (first plan-mode session)

What plan mode is for

Plan mode is the discipline of writing down what you’re about to do before you do it. With agents, that means: agent reads the context, proposes the steps, names the rollback path, and waits for human approval before any tool call that mutates state.

Plan mode is NOT a status update mode. NOT an exploration mode. NOT a way to ask “what should I do.” Plan mode produces a plan that is going to be executed — the seriousness comes from the commitment.

The mistake most operators make: plan mode for everything OR plan mode for nothing. Both are wrong. Plan mode is a depth dial — none / light / deep — matched to the task. The threshold logic in this lesson is what turns the dial honestly.

The plan-depth ladder

Match the depth to the task. Each rung has a different time cost and a different failure mode it prevents.

DepthWhenTime costOutput shape
NoneEffort < 30 min, ≤ 1 file, fully reversible0 minJust do the work.
Light30 min – 4 hours, 2-5 files, reversible5 min~150 words: contract row, steps, first action, rollback, out-of-scope.
DeepMulti-day, multi-stakeholder, irreversible side effects, decisions upstream of steps30 min~400 words: decision required, info needed, stakeholders, steps, rollback, risk notes.
TripleOne-way door, organizational consequence, regulatory or legal exposure2-4 hours, often spread over daysDecision log + plan + risk register. Multiple specialists weigh in. CIPHER and APEX both review.

Triple depth is rare — once or twice a quarter for most operators. SBA loan decisions, patent filings, hiring decisions, irreversible architectural commitments. The cost of getting it wrong is high enough that the planning cost is trivial.

Five failure patterns

01

Plan-mode-for-everything

claim looks likeOperator hits Plan for every task, including 5-minute edits.
what’s missingPlan mode adds 2-5 minutes of overhead per task. For trivial work, the overhead exceeds the work. Plan mode becomes a tax on productivity, not a discipline that improves it.
the movePlan mode is for tasks > 30 minutes of effort OR > 3 files of impact OR irreversible side effects. Below the threshold, just do the work.
02

Plan-mode-as-status-update

claim looks likeOperator uses plan mode to ask "what's the state of X?" — no work intended.
what’s missingPlan mode is a planning tool, not a query tool. Using it to gather status produces a plan no one needs.
the moveStatus questions go in normal mode. Plan mode is for proposing work.
03

The plan that never exits

claim looks likePlan looks good. Operator iterates the plan another five times. Days pass. No execution.
what’s missingPlan mode produces analysis paralysis when over-used. Every iteration of the plan reveals a new edge case to handle. The plan grows; the work doesn't ship.
the moveExit ritual. Plan is approved when (a) the contract Done Means rows are nameable, (b) the first concrete step is identified, (c) the rollback path is named. Three checks. Approved or rewritten. No fourth iteration.
04

The plan with no teeth

claim looks likePlan is approved. Agent exits plan. Starts doing whatever feels right. Plan is forgotten.
what’s missingPlan that doesn't bind execution is a writing exercise. The agent had a plan; the agent shipped a different thing.
the movePlan output gets written to a file (`docs/plans/active/<contract>.md`). Sprint contract references the plan. Postmortem if execution diverges from plan without an amendment.
05

The skip-the-plan-because-it's-fast

claim looks like"This is just a small refactor, no need to plan." Three hours later, the refactor has touched 14 files.
what’s missingThe skip-because-fast judgment is wrong about half the time. Tasks that look small often have hidden surface area. Without a plan, the surface area is discovered live.
the moveIf you're not sure, plan briefly (5 minutes). The fast plan reveals whether the task is actually as small as it looks.

Pattern #3 (the plan that never exits) is the most insidious. Plans always have one more edge case to consider. The exit ritual is what stops the spiral.

The exit-the-plan prompt

Three checks. All three must pass to exit plan mode and execute. If any fail, revise.

Exit ritual
Run the exit ritual on this plan. Three checks:

1. CONTRACT ROW NAMEABLE? Which Done Means row in which sprint
   contract does this plan close? Cite by file path and row name.

2. FIRST CONCRETE STEP? What is the very next thing I do? Name
   it precisely — file to open, command to run, person to call.

3. ROLLBACK PATH? If this plan executes wrong, how do I revert?
   For code: git. For documents: version control. For
   communications: prepared retraction. For irreversible
   actions: there is no rollback — flag it as a one-way door.

If all three pass, exit plan mode and execute.
If any fail, revise the plan — don't execute against an
under-specified plan.

Stops analysis paralysis. The plan is ready when these three things are nameable.

The exit ritual is intentionally short. Most operators over-iterate plans because each iteration reveals new detail. The three checks ask: do I know what closes this? Do I know what to do first? Do I know how to recover? Three yes answers = ship.

Three plans, three depths

A real morning across three ventures. Patent reword (none), QC dirt-path fix (light), SBA loan repoint (deep). Same operator, three depths.

One operator, three tasks, three plan depths

The threshold logic in action. Inline / light / deep — matched to task complexity.

  1. operator

    I have three things this morning: (1) reword three sentences in the QC patent draft, (2) implement the dirt-path P1 fix on QC, (3) figure out how to repoint the SBA 7(a) loan from Hickory to Denver NC for MHG. Which need plan mode?

  2. agent

    Walking each through the threshold:

    (1) Reword three sentences in the patent draft. Effort < 15 min. Files: 1. Reversible: yes (git). → No plan mode. Just do the edit.

    (2) QC dirt-path P1 fix. Effort: ~2 hours (TDD rhythm: failing test, implementation, boundary cases, full suite). Files: 3-4 (tests/test_dirt_path.py, src/qc/fsm/perception/pair_window.py, possibly events module). Reversible: yes (git). Sprint contract: yes (Phase 0 retry contract Done Means row). → Plan mode, light. 5-minute plan: name the test, name the API, name the boundary cases, exit.

    (3) SBA 7(a) loan repoint Hickory → Denver. Effort: multi-week. Files: not code — application docs, lender comms, grant assignments, decision log. Irreversible: SBA timelines and lender relationship are slow to recover. Cross-domain: legal (CIPHER), MHG (SUMMIT), commercial RE (Sarah Cooley). → Plan mode, deep. This is the one that earns 30 minutes of planning. Multiple stakeholders, irreversible side effects, structural decisions about whether to keep the loan or open a new one.

  3. operator

    Light plan for the dirt-path fix. Five minutes.

  4. agent
    ## Plan: QC dirt-path P1 fix
    
    **Contract:** QC Phase 0 Gate Retry (memory/sprint-contracts/active.md)
    **Done Means row this satisfies:** "Dirt-path off_board outcomes fire on pair-window expiration"
    
    ### Steps
    1. Write failing test in `tests/test_dirt_path.py` — assert off_board fires when pair window expires without a landing event.
    2. Run test, confirm failure for the right reason (missing PairWindow.tick method).
    3. Implement minimum: PairWindow.tick(t_ms) returns OffBoardEvent for any throw past timeout.
    4. Run test, confirm green.
    5. Add boundary cases: bag-lands-before-timeout (no off_board), multiple-throws-independent-timeouts, exact-boundary timing.
    6. Run full `tests/test_pair_window.py` suite — confirm 14/14 green (10 existing + 4 new).
    
    ### First concrete step
    Open `tests/test_dirt_path.py` (does not exist yet) and write the first test.
    
    ### Rollback path
    If any test in the broader suite breaks: revert the implementation, keep the test (as known-broken), open a postmortem.
    
    ### Out of scope
    Front-cam integration, ArUco recalibration, v16 retraining.

    Ready to exit plan mode. Approve or rewrite?

  5. operator

    Approved. Execute. Now do the deep plan for the SBA repoint. Take the 30 minutes.

  6. agent
    ## Plan: MHG SBA 7(a) loan repoint — Hickory → Denver NC
    
    **Status:** Hickory site DEAD as of 2026-04-28 (Denver pivot). SBA 7(a) was Hickory-scoped per memory/projects/mile-high-golf.md.
    **Stakeholders:** Mike (CEO), Sarah Cooley (Ascent RE), SBA lender (TBD — was Hickory-area), Curtis Woodie, Olivia Merlock (GM).
    **CIPHER concern:** Lender relationship implications, timeline reset risk.
    
    ### Decision required upfront
    A. Repoint the existing SBA 7(a) application to Denver NC site
    B. Withdraw and re-apply with a Denver-aware lender
    C. Pause SBA path entirely; pursue alternative financing
    
    This decision is upstream of any plan steps. Without it, planning is premature.
    
    ### Information needed for decision
    1. Current SBA application status (filed? underwriting? approved-pending-site?) — Sarah
    2. Lender flexibility on site change (some accept, some require restart)
    3. Denver site lender preference (Lake Norman corridor lenders may differ from Hickory)
    4. Timeline cost of B vs A (re-application typically 60-90 days)
    5. Grant entanglement (Lincolnton TIP + Facade — likely lost; doesn't gate this decision but worth surfacing)
    
    ### Proposed plan steps
    1. Sarah call this week — get current SBA status + lender's stance on site change.
    2. CIPHER review — lender contract terms, what changes when site changes.
    3. Decision log at `07-Decisions/2026-MM-DD-sba-repoint-or-restart.md` — three-option SWOT, decision recorded.
    4. Action: execute A or B or C. Each has a separate sub-plan that opens once the decision is made.
    
    ### Out of scope (now)
    - DDI buildout rework (terminated with Hickory)
    - Lincolnton TIP/Facade (separate decision, likely dead)
    - Denver landlord LOI (separate sprint contract)
    
    ### Rollback path
    This is mostly information-gathering until step 4. Steps 1-3 are reversible. Step 4 is the irreversible commit — postmortem if executed wrong.
    
    ### Risk notes
    - SBA timelines are long; the 60-90 day cost of restart could push MHG launch.
    - Lender relationship in Hickory area may not transfer to Lake Norman lenders.
    - If Denver landlord meeting fails, this whole plan changes.
    
    ### Exit ritual
    - Done Means row in MHG sprint contract: "SBA 7(a) status known, repoint decision logged."
    - First concrete step: book Sarah call this week.
    - Rollback: information-gathering only through step 3.

    Ready to exit plan mode. This is the kind of plan that earns its 30 minutes — irreversible side effects, multi-stakeholder, decision required upstream of execution.

Prompt kit

Three prompts: threshold check, exit ritual, mid-execution divergence. Save in your CLAUDE.md.

The plan-depth threshold check
Task: <describe>

Walk the threshold:
- Effort estimate (minutes / hours / days)
- Files affected (1 / a few / many)
- Reversibility (full / partial / one-way door)
- Stakeholders beyond me (none / one / several)

Recommend:
- No plan mode (under threshold)
- Light plan (5 minutes — name steps, first action, rollback)
- Deep plan (30 minutes — full structure with decisions, risks,
  stakeholders)

Output the recommendation with the threshold reasoning.
The exit ritual
Run the exit ritual on this plan. Three checks:

1. CONTRACT ROW NAMEABLE? Which Done Means row in which sprint
   contract does this plan close? Cite by file path and row name.

2. FIRST CONCRETE STEP? What is the very next thing I do? Name
   it precisely — file to open, command to run, person to call.

3. ROLLBACK PATH? If this plan executes wrong, how do I revert?
   For code: git. For documents: version control. For
   communications: prepared retraction. For irreversible
   actions: there is no rollback — flag it as a one-way door.

If all three pass, exit plan mode and execute.
If any fail, revise the plan — don't execute against an
under-specified plan.
Mid-execution divergence check
I'm partway through executing the plan at <path>. Walk the
plan vs what I've actually done.

For each plan step:
- Done as planned
- Done with a deviation (describe)
- Skipped (with reason)
- Not yet done

If deviation > 30%, the plan is failing and a re-plan is needed.
If skipped > 0, those become postmortem-eligible if they were
load-bearing.

Output: continue / re-plan / amendment needed.

Apply this

30-minute exercise. Calibrate your plan threshold. Write one deep plan. Run the exit ritual.

Calibrate plan-mode discipline

Each step takes 5–10 minutes. Progress saves automatically.

0/5
  1. 01List 5 tasks you did this week. Walk the threshold for each — should you have planned, light-planned, or skipped?Honesty matters here. Most operators over-plan trivial work and under-plan irreversible work. Calibrate against your own pattern.
  2. 02Pick one upcoming task that earns deep planning. Write the deep plan.Use the structure: decision-required, information-needed, stakeholders, steps, rollback, risk notes. ~400 words.
  3. 03Run the exit ritual on the deep plan. Confirm all three checks pass before executing.If any check fails, revise. Don't execute against under-specified plans — that's the discipline.
  4. 04Save approved plans to docs/plans/active/<contract-slug>.md and reference from your sprint contract.Plans that don't bind execution are writing exercises. The contract reference is what makes them real.
  5. 05Mid-week, run the divergence check on any active plan. Catch drift before it becomes a postmortem.Drift > 30% means the plan was wrong, not that you executed badly. Re-plan, don't push through.
Operating tier · what's next

After this lesson