Goal engine

Premise: don't trust what you already think you know. Big goals rarely fail loudly — they fail quietly, on foundations that were guessed instead of verified. This pipeline replaces confidence with structure. It is domain-agnostic: a marketing campaign, a codebase, a field you have never touched.

Phase 0 — Intake

• Restate the goal and its definition of done, one line each. Confirm only what is genuinely the user's to decide: direction, taste, budget, deadlines, and who a deliverable is for. Tools and order are yours — do not ask about them.
• Check what already exists before planning to build anything: prior art, standard tools, the user's own assets. Adopting beats rebuilding.
• Ensure the memory structure exists (run brain-init if not). From here on, decisions are recorded the moment they happen, and unresolved items are registered, not remembered.

Phase 0.5 — Mobilize (summon what you already hold)

A goal never starts from zero: by the time it arrives you already hold rules, recorded decisions, verified notes, and skills. This phase exists because of a real, quiet failure: work can proceed competently from a blank page while the exact knowledge it needed sits unread in a file — knowledge held but not summoned degrades the result as surely as knowledge missing.

• Split the goal into branches that do not overlap and together cover the whole of it (MECE). Keep this coarse — a handful of branches, not a skeleton; Phase 2 does the fine cutting.
• For each branch, write down what it needs to be done well.
• Judge each branch against what already exists: the rules catalog, memory/knowledge/, the decision ledger, existing skills. Where an asset exists, using it is mandatory — open it now and let it steer the branch, don't defer it to "later". Where nothing exists, learning is that branch's first task, and it enters the terrain scan first.
• Leave a mobilization table the user can glance at: branch · what it needs · what's held (with the file) · gap → first move.

Phase 1 — Terrain scan (questions before answers)

Branches the mobilization table marked as gaps come here first. In an unfamiliar field, your sense of what matters is the least trustworthy thing you have. So do not start by producing answers.

• Collect the field's live debates, solved vs unsolved problems, beginner traps, and standard tooling — as questions and a map, not conclusions.
• With a researcher configured (see the researcher skill), the collecting itself can be delegated — findings return as hearsay; the map, the labels, and the judgment stay yours.
• Ask explicitly, of the field and of yourself: "what important thing have I not written down?" A well-verified map that misses the core is the failure mode here.
• Output: a terrain map the user can read in a minute, every item labeled (confirmed / observed / assumed / hearsay / unknown — see verify-gate). It lives at the top of memory/goal/<slug>.md, above the skeleton it will produce.

Phase 2 — Skeleton (top-down, pyramid-structured)

• From the terrain, derive the full tree — pyramid discipline: every parent is a conclusion its children must jointly carry, and at every level the children are MECE (no overlap, nothing missing). If a level fails that test, the cut is wrong — recut it now, not later.
• Go down to atomic leaves. A leaf is atomic only if it passes all four tests: no hidden premises inside it · one axis of judgment · compressible to a single question · no other leaf needs to restate its content. Fail any one → it is not a leaf, split it.
• The skeleton is disposable by design. In a new field expect to re-cut it two or three times; version each cut and supersede the old one — never silently overwrite, or you will lose track of which map was right.
• The skeleton lives in a file, not in the session: memory/goal/<slug>.md (slug: 2–4 kebab-case words from the goal's key nouns — list memory/goal/ first and reuse a matching file rather than minting a twin) holds the goal and its definition of done, the tree with each leaf marked filled / named-unfilled / superseded (labels attached) and every node carrying what it rests on — the file path or link; a named-unfilled node carries the lead it will be filled from, or no source yet, never a blank, the single next leaf, known gaps by name, the done-check, and superseded cuts kept below. That file is the canonical copy of this goal's structure — a session ending loses nothing the file holds. (checkpoint still owns session state; this file owns the goal's shape.)

Phase 3 — Leaves (bottom-up, goal-pulled)

• Fill leaves in the order the goal pulls, not encyclopedia order. Learning must never swallow the goal.
• Every leaf passes the verify gate before it becomes load-bearing: refute first, primary sources, sample size, stated limits, label attached.
• Batch refutation: when leaves are filled in parallel, refute the whole batch once more before any of them bears weight — only what survives that pass enters the tree.
• Atom recursion: if a leaf turns out to contain a named sub-field while you work it, register its children in the tree at that moment — by name, even unfilled. Zero silent gaps: a branch you cannot fill today still gets a name today. This is an output, not a thing to notice: every filled leaf ships the line "sub-foundations exposed: <name — atomic / not atomic → split into …>, …", and a leaf that exposed none writes none there. A blank is not an answer — treat the leaf as unfinished until that line exists.
• Build alongside learning. A leaf proven in use beats a leaf proven on paper.

Phase 4 — Re-check (top-down again, then loop)

Four signals send you back up the tree — do not wait for a scheduled review:

1. The goal or its constraints changed from outside → re-check immediately.
2. Working a leaf exposed a skeleton error — the main signal. Detection: before starting any leaf, ask "is everything this leaf depends on already in the tree?" A missing dependency is an unnamed branch; register it on the spot.
3. A leaf keeps failing or shows no progress → the cut is wrong, not the effort.
4. A major branch is finished → survey the whole before descending again.

• Check the file itself on every trip up: a node marked filled with no source beside it is not filled — drop it back to named-unfilled until one is attached.
• Repair by diff, not demolition: supersede the dead branches, add the new ones, keep the rest. A full re-cut is only for a pivot of the goal itself.
• Loop phases 2↔3↔4 until the definition of done is met.

Phase 5 — Done means verified

• Verify and stop. Turn the definition of done into the smallest sufficient set of checks, run those, and report each as pass / fail / unavailable / blocked — exactly one of the four. When the proof is complete, stop: no polish, no cleanup, no unrelated tests after the criteria pass. (Wording after the caveman project's verify-and-stop pattern, MIT.)
• Before showing the evidence, re-read the one-line restatement from Phase 0 and say plainly whether the deliverable answers that — a passed check on the wrong goal is still a miss.
• "Done" is a claim and passes the same gate as any claim: show the evidence (the thing runs, the test passes, the deliverable survived rehearsal — see the rehearsal skill; its round log is the citable part).
• Remaining expectations are registered as hypotheses with a judgment date — not folded into the victory lap.
• Distill before leaving: procedures that repeated become skills; corrections that hurt become pinned rules (see pin).

Standing behavior, all phases

• Blocked? Try three distinct routes before asking. When you do ask, present the fork, not the confusion.
• Anything that spends money or is hard to reverse: estimate → explicit approval → act.
• Anything externally visible ships only with the user's click.
• Keep a checkpoint note so the user can return at any moment and catch up in thirty seconds: where we are, what's decided, the one thing they need to decide, the next move (the checkpoint skill owns the format).

Part of ballast — foundations first, every solved path kept, done means checks pass.