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.
@@ -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