coulomb/markitect-main
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
markitect-main/TODO.md

73 lines
3.5 KiB
Markdown
Raw Normal View History

docs: complete CHANGELOG.md with missing historical versions - Add standard Keep a Changelog header with format description - Add Unreleased section following standard format - Add comprehensive entries for versions 0.1.0, 0.2.0, and 0.3.0 - Research and document historical features using git log analysis - Follow Keep a Changelog categories (Added, Changed, Fixed) - Maintain chronological order with proper release dates - Update TODO.md to reflect completed changelog enhancement work 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-10-27 20:09:02 +01:00
# 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.
chore: updated header comments for TODO and CHANGELOG
2026-01-05 22:32:37 +01:00
See roadmap/YYMMDD-ROADMAPTOPIC/ directories for planning information like concepts, workplans, etc...
docs: complete CHANGELOG.md with missing historical versions - Add standard Keep a Changelog header with format description - Add Unreleased section following standard format - Add comprehensive entries for versions 0.1.0, 0.2.0, and 0.3.0 - Research and document historical features using git log analysis - Follow Keep a Changelog categories (Added, Changed, Fixed) - Maintain chronological order with proper release dates - Update TODO.md to reflect completed changelog enhancement work 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-10-27 20:09:02 +01:00
***
## [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.
chore: establish schema-of-schemas workplan and reorganize roadmap This commit sets up the comprehensive workplan for implementing a markdown-first schema management system with naming conventions, versioning, and self-validation capabilities. ## Directory Reorganization - Renamed `todo/` → `roadmap/` for better organization - Created `roadmap/schema-of-schemas/` subdirectory - Moved schema management planning artifacts to dedicated directory ## Planning Artifacts Created ### Workplan & Documentation - **WORKPLAN.md** (19KB) - Comprehensive 6-phase implementation plan - **SCHEMA_MANAGEMENT_PROPOSAL.md** - Full analysis with 4 options - **SCHEMA_MANAGEMENT_SUMMARY.md** - Executive summary - **README.md** - Quick reference guide ### Example Schema - **examples/schemas/manpage-schema-v1.md** - Demonstrates markdown format ## Schema Management System Design ### Naming Convention **Format:** `{domain}-schema-v{major}.{minor}.md` **Examples:** - `manpage-schema-v1.0.md` - `terminology-schema-v1.0.md` - `api-documentation-schema-v1.0.md` ### Markdown-First Format Schemas will be markdown files with: - YAML frontmatter for metadata - Rich documentation sections - Embedded JSON schema in code block - Version history and examples ### Implementation Phases (8-10 days) **Phase 0:** Planning & Setup ✅ (0.5 days) - COMPLETE **Phase 1:** Filename Convention (1 day) - NEXT **Phase 2:** Markdown Loader (2-3 days) **Phase 3:** Schema-for-Schemas (2 days) **Phase 4:** Schema Migration (1-2 days) **Phase 5:** CLI & Documentation (1 day) **Phase 6:** Testing & Validation (1 day) ### Goals 1. ✅ Establish naming convention 2. ⏳ Implement filename validation 3. ⏳ Create markdown schema loader 4. ⏳ Build schema-for-schemas metaschema 5. ⏳ Migrate 5 existing schemas (remove 2 duplicates) 6. ⏳ Update CLI and documentation ## Updated Tracking ### TODO.md - Added Schema-of-Schemas as active work item - Documented Phase 1 tasks and timeline - Paused capability extraction work ### CHANGELOG.md - Added schema management system to [Unreleased] - Documented directory reorganization - Added "In Progress" section for current work ## Next Steps Begin Phase 1: 1. Implement schema_naming.py with validation 2. Add unit tests 3. Update CLI schema-ingest command 4. Create naming specification document ## Files Changed - CHANGELOG.md - Added unreleased schema management features - TODO.md - Updated active work tracking - roadmap/ - Reorganized from todo/ - roadmap/schema-of-schemas/ - New planning directory - examples/schemas/ - Example markdown schema 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2026-01-04 23:47:02 +01:00
### Extract Capability-Capability from Issue-Facade (Paused)
docs: add capability-capability extraction plan to TODO.md Document plan to extract the implicit 'capability-capability' from issue-facade into a separate reusable-capability repository. Issue-facade currently provides two capabilities: 1. issue-tracking (explicit) - Issue management across platforms 2. capability-capability (implicit) - Patterns for creating/managing capabilities The capability-capability includes: - Feedback pattern and tooling - Detachment facility - Integration scripts - CAPABILITY-*.yaml specification format - ReusableCapabilitiesArchitecture.md - Directory conventions (_family/implementation, visible/hidden) Extraction plan divided into 4 phases: Phase 1: Specification & Planning - Create CAPABILITY-capability.yaml to declare the implicit capability - Define boundaries between families - Document API surface - Identify files to extract - Plan extraction strategy Phase 2: Repository Creation - Create reusable-capability repo - Extract all capability-capability files - Create canonical CAPABILITY-capability.yaml Phase 3: Integration & Testing - Integrate reusable-capability into issue-facade - Test functionality still works - Update documentation Phase 4: Dogfooding & Validation - Use in another capability - Validate and refine based on real usage Also documented completed tasks from today's architecture refactoring. Current step: Phase 1, Task 1 - Create CAPABILITY-capability.yaml
2025-12-17 23:02:21 +01:00
**Context:** Issue-facade currently provides two capabilities:
1. **issue-tracking** (explicit in CAPABILITY-issue-tracking.yaml) - Issue management across platforms
2. **capability-capability** (implicit) - Patterns and tools for creating/managing capabilities
The **capability-capability** includes:
- Feedback pattern (feedback/ directory, .capability/feedback CLI tool, documentation)
- Detachment facility (.capability/detach script for clean capability removal)
- Integration pattern (.capability/integrate.sh for project integration)
- CAPABILITY-*.yaml specification format
- ReusableCapabilitiesArchitecture.md (complete specification)
- Directory conventions (_family/implementation, visible/hidden patterns)
**Goal:** Extract capability-capability to separate `reusable-capability` repository so it can be used by any capability in the markitect ecosystem.
**Approach:** Step-by-step extraction, starting with specification.
#### Phase 1: Specification & Planning (Current)
- [ ] Create CAPABILITY-capability.yaml in issue-facade to explicitly declare the implicit capability
- [ ] Define what belongs to capability-capability family vs issue-tracking family
- [ ] Document the capability-capability API surface (what tools/patterns it provides)
- [ ] Identify all files/directories to extract
- [ ] Plan extraction strategy (copy vs move, how to maintain during transition)
#### Phase 2: Repository Creation
- [ ] Create reusable-capability repository structure
- [ ] Extract ReusableCapabilitiesArchitecture.md to new repo
- [ ] Extract feedback pattern (directory structure, CLI tool, README)
- [ ] Extract detachment facility (.capability/detach)
- [ ] Extract integration scripts (.capability/integrate.sh, integration-checklist.md)
- [ ] Create CAPABILITY-capability.yaml in new repo (canonical version)
- [ ] Add README.md for reusable-capability repo
#### Phase 3: Integration & Testing
- [ ] Update issue-facade to depend on reusable-capability (as integrated capability)
- [ ] Integrate reusable-capability into issue-facade using _capability/reusable-capability pattern
- [ ] Test that issue-facade still works with extracted capability
- [ ] Update issue-facade documentation to reference both capabilities it provides/uses
- [ ] Verify feedback system still works
- [ ] Verify detachment still works
#### Phase 4: Dogfooding & Validation
- [ ] Choose another markitect capability for dogfooding
- [ ] Integrate reusable-capability into that capability
- [ ] Add feedback system to new capability
- [ ] Add detachment facility to new capability
- [ ] Document learnings and refine reusable-capability based on real-world usage
- [ ] Update ReusableCapabilitiesArchitecture.md with insights
**Current Step:** Phase 1, Task 1 - Create CAPABILITY-capability.yaml
docs: update TODO.md with completed theme system refactor - Mark theme system refactor as completed - Add context about new layered theme capabilities - Document successful implementation of sophisticated theme combinations 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-10-27 21:31:15 +01:00
Reference in a new issue Copy permalink