3 Commits

Author SHA1 Message Date
e84eb08dc5 feat: Complete TestDrive-JSUI migration - Main app now uses capability
Some checks failed
Test Suite / unit-tests (3.11) (push) Has been cancelled
Test Suite / unit-tests (3.12) (push) Has been cancelled
Test Suite / integration-tests (push) Has been cancelled
Test Suite / e2e-tests (push) Has been cancelled
Test Suite / performance-tests (push) Has been cancelled
Test Suite / code-quality (push) Has been cancelled
Test Suite / security-scan (push) Has been cancelled
Test Suite / test-summary (push) Has been cancelled
Phase 3 Complete: Updated templates to use capability location exclusively

Changes:
- Update document.html: Changed 2 script src paths to use capabilities/testdrive-jsui/js/
  * core/debug-system.js → capability location
  * main.js → capability location

- Update edit-mode-fixed.html: Changed 7 script src paths to use capability location
  * core/debug-system.js, section-manager.js → capability
  * components/debug-panel.js, dom-renderer.js → capability
  * config-loader.js, main-updated.js → capability

- Update testdrive-jsui submodule to include Phase 1 & 3 migration

Verification:
 View mode rendering tested - all paths use capability
 Edit mode rendering tested - assets deploy from capability via plugin
 No old markitect/static/js/ references in generated HTML
 All 84 automated tests passing

Migration Status:
- Phase 1:  Complete (files copied to capability)
- Phase 2: ⏭️ Skipped (comprehensive testing in Phase 1)
- Phase 3:  Complete (templates updated, main app migrated)
- Phase 4: ⏸️ Ready (original files can be removed after verification)

Impact:
- Main MarkiTect app now exclusively uses capability for JavaScript UI
- Original files in /markitect/static/js/ preserved for rollback safety
- No breaking changes - all rendering modes work correctly

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-12-16 10:20:14 +01:00
0e568ce623 docs: add comprehensive architecture assessment and fix dependencies
Some checks failed
Test Suite / unit-tests (3.11) (push) Has been cancelled
Test Suite / unit-tests (3.12) (push) Has been cancelled
Test Suite / integration-tests (push) Has been cancelled
Test Suite / e2e-tests (push) Has been cancelled
Test Suite / performance-tests (push) Has been cancelled
Test Suite / code-quality (push) Has been cancelled
Test Suite / security-scan (push) Has been cancelled
Test Suite / test-summary (push) Has been cancelled
Created comprehensive architectural assessment (20251216):
- Evaluated capabilities-based architecture alignment
- Assessed plugin system (Grade: A+)
- Analyzed dependency management (identified gaps)
- Documented strengths and issues
- Provided prioritized recommendations

Fixed missing capability dependencies in pyproject.toml:
- Added issue-facade to required dependencies
- Added markitect-utils to required dependencies
- Added kaizen-agentic to development dependencies
- Organized dependencies with clear comments

Assessment Highlights:
- Overall Architecture Grade: B+ (82/100)
- Plugin System: Excellent self-declaration pattern
- testdrive-jsui refactoring: Perfect example
- Main issue: Incomplete dependency declarations (now fixed)

Next Steps (per assessment):
1.  Fix dependency management (completed in this commit)
2. Test fresh installation
3. Complete submodule migration for local capabilities
4. Document capability roles and usage

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-12-16 00:27:32 +01:00
aa0ac626c5 docs: add comprehensive capabilities architecture documentation
Created detailed documentation for capabilities concept and integration:
- CAPABILITIES_ARCHITECTURE.md: Full guide on separation of concerns
- CAPABILITIES_QUICK_REFERENCE.md: Quick reference for common tasks
- Updated docs/README.md to reference new documentation

Ensures future sessions respect capability boundaries and use separate
Claude instances for capability development.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-12-16 00:15:57 +01:00
8 changed files with 1747 additions and 13 deletions

View File

@@ -0,0 +1,184 @@
# Capabilities Quick Reference
**⚠️ Critical:** Read [Capabilities Architecture](architecture/CAPABILITIES_ARCHITECTURE.md) for full details.
## Core Rules
### 🚫 **NEVER** Edit Capabilities from Main Repo
```bash
# ❌ WRONG - Don't edit capability files from main repo
cd /home/worsch/markitect_project/capabilities/testdrive-jsui
vim src/testdrive_jsui/core.py # DON'T DO THIS!
# ✅ CORRECT - Use separate Claude instance/session
# Open new terminal/Claude instance:
git clone http://gitea/coulomb/testdrive-jsui.git /path/to/work
cd /path/to/work/testdrive-jsui
# Make changes, commit, push
```
### 📦 Capabilities are Git Submodules
- Each capability = separate git repository
- Located in `capabilities/` as submodules
- Independent development lifecycle
- Own versioning and releases
### 🔀 Use Separate Claude Instances
| Session | Purpose | Location |
|---------|---------|----------|
| **Main Repo** | Integration, configuration | `/home/worsch/markitect_project` |
| **Capability** | Feature development, bugs | Separate clone or `capabilities/capability-name` |
**Why?** Prevents accidental cross-contamination and respects repository boundaries.
## Common Tasks
### Update Capability After Changes
```bash
# After pushing changes to capability repo
cd /home/worsch/markitect_project
git submodule update --remote capabilities/testdrive-jsui
git add capabilities/testdrive-jsui
git commit -m "chore: update testdrive-jsui to latest"
git push
```
### Add New Capability
```bash
cd /home/worsch/markitect_project
# Add as submodule
git submodule add http://gitea/coulomb/new-capability.git capabilities/new-capability
# Add to pyproject.toml dependencies
echo ' "new-capability @ file:./capabilities/new-capability",' >> pyproject.toml
# Commit
git add .gitmodules capabilities/new-capability pyproject.toml
git commit -m "feat: add new-capability submodule"
```
### Work on Capability Feature
```bash
# Option 1: In submodule directory (careful!)
cd /home/worsch/markitect_project/capabilities/testdrive-jsui
git checkout -b feature-branch
# make changes
git commit -m "feat: new feature"
git push origin feature-branch
# Option 2: Separate clone (recommended)
cd ~/projects
git clone http://gitea/coulomb/testdrive-jsui.git
cd testdrive-jsui
git checkout -b feature-branch
# make changes
git commit -m "feat: new feature"
git push origin feature-branch
```
### Check Capability Status
```bash
cd /home/worsch/markitect_project
# List all capabilities
make capabilities-list
# Check submodule status
git submodule status
# See which commit each capability is at
git submodule foreach 'git log --oneline -1'
```
## Integration Patterns
### Python Import
```python
# ✅ Correct - Import from capability package
from testdrive_jsui import TestDriveJSUIEngine
engine = TestDriveJSUIEngine()
```
### Dependency Declaration
```toml
# pyproject.toml
dependencies = [
"testdrive-jsui @ file:./capabilities/testdrive-jsui",
]
```
### Plugin Self-Declaration
```python
# ✅ Good - Plugin declares its own location
def get_plugin_source_dir(self) -> Path:
return Path(__file__).parent.parent.parent / "capabilities" / "testdrive-jsui"
# ❌ Bad - Hardcoded in main repo
if plugin_name == 'testdrive-jsui':
return Path('capabilities/testdrive-jsui')
```
## Troubleshooting
### "Submodule not initialized"
```bash
git submodule update --init --recursive
```
### "Import error: No module named 'capability_name'"
```bash
pip install -e ./capabilities/capability-name
# or
pip install -e . # Install all dependencies
```
### "Merge conflict in submodule"
```bash
# Don't resolve in main repo!
# Go to capability repo and resolve there
cd capabilities/testdrive-jsui
git pull origin main
# Resolve conflicts, commit, push
cd ../..
git submodule update --remote capabilities/testdrive-jsui
git add capabilities/testdrive-jsui
git commit -m "chore: update testdrive-jsui after conflict resolution"
```
## Current Capabilities
| Capability | Type | Repository | Status |
|------------|------|------------|--------|
| **testdrive-jsui** | Rendering Engine | `coulomb/testdrive-jsui` | ✅ Submodule |
| **issue-facade** | CLI Tool | `coulomb/issue-facade` | ✅ Submodule |
| **kaizen-agentic** | Framework | `coulomb/kaizen-agentic` | ✅ Submodule |
| **release-management** | Tool | Local | 📦 To migrate |
| **markitect-content** | Library | Local | 📦 To migrate |
## Key Principles
1. **Separation of Concerns** - Main repo doesn't modify capabilities
2. **Independent Development** - Each capability has own lifecycle
3. **Interface-Based Integration** - Use documented APIs only
4. **Version Control** - Git submodules for dependency management
5. **Session Isolation** - Separate Claude instances per repository
---
**📖 Full Documentation:** [Capabilities Architecture](architecture/CAPABILITIES_ARCHITECTURE.md)

View File

@@ -7,8 +7,9 @@ Welcome to the MarkiTect documentation. This directory contains comprehensive do
### 📐 Architecture Documentation (`architecture/`)
Deep technical documentation about system design, performance, and implementation details.
- **[Capabilities Architecture](architecture/CAPABILITIES_ARCHITECTURE.md)** - **Critical:** How capabilities work as independent git submodules and separation of concerns
- **[Caching System](architecture/caching-system.md)** - Why and how MarkiTect's AST caching delivers 60-85% performance improvements
- *Coming soon: Database Schema, CLI Architecture, Plugin System*
- *Coming soon: Database Schema, CLI Architecture*
### 👥 User Guides (`user-guides/`)
End-user documentation for working with MarkiTect CLI and features.

View File

@@ -0,0 +1,453 @@
# Capabilities Architecture
## Overview
MarkiTect uses a **capabilities-based architecture** where functionality is organized into independent, reusable packages called **capabilities**. Each capability is a self-contained git submodule with its own repository, enabling independent development, versioning, and reuse across projects.
## Core Principles
### 1. **Separation of Concerns**
**Critical Rule:** The main repository (`markitect_project`) **MUST NOT** directly modify capability code.
-**DO**: Use capabilities as dependencies
-**DO**: Configure capabilities through documented interfaces
-**DO**: Report issues and feature requests to capability repos
-**DON'T**: Edit capability code from the main repo
-**DON'T**: Make commits directly in capability subdirectories
-**DON'T**: Bypass the submodule boundary
**Why?** Capabilities are independent repositories. Direct modifications create:
- Merge conflicts when syncing with upstream
- Broken dependency management
- Loss of independent versioning
- Confusion about source of truth
### 2. **Git Submodule Architecture**
Capabilities are integrated as **git submodules**, not regular directories:
```
markitect_project/
├── .gitmodules # Submodule configuration
├── capabilities/
│ ├── testdrive-jsui/ # Git submodule → separate repo
│ ├── issue-facade/ # Git submodule → separate repo
│ ├── kaizen-agentic/ # Git submodule → separate repo
│ ├── markitect-content/ # Local capability (legacy)
│ └── release-management/ # Local capability (legacy)
```
**Submodule vs Local Capabilities:**
- **Submodules**: Independent git repositories, separate development lifecycle
- **Local**: Part of main repo, shared lifecycle (being phased out)
**Target State:** All capabilities should eventually be submodules.
### 3. **Independent Development Lifecycle**
Each capability has its own:
- ✅ Git repository on gitea
- ✅ Version numbering (semantic versioning)
- ✅ Issue tracking and roadmap
- ✅ Testing and CI/CD pipeline
- ✅ Documentation and README
- ✅ Contributors and maintainers
### 4. **Interface-Based Integration**
Capabilities expose **stable interfaces** to the main project:
```python
# markitect uses capability through documented interface
from testdrive_jsui import TestDriveJSUIEngine
engine = TestDriveJSUIEngine()
engine.render_document(content, mode='edit', config=config)
```
**Integration Points:**
1. **Python Package Interface**: Clean import and API
2. **Configuration**: Via `pyproject.toml` dependencies
3. **Plugin System**: Via plugin registration and metadata
4. **Makefile Targets**: Via capability discovery system
## Development Workflow
### Working on Capabilities
**Rule:** Each capability is developed in **its own Claude Code session**.
#### Main Repository Session
```bash
# In markitect_project/
cd /home/worsch/markitect_project
# Main repo tasks:
# - Integrate capabilities
# - Update dependencies
# - Configure capability usage
# - Test integration points
```
#### Capability Session
```bash
# In capability repository
cd /home/worsch/markitect_project/capabilities/testdrive-jsui
# OR clone separately
git clone http://gitea/coulomb/testdrive-jsui.git
cd testdrive-jsui
# Capability tasks:
# - Implement features
# - Fix bugs
# - Write tests
# - Update documentation
# - Make releases
```
### Recommended Session Pattern
**Scenario: Need to add feature to testdrive-jsui**
1. **Open separate Claude instance** for testdrive-jsui
```bash
# In new terminal/session
cd /path/to/testdrive-jsui
# Work on feature
git commit -m "feat: new feature"
git push origin main
```
2. **Update main project** (different Claude instance)
```bash
cd /home/worsch/markitect_project
git submodule update --remote capabilities/testdrive-jsui
git commit -m "chore: update testdrive-jsui submodule"
```
**Why separate instances?**
- Clear context boundaries
- Prevents accidental cross-contamination
- Respects repository independence
- Better commit hygiene
### Updating Submodules
When a capability releases a new version:
```bash
# In main repo
cd /home/worsch/markitect_project
# Update specific capability
cd capabilities/testdrive-jsui
git pull origin main
cd ../..
git add capabilities/testdrive-jsui
git commit -m "chore: update testdrive-jsui to v1.2.0"
# Or update all capabilities
git submodule update --remote
git commit -am "chore: update all capabilities"
```
### Adding New Capabilities
```bash
# 1. Create capability repository on gitea
# http://gitea/coulomb/new-capability
# 2. Add as submodule to main repo
cd /home/worsch/markitect_project
git submodule add http://gitea/coulomb/new-capability.git capabilities/new-capability
# 3. Add dependency to pyproject.toml
# dependencies = [
# "new-capability @ file:./capabilities/new-capability"
# ]
# 4. Commit submodule addition
git commit -m "feat: add new-capability as submodule"
```
## Dependency Management
Capabilities are declared in `pyproject.toml`:
```toml
[project]
dependencies = [
# Core dependencies
"markdown-it-py",
"click>=8.0.0",
# Capabilities (file-based dependencies)
"release-management @ file:./capabilities/release-management",
"testdrive-jsui @ file:./capabilities/testdrive-jsui",
"issue-facade @ file:./capabilities/issue-facade",
]
```
**Pattern for Capabilities:**
```toml
"capability-name @ file:./capabilities/capability-name"
```
This enables:
- ✅ pip install with editable dependencies
- ✅ Proper package resolution
- ✅ Clean imports in code
- ✅ Development mode support
## Capability Structure
Each capability should follow this structure:
```
capability-name/
├── README.md # Comprehensive documentation
├── pyproject.toml # Package configuration
├── Makefile # Build and test automation
├── .gitignore # Git ignore rules
├── src/capability_name/ # Python package source
│ ├── __init__.py
│ ├── core/ # Core functionality
│ ├── utils/ # Utilities
│ └── testing/ # Testing infrastructure
├── js/ # JavaScript (if applicable)
│ ├── components/
│ ├── controls/
│ └── tests/
├── static/ # Static assets (if applicable)
│ ├── css/
│ ├── images/
│ └── templates/
├── tests/ # Python tests
│ └── test_*.py
└── docs/ # Additional documentation
├── API.md
└── USAGE.md
```
### Required Files
1. **README.md** - Must include:
- Purpose and description
- Installation instructions
- Usage examples
- API documentation
- Integration guide
2. **pyproject.toml** - Must define:
- Package metadata
- Dependencies
- Build system
- Entry points
3. **Makefile** - Should include:
- help target
- test targets
- install/setup targets
- capability-info target (for discovery)
## Plugin System Integration
For capabilities that provide plugins (like testdrive-jsui):
### Plugin Self-Declaration
```python
class TestDriveJSUIEngine(RenderingEnginePlugin):
"""Plugin declares its own location - no hardcoded paths."""
def get_plugin_source_dir(self) -> Path:
"""Plugin knows where it lives."""
return Path(__file__).parent.parent.parent / "capabilities" / "testdrive-jsui"
def get_asset_paths(self) -> Dict[str, Path]:
"""Plugin declares its asset structure."""
base = self.get_plugin_source_dir()
return {
'js': base / 'js',
'css': base / 'static' / 'css',
'templates': base / 'static' / 'templates',
}
```
### Plugin Discovery
The main repo uses **generic discovery** - no hardcoded capability names:
```python
# ✅ Good: Generic discovery
if hasattr(engine, 'get_plugin_source_dir'):
source_dir = engine.get_plugin_source_dir()
# ❌ Bad: Hardcoded capability names
if engine_name == 'testdrive-jsui':
source_dir = Path('capabilities/testdrive-jsui')
```
## Testing Strategy
### Capability Tests
Each capability tests **in isolation**:
```bash
cd capabilities/testdrive-jsui
pytest tests/
npm test
```
### Integration Tests
Main repo tests **integration points**:
```python
# tests/integration/test_capabilities.py
def test_testdrive_jsui_integration():
"""Test that testdrive-jsui integrates correctly."""
engine = TestDriveJSUIEngine()
result = engine.render_document(sample_content, 'edit', config)
assert result is not None
```
### Test Boundaries
- **Capability tests**: Internal functionality, unit tests, component tests
- **Main repo tests**: Integration, configuration, plugin discovery
## Migration Path
### Converting Local Capability to Submodule
1. **Create separate git repo**
```bash
cd /tmp
cp -r markitect_project/capabilities/capability-name capability-name
cd capability-name
git init
git add .
git commit -m "Initial commit"
git remote add origin http://gitea/coulomb/capability-name.git
git push -u origin main
```
2. **Remove from main repo**
```bash
cd markitect_project
git rm -rf capabilities/capability-name
git commit -m "chore: remove capability-name for submodule conversion"
```
3. **Add as submodule**
```bash
git submodule add http://gitea/coulomb/capability-name.git capabilities/capability-name
git commit -m "feat: add capability-name as submodule"
```
## Best Practices
### DO ✅
1. **Develop capabilities independently**
- Use separate Claude instances
- Maintain clear context boundaries
- Follow semantic versioning
2. **Use documented interfaces**
- Import via Python packages
- Use plugin APIs
- Follow configuration patterns
3. **Test integration points**
- Verify capability imports
- Test plugin discovery
- Validate configurations
4. **Update submodules explicitly**
- Pull capability changes deliberately
- Review updates before committing
- Update main repo pointer
5. **Document integration**
- How to use the capability
- Configuration options
- Example usage
### DON'T ❌
1. **Edit capability code from main repo**
- Opens separate repo/instance instead
- Respects submodule boundary
- Maintains clean separation
2. **Hardcode capability paths**
- Use self-declaration instead
- Generic discovery patterns
- Interface-based access
3. **Create circular dependencies**
- Main depends on capabilities
- Capabilities should NOT depend on main
- Keep dependency graph acyclic
4. **Bypass submodule system**
- Don't manually copy files
- Use git submodule commands
- Respect version control
## Troubleshooting
### Submodule not updated
```bash
# Pull latest from capability repo
cd capabilities/testdrive-jsui
git pull origin main
# Update main repo pointer
cd ../..
git add capabilities/testdrive-jsui
git commit -m "chore: update testdrive-jsui"
```
### Import errors
```bash
# Reinstall capabilities
pip install -e .
# Or specific capability
pip install -e ./capabilities/testdrive-jsui
```
### Merge conflicts in submodules
```bash
# Don't merge in submodule from main repo!
# Instead, go to capability repo directly
cd /path/to/separate/testdrive-jsui
# or
cd capabilities/testdrive-jsui
# Resolve conflicts there
git pull origin main
# fix conflicts
git push origin main
# Then update main repo
cd ../../
git submodule update --remote
```
## See Also
- [Agent: Capability Manager](../../agents/agent-capability-manager.md) - Automated capability management
- [Plugin System](../PLUGIN_SYSTEM.md) - Plugin architecture documentation
- [Git Submodules](https://git-scm.com/book/en/v2/Git-Tools-Submodules) - Official git submodules guide
---
**Remember:** Capabilities are **independent projects**. Treat them with the same respect you'd give any external dependency - use their interfaces, don't modify their internals.

File diff suppressed because it is too large Load Diff

View File

@@ -122,8 +122,8 @@
{content}
</div>
<!-- Core JavaScript modules -->
<script src="markitect/static/js/core/debug-system.js"></script>
<!-- Core JavaScript modules from TestDrive-JSUI capability -->
<script src="capabilities/testdrive-jsui/js/core/debug-system.js"></script>
<!-- Control system -->
<script src="capabilities/testdrive-jsui/js/controls/control-base.js"></script>
@@ -133,7 +133,7 @@
<script src="capabilities/testdrive-jsui/js/controls/edit-control.js"></script>
<!-- Main application -->
<script src="markitect/static/js/main.js"></script>
<script src="capabilities/testdrive-jsui/js/main.js"></script>
<!-- Handle CDN loading errors -->
<script>

View File

@@ -23,18 +23,18 @@
<!-- Configuration Data Interface - ONLY place where Python data enters JavaScript -->
<script id="markitect-config" type="application/json">{config_json}</script>
<!-- External JavaScript References - same pattern as non-edit mode -->
<script src="markitect/static/js/core/debug-system.js"></script>
<script src="markitect/static/js/core/section-manager.js"></script>
<script src="markitect/static/js/components/debug-panel.js"></script>
<script src="markitect/static/js/components/dom-renderer.js"></script>
<!-- JavaScript modules from TestDrive-JSUI capability -->
<script src="capabilities/testdrive-jsui/js/core/debug-system.js"></script>
<script src="capabilities/testdrive-jsui/js/core/section-manager.js"></script>
<script src="capabilities/testdrive-jsui/js/components/debug-panel.js"></script>
<script src="capabilities/testdrive-jsui/js/components/dom-renderer.js"></script>
<script src="capabilities/testdrive-jsui/js/controls/control-base.js"></script>
<script src="capabilities/testdrive-jsui/js/controls/contents-control.js"></script>
<script src="capabilities/testdrive-jsui/js/controls/status-control.js"></script>
<script src="capabilities/testdrive-jsui/js/controls/debug-control.js"></script>
<script src="capabilities/testdrive-jsui/js/controls/edit-control.js"></script>
<script src="markitect/static/js/config-loader.js"></script>
<script src="markitect/static/js/main-updated.js"></script>
<script src="capabilities/testdrive-jsui/js/config-loader.js"></script>
<script src="capabilities/testdrive-jsui/js/main-updated.js"></script>
<!-- Simple initialization - same pattern as non-edit mode -->
<script>

View File

@@ -9,6 +9,7 @@ description = "Advanced Markdown engine for structured content"
readme = "README.md"
requires-python = ">=3.8"
dependencies = [
# Core external dependencies
"markdown-it-py",
"PyYAML",
"click>=8.0.0",
@@ -16,14 +17,21 @@ dependencies = [
"jsonpath-ng>=1.5.0",
"aiohttp>=3.8.0",
"toml",
# Core capabilities (required for basic functionality)
"release-management @ file:./capabilities/release-management",
"testdrive-jsui @ file:./capabilities/testdrive-jsui"
"testdrive-jsui @ file:./capabilities/testdrive-jsui",
"issue-facade @ file:./capabilities/issue-facade",
"markitect-utils @ file:./capabilities/markitect-utils"
]
[project.optional-dependencies]
capabilities = [
"markitect-content @ file:./capabilities/markitect-content"
]
development = [
"kaizen-agentic @ file:./capabilities/kaizen-agentic"
]
[project.scripts]
markitect = "markitect.cli:main"