diff --git a/history/20251216-architecture-assessment.md b/history/20251216-architecture-assessment.md
new file mode 100644
index 00000000..85e569f2
--- /dev/null
+++ b/history/20251216-architecture-assessment.md
@@ -0,0 +1,1088 @@
+# MarkiTect Architecture Assessment
+**Date:** 2025-12-16
+**Scope:** Comprehensive review of capabilities-based architecture
+**Context:** Post testdrive-jsui refactoring to git submodule
+
+---
+
+## **Executive Summary**
+
+The architecture shows **strong alignment** with the capabilities-based design documented in `CAPABILITIES_ARCHITECTURE.md`. The recent testdrive-jsui refactoring demonstrates excellent separation of concerns. However, there are **dependency management inconsistencies** that need attention.
+
+**Overall Grade: B+** (Strong architecture with minor dependency management issues)
+
+---
+
+## **1. Capabilities Status**
+
+### ✅ **Submodule Capabilities** (3/3 configured correctly)
+| Capability | Git Submodule | Installed | In Dependencies | Status |
+|------------|--------------|-----------|-----------------|---------|
+| **testdrive-jsui** | ✅ | ✅ (0.1.0) | ✅ | **Perfect** |
+| **issue-facade** | ✅ | ✅ (0.1.0) | ❌ | **Missing from pyproject.toml** |
+| **kaizen-agentic** | ✅ | ✅ (1.0.0) | ❌ | **Missing from pyproject.toml** |
+
+### ⚠️ **Local Capabilities** (3 total, should migrate to submodules)
+| Capability | Git Submodule | Installed | In Dependencies | Migration Status |
+|------------|--------------|-----------|-----------------|-------------------|
+| **release-management** | ❌ | ✅ (0.1.0) | ✅ | Ready to migrate |
+| **markitect-content** | ❌ | ✅ (0.2.0) | ✅ (optional) | Ready to migrate |
+| **markitect-utils** | ❌ | ✅ (0.2.0) | ❌ | **Needs dependency entry** |
+
+---
+
+## **2. Dependency Management Analysis**
+
+### 📋 **Current pyproject.toml Dependencies**
+
+```toml
+dependencies = [
+    # Core external dependencies
+    "markdown-it-py", "PyYAML", "click>=8.0.0",
+    "tabulate>=0.9.0", "jsonpath-ng>=1.5.0",
+    "aiohttp>=3.8.0", "toml",
+
+    # Capability dependencies
+    "release-management @ file:./capabilities/release-management",
+    "testdrive-jsui @ file:./capabilities/testdrive-jsui"
+]
+
+[project.optional-dependencies]
+capabilities = [
+    "markitect-content @ file:./capabilities/markitect-content"
+]
+```
+
+### ⚠️ **Missing Dependency Declarations**
+
+Despite being **installed** and **used**, these are not in dependencies:
+- ❌ `issue-facade` - Used by main repo (references in CLI)
+- ❌ `kaizen-agentic` - Framework capability
+- ❌ `markitect-utils` - Utility functions
+
+### 🎯 **Recommended pyproject.toml Structure**
+
+```toml
+dependencies = [
+    # Core external dependencies
+    "markdown-it-py", "PyYAML", "click>=8.0.0",
+    "tabulate>=0.9.0", "jsonpath-ng>=1.5.0",
+    "aiohttp>=3.8.0", "toml",
+
+    # Core capabilities (required)
+    "release-management @ file:./capabilities/release-management",
+    "testdrive-jsui @ file:./capabilities/testdrive-jsui",
+    "issue-facade @ file:./capabilities/issue-facade",        # ADD
+    "markitect-utils @ file:./capabilities/markitect-utils",  # ADD
+]
+
+[project.optional-dependencies]
+capabilities = [
+    "markitect-content @ file:./capabilities/markitect-content"
+]
+development = [
+    "kaizen-agentic @ file:./capabilities/kaizen-agentic",    # ADD (dev-only)
+]
+```
+
+---
+
+## **3. Plugin System Architecture**
+
+### ✅ **Excellent Design Patterns**
+
+The plugin system demonstrates **best-in-class** separation of concerns:
+
+#### 1. **Base Plugin Architecture**
+- Clean abstract base classes (`BasePlugin`, `RenderingEnginePlugin`)
+- Type-safe plugin metadata
+- Well-defined interfaces
+
+#### 2. **Plugin Self-Declaration** ⭐ (New pattern from testdrive-jsui refactoring)
+
+**File:** `markitect/plugins/testdrive_jsui.py`
+
+```python
+def get_plugin_source_dir(self) -> Path:
+    """Plugin declares its own location - no hardcoded paths."""
+    return Path(__file__).parent.parent.parent / "capabilities" / "testdrive-jsui"
+
+def get_asset_paths(self) -> Dict[str, Path]:
+    """Plugin declares its asset structure."""
+    base = self.get_plugin_source_dir()
+    return {
+        'js': base / 'js',
+        'css': base / 'static' / 'css',
+        'images': base / 'static' / 'images',
+        'templates': base / 'static' / 'templates',
+    }
+```
+
+**Benefits:**
+- No hardcoded paths in main repo
+- Plugin knows its own structure
+- Easy to relocate or reuse
+- Main repo uses generic discovery
+
+#### 3. **Generic Discovery** ⭐
+
+**File:** `markitect/plugins/rendering.py`
+
+```python
+# ✅ Good: Generic discovery using hasattr
+if hasattr(engine, 'get_plugin_source_dir'):
+    source_dir = engine.get_plugin_source_dir()
+
+# ❌ Bad: Hardcoded plugin names (removed during refactoring)
+# if engine_name == 'testdrive-jsui':
+#     source_dir = Path('capabilities/testdrive-jsui')
+```
+
+**Pattern Evolution:**
+- **Before:** Hardcoded plugin-specific logic in main repo
+- **After:** Generic interface-based discovery
+- **Impact:** Main repo has ZERO knowledge of specific plugin implementations
+
+#### 4. **Clean Import Boundaries**
+- ✅ No JavaScript embedded in Python (learned from previous issues)
+- ✅ JSON-based configuration interface
+- ✅ Asset paths resolved at runtime
+- ✅ No direct file system dependencies
+
+### 🎯 **Plugin Architecture Grade: A+**
+
+**Justification:**
+- Follows SOLID principles (especially Dependency Inversion)
+- Self-declaring plugins (Open/Closed principle)
+- No tight coupling to implementations
+- Easily testable and maintainable
+
+---
+
+## **4. Directory Structure**
+
+### ✅ **Well-Organized**
+
+```
+markitect_project/
+├── capabilities/              # Independent git repositories
+│   ├── issue-facade/         # ✅ Submodule
+│   ├── kaizen-agentic/       # ✅ Submodule
+│   ├── testdrive-jsui/       # ✅ Submodule (recently refactored)
+│   ├── markitect-content/    # ⚠️ Local (should become submodule)
+│   ├── markitect-utils/      # ⚠️ Local (should become submodule)
+│   └── release-management/   # ⚠️ Local (should become submodule)
+│
+├── markitect/                # Main package
+│   ├── plugins/             # ✅ Clean plugin system
+│   │   ├── base.py
+│   │   ├── rendering.py
+│   │   ├── testdrive_jsui.py  # Self-contained plugin
+│   │   └── manager.py
+│   ├── assets/              # Asset management
+│   ├── cli.py               # Main CLI entry
+│   └── [other core modules]
+│
+├── docs/                     # ✅ Excellent documentation
+│   ├── architecture/
+│   │   ├── CAPABILITIES_ARCHITECTURE.md  # Comprehensive
+│   │   └── caching-system.md
+│   └── CAPABILITIES_QUICK_REFERENCE.md
+│
+├── pyproject.toml            # ⚠️ Incomplete dependencies
+└── Makefile                  # ✅ Excellent capability management
+```
+
+### 🎯 **Structure Grade: A**
+
+**Strengths:**
+- Clear separation of main repo vs capabilities
+- Well-documented architecture in `docs/`
+- Logical grouping of related functionality
+- Makefile provides excellent capability discovery
+
+**Areas for Improvement:**
+- Complete submodule migration for all capabilities
+- Ensure pyproject.toml reflects actual usage
+
+---
+
+## **5. Architectural Strengths**
+
+### 🌟 **Major Wins**
+
+#### 1. **Capabilities-Based Architecture**
+- Clear separation between main repo and capabilities
+- Git submodules enable independent development lifecycles
+- Each capability can have own versioning, testing, releases
+- Well-documented in `docs/architecture/CAPABILITIES_ARCHITECTURE.md`
+
+**Evidence:**
+```bash
+$ git submodule status
+ 34a8bc7d capabilities/issue-facade (heads/main)
+ 1e0ff82d capabilities/kaizen-agentic (heads/main)
+ 9d7964f9 capabilities/testdrive-jsui (heads/main)
+```
+
+#### 2. **Plugin System Excellence**
+- Self-declaring plugins (no hardcoded paths)
+- Generic discovery patterns (no if-else chains)
+- Clean interface boundaries (JSON config, not embedded JS)
+- Easily extensible for new plugins
+
+**Impact:**
+- Adding new rendering engine requires ZERO main repo changes
+- Plugins can be developed/tested independently
+- No fragile path dependencies
+
+#### 3. **testdrive-jsui Refactoring Success** ⭐
+
+**Achievements:**
+- ✅ Consolidated duplicate directories (`/testdrive-jsui/` + `/capabilities/testdrive-jsui/` → single source)
+- ✅ Implemented plugin self-declaration
+- ✅ Integrated upstream content from Gitea
+- ✅ Configured as git submodule
+- ✅ All 17 assets working correctly
+- ✅ No JavaScript in Python code
+
+**Files Changed:**
+- `markitect/plugins/testdrive_jsui.py` - Added self-declaration methods
+- `markitect/plugins/rendering.py` - Removed hardcoded discovery
+- `pyproject.toml` - Added dependency
+- `.gitmodules` - Added submodule configuration
+
+#### 4. **Makefile-Based Capability Management**
+
+**Commands Available:**
+```bash
+$ make capabilities-list      # Discovery of all capabilities
+$ make capabilities-help      # Delegated help from each capability
+$ make capabilities-status    # Health check
+```
+
+**Pattern:**
+- Main Makefile delegates to capability Makefiles
+- Each capability is self-describing
+- No hardcoded capability names in main Makefile
+
+#### 5. **Comprehensive Documentation**
+
+**Created:**
+- `docs/architecture/CAPABILITIES_ARCHITECTURE.md` (453 lines)
+  - Core principles (separation of concerns)
+  - Development workflow (separate Claude instances)
+  - Best practices (DO/DON'T lists)
+  - Troubleshooting guide
+
+- `docs/CAPABILITIES_QUICK_REFERENCE.md` (184 lines)
+  - Quick commands and patterns
+  - Common tasks
+  - Integration examples
+
+**Quality:**
+- Clear examples with code snippets
+- Emphasis on critical rules (DON'T edit from main repo)
+- Troubleshooting scenarios
+- Current capability status table
+
+---
+
+## **6. Architectural Issues**
+
+### ⚠️ **Critical Issues** (Must Fix)
+
+#### **Issue #1: Dependency Management Inconsistency**
+
+**Problem:**
+```
+issue-facade and kaizen-agentic are:
+- ✅ Configured as git submodules (.gitmodules)
+- ✅ Installed in environment (pip list shows them)
+- ❌ NOT declared in pyproject.toml dependencies
+- ❌ Can break fresh installs (pip install -e .)
+```
+
+**Evidence:**
+```bash
+$ pip list | grep -E "issue|kaizen"
+kaizen-agentic            1.0.0       /home/worsch/markitect_project/capabilities/kaizen-agentic
+universal-issue-tracker   0.1.0       /home/worsch/markitect_project/capabilities/issue-facade
+
+$ grep -E "issue|kaizen" pyproject.toml
+# No results - NOT in dependencies!
+```
+
+**Impact:**
+- **High** - Fresh installations will fail or be incomplete
+- Developers following standard `pip install -e .` won't get all capabilities
+- CI/CD pipelines may fail
+- Violates "reproducible builds" principle
+
+**Root Cause:**
+- Manual `pip install -e` was used instead of declaring in pyproject.toml
+- Dependencies were likely installed during development but never formalized
+
+**Fix Required:**
+Add to `pyproject.toml`:
+```toml
+dependencies = [
+    # ... existing ...
+    "issue-facade @ file:./capabilities/issue-facade",
+]
+
+[project.optional-dependencies]
+development = [
+    "kaizen-agentic @ file:./capabilities/kaizen-agentic",
+]
+```
+
+#### **Issue #2: markitect-utils Orphaned**
+
+**Problem:**
+```
+markitect-utils is:
+- ✅ Exists in capabilities/markitect-utils/
+- ✅ Installed in environment (0.2.0)
+- ❌ NOT in pyproject.toml
+- ❌ NOT a git submodule
+- ❌ Unclear purpose and usage
+```
+
+**Questions to Answer:**
+1. Is markitect-utils actually used by the main repo?
+2. Should it be a required dependency?
+3. Should it become a git submodule?
+4. Can it be deprecated/removed?
+
+**Investigation Needed:**
+```bash
+# Search for imports
+grep -r "from markitect_utils\|import markitect_utils" markitect/
+# Check its README
+cat capabilities/markitect-utils/README.md
+```
+
+**Recommendation:**
+- If used: Add to dependencies and migrate to submodule
+- If unused: Remove capability entirely
+- Document purpose and usage
+
+### ⚠️ **Medium Priority Issues**
+
+#### **Issue #3: Local Capabilities Not Migrated**
+
+**Problem:**
+```
+3 capabilities are still local (not submodules):
+- release-management
+- markitect-content
+- markitect-utils
+
+Per CAPABILITIES_ARCHITECTURE.md:
+"Target State: All capabilities should eventually be submodules."
+```
+
+**Current State:**
+```bash
+$ ls -d capabilities/*/
+capabilities/issue-facade/        # ✅ Submodule
+capabilities/kaizen-agentic/      # ✅ Submodule
+capabilities/markitect-content/   # ❌ Local
+capabilities/markitect-utils/     # ❌ Local
+capabilities/release-management/  # ❌ Local
+capabilities/testdrive-jsui/      # ✅ Submodule
+```
+
+**Migration Checklist per Capability:**
+- [ ] Verify Gitea repository exists (or create it)
+- [ ] Push capability content to Gitea
+- [ ] Remove from main repo tracking (`git rm -rf`)
+- [ ] Add as submodule (`git submodule add`)
+- [ ] Update dependencies in pyproject.toml
+- [ ] Test integration (`pip install -e .`)
+- [ ] Document in CAPABILITIES_ARCHITECTURE.md
+
+**Benefits of Migration:**
+- Independent version control
+- Separate development lifecycle
+- Can be used by other projects
+- Follows documented architecture
+
+#### **Issue #4: Mixed Dependency Patterns**
+
+**Problem:**
+```
+Inconsistent categorization of capabilities:
+
+CURRENT:
+- release-management     → dependencies (required)
+- testdrive-jsui        → dependencies (required)
+- markitect-content     → optional-dependencies.capabilities
+- issue-facade          → NOT DECLARED
+- kaizen-agentic        → NOT DECLARED
+- markitect-utils       → NOT DECLARED
+
+UNCLEAR:
+- Why is markitect-content optional?
+- What makes something "required" vs "optional"?
+- Which capabilities are for development only?
+```
+
+**Recommendation:**
+Define clear criteria:
+
+**Required Dependencies:**
+- Used by core CLI commands
+- Needed for basic functionality
+- Example: testdrive-jsui (for edit mode), release-management (for version info)
+
+**Optional Dependencies:**
+- Extend functionality but not required
+- User can choose to install
+- Example: markitect-content (for advanced content parsing?)
+
+**Development Dependencies:**
+- Only needed during development
+- Not required for end users
+- Example: kaizen-agentic (agent framework for development)
+
+---
+
+## **7. Recommendations**
+
+### 🎯 **Priority 1: Fix Dependency Management** (TODAY)
+
+**Objective:** Ensure pyproject.toml accurately reflects all used capabilities
+
+**Action Items:**
+
+1. **Add missing dependencies**
+
+   Edit `pyproject.toml`:
+   ```toml
+   dependencies = [
+       # Core external dependencies
+       "markdown-it-py",
+       "PyYAML",
+       "click>=8.0.0",
+       "tabulate>=0.9.0",
+       "jsonpath-ng>=1.5.0",
+       "aiohttp>=3.8.0",
+       "toml",
+
+       # Core capabilities (required for basic functionality)
+       "release-management @ file:./capabilities/release-management",
+       "testdrive-jsui @ file:./capabilities/testdrive-jsui",
+       "issue-facade @ file:./capabilities/issue-facade",           # FIX: ADD
+       "markitect-utils @ file:./capabilities/markitect-utils",     # FIX: ADD
+   ]
+
+   [project.optional-dependencies]
+   capabilities = [
+       "markitect-content @ file:./capabilities/markitect-content"
+   ]
+
+   development = [
+       "kaizen-agentic @ file:./capabilities/kaizen-agentic",      # FIX: ADD
+   ]
+   ```
+
+2. **Test clean installation**
+
+   ```bash
+   # Create fresh virtual environment
+   python -m venv /tmp/test-markitect-install
+   source /tmp/test-markitect-install/bin/activate
+
+   # Install from clean state
+   cd /home/worsch/markitect_project
+   pip install -e .
+
+   # Verify all capabilities installed
+   pip list | grep -E "testdrive|release|markitect|issue|kaizen"
+
+   # Test basic commands
+   markitect --version
+   issue --version
+
+   # Cleanup
+   deactivate
+   rm -rf /tmp/test-markitect-install
+   ```
+
+3. **Document dependency rationale**
+
+   Create `docs/architecture/DEPENDENCY_RATIONALE.md`:
+   ```markdown
+   # Dependency Rationale
+
+   ## Required Dependencies
+
+   ### testdrive-jsui
+   **Why:** Core rendering engine for edit mode
+   **Used by:** `markitect md-render --mode edit`
+
+   ### release-management
+   **Why:** Version management and release tooling
+   **Used by:** `markitect --version`, release targets in Makefile
+
+   ### issue-facade
+   **Why:** CLI interface to issue tracker
+   **Used by:** `issue` command, Makefile targets
+
+   ### markitect-utils
+   **Why:** Common utility functions
+   **Used by:** [DOCUMENT ACTUAL USAGE]
+
+   ## Optional Dependencies
+
+   ### markitect-content
+   **Why:** Advanced content parsing (frontmatter-free parsing)
+   **Used by:** [DOCUMENT WHEN NEEDED]
+
+   ## Development Dependencies
+
+   ### kaizen-agentic
+   **Why:** Agent development framework
+   **Used by:** Claude Code development workflows, not end users
+   ```
+
+**Success Criteria:**
+- ✅ Fresh `pip install -e .` installs all required capabilities
+- ✅ All commands work in fresh environment
+- ✅ Dependency rationale documented
+- ✅ No manual `pip install -e` needed for capabilities
+
+### 🎯 **Priority 2: Complete Submodule Migration** (THIS WEEK)
+
+**Objective:** Migrate remaining local capabilities to git submodules
+
+**Step 1: Verify Gitea Repositories**
+
+```bash
+# Check if these repositories exist on Gitea:
+# - http://92.205.130.254:32166/coulomb/release-management.git
+# - http://92.205.130.254:32166/coulomb/markitect-content.git
+# - http://92.205.130.254:32166/coulomb/markitect-utils.git
+
+# If they don't exist, create them via Gitea web UI
+```
+
+**Step 2: Migrate release-management**
+
+Following `docs/architecture/CAPABILITIES_ARCHITECTURE.md` section "Converting Local Capability to Submodule":
+
+```bash
+# 1. Create separate git repo (if needed)
+cd /tmp
+cp -r /home/worsch/markitect_project/capabilities/release-management release-management
+cd release-management
+git init
+git add .
+git commit -m "Initial commit: extract release-management capability"
+git remote add origin http://92.205.130.254:32166/coulomb/release-management.git
+git push -u origin main
+
+# 2. Remove from main repo
+cd /home/worsch/markitect_project
+git rm -rf capabilities/release-management
+git commit -m "chore: remove release-management for submodule conversion"
+
+# 3. Add as submodule
+git submodule add http://92.205.130.254:32166/coulomb/release-management.git \
+    capabilities/release-management
+git commit -m "feat: add release-management as submodule"
+
+# 4. Verify installation
+pip install -e .
+pip list | grep release-management
+```
+
+**Step 3: Repeat for markitect-content**
+
+**Step 4: Evaluate markitect-utils**
+- First determine if it's actually needed
+- If yes, migrate as above
+- If no, deprecate and remove
+
+**Success Criteria:**
+- ✅ All capabilities are git submodules
+- ✅ `.gitmodules` lists all capabilities
+- ✅ `git submodule status` shows all green
+- ✅ Capability independence verified
+
+### 🎯 **Priority 3: Clarify Capability Roles** (THIS WEEK)
+
+**Objective:** Document purpose, usage, and dependencies of each capability
+
+**Create Capability Matrix:**
+
+`docs/architecture/CAPABILITY_MATRIX.md`:
+
+```markdown
+# Capability Matrix
+
+| Capability | Type | Status | Required? | Used By | Purpose | Dependencies |
+|------------|------|--------|-----------|---------|---------|--------------|
+| **testdrive-jsui** | UI Engine | ✅ Submodule | Yes | `md-render --mode edit` | JavaScript UI rendering and editing | None |
+| **release-management** | Tool | ⚠️ Local | Yes | CLI `--version`, Makefile | Version management, releases | git, setuptools |
+| **issue-facade** | CLI | ✅ Submodule | Yes | `issue` command, Makefile | Unified issue tracker interface | Backend-specific adapters |
+| **kaizen-agentic** | Framework | ✅ Submodule | No (dev) | Development workflows | AI agent development framework | pydantic, click |
+| **markitect-content** | Parser | ⚠️ Local | Optional | ? | Frontmatter-free content parsing | ? |
+| **markitect-utils** | Utilities | ⚠️ Local | ? | ? | **NEEDS INVESTIGATION** | ? |
+
+## Capability Details
+
+### testdrive-jsui
+**Purpose:** Independent JavaScript UI rendering engine for markdown editing
+**Main Entry Points:**
+- `from markitect.plugins.testdrive_jsui import TestDriveJSUIEngine`
+**Commands That Use It:**
+- `markitect md-render --mode edit`
+- `markitect md-render --mode insert`
+**Can Be Removed?** No - core functionality for edit mode
+
+### release-management
+**Purpose:** Version management and release automation
+**Main Entry Points:**
+- `from release_management.utils.version import get_version_info`
+**Commands That Use It:**
+- `markitect --version`
+- `make release-*` targets
+**Can Be Removed?** No - core infrastructure
+
+### issue-facade
+**Purpose:** Backend-agnostic issue tracking CLI
+**Main Entry Points:**
+- `issue` CLI command
+**Commands That Use It:**
+- `issue list`, `issue show`, `issue create`, etc.
+- `make issue-*` targets
+**Can Be Removed?** Technically yes, but heavily integrated into workflow
+
+### kaizen-agentic
+**Purpose:** AI agent development framework with kaizen optimization
+**Main Entry Points:**
+- Not imported by main repo (development tool)
+**Commands That Use It:**
+- None (used during development sessions)
+**Can Be Removed?** Yes (for end users), No (for developers)
+
+### markitect-content
+**Purpose:** ? (Needs investigation)
+**Main Entry Points:**
+- ? (Search for imports in codebase)
+**Commands That Use It:**
+- ? (Needs documentation)
+**Can Be Removed?** Unclear - investigate first
+
+### markitect-utils
+**Purpose:** ? (Needs investigation)
+**Main Entry Points:**
+- ? (Search for imports in codebase)
+**Commands That Use It:**
+- ? (Needs documentation)
+**Can Be Removed?** Unclear - investigate first
+```
+
+**Investigation Commands:**
+```bash
+# Find actual usage of markitect-content
+grep -r "from markitect_content\|import markitect_content" \
+    markitect/ cli/ tddai* --include="*.py"
+
+# Find actual usage of markitect-utils
+grep -r "from markitect_utils\|import markitect_utils" \
+    markitect/ cli/ tddai* --include="*.py"
+
+# Check what they export
+python3 -c "import markitect_content; print(dir(markitect_content))"
+python3 -c "import markitect_utils; print(dir(markitect_utils))"
+```
+
+### 🎯 **Priority 4: Enforce Architecture Boundaries** (NEXT SPRINT)
+
+**Objective:** Prevent accidental violations of capabilities architecture
+
+**1. Add Git Hook**
+
+Create `.git/hooks/pre-commit`:
+```bash
+#!/bin/bash
+# Verify no direct edits to capability files from main repo
+
+CHANGED_FILES=$(git diff --cached --name-only --diff-filter=ACM)
+
+# Check for changes in capabilities/ subdirectories
+CAPABILITY_CHANGES=$(echo "$CHANGED_FILES" | grep "^capabilities/[^/]*/")
+
+if [ -n "$CAPABILITY_CHANGES" ]; then
+    echo "❌ ERROR: Direct capability edits detected!"
+    echo ""
+    echo "Changed files in capabilities:"
+    echo "$CAPABILITY_CHANGES"
+    echo ""
+    echo "Per CAPABILITIES_ARCHITECTURE.md:"
+    echo "  - Use separate Claude instance for capability development"
+    echo "  - Make changes in capability's own repository"
+    echo "  - Update main repo's submodule pointer after capability changes"
+    echo ""
+    echo "To override (use with caution):"
+    echo "  git commit --no-verify"
+    exit 1
+fi
+```
+
+```bash
+chmod +x .git/hooks/pre-commit
+```
+
+**2. Add Makefile Validation**
+
+```makefile
+# Verify architectural boundaries
+validate-architecture:
+	@echo "🔍 Validating architectural boundaries..."
+	@# Check no direct imports of capability internals
+	@! grep -r "from capabilities\." --include="*.py" markitect/ || \
+		(echo "❌ Direct capability imports detected - use package names" && exit 1)
+	@# Check all used capabilities are in dependencies
+	@python3 -c "import sys; import toml; \
+		deps = toml.load('pyproject.toml')['project']['dependencies']; \
+		print('✅ All dependencies declared') if all(c in str(deps) for c in \
+		['testdrive-jsui', 'release-management', 'issue-facade']) else sys.exit(1)"
+	@echo "✅ Architecture validation passed"
+```
+
+**3. Add CI Check**
+
+If using CI/CD, add validation step:
+```yaml
+# .github/workflows/architecture.yml or similar
+- name: Validate Architecture
+  run: make validate-architecture
+```
+
+---
+
+## **8. Comparison to Documented Architecture**
+
+### ✅ **Alignment with CAPABILITIES_ARCHITECTURE.md**
+
+**Document Location:** `docs/architecture/CAPABILITIES_ARCHITECTURE.md`
+**Created:** 2025-12-16
+**Lines:** 453
+
+| Principle | Documentation | Implementation | Grade | Notes |
+|-----------|---------------|----------------|-------|-------|
+| **Separation of Concerns** | ✅ Well documented | ✅ Implemented | **A** | testdrive-jsui is perfect example |
+| **Git Submodule Architecture** | ✅ Comprehensive guide | ⚠️ Partial | **B** | 3/6 capabilities are submodules |
+| **Independent Development** | ✅ Separate Claude instances | ✅ Supported | **A** | Submodules enable this |
+| **Interface-Based Integration** | ✅ Plugin patterns | ✅ Self-declaration | **A+** | Excellent implementation |
+| **Dependency Management** | ✅ File-based pattern | ❌ Incomplete | **C** | Missing declarations |
+| **Testing Strategy** | ✅ Documented | ✅ Separate tests | **A** | Each capability has own tests |
+
+### 📊 **Architecture Maturity Score: 82/100**
+
+**Breakdown:**
+- **Plugin System:** 95/100 ⭐
+  - Excellent self-declaration pattern
+  - Generic discovery (no hardcoded names)
+  - Clean boundaries (no embedded JS)
+  - Easily extensible
+  - *Minor deduction: Could use more plugins to validate pattern*
+
+- **Separation of Concerns:** 90/100
+  - Clear capability boundaries
+  - testdrive-jsui refactoring demonstrates pattern
+  - Well-documented architecture
+  - *Minor deduction: Some local capabilities not yet migrated*
+
+- **Submodule Management:** 70/100
+  - 3 capabilities properly configured as submodules
+  - `.gitmodules` correctly set up
+  - *Major deduction: 3 capabilities still local (50% migration)*
+
+- **Dependency Management:** 60/100
+  - Some capabilities properly declared
+  - File-based dependency pattern correct
+  - *Major deduction: 3 capabilities missing from pyproject.toml*
+  - *Risk: Fresh installs will fail*
+
+- **Documentation:** 95/100 ⭐
+  - Comprehensive architecture guide (453 lines)
+  - Quick reference for common tasks (184 lines)
+  - Clear examples and patterns
+  - DO/DON'T lists with rationale
+  - *Minor deduction: Missing dependency rationale doc*
+
+### 🎯 **Path to 95/100**
+
+**To reach 95/100, we need:**
+1. ✅ Fix dependency declarations (+15 points) → 75/100
+2. ✅ Complete submodule migration (+10 points) → 85/100
+3. ✅ Add dependency rationale doc (+5 points) → 90/100
+4. ✅ Add architecture validation (+3 points) → 93/100
+5. ✅ Add more rendering engine plugins (+2 points) → 95/100
+
+**Estimated Effort:**
+- Priority 1 (dependencies): 1-2 hours
+- Priority 2 (submodules): 4-6 hours
+- Priority 3 (documentation): 2-3 hours
+- Priority 4 (validation): 2-3 hours
+- **Total:** ~10-14 hours
+
+---
+
+## **9. Technical Debt Analysis**
+
+### 🔴 **High Priority Debt**
+
+1. **Missing Dependency Declarations** (Priority 1)
+   - **Impact:** High - breaks fresh installs
+   - **Effort:** Low - 1 hour
+   - **Risk:** High - production deployment issues
+
+2. **Incomplete Submodule Migration** (Priority 2)
+   - **Impact:** Medium - architectural inconsistency
+   - **Effort:** Medium - 4-6 hours
+   - **Risk:** Medium - confusion about capability management
+
+### 🟡 **Medium Priority Debt**
+
+3. **Unclear Capability Roles** (Priority 3)
+   - **Impact:** Medium - developer confusion
+   - **Effort:** Low - 2 hours
+   - **Risk:** Low - just documentation
+
+4. **No Architecture Validation** (Priority 4)
+   - **Impact:** Low - preventive measure
+   - **Effort:** Low - 2 hours
+   - **Risk:** Low - nice-to-have
+
+### 🟢 **Low Priority Debt**
+
+5. **markitect-utils Investigation**
+   - **Impact:** Low - might be unused
+   - **Effort:** Low - 1 hour
+   - **Risk:** Very Low - just cleanup
+
+---
+
+## **10. Success Metrics**
+
+### **How to Measure Improvement**
+
+1. **Dependency Correctness**
+   ```bash
+   # Metric: Fresh install success rate
+   # Target: 100% (currently: unknown, likely <100%)
+
+   # Test:
+   python -m venv /tmp/fresh-env
+   source /tmp/fresh-env/bin/activate
+   pip install -e .
+   pip list | grep -c -E "testdrive|release|issue|markitect"
+   # Should be: 6 (or however many required capabilities)
+   ```
+
+2. **Submodule Coverage**
+   ```bash
+   # Metric: Percentage of capabilities as submodules
+   # Current: 50% (3/6)
+   # Target: 100% (6/6)
+
+   # Test:
+   TOTAL=$(ls -d capabilities/*/ | wc -l)
+   SUBMODULES=$(git submodule status | grep -c "capabilities/")
+   echo "scale=2; $SUBMODULES / $TOTAL * 100" | bc
+   ```
+
+3. **Documentation Coverage**
+   ```bash
+   # Metric: Capabilities with documented purpose
+   # Current: ~50% (3/6 clear)
+   # Target: 100% (6/6)
+
+   # Test: Check CAPABILITY_MATRIX.md for "?" entries
+   grep -c "?" docs/architecture/CAPABILITY_MATRIX.md
+   # Should be: 0
+   ```
+
+4. **Architecture Violations**
+   ```bash
+   # Metric: Architecture boundary violations
+   # Current: Unknown
+   # Target: 0
+
+   # Test:
+   make validate-architecture
+   # Should exit 0
+   ```
+
+---
+
+## **11. Related Documentation**
+
+### **Key Documents to Review**
+
+1. **CAPABILITIES_ARCHITECTURE.md** ⭐ PRIMARY
+   - Location: `docs/architecture/CAPABILITIES_ARCHITECTURE.md`
+   - Lines: 453
+   - Content: Comprehensive guide to capabilities system
+   - Last Updated: 2025-12-16
+
+2. **CAPABILITIES_QUICK_REFERENCE.md**
+   - Location: `docs/CAPABILITIES_QUICK_REFERENCE.md`
+   - Lines: 184
+   - Content: Quick commands and common tasks
+   - Last Updated: 2025-12-16
+
+3. **testdrive-jsui Documentation**
+   - Location: `capabilities/testdrive-jsui/README.md`
+   - Content: Standalone capability usage guide
+   - Demonstrates: Plugin self-declaration pattern
+
+4. **This Assessment**
+   - Location: `history/20251216-architecture-assessment.md`
+   - Content: Current document
+   - Purpose: Snapshot of architectural state post-refactoring
+
+### **Documentation Gaps**
+
+**Needed:**
+1. `docs/architecture/DEPENDENCY_RATIONALE.md` - Why each capability is required/optional
+2. `docs/architecture/CAPABILITY_MATRIX.md` - Purpose and usage of each capability
+3. `docs/architecture/MIGRATION_GUIDE.md` - How to migrate capabilities to submodules
+4. Update to `docs/README.md` - Reference new architecture docs
+
+---
+
+## **12. Lessons Learned**
+
+### **From testdrive-jsui Refactoring**
+
+#### ✅ **What Worked Well**
+
+1. **Plugin Self-Declaration Pattern**
+   - Plugins know their own structure
+   - Main repo has zero knowledge of plugin internals
+   - Easy to relocate or reuse plugins
+   - **Lesson:** Inversion of control improves maintainability
+
+2. **Separate Claude Instances**
+   - Main repo session focused on integration
+   - Capability session focused on implementation
+   - No context pollution
+   - **Lesson:** Clear session boundaries prevent mistakes
+
+3. **Comprehensive Documentation First**
+   - Created CAPABILITIES_ARCHITECTURE.md before refactoring
+   - Provided clear guidelines
+   - Prevented ad-hoc decisions
+   - **Lesson:** Document architecture before implementing
+
+4. **Git Submodule Integration**
+   - Enabled independent development
+   - Upstream integration worked smoothly
+   - Version control separation maintained
+   - **Lesson:** Submodules work well for capabilities pattern
+
+#### ⚠️ **Challenges Encountered**
+
+1. **Unrelated Git Histories**
+   - Upstream repo had different history
+   - Needed `--allow-unrelated-histories`
+   - **Lesson:** Plan submodule creation from the start
+
+2. **Dependency Declaration Lag**
+   - Manual `pip install -e` during development
+   - Forgot to add to pyproject.toml
+   - **Lesson:** Update dependencies immediately
+
+3. **Asset Path Resolution**
+   - Initial confusion about relative vs absolute paths
+   - Solved with `get_plugin_source_dir()`
+   - **Lesson:** Let plugins declare their own paths
+
+### **Patterns to Replicate**
+
+For future capability work:
+
+1. **Create Architecture Docs First**
+   - Write CAPABILITY_NAME_ARCHITECTURE.md
+   - Define interfaces and boundaries
+   - Document integration points
+
+2. **Use Separate Sessions**
+   - One Claude instance for main repo
+   - One Claude instance for capability
+   - Prevents accidental boundary violations
+
+3. **Plugin Self-Declaration**
+   - Add `get_plugin_source_dir()` method
+   - Add `get_asset_paths()` method
+   - No hardcoded paths in main repo
+
+4. **Update Dependencies Immediately**
+   - Add to pyproject.toml when creating capability
+   - Test with fresh venv
+   - Document why it's required/optional
+
+---
+
+## **13. Action Items Summary**
+
+### **Immediate (Today)**
+
+- [ ] Update `pyproject.toml` to add missing dependencies
+  - [ ] Add `issue-facade` to dependencies
+  - [ ] Add `markitect-utils` to dependencies (after verification)
+  - [ ] Add `kaizen-agentic` to development dependencies
+- [ ] Test fresh installation in new venv
+- [ ] Commit dependency updates
+
+### **This Week**
+
+- [ ] Investigate `markitect-utils` usage
+  - [ ] Search for imports in codebase
+  - [ ] Check if actually needed
+  - [ ] Decide: keep and document, or remove
+- [ ] Verify Gitea repositories exist for local capabilities
+- [ ] Migrate `release-management` to submodule
+- [ ] Migrate `markitect-content` to submodule
+- [ ] Create CAPABILITY_MATRIX.md documentation
+
+### **Next Sprint**
+
+- [ ] Create DEPENDENCY_RATIONALE.md
+- [ ] Add architecture validation to Makefile
+- [ ] Add pre-commit hook for capability edits
+- [ ] Consider creating second rendering engine plugin (to validate pattern)
+
+### **Backlog**
+
+- [ ] Add CI/CD architecture validation
+- [ ] Create capability migration guide
+- [ ] Review all capability READMEs for consistency
+- [ ] Consider extracting more capabilities from main repo
+
+---
+
+## **Conclusion**
+
+The MarkiTect architecture is **fundamentally sound** with **excellent design patterns** established through the testdrive-jsui refactoring. The capabilities-based approach with self-declaring plugins demonstrates software engineering best practices.
+
+**The main work ahead is consistency:** ensuring dependency management matches actual usage and completing the submodule migration for all capabilities. These are straightforward tasks with clear paths to completion.
+
+**Key Strength:** The architecture documentation created on 2025-12-16 provides an excellent foundation for maintaining architectural integrity in future development sessions.
+
+**Recommendation:** Fix the dependency declarations immediately (Priority 1), then systematically work through the submodule migration (Priority 2). The architecture is mature enough that these are refinement tasks, not fundamental changes.
+
+---
+
+**Assessment Completed:** 2025-12-16
+**Assessor:** Claude (Sonnet 4.5)
+**Context:** Post testdrive-jsui submodule refactoring
+**Next Review:** After submodule migration completion
diff --git a/pyproject.toml b/pyproject.toml
index 817e87d9..864f9e77 100644
--- a/pyproject.toml
+++ b/pyproject.toml
@@ -9,6 +9,7 @@ description = "Advanced Markdown engine for structured content"
 readme = "README.md"
 requires-python = ">=3.8"
 dependencies = [
+    # Core external dependencies
     "markdown-it-py",
     "PyYAML",
     "click>=8.0.0",
@@ -16,14 +17,21 @@ dependencies = [
     "jsonpath-ng>=1.5.0",
     "aiohttp>=3.8.0",
     "toml",
+
+    # Core capabilities (required for basic functionality)
     "release-management @ file:./capabilities/release-management",
-    "testdrive-jsui @ file:./capabilities/testdrive-jsui"
+    "testdrive-jsui @ file:./capabilities/testdrive-jsui",
+    "issue-facade @ file:./capabilities/issue-facade",
+    "markitect-utils @ file:./capabilities/markitect-utils"
 ]
 
 [project.optional-dependencies]
 capabilities = [
     "markitect-content @ file:./capabilities/markitect-content"
 ]
+development = [
+    "kaizen-agentic @ file:./capabilities/kaizen-agentic"
+]
 
 [project.scripts]
 markitect = "markitect.cli:main"