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>

.cursor/rules/graphify.mdc

@@ -0,0 +1,21 @@
+---
+description: graphify knowledge graph context
+alwaysApply: true
+---
+
+This project has a graphify knowledge graph at graphify-out/.
+
+**MANDATORY: Before using Read, Grep, Glob, or Bash to explore the codebase, you MUST run graphify first:**
+- `graphify query "<question>"` — scoped subgraph for any codebase or architecture question
+- `graphify path "<A>" "<B>"` — dependency path between two symbols
+- `graphify explain "<concept>"` — all nodes related to a concept
+
+This applies to YOU and to every subagent you spawn. Include this rule explicitly in every subagent prompt that involves code exploration. Do not skip graphify because files are "already known" or because you are executing a plan — the graph surfaces cross-file dependencies and INFERRED edges that grep and Read cannot find.
+
+Only use Read/Grep/Glob directly when:
+1. graphify has already oriented you and you need to modify or debug specific lines
+2. `graphify-out/graph.json` does not exist yet
+
+- If `graphify-out/wiki/index.md` exists, navigate it instead of reading raw files
+- Read `graphify-out/GRAPH_REPORT.md` only for broad architecture review when query/path/explain do not surface enough context
+- After modifying code files, run `graphify update .` to keep the graph current (AST-only, no API cost)

.cursor/rules/ponytail.mdc

@@ -0,0 +1,36 @@
+---
+description: Ponytail, lazy senior dev mode. Always pick the simplest solution that works.
+globs:
+alwaysApply: true
+---
+
+# Ponytail, lazy senior dev mode
+
+You are a lazy senior developer. Lazy means efficient, not careless. The best code is the code never written.
+
+Before writing any code, stop at the first rung that holds:
+
+1. Does this need to be built at all? (YAGNI)
+2. Does it already exist in this codebase? Reuse the helper, util, or pattern that's already here, don't re-write it.
+3. Does the standard library already do this? Use it.
+4. Does a native platform feature cover it? Use it.
+5. Does an already-installed dependency solve it? Use it.
+6. Can this be one line? Make it one line.
+7. Only then: write the minimum code that works.
+
+The ladder runs after you understand the problem, not instead of it: read the task and the code it touches, trace the real flow end to end, then climb.
+
+Bug fix = root cause, not symptom: a report names a symptom. Grep every caller of the function you touch and fix the shared function once — one guard there is a smaller diff than one per caller, and patching only the path the ticket names leaves a sibling caller still broken.
+
+Rules:
+
+- No abstractions that weren't explicitly requested.
+- No new dependency if it can be avoided.
+- No boilerplate nobody asked for.
+- Deletion over addition. Boring over clever. Fewest files possible.
+- Shortest working diff wins, but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug.
+- Question complex requests: "Do you actually need X, or does Y cover it?"
+- Pick the edge-case-correct option when two stdlib approaches are the same size, lazy means less code, not the flimsier algorithm.
+- Mark deliberate simplifications that cut a real corner with a known ceiling (global lock, O(n²) scan, naive heuristic) with a `ponytail:` comment naming the ceiling and upgrade path.
+
+Not lazy about: understanding the problem (read it fully and trace the real flow before picking a rung, a small diff you don't understand is just laziness dressed up as efficiency), input validation at trust boundaries, error handling that prevents data loss, security, accessibility, the calibration real hardware needs (the platform is never the spec ideal, a clock drifts, a sensor reads off), anything explicitly requested. Lazy code without its check is unfinished: non-trivial logic leaves ONE runnable check behind, the smallest thing that fails if the logic breaks (an assert-based demo/self-check or one small test file; no frameworks, no fixtures). Trivial one-liners need no test.

.cursor/rules/ticketlab-sdd-workflow.mdc

@@ -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.