LogoSkills

/cc-spec:evolve — 잠긴 핵심 명세를 "공식 절차로" 고치기

잠긴(LOCKED) Seed spec 을 정해진 절차로만 고칩니다 — 허용 범위만 반영하고 핵심 문제·불변 제약 수정은 거절하며, 버전을 자동으로 올리고 변경 이력을 S6 에 남깁니다.

/cc-spec:evolve — 잠긴 핵심 명세를 "공식 절차로" 고치기#

항목내용
실행 명령/cc-spec:evolve
분류스펙 명확화
난이도●●○ 보통

한마디로#

이미 확정(잠금)된 핵심 기획서를, 마음대로가 아니라 정해진 절차를 거쳐서만 바꾸도록 해주는 명령입니다. 계약서를 함부로 수정하지 못하고 정식 "변경 합의서"를 써서만 고치는 것과 같아요.

누가·언제 쓰나요#

  • 이미 잠금(LOCKED) 처리된 Seed 명세를 바꿔야 할 상황이 생겼을 때
  • 도메인 항목을 추가하거나, 가정의 검증 상태를 갱신하고 싶을 때

👉 단, 핵심 문제(S1)불변 제약(S2) 은 절대 바꿀 수 없습니다. 이 둘을 바꿔야 한다면 새 Seed를 처음부터 다시 만들어야 합니다. 또한 한 주기(cycle) 안에서 변경은 최대 3번까지만 허용됩니다.

무엇을 해주나요#

기존 Seed 명세 파일(docs/seed-spec-*.md)이 안전하게 갱신됩니다. 구체적으로:

  • 허용된 범위만 반영 — 도메인 항목 추가, May(선택) 항목 변경, 가정 검증 상태 갱신만 적용됩니다.
  • 금지된 변경은 거절 — 핵심 문제·불변 제약 수정 시도는 막고 안내해 줍니다.
  • 버전 자동 갱신 — 변경 종류에 따라 버전 번호가 자동으로 올라갑니다(MINOR 또는 PATCH).
  • 변경 이력 기록 — 무엇을·왜·누가 바꿨는지가 명세 안의 변경 로그(S6)에 남습니다.

어떻게 쓰나요#

/cc-spec:evolve                         # 변경 절차 시작
/cc-spec:evolve --file {path}           # 특정 Seed 명세 파일 지정

--file 옵션을 생략하면 가장 최근 docs/seed-spec-*.md 파일을 자동으로 사용합니다.

안에서 무슨 일이 벌어지나요#

변경을 함부로 적용하지 않고, 6단계 절차를 차례로 밟습니다.

  1. 사전 확인 — 명세가 잠금(LOCKED) 상태인지, 변경 횟수가 3번 이내인지 확인합니다.
  2. 변경 요청 수집 — 무엇을 바꾸고 싶은지 물어보고, 허용·금지 범위를 알려줍니다.
  3. 유효성 검사 — 금지 영역 수정 시도는 거절하고 안내하며, 허용 범위만 반영합니다. 3.5. 기준선 대비 변형 점검 — 처음 잠근 v1.0.0의 핵심 문제(S1)와 불변 제약(S2)을 다시 읽고, 바뀐 도메인·수용 경계(S3/S4)가 여전히 S1을 위하고 S2를 어기지 않는지 의미로 판단합니다(키워드·단어 겹침이 아니라 뜻으로 비교 — 한국어 우선). 변형 정도를 낮음/중간/높음으로 나눠 한 줄 근거와 함께 알려주고, 높음이면 막고 새 Seed(/cc-spec:seed)를 권하며, 중간이면 사용자의 명시적 확인을 받고, 낮음이면 그대로 진행합니다.
  4. 버전 올리기 — 변경 종류에 맞춰 버전 번호를 자동으로 갱신합니다.
  5. 이력 남기기 — 변경 내용·사유·승인자를 변경 로그에 기록합니다.
  6. 재검증 권유 — 바뀐 뒤 모호성 점수를 다시 평가하도록 권합니다.

⚙️ 상세 옵션·실행 명세 (개발자 / AI 에이전트용)

Usage#

/cc-spec:evolve                         # Start evolution process
/cc-spec:evolve --file {path}           # Specify a specific Seed spec

Parameters#

ParameterDescriptionDefault
--fileSeed spec file pathLatest docs/seed-spec-*.md

Prerequisites#

  • Seed spec is in LOCKED status
  • Evolution count within cycle < 3

Allowed/Prohibited Changes#

SectionAllowed Changes
S1 Core ProblemNot allowed — Requires new Seed creation
S2 Immutable ConstraintsNot allowed — Requires new Seed creation
S3 Domain EntitiesAdditions only (existing cannot be modified)
S4 Acceptance BoundariesOnly May items can be changed
S5 Exposed AssumptionsVerification status can be updated

Execution Flow#

1. Pre-validation#

  • Confirm LOCKED status
  • Check evolution count (max 3 per cycle)

2. Collect Change Requests#

  • Ask the user for change details
  • Inform about allowed/prohibited scope

3. Change Validity Check#

  • Reject attempts to modify prohibited sections + provide guidance
  • Apply only changes within allowed scope

3.5. Drift Check vs Baseline (LLM SEMANTIC)#

  • Re-read the original v1.0.0 S1 Core Problem and S2 Immutable Constraints from the seed file (the locked baseline), not the just-edited values.
  • Make an LLM SEMANTIC judgment (NOT token/word-overlap matching): does the post-evolution S3 Domain Entities + S4 Acceptance Boundaries still serve the v1.0.0 S1 Core Problem, and does any of it violate an S2 Immutable Constraint?
    • Caveat: semantic judgment, not keyword/word-overlap — Korean-first (Korean has josa and no word boundaries, so lexical/token comparison is unreliable).
  • Classify drift with a one-line justification:
    • LOW — S3/S4 still clearly serve S1, no S2 constraint violated.
    • MEDIUM — partial/ambiguous alignment with S1, or a borderline S2 tension.
    • HIGH — S3/S4 no longer serve S1, or an S2 Immutable Constraint is violated.
  • Gate on the classification:
    • HIGHblock the evolution; recommend starting a new Seed via /cc-spec:seed.
    • MEDIUM → require explicit user confirmation before continuing.
    • LOW → proceed.

4. Version Bump#

Change TypeVersion Change
Domain entity additionMINOR (v1.0.0 → v1.1.0)
May item changeMINOR
Assumption status updatePATCH (v1.1.0 → v1.1.1)

5. Evolution Log Entry#

  • Append to evolution log (S6)
  • Record change details, reason, and approver

6. Re-verification#

  • Suggest re-evaluating ambiguity score after changes

Output#

Seed spec file updated (version + evolution log).

  • /cc-spec:seed — Create Seed spec
  • /cc-spec:verify — Verification + lock
  • /cc-spec:score — Ambiguity re-evaluation
  • /cc-spec:status — Read-only alignment report against the locked Seed spec