Request types
Every job starts as an intake in jobs/0_new/. Its Type decides everything that follows: which layer it runs in, which prompt drives it, and which fields its JOB.md carries. This section lists the types in the same order and grouping as the intake form, and gives each one a page explaining what it is for, how its flow runs, the logic that routes it, and the fields you set.
The registry at _processes/_shared/request-types.md is the single source of truth; the intake form, the orchestrator's routing, and these pages all derive from it.
quick_fix, action; Collaborative session → quick_fix_collab, operation op-card, direct-invoked), and Doc HTML as one row with an Upkeep / Create toggle (Upkeep → doc_upkeep, Create → doc_create). These pages mirror that: one page each, documenting both modes. They remain distinct backend types with distinct routing.
How an intake is routed
After pickup, the orchestrator reads JOB.md → Type, looks up its layer in the registry, and routes before any stage runs. The three layers are pipeline (runs the staged lifecycle), action (runs its own prompt outside the pipeline), and operation (user-invoked op-cards that record their work).
The main job lifecycle
Pipeline jobs (and the queue moves the orchestrator performs for every job) flow through the fixed Kanban queues. Action and operation jobs use the same queues but skip the stage loop; they reach 4_done/ through their action prompt or born-complete operation record, not by completing a stage checklist.
Pipeline types
Run the main staged lifecycle (clarify → brainstorm → plan → execute → test → document → review → validate) under the orchestrator. Disabled stages are skipped per the type's preset.
Feature
Build a new capability end-to-end through the full staged pipeline.
Bug
Diagnose and fix a defect via the lean pipeline (no brainstorm / document).
Brainstorm
Explore and converge on an approach; report-only, no code — reaches 4_done/.
Doc revalidate
Keep the whole documentation landscape in sync with the code via the pipeline.
App plan
Turn an initial project-definition document (idea, SOW, framing doc) into a well-segmented set of executable job intakes for an application that does not yet exist.
Action types
Run their own logic outside the stage pipeline — each is a self-contained prompt or its own mini-orchestrator. The main orchestrator hands the job off and does not enter the stage loop.
Audit
Read-only, whole-app or scoped review that produces a findings report and writes no code.
Quick fix
Small fixes, two modes: Task (action job: batch fan-out, then validate + commit → quick_fix) or Collaborative (operation op-card, direct-invoked live assistant → quick_fix_collab).
Doc HTML
HTML documentation, two modes: Upkeep (validate + update an existing folder → doc_upkeep) or Create (generate new docs → doc_create).
Code-review fix
Validate externally-supplied code-review comments against the whole app and fix only the verified-accurate ones in the working tree — no commit/PR (→ codereview_fix).
Operation types (op-cards)
User-invoked op-cards for setup and queue management. You start them by sending the prompt path directly; each records its work as an operation_record born in 4_done/.
App init
Bootstrap app.md + config.json by inspecting the host project (first-run setup).
App update
Refresh app.md + config.json against host drift.
App install
Lease a port + names and bring up this project's helper app; then recommends app-init.
Claude/Agents MD files
Idempotently ensure a host app's root CLAUDE.md + AGENTS.md (CLAUDE.md real — always the main one, AGENTS.md a relative symlink to it).
Promote
Manually move a job between Kanban queues (recovery / queue management).
Extend
Add stages + per-stage config to an existing job and re-stage it.
quick_fix_collab) into the Quick fix row, and Create (doc_create) into the Doc HTML row — so they are documented on those pages. An 18th type, operation_record, is reserved and non-intake (ops agents author it automatically to record an action in 4_done/); it never appears in the form and has no page.
All rows at a glance
The same fifteen rows the intake form's type dropdown shows, in the same order.
| Row (as in the form) | Layer | Backend type(s) / modes | Prompt path |
|---|---|---|---|
| Feature | pipeline | feature | _processes/02_orchestrator/orchestrator.prompt.md |
| Bug | pipeline | bug | _processes/02_orchestrator/orchestrator.prompt.md |
| Brainstorm | pipeline | brainstorm | _processes/02_orchestrator/orchestrator.prompt.md |
| Doc revalidate | pipeline | doc_revalidate | _processes/02_orchestrator/orchestrator.prompt.md |
| App plan | pipeline | app_plan | _processes/02_orchestrator/orchestrator.prompt.md |
| Audit | action | audit | _processes/03_action/audit/audit.prompt.md |
| Quick fix | Task: action Collaborative: operation | Task fixes → quick_fix · Collaborative session → quick_fix_collab (op-card, direct-invoked) | …/quick_fix/quick_fix.prompt.md · …/quick_fix/collab.prompt.md |
| Doc HTML | action | Upkeep → doc_upkeep · Create → doc_create | …/doc_upkeep/doc_upkeep.prompt.md · …/doc_create/doc_create.prompt.md |
| Code-review fix | action | codereview_fix | _processes/03_action/codereview_fix/codereview_fix.prompt.md |
| App init | operation | app-init | _processes/00_app/app-init.prompt.md |
| App update | operation | app-update | _processes/00_app/app-update.prompt.md |
| App install | operation | app-install | _processes/00_app/app-install.prompt.md |
| Claude/Agents MD files | operation | claude-agents-md-files | _processes/00_app/claude-agents-md-files.prompt.md |
| Promote | operation | promote | _processes/_operations/promote/promote.prompt.md |
| Extend | operation | extend | _processes/_operations/extend/extend.prompt.md |
Host-authored custom request types
Beyond the built-in rows above, a host application can define its own custom request types at runtime (D-74) — reusable canned flows meaningful only to that project — without committing anything to the workflow repo.
Each custom type is one JSON file in a gitignored app-request-types/ folder at the workflow root (per-host state, exactly like app.md / config.json). It maps onto a built-in pipeline base type (feature / bug / brainstorm) via a flow.kind: pipeline_recipe declaration carrying a canned mandate and/or a folder-local prompt. It surfaces in the intake form's request-type picker only in Docker/API (helper) mode — the offline static form shows the built-in types only — and the orchestrator's creation/bootstrap step re-reads the JSON as the authority, mapping the job onto its base-type pipeline and failing closed if the entry or its prompt is missing or invalid.
_docs/how-to-use.md → Adding your own custom request type and the authoring recipe in _docs/how-to-extend.md → Adding an app-local custom request type (host-authored); the field-by-field JSON contract is _processes/_shared/schemas/APP_REQUEST_TYPES.md.