Flow Permutation — 흐름 순열

파이프라인 4단계(Design) 산출물 · 2026-08-26 · 사용자 흐름 순열 분석 정본 순서: Seed Spec v3.1.0 > 조직 규약(cc-flutter·cc-coui 스킬) > PRD/BDD > Discovery

작성 방식: 초안을 작성한 에이전트와 별도의 검증 에이전트가 원본 파일을 직접 열어 대조하고 교정했다. 이 파일은 교정본이다.

⚠️ 이 문서 작성 이후 확정된 사항 (2026-08-26, 반영 필요)

아래 셋은 이 문서를 생성한 워크플로가 시작된 뒤 확정됐다. 본문에 반영돼 있지 않으므로 이 블록이 우선한다.

1. Flutter master 채널 + 네이티브 윈도잉 API (D-022) — 창 분리를 window_manager 가 아니라 Flutter 네이티브 윈도잉(RegularWindow·DialogWindow·PopupWindow·SatelliteWindow·WindowingOwner·WindowRegistry)으로 구현한다. 결정적 근거는 windowHandle 이 ffi.Pointer<ffi.Void> 로 네이티브 핸들(Linux GtkWindow·macOS NSWindow·Win32 HWND)을 노출해 네이티브 도킹이 가능하다는 점이다(_window_linux.dart:208, _window_macos.dart:200).

• 채널 제약: windowingFeature 가 master: 만 선언하므로 stable 에서는 available:false 이고 설정으로도 켤 수 없다(flutter_features.dart:99 가 config 를 읽기 전에 반환). 제품 빌드 전체가 master 채널 위에 서게 된다.
• 인수한 위험: @internal API · 패치 버전에서도 breaking change 예고 · CI·개발 환경·cob doctor 가 모두 master 전제. 완화로 창 관리 호출을 얇은 자체 인터페이스 뒤에 두어 수정 지점을 한 곳으로 모은다.

2. 프로젝트 초기 세팅은 cob 로 수행 (D-023) — 모노레포 생성과 기능 추가를 cob(co-bricks CLI)로 한다. cob doctor 전 항목 통과 확인. 관련 명령: cob create·cob generate(project.yaml → 모노레포+기능)·cob compose/add·cob apply·cob plan(PRD FR/AC 커버리지 게이팅, 고아 FR hard-fail). 미결: cocode ADE 는 앱이 아니라 데스크톱 IDE 이고 Serverpod 백엔드가 없어, 기존 brick 이 이 형태를 지원하는지 Scaffold 단계에서 cob list-features 로 확인해야 한다.

3. CoUI 실측 인벤토리 (docs/coui-inventory-cocode.md) — 이 문서가 인용하는 CoUI 컴포넌트는 그 인벤토리와 대조해야 한다. 특히 주의: coui-dock 은 IDE 도킹이 아니라 모바일 하단 내비게이션 바이고, coui-diff 는 코드 diff 가 아니라 이미지 비교 슬라이더다(코드 diff 는 coui-code-diff). Figma 검색 결과 Terminal·Toolbar·StatusBar·Sidebar·Panel(단독)·Input·Split·CommandPalette 는 실재하지 않는다.

사용자 흐름 순열 분석: cocode ADE

• 작성일: 2026-08-26 · 에이전트: flow-permutation
• 대상: docs/seed-spec-cocode.md v3.1.0(정본) · docs/prd-cocode.md §2 흐름 1~5 · docs/bdd-cocode.md Feature 1~9
• 핵심 대상: DelegatedTask 상태 기계(Seed Spec §3, 79행)
• 열거량: 상태 전이 행렬 49칸(7×7) · 입력 순열 11행 · 조건 분기 진리표 4종 44행(T-A 12 · T-B 12 · T-C 11 · T-D 9) · 오류 복구 경로 9종 · 순열 항목 FP-101~FP-503, 47건
• 누락: Critical 8 · Important 10 · Nice-to-have 5 (전수 주장 아님 — 아래 §7 참조)

인용 규칙. 모든 인용은 파일을 열어 행 번호를 확인했다. seed:NN=docs/seed-spec-cocode.md NN행, prd:NN, bdd:NN, dl:D-NNN=의사결정 일지, pi:§N=planning-inputs-cocode.md. 수치는 출처가 있는 것만 쓰고, 없으면 값 대신 **"누가 언제 정하는가"**를 적었다.

불변식 인용 시 엔티티를 함께 적는다. 이 문서 집합에는 이름이 겹치는 불변식이 있다 — Workspace 불변식2(seed:74, 승인 대기 중 잠금 미유지)와 DelegatedTask 불변식2(seed:83, 사람승인 모드 전이)는 서로 다른 조항이다. 아래에서는 항상 엔티티명을 붙인다.

자기 문서의 구조 카운트도 같은 규율을 받는다. 위 열거량은 본문에서 직접 계수했다. 초안이 적었던 FP-001~FP-058(58건)·입력 순열 22행·진리표 47행은 원문과 일치하지 않아 정정했다 — 자기 내용을 세는 자리가 가장 검증하기 쉬운 자리이며, 그 자리에서 틀리면 나머지 계수의 신뢰도가 함께 무너진다.

0. 먼저 — 이 분석의 최상위 발견

Planning 게이트가 지적한 "대기→실행중→자가검증중 전이 조건 미규정"은 증상이지 원인이 아니다.

grep 으로 확인한 사실:

결론: Seed Spec 은 7개 상태를 선언하지만, 어떤 전이 규칙도 출발 상태를 지정하지 않는다. 그 결과 상태 3종(대기·실행중·자가검증중)은 Seed Spec 의 어떤 규칙에서도 참조되지 않는 고아 상태이며, 초기 상태도 규정되지 않았다(AC-17(seed:119)은 새 작업의 completion_mode 기본값만 규정하고 초기 status는 규정하지 않는다).

⚠ 이 공백은 이미 하류에서 조용히 메워졌다 — 그것이 실질 위험이다. BDD 는 규칙이 없는 채로 출발 상태를 전제로 쓰기 시작했다: Feature 4 의 [AC-07] 재시도가 3회를 초과하면…·[AC-07] retry_count 가 3 인 동안에는…·[AC-08] 단일 자가 검증 시도가… 세 시나리오가 모두 Given 작업 "T" 의 status 가 "자가검증중" 이다로 시작한다. Seed Spec 이 규정한 적 없는 상태 배치가 인수 계약 후보 문서에 먼저 굳은 것이다. C-1 을 먼저 확정해야 하는 이유가 추상적 완전성이 아니라 이것이다.

이것이 아래 모든 Critical 누락의 공통 뿌리다.

1. 기법 ① — 상태 전이 매핑

1.1 전이 규칙 인벤토리 (스펙에 존재하는 것 전부)

1.2 전이 행렬 (7×7 = 49칸)

행=출발, 열=도착. W대기 R실행중 V자가검증중 P사람승인대기 C완료 F실패 B롤백됨

범례

• R = 스펙 규칙이 이 칸을 덮는다. 단 출발 상태는 스펙에 없으므로 행 배치는 이 문서의 독법이다.
• R? = 규칙의 Given 한정("작업 도중")이 이 행에 미치는지 문면상 불분명한 칸.
• N = 제품이 성립하려면 필요하나 어떤 규칙도 덮지 않는다(미규정).
• ! = 규칙이 배제하지 않는 부적절한 전이(구멍).
• · = 이 문서 판단으로 도달 불필요. 스펙이 금지한 것은 아니다.

미규정 칸(N) 목록 — 10건

구멍(!) 2건

• !1 — 대기/실행중 → 완료 직행 (completion_mode=자가검증에 한정). DelegatedTask 불변식1(seed:82)은 완료의 조건만 규정하고 경유 상태를 요구하지 않는다. 자가검증중을 거치지 않고 완료에 도달하는 구현이 이 불변식을 위반하지 않는다. 사람승인 모드에서는 이 구멍이 없다 — AC-10(seed:112)이 "사람승인대기에 머물며"로 경유를 강제한다.
• !2 — 사람승인대기 → 사람승인대기(승인 종류 전환). pending_approval_kind(seed:78)는 값 하나만 갖는 enum 이고, 두 승인의 순서가 규정되지 않아 동시 발생이 배제되지도 않았다. §4 C-2 참조.

2. 기법 ② — 입력 순열 행렬

Seed Spec 이 정의하는 사용자 입력과 그 순열(11행). 유효/경계/무효/동시 4축.

사람이 자리를 비운 동안에는 사용자 입력을 기대할 수 없다 — C-04(seed:63)가 규정한 비동기 위임 모델의 귀결이다(입력이 정의상 금지되는 것이 아니라, 도착을 보장할 수 없다). 따라서 아래 §3·§4 의 자동 분기가 유일한 방어선이다.

3. 기법 ③ — 조건 분기 열거

T-A. 사람 부재 중 4대 분기 (과제 지정 항목) — 12행

T-B. completion_mode × 테스트변경 × 자가검증 결과 진리표 — 12행

T-C. 롤백 충돌 진리표 (과제 지정 항목: 충돌 × 다중 파일 × 부분 실패) — 11행

v3.1.0(seed:172 ①)이 충돌 판정을 **현재 해시 ≠ 그 파일의 마지막 EditSnapshot 의 result_content_hash**로 교체했다(seed:93, seed:104).

T-D. AC-12 잠금 타이밍 진리표 (과제 지정 항목) — 9행

4. 과제 지정 질문에 대한 직접 답변

Q. completion_mode가 실행 중 전환되는 경우가 있는가 — C-04 전환 조항은 작업 생성 시점 기준인가?

답: 인수 기준 수준에서는 생성 시점 기준이 유일하게 규정된 것이며, 실행 중 전환은 규정도 금지도 되어 있지 않다.

근거 3건(전부 원문 확인):

1. AC-17(seed:119) — When 새 DelegatedTask 가 생성되면, Then completion_mode 의 기본값은 사람승인이며 → 판정 시점이 생성 시점으로 못 박혀 있다. 이것이 전환 조항에 붙은 유일한 인수 기준이다.
2. C-04 전환 조항(seed:63) — 기본 완료 모드는 "사람 승인 후 완료"로 전환된다. 시점을 말하지 않는다. 그리고 "기본 모드"는 시스템 수준 기본값이지 인스턴스 속성이 아니다.
3. §3 DelegatedTask(seed:78) — completion_mode는 인스턴스 속성이다. 속성값의 변경 가능 여부에 대한 불변식은 없다(seed:82~86 5개 중 해당 항목 없음).

즉 "기본 모드"(시스템)와 "completion_mode"(인스턴스)가 서로 다른 층위인데 전환 조항이 둘을 잇는 규칙을 쓰지 않았다. 결과적으로 미규정 시나리오 3종:

권고(판정이 필요 없는 규칙). completion_mode는 작업 생성 시점에 1회 평가해 인스턴스에 고정하고 이후 불변으로 둔다. 이 규칙은 ⓐ AC-17 의 문면과 정확히 일치하고 ⓑ C-04 본문("기본 모드")과 모순되지 않으며 ⓒ 실행 중 재평가가 만드는 모든 조합(FP-501)을 소멸시킨다.

⚠ 이 권고는 안전 방향이 아니다 — 그것이 오너 판단을 요구하는 이유다. 잔여 위험은 스파이크 미달 판정 전에 생성된 진행 중 작업이 자가검증만으로 완료될 수 있다는 것이며, C-04 가 전환 조항을 둔 취지("기준 미설정 시의 기본값은 안전한 쪽")와 방향이 어긋난다. 대안은 "전환 발동 시 진행 중 작업도 사람승인으로 승격"이며, 이쪽은 안전하지만 실행 중 상태 변경 조합(FP-501)을 되살린다. 값이 아니라 정책 판단이므로 프로젝트 오너 또는 Design 이 D-18 과 함께 결정해야 한다. 이 문서는 어느 쪽도 확정하지 않는다.

5. 기법 ④ — 오류 복구 경로 (9종)

6. 누락 분류

6.1 Critical — 구현 차단 (8건)

6.2 Important (10건)

6.3 Nice-to-have (6건 — N-6 은 #88 이 추가)

7. BDD 시나리오 추천

BDD 문서는 현재 47 시나리오다. 두 경로로 교차 확인했다 — §2 대응표 "시나리오 수" 열 합산(2+4+1+1+2+2+2+2+3+2+5+3+2+6+1+1+2+1+1+1+3 = 47)과 원문 계수(Scenario: 41건 + Scenario Outline: 6건 = 47). 아래는 그 위에 추가할 것이다.

원칙: 규칙이 없으면 시나리오도 쓸 수 없다. Critical 8건은 "시나리오를 추가하라"가 아니라 **"규칙을 먼저 정하고, 그 규칙에 대한 시나리오를 쓰라"**이다. 근거는 이 프로젝트의 기록된 실패 패턴이다 — spec-evaluation:127 이 1번 패턴으로 **"근거 없는 수치 생성"**을, 4번으로 **"인용 오류"**를 든다. 값 생성이 반복된 구간은 v1.1.0~v2.1.0 이며(prd:705), 8 은 평가 라운드 수이지 사건 수가 아니다(prd:267 이 이 혼동을 명시적으로 금지한다). 8 라운드 내내 확인된 것은 "지적된 항목은 고쳐지지만 같은 결함 유형의 새 사례가 생긴다" 는 패턴이다. 규칙 없이 시나리오를 쓰는 것은 그 패턴의 새 사례가 된다 — bdd Feature 4 가 이미 규정 없는 자가검증중 을 Given 으로 굳힌 것이 실물 증거다. bdd:796 자신도 "작성되어 있다는 것과 판정할 수 있다는 것은 다르다" 고 적었다.

7.1 Must Have — Critical 해소 직후 작성 (규칙 확정이 선행 조건) — 12건

B-09 의 문면이 초안에서 바뀐 이유. 초안은 "보존 정책이 삭제한 스냅샷 때문에 롤백이 불가능해지지 않는다" 로 썼는데, 그것은 §8 R-2·R-5(종결 작업의 스냅샷 삭제 허용, 롤백 불가 표시)와 정면으로 어긋난다. 같은 문서의 두 절이 서로를 반증하면 어느 쪽도 인수 계약이 될 수 없다. C-02 를 유지할지 완화할지가 먼저 정해져야 시나리오 문면이 정해진다.

7.2 Should Have — 기존 규정만으로 지금 쓸 수 있는 것 (4건)

초안의 B-17 은 삭제했다 — 이미 존재한다. "사용자가 승인도 롤백도 하지 않은 채 시간이 지나면 작업은 사람승인대기에 머문다" 는 bdd Feature 4 의 [AC-10] 사람승인 모드에서 자가 검증 결과는 정보이지 완료의 관문이 아니다 시나리오(When 사용자가 승인하지 않은 채 시간이 지난다 → Then status 가 "사람승인대기" 에 머문다)와 동일하다. "유사 1건 존재, 중복 여부 확인 필요"가 아니라 중복이다.

7.3 규칙 확정 없이 시나리오를 쓰지 말 것 (3건)

취소 입력(I-2), 생성·삭제 EditSnapshot(I-4 — 규칙은 #28 DD-25 로 섰다. Seed Spec §3 반영(개정 요청 D-038)이 끝나기 전에는 시나리오를 쓰지 않는다), 승인 granularity(I-10)은 입력·엔티티 자체가 스펙에 없다. 시나리오를 먼저 쓰면 없는 기능을 인수 계약으로 만드는 것이 된다. 순서는 범위 결정 → Seed Spec 또는 PRD 반영 → 시나리오다.

8. CH-022 보존 정책 — 이 설계가 정해야 할 항목 (오너 결정 3)

Contrarian CH-022(contrarian:144)가 Design 으로 미뤄둔 항목이며, 오너 결정 3(파일 기반 저장, Lumide local_history 방식)이 이제 이 설계에 그 결정을 넘겼다.

⚠ 먼저 정해야 할 것은 규칙이 아니라 C-02 의 범위다. C-02(seed:61)는 "작업 시작 직전 상태를 포함해 임의의 EditSnapshot 경계 시점으로 되돌릴 수 있다"를 무조건 보장한다. 스냅샷을 하나라도 지우는 순간 이 보장은 깨진다 — 종결된 작업만 지워도 마찬가지다. 따라서 아래 R-1~R-5 는 C-02 를 "보존 정책이 유지하는 범위 안에서"로 한정하는 Seed Spec 개정이 승인된 뒤에만 성립한다. 개정 없이 채택하면 설계가 불변 층위를 위반한 채 남는다. 대안은 삭제를 하지 않고 용량 위험을 계속 인수하는 것(CH-022 의 현 상태 유지)이며, 어느 쪽을 고를지는 오너 판단이다.

출처가 있는 참조값 1건: Lumide local_history = 파일당 최대 50버전 / 5MB(dl:37 D-003 본문, contrarian:144 에 "참고 기준"으로 재기재). 이것은 Lumide 의 값이지 cocode ADE 의 값이 아니다 — 그대로 채택할 근거는 없다.

이 문서가 제안하는 것은 값이 아니라 규칙의 형태다 (판정이 필요 없도록 구성):

R-4 가 초안에서 바뀐 이유 — 초안 규칙은 실행 불가였다. 초안은 삭제 순서를 "작업 종결 시각 오름차순" 으로 규정했으나, DelegatedTask 에는 시각 속성이 없다. seed:78 의 속성은 task_id · prompt · status · completion_mode · pending_approval_kind · agent_backend_kind · agent_backend_provider · retry_count · verification_log · created_by 10종뿐이며, prd:614 가 이 부재를 이미 기록해 두었다("§3의 DelegatedTask Attributes에 시각 속성이 없다(EditSnapshot에만 timestamp)"). 존재하지 않는 값으로 정렬하라는 규칙은 Planning 게이트가 AC-02 에서 잡아낸 것과 같은 유형(정의되지 않은 값을 판정 기준으로 삼음)이다. 위 R-4 는 실재하는 timestamp(seed:89)로 다시 썼다. DelegatedTask 에 종결 시각 속성을 신설하는 §3 개정도 대안이며(§3 머리말은 잠금 후 추가를 허용한다), 어느 쪽이든 Design 이 명시적으로 골라야 한다.

미확정으로 남기는 것: R-3 의 두 수치. 근거 없이 값을 쓰지 않는다 — A-06 스파이크(pi:§6 3행)가 실측치를 내놓기 전에는 Lumide 값을 복사하는 것 외에 근거가 없고, cocode ADE 는 에이전트 런타임을 포함하므로 그 값을 그대로 쓸 근거가 없다(D-013, dl:150 의 동일 논리).

9. Seed Spec 과 어긋나는가 — 명시

이 분석은 Seed Spec v3.1.0 을 뒤집지 않는다. 단 세 곳에서 스펙 문면 자체의 수정 여부를 오너에게 묻는다 — 구현 가능성이 아니라 문면의 결함 또는 범위 결정이기 때문이다:

1. seed:93 · seed:104 (EditSnapshot 불변식2 · AC-02) — "그 파일에 대한 가장 마지막 EditSnapshot"의 작업 범위 한정 누락(C-4). 바로 다음 불변식(seed:94)은 "같은 작업에서"라고 범위를 명시하므로 이 비대칭은 누락이지 의도가 아니다. AC-12 가 명시적으로 허용하는 순차 편집과 결합해 편집 소멸을 만든다. v3.1.0 이 고친 것과 같은 유형의 결함이며(seed:172 ①이 "모든 롤백이 충돌로 보고되는" 반대 방향 결함을 고쳤다), 이번은 "충돌이어야 할 것이 충돌로 잡히지 않는" 방향이다.
2. seed:110 (AC-08) — 시간 상한이 "자가 검증 시도"에만 걸려 편집 단계와 작업 총량이 무방비(C-5). D-008(dl:88)이 재시도 상한을 도입한 근거 문장("무인 상태에서 무한정 자원을 소모할 수 있다")이 편집 단계에 적용되지 않은 채 남아 있다. 이는 D-020 의 ⚠️ 정정(dl:235)이 지적한 "매달린 경우를 판정할 인수 기준 부재"와 같은 공백이 다른 단계에서 재발한 것이다(그 지적 자체는 v3.0.0 이 AC-08 을 신설해 자가 검증 단계에서는 해소했다).
3. seed:61 (C-02) — 보존 정책을 도입하려면 "임의의 EditSnapshot 경계 시점"의 무조건 보장을 한정해야 한다(C-6, §8 머리말). 개정하지 않으면 어떤 보존 상한도 불변 층위를 위반한다. 삭제를 하지 않고 용량 위험을 계속 인수하는 선택지도 유효하며, 어느 쪽인지는 값이 아니라 오너의 범위 결정이다.

나머지 Critical 5건(C-1·C-2·C-3·C-7·C-8)은 스펙 개정 없이 Design 결정으로 해소 가능하다.

10. 다음 단계

1. C-1(상태 기계 출발 상태·초기 상태)을 먼저 확정한다. 나머지 7건 중 3건(C-2·C-5·C-8)과 N1~N10 전부가 이것에 종속된다. 확정 전까지 bdd Feature 4 의 Given status 가 "자가검증중" 전제는 잠정 표기임을 BDD 에 주석으로 남긴다 — 규칙보다 시나리오가 먼저 굳는 것을 막는다.
2. C-4·C-5·C-6 은 Seed Spec 개정 여부를 오너에게 올린다 — Design 결정으로 덮으면 불변 층위와 설계가 어긋난 채 남는다. C-6 은 개정과 "삭제하지 않음" 두 선택지가 모두 유효하다.
3. C-6·C-7 은 오너 결정 3(파일 기반 EditSnapshot 저장)의 직접 산출물이므로 저장소 설계와 같은 문서에서 함께 결정한다. §8 R-1~R-5 를 초안으로 쓸 수 있되, R-2 는 C-02 개정 승인이, R-3 은 바이트 계수 규칙이, R-4 는 정렬 키(timestamp 사용 또는 속성 신설) 선택이 각각 선행한다.
4. B-01~B-12 는 각 규칙이 확정된 뒤에 BDD 에 추가한다. 규칙 없이 먼저 쓰지 않는다. B-13~B-16 은 지금 쓸 수 있다(B-13 은 §4 잔여 위험 수용이 선행).
5. 이 목록을 전수라고 주장하지 않는다. 열어 확인한 문서는 seed-spec v3.1.0 전문, prd 전문, bdd 전문, planning-inputs 전문, discovery 전문, decision-log 전문(D-001~D-023 — prd 가 "D-001~D-021"로 적은 범위보다 2건 많다), spec-evaluation §판정과 권고, contrarian CH-022 2행이다. cc-flutter flutter-patterns·package-layers·coui-flutter-rules 는 참조했으나 이 분석에 인용된 규정이 0건이므로 근거 목록에서는 제외한다(이 산출물은 상태 기계·인수 경계 층위이며 위젯·패키지 계층을 다루지 않는다).

Generated by cc-spec flow-permutation agent · 2026-08-26