@lugom.io/hefesto 0.3.0 → 1.0.0

package/skills/hefesto-security/references/secrets-detection.md

@@ -0,0 +1,121 @@
+# Detecção de Segredos
+
+Regex por provider e padrões genéricos para detecção automatizada de segredos hardcoded. Inclui auditoria de `.gitignore`.
+
+## Quick Index
+
+- **API keys por provider** → "API Keys by Provider" (linha 12)
+- **Padrões genéricos** → "Generic Patterns" (linha 31)
+- **.env commitado** → ".env Committed" (linha 47)
+- **Auditoria de .gitignore** → "Gitignore Audit" (linha 55)
+- **Regex para grep** → "Grep Patterns" (linha 87)
+
+---
+
+## API Keys by Provider
+
+| Provider      | Prefixo / Padrão       | Regex                                                    |
+| ------------- | ---------------------- | -------------------------------------------------------- |
+| **AWS**       | `AKIA` (access key)    | `AKIA[0-9A-Z]{16}`                                       |
+| **AWS**       | Secret key             | `['"]\w{40}['"]` proximo de `aws_secret` ou `AWS_SECRET` |
+| **GCP**       | Service account JSON   | `"type":\s*"service_account"` em `.json`                 |
+| **GCP**       | API key                | `AIza[0-9A-Za-z_-]{35}`                                  |
+| **GitHub**    | Personal access token  | `ghp_[0-9a-zA-Z]{36}`                                    |
+| **GitHub**    | OAuth token            | `gho_[0-9a-zA-Z]{36}`                                    |
+| **GitHub**    | App token              | `ghs_[0-9a-zA-Z]{36}`                                    |
+| **Stripe**    | Secret key (live)      | `sk_live_[0-9a-zA-Z]{24,}`                               |
+| **Stripe**    | Publishable key (live) | `pk_live_[0-9a-zA-Z]{24,}`                               |
+| **Slack**     | Bot token              | `xoxb-[0-9]{10,}-[0-9a-zA-Z]{24,}`                       |
+| **Slack**     | User token             | `xoxp-[0-9]{10,}-[0-9a-zA-Z]{24,}`                       |
+| **Anthropic** | API key                | `sk-ant-[0-9a-zA-Z_-]{80,}`                              |
+| **OpenAI**    | API key                | `sk-[0-9a-zA-Z]{48,}`                                    |
+| **Twilio**    | Account SID            | `AC[0-9a-f]{32}`                                         |
+| **SendGrid**  | API key                | `SG\.[0-9A-Za-z_-]{22}\.[0-9A-Za-z_-]{43}`               |
+| **Mailgun**   | API key                | `key-[0-9a-zA-Z]{32}`                                    |
+
+---
+
+## Generic Patterns
+
+| Tipo                    | O que procurar                                     | Regex                                                                  |
+| ----------------------- | -------------------------------------------------- | ---------------------------------------------------------------------- |
+| **API key generica**    | Variavel com nome sugestivo atribuida a string     | `(?:api_key\|apikey\|api_secret\|secret_key)\s*=\s*['"][^'"]{10,}['"]` |
+| **Password hardcoded**  | Variavel password/senha atribuida a string         | `(?:password\|passwd\|pwd\|senha)\s*=\s*['"][^'"]+['"]`                |
+| **JWT hardcoded**       | String que comeca com `eyJ` (base64 de `{"`)       | `['"]eyJ[A-Za-z0-9_-]{10,}\.eyJ[A-Za-z0-9_-]{10,}\.[A-Za-z0-9_-]+['"]` |
+| **URL com credentials** | `user:pass@` em URL                                | `https?://[^/\s:]+:[^/\s@]+@`                                          |
+| **Connection string**   | MongoDB, Postgres, MySQL, Redis                    | `(?:mongodb\|postgres\|mysql\|redis)://[^/\s:]+:[^/\s@]+@`             |
+| **SSH private key**     | Begin/end markers                                  | `-----BEGIN (?:RSA\|DSA\|EC\|OPENSSH) PRIVATE KEY-----`                |
+| **Arquivo de key**      | Extensoes de arquivo sensiveis                     | `\.(pem\|key\|p12\|pfx\|keystore)$` em arquivos tracked                |
+| **Base64 longa**        | Strings base64 suspeitas (>40 chars) em atribuicao | `['"][A-Za-z0-9+/=]{40,}['"]` proximo de `key\|secret\|token`          |
+
+---
+
+## .env Committed
+
+Verificar se `.env` esta no git:
+
+1. `git ls-files .env .env.local .env.production .env.staging` — se retorna algo, esta commitado
+2. Verificar `.gitignore` — se `.env` nao esta listado, qualquer .env futuro sera commitado
+
+---
+
+## Gitignore Audit
+
+Verificar que estes padroes estao em `.gitignore`:
+
+```
+# Secrets e credentials
+.env
+.env.local
+.env.production
+.env.staging
+*.pem
+*.key
+*.p12
+*.pfx
+*.keystore
+credentials.json
+service-account*.json
+*-credentials.json
+
+# IDE e sistema
+.idea/
+.vscode/settings.json
+*.swp
+.DS_Store
+
+# Databases locais
+*.sqlite
+*.sqlite3
+*.db
+```
+
+Se `.gitignore` nao tem estes padroes, reportar como ⚠ warning.
+
+Se algum destes arquivos ja esta tracked (`git ls-files`), reportar como 🔴 critical — precisam ser removidos do tracking com `git rm --cached`.
+
+---
+
+## Grep Patterns
+
+Regex prontos para busca automatizada com `Grep` tool.
+
+```
+AKIA[0-9A-Z]{16}
+AIza[0-9A-Za-z_-]{35}
+ghp_[0-9a-zA-Z]{36}
+gho_[0-9a-zA-Z]{36}
+sk_live_[0-9a-zA-Z]{24,}
+pk_live_[0-9a-zA-Z]{24,}
+xoxb-[0-9]{10,}
+xoxp-[0-9]{10,}
+sk-ant-[0-9a-zA-Z_-]{80,}
+sk-[0-9a-zA-Z]{48,}
+SG\.[0-9A-Za-z_-]{22}
+-----BEGIN\s+(?:RSA|DSA|EC|OPENSSH)\s+PRIVATE\s+KEY
+eyJ[A-Za-z0-9_-]{10,}\.eyJ
+(?:password|passwd|pwd|senha)\s*=\s*['"][^'"]+['"]
+(?:api_key|apikey|api_secret|secret_key)\s*=\s*['"][^'"]{10,}['"]
+https?://[^/\s:]+:[^/\s@]+@
+(?:mongodb|postgres|mysql|redis)://[^/\s:]+:[^/\s@]+@
+```

package/skills/hefesto-security/references/severity-and-judgment.md

@@ -0,0 +1,176 @@
+# Severidade e Julgamento
+
+Critérios universais para classificar findings, evitar falsos positivos e calibrar decisões de fix.
+
+## Quick Index
+
+- **Níveis de severidade** → "Severity Levels" (linha 14)
+- **Falhas silenciosas** → "Silent Failures" (linha 50)
+- **Quando NÃO reportar** → "When NOT to Report" (linha 108)
+- **SEMPRE reportar** → "When to ALWAYS Report" (linha 156)
+- **Migrations e schema** → "Migration and Schema Changes" (linha 172)
+
+---
+
+## Severity Levels
+
+### Critical — aplicar fix automaticamente
+
+Condições (independente de linguagem):
+
+- Erro completamente ignorado (catch vazio, erro descartado, bare except equivalente)
+- Processo pode crashar ou ficar em estado inconsistente
+- Panic/crash engolido sem log
+- Segredos de produção hardcoded
+- Input de usuário direto em code execution, shell commands, ou queries sem sanitização
+- Desserialização de dados não confiáveis usando deserializadores inseguros
+- Permissões excessivas de filesystem (world-writable)
+
+### Warning — aplicar fix se seguro, perguntar se altera comportamento
+
+Condições:
+
+- Erro logado mas não propagado (pode ser intencional)
+- Valor default pode confundir chamador (retorna `[]` ou `null` em vez de erro)
+- Catch/except muito amplo mas pelo menos trata o erro
+- Validação ausente em trust boundary
+- Configuração permissiva (CORS wildcard, debug mode, crypto fraco)
+- Rate limiting ausente em endpoints sensíveis (login, reset, signup)
+- Queries sem limit/pagination
+
+### Info — apenas reportar
+
+Condições:
+
+- Optional chaining ou null coalescing que pode ser intencional
+- Error handling via context managers sem except explícito
+- Configuração que pode ser intencional no contexto
+- Minor code smells sem impacto de segurança direto
+
+---
+
+## Silent Failures
+
+Falhas silenciosas são um dos riscos mais subestimados em segurança. Quando erros são engolidos, bugs ficam invisíveis em produção — incluindo bugs de segurança.
+
+### Categorias universais
+
+Estas categorias se aplicam a **qualquer linguagem** — os mecanismos mudam (try/catch, error returns, Result types, defer, promises), mas os anti-padrões são os mesmos:
+
+| Categoria                   | Definição                                                                                     | Severidade |
+| --------------------------- | --------------------------------------------------------------------------------------------- | ---------- |
+| **Swallowed errors**        | Erro capturado/retornado e completamente ignorado. Sem log, sem propagação, sem feedback      | critical   |
+| **Log-only handling**       | Erro logado mas execução continua como se fosse sucesso. Chamador não sabe que houve falha    | warning    |
+| **Deceptive defaults**      | Handler retorna valor indistinguível de sucesso (lista vazia, null, zero) sem indicar erro    | warning    |
+| **Overly broad catching**   | Captura todos os erros quando só específicos eram esperados, escondendo bugs não relacionados | warning    |
+| **Abandoned intent**        | Handler com TODO/FIXME — intenção de tratar nunca materializada                               | critical   |
+| **Panic/crash suppression** | Mecanismo de recovery (recover, catch-all, global handler) que suprime sem logar              | critical   |
+
+### O que procurar (por paradigma)
+
+| Paradigma                                                | Mecanismos a inspecionar                                                        |
+| -------------------------------------------------------- | ------------------------------------------------------------------------------- |
+| **Exception-based** (JS/TS, Python, Java, C#, Ruby, PHP) | try/catch/except blocks, promise .catch(), global exception handlers            |
+| **Error-return** (Go, Rust, C)                           | `_ = err`, `Result` não verificado, errno ignorado                              |
+| **Event-based** (Node.js, browsers)                      | EventEmitters sem handler de 'error', unhandled rejection handlers              |
+| **Async** (qualquer)                                     | Promises/Futures sem tratamento de rejeição, async sem try/catch em entrypoints |
+| **Deferred cleanup** (Go defer, Python with, C++ RAII)   | Erros em cleanup ignorados (ex: close() falha em escrita)                       |
+
+### Quando silenciamento é aceitável
+
+Não reportar como critical se:
+
+- **Cleanup code** — tentativa de deletar temp file em finally/defer. Falha não é crítica
+- **Feature detection** — testar se recurso existe, catch para saber que não existe
+- **Documentado** — catch com comentário explicando por que é intencional
+- **Best-effort** — operações explicitamente opcionais (ex: enviar analytics, prefetch de cache)
+
+---
+
+## When NOT to Report
+
+### Test code
+
+Arquivos em diretórios ou com padrões de teste:
+
+- `*.test.*`, `*.spec.*`, `__tests__/`, `test_*`, `*_test.go`, `*_test.py`, `*_test.rs`, `*Test.java`, `*_test.rb`, `tests/`, `spec/`
+- Exceção: se o teste usa input de PRODUÇÃO ou segredos reais → reportar
+
+### Static/literal input
+
+- O valor perigoso é uma string fixa no código, não controlada pelo usuário
+- `eval("2 + 2")` é code smell, não vulnerabilidade
+- Pode ser mencionado como ℹ info, nunca como 🔴 critical
+
+### Sanitization present
+
+- Existe validação/sanitização entre a fonte de input e a operação perigosa
+- Procurar: schema validation, type guards, sanitization functions, parameterized queries, middleware de validação
+- Se a sanitização está presente mas é insuficiente → reportar com contexto
+
+### Generated code
+
+- Arquivos com header de auto-geração, em diretórios de código gerado (ex: `components/ui/`, migrations geradas por ORM, código de protobuf)
+- Vulnerabilidades devem ser reportadas ao gerador, não corrigidas inline
+
+### Dependencies
+
+- Código em diretórios de dependência (`node_modules/`, `vendor/`, `site-packages/`, `.cargo/`, `Pods/`, etc.)
+- Escopo de ferramentas de auditoria de dependências, não desta revisão
+
+### Secret exceptions
+
+| Situação                                                             | Por quê                                                                |
+| -------------------------------------------------------------------- | ---------------------------------------------------------------------- |
+| Valores em `.env.example` / `.env.template`                          | Placeholders, não segredos reais                                       |
+| Referências a variáveis de ambiente (leitura, não valor)             | Estão usando env vars corretamente                                     |
+| Valores em arquivos de teste que são claramente mock                 | Fixtures intencionais                                                  |
+| Keys de modo teste de providers (ex: `sk_test_`, `pk_test_`)         | Keys de teste são públicas por design                                  |
+| Keys de exemplo em documentação                                      | Exemplos pedagógicos                                                   |
+| Variáveis marcadas como públicas pelo framework (ex: `NEXT_PUBLIC_`) | Intencionalmente públicas — mas verificar que não contêm secrets reais |
+
+---
+
+## When to ALWAYS Report
+
+Independente de contexto — estas são sempre vulnerabilidades:
+
+| Situação                                                                           | Por quê                                       |
+| ---------------------------------------------------------------------------------- | --------------------------------------------- |
+| Secrets de produção hardcoded (live API keys, SSH private keys, credentials reais) | Compromisso imediato se repositório é público |
+| `.env` com valores reais commitado no git                                          | Credenciais no git history permanentemente    |
+| Desserialização insegura de dados de rede                                          | Arbitrary code execution                      |
+| Shell execution com input de usuário não sanitizado                                | Command injection                             |
+| Permissões excessivas em filesystem (world-writable, 777)                          | Qualquer processo pode modificar              |
+| Private key no repositório                                                         | Compromisso criptográfico                     |
+
+---
+
+## Migration and Schema Changes
+
+### Operações destrutivas
+
+| Operação                     | Risco                                    | Verificação necessária                                           |
+| ---------------------------- | ---------------------------------------- | ---------------------------------------------------------------- |
+| DROP TABLE / DROP COLLECTION | Perda de dados irreversível              | Backup confirmado. Dados migrados antes                          |
+| DROP COLUMN / Remove field   | Perda de dados da coluna                 | Confirmar que campo não é usado. Deploy em fases                 |
+| TRUNCATE / Delete all        | Deleta todos os registros                | Nunca em migration de produção sem backup                        |
+| ALTER TYPE / Change schema   | Pode falhar com dados existentes         | Testar com dados reais. Considerar nova coluna + migrar + dropar |
+| RENAME                       | Quebra código que referencia nome antigo | Deploy em fases com período de compatibilidade                   |
+
+### Seed files
+
+- Sem passwords reais em seeds
+- Sem API keys de produção em dados de seed
+- Sem PII real (usar dados fake)
+- Guard de ambiente: seeds não devem ser executáveis em produção
+
+### Permissões
+
+| Contexto                 | Princípio                                                   |
+| ------------------------ | ----------------------------------------------------------- |
+| User da aplicação        | Apenas CRUD nas tabelas da app. Sem CREATE/DROP/ALTER/GRANT |
+| User de migration        | Pode ter DDL. Não deve ser usado pelo app em runtime        |
+| Connection string do app | Apontar para user da aplicação, não admin/root              |
+| Backups                  | SELECT apenas                                               |
+| Row-level security       | Habilitar em tabelas multi-tenant onde suportado            |

package/skills/hefesto-simplify/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: hefesto-simplify
+description: >
+  Revisão de código para reuso, qualidade e eficiência. Corrige issues preservando funcionalidade.
+  ATIVAR quando: "simplificar", "refatorar", "code review", "código duplicado", "limpar código",
+  "otimizar", "extrair pra lib", "checar qualidade", "código repetido", "performance".
+  Também: revisar reuso de utilitários, code smells, leaky abstractions, memory leaks.
+user-invocable: true
+disable-model-invocation: false
+argument-hint: '[arquivos ou escopo opcional]'
+---
+
+# Hefesto Simplify
+
+Revisão de código modificado focada em reuso, qualidade e eficiência. Corrige issues encontradas preservando funcionalidade.
+
+## Fase 1 — Identificar Escopo
+
+Rodar `git diff` (ou `git diff HEAD` se houver staged changes) para ver o que mudou. Determinar o escopo:
+
+1. Se argumentos foram fornecidos (paths de arquivos), usar esses arquivos como escopo
+2. Senão, identificar a feature ativa:
+   - Ler `.hefesto/STATE.md` → seção "Feature Ativa"
+   - Se houver feature ativa, ler o frontmatter do arquivo da feature em `.hefesto/features/`
+   - Usar `git diff --name-only` para listar arquivos modificados e não comitados
+3. Fallback: `git diff --name-only HEAD~1`
+4. Se nenhuma mudança no git, revisar os arquivos mais recentemente modificados que o usuário mencionou ou que foram editados anteriormente na conversa
+5. Filtrar: incluir apenas arquivos de código-fonte (`.ts`, `.tsx`, `.js`, `.jsx`, `.py`, `.go`, `.rs`, `.java`, etc.). Excluir: `node_modules/`, `.next/`, `dist/`, `build/`, arquivos de configuração, lockfiles, testes, arquivos gerados
+
+## Fase 2 — Lançar Três Agentes de Revisão em Paralelo
+
+Usar a ferramenta Agent para lançar os três agentes concorrentemente em uma única mensagem. Passar para cada agente o diff completo para que tenha o contexto completo.
+
+### Agent 1: Code Reuse Review
+
+Para cada mudança:
+
+1. **Buscar utilitários e helpers existentes** que possam substituir código recém-escrito. Procurar padrões similares em outros lugares do codebase — locais comuns são diretórios de utilitários, módulos compartilhados e arquivos adjacentes aos modificados
+2. **Flaggar qualquer função nova que duplica funcionalidade existente.** Sugerir a função existente para usar no lugar
+3. **Flaggar lógica inline que poderia usar utilitário existente** — manipulação de string manual, path handling customizado, checks de ambiente ad-hoc, type guards manuais e padrões similares são candidatos comuns
+4. **Duplicação cross-feature**: para funções exportadas nos arquivos do escopo, grep pelo nome em todo o projeto (excluindo o arquivo de origem). Se encontrar implementação idêntica ou muito similar em outro local, flaggar e sugerir extração para módulo compartilhado
+5. **Helpers não externalizados**: identificar funções helper definidas dentro de componentes/módulos que não dependem de state/props local e são genéricas o suficiente para compartilhar. Verificar se já existe algo similar nos diretórios compartilhados do projeto
+
+### Agent 2: Code Quality Review
+
+Revisar as mesmas mudanças para padrões problemáticos:
+
+1. **Redundant state**: state que duplica state existente, valores cacheados que poderiam ser derivados, observers/effects que poderiam ser chamadas diretas
+2. **Parameter sprawl**: adicionar novos parâmetros a uma função ao invés de generalizar ou reestruturar os existentes
+3. **Copy-paste com variação leve**: blocos de código near-duplicate que deveriam ser unificados com uma abstração compartilhada
+4. **Leaky abstractions**: expor detalhes internos que deveriam ser encapsulados, ou quebrar boundaries de abstração existentes
+5. **Stringly-typed code**: usar strings raw onde constants, enums (string unions) ou branded types já existem no codebase
+6. **Unnecessary JSX nesting**: wrapper Boxes/elements que não adicionam valor de layout — verificar se props do componente interno (flexShrink, alignItems, etc.) já fornecem o comportamento necessário
+7. **Unnecessary comments**: comentários explicando O QUE o código faz (identificadores bem nomeados já fazem isso), narrando a mudança, ou referenciando task/caller — deletar; manter apenas WHY não óbvio (constraints escondidas, invariantes sutis, workarounds)
+8. **Ternários aninhados**: substituir por `if/else` ou `switch`. Um nível de ternário é ok; dois ou mais precisa simplificar
+9. **Nesting excessivo**: funções com mais de 3 níveis de indentação. Aplicar early return ou extrair subfunção
+10. **Código morto**: imports não usados, variáveis declaradas mas não referenciadas, branches de condição inalcançáveis
+11. **Nomes pouco descritivos**: variáveis de 1-2 letras (exceto iteradores `i`, `j`), nomes genéricos como `data`, `temp`, `result` quando o contexto permite ser mais específico
+12. **Abstrações prematuras**: wrappers que apenas chamam outra função sem adicionar lógica, abstrações de uso único (classes, interfaces, factories usadas por apenas um consumidor), configurabilidade excessiva (parâmetros que só têm um valor possível)
+13. **Padrões do projeto**: ler `CLAUDE.md` e `.hefesto/PROJECT.md` (se existir). Comparar código do escopo contra convenções estabelecidas — imports, naming conventions, error handling, estrutura de features. Reportar desvios
+
+### Agent 3: Efficiency Review
+
+Revisar as mesmas mudanças para eficiência:
+
+1. **Trabalho desnecessário**: computações redundantes, leituras de arquivo repetidas, chamadas de rede/API duplicadas, padrões N+1
+2. **Concorrência perdida**: operações independentes executadas sequencialmente quando poderiam ser paralelas
+3. **Hot-path bloat**: novo trabalho bloqueante adicionado a startup ou hot paths per-request/per-render
+4. **Updates recorrentes no-op**: updates de state/store dentro de polling loops, intervals, ou event handlers que disparam incondicionalmente — adicionar guard de change-detection para que consumidores downstream não sejam notificados quando nada mudou. Também: se uma função wrapper recebe um callback updater/reducer, verificar que respeita retornos same-reference (ou qualquer que seja o sinal de "sem mudança") — senão, early-return no-ops dos callers são silenciosamente derrotados
+5. **Checks de existência desnecessários**: verificar existência de arquivo/recurso antes de operar (anti-pattern TOCTOU) — operar diretamente e tratar o erro
+6. **Memory**: data structures unbounded, cleanup faltando, event listener leaks
+7. **Operações broad demais**: ler arquivos inteiros quando apenas uma porção é necessária, carregar todos os items quando filtrando por um
+
+## Fase 3 — Aplicar Correções
+
+Aguardar os três agentes completarem. Agregar os findings e corrigir cada issue diretamente. Se um finding é false positive ou não vale a pena endereçar, anotar e seguir em frente — não argumentar com o finding, apenas pular.
+
+Restrições: não modificar configs/testes/gerados, respeitar boundaries de packages em monorepo, rodar `verification.commands` após fixes.
+
+Relatório via `TPL-SIMPLIFY.md`. Omitir dimensões sem issues. Código limpo → confirmar sem relatório.
+
+Funciona sem `.hefesto/` (usa `git diff` e `CLAUDE.md`). Se invocado pelo `/hefesto-execute`, relatório vai para o Argos.

package/templates/TPL-CLAUDE.md

@@ -0,0 +1,54 @@
+# CLAUDE.md
+
+Este arquivo orienta o Claude Code (claude.ai/code) ao trabalhar com o código deste repositório.
+
+# {{PROJECT_NAME}}
+
+{{PROJECT_DESCRIPTION}}
+
+## Comandos
+
+{{COMMANDS}}
+
+## Arquitetura
+
+{{ARCHITECTURE}}
+
+## Convenções
+
+{{CONVENTIONS}}
+
+## Idioma
+
+- Comunicação com o usuário: Português BR
+- Identificadores de código: Inglês
+
+## Hefesto
+
+Este projeto usa o [Hefesto](https://www.npmjs.com/package/@lugom.io/hefesto) para gestão de features e desenvolvimento feature-driven.
+
+### Estrutura .hefesto/
+
+- `PROJECT.md` — Visão, restrições, features e decisões
+- `STATE.md` — Memória entre sessões (manter < 80 linhas)
+- `config.json` — Configuração e counters
+- `features/` — Documentos de feature (FEAT-NNN-slug.md)
+- `research/` — Documentos de pesquisa (RES-NNN-slug.md)
+- `DESIGN.md` — Contrato visual (cores, tipografia, componentes, tokens)
+
+### Skills disponíveis
+
+- `/hefesto-init` — Inicializar ou atualizar configuração do projeto
+- `/hefesto-new-feature` — Criar nova feature
+- `/hefesto-execute` — Executar implementação de feature (verificação + QA loop)
+- `/hefesto-debug` — Debugging sistemático (causa raiz → hipótese → fix)
+- `/hefesto-design` — Criar contrato visual do projeto
+- `/hefesto-security` — Auditoria de segurança (OWASP, secrets, boundaries)
+- `/hefesto-simplify` — Simplificação e reuso de código
+
+### Workflow
+
+1. Features seguem o ciclo: `draft` → `ready` → `active` → `done`
+2. Cada feature tem Fases de implementação (stories atômicas)
+3. `STATE.md` é atualizado a cada mudança de estado
+4. IDs são sequenciais e nunca reutilizados

package/templates/TPL-CONFIG.json

@@ -0,0 +1,19 @@
+{
+  "version": "{{HEFESTO_VERSION}}",
+  "project": {
+    "name": "",
+    "description": "",
+    "language": "pt-BR",
+    "platform": "",
+    "lang": "",
+    "monorepo": false
+  },
+  "runtime": "claude",
+  "feature": { "id_prefix": "FEAT", "counter": 0 },
+  "research": { "id_prefix": "RES", "counter": 0 },
+  "design": { "status": "none" },
+  "verification": {
+    "commands": [],
+    "auto_detect": true
+  }
+}