Plan Strict

Forward-design a strict-granularity plan for the active thread from a single upstream input. Read the input, draft an index plus one dispatchable brief per task — each brief carrying explicit substeps, files modified, verification, and acceptance criteria — self-review before emission, write the index plan.md at the thread root and the task briefs under plan-tasks/, then confirm the path. Run end-to-end without walking the user task-by-task. Writing the files is where you stop.

Inputs

Accept ONE of the following input forms. Detect which form was passed before drafting:

1. A spec artifact — the thread-root spec.md, the usual upstream input. Its semantic-contract elements (intended outcome, expected behavior, constraints, acceptance guidance) drive the plan's task list directly, its acceptance criteria map cleanly onto per-task acceptance criteria, and its Degrees-of-freedom section tells the plan which hows are open.
2. A proposal artifact — the thread-root proposal.md. When the input is a proposal rather than a spec, the plan tasks elaborate the proposal's rough shape into an implementable sequence; treat the proposal's open questions as items the plan either resolves or carries forward. A thin proposal yields a thin plan — if there is not enough substance to warrant per-task briefs, flag it in self-review rather than padding the structure.
3. The thread's durable inputs — decisions.md (the settled decisions the plan must honor) together with seed.md (why the thread exists and what triggered it), when no proposal or spec has been written. Each settled decision may map to a task or constrain one — cite it as decisions.md DR<N> in the relevant task's input/context field where the decision is operative.
4. A GitHub issue URL or identifier — a full URL (https://github.com/<owner>/<repo>/issues/<NNN>) or the short owner/repo#NNN form. The issue body becomes the upstream input; treat the issue title and labels as additional context.
5. A raw user prompt — when no artifact is referenced, the user's prompt is itself the input, and the plan is forward-designed directly from it.

The emitted plan must be self-contained: a fresh implementer with only the plan and the thread's durable inputs can execute it, with no dependency on the originating chat.

If the input is ambiguous — a reference names "the spec" or "the decisions" with no clear referent, or several artifacts could be intended — that is a preflight failure, not an in-run decision: refuse before drafting, name the ambiguous reference and how to disambiguate it, write nothing, and end with Outcome: REFUSED — <the ambiguity and how to re-invoke>. Never silently pick by recency.

Plan Artifact Contract