sinapse-ai 7.7.10 → 8.0.0

package/bin/utils/staged-secret-scan.js

@@ -62,6 +62,11 @@ function scanStagedFiles(files) {
       continue;
     }
 
+    // Skip security test files (they contain intentional fake patterns for testing detection)
+    if (filePath.startsWith('tests/security/') && filePath.endsWith('.test.js')) {
+      continue;
+    }
+
     const content = readStagedFile(filePath);
     const matches = findSecretMatches(content);
     for (const match of matches) {

package/docs/architecture-overview.md

@@ -0,0 +1,239 @@
+# Visao Geral da Arquitetura
+
+> Arquitetura de alto nivel do SINAPSE-AI para novos contribuidores e usuarios.
+
+---
+
+## Diagrama do Sistema
+
+```
++------------------------------------------------------------------+
+|                        SINAPSE-AI Framework                       |
+|                                                                   |
+|  +--------------------+    +----------------------------------+   |
+|  |    Constitution     |    |        SYNAPSE Engine            |   |
+|  |  (10 artigos)       |    |  (Pipeline de Contexto L0-L7)   |   |
+|  |  NON-NEGOTIABLE (6) |    |                                  |   |
+|  |  MUST (4)           |    |  L0: Agent Definition            |   |
+|  +--------------------+    |  L1: Dependencies                 |   |
+|                             |  L2: Project Config               |   |
+|  +--------------------+    |  L3: Story Context                |   |
+|  |    Hook System      |    |  L4: Session State               |   |
+|  |  Pre-commit hooks   |    |  L5: Memory                      |   |
+|  |  Pre-push hooks     |    |  L6: Enrichment                  |   |
+|  |  Validation gates   |    |  L7: Compaction                  |   |
+|  +--------------------+    +----------------------------------+   |
+|                                                                   |
+|  +------------------------------------------------------------+  |
+|  |                    Agent Ecosystem                          |  |
+|  |                                                              |  |
+|  |  Core (12 agentes)          Squads (18 dominios)            |  |
+|  |  +--------+  +--------+    +--------+  +--------+          |  |
+|  |  | Pixel  |  | Litmus |    | Brand  |  | Growth |  ...     |  |
+|  |  | (dev)  |  | (qa)   |    | Squad  |  | Squad  |          |  |
+|  |  +--------+  +--------+    +--------+  +--------+          |  |
+|  |  +--------+  +--------+    163 especialistas               |  |
+|  |  |Stratum |  |Pipeline|    em 18 squads tematicos           |  |
+|  |  | (arch) |  |(devops)|                                     |  |
+|  |  +--------+  +--------+                                     |  |
+|  +------------------------------------------------------------+  |
+|                                                                   |
+|  +------------------------------------------------------------+  |
+|  |                    Quality Gates                            |  |
+|  |  Pre-commit (hooks) → PR Automation (CI) → Human Review    |  |
+|  +------------------------------------------------------------+  |
++------------------------------------------------------------------+
+```
+
+---
+
+## Conceitos Fundamentais
+
+### Agentes
+
+Agentes sao personas especializadas com expertise, comandos e responsabilidades definidas. Cada agente opera dentro de um escopo de autoridade exclusivo.
+
+- **12 agentes core** cobrem o ciclo completo de desenvolvimento de software
+- **163 agentes em 18 squads** expandem para dominios especializados
+- Cada agente tem persona (nome, estilo), comandos (`*help`, `*task`) e dependencias
+
+Ativacao: `@agent-name` ou `/SINAPSE:agents:agent-name`
+
+### Squads
+
+Squads sao agrupamentos tematicos de agentes especialistas, cada um com um orquestrador (*-orqx) que coordena o trabalho interno.
+
+Exemplos: squad-brand (branding), squad-growth (SEO/analytics), squad-cybersecurity (seguranca).
+
+### Tasks
+
+Tasks sao procedimentos passo-a-passo escritos em linguagem natural (markdown). Definem inputs, outputs, pre/post-conditions e modos de execucao. Tasks sao a unidade atomica de trabalho --- agentes sao executores de tasks.
+
+Localizacao: `.sinapse-ai/development/tasks/`
+
+### Workflows
+
+Workflows conectam tasks em sequencias. O SINAPSE tem 4 workflows primarios (detalhados em [workflows-overview.md](guides/workflows-overview.md)):
+
+1. **Story Development Cycle (SDC)** --- fluxo principal de desenvolvimento
+2. **QA Loop** --- ciclo iterativo de revisao-correcao
+3. **Spec Pipeline** --- transformacao de requisitos em especificacao
+4. **Brownfield Discovery** --- avaliacao de divida tecnica
+
+### Constitution
+
+10 artigos que governam o comportamento de todos os agentes. 6 sao NON-NEGOTIABLE (enforcement automatico via gates), 4 sao MUST (obrigatorios mas sem gate automatico).
+
+Detalhes: `.sinapse-ai/constitution.md`
+
+### Hooks
+
+Scripts executados automaticamente em momentos especificos (pre-commit, pre-push, pre-tool-use). Implementam o enforcement deterministico dos artigos constitucionais.
+
+Detalhes: `.claude/rules/hook-governance.md`
+
+---
+
+## Modelo de 4 Camadas (Boundary Model)
+
+O SINAPSE separa artefatos em 4 camadas com mutabilidade crescente:
+
+```
++------------------------------------------+
+|  L1: Framework Core (NEVER modify)       |
+|  .sinapse-ai/core/, constitution.md,     |
+|  bin/sinapse.js, bin/sinapse-init.js      |
++------------------------------------------+
+|  L2: Framework Templates (NEVER modify)  |
+|  tasks/, templates/, checklists/,        |
+|  workflows/, infrastructure/             |
++------------------------------------------+
+|  L3: Project Config (Mutable)            |
+|  .sinapse-ai/data/, core-config.yaml,    |
+|  agents/*/MEMORY.md                      |
++------------------------------------------+
+|  L4: Project Runtime (ALWAYS modify)     |
+|  docs/stories/, packages/, squads/,      |
+|  tests/                                  |
++------------------------------------------+
+```
+
+| Camada | Mutabilidade | Quem edita |
+|--------|-------------|------------|
+| L1 Core | NUNCA | Apenas framework maintainers |
+| L2 Templates | NUNCA | Extend-only (criar novos, nao editar existentes) |
+| L3 Config | Com restricoes | Projeto e agentes |
+| L4 Runtime | SEMPRE | Todo trabalho de projeto acontece aqui |
+
+**Toggle:** `core-config.yaml` → `boundary.frameworkProtection` controla se deny rules estao ativas.
+
+---
+
+## Fluxo de Ativacao de Agentes
+
+Quando um usuario ativa um agente (`@developer`), o seguinte pipeline executa:
+
+```
+1. Usuario digita @developer
+        |
+        v
+2. SYNAPSE Engine detecta ativacao
+        |
+        v
+3. Pipeline de Contexto (8 camadas L0-L7)
+   L0: Carrega definicao do agente (persona, comandos)
+   L1: Resolve dependencias (tasks, templates)
+   L2: Carrega config do projeto (core-config.yaml)
+   L3: Injeta contexto da story ativa (se houver)
+   L4: Restaura estado da sessao
+   L5: Carrega memoria do agente
+   L6: Enriquece com dados contextuais
+   L7: Compacta para caber na janela de contexto
+        |
+        v
+4. Greeting personalizado exibido
+        |
+        v
+5. Agente HALT --- aguarda comando do usuario
+```
+
+O agente NAO executa nenhuma acao automaticamente apos ativacao. Ele apresenta o greeting e aguarda.
+
+---
+
+## SYNAPSE Context Engine
+
+O SYNAPSE e o motor que injeta contexto relevante na janela de cada agente. Opera em 8 camadas:
+
+| Camada | Nome | Conteudo |
+|--------|------|----------|
+| L0 | Agent Definition | Persona, comandos, expertise |
+| L1 | Dependencies | Tasks, templates, checklists necessarios |
+| L2 | Project Config | core-config.yaml, tech preferences |
+| L3 | Story Context | Story ativa, acceptance criteria, progresso |
+| L4 | Session State | Agente ativo, contador de prompts |
+| L5 | Memory | Memoria persistente do agente |
+| L6 | Enrichment | Dados adicionais (git status, project status) |
+| L7 | Compaction | Reducao para caber na janela de contexto |
+
+**Diagnostico:** `npx sinapse-ai doctor` verifica a saude do pipeline.
+
+---
+
+## Quality Gates (3 Camadas)
+
+O SINAPSE implementa qualidade em 3 camadas progressivas:
+
+### Camada 1: Pre-Commit (Local)
+
+Hooks executam automaticamente antes de cada commit:
+
+- `enforce-story-gate.cjs` --- exige story valida
+- `enforce-architecture-first.cjs` --- exige docs antes de codigo protegido
+- `sql-governance.py` --- bloqueia SQL inseguro
+- `enforce-git-push-authority.sh` --- restringe push a @devops
+
+### Camada 2: PR Automation (CI)
+
+Apos push, automacoes de CI executam:
+
+- **CodeRabbit** --- review automatizado de codigo
+- **GitHub Actions** --- lint, typecheck, testes
+- **Dependabot** --- verificacao de dependencias
+- **CodeQL** --- analise de seguranca
+
+### Camada 3: Human Review
+
+Apos automacoes passarem:
+
+- @quality-gate (Litmus) executa QA gate com 7 checks
+- Reviewer humano aprova o PR
+- Merge so ocorre apos aprovacao
+
+```
+Commit → Hooks (BLOCK/PASS) → Push → CI (BLOCK/PASS) → Review → Merge
+```
+
+---
+
+## Como Tudo se Conecta
+
+O SINAPSE e um meta-framework de linguagem natural. Nao contem codigo de aplicacao --- contem instrucoes em markdown que agentes de IA seguem para construir software.
+
+**O ciclo completo:**
+
+1. **Usuario descreve o que quer** (em linguagem natural)
+2. **Imperator** (orquestrador principal) diagnostica e delega
+3. **@sprint-lead (Sync)** cria a story documentando o trabalho
+4. **@product-lead (Axis)** valida a story (10 criterios)
+5. **@developer (Pixel)** implementa seguindo a story
+6. **@quality-gate (Litmus)** verifica qualidade (7 checks)
+7. **@devops (Pipeline)** faz push e cria PR
+8. **CI + Review** garantem qualidade antes do merge
+9. **Constitution + Hooks** garantem que nenhuma etapa foi pulada
+
+Cada etapa e rastreavel, documentada e verificavel. O sistema e desenhado para que erros sejam detectados o mais cedo possivel --- idealmente antes de qualquer codigo ser escrito.
+
+---
+
+_Veja tambem: [Agent Reference](guides/agent-reference.md) | [Workflows Overview](guides/workflows-overview.md) | [Guiding Principles](guiding-principles.md)_

package/docs/community.md

@@ -158,7 +158,7 @@ Report violations to: conduct@SinapseAI.com
 
 1. Check if it exists in [Ideas](https://github.com/SinapseAI/sinapse-ai/discussions/categories/ideas)
 2. If new, [share your idea](https://github.com/SinapseAI/sinapse-ai/discussions/new?category=ideas)
-3. Read our [Feature Request Process](docs/FEATURE_PROCESS.md) for detailed guidelines
+3. Read our [Feature Request Process](docs/feature-process.md) for detailed guidelines
 
 ## Project Roadmap
 
@@ -184,7 +184,7 @@ We have a structured process for proposing new features:
 3. **Community Voting** - Use :+1: reactions to show support
 4. **Implementation** - Approved ideas move to our backlog
 
-See [Feature Request Process](docs/FEATURE_PROCESS.md) for complete details.
+See [Feature Request Process](docs/feature-process.md) for complete details.
 
 ## Resources
 

package/docs/feature-process.md

@@ -0,0 +1,162 @@
+# Processo de Propostas de Features
+
+> Como propor novas funcionalidades para o SINAPSE-AI.
+
+---
+
+## Visao Geral
+
+O SINAPSE segue o principio de Documentation-First (Constitution Art. III). Toda feature --- desde uma ideia simples ate uma mudanca arquitetural --- passa por um pipeline documentado antes de qualquer implementacao.
+
+```
+Ideia → Discussao → Decisao → Story → Implementacao → Release
+```
+
+---
+
+## Passo 1: Abra uma Discussion ou Issue
+
+**Para ideias e sugestoes:**
+- Abra uma [Discussion](../../discussions) na categoria **Ideas**
+- Descreva o problema que a feature resolve
+- Proponha uma solucao (pode ser alto nivel)
+- Inclua exemplos de uso se possivel
+
+**Para bugs ou melhorias pontuais:**
+- Abra uma [Issue](../../issues) usando o template **Feature Request** ou **Bug Report**
+- Preencha todos os campos do template
+
+---
+
+## Passo 2: Periodo de Feedback (7 dias)
+
+A comunidade e os maintainers revisam a proposta durante 7 dias:
+
+- Use reacoes (+1) para mostrar apoio
+- Comente com sugestoes, preocupacoes ou alternativas
+- Maintainers podem pedir esclarecimentos
+
+**Dica:** propostas com exemplos concretos e justificativa clara tem mais chances de aceitacao.
+
+---
+
+## Passo 3: Decisao dos Maintainers
+
+Apos o periodo de feedback, os maintainers tomam uma decisao:
+
+| Decisao | Significado | Proximo Passo |
+|---------|-------------|---------------|
+| **Aceita** | Feature aprovada para implementacao | Segue para Passo 4 |
+| **Adiada** | Valida, mas nao prioritaria agora | Fica no backlog |
+| **Rejeitada** | Nao alinha com a visao do projeto | Explicacao fornecida |
+
+### Criterios de Decisao
+
+- **Alinhamento com a Constitution:** a feature respeita os 10 artigos?
+- **Compatibilidade retroativa:** quebra algo existente?
+- **Carga de manutencao:** o custo de manter justifica o beneficio?
+- **Demanda da comunidade:** quantas pessoas precisam disso?
+- **Escopo:** e core framework ou pertence a um squad?
+
+### Quem Decide
+
+| Maintainer | GitHub | Papel |
+|-----------|--------|-------|
+| Caio Imori | @caioimori | Lead maintainer |
+| Matheus Soier | @Matheus-soier | Co-maintainer |
+
+---
+
+## Passo 4: Criacao de Story (se aceita)
+
+Toda feature aceita segue o pipeline Documentation-First:
+
+1. @sprint-lead (Sync) cria a story em `docs/stories/`
+2. Story inclui: acceptance criteria, escopo IN/OUT, dependencias, estimativa
+3. @product-lead (Axis) valida a story (checklist de 10 pontos)
+4. Story recebe status **Ready** apos validacao
+
+**Nenhum codigo e escrito antes da story estar validada.**
+
+---
+
+## Passo 5: Implementacao via SDC
+
+A implementacao segue o Story Development Cycle (SDC):
+
+```
+@sprint-lead *draft → @product-lead *validate → @developer *develop → @quality-gate *qa-gate → @devops *push
+```
+
+O contribuidor pode implementar a feature seguindo o [CONTRIBUTING.md](../CONTRIBUTING.md).
+
+---
+
+## Mudancas Significativas: Processo de RFC
+
+Para mudancas que impactam arquitetura, APIs publicas ou o comportamento do framework:
+
+### Quando Escrever um RFC
+
+- Novas funcionalidades de grande porte
+- Breaking changes em APIs ou comportamento existente
+- Mudancas arquiteturais significativas
+- Alteracoes que afetam muitos usuarios
+
+### Como Criar um RFC
+
+1. Crie um PR com o arquivo `docs/rfcs/RFC-NNN.md`
+2. Use o template de RFC disponivel em `.github/RFC_TEMPLATE.md`
+3. O PR serve como espaco de discussao
+4. Periodo de review: minimo 14 dias
+
+### Ciclo de Vida do RFC
+
+```
+Draft → Em Revisao (14 dias) → Decisao (Aceito/Rejeitado) → Implementacao
+```
+
+---
+
+## De Ideia a Release
+
+```
+Comunidade propoe (Discussion/Issue)
+        |
+        | [Aprovada pelos maintainers]
+        v
+Backlog interno
+        |
+        | [Priorizada por @product-lead (Axis)]
+        v
+Sprint Planning
+        |
+        | [Story criada por @sprint-lead (Sync)]
+        v
+Implementacao (SDC)
+        |
+        | [QA Gate por @quality-gate (Litmus)]
+        v
+Release (creditada no CHANGELOG.md)
+```
+
+---
+
+## Credito ao Contribuidor
+
+Contribuidores cujas ideias sao implementadas recebem credito em:
+
+- **CHANGELOG.md** nas notas de release
+- **PR** que implementa a feature
+- **Discussion** original marcada como resolvida
+
+---
+
+## Perguntas?
+
+- Abra uma Discussion na categoria **Q&A**
+- Consulte o [Troubleshooting Guide](troubleshooting.md)
+
+---
+
+_Veja tambem: [CONTRIBUTING.md](../CONTRIBUTING.md) | [Guiding Principles](guiding-principles.md) | [Code of Conduct](../CODE_OF_CONDUCT.md)_