PRD — 기능 요구사항

파이프라인 3단계(Planning) 산출물 · 2026-08-26 근거: docs/seed-spec-cocode.md v3.0.2 (DRAFT — Specification Gate 미통과), docs/planning-inputs-cocode.md, docs/discovery-cocode.md, docs/socratic-discovery-cocode.md, docs/decision-log-cocode.md

이 문서의 지위

Seed Spec 이 잠기지 않은 상태(모호성 0.3125 / 기준 0.2)이므로, 이 PRD 가 인용하는 C-NN·AC-NN 은 확정된 계약이 아니라 현재 시점의 가장 강한 합의다. docs/spec-evaluation-cocode.md §판정과 권고가 후속 단계에 이 문서를 "작업 가설"로 취급할 것을 지시한다.

PRD 는 Seed Spec 을 부연하며, 뒤집지 않는다. 둘이 어긋나면 Seed Spec 이 이긴다.

작성 방식

이 문서의 네 개 절은 각각 독립 에이전트가 초안을 쓰고, 별도의 출처 감사 에이전트가 원본 문서를 직접 열어 대조한 뒤 교정한 것이다. 감사가 잡아낸 것: 지어낸 수치 17건, 깨진 인용 26건, 거짓 완전성 주장 24건, 판정이 필요한 규칙 42건, Seed Spec 과의 모순 24건. 전부 이 파일에 쓰이기 전에 교정됐다.

이 방식을 쓴 이유는 Specification 단계에서 같은 결함 유형이 8라운드 반복됐고, 사후 감사로는 잡히지 않았기 때문이다(docs/spec-evaluation-cocode.md §반복된 실패 패턴).

⚠️ v3.1.0 반영 사항 (2026-08-26, Analysis Gate 이후)

Analysis Gate 가 이 문서와 BDD 에서 실제 로직 결함을 잡아냈고, 오너 결정 3건이 확정됐다. Seed Spec v3.1.0 이 정본이며 아래가 우선한다.

1. AC-02 롤백 충돌 감지 — 규칙이 교체됐다. 이 문서 본문의 현재 해시 vs base_content_hash 비교 서술(FR-506, 흐름 4, §3.3 등)은 폐기한다. base_content_hash 는 편집 직전 해시라 에이전트 편집 후에는 항상 불일치하므로, 그 규칙대로면 모든 롤백이 충돌로 보고되어 안전장치가 무력화된다.

• EditSnapshot 에 result_content_hash(편집 직후 해시)를 신설
• 충돌 판정 = 현재 해시 ≠ 그 파일의 마지막 EditSnapshot 의 result_content_hash
• base_content_hash 는 복원 목표이지 판정 기준이 아니다

2. "테스트 파일" 판정 확정 — test/ · integration_test/ · widgetbook/ 디렉터리 아래 파일(경로 기반, 판정 불필요). C-05 가 Planning 에 위임했던 항목이며 이로써 AC-11 이 기계적으로 판정 가능해진다. 이 문서가 U-7/D-1 로 "확정 주체부터 정해야 한다"고 적은 부분은 해소됐다.

3. 워크트리 격리·작업 인계는 MVP 밖 — AC-21(Must-Not) 신설. 이 문서가 Q-04 로 "명시되지 않은 회색지대"라 적은 부분은 해소됐다. 단 AC-12(한 워크스페이스 내 복수 작업 동시 진행 + 파일 단위 잠금)는 MVP 안이며 이 제한과 무관하다.

아직 미정 — North Star Metric 과 과금 방식은 오너가 "지금 정하지 않는다"로 결정했다. MVP 출시 후 실사용 데이터를 보고 정한다.

1. 제품 개요 · 목표 · 범위 · 비즈니스 모델

이 절의 근거 상태 (먼저 읽을 것). 이 절이 인용하는 Seed Spec(docs/seed-spec-cocode.md v3.0.2)은 DRAFT이며 Specification Gate 미통과다 — 모호성 0.3125, 통과 기준 0.2 이하(docs/spec-evaluation-cocode.md §Summary). 같은 문서 §판정과 권고 1번이 후속 단계에 "이 문서를 확정된 계약이 아니라 작업 가설로 취급"할 것을 지시한다. 따라서 아래의 C-NN·AC-NN 인용은 잠긴 계약이 아니라 현재 시점의 가장 강한 합의다. 또한 §판정과 권고 2번은 docs/planning-inputs-cocode.md를 Planning의 필수 입력으로 지정한다.

검증 범위 고지. 이 절의 모든 인용은 docs/ 안의 8개 문서(seed-spec · planning-inputs · discovery · socratic-discovery · decision-log · spec-evaluation · contrarian-review · simplifier-review)를 직접 열람해 대조했다. 원 설계 노트(Discovery 머리말 3행이 가리키는 외부 artifact)는 이 저장소에 없어 열람하지 못했다 — 설계 노트에서 유래한 값(§1.4의 가격 구간)에 대해 이 PRD가 보증할 수 있는 것은 "Discovery가 그렇게 전사했다"까지이며, 설계 노트 원문의 내용은 확인 불가다.

1.1 제품 개요

무엇인가

cocode ADE는 Dart/Flutter 전용 에이전트 개발 환경(ADE) 데스크톱 애플리케이션이다. Seed Spec §0 Glossary가 ADE를 "사람이 코드를 직접 편집하는 것을 1급으로 두는 IDE와 달리, AI 에이전트에게 작업을 위임하고 그 결과를 검토·되돌리는 것을 1급으로 두는 개발 환경"으로 정의한다.

이 정의는 IDE와의 대비이지 편집 기능의 격하가 아니다. 코드 에디터는 MVP의 필수 구성요소이며(C-01 "코드 에디터를 포함한 개발자용 인터페이스", AC-03), 제품이 추가로 1급에 올려놓는 것이 위임 → 검토 → 되돌리기 루프다. 두 가지는 경쟁하지 않는다.

어떤 부재를 메우는가 (Seed Spec §1 Core Problem)

§1이 규정한 문제는 "Dart/Flutter 개발자가 반복 작업을 AI 에이전트에게 되돌릴 수 있는 방식으로 위임하고 자리를 비울 수 있는, Dart/Flutter 전용으로 설계된 ADE가 없다"이다. 세 개의 강조점이 그대로 제품의 세 축이 된다.

왜 기존 도구로 안 되는가 (§1 Problem Rationale 4개 항목의 제품적 해석)

• Flutter 기반 경량 에디터는 이미 있으나 ACP 클라이언트에 그친다. Lumide 0.20.0 실사 결과다(§1 Rationale 1번). Seed Spec이 인용한 Discovery가 같은 사실을 별도 항목으로 기록해 두었다 — "ACP 클라이언트만으로 '멀티 LLM' 요구를 충족한다"는 가정이 Discovery §User Research > Validated/Unvalidated Assumptions 표에서 검증됨(거짓) 으로 판정됐다. ACP는 에이전트가 노출한 목록 안에서만 모델을 고를 수 있기 때문이다. → 제품 결론: 자체 런타임(agent)과 외부 에이전트 호스팅(acp)을 둘 다 1급으로 둔다(AC-06, D-006).
• 범용 에이전틱 에디터(Zed·Cursor·Google Antigravity) 는 Flutter/Dart를 부차적으로 지원할 뿐 언어 전용 목적 지향 설계가 아니다(§1 Rationale 2번, Discovery §Market Analysis > Competitive Landscape).
• 실질적 경쟁자는 Orca(Stably AI, MIT, ★2만+)이며, 언어·에이전트에 무관한 수평적 오케스트레이터라 Dart/Flutter 런타임 상태 인지도 결정론적 스캐폴딩도 없다(Socratic 문서 Level 4 B-02, D-002). ※ Orca 관련 수치의 출처는 Socratic B-02다 — Discovery에는 Orca 언급이 0회이며, 과거 Discovery를 출처로 적은 것은 오기로 정정됐다(Seed Spec 출처표). → 제품 결론: 같은 축에서 정면 경쟁하지 않고 수직 깊이로 포지셔닝한다. ⚠️ 이 포지셔닝은 고객 리서치가 아니라 프로젝트 오너의 판단에 근거하며, 위험을 인수한 상태다(C-03 본문 경고, A-07, D-011, Contrarian CH-009 = Accepted).
• 비동기 위임이 핵심 상호작용 모델인 이유는 "코딩을 선호하는 인구는 줄고 개발자조차 AI 위임이 늘어난다"는 오너의 전망이다(Socratic Level 2 A-04). 이 역시 전망이지 검증된 시장 데이터가 아니다.

아키텍처 개요 (확정 계층과 제안 계층의 구분)

확정된 것은 여기까지다: 자체 런타임 경로(agent — 서로 다른 LLM 프로바이더 2개 이상)와 외부 ACP 호스팅 경로(acp — ACP 에이전트 1개 이상) 두 경로를 모두 제공한다(AC-06), 둘 다 MVP 필수다(D-006), 그리고 agent의 프로바이더 조합은 Anthropic(anthropic_sdk_dart) + OpenAI 호환 게이트웨이다(D-017, planning-inputs §1) — 게이트웨이 한 계층으로 Grok·Mistral·Ollama·OpenRouter가 함께 들어오기 때문이다.

아직 제안 계층인 것: Discovery §Ideation > Solution Direction의 3분할 도해(cocode_ade 셸 아래 agent/acp, 자체 런타임도 ACP 서버로 노출해 UI 코드 경로를 통일)는 Discovery 본문 표현대로 "채택 방향으로 제안"된 것이며, 이를 채택한 결정 기록은 D-001~D-021에 없다. Design 단계 결정 사항으로 넘긴다. 또한 그 도해는 openai_dart 직접 구현을 함께 적지만 D-017이 그 옵션(옵션 3)을 명시적으로 기각했으므로, 도해를 그대로 승계하면 D-017과 충돌한다.

1.2 목표와 성공 기준

목표 (제품 수준)

§1이 규정한 부재를 해소하는 것 — 외부 Dart/Flutter 개발자가 반복 작업을 맡기고 자리를 비웠다가 돌아와, 무엇이 바뀌었는지 보고 마음에 들지 않으면 되돌릴 수 있는 상태. Socratic Level 1이 기록한 오너의 성공 이미지가 이것과 같다: "성공적인 위임 경험이 반복되면 이탈하지 않는 제품이 됨."

확정된 유일한 합격선 — Seed Spec §4 인수 경계 20건

§4의 인수 경계 20건(Must 18 + Must-Not 2) 전량 충족이 MVP의 합격선이다. 현재 20건 모두 Status = PENDING이다. (개수 교차 확인: §4 표 AC-01~AC-20, spec-evaluation M-06(Must 18)·M-07(Must-Not AC-04·AC-05).)

⚠️ "20건 전량"이 곧 "20건 전부 기계적으로 판정 가능"은 아니다. spec-evaluation §개정을 멈춘 이유 3번이 판정 주체 미정 3건(AC-11·AC-09·AC-20)을 지목했다. 즉 17건은 현 문언으로 판정 가능하고, 3건은 §1.6 Q-05가 풀린 뒤에야 판정 가능해진다. 이 사실을 합격선 서술에서 지우면 spec-evaluation의 판정을 조용히 뒤집는 것이 된다.

⚠️ 성공 기준에 수치는 아직 없다. 프레임 타임·설치 용량·콜드 스타트·메모리·자가 검증 검출률은 전부 미확정이며, 과거 라운드에서 이 자리에 지어낸 값을 넣었다가 폐기한 이력이 있다(spec-evaluation §반복된 실패 패턴 1번: p95 16.7ms·설치 150MB·결함 30건·검출률 80%·10분). 이 PRD는 값을 채우지 않고 측정 계획을 명시한다(아래 표).

A-01 승계 — 이 PRD가 담당하는 항목

Seed Spec A-01의 검증 방법이 "Planning 단계 PRD의 타깃 세그먼트 정의로 승계"다. 따라서 타깃 세그먼트를 확정하는 것은 이 PRD의 의무다. 확정된 입력은 1차 고객 = 외부 Dart/Flutter 개발자 시장(D-005, C-01 후단, A-01 Verified)이며, 코코드 내부 팀이 아니다.

North Star Metric — 미확정. 이 PRD가 결정하지 않는다.

Discovery §Vision > "North Star Metric (후보, 미확정)"이 세 후보를 제시하고 선택하지 않았다.

식별자 고지: NSM-a/b/c는 이 PRD가 참조 편의를 위해 붙인 것이며 Discovery 원문에는 ID 열이 없다. 후속 문서가 이 식별자를 Discovery의 것으로 재인용하지 말 것. 아래 2열은 Discovery 78~84행 표의 두 열("후보 지표", "적용 시나리오")을 원문 그대로 옮긴 것이고, 3열만 이 PRD의 판정이다.

Discovery §Recommendations 1번이 "비전 문장·North Star·MVP 범위가 전부 이 답(1차 사용자)에 종속됨"이라 적었고, 그 답은 D-005로 확정됐다. 즉 선행 조건은 이미 풀렸는데 North Star 결정만 기록되지 않았다. 의사결정 일지 D-001~D-021을 통독하고 docs/ 전체를 North Star로 검색한 결과, 이 지표를 정한 항목은 없다(히트는 Discovery 78행·130행 두 곳뿐이며 둘 다 미확정 서술).

→ 결정 필요 (Q-01, 아래 §1.6).

미확정 목표치의 측정 계획

제품 리스크로 승격해 둘 것. 위 표 3행이 뜻하는 바는, MVP 출시 시점의 기본 완료 모드가 사람승인일 수 있다는 것이다(AC-17). 그 경우 "자리를 비울 수 있다"는 핵심 가치제안이 첫 출시에서 부분적으로만 성립한다. A-02는 Seed Spec 스스로 "이 문서에서 가장 부담이 큰 가정"이라 표기한 항목이다.

1.3 범위 (MVP)

범위를 정하는 두 결정

• C-01 — MVP는 코드 에디터를 포함한 개발자용 인터페이스로 우선 출시하고, 비개발자용 자연어 전용 "드리머 모드"는 MVP 이후로 순연한다. 배포 대상은 macOS·Windows·Linux 데스크톱 3종이다(D-001, D-005, D-016).
• C-03 — 1급 프로젝트 타입을 Dart/Flutter로 한정한다(D-002, D-011).

MVP 안 — §4가 규정하는 것

계수 근거: 위 표의 AC 참조는 AC-03/01/02/06/07/08/09/10/17/11/12/18/13/14/15/16/19/20 = 18건이고, Must-Not 2건(AC-04·AC-05)은 아래 "MVP 밖"으로 옮겼다. 18 + 2 = §4의 20건 전량이다.

※ AC-15 묶음 라벨에 "대용량"을 쓰지 않은 것은 의도적이다 — Seed Spec Evolution Log v3.0.1 ②가 AC-15에서 모호어 "대용량·다수"를 제거했으므로, PRD가 그 단어를 요건 라벨로 되살리면 안 된다.

MVP 밖

범위 해석에서 자주 틀리는 세 지점

1. 결과물 카테고리 배제는 없다. Socratic Level 4 B-03 / D-004 — 게임·임베디드를 포함해 배제 카테고리를 두지 않는다. 이는 사용자가 만드는 결과물의 층위이며, cocode ADE 자신의 MVP 범위(C-01)와는 다른 층위다. 둘을 섞으면 D-004가 명시적으로 분리한 구분이 무너진다.
2. Discovery의 6단계 로드맵은 MVP 범위 정의가 아니다. 로드맵은 ACP를 3단계, 자체 런타임을 5단계에 배치하지만(Discovery §Recommendations 2번), D-006이 "Seed spec이 지배하며 Discovery의 단계 순서는 구현 순서 제안일 뿐"이라고 확정했다. agent와 acp는 둘 다 MVP 필수다.
3. 워크트리 격리·작업 인계는 §4에 인수 경계가 없다. C-03과 Socratic Level 5는 "장기적으로 Orca급 기능 폭(멀티 에이전트 오케스트레이션, 워크트리 격리, 작업 인계)까지 커버"를 장기 방향으로 서술한다. (검증: docs/ 전체를 워크트리|worktree|인계|handoff로 검색한 결과 Seed Spec 내 히트는 C-03 한 곳뿐이며 §4에는 0건.) 한편 AC-12("동일 워크스페이스에서 두 작업이 같은 파일을 편집하려 할 때… 첫 번째 작업이 마칠 때까지 대기")와 Workspace 불변식 2번("동일 파일 경로를 두 개 이상의 DelegatedTask가 동시에 편집할 수 없다")은 한 워크스페이스 안에서 복수 DelegatedTask가 동시에 진행되는 상황을 전제로 한 대기 규칙이다. 여기서 "복수 작업 동시 진행이 MVP에 포함된다"는 것은 이 PRD의 추론이지 §4가 명시한 문장이 아니다. 그리고 워크트리 격리·작업 인계에 대응하는 AC는 없다 → MVP 포함 여부가 명시되지 않은 회색지대다. → Q-04.

1.4 비즈니스 모델

소스가 실제로 분석한 것

가격 분석의 원출처는 Discovery가 인용한 설계 노트(Discovery 머리말 3행이 밝힌 외부 산출물)다. 이 저장소에 설계 노트는 없다 — 아래 표가 보증하는 것은 "Discovery가 이렇게 전사했다"까지이며 설계 노트 원문은 확인 불가다. Discovery 본문에는 두 곳에 나뉘어 기록돼 있으므로 인용 위치를 정확히 구분한다.

📌 인용 주의: $0·$20/월 두 수치는 §Market Analysis가 아니라 §User Research(Target Personas 표 P2 행) 에만 있다(전체 검색 결과 17행 1건). $5~9/월은 17행·66행 양쪽에 있다. (이 프로젝트는 과거에 §Market Analysis를 존재하지 않는 내용의 출처로 인용한 이력이 있어 위치를 분리 표기한다 — spec-evaluation §반복된 실패 패턴 4번.)

cocode ADE의 모델에 대한 함의

1. 소스의 논리는 수익원을 모델 마진이 아니라 "도구값"으로 잡는 것이다. 근거는 두 층으로 나뉜다 — 경로의 존재는 AC-06(acp가 외부 ACP 에이전트를 호스팅한다)이 보증하고, 그 경로가 사용자의 기존 구독을 재사용한다는 서술은 Discovery §User Research P2 행("ACP로 자기 구독(Claude/ChatGPT) 재사용")과 §Market Analysis 3번("모델 마진 없이 도구값만")에 있다. AC-06 자체는 비용·구독·마진을 일절 언급하지 않으므로 비용 논증을 인수 경계에 귀속시키지 말 것. 이 논리는 인용된 것이지 검증된 것이 아니다.
2. 그러나 agent가 이 논리에 구멍을 낸다. AC-06은 자체 런타임(프로바이더 2개 이상)을 MVP 필수로 규정하고, D-017이 Anthropic + OpenAI 호환 게이트웨이로 확정했다. 이 경로의 모델 비용을 누가 부담하는가(사용자 키 지참 = BYOK인가, 제품이 조달해 재판매하는가)가 과금 설계의 분기점이다. docs/의 8개 문서 전체를 가격|과금|구독|유료|지불|결제|무료|BYOK|$로 검색한 결과, 이 결정을 내린 항목이 없다(히트는 Discovery 12·17·66·84행과 decision-log 60행뿐이며 전부 시장 분석 인용이지 결정이 아니다). 설계 노트는 열람 불가이므로 그 안에 결정이 있는지는 확인할 수 없다. Seed Spec §0은 "LLM 프로바이더"를 "모델 API 제공자 또는 그와 호환되는 엔드포인트"로만 정의하고 과금 주체를 말하지 않는다.
3. 사내 도구 원가 모델로 회피할 수 없다. 1차 고객이 외부 시장으로 확정됐으므로(D-005, A-01 Verified), 가격은 실제 외부 판매 조건이지 내부 정산 항목이 아니다.
4. 유료화 근거가 미검증 가정 하나에 걸려 있다. 인지된 경쟁자 Orca는 MIT 오픈소스다(D-002, Socratic B-02). 무료 오픈소스 대비 유료를 정당화하는 논리는 "Dart/Flutter 수직 깊이"이며, 그 전제인 A-07("Dart/Flutter 개발자가 수평적 넓이보다 수직적 깊이를 더 선호한다")은 Unverified이고 검증 시점이 MVP 출시 후(사용자 인터뷰·이탈 사유 분석)다. 즉 가격 가설과 포지셔닝 가설이 같은 미검증 가정 위에 서 있다.
5. 원가 측면의 유리한 입력: 핵심 부품 다수가 MIT로 공개돼 있다 — lumide_api, panes, xterm2, flutter_pty2(Discovery §User Research > Key Insights 4번). 단 xterm2/flutter_pty2 재사용은 한글 IME 결함(Lumide 이슈 #64, 2026-07-29 등록·미해결)을 물려받을 위험이 있다(A-04, planning-inputs §4.2) — 원가 절감과 게이팅 리스크가 같은 부품에 얽혀 있다.
6. 재배포 가능 형태에 법무 제약이 있을 수 있다. Discovery §Recommendations > Input Items for Planning Stage 5번: cocode ADE 제품 자체에 Serverpod 서버 패키지를 임베드/재배포할 계획이 있다면 SSPL-1.0 사전 법무 검토가 필요하다.

확정되지 않은 것 (이 PRD가 정하지 않음)

• $5~9/월은 설계 노트의 시장 분석값을 Discovery가 전사한 것이지 오너가 선택한 가격이 아니다. 의사결정 일지 D-001~D-021을 통독한 결과 가격·과금 방식을 정한 항목이 없다.
• 미결: 가격대, 과금 방식(구독/영구 라이선스/무료+유료 티어), agent 경로의 API 키 조달 주체, 무료 티어 유무, 팀/조직 라이선스 유무.
• 이 문서 집합 안에서 사용자 지불 의사에 대한 1차 진술은 Socratic Level 1의 "돈을 내고 AI에게 일을 맡기고" 한 건뿐이며(돈 전체 검색 결과 socratic 15행 1건), 지불 대상·금액은 없다.

→ Q-02, Q-03.

1.5 제약 — C-01~C-05 (PRD 독자용 요약)

Seed Spec §2. 잠금 후 변경 불가로 설계된 층위이나 현재 문서는 DRAFT이므로 아직 잠기지 않았다(spec-evaluation M-02).

C-05의 설계 원칙은 다른 요구사항에도 그대로 적용할 것. C-05 근거란이 밝히듯, "약화"의 경계를 판정하는 대신 기존 테스트 파일에 대한 모든 변경을 승인 대상으로 삼아 판정 자체가 필요 없게 만들었다. 판정이 필요한 규칙은 분쟁하거나 우회된다.

반대로, 판정 주체가 미정이라 아직 기계적으로 검증 불가능한 항목이 3건 있다(spec-evaluation §개정을 멈춘 이유 3번 및 §판정과 권고 3번):

같은 문서가 이 셋은 문구 수정이 아니라 설계 결정으로만 정해진다고 판정했다.

추가로 이 PRD 작성 중 관찰된 판정 필요 지점 (위 3건에 포함되지 않은 것 — 개수를 늘려 인용하지 말 것). spec-evaluation이 세지 않은 항목이며, 여기서 새로 제기한다:

• AC-19의 "조용히" — "편집이 조용히 폐기되거나 조용히 확정되지 않는다"는 관찰자 기준 판정어다. C-05식으로 판정을 없애려면 "실패 작업의 편집은 사용자가 적용/롤백 중 하나를 명시적으로 선택하기 전까지 어느 쪽으로도 확정되지 않는다"처럼 상태 전이로 환원해야 한다. Seed Spec 개정 사항이므로 이 PRD는 제안까지만 한다.
• AC-15의 "화면이 응답하지 않는 구간" — Planning이 프레임 타임 임계값을 확정하기 전까지 판정 불가(§1.2 측정 계획표 2행).
• AC-16의 관찰 방법 — planning-inputs §4.3이 확정 항목으로 명시(§1.2 측정 계획표 4행).
• AC-14의 의존성 호스트 추출 알고리즘 — planning-inputs §2.5: 정해지지 않으면 두 구현이 서로 다른 허용 집합을 만든다.

→ Q-05.

1.6 이 절이 남기는 미결 질문

Q-07 세부 — 출처를 절 단위로 분리한다

planning-inputs §6은 5개 항목을 목록화하며, 그중 1번은 "미결"이 아니다. 나머지 두 항목은 §6이 아니라 §3.3·§4.3에 있다. 개수와 위치를 섞어 재인용하지 말 것.

이 절이 의도적으로 결정하지 않은 것에 대한 메모

위 8건은 "나중에 채울 빈칸"이 아니라 지금 채우면 근거 없는 값이 되는 항목이다. spec-evaluation §반복된 실패 패턴이 기록한 대로, 이 프로젝트는 8라운드에 걸쳐 같은 자리에 값을 지어 넣었다가 다음 라운드에서 폐기했다 — 확인된 구체 사례는 §반복된 실패 패턴 1번(p95 16.7ms·설치 150MB·결함 30건·검출률 80%·10분)과 D-013·D-015·D-020이며, D-020은 이 패턴이 그 시점까지 "세 차례" 반복됐다고 센다. (8은 평가 라운드 수이지 지어내고 폐기한 사건의 수가 아니다 — 이 둘을 섞어 세지 말 것.)

특히 패턴 2번(자기 인용 루프 — 앞 버전에서 만든 값을 다음 버전이 "업계 표준"으로 인용)을 피하려면, 이 PRD의 미결 항목이 후속 문서에서 확정값처럼 재인용되지 않도록 Q-NN 식별자를 유지한 채 전달해야 한다. 같은 이유로 이 PRD가 편의상 부여한 식별자(NSM-a/b/c)와 이 PRD가 새로 제기한 판정 필요 4건은 원 소스의 것이 아님을 표기해 두었다.

기능 요구사항 · 사용자 흐름 · 데이터 모델

이 절의 지위. 근거 문서는 Seed Spec docs/seed-spec-cocode.md v3.0.2다. 이 문서는 DRAFT이며 Specification Gate를 통과하지 못했다(docs/spec-evaluation-cocode.md §Summary — "Final Verdict: FAIL", 모호성 0.3125 / 기준 ≤ 0.2). 같은 문서 §판정과 권고의 첫 번째 전제가 후속 단계에 요구하는 취급은 다음과 같다: "Seed spec은 DRAFT 상태로 남는다. 잠기지 않았으므로 후속 단계는 이 문서를 확정된 계약이 아니라 작업 가설로 취급해야 한다." 아래 요구사항은 그 전제 위에 작성됐다.

근거 문서 8종. Seed Spec · planning-inputs-cocode.md · discovery-cocode.md · socratic-discovery-cocode.md · decision-log-cocode.md(D-001~D-021) · spec-evaluation-cocode.md · contrarian-review-cocode.md · simplifier-review-cocode.md. 뒤의 둘은 Seed Spec §0 용어집이 '참조 문서'로 지정한 정식 근거이며, 초기 판본이 이 둘을 빼고 "6개 문서"라고 적은 것은 오류다 — 그 누락으로 실제 규정 1건(스냅샷 보존 정책, Contrarian CH-022)을 '규정 없음'으로 잘못 분류했었다.

근거 계층 표기. 각 요구사항의 근거 열 앞에 층위를 붙인다.

• [경계] Seed Spec §2 불변 제약 · §3 엔티티 · §4 인수 경계에서 직접 파생. 이 PRD는 이를 elaborate 할 뿐 좁히거나 넓히지 않는다.
• [입력] planning-inputs-cocode.md 파생. 같은 문서가 스스로 "Planning 단계 입력 자료"라고 규정하므로 불변 경계가 아니다. 항목에 따라 Planning 미결분을 포함한다.
• [도출] 위 둘로부터 판정 없이 연역한 것. 연역 근거를 함께 적는다.

수치 표기 규칙. 수치는 다음 넷 중 하나에 근거가 있을 때만 쓴다 — ⓐ Seed Spec §4 "수치의 출처" 표 ⓑ planning-inputs 의 실측 기록 ⓒ spec-evaluation 의 측정치 ⓓ 인용된 원문에서 직접 계수 가능한 개수(이 경우 "직접 계수"라고 표기). Seed Spec §4 출처표의 자기 선언 범위는 Seed Spec §1~§5에 한정되므로 이 PRD의 수치를 자동으로 담보하지 않는다. 값이 아직 없는 항목은 값을 쓰지 않고 누가 언제 정하는지를 적는다.

1. 기능 요구사항

1.1 워크스페이스 · 스캐폴딩 (FR-1xx)

✅ 범위 확정 1 — co-brick 은 MVP 범위 밖 (D-037 / 이슈 #113, 프로젝트 오너 확정 2026-09-10). 「대응 AC 0건」이라는 공백은 AC-24(Must-Not) 신설로 닫혔다(Seed Spec v3.3.0) — applied_bricks 는 최초 스캐폴딩 brick 만 담으며 MVP 에서 원소는 1개다. 기존 워크스페이스에 co-brick 을 덧붙이는 기능은 MVP 출시 범위에 존재하지 않는다. 파급 반영은 이슈 #42.

✅ 판정 확정 2 — 실패의 정의 (D-049, 이슈 #41). FR-102의 "진행 중 실패"는 원인이 아니라 위치로 정의된다 — 반열린 구간 [첫 스테이징 쓰기, 커밋 완료) 안의 모든 비정상 종료다. 첫 쓰기 이전은 착수 전 거부(지울 스테이징도 워크스페이스도 없다), 커밋 이후는 스캐폴딩이 아니다. 위 후보 4종은 열거가 아니라 이 구간에 매핑되며 변수 검증 실패·사용자 취소는 시점에 따라 갈린다. 제시 형태는 ux-spec UX-D-23.

ℹ️ 초기값. edit_locks의 초기값은 Seed Spec이 규정하지 않는다. AC-14가 비어 있지 않은 초기화를 요구하는 대상은 allowed_hosts·write_exceptions 둘뿐이다. 초기 판본이 "생성 직후 edit_locks는 빈 집합"이라고 단언했던 것은 무출처 서술이므로 삭제하고 Design 결정으로 넘긴다(→ D-17).

1.2 에이전트 위임 · 동시성 (FR-2xx)

1.3 자가 검증 · 완료 판정 (FR-3xx)

1.4 테스트 보호 (FR-4xx)

⚠️ FR-403이 판정을 제거해도 경로 술어의 구체값은 남는다 — 그 값과 확정 주체가 §4 D-1의 내용이며, 근거 문서 두 개가 서로 다른 단계를 지정하고 있다.

1.5 편집 검토 · 롤백 (FR-5xx)

⚠️ 보존·정리 정책 누락(정정). Contrarian CH-022가 "스냅샷 볼륨 무한 증가(보존·정리 정책 부재)"를 Major로 지적하고 Accepted(위험 인수) — 재검토 시점: Design 단계 저장소 설계로 처분했다. 참고 기준으로 Lumide 선례(파일당 50버전 / 5MB)를 남겼다. 이 PRD는 보존 정책을 규정하지 않으며, 이는 '규정 없음'이 아니라 의도적 위험 인수 상태의 이관이다(→ §4.2, §3.4).

1.6 에이전트 백엔드 (FR-6xx)

FR-605의 종결 상태를 "실패"로 좁힌 연역. AC-20은 전이 대상을 "종결 상태"로만 쓰고 셋 중 어느 것인지 지정하지 않는다. 그러나 나머지 불변식이 둘을 배제한다:

• 완료 — DelegatedTask 불변식 1(자가검증 모드: 적용 가능한 방법 1종 이상 통과 + verification_log 기록)과 불변식 2(사람승인 모드: 사용자의 명시적 승인)가 요구하는 조건을 "프로바이더 응답 불가"라는 사건 자체가 만들어내지 않는다.
• 롤백됨 — 불변식 5가 "사용자의 명시적 롤백 요청으로만" 발생한다고 규정한다.

따라서 응답 불가 감지가 유발하는 전이가 도달할 수 있는 종결 상태는 실패뿐이다. 이는 AC-20을 좁힌 것이 아니라 AC-20 ∩ 불변식 1·2·5의 결과다. Design은 이 연역에 반례(응답 불가 상태에서 불변식 1 또는 2의 조건이 이미 충족된 경로)가 없음을 명시적으로 확인해 기록해야 한다. 남는 진짜 미결은 전이 대상이 아니라 감지 기준이다(→ D-3).

구현 선택(불변 경계가 아님). 아래는 D-017·D-019가 정한 구현 선택이며 Seed Spec §4의 경계가 아니다 — Seed Spec v3.0.0이 AC-06에서 프로토콜 버전 언급을 제거했다(§6 Evolution Log v3.0.0 ④: "AC-06에서 ACP 버전 언급 제거(불변 층위에 프로토콜 버전을 잠그지 않음)"). Seed Spec §4 출처표도 프로바이더 조합에 대해 같은 취지를 명시한다("D-017이 정한 구현 선택이며 이 경계의 일부가 아니다").

Gemini CLI는 파일 IO를 클라이언트로 되돌리므로 fs/read_text_file·fs/write_text_file 구현을 강제한다(planning-inputs §5.1). Codex는 resume이 있고 fork가 없으므로 fork가 resume을 함의한다고 가정한 코드를 잡는다(같은 표).

⚠️ v2 미지원 주장의 범위. planning-inputs §5.2는 "v2로 답할 수 있는 에이전트가 없다"가 디컴파일로 검증된 2종에 대해서만 참이며 나머지 30종은 미확인이라고 명시한다. 레지스트리 probe 32종/31종 v1 협상은 "프로버 자신이 v1을 요청하므로 구조상 당연"하여 v2 미지원을 증명하지 않는다.

1.7 안전 · 샌드박스 (FR-7xx)

층위 주의. FR-706~708은 [입력] 층이다 — planning-inputs 는 스스로를 "Planning 단계 입력 자료"로 규정하며, spec-evaluation §판정과 권고도 이를 '필수 입력'이라 부를 뿐 계약으로 취급하지 않는다. FR-701~705만이 [경계] 층이다.

허용 목록을 깨는 함정 3가지(실측 확인, planning-inputs §2.2). ① services.gradle.org는 zip을 서빙하지 않고 release-assets.githubusercontent.com까지 307 체인을 탄다 — "첫 호스트만 허용하면 wrapper 부트스트랩이 중간에 실패한다" ② plugins.gradle.org도 plugins-artifacts.gradle.org(때로 repo.maven.apache.org)로 303 리다이렉트한다 ③ Gradle google()의 실제 대상은 maven.google.com이 아니라 dl.google.com/dl/android/maven2/다(조사 머신 Gradle origin 인덱스: dl.google.com 3,060건 / maven.google.com 0건).

⚠️ 정정. 초기 판본은 여기에 *"구현은 리다이렉트 체인의 모든 호스트를 허용 대상으로 다뤄야 한다"*를 §2.2 인용처럼 붙였으나 그 문장은 §2.2에 없다(작성자의 일반화). 게다가 그대로 구현할 수 없다 — 리다이렉트 체인은 런타임에 드러나므로 "모든 호스트를 허용"하면 허용 목록이 무력화된다. 근거 문서가 실제로 지지하는 판정 없는 규칙은 다음 하나뿐이다: §2.2가 실측으로 확인한 중간·최종 호스트(release-assets.githubusercontent.com, objects.githubusercontent.com, plugins-artifacts.gradle.org, dl.google.com)를 §2.1 기본 목록에 미리 포함한다. 미지의 리다이렉트 대상을 런타임에 어떻게 처리할지(차단 후 사용자 승인 / 도메인 스코프 확장 / 실패)는 규정이 없다 → D-22.

1.8 개발자 인터페이스 (FR-8xx)

⚠️ AC-16은 3개 플랫폼 전부를 Must로 규정한다. D-016이 정한 것은 게이팅 스파이크의 순서(macOS 먼저 → Windows → Linux 순차)이지 출시 조건의 축소가 아니다. AC-16을 완화하려면 Seed Spec 개정이 필요하다(planning-inputs §4.3 경고문).

ℹ️ 측정 시나리오의 범위. Contrarian CH-032는 "단일 10만 줄 파일 테스트는 실제 병목(다수 생성 파일 동시 오픈)을 놓칠 수 있다"를 Major로 지적했고, 검증 방법을 두 시나리오 모두로 확장하는 것으로 Resolved 처리됐다. 현행 AC-15 본문에는 단일 파일 시나리오만 남아 있으므로 Planning의 시나리오 정의(planning-inputs §3.3)에서 이 확장을 되살릴지 결정해야 한다.

2. 사용자 흐름

상태 전이 표기. 아래 흐름은 §3 "status 값 집합"의 7개 값만 사용한다. Seed Spec이 전이 조건을 명시한 구간과 명시하지 않은 구간을 구분해 표시한다.

전이	스펙 근거
→ 완료 (자가검증 모드)	AC-09, 불변식 1 — 조건 명시
→ 사람승인대기 (완료승인)	AC-10, 불변식 2 — 조건 명시
→ 사람승인대기 (테스트변경승인)	AC-11, 불변식 3 — 조건 명시
→ 실패 (재시도 상한 초과)	AC-07, 불변식 4 — 조건 명시
→ 실패 (시간 상한 초과)	불변식 4 — 전이로 명시. ⚠️ AC-08 본문은 "실패로 기록된다"여서 전이와 범위 차이가 있다(흐름 2 미결 B)
→ 롤백됨	불변식 5 — 조건 명시
→ 실패 (프로바이더 응답 불가)	AC-20은 "종결 상태"로만 쓰나 불변식 1·2·5가 완료·롤백됨을 배제 → 실패로 연역(§1.6). 감지 기준은 미지정
대기 → 실행중 → 자가검증중	스펙이 전이 조건을 규정하지 않음 — Design 확정
재시도 시 되돌아가는 상태	스펙이 규정하지 않음 — Design 확정

흐름 1 — 워크스페이스 생성(brick 스캐폴딩)

1. 사용자가 새 워크스페이스 생성을 시작한다.
2. 시스템이 프로젝트 타입 선택지를 제시한다. Dart/Flutter 이외의 언어는 1급 프로젝트 타입으로 나타나지 않는다(FR-103 / AC-05).
3. 사용자가 brick을 선택하고 필요한 변수를 입력한다.
4. 시스템이 스캐폴딩을 실행한다.
5. 분기 A — 전량 성공: 워크스페이스가 생성되고 applied_bricks에 최초 스캐폴딩 brick이 기록된다. allowed_hosts·write_exceptions가 비어 있지 않은 유효한 값으로 초기화된다(FR-106 / AC-14).
6. 분기 B — 진행 중 실패: 부분 생성된 파일이 전량 제거되고, 워크스페이스는 생성되지 않은 상태로 남는다(FR-102 / AC-13). 중간 상태의 워크스페이스는 남지 않는다.

✅ 미결 A 해소: 분기 B 의 실패 사유 제시 형태는 ux-spec UX-D-23 이 정했다 — 폐쇄 사유 코드 + 고정 라벨 + 「아무것도 만들어지지 않았다」 고정 문구이며, 코드에 없는 원인은 문장을 지어내지 않고 자리표시자를 그린다(#41). ✅ 미결 B 해소: "진행 중 실패"는 D-049 가 위치로 정의했다 — [첫 스테이징 쓰기, 커밋 완료). 그 이전의 종료는 분기 B 가 아니라 착수 전 거부다(#41). 미결 C: 분기 A 시점의 edit_locks 초기값을 근거 문서가 규정하지 않는다 → D-17.

흐름 2 — 비동기 위임 → 자가 검증 → 완료

전제: 이 작업의 completion_mode가 자가검증인 경우. AC-17·C-04 전환 조항은 새 작업의 completion_mode 기본값만 규정한다 — Planning이 A-02 합격 기준을 정하지 않았거나 검증이 미수행·미달이면 기본값이 사람승인이 되어 새 작업은 기본적으로 흐름 3으로 간다. 사용자가 개별 작업에서 이 기본값을 뒤집을 수 있는지는 스펙 미규정이다(D-18).

1. 사용자가 prompt와 백엔드(agent_backend_kind / agent_backend_provider)를 지정해 작업을 생성한다 → 대기.
2. 작업이 시작된다 → 실행중. 사용자는 이 시점에 자리를 비울 수 있다(C-04 비동기 위임).
3. 에이전트가 파일을 편집할 때 그 경로의 잠금이 필요하다. 이미 다른 작업이 잠근 파일이면 그 작업이 해당 파일의 편집을 마칠 때까지 대기한다(FR-204 / AC-12). (잠금 획득 시점은 편집 시도 시점으로 확정됐다 — D-045/#76. 「작업 시작 시 일괄 예약」은 그 시점에 편집할 파일 집합의 출처가 어느 문서에도 없어 성립하지 않는다.)
4. 편집 1건마다 EditSnapshot이 생성된다 — file_path, diff, base_content_hash, timestamp, sequence_no(FR-501 / C-02). EditSnapshot 없는 편집 경로는 없다.
5. 에이전트가 그 파일의 편집을 마치면 그 시점에 잠금이 해제된다(FR-205). 마침의 판정 기준은 확정 — 그 편집의 게이트 연산이 반환하는 순간이다(D-045/#76, D-14 후보 ③).
6. 편집 중 기존 테스트 파일 변경이 발생하면 → 흐름 3-B로 분기한다(FR-404 / AC-11). completion_mode와 무관하다.
7. 에이전트가 편집을 마치면 → 자가검증중. C-04 ①~⑤ 중 해당 편집에 적용 가능한 방법을 수행하고 결과를 verification_log에 기록한다. ③의 관찰 창·⑤의 정본 파서·"새로운 오류"의 기준선은 미결(D-12).
8. 분기 A — 적용 가능한 방법 1종 이상 통과: → 완료(FR-302 / AC-09). ⑤로 완료한 경우 ①~④ 각각의 적용 불가 사유가 폐쇄 코드로 verification_log에 남는다(FR-303).
9. 분기 B — 검증 실패: retry_count가 증가하고 재시도한다. retry_count가 3을 초과하면 → 실패 + 사람 에스컬레이션(FR-304 / AC-07) → 흐름 5.
10. 분기 C — 단일 시도가 시간 상한 초과: 시도가 중단되고 → 실패(FR-305 / 불변식 4) → 흐름 5.
11. 분기 D — 프로바이더/ACP 에이전트 응답 불가 감지: → 실패로 전이하고 사유가 제시된다. 무한 대기하지 않는다(FR-605 / AC-20 ∩ 불변식 1·2·5). 감지 기준은 미결(D-3).
12. 완료 이후에도 사용자는 작업을 열어 전체 diff를 보고 롤백할 수 있다(흐름 4).

미결 A: 재시도가 어느 상태로 되돌아가는지(실행중 / 자가검증중)를 스펙이 규정하지 않는다 → Design. 미결 B: AC-08 본문은 "시도가 중단되고 실패로 기록된다"이고, §3 DelegatedTask 불변식 4는 "'실패'로 전이하고 사람에게 에스컬레이션한다"이다. 위 10번은 불변식 쪽을 따랐다(전이 규칙의 정본은 §3). 두 문장의 범위 차이를 Design이 명시적으로 해소해야 한다.

흐름 3 — 사람 승인 모드

3-A. 완료 승인 (pending_approval_kind=완료승인)

전제: 이 작업의 completion_mode가 사람승인인 경우. AC-17에 따라, Planning이 A-02 합격 기준을 정하지 않았거나 검증이 수행되지 않았으면 이것이 새 작업의 기본값이다.

1. 작업 생성 → 대기 → 실행중.
2. 편집 + EditSnapshot 기록은 흐름 2의 3~5단계와 동일하다.
3. 에이전트가 편집을 마치면 → 자가검증중. 자가 검증은 수행되지만 완료의 관문이 아니다(FR-307 / 불변식 2).
4. → 사람승인대기, pending_approval_kind=완료승인(FR-306 / AC-10).
5. 사용자에게 변경된 모든 파일의 diff(AC-01)와 verification_log의 자가 검증 결과가 정보로서 제시된다.
6. 분기 A — 사용자가 명시적으로 승인: → 완료.
7. 분기 B — 사용자가 롤백을 요청: → 흐름 4 → 롤백됨(FR-508 / 불변식 5).
8. 승인도 롤백도 없으면 작업은 사람승인대기에 머문다. 사용자의 명시적 승인 없이는 "완료"에 도달하지 않는다(AC-10).

✅ 해소 (2026-09-13 · D-032 + D-057 + D-058) — ⓐ status 폐쇄 집합에 거부됨 이 신설됐고(D-032 / seed v3.3.0, AC-23), 거부 전이는 사람승인대기 → 거부됨 이다(D-057 §1). ⓑ 승인도 롤백도 없는 무응답에는 시간 상한을 두지 않는다 — 승인 대기는 리스를 해제해 자원을 점유하지 않고 출구가 거부·롤백으로 둘 열려 있다(D-057 §2). ⓒ 같은 입력의 중복 도착은 no-op 으로 흡수된다(D-058 / FR-405·FR-407). 상세: docs/approval-rules-cocode.md · docs/approval-idempotency-cocode.md.

3-B. 테스트 변경 승인 (pending_approval_kind=테스트변경승인)

completion_mode와 무관하게 적용된다.

1. 에이전트가 기존 테스트 파일의 내용을 변경하려 한다.
2. 변경을 적용하기 전에 → 사람승인대기, pending_approval_kind=테스트변경승인(FR-404 / AC-11, 불변식 3).
3. 시스템은 파일 내용을 읽거나 변경의 성격을 분류하지 않는다 — 경로 술어에 걸린 파일에 대한 모든 변경이 대상이다(FR-403 / AC-11).
4. 새 테스트 파일 생성은 이 경로를 타지 않는다 — 유일한 예외다(FR-401 / AC-11).
5. 분기 A — 승인: 변경이 적용된다.
6. 분기 B — 미승인: 변경이 적용되지 않는다.

✅ 해소 (2026-09-13 · D-057 §3.2 · D-058) — 테스트변경승인 «승인» 후에는 변경을 적용하고 항상 실행중 으로 복귀한다(테스트 대상이 바뀌었으므로 자가 검증을 처음부터 다시 탄다. retry_count 는 증가하지 않는다). «미승인» 은 부작위가 아니라 [적용하지 않음] 거부 입력이며 거부됨(종결)으로 간다(D-058 §2 / FR-407). pending_approval_kind 리셋은 엔티티 생성자가 강제한다. 미결 B: 경로 술어의 구체값과 그 확정 주체 — 아래 §4 D-1 참조. 술어가 서면 3-B는 판정 없이 기계적으로 적용된다.

흐름 4 — diff 검토 → 롤백 (충돌 포함)

1. 사용자가 작업을 화면에서 연다 → 변경된 모든 파일의 diff가 표시된다(FR-503 / AC-01). 작업이 실패 상태여도 동일하다(FR-509 / AC-19).
2. 사용자가 롤백 지점을 고른다 — 특정 EditSnapshot 또는 작업 시작 직전 상태(FR-504 / AC-02).
3. 시스템이 되돌릴 집합을 산출한다.
   • 특정 snapshot 지정 시: 같은 작업에서 그 이후 생성된 모든 EditSnapshot(EditSnapshot 불변식 3).
   • 작업 시작 직전 지정 시: 그 작업의 모든 EditSnapshot. 각 파일은 그 파일에 대한 **최소 sequence_no를 갖는 EditSnapshot의 base_content_hash**가 가리키는 내용으로 복원된다(FR-507 / 불변식 4).
4. 시스템이 대상 파일 각각의 현재 내용 해시를 base_content_hash와 대조한다.
5. 분기 A — 전부 일치: 원자적으로 적용된다(전부 적용). → 롤백됨(FR-508 / 불변식 5).
6. 분기 B — 하나라도 불일치(= 사람이 그 사이에 직접 편집함): 자동 적용하지 않고 충돌로 제시한다(FR-506 / EditSnapshot 불변식 2). 부분 적용은 발생하지 않는다 — 원자성의 근거는 AC-02로, 두 롤백 경로("특정 스냅샷 또는 작업 시작 직전 상태")를 모두 덮는다. EditSnapshot 불변식 3은 특정 snapshot 경로에만 범위가 걸려 있으므로 단독 근거로 쓰지 않는다.

미결: 충돌 제시 이후 사용자에게 어떤 선택지를 주는지(강제 적용 / 파일별 처리 / 취소)는 근거 문서에 규정이 없다 → Design. 단 어떤 선택지를 두더라도 AC-02의 원자성과 EditSnapshot 불변식 2의 "자동 적용하지 않는다"를 깨서는 안 된다.

흐름 5 — 실패 · 에스컬레이션

진입 경로 (Seed Spec이 "실패" 또는 종결 상태 전이를 규정한 것):

1. E-1 / E-2 → 실패로 전이하고 사람에게 에스컬레이션한다(불변식 4). 그 이상 자동 재시도하지 않는다(AC-07).
2. E-3 → 실패로 전이하고 사용자에게 사유가 제시된다. 무한 대기하지 않는다(AC-20).
3. "실패"는 종결 상태이므로 더 이상 자동으로 전이하지 않는다(§0 용어집).
4. 사용자가 작업을 열면 그때까지 적용된 편집의 diff와 롤백 수단이 제공된다(FR-509 / AC-19).
5. 편집은 조용히 폐기되지도, 조용히 확정되지도 않는다(AC-19). 즉 실패 시점의 편집 처분은 사용자의 명시적 선택을 기다린다. "조용히"의 판정 기준은 미결(D-15).
6. 분기 A — 사용자가 롤백 요청: → 흐름 4 → 롤백됨.
7. 분기 B — 사용자가 편집 유지: 작업은 실패 상태로 남고 편집은 워크스페이스에 남는다.

별도 경로 — 에이전트 프로세스 비정상 종료: 그 작업이 보유하던 파일 잠금은 해제되어 있어야 하고, 다른 작업이 해당 파일을 편집할 수 있다(FR-207 / AC-18).

미결 A: AC-18은 잠금만 규정하고, 비정상 종료한 작업 자신의 status를 규정하지 않는다 → Design. 미결 B: 무엇을 "비정상 종료"로 감지할지의 기준이 없다 → D-13.

3. 데이터 모델 초안

Seed Spec §3의 3개 엔티티를 요약·재기술한 것이다(원문 축약과 부연이 섞여 있으므로 정본은 항상 docs/seed-spec-cocode.md §3이다). §3 머리말은 *"After locking, only additions are allowed (existing entities cannot be modified)"*라고 규정하지만, 문서가 아직 DRAFT이므로 잠금은 발생하지 않았다.

3.1 Workspace

관계: N개의 brick으로부터 스캐폴딩·확장됨 · N개의 DelegatedTask를 가짐.

불변식(§3 원문 3개 — 직접 계수): ① Dart/Flutter 프로젝트 구조를 벗어난 워크스페이스는 지원 대상이 아니다(C-03) ② 동일 파일 경로를 두 개 이상의 DelegatedTask가 동시에 편집할 수 없으며, 잠금은 에이전트가 그 파일의 편집을 마치는 시점에 해제되고 승인 대기 중에는 유지하지 않는다 ③ 스캐폴딩이 부분 실패한 워크스페이스는 생성되지 않는다.

3.2 DelegatedTask

관계: 1개의 Workspace에 속함 · N개의 EditSnapshot을 생성함.

불변식 (§3 원문 5개 — 직접 계수):

1. completion_mode=자가검증에서 "완료" 전이 조건 — C-04의 적용 가능한 방법 1종 이상 통과 + verification_log 기록. ⑤ 사용 시 ①~④ 적용 불가 사유 기록.
2. completion_mode=사람승인에서는 자가 검증 결과와 무관하게 "사람승인대기"(완료승인)로 전이. 명시적 승인 없이 "완료" 불가.
3. completion_mode와 무관하게, 기존 테스트 파일 변경 포함 작업은 적용 전 "사람승인대기"(테스트변경승인)로 전이(C-05).
4. retry_count > 3 또는 단일 자가 검증 시도의 시간 상한 초과 → "실패" 전이 + 사람 에스컬레이션(C-04).
5. "롤백됨" 전이는 사용자의 명시적 롤백 요청으로만 발생.

종결 상태 = 완료 · 실패 · 롤백됨 (§0 용어집 — "더 이상 자동으로 전이하지 않는 것").

3.3 EditSnapshot

관계: 1개의 DelegatedTask에 속함.

불변식 (§3 원문 4개 — 직접 계수):

1. 에이전트의 모든 파일 편집은 대응하는 EditSnapshot 없이 존재할 수 없다(C-02).
2. 롤백 시 현재 내용 해시 ≠ base_content_hash이면 자동 적용하지 않고 충돌로 제시.
3. 특정 snapshot으로의 롤백은 그 이후 생성된 모든 EditSnapshot을 함께 되돌리며 원자적이다.
4. "작업 시작 직전 상태" 복원 = 각 파일에 대한 최소 sequence_no EditSnapshot의 base_content_hash가 가리키는 내용.

3.4 모델 수준의 미확정 사항 (Design 결정)

4. Seed Spec이 Design에 남긴 결정 (해결하지 않고 이관)

docs/spec-evaluation-cocode.md §판정과 권고의 세 번째 전제(141행, "판정 주체가 미정인 3건은 설계 결정으로만 풀린다 — '테스트 파일'의 정의(C-05·AC-11), 자가 검증 ①~④의 '적용 불가' 판정 규칙(AC-09·C-04 ⑤), 프로바이더 응답 불가의 감지 기준(AC-20). Design 단계에서 이 셋을 정하면 관련 AC가 비로소 기계적으로 판정 가능해진다.")가 D-1~D-3이다.

ℹ️ 인용 방식 주의. 해당 절은 원문에서 번호가 깨져 있다(1 · 2 · 3 · 3 · 4 — '3.'이 두 번). 서수 대신 인용문과 행 위치로 지시한다.

4.1 근거 문서에 규정이 없어 흐름 정의가 막히는 지점

아래는 §1~§3에서 표시한 미결을 모은 것이다. 위 8개 문서를 읽고 규정을 찾지 못한 항목이다.

이 목록을 "전수"라고 주장하지 않는다. 위 8개 문서를 전문 읽고 확인한 범위의 것이며, 이 문서들의 후속 개정이나 다른 문서에 규정이 있을 수 있다. 초기 판본이 근거 문서를 6종으로 좁혔던 것은 오류였고, 그 결과 실제 규정 1건(스냅샷 보존 정책 — Contrarian CH-022)을 '규정 없음'으로 잘못 분류했었다.

4.2 Planning/Design이 함께 인수한 위험 5건 (이관)

spec-evaluation §판정과 권고 143행은 Planning 진행의 전제 중 하나로 *"잔여 위험 인수 항목 5건(CH-009·CH-003·CH-008·CH-022·CH-035)은 Contrarian 보고서에 재검토 시점과 함께 기록되어 있다"*를 든다. 이 절은 미결이 아니라 해소되지 않은 채 의도적으로 안고 가는 것이므로 별도로 옮긴다.

비기능 요구사항과 측정 계획

Seed Spec v3.0.2 §4 서문이 규정하는 것은 "근거 없는 임계값·측정 환경·픽스처는 담지 않고 docs/planning-inputs-cocode.md를 거쳐 Planning 단계의 BDD 인수 조건이 된다"이다(seed-spec 99행). 값을 전부 배제한다는 뜻이 아니라 출처표에 근거가 있는 값만 담는다는 뜻이다 — 실제로 §4 는 근거가 확인된 값을 담고 있다(AC-15 의 픽스처 10만 줄, AC-06 의 2개 이상, C-04·AC-07 의 재시도 3회). 서문이 내보낸 것 — 근거가 아직 없는 임계값·측정 환경·픽스처 — 을 채우는 것이 이 절이다.

단 이 절도 값을 만들어 내지 않는다 — 값이 없는 항목에는 값 대신 "누가·언제·무엇을 보고 정하는가"를 적는다.

재도입 금지 값 (값별 전거)

이 프로젝트는 값을 지어내 요구사항 층위에 잠그는 실패를 반복했다. 전거가 값마다 다르므로 뭉뚱그리지 않는다.

제거 시점: 30건·80%·10분은 v2.0.0(D-015 Impact "지어낸 수치 6개 제거"), 150MB·2초·400MB 는 v1.2.0(D-013). spec-evaluation "반복된 실패 패턴" 1번이 같은 목록을 재확인한다.

패턴의 범위를 정확히 적는다. "값을 지어내 잠근다"가 반복된 구간은 v1.1.0~v2.1.0 이며, §4 의 출처 없는 수치가 0 이 된 것은 v3.0.0 이 처음이다(spec-evaluation 개정 이력 5행 — "§4 출처 없는 수치 최초 0건"). 8 라운드 내내 독립 감사로 확인된 것은 값 생성이 아니라 "지적된 항목은 고쳐지지만 같은 결함 유형의 새 사례가 생긴다" 는 패턴이다(같은 문서 "개정을 멈춘 이유" 1번).

재인용 경로가 아직 열려 있다. 폐기된 값들은 Contrarian 보고서에 폐기 주석 없이 남아 있다 — CH-033 Response 는 p95 16.7ms 를 "측정 가능한 기준"으로, "적대적 감사 이력"은 10분 을 NFR-05 로, CH-034·CH-035 는 NFR-03 을 합격 기준으로 기술한다. ⚠️ 주석을 받은 것은 CH-011/CH-030 뿐이다. 그 문서 머리말이 "시점별 판정 기록"임을 명시하지만, 이 절은 그 문서에서 어떤 수치도 가져오지 않는다(아래 R-4).

값 확정 절차 (다섯 항목 공통)

이 절이 제안하는 규칙 — 판정이 필요 없는 형태로 적는다.

확정 주체는 Planning 이다. Seed Spec 이 이 절의 다섯 항목 전부에 대해 그렇게 규정한다 — AC-15 "프레임 타임 임계값과 측정 환경은 Planning이 확정한다", AC-16 "플랫폼별 검증 시점과 입력기·코퍼스 지정은 Planning이 확정한다", A-02 "표본 수와 합격 기준은 Planning이 확정", A-06 "…Planning이 목표치를 확정", C-05 "어떤 파일이 테스트 파일인지는 … Planning 이 확정한다". planning-inputs §1 표의 6행은 Planning 입력으로 미리 내려온 프로젝트 오너 결정의 기록 형식이지, 이 다섯 항목의 확정 주체를 오너로 바꾸는 근거가 아니다. 시점 원칙만 D-020 이 규정한다 — "실측 분포를 보기 전에 숫자를 정하면 같은 패턴이다."

NFR-A 성능 — 에디터 코어 (AC-15 / A-03)

무엇을 재는가. AC-15 의 관찰 조건은 "조작이 입력한 순서대로 반영되고 화면이 응답하지 않는 구간이 발생하지 않는다"이다. 값이 필요한 것은 planning-inputs §3.3 이 열거한 5개다: 프레임 타임 목표치 · 백분위 · 측정 환경(빌드 모드·하드웨어 등급·플랫폼) · 시나리오(스크롤 속도·조작 종류) · 표본 창.

어떤 환경에서. 문서가 지정하는 대상이 둘인데 서로 다르다.

• AC-15 의 픽스처는 10만 줄 규모의 Dart 파일이다(출처: Discovery 문서가 인용한 설계 노트 로드맵 1단계 검증 시나리오 — Seed Spec 출처표; 원 기재는 Discovery 34행·112행).
• planning-inputs §3.1 의 참조 워크스페이스 추천은 coco-de/unibook 이다 — Dart 파일 9,931개(~55.8MB), git 추적 생성 파일 712개, workspace: 멤버 141개.
• docs/ 8개 문서 전체 grep 결과 unibook 과 "10만 줄"이 함께 언급된 곳은 0건이다 — unibook 에 10만 줄짜리 단일 Dart 파일이 있는지는 어디에도 기록되어 있지 않다.

둘은 대체재가 아니라 둘 다 필요한 시나리오였다. Contrarian CH-032(Major)가 "단일 10만 줄 파일 테스트는 실제 병목(다수 생성 파일 동시 오픈)을 놓칠 수 있음" 을 지적했고, 해소책은 "A-03 검증 방법을 '단일 대용량 파일 + 다수 생성 파일 동시 오픈 두 시나리오 모두'로 수정" 이었다. 현행 v3.0.2 A-03 검증 방법에는 그 두 시나리오 요구가 남아 있지 않다 — v2.0.0/v3.0.0 재작성 과정에서 유실됐다(아래 미결 1). 따라서 두 픽스처는 별개로 취급하되, 어느 하나를 다른 하나로 대체하지 않는다.

§3.2 는 채택 시 처리할 항목을 다섯 개 요구한다. 그중 넷은 무조건 적용된다.

다섯 번째는 조건부다: .freezed.dart 가 org 전체에 0개이므로, freezed 생성 파일 시나리오가 필요하면 별도 픽스처를 만들어야 한다(§3.2).

판정이 필요 없는 규칙(제안). 측정 대상은 (커밋 SHA, 디렉터리 경로, 파일 경로) 3-튜플로 적는다. 세 값이 기록되지 않은 측정치는 목표치 확정의 근거로 인용하지 않는다(R-1).

누가 언제 정하는가. AC-15 본문이 "Planning 이 확정한다"고 규정한다. 시점은 A-03 스파이크(로드맵 1단계)의 실측 분포가 나온 뒤라는 것이 이 절의 제안이며, 근거는 D-020 의 원칙("실측 분포를 보기 전에 숫자를 정하면 같은 패턴이다")이다 — planning-inputs 는 §3 에서 시점을 규정하지 않는다. SHA 지정만은 측정보다 앞선다(고정 없이는 재현이 성립하지 않으므로).

미정일 때의 기본 동작. AC-15 본문의 관찰 조건이 그대로 판정 기준으로 남는다 — v3.0.1 ②가 동어반복 Then 을 관찰 가능한 실패 조건으로 교체했기 때문이다(Seed Spec Evolution Log v3.0.1 ②). 단 완전한 무판정은 아니다: 어느 길이의 정지부터 "응답하지 않는 구간"인지 임계값이 없어 관찰자 판정이 남으며, AC-15 자신이 "프레임 타임 임계값과 측정 환경은 Planning이 확정한다"를 덧붙인 이유가 그것이다. A-03 은 MVP 게이팅 리스크이며, 실패 시 분기는 "자체 렌더링 텍스트 레이어 검토"로 이미 지정되어 있다(Seed Spec §5 A-03). SHA 미지정 상태의 측정치에 대한 안전 기본값은 없다 — R-1 과 위 3-튜플 규칙이 그 공백을 메우는 장치다.

NFR-B 한글 IME (AC-16 / A-04)

무엇을 재는가. AC-16 의 실패 조건 3종 — 조합 중 글자 깨짐 · 중복 입력 · 커서 위치 오류 — 를 에디터와 터미널 양쪽에서, MVP 대상 3개 플랫폼 각각에서 관찰한다.

확정 대상 항목의 수를 정확히 적는다. planning-inputs §4.3 은 다섯을 열거한다: ①플랫폼별 입력기 지정(Linux 는 ibus/fcitx 중 무엇인지, 배포판 고정) ②입력 코퍼스(어떤 자모 시퀀스) ③시행 횟수 ④관찰 방법 ⑤Windows·Linux 검증이 출시 조건인지 아닌지. 그러나 §4.3 바로 아래 ⚠️ 주석이 ⑤를 Planning 소관에서 제외한다(아래 인용). 따라서 Planning 이 확정할 것은 ①~④의 네 개다. 별도로 AC-16 본문은 "플랫폼별 검증 시점"도 Planning 소관으로 지정한다 — D-016 이 1단계 순서를 정했을 뿐 Windows·Linux 의 검증 시점 자체는 여전히 미정이다.

어떤 환경에서 — 순서가 이미 규정되어 있다.

1. 재현 확인이 먼저다. 자체 구현 전에 xterm2/flutter_pty2 재사용 컴포넌트에서 Lumide 이슈 #64(2026-07-29 등록, 미해결)와 동일한 결함이 재현되는지 확인한다(§4.2).
2. 1단계 게이팅 스파이크는 macOS 만. 통과 후 Windows(MS-IME) → Linux(ibus/fcitx) 순차(§4.1, D-016).

판정이 필요 없는 규칙(제안). 두 가지를 저장소에 커밋된 파일로 고정한다.

• 입력 코퍼스 — 시행 때마다 무엇을 입력할지 사람이 고르지 않는다.
• 관찰 산출물 — "글자 깨짐·중복 입력·커서 위치 오류"는 눈으로 보면 판정이 갈리므로, 각 시행의 결과를 입력 후 버퍼 텍스트 덤프 + 커서 오프셋 정수값으로 기록하고 기대값 파일과 바이트 단위로 비교한다. 스크린샷은 보조 증거이지 판정 근거가 아니다.

둘 다 고정되지 않으면 macOS 결과와 Windows·Linux 결과를 비교할 근거가 없다.

누가 언제 정하는가. Planning 이 확정하되 범위가 좁다. planning-inputs §4.3 의 경고를 그대로 옮긴다 — "Seed Spec AC-16은 이미 3개 플랫폼 전부를 Must로 규정한다 … 따라서 위 'Windows·Linux 검증이 출시 조건인지 아닌지'는 Planning이 자유롭게 정할 수 있는 사항이 아니다 — AC-16을 완화하려면 Seed Spec 개정이 필요하다. D-016이 정한 것은 게이팅 스파이크의 순서(macOS 먼저)이지 출시 조건의 축소가 아니다. Planning이 확정할 것은 각 플랫폼의 입력기·코퍼스·시행 방법에 한정된다." 확정 시점은 macOS 스파이크 착수 전이라는 것이 이 절의 제안이다(코퍼스·입력기·관찰 산출물이 정해지지 않으면 그 결과를 나머지 두 플랫폼과 비교할 수 없다). 담당자·기한은 이 절의 소관이 아니다 — Contrarian CH-035 가 "담당자·기한은 Planning/Breakdown 단계에서 이슈로 배정될 사항" 으로 부분 해소·위험 인수로 분류하고 재검토 시점을 Breakdown 단계로 기록했다.

미정일 때의 기본 동작. 범위 쪽은 안전하다 — AC-16 이 이미 3플랫폼 Must 이므로 미정이 축소로 흐르지 않는다. 반대로 입력기·코퍼스·관찰 산출물이 미정이면 "통과"를 선언할 근거가 없으므로 A-04 는 Unverified 로 남는다(반증 사례 있음, MVP 게이팅 리스크 — Seed Spec §5 A-04). 즉 미정의 귀결은 "완화"가 아니라 "미검증 유지"다.

NFR-C 샌드박스 (AC-14)

무엇을 재는가. AC-14 는 Then 절에서 ⓐ(경로 — write_exceptions 밖 파일 미수정)와 ⓑ(호스트 — allowed_hosts 밖 요청 미발신)를 규정한 뒤, 이 기준의 대상을 따로 못박는다: "두 목록이 비어 있지 않은 유효한 값으로 초기화되어 있고 위반 시도가 차단되는 것이 이 기준의 대상이며, 목록의 구체적 내용은 설정이다." 즉 판정 대상은 ①초기화 여부와 ②차단 여부 두 가지이며 — AC-14 자신의 ⓐ/ⓑ 기호와 혼동하지 않도록 여기서는 ①②로 적는다 — 임계값이 필요 없는 이진 관찰이다.

단 "완성"은 아니다. AC-14 의 판정에는 임계값이 필요 없지만, 이 절이 완성할 수 있는 것은 초기 목록 대조와 함정 회귀 테스트까지다. 의존성 파생분(§2.5)과 ACP 에이전트 캐시 경로(§2.4 주석)는 여전히 열려 있다.

초기 목록의 내용은 이미 실측으로 확보되어 있다(Flutter 3.47.0 기준 실측 — planning-inputs §2 머리말, D-018).

§2.2 의 함정 3종은 값이 아니라 시나리오이므로 지금 회귀 테스트로 고정할 수 있다: ①services.gradle.org → release-assets.githubusercontent.com 307 체인 ②plugins.gradle.org → plugins-artifacts.gradle.org 303(때로 repo.maven.apache.org) ③Gradle google() 의 실제 대상은 dl.google.com/dl/android/maven2/(조사 머신 origin 인덱스 dl.google.com 3,060건 / maven.google.com 0건).

어떤 환경에서.

• 플랫폼별 부분집합으로 잰다 — 판정이 필요 없는 형태로. §2.1 주석은 "Linux 데스크톱 전용 빌드는 Android/iOS 호스트가 불필요하다 … 구현은 프로젝트가 실제로 타겟하는 플랫폼에 따라 부분집합을 적용해야 한다" 고 서술하는데, 어느 행이 어느 플랫폼에 속하는지는 §2.1 표의 '플랫폼' 열이 이미 정해 놓았다. 따라서 규칙은 "대상 플랫폼으로 §2.1 표의 플랫폼 열을 필터한 행 집합"이며 사람의 선별이 개입하지 않는다.
• "유효한 값"의 판정도 같은 방식으로 좁힌다. AC-14 의 "비어 있지 않은 유효한 값"은 그대로 두면 판정이 갈리므로, 초기화 검사를 "위 필터 결과의 모든 행이 allowed_hosts 에 들어 있는가" 라는 대조 검사로 정의한다.
• 경로는 환경변수를 존중한다 — PUB_CACHE·GRADLE_USER_HOME·CP_HOME_DIR·ANDROID_HOME(§2.4). 하드코딩된 경로를 전제한 측정은 무효다.
• 표가 덮지 않는 영역이 있다. §2.4 주석: "호스팅되는 ACP 에이전트(Claude Agent·Codex·Gemini CLI·Copilot CLI)도 자체 설정·캐시 경로를 쓴다. 이들의 경로는 Design 단계에서 각 에이전트를 실제로 띄워 확인해야 한다 — 위 표는 Flutter 빌드 툴체인만 다룬다."

누가 언제 정하는가. 미정인 것은 목록이 아니라 의존성 호스트 추출 알고리즘이다(§2.5, §6). Planning 이 확정할 세 가지: 추출 대상 매니페스트 범위(pubspec.yaml 만인지 pubspec.lock·Podfile.lock·dependency_overrides 까지인지) · 전이 의존성 포함 여부 · 매니페스트 변경 시 재계산 시점. §2.5 의 경고: "이것이 정해지지 않으면 두 구현이 서로 다른 허용 집합을 만든다." ACP 에이전트 4종의 캐시 경로는 Design 단계에서 실측한다(§2.4 주석).

미정일 때의 기본 동작 — fail-closed. allowed_hosts 는 "기본 목록·의존성 파생분·사용자 추가분의 합"으로 정의된다(Seed Spec Workspace 속성). 추출 알고리즘이 없으면 파생분이 비고 §2.1 기본 목록 + 사용자 수동 추가분만 남는다. 결과적으로 git: 의존성(gitlab·bitbucket·사내 호스트)이나 podspec 외부 소스를 쓰는 워크스페이스는 그 호스트가 차단된 채 빌드가 막힌다(§2.5). 목록이 비어 있지 않으므로 AC-14 위반은 아니고, 실패 방향이 "차단"이므로 안전한 쪽이다 — 다만 사용자에게는 수동 추가가 강제된다.

NFR-D 용량·기동 (A-06)

무엇을 재는가. 지표 3종 — 설치 용량 · 콜드 스타트 · 메모리 사용량(Seed Spec A-06, 출처표).

참조점이 한 지표에만 있다. Lumide 0.20.0 의 설치 55.8MB(버전은 Discovery 머리말 3행, 용량은 Discovery ### Key Insights 1번 — Seed Spec 출처표가 두 위치를 분리 기재)뿐이다. 콜드 스타트와 메모리에는 참조점이 없다 — docs/ 8개 문서 전체에 콜드 ?스타트|cold start|메모리|기동 을 grep 하면 히트는 넷뿐이고(A-06 본문, 출처표의 지표 열거, planning-inputs §6, D-013), 그 두 지표에 붙은 유일한 수치는 D-013 이 "작성자(Claude)가 추정으로 만들어낸 것이며 사용자가 제시한 값이 아니다" 라고 기록하며 제거한 2초/400MB 다. 따라서 두 지표는 참조점 없이 실측 분포부터 만들어야 한다.

55.8MB 를 인용할 때 두 가지 함정이 있다.

1. 같은 수가 두 번 나온다. planning-inputs §3.1 의 unibook Dart 소스 총량도 ~55.8MB 이며, §3.1 은 이를 "무관한 값이 우연히 일치한 것" 이라고 표기한다. Seed Spec 출처표도 같은 사실을 "서로 무관한 값이며 복사 오류가 아니다" 로 기록한다(v3.0.1 ⑩이 양쪽에 넣은 표기). 섞어 쓰지 않는다.
2. 비교 대상이 다르다. D-013: "cocode ADE는 자체 에이전트 런타임을 포함하므로 그 값을 그대로 목표로 삼을 근거가 없다." 55.8MB 는 하한 참조점이지 목표가 아니다.

어떤 환경에서. "최소 셸 조립 후 세 지표를 실측"(A-06 검증 방법, 로드맵 1단계). 두 가지가 미정이며 측정 전에 정해야 한다.

• 플랫폼 분리 여부 — C-01 이 배포 대상을 macOS·Windows·Linux 3종으로 규정하므로 지표가 플랫폼마다 갈릴 수 있다. 3종 각각 재는지, 하나를 대표로 삼는지는 Planning 이 정한다.
• "설치 용량"의 정의 — 비교 대상인 Lumide 값은 Discovery ### Key Insights 1번에 "설치 55.8MB"로만 적혀 있고, 그것이 배포 아카이브 크기인지 설치 후 디스크 점유인지는 기록되어 있지 않다(원문 직접 확인). 비교하려면 같은 정의를 써야 하므로 정의부터 확정한다.

누가 언제 정하는가. Planning — A-06 검증 방법("…그 결과와 Lumide 실측치(55.8MB)를 근거로 Planning이 목표치를 확정")과 planning-inputs §6("최소 셸 조립 후 실측하고 Lumide 55.8MB를 참조점으로 확정")이 일치한다.

미정일 때의 기본 동작 — 안전 기본값이 없다. A-06 은 §5 의 가정이며, Seed Spec §4 의 AC-01~AC-20 중 설치 용량·기동·메모리를 다루는 항목은 없다(AC 행 20개에 용량|기동|스타트|메모리 grep → 매치 0). 즉 목표치가 미확정이어도 출시를 막는 장치가 없고, C-04 전환 조항 같은 자동 강등도 걸려 있지 않다. 이것이 현재 상태다.

선택지는 둘이며 이 절은 어느 쪽도 임의로 고르지 않는다: ⓐ 게이트 없이 진행(현 상태 유지) ⓑ 게이트를 원하면 Seed Spec §4 에 AC 를 추가하는 개정이 필요하다. 지금 값을 만들어 넣는 것은 D-013 이 이미 한 번 되돌린 실패이므로 선택지가 아니다.

NFR-E 자가 검증 신뢰도 (A-02 / C-04 전환 조항)

무엇을 재는가. A-02 검증 방법이 두 검출률의 분리 측정을 명시한다.

• ⓐ 제3자가 주입한 결함의 검출률
• ⓑ 에이전트 자신이 만든 결함에 대한 검출률

"(Contrarian 보고서 CH-030의 내생적 실패 모드는 ⓐ로 측정되지 않는다)" — A-02 원문. ⓐ만 재고 합격을 선언하면 D-014 가 지목한 실패 모드(에이전트가 변경과 그 검증을 모두 작성하면서 검증이 통과하도록 모양을 맞추는 것)를 그대로 통과시킨다.

함께 재야 할 것(제안). C-04 ⑤(편집 대상 파일의 무결성 확인)로 완료된 작업의 비율. AC-09 가 ⑤ 사용 시 ①~④ 각각의 적용 불가 사유를 verification_log 에 남기도록 이미 강제하므로, 그 로그 자체가 측정 자료다. ⚠️ 다만 비율은 셀 수 있어도 "⑤가 실질적 우회로인가"는 지금 판정되지 않는다 — ①~④ 의 "적용 불가" 판정 규칙 자체가 미정이며, spec-evaluation 이 이를 판정 주체가 미정인 3건 중 하나로 지목한다(C-05 의 "테스트 파일" 정의, AC-09·C-04 ⑤의 "적용 불가" 판정, AC-20 의 "감지" 기준). 이 지표는 AC-09 판정 규칙이 Design 에서 정해진 뒤에야 해석 가능하다.

미정인 값. 표본 수 · 합격 기준 · ⓑ에서 "에이전트가 만든 결함"으로 셀 대상의 정의(A-02, D-020, planning-inputs §1·§6). 앞의 둘은 문서에 미정으로 기록돼 있고, 셋째는 어디에도 기록이 없으므로 Planning 확정 대상으로 새로 세운다. 재도입 금지 값: v2.0.0 이 제거한 결함 30건·검출률 80% 는 지어낸 수치다(D-015 Impact, spec-evaluation "반복된 실패 패턴" 1번; Contrarian CH-011/CH-030 아래 ⚠️ 폐기 주석).

어떤 환경에서.

• Design 단계 이전 스파이크(A-02 검증 방법).
• 선행 의존이 둘 있다. ⓑ 실험은 C-05 의 "어떤 파일이 테스트 파일인가"가 정해져야 재현되고(C-05 본문: "프로젝트의 테스트 디렉터리 규약을 따르며 Planning 이 확정한다"), ⑤ 비율 지표는 AC-09 의 "적용 불가" 판정 규칙에 의존한다. spec-evaluation 은 둘 다 "판정 주체가 미정인 3건" 에 넣고 "문구를 고쳐 정해지지 않고 설계 결정으로만 정해진다" 고 판정했다("개정을 멈춘 이유" 3번; "판정과 권고"의 "판정 주체가 미정인 3건은 설계 결정으로만 풀린다" 항목).

누가 언제 정하는가. 표본 수·합격 기준은 Planning 이 확정하되(A-02), 시점은 실측 분포를 본 뒤다 — D-020: "실측 분포를 보기 전에 숫자를 정하면 같은 패턴이다."

미정일 때의 기본 동작 — Seed Spec 이 이미 안전 기본값을 갖는다. C-04 전환 조항과 AC-17 이 그것이다.

AC-17: "Given Planning 단계가 A-02 의 합격 기준을 정하지 않았거나 검증이 수행되지 않은 상태에서, When 새 DelegatedTask 가 생성되면, Then completion_mode 의 기본값은 사람승인이며 자가 검증 통과만으로 '완료'에 도달하지 않는다"

C-04 는 이 전환이 "제약 위반이 아니라 제약이 미리 규정한 동작이며, 기준 미설정 시의 기본값은 안전한 쪽" 이라고 명시한다. spec-evaluation 도 같은 취지로 기록한다 — "미결정이 위험한 쪽으로 기울지 않도록 설계된 조항"("판정과 권고"의 C-04 전환 조항 항목). 다섯 항목 중 Seed Spec 이 전환 조항과 그 인수 기준(C-04 · AC-17)으로 안전 기본값을 명문화한 유일한 항목이다 — NFR-B·NFR-C 의 안전성은 명문화된 전환 장치가 아니라 각각 "3플랫폼 Must 유지"와 "차단 방향 실패"라는 귀결에서 나온다.

요약

이 절이 남기는 미결

1. A-03 의 두 시나리오 요구가 유실됐다. Contrarian CH-032(Major, Resolved)의 해소책은 "A-03 검증 방법을 '단일 대용량 파일 + 다수 생성 파일 동시 오픈 두 시나리오 모두'로 수정" 이었으나, 그 Evidence(v1.1.0 §5 A-03, §4 NFR-02)는 재작성으로 사라졌고 현행 v3.0.2 A-03 에는 두 시나리오 요구가 없다. 복원할지 여부는 Seed Spec 개정 사항이다.
2. AC-15 픽스처 공백. 10만 줄 규모 Dart 파일을 어디서 얻는지가 정해져 있지 않고, 참조 워크스페이스 unibook 이 그런 파일을 포함하는지도 기록이 없다(docs/ 8개 문서 grep, 동시 언급 0건).
3. ~~허용 호스트 개수 불일치.~~ ✅ 해소 — D-051(#39), 오너 결정 #109 (2026-09-13). D-018 「최소 11종」 · §2.1 표 12행 · D-021 「12종」의 불일치는 어느 쪽도 정본으로 고르지 않는 것으로 닫혔다 — 개수를 정본화하지 않고 목록 자체를 단일 SSOT 로 둔다. 근거는 실측이다: #38 의 3-OS 프로브가 §2.1 표에 없던 api.github.com 을 CocoaPods 경로에서 관측해 11 도 12 도 측정과 어긋났고(조건부 표기 행이 원인이라는 당시 가설은 틀렸다), 어떤 수를 고정해도 다음 실측에서 같은 불일치가 재발한다. 이후 어떤 문서도 개수를 판정 기준으로 인용하지 않는다.
4. NFR-E 는 판정 주체 미정 3건 중 둘에 선행 의존한다 — C-05 의 "테스트 파일" 정의(ⓑ 실험 재현), AC-09 의 "적용 불가" 판정 규칙(⑤ 비율 지표 해석). spec-evaluation 이 "설계 결정으로만 풀린다" 고 판정한 항목들이며, 정의 전에는 스파이크 결과를 해석할 수 없다.
5. 폐기된 값이 Contrarian 보고서에 주석 없이 남아 있다. CH-033(p95 16.7ms), 적대적 감사 이력(10분/NFR-05), CH-034·CH-035(NFR-03)에는 CH-011/CH-030 이 받은 ⚠️ 폐기 주석이 없다. 그 문서 머리말의 "시점별 기록" 경고에 의존하지 말고 항목별 주석을 다는 편이 재인용을 막는 데 확실하다.

Generated by cc-product Planning stage (BMAD v6) · 2026-08-26