engine-planner

Engine Planner

Produce an implementation plan for the phase.rs engine. Design for the class, not the card. Never propose bandaids, workarounds, or shortcuts — everything lives in its rules-correct place.

This skill produces the plan only. The plan-review loop belongs to the caller — when invoked from /engine-implementer, the orchestrator owns the loop. When invoked standalone, run /review-engine-plan against the plan yourself and iterate until clean.

Input

A task description: parser enhancement/fix, or engine mechanic enhancement/fix. May reference cards, Oracle text patterns, CR rules, or coverage gaps.

Modes

Ordinary mode is the default and produces a full single plan via the Process below. Three additional modes are activated when the caller's spawn inputs name them (the /engine-implementer phase-fit pipeline is the caller). Each mode scopes this file's mandatory language explicitly here, in this file — a spawn prompt never overrides this file's text; this section does.

Charter mode (spawn inputs: a plan or draft plus the phase-fit firing context)

Output contract: a phase charter, not a plan.

• Input mapping (three shapes): a draft plan, with whatever findings have accumulated (the initial gate firing on a fresh draft carries none; mid-loop and plan-loop T4 firings carry the round history) → derive the charter from the draft. A review-clean plan (scope-freeze or pre-existing-clean firing) → partition, not re-plan: carve the converged content into phases; nothing is rewritten, so the split does not invalidate the reviewed artifact. A review-clean plan with landed candidates (impl-loop T4) → derive phase 1 from the stabilized current candidate and partition the remainder.
• Step survival (enumerated): Step 0 (premise verification) survives — a fabricated premise poisons every phase. Step 1 (identify applicable skills) survives — the checklist inventory informs unit boundaries and seams. Step 2 (analogous trace) survives — it informs seam choice. Step 3 (read every file) survives, scoped to the files the charter's phases will touch. Steps 4 and 5 (the architectural sections and the step-by-step plan) are replaced by the charter output contract below — they apply later, to each phase plan in phase-plan mode.
• Charter output contract: linearly ordered phases; per phase, a goal statement, scope-path hints (literal paths or directories, no globs — the orchestrator's frozen SCOPE_PATHS representation and T2 directory expansion consume concrete paths), a verification plan (a phase's discriminating test may be written DEFERRED(phase n) naming the landing phase when it structurally cannot exist until a consumer phase lands — the defining property of a dependency seam; that phase's interim verification is structural: green tree, existing suites, unit-level assertions), and a deferral list — everything the full task needs that the phase intentionally omits, attributed to the phase that will land it; seam notes (shared files such as effects/mod.rs, surfaces held green via strict-failure tags); and a recursive check that no individual phase itself trips the T1∧T2 phase-fit conjunction defined in /engine-implementer.
• Feasibility exit: if no green-tree seam exists, report that instead of a charter — name every candidate split point and show why each leaves the tree non-compiling or tests red.