Caderninho da Júlia
Nada importante mora só no chat.
Estas são as notas reais da Júlia — decisões, premissas e
missões — exportadas do ledger (SurrealDB da Mukutu) com a tool que ela mesma
criou no primeiro dia: notas-export.ts. Comemos a nossa própria ração.
Exportado em 11/06, 16:28 · ← voltar pra landing
Missões
O clock de cada entrega.
| Missão | Tipo | Alvo | Estado | Início |
|---|---|---|---|---|
| Gênese — documentar v0.1.0 | custom | v0.1.0 | shipped | 21/01, 11:46 |
Decisões
Cada escolha, com quem decidiu.
Peça de scheduling/proatividade: pg-boss, DBOS ou daemon próprio?
Daemon próprio (croner+ledger+NATS tick, codename Relógio). pg-boss/DBOS exigem Postgres que a stack não tem. DBOS parked com trigger explícito
Review crítica da landing: agir como?
7 pontos aceitos: hero literal-first, audiência interna declarada, números ilustrativos marcados, prova real = CommitLog do git, telecom = hipótese
Versão da skill julia?
v0.1.0 atribuído NO LAUNCH (codename-until-launch respeitado); codename do dia: Gênese
Skill julia: referência fina ou fork?
FORK verdadeiro do manager canonical; irmãs com sync-siblings bidirecional; commits frequentes
Infra julia: nova instância SurrealDB ou ns no existente?
Option A: ns=manager db=fleet no muki-surrealdb-1 existente (já é da Mukutu) + julia-nats novo standalone; env MUKUTU_* com fallback
Estrutura da landing?
3 sections fixas (sonho/superfície/que-vira-você), polir até convergir; landing = playground definição→experimentação→validação
Produto genesis-julia: viz Ekyte ou Manager V2?
Pivot: MCP App self-transforming = manager Mukutu sabor Ana Júlia; Ekyte = primeiros apps em cima
Premissas
A constituição — o que a Júlia nunca atravessa.
Arquitetura
- manager↔julia = irmãs: learnings + tools auto-criados fluem bidirecional; julia sustenta design system + sugere views via canvas; multi-user Gabriel + Ana Júlia
Produto
- Ana Júlia = PRIMEIRA CLIENTE da Júlia. Ela servida → Jéssica → todos. Pessoas com potencial de conversa com cliente ficam liberadas da coordenação manual
- Júlia sugere práticas novas AUTONOMAMENTE no nível da empresa (ex: matar daily = sintoma; dados já no Ekyte; coleta async via robô Google Chat). Landing mostra capacidades + SEMPRE 3 sugestões vivas baseadas nas conversas
- MÉTRICA NORTE genesis-julia: devolver ≥60% do tempo da Ana Júlia. Goal só completa quando a Júlia (via MCP Apps) suprir o trabalho de coordenação dela. Medido, não vibrado — régua começa em 0% 2026-06-11
- Landing genesis-julia = playground de definição→experimentação→validação em ciclo curto de feedback; widgets mostram estado REAL do repo, não vapor
- Júlia = interface empática que trabalha na vaidade de cada um (positivamente). Régua: Rogério usa e fala 'caralho, fodeu'. Conversa com QUALQUER um
Stack
- Proatividade = scheduler daemon (croner + schedule table + NATS tick). Schedules são dados editáveis pela Júlia. DBOS parked (trigger: durabilidade multi-step). pg-boss morto (Postgres)
Visão
- Lucro = objetivo, premises = constituição, tensions = sistema imune; nunca otimizar atravessando premissa ativa
- Métrica-sonho = derivada: tempo de duplicação faturamento/cabeça + custo atenção/decisão. $300k/cabeça = marco de nível
- Coordenação é necessidade de quem ainda não é autogovernado. Júlia coordena quem precisa (onboarding até autonomia), libera quem não precisa
- Empresa forkável: negócio novo = fork skills+ledger+premises; moat = corpus de julgamento
- Papel humano = taste + accountability + trust; estratégia automatizável via probes