LogoSkills

SEED_SPEC_SCHEMA

Seed Spec Schema โ€” Structure and field definitions for the immutable core spec document

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 TypeVersion ChangeExample
Domain entity additionMINORv1.0.0 โ†’ v1.1.0
Acceptance boundary May item changeMINORv1.1.0 โ†’ v1.2.0
Assumption verification status updatePATCHv1.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#

  1. Can be locked when ambiguity score โ‰ค 0.2 is achieved
  2. After locking, Core Problem (S1) and Immutable Constraints (S2) cannot be modified
  3. Domain Entities (S3) can only be added (existing ones cannot be modified)
  4. In Acceptance Boundaries (S4), only rows whose Type is May can be changed (Must / Must-Not rows are immutable; their Status may still advance via the evolution protocol)
  5. Maximum 3 evolutions per cycle

File Location#

docs/seed-spec-{project-slug}.md