decision-path — Grafo de Dependências em ASCII de Decisões Pendentes
Decisões não acontecem no vácuo. O que parece razoável isoladamente frequentemente bloqueia trabalhos subsequentes, pressupõe precursores não construídos ou contorna portões de segurança estabelecidos. decision-path torna causalidades, sequências de execução e contradições transparentes no terminal.
Quando usar
- Um inventário existente de decisões abertas (do decision-briefing Fase 1, contexto de sessão ou briefing de decisão mestre de ticket) precisa ser estruturado.
- Você precisa identificar quais decisões podem ser executadas imediatamente (nós raiz) e quais dependem de pré-requisitos ou bloqueadores externos.
- Você precisa de uma visão geral de quais recomendações se encaixam harmoniosamente e onde duas recomendações colidem lógica ou operacionalmente.
- Palavras de disparo:
/decision-path, "quais decisões dependem umas das outras", "grafo de dependência de decisões", "visualizar caminho de decisão", "árvore de decisão ASCII", "contradições entre decisões", "verificar dependências causais". - Não use:
- Para primeiro descobrir e inventariar perguntas abertas — isso é feito pelo decision-briefing Fase 1.
- Para agrupar escolhas recomendadas em um único conceito coerente para aprovação — isso é feito pelo decision-draw.
- Para blocos compactos de cinco partes com opções e prós/contra por opção — isso é feito pelo decision-shot.
- Para avaliar metodicamente uma única decisão complexa com frameworks (pontuação ponderada, análise de cenários) — isso é feito pelo decide.
Fronteiras na Família de Decisões
| Skill | Papel | Entrada | Saída |
|---|---|---|---|
decide | Estrutura metodicamente uma única decisão | Critérios, opções | Matriz de pontuação, decisão única |
decision-briefing | Decompõe muitas decisões abertas em perguntas individuais com opções | Lista de pontos pendentes | Briefing numerado A/B/C/D, marcadores de dependência aproximados, agendamento em lote |
decision-path | Valida e visualiza causalidades e contradições entre muitas decisões | Marcadores aproximados do briefing/registro | Grafo de dependência ASCII com 5 avaliações de nó e status de aresta |
decision-draw | Agrupa recomendações em um todo coerente para aprovação | Pacotes do decision-path | Conceito, interação (apenas variante recomendada), retransferência |
decision-shot | Comprime análises finalizadas à sua essência executiva (1 decisão ou pacote apertado) | 1 pergunta ou grupo analisado | Forma curta de cinco partes com opções, prós/contra e link da análise completa |
decision-avatar | Modela preferências do usuário e histórico comportamental | Contexto, escolhas passadas | Classificação de confiança 🟢 / 🟡 / 🔴 |
Contrato e Responsabilidade em relação ao decision-briefing
A Fase 1 do decision-briefing já deriva dependências aproximadas e ordem de execução durante a triagem (por exemplo, a partir de sinais como "Depois automaticamente:", bloqueadores ou referências de ticket). O decision-path não duplica essa derivação, mas constrói diretamente sobre esses marcadores aproximados:
- decision-briefing fornece marcadores aproximados: Ele fornece o inventário bruto de itens pendentes e pistas de acoplamento iniciais.
- decision-path valida, avalia e visualiza: Ele verifica sinais contra fatos documentados, separa arestas confirmadas das presumidas, atribui as cinco avaliações por nó e expõe colisões de portão.
- Loop de feedback sobre discrepâncias: Se o
decision-pathdescobrir uma dependência ausente ou mal representada no briefing, ele nunca a absorve silenciosamente, mas a reporta explicitamente de volta como uma nota de correção ao briefing.
As Cinco Classificações por Nó (e Status de Verificação de Aresta)
As cinco dimensões [S E U Z W] avaliam os nós (decisões pendentes ou resolvidas em seu contexto sistêmico). As arestas carregam seu tipo de relacionamento semântico (por exemplo, desbloqueio, bloqueio, pré-requisito) e status de verificação (confirmado vs. presumido).
Cada nó no grafo exibe uma string de avaliação compacta de cinco elementos:
[S+ E:<Opção> U<Direção><Confiança> Z+ W-]
-
Sensível (
S) — Solidez técnica e arquitetural:S+: Solução robusta, aborda um problema real, evita complexidade artificial.S~: Parcialmente sólida, mas carrega sobrecarga de manutenção ou operacional.S-: Solução falsa, ativismo cosmético ou um beco sem saída comprovado (ex: filtragem na alavanca errada).
-
Recomendado (
E) — Ação recomendada concreta e baseada em evidências:E:<Opção>: Escolha clara (ex:E:A,E:B,E:resolve,E:Step1).E-: Nenhuma recomendação acionável possível (fatos faltantes ou questão de política de alto nível).
-
Típico-do-usuário (
U) — Alinhamento com hábitos passados do usuário e regras codificadas (viadecision-avatar): Códigos de direção (a opção se encaixa nos hábitos?) e confiança de verificação separadamente:- Direção (primeiro caractere após U):
+: Típico-do-usuário — corresponde a decisões passadas, políticas (CLAUDE.md) ou preferências explícitas.~: Neutro / aberto — nenhuma preferência histórica dominante documentada.-: Atípico — desvia do fluxo de trabalho habitual ou hábitos estabelecidos.
- Confiança de verificação (segundo caractere):
- ASCII puro dentro do grafo ASCII:
!: Alta / fundamentada (em prosa: 🟢 documentado).~: Média / plausível (em prosa: 🟡 trade-off pertence fundamentalmente ao usuário).?: Baixa / não verificado (em prosa: 🔴 questão de política, sem precedentes). Escale em vez de adivinhar!
- ASCII puro dentro do grafo ASCII:
- Exemplos:
U+!(típico e documentado),U+~(típico, mas julgamento do usuário),U-!(atípico documentado),U~?(aberto, sem precedente -> escalar).
- Direção (primeiro caractere após U):
-
Coerente (
Z) — Harmonia arquitetural e estilística suave com nós vizinhos:Z+: Integra-se perfeitamente com precursores e decisões a jusante; forma um todo coeso sem atrito.Z~: Atrito estilístico menor ou sobrecarga operacional, mas funcionalmente viável.Z-: Atrito perceptível na interação sistêmica (ex: proliferação de configuração, acoplamento estranho), mas não quebra uma regra rígida.
-
Contraditório (
W) — Contradição dura e violação de política/portão (saída mais crítica — alarme!):W-: Livre de contradições contra outras recomendações, políticas e portões de segurança ativos.W+: Colisão dura / alarme! Invalida outra recomendação, viola uma política estabelecida (CLAUDE.md, P-00x) ou contorna um portão de segurança ativo. Nós em colisão são sempre destacados explicitamente na seçãoCONTRADICTIONScom causa raiz e caminho de resolução.
Tipos de Aresta e Regras de Derivação
As dependências são derivadas estritamente do texto fonte, nunca inventadas. As arestas carregam seu tipo de relacionamento e status de verificação:
| Sinal na Fonte | Tipo de Aresta | Notação | Significado |
|---|---|---|---|
| "Depois automaticamente: ...", "desbloqueia", "habilita" | Desbloqueia | "#" | A decisão alvo torna-se acionável somente após a decisão fonte (documentado) |
| "bloqueia", "impede", "portão de segurança dispara" | Bloqueia | "=>" | O alvo está bloqueado até a fonte ser resolvida |
| "requer", "precisa antes", "pré-requisito" | Requer | "-->" | O alvo lógica e cronologicamente requer a fonte |
| "decisão de acompanhamento", "passo 2 depois" | Sequência | "-->" | Progressão lógica a jusante após a execução |
| "refutado por medição", "obsoleto", "substituído por" | Invalida | "--X-->" | A percepção da fonte torna o alvo obsoleto |
| D-ID compartilhado, ID de Ticket ou mesmo subsistema sem evidência textual | Presumido | "?-->" | Acoplamento plausível sem prova causal documentada (não verificado) |
Regra para Arestas Não Verificadas: Quando nenhuma declaração causal explícita existe no texto, a aresta deve ser marcada como presumida (
?-->) — nunca como fato confirmado. Onde nenhum relacionamento é documentado, os nós permanecem desconectados lado a lado.
Diretrizes de Formato para o Grafo ASCII
- Monoespaçado & Otimizado para Terminal: Largura máxima de linha 100 colunas. Sem tabelas largas que quebrem o layout do terminal.
- Conjunto de Caracteres & Pureza: ASCII puro. Dentro do bloco de código do grafo, nenhum emoji (🟢🟡🔴) pode aparecer; a confiança é representada exclusivamente por marcadores ASCII (
!,~,?). - IDs de Nó: Apenas identificadores existentes (
PD-A,MD-A,BH-A,VM-A,QR-A,CL-A,MO-A,D-001,732597768). Nunca invente IDs sintéticos! Se um item não tiver abreviação, seu número de item é usado. Etapas internas de acompanhamento são representadas como anotações de aresta não numeradas(...). - Estrutura em Camadas:
LEVEL 0 - independent: Nós raiz, itens desbloqueados, gatilhos externos.LEVEL 1 - depends on exactly one: Acompanhamentos diretos.LEVEL 2 - depends on multiple / deep chain: Nós com múltiplas dependências ou cadeia profunda.CONTRADICTIONS: Colisões duras, violações de portão e recomendações conflitantes (W+).LEGEND: Obrigatório em cada saída de grafo. Cada caractere estrutural usado no grafo (|,=Opção,(...), setas de aresta) deve ser listado e explicado na legenda.
- Bloco Mermaid Opcional: Um bloco de código
mermaidadicional pode ser anexado se útil; o grafo ASCII permanece a saída primária e autoritativa.
Exemplo (Conjunto de Dados Piloto: Ticket-Master 2026-09-13)
Trecho real do briefing de decisão Ticket-Master (732597768, MO-A, CL-A, QR-A, 387521104, CL-B):
====================================================================================================
DECISION-PATH: GRAFO DE DEPENDÊNCIAS (Piloto Ticket-Master 2026-09-13)
====================================================================================================
LEVEL 0 - independent (Decisões raiz e bloqueadores externos)
[732597768] Resolver problema de faturamento do GitHub [S+ E:resolve U+! Z+ W-]
| desbloqueia
+--> [MO-A] Lançar Wave 2 [S+ E:A U+~ Z+ W-]
[CL-A] Mesclar PR #6 e PR #8 do admin clutch [S+ E:A U+! Z+ W-]
| bloqueado por: [Gate "1 Revisão de Aprovação" (auto-aprovação impossível)]
--> (decisão de acompanhamento: definir proteção de branch para 0 ou bot)
[QR-A] Renomear junção NTFS da fila (_TICKETS -> TICKETS) [S+ E:B U+! Z+ W-]
+--> [387521104] Execuções da janela noturna (documentado: apenas sob B)
[CL-B] Portão de revisão do piloto: chave de assinatura Mac [S+ E:Step1 U+~ Z+ W-]
--> (etapas de acompanhamento 2-4: automatização do modelo após provisionamento da chave)
LEVEL 1 - depends on exactly one precursor
[MO-A] Lançar Wave 2 [S+ E:A U+~ Z+ W-]
| requer: [732597768] (faturamento resolvido, portões de CI remoto ativos novamente)
| requer: [Gate PRIVATE.txt "CI remoto verde"]
--> (etapa de acompanhamento: alternar visibilidade permanece ação apenas do usuário)
LEVEL 2 - depends on multiple / deep chain
[387521104] Execução de migração autônoma na janela noturna [S+ E:B U+! Z+ W-]
| requer: [QR-A]=B (junção NTFS estabelecida)
| requer: (junção definida no segundo host via ticket de transferência -
| número do ticket não informado no briefing)
----------------------------------------------------------------------------------------------------
CONTRADIÇÕES E COLISÕES DE PORTÃO
----------------------------------------------------------------------------------------------------
[MO-A]=B X [Gate PRIVATE.txt "CI remoto verde"]
Conflito: A Opção B lançaria a Wave 2 com base apenas em testes locais,
embora dois contratos de módulo exijam explicitamente CI remoto verde.
Resolução: A Recomendação A força [732597768] (faturamento) primeiro, resolvendo a colisão.
[CL-A]=StatusQuo X [Gate "1 Revisão de Aprovação" (auto-aprovação impossível)]
Conflito: master exige 1 revisão, mas a única conta do repositório é lukisch.
Resolução: A Recomendação A (mesclagem admin) legitima quebra o beco sem saída.
----------------------------------------------------------------------------------------------------
LEGENDA E CHAVE DE CLASSIFICAÇÃO
----------------------------------------------------------------------------------------------------
Arestas e Estrutura:
+--> desbloqueia / habilita (causalidade documentada na fonte)
=> bloqueia / impede (portão ou bloqueador externo)
--> requer / sequência (pré-condição ou etapa de acompanhamento)
?--> dependência presumida (acoplamento plausível, mas não documentado)
--X--> invalida / substitui (percepção da fonte torna alvo obsoleto)
X contradição / colisão (violação de portão ou política)
| linha de hierarquia vertical / mapeamento de atributo
[ID] nó de decisão (abreviação do item ou número do item do briefing)
[Gate] portão / regra / contrato externo - NÃO é um nó de decisão
=Opt opção específica para um nó (ex: [MO-A]=B)
(...) anotação de aresta não numerada / etapa de acompanhamento (nenhum ID sintético inventado)
Avaliação do Nó [S E U Z W]:
S: Sensível (+ sólido / ~ qualificado / - insensato)
E: Recomendado (A, B, C, resolve, Step1, - nenhum)
U: Típico-do-usuário (direção: + típico / ~ neutro / - atípico;
confiança: ! fundamentado / ~ trade-off / ? escalar)
[! = documentado (verde em prosa), ~ = trade-off do usuário (amarelo em prosa),
? = não verificado / escalar (vermelho em prosa)]
Z: Coerente (+ harmoniza / ~ leve atrito / - quebra arquitetural)
W: Contraditório (- sem conflito / + colisão dura com portão ou política)
====================================================================================================
O que o decision-path NÃO Faz
- Não toma decisões: O skill fornece transparência estrutural. A autoridade para decidir permanece com o usuário.
- Não inventa opções: O skill não gera novas alternativas ou critérios de ponderação; isso pertence ao decide ou decision-briefing.