# 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.