Change Check — Modificacao Segura com Freeze Specs

PRIMEIRO PASSO (obrigatorio)

Ao carregar esta skill, SEMPRE exibir este header antes de qualquer outra acao:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🔒 CHANGE CHECK — Skill carregada
Mudanca: <descricao recebida>
Verificando freeze specs...
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Consulta as freeze specs antes de qualquer modificacao e propoe uma mudanca com escopo explicito e limitado.

Regra que vale antes de todas

A freeze spec pode estar errada. Ela descreve o codigo como ele e; o CLAUDE.md descreve como ele deve ser. Se a spec do componente mandar algo que o CLAUDE.md proibe, o CLAUDE.md ganha — implementar o que a regra global manda, avisar o operador do conflito, e corrigir a freeze spec ANTES de mexer no codigo (nao depois do deploy: o proximo agente le o contrato antes de voce terminar). Ver Passo 4b da skill /freeze.

Quando usar

• Antes de QUALQUER bug fix ou modificacao em modulo que tem freeze spec
• Quando o operador descreve uma mudanca e voce quer garantir que nao vai quebrar nada
• Pode ser invocado explicitamente ou automaticamente (via regra no CLAUDE.md)

Input esperado

• /change fix o badge do detalhe do item no ListaDeItens
• /change adicionar filtro por sala no calendario
• /change o link de detalhe do item abre pagina errada no portal

Workflow de Execucao

Passo 1: Identificar modulos afetados

A partir da descricao do operador:

1. Identificar QUAIS componentes/arquivos serao tocados
2. Verificar se existem freeze specs em docs/superpowers/freeze/
3. Se NAO existir freeze spec: avisar o operador e sugerir rodar /freeze primeiro

Passo 2: Ler as specs relevantes

1. Ler o _INDEX.md do modulo
2. Identificar QUAL spec quebrada e relevante (ex: day-view.md para mudanca no ListaDeItens)
3. Ler SOMENTE essa spec
4. Extrair: linhas, props, regras, rotas API

Passo 3: Propor a mudanca

Apresentar ao operador um bloco estruturado:

## Proposta de Mudanca

**Descricao**: O que vai mudar
**Componente**: ListaDeItens
**Arquivo**: src/pages/PainelDeVendas.tsx
**Escopo**: Linhas 2060-2068

### O que vou fazer
- Descricao da mudanca tecnica

### O que NAO vou tocar
- DetailSidebar (funcao isolada)
- CalTab (container, nao afetado)
- ApptsTab (outra view, nao afetado)

### Regras da spec que estou respeitando
- ListaDeItens e funcao de modulo, sem acesso a state externo ✓
- Click no card via onAppt(a), nao navegar diretamente ✓

### Risco
- Baixo / Medio / Alto + justificativa

Passo 4: Aguardar aprovacao

NAO implementar sem o OK do operador. Esperar confirmacao.

Passo 5: Implementar

1. Fazer SOMENTE o que foi aprovado
2. NAO adicionar melhorias, refatoracoes ou features extras
3. NAO tocar em componentes fora do escopo
4. Anotar internamente QUAIS specs serao afetadas (arquivo + secao)

Passo 6: Testar e Revisar (OBRIGATORIO antes de atualizar specs)

1. Backend: verificar que o codigo carrega sem erro de sintaxe (node -e "require('./arquivo')" ou equivalente)
2. Backend: testar endpoint via curl/HTTP ou mock funcional se possivel
3. Frontend: rodar npm run build — deve passar sem erros TypeScript
4. Revisao: reler CADA arquivo modificado e validar:
   • Chamadas de API corretas (metodo, path, body)
   • Callbacks de reload/refresh corretos
   • Error handling presente
   • Sem codigo morto ou duplicado
5. Se qualquer teste falhar: corrigir ANTES de prosseguir

Passo 7: Atualizar freeze specs (OBRIGATORIO — somente apos teste)

Para CADA spec afetada pela mudanca, atualizar APENAS a secao relevante:

1. Linhas — se o componente mudou de tamanho, atualizar range de linhas
2. Props/contrato — se novo prop adicionado ou assinatura mudou
3. Rotas/endpoints — se nova rota criada, adicionar na tabela de rotas
4. Dependencias — se novo import/require adicionado
5. Regras — se nova regra de comportamento que NAO pode ser quebrada
6. Historico de mudancas — SEMPRE adicionar entrada com data:

   - YYYY-MM-DD: <descricao concisa da mudanca>

NAO reescrever a spec inteira. Editar cirurgicamente apenas as secoes afetadas. NAO atualizar specs de componentes que nao foram tocados.

Quando NAO existe freeze spec

Se o modulo nao tem freeze spec:

1. Avisar: "Este modulo nao tem freeze spec. Modificacoes podem causar regressoes."
2. Oferecer: "Quer que eu rode /freeze primeiro? (recomendado)"
3. Se o operador disser para continuar sem spec: fazer a mudanca com cuidado extra, mas sem garantias de escopo

Regra de ouro

Nunca modificar codigo fora do escopo aprovado. Se durante a implementacao voce perceber que precisa tocar em outro componente, PARAR e avisar o operador antes de continuar.

Ultimo passo (obrigatorio): sugerir o fechamento

O /change termina quando o codigo funciona. Funcionar nao e o fim do ciclo — falta guardar fora da maquina, atualizar o contrato e registrar o que foi decidido, e nenhuma dessas etapas avisa quando e esquecida.

Depois de concluir a mudanca (com ou sem deploy), SEMPRE exibir:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🔒 CHANGE CHECK — concluido
Arquivos tocados: <lista>

Falta fechar o ciclo: enviar ao GitHub, atualizar as freeze specs
e registrar o que foi decidido.
Rode /finalizar-sessao quando esta frente acabar.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Se a divergencia com o remoto passar de 30 commits, trocar a ultima linha por um aviso mais forte, com o numero real:

ATENCAO: <N> commits so nesta maquina. Rode /finalizar-sessao antes de parar.