# Transcript — IA Híbrida no manager-genesis — Opções & Decisões

_session: ia-hibrida-decisoes · 5 turnos_

## [1] user · gabriel · 2026-06-25T18:59:33.000Z

Preciso de um documento completo de opções e decisões para IA híbrida no manager-genesis (Ana Júlia/Genesis Julia). Origem: análise do artigo "IA Híbrida" cruzada com a arquitetura real do mukutu-mono. Quero ver: (1) recap da análise, (2) todas as opções A-E com recomendações, (3) não-recomendações, (4) checklist completo de decisões — nada foi escolhido ainda. Salvo em 2026-06-23.

## [2] assistant · julia · 2026-06-25T18:59:55.000Z

## Recap da Análise

O projeto **já é** uma arquitetura híbrida: execução local (workers Claude, CLI Bun, SLM local Parakeet/whisper para transcrição, tiering Opus→Sonnet→Haiku) + orquestração central (SurrealDB `ns=manager db=fleet` como SoT, filosofia Seshat) + curadoria humana madura (`grill.ts`→`premise.ts`→`decision.ts`→`selfcheck.ts`→agente `qa` com 25+ invariantes).

O artigo funciona como **lente/checklist de maturidade**, não como blueprint: revela que o único órgão de alto-ROI faltando é uma **camada de relevância/recuperação** sobre o conhecimento que o sistema já captura e valida.

---

### Regra de Ouro

> Vetorize o que é **heurístico/recuperável**; mantenha **estruturado e exato** o que é jurídico/auditável.
>
> O ledger estruturado continua sendo a fonte da verdade. Qualquer vetor é **índice POR CIMA**, com link de volta à linha canônica — nunca substitui.

> [widget: dynamic-layout] — Recap — Regra de Ouro

## [3] assistant · julia · 2026-06-25T19:00:29.000Z

## As 5 Opções (A–E)

Legenda: 🟢 alta recomendação · 🟡 média · 🔵 baixa/depende · ⚪ governança

---

### A — RAG sobre os Knowledge Pools 🟢 **maior ROI, menor atrito**

Hoje `references/{designer-heuristics,dev-patterns,qa-invariants}-pool.md` são despejados **inteiros** no contexto. Conforme crescem = sumidouro de tokens. Proposta: recuperar **top-k entradas relevantes** por similaridade.

- **Onde mora o vetor:** DuckDB-VSS (stack já usa DuckDB no pipeline Ekyte)
- **Esforço:** baixo-médio — toca o leitor dos pools + `append-to-pool.ts`. Não toca produção.
- **Depende de:** nada (ponto de partida autônomo)

---

### B — Índice Vetorial sobre o Ledger (premissas/decisões) 🟡

Embedding companheiro em `premise`/`decision` para busca semântica — "já decidimos algo parecido?". O **SurrealDB já tem HNSW/MTREE nativo** — sem banco vetorial separado, só coluna `embedding option<array<float>>`.

- **Esforço:** médio — toca `premise.ts`/`decision.ts` + schema + backfill. 100% aditivo/idempotente.
- **Depende de:** A (valida a abordagem de embedding nos pools primeiro)
- **⚠️ Pré-requisito:** corrigir `SKILL_ROOT` em `_lib.ts:14` (fileURLToPath — quebra Windows)

---

### C — SLM Local para Classificação/Roteamento 🔵

Modelo local pequeno para tarefas alta-frequência/baixo-valor/sensíveis: classificar/rotear events, pré-filtrar anomalias antes de escalar ao Opus.

- **Esforço:** alto — nova dependência de modelo + integração nos hooks/telemetria
- **Depende de:** A+B com dados de custo medidos na mão
- **Só com necessidade concreta medida.** Tiering Opus→Sonnet→Haiku já é a versão pragmática.

---

### D — Governança: Conflito de Premissas + Versionamento ⚪

Gabriel **e** Ana Júlia curam o **mesmo ledger**. Quando dois curadores ratificam premissas contraditórias, o que vence? O `premise` já tem `scope` e flag `active` — falta formalizar a política.

- **Esforço:** leve-médio — regra + talvez campo de proveniência/precedência
- **Depende de:** nada (decisão de política mais que código, pode andar em paralelo)

---

### E — Segurança: Exposição Pública do Espelho ⚪

O Espelho é **público, sem auth**, mostrando nomes/e-mails/horas reais — conflito com a regra "números internos Mukutu nunca em página pública".

- **Esforço:** médio — auth no `julia-chat`, decisão de produto + infra
- **Depende de:** nada (dívida de segurança independente)

> [widget: bar-rank] — Esforço × ROI por Opção

## [4] assistant · julia · 2026-06-25T19:01:15.000Z

## Não-Recomendações (o que NÃO fazer)

- ❌ **Não vetorizar o audit trail como fonte.** Decisões/premissas ativas permanecem linhas exatas no SurrealDB. Vetor é índice paralelo — nunca a fonte. (Quebraria Seshat/auditabilidade.)
- ❌ **Não trocar SurrealDB por um "vector DB".** Ele é o SoT; vetor é índice.
- ❌ **Não introduzir Qdrant/Chroma/pgvector** se DuckDB-VSS (pools) ou SurrealDB nativo (ledger) já resolvem. Evita dependência nova.
- ❌ **Não montar SLM local de inferência geral só para "ter edge".** O edge real é a API da Anthropic com tiering. SLM local só com caso de uso medido (Opção C).
- ❌ **Não mandar texto interno Mukutu para API de embedding externa** (Voyage/OpenAI) sem decisão explícita — egress de estratégia/nomes de empresas. Default: embedding **local**.
- ❌ **Não implementar nada antes de plano aprovado** (CLAUDE.md §8.1); não commitar/push sem aprovação (§3, §7.1).
- ❌ **Não fazer migração destrutiva no ledger compartilhado.** Tudo aditivo/idempotente (Gabriel + Ana Júlia no mesmo banco).

---

## Checklist de Decisões (14 itens)

**Estratégicas**
1. Quais opções perseguir e em que ordem? (ex.: A → B → D em paralelo; C/E depois)
2. Qual o objetivo nº1? (menos tokens / mais precisão / governança / segurança)

**Se A ou B — qualquer coisa com embedding**
3. Modelo de embedding: (i) local embarcado / ✅ *recomendado* · (ii) Ollama / · (iii) Voyage AI ❌ *egress de dado interno*
4. Onde mora o vetor: DuckDB-VSS (pools) · SurrealDB nativo (ledger) · Qdrant/pgvector ❌
5. Onde computar: CLI Bun () · pipeline Python Ekyte

**Se A**
6. Escopo dos pools: os 3 (//) de uma vez, ou começar por 1?

**Se B**
7. Escopo v1: (S1) só  · (S2) + · (S3) + distribuição-ponta ()
8. Tipo de índice: HNSW (aprox., escala) · MTREE (exato-ish) · força-bruta cosseno (< centenas)
9. Confirmar versão SurrealDB + HNSW habilitado (Fase 0, precisa túnel)

**Se D**
10. Política de conflito: last-wins? scope-wins? exige `decision` explícita? Formalizar `active`/proveniência?

**Se E**
11. Auth no Espelho: quando? que dado pode ficar público (agregado) vs interno?

**Transversais**
12. Versionamento de conhecimento: registrar /dimensão para detectar drift + forçar re-backfill
13. Dependências novas: aprovar explicitamente cada uma (CLAUDE.md §7.4)
14. Cadência de commit/push: confirmar a cada marco (§3, §7.1)

---

## Como Retomar

1. 
   *(clone envelhece rápido — [[mukutu-mono-clone-goes-stale-fast]])*
2. Responder o **checklist §3** acima (escolher opção(ões) + decisões)
3. Eu detalho o plano final SÓ da(s) opção(ões) escolhida(s) e aguardo aprovação antes de codar

**Ordem recomendada:** A → B (depois de A validado) → D + E em paralelo → C por último (só se necessidade medida)

> [widget: dynamic-layout] — Checklist de Decisões — 14 itens

## [5] assistant · julia · 2026-06-25T19:02:06.000Z

## Não-Recomendações (o que NÃO fazer)

- ❌ **Não vetorizar o audit trail como fonte.** Decisões/premissas ativas permanecem linhas exatas no SurrealDB. Vetor é índice paralelo — nunca a fonte. (Quebraria Seshat/auditabilidade.)
- ❌ **Não trocar SurrealDB por um "vector DB".** Ele é o SoT; vetor é índice.
- ❌ **Não introduzir Qdrant/Chroma/pgvector** se DuckDB-VSS (pools) ou SurrealDB nativo (ledger) já resolvem. Evita dependência nova.
- ❌ **Não montar SLM local de inferência geral só para "ter edge".** O edge real é a API da Anthropic com tiering. SLM local só com caso de uso medido (Opção C).
- ❌ **Não mandar texto interno Mukutu para API de embedding externa** (Voyage/OpenAI) sem decisão explícita — egress de estratégia/nomes de empresas. Default: embedding **local**.
- ❌ **Não implementar nada antes de plano aprovado** (CLAUDE.md §8.1); não commitar/push sem aprovação (§3, §7.1).
- ❌ **Não fazer migração destrutiva no ledger compartilhado.** Tudo aditivo/idempotente (Gabriel + Ana Júlia no mesmo banco).

---

## Checklist de Decisões (14 itens)

**Estratégicas**
1. Quais opções perseguir e em que ordem? (ex.: A → B → D em paralelo; C/E depois)
2. Qual o objetivo nº1? (menos tokens / mais precisão / governança / segurança)

**Se A ou B — qualquer coisa com embedding**
3. Modelo de embedding: (i) local embarcado `@xenova/transformers`/`fastembed` ✅ *recomendado* · (ii) Ollama `nomic-embed-text`/`bge-m3` · (iii) Voyage AI ❌ *egress interno*
4. Onde mora o vetor: DuckDB-VSS (pools) · SurrealDB nativo (ledger) · Qdrant/pgvector ❌
5. Onde computar: CLI Bun (`skills/julia/scripts`) · pipeline Python Ekyte

**Se A**
6. Escopo dos pools: os 3 (`designer`/`dev`/`qa`) de uma vez, ou começar por 1?

**Se B**
7. Escopo v1: (S1) só `premise` · (S2) `premise`+`decision` · (S3) + distribuição-ponta (`spawn.ts`)
8. Tipo de índice: HNSW (aprox., escala) · MTREE (exato-ish) · força-bruta cosseno (< centenas)
9. Confirmar versão SurrealDB + HNSW habilitado (Fase 0, precisa túnel)

**Se D**
10. Política de conflito: last-wins? scope-wins? exige `decision` explícita? Formalizar `active`/proveniência?

**Se E**
11. Auth no Espelho: quando? que dado pode ficar público (agregado) vs interno?

**Transversais**
12. Versionamento de conhecimento: registrar `embed_model`/dimensão para detectar drift + forçar re-backfill
13. Dependências novas: aprovar explicitamente cada uma (CLAUDE.md §7.4)
14. Cadência de commit/push: confirmar a cada marco (§3, §7.1)

---

## Como Retomar

1. `git -C mukutu-mono fetch origin && git --no-pager log --oneline HEAD..origin/main`
   *(clone envelhece rápido — [[mukutu-mono-clone-goes-stale-fast]])*
2. Responder o **checklist §3** acima (escolher opção(ões) + decisões)
3. Eu detalho o plano final SÓ da(s) opção(ões) escolhida(s) e aguardo aprovação antes de codar

**Ordem recomendada:** A → B (depois de A validado) → D + E em paralelo → C por último (só se necessidade medida)

> [widget: dynamic-layout] — Checklist de Decisões — 14 itens