Manutencao/paridade com sdd

[ronifabio]

Closes #5

O que este PR faz e por quê

Comparei este template com o utf-sdd-template e encontrei uma diferença que não
era de propósito: o SDD recebeu cinco rodadas de manutenção depois que este aqui
parou, e o miolo do método ficou uma geração atrás. As diferenças de identidade da
disciplina — Gitflow, Angular com BaaS, a ficha com oito RAs, a jornada vivendo no
protótipo em vez de num documento — continuam intactas. O que este PR traz é o que
ficou para trás sem querer, mais dois defeitos que faziam o ciclo mentir.

Os dois defeitos são o motivo principal deste PR.

O primeiro: o utf-task.md mandava os revisores rodarem
git diff <SHA-do-passo-0>..HEAD, mas nesse ponto o trabalho do implementador
ainda não está commitado — está no working tree. Com ..HEAD o comando compara o
SHA com ele mesmo e devolve nada, então os dois revisores vinham emitindo parecer
sobre diff vazio, e "APROVADO" não significava coisa alguma. Faltava também um
git add -A depois do implementador: arquivo novo não rastreado não aparece em
git diff de jeito nenhum, e componente e teste recém-criados são o miolo de quase
toda tarefa.

O segundo: o caminho dos pareceres aparecia em três formas diferentes dentro do
mesmo arquivo, e numa quarta no utf-issue.md. Como a contagem de rodadas é a
listagem do diretório, gravar num caminho e contar noutro faz o ciclo achar que
está sempre na rodada 1 — e o limite de duas rodadas, que é o freio contra o loop
infinito de correção, deixa de existir. Agora há uma forma só, com um passo
explícito de normalização do número.

O resto é paridade. A Fase 0 ganhou o portão de commit, que confere com
git status --porcelain se o documento anterior foi commitado antes de seguir —
sem ele o portão existia só como texto no guia, e os quatro documentos acabavam
empilhados num commit único no fim, com a autoria sumindo. O /utf-issue ganhou a
retomada de estado, para não reescrever spec já aprovada. O tutor ganhou os modos
passo, prd, design, architecture e setup, com a oferta no portão de cada
etapa. Entraram os modelos comentados de spec e plano, os templates de Issue para
bug e tarefa técnica, e a seção do tutorial que explica o caminho curto — no bug, o
primeiro commit é um teste que reproduz a falha. A auditoria final foi invertida:
a documentação é atualizada antes do auditor rodar, porque duas das quatro coisas
que ele confere são exatamente essas atualizações.

O Portão de Entendimento caiu de 400 para 250 caracteres, alinhando com o outro
template. Tirei as datas fixas da ficha, que envelhecem em silêncio — prazo vive no
Moodle. E o CONTRIBUTING agora diz a quem as regras de Gitflow se aplicam: ao
projeto que a equipe constrói, não a este repositório, que não tem produção nem
release. Essa ambiguidade tinha consequência prática — um agente rodando aqui lia a
constituição e tentava abrir branch a partir de uma develop que não existe.

Por fim, entra o site do método em site/, publicado no Pages por um workflow com
guarda de repositório, para o repositório de cada equipe não tentar publicá-lo. O
conteúdo foi escrito para este template, não copiado do outro: Gitflow com a branch
nascendo da develop antes da aprovação da spec, Angular e BaaS no lugar de NestJS,
e os onze artefatos deste método.

Depois do merge, falta um passo manual: em Settings → Pages, trocar a origem
para GitHub Actions. Sem isso o deploy falha, e não há como configurar isso por
arquivo.

Apontamentos da revisão

Não se aplica — PR de manutenção, sem spec.md.