feat: Add Role Analysis Reviewer Agent and validation template

- Introduced Role Analysis Reviewer Agent to validate role analysis outputs against templates and quality standards.
- Created a detailed validation ruleset for the system-architect role, including mandatory and recommended sections.
- Added JSON validation report structure for output.
- Implemented execution command for validation process.

test: Add UX tests for HookCard component

- Created comprehensive tests for HookCard component, focusing on delete confirmation UX pattern.
- Verified confirmation dialog appearance, deletion functionality, and button interactions.
- Ensured proper handling of state updates and visual feedback for enabled/disabled status.

test: Add UX tests for ThemeSelector component

- Developed tests for ThemeSelector component, emphasizing delete confirmation UX pattern.
- Validated confirmation dialog display, deletion actions, and toast notifications for undo functionality.
- Ensured proper management of theme slots and state updates.

feat: Implement useDebounce hook

- Added useDebounce hook to delay expensive computations or API calls, enhancing performance.

feat: Create System Architect Analysis Template

- Developed a comprehensive template for system architect role analysis, covering required sections such as architecture overview, data model, state machine, error handling strategy, observability requirements, configuration model, and boundary scenarios.
- Included examples and templates for each section to guide users in producing SPEC.md-level precision modeling.
This commit is contained in:
catlog22
2026-03-05 19:58:10 +08:00
parent bc7a556985
commit 3fd55ebd4b
55 changed files with 4262 additions and 1138 deletions

View File

@@ -531,22 +531,32 @@ ${feature_mode ? `
**Status**: Draft (from synthesis)
## 1. Requirements Summary
[Consolidated requirements from all role perspectives]
- Functional requirements (from product-manager, product-owner)
- User experience requirements (from ux-expert, ui-designer)
- Technical requirements (from system-architect, data-architect, api-designer)
- Domain requirements (from subject-matter-expert)
[Consolidated requirements from all role perspectives using RFC 2119 keywords]
- Functional requirements (from product-manager, product-owner) - use MUST/SHOULD/MAY
- User experience requirements (from ux-expert, ui-designer) - use MUST/SHOULD/MAY
- Technical requirements (from system-architect, data-architect, api-designer) - use MUST/SHOULD/MAY
- Domain requirements (from subject-matter-expert) - use MUST/SHOULD/MAY
**Example**:
- The feature MUST support user authentication via email/password
- The UI SHOULD provide real-time feedback within 100ms
- The system MAY cache user preferences for offline access
## 2. Design Decisions [CORE SECTION]
[Key architectural and design decisions with rationale - 40%+ of word count]
For each decision:
- **Decision**: [What was decided]
- **Decision**: [What was decided - MUST use RFC 2119 keywords]
- **Context**: [Why this decision was needed]
- **Options Considered**: [Alternatives from different roles]
- **Chosen Approach**: [Selected option with rationale]
- **Chosen Approach**: [Selected option with rationale using MUST/SHOULD/MAY]
- **Trade-offs**: [What we gain vs. what we sacrifice]
- **Source**: [Which role(s) drove this decision]
**RFC 2119 Examples**:
- "The system MUST authenticate users before granting access"
- "The feature SHOULD cache frequently accessed data for performance"
- "The component MAY support OAuth2 authentication as an optional enhancement"
## 3. Interface Contract
[API endpoints, data models, component interfaces]
- External interfaces (API contracts from api-designer)