scoped migration filter workplan and docs

docs/compatibility-policy.md

@@ -0,0 +1,47 @@
+# 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.