tegwick
b51999582e
Add comprehensive example showcasing schema validation with self-documenting manpage system: - markdown-manpage-schema.json: Reusable schema for Unix manpage structure - markdown-schema-validation.1.md: Complete manual about schema validation - README.md: Usage guide, integration examples, and best practices - SCHEMA_EVOLUTION_WORKPLAN.md: Roadmap for enhanced schema system The manual validates against its own schema, demonstrating dogfooding principle. Workplan outlines 5-phase evolution from rigid structural validation to flexible content control with blueprints. Key features demonstrated: - Schema-driven documentation structure - Self-validating documentation - Reusable validation patterns - Classification system design (required/recommended/optional/discouraged/improper) This sets foundation for Phase 1 implementation: enhanced schema format with section classification and content control. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
87 lines
4.0 KiB
Markdown
87 lines
4.0 KiB
Markdown
# 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.
|
|
|
|
0. the file TODO.html is legacy i think and can be removed
|
|
|
|
### Extract Capability-Capability from Issue-Facade
|
|
|
|
**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
|
|
|
|
***
|
|
|
|
## Completed Tasks
|
|
|
|
*Recent completed tasks have been documented in _issue-tracking/issue-facade/CHANGELOG.md following Keep a Changelog format.*
|
|
|
|
### 2025-12-17 - Architecture Refactoring
|
|
- ✅ Implemented ReusableCapabilitiesArchitecture v0.1
|
|
- ✅ Added feedback capability to issue-facade
|
|
- ✅ Created detachment facility
|
|
- ✅ Refactored to family-based directory structure (_issue-tracking/issue-facade)
|
|
- ✅ Made feedback directory visible (feedback/ not .feedback/)
|
|
- ✅ Renamed to explicit family declaration (CAPABILITY-issue-tracking.yaml)
|
|
- ✅ Created CHANGELOG.md documenting v1.0.0
|