git:20261023.33dc8af to git:20261027.856599d

---

name: b3os-bwf

description: b3rys 팀 기본 과제 수행 워크플로우(b3os workflow). 과제를 받으면 PM계획→팀배정→실행+품질방법→검증→보고+카드→학습hook 순으로 끝까지 끌고 가는 단일 진입점(stage router). BWF는 harness가 아니다 — harness/multi-ai/judge panel/적대적리뷰는 BWF 안에서 고르는 '품질방법'이다. 과제·프로젝트·구현·리서치·리뷰·릴리즈 등 실행이 필요한 일이면 이 흐름을 기본으로 쓴다. 얇은 오케스트레이터 — 실제 도구는 하위 스킬(task-loop·harness·report·team-inbox·learning-loop) 참조. 전 런타임(claude/openclaw/hermes). owner=maintainer.

trigger: a confirmed execution/delegation task

---

# b3os-bwf — 기본 과제 수행 워크플로우

BWF(b3os workflow)는 b3rys 팀이 과제를 받아 끝까지 수행하는 기본 흐름이다. harness(한 팀원이 서브에이전트를 병렬로 띄워 일을 나누는 방식)·multi-ai review·judge panel·적대적 리뷰는 이 흐름의 3단계에서 고르는 품질방법이고, BWF 자체가 아니다.

이 스킬은 단계마다 "무엇을 고르나"만 짧게 두고, 실제 실행은 하위 스킬을 가리킨다. 하위 스킬의 내용을 여기에 복사하지 않는다 — 정본은 각 스킬이다.

> 한 줄: 실행 과제는 아래 6단계로 한다. 작은 일은 가볍게, 큰 일은 6단계 전부. 끝나지 않은 일이 조용히 사라지지 않게 한다.

**적용 범위(먼저 읽기)**: BWF는 팀장이 확인한 팀 실행 과제·위임 과제에 적용한다. 단순 답변·가벼운 조회·의견·즉시 끝나는 작은 작업에는 6단계를 강제하지 않는다 — TEAM-OS §4/§10 "작은 일" 기준대로 thread 에 담당·근거만 남긴다. 이 범위가 없으면 작은 질문까지 계획→카드로 끌려간다.

---

## 0. 모드 판단 (시작)

- **턴모드**: 한 번 묻고 한 번 답하는 대화·검토. 범위·완료기준을 새로 정해야 하는 열린 과제면 계획·확인을 먼저 하고, 산출물은 팀장 확인 뒤에 만든다.

- **주행모드(실행 기본)**: 팀장 확인으로 실행이 시작된 과제. 다음 액션·재개 시각·대안(fallback)·멈출 조건(stop_rule)을 남기고, 완료·막힘(blocked)·확인 대기까지 들고 간다.

- **완전자율모드**: 기획부터 검증·보고까지 넓게 위임받은 과제. 범위·권한·멈출 조건을 더 분명히 한다.

- **프로젝트**: 요구가 여러 번 쌓이는 일이면 `b3os-sf` 로 운영한다. 요청 하나하나는 이 6단계로 닫는다.

판정: "범위·형식·완료기준을 내가 새로 정해야 하나?" 그렇다 = 열린 과제(계획 먼저) / 아니다 = 명확한 지시(바로 실행).

---

## 1~6. 단계 (실행 루프)

```

1. PM 계획 목표 / 비목표 / 완료기준(rubric)을 먼저 정한다. 담당(owner)을 정한다.

역할 밖 실행 과제면 PM 으로 전환 — 직접 다 하지 말고 맞는 팀원에게 맡긴다.

★착수(팀장 확인) 즉시 칸반 카드를 등록한다(필수). 누가 물어서가 아니라

PM 착수의 기본 단계다. 알림에 의존하지 않는다.

2. 팀 배정 담당 · 예상 소요 시간 · 검증자. 넘긴 일(handoff)은 받는 쪽의 접수(ack)·

거절·예상 시간 확인까지 추적한다(보냄 ≠ 받음). → b3os-team-inbox(reply.sh·thread.sh)

예상 소요 시간은 아래 "예상 시간 잡는 법"대로 잡는다(PR 하나 = 기본 10분).

3. 실행 + 품질 작업 모양에 맞는 품질방법을 고른다(아래 표). 작업 크기별:

(규모 숫자는 b3os-harness-playbook).

4. 검증 완료기준과 대조하고 증거(테스트·빌드·실측)로 입증한다. "됐다" 단정 금지.

릴리즈 검증 범위는 b3os-verification §1b 출고 모드(dev·hotfix·fix·full)로

정한다. full 은 팀장 승인 뒤.

5. 보고 + 카드 팀장에게 실제로 보이는 보고(만들었다 ≠ 보였다) + 칸반 갱신. 일이 닫힐 때까지

담당이 들고 간다. → b3os-task-loop(카드·가드 필드) · b3os-report(보고서)

6. 학습 hook 교훈·재발 사례를 learning-loop 입력으로 넘긴다(여기서 합치지 않는다).

→ b3os-team-learning-loop

```

## 예상 시간 잡는 법 (AI 팀 기준)

- **과제 하나(같은 목표의 변경 한 건, 보통 PR 하나) = 10분.** 완료기준·검증·리뷰 반영·보고가 다 이 안에 든다.

- **항목·파일·기능 수로 더하지 않는다.** 길게 적으려면 같은 종류 작업의 실측 한 줄(언제·무엇·몇 분)을 붙인다. 없으면 10분.

- **10분에 안 끝날 것 같으면 숫자를 늘리지 말고 따로 끝낼 수 있는 과제로 쪼갠다.** 10분이 지나면 실제 걸린 시간과 남은 일을 말하고 다시 잡는다.

- **대기(빌드·시험 실행·리뷰·승인)는 시간에 넣지 않고 "대기: 무엇"으로 따로 적는다.** 출고 검증 시간은 `b3os-verification` §1b(같은 모드의 직전 실측)를 따른다.

작은 일(즉시 끝남)은 1·4·5만 thread 에 가볍게. 10분 이상이거나 넘긴 일·배포·대기/재개가 생기면 카드를 만들고 6단계 전부를 돈다.

## ★ PM 보고 주기 — 이 일이 일어나면 바로 한 줄

PM 의 핵심은 단계마다 상황을 파악해 팀장에게 보이게 알리는 것이다. "보고해라"만으로는 안 된다 — 아래 일이 일어나면 바로 한 줄을 보낸다. 일이 멈추는 흔한 이유는 "끝나면 보고"로 알고 그냥 기다리는 것이다.

| 이 일이 일어나면 | 바로 할 것 |

|---|---|

| 착수 | 팀장에게 한 줄 — 목표·담당·멈출 조건 |

| **일을 넘긴 직후** | 팀장에게 한 줄 — 누구에게·무엇을·언제까지 |

| **리뷰어·담당이 접수함** | 팀장에게 알림 (보냄 ≠ 완료 — 접수 전에는 "넘김"으로 닫지 않는다) |

| **게이트 단계가 바뀔 때마다** (peer→pm→team_lead_report 등) | 팀장에게 보이는 한 줄 |

| 10~15분 무응답 / 30분 넘게 막힘 | 원인·선택지·추천을 알리고 대안으로 진행 (말없이 계속 기다리지 않는다) |

| 끝 | 결과·바뀐 파일·검증·남은 위험·다음 |

| **배포·전달 직전**(SF 진행 중) | 배포 전 보고를 `b3os-sf` `references/release.md` 「빌드 전달」 형식으로 — 요청 원문별 ✅/⏸ · 버그 · 내부 · 검증 · 꼭 알아야 할 것 · ❓ 결정. 팀장이 형식을 다시 묻지 않게 매번 같은 모양 |

**핵심**: 침묵은 실패로 읽힌다 — 기다리는 중에도 팀장에게는 보여야 한다. 여러 팀원의 답을 모으는 일은 두 번 알린다: 요청을 보낸 직후 한 줄(보냄·모으는 중·예상 시간), 결과가 다 오거나 마감됐을 때 종합 한 번. 답하는 팀원과 모으는 사람 사이는 조용히(접수 인사를 되풀이하지 않는다), 모으는 사람과 팀장 사이는 기다리지 않게 보인다. 이렇게 PM 이 스스로 멈춤을 막는다. 시스템 쪽 안전장치(오래된 제안 점검·과제 진행 가드)는 멈춘 과제를 찾아 담당을 깨우고 팀장에게 알린다.

병렬(harness)이면 계약을 먼저 정한다(라우트·요청/응답·DB 필드·파일 담당 경계를 코드 전에) — 상세는 `b3os-harness-playbook`.

**병렬 충돌 방지**: ① 구현자는 **검증한 것 / 안 한 것**을 밝힌다(못 본 범위를 숨기지 않는다). ② **같은 공유 파일을 동시에 고치지 않는다** — PM 이 순서를 정해 줄 때만. ③ 파일 담당 경계를 깨끗하게(한 에이전트 = 한 영역).

---

## 품질방법 표 (3단계에서 고름 — 정본은 각 스킬)

| 작업 모양 | 품질방법 | 정본 |

|---|---|---|

| 여러 실제 소스를 동시에(audit·여러 PR·마이그레이션·N 후보·여러 출처 리서치) | **harness(병렬)** | `b3os-harness-playbook` |

| 결함이 치명적이거나 되돌리기 어려움 | **적대적 리뷰(반증)** | `b3os-harness-playbook` 7패턴 |

| 중요한 설계·빌드 결정 | **multi-ai review** | `gd-multi-ai-review` (팀장 개인 스킬 — 팀 스킬 폴더에 없음. 없으면 코덱스 등 다른 모델 리뷰로) |

| 후보·판정 비교 | **judge panel** | `b3os-harness-playbook` 7패턴 |

| 릴리즈·공개 전 | **출고 모드별 검증** | `b3os-verification` §1b · TEAM-OS §4 |

판정 두 줄: **"조각마다 서로 다른 실제 소스를 읽나?" 그렇다 → harness.** **"만든 agent 가 자기 작업을 검수하면 안 되나?" 그렇다 → harness(역할 분리 다단계, `b3os-harness-playbook`).** 둘 다 아니면 솔로.

품질방법은 켜는 것보다 맞게 쓰는 것이 중요하다 — 완료기준 없이 judge panel·적대적 리뷰를 돌리면 형식만 돈다(1단계의 완료기준이 먼저).

---

## 런타임별 사용

- **TEAM-OS**: §4 에 BWF 짧은 정의가 반영되어 있다 — "팀장이 확인한 실행·위임은 BWF 로 닫는다: 계획/카드 → 배정/ack → 실행+품질 → 검증 → 보고/종료 → 학습". 이 스킬을 못 읽는 런타임은 TEAM-OS 를 직접 읽어 그 순서를 적용한다(TEAM-OS 도 자동으로 들어오지 않는다). 보고 주기 표와 품질방법 표는 이 스킬에만 있다.

- **claude 런타임**: 이 SKILL.md 와 하위 스킬을 자동으로 찾는다.

- **openclaw·hermes 런타임**: SKILL.md 를 자동으로 읽지 않을 수 있다. BWF 과제면 이 스킬을 직접 읽는다(경로 `<repo>/skills/b3os-bwf/SKILL.md`, 목록 `docs/B3OS_SKILLS.md`).

- 실행 도구는 런타임과 상관없는 스크립트(`scripts/`)라 어디서든 직접 돌릴 수 있다.

---

## 자가 점검 — "BWF 를 제대로 돌렸나"

`references/bwf-rubric.md`. 매 과제 자가 채점, 팀원 학습 평가, 공개 self-test 에 같은 기준을 쓴다:

- [ ] 완료기준을 실행 전에 정했나

- [ ] 작업 모양에 맞는 품질방법을 골랐나

- [ ] 카드로 추적했나(10분 이상인 일·넘긴 일·배포)

- [ ] 증거로 완료를 입증했나("됐다" 단정이 아니라)

- [ ] 팀장에게 보이는 보고 + 일이 닫힐 때까지 갔나

- [ ] 담당·안전 규칙(외부 발송·자기 수정·승인)을 지켰나

self-test: `scripts/bwf-selftest.sh`(샘플 과제 절차 + 단계 산출물 체크리스트).

---

## 경계 (BWF 가 아닌 것)

- BWF 는 **실행 절차**다. 담당 판단·외부 발송/자기 수정 승인·머지 승인 등급·롤백·릴리즈 게이트 같은 **안전·핵심 규칙은 TEAM-OS §4 에 있다(작업 때 직접 읽는다)** — 여기에 다시 적지 않는다(TEAM-OS DO-NOT-COMPACT).

- 품질방법의 정본은 각 스킬(harness 등)이다. BWF 는 고르는 표만 둔다 — 복사하면 내용이 어긋난다.

- 팀 정책을 스스로 다듬는 주간 개선은 **learning-loop**(별도)다. BWF 는 6단계에서 넘기기만 한다.