mirror of
https://github.com/jjbrunton/Sauci.git
synced 2026-10-31 10:19:43 +00:00
Add match archiving, chat enhancements, and daily limits
- Match archives with swipe-to-archive and unread filtering - Chat settings sheet and full-screen media modals - Match notification modal for new matches - Admin AI settings with model/provider configuration - Daily response limit feature with recommended questions - New test coverage for stores, hooks, and components - Claude Code agent and command configurations Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
1 parent
595d6bd394
commit
b0f1700e40
57 files changed
+8359
-1661
No files matched your search
@@ -0,0 +1,87 @@
|
||||
---
|
||||
allowed-tools: Read, Write, Edit, Bash
|
||||
argument-hint: [file-path] | [component-name]
|
||||
description: Generate comprehensive test suite with unit, integration, and edge case coverage
|
||||
---
|
||||
|
||||
# Generate Tests
|
||||
|
||||
Generate comprehensive test suite for: $ARGUMENTS
|
||||
|
||||
## Current Testing Setup
|
||||
|
||||
- Test framework: @package.json or @jest.config.js or @vitest.config.js (detect framework)
|
||||
- Existing tests: !`find . -name "*.test.*" -o -name "*.spec.*" | head -5`
|
||||
- Test coverage: !`npm run test:coverage 2>/dev/null || echo "No coverage script"`
|
||||
- Target file: @$ARGUMENTS (if file path provided)
|
||||
|
||||
## Task
|
||||
|
||||
I'll analyze the target code and create complete test coverage including:
|
||||
|
||||
1. Unit tests for individual functions and methods
|
||||
2. Integration tests for component interactions
|
||||
3. Edge case and error handling tests
|
||||
4. Mock implementations for external dependencies
|
||||
5. Test utilities and helpers as needed
|
||||
6. Performance and snapshot tests where appropriate
|
||||
|
||||
## Process
|
||||
|
||||
I'll follow these steps:
|
||||
|
||||
1. Analyze the target file/component structure
|
||||
2. Identify all testable functions, methods, and behaviors
|
||||
3. Examine existing test patterns in the project
|
||||
4. Create test files following project naming conventions
|
||||
5. Implement comprehensive test cases with proper setup/teardown
|
||||
6. Add necessary mocks and test utilities
|
||||
7. Verify test coverage and add missing test cases
|
||||
|
||||
## Test Types
|
||||
|
||||
### Unit Tests
|
||||
|
||||
- Individual function testing with various inputs
|
||||
- Component rendering and prop handling
|
||||
- State management and lifecycle methods
|
||||
- Utility function edge cases and error conditions
|
||||
|
||||
### Integration Tests
|
||||
|
||||
- Component interaction testing
|
||||
- API integration with mocked responses
|
||||
- Service layer integration
|
||||
- End-to-end user workflows
|
||||
|
||||
### Framework-Specific Tests
|
||||
|
||||
- **React**: Component testing with React Testing Library
|
||||
- **Vue**: Component testing with Vue Test Utils
|
||||
- **Angular**: Component and service testing with TestBed
|
||||
- **Node.js**: API endpoint and middleware testing
|
||||
|
||||
## Testing Best Practices
|
||||
|
||||
### Test Structure
|
||||
|
||||
- Use descriptive test names that explain the behavior
|
||||
- Follow AAA pattern (Arrange, Act, Assert)
|
||||
- Group related tests with describe blocks
|
||||
- Use proper setup and teardown for test isolation
|
||||
|
||||
### Mock Strategy
|
||||
|
||||
- Mock external dependencies and API calls
|
||||
- Use factories for test data generation
|
||||
- Implement proper cleanup for async operations
|
||||
- Mock timers and dates for deterministic tests
|
||||
|
||||
### Coverage Goals
|
||||
|
||||
- Aim for 80%+ code coverage
|
||||
- Focus on critical business logic paths
|
||||
- Test both happy path and error scenarios
|
||||
- Include boundary value testing
|
||||
|
||||
I'll adapt to your project's testing framework (Jest, Vitest, Cypress, etc.) and follow established patterns.
|
||||
@@ -0,0 +1,106 @@
|
||||
---
|
||||
allowed-tools: Read, Write, Edit, Bash
|
||||
argument-hint: [doc-type] | --implementation | --api | --architecture | --sync | --validate
|
||||
description: Systematically update project documentation with implementation status, API changes, and synchronized content
|
||||
---
|
||||
|
||||
# Documentation Update & Synchronization
|
||||
|
||||
Update project documentation systematically: $ARGUMENTS
|
||||
|
||||
## Current Documentation State
|
||||
|
||||
- Documentation structure: !`find . -name "*.md" | head -10`
|
||||
- Specs directory: @specs/ (if exists)
|
||||
- Implementation status: !`grep -r "✅\|❌\|⚠️" docs/ specs/ 2>/dev/null | wc -l` status indicators
|
||||
- Recent changes: !`git log --oneline --since="1 week ago" -- "*.md" | head -5`
|
||||
- Project progress: @CLAUDE.md or @README.md (if exists)
|
||||
|
||||
## Task
|
||||
|
||||
## Documentation Analysis
|
||||
|
||||
1. Review current documentation status:
|
||||
- Check `specs/implementation_status.md` for overall project status
|
||||
- Review implemented phase document (`specs/phase{N}_implementation_plan.md`)
|
||||
- Review `specs/flutter_structurizr_implementation_spec.md` and `specs/flutter_structurizr_implementation_spec_updated.md`
|
||||
- Review `specs/testing_plan.md` to ensure it is current given recent test passes, failures, and changes
|
||||
- Examine `CLAUDE.md` and `README.md` for project-wide documentation
|
||||
- Check for and document any new lessons learned or best practices in CLAUDE.md
|
||||
|
||||
2. Analyze implementation and testing results:
|
||||
- Review what was implemented in the last phase
|
||||
- Review testing results and coverage
|
||||
- Identify new best practices discovered during implementation
|
||||
- Note any implementation challenges and solutions
|
||||
- Cross-reference updated documentation with recent implementation and test results to ensure accuracy
|
||||
|
||||
## Documentation Updates
|
||||
|
||||
1. Update phase implementation document:
|
||||
- Mark completed tasks with ✅ status
|
||||
- Update implementation percentages
|
||||
- Add detailed notes on implementation approach
|
||||
- Document any deviations from original plan with justification
|
||||
- Add new sections if needed (lessons learned, best practices)
|
||||
- Document specific implementation details for complex components
|
||||
- Include a summary of any new troubleshooting tips or workflow improvements discovered during the phase
|
||||
|
||||
2. Update implementation status document:
|
||||
- Update phase completion percentages
|
||||
- Add or update implementation status for components
|
||||
- Add notes on implementation approach and decisions
|
||||
- Document best practices discovered during implementation
|
||||
- Note any challenges overcome and solutions implemented
|
||||
|
||||
3. Update implementation specification documents:
|
||||
- Mark completed items with ✅ or strikethrough but preserve original requirements
|
||||
- Add notes on implementation details where appropriate
|
||||
- Add references to implemented files and classes
|
||||
- Update any implementation guidance based on experience
|
||||
|
||||
4. Update CLAUDE.md and README.md if necessary:
|
||||
- Add new best practices
|
||||
- Update project status
|
||||
- Add new implementation guidance
|
||||
- Document known issues or limitations
|
||||
- Update usage examples to include new functionality
|
||||
|
||||
5. Document new testing procedures:
|
||||
- Add details on test files created
|
||||
- Include test running instructions
|
||||
- Document test coverage
|
||||
- Explain testing approach for complex components
|
||||
|
||||
## Documentation Formatting and Structure
|
||||
|
||||
1. Maintain consistent documentation style:
|
||||
- Use clear headings and sections
|
||||
- Include code examples where helpful
|
||||
- Use status indicators (✅, ⚠️, ❌) consistently
|
||||
- Maintain proper Markdown formatting
|
||||
|
||||
2. Ensure documentation completeness:
|
||||
- Cover all implemented features
|
||||
- Include usage examples
|
||||
- Document API changes or additions
|
||||
- Include troubleshooting guidance for common issues
|
||||
|
||||
## Guidelines
|
||||
|
||||
- DO NOT CREATE new specification files
|
||||
- UPDATE existing files in the `specs/` directory
|
||||
- Maintain consistent documentation style
|
||||
- Include practical examples where appropriate
|
||||
- Cross-reference related documentation sections
|
||||
- Document best practices and lessons learned
|
||||
- Provide clear status updates on project progress
|
||||
- Update numerical completion percentages
|
||||
- Ensure documentation reflects actual implementation
|
||||
|
||||
Provide a summary of documentation updates after completion, including:
|
||||
1. Files updated
|
||||
2. Major changes to documentation
|
||||
3. Updated completion percentages
|
||||
4. New best practices documented
|
||||
5. Status of the overall project after this phase
|
||||
Reference in new issue
Block a user