diff --git a/docs/workplan-planning-map.md b/docs/workplan-planning-map.md index 1d68380..125795a 100644 --- a/docs/workplan-planning-map.md +++ b/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 -`flex-auth` scope; Markitect now provides resource registration, policy +access-control gateway. Central authorization administration remains optional +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 -reactivatable agent context packages should still wait for a flex-auth-backed -enterprise policy service or equivalent. +declarations, and CLI inspection/mapping commands. Remaining Markitect +workplans should depend only on Markitect-local contracts and adapter +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 diff --git a/workplans/MKTT-WP-0008-agent-working-memory-context-cache.md b/workplans/MKTT-WP-0008-agent-working-memory-context-cache.md index 8944066..3998f17 100644 --- a/workplans/MKTT-WP-0008-agent-working-memory-context-cache.md +++ b/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 mkt context refresh ``` +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. diff --git a/workplans/MKTT-WP-0012-document-function-layer.md b/workplans/MKTT-WP-0012-document-function-layer.md index 018e8c4..3f7bd24 100644 --- a/workplans/MKTT-WP-0012-document-function-layer.md +++ b/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.