docs: reflect Cedar shipped alongside Rego as a peer backend

AGENTS.md

@@ -1,6 +1,6 @@
 # Zift
 
-Static analysis tool that scans codebases for embedded authorization logic and generates Policy as Code (PaC). Rego/OPA today; architecture is designed to grow into other policy languages (e.g. Cedar) over time.
+Static analysis tool that scans codebases for embedded authorization logic and generates Policy as Code (PaC). Generates Rego for OPA and Cedar for AWS Verified Permissions, Arbiter, and other Cedar-compatible engines; the backend layer is pluggable for additional policy languages.
 
 > This file is the canonical instructions document for AI coding agents working on Zift. `CLAUDE.md` is a symlink to this file so Claude Code picks it up automatically; other agents (Codex, Aider, Cursor, etc.) should read `AGENTS.md` directly.
 
@@ -34,8 +34,9 @@ cargo clippy --all-features -- -D warnings
 
 - **CLI** (`src/cli.rs`): Subcommands — `scan`, `extract`, `report`, `rules`, `init`
 - **Scanner** (`src/scanner/`): Tree-sitter AST parsing and pattern matching across languages
-- **Rules** (`rules/`): TOML-based pattern definitions with tree-sitter queries and policy templates (Rego today)
-- **Rego** (`src/rego/`): Policy-as-Code generation from scan findings (Rego/OPA today; additional engines like Cedar planned)
+- **Rules** (`rules/`): TOML-based pattern definitions with tree-sitter queries and per-engine policy templates (`rego_template`, `cedar_template`)
+- **Rego** (`src/rego/`): Rego/OPA policy generation, grouping, and validation (via `regorus`)
+- **Cedar** (`src/cedar/`): Cedar policy generation, grouping, and validation (via `cedar-policy`) for AWS Verified Permissions, Arbiter, and other Cedar-compatible engines
 - **Output** (`src/output/`): Formatters (JSON, text)
 
 ### Design principles

Cargo.toml

@@ -3,7 +3,7 @@ name = "zift"
 version = "0.2.2"
 edition = "2024"
 rust-version = "1.91"
-description = "Scan codebases for embedded authorization logic and generate Policy as Code (Rego/OPA today)"
+description = "Scan codebases for embedded authorization logic and generate Policy as Code (Rego for OPA, Cedar for AWS Verified Permissions and other Cedar-compatible engines)"
 license = "Apache-2.0"
 repository = "https://github.com/EnforceAuth/zift"
 homepage = "https://github.com/EnforceAuth/zift"

README.md

@@ -4,22 +4,22 @@
 [![License: Apache-2.0](https://img.shields.io/badge/License-Apache_2.0-blue.svg)](LICENSE)
 [![Rust](https://img.shields.io/badge/rust-1.91%2B-orange.svg)](https://www.rust-lang.org/)
 
-Sift through your codebase for embedded authorization logic. Extract it into Policy as Code (PaC) — [Rego](https://www.openpolicyagent.org/docs/latest/policy-language/) for [OPA](https://www.openpolicyagent.org/) today, with other engines (e.g. Cedar) on the roadmap.
+Sift through your codebase for embedded authorization logic. Extract it into Policy as Code (PaC) — [Rego](https://www.openpolicyagent.org/docs/latest/policy-language/) for [OPA](https://www.openpolicyagent.org/), or [Cedar](https://www.cedarpolicy.com/) for [AWS Verified Permissions](https://aws.amazon.com/verified-permissions/), Arbiter, and other Cedar-compatible engines.
 
 > **Status:** v0.2 — structural scanning ready for TypeScript, JavaScript, Java, Python, Go, and C#. `--deep` (LLM-assisted) mode functional via any OpenAI-compatible endpoint or MCP-capable agent host.
 
 ## What is zift?
 
 Most applications embed authorization decisions directly in application code: role checks in `if` statements, permission guards in middleware, business rules that act as access control. This scattered auth logic is hard to audit, hard to test, and impossible to enforce consistently.
 
-**zift** scans your codebase, finds these embedded authorization patterns, and helps you externalize them into Policy as Code (PaC) — Rego policies for OPA today — that a policy engine can enforce centrally.
+**zift** scans your codebase, finds these embedded authorization patterns, and helps you externalize them into Policy as Code (PaC) — Rego for OPA, or Cedar for AWS Verified Permissions, Arbiter, and other Cedar-compatible engines — that a policy engine can enforce centrally.
 
 ## How it works
 
 ```bash
 zift .                          # structural scan of current directory (fast, free)
 zift scan ./src --deep ...      # also run LLM-assisted semantic analysis
-zift extract ./findings.json    # generate Policy-as-Code from scan findings (Rego today)
+zift extract ./findings.json    # generate Policy-as-Code from scan findings (Rego or Cedar via --engine)
 zift report .                   # detailed findings report
 ```
 
@@ -176,7 +176,7 @@ If you already use an agent host — Claude Code, Cursor, Continue, Cline, Zed,
 zift mcp --scan-root .
 ```
 
-Your agent host calls Zift's tools; *its* model produces the analysis. Zift never hosts an LLM client this way — you keep your existing model relationship and Zift contributes the authz expertise (rule library, prompt, Rego validation today).
+Your agent host calls Zift's tools; *its* model produces the analysis. Zift never hosts an LLM client this way — you keep your existing model relationship and Zift contributes the authz expertise (rule library, prompt, policy generation and validation for Rego and Cedar).
 
 ### Tools exposed
 
@@ -186,8 +186,9 @@ Your agent host calls Zift's tools; *its* model produces the analysis. Zift neve
 | `get_finding_context` | Expand a finding's surrounding code window |
 | `list_rules` | Enumerate the rule library (filter by language / category) |
 | `get_rule` | Fetch a rule's full definition (tree-sitter query, predicates, Rego template) |
-| `suggest_rego` | Render a Rego stub for a finding (template-driven or category default) |
-| `validate_rego` | Parse a Rego policy with the embedded `regorus` engine |
+| `suggest_policy` | Render a policy stub for a finding in the requested engine (`rego` or `cedar`, default `rego`); template-driven or category default |
+| `validate_policy` | Parse a policy with the embedded engine — `regorus` for Rego, `cedar-policy` for Cedar |
+| `suggest_rego` / `validate_rego` | Rego-pinned aliases of `suggest_policy` / `validate_policy`, kept for backward compatibility |
 | `analyze_snippet` | Render the deep-scan prompt + JSON Schema *without* calling any model — the agent host's model produces the response |
 
 ### Resources exposed
@@ -226,7 +227,7 @@ echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":
 ```
 
 You should see a single line back with `serverInfo.name == "zift"` and capability flags for tools/resources.
-Then call `tools/list` to see the seven tool descriptors.
+Then call `tools/list` to see the tool descriptors.
 
 ## Contributing
 

docs/CEDAR_SUPPORT.md

@@ -1,7 +1,6 @@
 # Cedar Support — Design Memo
 
-**Status:** Draft — exploring for v0.3
-**Author:** seeded from a scoping investigation; refine before committing to a milestone
+**Status:** Historical — Cedar shipped in v0.2 as a peer backend to Rego. `src/cedar/` mirrors `src/rego/` (generator, grouping, templates, validator via `cedar-policy`); `extract --engine cedar` and the engine-agnostic MCP tools (`suggest_policy`, `validate_policy`) are live. This memo is preserved as the scoping document that informed the implementation — most of the "today" framing below was accurate at the time of writing and is now superseded by the shipped code.
 **Companion issue:** [#27 — Cedar support / pluggable policy backends](https://github.com/EnforceAuth/zift/issues/27)
 
 ## TL;DR

docs/DESIGN.md

@@ -2,15 +2,15 @@
 
 ## Vision
 
-**zift** is an open-source CLI tool that scans application codebases for embedded authorization logic and helps developers externalize it into **Policy as Code (PaC)**. Today it generates [Rego](https://www.openpolicyagent.org/docs/latest/policy-language/) policies for [OPA](https://www.openpolicyagent.org/); the architecture is designed to grow into other policy languages (e.g. [Cedar](https://www.cedarpolicy.com/)) over time.
+**zift** is an open-source CLI tool that scans application codebases for embedded authorization logic and helps developers externalize it into **Policy as Code (PaC)**. It generates [Rego](https://www.openpolicyagent.org/docs/latest/policy-language/) policies for [OPA](https://www.openpolicyagent.org/) and [Cedar](https://www.cedarpolicy.com/) policies for [AWS Verified Permissions](https://aws.amazon.com/verified-permissions/), Arbiter, and other Cedar-compatible engines; the backend layer is pluggable for additional policy languages.
 
 Most applications scatter authorization decisions across application code: role checks in conditionals, permission guards in middleware, business rules that implicitly act as access control. This pattern is hard to audit, hard to test, and impossible to enforce consistently across services. zift finds these patterns and provides a path to centralized policy enforcement.
 
 ## Goals
 
 1. **Detect** embedded authorization patterns across multiple languages and frameworks
 2. **Classify** findings by type (RBAC, ABAC, middleware guards, business-rule auth, custom schemes)
-3. **Generate** equivalent Policy-as-Code stubs from detected patterns (Rego today; pluggable for other engines)
+3. **Generate** equivalent Policy-as-Code stubs from detected patterns (Rego and Cedar today; pluggable for additional engines)
 4. **Report** findings in human-readable and machine-consumable formats
 5. **Integrate** into CI pipelines as a policy-drift detector
 
@@ -84,7 +84,7 @@ Each pattern rule specifies:
 - Confidence level (high / medium / low)
 - Category (RBAC, ABAC, middleware, business-rule, custom)
 - Description (human-readable explanation)
-- Rego template (stub for generation)
+- Per-engine policy templates (`rego_template`, optional `cedar_template`)
 
 Example rule (conceptual):
 
@@ -173,7 +173,7 @@ enum Confidence {
 
 ### Policy-as-Code generation
 
-For each finding (or group of related findings), zift generates a policy stub. The current backend emits Rego; the engine layer (`src/rego/`) is structured so additional targets (e.g. Cedar) can plug in alongside it:
+For each finding (or group of related findings), zift generates a policy stub. The engine layer ships two backends — `src/rego/` (Rego for OPA, validated with `regorus`) and `src/cedar/` (Cedar for AWS Verified Permissions, Arbiter, and other Cedar-compatible engines, validated with `cedar-policy`) — selected via `extract --engine <rego|cedar>`. The layer is structured so additional targets can plug in alongside them:
 
 ```rego
 # Generated by zift from src/api/orders.rs:47
@@ -269,8 +269,11 @@ DEEP SCAN OPTIONS:
 
 EXTRACT OPTIONS:
     --input, -i         Findings file (default: stdin or last scan)
-    --output-dir        Directory for generated policy files (Rego today)
-    --package-prefix    Rego package prefix (default: app)
+    --output-dir        Directory for generated policy files
+    --engine            Policy engine to generate (rego|cedar, default: rego)
+    --policy-prefix     Policy prefix: Rego package (e.g. app.authz) or Cedar
+                        filename/directory prefix (default: app)
+                        [alias: --package-prefix for backward compatibility]
     --min-confidence    Skip findings below this confidence
 
 REPORT OPTIONS:
@@ -409,7 +412,7 @@ Apache-2.0 — permissive, enterprise-friendly, compatible with OPA's and Cedar'
 - `zift rules test` validates contributed rules
 
 ### Relationship to EnforceAuth
-zift is a standalone diagnostic tool. It tells you where your authorization logic lives. EnforceAuth is the platform that helps you centralize and enforce it. zift generates Policy-as-Code stubs (Rego today, additional engines on the roadmap); EnforceAuth manages the full policy lifecycle.
+zift is a standalone diagnostic tool. It tells you where your authorization logic lives. EnforceAuth is the platform that helps you centralize and enforce it. zift generates Policy-as-Code stubs (Rego for OPA, Cedar for AWS Verified Permissions and other Cedar-compatible engines); EnforceAuth manages the full policy lifecycle.
 
 The funnel: **scan → discover → extract → enforce**