diff --git a/.gitignore b/.gitignore index 8017b1a..7eca63f 100644 --- a/.gitignore +++ b/.gitignore @@ -1,6 +1,7 @@ _hdl_checker .vscode .cache +.spec-workflow /fpga/.Xil /fpga/project diff --git a/.spec-workflow/templates/design-template.md b/.spec-workflow/templates/design-template.md deleted file mode 100644 index 1295d7b..0000000 --- a/.spec-workflow/templates/design-template.md +++ /dev/null @@ -1,96 +0,0 @@ -# Design Document - -## Overview - -[High-level description of the feature and its place in the overall system] - -## Steering Document Alignment - -### Technical Standards (tech.md) -[How the design follows documented technical patterns and standards] - -### Project Structure (structure.md) -[How the implementation will follow project organization conventions] - -## Code Reuse Analysis -[What existing code will be leveraged, extended, or integrated with this feature] - -### Existing Components to Leverage -- **[Component/Utility Name]**: [How it will be used] -- **[Service/Helper Name]**: [How it will be extended] - -### Integration Points -- **[Existing System/API]**: [How the new feature will integrate] -- **[Database/Storage]**: [How data will connect to existing schemas] - -## Architecture - -[Describe the overall architecture and design patterns used] - -### Modular Design Principles -- **Single File Responsibility**: Each file should handle one specific concern or domain -- **Component Isolation**: Create small, focused components rather than large monolithic files -- **Service Layer Separation**: Separate data access, business logic, and presentation layers -- **Utility Modularity**: Break utilities into focused, single-purpose modules - -```mermaid -graph TD - A[Component A] --> B[Component B] - B --> C[Component C] -``` - -## Components and Interfaces - -### Component 1 -- **Purpose:** [What this component does] -- **Interfaces:** [Public methods/APIs] -- **Dependencies:** [What it depends on] -- **Reuses:** [Existing components/utilities it builds upon] - -### Component 2 -- **Purpose:** [What this component does] -- **Interfaces:** [Public methods/APIs] -- **Dependencies:** [What it depends on] -- **Reuses:** [Existing components/utilities it builds upon] - -## Data Models - -### Model 1 -``` -[Define the structure of Model1 in your language] -- id: [unique identifier type] -- name: [string/text type] -- [Additional properties as needed] -``` - -### Model 2 -``` -[Define the structure of Model2 in your language] -- id: [unique identifier type] -- [Additional properties as needed] -``` - -## Error Handling - -### Error Scenarios -1. **Scenario 1:** [Description] - - **Handling:** [How to handle] - - **User Impact:** [What user sees] - -2. **Scenario 2:** [Description] - - **Handling:** [How to handle] - - **User Impact:** [What user sees] - -## Testing Strategy - -### Unit Testing -- [Unit testing approach] -- [Key components to test] - -### Integration Testing -- [Integration testing approach] -- [Key flows to test] - -### End-to-End Testing -- [E2E testing approach] -- [User scenarios to test] diff --git a/.spec-workflow/templates/product-template.md b/.spec-workflow/templates/product-template.md deleted file mode 100644 index 82e60de..0000000 --- a/.spec-workflow/templates/product-template.md +++ /dev/null @@ -1,51 +0,0 @@ -# Product Overview - -## Product Purpose -[Describe the core purpose of this product/project. What problem does it solve?] - -## Target Users -[Who are the primary users of this product? What are their needs and pain points?] - -## Key Features -[List the main features that deliver value to users] - -1. **Feature 1**: [Description] -2. **Feature 2**: [Description] -3. **Feature 3**: [Description] - -## Business Objectives -[What are the business goals this product aims to achieve?] - -- [Objective 1] -- [Objective 2] -- [Objective 3] - -## Success Metrics -[How will we measure the success of this product?] - -- [Metric 1]: [Target] -- [Metric 2]: [Target] -- [Metric 3]: [Target] - -## Product Principles -[Core principles that guide product decisions] - -1. **[Principle 1]**: [Explanation] -2. **[Principle 2]**: [Explanation] -3. **[Principle 3]**: [Explanation] - -## Monitoring & Visibility (if applicable) -[How do users track progress and monitor the system?] - -- **Dashboard Type**: [e.g., Web-based, CLI, Desktop app] -- **Real-time Updates**: [e.g., WebSocket, polling, push notifications] -- **Key Metrics Displayed**: [What information is most important to surface] -- **Sharing Capabilities**: [e.g., read-only links, exports, reports] - -## Future Vision -[Where do we see this product evolving in the future?] - -### Potential Enhancements -- **Remote Access**: [e.g., Tunnel features for sharing dashboards with stakeholders] -- **Analytics**: [e.g., Historical trends, performance metrics] -- **Collaboration**: [e.g., Multi-user support, commenting] diff --git a/.spec-workflow/templates/requirements-template.md b/.spec-workflow/templates/requirements-template.md deleted file mode 100644 index 1c80ca0..0000000 --- a/.spec-workflow/templates/requirements-template.md +++ /dev/null @@ -1,50 +0,0 @@ -# Requirements Document - -## Introduction - -[Provide a brief overview of the feature, its purpose, and its value to users] - -## Alignment with Product Vision - -[Explain how this feature supports the goals outlined in product.md] - -## Requirements - -### Requirement 1 - -**User Story:** As a [role], I want [feature], so that [benefit] - -#### Acceptance Criteria - -1. WHEN [event] THEN [system] SHALL [response] -2. IF [precondition] THEN [system] SHALL [response] -3. WHEN [event] AND [condition] THEN [system] SHALL [response] - -### Requirement 2 - -**User Story:** As a [role], I want [feature], so that [benefit] - -#### Acceptance Criteria - -1. WHEN [event] THEN [system] SHALL [response] -2. IF [precondition] THEN [system] SHALL [response] - -## Non-Functional Requirements - -### Code Architecture and Modularity -- **Single Responsibility Principle**: Each file should have a single, well-defined purpose -- **Modular Design**: Components, utilities, and services should be isolated and reusable -- **Dependency Management**: Minimize interdependencies between modules -- **Clear Interfaces**: Define clean contracts between components and layers - -### Performance -- [Performance requirements] - -### Security -- [Security requirements] - -### Reliability -- [Reliability requirements] - -### Usability -- [Usability requirements] diff --git a/.spec-workflow/templates/structure-template.md b/.spec-workflow/templates/structure-template.md deleted file mode 100644 index 1ab1fbc..0000000 --- a/.spec-workflow/templates/structure-template.md +++ /dev/null @@ -1,145 +0,0 @@ -# Project Structure - -## Directory Organization - -``` -[Define your project's directory structure. Examples below - adapt to your project type] - -Example for a library/package: -project-root/ -├── src/ # Source code -├── tests/ # Test files -├── docs/ # Documentation -├── examples/ # Usage examples -└── [build/dist/out] # Build output - -Example for an application: -project-root/ -├── [src/app/lib] # Main source code -├── [assets/resources] # Static resources -├── [config/settings] # Configuration -├── [scripts/tools] # Build/utility scripts -└── [tests/spec] # Test files - -Common patterns: -- Group by feature/module -- Group by layer (UI, business logic, data) -- Group by type (models, controllers, views) -- Flat structure for simple projects -``` - -## Naming Conventions - -### Files -- **Components/Modules**: [e.g., `PascalCase`, `snake_case`, `kebab-case`] -- **Services/Handlers**: [e.g., `UserService`, `user_service`, `user-service`] -- **Utilities/Helpers**: [e.g., `dateUtils`, `date_utils`, `date-utils`] -- **Tests**: [e.g., `[filename]_test`, `[filename].test`, `[filename]Test`] - -### Code -- **Classes/Types**: [e.g., `PascalCase`, `CamelCase`, `snake_case`] -- **Functions/Methods**: [e.g., `camelCase`, `snake_case`, `PascalCase`] -- **Constants**: [e.g., `UPPER_SNAKE_CASE`, `SCREAMING_CASE`, `PascalCase`] -- **Variables**: [e.g., `camelCase`, `snake_case`, `lowercase`] - -## Import Patterns - -### Import Order -1. External dependencies -2. Internal modules -3. Relative imports -4. Style imports - -### Module/Package Organization -``` -[Describe your project's import/include patterns] -Examples: -- Absolute imports from project root -- Relative imports within modules -- Package/namespace organization -- Dependency management approach -``` - -## Code Structure Patterns - -[Define common patterns for organizing code within files. Below are examples - choose what applies to your project] - -### Module/Class Organization -``` -Example patterns: -1. Imports/includes/dependencies -2. Constants and configuration -3. Type/interface definitions -4. Main implementation -5. Helper/utility functions -6. Exports/public API -``` - -### Function/Method Organization -``` -Example patterns: -- Input validation first -- Core logic in the middle -- Error handling throughout -- Clear return points -``` - -### File Organization Principles -``` -Choose what works for your project: -- One class/module per file -- Related functionality grouped together -- Public API at the top/bottom -- Implementation details hidden -``` - -## Code Organization Principles - -1. **Single Responsibility**: Each file should have one clear purpose -2. **Modularity**: Code should be organized into reusable modules -3. **Testability**: Structure code to be easily testable -4. **Consistency**: Follow patterns established in the codebase - -## Module Boundaries -[Define how different parts of your project interact and maintain separation of concerns] - -Examples of boundary patterns: -- **Core vs Plugins**: Core functionality vs extensible plugins -- **Public API vs Internal**: What's exposed vs implementation details -- **Platform-specific vs Cross-platform**: OS-specific code isolation -- **Stable vs Experimental**: Production code vs experimental features -- **Dependencies direction**: Which modules can depend on which - -## Code Size Guidelines -[Define your project's guidelines for file and function sizes] - -Suggested guidelines: -- **File size**: [Define maximum lines per file] -- **Function/Method size**: [Define maximum lines per function] -- **Class/Module complexity**: [Define complexity limits] -- **Nesting depth**: [Maximum nesting levels] - -## Dashboard/Monitoring Structure (if applicable) -[How dashboard or monitoring components are organized] - -### Example Structure: -``` -src/ -└── dashboard/ # Self-contained dashboard subsystem - ├── server/ # Backend server components - ├── client/ # Frontend assets - ├── shared/ # Shared types/utilities - └── public/ # Static assets -``` - -### Separation of Concerns -- Dashboard isolated from core business logic -- Own CLI entry point for independent operation -- Minimal dependencies on main application -- Can be disabled without affecting core functionality - -## Documentation Standards -- All public APIs must have documentation -- Complex logic should include inline comments -- README files for major modules -- Follow language-specific documentation conventions diff --git a/.spec-workflow/templates/tasks-template.md b/.spec-workflow/templates/tasks-template.md deleted file mode 100644 index be461de..0000000 --- a/.spec-workflow/templates/tasks-template.md +++ /dev/null @@ -1,139 +0,0 @@ -# Tasks Document - -- [ ] 1. Create core interfaces in src/types/feature.ts - - File: src/types/feature.ts - - Define TypeScript interfaces for feature data structures - - Extend existing base interfaces from base.ts - - Purpose: Establish type safety for feature implementation - - _Leverage: src/types/base.ts_ - - _Requirements: 1.1_ - - _Prompt: Role: TypeScript Developer specializing in type systems and interfaces | Task: Create comprehensive TypeScript interfaces for the feature data structures following requirements 1.1, extending existing base interfaces from src/types/base.ts | Restrictions: Do not modify existing base interfaces, maintain backward compatibility, follow project naming conventions | Success: All interfaces compile without errors, proper inheritance from base types, full type coverage for feature requirements_ - -- [ ] 2. Create base model class in src/models/FeatureModel.ts - - File: src/models/FeatureModel.ts - - Implement base model extending BaseModel class - - Add validation methods using existing validation utilities - - Purpose: Provide data layer foundation for feature - - _Leverage: src/models/BaseModel.ts, src/utils/validation.ts_ - - _Requirements: 2.1_ - - _Prompt: Role: Backend Developer with expertise in Node.js and data modeling | Task: Create a base model class extending BaseModel and implementing validation following requirement 2.1, leveraging existing patterns from src/models/BaseModel.ts and src/utils/validation.ts | Restrictions: Must follow existing model patterns, do not bypass validation utilities, maintain consistent error handling | Success: Model extends BaseModel correctly, validation methods implemented and tested, follows project architecture patterns_ - -- [ ] 3. Add specific model methods to FeatureModel.ts - - File: src/models/FeatureModel.ts (continue from task 2) - - Implement create, update, delete methods - - Add relationship handling for foreign keys - - Purpose: Complete model functionality for CRUD operations - - _Leverage: src/models/BaseModel.ts_ - - _Requirements: 2.2, 2.3_ - - _Prompt: Role: Backend Developer with expertise in ORM and database operations | Task: Implement CRUD methods and relationship handling in FeatureModel.ts following requirements 2.2 and 2.3, extending patterns from src/models/BaseModel.ts | Restrictions: Must maintain transaction integrity, follow existing relationship patterns, do not duplicate base model functionality | Success: All CRUD operations work correctly, relationships are properly handled, database operations are atomic and efficient_ - -- [ ] 4. Create model unit tests in tests/models/FeatureModel.test.ts - - File: tests/models/FeatureModel.test.ts - - Write tests for model validation and CRUD methods - - Use existing test utilities and fixtures - - Purpose: Ensure model reliability and catch regressions - - _Leverage: tests/helpers/testUtils.ts, tests/fixtures/data.ts_ - - _Requirements: 2.1, 2.2_ - - _Prompt: Role: QA Engineer with expertise in unit testing and Jest/Mocha frameworks | Task: Create comprehensive unit tests for FeatureModel validation and CRUD methods covering requirements 2.1 and 2.2, using existing test utilities from tests/helpers/testUtils.ts and fixtures from tests/fixtures/data.ts | Restrictions: Must test both success and failure scenarios, do not test external dependencies directly, maintain test isolation | Success: All model methods are tested with good coverage, edge cases covered, tests run independently and consistently_ - -- [ ] 5. Create service interface in src/services/IFeatureService.ts - - File: src/services/IFeatureService.ts - - Define service contract with method signatures - - Extend base service interface patterns - - Purpose: Establish service layer contract for dependency injection - - _Leverage: src/services/IBaseService.ts_ - - _Requirements: 3.1_ - - _Prompt: Role: Software Architect specializing in service-oriented architecture and TypeScript interfaces | Task: Design service interface contract following requirement 3.1, extending base service patterns from src/services/IBaseService.ts for dependency injection | Restrictions: Must maintain interface segregation principle, do not expose internal implementation details, ensure contract compatibility with DI container | Success: Interface is well-defined with clear method signatures, extends base service appropriately, supports all required service operations_ - -- [ ] 6. Implement feature service in src/services/FeatureService.ts - - File: src/services/FeatureService.ts - - Create concrete service implementation using FeatureModel - - Add error handling with existing error utilities - - Purpose: Provide business logic layer for feature operations - - _Leverage: src/services/BaseService.ts, src/utils/errorHandler.ts, src/models/FeatureModel.ts_ - - _Requirements: 3.2_ - - _Prompt: Role: Backend Developer with expertise in service layer architecture and business logic | Task: Implement concrete FeatureService following requirement 3.2, using FeatureModel and extending BaseService patterns with proper error handling from src/utils/errorHandler.ts | Restrictions: Must implement interface contract exactly, do not bypass model validation, maintain separation of concerns from data layer | Success: Service implements all interface methods correctly, robust error handling implemented, business logic is well-encapsulated and testable_ - -- [ ] 7. Add service dependency injection in src/utils/di.ts - - File: src/utils/di.ts (modify existing) - - Register FeatureService in dependency injection container - - Configure service lifetime and dependencies - - Purpose: Enable service injection throughout application - - _Leverage: existing DI configuration in src/utils/di.ts_ - - _Requirements: 3.1_ - - _Prompt: Role: DevOps Engineer with expertise in dependency injection and IoC containers | Task: Register FeatureService in DI container following requirement 3.1, configuring appropriate lifetime and dependencies using existing patterns from src/utils/di.ts | Restrictions: Must follow existing DI container patterns, do not create circular dependencies, maintain service resolution efficiency | Success: FeatureService is properly registered and resolvable, dependencies are correctly configured, service lifetime is appropriate for use case_ - -- [ ] 8. Create service unit tests in tests/services/FeatureService.test.ts - - File: tests/services/FeatureService.test.ts - - Write tests for service methods with mocked dependencies - - Test error handling scenarios - - Purpose: Ensure service reliability and proper error handling - - _Leverage: tests/helpers/testUtils.ts, tests/mocks/modelMocks.ts_ - - _Requirements: 3.2, 3.3_ - - _Prompt: Role: QA Engineer with expertise in service testing and mocking frameworks | Task: Create comprehensive unit tests for FeatureService methods covering requirements 3.2 and 3.3, using mocked dependencies from tests/mocks/modelMocks.ts and test utilities | Restrictions: Must mock all external dependencies, test business logic in isolation, do not test framework code | Success: All service methods tested with proper mocking, error scenarios covered, tests verify business logic correctness and error handling_ - -- [ ] 4. Create API endpoints - - Design API structure - - _Leverage: src/api/baseApi.ts, src/utils/apiUtils.ts_ - - _Requirements: 4.0_ - - _Prompt: Role: API Architect specializing in RESTful design and Express.js | Task: Design comprehensive API structure following requirement 4.0, leveraging existing patterns from src/api/baseApi.ts and utilities from src/utils/apiUtils.ts | Restrictions: Must follow REST conventions, maintain API versioning compatibility, do not expose internal data structures directly | Success: API structure is well-designed and documented, follows existing patterns, supports all required operations with proper HTTP methods and status codes_ - -- [ ] 4.1 Set up routing and middleware - - Configure application routes - - Add authentication middleware - - Set up error handling middleware - - _Leverage: src/middleware/auth.ts, src/middleware/errorHandler.ts_ - - _Requirements: 4.1_ - - _Prompt: Role: Backend Developer with expertise in Express.js middleware and routing | Task: Configure application routes and middleware following requirement 4.1, integrating authentication from src/middleware/auth.ts and error handling from src/middleware/errorHandler.ts | Restrictions: Must maintain middleware order, do not bypass security middleware, ensure proper error propagation | Success: Routes are properly configured with correct middleware chain, authentication works correctly, errors are handled gracefully throughout the request lifecycle_ - -- [ ] 4.2 Implement CRUD endpoints - - Create API endpoints - - Add request validation - - Write API integration tests - - _Leverage: src/controllers/BaseController.ts, src/utils/validation.ts_ - - _Requirements: 4.2, 4.3_ - - _Prompt: Role: Full-stack Developer with expertise in API development and validation | Task: Implement CRUD endpoints following requirements 4.2 and 4.3, extending BaseController patterns and using validation utilities from src/utils/validation.ts | Restrictions: Must validate all inputs, follow existing controller patterns, ensure proper HTTP status codes and responses | Success: All CRUD operations work correctly, request validation prevents invalid data, integration tests pass and cover all endpoints_ - -- [ ] 5. Add frontend components - - Plan component architecture - - _Leverage: src/components/BaseComponent.tsx, src/styles/theme.ts_ - - _Requirements: 5.0_ - - _Prompt: Role: Frontend Architect with expertise in React component design and architecture | Task: Plan comprehensive component architecture following requirement 5.0, leveraging base patterns from src/components/BaseComponent.tsx and theme system from src/styles/theme.ts | Restrictions: Must follow existing component patterns, maintain design system consistency, ensure component reusability | Success: Architecture is well-planned and documented, components are properly organized, follows existing patterns and theme system_ - -- [ ] 5.1 Create base UI components - - Set up component structure - - Implement reusable components - - Add styling and theming - - _Leverage: src/components/BaseComponent.tsx, src/styles/theme.ts_ - - _Requirements: 5.1_ - - _Prompt: Role: Frontend Developer specializing in React and component architecture | Task: Create reusable UI components following requirement 5.1, extending BaseComponent patterns and using existing theme system from src/styles/theme.ts | Restrictions: Must use existing theme variables, follow component composition patterns, ensure accessibility compliance | Success: Components are reusable and properly themed, follow existing architecture, accessible and responsive_ - -- [ ] 5.2 Implement feature-specific components - - Create feature components - - Add state management - - Connect to API endpoints - - _Leverage: src/hooks/useApi.ts, src/components/BaseComponent.tsx_ - - _Requirements: 5.2, 5.3_ - - _Prompt: Role: React Developer with expertise in state management and API integration | Task: Implement feature-specific components following requirements 5.2 and 5.3, using API hooks from src/hooks/useApi.ts and extending BaseComponent patterns | Restrictions: Must use existing state management patterns, handle loading and error states properly, maintain component performance | Success: Components are fully functional with proper state management, API integration works smoothly, user experience is responsive and intuitive_ - -- [ ] 6. Integration and testing - - Plan integration approach - - _Leverage: src/utils/integrationUtils.ts, tests/helpers/testUtils.ts_ - - _Requirements: 6.0_ - - _Prompt: Role: Integration Engineer with expertise in system integration and testing strategies | Task: Plan comprehensive integration approach following requirement 6.0, leveraging integration utilities from src/utils/integrationUtils.ts and test helpers | Restrictions: Must consider all system components, ensure proper test coverage, maintain integration test reliability | Success: Integration plan is comprehensive and feasible, all system components work together correctly, integration points are well-tested_ - -- [ ] 6.1 Write end-to-end tests - - Set up E2E testing framework - - Write user journey tests - - Add test automation - - _Leverage: tests/helpers/testUtils.ts, tests/fixtures/data.ts_ - - _Requirements: All_ - - _Prompt: Role: QA Automation Engineer with expertise in E2E testing and test frameworks like Cypress or Playwright | Task: Implement comprehensive end-to-end tests covering all requirements, setting up testing framework and user journey tests using test utilities and fixtures | Restrictions: Must test real user workflows, ensure tests are maintainable and reliable, do not test implementation details | Success: E2E tests cover all critical user journeys, tests run reliably in CI/CD pipeline, user experience is validated from end-to-end_ - -- [ ] 6.2 Final integration and cleanup - - Integrate all components - - Fix any integration issues - - Clean up code and documentation - - _Leverage: src/utils/cleanup.ts, docs/templates/_ - - _Requirements: All_ - - _Prompt: Role: Senior Developer with expertise in code quality and system integration | Task: Complete final integration of all components and perform comprehensive cleanup covering all requirements, using cleanup utilities and documentation templates | Restrictions: Must not break existing functionality, ensure code quality standards are met, maintain documentation consistency | Success: All components are fully integrated and working together, code is clean and well-documented, system meets all requirements and quality standards_ diff --git a/.spec-workflow/templates/tech-template.md b/.spec-workflow/templates/tech-template.md deleted file mode 100644 index 57cd538..0000000 --- a/.spec-workflow/templates/tech-template.md +++ /dev/null @@ -1,99 +0,0 @@ -# Technology Stack - -## Project Type -[Describe what kind of project this is: web application, CLI tool, desktop application, mobile app, library, API service, embedded system, game, etc.] - -## Core Technologies - -### Primary Language(s) -- **Language**: [e.g., Python 3.11, Go 1.21, TypeScript, Rust, C++] -- **Runtime/Compiler**: [if applicable] -- **Language-specific tools**: [package managers, build tools, etc.] - -### Key Dependencies/Libraries -[List the main libraries and frameworks your project depends on] -- **[Library/Framework name]**: [Purpose and version] -- **[Library/Framework name]**: [Purpose and version] - -### Application Architecture -[Describe how your application is structured - this could be MVC, event-driven, plugin-based, client-server, standalone, microservices, monolithic, etc.] - -### Data Storage (if applicable) -- **Primary storage**: [e.g., PostgreSQL, files, in-memory, cloud storage] -- **Caching**: [e.g., Redis, in-memory, disk cache] -- **Data formats**: [e.g., JSON, Protocol Buffers, XML, binary] - -### External Integrations (if applicable) -- **APIs**: [External services you integrate with] -- **Protocols**: [e.g., HTTP/REST, gRPC, WebSocket, TCP/IP] -- **Authentication**: [e.g., OAuth, API keys, certificates] - -### Monitoring & Dashboard Technologies (if applicable) -- **Dashboard Framework**: [e.g., React, Vue, vanilla JS, terminal UI] -- **Real-time Communication**: [e.g., WebSocket, Server-Sent Events, polling] -- **Visualization Libraries**: [e.g., Chart.js, D3, terminal graphs] -- **State Management**: [e.g., Redux, Vuex, file system as source of truth] - -## Development Environment - -### Build & Development Tools -- **Build System**: [e.g., Make, CMake, Gradle, npm scripts, cargo] -- **Package Management**: [e.g., pip, npm, cargo, go mod, apt, brew] -- **Development workflow**: [e.g., hot reload, watch mode, REPL] - -### Code Quality Tools -- **Static Analysis**: [Tools for code quality and correctness] -- **Formatting**: [Code style enforcement tools] -- **Testing Framework**: [Unit, integration, and/or end-to-end testing tools] -- **Documentation**: [Documentation generation tools] - -### Version Control & Collaboration -- **VCS**: [e.g., Git, Mercurial, SVN] -- **Branching Strategy**: [e.g., Git Flow, GitHub Flow, trunk-based] -- **Code Review Process**: [How code reviews are conducted] - -### Dashboard Development (if applicable) -- **Live Reload**: [e.g., Hot module replacement, file watchers] -- **Port Management**: [e.g., Dynamic allocation, configurable ports] -- **Multi-Instance Support**: [e.g., Running multiple dashboards simultaneously] - -## Deployment & Distribution (if applicable) -- **Target Platform(s)**: [Where/how the project runs: cloud, on-premise, desktop, mobile, embedded] -- **Distribution Method**: [How users get your software: download, package manager, app store, SaaS] -- **Installation Requirements**: [Prerequisites, system requirements] -- **Update Mechanism**: [How updates are delivered] - -## Technical Requirements & Constraints - -### Performance Requirements -- [e.g., response time, throughput, memory usage, startup time] -- [Specific benchmarks or targets] - -### Compatibility Requirements -- **Platform Support**: [Operating systems, architectures, versions] -- **Dependency Versions**: [Minimum/maximum versions of dependencies] -- **Standards Compliance**: [Industry standards, protocols, specifications] - -### Security & Compliance -- **Security Requirements**: [Authentication, encryption, data protection] -- **Compliance Standards**: [GDPR, HIPAA, SOC2, etc. if applicable] -- **Threat Model**: [Key security considerations] - -### Scalability & Reliability -- **Expected Load**: [Users, requests, data volume] -- **Availability Requirements**: [Uptime targets, disaster recovery] -- **Growth Projections**: [How the system needs to scale] - -## Technical Decisions & Rationale -[Document key architectural and technology choices] - -### Decision Log -1. **[Technology/Pattern Choice]**: [Why this was chosen, alternatives considered] -2. **[Architecture Decision]**: [Rationale, trade-offs accepted] -3. **[Tool/Library Selection]**: [Reasoning, evaluation criteria] - -## Known Limitations -[Document any technical debt, limitations, or areas for improvement] - -- [Limitation 1]: [Impact and potential future solutions] -- [Limitation 2]: [Why it exists and when it might be addressed] diff --git a/.spec-workflow/user-templates/README.md b/.spec-workflow/user-templates/README.md deleted file mode 100644 index ad36a48..0000000 --- a/.spec-workflow/user-templates/README.md +++ /dev/null @@ -1,64 +0,0 @@ -# User Templates - -This directory allows you to create custom templates that override the default Spec Workflow templates. - -## How to Use Custom Templates - -1. **Create your custom template file** in this directory with the exact same name as the default template you want to override: - - `requirements-template.md` - Override requirements document template - - `design-template.md` - Override design document template - - `tasks-template.md` - Override tasks document template - - `product-template.md` - Override product steering template - - `tech-template.md` - Override tech steering template - - `structure-template.md` - Override structure steering template - -2. **Template Loading Priority**: - - The system first checks this `user-templates/` directory - - If a matching template is found here, it will be used - - Otherwise, the default template from `templates/` will be used - -## Example Custom Template - -To create a custom requirements template: - -1. Create a file named `requirements-template.md` in this directory -2. Add your custom structure, for example: - -```markdown -# Requirements Document - -## Executive Summary -[Your custom section] - -## Business Requirements -[Your custom structure] - -## Technical Requirements -[Your custom fields] - -## Custom Sections -[Add any sections specific to your workflow] -``` - -## Template Variables - -Templates can include placeholders that will be replaced when documents are created: -- `{{projectName}}` - The name of your project -- `{{featureName}}` - The name of the feature being specified -- `{{date}}` - The current date -- `{{author}}` - The document author - -## Best Practices - -1. **Start from defaults**: Copy a default template from `../templates/` as a starting point -2. **Keep structure consistent**: Maintain similar section headers for tool compatibility -3. **Document changes**: Add comments explaining why sections were added/modified -4. **Version control**: Track your custom templates in version control -5. **Test thoroughly**: Ensure custom templates work with the spec workflow tools - -## Notes - -- Custom templates are project-specific and not included in the package distribution -- The `templates/` directory contains the default templates which are updated with each version -- Your custom templates in this directory are preserved during updates -- If a custom template has errors, the system will fall back to the default template