seed:evolve

Seed Spec Evolution — Explicit change protocol for locked Seed specs

항목	내용
Invoke	/seed:evolve
Category	spec-clarity
Complexity	moderate

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

한마디로#

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

누가·언제 쓰나요#

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

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

무엇을 해주나요#

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

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

어떻게 쓰나요#

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

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

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

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

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

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

Usage#

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

Parameters#

Parameter	Description	Default
`--file`	Seed spec file path	Latest `docs/seed-spec-*.md`

Prerequisites#

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

Allowed/Prohibited Changes#

Section	Allowed Changes
S1 Core Problem	Not allowed — Requires new Seed creation
S2 Immutable Constraints	Not allowed — Requires new Seed creation
S3 Domain Entities	Additions only (existing cannot be modified)
S4 Acceptance Boundaries	Only May items can be changed
S5 Exposed Assumptions	Verification 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:
- HIGH → block the evolution; recommend starting a new Seed via /spec:seed.
- MEDIUM → require explicit user confirmation before continuing.
- LOW → proceed.

4. Version Bump#

Change Type	Version Change
Domain entity addition	MINOR (v1.0.0 → v1.1.0)
May item change	MINOR
Assumption status update	PATCH (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).

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