UTF-SDD

A IA escreve o código. Você decide nos portões.

O UTF-SDD é o método da disciplina de Tópicos Especiais da UTFPR. Ele existe para que, no fim do semestre, você consiga explicar cada linha que entrou no seu projeto — inclusive as que não foi você que digitou.

commito que entrouescreveuautorizou
9c1e04aspec e plano da issue 27vocêvocê
4b7ad12spec: rascunho para aprovadavocêvocê
e30f8a6tarefa 1: entidade OrçamentoIAvocê
7fd2b90tarefa 2: recusa orçamento vencidoIAvocê
1a5c8e3tarefa 3: aviso ao aprovarIAvocê
c02d7f5docs: prd e arquitetura no mesmo commitIAvocê

O problema que o método resolve

Pedir código para uma inteligência artificial é fácil. Qualquer pessoa gera uma tela funcionando em cinco minutos. O problema aparece semanas depois: o sistema faz coisas que ninguém pediu, ninguém lembra por que uma regra existe e, quando é preciso mudar algo, a vontade é apagar tudo e recomeçar.

Nesta disciplina você não é avaliado por gerar código rápido. Você é avaliado por dirigir a IA, auditar o que ela gerou e explicar as decisões técnicas. Você é o engenheiro e o arquiteto; a IA é a sua equipe de execução.

Se o Pull Request for a primeira vez que você olha o código, o método falhou. A regra de ouro, do guia da disciplina

O que é um portão

O UTF-SDD é um SDD por portões (Gated Spec-Driven Development). Portão é um ponto onde o trabalho para e espera por uma decisão sua — decisão que fica registrada em algum lugar que outra pessoa consegue conferir depois. Neste site, um portão aparece assim:

Você aprova a spec Troque status: rascunho por status: aprovada e commite essa linha. O commit fica no git log, com o seu nome. Nenhum agente mexe nesse campo.

São quatro portões por história, mais o Pull Request no fim. Nenhum deles é burocracia: cada um existe porque, sem ele, alguma coisa que você deveria ter decidido seria decidida pela IA no seu lugar, sem você perceber.

Três compromissos

Spec-Driven Development não é invenção desta disciplina. O que distingue a variante daqui são três compromissos que o método não abre mão.

Nada avança sem uma decisão sua, registrada

Aprovar a spec, aceitar a explicação do tutor, triar cada apontamento da revisão, autorizar cada commit. A decisão vira arquivo ou vira commit — memória de conversa não conta, porque não sobrevive à sessão e não prova nada na defesa.

Quem revisa nunca é quem escreveu

O implementador começa com o contexto limpo. Dois revisores diferentes olham o resultado, e nenhum dos dois tem permissão de escrita — eles apontam, não corrigem. Um agente que corrige o próprio trabalho herda o próprio ponto cego e some com a evidência do erro.

Todo artefato é evidência para a defesa

Specs, planos, pareceres, decisões de triagem e mensagens de commit não existem para encher pasta. Eles existem para provar, no dia da arguição, que você entendeu o que assinou.

Quem produz o quê

O método gira em torno de doze artefatos. Desses doze, a IA produz sozinha apenas três: o código, o plano de tarefas e os pareceres de revisão. A ficha da disciplina já vem pronta no template. Todo o resto precisa da sua direção.

ArtefatoOnde ficaQuem dirige
README.mdraizvocê
docs/prd.mdo que o produto fazvocê
docs/architecture.mdonde as coisas moramvocê
docs/user-flows.mdo que a pessoa vive na telavocê
docs/design-tokens.mdcores, espaçamento, tipografiavocê
docs/checklist.mda ficha da disciplinavem no template
IssueGitHub Projectsvocê
spec.mdo que precisa existirvocê aprova
plan.mdcomo será construídoIA
Pareceresreviews/IA
Códigoapps/IA
Pull RequestGitHubvocê

Comece por aqui

Se você acabou de criar o seu repositório pelo Use this template, siga nesta ordem:

  1. Entenda o ciclo — a Fase 0, o ciclo de uma história e os quatro portões.
  2. Veja os comandos — o que digitar em cada etapa e o que sai de cada um.
  3. Conheça os papéis — quem escreve, quem revisa e por que a trava de escrita importa.
  4. Leia docs/checklist.md no seu repositório — é a ficha da disciplina, com as regras e as entregas.

Este site ensina o método. A regra escrita, valendo como fonte da verdade, está no guia da disciplina e no tutorial, dentro do repositório. Quando os dois divergirem, vale o que está no repositório.

Próximo

O ciclo, do começo ao Pull Request