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

id, type, title, domain, status, owner, topic_slug, planning_priority, planning_order, depends_on_workplans, related_workplans, created, updated, state_hub_workstream_id

id	type	title	domain	status	owner	topic_slug	planning_priority	planning_order	depends_on_workplans	related_workplans	created	updated	state_hub_workstream_id
FLEX-WP-0003	workplan	Markitect Consumer Integration	netkingdom	todo	flex-auth	flex-auth	P1	30	FLEX-WP-0002	MKTT-WP-0014	2026-05-04	2026-05-17	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

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:

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

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

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

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

Each fixture should include the expected CARING descriptor, conformance finding set, and exposure/audit behavior.

P3.5 - Add Markitect adapter contract tests

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
• CARING descriptor and conformance findings

P3.6 - Document integration flow

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.

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.