generated from coulomb/repo-seed
48 lines
1.6 KiB
Markdown
48 lines
1.6 KiB
Markdown
# 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.
|