aiwf 0.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/AI-WORKFLOW.md +285 -0
- package/CHANGELOG.md +1 -0
- package/COMMANDS_GUIDE.md +462 -0
- package/LICENSE +21 -0
- package/PRD.ko.md +96 -0
- package/PRD.md +98 -0
- package/README.ko.md +115 -0
- package/README.md +117 -0
- package/claude-code/docker/Dockerfile +117 -0
- package/claude-code/simone/.simone/00_PROJECT_MANIFEST.md +49 -0
- package/claude-code/simone/.simone/01_PROJECT_DOCS/ARCHITECTURE.md +55 -0
- package/claude-code/simone/.simone/02_REQUIREMENTS/CLAUDE.md +78 -0
- package/claude-code/simone/.simone/02_REQUIREMENTS/M01_Backend_Setup/M01_milestone_meta.md +38 -0
- package/claude-code/simone/.simone/02_REQUIREMENTS/M01_Backend_Setup/PRD_AMEND_01_Auth_Flow_Update.md +69 -0
- package/claude-code/simone/.simone/02_REQUIREMENTS/M01_Backend_Setup/PRD_Backend_Setup.md +98 -0
- package/claude-code/simone/.simone/02_REQUIREMENTS/M01_Backend_Setup/SPECS_API_V1.md +232 -0
- package/claude-code/simone/.simone/03_SPRINTS/CLAUDE.MD +62 -0
- package/claude-code/simone/.simone/03_SPRINTS/S01_M01_Initial_API/S01_sprint_meta.md +42 -0
- package/claude-code/simone/.simone/03_SPRINTS/S01_M01_Initial_API/T01_S01_Setup_Project_Structure.md +56 -0
- package/claude-code/simone/.simone/04_GENERAL_TASKS/CLAUDE.MD +51 -0
- package/claude-code/simone/.simone/04_GENERAL_TASKS/T002_API_Rate_Limiting.md +49 -0
- package/claude-code/simone/.simone/04_GENERAL_TASKS/TX001_Refactor_Logging_Module.md +53 -0
- package/claude-code/simone/.simone/05_ARCHITECTURAL_DECISIONS/ADR001_Chosen_Database_System.md +113 -0
- package/claude-code/simone/.simone/05_ARCHITECTURAL_DECISIONS/ADR002_API_Authentication_Method.md +118 -0
- package/claude-code/simone/.simone/99_TEMPLATES/adr_template.md +49 -0
- package/claude-code/simone/.simone/99_TEMPLATES/milestone_meta_template.md +25 -0
- package/claude-code/simone/.simone/99_TEMPLATES/project_manifest_template.md +39 -0
- package/claude-code/simone/.simone/99_TEMPLATES/sprint_meta_template.md +23 -0
- package/claude-code/simone/.simone/99_TEMPLATES/task_template.md +35 -0
- package/claude-code/simone/.simone/CLAUDE.MD +65 -0
- package/claude-code/simone/.simone/README.md +97 -0
- package/claude-code/simone/CHANGELOG.md +71 -0
- package/claude-code/simone/LICENSE +21 -0
- package/claude-code/simone/README.md +219 -0
- package/claude-code/simone/SYNC_GUIDE.md +172 -0
- package/claude-code/simone/sync-simone.sh +138 -0
- package/index.js +468 -0
- package/package.json +38 -0
- package/rules/global/code-style-guide.md +30 -0
- package/rules/global/coding-principles.md +33 -0
- package/rules/global/development-process.md +41 -0
- package/rules/global/global-rules.md +84 -0
- package/rules/manual/generate-plan-docs.md +280 -0
|
@@ -0,0 +1,98 @@
|
|
|
1
|
+
# Product Requirements Document: Backend Setup
|
|
2
|
+
|
|
3
|
+
## Overview
|
|
4
|
+
|
|
5
|
+
This document outlines the requirements for setting up the backend infrastructure for our application. The backend will provide API endpoints for client applications, handle data persistence, and implement business logic.
|
|
6
|
+
|
|
7
|
+
## Functional Requirements
|
|
8
|
+
|
|
9
|
+
### User Management
|
|
10
|
+
|
|
11
|
+
- FR-1.1: The system shall allow users to register with email and password
|
|
12
|
+
- FR-1.2: The system shall allow users to log in with their credentials
|
|
13
|
+
- FR-1.3: The system shall allow users to reset their password via email
|
|
14
|
+
- FR-1.4: The system shall allow users to update their profile information
|
|
15
|
+
- FR-1.5: The system shall allow administrators to disable user accounts
|
|
16
|
+
|
|
17
|
+
### Data Models
|
|
18
|
+
|
|
19
|
+
- FR-2.1: The system shall implement a User model with fields for:
|
|
20
|
+
- Email (unique)
|
|
21
|
+
- Password (hashed)
|
|
22
|
+
- Profile information (name, avatar, etc.)
|
|
23
|
+
- Role (user, admin)
|
|
24
|
+
- Account status (active, disabled)
|
|
25
|
+
|
|
26
|
+
- FR-2.2: The system shall implement a Project model with fields for:
|
|
27
|
+
- Title
|
|
28
|
+
- Description
|
|
29
|
+
- Creation date
|
|
30
|
+
- Owner (User reference)
|
|
31
|
+
- Members (User references)
|
|
32
|
+
- Status (active, archived)
|
|
33
|
+
|
|
34
|
+
- FR-2.3: The system shall implement a Task model with fields for:
|
|
35
|
+
- Title
|
|
36
|
+
- Description
|
|
37
|
+
- Due date
|
|
38
|
+
- Assigned user (User reference)
|
|
39
|
+
- Project (Project reference)
|
|
40
|
+
- Status (todo, in_progress, done)
|
|
41
|
+
- Priority (low, medium, high)
|
|
42
|
+
|
|
43
|
+
### API Endpoints
|
|
44
|
+
|
|
45
|
+
- FR-3.1: The system shall provide authentication endpoints:
|
|
46
|
+
- POST /api/auth/register
|
|
47
|
+
- POST /api/auth/login
|
|
48
|
+
- POST /api/auth/reset-password
|
|
49
|
+
- POST /api/auth/reset-password-confirm
|
|
50
|
+
|
|
51
|
+
- FR-3.2: The system shall provide user management endpoints:
|
|
52
|
+
- GET /api/users/me
|
|
53
|
+
- PUT /api/users/me
|
|
54
|
+
- GET /api/users (admin only)
|
|
55
|
+
- PUT /api/users/:id (admin only)
|
|
56
|
+
|
|
57
|
+
- FR-3.3: The system shall provide project management endpoints:
|
|
58
|
+
- GET /api/projects
|
|
59
|
+
- POST /api/projects
|
|
60
|
+
- GET /api/projects/:id
|
|
61
|
+
- PUT /api/projects/:id
|
|
62
|
+
- DELETE /api/projects/:id
|
|
63
|
+
|
|
64
|
+
- FR-3.4: The system shall provide task management endpoints:
|
|
65
|
+
- GET /api/projects/:id/tasks
|
|
66
|
+
- POST /api/projects/:id/tasks
|
|
67
|
+
- GET /api/tasks/:id
|
|
68
|
+
- PUT /api/tasks/:id
|
|
69
|
+
- DELETE /api/tasks/:id
|
|
70
|
+
|
|
71
|
+
## Non-Functional Requirements
|
|
72
|
+
|
|
73
|
+
- NFR-1: The backend shall be implemented using Node.js and Express
|
|
74
|
+
- NFR-2: The system shall use MongoDB for data persistence
|
|
75
|
+
- NFR-3: API response time shall be under 200ms for 95% of requests
|
|
76
|
+
- NFR-4: The system shall handle up to 1000 concurrent users
|
|
77
|
+
- NFR-5: The system shall implement JWT-based authentication
|
|
78
|
+
- NFR-6: All API endpoints shall be documented using OpenAPI/Swagger
|
|
79
|
+
- NFR-7: The codebase shall have at least 80% test coverage
|
|
80
|
+
- NFR-8: The system shall log all errors and API requests
|
|
81
|
+
|
|
82
|
+
## Constraints
|
|
83
|
+
|
|
84
|
+
- The backend must be deployable to AWS and Azure
|
|
85
|
+
- The system must comply with GDPR requirements for user data
|
|
86
|
+
- The API must be versioned to support future changes
|
|
87
|
+
|
|
88
|
+
## Assumptions
|
|
89
|
+
|
|
90
|
+
- The client applications will be responsible for input validation
|
|
91
|
+
- The backend will be accessed only through the API, not directly
|
|
92
|
+
- The database will be hosted on a managed service (MongoDB Atlas)
|
|
93
|
+
|
|
94
|
+
## Dependencies
|
|
95
|
+
|
|
96
|
+
- MongoDB Atlas account
|
|
97
|
+
- SMTP service for email sending
|
|
98
|
+
- JWT secret key management
|
|
@@ -0,0 +1,232 @@
|
|
|
1
|
+
# API Specifications V1
|
|
2
|
+
|
|
3
|
+
This document provides detailed specifications for the API endpoints to be implemented in the backend.
|
|
4
|
+
|
|
5
|
+
## Base URL
|
|
6
|
+
|
|
7
|
+
All API endpoints are prefixed with: `/api/v1`
|
|
8
|
+
|
|
9
|
+
## Authentication
|
|
10
|
+
|
|
11
|
+
All authenticated endpoints require a valid JWT token in the Authorization header:
|
|
12
|
+
|
|
13
|
+
```
|
|
14
|
+
Authorization: Bearer <token>
|
|
15
|
+
```
|
|
16
|
+
|
|
17
|
+
## Error Handling
|
|
18
|
+
|
|
19
|
+
All API endpoints follow a consistent error response format:
|
|
20
|
+
|
|
21
|
+
```json
|
|
22
|
+
{
|
|
23
|
+
"error": {
|
|
24
|
+
"code": "ERROR_CODE",
|
|
25
|
+
"message": "Human-readable error message",
|
|
26
|
+
"details": {} // Optional additional error details
|
|
27
|
+
}
|
|
28
|
+
}
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
Common error codes:
|
|
32
|
+
- `UNAUTHORIZED`: Authentication required or invalid
|
|
33
|
+
- `FORBIDDEN`: Insufficient permissions
|
|
34
|
+
- `NOT_FOUND`: Resource not found
|
|
35
|
+
- `VALIDATION_ERROR`: Request validation failed
|
|
36
|
+
- `INTERNAL_ERROR`: Server-side error
|
|
37
|
+
|
|
38
|
+
## Endpoints
|
|
39
|
+
|
|
40
|
+
### Authentication
|
|
41
|
+
|
|
42
|
+
#### POST /api/v1/auth/register
|
|
43
|
+
|
|
44
|
+
Register a new user.
|
|
45
|
+
|
|
46
|
+
**Request:**
|
|
47
|
+
```json
|
|
48
|
+
{
|
|
49
|
+
"email": "user@example.com",
|
|
50
|
+
"password": "securepassword",
|
|
51
|
+
"name": "John Doe"
|
|
52
|
+
}
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
**Response (201 Created):**
|
|
56
|
+
```json
|
|
57
|
+
{
|
|
58
|
+
"user": {
|
|
59
|
+
"id": "user123",
|
|
60
|
+
"email": "user@example.com",
|
|
61
|
+
"name": "John Doe",
|
|
62
|
+
"created_at": "2023-07-10T12:00:00Z"
|
|
63
|
+
},
|
|
64
|
+
"token": "jwt.token.here"
|
|
65
|
+
}
|
|
66
|
+
```
|
|
67
|
+
|
|
68
|
+
#### POST /api/v1/auth/login
|
|
69
|
+
|
|
70
|
+
Authenticate a user.
|
|
71
|
+
|
|
72
|
+
**Request:**
|
|
73
|
+
```json
|
|
74
|
+
{
|
|
75
|
+
"email": "user@example.com",
|
|
76
|
+
"password": "securepassword"
|
|
77
|
+
}
|
|
78
|
+
```
|
|
79
|
+
|
|
80
|
+
**Response (200 OK):**
|
|
81
|
+
```json
|
|
82
|
+
{
|
|
83
|
+
"user": {
|
|
84
|
+
"id": "user123",
|
|
85
|
+
"email": "user@example.com",
|
|
86
|
+
"name": "John Doe",
|
|
87
|
+
"created_at": "2023-07-10T12:00:00Z"
|
|
88
|
+
},
|
|
89
|
+
"token": "jwt.token.here"
|
|
90
|
+
}
|
|
91
|
+
```
|
|
92
|
+
|
|
93
|
+
### Users
|
|
94
|
+
|
|
95
|
+
#### GET /api/v1/users/me
|
|
96
|
+
|
|
97
|
+
Get current authenticated user profile.
|
|
98
|
+
|
|
99
|
+
**Response (200 OK):**
|
|
100
|
+
```json
|
|
101
|
+
{
|
|
102
|
+
"id": "user123",
|
|
103
|
+
"email": "user@example.com",
|
|
104
|
+
"name": "John Doe",
|
|
105
|
+
"created_at": "2023-07-10T12:00:00Z",
|
|
106
|
+
"role": "user",
|
|
107
|
+
"status": "active"
|
|
108
|
+
}
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
#### PUT /api/v1/users/me
|
|
112
|
+
|
|
113
|
+
Update current user profile.
|
|
114
|
+
|
|
115
|
+
**Request:**
|
|
116
|
+
```json
|
|
117
|
+
{
|
|
118
|
+
"name": "John Smith",
|
|
119
|
+
"avatar_url": "https://example.com/avatar.jpg"
|
|
120
|
+
}
|
|
121
|
+
```
|
|
122
|
+
|
|
123
|
+
**Response (200 OK):**
|
|
124
|
+
```json
|
|
125
|
+
{
|
|
126
|
+
"id": "user123",
|
|
127
|
+
"email": "user@example.com",
|
|
128
|
+
"name": "John Smith",
|
|
129
|
+
"avatar_url": "https://example.com/avatar.jpg",
|
|
130
|
+
"created_at": "2023-07-10T12:00:00Z",
|
|
131
|
+
"role": "user",
|
|
132
|
+
"status": "active"
|
|
133
|
+
}
|
|
134
|
+
```
|
|
135
|
+
|
|
136
|
+
### Projects
|
|
137
|
+
|
|
138
|
+
#### GET /api/v1/projects
|
|
139
|
+
|
|
140
|
+
List all projects accessible to the authenticated user.
|
|
141
|
+
|
|
142
|
+
**Query Parameters:**
|
|
143
|
+
- `status` (optional): Filter by status (active, archived)
|
|
144
|
+
- `limit` (optional): Maximum number of results (default: 20)
|
|
145
|
+
- `offset` (optional): Pagination offset (default: 0)
|
|
146
|
+
|
|
147
|
+
**Response (200 OK):**
|
|
148
|
+
```json
|
|
149
|
+
{
|
|
150
|
+
"total": 42,
|
|
151
|
+
"data": [
|
|
152
|
+
{
|
|
153
|
+
"id": "proj123",
|
|
154
|
+
"title": "Project Alpha",
|
|
155
|
+
"description": "This is project alpha",
|
|
156
|
+
"created_at": "2023-07-10T12:00:00Z",
|
|
157
|
+
"owner": {
|
|
158
|
+
"id": "user123",
|
|
159
|
+
"name": "John Doe"
|
|
160
|
+
},
|
|
161
|
+
"status": "active"
|
|
162
|
+
},
|
|
163
|
+
...
|
|
164
|
+
]
|
|
165
|
+
}
|
|
166
|
+
```
|
|
167
|
+
|
|
168
|
+
#### POST /api/v1/projects
|
|
169
|
+
|
|
170
|
+
Create a new project.
|
|
171
|
+
|
|
172
|
+
**Request:**
|
|
173
|
+
```json
|
|
174
|
+
{
|
|
175
|
+
"title": "New Project",
|
|
176
|
+
"description": "Description of the project"
|
|
177
|
+
}
|
|
178
|
+
```
|
|
179
|
+
|
|
180
|
+
**Response (201 Created):**
|
|
181
|
+
```json
|
|
182
|
+
{
|
|
183
|
+
"id": "proj456",
|
|
184
|
+
"title": "New Project",
|
|
185
|
+
"description": "Description of the project",
|
|
186
|
+
"created_at": "2023-07-15T14:30:00Z",
|
|
187
|
+
"owner": {
|
|
188
|
+
"id": "user123",
|
|
189
|
+
"name": "John Doe"
|
|
190
|
+
},
|
|
191
|
+
"status": "active"
|
|
192
|
+
}
|
|
193
|
+
```
|
|
194
|
+
|
|
195
|
+
### Tasks
|
|
196
|
+
|
|
197
|
+
#### GET /api/v1/projects/:projectId/tasks
|
|
198
|
+
|
|
199
|
+
List tasks for a specific project.
|
|
200
|
+
|
|
201
|
+
**Query Parameters:**
|
|
202
|
+
- `status` (optional): Filter by status (todo, in_progress, done)
|
|
203
|
+
- `assigned_to` (optional): Filter by assigned user ID
|
|
204
|
+
- `limit` (optional): Maximum number of results (default: 50)
|
|
205
|
+
- `offset` (optional): Pagination offset (default: 0)
|
|
206
|
+
|
|
207
|
+
**Response (200 OK):**
|
|
208
|
+
```json
|
|
209
|
+
{
|
|
210
|
+
"total": 24,
|
|
211
|
+
"data": [
|
|
212
|
+
{
|
|
213
|
+
"id": "task123",
|
|
214
|
+
"title": "Implement login page",
|
|
215
|
+
"description": "Create the login page with email and password fields",
|
|
216
|
+
"due_date": "2023-08-01T00:00:00Z",
|
|
217
|
+
"status": "in_progress",
|
|
218
|
+
"priority": "high",
|
|
219
|
+
"assigned_to": {
|
|
220
|
+
"id": "user123",
|
|
221
|
+
"name": "John Doe"
|
|
222
|
+
},
|
|
223
|
+
"project_id": "proj123"
|
|
224
|
+
},
|
|
225
|
+
...
|
|
226
|
+
]
|
|
227
|
+
}
|
|
228
|
+
```
|
|
229
|
+
|
|
230
|
+
## Rate Limiting
|
|
231
|
+
|
|
232
|
+
API requests are rate-limited to 100 requests per minute per user. When the limit is exceeded, the API will respond with status code 429 (Too Many Requests).
|
|
@@ -0,0 +1,62 @@
|
|
|
1
|
+
# Sprint Management Instructions
|
|
2
|
+
|
|
3
|
+
## Important Section - Always read
|
|
4
|
+
|
|
5
|
+
- When updating Tasks Logs (Output Log) always fetch current date and time first
|
|
6
|
+
- Update Output Log after every Subtask
|
|
7
|
+
- Always be truthful in Logs. If you cannot complete a task for technical reasons, just write it down. Don't lie!
|
|
8
|
+
- Only mark lines as done if you could acctually progress them.
|
|
9
|
+
- Update the task file after every completed subtask and check Acceptance criteria as well if successful.
|
|
10
|
+
|
|
11
|
+
## Sprint Structure
|
|
12
|
+
|
|
13
|
+
Sprints are organized by milestone and sequence:
|
|
14
|
+
|
|
15
|
+
- Folders follow pattern: `S<NN>_M<NN>_<Focus_Area>/` where:
|
|
16
|
+
- `S<NN>` is the sprint sequence number
|
|
17
|
+
- `M<NN>` directly references the milestone ID this sprint belongs to
|
|
18
|
+
- `<Focus_Area>` describes the sprint's main focus
|
|
19
|
+
- Each sprint has a meta file: `S<NN>_sprint_meta.md`
|
|
20
|
+
- Tasks use pattern: `T<NN>_S<NN>_<Description>.md`
|
|
21
|
+
|
|
22
|
+
## Sprint Meta Files
|
|
23
|
+
|
|
24
|
+
Sprint meta files define sprint goals and track status:
|
|
25
|
+
|
|
26
|
+
```yaml
|
|
27
|
+
---
|
|
28
|
+
sprint_id: S01
|
|
29
|
+
milestone_id: M01
|
|
30
|
+
status: in_progress # planning | in_progress | review | complete
|
|
31
|
+
---
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
Update status as progress occurs:
|
|
35
|
+
|
|
36
|
+
- planning → in_progress → review → complete
|
|
37
|
+
|
|
38
|
+
Always use the template at `.simone/99_TEMPLATES/sprint_template.md` when creating new sprint meta files.
|
|
39
|
+
|
|
40
|
+
## Sprint Tasks
|
|
41
|
+
|
|
42
|
+
Tasks within a sprint follow a standard format:
|
|
43
|
+
|
|
44
|
+
- Status progression: open → in_progress → pending_review → done
|
|
45
|
+
- When completing a task:
|
|
46
|
+
- Ask for user confirmation
|
|
47
|
+
- Update status to "done"
|
|
48
|
+
- Rename file from T... to TX... (e.g., `TX01_S01_Task_Name.md`)
|
|
49
|
+
- Update Output Log with final entry
|
|
50
|
+
|
|
51
|
+
Always use the template at `.simone/99_TEMPLATES/task_template.md` when creating new sprint tasks.
|
|
52
|
+
|
|
53
|
+
## Working with Sprint Tasks
|
|
54
|
+
|
|
55
|
+
When executing a sprint task:
|
|
56
|
+
|
|
57
|
+
1. Analyze task's Acceptance Criteria and Subtasks
|
|
58
|
+
2. Update status to "in_progress"
|
|
59
|
+
3. Log activities in the Output Log with timestamps after every Subtask(!)
|
|
60
|
+
4. Mark subtasks as completed using [x] only when they are really completed. If you were not able to complete them, don't mark them and tell the user.
|
|
61
|
+
5. Reference architectural guidelines when implementing technical solutions
|
|
62
|
+
6. Ensure the task follows the structure from the task template
|
|
@@ -0,0 +1,42 @@
|
|
|
1
|
+
---
|
|
2
|
+
sprint_folder_name: S01_M01_Initial_API
|
|
3
|
+
sprint_sequence_id: S01
|
|
4
|
+
milestone_id: M01
|
|
5
|
+
title: Initial API Development
|
|
6
|
+
status: active # pending | active | completed | aborted
|
|
7
|
+
goal: Implement the foundational API structure including user authentication, basic project endpoints, and the initial database models.
|
|
8
|
+
last_updated: 2023-07-15
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
# Sprint: Initial API Development (S01) (EXAMPLE)
|
|
12
|
+
|
|
13
|
+
## Sprint Goal
|
|
14
|
+
Implement the foundational API structure including user authentication, basic project endpoints, and the initial database models.
|
|
15
|
+
|
|
16
|
+
## Scope & Key Deliverables
|
|
17
|
+
1. Set up the project structure with Express.js and MongoDB
|
|
18
|
+
2. Implement user registration and authentication endpoints
|
|
19
|
+
3. Create basic project and task models
|
|
20
|
+
4. Implement core API endpoints for projects and tasks
|
|
21
|
+
5. Set up automated testing infrastructure
|
|
22
|
+
|
|
23
|
+
## Sprint Backlog
|
|
24
|
+
- [T01_S01_Setup_Project_Structure](./T01_S01_Setup_Project_Structure.md)
|
|
25
|
+
- [T02_S01_Define_User_Model](./T02_S01_Define_User_Model.md)
|
|
26
|
+
- [T03_S01_Implement_Auth_Endpoints](./T03_S01_Implement_Auth_Endpoints.md)
|
|
27
|
+
- [T04_S01_Define_Project_Model](./T04_S01_Define_Project_Model.md)
|
|
28
|
+
- [T05_S01_Implement_Project_Endpoints](./T05_S01_Implement_Project_Endpoints.md)
|
|
29
|
+
|
|
30
|
+
## Definition of Done (for the Sprint)
|
|
31
|
+
The sprint will be considered complete when:
|
|
32
|
+
- All sprint tasks are completed and meet their acceptance criteria
|
|
33
|
+
- All implemented endpoints pass their test cases
|
|
34
|
+
- API documentation is updated to reflect implemented endpoints
|
|
35
|
+
- Code has been reviewed and merged to the development branch
|
|
36
|
+
|
|
37
|
+
## Notes / Context
|
|
38
|
+
This is an example sprint document to demonstrate how sprints might be structured in a project using the Simone framework. This simulates what a typical initial API development sprint might look like.
|
|
39
|
+
|
|
40
|
+
## Related Documents
|
|
41
|
+
- [Milestone M01: Backend Setup](../../02_REQUIREMENTS/M01_Backend_Setup/M01_milestone_meta.md)
|
|
42
|
+
- [API Specifications V1](../../02_REQUIREMENTS/M01_Backend_Setup/SPECS_API_V1.md)
|
package/claude-code/simone/.simone/03_SPRINTS/S01_M01_Initial_API/T01_S01_Setup_Project_Structure.md
ADDED
|
@@ -0,0 +1,56 @@
|
|
|
1
|
+
---
|
|
2
|
+
task_id: T01_S01
|
|
3
|
+
sprint_sequence_id: S01
|
|
4
|
+
status: in_progress # open | in_progress | pending_review | done | failed | blocked
|
|
5
|
+
complexity: Medium # Low | Medium | High
|
|
6
|
+
last_updated: 2023-07-15
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Task: Setup Project Structure (EXAMPLE)
|
|
10
|
+
|
|
11
|
+
## Description
|
|
12
|
+
Set up the initial project structure for the backend API service, including directory organization, dependency installation, and basic configuration.
|
|
13
|
+
|
|
14
|
+
**Note: This is an example task to demonstrate the structure of a task in the Simone framework.**
|
|
15
|
+
|
|
16
|
+
## Goal / Objectives
|
|
17
|
+
- Create a well-organized, scalable project structure
|
|
18
|
+
- Set up the Express.js application with middleware
|
|
19
|
+
- Configure MongoDB connection
|
|
20
|
+
- Implement basic error handling
|
|
21
|
+
- Set up environment configuration
|
|
22
|
+
- Initialize logging system
|
|
23
|
+
|
|
24
|
+
## Acceptance Criteria
|
|
25
|
+
- [ ] Project structure follows MVC pattern with clear separation of concerns
|
|
26
|
+
- [ ] Express application is set up with necessary middleware (CORS, body-parser, etc.)
|
|
27
|
+
- [ ] MongoDB connection is configured with error handling
|
|
28
|
+
- [ ] Environment variables are properly managed (development vs production)
|
|
29
|
+
- [ ] Logger is implemented for request/error tracking
|
|
30
|
+
- [ ] Basic error handling middleware is implemented
|
|
31
|
+
- [ ] Project runs without errors
|
|
32
|
+
- [ ] Initial tests pass
|
|
33
|
+
|
|
34
|
+
## Subtasks
|
|
35
|
+
- [ ] Initialize Node.js project with package.json
|
|
36
|
+
- [ ] Install core dependencies (express, mongoose, dotenv, etc.)
|
|
37
|
+
- [ ] Create directory structure for routes, controllers, models, middleware
|
|
38
|
+
- [ ] Set up Express application with basic middleware
|
|
39
|
+
- [ ] Configure MongoDB connection
|
|
40
|
+
- [ ] Implement environment-specific configurations
|
|
41
|
+
- [ ] Set up logging system
|
|
42
|
+
- [ ] Implement error handling middleware
|
|
43
|
+
- [ ] Write basic tests to verify configuration
|
|
44
|
+
|
|
45
|
+
## Output Log
|
|
46
|
+
|
|
47
|
+
[2023-07-15 14:30:00] Started task
|
|
48
|
+
[2023-07-15 14:45:22] Created files: package.json, .env.example
|
|
49
|
+
[2023-07-15 15:10:05] Created directory structure and base files: app.js, server.js, config/db.js, config/env.js
|
|
50
|
+
[2023-07-15 15:30:18] Created middleware: middleware/auth.js, middleware/error.js
|
|
51
|
+
[2023-07-15 15:45:30] Created util files: utils/logger.js
|
|
52
|
+
[2023-07-15 16:10:15] Created base routes: routes/index.js
|
|
53
|
+
[2023-07-15 16:45:22] Implemented error handling in middleware/error.js
|
|
54
|
+
[2023-07-15 17:20:10] Configured logging system in utils/logger.js
|
|
55
|
+
[2023-07-15 18:20:45] Added Jest configuration and created sample tests
|
|
56
|
+
[2023-07-15 18:35:30] Completed all subtasks, verified server starts successfully
|
|
@@ -0,0 +1,51 @@
|
|
|
1
|
+
# General Tasks Instructions
|
|
2
|
+
|
|
3
|
+
## General Task Structure
|
|
4
|
+
|
|
5
|
+
General tasks are standalone work items not tied to sprints:
|
|
6
|
+
|
|
7
|
+
- Files follow pattern: `T<NNN>_<Description>.md`
|
|
8
|
+
- Completed tasks: `TX<NNN>_<Description>.md`
|
|
9
|
+
|
|
10
|
+
Always use the template at `.simone/99_TEMPLATES/task_template.md` when creating new general tasks.
|
|
11
|
+
|
|
12
|
+
## Task Formatting
|
|
13
|
+
|
|
14
|
+
General tasks use standardized YAML frontmatter and sections:
|
|
15
|
+
|
|
16
|
+
```yaml
|
|
17
|
+
---
|
|
18
|
+
task_id: T001
|
|
19
|
+
status: open # open | in_progress | pending_review | done | failed | blocked
|
|
20
|
+
complexity: Medium # Low | Medium | High
|
|
21
|
+
last_updated: YYYY-MM-DD HH:MM
|
|
22
|
+
---
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
The full task structure with all sections is defined in the task template. Always maintain this structure.
|
|
26
|
+
|
|
27
|
+
## Working with General Tasks
|
|
28
|
+
|
|
29
|
+
When handling general tasks:
|
|
30
|
+
|
|
31
|
+
1. Update the status field as you progress
|
|
32
|
+
2. Record timestamps in this format (YYYY-MM-DD HH:MM)
|
|
33
|
+
3. Log all significant actions in the Output Log section:
|
|
34
|
+
|
|
35
|
+
```plaintext
|
|
36
|
+
[YYYY-MM-DD HH:MM] Started task
|
|
37
|
+
[YYYY-MM-DD HH:MM] Modified files: file1.js, file2.js
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
4. Mark subtasks as they're completed: `- [x] Completed subtask`
|
|
41
|
+
5. Use the Acceptance Criteria as your primary completion checklist
|
|
42
|
+
6. Ensure all sections from the task template are preserved
|
|
43
|
+
|
|
44
|
+
## Task Completion Process
|
|
45
|
+
|
|
46
|
+
When a task is complete:
|
|
47
|
+
|
|
48
|
+
1. Update status to "done"
|
|
49
|
+
2. Update all Acceptance Criteria with [x]
|
|
50
|
+
3. Add final Output Log entry
|
|
51
|
+
4. Rename file from T... to TX... (e.g., `TX001_Task_Name.md`)
|
|
@@ -0,0 +1,49 @@
|
|
|
1
|
+
---
|
|
2
|
+
task_id: T002
|
|
3
|
+
status: in_progress # open | in_progress | pending_review | done | failed | blocked
|
|
4
|
+
complexity: Medium # Low | Medium | High
|
|
5
|
+
last_updated: 2023-07-25T09:15:00Z
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Task: API Rate Limiting (EXAMPLE)
|
|
9
|
+
|
|
10
|
+
## Description
|
|
11
|
+
Implement rate limiting for the API to prevent abuse and ensure fair usage across all clients. This task involves adding middleware to track and limit requests based on client IP or API key.
|
|
12
|
+
|
|
13
|
+
**Note: This is an example general task to demonstrate how non-sprint-specific tasks might be structured in the Simone framework.**
|
|
14
|
+
|
|
15
|
+
## Goal / Objectives
|
|
16
|
+
- Protect API endpoints from abuse and excessive requests
|
|
17
|
+
- Implement configurable rate limits based on client authentication
|
|
18
|
+
- Track usage statistics for billing and monitoring
|
|
19
|
+
- Provide clear feedback to clients when limits are exceeded
|
|
20
|
+
- Ensure minimal performance impact on normal API operation
|
|
21
|
+
|
|
22
|
+
## Acceptance Criteria
|
|
23
|
+
- [ ] Rate limiting is applied to all public API endpoints
|
|
24
|
+
- [ ] Different rate limits are configurable based on client tier/authentication
|
|
25
|
+
- [ ] Response headers include rate limit information (limit, remaining, reset)
|
|
26
|
+
- [ ] When limit is exceeded, a 429 status code is returned with appropriate error message
|
|
27
|
+
- [ ] Rate limiting can be temporarily disabled for specific clients if needed
|
|
28
|
+
- [ ] Implementation has minimal impact on response times (<10ms overhead)
|
|
29
|
+
- [ ] Usage statistics are collected for monitoring and analysis
|
|
30
|
+
|
|
31
|
+
## Subtasks
|
|
32
|
+
- [x] Research rate limiting strategies and best practices
|
|
33
|
+
- [x] Evaluate libraries (express-rate-limit, rate-limiter-flexible, etc.)
|
|
34
|
+
- [x] Design rate limit tiers for different client types
|
|
35
|
+
- [ ] Implement rate limiting middleware
|
|
36
|
+
- [ ] Add custom response headers
|
|
37
|
+
- [ ] Create storage adapter for distributed rate limiting
|
|
38
|
+
- [ ] Implement override mechanism for special cases
|
|
39
|
+
- [ ] Add monitoring and alerts for rate limit events
|
|
40
|
+
- [ ] Document rate limiting behavior for API consumers
|
|
41
|
+
|
|
42
|
+
## Output Log
|
|
43
|
+
*(This section is populated as work progresses on the task)*
|
|
44
|
+
|
|
45
|
+
[2023-07-23 10:30:00] Started task
|
|
46
|
+
[2023-07-23 13:45:22] Completed research on rate limiting strategies
|
|
47
|
+
[2023-07-24 09:15:30] Evaluated rate-limiter-flexible and express-rate-limit libraries
|
|
48
|
+
[2023-07-24 15:50:15] Decided on rate-limiter-flexible for implementation
|
|
49
|
+
[2023-07-25 09:15:00] Designed rate limit tiers for different client authentication levels
|
|
@@ -0,0 +1,53 @@
|
|
|
1
|
+
---
|
|
2
|
+
task_id: T001
|
|
3
|
+
status: done # open | in_progress | pending_review | done | failed | blocked
|
|
4
|
+
complexity: Medium # Low | Medium | High
|
|
5
|
+
last_updated: 2023-07-22T16:45:00Z
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Task: Refactor Logging Module (EXAMPLE)
|
|
9
|
+
|
|
10
|
+
## Description
|
|
11
|
+
The current logging implementation is basic and needs to be enhanced to provide better visibility and monitoring capabilities. This task involves refactoring the logging module to add structured logging, log rotation, and improved error tracking.
|
|
12
|
+
|
|
13
|
+
**Note: This is an example general task to demonstrate how non-sprint-specific tasks might be structured in the Simone framework.**
|
|
14
|
+
|
|
15
|
+
## Goal / Objectives
|
|
16
|
+
- Implement structured JSON logging for better parsing by log analysis tools
|
|
17
|
+
- Add log rotation to prevent log files from growing too large
|
|
18
|
+
- Enable different log levels based on environment
|
|
19
|
+
- Add request ID tracking for tracing requests through the system
|
|
20
|
+
- Improve error logging with stack traces and contextual information
|
|
21
|
+
|
|
22
|
+
## Acceptance Criteria
|
|
23
|
+
- [x] Logs are output in structured JSON format
|
|
24
|
+
- [x] Log files are rotated based on size and/or date
|
|
25
|
+
- [x] Different log levels are used appropriately (debug, info, warn, error)
|
|
26
|
+
- [x] Each request has a unique ID that is logged with every related log entry
|
|
27
|
+
- [x] Error logs include stack traces and relevant request information
|
|
28
|
+
- [x] Performance impact of logging is minimal
|
|
29
|
+
- [x] Documentation is updated to reflect new logging capabilities
|
|
30
|
+
|
|
31
|
+
## Subtasks
|
|
32
|
+
- [x] Evaluate and select appropriate logging libraries and tools
|
|
33
|
+
- [x] Design the structured log format with required fields
|
|
34
|
+
- [x] Implement log rotation configuration
|
|
35
|
+
- [x] Add request ID middleware for request tracking
|
|
36
|
+
- [x] Enhance error logging with more contextual information
|
|
37
|
+
- [x] Update logging throughout the application to use new formats
|
|
38
|
+
- [x] Write tests for logging functionality
|
|
39
|
+
- [x] Document the new logging system
|
|
40
|
+
|
|
41
|
+
## Output Log
|
|
42
|
+
*(This section is populated as work progresses on the task)*
|
|
43
|
+
|
|
44
|
+
[2023-07-15 10:30:00] Started task
|
|
45
|
+
[2023-07-15 11:15:22] Researched logging libraries: winston, pino, bunyan
|
|
46
|
+
[2023-07-15 13:45:30] Created prototype with winston for structured JSON logging
|
|
47
|
+
[2023-07-15 15:20:15] Implemented log rotation with winston-daily-rotate-file
|
|
48
|
+
[2023-07-15 16:40:05] Added request ID middleware
|
|
49
|
+
[2023-07-15 17:30:18] Enhanced error logging with stack traces and context
|
|
50
|
+
[2023-07-16 09:15:40] Updated application code to use new logging format
|
|
51
|
+
[2023-07-18 14:22:10] Wrote tests for logging functionality
|
|
52
|
+
[2023-07-20 11:05:33] Updated documentation with logging guidelines
|
|
53
|
+
[2023-07-22 16:45:00] Task completed
|