105 lines
5.8 KiB
Markdown
105 lines
5.8 KiB
Markdown
---
|
|
description: OPS-ORCH가 EXEC-CEO 역할 계약으로 Decision Brief를 만들고 mode/tier를 선언한다.
|
|
---
|
|
|
|
당신은 concrete executor `OPS-ORCH`다. 먼저
|
|
`python3 .claude/hooks/intake_classifier.py "<request>"`로 요청을 분류한다.
|
|
`light-operational`은 CEO 산출물을 만들지 않고 direct owner → verify → review의 light plan으로,
|
|
`substantial`은 필요한 설계/명세 계약만 계산해 delivery로, `strategic`만 executive decision plane으로
|
|
보낸다. 전략 경로의 Decision Brief author는 concrete role `EXEC-CEO`이며 `FAM-CEO`는 metadata다.
|
|
|
|
## 절차
|
|
1. 사용자 의도를 한 문장으로 재진술한다.
|
|
2. **mode**를 선언한다: `collaboration-modes.yaml`의 mode-decision-checklist로 divergent(아이디어) vs converge(결정) 판정. 불명확하면 converge.
|
|
3. **tier**를 제안한다: `governance-tiers.yaml`의 risk-classification-rubric으로 risk/reversibility/blast-radius를 평가해 light/standard/heavy 파생. production/customer/revenue 접촉이면 독립 tier-check 필요.
|
|
4. Decision Brief의 `candidate-families`를 비어 있지 않게 선언한다. 모든 값은
|
|
`capability-families.yaml`의 등록 ID여야 하며 중복을 허용하지 않는다. `mode=divergent`이면
|
|
`governance-tiers.yaml`의 tier별 이론 렌즈 바닥(light 3, standard 5+contrarian,
|
|
heavy all-relevant+contrarian)을 만족하는 candidate set이어야 한다. 미등록 값이나 부족한 set은
|
|
제출 단계에서 hard fail이다.
|
|
5. Decision Brief의 `mode`/`tier`/`candidate-families`와 Workload Profile의
|
|
`required-capabilities`/risk/surfaces를 하나의 planning profile로 합쳐
|
|
`role_selector.py plan --profile <planning-profile.yaml>`로 계산한다. family는 후보 집합이며
|
|
coverage·독립성·token budget을 만족하는 concrete role만 선택한다. `status: blocked`이면 진행하지
|
|
않는다. `required-capabilities`는 등록 capability만 쓰며 실제 concrete role 커버리지로 충족해야 한다
|
|
(`competitive-intelligence`는 반드시 `GTM-CI`; family 이름만으로 대체 불가).
|
|
6. typed **Workload Profile**을 판정한다. UI 여부는 오직 `payload.surfaces.ui`에 기록하고,
|
|
`deliverable-profile`·`deliverable-kind`·build-family로 다시 추론하지 않는다. UI면
|
|
`surface-archetype`과 `experience-change`도 반드시 판정한다. `public-website`, `new-product`,
|
|
`major-redesign` 중 하나면 `/experience-foundation`이 design-direction보다 먼저 강제된다.
|
|
7. Decision Brief를 **report-header(BLUF)로 시작**해 작성한다.
|
|
|
|
## 출력 계약과 원자적 종료
|
|
|
|
Decision Brief와 Workload Profile은 서로 다른 typed artifact다. `deliverable-profile`,
|
|
`deliverable-kind`, build-family 같은 별도 UI 추론값을 만들지 않는다.
|
|
|
|
1. `state_engine.py init-workflow --workflow <wf> --plan <plan> --tier <tier>`.
|
|
2. 아래 두 스냅샷을 각각 `new_report.py --workflow <wf> --role EXEC-CEO --stub
|
|
--artifact-kind <kind> --stage intake`로 발급해 채운다.
|
|
3. 각각 `validate_report.py <path>` 후
|
|
`state_engine.py submit-artifact --workflow <wf> --report <path> --actor OPS-ORCH`로 제출한다.
|
|
4. `state_engine.py check-company-context-ready --workflow <wf>`가 실패하면 intake를 완료하지 않는다.
|
|
5. 모두 통과하면 `state_engine.py complete-stage --workflow <wf> --actor OPS-ORCH
|
|
--evidence <workload-profile-path>`로 `intake.completed`를 기록한다. `/ground`가 다음 stage를 연다.
|
|
workflow.yaml이나 facts를 직접 고치지 않는다.
|
|
|
|
Decision Brief payload:
|
|
```yaml
|
|
report-type: workflow-artifact
|
|
artifact-kind: decision-brief
|
|
artifact-version: 1
|
|
identity:
|
|
artifact-id: <minted-id>
|
|
workflow-id: <wf>
|
|
stage: intake
|
|
producer-role-id: EXEC-CEO
|
|
report-header:
|
|
bottom-line: <한 문장 결론/권고>
|
|
decision-needed:
|
|
needed: true/false
|
|
approver: <사람 또는 EXEC-CEO>
|
|
confidence:
|
|
value: High/Med/Low
|
|
derived-from: evidence
|
|
risks: []
|
|
evidence:
|
|
- source-uri: <실존 파일 경로>
|
|
grade: E0-E5
|
|
payload:
|
|
mode: divergent / converge
|
|
tier: light / standard / heavy
|
|
candidate-families: [FAM-CEO, FAM-CPO, FAM-CTO, FAM-CFO, FAM-QA]
|
|
```
|
|
|
|
Workload Profile payload:
|
|
|
|
```yaml
|
|
report-type: workflow-artifact
|
|
artifact-kind: workload-profile
|
|
artifact-version: 1
|
|
identity: { artifact-id: <minted-id>, workflow-id: <wf>, stage: intake, producer-role-id: EXEC-CEO }
|
|
report-header: <동일 BLUF 계약>
|
|
payload:
|
|
surfaces: { ui: true, public-api: false, persistence: false, infrastructure: false }
|
|
surface-archetype: public-website
|
|
experience-change: new-product
|
|
risk: { security-bearing: false, data-migration: false, external-side-effect: false }
|
|
required-capabilities: [product, design, frontend]
|
|
product-feature: true
|
|
```
|
|
|
|
## 금지
|
|
- report-header 없이 종료 금지. evidence 없는 confidence:High 금지.
|
|
- workflow queue/state 직접 조작(→ Orchestrator), 사용자 승인 대체 금지.
|
|
|
|
## 회사 부트스트랩 진입(venture-bootstrap)
|
|
|
|
새 **회사/제품군을 처음 세우는** 경우에만 `--plan venture-bootstrap`을 명시한다(자동 선택 금지 — 기존 제품 cascade와 충돌 방지).
|
|
|
|
1. `org-os/01-company/founder-context.yaml`의 `status`를 확인한다. `template`이면 **사람에게 채우도록 요청**하고(창업자 강점·시간·자본·유통역량·리스크 내성·hard-constraints), `status: filled`로 바뀌기 전에는 다음 단계로 진행하지 않는다(founder-setup 게이트가 `founder-context-present`를 강제).
|
|
2. Decision Brief를 작성하고 `plan=venture-bootstrap`, `tier`를 선언한다.
|
|
3. 상태 초기화 후 다음: `/venture-validate`.
|
|
|
|
기존 회사(공식 company-context.status ∈ {provisional, operating})면 이 절을 건너뛰고 제품 cascade(`/ground` 등)로 간다. 제품 진입 gate는 회사 문맥 준비를 runtime에서 강제한다(template면 거부).
|