tegwick
fc828a345b
Some checks failed
Test Suite / performance-tests (push) Has been cancelled
Test Suite / code-quality (push) Has been cancelled
Test Suite / security-scan (push) Has been cancelled
Test Suite / unit-tests (3.11) (push) Has been cancelled
Test Suite / unit-tests (3.12) (push) Has been cancelled
Test Suite / integration-tests (push) Has been cancelled
Test Suite / e2e-tests (push) Has been cancelled
Test Suite / test-summary (push) Has been cancelled
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>
29 lines
1.1 KiB
Markdown
29 lines
1.1 KiB
Markdown
# MarkiTect Project Roadmap
|
|
|
|
This roadmap directory contains planning directories for roadmap topics.
|
|
- When starting to implement a topic its directory will be timestamped
|
|
- If implementing multiple topics in parallel use branches
|
|
- Keep current state of what's next to implement in TODO.md
|
|
- See ../history directory for closed topics
|
|
|
|
## Naming Convention
|
|
|
|
**Directory Format:** `yymmdd-topic-name`
|
|
|
|
- Use 2-digit year prefix (e.g., `260106-` for 2026-01-06)
|
|
- Lowercase topic names with hyphens
|
|
- Examples: `260106-semantic-document-validation`, `260105-schema-evolution`
|
|
|
|
This convention keeps names concise while maintaining chronological sorting.
|
|
|
|
## Purpose
|
|
|
|
This planning documentation serves multiple purposes:
|
|
|
|
1. **Implementation State Awareness**: Allow for recovery after breaks or breakdowns
|
|
2. **Minimal Plan-Implement Loop**: Don't complicate agentic coding with issue tracking if unnecessary
|
|
3. **Planning Info Analysis**: Keeping the planning info allows for retrospective analyses to optimize
|
|
4. **Clean Repo Structure**: Using roadmap/ for planning and TODO.md as current state helps stay organized
|
|
|
|
xxx
|