sinapse-ai 7.7.11 → 8.0.0

package/docs/guides/workflows-overview.md

@@ -0,0 +1,282 @@
+# Visao Geral dos Workflows
+
+> Os 4 workflows primarios do SINAPSE-AI com diagramas visuais.
+
+---
+
+## 1. Story Development Cycle (SDC)
+
+**O workflow principal.** Todo desenvolvimento de software segue este ciclo.
+
+```
+  Phase 1         Phase 2          Phase 3          Phase 4         Phase 5
+  CREATE          VALIDATE         IMPLEMENT        QA GATE         DEPLOY
++----------+   +----------+   +-------------+   +----------+   +----------+
+|  @sprint |   | @product |   | @developer  |   | @quality |   | @devops  |
+|  -lead   |-->|  -lead   |-->|   (Pixel)   |-->|  -gate   |-->|(Pipeline)|
+|  (Sync)  |   |  (Axis)  |   |             |   | (Litmus) |   |          |
++----------+   +----------+   +-------------+   +----------+   +----------+
+| *draft   |   | *validate|   | *develop    |   | *qa-gate |   | *push    |
+| Story    |   | 10-point |   | YOLO/Inter/ |   | 7 checks |   | PR +     |
+| criada   |   | checklist|   | Pre-Flight  |   | PASS/FAIL|   | Review   |
++----------+   +----------+   +-------------+   +----------+   +----------+
+  Status:        Status:         Status:          Status:        Status:
+  Draft          Ready           InProgress       InReview       Done
+```
+
+### Fases Detalhadas
+
+**Phase 1: Create** (@sprint-lead / Sync)
+- Cria story em `docs/stories/` com template padrao
+- Define: titulo, descricao, acceptance criteria, escopo IN/OUT, dependencias
+- Status inicial: **Draft**
+
+**Phase 2: Validate** (@product-lead / Axis)
+- Aplica checklist de 10 pontos:
+  1. Titulo claro e objetivo
+  2. Descricao completa
+  3. Acceptance criteria testaveis (Given/When/Then)
+  4. Escopo bem definido (IN e OUT)
+  5. Dependencias mapeadas
+  6. Estimativa de complexidade
+  7. Valor de negocio claro
+  8. Riscos documentados
+  9. Criterios de Done definidos
+  10. Alinhamento com PRD/Epic
+- Decisao: GO (>=7/10) ou NO-GO (com fixes obrigatorios)
+- Status apos GO: **Ready**
+
+**Phase 3: Implement** (@developer / Pixel)
+- Tres modos de execucao:
+  - **YOLO:** autonomo, 0-1 prompts, decisoes logadas
+  - **Interactive:** 5-10 prompts, checkpoints educacionais
+  - **Pre-Flight:** perguntas upfront, plano antes de executar
+- CodeRabbit self-healing: max 2 iteracoes para issues CRITICAL
+- Status: **InProgress**
+
+**Phase 4: QA Gate** (@quality-gate / Litmus)
+- 7 verificacoes de qualidade:
+  1. Code review (padroes, legibilidade)
+  2. Testes unitarios (cobertura, todos passando)
+  3. Acceptance criteria (todos atendidos)
+  4. Sem regressoes
+  5. Performance aceitavel
+  6. Seguranca (OWASP basico)
+  7. Documentacao atualizada
+- Verdicts: PASS | CONCERNS | FAIL | WAIVED
+- Status apos PASS: **InReview**
+
+**Phase 5: Deploy** (@devops / Pipeline)
+- `git push` para remote (autoridade EXCLUSIVA)
+- Cria PR com reviewer assignment
+- CI executa (lint, typecheck, testes)
+- Apos aprovacao e merge: **Done**
+
+---
+
+## 2. QA Loop
+
+**Ciclo iterativo de revisao-correcao.** Usado apos o QA Gate inicial quando issues sao encontradas.
+
+```
+                    +---> APPROVE ---> Done
+                    |
++----------+   +---+----+   +----------+
+| @quality |   |        |   |@developer|
+|  -gate   |-->| Verdict|   | (Pixel)  |
+| (Litmus) |   |        |   |          |
++----------+   +---+----+   +----------+
+     ^              |              |
+     |              +---> REJECT --+
+     |                    (fixes)  |
+     +-----------------------------+
+          max 5 iteracoes
+```
+
+### Fluxo
+
+```
+@quality-gate review
+        |
+        v
+    Verdict?
+   /    |    \
+APPROVE REJECT BLOCKED
+  |       |       |
+  v       v       v
+ Done   @dev    Escalate
+        fixes   imediato
+          |
+          v
+       Re-review
+    (volta ao topo)
+```
+
+### Comandos
+
+| Comando | Funcao |
+|---------|--------|
+| `*qa-loop {storyId}` | Inicia o loop |
+| `*qa-loop-review` | Resume da fase de review |
+| `*qa-loop-fix` | Resume da fase de fix |
+| `*stop-qa-loop` | Pausa e salva estado |
+| `*resume-qa-loop` | Resume do estado salvo |
+| `*escalate-qa-loop` | Forca escalacao manual |
+
+### Regras
+
+- **Maximo 5 iteracoes** --- apos isso, escalacao automatica
+- **3 verdicts possiveis:**
+  - APPROVE: completo, marca Done
+  - REJECT: @developer corrige, re-review
+  - BLOCKED: escalacao imediata
+
+### Triggers de Escalacao
+
+- `max_iterations_reached` (atingiu 5 iteracoes)
+- `verdict_blocked` (issue que @developer nao pode resolver)
+- `fix_failure` (tentativa de fix falhou)
+- `manual_escalate` (usuario forcou escalacao)
+
+---
+
+## 3. Spec Pipeline
+
+**Transforma requisitos informais em especificacao executavel.** Usado antes do SDC para features complexas.
+
+```
+  Phase 1       Phase 2       Phase 3       Phase 4       Phase 5       Phase 6
+  GATHER        ASSESS        RESEARCH      WRITE         CRITIQUE      PLAN
++----------+ +----------+ +----------+ +----------+ +----------+ +----------+
+| @project | |@architect| | @analyst | | @project | | @quality | |@architect|
+|  -lead   | | (Stratum)| |  (Scope) | |  -lead   | |  -gate   | | (Stratum)|
+| (Beacon) | |          | |          | | (Beacon) | | (Litmus) | |          |
++----------+ +----------+ +----------+ +----------+ +----------+ +----------+
+| require- | |complexity| | research | | spec.md  | | critique | | impl.    |
+| ments    | |   .json  | |   .json  | | completo | |   .json  | |   .yaml  |
+| .json    | |          | |          | |          | |          | |          |
++----------+ +----------+ +----------+ +----------+ +----------+ +----------+
+                                                          |
+                                                     >=4.0? APPROVED
+                                                     3.0-3.9? NEEDS_REVISION
+                                                     <3.0? BLOCKED
+```
+
+### Classes de Complexidade
+
+A complexidade e avaliada em 5 dimensoes (1-5 cada):
+
+| Dimensao | O que avalia |
+|----------|-------------|
+| Scope | Quantidade de arquivos afetados |
+| Integration | APIs e servicos externos |
+| Infrastructure | Mudancas de infraestrutura |
+| Knowledge | Familiaridade da equipe |
+| Risk | Criticidade e impacto |
+
+| Score Total | Classe | Fases Executadas |
+|-------------|--------|-----------------|
+| <= 8 | SIMPLE | 1, 4, 5 (3 fases) |
+| 9-15 | STANDARD | Todas as 6 fases |
+| >= 16 | COMPLEX | 6 fases + ciclo de revisao |
+
+### Gate Constitucional (Art. IV)
+
+Todo statement em `spec.md` DEVE rastrear para:
+- Requisito funcional (FR-*)
+- Requisito nao-funcional (NFR-*)
+- Constraint (CON-*)
+- Finding de research documentado
+
+**Nenhuma feature inventada e permitida.**
+
+---
+
+## 4. Brownfield Discovery
+
+**Avaliacao de divida tecnica em 10 fases.** Usado ao entrar em um projeto existente.
+
+```
+  DATA COLLECTION (1-3)        DRAFT & VALIDATION (4-7)      FINALIZATION (8-10)
++------------------------+   +-------------------------+   +---------------------+
+|                        |   |                         |   |                     |
+| Phase 1: @architect    |   | Phase 4: @architect     |   | Phase 8: @architect |
+|   system-architecture  |   |   tech-debt-DRAFT       |   |   tech-debt (final) |
+|                        |   |                         |   |                     |
+| Phase 2: @data-engineer|   | Phase 5: @data-engineer |   | Phase 9: @analyst   |
+|   SCHEMA + DB-AUDIT    |   |   db-specialist-review  |   |   TECH-DEBT-REPORT  |
+|                        |   |                         |   |                     |
+| Phase 3: @ux-design    |   | Phase 6: @ux-design     |   | Phase 10: @project  |
+|   frontend-spec        |   |   ux-specialist-review  |   |   -lead: Epic +     |
+|                        |   |                         |   |   stories prontas   |
+|                        |   | Phase 7: @quality-gate  |   |                     |
+|                        |   |   QA review (APPROVED   |   |                     |
+|                        |   |   ou NEEDS WORK)        |   |                     |
++------------------------+   +-------------------------+   +---------------------+
+```
+
+### Fases
+
+| Fase | Agente | Output |
+|------|--------|--------|
+| 1 | @architect (Stratum) | `system-architecture.md` |
+| 2 | @data-engineer (Tensor) | `SCHEMA.md` + `DB-AUDIT.md` |
+| 3 | @ux-design-expert (Mosaic) | `frontend-spec.md` |
+| 4 | @architect (Stratum) | `technical-debt-DRAFT.md` |
+| 5 | @data-engineer (Tensor) | `db-specialist-review.md` |
+| 6 | @ux-design-expert (Mosaic) | `ux-specialist-review.md` |
+| 7 | @quality-gate (Litmus) | `qa-review.md` |
+| 8 | @architect (Stratum) | `technical-debt-assessment.md` (final) |
+| 9 | @analyst (Scope) | `TECHNICAL-DEBT-REPORT.md` (executivo) |
+| 10 | @project-lead (Beacon) | Epic + stories prontas para SDC |
+
+**QA Gate (Fase 7):**
+- APPROVED: debitos validados, sem gaps criticos
+- NEEDS WORK: gaps nao endereados, volta para Fase 4
+
+---
+
+## Guia de Selecao de Workflow
+
+**Qual workflow usar em cada situacao?**
+
+| Situacao | Workflow | Por que |
+|----------|---------|---------|
+| Nova story de um epic | SDC | Fluxo padrao completo |
+| QA encontrou issues, precisa iterar | QA Loop | Ciclo automatico de fix-review |
+| Feature complexa precisa de spec | Spec Pipeline → SDC | Especificacao antes de implementacao |
+| Entrando em projeto existente | Brownfield Discovery | Mapear divida tecnica primeiro |
+| Bug fix simples | SDC (modo YOLO) | Fluxo padrao, execucao rapida |
+| Mudanca arquitetural | Spec Pipeline → SDC | Complexidade exige especificacao |
+
+### Arvore de Decisao
+
+```
+O trabalho e em projeto novo ou existente?
+  |
+  +-- Existente (primeira vez) --> Brownfield Discovery
+  |
+  +-- Ja conhego o projeto
+        |
+        +-- E uma feature complexa? --> Spec Pipeline, depois SDC
+        |
+        +-- E uma feature/bug normal? --> SDC direto
+              |
+              +-- QA encontrou issues? --> QA Loop
+```
+
+---
+
+## Modos de Execucao do @developer
+
+O SDC Phase 3 suporta 3 modos. Escolha baseado na situacao:
+
+| Modo | Prompts | Melhor Para |
+|------|---------|-------------|
+| **YOLO** | 0-1 | Tasks simples, deterministicas, baixo risco |
+| **Interactive** | 5-10 | Aprendizado, decisoes complexas, primeiro contato |
+| **Pre-Flight** | 10-15 upfront | Requisitos ambiguos, trabalho critico, alta complexidade |
+
+---
+
+_Veja tambem: [Agent Reference](agent-reference.md) | [Architecture Overview](../architecture-overview.md) | [Story Lifecycle](./../CONTRIBUTING.md)_

package/docs/guiding-principles.md

@@ -0,0 +1,188 @@
+# Principios Orientadores do SINAPSE
+
+> Filosofia por tras das decisoes de design do framework SINAPSE-AI.
+
+---
+
+## 1. CLI First
+
+**Por que CLI ao inves de UI?**
+
+O SINAPSE segue uma hierarquia rigorosa: CLI > Observabilidade > UI. Toda inteligencia, execucao e automacao vivem no CLI. Dashboards observam, mas nunca controlam.
+
+Essa decisao nao e estetica --- e estrutural. Agentes de IA operam em terminais. Interfaces graficas adicionam latencia, dependencias de runtime e pontos de falha entre o agente e a acao. Quando o CLI e a fonte da verdade, qualquer IDE compativel (Claude Code, Codex) consegue operar o framework sem camada intermediaria.
+
+**Implicacao pratica:** toda funcionalidade nova DEVE funcionar 100% via CLI antes de qualquer UI existir. Se nao funciona no terminal, nao esta pronto.
+
+> Constitution Art. I --- NON-NEGOTIABLE
+
+---
+
+## 2. Governanca Constitucional
+
+**Por que artigos formais com enforcement automatico?**
+
+O SINAPSE possui 10 artigos constitucionais que governam o comportamento de todos os 175 agentes. Cada artigo tem severidade definida (NON-NEGOTIABLE ou MUST) e gates automaticos que bloqueiam violacoes deterministicamente.
+
+A alternativa --- guidelines aspiracionais --- falha em escala. Quando 175 agentes operam em 18 dominios, regras que dependem de "boa vontade" sao violadas silenciosamente. Gates automaticos (hooks pre-commit, pre-push, validacoes de story) garantem que violacoes sao detectadas e bloqueadas antes de causar dano.
+
+**Exemplo:** o hook `enforce-git-push-authority.sh` bloqueia qualquer agente que nao seja @devops (Pipeline) de executar `git push`. Nao e uma sugestao --- e um bloqueio deterministico.
+
+> Constitution v2.2.0 --- 10 artigos, 6 NON-NEGOTIABLE, 4 MUST
+
+---
+
+## 3. Documentation-First Development
+
+**Por que stories antes de codigo?**
+
+Nenhuma linha de codigo e escrita sem uma story validada. O pipeline e automatico e inviolavel:
+
+```
+Briefing → Epic → Story → Validacao → Implementacao
+```
+
+Essa decisao nasce de experiencia pratica: codigo sem especificacao gera retrabalho. Stories com acceptance criteria claros (Given/When/Then) criam um contrato verificavel entre quem pede e quem implementa. O agente @product-lead (Axis) valida cada story antes que @developer (Pixel) toque em qualquer arquivo.
+
+**O que acontece se o usuario pedir "implementa rapido, sem story"?** O sistema RECUSA. Nao existe atalho. Mesmo bug fixes passam pelo pipeline de documentacao.
+
+> Constitution Art. III --- NON-NEGOTIABLE
+
+---
+
+## 4. Delegacao Obrigatoria
+
+**Por que orquestradores nunca executam trabalho de dominio?**
+
+Orquestradores (Imperator e todos os *-orqx) existem para rotear, diagnosticar e coordenar. Eles NUNCA escrevem codigo, criam schemas, fazem copy ou executam qualquer trabalho especializado. Sempre delegam ao agente correto.
+
+A razao e separacao de responsabilidades em escala. Um orquestrador que "faz tudo" acumula contexto desnecessario, perde especializacao e cria um ponto unico de falha. Quando Imperator recebe "implementa feature X", ele delega para @developer (Pixel). Quando recebe "audita a marca", delega para @brand-orqx (Meridian). Mesmo que o usuario diga "faz voce mesmo" --- o orquestrador delega.
+
+**Enforcement:** qualquer resposta de orquestrador contendo trabalho de dominio direto e uma violacao constitucional bloqueada automaticamente.
+
+> Constitution Art. VIII --- NON-NEGOTIABLE
+
+---
+
+## 5. Escala do Ecossistema de Agentes
+
+**Por que 175 agentes em 18 dominios?**
+
+O SINAPSE nao e um agente generalista. E um ecossistema de 175 especialistas organizados em 18 squads tematicos. Cada agente tem persona, expertise e comandos especificos para seu dominio.
+
+Essa arquitetura permite:
+
+- **Especializacao profunda:** um agente de copywriting (Quill) nao carrega contexto de database. Um data engineer (Tensor) nao carrega contexto de branding.
+- **Contexto otimizado:** cada agente carrega apenas as dependencias necessarias para seu dominio, preservando a janela de contexto para o trabalho real.
+- **Escalabilidade horizontal:** novos dominios sao adicionados como squads independentes, sem impactar o core.
+
+Os 12 agentes core cobrem o ciclo completo de desenvolvimento de software. Os 18 squads expandem para dominios como branding, growth, financeiro, cybersecurity e mais.
+
+| Camada | Agentes | Funcao |
+|--------|---------|--------|
+| Core | 12 agentes | Desenvolvimento de software completo |
+| Squads | 163 agentes em 18 dominios | Especializacao por dominio |
+| Total | 175 agentes | Ecossistema completo |
+
+> Constitution Art. VII --- metricas exatas, sempre sincronizadas
+
+---
+
+## 6. Enforcement via Hooks
+
+**Por que controles deterministicos ao inves de guidelines aspiracionais?**
+
+O SINAPSE usa hooks (scripts executados automaticamente em momentos especificos) para garantir que regras sejam seguidas. Cada hook tem comportamento definido:
+
+| Hook | O que faz | Comportamento |
+|------|-----------|---------------|
+| `enforce-git-push-authority.sh` | Bloqueia push por agentes nao-autorizados | BLOCK |
+| `sql-governance.py` | Bloqueia SQL perigoso (injection) | BLOCK |
+| `enforce-story-gate.cjs` | Exige story valida antes de codigo | BLOCK |
+| `enforce-delegation.cjs` | Impede orquestradores de executar dominio | BLOCK |
+| `enforce-architecture-first.cjs` | Exige docs antes de codigo protegido | BLOCK |
+
+**Principios de design dos hooks:**
+- **Fail-open:** se o hook crasha, a operacao continua (nunca bloqueia por bug)
+- **Rapidos:** cada hook completa em menos de 5 segundos
+- **Silenciosos no sucesso:** so produzem output quando bloqueiam ou alertam
+- **Deterministicos:** mesma entrada sempre produz mesma saida
+- **Sem efeitos colaterais:** hooks leem estado, nunca modificam
+
+> Detalhes completos: `.claude/rules/hook-governance.md`
+
+---
+
+## 7. Colaboracao Segura
+
+**Por que a complexidade do git e escondida dos usuarios?**
+
+Os usuarios do SINAPSE sao product builders, nao especialistas em git. Agentes DEVEM gerenciar toda a complexidade de versionamento automaticamente:
+
+- **Auto-branch:** nunca trabalhar em `main`. Criar branch automaticamente.
+- **Auto-sync:** `git fetch` + pull no inicio de toda sessao.
+- **Auto-resolve:** resolver conflitos simples automaticamente.
+- **Auto-PR:** criar PR com reviewer assignment apos push.
+- **Linguagem simples:** "salvei seu trabalho" ao inves de "commitei no HEAD".
+
+**Por que?** Porque merge conflicts, rebases e force pushes sao a maior fonte de perda de trabalho em equipes nao-tecnicas. O SINAPSE elimina essa classe inteira de problemas ao automatizar 100% do fluxo git.
+
+> Constitution Art. IX --- NON-NEGOTIABLE
+
+---
+
+## 8. Seguranca por Default
+
+**Por que 25 deployment blockers existem?**
+
+O SINAPSE define 25 verificacoes que DEVEM passar antes de qualquer deploy em producao. Sao organizadas em 3 tiers:
+
+| Tier | Quantidade | Consequencia de ignorar |
+|------|-----------|------------------------|
+| Tier 1: Absolute Blockers | 10 | Deploy impossivel |
+| Tier 2: Compliance Blockers | 7 | Deploy ilegal no Brasil (LGPD) |
+| Tier 3: Operational Blockers | 8 | Deploy irresponsavel |
+
+Essa decisao vem de licoes reais: os maiores vazamentos de dados de 2023-2025 (Change Healthcare: 192.7M afetados, Ticketmaster: 560M, 23andMe: 6.9M) tiveram como causa raiz a AUSENCIA de controles basicos como MFA e RLS.
+
+**Exemplos de blockers:**
+- Tabela sem RLS ativado
+- API keys hardcoded no codigo
+- `service_role` exposta no frontend
+- APIs sem autenticacao
+- Vulnerabilidades critical/high em dependencias
+
+> Constitution Art. X --- NON-NEGOTIABLE
+
+---
+
+## 9. Open Source com Standards
+
+**Por que MIT com quality gates?**
+
+O SINAPSE e distribuido sob licenca MIT --- qualquer pessoa pode usar, modificar e distribuir. Mas contribuicoes ao repositorio principal passam por quality gates rigorosos:
+
+- **3 camadas de qualidade:** pre-commit (hooks locais) → PR automation (CodeRabbit + CI) → human review
+- **Documentation-First:** toda contribuicao segue o pipeline de documentacao
+- **Constitution compliance:** nenhuma contribuicao pode violar os 10 artigos constitucionais
+- **Metricas exatas:** qualquer mudanca que altere contagem de squads/agentes deve atualizar TODOS os documentos que referenciam essas metricas
+
+Isso garante que o framework mantem coerencia e qualidade mesmo com contribuicoes externas.
+
+> Processo de contribuicao: [CONTRIBUTING.md](../CONTRIBUTING.md)
+
+---
+
+## Resumo
+
+| Principio | Por que existe | Enforcement |
+|-----------|---------------|-------------|
+| CLI First | Agentes operam em terminais | Hook WARN |
+| Governanca Constitucional | 175 agentes precisam de regras deterministicas | 10 artigos + gates |
+| Documentation-First | Codigo sem spec gera retrabalho | Hook BLOCK |
+| Delegacao Obrigatoria | Separacao de responsabilidades em escala | Hook BLOCK |
+| Ecossistema 175 Agentes | Especializacao profunda por dominio | Art. VII metricas |
+| Hooks Deterministicos | Guidelines aspiracionais falham em escala | 5+ hooks ativos |
+| Colaboracao Segura | Usuarios nao sao git experts | Auto-branch/sync/PR |
+| Seguranca por Default | Licoes de vazamentos reais | 25 blockers |
+| Open Source + Standards | Qualidade com contribuicoes externas | 3 camadas QA |

package/docs/legal/license-clarification.md

@@ -1,26 +1,131 @@
-# License Clarification (Core vs Pro)
+# Esclarecimento de Licenca — SINAPSE-AI
 
-**Last updated:** 2026-02-15
+**Ultima atualizacao:** 04 de abril de 2026
 
-This document clarifies the licensing boundary in SINAPSE.
+---
 
-## Scope
+## 1. Licenca do Nucleo (Core Framework)
 
-- `sinapse-ai` (this repository): **MIT**
-- `sinapse-pro` (private/proprietary module): separate license terms defined in that module/repository
+O pacote npm `sinapse-ai` e distribuido sob a **Licenca MIT**, uma das licencas open-source mais permissivas e amplamente adotadas.
 
-## What This Means
+O texto completo da licenca esta disponivel no arquivo `LICENSE` na raiz do repositorio.
 
-- The open-source core framework is MIT-licensed and can be used under MIT terms.
-- Commercial or proprietary restrictions, if any, belong to `sinapse-pro` and do not change the MIT license of `sinapse-ai`.
+---
 
-## Practical Guidance
+## 2. O que a Licenca MIT Permite
 
-- If you are using only `sinapse-ai`, follow MIT terms in `LICENSE`.
-- If you are using any `sinapse-pro` capability, also review and comply with `sinapse-pro` license terms.
+A Licenca MIT concede as seguintes liberdades, sem restricoes significativas:
 
-## Related Files
+| Permissao | Descricao |
+|-----------|-----------|
+| **Uso** | Utilizar o Software para qualquer finalidade, incluindo comercial |
+| **Modificacao** | Alterar o codigo-fonte conforme necessario |
+| **Distribuicao** | Redistribuir copias do Software original |
+| **Sublicenciamento** | Incluir o Software em projetos com outras licencas |
+| **Uso privado** | Utilizar sem obrigacao de publicar modificacoes |
 
-- `LICENSE` (root): MIT license for `sinapse-ai`
-- `docs/legal/terms.md`: terms of use for this repository
+### Unica obrigacao
 
+Manter o aviso de copyright e o texto da licenca em todas as copias ou porcoes substanciais do Software.
+
+---
+
+## 3. Cadeia de Direitos Autorais
+
+O SINAPSE-AI foi desenvolvido com inspiracao em padroes abertos de orquestracao de IA, amplamente difundidos na comunidade open-source. O arquivo `LICENSE` do projeto detalha a cadeia completa de direitos autorais, incluindo referencias a obras anteriores que foram distribuidas sob a Licenca MIT.
+
+### O que isso significa na pratica
+
+- O SINAPSE-AI e uma obra que incorpora e expande conceitos de projetos open-source anteriores
+- Todas as obras na cadeia foram distribuidas sob a Licenca MIT, garantindo compatibilidade total
+- O usuario final herda todas as liberdades da Licenca MIT sem restricoes adicionais
+
+---
+
+## 4. Requisito de Atribuicao
+
+Para cumprir os termos da Licenca MIT, ao redistribuir o SINAPSE-AI:
+
+1. **Mantenha o arquivo `LICENSE`** intacto na raiz do projeto
+2. **Nao remova** os avisos de copyright existentes nos arquivos-fonte
+3. **Nao e necessario** exibir atribuicao na interface do usuario ou na documentacao publica do seu projeto derivado — apenas o arquivo `LICENSE` deve ser preservado
+
+---
+
+## 5. Modulo Pro (Licenca Proprietaria)
+
+O SINAPSE-AI pode incluir um modulo Pro (`pro/`) com funcionalidades avancadas:
+
+| Aspecto | Core (MIT) | Pro (Proprietario) |
+|---------|-----------|-------------------|
+| **Licenca** | MIT — livre e aberta | Proprietaria — termos separados |
+| **Acesso** | Publico via npm e GitHub | Restrito a licenciados |
+| **Modificacao** | Livre | Conforme termos da licenca Pro |
+| **Redistribuicao** | Livre (com atribuicao) | Proibida sem autorizacao |
+| **Codigo-fonte** | Disponivel | Nao disponivel publicamente |
+
+A existencia do modulo Pro **nao afeta** a licenca do nucleo open-source. O core do SINAPSE-AI permanece sob Licenca MIT independentemente do modulo Pro.
+
+---
+
+## 6. Contribuicoes da Comunidade
+
+### Licenca de Contribuicoes
+
+Todas as contribuicoes submetidas ao repositorio do SINAPSE-AI via Pull Request sao licenciadas sob a **Licenca MIT**, por padrao. Ao submeter uma contribuicao:
+
+- O contribuidor declara possuir os direitos necessarios sobre o codigo submetido
+- O contribuidor concorda com o licenciamento sob MIT
+- O contribuidor reconhece que a contribuicao podera ser modificada e redistribuida conforme a Licenca MIT
+
+### Contribuicoes de Squads
+
+Os Squads (modulos de especializacao) contribuidos pela comunidade seguem a mesma politica: licenciamento MIT por padrao, salvo indicacao expressa em contrario no arquivo `LICENSE` do respectivo squad.
+
+---
+
+## 7. Componentes de Terceiros
+
+O SINAPSE-AI integra componentes de terceiros, cada um com sua propria licenca:
+
+| Componente | Licenca Tipica | Verificacao |
+|-----------|---------------|-------------|
+| Pacotes npm (dependencias) | Variada (MIT, Apache 2.0, ISC, etc.) | `npm ls` no projeto |
+| Claude Code (Anthropic) | Termos de servico da Anthropic | Site da Anthropic |
+| Servidores MCP | Variada por servidor | Documentacao de cada servidor |
+| Docker (quando utilizado) | Apache 2.0 | Site do Docker |
+
+O usuario e responsavel por verificar a compatibilidade de licencas ao combinar o SINAPSE-AI com outros componentes em seu projeto.
+
+---
+
+## 8. Perguntas Frequentes
+
+### Posso usar o SINAPSE-AI em projetos comerciais?
+**Sim.** A Licenca MIT permite uso comercial sem restricoes.
+
+### Preciso publicar o codigo-fonte do meu projeto se usar o SINAPSE-AI?
+**Nao.** A Licenca MIT nao exige publicacao de codigo-fonte de projetos derivados.
+
+### Posso modificar o SINAPSE-AI e redistribuir minha versao?
+**Sim**, desde que mantenha o arquivo `LICENSE` com os avisos de copyright originais.
+
+### O modulo Pro afeta a licenca do core?
+**Nao.** O nucleo open-source permanece sob Licenca MIT. O modulo Pro possui licenca propria e independente.
+
+### Preciso pagar para usar o SINAPSE-AI?
+**Nao** para o nucleo open-source. O modulo Pro pode ter termos de licenciamento separados.
+
+---
+
+## 9. Contato
+
+Para duvidas sobre licenciamento:
+
+- **E-mail:** legal@sinapse-ai.dev
+- **GitHub Issues:** [github.com/SinapseAI/sinapse-ai/issues](https://github.com/SinapseAI/sinapse-ai/issues)
+
+---
+
+*SINAPSE-AI — Framework open-source de orquestracao de IA*
+*Licenca MIT*