A matriz de sobreposição: adopt, already, defer, reject
Transforme admiração pelo repositório em uma decisão de propriedade que o Alembic consiga manter.
Commit upstream fixado: b189869b7755d2b482969acf6c92da3ecfeffd36
- Aplicar os quatro vereditos a uma superfície concreta.
- Separar aprendizado útil de adoção de código.
- Nomear o blocker que transforma ADOPT em DEFER.
A grande ideia
Uma boa ideia upstream não vira automaticamente uma feature que o Alembic deve copiar. Cada superfície precisa responder a duas perguntas: o Alembic já é dono desse trabalho e conseguimos provar o novo valor numa fronteira real? Os quatro vereditos evitam duplicação atraente e preservam um roadmap para lacunas genuínas.
Pense como… Use a matriz como uma junta de transplante: combine o órgão com uma necessidade real, rejeite duplicatas incompatíveis e adie a cirurgia até os pré-requisitos estarem prontos. Ela quebra porque features podem ser reavaliadas com baixo custo; decisões médicas não.
ADOPT exige dono ausente, interface estreita, implementação limitada e Proof Gate real. ALREADY direciona o aprendizado para donos existentes no Alembic. DEFER registra uma unidade atraente com blocker explícito. REJECT protege a arquitetura de um segundo plano de controle.
O antipadrão central é pensar por contagem de features. Sessões, rewind, worktrees, hooks, plugins, TUI e sandbox do Grok são impressionantes, mas importá-los duplicaria camadas maduras do Alembic. O design pode informar testes e costuras futuras sem virar código copiado.
Evidência: README fixado do Grok Build
Compare as fronteiras
Seguro: registrar decisão, blocker, prova e próximo dono.
Arriscado: igualar estrelas ou volume de código a fit arquitetural.
| Superfície | Upstream | Alembic | Veredito |
|---|---|---|---|
| Streaming JSONL | Contrato de subprocesso documentado | Costura de provider disponível | ADOPT |
| Sessions / rewind | Diretório coordenado + snapshots | Costura atual de storage de arquivo único | DEFER |
| TUI / tools / sandbox | Implementações upstream completas | Donos existentes no Alembic | REJECT |
O antipadrão central é pensar por contagem de features. Sessões, rewind, worktrees, hooks, plugins, TUI e sandbox do Grok são impressionantes, mas importá-los duplicaria camadas maduras do Alembic. O design pode informar testes e costuras futuras sem virar código copiado.
Código e comandos reais
docs/grok-build-internalization/research.md (decision method)
type Verdict = "ADOPT" | "ALREADY" | "DEFER" | "REJECT";
const headlessProvider = {
fit: "high",
overlap: "low",
proof: "real grok CLI",
verdict: "ADOPT" satisfies Verdict,
};Como chegar lá
rg -n "ADOPT|ALREADY|DEFER|REJECT" docs/grok-build-internalization docs/courses/grok-build-for-alembic
Evidência: RESOURCES.md
Atlas visual
Prática e feedback
Uma feature é valiosa, mas falta o pré-requisito de storage. Qual veredito é honesto?
Cartões de recuperação
Filtre o quadro de decisão
Selecione um veredito para ver sua regra operacional.
Resumo em quatro slides
Teste seu modelo
Onde entram as sessões multi-file do Grok na fase um?