---
description: Fluxo obrigatório de Spec-Driven Development do TicketLab
alwaysApply: true
---

# TicketLab — Fluxo Spec-Driven Development

Esta rule define o comportamento operacional do agente no workshop TicketLab.
Os princípios permanentes estão em `.specify/memory/constitution.md` — leia-a;
não a replique aqui. ADRs e RFCs permanecem no Plane e atuam como restrições.

## Entrada do trabalho

1. Identificar a história ou task do Plane **antes** de iniciar qualquer alteração.
2. Consultar pelo Plane MCP, para o item selecionado e seus relacionados:
   - descrição;
   - critérios de aceite;
   - cenários Gherkin;
   - tasks;
   - ADRs;
   - RFCs (quando existirem);
   - links e páginas anexadas.
3. Trabalhar **somente** no item selecionado (e no mínimo necessário para concluí-lo).
4. Interromper e solicitar esclarecimento quando houver ausência, conflito ou ambiguidade relevante.
5. Não inventar requisitos, critérios, Gherkin, ADRs ou RFCs.

## Fluxo Spec Kit

Aplicar esta sequência, usando as skills Spec Kit do projeto (`.cursor/skills/speckit-*`):

```text
Constitution
→ Specify
→ Clarify
→ Plan
→ Checklist
→ Tasks
→ Analyze
→ Implement
→ Converge
```

Regras da sequência:

- Execute uma etapa **somente** quando fizer sentido para o estado atual do trabalho.
- Artefatos existentes (`spec.md`, `plan.md`, `tasks.md`, checklists, etc.) devem ser **lidos e atualizados**.
- Não criar duplicatas de feature ou de artefato.
- Não gerar artefatos Spec Kit sem necessidade para a tarefa em curso.
- A Constitution é pré-condição permanente; não a reescreva como parte de uma feature.

## Implementação

- Seguir a spec, o plan e o `tasks.md` da feature ativa.
- Aplicar ADRs e RFCs do Plane como restrições vinculantes.
- Marcar uma task como concluída **somente** depois de implementar e validar o resultado.
- Manter a alteração restrita ao escopo da task.
- Durante implementação e refactoring, aplicar a rule do Ponytail (`.cursor/rules/ponytail.mdc`) — não a replique.
- Usar Graphify (`.cursor/rules/graphify.mdc`) para compreender relações e impacto quando houver código suficiente para isso — não replique a rule.

## Testes e evidências

- Derivar testes dos critérios de aceite e dos cenários Gherkin do Plane.
- Executar os scripts reais definidos no `package.json` (ex.: `typecheck`, `test`, `build`, e `lint` / cobertura quando existirem).
- Registrar os comandos executados e seus resultados (saída observável).
- Validar logs, métricas e traces quando forem critérios da história ou da task.
- Tratar falhas antes de seguir para revisão.
- Não mascarar testes, cobertura, issues ou Quality Gate.
- Não substituir evidência por afirmação.

## Revisão

Antes do Pull Request, nesta ordem quando aplicável:

1. typecheck;
2. lint;
3. testes;
4. cobertura, quando configurada;
5. build;
6. SonarQube pelo mecanismo existente do repositório;
7. consultar o resultado pelo SonarQube MCP;
8. revisar o diff;
9. executar a análise de convergência do Spec Kit (`speckit-converge` / Analyze + Converge conforme o estado);
10. confirmar aderência à história, Gherkin, spec, plan, tasks, ADRs, RFCs e Constitution.

Não declarar sucesso sem evidência real dos passos acima.

## Pull Request

- Abrir o Pull Request pelo Gitea MCP **somente** depois das validações.
- Relacionar história, spec, plan e tasks no corpo do PR.
- Incluir evidências de testes, build e SonarQube.
- Atualizar a história no Plane com o link do Pull Request.
- Não abrir PR sem Quality Gate / evidências quando forem exigidos pela história ou pela Constitution.

## Limites do agente

- Não inventar requisitos.
- Não criar ou alterar ADRs e RFCs.
- Não ampliar o escopo da task.
- Não modificar os MCPs (`.cursor/mcp.json` e configurações equivalentes).
- Não expor credenciais, tokens ou segredos.
- Não mascarar testes, cobertura, issues ou Quality Gate.
- Não substituir evidência por afirmação.
- Não replicar o conteúdo completo da Constitution nem das rules Graphify/Ponytail.
- Não alterar código da aplicação fora do escopo da task selecionada.