将项目约束正式落到 .specify/memory/constitution.md,并同步更新 plan、spec、tasks、checklist、agent 模板,使 Speckit 工作流默认遵循文档单一真源、范围收敛、Archive 隔离与校验闭环。
4.2 KiB
Feature Specification: [FEATURE NAME]
Feature Branch: [###-feature-name]
Created: [DATE]
Status: Draft
Input: User description: "$ARGUMENTS"
Document Scope & Sources (mandatory)
- Target documents: [List the exact files intended to be updated]
- Primary source of truth: [List the authoritative main docs]
- Reference sources: [List allowed Archive/guides/supporting docs]
- Scope decision: [State whether this request is in scope, needs confirmation, or is out of scope]
User Scenarios & Testing (mandatory)
User Story 1 - [Brief Title] (Priority: P1)
[Describe the document-maintenance user journey in plain language]
Why this priority: [Explain the value and why it has this priority level]
Independent Test: [Describe how this can be reviewed independently, e.g. by validating one target document and checking impacted links]
Acceptance Scenarios:
- Given [initial state], When [action], Then [expected outcome]
- Given [initial state], When [action], Then [expected outcome]
User Story 2 - [Brief Title] (Priority: P2)
[Describe this user journey in plain language]
Why this priority: [Explain the value and why it has this priority level]
Independent Test: [Describe how this can be tested independently]
Acceptance Scenarios:
- Given [initial state], When [action], Then [expected outcome]
User Story 3 - [Brief Title] (Priority: P3)
[Describe this user journey in plain language]
Why this priority: [Explain the value and why it has this priority level]
Independent Test: [Describe how this can be tested independently]
Acceptance Scenarios:
- Given [initial state], When [action], Then [expected outcome]
Edge Cases
- What happens when a requested change is only supported by Archive history but not by current main docs?
- How does the workflow handle broken relative links, unstable anchors, or Mermaid syntax regressions introduced by edits?
- What happens when one document changes numbering or terminology that affects other linked documents?
Requirements (mandatory)
Functional Requirements
- FR-001: Specification MUST identify the exact target documents that will be changed.
- FR-002: Specification MUST identify the main source-of-truth documents that govern the change.
- FR-003: Specification MUST record whether the request is in scope, requires confirmation, or is out of scope under the project range baseline.
- FR-004: System MUST preserve the single-source-of-truth model and MUST NOT assume creation of new parallel formal documents unless explicitly approved.
- FR-005: System MUST list the validation actions needed after the change, including file validation and any required link or Mermaid checks.
- FR-006: System MUST state whether management ledgers need updates in
01_Project_Progress.mdand03_Task_Checklist.md. - FR-007: System MUST capture cross-document consistency impacts when terminology, numbering, diagrams, or references may change.
Key Entities (include if feature involves data)
- Target Document: A Markdown file that will be modified as part of the request.
- Source of Truth Document: A main document or governance document that constrains allowed conclusions.
- Reference Source: Archive or guide material used only for verification, traceability, or scope judgment.
- Validation Action: A command or review step that proves the document set remains consistent after change.
- Ledger Update: A required change to project progress or task checklist records after important modifications.
Success Criteria (mandatory)
Measurable Outcomes
- SC-001: Every target document is explicitly named before implementation begins.
- SC-002: Every completed change can be traced to at least one source-of-truth or approved reference source.
- SC-003: Required validation actions are explicitly listed and can be executed without ambiguity.
- SC-004: Reviewers can determine from the spec alone whether ledger updates and cross-document sync are required.