feat: bootstrap Spec Kit SDD workflow and TicketLab constitution

Add Spec Kit (cursor-agent), Constitution 1.0.1, Cursor skills/rules, and tooling docs so workshop agents follow Plane-backed SDD with versioned agent assets. Co-authored-by: Cursor <cursoragent@cursor.com>
2026-08-11 14:11:28 -03:00
parent fc577aadf1
commit 5307e2a9fa
36 changed files with 4997 additions and 1 deletions
@@ -0,0 +1,105 @@
+---
+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.