tangweijie
aba7071723
将项目约束正式落到 .specify/memory/constitution.md，并同步更新 plan、spec、tasks、checklist、agent 模板，使 Speckit 工作流默认遵循文档单一真源、范围收敛、Archive 隔离与校验闭环。
99 lines
4.2 KiB
Markdown
99 lines
4.2 KiB
Markdown
# 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)*
|
|
|
|
<!--
|
|
For this repository, user stories should describe document-maintenance journeys
|
|
that deliver independently reviewable value.
|
|
-->
|
|
|
|
### 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**:
|
|
|
|
1. **Given** [initial state], **When** [action], **Then** [expected outcome]
|
|
2. **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**:
|
|
|
|
1. **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**:
|
|
|
|
1. **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.md` and `03_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.
|