deliverable-workflow

Deliverable Workflow

The agency's production line for client work. One brief in, one deployed and documented deliverable out — with a record that survives a dispute, an audit or a takedown request.

The rule underneath everything:

Rework is cheap. A bad approval is not. Backwards is always allowed and never gated. Forwards is gated.

Full spec: docs/DELIVERABLE-WORKFLOW.md in the KitchenMCP repo.

The shape of it

Eleven live states, seven gates, all held in Kitchen. Board = client engagement. Column = state. Task = deliverable. Gate passes, approvals and compliance reports are append-only task comments.

intake → scoped → in_production → internal_review → compliance_review
   → client_review → approved → scheduled → deployed → verified → archived
                  ↘ changes_requested ↗     ⛔ blocked   ✕ cancelled

Gate	Guards	Owner
G1 Scope	intake → scoped	Producer
G2 Production-ready	scoped → in_production	Producer
G3 Internal QA	internal_review → compliance_review	Reviewer
G4 Compliance	compliance_review → client_review	Compliance
G5 Client sign-off	client_review → approved	Client approver
G6 Deploy	approved → deployed	Deployer
G7 Verify	deployed → verified	Deployer

Starting work

When the user describes a new piece of work, treat it as an intake — don't ask twenty questions first.

1. Call workflow_recipe for the deliverable type. It tells you what the brief must answer, what assets are needed and what traps kill this type. Use as_brief_scaffold: true to get a ready-to-fill brief.
2. Fill what you can infer from what they said. Ask once, in one consolidated pass, for what is genuinely missing — never a barrage.
3. workflow_create_deliverable with the brief and metadata. It lands in Intake.

Set jurisdiction at intake, always. It decides what text must appear in the artwork, and discovering it at the compliance gate means a redesign. If it is a state election, set region too — the state rules are stricter than the Commonwealth ones and differ from each other.