- Add comprehensive gitea facade tests (35 tests covering all functionality) - Remove direct gitea integration tests from tddai/markitect modules - Maintain 100% test coverage while eliminating direct API testing - Achieve 324/324 passing tests confirming no functionality loss - Complete consolidation strategy from GITEA_INTEGRATION_CONSOLIDATION_GAMEPLAN.md 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
96 lines
4.4 KiB
Plaintext
96 lines
4.4 KiB
Plaintext
# Enhancement: Extract TDDAI/TDD8 into Independent Repository
|
|
|
|
## Summary
|
|
The Test-Driven Development AI (TDDAI) implementation with TDD8 methodology has evolved into a comprehensive, standalone capability that should be separated into its own repository for independent development and reuse.
|
|
|
|
## Current State Analysis
|
|
The TDDAI domain currently includes:
|
|
- **TDD8 Methodology Framework**: Complete 8-phase test-driven development workflow (ISSUE-TEST-RED-GREEN-REFACTOR-DOCUMENT-REFINE-PUBLISH)
|
|
- **Automated Test Generation**: AI-driven test case creation from requirements
|
|
- **Workspace Management**: Issue-based development workspace lifecycle
|
|
- **Coverage Analysis**: Test coverage gaps and optimization recommendations
|
|
- **CLI Integration**: tddai_cli.py with comprehensive workflow commands
|
|
- **Domain Models**: Issues, projects, milestones, and workflow state management
|
|
|
|
## Affected Components
|
|
**Files to Extract:**
|
|
- /tddai/ - Complete TDDAI library implementation
|
|
- tddai_cli.py - TDD workflow CLI interface
|
|
- /domain/issues/ - Issue domain models and services
|
|
- /domain/projects/ - Project management domain
|
|
- /tests/test_issue_11_* - TDD workflow integration tests
|
|
- /tests/unit/domain/ - Domain-specific unit tests
|
|
|
|
**Dependencies to Resolve:**
|
|
- Gitea integration (will be handled in separate spin-out)
|
|
- Configuration management (extract relevant portions)
|
|
- Logging infrastructure (duplicate or create shared dependency)
|
|
|
|
## Benefits of Extraction
|
|
|
|
### 1. Independent Development Lifecycle
|
|
- TDDAI can evolve with its own versioning and release cycles
|
|
- Specialized development team can focus on TDD methodology innovation
|
|
- Cleaner dependency management and testing
|
|
|
|
### 2. Broader Ecosystem Adoption
|
|
- Other projects can adopt TDDAI without markdown processing overhead
|
|
- Potential for integration with various IDE plugins and development tools
|
|
- Community contributions focused on TDD methodology improvements
|
|
|
|
### 3. Architectural Clarity
|
|
- MarkiTect focuses purely on markdown processing and data management
|
|
- Clear separation of concerns between document processing and development workflow
|
|
- Reduced complexity in both repositories
|
|
|
|
### 4. Reusability and Distribution
|
|
- TDDAI becomes a standalone Python package
|
|
- Can be published to PyPI for wider distribution
|
|
- Integration as dependency rather than embedded code
|
|
|
|
## Implementation Strategy
|
|
|
|
### Phase 1: Repository Setup and Code Migration
|
|
1. Create new repository: tddai-framework or tdd8-methodology
|
|
2. Extract core TDDAI code with full git history preservation
|
|
3. Establish independent CI/CD pipeline with comprehensive testing
|
|
4. Create proper package structure with setup.py/pyproject.toml
|
|
|
|
### Phase 2: Dependency Resolution
|
|
1. Identify shared dependencies between TDDAI and MarkiTect
|
|
2. Extract configuration management specific to TDDAI needs
|
|
3. Resolve Gitea integration (coordinate with Gitea spin-out issue)
|
|
4. Create abstraction layer for issue tracking system integration
|
|
|
|
### Phase 3: Integration and Migration
|
|
1. Modify MarkiTect to use TDDAI as external dependency
|
|
2. Update build and deployment processes for both repositories
|
|
3. Migrate documentation and setup guides
|
|
4. Validate full workflow end-to-end testing
|
|
|
|
### Phase 4: Publication and Distribution
|
|
1. Publish TDDAI package to PyPI
|
|
2. Create comprehensive documentation site
|
|
3. Establish community guidelines and contribution processes
|
|
4. Marketing and ecosystem outreach
|
|
|
|
## Success Criteria
|
|
- TDDAI operates independently with full TDD8 workflow capability
|
|
- MarkiTect integrates TDDAI as external dependency without functionality loss
|
|
- All existing tests pass in both repositories
|
|
- Documentation is complete and comprehensive
|
|
- CI/CD pipelines are established and functional
|
|
- Performance characteristics are maintained or improved
|
|
|
|
## Risk Mitigation
|
|
- Dependency Complexity: Create detailed dependency mapping before extraction
|
|
- Workflow Disruption: Maintain parallel development during transition period
|
|
- Integration Issues: Comprehensive integration testing between repositories
|
|
- Documentation Gaps: Parallel documentation development during code migration
|
|
|
|
## Estimated Effort
|
|
- Complexity: High (significant architectural separation)
|
|
- Duration: 2-3 weeks for complete extraction and validation
|
|
- Resources: Senior developer familiar with both domains
|
|
|
|
This enhancement will position TDDAI as a valuable standalone tool in the development ecosystem while allowing MarkiTect to focus on its core markdown processing capabilities. |