Fronteiras de produção: roster, Docker, credenciais
Impeça que um provider opt-in bem-sucedido vire silenciosamente uma dependência de produção não provada.
Commit upstream fixado: b189869b7755d2b482969acf6c92da3ecfeffd36
- Distinguir disponibilidade do provider de seleção no roster.
- Listar pré-requisitos Docker sem realizar rollout não aprovado.
- Manter secrets fora de comandos, artefatos e logs.
A grande ideia
Adicionar `factory.grok()` disponibiliza uma capacidade para callers explícitos. Não instala Grok na imagem da Factory, não autentica um container e não adiciona Grok ao roster fixo de planner/implementer/reviewer. Essas são decisões separadas com Proof Gates separados.
Pense como… Colocar um instrumento novo no depósito não reescreve a partitura nem põe um músico no palco. A analogia quebra porque um CLI também precisa de credenciais, rede, pin de versão e política de sandbox antes de o palco existir.
`.factory/run.ts` continua um roster pequeno e explícito: Claude para planning/publishing e rotas Codex para implementation/review. `.factory/Dockerfile` instala Codex e Claude fixados, não Grok. O export do provider é apenas superfície aditiva de biblioteca.
Para CI/container, o guia upstream suporta `XAI_API_KEY` e flows de device/external auth; credenciais de browser armazenadas têm precedência quando presentes. Um design de produção precisa escolher um método de injeção, impedir logs, fixar o CLI e provar a imagem exata. Não deve copiar `~/.grok/auth.json` casualmente.
Evidência: Guia fixado de autenticação
Compare as fronteiras
Seguro: caller explícito, secret injetada, imagem fixada, smoke independente.
Arriscado: auto-route para CLI apenas host ou copiar auth pessoal para uma imagem.
| Superfície | Upstream | Alembic | Veredito |
|---|---|---|---|
| Library export | `factory.grok()` disponível | Já implementado | OPT-IN |
| Factory image | Binário fixado + auth + rede | Grok não instalado | FUTURE |
| Fixed roster | Escolha planner/implementer/reviewer | Sem rota Grok | UNCHANGED |
Para CI/container, o guia upstream suporta `XAI_API_KEY` e flows de device/external auth; credenciais de browser armazenadas têm precedência quando presentes. Um design de produção precisa escolher um método de injeção, impedir logs, fixar o CLI e provar a imagem exata. Não deve copiar `~/.grok/auth.json` casualmente.
Código e comandos reais
.factory/run.ts + .factory/Dockerfile
rg -n "planner:|implementer:|reviewer:" .factory/run.ts rg -n "codex|claude|grok" .factory/Dockerfile # Current evidence: # .factory/run.ts -> Claude/Codex fixed roster # .factory/Dockerfile -> Codex + Claude install; no Grok
Como chegar lá
sed -n '1,90p' .factory/run.ts sed -n '1,90p' .factory/Dockerfile sed -n '1,70p' packages/factory/README.md
Evidência: RESOURCES.md
Atlas visual
Prática e feedback
`factory.grok()` funciona no host. `.factory/run.ts` pode rotear trabalho de produção para ele agora?
Cartões de recuperação
Alterne as camadas de produção
Selecione uma camada e veja seu pré-requisito e status atual.
Resumo em quatro slides
Teste seu modelo
O que muda quando `factory.grok()` é exportado?