markitect-tool/docs/compatibility-policy.md

Compatibility Policy

markitect-tool is a successor, not a compatibility release of markitect-main.

Default

Do not preserve legacy module paths, database-backed workflows, or command names unless the new PRD/FRS requires the behavior.

The durable compatibility target is the new product contract:

• Markdown input/output
• Structured document representation
• Schema validation and reporting
• Transform/query/template operations
• mkt CLI and library API

What May Be Compatible

Compatibility is acceptable for:

• Markdown schema file format, if it remains clean and provider-neutral.
• Validation error concepts and output formats, if they fit the new structured error model.
• Template variable syntax, if deterministic and documented.
• Transclusion/include directive syntax, if made explicit and testable.
• Selected fixture files, if they do not encode platform assumptions.

What Should Not Be Compatible

Do not carry forward:

• markitect.* import paths as public API.
• markitect CLI command names as MVP aliases.
• SQLite/database ingest/list/query behavior.
• GraphQL API behavior.
• Infospace, spaces, prompt execution, LLM provider configuration, rendering, asset, finance, wishlist, or legacy-management behavior.
• Backward compatibility shims whose only purpose is old internal tooling.

Migration Stance

Consumers should migrate to mkt and the new library API intentionally. Any compatibility shim must have a named downstream consumer, a removal condition or stability commitment, and tests proving it does not pull platform concerns into the core.