context loading, path resolution, form state, dynamic rules, and provider-neutral assessment runner/cache boundary

docs/contract-framework.md

@@ -9,9 +9,9 @@ Markdown as the authoring surface and uses fenced YAML as a structured extension
 for rules that need machine interpretation.
 
 The first implementation is deterministic. It checks document type, fields,
-sections, ordering, metric bands, and text assertions. Forms, context, and LLM
-rubrics are represented in the contract vocabulary as extension points before
-runtime adapters are added.
+sections, ordering, metric bands, and text assertions. Runtime context, forms,
+dynamic rules, and provider-neutral assessment requests are implemented as
+extensions around the same contract vocabulary.
 
 ## Contract File Shape
 
@@ -112,10 +112,10 @@ fields, and metric bands. This is the bridge to later LLM rubrics: semantic
 checks can become additional assessments without changing how failures are
 reported.
 
-## Forms And Context
+## Forms, Context, And Runtime Rules
 
-Field specs are the first step toward form-backed Markdown generation. Runtime
-form handling should build on the same field vocabulary:
+Field specs are the foundation for form-backed Markdown generation and
+context-aware checks. Runtime form handling uses the same field vocabulary:
 
 - `id`
 - `type`
@@ -128,15 +128,25 @@ form handling should build on the same field vocabulary:
 - `min` / `max`
 - `min_length` / `max_length`
 
-Dynamic requiredness, visibility, calculations, and prefill should be declared
-as context-aware rules in later work. The contract should remain the source of
-truth, while UI and generation layers act as adapters.
+Runtime context can be supplied as local YAML or JSON:
+
+```text
+mkt contract check <document.md> --contract <contract.md> --context <context.yaml>
+mkt contract form-state <document.md> --contract <contract.md> --context <context.yaml>
+```
+
+The runtime resolves fields in this order: document value, context source,
+default, missing. Document values win over context and conflicts are diagnostics.
+Dynamic rules support small deterministic `if` / `then` / `else` expressions
+for requiredness, visibility, allowed values, calculated values, context
+assertions, and dynamic section presence. See
+`docs/runtime-context-forms-assessments.md`.
 
 ## LLM Assessment Extension
 
-LLM-assisted checks should be declared as rubrics, scoped to document or section
-roles. Core Markitect should not call a provider directly. A future adapter
-should accept a provider-neutral request:
+LLM-assisted checks are declared as rubrics, scoped to document or section roles.
+Core Markitect does not call a provider directly. It creates provider-neutral
+assessment requests for injected adapters:
 
 - contract id and rule id
 - document or section text
@@ -152,26 +162,11 @@ It should return:
 - model/provider metadata
 - diagnostics using the shared diagnostic model
 
-## Deferred Runtime Work
-
-The deterministic contract framework is ready now. The runtime engines are
-deferred to `MKTT-WP-0005-runtime-context-and-assessment-engines.md`.
-
-Pick that work up when one of these becomes true:
-
-- contract checks need external user, project, or entity context
-- generation needs reliable field prefill before rendering
-- a UI or agent workflow needs form state, defaults, and dynamic requiredness
-- deterministic section assertions are not enough and rubric-based semantic
-  assessment becomes necessary
-
-The intended order is context and form runtime first, deterministic dynamic
-rules second, LLM assessment execution third.
-
 ## CLI
 
 ```text
 mkt contract validate <contract.md>
-mkt contract check <document.md> --contract <contract.md>
+mkt contract check <document.md> --contract <contract.md> [--context <context.yaml>]
+mkt contract form-state <document.md> --contract <contract.md> [--context <context.yaml>]
 mkt metrics <document.md>
 ```