Markitect schema-validation integration use case and fixture for Markdown proxy documents

docs/markitect-tool-integration-usecases.md

@@ -218,6 +218,34 @@ Engine expectation:
 - The engine owns workflow templates, run state, retries, review gates,
   exceptions, audit, and derived artifacts.
 
+## Use Case 7: Markdown Proxy Schema Validation
+
+Intent: validate Markdown source or proxy documents through Markitect document
+schemas instead of adding a second Markdown schema validator to the engine.
+
+Expected Markitect APIs:
+
+- `load_schema_file(...)`
+- `validate_schema(...)`
+- `validate_document(...)`
+- `validate_markdown_file(...)`
+
+Example:
+
+```python
+from markitect_tool import validate_markdown_file
+
+result = validate_markdown_file("asset-proxy.md", "asset-proxy.schema.md")
+```
+
+Engine expectation:
+
+- Markdown proxy documents are adapter representations of governed assets.
+- Markitect owns Markdown document schema validation for those proxies.
+- Engine metadata schema validation remains registry-owned because it governs
+  asset metadata records, confirmation state, policy assignment, write
+  rejection, and audit behavior.
+
 ## Integration Test Matrix
 
 | Test area | Boundary protected |
@@ -228,6 +256,7 @@ Engine expectation:
 | Snapshot identity | Engine stores Markitect snapshot metadata without owning the algorithm. |
 | Context package policy filtering | Agent context can reuse Markitect packages and local label policy. |
 | Document contracts | Markdown validation can call Markitect contracts without moving contract semantics into the engine. |
+| Markdown document schemas | Markdown source/proxy validation uses Markitect schema APIs instead of duplicating them. |
 | Capacity sentinels | Larger generated examples expose likely parser, selector, include, context-package, and snapshot bottlenecks. |
 
 These tests are intentionally small but example-backed. They are not a