The feature-centered model and the boundary of the early public release.
A specification workspace, not a document editor
Everything needed to reason about one feature
FeatureBuilder groups intent and verification planning around a stable feature. Each feature has a hierarchy position, key, owner, priority, tags, stage statuses, requirements, design sections, verification content, dependencies, open questions, and an update timestamp.
Why structure matters
- Atomic requirements have stable IDs, types, descriptions, and approval states.
- Architecture, interfaces, behavior, reset/error handling, and performance remain separate review surfaces.
- Verification scenarios declare their method and link directly to the requirements they cover.
- Specification, design, and DV can carry independent workflow statuses.
Current scope
The implemented release is a specification-authoring workspace. Execution milestones, regression results, coverage ingestion, issue-tracker integrations, richer exports, and architecture diagrams remain roadmap ideas rather than current capabilities.