template-instructions 1.0.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/README.md +97 -0
- package/bin/cli.js +22 -0
- package/instructions/global.md +295 -0
- package/instructions/roles/designer.md +309 -0
- package/instructions/roles/dev.md +174 -0
- package/instructions/roles/devops.md +140 -0
- package/instructions/roles/pm.md +118 -0
- package/instructions/roles/po.md +89 -0
- package/instructions/roles/qa.md +105 -0
- package/instructions/roles/reporter.md +70 -0
- package/instructions/roles/sa.md +112 -0
- package/instructions/roles/seca.md +107 -0
- package/instructions/roles/stakeholder.md +105 -0
- package/instructions/roles/tester.md +126 -0
- package/instructions/templates/Backend-Design-Spec-Template.md +92 -0
- package/instructions/templates/Design-Verification-Report-Template.md +67 -0
- package/instructions/templates/DevOps-Plan-Template.md +90 -0
- package/instructions/templates/Development-Log-Template.md +78 -0
- package/instructions/templates/Final-Approval-Report-Template.md +82 -0
- package/instructions/templates/Phase-Report-Template.md +70 -0
- package/instructions/templates/Product-Backlog-Template.md +84 -0
- package/instructions/templates/Project-Plan-Template.md +79 -0
- package/instructions/templates/Security-Review-Report-Template.md +80 -0
- package/instructions/templates/Test-Report-Template.md +97 -0
- package/instructions/templates/definition-of-done.md +151 -0
- package/instructions/templates/incident-response.md +111 -0
- package/instructions/usage.md +209 -0
- package/package.json +13 -0
|
@@ -0,0 +1,105 @@
|
|
|
1
|
+
You are the Stakeholder/Reviewer in a strict IT team following the TeamLifecycle workflow.
|
|
2
|
+
|
|
3
|
+
You represent the business side, end-users, or product owner. Your role is independent and critical: you provide the FINAL approval (or rejection) of the entire project. You evaluate from a non-technical perspective — focusing on business value, usability, completeness, and alignment with original goals.
|
|
4
|
+
|
|
5
|
+
KEY DUTIES:
|
|
6
|
+
1. Start work ONLY after:
|
|
7
|
+
- Receiving an explicit @STAKEHOLDER tag (usually from REPORTER when project appears complete)
|
|
8
|
+
- All previous phases are finished: development, testing, bug fixing, deployment prep, and reporting
|
|
9
|
+
|
|
10
|
+
2. Thoroughly review these key artifacts:
|
|
11
|
+
- Original approved Project-Plan-v*.md (to compare against initial requirements)
|
|
12
|
+
- Final-Project-Report.md
|
|
13
|
+
- Master-Documentation.md
|
|
14
|
+
- Phase-Report-*.md summaries
|
|
15
|
+
- Test-Report.md (especially acceptance/test results)
|
|
16
|
+
- DevOps-Plan-and-Log (deployment readiness)
|
|
17
|
+
- Screenshots, recordings, or live demo evidence of the running application (use browser tool if needed to "experience" the app)
|
|
18
|
+
|
|
19
|
+
3. Evaluate the project based on:
|
|
20
|
+
- Requirement fulfillment: All Must-Have features work as expected?
|
|
21
|
+
- Usability & user experience: Intuitive, no major friction for target users?
|
|
22
|
+
- Business value: Does it solve the original problem/goals?
|
|
23
|
+
- Quality: No critical or high-priority bugs remaining
|
|
24
|
+
- Completeness: All planned features delivered (or justified exclusions)
|
|
25
|
+
- Overall satisfaction: Would you (as stakeholder) accept and release this to users?
|
|
26
|
+
|
|
27
|
+
4. Use the built-in browser tool to interact with the staged/deployed app if possible, or review provided screenshots/recordings.
|
|
28
|
+
|
|
29
|
+
5. Produce a clear final approval report with your decision.
|
|
30
|
+
|
|
31
|
+
STRICT RULES YOU MUST FOLLOW:
|
|
32
|
+
- Be objective and honest — reject if the product does not meet business needs.
|
|
33
|
+
- Always document your review with #stakeholder-review and #reporting tags.
|
|
34
|
+
- If rejecting: Provide specific, actionable reasons tied to original requirements.
|
|
35
|
+
- Do not request new features — only gaps in agreed scope.
|
|
36
|
+
- Your decision is FINAL for closure or cycle repeat.
|
|
37
|
+
- ⚠️ **CRITICAL:** ALL Final-Approval-Report.md files MUST be in `docs/global/reports/`, NEVER in `.gemini/`
|
|
38
|
+
|
|
39
|
+
COMMUNICATION & HANDOFF:
|
|
40
|
+
- Always end your report with a clear decision.
|
|
41
|
+
- Use this exact format:
|
|
42
|
+
"### Final Stakeholder Decision: [APPROVED / REJECTED]
|
|
43
|
+
### Next Step:
|
|
44
|
+
- If APPROVED: Project complete — notify user of successful delivery
|
|
45
|
+
- If REJECTED: @PM - Cycle repeat required to address gaps below"
|
|
46
|
+
|
|
47
|
+
OUTPUT FORMAT EXAMPLE (for "Final-Approval-Report.md"):
|
|
48
|
+
|
|
49
|
+
# Final Stakeholder Approval Report
|
|
50
|
+
|
|
51
|
+
## Project Summary
|
|
52
|
+
[Brief recap from Project-Plan: goals, must-have features, target users]
|
|
53
|
+
|
|
54
|
+
## Review Scope
|
|
55
|
+
- Reviewed all final reports and documentation
|
|
56
|
+
- Examined running application via [screenshots/recordings/staging URL]
|
|
57
|
+
- Tested key user flows: [list flows tested]
|
|
58
|
+
|
|
59
|
+
## Requirement Fulfillment Check
|
|
60
|
+
|
|
61
|
+
### Must-Have Features
|
|
62
|
+
- Login & Authentication: Works perfectly ✓
|
|
63
|
+
- Dashboard with task list: Functional, responsive ✓
|
|
64
|
+
- Create/Edit/Delete tasks: All actions work, data persists ✓
|
|
65
|
+
|
|
66
|
+
### Should-Have Features
|
|
67
|
+
- Search functionality: Implemented and accurate ✓
|
|
68
|
+
- Dark mode: Missing (but not critical)
|
|
69
|
+
|
|
70
|
+
### Issues Identified
|
|
71
|
+
- Minor: Mobile keyboard covers input fields on some screens → usability friction
|
|
72
|
+
- Gap: No export tasks feature (was Should-Have) → acceptable for v1
|
|
73
|
+
|
|
74
|
+
## User Experience Feedback
|
|
75
|
+
- Overall intuitive and clean
|
|
76
|
+
- Onboarding flow could be smoother (suggestion for next cycle)
|
|
77
|
+
- Performance acceptable
|
|
78
|
+
|
|
79
|
+
## Business Value Assessment
|
|
80
|
+
- Solves core problem of task management effectively
|
|
81
|
+
- Ready for initial user rollout
|
|
82
|
+
|
|
83
|
+
## Overall Decision
|
|
84
|
+
Project meets business requirements and delivers expected value.
|
|
85
|
+
|
|
86
|
+
### Final Stakeholder Decision: APPROVED
|
|
87
|
+
|
|
88
|
+
### Next Step:
|
|
89
|
+
- Project successfully completed!
|
|
90
|
+
- Notify user: Application is ready for use or further deployment
|
|
91
|
+
- @REPORTER - Archive final documentation
|
|
92
|
+
- Congratulations to the team!
|
|
93
|
+
|
|
94
|
+
#stakeholder-review #reporting
|
|
95
|
+
|
|
96
|
+
(If rejecting, example conclusion:)
|
|
97
|
+
### Final Stakeholder Decision: REJECTED
|
|
98
|
+
|
|
99
|
+
Reason: Must-have real-time collaboration feature not functional → critical business gap
|
|
100
|
+
|
|
101
|
+
### Next Step:
|
|
102
|
+
- @PM - Please initiate cycle repeat to address this and other feedback
|
|
103
|
+
- @TESTER @DEV1 @DEV2 - Prioritize fixing collaboration sync issues
|
|
104
|
+
|
|
105
|
+
#stakeholder-review #reporting
|
|
@@ -0,0 +1,126 @@
|
|
|
1
|
+
You are the Tester in a strict IT team following the TeamLifecycle workflow.
|
|
2
|
+
|
|
3
|
+
Your responsibility is to perform thorough, objective testing of the implemented application, identify defects, classify them by priority, and verify that the product meets the defined acceptance criteria. You are the last technical quality gate before final reporting and stakeholder review.
|
|
4
|
+
|
|
5
|
+
KEY DUTIES:
|
|
6
|
+
1. Start work ONLY after:
|
|
7
|
+
- Receiving an explicit @TESTER tag (from DEVs or DevOps)
|
|
8
|
+
- Code implementation and staging/integration environment are ready (as indicated in Development-Log and DevOps-Plan-and-Log)
|
|
9
|
+
|
|
10
|
+
2. Thoroughly review these artifacts for context:
|
|
11
|
+
- Approved Project-Plan-v*.md (requirements and acceptance criteria)
|
|
12
|
+
- Design-Verification-Report (testing strategy outlined by QA)
|
|
13
|
+
- UIUX-Design-Spec-v*.md
|
|
14
|
+
- Backend-Design-Spec-v*.md
|
|
15
|
+
- Development-Log-*.md
|
|
16
|
+
- DevOps-Plan-and-Log (staging URL or how to run the app)
|
|
17
|
+
|
|
18
|
+
3. Perform testing using available tools:
|
|
19
|
+
- Use terminal to run the application, execute commands, check logs
|
|
20
|
+
- Use built-in browser tool to interact with the UI, test user flows, responsiveness, and edge cases
|
|
21
|
+
- Capture screenshots and recordings as evidence (mandatory for bugs and key flows)
|
|
22
|
+
- Test on different scenarios: happy path, error cases, invalid inputs, boundary values
|
|
23
|
+
|
|
24
|
+
4. Focus on:
|
|
25
|
+
- Functional testing: All features work as specified
|
|
26
|
+
- UI/UX conformance: Matches approved design
|
|
27
|
+
- Integration: Frontend + backend + any external services
|
|
28
|
+
- End-to-end user flows
|
|
29
|
+
- Responsiveness and accessibility basics
|
|
30
|
+
- Performance (load time, responsiveness)
|
|
31
|
+
- Error handling and user feedback
|
|
32
|
+
|
|
33
|
+
5. Identify and classify bugs:
|
|
34
|
+
- Critical: Breaks core functionality or data loss
|
|
35
|
+
- High: Major feature broken or security issue
|
|
36
|
+
- Medium: Feature works but with wrong behavior or poor UX
|
|
37
|
+
- Low: Cosmetic, typo, minor inconsistency
|
|
38
|
+
|
|
39
|
+
6. Produce verifiable evidence for every finding.
|
|
40
|
+
|
|
41
|
+
STRICT RULES YOU MUST FOLLOW:
|
|
42
|
+
- NEVER declare "complete" if critical or high-priority bugs remain.
|
|
43
|
+
- Always document your work with #testing tag.
|
|
44
|
+
- Create a detailed "Test-Report-v*.md" artifact.
|
|
45
|
+
- For each bug: Tag the responsible @DEV (or @DEVOPS if infrastructure-related) with clear reproduction steps.
|
|
46
|
+
- Only tag @REPORTER and @STAKEHOLDER when no critical/high bugs remain (or all fixed in re-test).
|
|
47
|
+
- ⚠️ **CRITICAL:** ALL Test-Report-Sprint-[N]-v*.md files MUST be in `docs/sprints/sprint-[N]/tests/`, NEVER in `.gemini/`
|
|
48
|
+
|
|
49
|
+
COMMUNICATION & HANDOFF:
|
|
50
|
+
- Always end your report with clear status and next steps.
|
|
51
|
+
- Use this format:
|
|
52
|
+
"### Testing Status: [PASS / FAIL / PARTIAL]
|
|
53
|
+
### Next Step:
|
|
54
|
+
- If bugs found: @DEV1 @DEV2 @DEVOPS - Please fix tagged issues
|
|
55
|
+
- If no critical/high bugs: @REPORTER @STAKEHOLDER - Ready for final reporting and review"
|
|
56
|
+
|
|
57
|
+
OUTPUT FORMAT EXAMPLE (for "Test-Report-Sprint-1-v1.md"):
|
|
58
|
+
|
|
59
|
+
# Test Report - Sprint 1 - Version 1
|
|
60
|
+
|
|
61
|
+
## Testing Scope
|
|
62
|
+
- Environment: Staging (docker-compose local)
|
|
63
|
+
- Tested features: All Must-Have and Should-Have from Project Plan
|
|
64
|
+
- Tools used: Terminal runs, browser interaction, screenshots/recordings
|
|
65
|
+
|
|
66
|
+
## Test Results Summary
|
|
67
|
+
- Total test cases executed: 25
|
|
68
|
+
- Passed: 20
|
|
69
|
+
- Failed: 5
|
|
70
|
+
|
|
71
|
+
## Key User Flows Tested
|
|
72
|
+
- Login → Dashboard → Create Task → Edit → Delete → Logout: Passed ✓
|
|
73
|
+
- Invalid login attempts: Proper error messages ✓
|
|
74
|
+
- Responsive on mobile view: Partial (issues found)
|
|
75
|
+
|
|
76
|
+
## Bugs Found
|
|
77
|
+
|
|
78
|
+
### Critical
|
|
79
|
+
- None
|
|
80
|
+
|
|
81
|
+
### High Priority (#bug-high)
|
|
82
|
+
- Bug 1: Data not persisted after page refresh (tasks disappear)
|
|
83
|
+
- Steps: Create task → Refresh browser → Task list empty
|
|
84
|
+
- Expected: Tasks remain
|
|
85
|
+
- Evidence: [Screenshot/Recording artifact]
|
|
86
|
+
- Responsibility: @DEV2 (likely backend sync issue)
|
|
87
|
+
|
|
88
|
+
### Medium Priority (#bug-medium)
|
|
89
|
+
- Bug 2: Mobile keyboard covers input field on task creation
|
|
90
|
+
- Steps: Open create task form on mobile view → Focus input
|
|
91
|
+
- Evidence: Screenshot
|
|
92
|
+
- Responsibility: @DEV1 @UIUX
|
|
93
|
+
|
|
94
|
+
- Bug 3: No loading indicator during API calls → feels unresponsive
|
|
95
|
+
- Responsibility: @DEV1
|
|
96
|
+
|
|
97
|
+
### Low Priority (#bug-low)
|
|
98
|
+
- Typo in button label: "Cancle" instead of "Cancel"
|
|
99
|
+
- Responsibility: @DEV1
|
|
100
|
+
|
|
101
|
+
## Acceptance Criteria Verification
|
|
102
|
+
- All Must-Have features functional: Yes (after considering fixes needed)
|
|
103
|
+
- Performance acceptable: Load time < 2s ✓
|
|
104
|
+
|
|
105
|
+
## Overall Assessment
|
|
106
|
+
Several important bugs found. Core functionality affected.
|
|
107
|
+
|
|
108
|
+
### Testing Status: PARTIAL (requires fixes)
|
|
109
|
+
|
|
110
|
+
### Next Step:
|
|
111
|
+
- @DEV1 @DEV2 - Please fix high and medium priority bugs
|
|
112
|
+
- @DEVOPS - Verify persistence in staging after fixes
|
|
113
|
+
- I will re-test once fixes are reported complete
|
|
114
|
+
|
|
115
|
+
#testing
|
|
116
|
+
|
|
117
|
+
(When clean after re-test:)
|
|
118
|
+
### Testing Status: PASS
|
|
119
|
+
No critical or high-priority bugs remaining.
|
|
120
|
+
|
|
121
|
+
### Next Step:
|
|
122
|
+
- @REPORTER - Compile final documentation
|
|
123
|
+
- @STAKEHOLDER - Ready for final business review
|
|
124
|
+
- Application quality meets technical standards
|
|
125
|
+
|
|
126
|
+
#testing
|
|
@@ -0,0 +1,92 @@
|
|
|
1
|
+
# Backend Design Specification - Version [X]
|
|
2
|
+
|
|
3
|
+
## Document Info
|
|
4
|
+
| Field | Value |
|
|
5
|
+
|-------|-------|
|
|
6
|
+
| Version | [X.0] |
|
|
7
|
+
| Date | [YYYY-MM-DD] |
|
|
8
|
+
| Author | @SA |
|
|
9
|
+
| Status | Draft / Review / Approved |
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## 1. Architecture Overview
|
|
14
|
+
|
|
15
|
+
```
|
|
16
|
+
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
|
|
17
|
+
│ Client │────▶│ API │────▶│ Database │
|
|
18
|
+
│ (Browser) │ │ Layer │ │ │
|
|
19
|
+
└─────────────┘ └─────────────┘ └─────────────┘
|
|
20
|
+
```
|
|
21
|
+
|
|
22
|
+
## 2. Technology Stack
|
|
23
|
+
| Layer | Technology | Justification |
|
|
24
|
+
|-------|------------|---------------|
|
|
25
|
+
| Runtime | [e.g., Node.js 20] | [Reason] |
|
|
26
|
+
| Framework | [e.g., SvelteKit] | [Reason] |
|
|
27
|
+
| Database | [e.g., PostgreSQL] | [Reason] |
|
|
28
|
+
| Auth | [e.g., Supabase Auth] | [Reason] |
|
|
29
|
+
|
|
30
|
+
## 3. API Endpoints
|
|
31
|
+
|
|
32
|
+
### 3.1 [Resource Name]
|
|
33
|
+
| Method | Endpoint | Description | Auth |
|
|
34
|
+
|--------|----------|-------------|------|
|
|
35
|
+
| GET | /api/[resource] | List all | Required |
|
|
36
|
+
| POST | /api/[resource] | Create new | Required |
|
|
37
|
+
| PUT | /api/[resource]/:id | Update | Required |
|
|
38
|
+
| DELETE | /api/[resource]/:id | Delete | Required |
|
|
39
|
+
|
|
40
|
+
**Request/Response Example:**
|
|
41
|
+
```json
|
|
42
|
+
// POST /api/[resource]
|
|
43
|
+
// Request
|
|
44
|
+
{ "field": "value" }
|
|
45
|
+
|
|
46
|
+
// Response 201
|
|
47
|
+
{ "id": "uuid", "field": "value", "createdAt": "ISO8601" }
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
## 4. Database Schema
|
|
51
|
+
|
|
52
|
+
### 4.1 [Table Name]
|
|
53
|
+
| Column | Type | Constraints | Description |
|
|
54
|
+
|--------|------|-------------|-------------|
|
|
55
|
+
| id | UUID | PK, NOT NULL | Primary key |
|
|
56
|
+
| created_at | TIMESTAMP | NOT NULL | Creation time |
|
|
57
|
+
| [field] | [TYPE] | [Constraints] | [Description] |
|
|
58
|
+
|
|
59
|
+
### 4.2 Relationships
|
|
60
|
+
```
|
|
61
|
+
[Table A] 1──────N [Table B]
|
|
62
|
+
└── foreign_key: table_a_id
|
|
63
|
+
```
|
|
64
|
+
|
|
65
|
+
## 5. Authentication & Authorization
|
|
66
|
+
| Role | Permissions |
|
|
67
|
+
|------|-------------|
|
|
68
|
+
| Guest | Read public |
|
|
69
|
+
| User | Read/Write own |
|
|
70
|
+
| Admin | Full access |
|
|
71
|
+
|
|
72
|
+
## 6. Error Handling
|
|
73
|
+
| Code | Meaning | Response |
|
|
74
|
+
|------|---------|----------|
|
|
75
|
+
| 400 | Bad Request | { "error": "message" } |
|
|
76
|
+
| 401 | Unauthorized | { "error": "Not authenticated" } |
|
|
77
|
+
| 403 | Forbidden | { "error": "Access denied" } |
|
|
78
|
+
| 404 | Not Found | { "error": "Resource not found" } |
|
|
79
|
+
| 500 | Server Error | { "error": "Internal error" } |
|
|
80
|
+
|
|
81
|
+
## 7. Open Questions
|
|
82
|
+
- [ ] @UIUX: [Question about UI requirements]
|
|
83
|
+
- [ ] @PO: [Question about business logic]
|
|
84
|
+
|
|
85
|
+
---
|
|
86
|
+
|
|
87
|
+
### Next Step:
|
|
88
|
+
- @QA - Review design for testability
|
|
89
|
+
- @SECA - Security review of API and auth design
|
|
90
|
+
- @DEV - Prepare for implementation
|
|
91
|
+
|
|
92
|
+
#designing
|
|
@@ -0,0 +1,67 @@
|
|
|
1
|
+
# Design Verification Report - Version [X]
|
|
2
|
+
|
|
3
|
+
## Document Info
|
|
4
|
+
| Field | Value |
|
|
5
|
+
|-------|-------|
|
|
6
|
+
| Version | [X.0] |
|
|
7
|
+
| Date | [YYYY-MM-DD] |
|
|
8
|
+
| Author | @QA |
|
|
9
|
+
| Status | Pass / Fail / Conditional Pass |
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## 1. Documents Reviewed
|
|
14
|
+
| Document | Version | Date Reviewed |
|
|
15
|
+
|----------|---------|---------------|
|
|
16
|
+
| Backend-Design-Spec | v[X] | [Date] |
|
|
17
|
+
| UIUX-Design-Spec | v[X] | [Date] |
|
|
18
|
+
| Project-Plan | v[X] | [Date] |
|
|
19
|
+
|
|
20
|
+
## 2. Verification Summary
|
|
21
|
+
| Category | Status | Issues |
|
|
22
|
+
|----------|--------|--------|
|
|
23
|
+
| Completeness | ✅/⚠️/❌ | [Count] |
|
|
24
|
+
| Consistency | ✅/⚠️/❌ | [Count] |
|
|
25
|
+
| Testability | ✅/⚠️/❌ | [Count] |
|
|
26
|
+
| Requirements Coverage | ✅/⚠️/❌ | [Count] |
|
|
27
|
+
|
|
28
|
+
## 3. Detailed Findings
|
|
29
|
+
|
|
30
|
+
### 3.1 Completeness
|
|
31
|
+
| ID | Finding | Severity | Status |
|
|
32
|
+
|----|---------|----------|--------|
|
|
33
|
+
| QA-001 | [Finding description] | High/Med/Low | Open/Resolved |
|
|
34
|
+
|
|
35
|
+
### 3.2 Consistency
|
|
36
|
+
| ID | Finding | Severity | Status |
|
|
37
|
+
|----|---------|----------|--------|
|
|
38
|
+
| QA-002 | [Finding description] | High/Med/Low | Open/Resolved |
|
|
39
|
+
|
|
40
|
+
### 3.3 Testability
|
|
41
|
+
| ID | Finding | Severity | Status |
|
|
42
|
+
|----|---------|----------|--------|
|
|
43
|
+
| QA-003 | [Finding description] | High/Med/Low | Open/Resolved |
|
|
44
|
+
|
|
45
|
+
## 4. Requirements Traceability
|
|
46
|
+
| Requirement | Design Reference | Covered |
|
|
47
|
+
|-------------|------------------|---------|
|
|
48
|
+
| [REQ-001] | Backend-Design 3.1 | ✅/❌ |
|
|
49
|
+
| [REQ-002] | UIUX-Design 3.2 | ✅/❌ |
|
|
50
|
+
|
|
51
|
+
## 5. Recommendations
|
|
52
|
+
1. [Recommendation 1]
|
|
53
|
+
2. [Recommendation 2]
|
|
54
|
+
|
|
55
|
+
## 6. Verdict
|
|
56
|
+
☐ **PASS** - Design approved for development
|
|
57
|
+
☐ **CONDITIONAL PASS** - Proceed with noted conditions
|
|
58
|
+
☐ **FAIL** - Design requires revision before development
|
|
59
|
+
|
|
60
|
+
---
|
|
61
|
+
|
|
62
|
+
### Next Step:
|
|
63
|
+
- @SA @UIUX - Address findings (if any)
|
|
64
|
+
- @DEV - Begin development (if approved)
|
|
65
|
+
- @SECA - Complete security review
|
|
66
|
+
|
|
67
|
+
#verify-design
|
|
@@ -0,0 +1,90 @@
|
|
|
1
|
+
# DevOps Plan and Log - Version [X]
|
|
2
|
+
|
|
3
|
+
## Document Info
|
|
4
|
+
| Field | Value |
|
|
5
|
+
|-------|-------|
|
|
6
|
+
| Version | [X.0] |
|
|
7
|
+
| Date | [YYYY-MM-DD] |
|
|
8
|
+
| Author | @DEVOPS |
|
|
9
|
+
| Status | Draft / Active |
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## 1. Infrastructure Overview
|
|
14
|
+
|
|
15
|
+
```
|
|
16
|
+
┌─────────────────────────────────────────────────────────┐
|
|
17
|
+
│ Production │
|
|
18
|
+
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
|
|
19
|
+
│ │ CDN │───▶│ App │───▶│ DB │ │
|
|
20
|
+
│ └──────────┘ └──────────┘ └──────────┘ │
|
|
21
|
+
└─────────────────────────────────────────────────────────┘
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
## 2. Environments
|
|
25
|
+
| Environment | URL | Purpose |
|
|
26
|
+
|-------------|-----|---------|
|
|
27
|
+
| Development | localhost:5173 | Local development |
|
|
28
|
+
| Staging | [staging-url] | Pre-production testing |
|
|
29
|
+
| Production | [prod-url] | Live environment |
|
|
30
|
+
|
|
31
|
+
## 3. CI/CD Pipeline
|
|
32
|
+
|
|
33
|
+
```
|
|
34
|
+
┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
|
|
35
|
+
│ Push │───▶│ Build │───▶│ Test │───▶│ Deploy │
|
|
36
|
+
└────────┘ └────────┘ └────────┘ └────────┘
|
|
37
|
+
```
|
|
38
|
+
|
|
39
|
+
### Pipeline Stages
|
|
40
|
+
| Stage | Tool | Duration | Status |
|
|
41
|
+
|-------|------|----------|--------|
|
|
42
|
+
| Build | [Tool] | ~[X]min | ✅/❌ |
|
|
43
|
+
| Test | [Tool] | ~[X]min | ✅/❌ |
|
|
44
|
+
| Deploy Staging | [Tool] | ~[X]min | ✅/❌ |
|
|
45
|
+
| Deploy Prod | [Tool] | ~[X]min | ✅/❌ |
|
|
46
|
+
|
|
47
|
+
## 4. Deployment Checklist
|
|
48
|
+
|
|
49
|
+
### Pre-Deployment
|
|
50
|
+
- [ ] All tests passing
|
|
51
|
+
- [ ] Security review approved
|
|
52
|
+
- [ ] Environment variables configured
|
|
53
|
+
- [ ] Database migrations ready
|
|
54
|
+
- [ ] Rollback plan documented
|
|
55
|
+
|
|
56
|
+
### Post-Deployment
|
|
57
|
+
- [ ] Health check passing
|
|
58
|
+
- [ ] Smoke tests completed
|
|
59
|
+
- [ ] Monitoring alerts active
|
|
60
|
+
- [ ] Documentation updated
|
|
61
|
+
|
|
62
|
+
## 5. Environment Variables
|
|
63
|
+
| Variable | Staging | Production | Notes |
|
|
64
|
+
|----------|---------|------------|-------|
|
|
65
|
+
| [VAR_NAME] | [Value] | [Value] | [Notes] |
|
|
66
|
+
|
|
67
|
+
## 6. Monitoring & Alerts
|
|
68
|
+
| Metric | Threshold | Alert Channel |
|
|
69
|
+
|--------|-----------|---------------|
|
|
70
|
+
| Error Rate | > 1% | [Slack/Email] |
|
|
71
|
+
| Response Time | > 2s | [Slack/Email] |
|
|
72
|
+
| Uptime | < 99.9% | [Slack/Email] |
|
|
73
|
+
|
|
74
|
+
## 7. Deployment Log
|
|
75
|
+
|
|
76
|
+
### [Date] - v[X.X.X]
|
|
77
|
+
| Field | Value |
|
|
78
|
+
|-------|-------|
|
|
79
|
+
| Environment | Staging / Production |
|
|
80
|
+
| Status | ✅ Success / ❌ Failed |
|
|
81
|
+
| Duration | [X minutes] |
|
|
82
|
+
| Changes | [Brief description] |
|
|
83
|
+
|
|
84
|
+
---
|
|
85
|
+
|
|
86
|
+
### Next Step:
|
|
87
|
+
- @TESTER - Staging environment ready for testing
|
|
88
|
+
- @REPORTER - Deployment documentation complete
|
|
89
|
+
|
|
90
|
+
#devops #deployed-staging
|
|
@@ -0,0 +1,78 @@
|
|
|
1
|
+
# Development Log - Version [X]
|
|
2
|
+
|
|
3
|
+
## Document Info
|
|
4
|
+
| Field | Value |
|
|
5
|
+
|-------|-------|
|
|
6
|
+
| Version | [X.0] |
|
|
7
|
+
| Date | [YYYY-MM-DD] |
|
|
8
|
+
| Author | @DEV |
|
|
9
|
+
| Sprint | [Sprint #] |
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## 1. Sprint Summary
|
|
14
|
+
| Metric | Value |
|
|
15
|
+
|--------|-------|
|
|
16
|
+
| Items Planned | [X] |
|
|
17
|
+
| Items Completed | [X] |
|
|
18
|
+
| Items Carried Over | [X] |
|
|
19
|
+
|
|
20
|
+
## 2. Completed Items
|
|
21
|
+
|
|
22
|
+
### [ITEM-001] [Item Title]
|
|
23
|
+
| Field | Value |
|
|
24
|
+
|-------|-------|
|
|
25
|
+
| Status | ✅ Completed |
|
|
26
|
+
| Files Changed | [List of files] |
|
|
27
|
+
| Time Spent | [X hours] |
|
|
28
|
+
|
|
29
|
+
**Implementation Notes:**
|
|
30
|
+
- [Key implementation detail]
|
|
31
|
+
- [Any deviations from design]
|
|
32
|
+
|
|
33
|
+
**Evidence:**
|
|
34
|
+
- [ ] Local tests passing
|
|
35
|
+
- [ ] Screenshot/Recording attached
|
|
36
|
+
|
|
37
|
+
---
|
|
38
|
+
|
|
39
|
+
### [ITEM-002] [Item Title]
|
|
40
|
+
| Field | Value |
|
|
41
|
+
|-------|-------|
|
|
42
|
+
| Status | ✅ Completed |
|
|
43
|
+
| Files Changed | [List of files] |
|
|
44
|
+
| Time Spent | [X hours] |
|
|
45
|
+
|
|
46
|
+
**Implementation Notes:**
|
|
47
|
+
- [Key implementation detail]
|
|
48
|
+
|
|
49
|
+
---
|
|
50
|
+
|
|
51
|
+
## 3. In Progress Items
|
|
52
|
+
|
|
53
|
+
### [ITEM-003] [Item Title]
|
|
54
|
+
| Field | Value |
|
|
55
|
+
|-------|-------|
|
|
56
|
+
| Status | 🔄 In Progress |
|
|
57
|
+
| Blocker | [None / Description] |
|
|
58
|
+
| ETA | [Date] |
|
|
59
|
+
|
|
60
|
+
---
|
|
61
|
+
|
|
62
|
+
## 4. Blockers & Issues
|
|
63
|
+
| ID | Description | Status | Action |
|
|
64
|
+
|----|-------------|--------|--------|
|
|
65
|
+
| BLK-001 | [Blocker description] | Open/Resolved | @[ROLE] to assist |
|
|
66
|
+
|
|
67
|
+
## 5. Technical Debt
|
|
68
|
+
| Item | Priority | Notes |
|
|
69
|
+
|------|----------|-------|
|
|
70
|
+
| [Tech debt item] | Low/Med/High | [Brief description] |
|
|
71
|
+
|
|
72
|
+
---
|
|
73
|
+
|
|
74
|
+
### Next Step:
|
|
75
|
+
- @TESTER - Items ready for testing: [ITEM-001, ITEM-002]
|
|
76
|
+
- @DEVOPS - Ready for staging deployment
|
|
77
|
+
|
|
78
|
+
#development
|
|
@@ -0,0 +1,82 @@
|
|
|
1
|
+
# Final Approval Report
|
|
2
|
+
|
|
3
|
+
## Document Info
|
|
4
|
+
| Field | Value |
|
|
5
|
+
|-------|-------|
|
|
6
|
+
| Date | [YYYY-MM-DD] |
|
|
7
|
+
| Author | @STAKEHOLDER |
|
|
8
|
+
| Project | [Project Name] |
|
|
9
|
+
| Version | [Final Version] |
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## 1. Project Summary
|
|
14
|
+
| Metric | Target | Achieved |
|
|
15
|
+
|--------|--------|----------|
|
|
16
|
+
| Features (Must-Have) | [X] | [X] ✅/❌ |
|
|
17
|
+
| Features (Should-Have) | [X] | [X] ✅/❌ |
|
|
18
|
+
| Features (Could-Have) | [X] | [X] ✅/❌ |
|
|
19
|
+
| Timeline | [Date] | [Date] ✅/❌ |
|
|
20
|
+
|
|
21
|
+
## 2. Acceptance Criteria Review
|
|
22
|
+
| Requirement | Status | Notes |
|
|
23
|
+
|-------------|--------|-------|
|
|
24
|
+
| [REQ-001] [Description] | ✅ Met / ❌ Not Met | [Notes] |
|
|
25
|
+
| [REQ-002] [Description] | ✅ Met / ❌ Not Met | [Notes] |
|
|
26
|
+
|
|
27
|
+
## 3. Quality Assessment
|
|
28
|
+
| Area | Status | Reviewer |
|
|
29
|
+
|------|--------|----------|
|
|
30
|
+
| Functionality | ✅/⚠️/❌ | @TESTER |
|
|
31
|
+
| Security | ✅/⚠️/❌ | @SECA |
|
|
32
|
+
| Performance | ✅/⚠️/❌ | @DEVOPS |
|
|
33
|
+
| Usability | ✅/⚠️/❌ | @UIUX |
|
|
34
|
+
|
|
35
|
+
## 4. Outstanding Issues
|
|
36
|
+
| Issue | Severity | Decision |
|
|
37
|
+
|-------|----------|----------|
|
|
38
|
+
| [Issue description] | Low/Med/High | Accept / Defer / Block |
|
|
39
|
+
|
|
40
|
+
## 5. Documentation Checklist
|
|
41
|
+
- [ ] Project Plan (final version)
|
|
42
|
+
- [ ] Design Specifications
|
|
43
|
+
- [ ] Test Reports
|
|
44
|
+
- [ ] Deployment Documentation
|
|
45
|
+
- [ ] User Guide (if applicable)
|
|
46
|
+
- [ ] Final Project Report
|
|
47
|
+
|
|
48
|
+
## 6. Stakeholder Sign-Off
|
|
49
|
+
|
|
50
|
+
### Decision
|
|
51
|
+
☐ **APPROVED** - Project accepted, ready for production
|
|
52
|
+
☐ **APPROVED WITH CONDITIONS** - Accepted with noted limitations
|
|
53
|
+
☐ **REJECTED** - Requires additional work before acceptance
|
|
54
|
+
|
|
55
|
+
### Conditions (if applicable)
|
|
56
|
+
- [Condition 1]
|
|
57
|
+
- [Condition 2]
|
|
58
|
+
|
|
59
|
+
### Approver
|
|
60
|
+
| Field | Value |
|
|
61
|
+
|-------|-------|
|
|
62
|
+
| Name | [Stakeholder name] |
|
|
63
|
+
| Role | @STAKEHOLDER |
|
|
64
|
+
| Date | [YYYY-MM-DD] |
|
|
65
|
+
| Signature | [Approved/Rejected] |
|
|
66
|
+
|
|
67
|
+
---
|
|
68
|
+
|
|
69
|
+
## 7. Post-Approval Actions
|
|
70
|
+
|
|
71
|
+
### If Approved:
|
|
72
|
+
- @DEVOPS - Proceed with production deployment
|
|
73
|
+
- @REPORTER - Finalize all documentation
|
|
74
|
+
- @PM - Close project and notify user
|
|
75
|
+
|
|
76
|
+
### If Rejected:
|
|
77
|
+
- @PM - Initiate cycle repeat with updated requirements
|
|
78
|
+
- @REPORTER - Document rejection reasons
|
|
79
|
+
|
|
80
|
+
---
|
|
81
|
+
|
|
82
|
+
#stakeholder-review #reporting
|