왜 네 개의 경계인가 — 4C Stack

4-1·4-2·4-3에서 한 칸씩 정의하고 4-4에서 Agent Execution Graph와 작업분해 하네스로 합친다.

작업 트리 — 한눈에 보는 구조

리프가 완비되어 있으면 보조 세션이 첫 문장을 추측 없이 시작한다.

트리 vs 목록 — 같은 5개, 다른 완결성

작성 절차

4세션 분업 — 상태판과 소모품

메인 세션은 상태판, 보조 세션은 소모품 — 돌려받는 것은 handoff 한 장뿐.

handoff 양식 — 한 장 골격

# Handoff — <리프 ID> · <세션 종류> → 메인

## From task (4-1 리프)
- 목적:
- 입력:
- 범위 (하지 않을 일 포함):
- 금지:
- 완료조건:

## Result (이 세션이 채운 부분)
- 결과 요약:        ← 본문 산출물의 한 줄 또는 표 한 장
- 근거(출처):       ← 결과의 각 주장이 온 파일·줄 (자기보고 금지)
- 판정:             ← pass / rework / ask-back / exit 중 하나
- 남은 질문:        ← 미해결 의문 모음
- 다음 첫 행동:     ← 메인 세션이 다음 보조 세션에 줄 한 줄

데모 — build 세션이 "본문 채우기"를 끝내고 돌려준 handoff

# Handoff — 본문 채우기 · build 세션 → 메인

## From task
- 목적: 회의록 확정 내용으로 1page 본문을 채움
- 입력: 회의록 원문(sample-meeting.md) + ask 세션 결정 답 + 보존 인용 3줄
- 범위: "확인 필요 항목"을 뺀 본문 전체. 회의록에 없는 사실 추가 금지
- 금지: 미확인 수치·일정·담당자를 결론처럼 쓰기
- 완료조건: 제목·배경·문제·사용자·해결 방향·성공 기준이 한 줄 이상씩

## Result
- 결과 요약:
  | 칸        | 채운 내용 |
  |---|---|
  | 제목      | 사내 교육 신청 페이지 개편 v1 |
  | 문제      | 일정·환불 안내가 안 읽혀 신청 후 CS 문의 |
  | 성공 기준 | "신청 직후 환불·일정 문의를 줄인다" |
- 근거(출처):
  - 성공 기준  ← sample-meeting.md:10
  - 문제       ← sample-meeting.md:16
  - 범위 밖(전체 리뉴얼 제외) ← sample-meeting.md:15
- 판정: 통과       ← 자체 검수 (review 세션 판정은 별도)
- 남은 질문: 성공 기준의 측정 단위·기간은 미확정
- 다음 첫 행동: review 세션에 본문 초안 + 근거(출처)를 함께 보낸다

작성 절차

데모 — review 세션이 "본문 채우기" 결과를 받고 돌려준 handoff

# Handoff — 본문 채우기 · review 세션 → 메인

## From task
- 목적: build 세션이 만든 본문 초안이 본문 채우기 완료조건을 만족하는지 독립 판정
- 입력: build 세션 handoff (본문 초안) + 본문 채우기 완료조건
- 범위: 통과/재작업/ask-back/exit 한 줄과 사유까지. 본문 직접 수정 금지
- 금지: build 세션 대화 전문 참조, 임의로 칸 내용 추가/삭제
- 완료조건: 판정 한 줄 + 사유 한 줄 + 메인 세션의 다음 결정 한 줄

## Result
- 결과 요약:
  - 형식: 9칸 + 근거(출처) 칸 다 채움 OK
  - 증거: 성공 기준·문제는 줄 10·16에 있음 OK / "CS 문의 60%"는 줄 16에 60% 없음
  - FN 보정: 60%는 수치라 표현차로 못 봐줌 — 누락 확정
- 판정: 재작업
- 남은 질문: 60% 출처가 회의록 어느 줄이었는지 확인 필요
- 다음 첫 행동: build 세션에 "60% 근거 줄을 달거나 본문에서 빼기"만 요청

3단 검수 — 어디서 막히는가

단계별 실패는 단계별 Exit가 정해져 있다. Exit가 정해져 있어야 검수가 다음 행동을 정한다.

우리가 만들 deterministic review gate — 한 장 골격

# Deterministic Review Gate — <리프 ID>

## Inputs
- handoff: <파일 또는 표>     ← 근거(출처) 칸 포함
- 완료조건: <리프의 완료조건>

## Stage 1 — 형식
- 질문: 9칸 + 근거(출처) 칸이 다 있고 양식이 맞는가
- 결과: [통과 / 실패]
- 다음 행동: 통과면 Stage 2, 실패면 재작업

## Stage 2 — 증거 (실작업)
- 질문: 각 주장이 근거 줄(파일:줄)에 실제로 있는가 (자기보고 금지)
- 결과: [통과 / 실패한 주장 목록]
- 다음 행동: 근거 없는 주장 = 안 한 작업 → Stage 3에서 확정

## Stage 3 — false-negative 보정
- 질문: Stage 2가 건 주장이 표현차(산문)인가 진짜 누락(값)인가
- 규칙: 수치·날짜·ID 값이 근거에 없으면 누락 확정 / 산문 차이는 통과
- 다음 행동: 누락 확정이면 재작업, 표현차면 되살려 통과

## Verdict
- 한 줄 판정: pass / rework / ask-back / exit
- 다음 세션의 첫 행동:

데모 — 본문 초안 검수 한 장

# Review Loop — 본문 채우기

## Inputs
- handoff: build 세션 handoff (본문 초안 + 근거(출처))
- 완료조건: 본문이 각각 한 줄 이상

## Stage 1 — 형식
- 결과: 통과
- 사유: 9칸 + 근거(출처) 칸 다 채움
- 다음: Stage 2

## Stage 2 — 증거 (실작업)
- 결과: 1건 실패
- 사유: 성공 기준·문제는 줄 10·16에 있음 OK / "CS 문의 60%"는 줄 16에 60% 없음
- 다음: Stage 3에서 확정

## Stage 3 — false-negative 보정
- 결과: 누락 확정
- 사유: "60%"는 수치(구조화된 값) — 표현차로 못 봐줌
- 다음: 재작업

## Verdict
- 한 줄 판정: 재작업
- 다음 세션의 첫 행동: build 세션에 "60% 근거 줄을 달거나 본문에서 빼기"만 요청

작성 절차

데모 — "본문 채우기"의 exit/ask-back 기준

# Review Loop Protocol — 본문 채우기

## Inputs
- handoff: build 세션 handoff (본문 초안)
- 완료조건: 본문이 각각 한 줄 이상

## Stage 1 — 형식      [통과]  9칸 + 근거 칸 다 채움 → Stage 2
## Stage 2 — 증거      [실패]  "CS 문의 60%" 줄 16에 60% 없음 → Stage 3
## Stage 3 — FN 보정   [누락]  60%는 수치 — 표현차로 못 봐줌

## Verdict
- 판정: 재작업
- 다음 첫 행동: build 세션에 "60% 근거 줄을 달거나 본문에서 빼기"만 요청

## exit 신호 (사람에게 보고)
- 재작업 3회 같은 Exit / 외부 답 대기 / 입력 자체 문제

## ask-back 신호 (ask 세션으로)
- 회의록 결정 항목이 2개 이상 해석 / 완료조건 단어가 2 해석
- 검수자가 같은 표현으로 두 번 판정 불가

데모 — Agent Execution Graph 한 장

# Agent Execution Graph — meeting-to-1page 분업

## Graph Goal
- 시작 입력: 회의록 원문
- 최종 산출물: 검수까지 통과한 1page 본문
- 성공 조건: 리프마다 handoff 한 장으로 돌고, review gate가 verdict를 남긴다

## Nodes  (4-1에서 분업 가치 있다고 본 리프만)
| node = 리프 | sub agent | input (handoff) | output (handoff) | guard (review gate) |
|---|---|---|---|---|
| 회의록 결정 항목 질문 | ask 세션 | 회의록 원문 | 의사결정자 질문 표 | format: 질문·대상 칸 |
| 본문 채우기 | build 세션 | 회의록 확정 + 질문 답 | 1page 본문 + 근거(출처) | evidence: 근거 줄 대조 |
| 보존 표현 인용 검사 | review 세션 | 본문 + 원문 인용 3줄 | 통과 / 위반 줄 | FN 보정: 값 일치 |

## Edges
결정 항목 질문 -> 본문 채우기 -> 보존 표현 인용 검사
보존 표현 인용 검사 -> 본문 채우기   [rework: 근거 누락]
결정 항목 질문 -> ask 세션            [ask-back: 회의록 모호]
보존 표현 인용 검사 -> 메인 보고       [pass / exit]

Task Decomposition Harness v1 — 실행 contract

핵심은 메인 세션이 리프마다 sub agent를 띄워 handoff → review → route를 도는 루프다. sub agent를 띄우는 방법(runtime surface)은 예시일 뿐, 이 루프가 v1의 본체다.

# Task Decomposition Harness v1 — <내 업무 이름>

## Harness Contract
- input: 내 실제 업무 입력 (예: 회의록 원문)
- output: 검수까지 통과한 산출물 + 리프마다 verdict
- pass condition: 리프마다 handoff·근거·verdict·다음 행동이 있음
- exit condition: 같은 rework 반복 / 외부 결정 대기 / 입력 부족

## 메인 세션이 도는 루프 (리프마다)
1. handoff 양식으로 sub agent에 brief를 보낸다
2. sub agent가 handoff 한 장으로 결과를 돌려준다
3. review gate(format·evidence·FN 보정)로 통과시킨다
4. route: pass=다음 리프 / rework=같은 sub agent에 좁힌 재의뢰 / ask-back=ask 세션 / exit=사람 보고

## Runtime Surface (예시 — 바뀌어도 위 루프는 그대로)
| 항목 | 지금 내 도구에서 | 런타임 독립 workflow |
|---|---|---|
| sub agent 띄우기 | Claude Code Task · Codex sub-agent · 새 대화창 | node 실행 단위 |
| guard | review gate 프롬프트 | format·evidence·FN |
| handoff | markdown 한 장 | node 입출력 계약 |
| state log | 리프별 verdict 메모 한 줄 | route + 상태 기록 |

작성 절차

데모 — dry-run 결과 한 장

# Dry-run — meeting-to-1page 분업 (sub agent 1회 실제 실행)

## 요청
회의록(sample-meeting.md)으로 1page 본문을 채우고 검수까지 돌려줘.

## 메인이 띄운 sub agent와 회수
| 리프 (node) | sub agent | handoff 회수 | review verdict |
|---|---|---|---|
| 본문 채우기 | build 세션 | 1page 본문 6칸 + 근거(출처) | evidence 1건 실패 |
| 보존 표현 인용 검사 | review 세션 | 인용 3줄 대조 | (대기) |

## Route
- verdict: rework
- 다음 행동: build 세션에 "성공 기준 60% 근거 줄을 달거나 본문에서 빼기"만 재의뢰
- state log: 본문 채우기 = rework(근거 누락) · 나머지 리프 대기