b3os-bwf · diff
git:20260924.839a49b to git:20261022.85c6253
73 added, 63 removed. Audit A to A.
---
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 — 기본 과제 수행 워크플로우 (stage router)
+ # b3os-bwf — 기본 과제 수행 워크플로우
- **BWF(b3os workflow)는 harness가 아니다.** b3rys 팀이 과제를 받아 끝까지 수행하는 **기본 흐름**이다. harness·multi-ai review·judge panel·적대적 리뷰는 이 흐름의 한 단계에서 고르는 **품질방법**일 뿐이다. (이 구분을 먼저 박는다 — 과거 "BWF=harness" 오해 방지.)
+ BWF(b3os workflow)는 b3rys 팀이 과제를 받아 끝까지 수행하는 기본 흐름이다. harness(한 팀원이 서브에이전트를 병렬로 띄워 일을 나누는 방식)·multi-ai review·judge panel·적대적 리뷰는 이 흐름의 3단계에서 고르는 품질방법이고, BWF 자체가 아니다.
- 이 스킬은 **얇은 라우터**다. 각 단계는 "무엇을·어떻게 고르나"만 짧게 두고, 실제 실행은 하위 스킬을 참조한다(복붙 금지 — 정본은 각 스킬).
+ 이 스킬은 단계마다 "무엇을 고르나"만 짧게 두고, 실제 실행은 하위 스킬을 가리킨다. 하위 스킬의 내용을 여기에 복사하지 않는다 — 정본은 각 스킬이다.
- > 한 줄: **실행 과제는 이 6단계로. 작은 일은 가볍게, 큰 일은 풀 루프. 끝나지 않은 일이 조용히 사라지지 않게.**
+ > 한 줄: 실행 과제는 아래 6단계로 한다. 작은 일은 가볍게, 큰 일은 6단계 전부. 끝나지 않은 일이 조용히 사라지지 않게 한다.
- **적용 범위(scope guard — 먼저 읽기)**: BWF는 **팀장 컨펌을 받은 팀 실행 과제·위임 과제**에 적용한다. 단순 답변·가벼운 조회·의견·즉시 끝나는 국소 작업에는 풀 절차를 강제하지 않는다 — TEAM-OS §4/§10 "작은 일" 기준대로 thread에 owner·근거만 남기면 충분하다. (이걸 안 박으면 openclaw 런타임에서 작은 질문까지 PM계획→카드로 끌려간다.)
+ **적용 범위(먼저 읽기)**: BWF는 팀장이 확인한 팀 실행 과제·위임 과제에 적용한다. 단순 답변·가벼운 조회·의견·즉시 끝나는 작은 작업에는 6단계를 강제하지 않는다 — TEAM-OS §4/§10 "작은 일" 기준대로 thread 에 담당·근거만 남긴다. 이 범위가 없으면 작은 질문까지 계획→카드로 끌려간다.
---
## 0. 모드 판단 (시작)
- - **턴모드**: 한 번 묻고 한 번 답하는 대화·검토. (열린 과제 = 범위·완료기준을 새로 정해야 함 → 계획·확인 먼저, 산출물 생성은 컨펌 후.)
- - **주행모드(실행 기본)**: the team lead 컨펌으로 실행 시작된 과제. `다음 액션·재개 시각·fallback·stop_rule` 남기고 완료/blocked/컨펌대기까지 들고 감.
- - **완전자율모드**: 기획~검증~보고까지 넓게 위임. 범위·권한·stop_rule 더 명확히.
+ - **턴모드**: 한 번 묻고 한 번 답하는 대화·검토. 범위·완료기준을 새로 정해야 하는 열린 과제면 계획·확인을 먼저 하고, 산출물은 팀장 확인 뒤에 만든다.
+ - **주행모드(실행 기본)**: 팀장 확인으로 실행이 시작된 과제. 다음 액션·재개 시각·대안(fallback)·멈출 조건(stop_rule)을 남기고, 완료·막힘(blocked)·확인 대기까지 들고 간다.
+ - **완전자율모드**: 기획부터 검증·보고까지 넓게 위임받은 과제. 범위·권한·멈출 조건을 더 분명히 한다.
+ - **프로젝트**: 요구가 여러 번 쌓이는 일이면 `b3os-sf` 로 운영한다. 요청 하나하나는 이 6단계로 닫는다.
- 판정: "내가 범위·형식·완료기준을 새로 발명해야 하나?" YES=열린 과제(계획 먼저) / NO=명확한 지시(바로).
+ 판정: "범위·형식·완료기준을 내가 새로 정해야 하나?" 그렇다 = 열린 과제(계획 먼저) / 아니다 = 명확한 지시(바로 실행).
---
- ## 1~6. 스테이지 (실행 루프)
+ ## 1~6. 단계 (실행 루프)
```
- 1. PM 계획 목표 / 비목표 / 완료기준(rubric)을 먼저. owner 결정.
- 역할 밖 실행과제면 PM 전환 — 직접 다 하지 말고 적임자에 위임.
- ★착수(the team lead 컨펌) 즉시 칸반 카드 등록(필수·자동) — 누가 물어서가
- 아니라 PM 킥오프 기본 스텝. reminder 의존 금지.
- 2. 팀 배정 owner · ETA · 검증자. handoff = 받는쪽 ack/거절/ETA 확인까지 추적
- (보냄 ≠ 수신확인). → b3os-team-inbox(reply.sh·thread.sh)
- 3. 실행 + 품질 작업모양 → 품질방법 선택(아래 표). 작업크기 게이팅:
- 턴=솔로 / 주행=limited harness / 완전자율=full harness.
- 4. 검증 완료기준(rubric) 대조 + 검증증거(테스트·빌드·실측). "됐다" 단정 금지.
- 중요 릴리즈/공개 = 팀원리뷰 + 하네스 다차원 (TEAM-OS §4, 무조건).
- 5. 보고 + 카드 the team lead에게 실제 보이는 보고(생성 ≠ 보임) + 칸반 갱신. closure까지 owner가.
- → b3os-task-loop(카드·guard 필드) · b3os-report(보고서)
- 6. 학습 hook 교훈·재발사례 → learning-loop 입력으로. (합치지 않고 넘김.)
+ 1. PM 계획 목표 / 비목표 / 완료기준(rubric)을 먼저 정한다. 담당(owner)을 정한다.
+ 역할 밖 실행 과제면 PM 으로 전환 — 직접 다 하지 말고 맞는 팀원에게 맡긴다.
+ ★착수(팀장 확인) 즉시 칸반 카드를 등록한다(필수). 누가 물어서가 아니라
+ PM 착수의 기본 단계다. 알림에 의존하지 않는다.
+ 2. 팀 배정 담당 · 예상 소요 시간 · 검증자. 넘긴 일(handoff)은 받는 쪽의 접수(ack)·
+ 거절·예상 시간 확인까지 추적한다(보냄 ≠ 받음). → b3os-team-inbox(reply.sh·thread.sh)
+ 예상 소요 시간은 아래 "예상 시간 잡는 법"대로 잡는다(PR 하나 = 기본 10분).
+ 3. 실행 + 품질 작업 모양에 맞는 품질방법을 고른다(아래 표). 작업 크기별:
+ 턴=솔로 / 주행=limited harness / 완전자율=full harness
+ (규모 숫자는 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
```
- 작은 일(즉시 끝남)은 1·4·5만 thread에 가볍게. 10분+·handoff·배포·대기/재개가 생기면 카드 + 풀 루프.
+ ## 예상 시간 잡는 법 (AI 팀 기준)
- ## ★ PM 루프 — status cadence (트리거→액션, 외워서 따라 한다)
+ - **PR 하나·산출물 하나 = 작업 하나 = 기본 10분.** 코드·문서·리서치·운영 모두 같다.
+ - **완료기준·리뷰 요구·할 일 항목의 개수만큼 10분을 더하지 않는다.** 항목은 그 작업 안의 체크리스트다. 예: "스크립트에 옵션 하나 + 완료기준 5개" = 10분, 60분이 아니다.
+ - **작업 시간과 기다리는 시간은 따로 적는다.** 기다리는 시간 = 빌드·전체 시험 실행, 리뷰·승인 응답, 사람 확인. 형식: "작업 10분 + 전체 시험 N분 + 코덱스 리뷰 대기".
+ - **10분은 기본 추정이다. 10분을 넘게 잡으려면 근거를 한 줄로 댄다**: 같은 종류 작업의 실측 기록(`b3os-sf` 작업시간 산출방법), 서로 다른 PR 여러 개인지(→ 각 10분, 병렬이면 전체도 10분대), 그 작업에만 있는 추가 작업. 기다림을 작업으로 센 것은 근거가 아니다. 근거가 없으면 10분으로 다시 잡고, 팀원 숫자를 그대로 팀장에게 옮기지 않는다. 출고 검증 시간은 `b3os-verification` §1b(같은 모드의 직전 실측)를 따른다.
+ - 사람 개발자 기준(몇 시간·며칠) 추정은 쓰지 않는다.
- PM의 핵심 = **단계마다 상황파악 → the team lead에게 보이는 보고**. "보고해라"(추상)로는 안 됨 — 아래 트리거가 오면 *반사적으로* 1줄 쏜다. (stall의 흔한 이유 = "완료될 때 보고"로 오해해 그냥 기다림.)
+ 작은 일(즉시 끝남)은 1·4·5만 thread 에 가볍게. 10분 이상이거나 넘긴 일·배포·대기/재개가 생기면 카드를 만들고 6단계 전부를 돈다.
- | 트리거(이게 일어나면) | 액션(즉시) |
+ ## ★ PM 보고 주기 — 이 일이 일어나면 바로 한 줄
+
+ PM 의 핵심은 단계마다 상황을 파악해 팀장에게 보이게 알리는 것이다. "보고해라"만으로는 안 된다 — 아래 일이 일어나면 바로 한 줄을 보낸다. 일이 멈추는 흔한 이유는 "끝나면 보고"로 알고 그냥 기다리는 것이다.
+
+ | 이 일이 일어나면 | 바로 할 것 |
|---|---|
- | 착수 | the team lead에 1줄 — 목표·owner·stop_rule |
- | **핸드오프 보낸 직후** | the team lead에 **ack+ETA 1줄** (누구에게·무엇·언제까지) |
- | **리뷰어/담당자 ack 받음** | the team lead에 보고 (**보냄 ≠ done** — ack까지 추적, ack 전 "넘김"으로 안 닫음) |
- | **게이트 전이마다** (peer→pm→team_lead_report 등) | **the team lead에게 보이는 1줄** |
- | 10~15분 무응답 / 30분+ blocked | 원인·옵션·추천 + fallback으로 진행 (**무한 침묵대기 금지**) |
- | 최종 | 결과·변경파일·검증·잔여리스크·다음 |
+ | 착수 | 팀장에게 한 줄 — 목표·담당·멈출 조건 |
+ | **일을 넘긴 직후** | 팀장에게 한 줄 — 누구에게·무엇을·언제까지 |
+ | **리뷰어·담당이 접수함** | 팀장에게 알림 (보냄 ≠ 완료 — 접수 전에는 "넘김"으로 닫지 않는다) |
+ | **게이트 단계가 바뀔 때마다** (peer→pm→team_lead_report 등) | 팀장에게 보이는 한 줄 |
+ | 10~15분 무응답 / 30분 넘게 막힘 | 원인·선택지·추천을 알리고 대안으로 진행 (말없이 계속 기다리지 않는다) |
+ | 끝 | 결과·바뀐 파일·검증·남은 위험·다음 |
- **핵심**: 침묵은 실패로 읽힌다 — 대기 중에도 the team lead에겐 보여야. 수집형은 **2박자**(팬아웃 직후 1줄[받음+모으는중+ETA] + 결과/timeout 시 종합 1회). 단 응답자↔수집자 사이는 조용히 모으고(ack 도배 X), 수집자↔the team lead 사이는 안 기다리게(visible). = PM이 "단계마다 상황파악→the team lead 보고"의 conti guard를 *스스로* 세우는 것. (시스템 백스톱 = stale-proposal worker·task continuation guard가 멈춤 감지→owner wake→the team lead에게 보이는 에스컬레이션.)
+ **핵심**: 침묵은 실패로 읽힌다 — 기다리는 중에도 팀장에게는 보여야 한다. 여러 팀원의 답을 모으는 일은 두 번 알린다: 요청을 보낸 직후 한 줄(보냄·모으는 중·예상 시간), 결과가 다 오거나 마감됐을 때 종합 한 번. 답하는 팀원과 모으는 사람 사이는 조용히(접수 인사를 되풀이하지 않는다), 모으는 사람과 팀장 사이는 기다리지 않게 보인다. 이렇게 PM 이 스스로 멈춤을 막는다. 시스템 쪽 안전장치(오래된 제안 점검·과제 진행 가드)는 멈춘 과제를 찾아 담당을 깨우고 팀장에게 알린다.
- 병렬(harness)이면 **contract-first**(라우트·요청/응답·DB필드·파일 owner 경계를 코드 전에) — 상세는 b3os-harness-playbook.
+ 병렬(harness)이면 계약을 먼저 정한다(라우트·요청/응답·DB 필드·파일 담당 경계를 코드 전에) — 상세는 `b3os-harness-playbook`.
- **병렬 충돌 방지(project-loop 흡수)**: ①구현자는 **검증한 것 / 안 한 것**을 명시한다(unverified scope 숨기지 않기). ②**같은 공유파일 동시 편집 금지** — PM이 순서를 명시 지정할 때만. ③파일 owner 경계 깨끗이(한 에이전트=한 영역).
+ **병렬 충돌 방지**: ① 구현자는 **검증한 것 / 안 한 것**을 밝힌다(못 본 범위를 숨기지 않는다). ② **같은 공유 파일을 동시에 고치지 않는다** — PM 이 순서를 정해 줄 때만. ③ 파일 담당 경계를 깨끗하게(한 에이전트 = 한 영역).
---
- ## 품질방법 카탈로그 (3단계에서 고름 — 라우팅만, 정본은 각 스킬)
+ ## 품질방법 표 (3단계에서 고름 — 정본은 각 스킬)
| 작업 모양 | 품질방법 | 정본 |
|---|---|---|
- | 좁고 순차·단일맥락·개념합성 | **솔로** | — |
- | 여러 실제 소스 동시(audit·다PR·마이그레이션·N후보·멀티소스 리서치) | **harness(병렬)** | `b3os-harness-playbook` |
- | 결함이 치명적·되돌리기 어려움 | **적대적 리뷰(반증)** | `b3os-harness-playbook` 7패턴 |
- | 중요 설계·빌드 결정 | **multi-ai review** | `gd-multi-ai-review` |
+ | 좁고 순차·한 맥락·개념 합성 | **솔로** | — |
+ | 여러 실제 소스를 동시에(audit·여러 PR·마이그레이션·N 후보·여러 출처 리서치) | **harness(병렬)** | `b3os-harness-playbook` |
+ | 결함이 치명적이거나 되돌리기 어려움 | **적대적 리뷰(반증)** | `b3os-harness-playbook` 7패턴 |
+ | 중요한 설계·빌드 결정 | **multi-ai review** | `gd-multi-ai-review` |
| 후보·판정 비교 | **judge panel** | `b3os-harness-playbook` 7패턴 |
- | 릴리즈/공개 전 | **팀원리뷰 + 하네스 다차원** | TEAM-OS §4 + `b3os-harness-playbook` |
+ | 릴리즈·공개 전 | **출고 모드별 검증** | `b3os-verification` §1b · TEAM-OS §4 |
- 판정 한 줄: **"각 조각이 서로 다른 실제 소스를 읽나?" YES→harness, NO→솔로.**
- 품질방법은 '켜기'보다 '맞게 쓰기'가 중요 — rubric/완료기준 없이 judge panel·적대적리뷰 돌리면 형식만 돈다(4단계의 완료기준이 선행).
+ 판정 한 줄: **"조각마다 서로 다른 실제 소스를 읽나?" 그렇다 → harness, 아니다 → 솔로.**
+ 품질방법은 켜는 것보다 맞게 쓰는 것이 중요하다 — 완료기준 없이 judge panel·적대적 리뷰를 돌리면 형식만 돈다(1단계의 완료기준이 먼저).
---
- ## 런타임별 사용 (claude만 자동 ≠ 전원)
-
- - **claude 런타임 팀원**: 이 SKILL.md 자동 발견. 하위 스킬도 자동.
- - **openclaw·hermes 런타임 팀원**: SKILL.md 자동로드가 없을 수 있다 → BWF 과제면 이 스킬을 **명시 로드**한다(경로 = `<repo>/skills/b3os-bwf/SKILL.md`). 카탈로그는 `docs/B3OS_SKILLS.md`에서 발견. 핵심 단계는 위 6줄 표를 ready-run으로 바로 따라 실행.
- - **TEAM-OS 핵심룰**에 BWF thin 정의(스테이지 + "BWF≠harness" + 품질 트리거)를 always-load로 **박을 예정**(초안=`TEAM-OS-INTEGRATION.md`, the team lead 승인 대기). 반영되면 스킬을 못 읽어도 최소 절차가 돈다.
- - 실행 도구는 런타임중립 스크립트(`scripts/`)라 어디서든 직접 실행 가능.
+ ## 런타임별 사용
- > **현재 상태(정직)**: claude 런타임 자동로드만 라이브다. openclaw/hermes의 always-load thin 정의 + AGENTS.md 진입점은 **the team lead 승인 후 반영 예정** — 그 전까지는 위 "명시 로드"로 써야 한다. (이 줄을 사실로 단정하지 않는다.)
+ - **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/`)라 어디서든 직접 돌릴 수 있다.
---
- ## 자가 점검 (rubric) — "BWF를 제대로 돌렸나"
+ ## 자가 점검 — "BWF 를 제대로 돌렸나"
- `references/bwf-rubric.md`. 매 과제 자가 채점 + 팀원 학습 평가 + 퍼블릭 self-test에 같은 기준 재사용:
+ `references/bwf-rubric.md`. 매 과제 자가 채점, 팀원 학습 평가, 공개 self-test 에 같은 기준을 쓴다:
- [ ] 완료기준을 실행 전에 정했나
- - [ ] 작업모양에 맞는 품질방법을 골랐나
- - [ ] 카드화/추적했나(10분+·handoff·배포)
- - [ ] 검증증거로 완료를 입증했나(할루시네이션 "됐다" 아님)
- - [ ] the team lead에게 보이는 보고 + closure까지 갔나
- - [ ] owner·안전룰(외부전송·self-mod·승인) 지켰나
+ - [ ] 작업 모양에 맞는 품질방법을 골랐나
+ - [ ] 카드로 추적했나(10분 이상인 일·넘긴 일·배포)
+ - [ ] 증거로 완료를 입증했나("됐다" 단정이 아니라)
+ - [ ] 팀장에게 보이는 보고 + 일이 닫힐 때까지 갔나
+ - [ ] 담당·안전 규칙(외부 발송·자기 수정·승인)을 지켰나
- self-test: `scripts/bwf-selftest.sh`(샘플 골든태스크 절차 + 단계 산출물 체크리스트).
+ self-test: `scripts/bwf-selftest.sh`(샘플 과제 절차 + 단계 산출물 체크리스트).
---
- ## 경계 (무엇이 BWF가 아닌가)
+ ## 경계 (BWF 가 아닌 것)
- - BWF는 **실행 절차**다. owner 판단·외부전송/self-mod 승인·릴리즈 게이트 같은 **안전/핵심룰은 TEAM-OS(always-load)에 남는다** — 스킬로 내리지 않는다(§9 DO-NOT-COMPACT).
- - 품질방법 정본은 각 스킬(harness 등). BWF는 **고르는 표**만 — 복붙하면 드리프트.
- - 주간 메타-개선(팀 정책 자가발전)은 **learning-loop**(별도). BWF는 6단계 hook으로 넘기기만.
+ - BWF 는 **실행 절차**다. 담당 판단·외부 발송/자기 수정 승인·머지 승인 등급·롤백·릴리즈 게이트 같은 **안전·핵심 규칙은 TEAM-OS §4 에 있다(작업 때 직접 읽는다)** — 여기에 다시 적지 않는다(TEAM-OS DO-NOT-COMPACT).
+ - 품질방법의 정본은 각 스킬(harness 등)이다. BWF 는 고르는 표만 둔다 — 복사하면 내용이 어긋난다.
+ - 팀 정책을 스스로 다듬는 주간 개선은 **learning-loop**(별도)다. BWF 는 6단계에서 넘기기만 한다.