Seed Spec Schema#
The Seed Spec is a constitutional document created before the PRD. After locking (LOCKED), it can only be changed through the explicit evolution protocol.
Document Structure#
# Seed: {project-name} | v{major.minor.patch} | Status: {DRAFT|LOCKED}
## Metadata
- Created: {YYYY-MM-DD}
- Author: {author}
- Locked: {YYYY-MM-DD or N/A}
- Ambiguity Score: {0.0-1.0}
## 1. Core Problem
> Immutable after locking. Cannot evolve.
{Core problem defined in a single sentence, without assumptions}
### Problem Rationale
- {Rationale based on data or user interviews 1}
- {Rationale 2}
## 2. Immutable Constraints
> Immutable after locking. Each item requires rationale.
| ID | Constraint | Rationale | Type |
|----|-----------|-----------|------|
| C-01 | {Constraint} | {Why this constraint is needed} | Technical/Business/Legal |
| C-02 | {Constraint} | {Rationale} | {Type} |
## 3. Domain Entities
> After locking, only additions are allowed (existing entities cannot be modified)
### {Entity Name}
- **Attributes**: {Attribute list}
- **Relationships**: {Relationships with other entities}
- **Invariants**: {Conditions that must always hold true}
## 4. Acceptance Boundaries
> One flat table. Each row is a single acceptance criterion with its own ID and Status.
> FLAT only โ no parent_id / no nesting. Nested AC decomposition (sub-criteria, trees) is OUT OF SCOPE.
| ID | Type (Must/Must-Not/May) | Acceptance Criterion | Status |
|----|--------------------------|----------------------|--------|
| AC-01 | Must | {Requirement that must be satisfied} | PENDING |
| AC-02 | Must-Not | {Thing that must never be done} | PENDING |
| AC-03 | May | {Thing that may or may not be implemented} | PENDING |
- **ID**: `AC-01`, `AC-02`, ... (sequential, stable; never reused after removal).
- **Type**: exactly one of `Must` / `Must-Not` / `May`.
- **Status**: one of `PENDING` / `IN-PROGRESS` / `MET` / `FAILED` / `WAIVED`. Defaults to `PENDING` at create time.
- Status is read/echoed by tooling (e.g. `/spec:status`) as an LLM-SEMANTIC judgment of the cell value โ never by whitespace/token-overlap matching (Korean criterion text has no word boundaries and uses josa, so lexical matching is invalid).
## 5. Exposed Assumptions
> List of assumptions derived from Socratic interviews
| ID | Assumption | Verification Status | Verification Method |
|----|-----------|-------------------|-------------------|
| A-01 | {Assumption content} | Verified/Unverified/Disproved | {Verification method} |
## 6. Evolution Log
> Append-only. Records change history after locking.
| Version | Date | Changes | Reason | Approver |
|---------|------|---------|--------|----------|
| v1.0.0 | {Date} | Initial version | Creation | {Approver} |
Field Rules#
State Transitions#
DRAFT โ LOCKED (after approval)
LOCKED โ LOCKED (version bump via evolution protocol)
- DRAFT: Freely modifiable
- LOCKED: Evolution protocol required (evolve command)
Version Rules (SemVer)#
| Change Type | Version Change | Example |
|---|---|---|
| Domain entity addition | MINOR | v1.0.0 โ v1.1.0 |
| Acceptance boundary May item change | MINOR | v1.1.0 โ v1.2.0 |
| Assumption verification status update | PATCH | v1.2.0 โ v1.2.1 |
| Core problem change | Not allowed | โ Requires new Seed creation |
| Immutable constraint change | Not allowed | โ Requires new Seed creation |
Lock Policy#
- Can be locked when ambiguity score โค 0.2 is achieved
- After locking, Core Problem (S1) and Immutable Constraints (S2) cannot be modified
- Domain Entities (S3) can only be added (existing ones cannot be modified)
-
In Acceptance Boundaries (S4), only rows whose Type is
Maycan be changed (Must / Must-Not rows are immutable; their Status may still advance via the evolution protocol) - Maximum 3 evolutions per cycle
File Location#
docs/seed-spec-{project-slug}.md