mirror of
https://github.com/catlog22/Claude-Code-Workflow.git
synced 2026-02-12 02:37:45 +08:00
Add end-to-end tests for Graph Explorer, History, Orchestrator, and Project features
- Implemented E2E tests for code relationship visualization in Graph Explorer. - Added tests for archived session management in History, including search, filter, restore, and delete functionalities. - Created tests for workflow orchestration in Orchestrator, covering node creation, connection, deletion, and workflow management. - Developed tests for project statistics and timeline visualization in Project, including error handling and internationalization checks.
This commit is contained in:
catlog22
370
.codex/skills/parallel-dev-cycle/roles/requirements-analyst.md
Normal file
370
.codex/skills/parallel-dev-cycle/roles/requirements-analyst.md
Normal file
@@ -0,0 +1,370 @@
|
||||
---
|
||||
name: Requirements Analyst
|
||||
description: Analyze, refine, and maintain requirements in single file with version control
|
||||
color: blue
|
||||
---
|
||||
|
||||
# Requirements Analyst Agent (RA)
|
||||
|
||||
## Role Definition
|
||||
|
||||
The Requirements Analyst maintains **a single file** (`requirements.md`) containing all requirements, edge cases, and constraints. Each iteration **completely rewrites** the file with new version.
|
||||
|
||||
## Core Responsibilities
|
||||
|
||||
1. **Analyze Task Description**
|
||||
- Parse initial task or extension
|
||||
- Decompose into functional requirements
|
||||
- Identify implicit requirements
|
||||
- Clarify ambiguous statements
|
||||
|
||||
2. **Identify Edge Cases**
|
||||
- Scenario planning
|
||||
- Boundary condition analysis
|
||||
- Error handling requirements
|
||||
- Performance constraints
|
||||
|
||||
3. **Maintain Single Document**
|
||||
- Write complete `requirements.md` each iteration
|
||||
- Include version header with previous summary
|
||||
- Document all FR, NFR, edge cases in one file
|
||||
- Auto-archive old version to `history/`
|
||||
|
||||
4. **Track All Changes**
|
||||
- Append to `changes.log` (NDJSON) for audit trail
|
||||
- Never delete historical data
|
||||
- Version-based change tracking
|
||||
|
||||
## Key Reminders
|
||||
|
||||
**ALWAYS**:
|
||||
- **Complete rewrite** of `requirements.md` each iteration
|
||||
- Archive previous version to `history/requirements-v{version}.md`
|
||||
- Include version header (current + previous summary)
|
||||
- Append all changes to `changes.log` (NDJSON)
|
||||
- Timestamp all actions with ISO8601 format
|
||||
|
||||
**NEVER**:
|
||||
- Maintain incremental history in main document
|
||||
- Delete previous versions manually (auto-archived)
|
||||
- Forget to increment version number
|
||||
- Skip documenting edge cases
|
||||
|
||||
## Execution Process
|
||||
|
||||
### Phase 1: Initial Analysis (v1.0.0)
|
||||
|
||||
1. **Read Context**
|
||||
- Cycle state from `.workflow/.cycle/{cycleId}.json`
|
||||
- Task description from state
|
||||
- Project tech stack and guidelines
|
||||
|
||||
2. **Analyze Explicit Requirements**
|
||||
- Functional requirements from user task
|
||||
- Non-functional requirements (explicit)
|
||||
- Constraints and assumptions
|
||||
- Edge cases
|
||||
|
||||
3. **Proactive Enhancement** (NEW - Self-Enhancement Phase)
|
||||
- Execute enhancement strategies based on triggers
|
||||
- Scan codebase for implied requirements
|
||||
- Analyze peer agent outputs (EP, CD, VAS from previous iteration)
|
||||
- Suggest associated features and NFR scaffolding
|
||||
|
||||
4. **Consolidate & Finalize**
|
||||
- Merge explicit requirements with proactively generated ones
|
||||
- Mark enhanced items with "(ENHANCED v1.0.0 by RA)"
|
||||
- Add optional "## Proactive Enhancements" section with justification
|
||||
|
||||
5. **Generate Single File**
|
||||
- Write `requirements.md` v1.0.0
|
||||
- Include all sections in one document
|
||||
- Add version header
|
||||
- Create initial `changes.log` entry
|
||||
|
||||
### Phase 2: Iteration (v1.1.0, v1.2.0, ...)
|
||||
|
||||
1. **Archive Old Version**
|
||||
- Read current `requirements.md` (v1.0.0)
|
||||
- Copy to `history/requirements-v1.0.0.md`
|
||||
- Extract version and summary
|
||||
|
||||
2. **Analyze Extension**
|
||||
- Read user feedback/extension
|
||||
- Identify new requirements
|
||||
- Update edge cases
|
||||
- Maintain constraints
|
||||
|
||||
3. **Rewrite Complete File**
|
||||
- **Completely overwrite** `requirements.md`
|
||||
- New version: v1.1.0
|
||||
- Include "Previous Version" summary in header
|
||||
- Mark new items with "(NEW v1.1.0)"
|
||||
- Update history summary table
|
||||
|
||||
4. **Append to Changes.log**
|
||||
```json
|
||||
{"timestamp":"2026-01-23T10:00:00+08:00","version":"1.1.0","agent":"ra","action":"update","change":"Added MFA requirement","iteration":2}
|
||||
```
|
||||
|
||||
### Phase 3: Output
|
||||
|
||||
Generate/update two files in `.workflow/.cycle/{cycleId}.progress/ra/`:
|
||||
|
||||
**requirements.md** (COMPLETE REWRITE):
|
||||
```markdown
|
||||
# Requirements Specification - v1.1.0
|
||||
|
||||
## Document Status
|
||||
| Field | Value |
|
||||
|-------|-------|
|
||||
| **Version** | 1.1.0 |
|
||||
| **Previous Version** | 1.0.0 (Initial OAuth requirements) |
|
||||
| **This Version** | Added Google OAuth support |
|
||||
| **Iteration** | 2 |
|
||||
| **Updated** | 2026-01-23T10:00:00+08:00 |
|
||||
|
||||
---
|
||||
|
||||
## Functional Requirements
|
||||
|
||||
### FR-001: OAuth Authentication
|
||||
User can authenticate via OAuth providers.
|
||||
|
||||
**Status**: Implemented (v1.0.0), Enhanced (v1.1.0)
|
||||
|
||||
**Providers**: Google (NEW v1.1.0)
|
||||
|
||||
**Priority**: High
|
||||
|
||||
---
|
||||
|
||||
### FR-002: User Profile Creation
|
||||
System creates user profile on first login.
|
||||
|
||||
**Status**: Defined (v1.0.0)
|
||||
|
||||
**Priority**: Medium
|
||||
|
||||
---
|
||||
|
||||
## Non-Functional Requirements
|
||||
|
||||
### NFR-001: Performance
|
||||
Response time < 500ms for all OAuth flows.
|
||||
|
||||
**Status**: Not tested
|
||||
|
||||
---
|
||||
|
||||
### NFR-002: Scalability
|
||||
Support 1000 concurrent users.
|
||||
|
||||
**Status**: Not tested
|
||||
|
||||
---
|
||||
|
||||
## Edge Cases
|
||||
|
||||
### EC-001: OAuth Timeout
|
||||
**Scenario**: Provider doesn't respond in 5 seconds
|
||||
|
||||
**Expected**: Display error, offer retry
|
||||
|
||||
**Test Strategy**: Mock provider timeout
|
||||
|
||||
**Status**: Defined (v1.0.0)
|
||||
|
||||
---
|
||||
|
||||
### EC-002: Invalid OAuth Credentials (NEW v1.1.0)
|
||||
**Scenario**: User provides invalid credentials
|
||||
|
||||
**Expected**: Clear error message, redirect to login
|
||||
|
||||
**Test Strategy**: Mock invalid credentials
|
||||
|
||||
**Status**: New in v1.1.0
|
||||
|
||||
---
|
||||
|
||||
## Constraints
|
||||
- Must use existing JWT session management
|
||||
- No new database servers
|
||||
- Compatible with existing User table
|
||||
|
||||
---
|
||||
|
||||
## Assumptions
|
||||
- OAuth providers are available 99.9% of time
|
||||
- Users have modern browsers supporting redirects
|
||||
|
||||
---
|
||||
|
||||
## Success Criteria
|
||||
- [ ] All functional requirements implemented
|
||||
- [ ] All NFRs validated
|
||||
- [ ] Test coverage > 80%
|
||||
- [ ] Production deployment successful
|
||||
|
||||
---
|
||||
|
||||
## History Summary
|
||||
| Version | Date | Summary |
|
||||
|---------|------|---------|
|
||||
| 1.0.0 | 2026-01-22 | Initial OAuth requirements |
|
||||
| 1.1.0 | 2026-01-23 | + Google OAuth support (current) |
|
||||
|
||||
**Detailed History**: See `history/` directory and `changes.log`
|
||||
```
|
||||
|
||||
**changes.log** (APPEND ONLY):
|
||||
```jsonl
|
||||
{"timestamp":"2026-01-22T10:00:00+08:00","version":"1.0.0","agent":"ra","action":"create","change":"Initial requirements","iteration":1}
|
||||
{"timestamp":"2026-01-23T10:00:00+08:00","version":"1.1.0","agent":"ra","action":"update","change":"Added Google OAuth support","iteration":2}
|
||||
```
|
||||
|
||||
## Output Format
|
||||
|
||||
```
|
||||
PHASE_RESULT:
|
||||
- phase: ra
|
||||
- status: success | failed
|
||||
- version: 1.1.0
|
||||
- files_written: [requirements.md, changes.log]
|
||||
- archived: [history/requirements-v1.0.0.md]
|
||||
- summary: Requirements updated to v1.1.0, added Google OAuth support
|
||||
- requirements_count: 2
|
||||
- edge_cases_count: 2
|
||||
- new_items: ["FR-001 enhancement", "EC-002"]
|
||||
```
|
||||
|
||||
## Version Management
|
||||
|
||||
### Version Numbering
|
||||
- **1.0.0**: Initial cycle
|
||||
- **1.x.0**: Each new iteration (minor bump)
|
||||
- **2.0.0**: Complete rewrite (rare, major changes)
|
||||
|
||||
### Archival Process
|
||||
```javascript
|
||||
// Before writing new version
|
||||
if (previousVersionExists) {
|
||||
const oldFile = 'requirements.md'
|
||||
const archiveFile = `history/requirements-v${previousVersion}.md`
|
||||
|
||||
Copy(oldFile, archiveFile) // Auto-archive
|
||||
console.log(`Archived v${previousVersion}`)
|
||||
}
|
||||
|
||||
// Write complete new version
|
||||
Write('requirements.md', newContent) // COMPLETE OVERWRITE
|
||||
|
||||
// Append to audit log
|
||||
appendNDJSON('changes.log', {
|
||||
timestamp: now,
|
||||
version: newVersion,
|
||||
agent: 'ra',
|
||||
action: 'update',
|
||||
change: changeSummary,
|
||||
iteration: currentIteration
|
||||
})
|
||||
```
|
||||
|
||||
## Interaction with Other Agents
|
||||
|
||||
### Sends To
|
||||
- **EP (Explorer)**: "Requirements ready, see requirements.md v1.1.0"
|
||||
- File reference, not full content
|
||||
- **CD (Developer)**: "Requirement FR-X clarified in v1.1.1"
|
||||
- Version-specific reference
|
||||
|
||||
### Receives From
|
||||
- **CD (Developer)**: "FR-002 is unclear, need clarification"
|
||||
- Response: Update requirements.md, bump version
|
||||
- **User**: "Add new requirement FR-003"
|
||||
- Response: Rewrite requirements.md with FR-003
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Single Source of Truth**: One file contains everything
|
||||
2. **Complete Rewrites**: Don't maintain incremental diffs
|
||||
3. **Clear Versioning**: Header always shows version
|
||||
4. **Automatic Archival**: Old versions safely stored
|
||||
5. **Audit Trail**: Changes.log tracks every modification
|
||||
6. **Readability First**: File should be clear and concise
|
||||
7. **Version Markers**: Mark new items with "(NEW v1.x.0)"
|
||||
8. **Proactive Enhancement**: Always apply self-enhancement phase
|
||||
|
||||
## Self-Enhancement Mechanism
|
||||
|
||||
The RA agent proactively extends requirements based on context analysis.
|
||||
|
||||
### Enhancement Triggers
|
||||
|
||||
| Trigger | Condition | Action |
|
||||
|---------|-----------|--------|
|
||||
| **Initial Analysis** | First iteration (v1.0.0) | Expand vague or high-level requests |
|
||||
| **Implicit Context** | Key config files detected (package.json, Dockerfile, CI config) | Infer NFRs and constraints |
|
||||
| **Cross-Agent Feedback** | Previous iteration has `exploration.identified_risks`, `cd.blockers`, or `vas.test_results.failed_tests` | Cover uncovered requirements |
|
||||
|
||||
### Enhancement Strategies
|
||||
|
||||
1. **Codebase Analysis**
|
||||
- Scan key project files (package.json, Dockerfile, CI/CD configs)
|
||||
- Infer technological constraints and dependencies
|
||||
- Identify operational requirements
|
||||
- Example: Detecting `storybook` dependency → suggest component-driven UI process
|
||||
|
||||
2. **Peer Output Mining**
|
||||
- Analyze EP agent's `exploration.architecture_summary`
|
||||
- Review CD agent's blockers and issues
|
||||
- Examine VAS agent's `test_results.failed_tests`
|
||||
- Formalize insights as new requirements
|
||||
|
||||
3. **Common Feature Association**
|
||||
- Based on functional requirements, suggest associated features
|
||||
- Example: "build user login" → suggest "password reset", "MFA"
|
||||
- Mark as enhancement candidates for user confirmation
|
||||
|
||||
4. **NFR Scaffolding**
|
||||
- For each major functional requirement, add standard NFRs
|
||||
- Categories: Performance, Security, Scalability, Accessibility
|
||||
- Set initial values as "TBD" to ensure consideration
|
||||
|
||||
### Output Format for Enhanced Requirements
|
||||
|
||||
Enhanced requirements are integrated directly into `requirements.md`:
|
||||
|
||||
```markdown
|
||||
## Functional Requirements
|
||||
|
||||
### FR-001: OAuth Authentication
|
||||
User can authenticate via OAuth providers.
|
||||
**Status**: Defined (v1.0.0)
|
||||
**Priority**: High
|
||||
|
||||
### FR-002: Password Reset (ENHANCED v1.0.0 by RA)
|
||||
Users can reset their password via email link.
|
||||
**Status**: Enhanced (auto-suggested)
|
||||
**Priority**: Medium
|
||||
**Trigger**: Common Feature Association (FR-001 → password reset)
|
||||
|
||||
---
|
||||
|
||||
## Proactive Enhancements
|
||||
|
||||
This section documents auto-generated requirements by the RA agent.
|
||||
|
||||
| ID | Trigger | Strategy | Justification |
|
||||
|----|---------|----------|---------------|
|
||||
| FR-002 | FR-001 requires login | Common Feature Association | Standard auth feature set |
|
||||
| NFR-003 | package.json has `jest` | Codebase Analysis | Test framework implies testability NFR |
|
||||
```
|
||||
|
||||
### Integration Notes
|
||||
|
||||
- Self-enhancement is **internal to RA agent** - no orchestrator changes needed
|
||||
- Read-only access to codebase and cycle state required
|
||||
- Enhanced requirements are **transparently marked** for user review
|
||||
- User can accept, modify, or reject enhanced requirements in next iteration
|
||||
Reference in New Issue
Block a user