Spec-Driven Development
Plan, review, and trace feature work through Initiatives, Features, lifecycle evidence, and roadmap context.
Spec-Driven Development is the workspace area for execution work: Initiatives, Features, lifecycle evidence, and roadmap context. It is where a team keeps feature work understandable and reviewable without turning requirements into project-management tasks or hiding decisions in chat.
Use Spec-Driven Development when you need to answer:
- What feature work exists?
- Which Initiative does it belong to?
- What Spec, Plan, Tasks, and Build Notes explain it?
- How does it relate to other Features?
- What evidence changed during implementation?
Notion and Linear can help with planning and comparison, but Integrity's Spec-Driven Development surface owns execution evidence in the app. Source Library remains the controlled requirements and evidence substrate.
Workspace navigation
Open a workspace and expand Spec-Driven Development in the sidebar. The shipped entries are:
| Entry | What it opens |
|---|---|
| Initiatives | A full-width Initiative table for roadmap containers and grouped feature work. |
| Features | A full-width Feature table for repo-backed execution slices. |
| Timeline | The current roadmap entry point, backed by planning roadmap data and Initiative detail views. |
Views is reserved for a future saved-lens surface. It is not shown as a sidebar item until it has real behavior.
Readable object URLs
Initiatives and Features use readable workspace URLs in the browser. The workspace URL segment stays human-readable, and the object segment uses the Initiative slug or Feature slug instead of a raw database id.
When a detail header or row menu shows Copy URL, the copied value is the current readable URL. Old readable object links redirect to the current URL when you still have access.
Spec-Driven Development vs Requirements Management
Integrity separates two jobs that are easy to blur:
| Area | Use it for |
|---|---|
| Spec-Driven Development | Initiatives, Features, roadmap context, Specs, Plans, Tasks, Build Notes, proposals, and lineage. |
| Requirements Management | Source Library, Reviews, Baselines, traceability links, coverage, and release evidence. |
Feature work can reference requirements and evidence, but it does not replace the Source Library. Requirements and controlled artefacts remain in Requirements Management surfaces.
planning substrate
The underlying lifecycle and roadmap records still use the planning substrate. That name appears in compatibility routes, architecture docs, and lower-level docs about drafts, proposals, exports, and roadmap graph state.
For daily navigation, use Spec-Driven Development.
Continue
Initiatives
Group related Features and inspect roadmap context.
Features
Review repo-backed execution slices and lifecycle evidence.
Coding Workflow
Use an authorized coding agent for safe daily planning work.
Timeline
Understand the current roadmap and timeline behavior.
Views
What exists today and what remains deferred.