풀스택 코딩 에디터 · E06

Contrarian Review — 반대 검토

확장 명세의 숨은 가정과 위험

Summary

Evaluation Date: 2026-09-16
Target: docs/seed-spec-fullstack-code-editor.md v1.0.0 (DRAFT)
Total Challenges: 15 (Critical: 2, Major: 9, Minor: 4)
검토 근거: 대상 Seed 전문 · docs/socratic-discovery-fullstack-code-editor.md · docs/decision-log-fullstack-code-editor.md · 상위 docs/seed-spec-cocode.md(AC-02 · AC-12 원문) · 상위 docs/decision-log-cocode.md(D-036 · D-045 · D-066 · D-067 · D-069) · docs/architecture-cocode.md C5 · package/lsp/lib/src/client/cocode_lsp_client.dart(진단 폐기 카운터) · app/cocode/lib/main.dart(슬롯 채움 현황) · docs/flutter-ide-analysis-fullstack-code-editor.md §6 · docs/spec-evaluation-cocode.md §반복된 실패 패턴
기법 적용: Assumption Attack(C-01~C-05 · A-01~A-09) · Scale Challenge(5만 파일 · 100 탭 · 20 세션 · 10 MB 파일 · 서버 5개 모노레포) · Removal Test(엔티티 3종 · Must AC-01~AC-10) · Historical Challenge(flutter_ide §6 · 상위 8라운드 게이트 실패 패턴)
규칙: Response 가 있어도 Evidence(Seed 문면 위치)가 비어 있으면 Unresolved 다.
저자 응답(2026-09-16, v1.1.0 · v1.1.1 교정): 15건 전부 응답 · Evidence 기재. Round 2 독립 감사(scratchpad/audit-round2.md §C): VALID 14 · WEAK 1(CH-009 — 환경변수 근거 서술 오류, v1.1.1 에서 교정) · INVALID 0. Resolved 15(그중 잔여 위험 Accepted 병기 4건: CH-002 개별 확답 부재 · CH-005 상위 AC-16 종속 · CH-012 May 존치 · CH-015 상위 DRAFT 위에 쌓는 위험). Critical 2건 미해소 0.

Critical 반론 (2건)

CH-001: C-03/AC-10 의 "기존 충돌 메커니즘 재사용" 주장이 상위 문면과 다르다 — 사람 편집이 롤백에 조용히 지워지는 경로가 열려 있다

Type: Assumption Attack (C-03 · A-07) + Historical Challenge
Target: §2 C-03 · §4 AC-10 · D-009
Severity: Critical
Challenge: C-03 은 "그 파일에 대한 에이전트의 다음 편집은 상위 cocode/AC-02 의 해시 불일치 규칙으로 충돌 처리된다"고 쓴다. 그러나 상위 AC-02 원문은 롤백 시점의 규칙이며, 대조 대상은 "그 파일에 대해 롤백 대상 작업이 남긴 마지막 EditSnapshot 의 result_content_hash"(D-036 으로 작업 범위 한정)다. 시나리오: 실행 중 작업 T 가 lib/a.dart 에 스냅샷 S1 을 남김 → 사람이 같은 파일을 편집·저장(C-03: 스냅샷 없음, 리스 없음) → T 가 다시 편집해 S2 를 남김(S2.base = 사람 편집본) → 사용자가 T 를 "작업 시작 직전"으로 롤백. 사전검사는 현재 해시 == S2.result 이므로 충돌 없이 통과하고, 파일은 S1.base 로 돌아가 사람의 편집이 고지 없이 소멸한다. 또한 AC-10 의 Given "편집 리스가 걸린 파일"은 D-045 에 따라 리스 구간이 [게이트 연산 호출 직전, 반환 직후] 한 번뿐이라 사람이 그 순간을 만날 확률이 사실상 0 — AC-10 은 존재하지 않는 상황을 판정하고, 진짜 위험 구간(실행 중 작업의 두 스냅샷 사이)은 어떤 AC 도 다루지 않는다
Expected Impact: "ADE 안전망 위의 에디터"(Discovery §2.3 차별화 2)가 사람 작업 손실 경로를 내장한 채 잠긴다. C-03 은 불변 층위라 잠긴 뒤 고칠 수 없다. flutter_ide 를 "구조적 데이터 손실"로 폐기 판정한 문서가 같은 부류의 결함을 Must 로 승격하는 셈이다
제안 해소안: (a) C-03 의 마지막 문장을 "…에이전트의 다음 편집은 base_content_hash 가 그 작업의 직전 result_content_hash 와 불일치함을 기록하고, 그 작업의 롤백은 사람 편집 구간을 경계로 충돌로 제시된다"처럼 실제 존재하는 메커니즘(base/result 해시 불연속)으로 다시 쓰거나, 존재하지 않으면 상위 Seed 개정 요청(D-0xx)으로 이관하고 이 문서는 "사람 편집 이후 작업의 롤백 동작은 상위 결정 대기"로 표기 (b) AC-10 의 Given 을 "실행 중인 DelegatedTask 가 EditSnapshot 을 남긴 파일"로 바꾸고 리스 표시가 아니라 작업 표시를 요구 (c) D-009 를 "오너 재확인 대상"에서 "상위 파이프라인 결정 필요"로 승격
Response: 지적이 맞다 — v1.0.0 의 '기존 충돌 메커니즘 재사용'은 상위 AC-02 문면(롤백 대상 작업의 마지막 스냅샷 result 해시만 대조)과 달랐고, 두 스냅샷 사이의 사람 편집이 롤백에 조용히 지워지는 경로가 열려 있었다. v1.1.0 은 (a) §0 에 '체인 불연속'을 정의하고 C-03 이 실제 메커니즘(연속 스냅샷의 base/result 해시 불일치)을 명시 (b) AC-10 의 Given 을 '실행 중인 DelegatedTask 가 EditSnapshot 을 남긴 파일'로, 요구를 리스 표시가 아니라 작업 표시로 교체(D-045 리스 구간은 게이트 호출 한 번이라 사람이 만날 수 없다는 지적 수용) (c) AC-22(Must-Not) 신설 — 사람 편집 구간을 건너뛰는 자동 롤백 경로 없음. 이 조건은 상위 AC-02 의 충돌 조건을 하나 더하는 강화이며 완화가 아니다. 구현은 상위 RollbackPrecheck 확장을 요구하므로 D-013 으로 '상위 파이프라인 결정 필요'를 표기했다(제안 (c) 수용).
Evidence: seed v1.1.0 §0 '체인 불연속' · §2 C-03 · §4 AC-10 · AC-22 · decision-log D-013
Status: Resolved

CH-002: 불변 제약 C-02(Dart 풀스택)와 Core Problem 이 오너의 개별 확답 없이 "계속 진행" 한 마디로 잠기려 한다 — 상위 CH-001 의 재현

Type: Assumption Attack (A-01 · A-02 · C-02) + Historical Challenge
Target: §1 Core Problem · §2 C-02 · §5 A-01/A-02 "Verified" · D-001~D-008
Severity: Critical
Challenge: 상위 Contrarian CH-001 은 "C-01 이 미해결 입력 위에 세워짐"을 Critical 로 잡았고, 그 스펙은 8라운드 동안 게이트를 넘지 못했다. 이 문서는 H1/H2 갈림(Discovery §0)을 "권장안 수용"으로 닫았는데, 그 수용의 실체는 오너의 "계속 진행 해줘" 한 문장이다. 오너가 실제로는 다국어(H2)를 염두에 뒀다면 잠긴 Core Problem 은 진화할 수 없어(SEED_SPEC_SCHEMA) 문서 전체를 새로 써야 한다. 더구나 §5 는 A-01·A-02 를 "Verified(오너 권장안 수용)"로 적는다 — 결정을 검증으로 승격한 것이며, 상위 spec-evaluation 이 경계한 자기 인용 패턴(앞 문서의 제안값이 다음 문서에서 확정값으로 둔갑)과 같은 형태다
Expected Impact: 잠금 뒤 H2 로 밝혀지면 Specification 단계 전량 재작업. 잠그지 않으면 Specification Gate M-02 실패. 어느 쪽이든 게이트 판정이 "오너 한 마디"의 해석에 걸려 있다
제안 해소안: (a) A-01·A-02 의 상태를 "Decided(오너 일괄 수용, 개별 확답 없음)"로 고쳐 Verified 와 구분 (b) §6 Evolution Log 또는 Metadata 에 "잠금 조건: Q1(H1) 오너 개별 확답" 한 줄을 두고, 확답 전에는 LOCKED 대신 DRAFT-PROVISIONAL 로 게이트에 제출 — M-02 는 실패로 기록하되 사유를 명시 (c) 최소한 Q1 하나만이라도 오너에게 되물어 확답을 받는다(AskUserQuestion 1건)
Response: A-01 을 'Unverified — 오너 일괄 수용으로 잠정 결정, 개별 확답 대기'로 고쳐 결정과 검증을 분리했고(제안 (a)), Metadata 에 '잠금 근거' 줄을 두어 H1 확정 근거가 '계속 진행' 일괄 수용임과 H2 정정 시 문서 폐기를 명시했다(제안 (b)의 취지). A-02 는 상위 cocode/AC-03 문면(개발자 표면은 ADE 출시 조건)으로 실제 검증된다. 오너 개별 확답(제안 (c))은 이 세션이 비대화형이라 받을 수 없어, 평가 보고서와 최종 보고에 '오너 재확인 1순위'로 올린다. 잠금은 잠정 결정 표기 위에서 진행한다.
Evidence: seed v1.1.0 Metadata '잠금 근거' · §5 A-01 · A-02 · decision-log D-014
Status: Resolved — 잔여 위험 Accepted(개별 확답 부재)

Major 반론 (9건)

CH-003: "풀스택 워크스페이스" 정의가 도그푸딩 워크스페이스(unibook)를 배제한다

Type: Assumption Attack (A-08) + Scale Challenge(서버 5개 모노레포)
Target: §0 Glossary "풀스택 워크스페이스" · A-08 · AC-08 · AC-11
Severity: Major
Challenge: §0 은 "루트 바로 아래에 Flutter 앱 · Serverpod 서버 · Jaspr 웹 중 둘 이상"으로 정의한다. 그런데 D-007/A-08 이 지정한 unibook(이 리포가 그 거울이다)은 app/cocode · backend/cocode_server · feature/console 처럼 프로젝트가 한 단계 아래에 있다. 정의대로면 도그푸딩 워크스페이스는 풀스택 워크스페이스가 아니고, serverpodStart 템플릿(AC-08)이 어느 디렉터리를 향해야 하는지도 정의에서 나오지 않는다. 서버 5개 모노레포에서는 "둘 이상"이 성립해도 어느 서버가 실행 대상인지 정의가 답하지 않는다
Expected Impact: A-08 의 검증 환경이 정의상 대상 밖 → 도그푸딩 실험(§1.5)의 결과가 이 문서에 귀속되지 않음. AC-08 템플릿의 working_dir 결정이 Design 으로 새고, 상위 D-052(플랫폼 디렉터리는 루트 바로 아래)와 같은 실수를 반대 방향으로 반복
제안 해소안: 정의를 "워크스페이스 안에서 pubspec.yaml 이 있는 디렉터리 가운데 Flutter 앱 · Serverpod 서버 · Jaspr 웹으로 판정되는 것이 둘 이상"으로 바꾸고, 판정 입력(예: serverpod 의존 여부 · flutter SDK 의존 여부 · jaspr 의존 여부)을 명시. RunConfiguration.working_dir 는 판정된 프로젝트 디렉터리 중 하나를 가리킨다고 불변식에 추가
Response: §0 '풀스택 워크스페이스'를 'pubspec.yaml 이 있는 디렉터리(깊이 무관) 가운데 Flutter 앱 · Serverpod 서버 · Jaspr 웹으로 판정되는 프로젝트 디렉터리가 둘 이상'으로 바꾸고 판정 입력 세 가지를 명시했다. '프로젝트 디렉터리' 용어를 신설하고 RunConfiguration 불변식 (1)을 'working_dir 은 프로젝트 디렉터리 중 하나'로 고쳤다. unibook(app/ · backend/ 아래)은 이 정의로 포함된다.
Evidence: seed v1.1.0 §0 '풀스택 워크스페이스' · '프로젝트 디렉터리' · §3 RunConfiguration 불변식 (1) · decision-log D-015
Status: Resolved

CH-004: AC-07 의 진단 표시가 상위 #60 AC3 · C5 와 맞닿아 있는데 소유 계약이 문면에 없다

Type: Assumption Attack + Removal Test (AC-07)
Target: §4 AC-07
Severity: Major
Challenge: 상위 #60 AC3 은 "자가 검증 ④ 에 LSP 진단을 쓰지 않는다(정본은 dart analyze 프로세스 결과)"이고 architecture C5 는 toolchain→lsp 의존을 금지한다. 현행 CocodeLspClient 는 publishDiagnostics 를 세면서 버린다(droppedDiagnosticNotifications). AC-07 은 진단을 문제 목록과 거터에 표시하라고 하면서, 그 진단이 (a) 어느 계약으로 에디터에 닿는지 (b) 자가 검증 ④ 와 절대 섞이지 않는다는 경계가 어디에 있는지 말하지 않는다. Discovery §4.2 는 "별도 DiagnosticsSink 계약"을 제안했지만 Seed 에는 없다
Expected Impact: 구현자가 가장 쉬운 길(lsp 의 진단을 toolchain 의 ④ 실행자에 흘려 보내기)을 택하면 C5 위반 + 상위 #60 AC3 위반. 반대로 아무도 소유하지 않으면 AC-07 은 미구현으로 남는다
제안 해소안: AC-07 Then 에 "진단은 자가 검증 ④ 의 입력이 아니다(상위 #60 AC3)"를 한 줄 추가하고, §3 에 진단의 소유자(에디터 측 DiagnosticsSink — 상위 SemanticTokenSink 와 같은 결)를 명시하거나 D-012 이관 목록에 "진단 계약의 소유 패키지"를 추가
Response: §0 에 '진단' 용어를 신설해 '에디터 표시 전용, 상위 자가 검증 ④ 의 입력이 아님(상위 #60 AC3)'을 정의하고, AC-07 Then 에 같은 경계와 '언어 서버 부재 · 종료 시 서버 상태 표시 · 편집 계속'을 넣었다. 진단 수신 계약의 소유 패키지(에디터 측 sink, lsp 는 전달만)는 D-017 로 Design 이관 목록에 올렸다.
Evidence: seed v1.1.0 §0 '진단' · §4 AC-07 · decision-log D-017
Status: Resolved

CH-005: 터미널 Must(AC-09)와 C-04 가 상위 AC-16(6조합 전부 미충족)에 묶여 있고, 새 표면 4종은 미충족 조합 수만 늘린다

Type: Assumption Attack (A-04 · C-04) + Historical Challenge (D-067 · D-069)
Target: §2 C-04 · §4 AC-09 · §5 A-04
Severity: Major
Challenge: D-069 는 상위 AC-16 을 3-OS × 2표면 = 6조합 전부 ❌ 로 닫았고, 입력기 축은 러너에서 측정 불가(unavailable)다. C-04 는 여기에 검색/치환 패널 · 명령 팔레트 · 실행 구성 편집 입력을 더해 판정 대상을 늘리면서 "판정 기준을 새로 정의하지 않는다"고만 한다. 즉 이 문서의 Must 집합은 상위가 풀지 못한 게이트에 종속되며, 문서 스스로 그 종속을 인정하는 문장이 §4 에 없다. D-067 이 지적한 "가드가 실기기에서 한 번도 발동할 수 없다"(TextInputClient 구현 0건)는 상태도 AC-09 의 PTY 백엔드가 그대로 물려받는다
Expected Impact: AC-09 는 PTY 만으로 판정 가능해 보이지만 C-04 에 의해 IME 판정을 함께 지므로, 상위 AC-16 이 열릴 때까지 "MET" 이 될 수 없다. 첫 릴리스 Must 의 출시 가능성이 이 문서 밖의 결정에 걸린다
제안 해소안: (a) AC-09 의 판정 범위를 "PTY · 크기 조절 · 키 전달 · 다중 세션"으로 한정하고 IME 는 상위 AC-16 의 판정 대상임을 AC-09 Then 끝에 명시(분리 판정) (b) §5 A-04 의 검증 방법에 "실기기 입력기 측정은 상위 D-069 ⓐ 사유로 러너에서 불가 — 사람 수동 재생 필요"를 적어 자동화 착시를 막음
Response: AC-09 마지막 문장에 '한글 IME 판정은 이 항목의 대상이 아니라 상위 cocode/AC-16 의 대상이다(분리 판정)'를 넣고 C-04 에도 분리 판정 원칙을 명시했다(제안 (a)). A-04 의 검증 방법에 '실기기 입력기 측정은 상위 D-069 ⓐ 사유로 러너에서 불가 — 사람 수동 재생 필요'를 적었다(제안 (b)). 상위 AC-16 종속 자체는 이 문서가 해소할 수 없어 Accepted 로 남긴다.
Evidence: seed v1.1.0 §2 C-04 · §4 AC-09 마지막 문장 · §5 A-04
Status: Resolved — 잔여(상위 AC-16 종속) Accepted

CH-006: AC-08 "명령 내용은 설정 항목"이 판정 주체 미정을 숨긴다

Type: Assumption Attack (A-05 · D-006) + Historical Challenge(상위 "판정 주체 미정" 패턴)
Target: §4 AC-08 · §3 RunConfiguration.command_template
Severity: Major
Challenge: "설치 직후 기본 템플릿 3종이 제공된다"는 판정 가능하지만, 템플릿의 내용이 없으면 무엇이 제공된 것인지 판정할 수 없다. serverpodStart 는 serverpod CLI 4.x 가 사용자 머신에 있어야 하고(3.x 에는 start 가 없다) flutterRun 은 디바이스 인자가 없으면 대화형 선택에서 멈춘다. 상위 spec-evaluation 은 "남은 결함 대부분이 판정 주체 미정에서 온다"고 적었다 — 이 문장은 그 패턴의 축약형이다
Expected Impact: Planning 이 템플릿 내용을 정하지 않으면 AC-08 은 "빈 템플릿 3개 제공"으로도 MET 이 된다(형식 통과). 정하면 Seed 가 아니라 Planning 이 실질 인수 경계를 쥔다
제안 해소안: AC-08 에 템플릿의 최소 요건을 경계 수준으로 명시 — "각 기본 템플릿은 실행 파일과 인자 목록이 비어 있지 않고, 실행 전제(예: 필요한 CLI 의 존재)를 확인해 미충족 시 사유를 표시한다". 내용의 정본은 D-012 이관 목록에 "기본 템플릿 3종의 정본 내용 → Planning" 으로 명시
Response: AC-08 에 기본 템플릿의 최소 요건(실행 파일과 인자 목록이 비어 있지 않음 · 실행 전제 확인 · 미충족 시 사유 표시)을 경계 수준으로 명시하고, 템플릿 정본 내용은 D-017 로 Planning 이관을 명기했다.
Evidence: seed v1.1.0 §4 AC-08 · decision-log D-017
Status: Resolved

CH-007: C-02 의 "파일 단위 편집 지원까지만"은 상한도 하한도 AC 로 닫히지 않는다

Type: Removal Test + Assumption Attack (C-02)
Target: §2 C-02 · §4 (비-Dart 편집 AC 부재)
Severity: Major
Challenge: 풀스택 워크스페이스의 핵심 파일 가운데 Dart 가 아닌 것 — Serverpod 마이그레이션 SQL · config/*.yaml · Dockerfile · CI 워크플로 — 에 대해 "편집 지원"이 무엇을 뜻하는지(구문 강조? 언어 서버? 저장만?) 요구하는 AC 가 하나도 없다. AC-11 은 "1급으로 제시하지 않는다"만 판정한다. 즉 C-02 의 "까지만"은 넘어섰는지 판정할 수도(상한), 제공됐는지 판정할 수도(하한) 없다
Expected Impact: 구현이 SQL 파일을 일반 텍스트로만 열어도 C-02 위반이 아니고, 반대로 SQL 언어 서버 · 스키마 완성 · 실행 버튼까지 붙여도(1급에 가까워져도) 위반이 아니다. 불변 제약이 판정 불가
제안 해소안: Must 한 줄 추가 — "Given SQL · YAML · Dockerfile 파일을 열면, Then 확장자에 대응하는 구문 강조가 적용되고 파일을 편집·저장할 수 있다(언어 서버 연결은 Dart 이외 언어에 대해 May)". C-02 의 "까지만"을 "1급 정의(§0)의 세 요소를 제공하지 않는다"로 바꿔 판정을 §0 정의에 위임
Response: C-02 의 '까지만'을 '파일 단위 편집 지원(구문 강조 · 편집 · 저장)을 제공하고 1급 정의의 세 요소는 제공하지 않는다'로 바꿔 하한(AC-07 후단: Dart 이외 파일의 구문 강조 · 편집 · 저장)과 상한(AC-11)을 각각 판정 가능하게 했다. Dart 이외 언어 서버 연결은 AC-24(May)로 명시했다.
Evidence: seed v1.1.0 §2 C-02 · §4 AC-07 후단 · AC-24
Status: Resolved

CH-008: "무음 실패 금지"가 저장(AC-04)에만 있다 — 프로세스 기동 · 언어 서버 · PTY 생성 실패는 flutter_ide 패턴이 그대로 재현될 수 있다

Type: Historical Challenge (flutter_ide §6-c: catch 22개 중 16개 무음, 로그 0건)
Target: §4 AC-04 · AC-07 · AC-08 · AC-09
Severity: Major
Challenge: 이 문서는 flutter_ide 의 "오류가 전부 삼켜진다"를 폐기 사유로 인용하면서, 실패 표시 의무를 저장 한 곳에만 둔다. 실행 구성의 프로세스가 기동에 실패하면(실행 파일 없음 · 권한 없음) AC-08 은 "출력이 세션으로 표시된다"만 요구해 빈 세션이 남아도 통과한다. 언어 서버 크래시(AC-07)와 PTY 생성 실패(AC-09)도 마찬가지다
Expected Impact: 사용자는 "실행 버튼을 눌렀는데 아무 일도 없음"을 경험한다 — flutter_ide §6-c 의 자동저장 무음 실패와 같은 부류
제안 해소안: 실패 표시를 AC 하나로 묶어 상향 — "Given 앱이 기동한 프로세스(실행 구성 · 언어 서버 · 셸)가 시작에 실패하거나 비정상 종료하면, Then 사유(종료 코드 또는 오류 메시지)가 사용자에게 표시되며 무음으로 사라지지 않는다". TerminalSession.status 의 exited(exit_code) 가 이미 그 값을 갖고 있다
Response: AC-23(Must-Not) 신설 — 실행 구성 · 언어 서버 · PTY 기동 실패, 비정상 종료, 저장 실패가 표시 없이 사라지는 경로 없음. AC-07(서버 부재 · 종료 시 상태 표시)과 AC-08(전제 미충족 시 사유 표시)에도 개별 실패 표시를 넣었다.
Evidence: seed v1.1.0 §4 AC-23 · AC-07 · AC-08
Status: Resolved

CH-009: Removal Test — RunConfiguration 없이도 Core Problem 은 성립한다

Type: Removal Test (엔티티 RunConfiguration · AC-08)
Target: §3 RunConfiguration · §4 AC-08 · D-003
Severity: Major
Challenge: Core Problem 은 "편집·실행·검사를 한 창에서"다. AC-09 의 PTY 터미널이 있으면 사용자가 serverpod start 를 직접 쳐서 "한 창에서 실행"이 성립한다. RunConfiguration 이 추가로 주는 가치(중지 버튼 · origin 추적 · 환경변수 화이트리스트)는 문서 어디에도 "왜 첫 릴리스 Must 인가"로 적혀 있지 않다. D-003 은 권장안 수용일 뿐 근거를 담지 않는다. 한편 A-05 는 serverpod start 자체가 서버·DB·앱을 함께 띄운다고 확인했으므로, 실행 구성이 없어도 "풀스택 실행"은 CLI 한 줄이다
Expected Impact: 복잡도 계산에서 엔티티 1 + 관계 1.5 + Must 1 + 불변식 0.5 = 4 를 차지하는 항목이 제거 시험을 통과한다. 남기려면 근거가 문면에 있어야 한다
제안 해소안: (a) 첫 릴리스에서 AC-08 을 May 로 내리고 RunConfiguration 을 §3 에서 빼거나 (b) 남긴다면 AC-08 의 Then 에 실행 구성만이 주는 판정 가능한 가치(예: "실행 중인 프로세스가 세션 목록에 origin 과 함께 나타나고 한 번의 조작으로 종료된다")를 명시하고 D-003 에 근거 한 줄을 추가
Response: RunConfiguration 을 유지하되 AC-08 Then 에 실행 구성만이 주는 판정 가능한 가치를 명시했다 — 세션 목록에 origin 과 함께 표시, 한 번의 조작으로 종료, 실행 전제(CLI 존재 · 디바이스 지정) 사전 확인과 미충족 사유 표시. (Round 2 교정: v1.1.0 응답이 든 "사용자 명령 셸은 전체 환경을 상속한다"는 상위 architecture DD-23a 문면 — 화이트리스트는 프로파일과 무관하게 사람 터미널에도 적용 — 과 충돌해 삭제했다. AC-08 의 환경변수 문장 자체는 참이지만 실행 구성 고유의 가치가 아니다.) D-003 에 같은 근거를 추가했다. 첫 릴리스 Must 여부는 오너 권장안 Q3 수용에 따른다.
Evidence: seed v1.1.1 §4 AC-08 Then · decision-log D-003(v1.1.0 추가 근거, v1.1.1 교정)
Status: Resolved

CH-010: Scale — 20 세션 × 무제한 scrollback

Type: Scale Challenge
Target: §3 TerminalSession 불변식 (2) · "수치의 출처"
Severity: Major
Challenge: 불변식 (2)는 exited 세션의 scrollback 을 "닫기 전까지 유지"하고, 문서는 상한 수치를 쓰지 않는다(원칙상 옳다). 그러나 상한이 존재한다는 사실조차 없으면 flutter run --verbose 를 20 세션에서 돌린 뒤 닫지 않은 사용자의 메모리는 무한히 자란다. flutter_ide 조차 maxLines: 10000(output_panel.dart:31)은 두었다
Expected Impact: 값을 안 쓰는 원칙이 "상한 없음"으로 읽혀 구현된다. 상위 AC-08 이 "설치 직후 양의 유한한 값을 갖는다(값은 설정)"로 같은 문제를 푼 선례가 있다
제안 해소안: TerminalSession 불변식 (2)를 "scrollback 은 설치 직후 양의 유한한 상한을 가지며(값은 설정 항목), 상한을 넘으면 오래된 줄부터 버린다"로 수정 — 상위 AC-08 의 형식 그대로
Response: TerminalSession 불변식 (2)를 삭제(S-001)하고 AC-09 에 '종료된 세션의 출력은 닫기 전까지 남으며, scrollback 은 설치 직후 양의 유한한 상한(값은 설정 항목)을 가져 넘치면 오래된 줄부터 버린다'를 넣었다 — 상위 cocode/AC-08 의 형식.
Evidence: seed v1.1.0 §4 AC-09 · §4 수치의 출처
Status: Resolved

CH-011: AC-01 은 "어느 슬롯에도 플레이스홀더가 남지 않는다"고 하면서 workbench 슬롯의 내용을 정의하지 않는다

Type: Assumption Attack (AC-01)
Target: §4 AC-01 · §0 "셸 통합"
Severity: Major
Challenge: CocodePaneId 는 navigation · workbench · editorStack · terminal · inspector 5종이고 현행 main.dart 는 navigation · inspector 만 실제 위젯을 넣는다. AC-01 은 세 슬롯의 내용만 정의하고 workbench 는 언급하지 않은 채 "어느 슬롯에도" 플레이스홀더가 없어야 한다고 요구한다 — workbench 에 무엇이 들어가야 통과인지 판정 불가
Expected Impact: 구현자가 workbench 를 빈 컨테이너로 두면 통과인지, 텍스트 하나라도 있으면 플레이스홀더인지 해석이 갈린다
제안 해소안: AC-01 에 "workbench 는 editorStack 과 terminal 을 담는 컨테이너이며 자체 내용을 갖지 않는다"를 명시하거나, 판정 범위를 "navigation · editorStack · terminal 세 슬롯"으로 한정
Response: AC-01 에 'workbench 는 editorStack 과 terminal 을 담는 컨테이너로서 자체 내용을 갖지 않는다'를 명시했다.
Evidence: seed v1.1.0 §4 AC-01
Status: Resolved

Minor 반론 (4건)

CH-012: May 8종(AC-14~AC-21)이 §4 의 38%를 차지하고, AC-14 안에 미결("Design 결정")이 들어 있다

Type: Removal Test
Target: §4 AC-14~AC-21
Severity: Minor
Challenge: May 는 복잡도에 들어가지 않지만 읽기 표면과 모호성 평가 대상에는 들어간다. AC-14 는 Then 안에 "접속 비밀의 저장 위치는 Design 결정"을 품어 인수 경계가 미결을 포함한다. 8건은 사실상 Discovery §4.2 트랙 C·D 의 목록 복사다
Expected Impact: 모호성 평가에서 완전성·참조 명확성 감점의 표적이 되고, 실제 판정에는 기여하지 않는다
제안 해소안: May 8종을 "후속 후보 목록"으로 §4 밖(부록 또는 planning-inputs)으로 옮기고 §4 에는 Must · Must-Not 만 남기거나, 남기더라도 AC-14 의 미결 문구를 D-012 로 옮긴다
Response: AC-14 에서 '접속 비밀의 저장 위치는 Design 결정' 문구를 제거했다(이미 D-012 에 있다). May 8건의 부록 분리(S-007)는 flat 규칙 논쟁 위험으로 보류했으므로 May 존치는 Accepted 다.
Evidence: seed v1.1.0 §4 AC-14 · simplifier-review S-007 Defer
Status: Resolved(부분) — May 존치 Accepted

CH-013: Scale — 100 탭 · dirty 버퍼 무한 보유 · 앱 종료 시 처분 규칙 부재

Type: Scale Challenge + Assumption Attack (DocumentBuffer 불변식 2)
Target: §3 DocumentBuffer 불변식 (2) · §4 AC-03
Severity: Minor
Challenge: 불변식 (2)는 dirty 버퍼가 사용자 처분 전에 사라지지 않는다고 하지만, 처분을 요구하는 AC 는 탭 닫기(AC-03)뿐이다. 워크스페이스 전환 · 앱 종료 시 dirty 버퍼 100개의 처분 규칙이 없다(세션 복원 AC-20 은 May)
Expected Impact: 앱 종료 시 조용히 폐기되면 불변식 위반, 100개 다이얼로그를 띄우면 사용 불가 — 둘 다 문서가 막지 않는다
제안 해소안: AC-03 의 When 에 "워크스페이스를 닫거나 앱을 종료하려 하면"을 추가하고 Then 을 "dirty 버퍼 목록을 한 번에 제시해 저장·폐기·취소를 일괄 선택"으로 확장
Response: AC-03 의 When 에 '워크스페이스를 닫거나 앱을 종료하려 하면'을 추가하고 Then 에 'dirty 버퍼 전체 목록을 한 번에 제시해 일괄 저장 · 일괄 폐기 · 취소'를 넣었다.
Evidence: seed v1.1.0 §4 AC-03
Status: Resolved

CH-014: A-05 는 "Verified" 인데 검증 방법이 Design 결정이다 — 사실과 가정이 한 행에 섞였다

Type: Historical Challenge(상위 자기 인용 패턴)
Target: §5 A-05
Severity: Minor
Challenge: "serverpod start 가 존재한다"는 블로그로 확인된 사실이고, "beta/stable 차이를 설정으로 흡수한다"(D-006 의 전제)는 미검증 가정이다. 후자를 Design 으로 이관했다고 해서 전자의 Verified 가 후자를 덮지 않는다. 가정 목록에서 실제로 위험한 쪽이 사라졌다
Expected Impact: 복잡도 산정에서 미검증 가정 1건이 빠지고, Serverpod 4 stable 이 명령을 바꿀 때 어떤 가정이 깨졌는지 추적할 행이 없다
제안 해소안: A-05 를 사실 행(Verified)과 가정 행(Unverified — "템플릿 스키마가 beta/stable 명령 차이를 설정 값만으로 흡수한다")으로 분리
Response: A-05 를 사실 행(Verified — serverpod start 존재)과 A-10 가정 행(Unverified — 템플릿 스키마가 beta/stable 명령 차이를 설정 값만으로 흡수)으로 분리했다.
Evidence: seed v1.1.0 §5 A-05 · A-10
Status: Resolved

CH-015: C-01 "상위 개정을 추종한다"가 이 문서의 진화 불가 규칙과 충돌한다

Type: Assumption Attack (C-01)
Target: §2 C-01 · §1 Core Problem
Severity: Minor
Challenge: 상위 Seed 는 DRAFT 이고 게이트를 넘지 못했다. 상위 C-03(Dart/Flutter 전용)이 개정되면 이 문서의 C-02 와 Core Problem 의 "Dart 풀스택"도 바뀌어야 하는데, Core Problem 과 불변 제약은 진화 프로토콜로 바꿀 수 없다. "추종한다"는 약속은 지킬 수단이 없다
Expected Impact: 상위 개정 시 이 문서는 추종이 아니라 폐기·재작성이 된다. 문면이 그 사실을 감춘다
제안 해소안: C-01 의 "추종하며"를 "상위의 C-01~C-05 가 개정되면 이 문서는 새 Seed 로 대체된다(진화가 아니라 재작성)"로 정직하게 고친다
Response: C-01 을 Metadata '상속' 줄로 옮기면서(S-002) '추종한다'를 '상위의 C-01~C-05 가 개정되면 이 문서는 진화가 아니라 새 Seed 로 대체된다'로 고쳤다. 상위 DRAFT 위에 쌓는 위험 자체는 Accepted 다.
Evidence: seed v1.1.0 Metadata '상속' 줄
Status: Resolved — 잔여 위험 Accepted

위험 인수 후보 (저자가 Accepted 로 처분할 수 있는 항목)

CH-005 의 IME 종속은 상위 파이프라인과 공유하는 리스크다 — 이 문서 단독으로 해소할 수 없으므로 분리 판정(제안 (a))을 적용한 뒤 잔여를 Accepted 로 기록하는 것이 정직하다.
CH-015 는 문면 교정으로 닫히지만, 상위 DRAFT 위에 쌓는 위험 자체는 Accepted 로 남는다.

Generated by cc-spec:challenge (contrarian) · 2026-09-16 · 대상 v1.0.0