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

workplans/MKTT-WP-0005-runtime-context-and-assessment-engines.md

@@ -3,10 +3,10 @@ id: MKTT-WP-0005
 type: workplan
 title: "Runtime Context, Form, and Assessment Engines"
 domain: markitect
-status: todo
+status: done
 owner: markitect-tool
 topic_slug: markitect
-planning_priority: P2
+planning_priority: complete
 planning_order: 70
 depends_on_workplans:
   - MKTT-WP-0003
@@ -31,7 +31,11 @@ This workplan picks up the deferred runtime scope from
 
 ## Decision
 
-Do not start this immediately unless one of these is true:
+This workplan is implemented. It was picked up after the workflow and internal
+extension framework work made runtime form/context evaluation useful and cleanly
+integrable.
+
+The original trigger conditions were:
 
 - We are implementing template/generation flows that need reliable field
   prefill and pre-render validation.
@@ -41,16 +45,12 @@ Do not start this immediately unless one of these is true:
 - A user-facing or agent-facing workflow needs structured form state, defaults,
   conditional requiredness, or guided repair.
 
-Recommended sequencing:
+Implemented sequencing:
 
 1. Implement context and form runtime first.
 2. Add deterministic context-aware rules.
-3. Add LLM assessment execution only after the diagnostic/caching boundary is
-   stable.
-
-This is probably not the next immediate implementation if we want to first
-finish core query/extraction and deterministic transform primitives. It should
-come before serious generation pipelines or any LLM review loop.
+3. Add provider-neutral assessment execution after the diagnostic/caching
+   boundary was stable.
 
 ## Background
 
@@ -76,7 +76,7 @@ It does not yet execute:
 
 ```task
 id: MKTT-WP-0005-T001
-status: todo
+status: done
 priority: high
 state_hub_task_id: "e24e6238-efef-41c4-9f1e-ca677c1be89b"
 ```
@@ -96,7 +96,7 @@ Expected output: design notes and tests for context loading.
 
 ```task
 id: MKTT-WP-0005-T002
-status: todo
+status: done
 priority: high
 state_hub_task_id: "d180bb6d-dae8-4305-88de-64c80b708b8a"
 ```
@@ -114,7 +114,7 @@ application-specific data access belongs in adapters outside the core package.
 
 ```task
 id: MKTT-WP-0005-T003
-status: todo
+status: done
 priority: high
 state_hub_task_id: "b954984a-6f67-4e5b-8744-35e3c4fcc992"
 ```
@@ -135,7 +135,7 @@ document exists.
 
 ```task
 id: MKTT-WP-0005-T004
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "cccdf868-2308-42a1-b564-8b54fccd3c8b"
 ```
@@ -157,7 +157,7 @@ This should support future UI adapters while remaining useful from the CLI.
 
 ```task
 id: MKTT-WP-0005-T005
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "6e420e1e-2465-40d3-8e64-d8681a294e63"
 ```
@@ -178,7 +178,7 @@ small set of operators over embedding a general programming language.
 
 ```task
 id: MKTT-WP-0005-T006
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "24b22b3a-e89e-4946-81f4-94f971a11979"
 ```
@@ -205,7 +205,7 @@ implementation.
 
 ```task
 id: MKTT-WP-0005-T007
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "b09b77e2-59c0-4d31-b246-685b742d111f"
 ```
@@ -220,7 +220,7 @@ cache may be local file-based only if it remains transparent and easy to reset.
 
 ```task
 id: MKTT-WP-0005-T008
-status: todo
+status: done
 priority: high
 state_hub_task_id: "2efb8233-3154-4824-a898-6fcde37330c5"
 ```
@@ -237,14 +237,29 @@ prefill, invalid dynamic rules, and assessment failures.
 
 ## Open Questions
 
-- Should context values override frontmatter, or should conflicts always be
-  diagnostics until explicitly resolved?
-- Should the first dynamic rule syntax reuse JSON Schema conditionals or define
-  a smaller Markitect-native rule vocabulary?
-- Should LLM assessment execution live behind an optional extra, or only in
-  external adapters?
-- What cache invalidation metadata is sufficient for assessment reproducibility
-  without pretending model judgments are deterministic?
+- Resolved: document/frontmatter values win over context; conflicts are
+  diagnostics and can be escalated per field.
+- Resolved: dynamic rules use a smaller Markitect-native vocabulary over
+  JSON/YAML paths instead of embedding JSON Schema conditionals.
+- Resolved: provider execution remains external; core defines request/result,
+  runner, diagnostics, and cache boundary only.
+- Resolved for core: assessment cache keys include contract/rule/scope/text,
+  criteria, context, structured inputs, provider/model metadata, threshold, and
+  metadata. Persistent cache invalidation remains a backend concern.
+
+## Implementation Notes
+
+- Added `markitect_tool.runtime` with context loading, path resolution,
+  deterministic condition evaluation, form state, dynamic rules, assessment
+  request/result models, runner, and in-memory cache boundary.
+- `mkt contract check` now accepts `--context`.
+- Added `mkt contract form-state`.
+- Workflow `contract_check` accepts context and workflow `form_state` exposes
+  runtime field state as a step result.
+- Built-in extension descriptors now include `runtime.context`,
+  `runtime.form-state`, and `runtime.assessment`.
+- Documentation lives in `docs/runtime-context-forms-assessments.md`.
+- Examples live in `examples/runtime/`.
 
 ## Exit Criteria