Files
flex-auth/workplans/FLEX-WP-0003-markitect-consumer-integration.md

151 lines
3.3 KiB
Markdown

---
id: FLEX-WP-0003
type: workplan
title: "Markitect Consumer Integration"
domain: netkingdom
status: todo
owner: flex-auth
topic_slug: flex-auth
planning_priority: P1
planning_order: 30
depends_on_workplans:
- FLEX-WP-0002
related_workplans:
- MKTT-WP-0014
created: "2026-05-04"
updated: "2026-05-04"
state_hub_workstream_id: "c0a6c9f6-bb6b-416d-b537-f30504c63d75"
---
# FLEX-WP-0003: Markitect Consumer Integration
## Purpose
Make Markitect the first concrete protected-system consumer of flex-auth.
Markitect already has a local enterprise integration boundary in
`MKTT-WP-0014`: identity claim normalization fixtures, policy-subject mapping,
resource manifests, local decision-log sink, workflow declarations, and CLI
inspection. This flex-auth workplan implements the service-side contract that
Markitect can call.
## P3.1 - Define Markitect resource namespace
```task
id: FLEX-WP-0003-T001
status: todo
priority: high
state_hub_task_id: "53f2fa67-780b-4e40-bbda-e669e4cecc32"
```
Define resource types and hierarchy for Markitect:
```text
knowledge_base
-> repository
-> document/path
-> section/span
-> context_package
-> workflow_artifact/export
```
Output: namespace docs, schema examples, and compatibility notes for
Markitect frontmatter and backend metadata.
## P3.2 - Import Markitect resource manifests
```task
id: FLEX-WP-0003-T002
status: todo
priority: high
state_hub_task_id: "90082eaf-37f5-492f-a884-ff8eec0eccaa"
```
Accept the Markitect-side `FlexAuthResourceManifest` shape and import it into
the flex-auth registry.
Output: importer, validation diagnostics, example fixtures, and tests.
## P3.3 - Define Markitect action vocabulary
```task
id: FLEX-WP-0003-T003
status: todo
priority: high
state_hub_task_id: "cfc78bbb-5425-4780-a860-9109df62ea37"
```
Define actions:
- `read`
- `query`
- `search`
- `package`
- `activate_context`
- `export`
- `workflow_run`
- `admin`
Map these actions to Markitect policy-gateway decisions.
## P3.4 - Implement Markitect check fixtures
```task
id: FLEX-WP-0003-T004
status: todo
priority: high
state_hub_task_id: "1d5de3b2-c581-4ca3-9107-93211eb02c6b"
```
Create fixtures that mirror Markitect examples:
- public document allow
- internal document deny
- internal document allow for reader group
- restricted export requires steward role and MFA
- context package activation includes policy version and freshness metadata
## P3.5 - Add Markitect adapter contract tests
```task
id: FLEX-WP-0003-T005
status: todo
priority: medium
state_hub_task_id: "f9297b0d-69dc-495c-a650-ca671f2c59c7"
```
Add tests that produce flex-auth decisions in the shape Markitect expects:
- `allow`
- `deny`
- `redact`
- `audit_denied`
- reason and rule id
- policy version
- resource metadata
- obligations/diagnostics
## P3.6 - Document integration flow
```task
id: FLEX-WP-0003-T006
status: todo
priority: medium
state_hub_task_id: "e34b0303-4416-40a3-8b34-e0e80d644aea"
```
Document how Markitect should:
1. Publish resources.
2. Submit check or batch_check requests.
3. Enforce allow/deny/redact.
4. Record decision ids.
5. Explain decisions back to users.
## Exit Criteria
- flex-auth can ingest Markitect resource manifests.
- flex-auth can return Markitect-compatible decisions.
- Markitect examples can be represented in flex-auth fixtures.
- Integration remains generic enough for other protected systems.