mirror of
https://github.com/github/spec-kit.git
synced 2026-07-03 20:36:23 +08:00
docs: align Articles IV-V language with existing article style
Replace 'clarification pipeline' tooling references with principle-effect language matching Articles I-III and VII-IX.
This commit is contained in:
@@ -329,7 +329,7 @@ All requirements MUST be:
|
||||
- Traceable: mapped from user stories through tasks to implementation
|
||||
```
|
||||
|
||||
This article drives the clarification, checklist, and analysis pipeline. Before planning begins, specifications are scanned for ambiguity across functional scope, data modeling, interaction flows, and edge cases. "Unit tests for English" validate requirement quality rather than implementation correctness. Cross-artifact consistency checks catch coverage gaps, terminology drift, and duplicate or conflicting requirements before any code is written.
|
||||
This forces the LLM to treat requirement quality as a first-class engineering concern. Before planning begins, specifications must be scanned for ambiguity across functional scope, data modeling, interaction flows, and edge cases. "Unit tests for English" validate requirement quality rather than implementation correctness. Cross-artifact consistency checks catch coverage gaps, terminology drift, and duplicate or conflicting requirements before any code is written.
|
||||
|
||||
#### Article V: Non-Functional Standards
|
||||
|
||||
@@ -343,7 +343,7 @@ Non-functional requirements MUST be specified for:
|
||||
- Accessibility: interaction standards for all user interfaces
|
||||
```
|
||||
|
||||
Without this article, LLMs default to functional-only implementations—code that works but cannot be monitored, secured, or maintained in production. The clarification pipeline explicitly scans for non-functional coverage gaps, and checklists can target specific quality dimensions to ensure these concerns are captured in requirements before implementation begins.
|
||||
Without this article, LLMs default to functional-only implementations—code that works but cannot be monitored, secured, or maintained in production. Specifications must explicitly address non-functional coverage gaps, and quality checklists can target specific dimensions to ensure these concerns are captured in requirements before implementation begins.
|
||||
|
||||
#### Article VI: Governance and Versioning
|
||||
|
||||
|
||||
Reference in New Issue
Block a user