Simplifier Review — 단순화 검토

대상: docs/seed-spec-fullstack-code-editor.md v1.0.0 DRAFT · 검토일 2026-09-16 · 검토자: cc-spec simplifier 페르소나(같은 세션 fork, 독립 계수) 상위 Seed(docs/seed-spec-cocode.md)의 항목은 이 문서의 복잡도에 세지 않는다 — C-01 이 참조로 상속할 뿐이다. 다만 상위와의 중복은 아래에서 표시한다.

Complexity Measurement (v1.0.0 기준)

판정: Caution~Excessive 경계 — 단순화 검토 필요. 평가 프로토콜 Stage 2c 는 "복잡도 ≤ 30" 을 요구하므로, 아래 제안 중 최소 한 건(S-001 또는 S-003)을 받아들여야 통과선 안쪽으로 들어온다.

상위 문서와의 중복 (계수 무관, 표면 정리 대상)

• AC-12(Must-Not)는 C-05 를, AC-13(Must-Not)은 C-03 후단을 거의 문면 그대로 재진술한다. 상위 파이프라인은 Must-Not 을 "부재 증명 가드"(D-072)로 쓰므로 검증 훅 가치는 있다.
• AC-10(Must)은 C-03 의 두 번째 문장을 Given/When/Then 으로 옮긴 것이다.
• C-01 은 제품 제약이 아니라 문서 관계(상속 조항)다. 제약 표에 두면 "완화 금지"가 잠기지만, 계수상 0.5 를 차지한다.

Simplification Proposals

S-001: TerminalSession 불변식 (2) 삭제 — 스크롤백 유지는 UX 동작이지 도메인 불변식이 아니다

• Target: §3 TerminalSession Invariants (2) "exited 세션의 scrollback 은 사용자가 세션을 닫기 전까지 유지된다"
• Current (Before): 불변식 2건
• Proposed (After): 불변식 1건(C-05 집행만). 스크롤백 유지는 Design 단계 UX 스펙 또는 AC-09 Then 절의 한 구("종료된 세션의 출력은 닫기 전까지 남는다")로 이동
• Complexity Change: 30.5 → 30.0 (Δ −0.5)
• Trade-off: 불변식으로서의 "잠금" 보호를 잃는다. 대신 AC-09 에 넣으면 Must 문면 안에서 검증 가능해 손실이 작다
• Decision: Accept — 불변식 (2) 삭제. AC-09 Then 으로 이동하되 CH-010 을 함께 닫기 위해 '양의 유한한 상한(값은 설정)' 형식으로 기재

S-002: C-01(상속 조항)을 §2 제약 표에서 Metadata 로 이동

• Target: §2 C-01
• Current (Before): 불변 제약 5건, 그중 1건은 제품이 아니라 문서 관계
• Proposed (After): Metadata 의 Parent 줄에 "cocode/C-01~C-05 · Must-Not AC-04/05/21/24 를 상속하며 완화하지 않는다"를 옮기고 §2 는 C-02~C-05 4건. 번호는 재부여하지 않고 C-01 을 "Metadata 로 이동" 표기로 남겨 인용 안정성 유지
• Complexity Change: 30.0 → 29.5 (Δ −0.5, S-001 누적 기준)
• Trade-off: 상속 조항이 "Immutable after locking" 보호 밖으로 나간다. 상위 evolve 추종 의무가 느슨해질 위험 — Metadata 에 "이 줄은 §2 와 같은 잠금 규칙을 따른다"를 병기하면 완화됨
• Decision: Accept — C-01 을 Metadata '상속' 줄로 이동, '§2 와 같은 잠금 규칙' 병기. CH-015 문면 교정 동시 반영

S-003: A-06 을 §5 에서 결정 일지로 이관 — 어떤 Must 도 이 가정에 의존하지 않는다

• Target: §5 A-06 "P1 은 DB 브라우저 · API 클라이언트를 에디터 안에서 원한다"
• Current (Before): 미검증 가정 3건(×2 = 6)
• Proposed (After): 미검증 가정 2건(A-03 · A-04). A-06 은 May 항목 AC-14·AC-15 의 채택 근거이므로 D-003(첫 릴리스 범위)에 "도그푸딩 결과로 판단" 문장으로 기록하고 §5 에서 제거. §4 의 Must 10건 중 A-06 에 의존하는 항목은 0건
• Complexity Change: 29.5 → 27.5 (Δ −2.0)
• Trade-off: 가정 추적이 Seed 밖으로 나가 /cc-spec:status 가 이 가정의 검증 상태를 읽지 못한다. May 항목 자체는 §4 에 남으므로 범위 정보는 손실 없음
• Decision: Accept — A-06 을 §5 에서 제거하고 D-003 에 '도그푸딩 결과로 판단' 문장으로 기록. Must 의존처 0건 확인

S-004: AC-10 을 삭제하고 C-03 의 검증은 Planning BDD 로 — 재진술 제거

• Target: §4 AC-10 (Must)
• Current (Before): Must 10건, 그중 AC-10 은 C-03 두 번째 문장의 GWT 재진술
• Proposed (After): Must 9건. C-03 은 그대로 두고, "리스 상태 표시 · 저장 비차단 · 스냅샷 없음"의 판정은 Planning 의 BDD 시나리오로 내린다(AC-13 이 "스냅샷 없음"을 이미 Must-Not 으로 잡고 있다)
• Complexity Change: 27.5 → 26.5 (Δ −1.0)
• Trade-off: D-009(진행자 판단, 오너 재확인 대상)의 결정이 §4 에서 보이지 않게 된다 — 오너가 뒤집어야 할 항목이 제약 표 깊숙이 숨는다. 핵심 가치 보호 관점에서 Reject 를 권한다: AC-10 은 "사람 편집이 에이전트에 종속되지 않는다"는 이 제품의 경계 자체다
• Decision: Reject — 핵심 가치(사람 편집의 비종속) 경계. CH-001 로 Given 을 '작업이 스냅샷을 남긴 파일'로 교정해 유지

S-005: AC-12 · AC-13(Must-Not)을 하나의 부재 증명 행으로 병합

• Target: §4 AC-12 · AC-13
• Current (Before): Must-Not 3건(AC-11 · AC-12 · AC-13)
• Proposed (After): Must-Not 2건 — AC-12 를 "Given 앱의 자체 명령 기동과 사람 편집 저장 경로를 검사할 때, When 코드 스캔 가드를 실행하면, Then ⓐ 사용자 터미널 stdin 에 명령을 쓰는 경로와 ⓑ 사람 편집이 EditSnapshot 을 만드는 경로가 모두 존재하지 않는다"로 합침
• Complexity Change: Δ 0 (Must-Not 은 미계수) — 읽기 표면만 21행 → 20행
• Trade-off: 두 가드가 한 AC 에 묶여 실패 시 어느 쪽인지 AC 단위로 구분되지 않는다. 이득이 작아 Defer 권장
• Decision: Defer — 실패 시 AC 단위 구분 손실 대비 이득이 작음

S-006: Verified 이면서 어떤 항목도 의존하지 않는 가정 A-05 · A-08 · A-09 정리

• Target: §5 A-05(serverpod start 존재) · A-08(unibook) · A-09(flutter_ide 미복사)
• Current (Before): 가정 9건(Verified 6)
• Proposed (After): A-05 는 AC-08 템플릿 serverpodStart 의 근거이므로 유지. A-08 · A-09 는 §4 어디에도 의존처가 없다 — 결정 일지(D-007 · Discovery A-F6)로 충분하므로 제거해 가정 7건
• Complexity Change: Δ 0 (Verified 미계수) — 읽기 표면 감소
• Trade-off: 인터뷰 Level 2 "전량" 승계 원칙(§5 머리말)과 어긋난다. 머리말을 "Level 2 중 §4 에 의존처가 있는 것"으로 고쳐야 함
• Decision: Accept — A-08 · A-09 제거(D-007 · Discovery A-F6 이 근거 보유). §5 머리말을 '§4 에 의존처가 있거나 잠금 근거인 것'으로 수정. A-05 유지

S-007: May 8건(AC-14~AC-21)을 §4 에서 "후보 범위" 부록으로 분리

• Target: §4 AC-14 ~ AC-21
• Current (Before): §4 21행 중 8행이 첫 릴리스 밖 May
• Proposed (After): §4 는 Must 10 + Must-Not 3 의 13행. May 8건은 "§4.1 후보 범위(May — 도그푸딩 결과로 순서 결정, D-003)"로 같은 ID 를 유지한 채 분리
• Complexity Change: Δ 0 — 읽기 표면과 평가자의 스캔 범위만 감소
• Trade-off: 스키마는 "One flat table" 을 요구한다(SEED_SPEC_SCHEMA §4). 부록 분리는 M-06/M-07 기계 검사에는 영향이 없으나 "flat" 규칙 해석 논쟁을 부를 수 있다. Defer 권장
• Decision: Defer — SEED_SPEC_SCHEMA 'One flat table' 규칙 논쟁 위험. AC-14 의 미결 문구만 제거(CH-012)

S-008: 정의만 있고 쓰이지 않는 §0 용어 2건 삭제

• Target: §0 "풀스택 워크스페이스" · "셸 통합"
• Current (Before): §0 11행, 그중 2행은 본문 참조 0회(grep 실측)
• Proposed (After): "풀스택 워크스페이스"는 §1 Core Problem 에서 실제로 사용하거나 삭제, "셸 통합"은 AC-01 이 참조하도록 문구를 바꾸거나 삭제
• Complexity Change: Δ 0
• Trade-off: 없음(미사용 정의)
• Decision: Accept — '풀스택 워크스페이스'는 §1 Core Problem · AC-08 · AC-14 에서 사용(정의도 CH-003 으로 교체), '셸 통합'은 AC-01 이 참조하도록 §0 문구 수정

Summary

• Total proposals: 8 (복잡도에 영향: S-001 · S-002 · S-003 · S-004 4건 / 표면 정리: S-005 ~ S-008 4건)
• Complexity if all accepted: 30.5 → 26.5 (Caution)
• Complexity if S-001 + S-003 만 수용(권장 최소): 30.5 → 28.0 (Caution, ≤ 30 충족)
• Complexity if S-001 + S-002 + S-003 수용: 30.5 → 27.5
• Recommendation: Simplification review 필요 — 최소 S-001 · S-003 수용으로 통과선(≤ 30) 안쪽 진입. S-004 는 핵심 가치(사람 편집의 비종속) 보호를 위해 Reject 권장. S-005 · S-007 은 Defer, S-006 · S-008 은 표면 정리로 Accept 무방.
• 핵심 가치 보호 확인: 어떤 제안도 §1 Core Problem(한 창 편집·실행·검사 + 플레이스홀더 해소)을 푸는 Must(AC-01~AC-09)를 건드리지 않는다.

저자 처분 후 (v1.1.0, 2026-09-16)

• 처분: Accept 5(S-001 · S-002 · S-003 · S-006 · S-008) · Reject 1(S-004) · Defer 2(S-005 · S-007)
• 저자 추가 병합 2건(D-016): AC-02(디렉터리 트리) → AC-01(셸 통합 — 슬롯 내용의 일부) · AC-05(외부 변경) → AC-04(버퍼-디스크 동기화). 번호는 재사용하지 않고 표 머리말에 기록
• Contrarian 반영으로 늘어난 항목: Must-Not AC-22 · AC-23, May AC-24, 미검증 가정 A-01(잠정 결정) · A-10(A-05 분리) — Must 는 늘리지 않았다
• 저자 예상 복잡도(v1.1.0): 엔티티 3 + 관계 4×1.5 + 제약 (4 + 불변식 5)×0.5 + Must 8 + 미검증 4×2 = 3 + 6 + 4.5 + 8 + 8 = 29.5 (Caution, ≤ 30). 정본 계수는 Round 2 독립 재측정이 한다