invos 1.0.0 → 2.0.2

package/kit/SECURITY.md

@@ -1,39 +0,0 @@
-# Segurança
-
-> Regras pra não vazar chave, token, senha ou dado de cliente.
-
-## Nunca commitar
-
-```
-.env
-.env.*
-*.local
-**/secrets/**
-**/credentials/**
-**/*_key*
-**/*_secret*
-**/token*
-**/auth*
-```
-
-O `.gitignore` já bloqueia a maioria. Mas o agente também **nunca** deve escrever chaves em arquivos tracked.
-
-## Regras pro agente
-
-- Se detectar que um arquivo contém chave/API key/token SECRETO, avise antes de qualquer ação
-- Não escreva `.env` preenchido em arquivo versionado
-- Se precisar de credencial pra teste, use variável de ambiente ou `.env.local` (no `.gitignore`)
-- Dados de cliente (nome, empresa, contato) em `memoria/` são ok — mas sem senha, token ou dado financeiro
-- **Composio / OAuth:** `COMPOSIO_API_KEY` e tokens só em ambiente ou `.env` local (gitignore). Nunca em `integracoes/`, `memoria/` ou commit. OAuth fica na conta Composio do usuário.
-
-## Checklist de segurança (antes de push)
-
-- [ ] `grep -r "API_KEY\|SECRET\|PASSWORD\|token" .env* 2>/dev/null` — não deve achar nada
-- [ ] `cat .gitignore` — `.env*` e `*.local` estão lá?
-- [ ] `git status` — tem arquivo de credencial aparecendo? Se sim, adicionar no `.gitignore`
-
-## Se vazar
-
-1. Rotacionar a chave imediatamente no serviço (Notion, OpenAI, GitHub, etc.)
-2. Usar `git filter-branch` ou `bfg` pra remover do histórico
-3. Anotar como regra em `memoria/regras/` pra não repetir

package/kit/clientes/README.md

@@ -1,72 +0,0 @@
-# Clientes
-
-Pasta do **prestador de serviço**: um cliente (ou lead quente) = uma subpasta.
-
-Assim o agente não mistura o João com a Maria, e a skill **proposta** usa o contexto certo.
-
-## Índice (boot)
-
-| Arquivo | Pra quê |
-|---------|---------|
-| `clientes/_index.md` | Pipeline: status, **valor**, **pagto**, próximo, dono, desde. Boot. |
-| `clientes/<slug>/` | Ficha + suporte + propostas + arquivos daquele cliente. |
-
-Não coloque HTML/PDF/imagem de cliente na raiz — só em `clientes/<slug>/arquivos/`.  
-Logo **sua** (prestador) → `marca/assets/`, não aqui.
-
-## Criar cliente novo
-
-### Instrução pro agente (preferido)
-
-1. Defina slug: minúsculo, hífen, sem acento (`clinica-vida`, `ana-studio`).  
-2. **Duplique** o template — **nunca** preencha `_template` com dados reais:
-
-```bash
-cp -R clientes/_template "clientes/<slug>"
-```
-
-3. Escreva os dados em `clientes/<slug>/perfil.md` (e contexto se o user der).  
-4. **Adicione 1 linha** em `clientes/_index.md` (status, próximo, dono, desde).  
-5. Confirme o path.  
-6. Setup geral do kit: ver `COMECE-AQUI.md` (passo 4).
-
-### Na mão (humano)
-
-```bash
-cp -R clientes/_template clientes/nome-do-cliente
-# edite clientes/nome-do-cliente/perfil.md
-# edite clientes/_index.md — uma linha no pipeline
-```
-
-Depois no chat: **“Cliente atual: nome-do-cliente”**.
-
-## Estrutura de cada cliente
-
-| Path | Pra quê |
-|------|---------|
-| `perfil.md` | Quem é, o que compra, status, **próximo passo + dono** |
-| `contexto.md` | Histórico curto, combinados, decisões |
-| `entregas.md` | Log do que saiu / prazos (tabela) |
-| `propostas/` | **HTML pronto pra enviar** (`YYYY-MM-DD.html`) + MD opcional |
-| `arquivos/` | PDF exportado, imagens, anexos **desse** cliente |
-
-## Dono da task
-
-- **agente** — redigir proposta, atualizar ficha, gerar arquivo em `arquivos/`, organizar contexto  
-- **humano** — enviar DM de verdade, ligar, assinar, cobrar, decidir preço final  
-
-Toda linha do `_index` e do `ativo` precisa de dono. Sem dono = inválida.
-
-## O que NÃO colocar aqui
-
-- Senha, token, cartão, dado bancário completo  
-- Toda a vida do cliente (só o que mexe no serviço **agora**)  
-- CRM completo com 20 campos — se não usa, não inventa  
-- Entregas de um cliente misturadas na pasta de outro  
-
-## Frases úteis pro agente
-
-- “Cria o cliente Ana Studio a partir do template: designer, lead, quer site.”  
-- “O que importa hoje no cliente X?”  
-- “Gera proposta pro cliente X com este brief: …”  
-- “Salva esse PDF na pasta do cliente X.”  

package/kit/clientes/_index.md

@@ -1,32 +0,0 @@
-# Clientes — índice
-
-> Pipeline comercial + dinheiro leve. Boot: ler **só este arquivo**.  
-> Ficha e arquivos: `clientes/<slug>/`.
-
-## Como usar
-
-| Campo | Significado |
-|-------|-------------|
-| **slug** | pasta `clientes/<slug>/` |
-| **status** | lead · dm · call · proposta · enviado · aceito · ativo · pausado · perdido · encerrado |
-| **próximo** | 1 ação concreta |
-| **dono** | `agente` ou `humano` |
-| **desde** | data ISO da pendência atual |
-| **valor** | R$ da proposta/deal (número ou `—`) |
-| **pagto** | — · pendente · parcial · pago · cancelado |
-
-**Novo cliente:** `cp -R clientes/_template clientes/<slug>` → preencher → **1 linha aqui**.
-
-## Pipeline
-
-| slug | nome | status | valor | pagto | próximo | dono | desde | pasta |
-|------|------|--------|-------|-------|---------|------|-------|-------|
-| — | *(vazio — 1ª ficha no 1º lead real)* | | — | — | | | | |
-
-## A receber (visão rápida)
-
-Linhas com `pagto` = pendente ou parcial e `valor` preenchido → session-start pode citar “em aberto: R$ …”.
-
-## Atrasados
-
-Se `desde` > 3 dias e status aberto → alerta no boot.

package/kit/clientes/_template/contexto.md

@@ -1,21 +0,0 @@
-# Contexto — [Nome do cliente]
-
-## Histórico (curto)
-
-- 
-
-## Combinados / decisões
-
-| Data | O que ficou combinado |
-|------|------------------------|
-| | |
-
-## Suporte (histórico curto)
-
-| Data | Pedido / problema | Status |
-|------|-------------------|--------|
-| | | aberto / resolvido |
-
-## Notas
-
-( objeções, preferências de tom, o que NÃO oferecer )

package/kit/clientes/_template/entregas.md

@@ -1,20 +0,0 @@
-# Entregas — [Nome do cliente]
-
-| Data | O que saiu | Status |
-|------|------------|--------|
-| | proposta `propostas/YYYY-MM-DD.html` | rascunho / enviado / aceito |
-| | kickoff / wire / entrega N | em andamento / feito |
-
-## Em andamento
-
-- [ ] …
-
-## Pendente do cliente
-
-- materiais, acesso, feedback…
-
-## Regras
-
-- Toda **proposta gerada** ganha 1 linha aqui.  
-- Todo **pagamento** → linha “proposta aceita / kickoff” + atualizar **Em andamento** com a entrega.  
-- Não deixar só o `_index` atualizado e esta tabela vazia.

package/kit/clientes/_template/perfil.md

@@ -1,47 +0,0 @@
-# Cliente — [Nome]
-
-> Copie esta pasta `_template` e renomeie. Preencha o que souber; deixe o resto em branco.  
-> Depois: 1 linha em `clientes/_index.md`.
-
-## Identidade
-
-- **Nome / empresa:**
-- **slug da pasta:** (ex: ana-studio)
-- **Contato principal:** (nome + canal: WhatsApp, e-mail…)
-- **Setor / o que faz:**
-- **Status:** lead | dm | call | proposta | ativo | pausado | perdido | encerrado
-- **Como chegou:** indicação | Instagram | site | outro
-
-## Relação comercial
-
-- **O que compra / pode comprar de mim:**
-- **Orçamento (se souber):**
-- **Prazo desejado:**
-- **Urgência:** baixa | média | alta
-
-## Dor principal
-
-(1–3 frases: o problema real, não o “quero um site”)
-
-## Dinheiro (leve)
-
-- **Valor do deal:** R$
-- **Pagamento:** — | pendente | parcial | pago | cancelado
-- **Espelhar no** `clientes/_index.md` (colunas valor / pagto)
-
-## Próximo passo
-
-- **Ação:**
-- **Dono:** agente | humano
-- **Desde:** YYYY-MM-DD
-- **Done quando:** (critério binário)
-- **Até quando:** (opcional)
-
-## Suporte / o que o cliente espera
-
-> Pós-venda e retainer. Evita “sumiu o combinado”.
-
-- **Expectativa atual do cliente:** (1–2 frases)
-- **Pendência aberta dele:** (se houver)
-- **Canal de suporte:** WhatsApp | e-mail | outro
-- **SLA informal:** (ex: respondo em 24h úteis)

package/kit/conteudo/README.md

@@ -1,12 +0,0 @@
-# Conteúdo (marketing leve)
-
-Pasta opcional pro prestador que posta. **Não** é CMS.
-
-| Path | Pra quê |
-|------|---------|
-| `conteudo/_fila.md` | Ideias e posts da semana |
-| `conteudo/publicados/` | Texto já usado (opcional) |
-| `conteudo/carrosseis/` | Saída da **fábrica** (squad instagram-carrossel): PNG + caption |
-
-- Texto rápido: skill `social-content`  
-- Carrossel (MVP): **“Faz um carrossel: [tema]”** → HTML + caption. Full: **“fábrica completa”**.

package/kit/conteudo/_fila.md

@@ -1,12 +0,0 @@
-# Fila de conteúdo
-
-> Máx. 5 ideias ativas. Voz e exemplos: `marca/marca.md`.
-
-| data | ideia (1 linha) | formato | status | dono | prova / origem |
-|------|-----------------|---------|--------|------|----------------|
-| | | post · story · carrossel · thread | ideia · rascunho · publicado | agente \| humano | |
-
-## Em destaque (1 só)
-
-- **Peça da semana:** (vazio)
-- **Done quando:** publicado ou enviado

package/kit/docs/audit-enxugamento-sieve.md

@@ -1,187 +0,0 @@
-# Auditoria de Enxugamento — INVOS
-
-**Data:** 2026-07-24  
-**Escopo:** `/Users/felipealves/FelipeOS/projetos/Felipe.aiOS/projetos/invos`  
-**Persona:** Empresário solo / prestador de serviço  
-**Read-only:** Nenhum arquivo foi editado.
-
----
-
-## 1. Veredito (5 linhas)
-
-**Score: 6/10** — O core INVOS (memoria + clientes + session skills + proposta + social-content) é enxuto e funcional. O problema é **gordura opcional que veio junto**: 22 skills (10+ nunca usadas por empresário solo semanalmente), 3 squads (só 1 é MVP real), e README/AGENTS.md com seções duplicadas. Risco principal: **modelo fraco vai carregar description de 22 skills no boot** e se confundir com triggers sobrepostos (notion vs google-workspace vs composio; humanizer vs stop-slop).
-
----
-
-## 2. Tabela KEEP (essencial dia a dia)
-
-| Path | Por quê | Freq. esperada |
-|------|---------|----------------|
-| `memoria/` (9 arquivos) | Cérebro do negócio. Sem isso não existe INVOS. | Toda sessão |
-| `clientes/_index.md` + `_template/` | Pipeline de vendas + duplicar cliente. Core do prestador. | Toda sessão |
-| `marca/marca.md` + `assets/` | Identidade visual pra propostas e posts. | Toda sessão (via proposta/social-content) |
-| `conteudo/_fila.md` | Fila de conteúdo pra postar. | Semanal |
-| `.agents/skills/session-start` | Boot. Não negocia. | Toda sessão |
-| `.agents/skills/session-end` | Arquivamento. | Toda sessão |
-| `.agents/skills/session-checkpoint` | Checkpoint proativo. | Durante sessão |
-| `.agents/skills/onboard` | Primeira configuração. | 1x (depois arquivar) |
-| `.agents/skills/proposta` | Proposta comercial HTML. Ferramenta #1 do prestador. | Quinzenal |
-| `.agents/skills/social-content` | Posts/legendas texto. Leve, rápido. | Semanal |
-| `.agents/skills/instagram-carrossel` | Carrossel IG. MVP (1-2 HTML + caption). | Semanal |
-| `.agents/skills/design-marca` | Extrair branding de site. | Mensal |
-| `scripts/validar.sh` | Valida integridade do kit. | Pós-edit |
-| `scripts/smoke-estado.sh` | Smoke test de coerência. | Pós-edit |
-| `AGENTS.md` | Fonte de verdade de operação. | Toda sessão (lido pelo agente) |
-| `COMECE-AQUI.md` | Setup inicial. | 1x (depois não lido) |
-
----
-
-## 3. Tabela TRIM (manter mas encolher)
-
-| Path | O que cortar | Ganho |
-|------|-------------|-------|
-| `AGENTS.md` | **Seção "Proactive Content — Formato Seriado"** (linhas 76-110): 35 linhas de tutorial de conteúdo que o empresário solo não precisa ler no boot. Mover para `conhecimento/formato-seriado.md` e referenciar 1 linha. | -800 tokens boot |
-| `AGENTS.md` | **Tabela "Dia a dia do prestador"** (linhas 36-49): duplica o que já está em `COMECE-AQUI.md` Passo 5. Manter 3 linhas essenciais + link. | -400 tokens |
-| `AGENTS.md` | **Tabela "Skills disponíveis"** (linhas 138-153): redundante com o trigger natural das skills. Manter só as 5 core + 1 linha "outras sob demanda". | -300 tokens |
-| `AGENTS.md` | **Tabela "Squads disponíveis"** (linhas 155-163): o empresário não usa squads. Manter 1 linha: "Squads: instagram-carrossel (produção), brand, advisory-board — detalhes em `.agents/squads/`." | -150 tokens |
-| `README.md` | **Seções "O problema" + "Como funciona"** (linhas 31-150): 120 linhas de marketing. O ZIP é a venda; o README é ref. Manter tabela "Core do dia a dia" + link pra COMECE-AQUI. | -3.000 tokens (mas não lido no boot) |
-| `COMECE-AQUI.md` | **Passo 0 + Passo 2** (linhas 38-87): explicação óbvia ("abra a pasta no agente"). Manter só Passo 1 (renomear) + Passo 3 (onboard). | -500 tokens |
-| `.agents/skills/humanizer` | Manter, mas **renomear trigger** para "humanizer-ptbr" e adicionar `aliases: [tira-ia, limpa-texto]` — empresário não sabe o que é "humanizer". | Clareza |
-| `.agents/skills/stop-slop` | Mesmo caso. Aliases: `tira-ia-en, clean-english`. | Clareza |
-
----
-
-## 4. Tabela CUT / Opcional (fora do core ou mover)
-
-| Path | Motivo | Se mover: para onde |
-|------|--------|---------------------|
-| `.agents/skills/llm-wiki` | Knowledge base interligada. **507 linhas.** Empresário solo não usa wiki. É ferramenta de dev/pesquisador. | `addons/llm-wiki/` ou deletar |
-| `.agents/skills/popular-web-designs` | 54 templates de design systems. **214 linhas.** Empresário não pede "faz igual Stripe". É pra dev frontend. | `addons/popular-web-designs/` ou deletar |
-| `.agents/skills/pd-ikigai` | Encontrar ideia de negócio. **Uma vez na vida.** Não é operação diária. | `addons/pd-ikigai/` |
-| `.agents/skills/audit` | Auditoria Four Cs. Roda 1x por semana no máximo. Não precisa estar no boot. | Manter em skills mas sem trigger automático |
-| `.agents/skills/apple/*` (2) | **macOS only.** 50% do ICP usa Windows. Se incluir, colocar guard: `if platform != darwin: skip`. | `addons/apple/` ou condicional |
-| `.agents/skills/productivity/notion` | Notion é opcional. Empresário solo pode não usar. | `addons/notion/` |
-| `.agents/skills/productivity/google-workspace` | Gmail/Calendar. Opcional. Composio já cobre. | `addons/google-workspace/` |
-| `.agents/skills/productivity/maps` | Geocode/POIs. Nenhum prestador precisa disso. | `addons/maps/` ou deletar |
-| `.agents/skills/productivity/nano-pdf` | Editar PDFs. Nicho. | Manter mas sem destaque |
-| `.agents/skills/productivity/ocr-and-documents` | Extrair texto de PDFs. Nicho. | Manter mas sem destaque |
-| `.agents/skills/productivity/powerpoint` | Criar .pptx. Raramente usado. | `addons/powerpoint/` |
-| `.agents/squads/advisory-board` | 11 conselheiros (Naval, Thiel, Munger...). **Overkill total** pra empresário solo. Nunca vai usar. | `addons/advisory-board/` ou deletar |
-| `.agents/squads/brand` | 7 especialistas de branding. **Overkill.** `design-marca` já cobre o essencial. | `addons/brand/` |
-| `integracoes/composio/` | Opcional. Só se o empresário pedir. | Manter como está (já é opcional) |
-
----
-
-## 5. Conflitos e Ambiguidade de Trigger
-
-| Par de skills | Conflito | Recomendação |
-|---------------|----------|--------------|
-| `social-content` vs `instagram-carrossel` | Ambas criam conteúdo IG. "Post" vs "Carrossel" é a linha, mas modelo fraco vai confundir. | **Já resolvido no AGENTS.md**: social-content = texto, carrossel = visual. Manter. |
-| `humanizer` vs `stop-slop` | Uma é PT-BR, outra EN. Mas trigger "tira-ia" é ambíguo. | Adicionar alias claro: `humanizer-ptbr` e `stop-slop-en`. |
-| `notion` vs `google-workspace` vs `composio` | Três ways de acessar dados. Notion = banco. Google = email/calendário. Composio = CLI. Modelo fraco vai chamar a errada. | **Cortar notion e google-workspace do core.** Composio já cobre CLI. Se precisar, volta via addon. |
-| `proposta` vs `design-marca` | Proposta já lê `marca/marca.md`. Design-marca extrai de site. Conflito: "extrai minha marca" → design-marca. "faz proposta" → proposta. | OK. Sem conflito real. |
-| `session-start` vs `onboard` | Session-start detecta template e chama onboard. OK. | Sem conflito. |
-| `llm-wiki` vs `memoria/` | Duas formas de knowledge base. llm-wiki é interligada; memoria/ é simples. Modelo fraco vai misturar. | **Cortar llm-wiki.** Memória já resolve. |
-
----
-
-## 6. Boot Mínimo para Modelo Fraco
-
-### O que o agente DEVE ler no session-start (ordem):
-
-1. `AGENTS.md` (enxugado, ~4.000 tokens)
-2. Skill `session-start` → lê automaticamente:
-   - `memoria/empresa.md`
-   - `memoria/projetos.md`
-   - `memoria/decisoes.md`
-   - `memoria/insights.md`
-   - `memoria/ativo.md`
-   - `clientes/_index.md`
-   - `marca/marca.md`
-   - Último `memoria/historico/`
-
-### O que NUNCA carregar no boot:
-
-- `README.md` (12.8KB de marketing)
-- `SECURITY.md` (só sob demanda)
-- `.agents/skills/*/SKILL.md` (corpo completo — só description)
-- `.agents/squads/` (só se pedir)
-- `integracoes/` (só se pedir)
-- `llm-wiki`, `popular-web-designs`, `pd-ikigai` (nunca no boot)
-- `apple/*`, `productivity/*` (só se platform check passar)
-
-### Checklist de 10s se AGENTS.md estiver gordo:
-
-```
-[ ] AGENTS.md tem < 6.000 bytes?
-[ ] Tabela "Dia a dia" tem < 8 linhas?
-[ ] Tabela "Skills disponíveis" tem < 8 linhas?
-[ ] Seção "Proativo" tem < 15 linhas?
-[ ] Não há seção de marketing/tutorial?
-[ ] Link pra COMECE-AQUI.md (não duplica)?
-[ ] Total skills listadas no boot: < 8?
-[ ] Squads: 1 linha + link?
-```
-
----
-
-## 7. Plano de Enxugamento em 3 Ondas
-
-### Onda 1 (hoje, zero risco de quebrar fluxo comercial)
-
-1. **AGENTS.md**: mover "Formato Seriado" para `conhecimento/formato-seriado.md` (-800 tokens)
-2. **AGENTS.md**: enxugar tabela "Dia a dia" de 14 para 5 linhas (-400 tokens)
-3. **AGENTS.md**: enxugar tabela "Skills disponíveis" de 14 para 6 linhas (-300 tokens)
-4. **AGENTS.md**: enxugar tabela "Squads" de 4 para 1 linha (-150 tokens)
-5. **Renomear triggers**: `humanizer` → `humanizer-ptbr`, `stop-slop` → `stop-slop-en`
-
-**Resultado**: AGENTS.md de ~9.2KB para ~5.5KB (~1.400 tokens economizados no boot)
-
-### Onda 2 (semana, mover para addons)
-
-1. Mover `llm-wiki/` → `addons/llm-wiki/`
-2. Mover `popular-web-designs/` → `addons/popular-web-designs/`
-3. Mover `pd-ikigai/` → `addons/pd-ikigai/`
-4. Mover `apple/` → `addons/apple/` (com guard de platform)
-5. Mover `productivity/notion/` → `addons/notion/`
-6. Mover `productivity/google-workspace/` → `addons/google-workspace/`
-7. Mover `productivity/maps/` → `addons/maps/`
-8. Mover `productivity/powerpoint/` → `addons/powerpoint/`
-9. Mover `.agents/squads/advisory-board/` → `addons/advisory-board/`
-10. Mover `.agents/squads/brand/` → `addons/brand/`
-
-**Resultado**: Skills core de 22 para 12. Squads de 3 para 1.
-
-### Onda 3 (só se ICP não usar)
-
-1. Se empresário não usa `ocr-and-documents` → mover pra addon
-2. Se não usa `nano-pdf` → mover pra addon
-3. Se não usa `audit` → mover pra addon (já é semanal)
-4. Se `composio` nunca é pedido → mover pra addon
-5. Consolidar `session-start` + `session-end` em 1 skill com flags (economiza 1 SKILL.md)
-
----
-
-## 8. NÃO Recomendo
-
-- Apagar `memoria/` ou `session-*` (core do sistema)
-- Fundir `social-content` no `instagram-carrossel` (já decidido: texto vs visual)
-- Inventar features novas
-- Mover `proposta`, `design-marca`, `onboard` (core do prestador)
-- Mudar `clientes/_template` ou `_index` (pipeline funcional)
-
----
-
-## 5 Decisões — RESOLVIDO (Felipe, 2026-07-24)
-
-| # | Proposta Sieve | Decisão produto |
-|---|----------------|-----------------|
-| 1 | Mover llm-wiki + popular-web → addons | **NÃO.** Empresário digital pesquisa e cria site/UI p/ si e clientes. |
-| 2 | Mover squads advisory + brand → addons | **NÃO.** Bônus sob demanda (mentes/branding). |
-| 3 | Mover productivity/* → addons / Composio | **NÃO** (exceto maps). Skill nativa Gmail/Notion/PPTX > CLI Composio no dia a dia. Composio = IG/TikTok/Telegram etc. |
-| 4 | Mover apple → addons | **NÃO.** Manter Reminders/Notes. |
-| 5 | Enxugar AGENTS por KB | **Parcial.** Otimizar **linhas/clareza**, não podar regra útil (engessa o sistema). |
-
-**Única corte aprovado:** skill **`maps`** removida (sem encaixe; humano usa Google Maps).
-
-Ver também: `memoria/decisoes.md` § Skills & enxugamento.

package/kit/docs/cli.md

@@ -1,62 +0,0 @@
-# CLI INVOS — `npx invos`
-
-## Como rodar localmente (dev)
-
-```bash
-# Na raiz do kit invos
-cd /caminho/invos
-
-# npm link (registra comando invos global)
-npm link packages/cli
-
-# Ou rodar direto
-node packages/cli/bin/invos.js --help
-
-# Ou via npm
-npm run invos -- init
-```
-
-## Comandos MVP
-
-| Comando | Descrição |
-|---------|-----------|
-| `invos init [dir]` | Cria novo projeto INVOS (copia kit + lock + symlinks) |
-| `invos install` | Instala skills/scripts em diretório existente |
-| `invos update [--dry-run]` | Atualiza shipped, preserva user data |
-| `invos doctor [--fix]` | Valida instalação |
-
-## Smokes
-
-```bash
-# 1. Init
-node packages/cli/bin/invos.js init /tmp/invos-smoke
-
-# 2. Install (em repo existente)
-cd /tmp/invos-smoke
-node /caminho/packages/cli/bin/invos.js install
-
-# 3. Doctor
-node /caminho/packages/cli/bin/invos.js doctor
-
-# 4. Update (preserva USER)
-echo "USER DATA" > memoria/perfil.md
-node /caminho/packages/cli/bin/invos.js update --dry-run
-```
-
-## Kit source detection
-
-1. `INVOS_KIT_PATH` env var (se definido)
-2. Relativo ao bin do CLI (`../../..` quando em `packages/cli/`)
-3. Fallback: `process.cwd()`
-
-## Publicação
-
-```bash
-# npm login (com conta com acesso)
-npm publish packages/cli
-```
-
-Após publicado:
-```
-npx invos init meu-negocio
-```

package/kit/docs/hotmart-webhook.md

@@ -1,96 +0,0 @@
-# Hotmart Webhook — INVOS
-
-> Endpoint que recebe eventos do Hotmart (2.0.0) após compra do INVOS.
-
-## URL canônica
-
-```
-https://inovadigitalid.com/api/hotmart-invos
-```
-
-## Como configurar no Hotmart
-
-1. Acesse o **formulário do Hotmart** do produto INVOS
-2. Aba **Webhook**
-3. **URL:** `https://inovadigitalid.com/api/hotmart-invos`
-4. **Versão:** 2.0.0
-5. **Hottok:** o valor da env `HOTMART_HOTTOK` (opcional — gera 503 sem ele em produção)
-6. **Eventos marcados:**
-   - ✅ PURCHASE_APPROVED
-   - ✅ COMPLETE (se houver)
-   - ✅ REFUNDED
-   - ✅ CHARGEBACK
-
-## Eventos tratados
-
-| Evento | Ação |
-|--------|------|
-| `PURCHASE_APPROVED` | Extrai buyer email/name, envia e-mail com instruções de instalação via Resend |
-| `COMPLETE` | Mesmo que PURCHASE_APPROVED |
-| `REFUNDED` | Log com tag `revoke` |
-| `CHARGEBACK` | Log com tag `revoke` |
-
-## Validação
-
-- Header `X-Hottok` **ou** query param `hottok` — se `HOTMART_HOTTOK` estiver setado, o valor deve bater
-- Se `HOTMART_HOTTOK` estiver vazio em produção (`VERCEL_ENV=production`): **503**
-- Se vazio em dev: aceita com warning implícito
-
-## E-mail: Hotmart vs Resend
-
-**Não precisa Resend** se a Hotmart já envia e-mail de entrega pós-compra (área de membros / conteúdo do produto).  
-Configure o **conteúdo do e-mail da Hotmart** com: link do repo + “abra no agente e diga Segue o COMECE-AQUI”.
-
-Resend no webhook só se quiser **segundo** e-mail técnico nosso (`INVOS_SEND_EMAIL=1` + `RESEND_API_KEY`).
-
-## Env vars
-
-| Var | Obrigatória | Descrição |
-|-----|-------------|-----------|
-| `HOTMART_HOTTOK` | Recomendado | Token do form Hotmart (header/body) |
-| `INVOS_SEND_EMAIL` | Não | Só `1` se quiser e-mail via Resend (default: off) |
-| `RESEND_API_KEY` | Não | Só com INVOS_SEND_EMAIL=1 |
-| `RESEND_FROM` | Não | Remetente Resend |
-| `INVOS_GITHUB_URL` | Não | Link no e-mail Resend (default: github.com/felipenalves/invos) |
-
-## Body esperado (Hotmart 2.0.0)
-
-```json
-{
-  "id": "evt_abc123",
-  "event": "PURCHASE_APPROVED",
-  "data": {
-    "buyer": { "email": "comprador@email.com", "name": "João" },
-    "product": { "id": 12345, "name": "INVOS — Business Memory for AI Agents" },
-    "purchase": { "status": "approved", "transaction": "tx_abc" }
-  }
-}
-```
-
-## Response
-
-```json
-{ "ok": true, "event": "PURCHASE_APPROVED" }
-```
-
-Sempre 200 (a menos que validação falhe). Hotmart espera resposta rápida.
-
-## Logs
-
-Payload é logado com email/name mascarados (`***@***`). Eventos financeiros (REFUNDED/CHARGEBACK) são logados com tag `revoke`.
-
-## Teste local
-
-```bash
-curl -X POST http://localhost:3000/api/hotmart-invos \
-  -H "Content-Type: application/json" \
-  -H "X-Hottok: meu-hottok-dev" \
-  -d '{
-    "id": "test_1",
-    "event": "PURCHASE_APPROVED",
-    "data": {
-      "buyer": { "email": "teste@teste.com", "name": "Teste" },
-      "product": { "id": 999, "name": "INVOS Dev" }
-    }
-  }'
-```

package/kit/docs/lab-user.md

@@ -1,35 +0,0 @@
-# Lab — Testar CLI como comprador
-
-> Sandbox isolado pra testar o fluxo `invos init/install/update/doctor`.
-
-## Sandbox
-
-```
-/Users/felipealves/FelipeOS/projetos/Felipe.aiOS/projetos/invos-TEST
-```
-
-## Rodar
-
-```bash
-bash /Users/felipealves/FelipeOS/projetos/Felipe.aiOS/projetos/invos-TEST/scripts/lab-user-flow.sh
-```
-
-O script:
-
-1. Cria `user-home/` via `invos init`
-2. Roda `invos doctor` (valida 6/6 files, 7/7 dirs)
-3. Simula dados do usuário (USER MARKER)
-4. Roda `invos update` e verifica que USER foi preservado
-5. Cria `user-existing-app/` com README.md
-6. Roda `invos install` e verifica que README foi preservado
-7. Roda `doctor` no existing app
-
-Exit 0 = tudo ok.
-
-## Reset
-
-```bash
-bash /Users/felipealves/FelipeOS/projetos/Felipe.aiOS/projetos/invos-TEST/scripts/lab-reset.sh
-```
-
-Remove `user-home/` e `user-existing-app/`.