Integrity
Spec-Driven Development

Planning Substrate

Understand the planning lifecycle and roadmap substrate behind Spec-Driven Development.

Beta

The planning substrate behind Spec-Driven Development stores Features, Specs, Plans, Tasks, Build Notes, Change Proposals, and the roadmap graph that explains how Features relate.

Use Spec-Driven Development in the workspace sidebar for daily navigation. The underlying database still uses the historical project_file_* table and realtime namespace; that is an internal storage boundary, not a separate workspace navigation surface.

Spec-Driven Development is not a general file manager. In this release you create Features and Initiatives; Features get the standard lifecycle work products, and Initiatives group Features for roadmap planning. You cannot create arbitrary folders, custom files, or generic document nodes.

How the substrate is reached

The visible workspace navigation is:

Spec-Driven Development
  Initiatives
  Features
  Timeline

The dedicated Initiatives and Features pages render full-width tables. Timeline opens the current roadmap entry point backed by planning roadmap state. The old /project-files route family has been retired; use the Spec-Driven Development routes instead.

Every Feature has one home placement in the tree:

  • A Feature with a primary initiative membership is shown under that Initiative.
  • A Feature with no active initiative membership is shown under Unassigned.
  • A Feature that belongs to more than one Initiative is shown once at home and appears elsewhere only as a muted linked reference back to its home row.

What a Feature contains

Each Feature is a durable container with an immutable slug, editable title, lifecycle status, canonical version, and standard work products.

Work productWhat it is for
SpecProblem, goals, scope, workflows, data model, permissions, docs impact, and architecture impact.
PlanImplementation phases, dependencies, checkpoints, testing strategy, and closeout work.
TasksPhase-grouped checklist items with acceptance criteria, verification, and evidence.
Build NotesImplementation decisions, changed files, verification commands, and skipped checks.
ProposalsSemantic changes pushed from private drafts for review and apply.
ActivityVersion, proposal, and seed/MCP-managed local repo sync metadata history.
LineageA feature-centered graph showing parents, children, dependencies, supersession, touched work, and carried-forward context.

Spec-Driven Development renders Specs, Plans, and Build Notes as readable documents, including code fences and Mermaid diagrams when the work product contains them. Tasks render as a checklist grouped by phase.

What an Initiative contains

An Initiative is a roadmap container for related Features. It does not have its own Spec, Plan, Tasks, or Build Notes packet. It exists to help teams inspect sequencing, dependencies, scope, and status across Features that already carry their own lifecycle evidence.

Initiatives include roadmap views:

ViewWhat it is for
GraphDefault relationship map for deciding what is blocked, ready, current, superseded, or carried forward.
GanttPlanned and actual planning-owned roadmap dates.
OutlineParent/child decomposition only. Cross-cutting links are not forced into the tree.
LogTraceability events for initiative, membership, relationship, date, supersession, and export changes.

See Roadmap Graph for details.

Open lifecycle work

  1. Open a workspace.
  2. Expand Spec-Driven Development in the workspace sidebar.
  3. Open Initiatives or Features for the full-width tables.
  4. Open an Initiative or Feature to inspect roadmap context and lifecycle tabs.

The planning graph is semantic, not a file explorer:

Spec-Driven Development
  Initiatives
    initiative-slug
      feature-slug
  Unassigned
    feature-slug

Feature rows open Feature detail. Work-product views live inside the Feature detail surface. Initiative rows open Initiative detail with the scoped Feature list and planning context.

Create a Feature

  1. Open Spec-Driven Development -> Features.
  2. Use the create action when it is available for your role.
  3. Enter the Feature title.
  4. Create the Feature.

Integrity creates the Feature slug and standard lifecycle work products. The slug stays immutable so proposals, local snapshot metadata, and audit history have a stable identity.

Work with roadmap membership

Workspace admins can manage roadmap membership from Spec-Driven Development controls:

  • Right-click an Initiative to add an existing Feature.
  • Right-click a Feature to move its home Initiative, link it to another Initiative, or remove it from one or all Initiatives.
  • Right-click a linked reference to go to the home Feature, make the current Initiative the home, or unlink it.

Membership changes are roadmap state, not lifecycle record edits. They are permission-gated and reconcile through planning roadmap realtime updates.

How authoring works

Spec-Driven Development is designed for chat-assisted authoring and human review. In this release, broad Spec and Plan authoring is draft-backed and proposal-backed rather than a free-form manual editor that mutates canonical records directly.

The normal lifecycle is:

  1. An agent or controlled authoring flow creates a private draft.
  2. Draft changes are persisted as structured batches.
  3. The draft is pushed to a Change Proposal.
  4. A human reviews semantic proposal items.
  5. Approved items are applied to the canonical Feature version.
  6. MCP-managed local repo sync can write repo files when explicitly invoked outside the web app.

Do not treat repo markdown as a second source of truth. Planning records are canonical inside the app; local repo file sync is handled outside the web app by the MCP bridge.

On this page