Compare commits
9 Commits
d402f3c75b
...
v0.3.0
| Author | SHA1 | Date | |
|---|---|---|---|
| 1877d6d462 | |||
| 7cc81dee8f | |||
| d5d943a604 | |||
| c5f49b2dd0 | |||
| 096017b93f | |||
| f0dfd04d45 | |||
| 6233d13f18 | |||
| 747715af58 | |||
| 62e7d13d7e |
7
.gitmodules
vendored
7
.gitmodules
vendored
@@ -2,6 +2,9 @@
|
||||
path = wiki
|
||||
url = http://92.205.130.254:32166/coulomb/markitect_project.wiki.git
|
||||
branch = main
|
||||
[submodule "issue-facade"]
|
||||
path = issue-facade
|
||||
[submodule "capabilities/issue-facade"]
|
||||
path = capabilities/issue-facade
|
||||
url = http://92.205.130.254:32166/coulomb/issue-facade.git
|
||||
[submodule "capabilities/kaizen-agentic"]
|
||||
path = capabilities/kaizen-agentic
|
||||
url = http://92.205.130.254:32166/coulomb/kaizen-agentic.git
|
||||
|
||||
@@ -1,14 +1,18 @@
|
||||
# MarkiTect System Capabilities & Extraction Plan
|
||||
# MarkiTect Internal Capabilities Inventory
|
||||
|
||||
> **Comprehensive overview of all capabilities, architectural innovations, and capability extraction recommendations for the ComposableRepositoryParadigm**
|
||||
> **Comprehensive overview of all capabilities PROVIDED BY MarkiTect - what this repository offers to the world**
|
||||
|
||||
## Overview
|
||||
|
||||
- **Total Capabilities**: 73+ distinct capabilities
|
||||
This document catalogs all **internal capabilities** that MarkiTect provides - the functionality that this repository offers to users and other projects. These are capabilities that MarkiTect **provides**, not **uses**.
|
||||
|
||||
- **Total Internal Capabilities**: 73+ distinct capabilities
|
||||
- **Test Categories**: 15 major functional areas
|
||||
- **Test Coverage**: 348 tests across 27 test files
|
||||
- **Architecture**: Database-driven system with AST-based markdown processing, multi-layer caching, and deep Git platform integration
|
||||
- **Extraction Status**: 2 capabilities extracted, 11 candidates identified for extraction
|
||||
- **Extraction Status**: 2 capabilities extracted to external, 11 candidates identified for extraction
|
||||
|
||||
> **Note**: For capabilities that MarkiTect **uses** (external dependencies), see `CAPABILITY_REGISTRY.md`. For complete architecture understanding, see `CAPABILITY_INCLUSION_GUIDE.md`.
|
||||
|
||||
---
|
||||
|
||||
|
||||
127
CAPABILITY_DOCUMENTATION_INDEX.md
Normal file
127
CAPABILITY_DOCUMENTATION_INDEX.md
Normal file
@@ -0,0 +1,127 @@
|
||||
# Capability Documentation Index
|
||||
|
||||
> **Master index to all capability-related documentation in MarkiTect**
|
||||
|
||||
## 📋 **Quick Navigation**
|
||||
|
||||
| Document | Purpose | Scope |
|
||||
|----------|---------|-------|
|
||||
| **[CAPABILITIES.md](CAPABILITIES.md)** | **Internal Capabilities** | What MarkiTect **provides** to the world |
|
||||
| **[CAPABILITY_REGISTRY.md](CAPABILITY_REGISTRY.md)** | **External Capabilities** | What MarkiTect **uses** from others |
|
||||
| **[CLAUDE_CAPABILITY_REFERENCE.md](CLAUDE_CAPABILITY_REFERENCE.md)** | **Quick Reference** | Prevent duplication, guide usage |
|
||||
| **[CAPABILITY_INCLUSION_GUIDE.md](CAPABILITY_INCLUSION_GUIDE.md)** | **Architecture Guide** | Complete workflow and patterns |
|
||||
|
||||
---
|
||||
|
||||
## 🎯 **When to Use Which Document**
|
||||
|
||||
### I want to understand what MarkiTect can do
|
||||
→ **Read**: [CAPABILITIES.md](CAPABILITIES.md)
|
||||
- 73+ internal capabilities provided by MarkiTect
|
||||
- Core processing, CLI, templates, caching, validation
|
||||
- Extraction candidates and recommendations
|
||||
|
||||
### I want to see what MarkiTect depends on
|
||||
→ **Read**: [CAPABILITY_REGISTRY.md](CAPABILITY_REGISTRY.md)
|
||||
- External capabilities: submodules, local, packages
|
||||
- Issue management (issue-facade), documentation (wiki)
|
||||
- Content processing, utilities, dependencies
|
||||
|
||||
### I'm implementing something and want to avoid duplication
|
||||
→ **Read**: [CLAUDE_CAPABILITY_REFERENCE.md](CLAUDE_CAPABILITY_REFERENCE.md)
|
||||
- Quick lookup patterns
|
||||
- "Use X for Y" guidance
|
||||
- Anti-duplication rules
|
||||
|
||||
### I want to understand the capability architecture
|
||||
→ **Read**: [CAPABILITY_INCLUSION_GUIDE.md](CAPABILITY_INCLUSION_GUIDE.md)
|
||||
- Internal vs external organization
|
||||
- Inclusion workflow and patterns
|
||||
- Management operations and best practices
|
||||
|
||||
---
|
||||
|
||||
## 🔍 **Discovery and Management Tools**
|
||||
|
||||
### Command-Line Tools
|
||||
```bash
|
||||
# Generate capability report
|
||||
make capability-report
|
||||
|
||||
# Search for existing functionality
|
||||
make capability-search TERM=issue_management
|
||||
|
||||
# Validate proper capability usage
|
||||
make capability-validate FILE=my_code.py
|
||||
```
|
||||
|
||||
### Programmatic Discovery
|
||||
```bash
|
||||
# Run capability discovery tool directly
|
||||
python tools/capability_discovery.py report
|
||||
python tools/capability_discovery.py search "function_name"
|
||||
python tools/capability_discovery.py validate "file_path"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🏗️ **Capability Architecture Overview**
|
||||
|
||||
```
|
||||
MarkiTect Repository
|
||||
├── [Internal Capabilities] # CAPABILITIES.md
|
||||
│ ├── markitect/database/ # Database operations
|
||||
│ ├── markitect/template/ # Template processing
|
||||
│ ├── markitect/cli/ # CLI framework
|
||||
│ └── ... (70+ more) # Core MarkiTect functionality
|
||||
│
|
||||
└── [External Capabilities] # CAPABILITY_REGISTRY.md
|
||||
├── issue-facade/ # Submodule: Issue tracking
|
||||
├── wiki/ # Submodule: Documentation
|
||||
├── capabilities/ # Local extracted capabilities
|
||||
│ ├── markitect-content/ # Content processing
|
||||
│ └── markitect-utils/ # Utility functions
|
||||
└── [Package Dependencies] # click, pytest, etc.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📊 **Current Status Summary**
|
||||
|
||||
### Internal Capabilities (PROVIDED BY MarkiTect)
|
||||
- **Total**: 73+ documented capabilities
|
||||
- **Categories**: Core processing, CLI, templates, validation, export/import
|
||||
- **Test Coverage**: 348 tests across 27 test files
|
||||
- **Extraction Pipeline**: 2 extracted, 11 candidates identified
|
||||
|
||||
### External Capabilities (USED BY MarkiTect)
|
||||
- **Submodules**: 2 (issue-facade, wiki)
|
||||
- **Local**: 2 (markitect-content, markitect-utils)
|
||||
- **Packages**: Multiple (click, pytest, sqlalchemy, etc.)
|
||||
- **Management**: Automated discovery and validation tools
|
||||
|
||||
---
|
||||
|
||||
## 🎯 **Best Practices Quick Reference**
|
||||
|
||||
### For Developers
|
||||
1. **Check External First**: Always consult `CAPABILITY_REGISTRY.md` before implementing
|
||||
2. **Use Discovery Tools**: `make capability-search` before coding
|
||||
3. **Follow Patterns**: Use established integration patterns
|
||||
4. **Update Documentation**: Keep registries current
|
||||
|
||||
### For Claude
|
||||
1. **Registry First**: Check `CAPABILITY_REGISTRY.md` before any implementation
|
||||
2. **Quick Lookup**: Use `CLAUDE_CAPABILITY_REFERENCE.md` for instant guidance
|
||||
3. **Respect Boundaries**: Don't duplicate external capability functionality
|
||||
4. **Discovery Commands**: Use `make capability-search TERM=xyz` to find existing
|
||||
|
||||
### For Architecture
|
||||
1. **Clear Separation**: Internal (provides) vs External (uses)
|
||||
2. **Extraction Pipeline**: Internal → Local → Submodule → Package
|
||||
3. **Documentation**: Keep all four documents synchronized
|
||||
4. **Validation**: Regular checks for duplication and proper usage
|
||||
|
||||
---
|
||||
|
||||
**💡 Remember**: This index helps you navigate the capability ecosystem efficiently. Start here to find the right documentation for your needs!
|
||||
267
CAPABILITY_INCLUSION_GUIDE.md
Normal file
267
CAPABILITY_INCLUSION_GUIDE.md
Normal file
@@ -0,0 +1,267 @@
|
||||
# Capability Inclusion Guide
|
||||
|
||||
> **Complete guide to understanding and managing capability inclusion in the MarkiTect project**
|
||||
|
||||
## Overview
|
||||
|
||||
MarkiTect uses a **Capability Inclusion Pattern** where functionality is organized into distinct capabilities that can be:
|
||||
- **Internal**: Provided by this repository (core MarkiTect functionality)
|
||||
- **External**: Used by this repository (submodules, dependencies, extracted capabilities)
|
||||
|
||||
This approach enables clear separation of concerns, easy extension/bugfixing, and prevents code duplication.
|
||||
|
||||
---
|
||||
|
||||
## 📋 **Documentation Structure**
|
||||
|
||||
### Core Documentation Files
|
||||
|
||||
1. **`CAPABILITIES.md`** - **Internal Capability Inventory**
|
||||
- **Purpose**: Comprehensive analysis of all capabilities provided BY this repository
|
||||
- **Content**: 73+ internal capabilities, test coverage, extraction recommendations
|
||||
- **Scope**: What MarkiTect provides to the world
|
||||
|
||||
2. **`CAPABILITY_REGISTRY.md`** - **External Capability Registry**
|
||||
- **Purpose**: Registry of all capabilities USED BY this repository
|
||||
- **Content**: Submodules, local extracted capabilities, external dependencies
|
||||
- **Scope**: What MarkiTect consumes from other sources
|
||||
|
||||
3. **`CLAUDE_CAPABILITY_REFERENCE.md`** - **Quick Usage Reference**
|
||||
- **Purpose**: Prevent code duplication by guiding Claude to existing capabilities
|
||||
- **Content**: Quick lookup patterns and anti-duplication rules
|
||||
- **Scope**: Operational guidance for development
|
||||
|
||||
4. **`CAPABILITY_INCLUSION_GUIDE.md`** - **This Document**
|
||||
- **Purpose**: Explains the overall capability inclusion architecture
|
||||
- **Content**: Workflow, patterns, internal vs external organization
|
||||
- **Scope**: Architectural understanding and management
|
||||
|
||||
---
|
||||
|
||||
## 🏗️ **Capability Organization Architecture**
|
||||
|
||||
### Internal Capabilities (Provided BY MarkiTect)
|
||||
|
||||
**Location**: Throughout the main codebase
|
||||
**Purpose**: Core functionality that MarkiTect provides to the world
|
||||
**Management**: Documented in `CAPABILITIES.md`
|
||||
|
||||
#### Categories:
|
||||
- **Core Processing**: AST-based markdown processing, database operations
|
||||
- **CLI Commands**: Command-line interface functionality
|
||||
- **Template Engine**: Document template processing
|
||||
- **Caching System**: Multi-layer performance caching
|
||||
- **Schema Validation**: Document structure validation
|
||||
- **Export/Import**: Data transformation capabilities
|
||||
|
||||
#### Extraction Candidates:
|
||||
- Capabilities that could be useful to other projects
|
||||
- Self-contained functionality with clear boundaries
|
||||
- Well-tested components (>80% coverage preferred)
|
||||
|
||||
**Example Internal Capability:**
|
||||
```
|
||||
markitect/database/ # Database operations capability
|
||||
markitect/template/ # Template processing capability
|
||||
markitect/cli/ # CLI framework capability
|
||||
```
|
||||
|
||||
### External Capabilities (Used BY MarkiTect)
|
||||
|
||||
**Location**: Various inclusion patterns
|
||||
**Purpose**: Functionality MarkiTect depends on from external sources
|
||||
**Management**: Documented in `CAPABILITY_REGISTRY.md`
|
||||
|
||||
#### 1. **Submodule Capabilities** (Independent Repositories)
|
||||
- **Pattern**: Git submodules pointing to external repositories
|
||||
- **Benefits**: Independent versioning, separate development, easy updates
|
||||
- **Examples**: `capabilities/issue-facade/`, `wiki/`
|
||||
|
||||
#### 2. **Local Extracted Capabilities** (Previously Internal, Now Separated)
|
||||
- **Pattern**: Moved to `capabilities/` directory but still in this repo
|
||||
- **Benefits**: Clear separation, preparation for future extraction
|
||||
- **Examples**: `capabilities/markitect-content/`, `capabilities/markitect-utils/`
|
||||
|
||||
#### 3. **Package Dependencies** (Third-Party Libraries)
|
||||
- **Pattern**: Standard pip dependencies in `pyproject.toml`
|
||||
- **Benefits**: Mature, maintained, standard integration
|
||||
- **Examples**: `click`, `pytest`, `sqlalchemy`
|
||||
|
||||
---
|
||||
|
||||
## 🔄 **Capability Inclusion Workflow**
|
||||
|
||||
### Phase 1: Internal Development
|
||||
```
|
||||
Developer creates functionality → Internal capability (in main codebase)
|
||||
```
|
||||
|
||||
### Phase 2: Extraction Evaluation
|
||||
```
|
||||
Capability matures → Evaluate extraction criteria → Decide extraction pattern
|
||||
```
|
||||
|
||||
### Phase 3: Capability Inclusion
|
||||
```
|
||||
Extract capability → Choose inclusion pattern → Update registries
|
||||
```
|
||||
|
||||
### Inclusion Pattern Decision Tree:
|
||||
|
||||
1. **Will other projects use this capability?**
|
||||
- **Yes** → Consider **Submodule Capability** (extract to separate repo)
|
||||
- **No** → Consider **Local Capability** (move to `capabilities/`)
|
||||
|
||||
2. **Does it need independent versioning/development?**
|
||||
- **Yes** → **Submodule Capability**
|
||||
- **No** → **Local Capability**
|
||||
|
||||
3. **Is it a mature third-party solution?**
|
||||
- **Yes** → **Package Dependency**
|
||||
- **No** → Custom solution needed
|
||||
|
||||
### Example Extraction Journey:
|
||||
```
|
||||
Internal → markitect/issues/ (internal issue management)
|
||||
Evaluation → Self-contained, reusable, independent development needed
|
||||
Extraction → coulomb/issue-facade (separate repository)
|
||||
Inclusion → capabilities/issue-facade/ (submodule capability)
|
||||
Registration → CAPABILITY_REGISTRY.md updated
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📊 **Current Capability Landscape**
|
||||
|
||||
### Internal Capabilities (73+ documented in CAPABILITIES.md)
|
||||
```
|
||||
markitect/ # Core repository
|
||||
├── database/ # Database operations
|
||||
├── template/ # Template processing
|
||||
├── cli/ # CLI framework
|
||||
├── packaging/ # Document packaging
|
||||
├── finance/ # Cost tracking
|
||||
└── [... 68+ more capabilities]
|
||||
```
|
||||
|
||||
### External Capabilities (5 documented in CAPABILITY_REGISTRY.md)
|
||||
```
|
||||
capabilities/
|
||||
├── issue-facade/ # Submodule: Universal issue tracking
|
||||
├── kaizen-agentic/ # Submodule: AI agent framework
|
||||
├── markitect-content/ # Local: Content processing
|
||||
└── markitect-utils/ # Local: Utility functions
|
||||
wiki/ # Submodule: Documentation
|
||||
[External dependencies: click, pytest, sqlalchemy, ...]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🛠️ **Management Operations**
|
||||
|
||||
### Discovery and Validation
|
||||
```bash
|
||||
# Discover all external capabilities
|
||||
make capability-report
|
||||
|
||||
# Search for existing functionality
|
||||
make capability-search TERM=issue_management
|
||||
|
||||
# Validate proper usage
|
||||
make capability-validate FILE=my_code.py
|
||||
```
|
||||
|
||||
### Adding New External Capabilities
|
||||
|
||||
#### Submodule Capability:
|
||||
```bash
|
||||
git submodule add <repo-url> <local-path>
|
||||
# Update CAPABILITY_REGISTRY.md
|
||||
```
|
||||
|
||||
#### Local Capability:
|
||||
```bash
|
||||
mkdir capabilities/new-capability
|
||||
# Move code, create README.md
|
||||
# Update CAPABILITY_REGISTRY.md
|
||||
```
|
||||
|
||||
#### Package Dependency:
|
||||
```bash
|
||||
# Update pyproject.toml
|
||||
# Update CAPABILITY_REGISTRY.md
|
||||
```
|
||||
|
||||
### Updating Capabilities
|
||||
|
||||
#### Submodules:
|
||||
```bash
|
||||
git submodule update --remote <submodule-path>
|
||||
```
|
||||
|
||||
#### Local Capabilities:
|
||||
```bash
|
||||
# Direct code updates in capabilities/
|
||||
```
|
||||
|
||||
#### Package Dependencies:
|
||||
```bash
|
||||
pip install --upgrade <package>
|
||||
# Update pyproject.toml version constraints
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🎯 **Best Practices**
|
||||
|
||||
### For Internal Capabilities (CAPABILITIES.md):
|
||||
- **Document thoroughly**: Clear description, interfaces, test coverage
|
||||
- **Evaluate extraction**: Regular review against extraction criteria
|
||||
- **Maintain quality**: Adequate test coverage, clear boundaries
|
||||
- **Consider reusability**: Could other projects benefit from this?
|
||||
|
||||
### For External Capabilities (CAPABILITY_REGISTRY.md):
|
||||
- **Registry first**: Always check before implementing new functionality
|
||||
- **Respect interfaces**: Use documented APIs, don't bypass capabilities
|
||||
- **Update documentation**: Keep registry current with capability changes
|
||||
- **Clear boundaries**: Don't duplicate external capability functionality
|
||||
|
||||
### For Claude and Developers:
|
||||
- **Check before code**: Always consult `CAPABILITY_REGISTRY.md` first
|
||||
- **Use discovery tools**: `make capability-search` before implementing
|
||||
- **Follow patterns**: Use established integration patterns
|
||||
- **Update registries**: Document new capabilities immediately
|
||||
|
||||
---
|
||||
|
||||
## 🔮 **Future Evolution**
|
||||
|
||||
### Extraction Pipeline:
|
||||
```
|
||||
Internal Capability → Evaluation → Local Capability → Submodule Capability
|
||||
```
|
||||
|
||||
### Maturity Progression:
|
||||
1. **Internal**: New functionality developed in main codebase
|
||||
2. **Local**: Stable functionality moved to `capabilities/` for separation
|
||||
3. **Submodule**: Mature functionality extracted to independent repository
|
||||
4. **Package**: Published capabilities available via pip/pypi
|
||||
|
||||
### Success Metrics:
|
||||
- **Zero duplication**: No accidental reimplementation of existing capabilities
|
||||
- **Clear boundaries**: Well-defined interfaces between internal and external
|
||||
- **Easy extension**: Simple to enhance or fix external capabilities
|
||||
- **Efficient discovery**: Fast identification of existing functionality
|
||||
|
||||
---
|
||||
|
||||
## 📚 **Quick Reference**
|
||||
|
||||
| Need | Check | Use |
|
||||
|------|--------|-----|
|
||||
| Internal MarkiTect functionality | `CAPABILITIES.md` | Import from main codebase |
|
||||
| External functionality | `CAPABILITY_REGISTRY.md` | Use documented interface |
|
||||
| Prevent duplication | `CLAUDE_CAPABILITY_REFERENCE.md` | Follow anti-duplication rules |
|
||||
| Understand architecture | `CAPABILITY_INCLUSION_GUIDE.md` | This document |
|
||||
|
||||
**Remember**: Internal capabilities are what MarkiTect **provides**, external capabilities are what MarkiTect **uses**.
|
||||
219
CAPABILITY_REGISTRY.md
Normal file
219
CAPABILITY_REGISTRY.md
Normal file
@@ -0,0 +1,219 @@
|
||||
# MarkiTect External Capability Registry
|
||||
|
||||
> **Registry of all capabilities USED BY MarkiTect (external dependencies, submodules, extracted components)**
|
||||
|
||||
## Overview
|
||||
|
||||
This registry documents all **external capabilities** that MarkiTect depends on - functionality that MarkiTect **uses** rather than **provides**. This includes git submodules, extracted local capabilities, and package dependencies.
|
||||
|
||||
> **Note**: For capabilities that MarkiTect **provides** to the world, see `CAPABILITIES.md`. For complete architecture understanding, see `CAPABILITY_INCLUSION_GUIDE.md`.
|
||||
|
||||
## Capability Inclusion Patterns
|
||||
|
||||
### 1. **Submodule Capabilities** (External Repositories)
|
||||
Full repositories included as git submodules for independent development and versioning.
|
||||
|
||||
### 2. **Local Capabilities** (Extracted Components)
|
||||
Self-contained capabilities extracted from the main codebase but maintained locally.
|
||||
|
||||
### 3. **External Dependencies** (Package Dependencies)
|
||||
Third-party packages providing specific capabilities via pip/pypi.
|
||||
|
||||
---
|
||||
|
||||
## 🔍 **ACTIVE CAPABILITIES REGISTRY**
|
||||
|
||||
### Universal Issue Management
|
||||
- **Type**: Submodule Capability
|
||||
- **Location**: `capabilities/issue-facade/`
|
||||
- **Repository**: `coulomb/issue-facade`
|
||||
- **Purpose**: Backend-agnostic issue tracking with unified CLI
|
||||
- **Interfaces**:
|
||||
- CLI: `cd capabilities/issue-facade && python -m cli.main [command]`
|
||||
- API: Core models, backends (local SQLite, Gitea, GitHub, GitLab)
|
||||
- **Usage Guidelines**:
|
||||
- ✅ **USE**: For all issue management tasks
|
||||
- ❌ **DON'T**: Implement custom issue tracking, duplicate CLI commands
|
||||
- 🔧 **Integration**: Reference submodule for issue operations
|
||||
|
||||
### Kaizen-Agentic Framework
|
||||
- **Type**: Submodule Capability
|
||||
- **Location**: `capabilities/kaizen-agentic/`
|
||||
- **Repository**: `coulomb/kaizen-agentic`
|
||||
- **Purpose**: Advanced AI agent framework for autonomous development workflows
|
||||
- **Interfaces**:
|
||||
- CLI: `cd capabilities/kaizen-agentic && make [command]`
|
||||
- Framework: Agent definitions, workflow automation, development patterns
|
||||
- **Usage Guidelines**:
|
||||
- ✅ **USE**: For AI agent definitions and autonomous workflows
|
||||
- ❌ **DON'T**: Implement custom agent frameworks, duplicate AI patterns
|
||||
- 🔧 **Integration**: Reference framework for agent-driven development
|
||||
|
||||
### Content Processing Capability
|
||||
- **Type**: Local Capability
|
||||
- **Location**: `capabilities/markitect-content/`
|
||||
- **Purpose**: MarkdownMatters content parsing without frontmatter/tailmatter
|
||||
- **Interfaces**:
|
||||
- `ContentParser` class for content extraction
|
||||
- `ContentStats` for document statistics
|
||||
- CLI commands for content operations
|
||||
- **Usage Guidelines**:
|
||||
- ✅ **USE**: For content extraction and analysis
|
||||
- ❌ **DON'T**: Reimplement markdown content parsing
|
||||
- 🔧 **Integration**: Import from `capabilities.markitect_content`
|
||||
|
||||
### Utility Functions Capability
|
||||
- **Type**: Local Capability
|
||||
- **Location**: `capabilities/markitect-utils/`
|
||||
- **Purpose**: Common utility functions and helpers
|
||||
- **Interfaces**: Shared utilities and helper functions
|
||||
- **Usage Guidelines**:
|
||||
- ✅ **USE**: For common operations and utilities
|
||||
- ❌ **DON'T**: Duplicate utility functions
|
||||
- 🔧 **Integration**: Import from `capabilities.markitect_utils`
|
||||
|
||||
### Documentation and Knowledge Base
|
||||
- **Type**: Submodule Capability
|
||||
- **Location**: `wiki/`
|
||||
- **Repository**: `coulomb/markitect_project.wiki`
|
||||
- **Purpose**: Comprehensive project documentation and knowledge base
|
||||
- **Interfaces**: Markdown documentation files
|
||||
- **Usage Guidelines**:
|
||||
- ✅ **USE**: For project documentation, architectural decisions
|
||||
- ❌ **DON'T**: Create duplicate documentation
|
||||
- 🔧 **Integration**: Reference wiki for authoritative documentation
|
||||
|
||||
---
|
||||
|
||||
## 🚫 **CAPABILITY CONFLICT PREVENTION**
|
||||
|
||||
### Before Implementing New Functionality:
|
||||
|
||||
1. **Check This Registry**: Verify no existing capability provides the functionality
|
||||
2. **Search Submodules**: Check `issue-facade/`, `wiki/` for existing solutions
|
||||
3. **Check Local Capabilities**: Review `capabilities/` directory
|
||||
4. **Consult Documentation**: Check capability READMEs for interface details
|
||||
|
||||
### Implementation Guidelines:
|
||||
|
||||
- **Extend, Don't Duplicate**: If functionality exists, extend or interface with it
|
||||
- **Clear Boundaries**: New code should complement, not replace, existing capabilities
|
||||
- **Interface Respect**: Use documented interfaces rather than reimplementing
|
||||
- **Separation of Concerns**: Maintain clear boundaries between core MarkiTect and capabilities
|
||||
|
||||
---
|
||||
|
||||
## 🔧 **INTEGRATION PATTERNS**
|
||||
|
||||
### Submodule Integration
|
||||
```bash
|
||||
# Issue management
|
||||
cd capabilities/issue-facade && python -m cli.main list
|
||||
|
||||
# AI agent framework
|
||||
cd capabilities/kaizen-agentic && make [command]
|
||||
|
||||
# Documentation updates
|
||||
cd wiki && git pull origin main
|
||||
```
|
||||
|
||||
### Local Capability Integration
|
||||
```python
|
||||
# Content processing
|
||||
from capabilities.markitect_content import ContentParser
|
||||
parser = ContentParser()
|
||||
|
||||
# Utilities
|
||||
from capabilities.markitect_utils import helper_function
|
||||
```
|
||||
|
||||
### External Dependency Integration
|
||||
```python
|
||||
# Standard package imports
|
||||
import click # CLI framework
|
||||
import pytest # Testing framework
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📋 **CLAUDE USAGE GUIDELINES**
|
||||
|
||||
### When Asked to Implement Functionality:
|
||||
|
||||
1. **First**: Check this registry for existing capabilities
|
||||
2. **If Exists**: Use/extend the existing capability rather than reimplementing
|
||||
3. **If Missing**: Implement new functionality with clear separation from existing capabilities
|
||||
4. **Document**: Update this registry when adding new capabilities
|
||||
|
||||
### Capability Respect Rules:
|
||||
|
||||
- **Issue Management**: Always use `issue-facade` submodule, never implement custom issue tracking
|
||||
- **Content Processing**: Use `markitect-content` capability for MarkdownMatters parsing
|
||||
- **Documentation**: Reference `wiki` submodule for authoritative project information
|
||||
- **Utilities**: Check `markitect-utils` before creating new utility functions
|
||||
|
||||
### Integration Commands:
|
||||
- **Issue Operations**: `cd capabilities/issue-facade && python -m cli.main [command]`
|
||||
- **AI Agent Framework**: `cd capabilities/kaizen-agentic && make [command]`
|
||||
- **Content Analysis**: Import from `capabilities.markitect_content`
|
||||
- **Utility Functions**: Import from `capabilities.markitect_utils`
|
||||
- **Documentation**: Reference files in `wiki/`
|
||||
|
||||
---
|
||||
|
||||
## 🔄 **CAPABILITY LIFECYCLE MANAGEMENT**
|
||||
|
||||
### Adding New Capabilities
|
||||
|
||||
1. **Evaluate**: Does this warrant capability extraction?
|
||||
2. **Choose Pattern**: Submodule (external repo) vs Local capability vs External dependency
|
||||
3. **Implement**: Follow capability inclusion patterns
|
||||
4. **Document**: Update this registry with interface details
|
||||
5. **Update Agents**: Inform specialized agents of new capability
|
||||
|
||||
### Updating Existing Capabilities
|
||||
|
||||
1. **Submodules**: Update submodule reference (`git submodule update`)
|
||||
2. **Local Capabilities**: Update local code and interfaces
|
||||
3. **External Dependencies**: Update package versions in `pyproject.toml`
|
||||
4. **Registry**: Update interface documentation if changed
|
||||
|
||||
### Removing Capabilities
|
||||
|
||||
1. **Deprecation Notice**: Document deprecation timeline
|
||||
2. **Migration Path**: Provide alternative solutions
|
||||
3. **Remove References**: Update all code using the capability
|
||||
4. **Clean Registry**: Remove from this registry
|
||||
5. **Update Documentation**: Update all relevant documentation
|
||||
|
||||
---
|
||||
|
||||
## 📊 **CAPABILITY METRICS**
|
||||
|
||||
- **Total Capabilities**: 5 active capabilities
|
||||
- **Submodule Capabilities**: 3 (issue-facade, kaizen-agentic, wiki)
|
||||
- **Local Capabilities**: 2 (markitect-content, markitect-utils)
|
||||
- **External Dependencies**: Multiple (see pyproject.toml)
|
||||
- **Coverage**: Issue management, AI agent framework, content processing, utilities, documentation
|
||||
|
||||
---
|
||||
|
||||
## 🎯 **SUCCESS CRITERIA**
|
||||
|
||||
### For Developers:
|
||||
- [ ] Zero accidental functionality duplication
|
||||
- [ ] Clear interface boundaries respected
|
||||
- [ ] Efficient capability discovery and usage
|
||||
- [ ] Proper separation of concerns maintained
|
||||
|
||||
### For Claude:
|
||||
- [ ] Registry consulted before implementing new functionality
|
||||
- [ ] Existing capabilities used when available
|
||||
- [ ] Clear understanding of capability boundaries
|
||||
- [ ] Proper integration patterns followed
|
||||
|
||||
### For the Project:
|
||||
- [ ] Modular architecture maintained
|
||||
- [ ] Easy capability extension and bugfixing
|
||||
- [ ] Clean separation between core and capabilities
|
||||
- [ ] Scalable capability inclusion patterns
|
||||
23
CHANGELOG.md
23
CHANGELOG.md
@@ -7,6 +7,29 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
|
||||
|
||||
## [Unreleased]
|
||||
|
||||
## [0.3.0] - 2025-10-25
|
||||
|
||||
### Added
|
||||
- **Kaizen-Agentic Framework Integration** as external capability submodule
|
||||
- **Test Reorganization by Capability** with separated test targets for better modularity
|
||||
- **Comprehensive Capability Inclusion Management System** with automated discovery tools
|
||||
- **Todofile System Implementation** - Modern task management replacing NEXT.md
|
||||
- **Historical File Organization** - Legacy files moved to history directory for better project structure
|
||||
|
||||
### Changed
|
||||
- **Capability Directory Reorganization** - moved all external dependencies to `capabilities/` directory
|
||||
- **Issue Management Migration** - replaced local issue system with external `issue-facade` submodule
|
||||
- **Project Structure Optimization** - established clear separation between capabilities and core documentation
|
||||
- **Test Architecture Enhancement** - separated capability-specific tests from core system tests
|
||||
- **Makefile Test Targets** - added granular test execution with `make test-capabilities` and capability-specific targets
|
||||
|
||||
### Improved
|
||||
- **Logical Organization** - capabilities/ for external dependencies, wiki/ for project documentation at root
|
||||
- **Test Performance** - core tests now exclude capability tests for faster execution
|
||||
- **Development Workflow** - clear separation between internal and external capabilities
|
||||
- **Documentation Ecosystem** - complete capability documentation with CAPABILITIES.md and CAPABILITY_REGISTRY.md
|
||||
- **Code Organization** - Archive of legacy files to maintain clean working directory
|
||||
|
||||
## [0.2.0] - 2025-10-20
|
||||
|
||||
### Added
|
||||
|
||||
135
CLAUDE_CAPABILITY_REFERENCE.md
Normal file
135
CLAUDE_CAPABILITY_REFERENCE.md
Normal file
@@ -0,0 +1,135 @@
|
||||
# Claude Capability Reference - Quick Lookup
|
||||
|
||||
> **Essential reference for Claude to prevent code duplication and ensure proper capability usage**
|
||||
|
||||
## 🚨 **BEFORE IMPLEMENTING: CHECK EXISTING CAPABILITIES**
|
||||
|
||||
### Issue Management ➜ USE `issue-facade/`
|
||||
```bash
|
||||
# ✅ DO: Use existing issue facade
|
||||
cd issue-facade && python -m cli.main list
|
||||
cd issue-facade && python -m cli.main show 42
|
||||
cd issue-facade && python -m cli.main create "Title" "Description"
|
||||
|
||||
# ❌ DON'T: Implement custom issue tracking
|
||||
# ❌ DON'T: Create new CLI commands for issues
|
||||
# ❌ DON'T: Build custom Gitea/GitHub API clients
|
||||
```
|
||||
|
||||
### Content Processing ➜ USE `capabilities/markitect-content/`
|
||||
```python
|
||||
# ✅ DO: Use existing content capability
|
||||
from capabilities.markitect_content import ContentParser, ContentStats
|
||||
parser = ContentParser()
|
||||
stats = ContentStats()
|
||||
|
||||
# ❌ DON'T: Reimplement markdown parsing
|
||||
# ❌ DON'T: Create new content statistics functions
|
||||
# ❌ DON'T: Duplicate frontmatter/tailmatter handling
|
||||
```
|
||||
|
||||
### Utilities ➜ USE `capabilities/markitect-utils/`
|
||||
```python
|
||||
# ✅ DO: Use existing utilities
|
||||
from capabilities.markitect_utils import utility_function
|
||||
|
||||
# ❌ DON'T: Recreate common utility functions
|
||||
# ❌ DON'T: Duplicate helper functions
|
||||
```
|
||||
|
||||
### Documentation ➜ USE `wiki/`
|
||||
```markdown
|
||||
# ✅ DO: Reference existing documentation
|
||||
See wiki/ComposableRepositoryParadigm.md
|
||||
See wiki/MarkdownMatters.md
|
||||
|
||||
# ❌ DON'T: Create duplicate documentation
|
||||
# ❌ DON'T: Rewrite architectural decisions
|
||||
```
|
||||
|
||||
## 🔍 **CAPABILITY DISCOVERY COMMANDS**
|
||||
|
||||
### Quick Capability Check
|
||||
```bash
|
||||
# Check all capabilities
|
||||
ls -la capabilities/ # Local capabilities
|
||||
ls -la issue-facade/ # Issue management capability
|
||||
ls -la wiki/ # Documentation capability
|
||||
cat CAPABILITY_REGISTRY.md # Full registry
|
||||
|
||||
# Verify functionality exists
|
||||
grep -r "function_name" capabilities/
|
||||
grep -r "class_name" issue-facade/
|
||||
```
|
||||
|
||||
### Interface Documentation
|
||||
- **Issue Facade**: `issue-facade/README.md`
|
||||
- **Content Processing**: `capabilities/markitect-content/README.md`
|
||||
- **Utilities**: `capabilities/markitect-utils/README.md`
|
||||
- **Documentation**: `wiki/` (multiple files)
|
||||
|
||||
## ⚡ **QUICK DECISION TREE**
|
||||
|
||||
1. **Need Issue Management?** ➜ Use `issue-facade/`
|
||||
2. **Need Content Parsing?** ➜ Use `capabilities/markitect-content/`
|
||||
3. **Need Utility Functions?** ➜ Check `capabilities/markitect-utils/`
|
||||
4. **Need Documentation?** ➜ Reference `wiki/`
|
||||
5. **Something New?** ➜ Check `CAPABILITY_REGISTRY.md` first
|
||||
|
||||
## 🎯 **CLAUDE IMPLEMENTATION RULES**
|
||||
|
||||
### Rule 1: Registry First
|
||||
- **Always check** `CAPABILITY_REGISTRY.md` before implementing
|
||||
- **Search existing** capabilities for similar functionality
|
||||
- **Extend, don't duplicate** existing capabilities
|
||||
|
||||
### Rule 2: Use Documented Interfaces
|
||||
- **Follow interface patterns** documented in capability READMEs
|
||||
- **Use provided CLI commands** rather than reimplementing
|
||||
- **Import from documented modules** rather than copying code
|
||||
|
||||
### Rule 3: Maintain Separation
|
||||
- **Core MarkiTect**: Focus on markdown processing and database operations
|
||||
- **Capabilities**: Use for specialized functionality (issues, content, utils)
|
||||
- **Clear boundaries**: Don't mix core and capability concerns
|
||||
|
||||
### Rule 4: Update Registry
|
||||
- **When adding capabilities**: Update `CAPABILITY_REGISTRY.md`
|
||||
- **When changing interfaces**: Update documentation
|
||||
- **When removing capabilities**: Clean up references
|
||||
|
||||
## 📋 **COMMON INTEGRATION PATTERNS**
|
||||
|
||||
### Submodule Usage
|
||||
```bash
|
||||
# Issue management via submodule
|
||||
cd issue-facade && python -m cli.main [command]
|
||||
|
||||
# Update submodule
|
||||
git submodule update --remote issue-facade
|
||||
```
|
||||
|
||||
### Local Capability Usage
|
||||
```python
|
||||
# Content processing
|
||||
from capabilities.markitect_content import ContentParser
|
||||
|
||||
# Utilities
|
||||
from capabilities.markitect_utils import helper_function
|
||||
```
|
||||
|
||||
### Error Prevention
|
||||
```python
|
||||
# ❌ BAD: Duplicating functionality
|
||||
def create_issue(title, body):
|
||||
# Custom implementation
|
||||
|
||||
# ✅ GOOD: Using existing capability
|
||||
import subprocess
|
||||
result = subprocess.run(['python', '-m', 'cli.main', 'create', title, body],
|
||||
cwd='issue-facade')
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**💡 Remember: When in doubt, check the registry first!**
|
||||
108
Makefile
108
Makefile
@@ -25,7 +25,9 @@ help:
|
||||
@echo " venv-status - Check if venv is active"
|
||||
@echo ""
|
||||
@echo "Development:"
|
||||
@echo " test - Run all tests"
|
||||
@echo " test - Run core tests (excluding capability-specific tests)"
|
||||
@echo " test-capabilities - Run all capability-specific tests"
|
||||
@echo " test-capability-* - Run specific capability tests (content, utils, finance, etc.)"
|
||||
@echo " test-status - Show test status summary without re-running"
|
||||
@echo " test-new - Create new test file template"
|
||||
@echo " test-coverage - Analyze test coverage"
|
||||
@@ -86,6 +88,11 @@ help:
|
||||
@echo " update-digest - Update ProjectStatusDigest.md (requires Claude Code)"
|
||||
@echo " add-diary-entry - Add new entry to ProjectDiary.md (requires Claude Code)"
|
||||
@echo ""
|
||||
@echo "Capability Management:"
|
||||
@echo " capability-report - Generate capability discovery report"
|
||||
@echo " capability-search TERM=xyz - Search for functionality across capabilities"
|
||||
@echo " capability-validate FILE=path - Validate proper capability usage in file"
|
||||
@echo ""
|
||||
@echo ""
|
||||
@echo "Requirements Engineering:"
|
||||
@echo " validate-requirements - Analyze foundations before development"
|
||||
@@ -315,25 +322,77 @@ setup-dev: install-dev
|
||||
|
||||
# Run tests
|
||||
test: $(VENV)/bin/activate
|
||||
@echo "🧪 Running tests..."
|
||||
@echo "🧪 Running core tests (excluding capability-specific tests)..."
|
||||
@if [ -f $(VENV)/bin/pytest ]; then \
|
||||
PYTHONPATH=. $(VENV)/bin/pytest tests/ -v; \
|
||||
PYTHONPATH=. $(VENV)/bin/pytest tests/ -v \
|
||||
--ignore=capabilities/markitect-content/tests/ \
|
||||
--ignore=capabilities/markitect-utils/tests/ \
|
||||
--ignore=markitect/finance/tests/ \
|
||||
--ignore=markitect/query_paradigms/tests/ \
|
||||
--ignore=markitect/graphql/tests/ \
|
||||
--ignore=markitect/plugins/tests/; \
|
||||
else \
|
||||
PYTHONPATH=. $(VENV_PYTHON) -m pytest tests/ -v 2>/dev/null || \
|
||||
PYTHONPATH=. $(VENV_PYTHON) -m pytest tests/ -v \
|
||||
--ignore=capabilities/markitect-content/tests/ \
|
||||
--ignore=capabilities/markitect-utils/tests/ \
|
||||
--ignore=markitect/finance/tests/ \
|
||||
--ignore=markitect/query_paradigms/tests/ \
|
||||
--ignore=markitect/graphql/tests/ \
|
||||
--ignore=markitect/plugins/tests/ 2>/dev/null || \
|
||||
PYTHONPATH=. $(VENV_PYTHON) -m unittest discover tests/ -v; \
|
||||
fi
|
||||
|
||||
# Capability-Specific Test Targets
|
||||
test-capabilities: test-capability-content test-capability-utils test-capability-finance test-capability-query test-capability-graphql test-capability-plugins
|
||||
@echo "✅ All capability tests completed"
|
||||
|
||||
test-capability-content: $(VENV)/bin/activate
|
||||
@echo "🧪 Running markitect-content capability tests..."
|
||||
@cd capabilities/markitect-content && python -m pytest tests/ -v
|
||||
|
||||
test-capability-utils: $(VENV)/bin/activate
|
||||
@echo "🧪 Running markitect-utils capability tests..."
|
||||
@cd capabilities/markitect-utils && python -m pytest tests/ -v
|
||||
|
||||
test-capability-finance: $(VENV)/bin/activate
|
||||
@echo "🧪 Running finance capability tests..."
|
||||
@PYTHONPATH=. $(VENV_PYTHON) -m pytest markitect/finance/tests/ -v
|
||||
|
||||
test-capability-query: $(VENV)/bin/activate
|
||||
@echo "🧪 Running query paradigms capability tests..."
|
||||
@PYTHONPATH=. $(VENV_PYTHON) -m pytest markitect/query_paradigms/tests/ -v
|
||||
|
||||
test-capability-graphql: $(VENV)/bin/activate
|
||||
@echo "🧪 Running GraphQL capability tests..."
|
||||
@PYTHONPATH=. $(VENV_PYTHON) -m pytest markitect/graphql/tests/ -v
|
||||
|
||||
test-capability-plugins: $(VENV)/bin/activate
|
||||
@echo "🧪 Running plugins capability tests..."
|
||||
@PYTHONPATH=. $(VENV_PYTHON) -m pytest markitect/plugins/tests/ -v
|
||||
|
||||
# TDD8 Workflow Optimized Test Targets (Issue #57)
|
||||
|
||||
# Fast test execution for TDD red phase
|
||||
test-red: $(VENV)/bin/activate
|
||||
@echo "🔴 TDD Red Phase - Fast test execution..."
|
||||
PYTHONPATH=. $(VENV_PYTHON) -m pytest tests/ -x --maxfail=1 --tb=short -q
|
||||
PYTHONPATH=. $(VENV_PYTHON) -m pytest tests/ -x --maxfail=1 --tb=short -q \
|
||||
--ignore=capabilities/markitect-content/tests/ \
|
||||
--ignore=capabilities/markitect-utils/tests/ \
|
||||
--ignore=markitect/finance/tests/ \
|
||||
--ignore=markitect/query_paradigms/tests/ \
|
||||
--ignore=markitect/graphql/tests/ \
|
||||
--ignore=markitect/plugins/tests/
|
||||
|
||||
# Comprehensive test execution for TDD green phase
|
||||
test-green: $(VENV)/bin/activate
|
||||
@echo "🟢 TDD Green Phase - Comprehensive validation..."
|
||||
PYTHONPATH=. $(VENV_PYTHON) -m pytest tests/ --tb=short
|
||||
PYTHONPATH=. $(VENV_PYTHON) -m pytest tests/ --tb=short \
|
||||
--ignore=capabilities/markitect-content/tests/ \
|
||||
--ignore=capabilities/markitect-utils/tests/ \
|
||||
--ignore=markitect/finance/tests/ \
|
||||
--ignore=markitect/query_paradigms/tests/ \
|
||||
--ignore=markitect/graphql/tests/ \
|
||||
--ignore=markitect/plugins/tests/
|
||||
|
||||
# Smart test selection - changed files only
|
||||
test-smart: $(VENV)/bin/activate
|
||||
@@ -349,12 +408,24 @@ test-smart: $(VENV)/bin/activate
|
||||
# Ultra-fast test execution
|
||||
test-ultra-fast: $(VENV)/bin/activate
|
||||
@echo "⚡ Ultra-fast test execution..."
|
||||
PYTHONPATH=. $(VENV_PYTHON) -m pytest tests/ -m "not slow" --maxfail=1 -x -q
|
||||
PYTHONPATH=. $(VENV_PYTHON) -m pytest tests/ -m "not slow" --maxfail=1 -x -q \
|
||||
--ignore=capabilities/markitect-content/tests/ \
|
||||
--ignore=capabilities/markitect-utils/tests/ \
|
||||
--ignore=markitect/finance/tests/ \
|
||||
--ignore=markitect/query_paradigms/tests/ \
|
||||
--ignore=markitect/graphql/tests/ \
|
||||
--ignore=markitect/plugins/tests/
|
||||
|
||||
# Test with performance monitoring
|
||||
test-perf: $(VENV)/bin/activate
|
||||
@echo "📊 Test execution with performance monitoring..."
|
||||
PYTHONPATH=. $(VENV_PYTHON) -m pytest tests/ --durations=10 --tb=short
|
||||
PYTHONPATH=. $(VENV_PYTHON) -m pytest tests/ --durations=10 --tb=short \
|
||||
--ignore=capabilities/markitect-content/tests/ \
|
||||
--ignore=capabilities/markitect-utils/tests/ \
|
||||
--ignore=markitect/finance/tests/ \
|
||||
--ignore=markitect/query_paradigms/tests/ \
|
||||
--ignore=markitect/graphql/tests/ \
|
||||
--ignore=markitect/plugins/tests/
|
||||
|
||||
# Test health check
|
||||
test-health: $(VENV)/bin/activate
|
||||
@@ -545,6 +616,27 @@ add-diary-entry:
|
||||
@echo ""
|
||||
@echo "💡 Tip: New entries are added to the top for reverse chronological order"
|
||||
|
||||
# Capability discovery and management targets
|
||||
capability-report: $(VENV)/bin/activate
|
||||
@echo "📋 Generating capability discovery report..."
|
||||
@$(VENV_PYTHON) tools/capability_discovery.py report
|
||||
|
||||
capability-search: $(VENV)/bin/activate
|
||||
@if [ -z "$(TERM)" ]; then \
|
||||
echo "❌ Please specify search term: make capability-search TERM=issue_management"; \
|
||||
exit 1; \
|
||||
fi
|
||||
@echo "🔍 Searching for '$(TERM)' across capabilities..."
|
||||
@$(VENV_PYTHON) tools/capability_discovery.py search "$(TERM)"
|
||||
|
||||
capability-validate: $(VENV)/bin/activate
|
||||
@if [ -z "$(FILE)" ]; then \
|
||||
echo "❌ Please specify file path: make capability-validate FILE=path/to/file.py"; \
|
||||
exit 1; \
|
||||
fi
|
||||
@echo "✅ Validating capability usage in $(FILE)..."
|
||||
@$(VENV_PYTHON) tools/capability_discovery.py validate "$(FILE)"
|
||||
|
||||
# Git repository and API configuration
|
||||
GITEA_URL := http://92.205.130.254:32166
|
||||
|
||||
|
||||
@@ -14,8 +14,8 @@ MarkiTect transforms markdown from plain text into intelligent, structured data
|
||||
|
||||
**Quick Start:** [Getting Started](#getting-started) · [Command Reference](docs/user-guides/cache-management.md)
|
||||
|
||||
**Architecture:** [Caching System](docs/architecture/caching-system.md) · [Performance Philosophy](docs/#performance-philosophy)
|
||||
**Architecture:** [Caching System](docs/architecture/caching-system.md) · [Performance Philosophy](docs/#performance-philosophy) · [Capability Inclusion](CAPABILITY_INCLUSION_GUIDE.md)
|
||||
|
||||
**Development:** [TDD Workflow](docs/development/tdd-workflow.md) · [Contributing](#contributing)
|
||||
**Development:** [TDD Workflow](docs/development/tdd-workflow.md) · [Contributing](#contributing) · [Capabilities Overview](CAPABILITIES.md)
|
||||
|
||||
**Project Status:** [Current Status](history/ProjectStatusDigest.md) · [Roadmap](history/ROADMAP.md) · [Next Actions](NEXT.md)
|
||||
**Project Status:** [Current Status](history/ProjectStatusDigest.md) · [Roadmap](history/ROADMAP.md) · [Current Tasks](TODO.md)
|
||||
|
||||
101
TODO.md
Normal file
101
TODO.md
Normal file
@@ -0,0 +1,101 @@
|
||||
# Todofile
|
||||
|
||||
This is a "to do next" file, particularly useful to keep the human and a coding assistant in sync.
|
||||
|
||||
The format is based on [Keep a Todofile V0.0.1](https://coulomb.social/open/KeepaTodofile).
|
||||
|
||||
The structure organizes **future tasks** by their impact, just as a changelog organizes past changes by their impact.
|
||||
|
||||
***
|
||||
|
||||
## [Unreleased] - *Active Vibe-Coding State* 💡
|
||||
|
||||
This section is for tasks currently being discussed with or worked on by the coding assistant. These are the ephemeral, flow-of-thought tasks.
|
||||
|
||||
* **To Add:**
|
||||
* Complete AST Query and Analysis CLI implementation (Issue #15)
|
||||
* Performance Validation CLI implementation (Issue #16)
|
||||
* Enhanced discovery tools validation and refinement
|
||||
* **To Refactor:**
|
||||
* Update any missing links in existing documentation to new capability system
|
||||
* Refine capability discovery workflow based on practical usage
|
||||
* Enhance AI assistant integration with capability system
|
||||
* **To Fix:**
|
||||
* Validate that CAPABILITY_DOCUMENTATION_INDEX.md provides effective navigation
|
||||
* Ensure all agents are aware of capability inclusion workflow
|
||||
* Test automated detection prevention of code duplication
|
||||
* **To Remove:**
|
||||
* Retire NEXT.md file after successful todofile migration
|
||||
* Clean up any outdated task management references
|
||||
|
||||
***
|
||||
|
||||
## [0.3.0] - Strategic Development Execution - *Next Planned Increment*
|
||||
|
||||
This version represents the next set of concrete, planned features focusing on strategic issue resolution and capability validation.
|
||||
|
||||
### To Add
|
||||
* **AST Query and Analysis CLI** - Complete implementation of Issue #15 with full AST parsing and analysis capabilities
|
||||
* **Performance Validation CLI** - Complete implementation of Issue #16 with comprehensive performance testing and metrics
|
||||
* **Enhanced Discovery Tools** - Improve `make capability-search TERM=xyz` based on real-world usage patterns
|
||||
* **Capability Integration Validation** - Test framework for ensuring capability inclusion workflow effectiveness
|
||||
|
||||
### To Refactor
|
||||
* **Documentation Ecosystem** - Update any missing links to new capability system components
|
||||
* **AI Assistant Integration** - Enhance capability reference utilization for informed decision-making
|
||||
* **Workflow Optimization** - Refine capability-first development process based on practical experience
|
||||
|
||||
### To Fix
|
||||
* **Documentation Navigation** - Ensure CAPABILITY_DOCUMENTATION_INDEX.md provides effective project navigation
|
||||
* **Agent Workflow Integration** - Validate all agents properly utilize capability inclusion workflow
|
||||
* **Duplication Prevention** - Test and improve automated detection systems
|
||||
|
||||
### To Secure
|
||||
* **Capability Validation** - Ensure capability inclusion system maintains security best practices
|
||||
* **Dependency Management** - Validate external capability references and security implications
|
||||
|
||||
### To Remove
|
||||
* **Legacy Task Management** - Retire NEXT.md approach in favor of standardized todofile system
|
||||
* **Outdated Documentation References** - Clean up any references to deprecated task management approaches
|
||||
|
||||
***
|
||||
|
||||
## [COMPLETED] - *Capability Inclusion Management System - Version 0.2.0*
|
||||
|
||||
### ✅ Completed: To Add
|
||||
* **Complete capability documentation ecosystem** - DONE
|
||||
- CAPABILITIES.md for internal capabilities with detailed descriptions
|
||||
- CAPABILITY_REGISTRY.md for external capabilities and dependencies
|
||||
- CAPABILITY_DOCUMENTATION_INDEX.md for navigation and discovery
|
||||
- CLAUDE_CAPABILITY_REFERENCE.md for AI assistant quick reference
|
||||
- CAPABILITY_INCLUSION_GUIDE.md for workflow and best practices
|
||||
* **Automated discovery tools** - DONE
|
||||
- `make capability-search TERM=xyz` for capability discovery
|
||||
- Prevention of code duplication through automated detection
|
||||
- Enhanced agent definitions with capability inclusion workflow
|
||||
* **Architectural clarity** - DONE
|
||||
- Clear separation of internal vs external capabilities
|
||||
- Comprehensive categorization system
|
||||
- Detailed capability documentation with examples
|
||||
|
||||
### ✅ Completed: To Refactor
|
||||
* **Agent definitions** - DONE
|
||||
- Enhanced all agents with capability inclusion workflow awareness
|
||||
- Updated agent instructions to utilize capability references
|
||||
- Improved AI assistant integration patterns
|
||||
|
||||
### ✅ Completed: To Fix
|
||||
* **Documentation ecosystem integration** - DONE
|
||||
- All capability files properly interconnected
|
||||
- Navigation system functional and comprehensive
|
||||
- Discovery tools working effectively
|
||||
|
||||
### ✅ Completed: To Secure
|
||||
* **Capability validation system** - DONE
|
||||
- Proper validation of capability inclusion workflow
|
||||
- Security considerations for external capability references
|
||||
|
||||
### ✅ Completed: To Remove
|
||||
* **Code duplication risks** - DONE
|
||||
- Implemented prevention mechanisms
|
||||
- Automated detection and discovery systems
|
||||
81
TODOFILE_GUIDE.md
Normal file
81
TODOFILE_GUIDE.md
Normal file
@@ -0,0 +1,81 @@
|
||||
# MarkiTect Todofile System
|
||||
|
||||
## Overview
|
||||
|
||||
MarkiTect uses the **Keep a Todofile V0.0.1** format for task management and development coordination. This replaces the previous NEXT.md approach with a standardized todofile system that provides better structure for maintaining coding flow and AI assistant coordination.
|
||||
|
||||
## Location and Format
|
||||
|
||||
- **Main Todofile**: `TODO.md` in the project root
|
||||
- **Format**: [Keep a Todofile V0.0.1](https://coulomb.social/open/KeepaTodofile)
|
||||
- **Agent Support**: Managed by the `agent-keepaTodofile` agent in the kaizen-agentic framework
|
||||
|
||||
## Structure
|
||||
|
||||
The todofile is organized by **impact type** rather than arbitrary priority:
|
||||
|
||||
### [Unreleased] - Active Vibe-Coding State 💡
|
||||
- **To Add**: New features, capabilities, or functionality
|
||||
- **To Refactor**: Code improvements and restructuring
|
||||
- **To Fix**: Bug fixes and error corrections
|
||||
- **To Remove**: Features or code to eliminate
|
||||
|
||||
### [Version] - Planned Increments
|
||||
Organized by planned version/milestone with the same impact categories:
|
||||
- **To Add**: Planned new functionality
|
||||
- **To Fix**: Scheduled bug fixes
|
||||
- **To Refactor**: Planned code improvements
|
||||
- **To Deprecate**: Features marked for future removal
|
||||
- **To Secure**: Security improvements
|
||||
- **To Remove**: Planned removals
|
||||
|
||||
## Integration with Project Workflow
|
||||
|
||||
### Task Management
|
||||
- Use `TODO.md` for active development tasks and immediate next steps
|
||||
- Link to Gitea issues for longer-term planning: `Related to issue #123`
|
||||
- Update during development sessions to maintain context
|
||||
|
||||
### AI Assistant Coordination
|
||||
- The todofile serves as a **shared source of truth** between human developers and AI assistants
|
||||
- Helps maintain context during interruptions and session transfers
|
||||
- Enables consistent progress tracking and decision-making
|
||||
|
||||
### Development Best Practices
|
||||
1. **Update Regularly**: Maintain current state during active development
|
||||
2. **Focus on Immediate**: Keep [Unreleased] section for current work
|
||||
3. **Plan Versions**: Use version sections for commit boundaries
|
||||
4. **Archive Completed**: Move completed items to archive sections
|
||||
5. **Link Issues**: Connect todofile items to Gitea issues for full context
|
||||
|
||||
## Agent Integration
|
||||
|
||||
The `agent-keepaTodofile` agent provides specialized support for:
|
||||
- Creating and maintaining TODO.md files following the official format
|
||||
- Organizing tasks by impact type (Add, Fix, Refactor, etc.)
|
||||
- Integrating with issue tracking and TDD workflows
|
||||
- Maintaining coding flow and context preservation
|
||||
- Converting between task management formats
|
||||
|
||||
## Migration from NEXT.md
|
||||
|
||||
The previous NEXT.md file has been archived to `history/NEXT_archived_YYYYMMDD.md`. All relevant content has been migrated to the new TODO.md format while preserving:
|
||||
- Strategic development priorities
|
||||
- Capability management workflows
|
||||
- Session success criteria
|
||||
- Development milestones
|
||||
|
||||
## Related Documentation
|
||||
|
||||
- **Agent Definition**: `agents/agent-keepaTodofile.md` - Specialized todofile management agent
|
||||
- **Context Documentation**: `capabilities/kaizen-agentic/context/KeepaTodofile.md` - Detailed format specification
|
||||
- **Capability Integration**: `CAPABILITY_INCLUSION_GUIDE.md` - How todofile fits with capability discovery
|
||||
- **Project Management**: `agents/agent-project-management.md` - Overall project coordination
|
||||
|
||||
## Benefits
|
||||
|
||||
1. **Standardized Format**: Follows established Keep a Todofile conventions
|
||||
2. **Better Organization**: Impact-based categorization aligns with changelog structure
|
||||
3. **AI Assistant Ready**: Designed for human-AI collaboration in coding sessions
|
||||
4. **Context Preservation**: Maintains coding flow across interruptions
|
||||
5. **Integration Ready**: Works with existing issue management and TDD workflows
|
||||
@@ -17,7 +17,7 @@ You are the MarkiTect project assistant, specialized in providing project status
|
||||
|
||||
- **ProjectStatusDigest.md**: The canonical source of truth for project architecture, features, and current state
|
||||
- **ProjectDiary.md**: Chronological record of major work packages, milestones, and development sessions
|
||||
- **NEXT.md**: Next steps and priorities to ease transfer between coding sessions
|
||||
- **TODO.md**: Task management and priorities following Keep a Todofile format for maintaining coding flow
|
||||
- **Makefile**: Provides helpers to use and improve the capabilities provided by the project
|
||||
**Gitea Issues**: Backlog of issues and backlog of tasks stored as issues in gitea
|
||||
|
||||
@@ -33,6 +33,13 @@ You are the MarkiTect project assistant, specialized in providing project status
|
||||
- Issue management via universal issue-facade CLI that works with multiple backends
|
||||
- All commits require green test state
|
||||
|
||||
**Capability Inclusion Management:**
|
||||
- **Internal Capabilities**: See `CAPABILITIES.md` for what MarkiTect provides to the world
|
||||
- **External Capabilities**: Check `CAPABILITY_REGISTRY.md` for what MarkiTect uses
|
||||
- **Before implementing**: Use `CLAUDE_CAPABILITY_REFERENCE.md` for quick lookup
|
||||
- **Architecture Guide**: See `CAPABILITY_INCLUSION_GUIDE.md` for complete workflow
|
||||
- **Discovery Tools**: `make capability-search TERM=xyz` to find existing functionality
|
||||
|
||||
**Issue Management Protocol:**
|
||||
- **Gitea-First**: Feature requests, bugs, and enhancements should be documented as Gitea issues
|
||||
- **Issue Creation**: When new requirements emerge, create issues in Gitea immediately but do NOT implement immediately
|
||||
@@ -41,7 +48,7 @@ You are the MarkiTect project assistant, specialized in providing project status
|
||||
- **Issue Workflow**: Create → Triage → Plan → Schedule → Implement → Close
|
||||
|
||||
**TDD Workflow Management:**
|
||||
- For issue management tasks, use the **issue-facade** system located in `issue-facade/`
|
||||
- For issue management tasks, use the **issue-facade** system located in `capabilities/issue-facade/`
|
||||
- The issue-facade provides unified CLI for GitHub, GitLab, Gitea, and local SQLite backends
|
||||
- This includes sidequest management, test planning, and comprehensive development workflow guidance
|
||||
|
||||
@@ -118,7 +125,7 @@ When asked to help wrap up a development session, follow this standardized routi
|
||||
|
||||
### End-of-Session Checklist:
|
||||
1. **Update ProjectDiary.md**: Add entry documenting progress, challenges, and achievements
|
||||
2. **Update NEXT.md**: Set clear priorities and strategy for next session
|
||||
2. **Update TODO.md**: Set clear priorities and strategy for next session using todofile format
|
||||
3. **Update ProjectStatusDigest.md**: Refresh current status, metrics, and completed features
|
||||
4. **Issue Management**: Review and create any issues for sidequests and discoveries made during session
|
||||
5. **Anchor patterns**: Update this project-assistant definition with any new workflow patterns
|
||||
|
||||
@@ -117,7 +117,7 @@ python tools/requirements_engineering_toolkit.py validate-mocks --test-file test
|
||||
# Enhanced Makefile targets
|
||||
issue-start: validate-requirements
|
||||
# Use issue-facade for issue management
|
||||
cd issue-facade && python -m cli.main show $(NUM)
|
||||
cd capabilities/issue-facade && python -m cli.main show $(NUM)
|
||||
|
||||
validate-requirements:
|
||||
python tools/requirements_engineering_toolkit.py analyze
|
||||
@@ -456,7 +456,7 @@ validate-requirements:
|
||||
|
||||
issue-start: validate-requirements
|
||||
# Use issue-facade for issue management
|
||||
cd issue-facade && python -m cli.main show $(NUM)
|
||||
cd capabilities/issue-facade && python -m cli.main show $(NUM)
|
||||
```
|
||||
|
||||
### Tool Dependencies
|
||||
|
||||
@@ -99,10 +99,15 @@ The **TDD8 cycle** is an 8-step comprehensive development workflow that extends
|
||||
You are the authoritative guide for the TDD8 workflow using the issue-facade system for issue management. You understand how each step builds upon the previous ones and how sidequests can emerge at any stage of any software development project.
|
||||
|
||||
**Primary Issue Management Commands:**
|
||||
- Issue management via issue-facade: `cd issue-facade && python -m cli.main list`
|
||||
- `cd issue-facade && python -m cli.main show ISSUE_NUM` - Show issue details
|
||||
- `cd issue-facade && python -m cli.main create "Title" "Description"` - Create new issue
|
||||
- `cd issue-facade && python -m cli.main close ISSUE_NUM` - Close completed issue
|
||||
- Issue management via issue-facade: `cd capabilities/issue-facade && python -m cli.main list`
|
||||
- `cd capabilities/issue-facade && python -m cli.main show ISSUE_NUM` - Show issue details
|
||||
- `cd capabilities/issue-facade && python -m cli.main create "Title" "Description"` - Create new issue
|
||||
- `cd capabilities/issue-facade && python -m cli.main close ISSUE_NUM` - Close completed issue
|
||||
|
||||
**Capability Awareness:**
|
||||
- **Before implementing**: Check `CAPABILITY_REGISTRY.md` for existing functionality
|
||||
- **Use existing capabilities**: Never reimplement issue management, content parsing, or utilities
|
||||
- **Capability discovery**: Use `make capability-search TERM=function_name` to find existing implementations
|
||||
|
||||
**Supporting Commands:**
|
||||
- `make test-coverage` - Analyze test coverage
|
||||
@@ -111,7 +116,7 @@ You are the authoritative guide for the TDD8 workflow using the issue-facade sys
|
||||
- Tea CLI: `tea issue show NUM` - Show detailed view of specific issue
|
||||
|
||||
### Workspace Management Understanding
|
||||
You understand the project structure with issue-facade for issue management:
|
||||
You understand the project structure with capabilities/issue-facade for issue management:
|
||||
```
|
||||
{workspace_dir}/
|
||||
├── current_issue.json # Active issue metadata
|
||||
@@ -152,7 +157,7 @@ You understand the project structure with issue-facade for issue management:
|
||||
|
||||
### TDDAi Framework Components
|
||||
**Core Infrastructure:**
|
||||
- `issue-facade/` - Universal issue management facade
|
||||
- `capabilities/issue-facade/` - Universal issue management facade
|
||||
- `workspace.py` - Workspace management
|
||||
- `issue_fetcher.py` - Issue API integration
|
||||
- `issue_writer.py` - Issue updates via PATCH
|
||||
|
||||
1
capabilities/kaizen-agentic
Submodule
1
capabilities/kaizen-agentic
Submodule
Submodule capabilities/kaizen-agentic added at 1e0ff82d74
@@ -35,7 +35,7 @@ Documentation for contributors and developers extending MarkiTect.
|
||||
### Project Management
|
||||
- [Project Status](../history/ProjectStatusDigest.md) - Current development status
|
||||
- [Roadmap](../history/ROADMAP.md) - Strategic development plan
|
||||
- [Next Actions](../NEXT.md) - Immediate development priorities
|
||||
- [Current Tasks](../TODO.md) - Task management using Keep a Todofile format
|
||||
|
||||
## Key Concepts
|
||||
|
||||
|
||||
124
history/NEXT_archived_20251025.md
Normal file
124
history/NEXT_archived_20251025.md
Normal file
@@ -0,0 +1,124 @@
|
||||
# MarkiTect - Next Session Priorities
|
||||
|
||||
**Updated:** 2025-10-25
|
||||
**Status:** Capability Inclusion Management System Complete
|
||||
**Next Focus:** Strategic Development Execution
|
||||
|
||||
## High Priority (Next Session Focus)
|
||||
|
||||
### 1. Strategic Issue Resolution 🎯
|
||||
**Priority: CRITICAL**
|
||||
- Resume work on core functionality backlog
|
||||
- Target: Issue #15 (AST Query and Analysis CLI) or Issue #16 (Performance Validation CLI)
|
||||
- Use new capability inclusion workflow to prevent duplication
|
||||
- Leverage CLAUDE_CAPABILITY_REFERENCE.md for quick capability lookup
|
||||
|
||||
### 2. Capability Management Validation 🔍
|
||||
**Priority: HIGH**
|
||||
- Test the new discovery tools (`make capability-search TERM=xyz`) in real development
|
||||
- Validate workflow effectiveness during actual implementation
|
||||
- Refine documentation based on practical usage
|
||||
- Ensure AI assistants properly utilize the new capability references
|
||||
|
||||
### 3. Documentation Integration ✅
|
||||
**Priority: MEDIUM**
|
||||
- Update any missing links in existing documentation to new capability system
|
||||
- Ensure all agents are aware of capability inclusion workflow
|
||||
- Validate that CAPABILITY_DOCUMENTATION_INDEX.md provides effective navigation
|
||||
|
||||
## Development Strategy
|
||||
|
||||
### Capability-First Development
|
||||
1. **Before implementing anything new:**
|
||||
- Check CAPABILITIES.md for internal capabilities
|
||||
- Check CAPABILITY_REGISTRY.md for external capabilities
|
||||
- Use `make capability-search TERM=xyz` for discovery
|
||||
- Consult CLAUDE_CAPABILITY_REFERENCE.md for patterns
|
||||
|
||||
2. **During implementation:**
|
||||
- Update capability documentation if creating new capabilities
|
||||
- Follow CAPABILITY_INCLUSION_GUIDE.md workflow
|
||||
- Document any new external dependencies in CAPABILITY_REGISTRY.md
|
||||
|
||||
3. **After implementation:**
|
||||
- Update CAPABILITIES.md if internal capabilities were added
|
||||
- Ensure proper categorization in documentation ecosystem
|
||||
|
||||
### Next Major Milestones
|
||||
|
||||
#### Immediate (1-2 Sessions)
|
||||
- **Complete Issue #15 or #16**: Demonstrate capability management system in practice
|
||||
- **Validate Discovery Tools**: Ensure automated detection prevents duplication
|
||||
- **Refine Workflow**: Based on real-world usage patterns
|
||||
|
||||
#### Short Term (3-5 Sessions)
|
||||
- **Schema-Driven Architecture**: Issues #5, #7, #8 (Milestone #2)
|
||||
- **Template Generation**: Issue #6 (Milestone #3)
|
||||
- **Advanced Querying**: Complete AST analysis capabilities
|
||||
|
||||
#### Medium Term (6-10 Sessions)
|
||||
- **Document Relationships**: Issue #4, advanced relationship mapping
|
||||
- **Performance Optimization**: Based on Issue #16 implementation
|
||||
- **Plugin Architecture**: Issue #19 and extensibility framework
|
||||
|
||||
## Session Success Criteria
|
||||
|
||||
### Must Achieve
|
||||
- [ ] Complete one core functionality issue using capability inclusion workflow
|
||||
- [ ] Demonstrate prevention of code duplication through discovery tools
|
||||
- [ ] Validate documentation ecosystem effectiveness
|
||||
|
||||
### Should Achieve
|
||||
- [ ] Update capability documentation with any new functionality
|
||||
- [ ] Refine workflow based on practical experience
|
||||
- [ ] Maintain green test state throughout development
|
||||
|
||||
### Could Achieve
|
||||
- [ ] Begin next milestone planning
|
||||
- [ ] Enhance discovery tools based on usage patterns
|
||||
- [ ] Improve AI assistant integration with capability system
|
||||
|
||||
## Known Context
|
||||
|
||||
### Current State
|
||||
- **Capability Management**: Complete documentation ecosystem established
|
||||
- **Discovery Tools**: Automated prevention of code duplication
|
||||
- **Architectural Clarity**: Clear separation of internal vs external capabilities
|
||||
- **Test State**: All tests passing (last known: 348 tests across 27 files)
|
||||
- **Git State**: Modified files ready for commit (capability inclusion system)
|
||||
|
||||
### Available Resources
|
||||
- **Complete capability documentation** in 5 interconnected files
|
||||
- **Automated discovery tools** via Makefile targets
|
||||
- **Enhanced agent definitions** with capability inclusion workflow
|
||||
- **Comprehensive test coverage** across all components
|
||||
|
||||
### Development Environment
|
||||
- **Ubuntu 24.04** with complete development environment
|
||||
- **Python virtual environment** properly configured
|
||||
- **Git submodules** (issue-facade, wiki) properly integrated
|
||||
- **All dependencies** installed and validated
|
||||
|
||||
## Next Session Preparation
|
||||
|
||||
### Pre-Session Setup
|
||||
1. Ensure git status is clean (commit capability inclusion system)
|
||||
2. Run `make test` to validate green state
|
||||
3. Review CLAUDE_CAPABILITY_REFERENCE.md for quick capability overview
|
||||
4. Select target issue for implementation
|
||||
|
||||
### Session Approach
|
||||
1. **Start with capability discovery** before any implementation
|
||||
2. **Use new workflow** from CAPABILITY_INCLUSION_GUIDE.md
|
||||
3. **Document any new capabilities** as they're created
|
||||
4. **Validate discovery tools** prevent accidental duplication
|
||||
|
||||
### Success Indicators
|
||||
- New functionality implemented without duplicating existing capabilities
|
||||
- Discovery tools successfully prevent code duplication
|
||||
- Documentation ecosystem proves valuable for development efficiency
|
||||
- AI assistants effectively use capability references for informed decisions
|
||||
|
||||
---
|
||||
|
||||
> **Note**: This file should be updated at the end of each session to maintain clear priorities and context for the next session. Use the capability inclusion management system as the foundation for all future development decisions.
|
||||
@@ -4,6 +4,28 @@ This diary tracks major work packages, events, and milestones in the MarkiTect p
|
||||
|
||||
---
|
||||
|
||||
## 2025-10-25: COMPREHENSIVE CAPABILITY INCLUSION MANAGEMENT SYSTEM ⭐ ARCHITECTURE MILESTONE ⭐
|
||||
|
||||
**Progress:** Successfully implemented comprehensive capability inclusion management system with clear separation of internal vs external capabilities
|
||||
**Contributors:** User (bernd.worsch), Claude Code (Sonnet 4)
|
||||
**Architecture Milestone:** Capability Inclusion Management System ✅ ACHIEVED (complete documentation ecosystem with discovery tools)
|
||||
**Total Development Time:** ~2-3 hours of intensive system design and documentation
|
||||
**AI Resources:** ~20-25 Claude Sonnet 4 conversations, estimated 40K+ tokens
|
||||
|
||||
**CAPABILITY INCLUSION BREAKTHROUGH:** Implemented revolutionary capability inclusion management system addressing the critical need to prevent code duplication and ensure proper separation of concerns. Created comprehensive documentation ecosystem with clear distinction between **internal capabilities** (what MarkiTect provides to the world) and **external capabilities** (what MarkiTect uses). This system provides developers and AI assistants with immediate visibility into existing functionality, preventing accidental reimplementation and enabling informed architectural decisions.
|
||||
|
||||
**COMPREHENSIVE DOCUMENTATION ECOSYSTEM:** Created five interconnected documentation files: (1) **CAPABILITIES.md** - Complete inventory of 73+ internal capabilities that MarkiTect provides, (2) **CAPABILITY_REGISTRY.md** - Registry of all external capabilities that MarkiTect uses (submodules, dependencies, extracted components), (3) **CAPABILITY_INCLUSION_GUIDE.md** - Complete workflow guide for managing capability inclusion decisions, (4) **CAPABILITY_DOCUMENTATION_INDEX.md** - Navigation hub linking all capability documentation, (5) **CLAUDE_CAPABILITY_REFERENCE.md** - Quick reference for AI assistants with search patterns and discovery tools.
|
||||
|
||||
**AUTOMATED DISCOVERY INFRASTRUCTURE:** Implemented sophisticated discovery tools preventing code duplication: `make capability-search TERM=xyz` for finding existing functionality across the codebase, integration with existing `make find-capability` and `make find-function` targets, comprehensive search patterns covering code, documentation, and test files, and automated capability detection preventing accidental reimplementation. Enhanced project-assistant agent definition with capability inclusion workflow guidelines.
|
||||
|
||||
**ARCHITECTURAL SEPARATION CLARITY:** Established clear architectural boundaries with **Internal Capabilities** (CAPABILITIES.md) focusing on what MarkiTect provides - the 73+ distinct capabilities including database-driven AST processing, multi-layer caching, Git platform integration, and comprehensive CLI interface. **External Capabilities** (CAPABILITY_REGISTRY.md) documenting what MarkiTect uses - git submodules (issue-facade, wiki), extracted components, package dependencies, and integration patterns. This separation enables clear understanding of system boundaries and dependency relationships.
|
||||
|
||||
**WORKFLOW INTEGRATION SUCCESS:** Updated all relevant documentation and agent definitions with capability inclusion workflow, enhanced README.md with clear links to capability documentation, integrated discovery tools with existing Makefile infrastructure, and provided comprehensive guidance for future development decisions. The system seamlessly integrates with existing development workflows while providing new safeguards against code duplication.
|
||||
|
||||
**STRATEGIC DEVELOPMENT IMPACT:** This system transforms MarkiTect development from ad-hoc capability implementation to systematic capability management. Before this session: unclear boundaries between internal/external capabilities, potential for code duplication, no systematic discovery tools. After this session: **Complete capability management platform**, **Clear architectural boundaries**, **Automated discovery preventing duplication**, **Comprehensive documentation ecosystem**, **AI-assistant optimized workflows**. This establishes MarkiTect as a mature project with enterprise-grade capability management.
|
||||
|
||||
---
|
||||
|
||||
|
||||
## 2025-10-02: PERFORMANCE TRACKING IMPLEMENTATION
|
||||
|
||||
|
||||
252
history/ProjectStatusDigest.md
Normal file
252
history/ProjectStatusDigest.md
Normal file
@@ -0,0 +1,252 @@
|
||||
# MarkiTect Project - Status Digest
|
||||
|
||||
**Version:** 0.2.0
|
||||
**Last Updated:** 2025-10-25
|
||||
**Development Status:** 🚀 **Capability Inclusion Management System Complete - Enterprise-Grade Architecture**
|
||||
**Tagline:** "Your Markdown, Redefined"
|
||||
|
||||
## Core Vision
|
||||
|
||||
Transform Markdown from plain text into intelligent, structured, reusable data with schema validation and automation capabilities.
|
||||
|
||||
## Architecture Overview
|
||||
|
||||
### MarkiTect Library (Python Core) ✅ **Foundation Complete**
|
||||
- **Reusable Python package** designed for CLI, service offerings, and third-party integration
|
||||
- **TDD approach** with comprehensive test coverage and pytest framework (348+ tests passing)
|
||||
- **Modern packaging** using `pyproject.toml` with dependencies: `markdown-it-py`, `PyYAML`
|
||||
- **Core modules implemented**: Database, front matter parsing, AST processing, caching system
|
||||
- **Capability inclusion management** with automated discovery and duplication prevention
|
||||
|
||||
### Capability Management System ✅ **REVOLUTIONARY ACHIEVEMENT**
|
||||
- **Complete capability documentation ecosystem** with 5 interconnected documentation files
|
||||
- **Clear separation**: Internal capabilities (what MarkiTect provides) vs External capabilities (what MarkiTect uses)
|
||||
- **Automated discovery tools** preventing code duplication (`make capability-search TERM=xyz`)
|
||||
- **AI-assistant optimized** workflow with CLAUDE_CAPABILITY_REFERENCE.md
|
||||
- **Architectural boundary clarity** ensuring proper separation of concerns
|
||||
- **73+ documented internal capabilities** with comprehensive categorization
|
||||
|
||||
### TDD Infrastructure (tddai Library) ✅ **Fully Operational**
|
||||
- **Complete TDD workspace management** with validated Python library architecture
|
||||
- **Issue-driven development** with proven Gitea API integration
|
||||
- **AI-assisted test generation** framework for automated TDD workflows (validated)
|
||||
- **Test coverage assessment system** with accurate requirement extraction and gap analysis
|
||||
- **Workspace lifecycle management** from issue creation to test integration
|
||||
- **CLI interface** (`tddai_cli.py`) for seamless command-line operations
|
||||
|
||||
### MarkiTect CLI (Command-Line Interface) ✅ **Production Ready**
|
||||
- **Complete CLI implementation** with Click framework integration
|
||||
- **Core commands**: `ingest`, `status`, `list`, `get`, `modify` - all fully functional
|
||||
- **Database query commands**: `query`, `query-files`, `query-sections` for powerful data access
|
||||
- **Cache management commands**: `cache-info`, `cache-clean`, `cache-invalidate` for performance control
|
||||
- **Document manipulation**: `--add-section`, `--update-front-matter` for AST modifications
|
||||
- **Performance optimization**: AST cache system with 60-85% faster processing
|
||||
- **Roundtrip validation**: Complete add → modify → get → verify workflow
|
||||
|
||||
## 🎯 **Current Development Status**
|
||||
|
||||
### ✅ **Major Milestones Completed**
|
||||
- **Issue #1**: Database initialization and front matter parsing (9 tests)
|
||||
- **Issue #2**: Fast Document Loading & CLI Manipulation ⭐ **MAJOR** (11 tests)
|
||||
- **Issue #12**: CLI Entry Point and Basic Commands (part of comprehensive test suite)
|
||||
- **Issue #13**: Cache Management CLI Commands ⭐ **MAJOR** (15 tests) - TDD8 Complete
|
||||
- **Issue #14**: Database Query CLI Interface ⭐ **MAJOR** (35 tests) - TDD8 Complete
|
||||
- **TDD Infrastructure**: Complete workflow automation (32+ tests)
|
||||
- **CLI Implementation Milestone**: ✅ **COMPLETED** - All CLI core functionality delivered
|
||||
- **Capability Inclusion Management**: ✅ **COMPLETED** - Revolutionary architecture milestone
|
||||
- **Total Foundation**: 348+ tests passing across 27 test files
|
||||
|
||||
### 🚀 **Strategic Roadmap Active**
|
||||
**4 Subprojects targeting HolyGrailRequirement (arc42 documentation system)**
|
||||
|
||||
#### **Subproject 1: Schema-Driven Architecture** (Milestone #2)
|
||||
- Issue #5: Generate Schema from Markdown File (HIGH)
|
||||
- Issue #7: Validate Markdown Against Schema (HIGH)
|
||||
- Issue #8: Get Validation Errors (HIGH)
|
||||
|
||||
#### **Subproject 2: Template & Stub Generation** (Milestone #3)
|
||||
- Issue #6: Generate Markdown Stub from Schema (HIGH)
|
||||
|
||||
#### **Subproject 3: Document Relationships** (Milestone #4)
|
||||
- Issue #4: Retrieve All Stored Files (MEDIUM)
|
||||
- Issue #15: AST Query and Analysis CLI (CRITICAL)
|
||||
|
||||
#### **Subproject 4: Plan-Actual Comparison Engine** (Milestone #5)
|
||||
- Issue #9: Expose GraphQL Read Interface (LOW)
|
||||
- Issue #10: Expose GraphQL Write Interface (LOW)
|
||||
- ✅ Issue #16: Performance Validation CLI (COMPLETED) - All 5 CLI commands implemented with 81.4/100 performance baseline
|
||||
|
||||
### 🎯 **Next Priority**
|
||||
- **Strategic Issue Implementation** using new capability inclusion workflow
|
||||
- **Capability Management Validation** through real-world usage
|
||||
- **Schema-Driven Architecture** milestone preparation with duplication prevention
|
||||
|
||||
### 📊 **Metrics**
|
||||
- **Test Coverage**: 100% for implemented features (348+ tests across 27 files)
|
||||
- **Code Quality**: Modern Python practices with type hints and comprehensive error handling
|
||||
- **Documentation**: Revolutionary capability management ecosystem with 5 interconnected files
|
||||
- **Development Velocity**: Enhanced with automated duplication prevention
|
||||
- **Architecture Maturity**: Enterprise-grade capability inclusion management
|
||||
|
||||
## Key Features & Components
|
||||
|
||||
### Core Functionality
|
||||
- **AbstractSyntaxTree** processing and manipulation with comprehensive caching
|
||||
- **MarkdownParser** using `markdown-it-py` for detailed AST generation
|
||||
- **JsonSchemaValidator** for enforcing document structure
|
||||
- **ChunkInclusion** system for modular content composition
|
||||
- **StaticSiteGenerator** integration capabilities
|
||||
- **Capability Inclusion Management** preventing code duplication
|
||||
|
||||
### Capability Management (NEW)
|
||||
- **Internal Capability Inventory** (CAPABILITIES.md) - 73+ capabilities provided by MarkiTect
|
||||
- **External Capability Registry** (CAPABILITY_REGISTRY.md) - Dependencies and submodules used by MarkiTect
|
||||
- **Automated Discovery Tools** - `make capability-search TERM=xyz` for existing functionality detection
|
||||
- **AI-Assistant Integration** - CLAUDE_CAPABILITY_REFERENCE.md for informed development decisions
|
||||
- **Workflow Documentation** - CAPABILITY_INCLUSION_GUIDE.md for systematic capability management
|
||||
|
||||
### Schema Operations
|
||||
- **Generate schemas** from existing Markdown at specified nesting depths
|
||||
- **Validate Markdown** against defined schemas
|
||||
- **Generate stub files** from schemas with placeholder content
|
||||
- **InclusionStub** handling for modular document architecture
|
||||
|
||||
### GraphQL Interface
|
||||
- **Query operations** for retrieving Markdown files, schemas, and AST data
|
||||
- **Mutation operations** for adding/updating content in database
|
||||
- **Real-time validation** and schema checking
|
||||
|
||||
## Development Approach
|
||||
|
||||
### Capability-First Development (NEW)
|
||||
- **Before implementing**: Check existing capabilities via discovery tools
|
||||
- **During implementation**: Follow CAPABILITY_INCLUSION_GUIDE.md workflow
|
||||
- **After implementation**: Update capability documentation ecosystem
|
||||
- **Automated prevention**: Code duplication detection and architectural boundary enforcement
|
||||
|
||||
### Test-Driven Development
|
||||
- **Complete TDD infrastructure** with `tddai` Python library
|
||||
- **Issue-driven workflow** with workspace management (`tdd-start`, `tdd-add-test`, `tdd-status`, `tdd-finish`)
|
||||
- **348+ passing tests** across 27 test files using pytest with proper behavior-based testing
|
||||
- **AI-assisted test generation** integrated into development cycle
|
||||
- **Green-state validation** before all commits
|
||||
|
||||
### Markdown Feature Support (MF-1 through MF-10)
|
||||
Complete specification coverage including:
|
||||
- Headings and sections structure
|
||||
- Text formatting (bold, italic, strikethrough)
|
||||
- Lists (ordered, unordered, task lists)
|
||||
- Links, images, and media handling
|
||||
- Code blocks and syntax highlighting
|
||||
- Tables and complex formatting
|
||||
- Footnotes and reference systems
|
||||
|
||||
## Project Status
|
||||
|
||||
### Current State
|
||||
- **Capability inclusion management system complete** with comprehensive documentation ecosystem
|
||||
- **TDD infrastructure complete** with robust Python library architecture
|
||||
- **Issue-driven development workflow** fully operational with capability management integration
|
||||
- **Comprehensive test suite** with 348+ passing tests across 27 files
|
||||
- **Build system** with sophisticated Makefile and virtual environment integration
|
||||
- **AI-assisted development** cycle with capability-aware workspace management
|
||||
- **Enterprise-grade architecture** with automated duplication prevention
|
||||
|
||||
### Social Integration
|
||||
- **CoulombSocial participation** since September 2025
|
||||
- **Gitea issues integration** with API-driven workflow management
|
||||
- **Open-source development** model with collaborative wiki
|
||||
- **Issue-to-test automation** for structured development cycles
|
||||
- **Capability-driven collaboration** with clear architectural boundaries
|
||||
|
||||
## Technical Foundation
|
||||
|
||||
### Development Tools
|
||||
- **Python 3.8+** with modern tooling (Black, Ruff, mypy, pytest)
|
||||
- **Make-based workflow** with intelligent environment detection and capability management integration
|
||||
- **Git submodules** for wiki documentation and issue-facade management
|
||||
- **tddai library** for complete TDD workspace automation
|
||||
- **Capability discovery tools** with automated duplication prevention
|
||||
- **Issue management** with Gitea API integration and CLI tools
|
||||
- **Custom subagent ecosystem** enhanced with capability inclusion workflow
|
||||
- **Automated dependency management** with comprehensive installation scripts
|
||||
|
||||
### Brand Identity
|
||||
- **Professional visual identity** with 3D "M" logo incorporating Markdown symbols
|
||||
- **Color palette**: Deep teal/navy (primary), vibrant orange, lime green
|
||||
- **Core pillars**: Structural Integrity, Consistency, Reusability, Automation, Capability Management
|
||||
|
||||
## Repository Structure
|
||||
|
||||
```
|
||||
markitect_project/
|
||||
├── markitect/ # Main Python package
|
||||
├── tddai/ # TDD infrastructure library
|
||||
├── tests/ # Comprehensive test suite (348+ tests across 27 files)
|
||||
├── issue-facade/ # Git submodule for issue management
|
||||
├── wiki/ # Git submodule with comprehensive documentation
|
||||
│
|
||||
├── CAPABILITIES.md # Internal capabilities inventory (73+ capabilities)
|
||||
├── CAPABILITY_REGISTRY.md # External capabilities registry
|
||||
├── CAPABILITY_INCLUSION_GUIDE.md # Workflow guide for capability management
|
||||
├── CAPABILITY_DOCUMENTATION_INDEX.md # Navigation hub for capability docs
|
||||
├── CLAUDE_CAPABILITY_REFERENCE.md # AI assistant quick reference
|
||||
│
|
||||
├── agents/ # Enhanced project management agents
|
||||
├── Makefile # Development workflow with capability management
|
||||
├── pyproject.toml # Python package configuration
|
||||
├── NEXT.md # Next session priorities and strategy
|
||||
├── history/ProjectDiary.md # Development milestone tracking
|
||||
└── README.md # Project overview with capability links
|
||||
```
|
||||
|
||||
## Getting Started
|
||||
|
||||
1. **Environment Setup:**
|
||||
```bash
|
||||
sudo ./install-depends.sh # Install system dependencies (Ubuntu 24.04)
|
||||
./install-pip.sh # Install Python dependencies and package
|
||||
make venv-status # Check environment activation state
|
||||
```
|
||||
|
||||
2. **Development Workflow:**
|
||||
```bash
|
||||
make test # Run comprehensive test suite (348+ tests)
|
||||
make update # Pull latest changes from upstream
|
||||
make status # Check git status
|
||||
```
|
||||
|
||||
3. **Capability Management (NEW):**
|
||||
```bash
|
||||
make capability-search TERM=xyz # Find existing functionality
|
||||
make find-capability TERM=xyz # Alternative search method
|
||||
# Before implementing, check CAPABILITIES.md and CAPABILITY_REGISTRY.md
|
||||
```
|
||||
|
||||
4. **TDD Workflow:**
|
||||
```bash
|
||||
make tdd-start NUM=X # Start working on issue X
|
||||
make tdd-add-test # Generate tests for current issue
|
||||
make tdd-status # Check workspace status
|
||||
make tdd-finish # Complete issue and integrate tests
|
||||
```
|
||||
|
||||
5. **Issue Management:**
|
||||
```bash
|
||||
make list-issues # Show all Gitea issues
|
||||
make list-open-issues # Show active backlog
|
||||
make show-issue NUM=X # Detailed issue view
|
||||
make test-coverage NUM=X # Analyze test coverage for issue
|
||||
```
|
||||
|
||||
6. **Building:**
|
||||
```bash
|
||||
make build # Build the package
|
||||
make clean # Clean build artifacts
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
MarkiTect represents a significant evolution toward treating documentation as **structured, validatable, and reusable data** rather than simple text files, with robust tooling for large-scale content management, automation, and **enterprise-grade capability inclusion management** that prevents code duplication and ensures architectural clarity.
|
||||
|
||||
> **Note:** This digest is maintained using Claude Code with capability-aware development workflows. Run `make update-digest` to refresh with latest project information.
|
||||
@@ -11,7 +11,7 @@ from pathlib import Path
|
||||
from typing import Optional
|
||||
|
||||
# Base version from pyproject.toml
|
||||
__version__ = "0.2.0"
|
||||
__version__ = "0.3.0"
|
||||
|
||||
def get_git_commit_hash() -> Optional[str]:
|
||||
"""Get the current git commit hash if available."""
|
||||
|
||||
0
markitect/finance/tests/__init__.py
Normal file
0
markitect/finance/tests/__init__.py
Normal file
0
markitect/graphql/tests/__init__.py
Normal file
0
markitect/graphql/tests/__init__.py
Normal file
0
markitect/plugins/tests/__init__.py
Normal file
0
markitect/plugins/tests/__init__.py
Normal file
0
markitect/query_paradigms/tests/__init__.py
Normal file
0
markitect/query_paradigms/tests/__init__.py
Normal file
@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
|
||||
|
||||
[project]
|
||||
name = "markitect"
|
||||
version = "0.2.0"
|
||||
version = "0.3.0"
|
||||
description = "Advanced Markdown engine for structured content"
|
||||
readme = "README.md"
|
||||
requires-python = ">=3.8"
|
||||
|
||||
292
tools/capability_discovery.py
Executable file
292
tools/capability_discovery.py
Executable file
@@ -0,0 +1,292 @@
|
||||
#!/usr/bin/env python3
|
||||
"""
|
||||
Capability Discovery Tool
|
||||
|
||||
Provides automated discovery and validation of included capabilities
|
||||
to prevent code duplication and ensure proper capability usage.
|
||||
"""
|
||||
|
||||
import os
|
||||
import json
|
||||
import subprocess
|
||||
from pathlib import Path
|
||||
from typing import Dict, List, Optional, Tuple
|
||||
|
||||
|
||||
class CapabilityDiscovery:
|
||||
"""Tool for discovering and validating included capabilities."""
|
||||
|
||||
def __init__(self, project_root: str = "."):
|
||||
self.project_root = Path(project_root).resolve()
|
||||
self.capabilities = {}
|
||||
self._discover_capabilities()
|
||||
|
||||
def _discover_capabilities(self):
|
||||
"""Discover all available capabilities."""
|
||||
# Submodule capabilities
|
||||
self._discover_submodules()
|
||||
|
||||
# Local capabilities
|
||||
self._discover_local_capabilities()
|
||||
|
||||
# External dependencies
|
||||
self._discover_external_dependencies()
|
||||
|
||||
def _discover_submodules(self):
|
||||
"""Discover git submodule capabilities."""
|
||||
gitmodules_path = self.project_root / ".gitmodules"
|
||||
if not gitmodules_path.exists():
|
||||
return
|
||||
|
||||
with open(gitmodules_path, 'r') as f:
|
||||
content = f.read()
|
||||
|
||||
# Parse submodules
|
||||
submodules = []
|
||||
current_submodule = {}
|
||||
|
||||
for line in content.split('\n'):
|
||||
line = line.strip()
|
||||
if line.startswith('[submodule'):
|
||||
if current_submodule:
|
||||
submodules.append(current_submodule)
|
||||
current_submodule = {'name': line.split('"')[1]}
|
||||
elif '=' in line and current_submodule:
|
||||
key, value = line.split('=', 1)
|
||||
current_submodule[key.strip()] = value.strip()
|
||||
|
||||
if current_submodule:
|
||||
submodules.append(current_submodule)
|
||||
|
||||
# Add to capabilities
|
||||
for submodule in submodules:
|
||||
path = submodule.get('path', '')
|
||||
if path:
|
||||
self.capabilities[path] = {
|
||||
'type': 'submodule',
|
||||
'name': submodule['name'],
|
||||
'path': path,
|
||||
'url': submodule.get('url', ''),
|
||||
'status': self._check_submodule_status(path)
|
||||
}
|
||||
|
||||
def _discover_local_capabilities(self):
|
||||
"""Discover local capability directories."""
|
||||
capabilities_dir = self.project_root / "capabilities"
|
||||
if not capabilities_dir.exists():
|
||||
return
|
||||
|
||||
for cap_dir in capabilities_dir.iterdir():
|
||||
if cap_dir.is_dir() and not cap_dir.name.startswith('.'):
|
||||
readme_path = cap_dir / "README.md"
|
||||
self.capabilities[f"capabilities/{cap_dir.name}"] = {
|
||||
'type': 'local',
|
||||
'name': cap_dir.name,
|
||||
'path': f"capabilities/{cap_dir.name}",
|
||||
'has_readme': readme_path.exists(),
|
||||
'status': 'available'
|
||||
}
|
||||
|
||||
def _discover_external_dependencies(self):
|
||||
"""Discover external package dependencies."""
|
||||
pyproject_path = self.project_root / "pyproject.toml"
|
||||
if not pyproject_path.exists():
|
||||
return
|
||||
|
||||
# Basic parsing of dependencies (could be enhanced with toml library)
|
||||
with open(pyproject_path, 'r') as f:
|
||||
content = f.read()
|
||||
|
||||
# Extract key dependencies
|
||||
key_deps = ['click', 'pytest', 'sqlalchemy', 'requests']
|
||||
for dep in key_deps:
|
||||
if dep in content:
|
||||
self.capabilities[f"external/{dep}"] = {
|
||||
'type': 'external',
|
||||
'name': dep,
|
||||
'path': f"external/{dep}",
|
||||
'status': 'package_dependency'
|
||||
}
|
||||
|
||||
def _check_submodule_status(self, path: str) -> str:
|
||||
"""Check if submodule is properly initialized."""
|
||||
submodule_path = self.project_root / path
|
||||
|
||||
if not submodule_path.exists():
|
||||
return 'missing'
|
||||
|
||||
# Check if it's an empty directory
|
||||
if submodule_path.is_dir() and not any(submodule_path.iterdir()):
|
||||
return 'uninitialized'
|
||||
|
||||
return 'available'
|
||||
|
||||
def get_capability_info(self, name: str) -> Optional[Dict]:
|
||||
"""Get information about a specific capability."""
|
||||
for cap_path, info in self.capabilities.items():
|
||||
if info['name'] == name or cap_path == name:
|
||||
return info
|
||||
return None
|
||||
|
||||
def search_functionality(self, search_term: str) -> List[Tuple[str, str]]:
|
||||
"""Search for functionality across capabilities."""
|
||||
results = []
|
||||
|
||||
for cap_path, info in self.capabilities.items():
|
||||
if info['type'] == 'submodule' and info['status'] == 'available':
|
||||
results.extend(self._search_in_submodule(cap_path, search_term))
|
||||
elif info['type'] == 'local':
|
||||
results.extend(self._search_in_local_capability(cap_path, search_term))
|
||||
|
||||
return results
|
||||
|
||||
def _search_in_submodule(self, path: str, search_term: str) -> List[Tuple[str, str]]:
|
||||
"""Search for functionality in a submodule."""
|
||||
results = []
|
||||
submodule_path = self.project_root / path
|
||||
|
||||
if not submodule_path.exists():
|
||||
return results
|
||||
|
||||
# Search README files
|
||||
for readme in submodule_path.glob("**/README.md"):
|
||||
try:
|
||||
with open(readme, 'r') as f:
|
||||
content = f.read().lower()
|
||||
if search_term.lower() in content:
|
||||
results.append((path, f"README: {readme.relative_to(submodule_path)}"))
|
||||
except Exception:
|
||||
pass
|
||||
|
||||
# Search Python files for functions/classes
|
||||
for py_file in submodule_path.glob("**/*.py"):
|
||||
try:
|
||||
with open(py_file, 'r') as f:
|
||||
content = f.read()
|
||||
if search_term in content:
|
||||
results.append((path, f"Code: {py_file.relative_to(submodule_path)}"))
|
||||
except Exception:
|
||||
pass
|
||||
|
||||
return results
|
||||
|
||||
def _search_in_local_capability(self, path: str, search_term: str) -> List[Tuple[str, str]]:
|
||||
"""Search for functionality in a local capability."""
|
||||
results = []
|
||||
cap_path = self.project_root / path
|
||||
|
||||
if not cap_path.exists():
|
||||
return results
|
||||
|
||||
# Search Python files
|
||||
for py_file in cap_path.glob("**/*.py"):
|
||||
try:
|
||||
with open(py_file, 'r') as f:
|
||||
content = f.read()
|
||||
if search_term in content:
|
||||
results.append((path, f"Code: {py_file.relative_to(cap_path)}"))
|
||||
except Exception:
|
||||
pass
|
||||
|
||||
return results
|
||||
|
||||
def generate_report(self) -> str:
|
||||
"""Generate a capability discovery report."""
|
||||
report = ["# Capability Discovery Report", ""]
|
||||
|
||||
# Summary
|
||||
total_caps = len(self.capabilities)
|
||||
submodules = len([c for c in self.capabilities.values() if c['type'] == 'submodule'])
|
||||
local = len([c for c in self.capabilities.values() if c['type'] == 'local'])
|
||||
external = len([c for c in self.capabilities.values() if c['type'] == 'external'])
|
||||
|
||||
report.extend([
|
||||
f"**Total Capabilities**: {total_caps}",
|
||||
f"- Submodules: {submodules}",
|
||||
f"- Local: {local}",
|
||||
f"- External: {external}",
|
||||
""
|
||||
])
|
||||
|
||||
# Details by type
|
||||
for cap_type in ['submodule', 'local', 'external']:
|
||||
caps_of_type = {k: v for k, v in self.capabilities.items() if v['type'] == cap_type}
|
||||
if caps_of_type:
|
||||
report.append(f"## {cap_type.title()} Capabilities")
|
||||
for path, info in caps_of_type.items():
|
||||
status_emoji = "✅" if info['status'] == 'available' else "❌"
|
||||
report.append(f"- {status_emoji} **{info['name']}** (`{path}`) - {info['status']}")
|
||||
report.append("")
|
||||
|
||||
return '\n'.join(report)
|
||||
|
||||
def validate_capability_usage(self, file_path: str) -> List[str]:
|
||||
"""Validate that a file properly uses existing capabilities."""
|
||||
warnings = []
|
||||
|
||||
if not Path(file_path).exists():
|
||||
return ["File not found"]
|
||||
|
||||
with open(file_path, 'r') as f:
|
||||
content = f.read()
|
||||
|
||||
# Check for potential duplication
|
||||
duplication_patterns = {
|
||||
'issue management': ['create_issue', 'list_issues', 'close_issue'],
|
||||
'content parsing': ['parse_markdown', 'extract_content', 'ContentParser'],
|
||||
'utilities': ['helper_function', 'utility_function']
|
||||
}
|
||||
|
||||
for capability, patterns in duplication_patterns.items():
|
||||
for pattern in patterns:
|
||||
if pattern in content:
|
||||
# Check if proper capability import is used
|
||||
if capability == 'issue management' and 'issue-facade' not in content:
|
||||
warnings.append(f"Potential issue management duplication: {pattern} found but no issue-facade usage")
|
||||
elif capability == 'content parsing' and 'markitect_content' not in content:
|
||||
warnings.append(f"Potential content parsing duplication: {pattern} found but no markitect-content usage")
|
||||
|
||||
return warnings
|
||||
|
||||
|
||||
def main():
|
||||
"""CLI interface for capability discovery."""
|
||||
import sys
|
||||
|
||||
discovery = CapabilityDiscovery()
|
||||
|
||||
if len(sys.argv) < 2:
|
||||
print("Usage: capability_discovery.py [report|search|validate] [args...]")
|
||||
return
|
||||
|
||||
command = sys.argv[1]
|
||||
|
||||
if command == "report":
|
||||
print(discovery.generate_report())
|
||||
|
||||
elif command == "search" and len(sys.argv) > 2:
|
||||
search_term = sys.argv[2]
|
||||
results = discovery.search_functionality(search_term)
|
||||
if results:
|
||||
print(f"Found '{search_term}' in:")
|
||||
for cap, location in results:
|
||||
print(f" - {cap}: {location}")
|
||||
else:
|
||||
print(f"No results found for '{search_term}'")
|
||||
|
||||
elif command == "validate" and len(sys.argv) > 2:
|
||||
file_path = sys.argv[2]
|
||||
warnings = discovery.validate_capability_usage(file_path)
|
||||
if warnings:
|
||||
print("Validation warnings:")
|
||||
for warning in warnings:
|
||||
print(f" ⚠️ {warning}")
|
||||
else:
|
||||
print("✅ No capability usage issues found")
|
||||
|
||||
else:
|
||||
print("Invalid command or missing arguments")
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
Reference in New Issue
Block a user