• PRD como fila e piloto. Checklist montado do texto quando o PRD não tem itens; fila que não trava quando o agente espera um comando em segundo plano; pergunta com opção recomendada e sem risco segue sozinha, e o que é arriscado (produção, push forçado, dependência nova, migration, apagar) espera você.
• Piloto e modo noturno com trava. Comando perigoso é recusado na hora, sem ficar pendurado esperando aprovação.
• Athena Remote (Android). A Athena do PC no celular: projetos, PRDs, terminais dos agentes, decisões, diff e stage, uso das contas. Pareamento por código, X25519 + AES-256-GCM de ponta a ponta, relay no VPS que só repassa e não lê nada. O app se atualiza sem reinstalar, com pacote assinado em Ed25519.
• Projeto do zero com harness. Cria git, README, .gitignore, publica no GitHub ou GitLab e já liga o harness da Steply (plugin do Claude Code + AGENTS.md para Codex) no 1º commit.
• Contas e uso. Vários logins do Claude Code e do Codex, plano, conta ativa e consumo da sessão (5 h) e da semana, com alerta em 80% e 95%.
• Memória por projeto com anonimização antes da injeção, timeline por PRD, Explorer com prévia de CSV e XLSX, busca via ripgrep, worktrees com resolução de conflito 3-way, issues do GitHub, GitLab e Azure DevOps.
• Laya como backend de decisão padrão (ver abaixo).

A camada de memória que deu origem a ela está descrita em docs/step-ai-infinity-memory.md.

• Stack: Electron + React no cliente, NestJS + Socket.IO + TypeORM + PostgreSQL na API, mediasoup como SFU embarcado no app, TURN/STUN próprio com relays em enxame e credencial por pessoa.
• Chamada que respeita a máquina: teto de CPU medido no app inteiro (padrão 10%), só desce o vídeo que está na tela e no tamanho do quadro. Sala de 3 com câmera caiu de ~0,95 para ~0,4 núcleo.
• Tela até 60 fps / 1440p, com prioridade e banda escolhíveis. No Linux, o som da tela é só do programa escolhido: o PipeWire duplica o stream para um sink que só o Kraked ouve, sem levar a voz da sala.
• Exibição sincronizada: o servidor guarda só o ponto do vídeo e cada um toca na própria máquina. Vídeo do computador transmitido para a sala sem passar por servidor.
• Lojas: vitrine por servidor, Pix com mensalidade e carência, carteira interna com saldo travado 7 dias, direito de arrependimento (art. 49 do CDC) com devolução que não passa pelo vendedor.
• Cargos e permissões granulares por servidor e canal, convite público, menções, diagnóstico da chamada ponta a ponta.

🌍 asteroth-public — o canal externo. Aqui não tem código de jogo, tem mundo:

• Lore cosmogônica (LORE.md) — a origem das partículas, Asteroth como entidade, o planeta físico.
• Os Governantes (GOVERNANTES.md) — panteão de 26 entidades, cada uma com condição de despertar própria.
• Mecânicas (GAMEPLAY.md) — classes, fama, ciclo explorar → coletar → construir → defender → ser invadido → reconstruir.
• Contos (stories/) e 17 concept arts (concepts/worlds/), cada um com vinheta curta.

_{5 dos 26 governantes do panteão de Asteroth}

🧪 asteroth-learnings 🔒 — pesquisa fundacional. ~147 documentos em 9 pilares (renderização iso, movimento iso, networking, ECS, física, mundo esférico, biomas, infra MMO, integração de stack). Highlight: o lowpoly_generator, pipeline em produção que converte sprite-sheet ortográfica em mesh low-poly 3D fiel à arte:

sprite sheet ortográfico
   ↓ slice_sheets.py (Blender)
slices + metadata (bbox + m_per_px)
   ↓ 01_extract/ — 8 features por slice
silhouette · keypoints · edges · palette · depth · normals · parts · symmetry
   ↓ 02_fuse/ — landmarks 3D + visual hull
   ↓ 06_ai/run_hunyuan_cloud.py
Hunyuan3D-2 multi-view via HF Space (~5s)
   ↓ postprocess: decimate (~2k tris) + rescale métrico
character.glb pronto pra engine

A descoberta central: CV clássico (visual hull + primitives + shrinkwrap) bate na parede em fidelidade artística. A solução foi inverter o paradigma — usar o pipeline pra preparar inputs alinhados (3 vistas em escala métrica + landmarks) e delegar a inferência 3D pra uma IA multi-view. Híbrido CV + IA generativa entrega resultado em segundos.

🔒 Asteroth — engine + jogo (privado). Engine própria em C++, atualmente na Fase 0: Fundação 3D (pipeline de renderização — cubo isométrico, depth test, sistema de mesh). Roadmap até infra MMO (Fase 5) e conteúdo (Fase 6+). Stack consolidada em ~22 libs C++ defensivamente avaliadas (Flecs, Jolt, GNS, etc).

• Hierarquia explícita: Fase (F#) → Épico (E# = Milestone + Discussion) → Issue → PR. Nenhuma issue órfã.
• Templates de épico e spec que padronizam tracking entre Asteroth, Steply e laterais.
• Style guide arquitetural — design system Steply replicável (CSS variables, dark/light, tokens).
• Tooling automatizado (bulk_create_epics.py, spec_report.py, sync_design_specs.py) — épicos em lote, relatórios de progresso, sincronização de specs entre repos.
• ERD versionado como source-of-truth de domínio + roteiros de implantação (n8n em VPS e AWS).

Força clareza de escopo antes do commit, deixa rastro auditável das decisões e reduz drasticamente o custo de onboard em projetos longos.

Pipeline pra criar animes controlando Blender remotamente via Model Context Protocol (MCP stdio):

1. IA gera concept art 2D do personagem (Fal.ai)
2. IA converte imagem → modelo 3D rigado (Meshy.ai, image-to-3d + auto-rigging)
3. Blender controlado via MCP monta a cena, aplica animação pronta (walk/run)
4. Render NPR vanilla (Toon BSDF via Shader-to-RGB + ColorRamp + Freestyle), câmera ortográfica pra "sensação 2D" anime
5. Frames PNG + MP4 (ffmpeg) saem prontos por episódio

CLI Typer end-to-end. Stack: Python 3.10+ · Typer · MCP · Blender · Meshy.ai. É a prova de conceito de que MCP + Blender + image-to-3D monta um pipeline cinematográfico controlado por linguagem natural, sem operador artista no loop.

   pergunta ──► researcher ───► writer ──► resposta
                 │ tool: search_docs
                 ▼
           PGVector (pg16) ← embeddings MiniLM (384d)

• Orquestração: LangGraph (StateGraph) — fluxo entre agentes explícito e inspecionável
• Agentes: LangChain create_react_agent (loop ReAct)
• LLM: Claude Haiku 4.5 · Vector store: PostgreSQL + pgvector · Embeddings: MiniLM-L6-v2 local
• Infra: Docker Compose, up -d e tá pronto

O ponto: trocar peças (LLM, tool, vetor, política de roteamento) e ver o efeito imediato, sem framework de alto nível escondendo o que acontece.

Workspace de código local-first para Linux, em Rust, porte de um código-base MIT. Roda os agentes que já uso (Claude Code, Codex, Cursor, Grok, Hermes, pi via ACP) e um loop DeepSeek embutido. Antes de cada tarefa, um seletor escolhe entre as rotas que o host preparou, ou se abstém, e o host confere a escolha antes de aplicar.

• Laya em ONNX Runtime, dentro do processo: sem Python e sem GPU. Modelo de ≈380 MB conferido por SHA-256; com o serviço local (socket Unix 0600, sem porta de rede) cada decisão cai de ~1,4 s / 290 MB para ~0,2 s / 37 MB. Contra um laya-serve em GPU fp16: ~20–30 ms.
• Medido antes de usar. tools/laya-eval separa dev e holdout: perguntas de foco e de modelo foram abandonadas (18% e "escolhe ponta para tudo"); ficou só "mudança ou pergunta?", com 80% de acerto e 100% de precisão ao aplicar no holdout.
• Seleção nunca concede permissão. Escolha inválida, velha ou abstenção cai na rota original; o host recusa sozinho push --force, push em main, reset --hard, rm -rf amplo e escrita em .env ou chaves.
• Instalação em um comando, instalador visual em Electron e AppImage com o modelo embutido.
• laya-serve no meu PM2 com um porteiro que acorda o modelo sob demanda e desliga depois de 10 min parado, travado no checkpoint multilíngue em fp16 (VRAM de 1,25 GB para 0,63 GB). Athena e harness-jev consomem o mesmo serviço.

Laya é um modelo aberto (NandhaKishorM/laya, Apache-2.0); o meu trabalho é o porte para ONNX, a integração, a avaliação e o serviço.

Robô de day trade na Nelogica (ProfitDLL). A estratégia propõe a entrada, o Jev confirma ou manda esperar e o gestor de risco tem a última palavra. Os padrões em que o Jev disse "seguir" e o mercado deu razão viram critérios da Laya, que roda local em ~30 ms, sem custo por pergunta.

negócio → candle → estratégia → risco (veto) → Jev/Laya → risco (ordem) → corretora
                                                  ↓
                    caderno (resposta do Jev + desfecho) → critérios da Laya

Os dois falam o mesmo protocolo (/v1/systemone: estado + perguntas tipadas, resposta com probabilidade), em cascata ou em corrida. Qualquer dúvida vira esperar, e o decisor nunca libera o que o risco vetou. Python 3.11+, sem dependência em tempo de execução.

Steply em produção e em desenvolvimento:

• Athena e Kraked — os dois produtos de desktop descritos acima.
• services.steply.pm2 — orquestração PM2 dos serviços Steply (realtime chat com WebRTC + ICE relay, blog publisher SSR, integrações).
• build-market-business (frontend / dashboard) — produto B2B em React.
• main.steply.build — site institucional · lp.email.sender — disparador de campanhas próprio · lucashiago.resume — currículo como HTML versionado.
• integration-mercado-pago-nestjs — integração de pagamentos NestJS.

Históricos que ainda ensinam (e às vezes ainda rodam em produção):

• galax-api / galax-commerce — núcleo NestJS + camada de e-commerce desacoplada, backend-first.
• Poker Electron — desktop multiplataforma, prova de que Electron não é gambiarra quando bem arquitetado.
• NFMEI — sistema fiscal pra microempreendedores, simplificando o que sistemas enterprise complicam.
• Fashion Manager — gestão de coleções e estoque; o desafio era traduzir negócio específico pra software sem forçar o cliente a se adaptar.
• docsModule (NestJS) — módulo reutilizável de documentação viva de APIs.

Além dos projetos autorais, entro em projetos onde o escopo já estava atrasado, o código já estava frágil e a arquitetura já tinha dado sinais de colapso.

Aplicações típicas: sistemas administrativos, backoffices complexos, dashboards operacionais, migração de legado, reestruturação de código caótico, performance tuning de banco — prazo curto com impacto real.