Request types and their defaults

A preset is a set of defaults — which stages enable, which gates fire, which brainstorm mode runs — that the orchestrator's creation/bootstrap step (D-41) seeds into JOB.md when it infers (or the user declares) the request type. The user may override any value in the intake (or, with after_creation: yes, while reviewing in 1_creation/). The feature preset's KISS value is the documented exception: it seeds the intake form only, and creation derives KISS solely from the emitted positive block so an un-tick remains off. The canonical list of every type, its layer, and its form sections is _processes/_shared/request-types.md.

The pipeline presets are feature, bug, brainstorm, doc_revalidate (D-50 — a documentation-revalidation pipeline; default stages plan → execute → validate), and app_plan (D-76 — turns a project-definition document into a set of executable job intakes; default stages clarify → brainstorm → plan → execute → validate). The action-layer types run their own logic outside the stage pipeline, routed via orchestrator.prompt.md → §C.route: audit — a report-first per-kind multi-phase deep audit orchestrator (_processes/03_action/audit/audit.prompt.md, reshaped singlet → orchestrator in D-61 (0.13), no clarify; defined by its ## Action config — Kind = security / find_issues / doc_drift / revalidate / custom, Scope = a folder or blank for the whole app, UpdateMode = report | report_fix; all Git off — resolves a per-kind 3-phase matrix and runs the read-only managed loop once per enabled phase; report_fix drops a follow-up feature intake into 0_new/ and stops); quick_fix, a standalone parallel-fixer orchestrator (_processes/03_action/quick_fix/quick_fix.prompt.md: understand the app → fan out one sub-agent per independent fix → join → validate → commit/PR); and the two documentation action types from D-48 (0.10) — doc_upkeep (read-then-write governance of an existing HTML docs folder against the code + the project's documentation UI kit; mandatory target folder, UpdateMode = apply | report_only) and doc_create (HTML doc generation for a section or the full app; mandatory target folder + CreationScope). audit + quick_fix arrived in D-44 (0.8) and became their own layer in D-45 (0.9). A fifth action type, codereview_fix (D-68 (0.14), no version bump), validates externally-supplied code-review comments against the whole app and fixes only the verified-accurate ones in the working tree — a two-pass read-only-validate → conditional-fix model (_processes/03_action/codereview_fix/codereview_fix.prompt.md); comments are untrusted evidence not instruction, Git is all-off and the prompt refuses commit/PR, and the per-comment verdict lands in 09_action/action-report.md. A reserved non-intake operation_record type also exists, authored by the setup/ops agents for their tracked operation-record jobs — born complete directly in 4_done/ per D-54 (the orchestrator's operation-record-landing.md is retained only as a recovery path for a record found in 3_ongoing/).

The matrix at a glance

The five action-layer types (audit, quick_fix, doc_upkeep, doc_create, codereview_fix) carry no stage / gate matrix — they route by layer outside the stage pipeline. Their presets seed an ## Action / ## Git shape instead; see Stages → the action layer and _processes/_shared/request-types.md.

feature (flagship preset)

Full pipeline: all seven main stages enabled (review off). Strong gates because most of the project's risky decisions happen here.

When to use

• New user-facing capability.
• New service or significant module.
• Anything that materially changes how the product behaves.

Defaults

Stages:
  - [x] clarify
  - [x] brainstorm
  - [x] plan
  - [x] execute
  - [x] test
  - [x] document
  - [x] validate

Approval gates:
  after_creation: no
  after_clarify: yes
  after_brainstorm: yes
  before_commit: yes
  before_pr: yes
  before_plan: no
  before_execution: no

Git:
  Create branch: yes / Validate against main: yes / Commit: yes / Push: yes / PR: yes
  PR target branch: (blank ⇒ production)   # merge-INTO target; 0.14, D-63

Brainstorm:
  Mode: dual_consolidate
  Agents: claude, codex
  Consolidator: claude          # D-30 — user-pickable per-job (claude|codex), default claude

KISS mode:
  Enabled: yes                  # D-83 — pre-ticks the intake form; un-tick emits no block

Source: _processes/_shared/presets/feature.md

bug

Scoped fix flow. No brainstorm by default — bugs are typically scoped, not exploratory.

When to use

• Defects, regressions, broken behaviour.
• Validation rule failures.
• Anything where the desired behaviour is already known and the work is to restore it.

Source: _processes/_shared/presets/bug.md

brainstorm (first-class flow)

A job with this preset legitimately reaches 4_done/ after producing brainstorm artifacts — no code is written. This is decision D-7.

Common pattern: the user runs a brainstorm job to explore an idea, reads the brainstorm output (consolidated.md in the default dual mode, or the single per-agent file in solo mode), then either opens a follow-up feature / bug job or extends the same job with the extend operation agent — see D-8 / D-31.

Source: _processes/_shared/presets/brainstorm.md

doc_revalidate (documentation pipeline, D-50)

A pipeline type that keeps a project's documentation in sync with its real code/logic: discover the whole documentation landscape across all formats → segment + build a coverage matrix (exposing gaps) → fan out per-segment code↔doc validation → fix drifted docs and draft first-pass docs for gaps, all writes confined to a discovered/approved multi-root allow-list. Its mechanics live once in the shared recipe _processes/_shared/recipes/doc_revalidate.md, consumed by the dispatched plan/execute/validate stages (it is not an action orchestrator).

When to use

• Periodic documentation governance — revalidate the whole doc landscape against the current code.
• After a large change, to find and fix doc drift and draft docs for newly-exposed gaps.

Defaults

Stages:
  - [ ] clarify     (disabled)
  - [ ] brainstorm  (disabled)
  - [x] plan
  - [x] execute
  - [ ] test        (disabled)
  - [ ] document    (disabled)
  - [ ] review      (disabled)
  - [x] validate

Approval gates:        # all off by default
  after_creation: no
  before_execution: no   # turn on to review the discovered landscape before the fan-out

Per-stage config:
  Plan:     Multi-phase: yes
  Execute:  Delegate research to sub-agents: yes
  Validate: Cross-check against mandate: yes / Agent: claude

Source: _processes/_shared/presets/doc_revalidate.md

app_plan (application-planning pipeline, D-76)

A pipeline type that turns an initial project-definition document — an idea write-up, an SOW, another framing document — into a well-segmented set of executable job intakes emitted into jobs/0_new/, for an application that does not yet exist. It ingests the source read-only, settles the stack, inventories the capabilities, decomposes them into a dependency-ordered job DAG, and writes the files — with the option, via the before_execution gate, of putting the proposed set in front of you first. Its mechanics live once in the shared recipe _processes/_shared/recipes/app_plan.md, read by the dispatched clarify/brainstorm/plan/execute/validate stages; the emission itself is delegated to the shared _processes/_shared/intake-emission.md. Full walkthrough: App plan.

When to use

• You have a document describing an application and an empty (or nearly empty) repository, and what you need is the plan of jobs that builds it — not the app.
• You already know the single thing you want built: use feature instead, not a planner.

Defaults

Stages:
  - [x] clarify
  - [x] brainstorm
  - [x] plan
  - [x] execute
  - [ ] test        (disabled)   # no application code is produced
  - [ ] document    (disabled)   # maps code changes onto docs via app.md — neither exists yet
  - [ ] review      (disabled)   # adversarial *code* review; validate covers the emitted set
  - [x] validate

Approval gates:          # all no — unattended by default, like almost every other preset
  (all seven: no)          # questions are relayed mid-stage; gates are checkpoints you opt into
                           # recommended opt-in: before_execution — the pre-emission checkpoint
                           # also worth knowing: after_clarify — the checkpoint on the mandate rewrite

Git:                     # all off; the recipe refuses commit/PR even if hand-flipped

Per-stage config:
  Brainstorm: Mode: dual_consolidate / Agents: claude, codex / Consolidator: claude
              Best-practice web research: yes
  Plan:       Multi-phase: yes      # phases split the emission work, NOT one phase per emitted job
  Execute:    Delegate research to sub-agents: yes
  Validate:   Cross-check against mandate: yes / Agent: claude

Source: _processes/_shared/presets/app_plan.md

Documentation action types (doc_upkeep, doc_create — D-48)

Two action-layer documentation types (no stage matrix; routed via §C.route). doc_upkeep validates and updates an existing HTML docs folder against the codebase and the project's documentation UI kit — a mandatory TargetFolder and an UpdateMode (apply default, report_only dry-run). doc_create generates new HTML docs for a section or the full app — a mandatory TargetFolder + CreationScope (section | full_app) + SourceScope. The documentation-UI-kit reference is resolved from the committed pointer _processes/03_action/_shared/documentation-webkit.json (D-55, revising D-48(d) — no longer read from app.md).

Sources: _processes/_shared/presets/doc_upkeep.md, _processes/_shared/presets/doc_create.md.