Roadmap e playbook operacional
Escolha a próxima unidade limitada por pré-requisito e prova — não por contagem de features upstream.
Commit upstream fixado: b189869b7755d2b482969acf6c92da3ecfeffd36
- Escolher unidade futura pela necessidade do produto e prontidão do pré-requisito.
- Escrever uma fronteira de prova real antes da implementação.
- Manter superfícies duplicadas rejeitadas fora do roadmap.
A grande ideia
A fase um termina quando o provider opt-in funciona e seus limites estão explícitos. Trabalho futuro deve avançar uma fronteira honesta por vez: primeiro prontidão da imagem se produção precisar do Grok, storage atômico de sessão se resume importar, ou pesquisa ACP/stdio se telemetria de tools valer a complexidade. O resto permanece com donos existentes no Alembic.
Pense como… Trate o roadmap como uma via de escalada: cada ancoragem precisa segurar antes de você transferir peso para a próxima. A analogia quebra porque ramos independentes — Docker, sessões, telemetria — podem ser escalados separadamente quando a necessidade de produto estiver clara.
Candidato A: fixar e instalar Grok em `.factory/Dockerfile`, escolher injeção auth sem vazamento e executar o sentinel exato dentro da imagem. Candidato B: generalizar session storage de um arquivo para bundle atômico de diretório, então provar capture/resume/fork. Candidato C: avaliar ACP/stdio para eventos estruturados de tools preservando a cintura estreita de AgentProvider.
Não faça auto-routing para Grok, não copie o runtime Rust nem crie subsistemas paralelos de hooks/plugins/TUI/sandbox. Reabra docs upstream fixadas/vivas antes de cada unidade porque flags do CLI e formas de evento podem mudar. Cada unidade recebe owner, blocker, comando de prova, rollback e validator independente.
Evidência: Guia fixado de gerenciamento de sessões
Compare as fronteiras
Seguro: uma unidade limitada, owner, blocker, prova e rollback explícitos.
Arriscado: “internalizar tudo” como plataforma paralela permanente.
| Superfície | Upstream | Alembic | Veredito |
|---|---|---|---|
| Docker readiness | Necessário para uso na imagem Factory | Pin + auth + smoke na imagem | NEXT IF NEEDED |
| Session bundle | Necessário para resume/fork | Storage atômico de diretório | DEFER |
| ACP telemetry | Necessário para eventos de tools | Pesquisa de protocolo + prova do adapter | DEFER |
Não faça auto-routing para Grok, não copie o runtime Rust nem crie subsistemas paralelos de hooks/plugins/TUI/sandbox. Reabra docs upstream fixadas/vivas antes de cada unidade porque flags do CLI e formas de evento podem mudar. Cada unidade recebe owner, blocker, comando de prova, rollback e validator independente.
Código e comandos reais
packages/factory/README.md (phase-one contract)
const nextUnit = {
id: "grok-docker-boundary",
prerequisite: "production actually needs Grok",
proof: [
"grok --version inside the pinned image",
"exact sentinel through factory.run inside the image",
"no credential in image layers or logs",
],
changesRoster: false,
};Como chegar lá
sed -n '1,80p' packages/factory/README.md rg -n "captureSessions|resumeSession|forkSession" packages/factory/src/GrokAgentProvider.ts
Evidência: RESOURCES.md
Atlas visual
Prática e feedback
Telemetria de tool calls é desejável, mas nenhum consumidor de produto precisa dela ainda. Qual é a próxima ação?
Cartões de recuperação
Ajuste a próxima unidade
Selecione um resultado desejado e leia a menor unidade honesta seguinte.
Resumo em quatro slides
Teste seu modelo
O que deve selecionar a próxima unidade do roadmap?