Skip to content

spec: refresh Directive product specification for current architecture #1567

@MScottAdams

Description

@MScottAdams

Summary

Directive's own vbrief/specification.vbrief.json and rendered SPECIFICATION.md appear stale relative to the current framework architecture and operating model.

Even after rendering with lifecycle scopes disabled, the spec still reads like the original Phases 1-3 bootstrap/adoption document. Important current domains are missing or underrepresented, and some top-level sections are likely obsolete.

Stale areas observed

Sections that likely need review and rewrite:

  • Overview
  • ProblemStatement
  • Goals
  • UserStories
  • Architecture
  • SuccessMetrics
  • LegacyArtifacts

The LegacyArtifacts narrative is especially problematic for a living spec. It is migration residue/audit data and should probably be excluded from the rendered product specification or moved to archive/report surfaces.

Current framework domains that should be represented

A refreshed Directive spec should describe the framework as it exists now, including:

  • vBRIEF lifecycle and scope management
  • triage cache, queue, and cache freshness model
  • skills and strategy routing
  • setup/build/refinement/release/review-cycle workflows
  • swarm orchestration and provider/runtime portability
  • runtime capability detection and GitHub auth-mode contracts
  • SCM/GitHub safety gates and protected issue handling
  • install/upgrade/consumer sync model
  • generated artifact/source-of-truth discipline

Recommended approach

Treat this as a spec-refresh/probe effort rather than a quick mechanical render change.

Suggested workflow:

  1. First land the renderer-defaults fix tracked in spec: render produces unusably large SPECIFICATION.md by default #1566 so the rendered spec is compact and stable.
  2. Produce a deterministic scopes-off render as the baseline for review.
  3. Audit current docs, skills, strategies, and vBRIEF lifecycle conventions.
  4. Draft updated narratives for the current product architecture.
  5. Optionally use an LLM-assisted draft as a review aid, but keep vbrief/specification.vbrief.json as the human-reviewed source of truth.
  6. Render and validate the refreshed SPECIFICATION.md.

Acceptance criteria

  • Directive's own spec narratives reflect the current framework, not only the early Phases 1-3 bootstrap effort.
  • Stale or migration-only content is removed from the living rendered spec or archived outside the main spec.
  • Architecture describes current core components and workflows.
  • User stories and success metrics align with current users: operators, maintainers, consuming projects, and agent workers.
  • The refreshed spec renders cleanly after spec: render produces unusably large SPECIFICATION.md by default #1566 without excessive lifecycle/archive content.

Metadata

Metadata

Assignees

No one assigned

    Labels

    designdocssource-of-truthCanonical authority, projection discipline, and drift checks for generated or derived artifacts.type:researchInvestigation or design discussion before implementation

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions