Metadata
- Created: 2026-08-25
- Rewritten: 2026-08-26 (v3.0.0 — 인수 경계를 범위 경계로 환원, 측정 자료를 Planning 입력으로 분리)
- Author: 프로젝트 오너 (Dart/Flutter 7년 경력) · Socratic 인터뷰 진행: Claude (cc-spec:interview)
- Locked: N/A
- Ambiguity Score: 0.3125 (AMBIGUOUS) — v3.0.2 기준. v3.1.0 재평가 대기. 이전 표기: 0.3125 (AMBIGUOUS) — v3.0.2 기준(8차 평가). Specification Gate 미통과 (기준 ≤ 0.2). 개정 중단 상태 — 사유는
docs/spec-evaluation-cocode.md참조
v3.0.0 재작성 원칙. v1.1.0부터 v2.1.0까지 네 차례 개정에서 모호성 점수가 개선되지 않고 진동했다(0.625 → 0.4125 → 0.47 → 0.4075 → 0.4975). 5차 감사가 원인을 지목했다 — §4 인수 경계가 임계값·측정 환경·픽스처 명세까지 떠안는 테스트 명세가 되려 했고, 그 결과 아직 만들지 않은 물건의 측정 조건을 미리 적어야 했다. 채워 넣을 근거가 없으니 값을 지어냈고, 지어낸 값이 다시 불변 층위에 잠겼다.
v3.0.0은 계층을 제자리로 돌린다:
- §4는 "무엇을 만들고 무엇을 안 만드는가"의 경계만 규정한다. 각 항목은 Given-When-Then 형식을 유지하되, 임계값·측정 환경·픽스처를 담지 않는다. 판정은 "그 성질이 시스템에 존재하는가"로 이뤄지며, 구체적 수치 없이도 가능하다.
- 측정 가능한 조건은
docs/planning-inputs-cocode.md를 거쳐 Planning의 BDD 인수 조건이 된다. 파이프라인 설계상 그것이 Planning 단계(/cc-product:plan)의 산출물이다.- 출처 없는 수치를 쓰지 않는다. §4의 모든 수치는 출처표에 근거를 명시하며, 근거가 없으면 값을 쓰지 않는다.
0. Glossary
| 약어/용어 | 정본 정의 |
|---|---|
| ADE | Agent Development Environment. 사람이 코드를 직접 편집하는 것을 1급으로 두는 IDE와 달리, AI 에이전트에게 작업을 위임하고 그 결과를 검토·되돌리는 것을 1급으로 두는 개발 환경 |
| ACP | Agent Client Protocol. Zed Industries가 만들고 Zed·JetBrains가 공동 관리하는 Apache-2.0 표준. JSON-RPC 2.0 over stdio로 에디터(클라이언트)와 코딩 에이전트(서버)를 연결한다 |
| MCP | Model Context Protocol. 에이전트(클라이언트)가 외부 도구(서버)에 연결하는 프로토콜 |
| LLM 프로바이더 | 모델 API 제공자 또는 그와 호환되는 엔드포인트 |
| MVP | C-01이 정의하는 첫 출시 범위 |
| IME | Input Method Editor. 한글 등 조합형 문자 입력기 |
| 1급 프로젝트 타입 | 새 워크스페이스 생성 시 선택지로 제시되고, 스캐폴딩·언어 지원·에이전트 도구가 그 타입을 전제로 동작하는 것. 단순히 "파일을 열 수 있음"은 1급이 아니다 |
| brick / co-brick | Mason brick. 프로젝트 골격을 결정론적으로 생성하는 템플릿 단위. co-brick은 기존 워크스페이스에 기능 모듈을 덧붙이는 brick — MVP 범위 밖이다(AC-24). MVP 에서 brick 은 워크스페이스 최초 스캐폴딩에만 적용된다 |
| 자가 검증 | 에이전트가 사람의 실시간 관찰 없이 스스로 수행하는 검증. 정본 방법 목록은 C-04 |
| 종결 상태 | DelegatedTask의 상태 중 더 이상 자동으로 전이하지 않는 것: 완료 · 실패 · 롤백됨 · 거부됨 · 중지됨 |
| 참조 문서 | Discovery 문서=docs/discovery-cocode.md · Socratic 문서=docs/socratic-discovery-cocode.md · Contrarian 보고서=docs/contrarian-review-cocode.md · Simplifier 보고서=docs/simplifier-review-cocode.md · 의사결정 일지=docs/decision-log-cocode.md · Planning 입력=docs/planning-inputs-cocode.md. 식별자: CH-NNN=Contrarian, S-NNN=Simplifier, D-NNN=의사결정 일지 |
식별자 주의 1 — 외부 문서와의 충돌. 이 문서의
C-NN(불변 제약)·A-NN(가정)은 Socratic 문서의C-NN(모순)·A-NN(가정)과 다른 체계다. 외부 인용 시 항상 문서명과 Level을 함께 적는다.식별자 주의 2 — 버전 간 재사용 이력. v1.1.0의 삭감 과정에서 제거된 식별자를 이후 버전이 다른 내용으로 재사용했다. 옛 문서를 읽을 때 참고할 대응표:
식별자 v1.0.0에서의 의미 현재 의미 C-05배제 카테고리 없음 (S-001로 제거) 기존 테스트 보호 AC-07May — 게임/임베디드 향후 지원 (S-001로 제거) 재시도 상한 초과 시 실패 A-02코코드 팀이 skill 격차를 채움 (S-002로 제거) 자가 검증 신뢰도 A-05Dart로 못 만드는 것이 없음 (S-001로 제거) ACP v1 전용 구현 타당성
1. Core Problem
Immutable after locking. Cannot evolve.
Dart/Flutter 개발자가 반복 작업을 AI 에이전트에게 되돌릴 수 있는 방식으로 위임하고 자리를 비울 수 있는, Dart/Flutter 전용으로 설계된 에이전트 개발 환경(ADE)이 없다.
Problem Rationale
- Lumide 0.20.0 실사(Discovery 문서
### Key Insights1번 — 설치 용량 55.8MB) 결과, Flutter 기반 경량 에디터는 존재하지만 ACP 클라이언트 역할에 그쳐 자체 LLM 프로바이더 선택 요구를 충족하지 못한다. - Zed·Cursor·Google Antigravity 등 범용 에이전틱 에디터는 Flutter/Dart를 부차적으로 지원할 뿐 언어 전용 목적 지향 설계가 아니다(Discovery 문서
## Market Analysis). - 실질적으로 인지된 경쟁자는 Orca(Stably AI, MIT, GitHub 스타 2만 이상)이며, 언어·에이전트에 무관한 수평적 오케스트레이터로서 Dart/Flutter 런타임 상태 인지나 결정론적 스캐폴딩을 제공하지 않는다(Socratic 문서 Level 4 경계 B-02).
- 프로젝트 오너 인터뷰(Socratic 문서 Level 2 가정 A-04): 코딩을 선호하는 인구는 줄고 개발자조차 AI 위임이 늘어나는 추세가 가속화될 것이라는 전망 위에, 비동기 위임이 핵심 상호작용 모델로 확정됨.
2. Immutable Constraints
Immutable after locking. Each item requires rationale.
| ID | Constraint | Rationale | Type |
|---|---|---|---|
| C-01 | MVP는 코드 에디터를 포함한 개발자용 인터페이스로 우선 출시하고, 비개발자용 자연어 전용 "드리머 모드"는 MVP 이후로 순연한다. 1차 고객은 코코드 내부 팀이 아니라 외부 Dart/Flutter 개발자 시장이다. MVP 배포 대상은 macOS·Windows·Linux 데스크톱 3종이다 | Socratic 문서 Level 3 모순 C-01 + 프로젝트 오너 확답. 의사결정 일지 D-001, D-005, D-016 | Business |
| C-02 | 에이전트가 생성한 모든 파일 편집은 EditSnapshot을 남겨야 하며, EditSnapshot을 남기지 않는 에이전트 편집 경로는 존재하지 않는다. 사용자는 작업 시작 직전 상태를 포함해 임의의 EditSnapshot 경계 시점으로 되돌릴 수 있고, 그 시점 이후 같은 작업이 만든 편집은 함께 되돌아간다. 이 보장의 범위는 보존 정책이 유지하고 있는 EditSnapshot 에 한한다 — 보존 한계를 벗어나 삭제된 스냅샷의 경계 시점은 되돌림 대상이 아니며, 그 사실은 사용자에게 고지된다. 보존 정책의 값은 설정 항목이다(docs/planning-inputs-cocode.md §7) |
Socratic 문서 Level 4 경계 B-01. 사람이 에디터로 직접 하는 편집은 이 제약의 대상이 아니다. 의사결정 일지 D-003 | Technical |
| C-03 | cocode ADE는 Dart/Flutter 전용 ADE로 포지셔닝한다 — 기능의 폭이 Orca 수준(멀티 에이전트 오케스트레이션, 워크트리 격리, 작업 인계 — 전부 MVP 범위 밖의 장기 방향이다)으로 확장되어도 프로젝트 타입은 Dart/Flutter로 한정한다. 단 Dart/Flutter 프로젝트 내부의 비-Dart 파일(CI 설정, 각 플랫폼의 네이티브 빌드 파일, 생성된 자산 등 Dart 가 아닌 모든 파일) 편집은 제한하지 않는다 | Socratic 문서 Level 4 경계 B-02 + Level 5 수렴. ⚠️ 이 포지셔닝은 고객 리서치가 아니라 프로젝트 오너의 판단에 근거한다(Contrarian 보고서 CH-009). 위험을 인수한 상태로 잠그며, 전제는 가정 A-07로 추적한다. 의사결정 일지 D-002, D-011 | Business |
| C-04 | 핵심 상호작용 모델은 비동기 위임이다. 에이전트는 사람의 실시간 관찰 없이 자가 검증을 수행하며, 자가 검증 방법의 정본 목록은 다음과 같다: ① 빌드 성공 ② 테스트 통과 ③ 핫 리로드 후 런타임 오류 없음 ④ 정적 분석 통과 ⑤ (①~④가 모두 적용 불가한 편집에 한해) 편집 대상 파일의 무결성 확인 — 파일이 읽히고, 해당 형식의 파서가 오류를 내지 않으며, 정적 분석이 그 파일에 대해 새로운 오류를 보고하지 않음. ⑤를 근거로 완료하려면 ①~④ 각각이 왜 적용 불가한지를 verification_log에 남겨야 한다. 자가 검증·재시도는 최대 3회 재시도로 제한하며, 단일 시도에는 시간 상한이 설정된다. [전환 조항] 가정 A-02의 검증 결과가 Planning 단계에서 정한 기준에 미달하거나, Planning 단계가 그 기준을 정하지 않았거나, 검증이 수행되지 않은 경우, 기본 완료 모드는 "사람 승인 후 완료"로 전환된다 — 이 전환은 제약 위반이 아니라 제약이 미리 규정한 동작이며, 기준 미설정 시의 기본값은 안전한 쪽이다 | Socratic 문서 Level 2 가정 A-04 + 프로젝트 오너 확답. 재시도 3회는 cc-product BMAD 설정(references/bmad-config.md의 feedback.maxRetries: 3)과 동일한 근거. 의사결정 일지 D-007, D-008, D-012, D-020 |
Technical |
| C-05 | 에이전트는 새 테스트 파일을 생성할 수 있으나, 기존 테스트 파일의 내용을 변경할 수 없다. 기존 테스트 파일에 대한 모든 변경(케이스 추가 포함)은 사람의 명시적 승인을 거쳐야 한다. 테스트 파일은 워크스페이스의 test/ · integration_test/ · widgetbook/ 디렉터리 아래의 파일로 판정한다(경로 기반이므로 판정이 필요 없다) |
프로젝트 오너 확답. C-04 ②(테스트 통과)가 자가 검증 방법인 이상, 에이전트가 테스트 자체를 고쳐 통과시키는 경로를 막지 않으면 자가 검증이 무의미해진다(Contrarian 보고서 CH-030). "약화"의 경계를 판정하는 대신 기존 테스트 파일에 대한 모든 변경을 승인 대상으로 삼아 판정이 필요 없게 한다. 삭제·이름변경도 «변경»이다 — 삭제를 변경에서 빼면 「삭제 후 재생성」으로 C-05 전체가 우회된다(불변식 7 의 투영 전이 단위로 판정한다). 의사결정 일지 D-014 · D-038 | Technical |
3. Domain Entities
After locking, only additions are allowed (existing entities cannot be modified)
Workspace
- Attributes: workspace_id, applied_bricks(워크스페이스 최초 스캐폴딩에 사용된 brick — co-brick 덧붙이기는 MVP 범위 밖이므로 MVP 에서 이 목록의 원소는 1개다, AC-24), dart_sdk_mode, agent_runtime_config, edit_locks(에이전트가 현재 편집 중인 파일 경로 집합), allowed_hosts(에이전트 작업에 허용된 네트워크 호스트 집합 — 기본 목록·의존성 파생분·사용자 추가분의 합), write_exceptions(워크스페이스 밖이지만 에이전트 쓰기가 허용된 경로 집합.
allowed_hosts와 같이 기본 목록·사용자 추가분의 합으로 구성되며, 기본 목록은docs/planning-inputs-cocode.md§2.4 가 정의한다) - Relationships: N개의 brick으로부터 스캐폴딩·확장됨; N개의 DelegatedTask를 가짐
- Invariants:
- Dart/Flutter 프로젝트 구조를 벗어난 워크스페이스는 지원 대상이 아니다(C-03)
- 동일 파일 경로를 두 개 이상의 DelegatedTask가 동시에 편집할 수 없다. 잠금은 에이전트가 그 파일의 편집을 마치는 시점에 해제되며, 작업이 사람의 승인을 기다리는 동안 잠금을 유지하지 않는다
- 스캐폴딩이 부분 실패한 워크스페이스는 생성되지 않는다(전량 성공 또는 전량 롤백)
DelegatedTask (에이전트 위임 작업)
- Attributes: task_id, prompt, status, completion_mode(자가검증 | 사람승인), pending_approval_kind(없음 | 완료승인 | 테스트변경승인), agent_backend_kind(cocode_agent | cocode_acp), agent_backend_provider, retry_count, verification_log(수행한 자가 검증 방법과 결과, ⑤ 사용 시 ①~④ 각각의 적용 불가 사유), created_by
- status 값 집합: 대기 · 실행중 · 자가검증중 · 사람승인대기 · 완료 · 실패 · 롤백됨 · 거부됨 · 중지됨 (9종 폐쇄 집합)
- Relationships: 1개의 Workspace에 속함; N개의 EditSnapshot을 생성함
- Invariants:
- completion_mode가
자가검증일 때 "완료"로 전이하려면, C-04의 방법 중 해당 편집에 적용 가능한 것을 1종 이상 통과하고 그 결과가 verification_log에 기록되어야 한다. ⑤로 완료하는 경우 ①~④ 각각의 적용 불가 사유도 함께 기록되어야 한다 - completion_mode가
사람승인일 때는 자가 검증 결과와 무관하게 "사람승인대기"(pending_approval_kind=완료승인)로 전이하며, 사용자의 명시적 승인 없이 "완료"에 도달하지 않는다. 이 모드에서 자가 검증 결과는 사용자에게 제시되는 정보이지 완료의 관문이 아니다 - completion_mode와 무관하게, 기존 테스트 파일 변경이 포함된 작업은 그 변경을 적용하기 전에 "사람승인대기"(pending_approval_kind=테스트변경승인)로 전이한다(C-05)
- retry_count가 3을 초과하거나 단일 자가 검증 시도가 설정된 시간 상한을 넘기면 "실패"로 전이하고 사람에게 에스컬레이션한다(C-04)
- "롤백됨"으로의 전이는 사용자의 명시적 롤백 요청으로만 발생한다
- completion_mode가
EditSnapshot (편집 스냅샷 / 롤백 단위)
- Attributes: snapshot_id, file_path, diff, base_content_hash(편집 직전 해당 파일 내용의 해시 — 롤백이 복원할 목표 상태), result_content_hash(편집 직후 해당 파일 내용의 해시 — 에이전트가 남긴 상태), timestamp, sequence_no(같은 DelegatedTask 내 순번), attempt_no(그 편집을 남긴 시도의 번호 — 최초 시도가 0, 재시도마다 1씩 증가), previous_path(선택 — 이름변경 스냅샷에만 존재. 이름변경 직전의 경로. 이름변경은 내용을 보존하므로
base_content_hash=result_content_hash다)- 두 해시의 값 집합에는 «부재(absent)» 가 포함된다 — 편집 직전/직후 그 경로에 파일이 존재하지 않음을 나타내는 구별값이며, 빈 파일의 해시와 다르다. 부재로의 복원은 파일 삭제다. 이 값이 없으면 생성(base 미정의)·삭제(result 미정의)·이름변경(경로 2개)을 표현할 수 없다(
docs/flow-permutation-cocode.mdI-4 / FP-306·307). Design 결정은docs/architecture-cocode.md§4.7 DD-25 sequence_no와attempt_no의 차이:sequence_no는 작업 전체에서 몇 번째 편집인가(단조 증가, 시도를 가로질러 이어진다)이고attempt_no는 그 편집이 어느 시도에 속하는가이다. 하나의attempt_no값에 여러sequence_no가 대응한다 — 시도 하나가 여러 파일을 편집하기 때문이다.sequence_no만으로는 「3번째 편집과 4번째 편집 사이에 재시도 경계가 있는가」를 답할 수 없고, 그래서 재시도 3회 소진 후 사람에게 넘어가는 최대 4세트의 편집이 구분 없이 누적된다(이 속성이 없을 때의 상태 —docs/flow-permutation-cocode.mdFP-103 / I-5)- 시도 경계의 정의:
attempt_no는 DelegatedTask 의retry_count가 증가하는 시점에 함께 증가한다.docs/state-machine-cocode.md§3(전이 ⑧자가검증중 → 실행중)이 재시도가 되돌아가는 상태를실행중으로 확정하고retry_count증가 지점을 그 전이 시점으로 못박았으므로, 「retry_count 증가 시점」과 「재시도 시작 status 전이」는 같은 사건이다 — 둘 중 어느 것으로 정의해도 결과가 같다. (flow-permutation-cocode.md:102N3 가 이 자리를 미규정으로 남겼던 것은 그 문서 작성 시점 기준이며, 위 결정으로 해소됐다.)
- 두 해시의 값 집합에는 «부재(absent)» 가 포함된다 — 편집 직전/직후 그 경로에 파일이 존재하지 않음을 나타내는 구별값이며, 빈 파일의 해시와 다르다. 부재로의 복원은 파일 삭제다. 이 값이 없으면 생성(base 미정의)·삭제(result 미정의)·이름변경(경로 2개)을 표현할 수 없다(
- Relationships: 1개의 DelegatedTask에 속함
- Invariants:
- 에이전트의 모든 파일 편집은 대응하는 EditSnapshot 없이 존재할 수 없다(C-02)
- 롤백 시 대상 파일의 현재 내용 해시를 그 파일에 대해 롤백 대상 작업이 남긴 가장 마지막 EditSnapshot 의 result_content_hash 와 대조한다. 다르면 에이전트가 남긴 상태가 이후 변경된 것이므로(사람의 직접 편집 등) 자동 적용하지 않고 충돌로 제시한다. 또한 그 파일의 전역 마지막 EditSnapshot 이 롤백 대상 작업의 것이 아니면(= 다른 작업이 그 뒤 같은 파일을 편집했으면) 자동 적용하지 않고 충돌로 제시한다 — 뒤 작업의 편집이 조용히 소멸하는 것을 막는다(FP-304). base_content_hash 는 복원 목표이지 충돌 판정 기준이 아니다
- 특정 snapshot으로의 롤백은 같은 작업에서 그 이후 생성된 모든 EditSnapshot을 함께 되돌리며, 전부 적용되거나 전부 적용되지 않는다(원자성)
- 작업 시작 직전 상태로의 롤백은 그 작업의 모든 EditSnapshot을 되돌리는 것이며, 각 파일은 그 파일에 대한 최소 sequence_no를 갖는 EditSnapshot의 base_content_hash가 가리키는 내용으로 복원된다 — 즉 작업의 첫 편집도 되돌릴 수 있다
- 시도 경계 롤백:
attempt_no는 아래 3종 질의 각각에 대해 되돌릴 EditSnapshot 집합을 유일하게 결정한다. 재시도는 직전 시도의 편집을 자동으로 되돌리지 않으므로(누적 —docs/decision-log-cocode.mdD-030), 각 시도의 편집은 이전 시도 위에 쌓인 채 남아 있고 이 세 집합은 서로 다르다
| 질의 | 대상 집합 | 산출 예시 (한 작업이 retry_count 3 까지 가고 시도마다 파일 2개씩 편집 — 스냅샷 8건) |
|---|---|---|
| ⓐ 시도 k 시작 직전 | attempt_no ≥ k 인 모든 EditSnapshot |
k=2 → attempt_no 2·3 의 스냅샷 4건(seq 5·6·7·8). 각 파일은 그 집합 안에서 그 파일의 최소 sequence_no 스냅샷의 base_content_hash 로 복원된다 |
| ⓑ 시도 k 가 남긴 편집만 | attempt_no == k 인 EditSnapshot |
k=2 → 스냅샷 2건(seq 5·6). ⚠️ 이 질의는 원자성 불변식과 충돌할 수 있다 — 시도 2 만 되돌리면 그 위에 쌓인 시도 3 의 편집이 시도 2 가 만든 내용을 전제로 남는다. 그래서 ⓑ 는 k 가 마지막 시도일 때만 적용 가능하고(그때 ⓐ 와 결과가 같다), 그 밖의 k 에서는 충돌로 제시한다 |
| ⓒ 작업 시작 직전 | 그 작업의 모든 EditSnapshot (= attempt_no ≥ 0) |
스냅샷 8건 전부. 각 파일은 그 파일에 대한 최소 sequence_no 스냅샷의 base_content_hash 로 복원된다 — 바로 위 불변식 4 와 문자 그대로 같은 결과이며, attempt_no 도입이 기존 정의를 바꾸지 않음을 이 일치가 보인다(ⓐ 에 k=0 을 넣은 것과도 같다) |
- Invariants (이어서 — 종류와 투영):
- 불변식 6 — 종류는 유일하게 결정된다. 스냅샷의 종류는
(base_content_hash, result_content_hash, previous_path)로 유일하게 결정된다: 수정(해시→해시,previous_path없음) · 생성(부재→해시) · 삭제(해시→부재) · 이름변경(previous_path있음, base = result). 부재→부재인 스냅샷과previous_path가 있으면서 base ≠ result 인 스냅샷은 존재하지 않는다. 별도의kind속성을 두지 않는다 - 불변식 7 — 경로별 투영 전이. 불변식 2(충돌 판정)·4(작업 시작 직전 복원)·「시도 경계 롤백」의 "그 파일" 은 경로별 투영 전이로 읽는다: 이름변경 스냅샷은
previous_path에 (해시→부재),file_path에 (부재→해시) 두 전이로 투영되고, 나머지 종류는file_path에 한 전이로 투영된다. "현재 내용 해시"는 그 경로에 파일이 없으면 부재이며, 정규 파일이 아닌 것이 있으면 어떤 값과도 일치하지 않는다(충돌)
- 불변식 6 — 종류는 유일하게 결정된다. 스냅샷의 종류는
4. Acceptance Boundaries
One flat table (FLAT). Status defaults to PENDING at create. 이 표는 범위 경계를 규정한다 — "무엇을 만들고 무엇을 안 만드는가". 여기 담는 수치는 출처표에 근거가 있는 것에 한하며, 근거 없는 임계값·측정 환경·픽스처는 담지 않고
docs/planning-inputs-cocode.md를 거쳐 Planning 단계의 BDD 인수 조건이 된다.
| ID | Type | Acceptance Criterion | Status |
|---|---|---|---|
| AC-01 | Must | Given 에이전트가 파일을 편집한 DelegatedTask가 존재할 때, When 사용자가 해당 작업을 화면에서 열면, Then 변경된 모든 파일의 diff가 표시된다 | PENDING |
| AC-02 | Must | Given 에이전트가 편집한 EditSnapshot이 존재할 때, When 사용자가 특정 스냅샷 또는 작업 시작 직전 상태로 롤백을 요청하면, Then 그 시점 이후 같은 작업이 만든 편집이 함께 원자적으로 되돌아가고, 대상 파일의 현재 해시가 그 파일에 대해 롤백 대상 작업이 남긴 마지막 EditSnapshot 의 result_content_hash 와 불일치하거나, 그 파일의 전역 마지막 EditSnapshot 이 롤백 대상 작업의 것이 아니면 자동 적용 대신 충돌로 제시된다 | PENDING |
| AC-03 | Must | Given cocode ADE가 MVP로 출시된 시점에, When macOS·Windows·Linux 각각에서 애플리케이션을 실행하면, Then 코드 에디터·파일 트리·터미널을 포함한 개발자용 인터페이스가 제공된다 | PENDING |
| AC-04 | Must-Not | Given cocode ADE MVP 출시 범위에서, When 애플리케이션이 제공하는 기능을 확인하면, Then 코드 뷰 없이 자연어만으로 조작하는 "드리머 모드"는 존재하지 않는다 | PENDING |
| AC-05 | Must-Not | Given 사용자가 새 워크스페이스를 생성할 때, When 프로젝트 타입 선택지를 확인하면, Then Dart/Flutter 이외의 언어는 1급 프로젝트 타입(§0 정의)으로 제시되지 않는다. 프로젝트 내부의 비-Dart 파일 편집은 이 제한과 무관하다 | PENDING |
| AC-06 | Must | Given cocode ADE가 MVP로 출시된 시점에, When 사용자가 에이전트 백엔드를 선택하면, Then 자체 런타임(agent — 서로 다른 LLM 프로바이더 2개 이상)과 외부 ACP 에이전트 호스팅(acp — ACP 에이전트 1개 이상 연결) 두 경로가 모두 제공된다 | PENDING |
| AC-07 | Must | Given 에이전트가 자가 검증에 실패를 반복할 때, When 재시도가 3회를 초과하면, Then 작업은 "실패"로 전이해 사람에게 에스컬레이션되고 그 이상 자동 재시도하지 않는다 | PENDING |
| AC-08 | Must | Given 자가 검증 시도가 진행 중일 때, When 그 시도의 경과 시간이 시간 상한을 넘기면, Then 시도가 중단되고 실패로 기록된다. 설치 직후 사용자 설정 없이도 시간 상한이 양의 유한한 시간값을 갖는다(값은 변경 가능한 설정 항목이나, 미설정·무한대는 허용하지 않는다) | PENDING |
| AC-09 | Must | Given completion_mode가 자가검증인 작업에서 에이전트가 편집을 마쳤을 때, When 완료 전이를 시도하면, Then C-04의 방법 중 적용 가능한 것을 1종 이상 통과하고 그 결과가 verification_log에 기록된 뒤에만 "완료"에 도달하며, ⑤로 완료하는 경우 ①~④ 각각의 적용 불가 사유도 기록된다 |
PENDING |
| AC-10 | Must | Given completion_mode가 사람승인인 작업에서 에이전트가 편집을 마쳤을 때, When 완료 전이를 시도하면, Then 작업은 "사람승인대기"에 머물며 사용자의 명시적 승인 없이는 "완료"에 도달하지 않는다 |
PENDING |
| AC-11 | Must | Given 에이전트가 기존 테스트 파일(test/ · integration_test/ · widgetbook/ 아래)에 대한 변경(내용 변경 · 삭제 · 이름변경 전 경로가 테스트 경로인 이름변경)을 적용하려 할 때, When 그 변경을 적용하려 하면, Then 변경의 성격을 판정하지 않고 completion_mode와 무관하게 사람의 명시적 승인 없이는 적용되지 않는다. 테스트 경로에 대한 생성(부재→해시)만이 이 제한의 예외다 |
PENDING |
| AC-12 | Must | Given 동일 워크스페이스에서 두 작업이 같은 파일을 편집하려 할 때, When 두 번째 작업이 그 파일에 접근하면, Then 첫 번째 작업이 그 파일의 편집을 마칠 때까지 대기하며 동시 편집이 발생하지 않는다 | PENDING |
| AC-13 | Must | Given brick 스캐폴딩이 진행 중 실패할 때, When 실패가 발생하면, Then 부분 생성된 파일은 전량 제거되고 워크스페이스는 생성되지 않은 상태로 남는다 | PENDING |
| AC-14 | Must | Given 에이전트가 작업을 수행할 때, When 파일을 수정하거나 명령을 실행하면, Then ⓐ 해당 Workspace의 경로와 write_exceptions에 없는 경로의 파일은 수정하지 않고, ⓑ 해당 Workspace의 allowed_hosts에 없는 호스트로는 네트워크 요청을 보내지 않는다. 두 목록이 비어 있지 않은 유효한 값으로 초기화되어 있고 위반 시도가 차단되는 것이 이 기준의 대상이며, 목록의 구체적 내용은 설정이다(docs/planning-inputs-cocode.md §2) |
PENDING |
| AC-15 | Must | Given 10만 줄 규모의 Dart 파일을 연 상태에서, When 사용자가 스크롤·커서 이동·다중 선택을 수행하면, Then 조작이 입력한 순서대로 반영되고 화면이 응답하지 않는 구간이 발생하지 않는다. 프레임 타임 임계값과 측정 환경은 Planning이 확정한다(docs/planning-inputs-cocode.md §3) |
PENDING |
| AC-16 | Must | Given MVP 대상 3개 플랫폼 각각의 에디터와 터미널에서, When 한글을 조합 입력하면, Then 조합 중 글자 깨짐·중복 입력·커서 위치 오류가 발생하지 않는다. 플랫폼별 검증 시점과 입력기·코퍼스 지정은 Planning이 확정한다(docs/planning-inputs-cocode.md §4) |
PENDING |
| AC-17 | Must | Given Planning 단계가 A-02 의 합격 기준을 정하지 않았거나 검증이 수행되지 않은 상태에서, When 새 DelegatedTask 가 생성되면, Then completion_mode 의 기본값은 사람승인이며 자가 검증 통과만으로 "완료"에 도달하지 않는다(C-04 전환 조항) |
PENDING |
| AC-18 | Must | Given 에이전트 프로세스가 편집 도중 비정상 종료했을 때, When 그 작업이 보유하던 파일 잠금을 확인하면, Then 잠금은 해제되어 있고 다른 작업이 해당 파일을 편집할 수 있다 | PENDING |
| AC-19 | Must | Given 작업이 "실패"로 전이했을 때, When 사용자가 그 작업을 열면, Then 그때까지 적용된 편집의 diff 와 롤백 수단이 제공되며, 편집이 조용히 폐기되거나 조용히 확정되지 않는다 | PENDING |
| AC-20 | Must | Given LLM 프로바이더 또는 연결된 ACP 에이전트가 작업 도중 응답 불가 상태가 되었을 때, When 그 상태가 감지되면, Then 작업은 종결 상태로 전이해 사용자에게 사유가 제시되며 무한 대기하지 않는다 | PENDING |
| AC-21 | Must-Not | Given cocode ADE MVP 출시 범위에서, When 애플리케이션이 제공하는 기능을 확인하면, Then 워크트리 격리와 에이전트 간 작업 인계는 존재하지 않는다(한 워크스페이스 안에서 복수 DelegatedTask 를 동시 진행하고 파일 단위로 잠그는 AC-12 는 이 제한과 무관하다) | PENDING |
| AC-22 | Must | Given 작업이 실행중 또는 자가검증중 일 때, When 사용자가 그 작업의 중지를 요청하면, Then 작업은 중지됨(종결 상태)으로 전이하고, 그때까지 적용된 편집의 diff 와 롤백 수단이 제공되며, 편집이 조용히 폐기되거나 조용히 확정되지 않는다 |
PENDING |
| AC-23 | Must | Given 작업이 사람승인대기 일 때, When 사용자가 승인을 거부하면, Then 작업은 거부됨(종결 상태)으로 전이하고, 그때까지 적용된 편집의 diff 와 롤백 수단이 제공되며 무한 대기하지 않는다 |
PENDING |
| AC-24 | Must-Not | Given cocode ADE MVP 출시 범위에서, When 애플리케이션이 제공하는 기능을 확인하면, Then 기존 워크스페이스에 co-brick 을 덧붙이는 기능은 존재하지 않는다(brick 적용은 워크스페이스 최초 스캐폴딩에 한한다) | PENDING |
수치의 출처 (전수)
§1~§5에 등장하는 모든 규범적 수치와 그 근거다. 이 표에 없는 수치가 §1~§5에 있다면 그것은 누락이며 결함으로 취급한다.
| 수치 | 위치 | 출처 |
|---|---|---|
| 재시도 3회 | C-04, AC-07 | 프로젝트 오너 확답(D-008) + cc-product references/bmad-config.md의 feedback.maxRetries: 3 |
| LLM 프로바이더 2개 이상 | AC-06 | "멀티 LLM"이 성립하기 위한 정의상 최소값. 구체적 프로바이더 조합(Anthropic + OpenAI 호환 게이트웨이)은 D-017이 정한 구현 선택이며 이 경계의 일부가 아니다 |
| ACP 에이전트 1개 이상 | AC-06 | 경로가 존재함을 보이는 최소값 |
| 자가 검증 방법 1종 이상 | AC-09, DelegatedTask 불변식 | C-04의 5종 중 해당 편집에 적용 가능한 것이 하나도 없을 수는 없다는 하한(⑤가 항상 대체 경로로 존재하므로 1은 도달 가능한 최소값) |
| 데스크톱 플랫폼 3종 | C-01, AC-03, AC-16 | 프로젝트 오너 확답(D-016) |
| 자가 검증 방법 5종 | C-04 | 이 문서가 정의하는 폐쇄 집합. ⑤는 ①~④가 모두 적용 불가한 경우의 대체 경로이며 목록의 일부다 |
| 10만 줄 | AC-15, A-03 | Discovery 문서가 인용한 설계 노트 로드맵 1단계의 검증 시나리오 |
| Lumide 0.20.0 | §1 | Discovery 문서 머리말(3행)이 밝힌 실사 대상 버전 |
| Lumide 설치 55.8MB | §1, A-06 | Discovery 문서 ### Key Insights 1번의 실측치 (참조값). ⚠️ docs/planning-inputs-cocode.md §3.1의 unibook Dart 소스 총량도 우연히 ~55.8MB다 — 서로 무관한 값이며 복사 오류가 아니다 |
| ACP 레지스트리 probe 32종 / v1 협상 31종 / 디컴파일 2종 | A-05 | docs/planning-inputs-cocode.md §5.2 의 조사 기록 |
| 지표 3종(설치 용량·콜드 스타트·메모리) | A-06 | 이 문서가 A-06 에서 열거하는 측정 대상 |
| GitHub 스타 2만 이상 | §1 | Socratic 문서 Level 4 경계 B-02 의 보강 조사 기록 ("★2만+"). Discovery 문서에는 Orca 언급이 없다 — 초기 기재의 Discovery 인용은 오기였고 6차 감사에서 정정 |
| flutter#128575 | A-03 | Flutter 저장소 공개 이슈 — Discovery 문서 §Technical Feasibility 가 미해결(open)로 기록 |
| Lumide 이슈 #64 (2026-07-29) | A-04 | Lumide 저장소 공개 이슈 — Discovery 문서 §Validated/Unvalidated Assumptions 가 미해결로 기록 |
5. Exposed Assumptions
| ID | Assumption | Verification Status | Verification Method |
|---|---|---|---|
| A-01 | 1차 고객은 외부 Dart/Flutter 개발자 시장이며, 비개발자 접근성 확장은 MVP 이후 목표다 | Verified (프로젝트 오너 확답, 2026-08-25) | Planning 단계 PRD의 타깃 세그먼트 정의로 승계 |
| A-02 | 자가 검증(C-04)이 사람의 판단을 대체할 만큼 신뢰할 수 있으며, 에이전트가 자기 검증을 형식적으로 통과시키는 실패 모드가 C-05의 테스트 보호와 결합해 실용적 수준에서 억제된다 | Unverified — 이 문서에서 가장 부담이 큰 가정 | Design 단계 이전 스파이크. 표본 수와 합격 기준은 Planning이 확정. 실험은 ⓐ 제3자가 주입한 결함의 검출률과 ⓑ 에이전트 자신이 만든 결함에 대한 검출률을 분리 측정해야 한다(Contrarian 보고서 CH-030의 내생적 실패 모드는 ⓐ로 측정되지 않는다). 미달 또는 미수행 시 C-04 전환 조항 발동 |
| A-03 | re_editor 기반 에디터 코어가 AC-15의 시나리오를 실사용 가능한 성능으로 지원한다. 단 flutter#128575가 Flutter 엔진 자체의 이슈라면 cocode ADE 자체 노력으로 해결 불가능할 수 있다 | Unverified — MVP 게이팅 리스크 | 로드맵 1단계 스파이크(docs/planning-inputs-cocode.md §3). 실패 시 자체 렌더링 텍스트 레이어 검토로 분기 |
| A-04 | 한글 IME가 에디터·터미널 양쪽에서 AC-16을 충족한다. xterm2/flutter_pty2를 재사용할 경우 Lumide 이슈 #64(2026-07-29 등록, 미해결)와 동일한 결함을 물려받을 위험이 있다 | Unverified, 반증 사례 있음 — MVP 게이팅 리스크 | 로드맵 1단계 스파이크(docs/planning-inputs-cocode.md §4). macOS 우선, 재사용 컴포넌트의 결함 재현 여부를 먼저 확인 |
| A-05 | ACP v1 전용 구현으로 MVP를 출시할 수 있으며, v2 라우팅 seam만 두면 이후 분기를 흡수할 수 있다 | Unverified — 근거 자료는 확보됨(docs/planning-inputs-cocode.md §5: 레지스트리 probe 32종 중 31종 v1, flagship 어댑터 2종 디컴파일 결과 v2 미지원). 실제 구현으로는 미검증 |
Design 단계에서 v1 협상 계층 구현 후 Claude Agent(Claude Code 의 ACP 어댑터)·Codex·Gemini CLI·Copilot CLI 4종으로 연결 검증 |
| A-06 | Flutter 데스크톱 셸에 에이전트 런타임을 포함하고도 경쟁력 있는 설치 용량·콜드 스타트·메모리 사용량을 달성할 수 있다 | Unverified — 목표치 자체가 미확정 | 로드맵 1단계 스파이크: 최소 셸 조립 후 세 지표를 실측하고, 그 결과와 Lumide 실측치(55.8MB)를 근거로 Planning이 목표치를 확정 |
| A-07 | Dart/Flutter 개발자가 수평적 넓이(여러 언어·인프라를 한 도구에서)보다 수직적 깊이(Flutter 전용 심화)를 더 선호한다 | Unverified — C-03 포지셔닝의 전제 | MVP 출시 후 사용자 인터뷰 및 이탈 사유 분석(Contrarian 보고서 CH-009, 의사결정 일지 D-011) |
6. Evolution Log
Append-only. 최신 항목이 표의 마지막 행이다.
| Version | Date | Changes | Reason | Approver |
|---|---|---|---|---|
| v1.0.0 | 2026-08-25 | Initial version — Socratic 인터뷰(Level 1–5) 결과 반영 | Creation | 프로젝트 오너 |
| v1.1.0 | 2026-08-25 | 용어집 신설, 1차 고객 확정, 자가 검증 방법 목록화·재시도 상한, Simplifier 제안 3건 수용, AC 전량 Given-When-Then 전환, NFR 신설, EditSnapshot 충돌 감지, "실패" 상태 추가 | 모호성 0.625(UNCLEAR) 및 Contrarian 반론 36건 반영 | 프로젝트 오너 |
| v1.2.0 | 2026-08-26 | C-04 전환 조항, completion_mode·사람승인대기, NFR-01 목표치를 스파이크로 이관, A-06·A-07 신설 | 적대적 감사가 Critical 3건 미해소 판정 + 신규 Critical 3건 지적 | 프로젝트 오너 |
| v2.0.0 | 2026-08-26 | 삭감 재작성 — 출처 없는 수치 제거, 식별자를 AC-NN으로 통일, C-05 신설(테스트 보호), 모순 11건 해소 |
3차 감사: 모호성 0.47로 악화, 복잡도 42.5, 내부 모순 11건 | 프로젝트 오너 |
| v2.0.1 | 2026-08-26 | 사실 오류 정정(Discovery 인용, 복잡도 수치, maxRetries 출처, p95 제안값 표기), 우회 경로 차단 | 4차 감사: 근거 없는 수치 11건, 사실 오류 3건 확인 | 프로젝트 오너 |
| v2.1.0 | 2026-08-26 | Planning 입력 9건 중 7건 확정(플랫폼·IME 순서·프로바이더·허용 호스트·참조 워크스페이스·ACP 4종·v1 전용) | Planning 필수 입력 해소 | 프로젝트 오너 |
| v3.0.0 | 2026-08-26 | 계층 환원. ①§4를 범위 경계로 되돌림 — 임계값·측정 환경·픽스처를 전부 docs/planning-inputs-cocode.md로 이관 ②AC-08 신설로 시간 상한 인수 기준 복원(v2.0.1이 제거한 뒤 v2.1.0이 존재한다고 잘못 서술했던 공백) ③테스트 변경 승인을 completion_mode와 무관하게 적용하도록 수정 + pending_approval_kind 속성 신설 ④AC-06에서 ACP 버전 언급 제거(불변 층위에 프로토콜 버전을 잠그지 않음) ⑤EditSnapshot 작업 시작 상태 정의를 파일별 최소 sequence_no 기준으로 수정 ⑥Workspace에 allowed_hosts 속성 신설(AC-14가 요구하는 상태의 저장 위치) ⑦MVP 플랫폼 3종을 C-01에 규범적으로 명시 ⑧AC-09에 ⑤ 사용 시 사유 기록 의무 반영 ⑨1급 프로젝트 타입 용어 정의 ⑩식별자 재사용 대응표 신설 ⑪출처표를 §4 실제 내용과 일치시킴 ⑫Evolution Log 정렬 복구 ⑬A-05 상태를 스키마 enum(Unverified)으로 교정 |
5차 감사: 모호성 0.4975로 악화(궤적 0.625→0.4125→0.47→0.4075→0.4975 — 개선이 아니라 진동), 내부 모순 17건, 판정 불가 AC 5건, 자기 문서에 대한 허위 서술 1건. 근본 원인이 계층 착오(인수 경계가 테스트 명세가 되려 함)로 진단되어 개정이 아니라 계층 환원으로 대응. 프로젝트 오너 결정(2026-08-26) | 프로젝트 오너 |
| v3.0.1 | 2026-08-26 | 위성 문서 정리 및 국소 결함 수정. ①AC-11 에서 C-05 와 모순되던 예외("기존 파일에 케이스 덧붙이기") 제거 — 판정 없이 기존 테스트 파일의 모든 변경을 승인 대상으로 통일 ②AC-15 의 동어반복 Then("지원 범위에 포함된다")을 관찰 가능한 실패 조건으로 교체 + 금지어(대용량·다수) 제거 ③AC-08 에서 "응답 없이" 한정 제거(C-04·불변식과 범위 일치) + 설치 직후 유효한 기본값 요구 ④Workspace 에 write_exceptions 신설(AC-14 가 요구하던 두 번째 상태의 저장 위치) ⑤출처표 범위를 §1~§5 로 정정하고 누락 수치 5종 추가 ⑥§4 서문을 "출처 없는 임계값을 담지 않는다"로 정정(사실과 일치) ⑦planning-inputs 의 AC 참조를 v3.0.0 번호로 갱신 ⑧planning-inputs §4.3 이 AC-16(3플랫폼 Must)을 완화할 수 있다고 읽히던 서술 정정 ⑨planning-inputs §5.2 의 v2 미지원 주장 범위를 검증된 2종으로 한정 ⑩55.8MB 중복(Lumide 설치 용량 vs unibook Dart 소스)이 우연의 일치임을 양쪽에 표기 ⑪의사결정 일지 D-018·D-019 에 현재 상태 정정 주석 ⑫Contrarian 보고서에 "시점별 기록" 성격 명시 |
6차 감사: 모호성 0.435(v3.0.0 기준 — v3.0.1 자체는 7차에서 0.4175 로 측정됨), 17건 중 13건 해소 확인. 감사 판정 — "결함이 사라진 게 아니라 이주했다": 깨진 인용 9건이 전부 위성 문서→스펙 방향. 미해소 4건이 모두 작성자가 쓸지 않은 위성 문서에 있었음 | 프로젝트 오너 |
| v3.0.2 | 2026-08-26 | 6차 감사 지적 기계적 해소. ①§6 정렬 복구(v3.0.1 이 v3.0.0 의 수정을 되돌렸던 것) ②출처표에 A-05·A-06 수치 추가로 "§1~§5 전수" 주장을 참으로 회복 ③GitHub 스타 2만의 출처를 Socratic B-02 로 정정 — Discovery 문서에는 Orca 언급이 0회이며 초기 기재는 존재하지 않는 절을 가리켰다 ④Lumide 0.20.0 과 55.8MB 를 출처 위치별로 분리 ⑤이슈 번호의 순환 출처를 Discovery 내 기록 위치로 교체 ⑥Claude Code/Claude Agent 명칭 통일 ⑦C-04 ⑤ "무결성 확인"을 판정 가능한 술어로 정의 ⑧AC-08 "유효한 값"→"양의 유한한 시간값"(무한대 배제) ⑨write_exceptions 에 allowed_hosts 와 동일한 기본 목록 구성 규칙 부여 ⑩C-05 를 파일 단위로 통일(문장과 근거·AC-11 의 granularity 불일치 해소) ⑪금지어 "등" 3곳 제거 ⑫AC-17 신설 — C-04 전환 조항에 인수 기준이 없던 공백(감사가 최고 가치 결함으로 지목) ⑬AC-18·19·20 신설(비정상 종료 시 잠금 누수, 실패 작업의 편집 처분, 프로바이더 응답 불가) ⑭planning-inputs §6 의 "시간 상한 미정" 서술이 개정된 AC-08 과 모순되던 것 정정 + 대상 버전 갱신 |
6차 감사: 모호성 0.4175. 감사가 "0.2 도달 가능" 판정 — 문서 유형이 먹는 바닥은 0.0775 뿐이고 나머지(가중치 0.65)는 "측정도 코드도 필요 없는 책상 작업". 전량 수정 시 예상 0.155~0.165(CLEAR). 이 개정은 그 목록을 그대로 실행한 것 | 프로젝트 오너 |
| v3.2.0 | 2026-08-29 | 재시도 시도 경계 표현 신설 (#20). ①EditSnapshot 에 attempt_no 속성 신설 — 최초 시도 0, 재시도마다 1 증가. sequence_no(작업 전체 편집 순번)와 병존하며 역할이 다르다: 순번은 「몇 번째 편집인가」, attempt_no 는 「어느 시도의 편집인가」. 이 속성이 없으면 재시도 3회 소진 후 최대 4세트 편집이 구분 없이 사람에게 넘어간다(FP-103 / I-5) ②EditSnapshot 불변식에 시도 경계 롤백 규칙 추가 — ⓐ시도 k 시작 직전 ⓑ시도 k 가 남긴 편집만 ⓒ작업 시작 직전 3종 질의 각각에 대상 집합이 유일하게 결정되고, ⓒ의 결과가 기존 불변식 4(파일별 최소 sequence_no 의 base_content_hash)와 일치함을 명시 ③시도 경계를 retry_count 증가 시점으로 정의 — docs/state-machine-cocode.md §3(전이 ⑧)이 재시도 복귀 상태를 실행중 으로 확정하고 증가 지점을 그 전이 시점으로 못박아, 「retry_count 증가」와 「재시도 시작 전이」가 같은 사건이 됐다(N3 해소, 잠정 아님) |
#20 커버리지 비평이 승격한 항목. 재시도가 직전 시도 편집을 되돌리는가(누적/되감기)는 누적으로 오너 확정 — docs/decision-log-cocode.md D-030 |
프로젝트 오너 |
| v3.3.0 | 2026-09-10 | 착수 전 오너 결정 6건 반영 (#105 #106 #107 #108 #110 #113). ①**#105 — 중지 입력과 거부 경로 신설**: status 폐쇄 집합을 7종 → 9종(거부됨 · 중지됨 추가)으로 개정하고 종결 상태 정의에 둘을 포함. AC-22(실행 중 중지) · AC-23(승인 거부) 신설 — flow-permutation C-5 의 무한 체류 4지점(FP-105·106·107·405)과 UX-D-06 의 정면 충돌을 '중지 수단 신설' 쪽으로 처분 ②**#106 — AC-08 자가 검증 시간 상한의 출하 기본값을 잠정 확정**: 값은 docs/planning-inputs-cocode.md §6 에 두고 AC-08 문면은 불변(§4 는 값을 담지 않는다). D-020 의 보류를 해제 ③**#107 — agent 경로 모델 비용은 BYOK**: 키 소유자는 사용자이며 DD-23 의 CredentialVault 설계가 그대로 유효. 과금·정산은 MVP 범위 밖 ④**#108 — C-02 에 보존 한계 명시**: '임의의 EditSnapshot 경계 시점으로 되돌릴 수 있다'의 범위를 보존 정책이 유지하고 있는 스냅샷으로 한정하고 삭제분에 대한 고지 의무를 추가. 이 개정으로 보존 정책 값 3종(K·총량 상한·보존 기간)이 C-02 와 모순 없이 정해질 수 있게 됐다 — 값 자체는 #29 의 Planning 산출물이며 이 개정이 값을 정하지는 않는다 ⑤**#110 — 롤백 충돌 판정에 작업 범위 한정 명시**: 불변식과 AC-02 를 '롤백 대상 작업이 남긴 마지막 result_content_hash' 로 한정하고, 전역 마지막 스냅샷이 롤백 대상 작업의 것이 아니면 충돌로 제시를 규범으로 추가. 구현(#24 의 사전검사)이 스펙보다 앞서 있던 상태를 해소하고 FP-304(뒤 작업 편집의 조용한 소멸)를 막는다 ⑥**#113 — co-brick 덧붙이기는 MVP 범위 밖**: AC-24(Must-Not) 신설, 용어표와 Workspace.applied_bricks 를 '최초 스캐폴딩 brick' 의미로 정정 |
docs/breakdown-cocode.md → '착수 전 사람이 정해야 하는 것' 의 오너 판정 항목 6건을 일괄 처분. 이 6건이 막고 있던 것은 총 16건 · 76pt(#24 #29 #30 #32 #42 #45 #50 #52 #66 #67 #68 #69 #70 #71 #73 #89). 의사결정 일지 D-032 ~ D-037 |
프로젝트 오너 |
| v3.4.0 | 2026-09-10 | 파일 생성·삭제·이름변경의 스냅샷 표현 (#28 → D-038). ①base_content_hash·result_content_hash 두 속성의 값 집합에 부재(absent) 도입 — 빈 파일 해시와 구별되며, 부재로의 복원은 파일 삭제다 ②**previous_path 신설**(선택 · 이름변경 스냅샷 전용. 이름변경은 내용을 보존하므로 base = result) ③불변식 6(종류는 (base, result, previous_path) 로 유일 결정 — 수정·생성·삭제·이름변경. 부재→부재와 previous_path 있으면서 base ≠ result 는 존재하지 않는다. 별도 kind 속성 없음) · 불변식 7(불변식 2·4·시도 경계 롤백의 «그 파일»을 경로별 투영 전이로 읽는다 — 이름변경은 두 전이, 나머지는 한 전이. 현재 상태가 없으면 부재, 정규 파일이 아니면 충돌) ④AC-11 문면 명확화 — 「내용을 변경」 → 「변경(내용 변경·삭제·이름변경 전 경로가 테스트 경로인 이름변경)」, 예외를 「테스트 경로에 대한 생성(부재→해시)만」으로. C-05 Rationale 에 「삭제·이름변경도 변경이다 — 아니면 삭제 후 재생성으로 우회된다」 추가 |
docs/flow-permutation-cocode.md I-4 / FP-306·307 해소. Design 결정은 docs/architecture-cocode.md §4.7 DD-25(R1~R7) — 이 개정은 그 DD 가 전제한 옵션 1 을 스펙 문면에 반영한 것이다. 대안 ⓐ(삭제+생성 2건 묶음)는 중간 경계 롤백에서 파일이 양쪽 경로에 없는 상태가 생겨 기각, ⓑ(대상 제외)는 AC-11·C-02 와 모순이라 불가. 의사결정 일지 D-038 |
프로젝트 오너 |
| v3.1.0 | 2026-08-26 | Planning 단계 Analysis Gate 가 잡아낸 결함 수정 + 오너 결정 3건 반영. ①AC-02 롤백 충돌 감지 로직 버그 수정 — base_content_hash 는 편집 직전 해시이므로 에이전트 편집 후에는 현재 내용과 항상 달라, 기존 규칙대로면 모든 롤백이 충돌로 보고되어 안전장치가 무력화된다. EditSnapshot 에 result_content_hash(편집 직후 해시)를 신설하고 충돌 판정을 "현재 해시 ≠ 그 파일의 마지막 result_content_hash" 로 교체. base_content_hash 는 복원 목표로 역할 분리 ②C-05·AC-11 의 "테스트 파일" 판정을 경로 기반으로 확정 — test/ · integration_test/ · widgetbook/(오너 결정). C-05 가 Planning 에 위임했던 항목이며, 경로 기반이므로 판정이 필요 없다 ③AC-21 신설 — 워크트리 격리·에이전트 간 작업 인계를 MVP 범위 밖으로 명시(오너 결정). C-03 본문에도 반영. AC-12(한 워크스페이스 내 복수 작업 동시 진행 + 파일 잠금)는 MVP 안이며 이 제한과 무관함을 명시 |
Planning Analysis Gate: FAIL(요구사항 명확성·범위 적절성 미달, Gherkin 형식·AC 완전성 통과), Plan Quality 0.63. 게이트가 AC-02 를 "구현 불가능한 규칙"으로 판정 | 프로젝트 오너 |