generated from coulomb/repo-seed
172 lines
4.4 KiB
Markdown
172 lines
4.4 KiB
Markdown
---
|
|
id: FLEX-WP-0003
|
|
type: workplan
|
|
title: "Markitect Consumer Integration"
|
|
domain: netkingdom
|
|
status: completed
|
|
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-17"
|
|
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.
|
|
|
|
This workplan is also the first concrete CARING benchmark for flex-auth.
|
|
Markitect resource/action fixtures should prove that a protected system can
|
|
map local resource semantics into CARING access descriptors without making
|
|
Markitect-specific assumptions part of the generic core.
|
|
|
|
## P3.1 - Define Markitect resource namespace
|
|
|
|
```task
|
|
id: FLEX-WP-0003-T001
|
|
status: done
|
|
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. The namespace docs must map
|
|
each resource level to CARING scope and plane values.
|
|
|
|
## P3.2 - Import Markitect resource manifests
|
|
|
|
```task
|
|
id: FLEX-WP-0003-T002
|
|
status: done
|
|
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.
|
|
Diagnostics should include missing or ambiguous CARING classification when a
|
|
manifest cannot be mapped cleanly enough for conformance checks.
|
|
|
|
## P3.3 - Define Markitect action vocabulary
|
|
|
|
```task
|
|
id: FLEX-WP-0003-T003
|
|
status: done
|
|
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.
|
|
Also map each action to CARING capabilities and exposure modes, keeping
|
|
`view`/`read` separate from `export`, and keeping plaintext, masked, and
|
|
metadata-only exposure explicit.
|
|
|
|
## P3.4 - Implement Markitect check fixtures
|
|
|
|
```task
|
|
id: FLEX-WP-0003-T004
|
|
status: done
|
|
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
|
|
|
|
Each fixture should include the expected CARING descriptor, conformance
|
|
finding set, and exposure/audit behavior.
|
|
|
|
## P3.5 - Add Markitect adapter contract tests
|
|
|
|
```task
|
|
id: FLEX-WP-0003-T005
|
|
status: done
|
|
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
|
|
- CARING descriptor and conformance findings
|
|
|
|
## P3.6 - Document integration flow
|
|
|
|
```task
|
|
id: FLEX-WP-0003-T006
|
|
status: done
|
|
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.
|
|
|
|
The documented flow should explain how Markitect local roles, groups,
|
|
frontmatter, and workflow states map into CARING dimensions before they
|
|
become flex-auth decisions.
|
|
|
|
## 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.
|
|
- Markitect local semantics can be represented as CARING descriptors and
|
|
conformance findings without custom core concepts.
|