Workplan updates

This commit is contained in:
2026-05-04 19:12:20 +02:00
parent 189b436b27
commit 19c3d3e5ce
3 changed files with 109 additions and 14 deletions

View File

@@ -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.