feat(plan-01): Phase 1 — relocate harness code to packages/casan-harness (symlink facade)
Physically move the pure-code subtrees out of .specify into the package, leaving compat symlinks at the old .specify/<dir> paths so every existing reference (internal CASAN_HARNESS_ROOT + external CI/docker/mjs) keeps resolving. Runtime state stays put. Moved (git mv): scripts/ tests/ security/ templates/ config/ governance/ memory/ .specify/<dir> -> packages/casan-harness/<dir> (+ .specify/<dir> symlink) Stays in .specify (state/governance/domain, handled later): logs/ agentops/ level5/ init-options.json traceability-map.json Python `.resolve()` self-location followed the compat symlink into packages and lost the app root; generate-casan-demo-context.py, generate-agentops-dashboard.py and dashboard-server.py now walk UP for the `.specify` state marker instead of a fixed parent depth (fixes "missing trace files" in run-casan4). Full gate: PASS=64 FAIL=0 SKIP=3 (CASAN_CI_STEP_TIMEOUT_SEC=1200 — track-a ~450s runs close to the 600s default and can tip over under load; this is timing variance, not a regression — it passed cleanly with headroom). Runtime log/audit artifacts kept unstaged. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
thanhnv
co-authored by
Claude Opus 4.8
Claude Opus 4.8
parent
2c765c9a45
commit
664bd1f00c
+1
@@ -0,0 +1 @@
|
||||
../packages/casan-harness/templates
|
||||
@@ -1,28 +0,0 @@
|
||||
# [PROJECT NAME] Development Guidelines
|
||||
|
||||
Auto-generated from all feature plans. Last updated: [DATE]
|
||||
|
||||
## Active Technologies
|
||||
|
||||
[EXTRACTED FROM ALL PLAN.MD FILES]
|
||||
|
||||
## Project Structure
|
||||
|
||||
```text
|
||||
[ACTUAL STRUCTURE FROM PLANS]
|
||||
```
|
||||
|
||||
## Commands
|
||||
|
||||
[ONLY COMMANDS FOR ACTIVE TECHNOLOGIES]
|
||||
|
||||
## Code Style
|
||||
|
||||
[LANGUAGE-SPECIFIC, ONLY FOR LANGUAGES IN USE]
|
||||
|
||||
## Recent Changes
|
||||
|
||||
[LAST 3 FEATURES AND WHAT THEY ADDED]
|
||||
|
||||
<!-- MANUAL ADDITIONS START -->
|
||||
<!-- MANUAL ADDITIONS END -->
|
||||
@@ -1,319 +0,0 @@
|
||||
# [PROJECT_NAME] - Basic Design Document
|
||||
|
||||
## [FEATURE_NAME]
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **Project Code:** | [PROJECT_CODE] |
|
||||
| **Document Code:** | [DOCUMENT_CODE] |
|
||||
| **Version:** | [VERSION] |
|
||||
| **Effective Date:** | [DATE] |
|
||||
|
||||
---
|
||||
|
||||
## Record of change
|
||||
|
||||
| No | Effective Date | Version | Change Description | Reason | Reviewer | Approver |
|
||||
|---|---|---|---|---|---|---|
|
||||
| 1 | [dd/mm/yyyy] | [x.y] | Initial version | Feature development | | |
|
||||
| 2 | | | | | | |
|
||||
| 3 | | | | | | |
|
||||
|
||||
---
|
||||
|
||||
## TABLE OF CONTENTS
|
||||
|
||||
1. [Introduction](#1-introduction)
|
||||
- 1.1 [Purpose](#11-purpose)
|
||||
- 1.2 [Scope](#12-scope)
|
||||
- 1.3 [References](#13-references)
|
||||
- 1.4 [Overview](#14-overview)
|
||||
2. [System Overview](#2-system-overview)
|
||||
- 2.1 [System Context](#21-system-context)
|
||||
- 2.2 [Component Overview](#22-component-overview)
|
||||
3. [Screen Design](#3-screen-design)
|
||||
- 3.1 [Screen List](#31-screen-list)
|
||||
- 3.2 [Screen Transition Diagram](#32-screen-transition-diagram)
|
||||
- 3.3 [Screen Layout](#33-screen-layout)
|
||||
- 3.4 [Screen I/O Item List](#34-screen-io-item-list)
|
||||
- 3.5 [Screen Action Detail](#35-screen-action-detail)
|
||||
- 3.6 [Common UI Rules](#36-common-ui-rules)
|
||||
4. [Data Model Design](#4-data-model-design)
|
||||
- 4.1 [ER Diagram](#41-er-diagram)
|
||||
- 4.2 [Entity List](#42-entity-list)
|
||||
- 4.3 [Entity Definition](#43-entity-definition)
|
||||
- 4.4 [CRUD Matrix](#44-crud-matrix)
|
||||
5. [Optional Design Sections](#5-optional-design-sections)
|
||||
- 5.1 [External Interface Design](#51-external-interface-design)
|
||||
- 5.2 [Batch Processing Design](#52-batch-processing-design)
|
||||
- 5.3 [Reports / Forms Design](#53-reports--forms-design)
|
||||
6. [Assumptions and Open Items](#6-assumptions-and-open-items)
|
||||
|
||||
---
|
||||
|
||||
## 1. Introduction
|
||||
|
||||
### 1.1 Purpose
|
||||
|
||||
This Basic Design (BD) document defines the high-level design for [FEATURE_NAME] in [PROJECT_NAME].
|
||||
|
||||
The document is intended for:
|
||||
|
||||
- Designers and developers
|
||||
- Test engineers
|
||||
- Reviewers and project stakeholders
|
||||
|
||||
### 1.2 Scope
|
||||
|
||||
This document covers:
|
||||
|
||||
- System context and major components relevant to the feature
|
||||
- Mandatory screen design deliverables
|
||||
- Mandatory data model design deliverables
|
||||
- Optional design sections only when the feature requires them
|
||||
|
||||
This document does not cover implementation-level logic. Those details belong in Detailed Design.
|
||||
|
||||
### 1.3 References
|
||||
|
||||
| No. | Document Number | Title |
|
||||
|---|---|---|
|
||||
| 1 | [SRS-DOC-ID] | Software Requirements Specification - [PROJECT_NAME] |
|
||||
| 2 | [BD-GUIDE-ID] | IPA Basic Design guidance / project template rules |
|
||||
| 3 | [Add other references] | |
|
||||
|
||||
### 1.4 Overview
|
||||
|
||||
This template is intentionally concise.
|
||||
|
||||
- Section 3 and Section 4 are mandatory in BD
|
||||
- Section 5 is optional and should be included only when applicable
|
||||
- Remove unused placeholders before finalizing the document
|
||||
|
||||
---
|
||||
|
||||
## 2. System Overview
|
||||
|
||||
### 2.1 System Context
|
||||
|
||||
**Purpose:** Briefly explain where this feature sits in the overall system.
|
||||
|
||||
**System Context Diagram:**
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
User[User / Operator] --> Screen[Target Screen or Function]
|
||||
Screen --> Service[Application Service]
|
||||
Service --> DB[(Database)]
|
||||
Service --> Ext[External System]
|
||||
```
|
||||
|
||||
**Context Notes:**
|
||||
|
||||
- Feature objective: [Short summary]
|
||||
- Primary users: [User roles]
|
||||
- Related subsystems: [Subsystems / modules]
|
||||
- Related requirements: [SRS IDs]
|
||||
|
||||
### 2.2 Component Overview
|
||||
|
||||
| Component | Responsibility | Input / Output | Notes |
|
||||
|---|---|---|---|
|
||||
| [UI / Screen] | [What it handles] | [Main I/O] | |
|
||||
| [Service / API] | [What it handles] | [Main I/O] | |
|
||||
| [Data Store / Table Group] | [What it stores] | [Main I/O] | |
|
||||
|
||||
---
|
||||
|
||||
## 3. Screen Design
|
||||
|
||||
**Mandatory section:** Include all subsections in this chapter for screen-based features.
|
||||
|
||||
### 3.1 Screen List
|
||||
|
||||
| No | Screen ID | Screen Name | Purpose | Related Requirement / Use Case |
|
||||
|---|---|---|---|---|
|
||||
| 1 | SCR-001 | [Screen Name] | [Purpose] | [FR / UC] |
|
||||
| 2 | SCR-002 | [Screen Name] | [Purpose] | [FR / UC] |
|
||||
|
||||
### 3.2 Screen Transition Diagram
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
A[Screen A] --> B[Screen B]
|
||||
B --> C[Screen C]
|
||||
B --> D[Screen D]
|
||||
D --> B
|
||||
```
|
||||
|
||||
**Transition Notes:**
|
||||
|
||||
- Entry point: [How the user reaches this screen group]
|
||||
- Main transition rules: [Key navigation rules]
|
||||
- Error or cancel routes: [Back / cancel behavior]
|
||||
|
||||
### 3.3 Screen Layout
|
||||
|
||||
#### Screen: [Screen Name] ([Screen ID])
|
||||
|
||||
**Purpose:** [What the user can do on this screen]
|
||||
|
||||
**Layout Sketch:**
|
||||
|
||||
```
|
||||
+--------------------------------------------------+
|
||||
| Header: [Title] [User] |
|
||||
+--------------------------------------------------+
|
||||
| Search / Condition Area |
|
||||
+--------------------------------------------------+
|
||||
| Main Content Area |
|
||||
| - List / Form / Detail |
|
||||
| - Main controls |
|
||||
+--------------------------------------------------+
|
||||
| Action Area: [Button] [Button] [Button] |
|
||||
+--------------------------------------------------+
|
||||
```
|
||||
|
||||
**Layout Notes:**
|
||||
|
||||
- Main areas: [Header / filter / list / detail / footer]
|
||||
- Key display rules: [Highlight, readonly, hidden, modal]
|
||||
- Related requirements: [SRS IDs]
|
||||
|
||||
### 3.4 Screen I/O Item List
|
||||
|
||||
#### Screen: [Screen Name] ([Screen ID])
|
||||
|
||||
| No | Item ID | Item Name | I/O | Type | Required | Validation / Format | Source / Destination |
|
||||
|---|---|---|---|---|---|---|---|
|
||||
| 1 | item_01 | [Item Name] | Input | Text | Yes | Max 50 chars | User input |
|
||||
| 2 | item_02 | [Item Name] | Output | Label | No | YYYY/MM/DD | [Table / API] |
|
||||
| 3 | item_03 | [Item Name] | Input | Select | Yes | Code list | [Master / API] |
|
||||
|
||||
### 3.5 Screen Action Detail
|
||||
|
||||
#### Screen: [Screen Name] ([Screen ID])
|
||||
|
||||
| No | Action | Trigger | Processing Summary | Success Result | Error Result |
|
||||
|---|---|---|---|---|---|
|
||||
| 1 | Search | Search button click | Validate conditions and retrieve data | Result list displayed | Error message displayed |
|
||||
| 2 | Register | Register button click | Validate input and save data | Completion message displayed | Input errors highlighted |
|
||||
| 3 | Cancel | Cancel button click | Discard temporary changes | Return to previous state | - |
|
||||
|
||||
### 3.6 Common UI Rules
|
||||
|
||||
| No | Rule Category | Rule Description |
|
||||
|---|---|---|
|
||||
| 1 | Validation | Required items must be checked before execution |
|
||||
| 2 | Error Display | Validation errors are shown near the related item |
|
||||
| 3 | Authority | Buttons and data visibility follow the user role |
|
||||
| 4 | Navigation | Cancel and back actions must return to the defined previous screen |
|
||||
|
||||
---
|
||||
|
||||
## 4. Data Model Design
|
||||
|
||||
**Mandatory section:** Include all subsections in this chapter when the feature creates, reads, updates, or deletes business data.
|
||||
|
||||
### 4.1 ER Diagram
|
||||
|
||||
```mermaid
|
||||
erDiagram
|
||||
ENTITY_A ||--o{ ENTITY_B : has
|
||||
ENTITY_A {
|
||||
string id PK
|
||||
string name
|
||||
}
|
||||
ENTITY_B {
|
||||
string id PK
|
||||
string entity_a_id FK
|
||||
string status
|
||||
}
|
||||
```
|
||||
|
||||
**ER Notes:**
|
||||
|
||||
- Main entities: [Entity names]
|
||||
- Key relationships: [1:N, N:M, reference rules]
|
||||
- Scope note: [Only entities relevant to this feature]
|
||||
|
||||
### 4.2 Entity List
|
||||
|
||||
| No | Entity Name | Description | Primary Key | Related Screens / Functions |
|
||||
|---|---|---|---|---|
|
||||
| 1 | [Entity Name] | [Business meaning] | [PK] | [Screen / function] |
|
||||
| 2 | [Entity Name] | [Business meaning] | [PK] | [Screen / function] |
|
||||
|
||||
### 4.3 Entity Definition
|
||||
|
||||
#### Entity: [Entity Name]
|
||||
|
||||
| No | Attribute Name | Type | Length | Null | Key | Description | Source / Rule |
|
||||
|---|---|---|---|---|---|---|---|
|
||||
| 1 | [attribute_1] | VARCHAR | 50 | No | PK | [Description] | [Business rule] |
|
||||
| 2 | [attribute_2] | VARCHAR | 20 | Yes | FK | [Description] | [Reference entity] |
|
||||
| 3 | [attribute_3] | DATETIME | - | No | - | [Description] | System generated |
|
||||
|
||||
**Entity Notes:**
|
||||
|
||||
- Uniqueness / index: [If needed]
|
||||
- Lifecycle notes: [Create/update/delete policy]
|
||||
- Related requirements: [SRS IDs]
|
||||
|
||||
### 4.4 CRUD Matrix
|
||||
|
||||
| Entity | Function / Screen A | Function / Screen B | Function / Screen C |
|
||||
|---|---|---|---|
|
||||
| [Entity A] | C, R | R, U | R |
|
||||
| [Entity B] | R | C, R, U | D |
|
||||
|
||||
**Legend:** C = Create, R = Read, U = Update, D = Delete
|
||||
|
||||
---
|
||||
|
||||
## 5. Optional Design Sections
|
||||
|
||||
Include the following sections only when applicable. Remove unused sections from the final BD.
|
||||
|
||||
### 5.1 External Interface Design
|
||||
|
||||
| Interface ID | Interface Name | Direction | External System | Summary |
|
||||
|---|---|---|---|---|
|
||||
| IF-001 | [Name] | Input / Output | [System name] | [Short purpose] |
|
||||
|
||||
Add request / response examples or item definitions only when the interface is in scope for this feature.
|
||||
|
||||
### 5.2 Batch Processing Design
|
||||
|
||||
| Job ID | Job Name | Trigger / Schedule | Summary | Input / Output |
|
||||
|---|---|---|---|---|
|
||||
| JOB-001 | [Name] | [Schedule] | [Short purpose] | [Main I/O] |
|
||||
|
||||
Add detailed flow only when the feature contains batch processing.
|
||||
|
||||
### 5.3 Reports / Forms Design
|
||||
|
||||
| Report ID | Report / Form Name | Trigger | Output Format | Summary |
|
||||
|---|---|---|---|---|
|
||||
| RPT-001 | [Name] | [Manual / schedule] | PDF / Excel / CSV | [Short purpose] |
|
||||
|
||||
Add layout or item detail only when the feature produces reports or forms.
|
||||
|
||||
---
|
||||
|
||||
## 6. Assumptions and Open Items
|
||||
|
||||
### Assumptions
|
||||
|
||||
- [Assumption 1]
|
||||
- [Assumption 2]
|
||||
|
||||
### Open Items
|
||||
|
||||
| No | Topic | Description | Owner | Due Date |
|
||||
|---|---|---|---|---|
|
||||
| 1 | [Topic] | [Open point to confirm] | [Owner] | [Date] |
|
||||
|
||||
---
|
||||
|
||||
**End of Basic Design Document**
|
||||
@@ -1,40 +0,0 @@
|
||||
# [CHECKLIST TYPE] Checklist: [FEATURE NAME]
|
||||
|
||||
**Purpose**: [Brief description of what this checklist covers]
|
||||
**Created**: [DATE]
|
||||
**Feature**: [Link to spec.md or relevant documentation]
|
||||
|
||||
**Note**: This checklist is generated by the `/speckit.checklist` command based on feature context and requirements.
|
||||
|
||||
<!--
|
||||
============================================================================
|
||||
IMPORTANT: The checklist items below are SAMPLE ITEMS for illustration only.
|
||||
|
||||
The /speckit.checklist command MUST replace these with actual items based on:
|
||||
- User's specific checklist request
|
||||
- Feature requirements from spec.md
|
||||
- Technical context from plan.md
|
||||
- Implementation details from tasks.md
|
||||
|
||||
DO NOT keep these sample items in the generated checklist file.
|
||||
============================================================================
|
||||
-->
|
||||
|
||||
## [Category 1]
|
||||
|
||||
- [ ] CHK001 First checklist item with clear action
|
||||
- [ ] CHK002 Second checklist item
|
||||
- [ ] CHK003 Third checklist item
|
||||
|
||||
## [Category 2]
|
||||
|
||||
- [ ] CHK004 Another category item
|
||||
- [ ] CHK005 Item with specific criteria
|
||||
- [ ] CHK006 Final item in this category
|
||||
|
||||
## Notes
|
||||
|
||||
- Check items off as completed: `[x]`
|
||||
- Add comments or findings inline
|
||||
- Link to relevant resources or documentation
|
||||
- Items are numbered sequentially for easy reference
|
||||
@@ -1,50 +0,0 @@
|
||||
# [PROJECT_NAME] Constitution
|
||||
<!-- Example: Spec Constitution, TaskFlow Constitution, etc. -->
|
||||
|
||||
## Core Principles
|
||||
|
||||
### [PRINCIPLE_1_NAME]
|
||||
<!-- Example: I. Library-First -->
|
||||
[PRINCIPLE_1_DESCRIPTION]
|
||||
<!-- Example: Every feature starts as a standalone library; Libraries must be self-contained, independently testable, documented; Clear purpose required - no organizational-only libraries -->
|
||||
|
||||
### [PRINCIPLE_2_NAME]
|
||||
<!-- Example: II. CLI Interface -->
|
||||
[PRINCIPLE_2_DESCRIPTION]
|
||||
<!-- Example: Every library exposes functionality via CLI; Text in/out protocol: stdin/args → stdout, errors → stderr; Support JSON + human-readable formats -->
|
||||
|
||||
### [PRINCIPLE_3_NAME]
|
||||
<!-- Example: III. Test-First (NON-NEGOTIABLE) -->
|
||||
[PRINCIPLE_3_DESCRIPTION]
|
||||
<!-- Example: TDD mandatory: Tests written → User approved → Tests fail → Then implement; Red-Green-Refactor cycle strictly enforced -->
|
||||
|
||||
### [PRINCIPLE_4_NAME]
|
||||
<!-- Example: IV. Integration Testing -->
|
||||
[PRINCIPLE_4_DESCRIPTION]
|
||||
<!-- Example: Focus areas requiring integration tests: New library contract tests, Contract changes, Inter-service communication, Shared schemas -->
|
||||
|
||||
### [PRINCIPLE_5_NAME]
|
||||
<!-- Example: V. Observability, VI. Versioning & Breaking Changes, VII. Simplicity -->
|
||||
[PRINCIPLE_5_DESCRIPTION]
|
||||
<!-- Example: Text I/O ensures debuggability; Structured logging required; Or: MAJOR.MINOR.BUILD format; Or: Start simple, YAGNI principles -->
|
||||
|
||||
## [SECTION_2_NAME]
|
||||
<!-- Example: Additional Constraints, Security Requirements, Performance Standards, etc. -->
|
||||
|
||||
[SECTION_2_CONTENT]
|
||||
<!-- Example: Technology stack requirements, compliance standards, deployment policies, etc. -->
|
||||
|
||||
## [SECTION_3_NAME]
|
||||
<!-- Example: Development Workflow, Review Process, Quality Gates, etc. -->
|
||||
|
||||
[SECTION_3_CONTENT]
|
||||
<!-- Example: Code review requirements, testing gates, deployment approval process, etc. -->
|
||||
|
||||
## Governance
|
||||
<!-- Example: Constitution supersedes all other practices; Amendments require documentation, approval, migration plan -->
|
||||
|
||||
[GOVERNANCE_RULES]
|
||||
<!-- Example: All PRs/reviews must verify compliance; Complexity must be justified; Use [GUIDANCE_FILE] for runtime development guidance -->
|
||||
|
||||
**Version**: [CONSTITUTION_VERSION] | **Ratified**: [RATIFICATION_DATE] | **Last Amended**: [LAST_AMENDED_DATE]
|
||||
<!-- Example: Version: 2.1.1 | Ratified: 2025-06-13 | Last Amended: 2025-07-16 -->
|
||||
@@ -1,443 +0,0 @@
|
||||
# \<Name of Project\>
|
||||
|
||||
# DETAIL DESIGN DOCUMENT
|
||||
|
||||
**Project Code:** \<Code of the project\>
|
||||
**Document Code:** \<82e-BM/DE/HDCV/FSOFT\> – DD – v\<1.5\>
|
||||
|
||||
---
|
||||
|
||||
## RECORD OF CHANGE
|
||||
|
||||
| No | Effective Date | Version | Change Description | Reason | Reviewer | Approver |
|
||||
|----|----------------|---------|-------------------|---------|----------|----------|
|
||||
| 1 | 15/Nov/2004 | 1.0 | Issued | IP | | |
|
||||
| 2 | 15/Oct/2005 | 1.1 | Change logo | BOM decision | | |
|
||||
| 3 | 10/Dec/2005 | 1.2 | Page 8: Section 2: Add data model | 20-PIP2005 | | |
|
||||
| 4 | 8/Mar/2006 | 1.3 | Add 5. OTHER CONSIDERATIONS | For CMMI 5 | | |
|
||||
| 5 | 10/Oct/2013 | 1.4 | - 1.3 Standards and Conventions => Add new<br>- 2.3 Store Procedure => Add new | Update to fit the actual | | |
|
||||
| 6 | 20/Jun/2016 | 1.5 | Re-format template to make consistent in QDS | To fix comments of QAI from CMMi5-v1.3 assessment project (Gap Analysis phase) | | HyTQ |
|
||||
| 7 | | | | | | |
|
||||
| 8 | | | | | | |
|
||||
| 9 | | | | | | |
|
||||
| 10 | | | | | | |
|
||||
|
||||
---
|
||||
|
||||
## TABLE OF CONTENTS
|
||||
|
||||
1. [Introduction](#1-introduction)
|
||||
- 1.1 [Purpose](#11-purpose)
|
||||
- 1.2 [Definitions, Acronyms and Abbreviations](#12-definitions-acronyms-and-abbreviations)
|
||||
- 1.3 [Standards and Conventions](#13-standards-and-conventions)
|
||||
- 1.4 [References](#14-references)
|
||||
- 1.5 [Overview](#15-overview)
|
||||
2. [Common Package and Mechanism](#2-common-package-and-mechanism)
|
||||
- 2.1 [Common Package](#21-common-package)
|
||||
- 2.2 [Error, Exception Handling](#22-error-exception-handling)
|
||||
- 2.3 [Log, Trace and Debug](#23-log-trace-and-debug)
|
||||
- 2.4 [Performance Optimizing Mechanism](#24-performance-optimizing-mechanism)
|
||||
- 2.5 [Multilingual Processing](#25-multilingual-processing)
|
||||
3. [Diagrams](#3-diagrams)
|
||||
4. [Packages](#4-packages)
|
||||
- 4.1 [XXX Package](#41-xxx-package)
|
||||
- 4.2 [Implementation](#42-implementation)
|
||||
5. [Database](#5-database)
|
||||
- 5.1 [ERDs](#51-erds)
|
||||
- 5.2 [XXX Table](#52-xxx-table)
|
||||
- 5.3 [Store Procedure](#53-store-procedure)
|
||||
6. [File Design](#6-file-design)
|
||||
- 6.1 [File List](#61-file-list)
|
||||
- 6.2 [XXX File](#62-xxx-file)
|
||||
7. [Code Design](#7-code-design)
|
||||
8. [Edge Case Definition (エッジケース定義)](#8-edge-case-definition-エッジケース定義)
|
||||
- 8.1 [Abnormal Value Definition (異常値定義)](#81-abnormal-value-definition-異常値定義)
|
||||
- 8.2 [Boundary Value Definition (境界値定義)](#82-boundary-value-definition-境界値定義)
|
||||
- 8.3 [Exception Handling Definition (例外処理定義)](#83-exception-handling-definition-例外処理定義)
|
||||
9. [Other Considerations](#9-other-considerations)
|
||||
10. [Appendix](#10-appendix)
|
||||
|
||||
---
|
||||
|
||||
## RECORD OF CHANGE (of the project)
|
||||
|
||||
| No | Effective Date | Version | Change Description | Reason | Reviewer | Approver |
|
||||
|----|----------------|---------|-------------------|---------|----------|----------|
|
||||
| 1 | \<dd/mm/yyyy\> | \<x.y\> | \<Describe the change of document in detail\> | \<Describe reason for the change\> | | |
|
||||
|
||||
---
|
||||
|
||||
## 1. Introduction
|
||||
|
||||
### 1.1 Purpose
|
||||
|
||||
\<This part will give general description of the document including:
|
||||
- Purpose of document.
|
||||
- What are contained in the document.
|
||||
- Reader of document.
|
||||
- Other description about scope of document, limitation,...\>
|
||||
|
||||
**Example:**
|
||||
|
||||
XXX detail design document contains descriptions of all classes, data structures, and implementation details of the YYYY system including:
|
||||
- Class diagrams that describe the static relation of all classes in the system
|
||||
- Dynamic diagrams such as collaboration diagram, sequence diagram, activities diagram
|
||||
- Description of class in detail
|
||||
- Database design including ERDs, table definitions, and stored procedures
|
||||
- File design specifications
|
||||
- Common mechanism in implementing is also defined in this document
|
||||
|
||||
Developer and tester will base on this design to implement classes, database objects, and conduct unit testing.
|
||||
|
||||
### 1.2 Definitions, Acronyms and Abbreviations
|
||||
|
||||
| Abbreviations | Description | Comment |
|
||||
|--------------|-------------|---------|
|
||||
| TBD | To be decided | It means "not decided yet" |
|
||||
| Windows DDK | Windows Device Development Kit | Development Kit from Microsoft to develop device driver for Windows 2000/XP/Server 2003 OS |
|
||||
| ESC/P | Escape Printing command | A page description language used on Epson ink jet printers |
|
||||
|
||||
### 1.3 Standards and Conventions
|
||||
|
||||
\<Define all the conventions to write detail design:
|
||||
- Design standards: what is the tool to design?
|
||||
- Documentation standards: Font, color, style – formal style…
|
||||
- Naming conventions: naming for package, class, variable, method, table, column… (Take from the coding convention document)\>
|
||||
|
||||
### 1.4 References
|
||||
|
||||
\<List all the reference document such as: other document of the system, or the technical article,...\>
|
||||
|
||||
| Document Number | Title |
|
||||
|----------------|-------|
|
||||
| \<01\> | \<Software Requirements Specification\> |
|
||||
| \<02\> | \<System Architecture Document\> |
|
||||
| | |
|
||||
|
||||
### 1.5 Overview
|
||||
|
||||
\<General overview of the detail design such as what is the structure of the document\>
|
||||
|
||||
---
|
||||
|
||||
## 2. Common Package and Mechanism
|
||||
|
||||
### 2.1 Common Package
|
||||
|
||||
#### 2.1.1 Class Diagram
|
||||
|
||||
\<Class diagram\>
|
||||
|
||||
| No | Class Name | Description |
|
||||
|----|-----------|-------------|
|
||||
| 01 | \<Name of class\> | \<Brief description about class ex. One sentence to tell what the class is for, what does it encapsulate\> |
|
||||
| 02 | | |
|
||||
| 03 | | |
|
||||
|
||||
#### 2.1.2 XXX Class
|
||||
|
||||
\<Class description\>
|
||||
|
||||
**Attributes**
|
||||
|
||||
| No | Attribute | Type | Default | Note | Description |
|
||||
|----|-----------|------|---------|------|-------------|
|
||||
| 01 | \<Attribute name\> | int | | Public/ Static | \<Description of attribute\> |
|
||||
| 02 | | | | | |
|
||||
|
||||
**Methods**
|
||||
|
||||
| No | Method | Description |
|
||||
|----|--------|-------------|
|
||||
| 01 | \<method name\> | \<brief description of method. can be one sentence tell what the method does\> |
|
||||
| 02 | | |
|
||||
| 03 | | |
|
||||
|
||||
**xxxx Method**
|
||||
|
||||
\<Method declaration\>
|
||||
|
||||
\<method description, it must be compliance with the brief description in the upper class list\>
|
||||
|
||||
**Parameters & Return**
|
||||
|
||||
| No | Parameter | Type | In/out | Default | Description |
|
||||
|----|-----------|------|--------|---------|-------------|
|
||||
| 01 | parameter name | int | | | \<Description of parameter, special criteria such as boundary should be stated\> |
|
||||
| 02 | | | | | |
|
||||
| 03 | \<return\> | | | | |
|
||||
|
||||
**Implementation**
|
||||
|
||||
\<How to implement the method, it can be in pseudo code or activity diagram or just words\>
|
||||
|
||||
### 2.2 Error, Exception Handling
|
||||
|
||||
#### 2.2.1 Class Diagram
|
||||
|
||||
\< Describe class like in common package\>
|
||||
|
||||
#### 2.2.2 Usage Mechanism
|
||||
|
||||
\<Common mechanism of exception handling\>
|
||||
|
||||
### 2.3 Log, Trace and Debug
|
||||
|
||||
\<Describe logging mechanism, trace and debug strategies\>
|
||||
|
||||
### 2.4 Performance Optimizing Mechanism
|
||||
|
||||
\<Describe performance optimization approaches\>
|
||||
|
||||
### 2.5 Multilingual Processing
|
||||
|
||||
\<Describe multilingual support implementation\>
|
||||
|
||||
---
|
||||
|
||||
## 3. Diagrams
|
||||
|
||||
\<Describe diagrams in system such as collaboration diagram, sequence diagram, activities diagram and state chart for some functionalities of the system\>
|
||||
|
||||
**Example: Customer management**
|
||||
|
||||
- **Add customer**
|
||||
|
||||
![Figure 1 Add Customer sequence diagram]
|
||||
|
||||
- **Update customer**
|
||||
|
||||
\<Include relevant sequence/collaboration diagrams\>
|
||||
|
||||
---
|
||||
|
||||
## 4. Packages
|
||||
|
||||
| No | Package | Language | Description |
|
||||
|----|---------|----------|-------------|
|
||||
| 01 | \<package name\> | C++, Java | \<brief description of package; can be one sentence tell what the method does\> |
|
||||
| 02 | | | |
|
||||
| 03 | | | |
|
||||
|
||||
### 4.1 XXX Package
|
||||
|
||||
#### 4.1.1 Class Diagram
|
||||
|
||||
\<Class diagram figure\>
|
||||
|
||||
| No | Class Name | Description |
|
||||
|----|-----------|-------------|
|
||||
| 01 | \<Name of class\> | \<Brief description about class ex. One sentence to tell what the class is for, what does it encapsulate\> |
|
||||
| 02 | | |
|
||||
| 03 | | |
|
||||
|
||||
#### 4.1.2 External Interface
|
||||
|
||||
\<Describe the external interface of the package (exported classes, methods).\>
|
||||
|
||||
#### 4.1.3 XXX Class
|
||||
|
||||
\<Class description\>
|
||||
|
||||
**Attributes**
|
||||
|
||||
| No | Attribute | Type | Default | Note | Description |
|
||||
|----|-----------|------|---------|------|-------------|
|
||||
| 01 | \<Attribute name\> | int | | Public/ Static | \<Description of attribute\> |
|
||||
| 02 | | | | | |
|
||||
| 03 | | | | | |
|
||||
|
||||
**Methods**
|
||||
|
||||
| No | Method | Description |
|
||||
|----|--------|-------------|
|
||||
| 01 | \<method name\> | \<brief description of method. can be one sentence tell what the method does\> |
|
||||
| 02 | | |
|
||||
| 03 | | |
|
||||
|
||||
**xxxx Method**
|
||||
|
||||
\<Method declaration\>
|
||||
|
||||
\<method description, it must be compliance with the brief description in the upper class list\>
|
||||
|
||||
**Parameters & Return**
|
||||
|
||||
| No | Parameter | Type | in/out | Default | Description |
|
||||
|----|-----------|------|--------|---------|-------------|
|
||||
| 01 | \<parameter name\> | int | | | \<Description of parameter, the special criteria such as boundary should be stated\> |
|
||||
| 02 | | | | | |
|
||||
| 03 | \<return\> | | | | |
|
||||
|
||||
### 4.2 Implementation
|
||||
|
||||
\<How to implement the method, it can be in pseudo code or activity diagram or just words\>
|
||||
|
||||
......
|
||||
|
||||
---
|
||||
|
||||
## 5. Database
|
||||
|
||||
### 5.1 ERDs
|
||||
|
||||
\<Include Entity Relationship Diagrams showing the logical and/or physical data model\>
|
||||
|
||||
### 5.2 XXX Table
|
||||
|
||||
\<Table description\>
|
||||
|
||||
**Table Structure**
|
||||
|
||||
| No | Column Name | Data Type | Length | Null | Default | PK | FK | Description |
|
||||
|----|------------|-----------|--------|------|---------|----|----|-------------|
|
||||
| 01 | \<column name\> | \<VARCHAR\> | \<50\> | \<N\> | | \<Y\> | | \<Description of column\> |
|
||||
| 02 | | | | | | | | |
|
||||
| 03 | | | | | | | | |
|
||||
|
||||
**Indexes**
|
||||
|
||||
| No | Index Name | Type | Columns | Description |
|
||||
|----|-----------|------|---------|-------------|
|
||||
| 01 | \<index name\> | \<Unique/Non-unique\> | \<column list\> | \<Description\> |
|
||||
| 02 | | | | |
|
||||
|
||||
**Constraints**
|
||||
|
||||
\<Describe any constraints, triggers, or business rules associated with the table\>
|
||||
|
||||
### 5.3 Store Procedure
|
||||
|
||||
#### 5.3.1 XXX Stored Procedure
|
||||
|
||||
**Purpose**
|
||||
|
||||
\<Describe the purpose and functionality of the stored procedure\>
|
||||
|
||||
**Parameters**
|
||||
|
||||
| No | Parameter Name | Data Type | In/Out | Default | Description |
|
||||
|----|---------------|-----------|--------|---------|-------------|
|
||||
| 01 | \<@parameter_name\> | \<VARCHAR(50)\> | \<IN\> | | \<Description\> |
|
||||
| 02 | | | | | |
|
||||
| 03 | \<@return_value\> | \<INT\> | \<OUT\> | | \<Description\> |
|
||||
|
||||
**Logic**
|
||||
|
||||
\<Describe the logic flow of the stored procedure\>
|
||||
|
||||
**Example**
|
||||
|
||||
```sql
|
||||
CREATE PROCEDURE [dbo].[XXX_ProcedureName]
|
||||
@param1 VARCHAR(50),
|
||||
@param2 INT
|
||||
AS
|
||||
BEGIN
|
||||
-- Procedure logic here
|
||||
END
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. File Design
|
||||
|
||||
### 6.1 File List
|
||||
|
||||
| No | File Name | Format | Description | Location |
|
||||
|----|-----------|--------|-------------|----------|
|
||||
| 01 | \<file name\> | \<CSV/XML/JSON\> | \<Brief description\> | \<Path or location\> |
|
||||
| 02 | | | | |
|
||||
| 03 | | | | |
|
||||
|
||||
### 6.2 XXX File
|
||||
|
||||
**File Description**
|
||||
|
||||
\<Describe the purpose and usage of the file\>
|
||||
|
||||
**File Format**
|
||||
|
||||
\<Specify the file format (CSV, XML, JSON, binary, etc.)\>
|
||||
|
||||
**File Structure**
|
||||
|
||||
| No | Field Name | Data Type | Length | Format | Description |
|
||||
|----|-----------|-----------|--------|--------|-------------|
|
||||
| 01 | \<field name\> | \<String\> | \<50\> | | \<Description\> |
|
||||
| 02 | | | | | |
|
||||
| 03 | | | | | |
|
||||
|
||||
**Sample Data**
|
||||
|
||||
\<Provide sample file content or record examples\>
|
||||
|
||||
**Processing Rules**
|
||||
|
||||
\<Describe any validation rules, processing logic, or constraints for the file\>
|
||||
|
||||
---
|
||||
|
||||
## 7. Code Design
|
||||
|
||||
\<Describe code-level design elements such as:
|
||||
- Code organization and structure
|
||||
- Key algorithms or complex logic
|
||||
- Design patterns used
|
||||
- Configuration management
|
||||
- Constants and enumerations
|
||||
- Utility functions\>
|
||||
|
||||
---
|
||||
|
||||
## 8. Edge Case Definition (エッジケース定義)
|
||||
|
||||
\<Define all edge cases per feature/function, covering abnormal inputs, boundary values, and runtime exceptions. Each subsection below should be filled per functional requirement ID (BD ID).\
|
||||
|
||||
### 8.1 Abnormal Value Definition (異常値定義)
|
||||
|
||||
\<Define invalid or unexpected inputs and the expected system behavior for each.\>
|
||||
|
||||
| Edge Case ID | BD ID | Input Item | Abnormal Condition | Expected System Behavior | Error Code | Log Level | User Message |
|
||||
|--------------|-------|-----------|-------------------|-------------------------|------------|-----------|-------------|
|
||||
| EC-001 | \<F-01\> | \<Email\> | \<Null\> | \<Reject request\> | \<ERR-001\> | \<WARN\> | \<Email is required\> |
|
||||
| EC-002 | | | | | | | |
|
||||
| EC-003 | | | | | | | |
|
||||
|
||||
### 8.2 Boundary Value Definition (境界値定義)
|
||||
|
||||
\<Define minimum, maximum, and limit cases for input fields.\>
|
||||
|
||||
| Boundary ID | BD ID | Field Name | Min | Max | Test Value | Expected Result |
|
||||
|-------------|-------|-----------|-----|-----|------------|----------------|
|
||||
| BV-001 | \<F-01\> | \<Username\> | \<1\> | \<50\> | \<0\> | \<Error\> |
|
||||
| BV-002 | | | | | \<1\> | \<OK\> |
|
||||
| BV-003 | | | | | \<50\> | \<OK\> |
|
||||
| BV-004 | | | | | \<51\> | \<Error\> |
|
||||
|
||||
### 8.3 Exception Handling Definition (例外処理定義)
|
||||
|
||||
\<Define system-level or runtime exceptions, including transaction handling and retry policy.\>
|
||||
|
||||
| Exception ID | Scenario | Trigger Condition | System Behavior | Transaction Handling | Retry Policy | Log Level | User Impact |
|
||||
|-------------|----------|------------------|----------------|--------------------|--------------|-----------|------------|
|
||||
| EX-001 | \<DB connection failure\> | \<DB unavailable\> | \<Abort process\> | \<Rollback\> | \<No retry\> | \<ERROR\> | \<Show system error message\> |
|
||||
| EX-002 | \<Duplicate data\> | \<Unique constraint violation\> | \<Reject insert\> | \<No rollback\> | \<No retry\> | \<WARN\> | \<Show duplication message\> |
|
||||
| EX-003 | | | | | | | |
|
||||
|
||||
---
|
||||
|
||||
## 9. Other Considerations
|
||||
|
||||
\<This section provides a description of other design elements that were considered as alternatives in selection process for the above design, i.e. a brief explanation of advantages and disadvantages of the selected package relationships, class implementation, database structure, and/or file formats in comparison with others. It should be a clear answer to the question why the above design is selected for this system, not the others.\>
|
||||
|
||||
---
|
||||
|
||||
## 10. Appendix
|
||||
|
||||
\<Include any additional supporting information such as:
|
||||
- Glossary
|
||||
- Additional diagrams
|
||||
- Code samples
|
||||
- Reference materials
|
||||
- Tools and technologies used\>
|
||||
@@ -1,108 +0,0 @@
|
||||
# Implementation Plan: [FEATURE]
|
||||
|
||||
**Branch**: `[###-feature-name]` | **Date**: [DATE] | **Spec**: [link]
|
||||
**Input**: Feature specification from `/specs/[###-feature-name]/spec.md`
|
||||
|
||||
**Note**: This template is filled in by the `/speckit.plan` command. See `.specify/templates/plan-template.md` for the execution workflow.
|
||||
|
||||
## Summary
|
||||
|
||||
[Extract from feature spec: primary requirement + technical approach from research]
|
||||
|
||||
## Technical Context
|
||||
|
||||
<!--
|
||||
ACTION REQUIRED: Replace the content in this section with the technical details
|
||||
for the project. The structure here is presented in advisory capacity to guide
|
||||
the iteration process.
|
||||
-->
|
||||
|
||||
**Language/Version**: [e.g., Python 3.11, Swift 5.9, Rust 1.75 or NEEDS CLARIFICATION]
|
||||
**Primary Dependencies**: [e.g., FastAPI, UIKit, LLVM or NEEDS CLARIFICATION]
|
||||
**Storage**: [if applicable, e.g., PostgreSQL, CoreData, files or N/A]
|
||||
**Testing**: [e.g., pytest, XCTest, cargo test or NEEDS CLARIFICATION]
|
||||
**Target Platform**: [e.g., Linux server, iOS 15+, WASM or NEEDS CLARIFICATION]
|
||||
**Project Type**: [e.g., library/cli/web-service/mobile-app/compiler/desktop-app or NEEDS CLARIFICATION]
|
||||
**Performance Goals**: [domain-specific, e.g., 1000 req/s, 10k lines/sec, 60 fps or NEEDS CLARIFICATION]
|
||||
**Constraints**: [domain-specific, e.g., <200ms p95, <100MB memory, offline-capable or NEEDS CLARIFICATION]
|
||||
**Scale/Scope**: [domain-specific, e.g., 10k users, 1M LOC, 50 screens or NEEDS CLARIFICATION]
|
||||
|
||||
## Constitution Check
|
||||
|
||||
*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
|
||||
|
||||
- Requirement-first scope is preserved: the plan resolves implementation only for behavior already justified by the spec.
|
||||
- All unresolved business rules from spec.md are either clarified or explicitly carried as constraints; none are silently assumed.
|
||||
- Strict TDD is enforceable: for every story, the plan identifies the tests that will be written first before implementation begins.
|
||||
- Stories remain independently testable and traceable to user roles, business workflow steps, and acceptance scenarios.
|
||||
- Technical decisions included here are limited to mandated constraints or decisions necessary to implement approved behavior.
|
||||
|
||||
## Project Structure
|
||||
|
||||
### Documentation (this feature)
|
||||
|
||||
```text
|
||||
specs/[###-feature]/
|
||||
├── plan.md # This file (/speckit.plan command output)
|
||||
├── research.md # Phase 0 output (/speckit.plan command)
|
||||
├── data-model.md # Phase 1 output (/speckit.plan command)
|
||||
├── quickstart.md # Phase 1 output (/speckit.plan command)
|
||||
├── contracts/ # Phase 1 output (/speckit.plan command)
|
||||
└── tasks.md # Phase 2 output (/speckit.tasks command - NOT created by /speckit.plan)
|
||||
```
|
||||
|
||||
### Source Code (repository root)
|
||||
<!--
|
||||
ACTION REQUIRED: Replace the placeholder tree below with the concrete layout
|
||||
for this feature. Delete unused options and expand the chosen structure with
|
||||
real paths (e.g., apps/admin, packages/something). The delivered plan must
|
||||
not include Option labels.
|
||||
-->
|
||||
|
||||
```text
|
||||
# [REMOVE IF UNUSED] Option 1: Single project (DEFAULT)
|
||||
src/
|
||||
├── models/
|
||||
├── services/
|
||||
├── cli/
|
||||
└── lib/
|
||||
|
||||
tests/
|
||||
├── contract/
|
||||
├── integration/
|
||||
└── unit/
|
||||
|
||||
# [REMOVE IF UNUSED] Option 2: Web application (when "frontend" + "backend" detected)
|
||||
backend/
|
||||
├── src/
|
||||
│ ├── models/
|
||||
│ ├── services/
|
||||
│ └── api/
|
||||
└── tests/
|
||||
|
||||
frontend/
|
||||
├── src/
|
||||
│ ├── components/
|
||||
│ ├── pages/
|
||||
│ └── services/
|
||||
└── tests/
|
||||
|
||||
# [REMOVE IF UNUSED] Option 3: Mobile + API (when "iOS/Android" detected)
|
||||
api/
|
||||
└── [same as backend above]
|
||||
|
||||
ios/ or android/
|
||||
└── [platform-specific structure: feature modules, UI flows, platform tests]
|
||||
```
|
||||
|
||||
**Structure Decision**: [Document the selected structure and reference the real
|
||||
directories captured above]
|
||||
|
||||
## Complexity Tracking
|
||||
|
||||
> **Fill ONLY if Constitution Check has violations that must be justified**
|
||||
|
||||
| Violation | Why Needed | Simpler Alternative Rejected Because |
|
||||
|-----------|------------|-------------------------------------|
|
||||
| [e.g., 4th project] | [current need] | [why 3 projects insufficient] |
|
||||
| [e.g., Repository pattern] | [specific problem] | [why direct DB access insufficient] |
|
||||
@@ -1,143 +0,0 @@
|
||||
# Feature Specification: [FEATURE NAME]
|
||||
|
||||
**Feature Branch**: `[###-feature-name]`
|
||||
**Created**: [DATE]
|
||||
**Status**: Draft
|
||||
**Input**: User description: "$ARGUMENTS"
|
||||
|
||||
> Write this specification in requirement language only. Focus on what the system must do and why the
|
||||
> behavior matters. Do not choose a technical stack or implementation approach unless the input explicitly
|
||||
> mandates it.
|
||||
|
||||
## User Scenarios & Testing *(mandatory)*
|
||||
|
||||
<!--
|
||||
IMPORTANT: User stories should be PRIORITIZED as user journeys ordered by importance.
|
||||
Each user story/journey must be INDEPENDENTLY TESTABLE - meaning if you implement just ONE of them,
|
||||
you should still have a viable MVP (Minimum Viable Product) that delivers value.
|
||||
|
||||
Assign priorities (P1, P2, P3, etc.) to each story, where P1 is the most critical.
|
||||
Think of each story as a standalone slice of functionality that can be:
|
||||
- Developed independently
|
||||
- Tested independently
|
||||
- Deployed independently
|
||||
- Demonstrated to users independently
|
||||
- Implemented with tests written first and observed failing before code changes
|
||||
-->
|
||||
|
||||
### Test-First Delivery Rules
|
||||
|
||||
<!--
|
||||
ACTION REQUIRED: Replace this section with project-specific test-first rules.
|
||||
Strict TDD is mandatory:
|
||||
- Tests MUST be written before implementation
|
||||
- Tests MUST fail first for the expected reason
|
||||
- Implementation MUST be the minimum change required to pass
|
||||
- Refactoring happens only after tests pass
|
||||
-->
|
||||
|
||||
- [Document the non-negotiable TDD rules for this feature]
|
||||
|
||||
### User Story 1 - [Brief Title] (Priority: P1)
|
||||
|
||||
[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 - e.g., "Can be fully tested by [specific action] and delivers [specific value]"]
|
||||
|
||||
**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]
|
||||
|
||||
---
|
||||
|
||||
[Add more user stories as needed, each with an assigned priority]
|
||||
|
||||
### Edge Cases
|
||||
|
||||
<!--
|
||||
ACTION REQUIRED: The content in this section represents placeholders.
|
||||
Fill them out with the right edge cases.
|
||||
-->
|
||||
|
||||
- What happens when [boundary condition]?
|
||||
- How does system handle [error scenario]?
|
||||
|
||||
## Requirements *(mandatory)*
|
||||
|
||||
<!--
|
||||
ACTION REQUIRED: The content in this section represents placeholders.
|
||||
Fill them out with the right functional requirements.
|
||||
-->
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: System MUST [specific capability, e.g., "allow users to create accounts"]
|
||||
- **FR-002**: System MUST [specific capability, e.g., "validate email addresses"]
|
||||
- **FR-003**: Users MUST be able to [key interaction, e.g., "reset their password"]
|
||||
- **FR-004**: System MUST [data requirement, e.g., "persist user preferences"]
|
||||
- **FR-005**: System MUST [behavior, e.g., "log all security events"]
|
||||
|
||||
### Clarifications Needed
|
||||
|
||||
<!--
|
||||
ACTION REQUIRED: Capture unresolved business rules here instead of guessing.
|
||||
Use this section whenever the input mentions UI elements, workflow states, roles,
|
||||
calculations, or data rules without defining the expected behavior.
|
||||
-->
|
||||
|
||||
- **CL-001**: [Describe unresolved requirement and why it blocks or constrains design]
|
||||
|
||||
*Example of marking unclear requirements:*
|
||||
|
||||
- **FR-006**: System MUST authenticate users via [NEEDS CLARIFICATION: auth method not specified - email/password, SSO, OAuth?]
|
||||
- **FR-007**: System MUST retain user data for [NEEDS CLARIFICATION: retention period not specified]
|
||||
|
||||
### Key Entities *(include if feature involves data)*
|
||||
|
||||
- **[Entity 1]**: [What it represents, key attributes without implementation]
|
||||
- **[Entity 2]**: [What it represents, relationships to other entities]
|
||||
|
||||
## Success Criteria *(mandatory)*
|
||||
|
||||
<!--
|
||||
ACTION REQUIRED: Define measurable success criteria.
|
||||
These must be technology-agnostic and measurable.
|
||||
-->
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: [Measurable metric, e.g., "Users can complete account creation in under 2 minutes"]
|
||||
- **SC-002**: [Measurable metric, e.g., "System handles 1000 concurrent users without degradation"]
|
||||
- **SC-003**: [User satisfaction metric, e.g., "90% of users successfully complete primary task on first attempt"]
|
||||
- **SC-004**: [Business metric, e.g., "Reduce support tickets related to [X] by 50%"]
|
||||
@@ -1,248 +0,0 @@
|
||||
# Software Requirements Specification — [PROJECT_NAME]
|
||||
|
||||
**Project Code:** [PROJECT_CODE] | **Doc Code:** [DOCUMENT_CODE] | **Version:** [VERSION] | **Date:** [EFFECTIVE_DATE]
|
||||
|
||||
## Record of Change
|
||||
|
||||
| No | Date | Version | Description | Reason |
|
||||
|----|------|---------|-------------|--------|
|
||||
| 1 | [dd/mm/yyyy] | 1.0 | Initial version | Feature request |
|
||||
|
||||
---
|
||||
|
||||
## TABLE OF CONTENTS
|
||||
|
||||
1. [Introduction](#1-introduction)
|
||||
- 1.1 [Purpose](#11-purpose)
|
||||
- 1.2 [Scope](#12-scope)
|
||||
- 1.3 [Definitions, Acronyms, and Abbreviations](#13-definitions-acronyms-and-abbreviations)
|
||||
- 1.4 [References](#14-references)
|
||||
- 1.5 [Overview](#15-overview)
|
||||
2. [Overall Description](#2-overall-description)
|
||||
- 2.1 [Product Perspective](#21-product-perspective)
|
||||
- 2.2 [Product Functions](#22-product-functions)
|
||||
- 2.3 [User Characteristics](#23-user-characteristics)
|
||||
- 2.4 [Constraints](#24-constraints)
|
||||
- 2.5 [Assumptions and Dependencies](#25-assumptions-and-dependencies)
|
||||
3. [Specific Requirements](#3-specific-requirements)
|
||||
- 3.1 [Functionality](#31-functionality)
|
||||
- 3.2 [Usability](#32-usability)
|
||||
- 3.3 [Reliability](#33-reliability)
|
||||
- 3.4 [Performance](#34-performance)
|
||||
- 3.5 [Supportability](#35-supportability)
|
||||
- 3.6 [Design Constraints](#36-design-constraints)
|
||||
- 3.7 [Online Documentation Requirements](#37-online-documentation-requirements)
|
||||
- 3.8 [Purchased Components](#38-purchased-components)
|
||||
- 3.9 [Interfaces](#39-interfaces)
|
||||
- 3.10 [Licensing Requirements](#310-licensing-requirements)
|
||||
- 3.11 [Legal, Copyright, and Other Notices](#311-legal-copyright-and-other-notices)
|
||||
- 3.12 [Applicable Standards](#312-applicable-standards)
|
||||
4. [Supporting Information](#4-supporting-information)
|
||||
- 4.1 [Glossary](#41-glossary)
|
||||
- 4.2 [Open Issues](#42-open-issues)
|
||||
|
||||
---
|
||||
|
||||
## 1 Introduction
|
||||
|
||||
### 1.1 Purpose
|
||||
|
||||
[Purpose of this SRS and what system/feature it specifies.]
|
||||
|
||||
**Target Audience**: [developers, testers, project managers, stakeholders]
|
||||
|
||||
### 1.2 Scope
|
||||
|
||||
**System Name**: [Name]
|
||||
**Objectives**: [Key goals]
|
||||
**In Scope**: [What is included]
|
||||
**Out of Scope**: [What is excluded]
|
||||
|
||||
### 1.3 Definitions, Acronyms, and Abbreviations
|
||||
|
||||
| Term | Definition |
|
||||
|------|------------|
|
||||
| IPA | Information-technology Promotion Agency |
|
||||
| SRS | Software Requirements Specification |
|
||||
| OWASP | Open Web Application Security Project |
|
||||
| [TERM] | [Definition] |
|
||||
|
||||
### 1.4 References
|
||||
|
||||
| No | Title | Version |
|
||||
|----|-------|---------|
|
||||
| 1 | [PROJECT_NAME] Constitution | — |
|
||||
| 2 | IEEE 830-1998 SRS Standard | — |
|
||||
| 3 | OWASP Top 10 | Latest |
|
||||
|
||||
### 1.5 Overview
|
||||
|
||||
Sections: **1** Introduction · **2** Overall Description · **3** Specific Requirements · **4** Supporting Information.
|
||||
|
||||
---
|
||||
|
||||
## 2 Overall Description
|
||||
|
||||
### 2.1 Product Perspective
|
||||
|
||||
[Context: new product / enhancement / component of larger system.]
|
||||
|
||||
- **System Interfaces**: [Other systems this interacts with]
|
||||
- **User Interfaces**: [General UI characteristics]
|
||||
- **Software Interfaces**: [Databases, libraries, OS dependencies]
|
||||
- **Communications**: [Network protocols, message formats]
|
||||
|
||||
### 2.2 Product Functions
|
||||
|
||||
[Summary of major functions — details are in Section 3.]
|
||||
|
||||
- [FUNCTION_1]: [description]
|
||||
- [FUNCTION_2]: [description]
|
||||
|
||||
### 2.3 User Characteristics
|
||||
|
||||
| User Type | Characteristics | Primary Use |
|
||||
|-----------|----------------|-------------|
|
||||
| [TYPE_1] | [description] | [tasks] |
|
||||
| [TYPE_2] | [description] | [tasks] |
|
||||
|
||||
### 2.4 Constraints
|
||||
|
||||
- **Regulatory**: [Legal/compliance requirements]
|
||||
- **Security**: [OWASP Top 10 compliance required]
|
||||
- **Development Standards**: [IPA coding/doc standards]
|
||||
- **Other**: [Hardware, integration, or operational limits]
|
||||
|
||||
### 2.5 Assumptions and Dependencies
|
||||
|
||||
**Assumptions**:
|
||||
- [ASSUMPTION_1]
|
||||
|
||||
**Dependencies**:
|
||||
- [DEPENDENCY_1]
|
||||
|
||||
---
|
||||
|
||||
## 3 Specific Requirements
|
||||
|
||||
### 3.1 Functionality
|
||||
|
||||
Functional requirements format:
|
||||
|
||||
**FR-[CAT]-NNN**: [Title]
|
||||
- **Description**: [What the system shall do]
|
||||
- **Input**: [Inputs required]
|
||||
- **Processing**: [High-level logic]
|
||||
- **Output**: [Result/output]
|
||||
- **Priority**: High / Medium / Low
|
||||
- **Dependencies**: [Other FR IDs, if any]
|
||||
- **Acceptance Criteria**:
|
||||
- Given [condition], when [action], then [result]
|
||||
|
||||
#### 3.1.1 [Feature Category 1]
|
||||
|
||||
**FR-[CAT]-001**: [Title]
|
||||
- **Description**: [...]
|
||||
- **Input**: [...]
|
||||
- **Processing**: [...]
|
||||
- **Output**: [...]
|
||||
- **Priority**: [High/Medium/Low]
|
||||
- **Dependencies**: —
|
||||
- **Acceptance Criteria**:
|
||||
- Given [...], when [...], then [...]
|
||||
|
||||
[Add more FR-[CAT]-NNN entries as needed]
|
||||
|
||||
### 3.2 Usability
|
||||
|
||||
**UR-001**: [Users shall become productive within X hours of training]
|
||||
**UR-002**: [Common tasks completable within X steps/seconds]
|
||||
**UR-003**: [Accessibility or standards compliance requirement]
|
||||
|
||||
### 3.3 Reliability
|
||||
|
||||
**RR-001**: System shall be available [XX%] of the time; planned downtime windows: [specify].
|
||||
**RR-002**: Recovery time after failure shall not exceed [X] minutes.
|
||||
**RR-003**: Data calculations shall be accurate to [X] decimal places.
|
||||
|
||||
### 3.4 Performance
|
||||
|
||||
**PR-001**: [Operation] shall complete within [X] seconds at average load (95th pct ≤ [Y]s).
|
||||
**PR-002**: System shall handle at least [X] concurrent users / [Y] transactions per second.
|
||||
**PR-003**: [Capacity or resource utilization constraint]
|
||||
|
||||
### 3.5 Supportability
|
||||
|
||||
**SR-001**: Code shall conform to [standard]; test coverage ≥ [X]%.
|
||||
**SR-002**: All errors shall be logged with stack traces; health-check endpoints provided.
|
||||
**SR-003**: [Naming conventions or other maintainability requirements]
|
||||
|
||||
### 3.6 Design Constraints
|
||||
|
||||
**DC-001**: Technology stack — Language: [X]; Framework: [Y]; Database: [Z].
|
||||
**DC-002**: Architecture — [Pattern, e.g., MVC/microservices]; component communication via [protocol].
|
||||
**DC-003**: Tooling — VCS: Git; CI/CD: [tool]; Test framework: [tool].
|
||||
|
||||
### 3.7 Online Documentation Requirements
|
||||
|
||||
[Requirements for user manuals, context-sensitive help, or auto-generated API docs. Mark "Not applicable" if none.]
|
||||
|
||||
### 3.8 Purchased Components
|
||||
|
||||
| Component | Vendor | Version | License | Purpose |
|
||||
|-----------|--------|---------|---------|---------|
|
||||
| [NAME] | [VENDOR] | [VERSION] | [LICENSE] | [PURPOSE] |
|
||||
|
||||
All components must have no critical CVEs and be actively maintained.
|
||||
|
||||
### 3.9 Interfaces
|
||||
|
||||
#### 3.9.1 User Interfaces
|
||||
|
||||
**UI-001**: [Screen name] — [description, key inputs, available actions]
|
||||
|
||||
#### 3.9.2 Software Interfaces
|
||||
|
||||
**SI-001**: [System] — Type: [REST/gRPC/MQ]; Protocol: [HTTP/S]; Format: [JSON]; Auth: [method].
|
||||
|
||||
#### 3.9.3 Hardware Interfaces
|
||||
|
||||
[Describe or mark "Not applicable".]
|
||||
|
||||
#### 3.9.4 Communications Interfaces
|
||||
|
||||
[Network protocol, message format, TLS requirements, or "Not applicable".]
|
||||
|
||||
### 3.10 Licensing Requirements
|
||||
|
||||
[License enforcement rules, or "Not applicable".]
|
||||
|
||||
### 3.11 Legal, Copyright, and Other Notices
|
||||
|
||||
[Copyright statement, open-source license disclosures, disclaimers.]
|
||||
|
||||
### 3.12 Applicable Standards
|
||||
|
||||
| Standard | Application |
|
||||
|----------|-------------|
|
||||
| IPA Documentation Standards | Document structure |
|
||||
| OWASP Top 10 | Security requirements (Sec 3.1, 3.9) |
|
||||
| IEEE 830-1998 | SRS structure |
|
||||
|
||||
---
|
||||
|
||||
## 4 Supporting Information
|
||||
|
||||
### 4.1 Glossary
|
||||
|
||||
[Additional term definitions not in Section 1.3, if needed.]
|
||||
|
||||
### 4.2 Open Issues
|
||||
|
||||
| ID | Description | Status |
|
||||
|----|-------------|--------|
|
||||
| ISS-001 | [description] | Open |
|
||||
|
||||
---
|
||||
|
||||
**Document Status**: [Draft/Review/Approved] | **Last Updated**: [DATE]
|
||||
@@ -1,251 +0,0 @@
|
||||
---
|
||||
|
||||
description: "Task list template for feature implementation"
|
||||
---
|
||||
|
||||
# Tasks: [FEATURE NAME]
|
||||
|
||||
**Input**: Design documents from `/specs/[###-feature-name]/`
|
||||
**Prerequisites**: plan.md (required), spec.md (required for user stories), research.md, data-model.md, contracts/
|
||||
|
||||
**Tests**: Tests are MANDATORY. For every user story, create the required test tasks first and order them before implementation tasks.
|
||||
|
||||
**Organization**: Tasks are grouped by user story to enable independent implementation and testing of each story.
|
||||
|
||||
## Format: `[ID] [P?] [Story] Description`
|
||||
|
||||
- **[P]**: Can run in parallel (different files, no dependencies)
|
||||
- **[Story]**: Which user story this task belongs to (e.g., US1, US2, US3)
|
||||
- Include exact file paths in descriptions
|
||||
|
||||
## Path Conventions
|
||||
|
||||
- **Single project**: `src/`, `tests/` at repository root
|
||||
- **Web app**: `backend/src/`, `frontend/src/`
|
||||
- **Mobile**: `api/src/`, `ios/src/` or `android/src/`
|
||||
- Paths shown below assume single project - adjust based on plan.md structure
|
||||
|
||||
<!--
|
||||
============================================================================
|
||||
IMPORTANT: The tasks below are SAMPLE TASKS for illustration purposes only.
|
||||
|
||||
The /speckit.tasks command MUST replace these with actual tasks based on:
|
||||
- User stories from spec.md (with their priorities P1, P2, P3...)
|
||||
- Feature requirements from plan.md
|
||||
- Entities from data-model.md
|
||||
- Endpoints from contracts/
|
||||
|
||||
Tasks MUST be organized by user story so each story can be:
|
||||
- Implemented independently
|
||||
- Tested independently
|
||||
- Delivered as an MVP increment
|
||||
|
||||
DO NOT keep these sample tasks in the generated tasks.md file.
|
||||
============================================================================
|
||||
-->
|
||||
|
||||
## Phase 1: Setup (Shared Infrastructure)
|
||||
|
||||
**Purpose**: Project initialization and basic structure
|
||||
|
||||
- [ ] T001 Create project structure per implementation plan
|
||||
- [ ] T002 Initialize [language] project with [framework] dependencies
|
||||
- [ ] T003 [P] Configure linting and formatting tools
|
||||
|
||||
---
|
||||
|
||||
## Phase 2: Foundational (Blocking Prerequisites)
|
||||
|
||||
**Purpose**: Core infrastructure that MUST be complete before ANY user story can be implemented
|
||||
|
||||
**⚠️ CRITICAL**: No user story work can begin until this phase is complete
|
||||
|
||||
Examples of foundational tasks (adjust based on your project):
|
||||
|
||||
- [ ] T004 Setup database schema and migrations framework
|
||||
- [ ] T005 [P] Implement authentication/authorization framework
|
||||
- [ ] T006 [P] Setup API routing and middleware structure
|
||||
- [ ] T007 Create base models/entities that all stories depend on
|
||||
- [ ] T008 Configure error handling and logging infrastructure
|
||||
- [ ] T009 Setup environment configuration management
|
||||
|
||||
**Checkpoint**: Foundation ready - user story implementation can now begin in parallel
|
||||
|
||||
---
|
||||
|
||||
## Phase 3: User Story 1 - [Title] (Priority: P1) 🎯 MVP
|
||||
|
||||
**Goal**: [Brief description of what this story delivers]
|
||||
|
||||
**Independent Test**: [How to verify this story works on its own]
|
||||
|
||||
### Tests for User Story 1 ⚠️
|
||||
|
||||
> **NOTE: Write these tests FIRST, ensure they FAIL before implementation, and record the failing behavior being protected**
|
||||
|
||||
- [ ] T010 [P] [US1] Contract test for [endpoint] in tests/contract/test_[name].py
|
||||
- [ ] T011 [P] [US1] Integration test for [user journey] in tests/integration/test_[name].py
|
||||
|
||||
### Implementation for User Story 1
|
||||
|
||||
- [ ] T012 [P] [US1] Create [Entity1] model in src/models/[entity1].py
|
||||
- [ ] T013 [P] [US1] Create [Entity2] model in src/models/[entity2].py
|
||||
- [ ] T014 [US1] Implement [Service] in src/services/[service].py (depends on T012, T013)
|
||||
- [ ] T015 [US1] Implement [endpoint/feature] in src/[location]/[file].py
|
||||
- [ ] T016 [US1] Add validation and error handling
|
||||
- [ ] T017 [US1] Add logging for user story 1 operations
|
||||
|
||||
**Checkpoint**: At this point, User Story 1 should be fully functional and testable independently
|
||||
|
||||
---
|
||||
|
||||
## Phase 4: User Story 2 - [Title] (Priority: P2)
|
||||
|
||||
**Goal**: [Brief description of what this story delivers]
|
||||
|
||||
**Independent Test**: [How to verify this story works on its own]
|
||||
|
||||
### Tests for User Story 2 ⚠️
|
||||
|
||||
- [ ] T018 [P] [US2] Contract test for [endpoint] in tests/contract/test_[name].py
|
||||
- [ ] T019 [P] [US2] Integration test for [user journey] in tests/integration/test_[name].py
|
||||
|
||||
### Implementation for User Story 2
|
||||
|
||||
- [ ] T020 [P] [US2] Create [Entity] model in src/models/[entity].py
|
||||
- [ ] T021 [US2] Implement [Service] in src/services/[service].py
|
||||
- [ ] T022 [US2] Implement [endpoint/feature] in src/[location]/[file].py
|
||||
- [ ] T023 [US2] Integrate with User Story 1 components (if needed)
|
||||
|
||||
**Checkpoint**: At this point, User Stories 1 AND 2 should both work independently
|
||||
|
||||
---
|
||||
|
||||
## Phase 5: User Story 3 - [Title] (Priority: P3)
|
||||
|
||||
**Goal**: [Brief description of what this story delivers]
|
||||
|
||||
**Independent Test**: [How to verify this story works on its own]
|
||||
|
||||
### Tests for User Story 3 ⚠️
|
||||
|
||||
- [ ] T024 [P] [US3] Contract test for [endpoint] in tests/contract/test_[name].py
|
||||
- [ ] T025 [P] [US3] Integration test for [user journey] in tests/integration/test_[name].py
|
||||
|
||||
### Implementation for User Story 3
|
||||
|
||||
- [ ] T026 [P] [US3] Create [Entity] model in src/models/[entity].py
|
||||
- [ ] T027 [US3] Implement [Service] in src/services/[service].py
|
||||
- [ ] T028 [US3] Implement [endpoint/feature] in src/[location]/[file].py
|
||||
|
||||
**Checkpoint**: All user stories should now be independently functional
|
||||
|
||||
---
|
||||
|
||||
[Add more user story phases as needed, following the same pattern]
|
||||
|
||||
---
|
||||
|
||||
## Phase N: Polish & Cross-Cutting Concerns
|
||||
|
||||
**Purpose**: Improvements that affect multiple user stories
|
||||
|
||||
- [ ] TXXX [P] Documentation updates in docs/
|
||||
- [ ] TXXX Code cleanup and refactoring
|
||||
- [ ] TXXX Performance optimization across all stories
|
||||
- [ ] TXXX [P] Additional unit tests (if requested) in tests/unit/
|
||||
- [ ] TXXX Security hardening
|
||||
- [ ] TXXX Run quickstart.md validation
|
||||
|
||||
---
|
||||
|
||||
## Dependencies & Execution Order
|
||||
|
||||
### Phase Dependencies
|
||||
|
||||
- **Setup (Phase 1)**: No dependencies - can start immediately
|
||||
- **Foundational (Phase 2)**: Depends on Setup completion - BLOCKS all user stories
|
||||
- **User Stories (Phase 3+)**: All depend on Foundational phase completion
|
||||
- User stories can then proceed in parallel (if staffed)
|
||||
- Or sequentially in priority order (P1 → P2 → P3)
|
||||
- **Polish (Final Phase)**: Depends on all desired user stories being complete
|
||||
|
||||
### User Story Dependencies
|
||||
|
||||
- **User Story 1 (P1)**: Can start after Foundational (Phase 2) - No dependencies on other stories
|
||||
- **User Story 2 (P2)**: Can start after Foundational (Phase 2) - May integrate with US1 but should be independently testable
|
||||
- **User Story 3 (P3)**: Can start after Foundational (Phase 2) - May integrate with US1/US2 but should be independently testable
|
||||
|
||||
### Within Each User Story
|
||||
|
||||
- Tests MUST be written and FAIL before implementation
|
||||
- Models before services
|
||||
- Services before endpoints
|
||||
- Core implementation before integration
|
||||
- Story complete before moving to next priority
|
||||
|
||||
### Parallel Opportunities
|
||||
|
||||
- All Setup tasks marked [P] can run in parallel
|
||||
- All Foundational tasks marked [P] can run in parallel (within Phase 2)
|
||||
- Once Foundational phase completes, all user stories can start in parallel (if team capacity allows)
|
||||
- All tests for a user story marked [P] can run in parallel
|
||||
- Models within a story marked [P] can run in parallel
|
||||
- Different user stories can be worked on in parallel by different team members
|
||||
|
||||
---
|
||||
|
||||
## Parallel Example: User Story 1
|
||||
|
||||
```bash
|
||||
# Launch all tests for User Story 1 together:
|
||||
Task: "Contract test for [endpoint] in tests/contract/test_[name].py"
|
||||
Task: "Integration test for [user journey] in tests/integration/test_[name].py"
|
||||
|
||||
# Launch all models for User Story 1 together:
|
||||
Task: "Create [Entity1] model in src/models/[entity1].py"
|
||||
Task: "Create [Entity2] model in src/models/[entity2].py"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Implementation Strategy
|
||||
|
||||
### MVP First (User Story 1 Only)
|
||||
|
||||
1. Complete Phase 1: Setup
|
||||
2. Complete Phase 2: Foundational (CRITICAL - blocks all stories)
|
||||
3. Complete Phase 3: User Story 1
|
||||
4. **STOP and VALIDATE**: Test User Story 1 independently
|
||||
5. Deploy/demo if ready
|
||||
|
||||
### Incremental Delivery
|
||||
|
||||
1. Complete Setup + Foundational → Foundation ready
|
||||
2. Add User Story 1 → Test independently → Deploy/Demo (MVP!)
|
||||
3. Add User Story 2 → Test independently → Deploy/Demo
|
||||
4. Add User Story 3 → Test independently → Deploy/Demo
|
||||
5. Each story adds value without breaking previous stories
|
||||
|
||||
### Parallel Team Strategy
|
||||
|
||||
With multiple developers:
|
||||
|
||||
1. Team completes Setup + Foundational together
|
||||
2. Once Foundational is done:
|
||||
- Developer A: User Story 1
|
||||
- Developer B: User Story 2
|
||||
- Developer C: User Story 3
|
||||
3. Stories complete and integrate independently
|
||||
|
||||
---
|
||||
|
||||
## Notes
|
||||
|
||||
- [P] tasks = different files, no dependencies
|
||||
- [Story] label maps task to specific user story for traceability
|
||||
- Each user story should be independently completable and testable
|
||||
- Verify tests fail before implementing
|
||||
- Commit after each task or logical group
|
||||
- Stop at any checkpoint to validate story independently
|
||||
- Avoid: vague tasks, same file conflicts, cross-story dependencies that break independence
|
||||
Reference in New Issue
Block a user