Add comprehensive CHANGELOG validation to release validation process:
- Add _validate_changelog() method that validates CHANGELOG.md against
changelog-schema-v1.0.md using markitect validate --semantic
- Add validate_changelog_version() to check version section exists with
proper date format and Unreleased section
- Add check_version_tag_consistency() to verify CHANGELOG versions
match git tags
- Integrate CHANGELOG validation into validate_release_state()
- Add CHANGELOG-specific recommendations to _get_recommendations()
This prevents releases with invalid or inconsistent CHANGELOG files,
catching format errors before they become problems.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Added --push/--no-push flag to release tag command for explicit control
over tag pushing behavior.
**Implementation**:
- Added --push/--no-push flag to CLI tag command (default: --push)
- Updated ReleaseManager.create_tag to accept push parameter
- Updated GitManager.create_tag to conditionally push based on flag
- Maintains backward compatibility (defaults to pushing)
**Usage**:
```bash
# Default behavior - creates and pushes tag
release tag --version 0.11.0
# Explicit push (same as default)
release tag --version 0.11.0 --push
# Create tag but don't push (manual push later)
release tag --version 0.11.0 --no-push
```
**Output when --no-push used**:
```
✅ Tag v0.11.0 created
💡 Push tag with: git push origin v0.11.0
```
**Benefits**:
- Makes push behavior explicit and controllable
- Prevents accidental pushes in some workflows
- Defaults to safe behavior (automatic push)
- Helpful reminder shown when --no-push used
**Files Modified**:
- capabilities/release-management/src/release_management/cli/main.py
- capabilities/release-management/src/release_management/core/manager.py
- capabilities/release-management/src/release_management/git/manager.py
Optimizations completed: 2/9 (High Priority)
Added unpushed tag detection to release status command to prevent
forgotten tag pushes (the critical issue from v0.10.0 release).
**Implementation**:
- Added `get_unpushed_tags()` method to GitManager
- Compares local tags with remote tags (git ls-remote)
- Handles annotated tags correctly (strips ^{} suffix)
- Added unpushed_tags to repository status dict
**CLI Enhancement**:
- `release status` now shows unpushed tags with warning emoji
- Lists all unpushed tags
- Provides helpful command to push them
**Output Example**:
```
⚠️ Unpushed Tags: 2 tag(s) not pushed to origin
- v0.9.0
- v0.10.0
💡 Push tags with: git push origin v0.9.0 v0.10.0
Or push all tags: git push --tags
```
**Testing**: Verified with current repo (no unpushed tags after push)
**Files Modified**:
- capabilities/release-management/src/release_management/git/manager.py
- capabilities/release-management/src/release_management/cli/main.py
**Documentation**: Added comprehensive IMPLEMENTATION_PLAN.md with
all 9 optimizations detailed (13.5 hours total estimated)
This solves the #1 critical issue from OPTIMIZATION_ASSESSMENT.md.
Added critical optimization #1 based on v0.10.0 release experience:
**Issue**: git status doesn't show unpushed tags, leading to forgotten tag pushes
**Impact**: v0.9.0 and v0.10.0 tags weren't pushed, plus older version tags
**Solution**: Enhanced release status or git hook to show unpushed tags
Total optimizations identified: 9 (was 8)
- High Priority: 4 (added unpushed tags visibility)
- Medium Priority: 3
- Low Priority: 2
Ready to implement all optimizations systematically.
Added comprehensive documentation to release-management-optimization topic:
**RELEASE_SUMMARY.md**:
- Complete v0.10.0 release documentation
- Build artifacts, testing results, validation status
- Git statistics and file changes
- Next steps and manual actions required
**OPTIMIZATION_ASSESSMENT.md**:
- Post-release analysis of what worked vs. issues
- Identified 8 optimization opportunities across 3 priority levels
- Detailed Stage 3 implementation recommendations
- Three options for next steps (Complete Stage 3, Quick Wins, or Move On)
**Key Finding**: Forgot to push tags (git push doesn't include tags by default)
**Action Required**: `git push --tags` to push v0.9.0 and v0.10.0 tags
**Recommendation**: Implement Stage 3 (2 hours) for automated validation
and tag pushing to prevent similar issues in future releases.
Created comprehensive changelog-schema-v1.0.md to validate CHANGELOG.md
files following the Keep a Changelog format. This schema demonstrates
the practical application of the schema evolution system.
**Schema Features**:
- Section validation: Enforces [Unreleased] section presence
- Version format validation: [X.Y.Z] - YYYY-MM-DD pattern
- Semantic versioning compliance
- ISO 8601 date format checking
- Change type subsections: Added, Changed, Deprecated, Removed, Fixed, Security
- Content pattern matching via x-markitect-content-control extensions
- Structural validation via JSON Schema properties
**Validation Results**:
✅ Successfully validates project CHANGELOG.md
✅ All section requirements met (7 sections checked, 11 found)
✅ All content requirements met
✅ All semantic checks passing
**Implementation Notes**:
- H1 "Changelog" title validated via JSON Schema structural checks
- H2 sections validated via x-markitect-sections classifications
- SectionValidator limitation: Only checks H2+ headings, not H1
- Workaround: Structural validation covers H1 title requirement
**Philosophy**: "The release that validates itself"
- v0.10.0 uses its own schema system to validate its CHANGELOG
- Perfect showcase of schema evolution practical value
- Demonstrates x-markitect extensions in real-world use case
**Stage 2 Complete** per release-management-optimization workplan.
Files:
- markitect/schemas/changelog-schema-v1.0.md (new)
- CHANGELOG.md (documented new schema)
**Critical Fixes for v0.10.0 Release**:
1. **Fixed setuptools-scm Configuration** (pyproject.toml):
- Added git_describe_command with --match 'v*' pattern
- Prevents setuptools-scm from parsing non-version tags
- Resolves "markitect --version" returning "unknown"
- Version detection now works correctly (0.9.1.dev76)
2. **Retroactively Created v0.9.0 Git Tag**:
- Tagged commit b9c1b90 from 2025-11-14
- Maintains version history integrity
- CHANGELOG documented v0.9.0 but tag was missing
- Enables proper version progression to v0.10.0
3. **Prepared CHANGELOG.md for v0.10.0 Release**:
- Created [0.10.0] - 2026-01-06 section
- Moved all Unreleased content to v0.10.0
- Documented version detection fixes
- Documented v0.9.0 retroactive tag creation
**Issue Identified**: Non-version git tags (e.g.,
"testdrive-jsui-migration-phase4-complete") were causing
setuptools-scm to crash with AssertionError.
**Solution**: Configure git describe to only match version tags
using --match 'v*' pattern, filtering out non-version tags.
**Result**: Version command now works correctly, showing
development version based on v0.9.0 + 76 commits.
**Next Step**: Ready to proceed with Stage 2 (CHANGELOG schema)
per release-management-optimization workplan.
Created comprehensive staged workplan for enhancing release management
infrastructure with robust validation using the schema system.
**Critical Issues Identified**:
- setuptools-scm missing tag_regex configuration
- markitect --version returns 'unknown' instead of actual version
- CHANGELOG shows v0.9.0 (2025-11-14) but git tag never created
- No validation for CHANGELOG format or version-tag consistency
**Solution Approach**:
Create changelog-schema-v1.0.md to validate Keep a Changelog format,
demonstrating schema evolution in real-world use case.
**Staged Workplan**:
- Stage 1 (45 min): Critical fixes to unblock v0.10.0 release
- Stage 2 (2.5 hrs): CHANGELOG schema creation and validation
- Stage 3 (2 hrs): Release capability enhancements
- Stage 4 (optional): Schema system extensions
**Showcase Feature**: 'The release that validates itself'
- v0.10.0 uses its own schema system to validate its CHANGELOG
- Perfect demonstration of schema evolution practical value
**Next Version**: v0.10.0 (not v0.9.0)
- CHANGELOG already shows v0.9.0 as released
- Must maintain version history integrity
This commit closes the schema-evolution topic (260105) by adding the final
deliverable (ADR schema) and fixing markdown schema support across commands.
**ADR Schema Created**:
- Comprehensive Architecture Decision Record validation schema
- 12 section classifications (7 required, 2 recommended, 2 optional, 3 improper/discouraged)
- Content pattern validation for ADR formatting rules (status dates, decision statements, rationale structure)
- Quality metrics for completeness (word counts, sentence counts)
- Follows title case naming convention (Status, Context, Decision, etc.)
**Markdown Schema Support Fixed**:
- Fixed `markitect validate` command to support .md schemas
- Added load_schema_from_path() for both .json and .md files
- Updated structural and semantic validation to use schema dict
- Fixed `markitect generate-stub` command to support .md schemas
- Uses load_schema_from_path() instead of direct JSON loading
- Created DocumentWrapper class in semantic_validator.py
- Extracts headings from AST tokens (heading_open, inline)
- Provides get_headings_by_level() interface expected by validators
- Enables section validation to work with real documents
**Topic Closure**:
- Updated SCHEMA_EVOLUTION_WORKPLAN.md with completion summary
- Phases 1-3: 100% complete (via Schema-of-Schemas and Semantic Validation)
- Phase 4: Deferred as future enhancement (15-20 sessions)
- Phase 5: 70% complete (docs done, CI/CD templates deferred)
- Created DONE.md with comprehensive task checklist
- Generated ADR template stub (examples/templates/adr-template.md)
- Moved topic from roadmap/ to history/260105-schema-evolution/
**Files Changed**:
- markitect/cli.py: Added markdown schema support to validate and generate-stub
- markitect/semantic_validator.py: Added DocumentWrapper class for AST parsing
- markitect/schemas/adr-schema-v1.0.md: New ADR validation schema (560 lines)
- examples/templates/adr-template.md: Generated ADR template stub
- history/260105-schema-evolution/: Moved completed topic to history
**Status**: Schema evolution topic successfully closed with ADR schema as final deliverable.
All schema commands now support markdown schemas. Section validation working correctly.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Naming Convention Updates:
- Renamed history/2026-01-06-semantic-document-validation → history/260106-semantic-document-validation
- Documented yymmdd- format convention in history/README.md and roadmap/README.md
- Updated all date references in WORKPLAN.md and DONE.md
- Fixed SCHEMA_MANAGEMENT_GUIDE.md references to use yymmdd- format
Convention Details:
- Format: yymmdd-topic-name (e.g., 260106-semantic-document-validation)
- Benefits: Concise while maintaining chronological sorting
- Examples documented in both README files
- Applies to both roadmap/ and history/ directories
This establishes a consistent timestamp prefix convention that Claude and its agents should follow.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Repository Cleanup:
- Moved roadmap/20260106-semantic-document-validation → history/2026-01-06-semantic-document-validation
- Added completion summary to WORKPLAN.md documenting all 6 phases
- Created DONE.md with detailed list of accomplished tasks
- Documented all deliverables, commits, and success metrics
Topic Status: COMPLETED on 2026-01-06
- All phases complete: Section, Content, Link validation
- 25 tests passing (100% coverage)
- Full documentation and CLI integration
- Production ready
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Added link validation details to semantic validation entry:
- Internal link validation (fragments and file paths) by default
- External link validation with --check-links flag (opt-in)
- Email validation for mailto: links
- Updated test coverage: 25 tests (16 section/content + 9 link)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Implement comprehensive link validation as part of semantic validation:
Core Features:
- Link classification: internal, external, fragment, email
- Internal link validation: fragment anchors and file paths
- External link validation: HTTP/HTTPS with configurable timeout
- Email validation: mailto: link format checking
- Fragment policy enforcement: allow/disallow fragment identifiers
Link Validator:
- markitect/validators/link_validator.py - Full link validation implementation
- Supports x-markitect-content-control.link_validation configuration
- Default: check internal links, skip external (fast)
- Opt-in external checking with --check-links flag
Integration:
- Updated SemanticValidator to include link_result in reports
- CLI already supports --check-links flag (line 1629 in cli.py)
- Link validation runs by default for internal links (fast)
- External link checking requires explicit --check-links flag
Test Coverage:
- Added 9 comprehensive tests for LinkValidator
- Tests cover: classification, broken links, fragments, email, statistics
- All 25 semantic validator tests passing (100%)
Documentation:
- Updated SCHEMA_MANAGEMENT_GUIDE.md with link validation section
- Added examples for broken links and external link checking
- Documented link types, validation rules, and configuration
Statistics Tracking:
- Links checked, internal/external/fragment/email counts
- Detailed error/warning reporting with line numbers
- Integration with existing semantic validation reporting
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Updated submodule reference after rebasing local commits on top of
remote changes. Local commits for project agent and TODO.md integration
now applied after remote updates to keepaTodofile and keepaContributingfile
agents.
Rebased commits:
- afc038d: agent: updated kaizen project agent
- 4b02ec5: feat: update project-management agent for TODO.md integration
Remote commits integrated:
- d372aea: Update agents/agent-keepaContributingfile.md
- 850a09e: Update agents/agent-keepaTodofile.md
Moved schema-of-schemas planning artifacts from roadmap to history
with datestamp prefix, marking completion of all 6 implementation phases.
**Changes:**
- Moved roadmap/schema-of-schemas/ → history/2026-01-05-schema-of-schemas/
- Updated all documentation references to new location
- Marked implementation as completed in TODO.md
- Updated CHANGELOG.md to reflect archived status
**Implementation Summary:**
All 6 phases completed successfully:
- Phase 1: Filename validation (50 tests)
- Phase 2: Markdown schema loader (35 tests)
- Phase 3: Schema-for-schemas metaschema (12 tests)
- Phase 4: Schema migration (2 migrated, 3 deleted)
- Phase 5: CLI enhancements (multi-schema validation)
- Phase 6: Integration testing and documentation
**Deliverables:**
- 97 unit tests (100% passing)
- 4 production schemas in registry
- Comprehensive user documentation
- Updated examples (manpages, terminology)
- Complete schema management system
The schema-of-schemas topic is now complete and archived for
historical reference.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Updated example documentation to use the new schema-of-schemas standard
with markdown schema format and multi-schema validation commands.
**Manpage Example Updates:**
- Changed schema reference from markdown-manpage-schema.json to manpage-schema-v1.0.md
- Updated all commands to use new multi-schema validation syntax
- Added examples of number-based validation (markitect schema-validate 2)
- Added examples of batch validation (--all, ranges, lists)
- Updated integration examples (CI/CD, pre-commit hooks, Makefile)
- Documented schema registry workflow
**Terminology Example Updates:**
- Changed schema reference from terminology-schema.json to terminology-schema-v1.0.md
- Updated all validation commands to use new CLI syntax
- Added examples of schema-list and numbered selection
- Added batch validation examples
- Updated GitHub Actions and pre-commit hook examples
- Documented schema registry access methods
**Key Changes:**
- All schema filenames now follow {domain}-schema-v{major}.{minor}.md convention
- Commands use schema registry with numbered or filename selection
- Batch validation examples added throughout
- Integration examples updated to new standard
- Documentation reflects markdown-first schema format
All schemas validated successfully against metaschema.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Enhanced schema-list and schema-validate commands to support efficient
batch validation of multiple schemas, especially useful when the
metaschema changes.
**schema-list enhancements:**
- Added numbered references (#1, #2, etc.) to all output formats
- Simple format: [1] prefix for each schema
- Table format: # column as first column
- JSON/YAML: number field added to each schema
**schema-validate enhancements:**
- Number selection: `markitect schema-validate 1`
- Range selection: `markitect schema-validate 1-3`
- List selection: `markitect schema-validate 1,3,5`
- Batch validation: `markitect schema-validate --all`
- Filename selection: `markitect schema-validate schema.md`
- Filesystem path: `markitect schema-validate ./schema.md`
- Batch results displayed as clear summary table
- Registry schemas take precedence with filesystem fallback
- Full backward compatibility maintained
**Implementation details:**
- Added ValidationResult dataclass for structured results
- Added helper functions: parse_schema_selector, resolve_schema_source,
is_filesystem_path, format_validation_summary
- Changed schema_selector from Path to str for flexible input
- Added --all flag for validating all registered schemas
- Comprehensive error handling and helpful usage messages
**Testing:**
- All selection methods tested and working
- Backward compatibility verified
- Parsing utilities tested with unit tests
Completes Phase 5 of Schema-of-Schemas implementation.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Completed Phase 4 of the schema-of-schemas implementation with successful
migration of all legacy schemas to the new markdown format following the
naming convention.
Migration Script (scripts/migrate_schemas.py - 240 lines):
- Automated schema migration from JSON to markdown format
- Updates version and $id fields to follow conventions
- Generates proper frontmatter metadata
- Dry-run mode for safe testing
- Database cleanup functionality
- Comprehensive progress reporting
Schemas Migrated (2):
- terminology-schema.json → terminology-schema-v1.0.md
- Fixed missing version field
- Updated $id from /terminology-v1.json to /terminology/v1.0
- Validates successfully against metaschema
- api-documentation → api-documentation-schema-v1.0.md
- Added version: 1.0.0
- Updated $id to follow /api-documentation/v1.0 format
- Validates successfully against metaschema
Schemas Deleted (3):
- markdown-manpage (duplicate of manpage-schema-v1.0.md)
- markdown-manpage-schema.json (duplicate of manpage-schema-v1.0.md)
- enhanced-manpage (replaced by manpage-schema-v1.0.md)
CLI Enhancement (markitect/cli.py):
- Updated schema-ingest to support markdown (.md) files
- Auto-detects file type and uses MarkdownSchemaLoader for .md files
- Extracts JSON schema from markdown for database storage
- Maintains backward compatibility with JSON files
Final Schema Registry (4 schemas):
✅ terminology-schema-v1.0.md - Terminology validation
✅ api-documentation-schema-v1.0.md - API documentation structure
✅ manpage-schema-v1.0.md - Unix manual pages
✅ schema-schema-v1.0.md - Metaschema for validating schemas
All schemas:
- Follow naming convention: {domain}-schema-v{major}.{minor}.md
- Include proper frontmatter with schema-id, version, status
- Validate successfully against schema-schema-v1.0.md metaschema
- Stored in database and ready for use
Progress Tracking:
- Updated TODO.md with Phase 4 completion
- Updated CHANGELOG.md with migration details
- Next: Phase 5 - CLI & Documentation Updates
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Completed Phase 2 of the schema-of-schemas implementation with full
markdown schema support. This enables schemas to be authored as
markdown files with rich documentation and embedded JSON schemas.
Core Implementation (markitect/schema_loader.py):
- MarkdownSchemaLoader class with comprehensive parsing capabilities
- YAML frontmatter extraction with error handling
- JSON code block extraction with section preference (## Schema Definition)
- Metadata merging with x-markitect-source tracking
- Schema saving with template support and round-trip capability
- Helper methods: list_json_blocks(), validate_schema_structure()
Test Coverage (tests/test_schema_loader.py):
- 35 comprehensive unit tests (100% passing)
- Tests for loading, parsing, saving, round-trip conversion
- Edge case handling (empty files, binary files, malformed blocks)
- Fixed binary file test to use invalid UTF-8 sequences
Example Schema (markitect/schemas/manpage-schema-v1.0.md):
- First markdown schema following naming convention
- Complete manpage schema with frontmatter + documentation + JSON
- Demonstrates section classification and content control
- Shows proper structure for future schema authors
Documentation (roadmap/schema-of-schemas/SCHEMA_LOADER_GUIDE.md):
- Comprehensive user guide (600+ lines)
- API reference with examples
- Best practices and troubleshooting
- Integration patterns for CLI and validator
Progress Tracking:
- Updated TODO.md with Phase 2 completion
- Updated CHANGELOG.md with implementation details
- Next: Phase 3 - Schema-for-Schemas Metaschema
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This commit completes Phase 2 of schema evolution work and establishes
a new example demonstrating schema usage for terminology documents.
## New Features
### Terminology Validation Example (examples/terminology/)
- Complete example terminology document with proper structure
- JSON schema with MarkiTect extensions for validation
- Demonstrates schema usage beyond manpages (glossaries, lexicons)
- Validates term structure: Definition, Synonyms, Related Terms, Examples
- Includes content control and quality validation rules
- Full documentation with usage examples and best practices
### Schema Registration System
- Registered terminology schema in markitect database
- Created schema catalog (markitect/schemas/schema-catalog.yaml)
- Copied schema to official location (markitect/schemas/)
- Provides metadata, features, and usage info for all schemas
### Improved schema-list Command
- Now displays creation timestamps in default output
- Table format includes Created/Updated columns
- Cleaner timestamp formatting (removed microseconds)
- Better visibility into when schemas were added
## Files Changed
Added:
- examples/terminology/README.md - Complete documentation
- examples/terminology/terminology-example.md - Example glossary
- examples/terminology/terminology-schema.json - Validation schema
- markitect/schemas/terminology-schema.json - Registered schema
- markitect/schemas/schema-catalog.yaml - Schema registry
Modified:
- markitect/cli.py - Enhanced schema-list with timestamps
- TODO.md - Documented Phase 2 completion and new example
Moved:
- SCHEMA_EVOLUTION_WORKPLAN.md → todo/ directory
## Schema Features Demonstrated
- Heading hierarchy validation (H1 → H2 → H3)
- Term structure validation with required/optional fields
- Content quality metrics (word counts, readability targets)
- MarkiTect extensions (x-markitect-sections, x-markitect-content-control)
- Classification system (required/recommended/optional/discouraged/improper)
## Usage
```bash
# List schemas with timestamps
markitect schema-list
# Validate terminology document
markitect validate glossary.md --schema terminology-schema.json
# View in table format
markitect schema-list --format table
```
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Added --interactive/-i flag to schema-refine command that allows users to
review and approve each refinement individually:
- Displays each detected issue with details
- Shows current and suggested values
- Prompts for confirmation (y/N/q)
- Applies only approved fixes
- Shows summary at completion
This gives users fine-grained control over which refinements to apply.
Example usage:
markitect schema-refine schema.json --interactive
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Implemented two new CLI commands for schema analysis and refinement:
1. schema-analyze: Analyzes schemas for rigidity issues
- Detects exact counts that should be ranges
- Identifies missing classification system
- Flags deprecated extensions
- Calculates rigidity score (0-100)
- Provides detailed or summary reports
2. schema-refine: Automatically refines rigid schemas
- Converts exact counts to flexible ranges
- Rounds overly specific numbers
- Widens narrow integer constraints
- Supports dry-run mode
- Can save to new file or overwrite in place
Key improvements:
- Created SchemaAnalyzer class with issue detection
- Created SchemaRefiner class with automatic fixes
- Improved schema navigation to handle nested properties
- Tested on example schemas (reduced rigidity from 60/100 to 24/100)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Comprehensively document the new classification system and content control
features added in Phase 1.
## Documentation Updates
### New Content Added
**1. Updated MarkiTect Extensions Section**
- Replaced deprecated x-markitect-required/recommended-sections
- Documented x-markitect-sections with five classification levels
- Documented x-markitect-content-control for content validation
**2. Added Section Classification System (150+ lines)**
- Detailed explanation of all five classification levels:
- required: Missing = ERROR
- recommended: Missing = WARNING
- optional: No validation impact
- discouraged: Present = WARNING
- improper: Present = ERROR
- Validation behavior for each classification
- JSON examples for each level
**3. Added Content Control Documentation**
- Pattern validation (required/discouraged/forbidden)
- Content quality metrics (word count, readability targets)
- Content instructions for authors
- Complete examples with explanations
**4. Updated Schema Design Best Practices**
- Replaced old extension examples with new classification system
- Added guidance on choosing appropriate classifications
- Examples showing required, recommended, optional, discouraged, improper
**5. Added Classification System Example**
- Complete working schema demonstrating all features
- Validation scenarios showing different outcomes
- Integration of sections and content-control extensions
## Changes Summary
**Lines Added**: ~200 lines of new documentation
**Sections Updated**: 4 major sections
**Examples Added**: 8 new code examples
**Key Topics Covered**:
- Five-level classification system (required → improper)
- Content pattern validation
- Quality metrics and readability targets
- Content instructions for document authors
- Validation behavior for each classification
- Complete working examples
## Validation
✅ Manual validates against improved markdown-manpage-schema.json
✅ All new features documented with examples
✅ Backward compatibility maintained
✅ Self-documenting: manual uses the features it documents
The manual now comprehensively documents the Phase 1 enhanced schema
system while itself validating against a schema using those features.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
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>
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
Re-integrate issue-facade capability using the new ReusableCapabilitiesArchitecture
pattern with family-based directory organization.
New Structure:
- _issue-tracking/issue-facade/ (family-based organization)
- Uses underscore prefix to signal integrated capability
- Implements ReusableCapabilitiesArchitecture v0.1
Capability Features (from refactored version 35daa51):
- CAPABILITY-issue-tracking.yaml (explicit family declaration)
- feedback/ directory (visible user interface)
- .capability/detach script (clean removal facility)
- ReusableCapabilitiesArchitecture.md (complete specification)
This integration follows the principle that capabilities are conceptual
units organized by family, enabling multiple implementations of the same
capability family to coexist.
Architecture: _<family>/<implementation>/ pattern
Example: _issue-tracking/issue-facade/
See _issue-tracking/issue-facade/ReusableCapabilitiesArchitecture.md for details.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Detach issue-facade from capabilities/ directory in preparation for
re-integration using new ReusableCapabilitiesArchitecture pattern.
Changes:
- Remove capabilities/issue-facade submodule
- Add detachment manifest with re-integration metadata
Next: Re-integrate as _issue-tracking/issue-facade/ (family-based organization)
Detachment manifest: capabilities/DETACHED-issue-facade.yaml
Original commit: 35daa514e59788250847cd706c43ea78f24c5c1d
