Escrever um contrato

O contrato é a camada que diz o que a task é — prompt, propósito, território, gates e a forma do relatório.

Uma task tem quatro camadas. A primeira é o contrato: o que esta task é. É o que você declara na criação, e é o que o card recebe no briefing.

Os campos

Campo	Valores	Obrigatório	Regra
`prompt`	texto livre	sim	por que a task existe
`purpose`	`investigate` `implement` `measure` `fix`	não	write-once: rotular errado é outra task, não um relabel
`deps`	ids de outras tasks	não	destrava o despacho automático quando todas ficam `done`
`review`	`wanted` ou ausente	não	mutável — risco é avaliação, e avaliação muda
`territory`	arquivos/regiões	não	quais arquivos são desta task
`gates`	comandos	não	o que precisa passar antes de entregar
`allow_commit`	bool	não	se o card pode commitar; normalmente `false`
`report_schema`	JSON	não	o formato que você exige de volta
`cwd`	caminho	não	onde o card nasce

O briefing montado

O card recebe, no despacho:

prompt  +  ponteiro de dependências  +  contrato

Nada mais. Regra de board não está nessa lista: se você precisa que o card saiba algo, isso cabe num campo do contrato, ou você manda explicitamente, ou ele não vai saber.

O erro mais caro é o brief sem “como”

Briefar “meça X” sem dizer como medir já produziu doze sondas em vinte e três segundos na conversa do usuário. Briefar “mexa só nesta região” sem dizer o que fazer com a fonte antiga já produziu uma segunda fonte de verdade ao lado da primeira.

Um bom contrato:

O defeito, medido — não “melhorar X”, mas “X faz A quando deveria fazer B; medido em N casos; aqui está a query ou o arquivo”.
A fronteira — quais arquivos são seus, e quem mais está escrevendo neles agora.
A decisão que você não tomou — se há duas saídas plausíveis, diga as duas e peça que o card meça antes de escolher.
O gate — o que precisa passar antes de a entrega valer.
A forma do relatório — para não receber prosa quando precisa de números.

Depois do contrato, o próximo passo é Papéis e vereditos.