App plan

The generated jobs are the deliverable; any document it writes is a by-product. Its mechanics live once in the shared recipe _processes/_shared/recipes/app_plan.md, which the clarify, brainstorm, plan, execute, and validate stages read through a thin type-conditional pointer. The preset _processes/_shared/presets/app_plan.md seeds the JOB.md defaults.

The flow

As a pipeline type, app_plan runs the orchestrator's staged lifecycle. Per the preset, five stages are enabled out of the box — clarify → brainstorm → plan → execute → validate — and test, document, and review are disabled by default because no application code is produced. clarify ingests the source document read-only and builds a quote-and-attribute claim ledger; brainstorm runs two independent writers at the stack and architecture question; plan owns the capability inventory, the job DAG, and the proposed job-set table; execute is the only stage that writes into jobs/0_new/; validate re-verifies the set from the files as written.

Underneath the stage set, the recipe drives one continuous pipeline from the untrusted source document to the emitted files. It runs unattended by default — every approval gate is no, as on almost every other preset, and genuine open questions come back to you mid-stage through the orchestrator's question relay rather than through a gate. Two checkpoints are worth opting into, each a one-line flip in the intake form: after_clarify, where you ratify the normalized mandate (clarify is the one stage allowed to rewrite it, and its input is the untrusted document — so this is the type's single injection channel), and before_execution, the pre-emission checkpoint where you review the proposed job set in 03_plan/PLAN.md before any file is written into your queue. before_execution is the one to reach for first.

What lands

• An ordered, dependency-declared set of NNN-descriptive-slug.md intakes in jobs/0_new/, numbered in steps of ten (000, 010, 020, …). Parallel siblings share a decade and differ in the trailing digit — 030 / 031 / 032 are three jobs that may run in any order relative to each other once 020 is done.
• A 000- foundation job — the repository skeleton, the build/test/CI automation, app.md and config.json — followed by a 010- walking skeleton: the thinnest end-to-end path that actually deploys, proven by one automated end-to-end test. That pair is the one sanctioned exception to the "slice vertically" rule, and it lands first so the riskiest integration point is retired first rather than last.
• Each intake carries its own declared job configuration, and it is layer-aware — a pipeline job declares the stages, gates and Git settings it should run with; an action job (an audit or a doc_create in the set) declares its Git settings and its complete ## Action block, with no mandatory field left blank. Either way the reason for every divergence from that type's preset is stated, so emitted jobs do not silently inherit the heaviest preset in the system.
• One dated initial-plan record in the host project's project/ folder — a non-binding historical snapshot of what was proposed on the day, left uncommitted in the working tree for you to read and land yourself. It is a record, not a contract: later jobs are free to diverge from it and nothing reads it back.

What it is for

Reach for app_plan at the moment you have a document describing an application and an empty (or nearly empty) repository, and what you need is not the app but the plan of jobs that builds the app. It answers the question "what are the five to fifteen jobs, in what order, with what boundaries?" — and answers it as files you can immediately run, rather than as prose you then have to hand-transcribe into intakes.

The type owns three levels of a four-level ladder — Initiative → Wave → Job — and deliberately stops at the job level. It never slices a job into execution phases; that is each emitted job's own plan stage's work, and duplicating it here would produce a plan that is stale before the first job starts.

The logic

After pickup, the orchestrator reads JOB.md → Type and looks up app_plan in the registry: layer pipeline, shape pipeline. It therefore runs the normal staged lifecycle on the single shared pipeline route — it does not hand off to an action prompt, and it needed no new dispatch branch. The five enabled stages enrich their work by reading the shared recipe through a type-conditional pointer in their ## Inputs.

Select-and-go — the identity half only. doc_revalidate established the select-and-go pattern (D-50) by hiding both the identity and mandate sections. app_plan takes half of it and parameterizes the other half: it hides identity and keeps mandate. The slug derives from the source document's filename rather than from a constant — so a second run on a different document on the same day does not collide — and the mandate is auto-filled from the recipe's prose with your source path interpolated into it. The mandate box stays on screen, repurposed as the optional free-prose companion to that path: whatever you type is appended to the auto-filled body under its own ## Additional constraints heading, and the heading is omitted entirely when you leave it blank.

One mandatory structured input, and no configuration knobs. The type ships exactly two form inputs — the required source-document path and the optional free-prose box — and that is deliberate. Every other policy is a recipe default you override in words: "cap at 20 jobs", "plan waves 0-2 only", "plan §§4-9 only", "do not emit the initial-plan record". The wave subset is the one to reach for on a large source document: the whole set is planned and emitted at once by default, and on a document carrying a long phase outline the 15-job cap binds — planning a subset of the waves is the sanctioned way through, rather than shrinking the jobs to fit. A pipeline job carries no ## Action block, so the source path is not emitted as a structured config line at all; it is interpolated into the mandate prose. The path is also the workflow's first genuinely enforced mandatory form field — leaving it empty blocks the emit with an error rather than passing a placeholder downstream.

The source document is untrusted input. A real framing document is full of imperative prose aimed at a human reader, and a naive ingestion would launder those directives into an executable mandate. The recipe fences clarify to quote and attribute (<source> §N says X) rather than adopt source imperatives into mandate voice, and two opt-in gates put a human on that boundary when you want one — after_clarify on the rewritten mandate, before_execution on the proposed job set. Both default no; enabling before_execution is the single highest-value flip for an untrusted source. That is the quarantined/privileged split current prompt-injection guidance prescribes, arrived at structurally rather than bolted on.

The fields

The intake form shows action-config, mandate, stage-config, approval-gates, and git for this type — identity is hidden and auto-filled. The table below records the defaults the preset seeds into JOB.md.

How to run it

In the intake form, pick App plan, fill in the source document path (repo-relative — the idea, SOW, or framing document to read), optionally add free prose in the mandate box for any per-run policy override, adjust stage-config / approval-gates if you want, and submit. The slug and the mandate body are filled in for you. Then start the orchestrator by sending it the prompt path:

_processes/02_orchestrator/orchestrator.prompt.md

The orchestrator picks up the job and runs the five enabled stages. Expect to be stopped twice: once after clarify, to ratify the normalized mandate, and once before execute, to approve the proposed job set. The second stop is the one that matters — read the job-set table in 03_plan/PLAN.md, because approving it is what causes files to appear in your queue.

Running the app in a brand-new repository

The usual target for this type is a repository with a framing document and nothing else — no app.md, no config.json. Every workflow agent normally refuses to run in that state. To start anyway, the intake's # Mandate carries a ## Bootstrap carve-out block declaring the bypass; the auto-filled mandate includes one. The emitted 000- foundation job carries the same block, so it can run before the project context exists, and its own document stage is what authors a real app.md — after which the rest of the set runs with no bypass at all.

Afterwards

1. Read the emitted intakes in jobs/0_new/ — they are ordinary intake files and you can edit them before running any of them.
2. Read the initial-plan record in project/ and commit it yourself if you want it in history. Nothing reads it back; it is a snapshot of intent, not a contract.
3. Work the queue in number order. Run 000- first; run same-decade siblings (030 / 031 / 032) in any order once their shared predecessor is done.
4. Expect drift. A later job's brainstorm can invalidate an assumption a not-yet-run intake was written against — edit or cancel that intake by hand when it happens. This is a known, honest limitation the run's own report names.

See also