Workplan updates

docs/workplan-planning-map.md

@@ -76,12 +76,26 @@ capability-gated, especially before assisted, external, file, or network
 functions are allowed.
 
 `MKTT-WP-0014` completed Markitect-side enterprise IAM integration for the
-access-control gateway. Central authorization administration remains
+access-control gateway. Central authorization administration remains optional
-`flex-auth` scope; Markitect now provides resource registration, policy
+external-service scope; Markitect now provides resource registration, policy
 request, decision, diagnostics, local development adapter contracts, workflow
-declarations, and CLI inspection/mapping commands. Production deployment of
+declarations, and CLI inspection/mapping commands. Remaining Markitect
-reactivatable agent context packages should still wait for a flex-auth-backed
+workplans should depend only on Markitect-local contracts and adapter
-enterprise policy service or equivalent.
+protocols. A live flex-auth service can improve enterprise deployment, central
+policy administration, and durable audit, but it is not a prerequisite for the
+document function layer or local agent context packages.
+
+`MKTT-WP-0012` and `MKTT-WP-0008` are the remaining Markitect workplans. Their
+policy posture should be:
+
+- use `AccessPolicyGateway`, `PolicySubject`, `PolicyObject`, and
+  `PolicyDecision` as local contracts
+- support local label policy and deterministic test fixtures first
+- treat flex-auth, OpenFGA, OPA, Cedar, Keycloak, Entra, and other external
+  systems as optional adapters
+- never make external IAM or authorization services required for core Markdown
+  parsing, deterministic functions, workflows, cache queries, or context
+  package lifecycle
 
 ## State Hub Mirror
 

workplans/MKTT-WP-0008-agent-working-memory-context-cache.md

@@ -25,6 +25,25 @@ Create activatable context packages that let agents drop, reactivate, and
 reuse project knowledge efficiently while preserving provenance and policy
 metadata.
 
+## Architectural Boundary
+
+This workplan depends only on Markitect-local backend and policy contracts:
+
+- `ContextPackageRegistry`
+- `LocalSnapshotStore` and query/search result envelopes
+- `AccessPolicyGateway`
+- `PolicySubject`, `PolicyObject`, and `PolicyDecision`
+- local label policy and deterministic enterprise-policy fixtures
+
+It must not require flex-auth, NetKingdom SSO, Keycloak, Entra, OpenFGA, OPA,
+Cedar, or any other live service. Those systems may attach later through
+optional policy adapters. The local implementation should remain useful for
+single-user and team-local agent memory.
+
+For enterprise deployments, a context package may store optional external
+policy references such as policy version, decision id, resource id, issuer, or
+freshness metadata. These references are metadata, not hard dependencies.
+
 ## P8.1 - Define context package schema
 
 ```task
@@ -37,6 +56,18 @@ state_hub_task_id: "21ee9c37-4add-4886-bd03-a7bb4b20e957"
 Represent source spans, summaries, token estimates, freshness, provenance,
 policy labels, and retrieval recipes.
 
+The schema should include optional policy metadata:
+
+- policy labels and trust zones
+- subject or namespace that created the package
+- policy decision ids where available
+- policy version or local policy id
+- external resource ids where available
+- refresh and reauthorization requirements
+
+These fields must support local policy gateways first and external policy
+services only through optional adapters.
+
 ## P8.2 - Implement package creation from queries
 
 ```task
@@ -49,6 +80,10 @@ state_hub_task_id: "4df06b93-13ce-41fb-a8c3-f04d4ad9d752"
 Create context packages from simple selectors, cached search results, or
 manifest files.
 
+Package creation should use current query/search APIs and policy-aware result
+filtering. It should not call flex-auth directly; future flex-auth-backed
+filtering can be injected through the existing policy gateway boundary.
+
 ## P8.3 - Implement activation lifecycle
 
 ```task
@@ -60,6 +95,10 @@ state_hub_task_id: "9f3d9792-d655-482d-bae0-262df5fc0136"
 
 Support activate, deactivate, refresh, and explain operations for a package.
 
+Activation should re-check local policy metadata when a policy gateway is
+available. In the absence of an external service, activation remains fully
+local and explainable.
+
 ## P8.4 - Add memory namespaces
 
 ```task
@@ -72,6 +111,10 @@ state_hub_task_id: "2d090494-0e10-44cd-8e2d-c418d7530b27"
 Support project, user, agent, thread, and task namespaces without hard-coding
 any external agent platform.
 
+Namespace design should leave room for enterprise subject ids and external
+resource ids, but must not require any particular SSO, IAM, or authorization
+provider.
+
 ## P8.5 - Add summary layers
 
 ```task
@@ -84,6 +127,9 @@ state_hub_task_id: "4d1cf970-3d6d-4bd5-8da9-ec2399aa7efe"
 Support deterministic summaries first, then optional LLM-generated summaries
 through an injected adapter.
 
+Assisted summaries must be optional and policy/capability-gated before any
+prompt assembly happens.
+
 ## P8.6 - Add CLI commands
 
 ```task
@@ -102,8 +148,16 @@ mkt context explain <package-id>
 mkt context refresh <package-id>
 ```
 
+CLI commands should work against local packages without flex-auth. Optional
+policy flags may accept local policy files or later external adapter
+configuration.
+
 ## Exit Criteria
 
 - Agents can reactivate project context by stable id.
 - Context packages show included sources and token budgets.
 - Memory writes remain explicit and inspectable.
+- Local policy metadata and explanations are preserved without external
+  services.
+- flex-auth or other enterprise policy services remain optional adapter paths,
+  not prerequisites.

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
+The deterministic workflow layer, processor/reference stack, local backend, and
-to show real author pressure. Treat it as a future extension track that can
+internal extension framework are now in place. This workplan can be picked up
-unify processor ergonomics, workflow steps, contract-aware generation, and
+without waiting for flex-auth or any other external authorization service.
-render/export adapters.
+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`.
+1. Use practical workflow examples to identify recurring author-facing step
-2. Use practical workflow examples to identify recurring author-facing step
    patterns.
-3. Define the function model as a thin authoring surface over those primitives.
+2. Define the function model as a thin authoring surface over existing
-4. Add assisted and unsafe functions only after capability/policy metadata is
+   processors, references, templates, contracts, workflows, and extension
-   enforced.
+   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.