결정-드로우(decision-draw) — 번들 결정을 위한 큰 그림과 전체 승인
다섯 개 또는 열 개의 결정이 대기 중일 때, 개별 옵션의 세부 사항에 빠져 시스템 전체를 놓치기 쉽습니다. 결정-드로우는 대안을 설명하지 않습니다. 작동하는 전체를 그려냅니다: 모든 권장 사항이 적용되면 시스템은 어떻게 협력할까요? 사용자는 그림 전체를 승인하거나, 대상 수정 피드백을 제공합니다.
사용 시기
- 여러 상호 의존적인 결정(decision-briefing 또는 결정 브리핑 문서에서 비롯된)을 지루한 개별 질문 체크리스트로 처리해서는 안 됩니다.
- 사용자가 승인하기 전에 구성 요소가 실제 일상 업무에서 어떻게 상호 작용하는지 보고자 합니다.
- 의존성 그래프(decision-path)를 통해 식별된 밀접하게 결합된 결정 클러스터를 기능 단위로 함께 승인할 수 있습니다.
- 트리거 단어:
/decision-draw, "모든 것에 동의한다면 전체는 어떻게 보이나요?", "큰 그림을 그려줘", "전체 결정 개념", "decision draw", "시스템들이 나중에 어떻게 함께 작동하나요?", "전체 승인 그림". - 사용하지 말아야 할 경우:
- 사용자가 항목별로 별개의 옵션을 평가하고 문자(A/B/C)로 선택하려 할 때 — 이는 decision-briefing이 처리합니다.
- 터미널에서 순수 인과 관계 및 병목 현상 분석을 위한 경우 — 이는 decision-path가 처리합니다.
- 단일 이슈 또는 밀접하게 그룹화된 질문에 대한 5부분 개별 블록(컨텍스트, 옵션별 장단점, 권장 사항)에서 개별 옵션 평가를 위한 경우 — 이는 decision-shot이 처리합니다.
- 단일 공개 정책 질문을 체계적으로 평가하기 위한 경우 — 이는 decide가 처리합니다.
결정군 내 경계
| 기술 | UX 및 초점 | 옵션에 대한 입장 | 승인 방식 |
|---|---|---|---|
decision-briefing | 개별 항목으로 분해 | 모든 옵션 A/B/C/D 표시 | 문자 코드 (1A 2C 3B) |
decision-path | 인과 관계 구조화 | 그래프에서 옵션 평가 | 터미널 진단 (ASCII) |
decision-draw | 응집력 있는 목표 그림 (상호 의존적 결정 번들) | 권장 변형만 설명 (대안은 연결됨) | 전체적 승인 또는 수정 문장 |
decision-shot | 구조화된 개별 블록 (단일 이슈 또는 긴밀한 그룹용) | 2-4개의 장단점 요점이 있는 옵션 표시 | 경영진 결정 / 개별 검토 |
decide | 단일 이슈 도출 | 평가 매트릭스 (기준) | 분석적 권장 사항 |
핵심 규칙:
decision-draw는 권장 변형만을 설명합니다. 폐기된 대안이 사라진 것은 아닙니다. 이들은 decision-briefing, decision-shot 또는 연결된 티켓에 문서화되어 있으며, 헤더 테이블에서 참조됩니다. 이 연결 없이 그림을 그리면 사용자의 선택권을 단순화하는 대신 빼앗는 것입니다.
필수 구조 (7개 부분)
완전한 decision-draw는 다음 7개 부분 레이아웃을 엄격히 따릅니다:
1. 번들 및 범위
번들에 포함된 모든 항목의 표 형식 요약:
- 약어 / ID (예:
BH-A,MD-A,CF-A) - 티켓 참조
- 항목의 간략한 제목
- 가정된 권장 사항 (이 전체 그림의 전제)
decision-avatar신뢰도 (🟢 문서화됨, 🟡 트레이드오프, 🔴 에스컬레이션 필요)- 전체 분석 / 대안에 대한 링크
2. 개념
응집력 있는 산문으로 된 목표 상태:
- 모든 권장 사항이 정확히 계획된 대로 실행될 때 나타나는 시스템 환경 또는 워크플로는 무엇인가?
- 병렬 옵션 비교나 가정법적 회피("다음과 같이 할 수도 있다")는 없습니다.
- 명확하고 자신 있는 직설법: 이것이 시스템이 목표 상태에서 작동하는 방식입니다.
3. 상호 작용
기술의 기능적 핵심:
- 결정된 구성 요소는 구현 후 실제로 어떻게 서로 맞물리는가?
- 구성 요소의 정적 목록이 아닌 구체적인 종단 간 운영 흐름(예: "티켓 도착 → 에이전트 시작 → 백엔드 할당 → 호스트에 배포")을 따라 구성됩니다.
- 데이터 흐름, 인터페이스 및 운영 책임을 명확히 합니다.
4. 구현
롤아웃 단계의 구체적인 순서:
- 실제로 단계별로 어떤 일이 발생하는가?
- decision-path에서 실행 순서와 의존성 로직을 직접 상속받습니다.
- 독립적인 작업 스트림은 병렬 트랙으로 정직하게 표현됩니다 (인위적인 인과 관계 체인을 만들지 마십시오; 번들은 여러 병렬 트랙으로 구성될 수 있습니다). 순차적 순서는 입증된 의존성이나 마감일이 있는 경우에만 주장됩니다.
- 게이트, 마이그레이션 스크립트 및 유효성 검사를 강조합니다.
5. 이 그림이 다루지 않는 것
잘못된 완전성에 대한 경계 방어:
- 어떤 보조 질문, 해결되지 않은 문제 또는 🔴 신뢰도가 의도적으로 제외되었는가?
- 이웃 시스템과의 경계선은 어디인가?
- 한계를 숨기는 그림은 잘못된 안전감을 생성합니다.
6. 승인
사용자 상호 작용:
- 사용자는 그림 전체를 검토합니다.
- 응답 옵션 1: 명시적 전체 승인 ("좋아 보임", "승인", "제안된 모든 것을 구현"). 이 경우에만 모든 번들 항목이 결정된 것으로 기록됩니다.
- 응답 옵션 2: 자연어로 대상 수정 ("BH-A는 더 작은 변형 선호", "MD-A에 자동 재시작 없음", "VM-A는 그대로 유지"). 개별 결정으로 분해를 트리거합니다. 수정되지 않은 모든 항목은 열린 상태로 유지됩니다.
7. 역전송
사용자 피드백을 개별 원장 항목으로 체계적으로 변환:
- 자동 공동 기록 없음: 변경되지 않은 항목은 명시적 전체 승인 시에만 기록됩니다. 부분 수정은 전체 승인이 아닙니다!
- 수정 시 격리: 사용자가 수정을 제출하면 개별 결정으로 분해됩니다. 번들의 다른 모든 항목은 사용자가 조정된 그림을 전체로 수락하거나 나머지 항목을 개별적으로 확인할 때까지 엄격히 열린 상태로 유지됩니다(소스 티켓/원장에서).
- 필수 역전송 테이블: 모든 부분 피드백은 4개 열로 구성된 구조화된 평가 테이블을 생성합니다:
- 원래 수정: 사용자 진술을 그대로.
- 영향받은 키: 어떤 번들 ID가 변경되었는지 (하나의 진술이 여러 결정에 닿는 경우 다중 적중 포함).
- 도미노 상태: decision-path에서 어떤 종속 노드 또는 다운스트림 가정이 무너지거나 재평가가 필요한지.
- 열린 모호성: 수정이 기록 전에 명확히 해야 하는 여러 해석을 허용하는 위치.
- 다중 적중 처리: 단일 사용자 문장이 여러 결정을 동시에 변경할 수 있습니다. 역전송은 이 결합을 풀고 영향을 받는 모든 키를 함께 캡처해야 합니다.
- 페이즈 4를 통한 독점 쓰기 경로:
decision-draw는 티켓 또는 레지스터에 대한 기본 쓰기 경로가 없습니다. 원장 업데이트는 decision-briefing 페이즈 4의 표준화된 프로토콜(DECIDED-AND-DONE.md또는TO-DECIDE-USER.txt에 로깅 및 영속화)을 통해 독점적으로 발생합니다.
예시 (파일럿 데이터셋: Ticket-Master 2026-09-13 — BACH 및 시스템 클러스터)
2026-09-13일자 Ticket-Master 결정 브리핑의 실제 번들: BH-A, MD-A, CF-A, VM-A, PD-A.
# 결정-드로우: BACH 코어 클러스터 및 운영 무결성
## 1. 번들 및 범위
| 키 | 티켓 / 출처 | 주제 | 가정된 권장 사항 | 신뢰도 | 대안 및 세부 사항 |
|---|---|---|---|---|---|
| `BH-A` | `T-20260913-896336887` | 모델 백엔드 = Heart | 1A / 2A / 3A / 4B / 5A / 6A | 🟢 | `docs/MODELL-BACKEND-KONZEPT_2026-09-13.md` |
| `MD-A` | `T-20260913-799464688` | Mac 배포 및 재시작 | A1 + 스크립트 (24/7 보고 전용) | 🟢 | 티켓 `T-20260913-799464688.txt` |
| `CF-A` | `T-20260913-947070291` | 호스트 간 구성 대상 | 1C (정당화됨) / 2B (호스트 종속) / 3B (높음) | 🟢 / 🟡 | 티켓 `T-20260913-947070291.<HOST>.txt` |
| `VM-A` | `T-20260906-496406575` | VersicherungsManager 시간대 | A (routinika와 같은 앱 전체 설정) | 🟢 | 티켓 `T-20260906-496406575.<HOST>.txt` |
| `PD-A` | `T-20260913-609930207` | USMC 페이지 가시성 | A (선언을 public으로 정렬, 현상 유지) | 🟢 | 티켓 `T-20260913-609930207.txt` |
*참고: 폐기된 모든 대안(예: BH-A E5=B ocean-heart, MD-A A2 전체 쓰기 키, VM-A B 프로필별 영역)은 Ticket-Master 결정 브리핑에 문서화되어 있습니다.*
---
## 2. 개념
우리는 모델 백엔드가 `agents-heart`라는 독립적인 코어 모듈로 운영되는 깔끔하고 분리된 멀티 호스트 아키텍처를 구축합니다. 역할, 권한 및 예산은 관계형 SQLite 데이터베이스에서 깔끔하게 유지되는 반면, 모델 라우팅 결정은 두 단계로 발생합니다: BACH는 도메인에 적합한 후보 집합을 구축하고, clutch는 해당 집합 내에서 비용 및 기능 최적 모델을 선택합니다.
Mac Studio에서는 읽기 전용 배포 키를 사용하여 24/7 백그라운드 서비스가 안전하고 안정적으로 작동합니다. 코드 업데이트는 자동으로 가져오고, 실행 중인 24/7 서비스는 강제 종료되지 않고 부드럽게 통보됩니다. 구성은 성능이 요구되는 경우 호스트별로 유지될 수 있으며, 앱 전체 설정(예: 입증된 routinika 패턴을 따르는 VersicherungsManager의 시간대)은 결정론적으로 고정됩니다. USMC는 표준 공개 메모리 퍼사드로 남아 공개 웹사이트에서 그 위치를 유지합니다.
---
## 3. 상호 작용
다섯 항목은 직렬 인과 관계 체인을 형성하지 않습니다. 대신, 이들은 시스템 전반에 걸쳐 병렬로 맞물리는 일상 운영 무결성의 모듈식 분리된 기둥을 나타냅니다:
- **코어 아키텍처 및 모델 라우팅 (`BH-A`):** `agents-heart` 모듈은 모델 할당을 분리합니다. 작업이 도착하면 BACH는 도메인에 적합한 후보 집합을 결정하고 clutch는 비용 및 용량 최적 모델을 선택합니다.
- **호스트 구성 및 배포 무결성 (`CF-A`, `MD-A`):** 일관된 추론 노력이 랩톱과 워크스테이션에 적용되는 반면(`CF-A`; 호스트 종속 모델은 투명하게 유지됨), Mac Studio는 검증된 설정에서 지속적인 백그라운드 프로세스를 실행합니다. 업데이트를 위해 Mac은 읽기 전용 배포 키를 통해 코드를 가져옵니다(`MD-A`). GUI 서버는 재시작되는 반면, 장기 실행 24/7 서비스는 업데이트 요구 사항을 대시보드에 부드럽게 통보합니다.
- **도메인 영속성 및 마감일 (`VM-A`):** VersicherungsManager와 같은 애플리케이션은 routinika 패턴을 따라 앱 전체 `settings` 테이블에 대해 마감일을 유지합니다. 계산 및 마감일 감시자는 동일한 IANA 시간대에서 모든 프로필에 걸쳐 결정론적으로 작동합니다.
- **공개 표시 (`PD-A`):** 야간 사이트 빌더는 저장소 상태를 검증합니다. USMC는 수정된 `public` 선언 아래 깔끔하게 게시되어 보안 게이트에서 경고를 트리거하지 않습니다.
---
## 4. 구현
소스 데이터셋이 의존성 그래프([decision-path](../decision-path/SKILL.md))에서 이 다섯 항목에 걸친 직렬 체인을 입증하지 않기 때문에, 롤아웃은 정직하게 4개의 독립적인 병렬 작업 스트림으로 구조화됩니다 (접근법 a: 인위적 인과 관계 대신 병렬 트랙). 순차적 순서는 외부 마감일이나 내부 단계가 존재하는 경우에만 적용됩니다:
- **트랙 A (시간 중요 — 마감일 2026-09-14):**
1. USMC 메타데이터를 `public`으로 정렬 (`PD-A`); 초안 PR #2 폐기. 야간 빌더 실행으로 인해 지연이 허용되지 않지만, 이 단계는 기술적으로 다른 모든 트랙과 완전히 독립적입니다.
- **트랙 B (호스트 구성 및 Mac 배포 — 병렬화 가능):**
1. B1: `.SYNC`에서 구성 대상 코딩 (`CF-A`), 두 호스트 모두에서 추론 노력을 `high`로 동기화.
2. B2 (B1과 독립적): Mac Studio에 읽기 전용 배포 키 설치 및 풀 및 보고 자동화 스크립트 설정 (`MD-A`).
- **트랙 C (도메인 데이터베이스 — 병렬화 가능):**
1. routinika 패턴을 따라 VersicherungsManager에 앱 전체 `settings` 테이블 마이그레이션 구현 (`VM-A`), 후속 게시자 개발을 위한 깔끔한 기준선 확립.
- **트랙 D (아키텍처 추출 — 내부 다단계 계획):**
1. D1: `agents-heart`에서 역할 및 예산을 위한 SQLite 스키마 설정 (`BH-A` E1).
2. D2: 백엔드 카탈로그를 Python 모듈로 분리 (`BH-A` E3) 및 clutch 할당 지점 바인딩 (`BH-A` E2).
3. D3: `agents-heart` 모듈 추출 및 바인딩 (`BH-A` E5, E6).
---
## 5. 이 그림이 다루지 않는 것
- **작업 클레임 경쟁 조건:** 중복 작업 클레임을 허용하는 동시성 버그는 전용 핫픽스 티켓에서 처리 중이며 이 승인 범위를 벗어납니다.
- **조종석 프론트엔드:** 모니터링 조종석(`BH-A` E4)은 백엔드가 실시간 운영 원격 측정을 생성할 때까지 의도적으로 연기됩니다.
- **공개 저장소 게시:** 코드 병합 및 스테이징이 자동으로 비공개 저장소를 공개로 만들지는 않습니다. 최종 가시성 토글은 사용자에게 유보됩니다.
---
## 6. 승인
이 시스템 클러스터를 전체적으로 승인하거나 자연어 조정을 제공할 수 있습니다:
- **명시적 전체 승인:** "좋아 보입니다. 제안된 대로 정확히 구현하세요." (이 경우에만 모든 항목이 기록됩니다).
- **수정 예시:**
- *"Mac에 대한 호스트별 특별 처리는 없음: MD-A에는 직접 푸시를 위한 전체 쓰기 키(A2)가 필요하고, CF-A는 모든 구성을 워크스테이션에 엄격히 정렬해야 합니다(그룹 1=A, 2=A)."* (다중 적중)
- *"BH-A E5의 경우, 이름을 agents-heart 대신 ocean-heart로 지정하세요."*
- *"VM-A는 당분간 연기하세요. 게시자는 기다릴 수 있습니다."*
---
## 7. 역전송
개념이 승인되거나 수정되면, 기술은 피드백을 원장 항목으로 변환합니다:
### 사례 A: 명시적 전체 승인
사용자가 전체 그림을 명시적으로 승인하는 경우 (예: *"좋아 보입니다. 제안된 대로 정확히 구현하세요"*):
- 다섯 항목 모두 (`BH-A: 1A/2A/3A/4B/5A/6A`, `MD-A: A1`, `CF-A: 1C/2B/3B`, `VM-A: A`, `PD-A: A`)가 DECIDED로 [decision-briefing](../decision-briefing/SKILL.md) 페이즈 4에 전달됩니다.
- 페이즈 4는 원장 엔트리를 수행합니다.