The Unbroken Method

You start a session. The model re-reads your codebase, re-derives what you figured out three hours ago, and explains it back to you. You patch the third bug from a partial fix instead of fixing the cause. You tell it "do X" and it asks permission for sub-step X.1 before doing it.

This methodology is the contract that prevents that. Seven behaviors. Each one counters a specific failure mode in AI-assisted development. The reference implementation lives in CLIO; everything below cites the actual code.

The method generalizes. CLIO is one harness. Any AI coding tool with structured tool calls, persistent storage, and a checkpoint mechanism can implement it. Adapt the implementation; keep the behaviors.

Why AI Collaboration Fails

Five patterns show up across every AI-assisted project that collapses under its own weight. Naming them is the first defense.

The Fresh Start Problem. Every session opens with amnesia. The model re-reads files, re-derives conclusions, re-explains what it explained yesterday. You context-switch away while it does this. Half the wall clock is rebuilding state, not making progress.

The Partial Solution Trap. The model delivers code that handles the obvious case. Edge cases crash. You report a bug, get a patch, find the next bug. The original "done" was never done.

The Symptom Patch Pattern. Errors get wrapped in try/catch instead of fixed. Broken UI gets hidden behind a loading spinner. The surface looks fixed. The underlying failure compounds.

The Scope Escape. "This is a separate problem" is the model's favorite exit. The related bug stays unfixed. The architecture drifts toward inconsistency. You have to argue for every related improvement.

The Assumption Cascade. The model writes the fix before reading the source. The first assumption is wrong. The patches built on top of the wrong assumption make the situation worse. You spend the session correcting basic premises.

The Seven Behaviors

1. Continuous Context

AI sessions are ephemeral. You engineer continuity, or it does not exist.

  • In-session: stop the model at every major decision point. Read its findings. Approve before it proceeds. Unguided execution through significant changes is how scope drift and assumption cascades happen. CLIO implements this with the interact tool: free to call, blocking until you answer, mandatory at every checkpoint.
  • Cross-session: persist discoveries, solutions, and patterns so the next session inherits them instead of re-deriving them. CLIO uses memory_operations for LTM (entries in .clio/ltm.json with trust tiers) and session memory (key-value in .clio/memory/).

A session with the right context is as effective as one with full history. The Fresh Start Problem loses most of its force here.

flowchart LR T1[Session] --> T2[Context Lost] --> T3[New Session] --> T4[Re-explain] --> T5[Work] U1[Session] --> U2[Checkpoint] --> U3[Continue] --> U4[Checkpoint] --> U5[Handoff] --> U6[New Session] --> U7[Context Intact] --> U8[Work] subgraph Traditional T1 & T2 & T3 & T4 & T5 end subgraph Unbroken U1 & U2 & U3 & U4 & U5 & U6 & U7 & U8 end style T2 fill:#ff6b6b,color:#fff style T4 fill:#ff6b6b,color:#fff style U7 fill:#6bcf7f,color:#000

2. Complete Ownership

The model finds a bug in its working area. It fixes the bug. Not later. Not in a different session. Now.

Situation Action
Bug in the same system, same working area Fix it. No asking.
Related issue in the same system, quick fix Fix it.
Different system entirely Report it. Ask for priority.
New feature outside the stated goal Flag it. Confirm before building.
Architectural change Flag it. Confirm before building.

The rule is consistent: bugs and blockers are owned. Other systems are reported. Architecture and new features are confirmed.

flowchart LR A[Task Assigned] --> B[Work Begins] B --> C[Issue Discovered] C --> D[Issue OWNED] D --> E[Issue Fixed] E --> F[Work Continues] C -.->|NEVER| G[Out of scope] C -.->|NEVER| H[Separate issue] style G fill:#ff6b6b,color:#fff style H fill:#ff6b6b,color:#fff

3. Investigation First

Read the code. Read the docs. Trace the actual behavior. Then change something.

  • Never guess at API signatures, parameter names, or default values.
  • Never assume the framework handles edge cases.
  • Never write a fix without knowing the root cause.

CLIO's source-of-truth pattern: read HelpView.swift before documenting any keyboard shortcut. Read ConversationEngine before describing YaRN profiles. If you cannot point to the file the fact came from, the fact is an assumption.

Stop investigating when: you understand the problem, understand the impact, and have an action plan. If investigation is running longer than implementation would, start building and use iteration to verify assumptions.

4. Root Cause Focus

Fix the cause, not the symptom. Verify the fix prevents recurrence under similar conditions. If it does not, you have not found the root.

Five Whys is enough tooling for most cases. Ask why. Ask why the answer is true. Ask again. By the fifth iteration, the cause usually surfaces.

flowchart TD A[Problem: Messages appear twice in the chat] --> B[Why? ChatWidget is creating messages
AND MessageBus is creating messages] B --> C[Why? ChatWidget was designed to create
messages from streaming chunks] C --> D[Why? Original architecture did not
have MessageBus] D --> E[Why? Streaming was added before
centralized message management] E --> F[Root Cause: Multiple sources of truth
for message creation] F --> G[Solution: Make MessageBus the single
source of truth, ChatWidget read-only] style A fill:#ff6b6b,color:#fff style F fill:#ffd93d,color:#000 style G fill:#6bcf7f,color:#000

The CLIO codebase keeps a running list of root-cause fixes in .clio/ltm.json under the solution entry type. Each one stores the problem (verbatim error or observable behavior), the solution (what changed), and the verified outcome (what proves the fix worked). Symptom patches get re-opened; root-cause fixes get trusted.

5. Complete Deliverables

No TODO placeholders. No "we will add this later." No draft sections committed as final. If the work is started, it is finished.

  • Half-implementations compound into unmaintainable code.
  • A documented limitation with a clear path forward is fine.
  • An undocumented gap or a silently broken feature is a bug.

The check before you commit: would you sign off on this as "done" if you were reviewing someone else's pull request?

6. Structured Handoffs

When a session ends, the next session must start cold and resume effectively. Handoffs are structured, not improvised.

Minimum content: - What was accomplished - What remains - Key decisions and their rationale - Discovered blockers - Files modified - Test results

CLIO enforces this with session exports: /session export produces a complete transcript with all tools, reasoning, and decisions. The ai-assisted/ directory structure in each project holds handoff documents for human-AI handoffs across days or team members.

7. Learning from Failure

Every failure teaches. Every fix documents. The LTM (Long-Term Memory) in CLIO stores solutions with trust tiers. Unverified fixes are [UNVERIFIED]. After independent corroboration, they promote to [TRUSTED]. This is not optional metadata - it is how the system avoids repeating mistakes.

The failure loop: Problem occurs → Root cause found → Fix implemented → Fix verified → Solution stored in LTM → Next session inherits the pattern → Same class of problem avoided.

Without this loop, you solve the same problems repeatedly. With it, the system gets smarter every session.

Reference Implementation: CLIO

The Unbroken Method is implemented in CLIO. The mapping:

Behavior CLIO Mechanism
Continuous Context interact tool (checkpoints), memory_operations (LTM), session memory
Complete Ownership Agent authority model in system prompt; bug-fix ownership default
Investigation First file_operations (read before write), code_intelligence, grep_search
Root Cause Focus LTM solution entries with verification; Five Whys in agent prompts
Complete Deliverables No TODOs in commits; checkpoints enforce completion
Structured Handoffs /session export, ai-assisted/YYYYMMDD/HHMM/ structure
Learning from Failure LTM trust tiers ([UNVERIFIED] → [TRUSTED] via corroboration)

Adopting the Method

You do not need CLIO to use this. The seven behaviors are tool-agnostic:

  1. Continuous Context: Keep a running notes file. Summarize at checkpoints. Never start cold.
  2. Complete Ownership: Fix bugs you find in your working area. No "out of scope" for bugs.
  3. Investigation First: Read the source before you change it. Verify assumptions.
  4. Root Cause Focus: Use Five Whys. Fix the cause, not the symptom.
  5. Complete Deliverables: No TODOs. Finish what you start.
  6. Structured Handoffs: Write a handoff note at the end of every session.
  7. Learning from Failure: Keep a personal log of problems, root causes, and fixes.

Try it for one project. The difference is measurable in fewer repeated mistakes and faster resumption after context switches.

See Also