decision-draw — Visão Geral e Aprovação Conjunta para Decisões Agrupadas

Quando cinco ou dez decisões estão pendentes, é fácil se perder nos detalhes de opções isoladas e perder de vista o sistema emergente. O decision-draw não descreve as alternativas; ele pinta o todo em funcionamento: Como os sistemas cooperam uma vez que todas as recomendações estão em vigor? O usuário aprova a imagem como um todo ou fornece feedback direcionado.

Quando usar

Múltiplas decisões interdependentes (do decision-briefing ou de um documento de briefing de decisões) não devem ser consumidas como uma lista de verificação tediosa de perguntas individuais.
O usuário deseja ver como os componentes realmente interagem na prática diária após a implementação, antes de aprová-los.
Um aglomerado de decisões fortemente acopladas identificadas através do gráfico de dependência (decision-path) pode ser aprovado em conjunto como uma unidade funcional.
Palavras de gatilho: /decision-draw, "qual é a aparência do todo se concordarmos com tudo", "desenhe o panorama geral", "conceito geral da decisão", "decision draw", "como os sistemas funcionam juntos depois", "imagem de aprovação geral".
Não use:
- Quando o usuário deseja avaliar opções distintas por item e escolher por letras (A/B/C) — isso é feito pelo decision-briefing.
- Para análise pura de causalidade e gargalos no terminal — isso é feito pelo decision-path.
- Para avaliações de opções isoladas em blocos discretos de 5 partes (contexto, prós/contras por opção, recomendação) para questões únicas ou perguntas agrupadas — isso é feito pelo decision-shot.
- Para avaliar metodicamente uma única questão de política em aberto — isso é feito pelo decide.

Limites na Família de Decisão

Skill	UX & Foco	Postura sobre Opções	Modo de Aprovação
`decision-briefing`	Decompõe em itens individuais	Mostra todas as opções A/B/C/D	Códigos de letras (`1A 2C 3B`)
`decision-path`	Estrutura causalidades	Avalia opções no gráfico	Diagnósticos de terminal (ASCII)
`decision-draw`	Imagem alvo coesa (agrupa decisões interdependentes)	Descreve apenas a variante recomendada (alternativas vinculadas)	Aprovação holística ou frase de correção
`decision-shot`	Blocos discretos estruturados (para questões únicas ou grupos restritos)	Mostra opções com 2–4 marcadores de prós/contras	Decisão executiva / revisão individual
`decide`	Elabora questão única	Matriz de avaliação (critérios)	Recomendação analítica

Regra Central: O decision-draw descreve exclusivamente a variante recomendada. As alternativas descartadas não desapareceram — elas estão documentadas no decision-briefing, no decision-shot ou em tickets vinculados, e são referenciadas na tabela de cabeçalho. Um desenho sem esse link tira a escolha do usuário em vez de simplificá-la.

Estrutura Obrigatória (Sete Partes)

Um decision-draw completo segue rigorosamente este layout de sete partes:

1. Pacote e Escopo

Resumo tabular de todos os itens incluídos no pacote:

Abreviatura / ID (ex.: BH-A, MD-A, CF-A)
Referência do ticket
Título curto do item
Recomendação assumida (a premissa desta imagem abrangente)
Confiança do decision-avatar (🟢 documentado, 🟡 trade-off, 🔴 precisa de escalonamento)
Link para análise completa / alternativas

2. Conceito

O estado alvo em prosa coesa:

Qual paisagem de sistema ou fluxo de trabalho emerge quando todas as recomendações são executadas exatamente como planejado?
Sem comparação lado a lado de opções, sem hesitação no modo subjuntivo ("também se poderia").
Indicativo claro e confiante: É assim que o sistema opera em seu estado alvo.

3. Interação

O núcleo funcional da habilidade:

Como os componentes decididos realmente se encaixam após a implementação?
Enquadrado ao longo de um fluxo operacional concreto de ponta a ponta (ex.: "Um ticket chega → agente inicia → backend atribui → implanta no host") em vez de uma lista estática de componentes.
Esclarece fluxos de dados, interfaces e responsabilidades operacionais.

4. Implementação

A sequência concreta de etapas de implantação:

O que acontece na prática, passo a passo?
Herda a sequência de execução e a lógica de dependência diretamente do decision-path.
Fluxos de trabalho independentes são representados honestamente como trilhas paralelas (não invente cadeias causais artificiais; um pacote pode consistir em múltiplas trilhas paralelas). A ordenação sequencial é afirmada apenas onde existem dependências ou prazos fundamentados.
Destaca portões, scripts de migração e verificações de validação.

5. O Que Esta Imagem Não Abrange

Defesa de limites contra uma falsa sensação de completude:

Quais questões secundárias, problemas não resolvidos ou confianças 🔴 são deliberadamente excluídos?
Onde estão as linhas divisórias para sistemas vizinhos?
Uma imagem que oculta suas margens produz uma falsa sensação de segurança.

6. Aprovação

A interação com o usuário:

O usuário revisa a imagem como um todo.
Opção de resposta 1: Aprovação explícita geral ("Parece bom", "Aprovado", "Implementar tudo como proposto"). Somente neste caso todos os itens do pacote são registrados como decididos.
Opção de resposta 2: Correção direcionada em linguagem natural ("Prefiro a variante menor para BH-A", "Sem reinicialização automática para MD-A", "Mantenha VM-A como está"). Aciona a decomposição em decisões discretas; todos os itens não corrigidos permanecem abertos.

7. Retroalimentação

A tradução sistemática do feedback do usuário em entradas individuais do livro-razão:

Sem Cô-registro Automático: Itens inalterados são registrados apenas mediante aprovação geral explícita. Uma correção parcial não é uma aprovação geral!
Isolamento na Correção: Se o usuário enviar uma correção, ela é decomposta em decisões individuais; todos os outros itens no pacote permanecem estritamente abertos (nos tickets de origem / livro-razão) até que o usuário aceite a imagem ajustada como um todo ou confirme os itens restantes individualmente.
Tabela de Retroalimentação Obrigatória: Cada feedback parcial gera uma tabela de avaliação estruturada com quatro colunas:
1. Correção Original: Declaração literal do usuário.
2. Chaves Afetadas: Quais IDs do pacote são alterados (incluindo impactos múltiplos quando uma declaração toca em várias decisões).
3. Status Dominó: Quais nós dependentes ou suposições downstream no decision-path colapsam ou exigem reavaliação.
4. Ambiguidades em Aberto: Onde a correção permite múltiplas interpretações que exigem esclarecimento antes do registro.
Lidando com Impactos Múltiplos: Uma única declaração do usuário pode alterar várias decisões simultaneamente. A retroalimentação deve desembaraçar esse acoplamento e capturar todas as chaves afetadas juntas.
Caminho de Gravação Exclusivo via Fase 4: O decision-draw não tem caminho de gravação nativo para tickets ou livros-razão. As atualizações do livro-razão ocorrem exclusivamente através do protocolo padronizado na decision-briefing Fase 4 (registro e persistência em DECIDED-AND-DONE.md ou TO-DECIDE-USER.txt).

Exemplo (Conjunto de Dados Piloto: Ticket-Master 2026-09-13 — BACH & Cluster de Sistema)

Pacote real do briefing de decisão Ticket-Master datado de 2026-09-13: BH-A, MD-A, CF-A, VM-A, PD-A.

# DECISION-DRAW: BACH Core Cluster & Operational Integrity

## 1. Bundle and Scope

| Key | Ticket / Source | Topic | Assumed Recommendation | Confidence | Alternatives & Details |
|---|---|---|---|---|---|
| `BH-A` | `T-20260913-896336887` | Model backend = Heart | 1A / 2A / 3A / 4B / 5A / 6A | 🟢 | `docs/MODELL-BACKEND-KONZEPT_2026-09-13.md` |
| `MD-A` | `T-20260913-799464688` | Mac deploy & restart | A1 + script (report-only for 24/7) | 🟢 | Ticket `T-20260913-799464688.txt` |
| `CF-A` | `T-20260913-947070291` | Config targets across hosts | 1C (justified) / 2B (host-dep.) / 3B (high) | 🟢 / 🟡 | Ticket `T-20260913-947070291.<HOST>.txt` |
| `VM-A` | `T-20260906-496406575` | VersicherungsManager timezone | A (app-wide settings like routinika) | 🟢 | Ticket `T-20260906-496406575.<HOST>.txt` |
| `PD-A` | `T-20260913-609930207` | USMC page visibility | A (align declaration to public, status quo) | 🟢 | Ticket `T-20260913-609930207.txt` |

*Note: All discarded alternatives (e.g. BH-A E5=B ocean-heart, MD-A A2 full write keys, VM-A B per-profile zones) remain documented in the Ticket-Master decision briefing.*

---

## 2. Concept

We establish a clean, decoupled multi-host architecture where the model backend is
operated as an independent core module named `agents-heart`. Roles, rights, and budgets
are cleanly maintained in a relational SQLite database, while model routing decisions
occur in two stages: BACH builds the domain-qualified candidate set, and clutch selects
the cost- and capability-optimal model within that set.

On the Mac Studio, 24/7 background services operate safely and reliably using a read-only
deploy key; code updates are pulled automatically, and running 24/7 services are gently
notified rather than violently terminated. Configurations may remain host-specific where
performance demands it, while app-wide settings (such as timezones in VersicherungsManager
following the proven routinika pattern) are deterministically hard-wired. USMC remains
the canonical public memory facade and retains its place on the public website.

---

## 3. Interplay

The five items do not form a serial causal chain; instead, they represent modular, decoupled pillars of daily operational integrity that interlock in parallel across the system:

- **Core Architecture & Model Routing (`BH-A`):** The `agents-heart` module decouples model assignment. When a task arrives, BACH determines the domain-qualified candidate set and clutch selects the cost- and capacity-optimal model.
- **Host Configuration & Deploy Integrity (`CF-A`, `MD-A`):** While consistent reasoning effort applies to the laptop and workstation (`CF-A`; host-dependent models remain transparent), the Mac Studio runs persistent background processes under validated settings. For updates, the Mac pulls code via read-only deploy key (`MD-A`); the GUI server restarts while long-running 24/7 services gently notify the dashboard of update requirements.
- **Domain Persistence & Deadlines (`VM-A`):** Applications such as VersicherungsManager persist deadlines against an app-wide `settings` table following the routinika pattern. Calculations and deadline watchers operate deterministically across all profiles on the same IANA timezone.
- **Public Presentation (`PD-A`):** The nightly site builder validates repository states. USMC is published cleanly under its corrected `public` declaration, triggering zero alerts in the security gates.

---

## 4. Implementation

Because the source dataset does not substantiate a serial chain across these five items in the dependency graph ([decision-path](../decision-path/SKILL.md)), rollout is honestly structured into four independent, parallel workstreams (Approach a: parallel tracks instead of invented causality). Sequential ordering applies only where external deadlines or internal steps exist:

- **Track A (Time-Critical — Deadline 2026-09-14):**
  1. Align USMC metadata to `public` (`PD-A`); discard Draft PR #2. Delays cannot be tolerated due to the nightly builder run, yet this step is technically completely independent of all other tracks.
- **Track B (Host Configuration & Mac Deploy — Parallelizable):**
  1. B1: Codify configuration targets in `.SYNC` (`CF-A`), synchronizing reasoning effort to `high` across both hosts.
  2. B2 (independent of B1): Install read-only deploy key on Mac Studio and set up the pull-and-report automation script (`MD-A`).
- **Track C (Domain Database — Parallelizable):**
  1. Implement the app-wide `settings` table migration in VersicherungsManager following the routinika pattern (`VM-A`), establishing the clean baseline for subsequent publisher development.
- **Track D (Architectural Extraction — Internal Multi-Stage Plan):**
  1. D1: Set up SQLite schema for roles and budgets in `agents-heart` (`BH-A` E1).
  2. D2: Carve out the backend catalog as a Python module (`BH-A` E3) and bind the clutch allocation seam (`BH-A` E2).
  3. D3: Extract and bind the `agents-heart` module (`BH-A` E5, E6).

---

## 5. What This Picture Does Not Cover

- **Task-Claiming Race Condition:** The concurrency bug allowing duplicate task claims
  is being addressed in a dedicated hotfix ticket and is outside this sign-off.
- **Cockpit Frontend:** The monitoring cockpit (`BH-A` E4) is deliberately deferred until
  the backend produces live operational telemetry.
- **Publishing Public Repositories:** Merging and staging code does not automatically
  make private repositories public; final visibility toggles remain reserved for the user.

---

## 6. Sign-Off

You can sign off on this system cluster as a whole or provide natural-language adjustments:

- **Explicit Overall Sign-Off:** "Looks good, implement exactly as proposed." (Only this triggers booking of all items).
- **Example Corrections:**
  - *"No host-specific special handling for the Mac: MD-A needs full write keys (A2) for direct pushing, and CF-A should strictly align all configurations to the workstation (Group 1=A, 2=A)."* (Multi-hit)
  - *"For BH-A E5, name it ocean-heart instead of agents-heart."*
  - *"Postpone VM-A for now; the publisher can wait."*

---

## 7. Back-Transfer

When the concept is approved or amended, the skill translates the feedback into ledger entries:

### Case A: Explicit Overall Sign-Off
When the user explicitly approves the overarching picture as a whole (e.g. *"Looks good, implement exactly as proposed"*):
- All five items (`BH-A: 1A/2A/3A/4B/5A/6A`, `MD-A: A1`, `CF-A: 1C/2B/3B`, `VM-A: A`, `PD-A: A`) are passed as DECIDED to [decision-briefing](../decision-briefing/SKILL.md) Phase 4.
- Phase 4 performs the ledger entries.

Exemplo concluído. O pacote real do Ticket-Master 2026-09-13 foi usado para demonstrar a estrutura e o propósito do skill.

decision-draw — Visão Geral e Aprovação Conjunta para Decisões…

O que é decision-draw — Visão Geral e Aprovação Conjunta para Decisões…?

Perguntar na sua IA favorita

Documentação