Land foundations: assessment, ADR-001/002/003, FLEX-WP-0005, Go skeleton

Pre-implementation assessment and boundary review
(docs/pre-implementation-assessment.md) lead to three ADRs:
- ADR-001 Go + repo skeleton
- ADR-002 Rego-in-Markdown policy package format
- ADR-003 Topaz-aligned MVP (Topaz spike moves into foundations)

New workplan FLEX-WP-0005 (Foundations and Topaz Alignment) is inserted
between WP-0001 (done) and WP-0002 (core). WP-0002 pins Rego-in-Markdown
for P2.3; WP-0004 P4.1 refocused from Topaz evaluation to Topaz adapter.

Go skeleton at repo root: cmd/flex-auth + internal/{registry,policy,
decision,audit,adapters} + pkg/api + Makefile + .golangci.yml + GitHub
Actions CI. make ci green locally; bin/flex-auth --version works.

INTENT/SCOPE cite the NetKingdom IAM Profile and add the ops-warden /
ops-bridge disjoint-surface clarifications.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

workplans/FLEX-WP-0002-standalone-policy-as-code-core.md

@@ -10,8 +10,9 @@ planning_priority: P0
 planning_order: 20
 depends_on_workplans:
   - FLEX-WP-0001
+  - FLEX-WP-0005
 created: "2026-05-04"
-updated: "2026-05-04"
+updated: "2026-05-15"
 state_hub_workstream_id: "aa60e183-9a87-4e03-99b0-15786bfa11ae"
 ---
 
@@ -28,6 +29,15 @@ This is the first implementation workplan. It should produce a useful local
 authorization system before delegating to Topaz, OpenFGA, OPA, or other
 external policy engines.
 
+> **Sequencing note (2026-05-15).** This workplan now depends on
+> `FLEX-WP-0005 Foundations and Topaz Alignment`. The foundations workplan
+> records the three ADRs that pin language (Go, ADR-001), policy package
+> format (Rego-in-Markdown, ADR-002), and evaluator alignment
+> (Topaz-shaped from day one, ADR-003), lands the Go skeleton, pins the
+> `FlexAuthResourceManifest` schema with Markitect, and produces the
+> Topaz mapping spike. Tasks below have been updated to consume those
+> outputs rather than re-decide them.
+
 ## Design Direction
 
 The core should define flex-auth's own stable vocabulary:
@@ -58,16 +68,22 @@ state_hub_task_id: "534e5251-8529-48fe-8cf8-b3b6bc4ec1f4"
 Define machine-readable schemas for:
 
 - protected system manifest
-- resource manifest
-- subject/group/team manifest
-- relationship fact manifest
-- policy package
+- resource manifest (consumes `FlexAuthResourceManifest` pinned in
+  `FLEX-WP-0005 T03`)
+- subject/group/team manifest (vocabulary aligned with the Topaz
+  mapping produced in `FLEX-WP-0005 T04`)
+- relationship fact manifest (same alignment note)
+- policy package (Rego-in-Markdown envelope per ADR-002 — frontmatter
+  schema, fenced `rego` / `rego test` / `yaml fixture` blocks)
 - policy fixture/test case
 - check request
-- decision envelope
+- decision envelope (provenance fields identical for local and
+  delegated evaluation per ADR-003)
 - audit event
 
-Output: docs, examples, schema files, and validation tests.
+Output: docs, JSON Schema files in `schemas/`, runnable examples in
+`examples/`, and validation tests in `internal/policy/` and
+`internal/registry/`.
 
 ## P2.2 - Implement local registry store
 
@@ -96,8 +112,22 @@ state_hub_task_id: "09be0f25-e5ba-42b5-8b2f-36fd0ef2fe6b"
 Load policy-as-code packages with metadata, rules, fixtures, tests, and
 activation metadata.
 
-The first implementation may use a simple declarative rule format as long as
-the package boundary leaves room for OPA/Rego, Cedar, and Topaz later.
+Per ADR-002, packages are Markdown documents with YAML frontmatter,
+prose intent sections, fenced `rego` rule blocks, fenced `rego test`
+blocks, and fenced `yaml fixture` blocks. The loader extracts and
+concatenates the Rego blocks into one OPA module per package, runs
+`opa parse` and `opa test`, and evaluates each declared fixture against
+the module before marking the package `valid`.
+
+The evaluator embeds the OPA Rego library directly
+(`github.com/open-policy-agent/opa/rego`) so the same module that
+flex-auth evaluates locally can be served unchanged to a delegated
+Topaz/OPA backend in FLEX-WP-0004.
+
+Output: a Markdown-to-Rego extractor, a package validator with useful
+diagnostics for malformed frontmatter / unparseable rules / failing
+tests / failing fixtures, and golden tests on at least three real
+package examples (one allow, one deny, one redact-with-obligation).
 
 ## P2.4 - Implement deterministic check and batch_check APIs
 

workplans/FLEX-WP-0004-delegated-pdp-and-directory-adapters.md

@@ -13,7 +13,7 @@ depends_on_workplans:
 related_workplans:
   - FLEX-WP-0003
 created: "2026-05-04"
-updated: "2026-05-04"
+updated: "2026-05-15"
 state_hub_workstream_id: "99a82976-d376-42b0-89cc-c44e01c0bec6"
 ---
 
@@ -28,7 +28,14 @@ The standalone core must work first. This workplan adds delegated backends and
 provider examples after flex-auth's own request, decision, registry, and audit
 vocabulary are stable.
 
-## P4.1 - Evaluate Topaz as MVP delegated backend
+> **Scope change (2026-05-15).** Per ADR-003 and the pre-implementation
+> assessment, the Topaz *evaluation* moved to `FLEX-WP-0005 T04` so its
+> output can shape the standalone core. This workplan now implements the
+> Topaz *adapter* against that mapping; the standalone evaluator already
+> speaks Rego, so adapter work focuses on directory delegation, wire
+> protocol, and consistency metadata rather than re-deciding fit.
+
+## P4.1 - Implement Topaz adapter
 
 ```task
 id: FLEX-WP-0004-T001
@@ -37,10 +44,28 @@ priority: high
 state_hub_task_id: "9046418c-2b78-42c6-8bfa-76d6ed0050dd"
 ```
 
-Evaluate Topaz because it combines a local directory, relation modeling, and
-OPA/Rego policy evaluation.
+Implement the Topaz adapter behind flex-auth's stable PDP and directory
+contracts. Consumes `docs/topaz-mapping-spike.md` produced in
+`FLEX-WP-0005 T04`.
 
-Output: spike notes, mapping examples, pros/cons, and recommendation.
+Scope:
+
+- Wire-protocol selection (gRPC vs HTTP vs embedded library) with
+  rationale recorded.
+- Directory delegation: flex-auth registry writes flow into Topaz
+  directory objects/relations; reads can be served from either side
+  with documented consistency semantics.
+- Policy delegation: a flex-auth package (Rego-in-Markdown) is
+  decomposed and pushed to Topaz unchanged; decisions returned carry
+  the same envelope shape as standalone evaluation.
+- Failure modes: Topaz unavailable, stale directory, partial result —
+  each produces a decision envelope that the standalone code path
+  could also have produced.
+
+Output: adapter package under `internal/adapters/topaz/`, end-to-end
+integration test using the `examples/topaz/` docker-compose from the
+spike, and an operations note covering startup, health checks, and
+fail-closed defaults.
 
 ## P4.2 - Add relationship PDP adapter boundary
 

workplans/FLEX-WP-0005-foundations-and-topaz-alignment.md

@@ -67,7 +67,7 @@ decisions.
 
 ```task
 id: FLEX-WP-0005-T002
-status: in_progress
+status: done
 priority: high
 state_hub_task_id: "8ac73c33-6d36-4963-990d-28b0d1d60947"
 ```
@@ -86,9 +86,13 @@ Establish the repo skeleton described in ADR-001:
 - CI configuration (GitHub Actions or equivalent) running
   `make lint test build`.
 
-Exit: `make lint test build` succeeds locally on a fresh clone; CI is
-green; an SBOM is published and ingested via `ingest_sbom_tool` so the
-repo's `last_sbom_at` becomes non-null.
+Exit: `make ci` (vet + lint + test + build) succeeds locally on a fresh
+clone; GitHub Actions CI is green. SBOM generation works via
+`make sbom` (cyclonedx-gomod), but `ingest_sbom_tool` requires a
+non-empty dependency source — that step is deferred to the first task
+that adds an external dependency (`FLEX-WP-0002 P2.3`, which pulls in
+the OPA Rego library), where it lands as part of the dep-introduction
+checklist.
 
 ## P5.3 - Pin FlexAuthResourceManifest schema