Feat: AIAC OPA plugin integration + live enforcement (phase 2, PR 1)

aiac/CLAUDE.md

@@ -1,6 +1,6 @@
 # AIAC Codebase Guide
 
-All paths below are relative to `kagenti-extensions/aiac/`.
+All paths below are relative to `cortex/aiac/`.
 
 ## Requirements / PRD docs
 
@@ -50,23 +50,18 @@ Per-task handoff documents live under `docs/handoffs/` — one markdown file per
 
 ## Source code
 
-`src/aiac/` — Python package root (`__init__.py` is empty).
+`src/aiac/` — Python package root (`__init__.py` is empty). It is organized by
+subsystem: an IdP configuration layer, a PDP policy-writer layer, the AIAC Agent
+layer (built on the SPM/APM model — a Controller dispatching to use-case
+sub-agents and a policy-rules builder), and a two-layer policy stack (models, a
+model store, and the Policy Computation Engine).
 
-Key stable structure:
-- `idp/` — IdP configuration service and models
-- `pdp/` — PDP policy writer service and library
-- `agent/` — the AIAC Agent layer (rebuilt on the SPM/APM model):
-  - `agent/controller/` — FastAPI Controller (`routes.py` + Dockerfile); `/apply/*` routes dispatch to the UC sub-agents and make the single `compute_and_apply` (PCE) call
-  - `agent/uc/` — use-case sub-agents: `onboarding/` (provision + policy_builder + orchestrator), `policy_update/` (build/rebuild), `role_update/`
-  - `agent/policy_rules_builder/` — PRB: `build_role_rules` / `build_scope_rules` emit `list[PolicyRule]`
-  - `agent/shared/` — shared helpers (`roles.py`, e.g. `flatten_role`)
-  - `agent/onboarding.old/` — archived prior implementation (built on the superseded `ProposedDiff` model); not part of the active build
-- `policy/` — the two-layer policy stack (all implemented):
-  - `policy/model/` — `PolicyRule`, `ServicePolicyModel` (SPM), `AgentPolicyModel` (APM), `PolicyModel`
-  - `policy/store/` — Policy Store service + library (SPM CRUD)
-  - `policy/computation/` — Policy Computation Engine (`compute_and_apply`, SPM-based)
+Discover the concrete layout live rather than relying on a memorized tree:
 
-For current file list, `ls` or `find` under `src/aiac/`.
+```bash
+find src/aiac -maxdepth 2 -type d      # subsystems and their immediate children
+ls src/aiac/<subsystem>/               # drill into any layer
+```
 
 ## Tests
 
@@ -78,24 +73,32 @@ For current file list, `ls` or `find` under `src/aiac/`.
 .venv/bin/pytest test/ -m "not integration"
 ```
 
-The whole `test/` tree (including `test/policy/`) collects and runs green. The Policy
-Computation Engine (`aiac.policy.computation.engine`) was migrated to the SPM store surface in
-**Wave 3 / Handoff 05**, so the earlier PCE-chain collection failures (which required ignoring
-`test/policy/computation`, `test/agent/controller/test_routes.py`, and
-`test/integration/test_policy_pipeline.py`) are resolved — no `--ignore` flags are needed.
-
-Use `ls test/` to discover current test directories.
-
-**Integration tests** (`-m integration`) need live config — Keycloak + admin creds + an LLM
-endpoint (`opa` on PATH for the policy-pipeline suite). Those variables live in
+The whole `test/` tree collects and runs green — no `--ignore` flags are needed.
+(This wasn't always true: the Policy Computation Engine was migrated to the SPM
+store surface in Wave 3, which resolved the earlier PCE-chain collection
+failures.)
+
+Use `ls test/` / `find test -type d` to discover current test directories.
+
+**Integration tests** (`-m integration`) now close the **real OPA evaluation loop** — they onboard
+through the in-cluster Controller, then drive real HTTP requests **through AuthBridge** and assert the
+**deployed OPA plugin's** allow/deny (no `opa eval`, no `.rego` dump, so `opa` on PATH is no longer
+needed). They therefore need a live **rossoctl/Kind cluster with the AuthBridge OPA pipeline wired
+into both legs** (the demo `github-agent`/`github-tool` deployed + registered), plus Keycloak admin
+creds and an LLM endpoint for onboarding. Stand the pipeline up with `k8s/opa-kind-enable.sh`;
+the full prerequisites, wiring, and manual probe commands are in `k8s/opa-kind-runbook.md`, and the
+per-loop shape is documented in `test/integration/uc1_onboard.py`. Config lives in
 `test/integration/.env` (gitignored): `LLM_BASE_URL`, `LLM_API_KEY`, `LLM_MODEL`, `KEYCLOAK_URL`,
 `KEYCLOAK_ADMIN_USERNAME`, `KEYCLOAK_ADMIN_PASSWORD`. Source it before running:
 
 ```bash
+k8s/opa-kind-enable.sh          # one-time: wire the OPA plugin into the Kind cluster
 set -a; . test/integration/.env; set +a
 .venv/bin/pytest test/integration/ -m integration
 ```
 
+When the cluster is not wired or the env is unset, the suite **skips cleanly** (it never false-passes).
+
 **Smoke test** (requires live service at `AIAC_PDP_CONFIG_URL`, default `http://127.0.0.1:7071`):
 
 ```bash
@@ -106,26 +109,28 @@ Exercises all `Configuration` methods — run `ls test/idp/configuration/` to se
 
 ## Python environment
 
-Virtual environment: `kagenti-extensions/aiac/.venv`
+Virtual environment: `cortex/aiac/.venv`
 
-Activate: `source kagenti-extensions/aiac/.venv/bin/activate`
-Run directly: `kagenti-extensions/aiac/.venv/bin/python` / `kagenti-extensions/aiac/.venv/bin/pytest`
+Activate: `source cortex/aiac/.venv/bin/activate`
+Run directly: `cortex/aiac/.venv/bin/python` / `cortex/aiac/.venv/bin/pytest`
 
 Always use this venv for any Python execution, test runs, or dependency checks.
 
 ## Kubernetes & builds
 
 Config: `k8s/`, `pyproject.toml`, `pyrightconfig.json`
 
-Docker images:
+Docker images: each service ships a `Dockerfile` next to its service code (build
+context is `src/`, except `rag-ingest/`, which is a separate top-level
+directory). Discover the current set of images and their Dockerfiles live:
 
-| Image | Dockerfile location |
-|-------|-------------------|
-| `aiac-agent` | `src/aiac/agent/controller/Dockerfile` (build context `src/`) |
-| `aiac-pdp-config` | `src/aiac/idp/service/configuration/keycloak/Dockerfile` |
-| `aiac-pdp-policy-opa` | `src/aiac/pdp/service/policy/opa/Dockerfile` |
-| `aiac-policy-store` | `src/aiac/policy/store/service/Dockerfile` |
-| `aiac-rag-ingest` | `rag-ingest/` (separate directory) |
+```bash
+find src -name Dockerfile          # per-service Dockerfiles under src/
+ls rag-ingest/                     # the out-of-tree ingest image
+```
+
+Image names and build contexts are declared in the build/CI config and the
+`k8s/` manifests — grep there for the authoritative name→Dockerfile mapping.
 
 ### Non-root container / volume-ownership pattern
 
@@ -152,9 +157,12 @@ spec:
     fsGroup: 10001   # makes the mounted volume group-writable by UID 10001
 ```
 
-Services requiring this today:
-- **Policy store** — PVC at `/data` (SQLite backend), `policy-store-statefulset.yaml`
-- **PDP policy OPA writer** — emptyDir at `/rego` (`REGO_OUTPUT_DIR`), `pdp-interface-deployment.yaml`
+This applies to any service that writes to a mounted volume (a PVC or an
+emptyDir). Find them live by grepping the manifests for volume mounts / claims:
+
+```bash
+grep -rlniE 'volumeMounts|volumeClaimTemplates|emptyDir|persistentVolumeClaim' k8s/
+```
 
 Services that mount no volumes still need the Dockerfile `USER` directive; the
 pod-level `fsGroup`/volume-chown block above is only required for those that

aiac/demo/assets/INSTALL.md

@@ -1,16 +1,16 @@
 # Installing the demo assets (`github-tool` + `github-agent`)
 
 Single install guide for both reusable demo workloads under `demo/assets/`, deployed to a
-Kagenti/Kind cluster in namespace `team1`. Consolidates what used to be split across
+rossoctl/Kind cluster in namespace `team1`. Consolidates what used to be split across
 [`docs/specs/demo/github-tool.md`](../../docs/specs/demo/github-tool.md) §7–8 and the agent
-README's former "Deploying to Kagenti" section, so the two installation paths can't drift apart
+README's former "Deploying to Rossoctl" section, so the two installation paths can't drift apart
 again. Prefer [`install.sh`](install.sh) over doing this by hand; the steps below are what it
 automates.
 
 ## Prerequisites
 
-- A running Kagenti/Kind cluster with the kagenti-operator installed.
-- Namespace **`team1`** already exists — created by the Rossoctl/Kagenti installer, not by
+- A running rossoctl/Kind cluster with the rossoctl-operator installed.
+- Namespace **`team1`** already exists — created by the Rossoctl installer, not by
   anything in this repo. Nothing here creates cluster-owned resources.
 - `kubectl`, `kind`, and a container runtime (`docker` or `podman`) on `PATH`.
 
@@ -28,11 +28,11 @@ apply the manifests → `kubectl rollout status`.
 
 These each fail far from their cause — read before editing the manifests or install path.
 
-- **The tool `Service` must carry `protocol.kagenti.io/mcp: "true"`.** This is a *deploy-time*
-  label that the kagenti operator does **not** add. Without it, UC-1's `analyze_tool` returns
+- **The tool `Service` must carry `protocol.rossoctl.io/mcp: "true"`.** This is a *deploy-time*
+  label that the rossoctl operator does **not** add. Without it, UC-1's `analyze_tool` returns
   **502** — during onboarding, long after deployment looked fine. It is already present in the
   committed manifest; don't drop it when editing.
-- **`kagenti.io/type` is applied by the operator** from the `AgentRuntime` CR. Don't hand-set it
+- **`rossoctl.io/type` is applied by the operator** from the `AgentRuntime` CR. Don't hand-set it
   on the pod.
 - **The tool's declared `PORT` must not be `9090`.** The AuthBridge sidecar reuses the declared
   `PORT` as its own reverse-proxy listener and shifts the app's real listen port to `PORT+1`.
@@ -54,7 +54,7 @@ These each fail far from their cause — read before editing the manifests or in
   `/.well-known/agent-card.json` with no MCP server present, which is all UC-1 discovery needs.
   **Do not add `github-tool-mcp` to this install path.**
 - **Namespace `team1` is a precondition, not an output.** No manifest here creates it; the
-  Rossoctl/Kagenti installer owns it (and any labels it carries). `install.sh` fails fast with a
+  Rossoctl installer owns it (and any labels it carries). `install.sh` fails fast with a
   pointer to the installer if the namespace is missing.
 
 ## Manual steps (what `install.sh` automates)
@@ -63,7 +63,7 @@ These each fail far from their cause — read before editing the manifests or in
 ```bash
 cd tools/github_tool
 podman build -t localhost/github-tool:latest .   # or docker; the localhost/ prefix must match the manifest's image ref
-kind load docker-image localhost/github-tool:latest --name kagenti
+kind load docker-image localhost/github-tool:latest --name rossoctl
 kubectl apply -f k8s/github-tool-deployment.yaml
 kubectl rollout status deployment/github-tool -n team1
 ```
@@ -72,7 +72,7 @@ kubectl rollout status deployment/github-tool -n team1
 ```bash
 cd agents/github_agent
 podman build -t localhost/github-agent:latest .   # or docker; the localhost/ prefix must match the manifest's image ref
-kind load docker-image localhost/github-agent:latest --name kagenti
+kind load docker-image localhost/github-agent:latest --name rossoctl
 kubectl apply -f k8s/configmaps.yaml
 kubectl apply -f k8s/github-agent-deployment.yaml
 kubectl rollout status deployment/github-agent -n team1
@@ -81,18 +81,19 @@ kubectl rollout status deployment/github-agent -n team1
 ## Verifying
 
 ```bash
-# Tool got its MCP label and the operator stamped kagenti.io/type
-kubectl get svc github-tool -n team1 -o jsonpath='{.metadata.labels.protocol\.kagenti\.io/mcp}'
-kubectl get pod -l app=github-tool -n team1 -o jsonpath='{.items[0].metadata.labels.kagenti\.io/type}'
+# Tool got its MCP label and the operator stamped rossoctl.io/type
+kubectl get svc github-tool -n team1 -o jsonpath='{.metadata.labels.protocol\.rossoctl\.io/mcp}'
+kubectl get pod -l app=github-tool -n team1 -o jsonpath='{.items[0].metadata.labels.rossoctl\.io/type}'
 
 # Agent serves its card with no MCP server present
-kubectl port-forward svc/github-agent 8080:8080 -n team1 &
-curl -s http://localhost:8080/.well-known/agent-card.json | python3 -m json.tool
+# (local port 18080, not 8080 -- rossoctl's Gateway already binds host:8080 on a Kind cluster)
+kubectl port-forward svc/github-agent 18080:8080 -n team1 &
+curl -s http://localhost:18080/.well-known/agent-card.json | python3 -m json.tool
 ```
 
 ## Out of scope
 
-- Deploying `github-tool-mcp`, Keycloak, SPIRE, the kagenti operator, or the cluster itself.
+- Deploying `github-tool-mcp`, Keycloak, SPIRE, the rossoctl operator, or the cluster itself.
 - Deploying the AIAC stack (`k8s/`) — see `k8s/aiac-deployment-guide.md`.
 - Waiting for Keycloak client registration — that needs Keycloak credentials this install path
   has no business holding; it belongs to whatever use-case demo consumes the client (e.g. UC-1's

aiac/demo/assets/agents/github_agent/README.md

@@ -1,6 +1,6 @@
 # github-agent
 
-An autonomous A2A agent that acts on a user's behalf against GitHub **source repositories** and an **issue/PR tracker**, using the [`github-tool-mcp`](https://github.com/kagenti/kagenti-extensions) MCP server.
+An autonomous A2A agent that acts on a user's behalf against GitHub **source repositories** and an **issue/PR tracker**, using the [`github-tool-mcp`](https://github.com/rossoctl/cortex) MCP server.
 
 This agent implements the canonical `github-agent` used by the AIAC policy-pipeline integration test — the two skills match the policy scenario's `source_operations` and `issue_operations` roles.
 
@@ -68,7 +68,7 @@ curl -s localhost:8000/.well-known/agent-card.json | python3 -m json.tool
 
 Optionally, run `expect -f test_startup.exp` instead to check startup automatically.
 
-## Deploying to Kagenti (Kind cluster)
+## Deploying to Rossoctl (Kind cluster)
 
 See [`../../INSTALL.md`](../../INSTALL.md) — the single install guide for this agent and the
 `github_tool` stub together (build, `kind load`, manifests, invariants, verification).

aiac/demo/assets/agents/github_agent/k8s/configmaps.yaml

@@ -1,7 +1,7 @@
 # Demo-specific ConfigMap overrides for GitHub Issue Agent + AuthBridge
 #
-# The Kagenti installer already creates correct defaults for authbridge-config,
-# spiffe-helper-config, and envoy-config (with the kagenti realm). This file
+# The Rossoctl installer already creates correct defaults for authbridge-config,
+# spiffe-helper-config, and envoy-config (with the rossoctl realm). This file
 # overrides:
 # - authbridge-config: Keycloak connection, inbound validation, and outbound exchange settings
 # - authproxy-routes: per-target token exchange routes
@@ -15,7 +15,7 @@
 #
 # Note: These manifests are configured for namespace "team1" (installer-provided
 #       and enrolled for AuthBridge sidecar injection) and the installer's
-#       "kagenti" Keycloak realm (set via KEYCLOAK_REALM below).
+#       "rossoctl" Keycloak realm (set via KEYCLOAK_REALM below).
 
 ---
 # authbridge-config ConfigMap - Unified config for both client-registration and envoy-proxy
@@ -35,12 +35,12 @@ metadata:
   namespace: team1
 data:
   KEYCLOAK_URL: "http://keycloak-service.keycloak.svc:8080"
-  KEYCLOAK_REALM: "kagenti"
+  KEYCLOAK_REALM: "rossoctl"
   # TOKEN_URL: Auto-derived from KEYCLOAK_URL + KEYCLOAK_REALM. Only set explicitly
   # when the token endpoint differs from the standard Keycloak path.
-  # TOKEN_URL: "http://keycloak-service.keycloak.svc:8080/realms/kagenti/protocol/openid-connect/token"
+  # TOKEN_URL: "http://keycloak-service.keycloak.svc:8080/realms/rossoctl/protocol/openid-connect/token"
   # ISSUER: Set explicitly because the internal KEYCLOAK_URL differs from the frontend URL.
-  ISSUER: "http://keycloak.localtest.me:8080/realms/kagenti"
+  ISSUER: "http://keycloak.localtest.me:8080/realms/rossoctl"
   # Audience validation is automatic — uses CLIENT_ID from /shared/client-id.txt
   # (written by client-registration or operator). No manual configuration needed.
 

aiac/demo/assets/agents/github_agent/k8s/github-agent-deployment.yaml

@@ -1,6 +1,6 @@
 # GitHub Agent Deployment with AuthBridge
 #
-# This deployment uses the kagenti-operator webhook to automatically inject
+# This deployment uses the rossoctl-operator webhook to automatically inject
 # a single combined AuthBridge sidecar (post-kagenti-extensions#411). The exact
 # container shape depends on the resolved AuthBridge mode:
 # - proxy-sidecar (default): one container "authbridge-proxy" from the
@@ -13,7 +13,7 @@
 # exchange (HTTP), and HTTPS passthrough.
 #
 # Keycloak client registration is operator-managed (no in-pod sidecar);
-# the operator creates a kagenti-keycloak-client-credentials-<hash> Secret
+# the operator creates a rossoctl-keycloak-client-credentials-<hash> Secret
 # and the webhook mounts it at /shared/client-{id,secret}.txt.
 #
 # The agent container:
@@ -22,10 +22,10 @@
 #   - Token exchange to the tool is handled transparently by the AuthBridge sidecar
 #
 # Labels (on Pod template):
-#   kagenti.io/inject: enabled  - Enables AuthBridge sidecar injection
-#   kagenti.io/spire: enabled   - Enables SPIRE-based identity (set to "disabled" if no SPIRE)
+#   rossoctl.io/inject: enabled  - Enables AuthBridge sidecar injection
+#   rossoctl.io/spire: enabled   - Enables SPIRE-based identity (set to "disabled" if no SPIRE)
 #
-# kagenti.io/type is applied automatically by the operator when the
+# rossoctl.io/type is applied automatically by the operator when the
 # AgentRuntime CR (at the end of this file) is created.
 #
 # Prerequisites (NOT created by this file — must exist before applying):
@@ -57,7 +57,7 @@ metadata:
   namespace: team1
   labels:
     app.kubernetes.io/name: github-agent
-    protocol.kagenti.io/a2a: ""
+    protocol.rossoctl.io/a2a: ""
 spec:
   replicas: 1
   selector:
@@ -67,9 +67,9 @@ spec:
     metadata:
       labels:
         app.kubernetes.io/name: github-agent
-        kagenti.io/inject: enabled
-        kagenti.io/spire: enabled
-        protocol.kagenti.io/a2a: ""
+        rossoctl.io/inject: enabled
+        rossoctl.io/spire: enabled
+        protocol.rossoctl.io/a2a: ""
     spec:
       serviceAccountName: github-agent
       containers:
@@ -125,7 +125,7 @@ spec:
 
             # Agent service settings
             # PORT tells the agent where to listen for A2A traffic.
-            # The kagenti operator may override this via proxy-sidecar
+            # The rossoctl operator may override this via proxy-sidecar
             # port-stealing to relocate the agent to a free port.
             - name: PORT
               value: "8000"
@@ -141,7 +141,7 @@ spec:
 
             # JWKS URI for validating incoming tokens from Keycloak
             - name: JWKS_URI
-              value: "http://keycloak-service.keycloak.svc:8080/realms/kagenti/protocol/openid-connect/certs"
+              value: "http://keycloak-service.keycloak.svc:8080/realms/rossoctl/protocol/openid-connect/certs"
           resources:
             limits:
               cpu: 500m
@@ -195,11 +195,11 @@ spec:
 
 ---
 # AgentRuntime triggers operator-managed Keycloak client registration
-# (creates kagenti-keycloak-client-credentials-<hash> Secret with
+# (creates rossoctl-keycloak-client-credentials-<hash> Secret with
 # client-id.txt and client-secret.txt that the authbridge sidecar
-# mounts at /shared/). The operator also applies kagenti.io/type=agent
+# mounts at /shared/). The operator also applies rossoctl.io/type=agent
 # to the Deployment and Pod template, enabling webhook sidecar injection.
-apiVersion: agent.kagenti.dev/v1alpha1
+apiVersion: agent.rossoctl.dev/v1alpha1
 kind: AgentRuntime
 metadata:
   name: github-agent