Drills do operador — 8 cenários reais

Hipótese: family-prefix. A família vem do 1º segmento do path relativo ao CORPUS; apontando na raiz da própria família, o 1º segmento vira items ⇒ família Unknown ⇒ nada roteia ⇒ residue 0, sem erro (foi exatamente assim no primeiro run real da rota, 06-07).

# prova (compare o residue dos dois):
alembic distill ~/Documents/Resources/Bookmarks --offline   # residue 0 (Unknown)
alembic distill ~/Documents/Resources --offline             # residue > 0 (Bookmarks)

Correção: aponte SEMPRE no pai das famílias; para escopar 1 família só, use o truque cpio dos package.jsonl. Registro: anote no STATE do seu loop: "residue 0 + exit 0 = conferir corpus root ANTES de culpar o modelo".

Hipótese: o pacote não tem vitest.config.ts PRÓPRIO — sem ele, o filtro "passa" sem executar teste nenhum (gotcha documentado; o comentário da raiz engana).

# prova: conte os testes executados, não a cor
pnpm --filter @alembic/novo test 2>&1 | grep -E "Test Files|Tests"
ls packages/novo/vitest.config.ts   # existe?

Correção: crie o vitest.config.ts do pacote (setupFiles em caminho ABSOLUTO, como os irmãos) e confirme o contador subindo (ex.: 1.834 → 1.834+N). Regra: a suíte inteira, sempre via node scripts/safe-test.mjs pnpm -w test.

Hipótese: symlink de workspace stale — a branch ADICIONOU uma dep que o seu node_modules local nunca instalou. O vitest resolve por outro caminho e engana; o tsc não perdoa; CI é imune porque instala do zero.

# prova + correção:
pnpm install                        # materializa o symlink novo
pnpm -r build                       # deps geram os .d.ts que os dependentes leem
pnpm -r typecheck                   # agora julga de verdade

Registro: "checkout de branch com dep workspace nova ⇒ pnpm install ANTES de confiar em qualquer resultado local." Nunca conclua pelo vitest verde.

Hipótese (que é certeza de desenho): a varredura é FABRICADA. O turno do A4c não tem tool-loop — o modelo não tem como ler o filesystem; pedir "varra X" produz varredura com cara de real (provado na fronteira, é o caveat de honestidade do spec). O registro no journal é honesto sobre O QUE FOI PERGUNTADO E RESPONDIDO — não sobre o mundo.

# prova: qualquer item da lista
ls <um-dos-paths-citados>            # não bate? fabricação confirmada
alembic automation show emp-pesquisador-0   # o manifest não declara tool nenhuma

Correção: descartar as "descobertas"; colocar os dados VERIFICADOS no prompt (você varre, o modelo raciocina) até a perna tool-loop existir. Registro: marcar no journal que o output foi tratado como não-verificado.

Checklist do operador: (1) proveniência — TODO registro mantém sourceRefs+hash? (2) dedupe — a promoção preserva os ids determinísticos para re-runs continuarem no-op? (3) separação ADR-0002 — learnings NÃO se misturam ao store de signals; são cadeias com budgets, stores e cadências separados por decisão registrada; (4) leitura por amostra — learnings são destilação, não fatos: μ0.94 é a média da rota, não um selo individual.

# prova por amostragem antes de decidir
head -3 ~/.alembic-learnings-bkm/Skills/learning/learnings.jsonl
alembic status                     # os dois stores, cada um no seu lugar

Decisão: promoção de store é mudança de contrato — decisão de founder com ADR, não um cat >> de madrugada. Até lá, o isolamento É a feature.

Hipótese: violação clássica que o detector pega: cor fora de token (ou contraste dependente de tema) + fonte abaixo do mínimo. A regra da casa: texto mono de apoio ≥ 12px, cores SEMPRE via tokens do shell (--ok/--bad/--clay-d…), e TESTAR NOS DOIS TEMAS antes de publicar (o toggle existe para isso).

# prova
impeccable detect docs/                 # o gate acusa inline-color/tamanho
# correção: badge com token + tamanho mínimo
font: 12px var(--mono); color: var(--ok); border: 1px solid var(--ok);

Registro: "cor nova = token novo no shell compartilhado, nunca hex local" — se precisar de um componente novo, ele entra no template para TODAS as lições herdarem.

Hipótese: órfãos tinypool — matar só o processo main deixa os forks reparentearem para o PID 1 e girarem para sempre. O kill certo é no GRUPO de processos, e a prevenção é nunca rodar a suíte "pelada" em loop.

# agora: identifique e mate o grupo
ps -Ao pid,ppid,pgid,pcpu,etime,comm | grep node | grep -v grep
kill -TERM -<pgid>                  # o sinal vai para o GRUPO (note o sinal de menos)
# para sempre: o baseline canônico já embute a proteção
node scripts/safe-test.mjs pnpm -w test   # process-group kill + sweep no final

Registro: se um teste NOVO pendura a suíte, o safe-test mata e varre — mas a causa raiz (teardown pendente) vira issue, não convivência.

Hipótese: é EXATAMENTE o pior ofensor eleito pelo digest #1 do failure-historian — drift de contagem. A resposta da casa não foi "corrigir o número": foi parar de digitar números. scripts/derive-counts.mjs (PR #158) deriva as contagens da fonte, e a PRIMEIRA execução pegou este drift vivo (docs 32; real 33/47).

# prova
node scripts/derive-counts.mjs          # a fonte responde: 33 comandos / 47 formas

Correção: o PR troca o número digitado pelo número DERIVADO (e idealmente cita o script). Registro: este curso segue a mesma lei — olhe o rodapé de qualquer página: "números derivados, nunca digitados".