Workplan updates

workplans/MKTT-WP-0012-document-function-layer.md

@@ -63,19 +63,40 @@ tracks identity/provenance, and access policy gates risky operations.
 
 ## Decision
 
-Do not implement this until the deterministic workflow layer has enough shape
-to show real author pressure. Treat it as a future extension track that can
-unify processor ergonomics, workflow steps, contract-aware generation, and
-render/export adapters.
+The deterministic workflow layer, processor/reference stack, local backend, and
+internal extension framework are now in place. This workplan can be picked up
+without waiting for flex-auth or any other external authorization service.
+Treat it as an optional Markitect extension track that unifies processor
+ergonomics, workflow steps, contract-aware generation, and render/export
+adapters.
 
 Recommended sequencing:
 
-1. Finish or substantially shape `MKTT-WP-0011`.
-2. Use practical workflow examples to identify recurring author-facing step
+1. Use practical workflow examples to identify recurring author-facing step
    patterns.
-3. Define the function model as a thin authoring surface over those primitives.
-4. Add assisted and unsafe functions only after capability/policy metadata is
-   enforced.
+2. Define the function model as a thin authoring surface over existing
+   processors, references, templates, contracts, workflows, and extension
+   descriptors.
+3. Implement pure deterministic functions first.
+4. Add assisted, filesystem, external-process, network, or export functions
+   only after local capability and policy metadata are enforced.
+5. Keep flex-auth integration optional through policy adapter protocols; do
+   not require a live flex-auth service for function parsing, registration, or
+   deterministic execution.
+
+## Current Code Fit
+
+The workplan should build on current Markitect primitives:
+
+- `ExtensionDescriptor`, `ProcessingCapability`, `ProcessingRequest`,
+  `ProcessingContext`, `ProcessingResult`, provenance, and trace envelopes.
+- Existing processors, references, selectors, JSONPath query engines,
+  templates, contracts, runtime context, form state, and workflow steps.
+- `AccessPolicyGateway` and policy decision envelopes for gating unsafe
+  capabilities.
+
+The function layer should be an authoring surface over these capabilities, not
+a second workflow engine or a dependency on flex-auth.
 
 ## P12.1 - Define function model and vocabulary
 
@@ -221,6 +242,10 @@ Integrate with the access-control and backend capability vocabulary before any
 function can read files, access network resources, invoke external processes, or
 call assisted-generation adapters.
 
+Use Markitect-local `AccessPolicyGateway`/capability metadata as the required
+contract. External policy services, including flex-auth, may provide decisions
+through adapters later but must not be required.
+
 Output: permission model, blocked-operation diagnostics, and policy examples.
 
 ## P12.8 - Add author-facing examples
@@ -252,5 +277,7 @@ Output: examples and comparison notes against Quarkdown-inspired patterns.
   dependencies.
 - Function calls preserve source provenance and can be explained.
 - Risky capabilities are declared before execution and can be blocked.
+- No live flex-auth or other external authorization service is required for
+  deterministic function execution.
 - The model composes naturally with workflows, contracts, references,
   processors, cache backends, and future assisted steps.