How DOS plans

When you ask DOS for something non-trivial, a specific loop engages before any real work happens. That loop is the Algorithm.

Why a planning layer exists

Language models are excellent at producing plausible output and terrible at producing auditable output. Left alone they skip requirements, fabricate sub-steps, and "finish" work that is halfway done. The Algorithm is the structural fix: it forces the model to declare, up front, what success looks like in atomic verifiable terms, then hill-climbs toward that target with checkpoints you can read.

Three things come out of this structure:

• Transparency — at any moment you can read the PRD and know what phase DOS is in, which criteria have passed, and what is still open.
• Testability — every criterion is a binary check, not a vibe. "Hero H1 renders under 60 chars" either passes or it does not.
• Recoverability — if a session gets interrupted, the next session reads the PRD and picks up where the last one left off.

The 7 phases in motion

Each phase announces itself in your terminal, writes state to the PRD, and moves on only when its contract is satisfied. That visibility is not decoration — it is the contract.

1. OBSERVE — Reverse-engineer the request. What was explicitly asked, explicitly not asked, implicitly expected. Pick an effort tier. Generate atomic ISC criteria. Select capabilities (Packs, agents, platform tools) to invoke later.
2. THINK — Pressure-test the plan. Premortem, risky assumptions, prerequisites. Refine or split compound ISC.
3. PLAN — Commit to a technical approach. For Advanced+ effort, enter plan mode and record it in the PRD.
4. BUILD — Preparation work. Scaffolding, dependency checks, environment setup. Invoke selected capabilities via the Skill or Task tool.
5. EXECUTE — The actual work. As each ISC passes, the PRD checkbox flips from [ ] to [x] in real time.
6. VERIFY — Independent check of every criterion. Evidence lands in the PRD's Verification section. No criterion is trusted until verified.
7. LEARN — Reflection. What would a smarter Algorithm have done? Learnings feed the reflection log so future runs improve.

The 5 effort tiers

Not every request deserves the same structure. DOS picks one of five tiers during OBSERVE based on SLA, scope, and implied quality bar.

ISC — atomic verifiable criteria

ISC stands for Ideal State Criteria. Each one is a single binary check describing part of the end state, written as a markdown checkbox in the PRD. The rule is atomic: if a criterion can fail in two independent ways, it is two criteria.

A compound criterion like "All hero section elements render correctly and are accessible" hides six independent verifications. The atomic version:

• - [ ] ISC-1: H1 renders at 64px on desktop
• - [ ] ISC-2: H1 renders at 40px under 768px viewport
• - [ ] ISC-3: CTA button has accessible name
• - [ ] ISC-4: Hero section contrast ratio is at least 4.5:1

Every criterion goes through a Splitting Test — a 4-check filter for "and/with" joins, independent failure modes, scope words like "all", and domain boundaries. Compound criteria get split until every one can be tested in isolation.

The PRD as system of record

Every Algorithm run creates a PRD at MEMORY/WORK/{slug}/PRD.md. That file is the single source of truth for the run:

• Frontmatter — task, slug, effort, phase, progress, timestamps.
• Context — what was asked, what was not, risks, plan.
• Criteria — the ISC checkboxes, updated as they pass.
• Decisions — non-obvious choices made during BUILD and EXECUTE.
• Verification — evidence that each criterion passed.

The model writes the PRD directly. Hooks only read it — PRDSync.hook.ts fires on Write/Edit of PRD.md and syncs frontmatter plus criteria into work.json for the Activity Dashboard. If you interrupt a run and come back later, DOS reads the most recent PRD to recover state.

Where to go deeper

The full Algorithm specification — every phase's mandatory actions, the Splitting Test in detail, the capability invocation contract, reflection logging — lives in the Reference section under the Algorithm spec page. Read it when you want to know exactly how the sausage is made, or when you are designing a Pack that needs to play well with Algorithm runs.