Resumo
O Stage 1 (mapeamento-s01-descobrindo) ganhou 3 blocos de fechamento aditivos em stories sucessivas — Etapa 4.6 (diagnóstico, STORY-215.W3.1), Etapa 4.7 (plano/priorização, STORY-215.W3.2) e Etapa 4.8 (os 4 singletons da base, STORY-247.W1.3). Todos os três são disparados pela mesma invocação de fechamento de task03 (task_completar_gaps_company_snapshot.md, Etapa 4).
Não existe caminho de re-entrada para essa invocação de fechamento num run cujo Stage 1 já fechou. Quem fechou o Stage 1 antes de um desses blocos existir não tem como executá-los depois — o company-snapshot.json fica permanentemente sem diagnostic, sem diagnostic.plan, e workspace/0-base/ fica permanentemente vazia.
Como o gate de entrega da missão (challenge-s01-verificando-entregabilidade, task_verificar_base.md ac-1) exige os 4 documentos de workspace/0-base/, o efeito prático é entrega bloqueada sem saída não-destrutiva.
Ambiente
| Item |
Valor |
| Bundle |
MANIFEST.json version 3.7.0, managed_section_version 3.7.0 |
build_date |
2026-08-18T14:52:19.733Z |
source_commit |
786eb0d7af |
| Produto |
SINKRA OPS Cohort — Student Edition V5 (sinkra-ops-cohort-v5@5.0.0) |
| Regime do state |
unified-v2 (progress-v2, run-*) |
| Host |
Claude Code, macOS |
O que aconteceu
Run com os 4 stages fechados (macro.current_stage: 4, quatro .ack com status: passed):
| Quando (UTC-3) |
Evento |
| 15/jun 14:07 |
company-snapshot.json capturado — completeness_score: 0.78 (acima do corte TK-SINKRA-STAGE-COMPLETENESS-MIN = 0.6) |
| 17/ago 18:44 |
workspace/0-base/ criada vazia pelo /sinkra-init (só taxonomia) |
| 18/ago 14:31 |
Stage 1 fecha — checkpoints/stage-1.ack, status: passed, closed_at: 2026-08-18T17:31:26Z |
| 18/ago 16:55 |
Update do bundle traz as Etapas 4.6/4.7/4.8 + os 5 templates R14 (41 arquivos de skill com esse mtime) |
O escritor da base chegou 2h24 depois do Stage 1 fechar.
Evidência verificada
| Verificação |
Resultado |
company-snapshot.json tem diagnostic? (4.6) |
não |
company-snapshot.json tem diagnostic.plan? (4.7) |
não |
base-artifacts.json existe em qualquer lugar do checkout? (4.8) |
não — find retorna vazio |
workspace/0-base/ tem algum arquivo (inclusive ocultos)? |
não — 0 arquivos |
Foi barrado por completeness_score? |
não — 0.78 ≥ 0.6 |
Existe flag de re-entrada em /sinkra-pipeline? |
não — as únicas formas documentadas são <run_id>, --companion, --new-workspace, --dry-run |
Ou seja: a corrente de fechamento inteira nunca rodou, e não por falha de qualidade — só por descompasso de versão.
Causa-raiz (classe do problema)
Blocos ADITIVOS foram enxertados numa task que, em runs existentes, já executou. O contrato de execução do pipeline é "task executada → stage fechado → .ack → segue". Não há noção de "esta task ganhou um passo novo depois que você a executou".
Isso não é específico da 4.8 — são três blocos com o mesmo problema, de duas stories diferentes (215 e 247). O padrão vai se repetir a cada bloco aditivo novo.
Por que o resume do R17 não cobre
O B4 do Step 0.5 oferece exatamente 4 opções:
(a) Retomar CONSULTIVO de {sub_progress.current_name}
(b) Continuar EXECUTOR do stage {macro.current_stage}
(c) Inspecionar estado (modo D — só lê, NÃO executa)
(d) Começar NOVO (arquiva o run atual, cria run novo)
Com macro.current_stage: 4 e os 4 stages done:
- (a)/(b) partem do estágio corrente — não voltam ao fechamento do Stage 1;
- (c) não executa;
- (d) arquiva o run inteiro — descarta 4 stages de trabalho (no caso real: 11 entity_types, 34 tasks, 52 fields, múltiplos ciclos de emenda registrados no
.ack) para recuperar 4 documentos derivados. Desproporcional a ponto de não ser opção.
A opção "Other — escrevo livre" existe, mas depende do aluno saber que os três blocos existem, em qual task moram e em que ordem rodam. Não há afordância nenhuma que sinalize isso.
Agravante: o passo já é idempotente por design
A Etapa 4.8 foi escrita para tolerar re-execução — o passo 1 manda reusar o id de um artifact com mesmo slug já presente em base-artifacts.json ("re-run nunca duplica nem troca identidade"), e o passo 2 protege doc do aluno via marcadores pareados SINKRA-BASE:BEGIN/END.
O passo é seguro de re-executar e mesmo assim inalcançável. Falta só o gatilho.
Impacto
- Todo aluno cujo Stage 1 fechou antes do bundle 3.7.0 tem
workspace/0-base/ vazia.
- O gate de entrega falha de forma determinística:
✖ [base] workspace/0-base/ sem 4 doc(s): company-dna.md, founder-dna.md, brand.md, icp.md
- A única saída documentada é destrutiva (
(d) começar novo).
- Silencioso: nada no fechamento do Stage 1, no resume ou no
doctor avisa que a base ficou por preencher. O aluno só descobre no gate de entrega, no fim.
Reprodução
- Rodar
/sinkra-pipeline até os 4 stages fecharem, num bundle anterior ao 3.7.0.
- Atualizar o bundle para 3.7.0 (
npx sinkra-os update).
- Rodar
/sinkra-pipeline <run_id> e escolher qualquer opção de resume.
- Observar:
workspace/0-base/ continua vazia; company-snapshot.json continua sem diagnostic; nenhuma opção do B4 alcança o fechamento do Stage 1.
Sugestões (não prescritivo — o time decide)
Em ordem de esforço crescente:
- Detecção + aviso. No Phase-0 recognition, comparar os blocos de fechamento presentes nas tasks com o que o artefato do run já tem (
diagnostic, diagnostic.plan, base-artifacts.json). Divergente → reportar explicitamente no resume, em vez de deixar o aluno descobrir no gate de entrega. Resolve o silêncio, que é a metade pior do problema.
- Opção de resume dedicada. Uma 5ª opção no
B4 do tipo "completar fechamento pendente do Stage {N}" que rode só a corrente 4.6 → 4.7 → 4.8 sobre o snapshot existente, sem retocar o resto do run.
- Backfill no
/sinkra-update. O /sinkra-update já faz sweep versionado de artefatos e é o lugar natural para "seu run está numa versão de contrato anterior; estes passos de fechamento faltam". Trataria a classe inteira, não só estes três blocos.
Nota sobre a origem deste report
Diagnóstico levantado em sessão read-only (nenhum artefato alterado). O handoff completo — linha do tempo, evidência, fontes já mapeadas e as armadilhas para a sessão de correção — está gravado em .sinkra/state/<run_id>/HANDOFF-base-0-base-20260819.md no checkout afetado, disponível se ajudar a reproduzir.
Todas as afirmações acima são leitura direta de disco [Confiança: ALTA], exceto a ausência de caminho de re-entrada, que é [Confiança: MÉDIA] — varri as formas documentadas de /sinkra-pipeline, o B4 do R17 e o SKILL.md/tasks do Stage 1 procurando por re-run/backfill/redo/idempotência, e não achei; pode existir afordância não-documentada que eu não alcancei.
Resumo
O Stage 1 (
mapeamento-s01-descobrindo) ganhou 3 blocos de fechamento aditivos em stories sucessivas — Etapa 4.6 (diagnóstico, STORY-215.W3.1), Etapa 4.7 (plano/priorização, STORY-215.W3.2) e Etapa 4.8 (os 4 singletons da base, STORY-247.W1.3). Todos os três são disparados pela mesma invocação de fechamento detask03(task_completar_gaps_company_snapshot.md, Etapa 4).Não existe caminho de re-entrada para essa invocação de fechamento num run cujo Stage 1 já fechou. Quem fechou o Stage 1 antes de um desses blocos existir não tem como executá-los depois — o
company-snapshot.jsonfica permanentemente semdiagnostic, semdiagnostic.plan, eworkspace/0-base/fica permanentemente vazia.Como o gate de entrega da missão (
challenge-s01-verificando-entregabilidade,task_verificar_base.mdac-1) exige os 4 documentos deworkspace/0-base/, o efeito prático é entrega bloqueada sem saída não-destrutiva.Ambiente
MANIFEST.jsonversion 3.7.0,managed_section_version3.7.0build_date2026-08-18T14:52:19.733Zsource_commit786eb0d7afsinkra-ops-cohort-v5@5.0.0)progress-v2,run-*)O que aconteceu
Run com os 4 stages fechados (
macro.current_stage: 4, quatro.ackcomstatus: passed):company-snapshot.jsoncapturado —completeness_score: 0.78(acima do corteTK-SINKRA-STAGE-COMPLETENESS-MIN = 0.6)workspace/0-base/criada vazia pelo/sinkra-init(só taxonomia)checkpoints/stage-1.ack,status: passed,closed_at: 2026-08-18T17:31:26ZO escritor da base chegou 2h24 depois do Stage 1 fechar.
Evidência verificada
company-snapshot.jsontemdiagnostic? (4.6)company-snapshot.jsontemdiagnostic.plan? (4.7)base-artifacts.jsonexiste em qualquer lugar do checkout? (4.8)findretorna vazioworkspace/0-base/tem algum arquivo (inclusive ocultos)?completeness_score?/sinkra-pipeline?<run_id>,--companion,--new-workspace,--dry-runOu seja: a corrente de fechamento inteira nunca rodou, e não por falha de qualidade — só por descompasso de versão.
Causa-raiz (classe do problema)
Blocos ADITIVOS foram enxertados numa task que, em runs existentes, já executou. O contrato de execução do pipeline é "task executada → stage fechado →
.ack→ segue". Não há noção de "esta task ganhou um passo novo depois que você a executou".Isso não é específico da 4.8 — são três blocos com o mesmo problema, de duas stories diferentes (215 e 247). O padrão vai se repetir a cada bloco aditivo novo.
Por que o resume do R17 não cobre
O
B4do Step 0.5 oferece exatamente 4 opções:Com
macro.current_stage: 4e os 4 stagesdone:.ack) para recuperar 4 documentos derivados. Desproporcional a ponto de não ser opção.A opção "Other — escrevo livre" existe, mas depende do aluno saber que os três blocos existem, em qual task moram e em que ordem rodam. Não há afordância nenhuma que sinalize isso.
Agravante: o passo já é idempotente por design
A Etapa 4.8 foi escrita para tolerar re-execução — o passo 1 manda reusar o
idde um artifact com mesmoslugjá presente embase-artifacts.json("re-run nunca duplica nem troca identidade"), e o passo 2 protege doc do aluno via marcadores pareadosSINKRA-BASE:BEGIN/END.O passo é seguro de re-executar e mesmo assim inalcançável. Falta só o gatilho.
Impacto
workspace/0-base/vazia.(d)começar novo).doctoravisa que a base ficou por preencher. O aluno só descobre no gate de entrega, no fim.Reprodução
/sinkra-pipelineaté os 4 stages fecharem, num bundle anterior ao 3.7.0.npx sinkra-os update)./sinkra-pipeline <run_id>e escolher qualquer opção de resume.workspace/0-base/continua vazia;company-snapshot.jsoncontinua semdiagnostic; nenhuma opção do B4 alcança o fechamento do Stage 1.Sugestões (não prescritivo — o time decide)
Em ordem de esforço crescente:
diagnostic,diagnostic.plan,base-artifacts.json). Divergente → reportar explicitamente no resume, em vez de deixar o aluno descobrir no gate de entrega. Resolve o silêncio, que é a metade pior do problema.B4do tipo "completar fechamento pendente do Stage {N}" que rode só a corrente 4.6 → 4.7 → 4.8 sobre o snapshot existente, sem retocar o resto do run./sinkra-update. O/sinkra-updatejá faz sweep versionado de artefatos e é o lugar natural para "seu run está numa versão de contrato anterior; estes passos de fechamento faltam". Trataria a classe inteira, não só estes três blocos.Nota sobre a origem deste report
Diagnóstico levantado em sessão read-only (nenhum artefato alterado). O handoff completo — linha do tempo, evidência, fontes já mapeadas e as armadilhas para a sessão de correção — está gravado em
.sinkra/state/<run_id>/HANDOFF-base-0-base-20260819.mdno checkout afetado, disponível se ajudar a reproduzir.Todas as afirmações acima são leitura direta de disco
[Confiança: ALTA], exceto a ausência de caminho de re-entrada, que é[Confiança: MÉDIA]— varri as formas documentadas de/sinkra-pipeline, oB4do R17 e oSKILL.md/tasks do Stage 1 procurando por re-run/backfill/redo/idempotência, e não achei; pode existir afordância não-documentada que eu não alcancei.