refactor(examples): rewrite policy demo as Codex-default loop

Re-shape examples/agent-driven-policy-management/ to be a single, clean
end-to-end demonstration of the agent-driven policy loop. A Codex agent
inside an OpenShell sandbox attempts a GitHub Contents API write, hits a
structured 403 from the L7 proxy, reads the policy_advisor skill, drafts a
narrow addRule proposal via http://policy.local/v1/proposals, the host
auto-approves, the sandbox hot-reloads policy, and the agent's retry
succeeds. Whole loop runs in roughly two minutes.

Demo cleanup:

- Drop .env file ceremony. Defaults resolve from gh: owner via
  'gh api user --jq .login', repo defaults to 'openshell-policy-demo',
  token from gh auth token / GITHUB_TOKEN / GH_TOKEN. With gh auth login
  and codex login already done, 'bash demo.sh' Just Works.
- Codex-specific. Bootstraps ~/.codex/auth.json from credentials injected
  by the OpenShell provider, runs codex exec --sandbox danger-full-access
  (OpenShell is the actual security boundary; bwrap nesting cannot create
  user namespaces inside the sandbox container).
- Tighter narrative output: a single 'Preflight' step, a run summary banner
  before launch, an inline narration of what's happening inside the sandbox
  while we poll for the proposal (including the literal structured 403
  body the agent acts on), and an OCSF trace at the end filtered to the
  three events that tell the story (DENY, RELOAD, ALLOW).
- Replace Python heredoc templating with sed; uploads use the single-flag
  pattern (--upload "${PAYLOAD_DIR}:/sandbox") with files referenced at
  the basename-prefixed path that #952 / #1028 established.
- README documents the trust model honestly: structured rule is the
  contract, agent rationale is a hint, prover validation badge in
  progress per RFC 0001.

Move the deterministic no-LLM regression harness out of examples/ into
e2e/policy-advisor/ -- it was a parallel demo, not an example. Same loop
without the LLM, useful for iterating on the proxy and policy.local API.

Author: zredlined

e2e/policy-advisor/README.md

@@ -0,0 +1,29 @@
+<!-- SPDX-FileCopyrightText: Copyright (c) 2025-2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. -->
+<!-- SPDX-License-Identifier: Apache-2.0 -->
+
+# Policy Advisor end-to-end test
+
+Deterministic, no-LLM exercise of the agent-driven policy loop:
+
+1. Start a sandbox with a read-only GitHub L7 policy.
+2. From inside the sandbox, attempt a GitHub contents PUT and assert OpenShell
+   returns a structured `policy_denied` 403.
+3. Submit a narrow `addRule` proposal through `http://policy.local/v1/proposals`.
+4. Approve the draft from the host and retry until the write succeeds.
+
+This proves the proxy, the structured deny body, the `policy.local` HTTP API,
+the gateway proposal path, and the hot-reload of approved rules — without
+involving an LLM. The user-facing demo (`examples/agent-driven-policy-management/`)
+runs the same loop with Codex driving from inside the sandbox.
+
+## Run it
+
+```bash
+DEMO_GITHUB_OWNER=<your-handle> \
+DEMO_GITHUB_REPO=openshell-policy-demo \
+bash e2e/policy-advisor/test.sh
+```
+
+Requires an active OpenShell gateway (`openshell gateway start`) and a GitHub
+token with contents write on the repository (auto-resolved from `gh auth token`,
+`GITHUB_TOKEN`, or `GH_TOKEN`).

…nagement/validation/policy.template.yaml e2e/policy-advisor/policy.template.yamlexamples/agent-driven-policy-management/validation/policy.template.yaml renamed to e2e/policy-advisor/policy.template.yaml examples/agent-driven-policy-management/validation/policy.template.yaml renamed to e2e/policy-advisor/policy.template.yaml

@@ -6,9 +6,9 @@
 set -euo pipefail
 
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
-REPO_ROOT="$(cd "${SCRIPT_DIR}/../../.." && pwd)"
+REPO_ROOT="$(cd "${SCRIPT_DIR}/../.." && pwd)"
 POLICY_TEMPLATE="${SCRIPT_DIR}/policy.template.yaml"
-RUNNER_SOURCE="${SCRIPT_DIR}/runner.sh"
+RUNNER_SOURCE="${SCRIPT_DIR}/sandbox-runner.sh"
 
 if [[ -z "${OPENSHELL_BIN:-}" ]]; then
     if [[ -x "${REPO_ROOT}/target/debug/openshell" ]]; then

…n-policy-management/validation/runner.sh e2e/policy-advisor/sandbox-runner.shexamples/agent-driven-policy-management/validation/runner.sh renamed to e2e/policy-advisor/sandbox-runner.sh examples/agent-driven-policy-management/validation/runner.sh renamed to e2e/policy-advisor/sandbox-runner.sh

@@ -3,90 +3,85 @@
 
 # Agent-Driven Policy Management Demo
 
-Run the first policy-advisor MVP loop with a real agent:
+Run the full agent-driven policy loop end-to-end:
 
-1. Use the active OpenShell gateway.
-2. Create a GitHub provider from a host token.
-3. Start a sandbox with your agent command and an uploaded task file.
-4. Let the agent hit an OpenShell `policy_denied` response.
-5. Let the agent read `/etc/openshell/skills/policy_advisor.md` and submit a
-   narrow proposal through `http://policy.local/v1/proposals`.
-6. Approve the draft rule from outside the sandbox.
-7. Let the agent retry and confirm the GitHub write succeeds.
+1. A Codex agent inside an OpenShell sandbox tries to write a markdown file to
+   GitHub via the Contents API.
+2. OpenShell denies the request with a structured `policy_denied` 403 because
+   the initial policy only allows read-only access to `api.github.com`.
+3. The agent reads `/etc/openshell/skills/policy_advisor.md`, drafts the
+   narrowest rule needed, and submits it to `http://policy.local/v1/proposals`.
+4. You approve the proposal from the host with one keystroke.
+5. The sandbox hot-reloads the merged policy and the agent's retry succeeds.
 
-The shell script is agent-agnostic. It does not know how to sign in to a
-specific coding agent. Pass the provider names and sandbox command for the
-agent you want to run.
+The whole loop usually finishes in under two minutes.
 
 ## Prerequisites
 
-- An active OpenShell gateway that includes the current sandbox supervisor
-  build.
-- `curl` and `jq` on the host machine.
-- The GitHub CLI (`gh`) if you want to create the scratch repo with the command
-  below.
-- A disposable or demo-safe GitHub repository.
-- A GitHub token with contents write permission for that repository.
-- An agent provider and policy that let your chosen agent run inside the
-  sandbox.
-
-## Create A Scratch Repo
-
-Use a private scratch repository with an initial README. The README matters
-because GitHub does not create the default branch until the first commit exists.
-
-```bash
-gh repo create zredlined/openshell-policy-demo \
-  --private \
-  --add-readme \
-  --description "OpenShell policy advisor demo scratch repo"
-```
-
-The demo never creates repositories and refuses to overwrite an existing demo
-file. Each default run writes a new timestamped file under
-`openshell-policy-advisor-demo/`.
-
-## Quick Start
+- An active OpenShell gateway (`openshell gateway start`).
+- `gh auth login` (or a `GITHUB_TOKEN` env var with contents-write on a
+  scratch repo).
+- `codex login` on the host.
+- A scratch GitHub repository with at least one commit on the default branch.
+  If you don't have one yet:
 
-The included `policy.template.yaml` only defines the GitHub API target for the
-policy-management loop. Use `DEMO_POLICY_FILE` to point at a policy that also
-allows your chosen agent to reach its model/provider endpoints.
+  ```shell
+  gh repo create "$(gh api user --jq .login)/openshell-policy-demo" \
+      --private --add-readme \
+      --description "OpenShell policy advisor demo scratch repo"
+  ```
 
-```bash
-cp examples/agent-driven-policy-management/.env.example .env
-$EDITOR .env
-
-set -a
-source .env
-set +a
+## Run it
 
+```shell
 bash examples/agent-driven-policy-management/demo.sh
 ```
 
-The host script only orchestrates sandbox lifecycle and developer approval. The
-policy proposal is authored by the agent inside the sandbox from the installed
-skill, structured denial response, and `policy.local` API.
-
-The demo writes one markdown file under:
-
-```text
-openshell-policy-advisor-demo/<run-id>.md
-```
-
-Use a scratch repository or a demo branch if you do not want this file in a
-production repository.
-
-The deterministic non-model validation flow lives in
-`examples/agent-driven-policy-management/validation/validation.sh`.
-
-## Options
-
-```bash
-export OPENSHELL_BIN=/path/to/openshell
-export DEMO_BRANCH=main
-export DEMO_RUN_ID="$(date +%Y%m%d-%H%M%S)"
-export DEMO_FILE_DIR=openshell-policy-advisor-demo
-export DEMO_KEEP_SANDBOX=0
-export DEMO_APPROVAL_TIMEOUT_SECS=240
-export DEMO_AGENT_PROVIDERS="agent-provider-a agent-provider-b"
-```
+That's the whole thing. The demo resolves your GitHub handle from `gh`, picks
+`openshell-policy-demo` as the repo, and writes one timestamped markdown file
+under `openshell-policy-advisor-demo/` per run.
+
+## Overrides (all optional)
+
+| Env var | Default |
+|---|---|
+| `DEMO_GITHUB_OWNER` | `gh api user --jq .login` |
+| `DEMO_GITHUB_REPO` | `openshell-policy-demo` |
+| `DEMO_BRANCH` | `main` |
+| `DEMO_RUN_ID` | timestamp |
+| `DEMO_GITHUB_TOKEN` | falls back to `GITHUB_TOKEN`, `GH_TOKEN`, or `gh auth token` |
+| `DEMO_KEEP_SANDBOX` | `0` (set `1` to inspect the sandbox after the demo) |
+| `DEMO_APPROVAL_TIMEOUT_SECS` | `240` |
+| `OPENSHELL_BIN` | `target/debug/openshell` if present, else `openshell` on `PATH` |
+
+## What the agent sees
+
+`policy.template.yaml` is the initial restrictive policy: a read-only L7 REST
+rule for `api.github.com` plus the binary set Codex needs. The agent has to
+ask for the additional `PUT /repos/.../contents/...` write itself — that's the
+proposal you approve.
+
+## What gets approved (trust model)
+
+Every proposal lands in the gateway as a `PolicyChunk` — a structured object
+with three parts, each with a different trust level:
+
+| Field | Source | Trust |
+|---|---|---|
+| `proposed_rule` (host, port, method, path, binary) | agent, schema-validated by the gateway | structured contract — *this* is what you're approving |
+| `rationale` (free-form prose) | agent | hint only — a compromised agent can lie here |
+| `validation_result` (prover output) | gateway-side prover | trust signal — but this surface is in progress (see [RFC 0001](../../rfc/0001-agent-driven-policy-management.md)) |
+
+The MVP today shows the structured rule plus the agent's rationale in
+`openshell rule get` and the TUI inbox panel. The demo's `openshell rule
+approve-all` auto-approves to keep the loop short — in a real session a
+developer reviews the structured grant before pressing `a`. Prover-backed
+validation badges, computed reachability deltas, and a richer "this is what
+the rule actually permits" summary are the next phase. For now, **always
+approve based on the structured rule, not the agent's rationale.**
+
+## Going further
+
+`e2e/policy-advisor/test.sh` runs the same loop deterministically without an
+LLM (curl + the `policy.local` API directly). Use it to validate the proxy and
+proposal pipeline when iterating on the sandbox or gateway code.

…licy-management/validation/validation.sh e2e/policy-advisor/test.shexamples/agent-driven-policy-management/validation/validation.sh renamed to e2e/policy-advisor/test.sh examples/agent-driven-policy-management/validation/validation.sh renamed to e2e/policy-advisor/test.sh

@@ -1,45 +1,48 @@
 <!-- SPDX-FileCopyrightText: Copyright (c) 2025-2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. -->
 <!-- SPDX-License-Identifier: Apache-2.0 -->
 
-# Agent Policy Management Demo Task
+You are running inside an OpenShell sandbox. Your job is to write one
+markdown file to GitHub via the GitHub Contents API.
 
-You are inside an OpenShell sandbox. The user asked you to write one markdown
-file to GitHub using the GitHub Contents API.
-
-Target:
+## Target
 
 - Repository: `{{OWNER}}/{{REPO}}`
 - Branch: `{{BRANCH}}`
 - File path: `{{FILE_PATH}}`
 - Run id: `{{RUN_ID}}`
 
-Requirements:
-
-- Use ordinary shell commands and the `GITHUB_TOKEN` environment variable.
-- Do not print, echo, or reveal the token.
-- First try to write the file with `PUT /repos/{{OWNER}}/{{REPO}}/contents/{{FILE_PATH}}`.
-- If OpenShell returns `policy_denied`, read
-  `/etc/openshell/skills/policy_advisor.md` and follow the local API workflow
-  there.
-- Submit the narrowest proposal that permits only this write.
-- Do not include a `tls` field in the proposed endpoint unless you are
-  explicitly disabling TLS inspection.
-- After submitting a proposal, retry the write for up to 120 seconds. The
-  developer may approve while you are waiting.
-- Do not print the full GitHub response body. It can include temporary
-  `download_url` query tokens. Extract only `content.path`, `content.html_url`,
-  and `commit.sha`.
-- Finish with a short summary that says whether the write succeeded. Include
-  the GitHub file path and URL if GitHub returns them.
-
-Suggested file content:
-
-```markdown
-# OpenShell policy advisor demo
-
-Run id: {{RUN_ID}}
-
-This file was written from inside an OpenShell sandbox after the agent read the
-policy advisor skill, submitted a narrow policy proposal, and waited for
-developer approval.
-```
+## What to do
+
+1. PUT the file with `curl` against
+   `https://api.github.com/repos/{{OWNER}}/{{REPO}}/contents/{{FILE_PATH}}`.
+   Authenticate with the `GITHUB_TOKEN` environment variable. Do not echo the
+   token. Body content (base64-encoded into the JSON `content` field):
+
+   ```
+   # OpenShell policy advisor demo
+
+   Run id: {{RUN_ID}}
+
+   Written from inside an OpenShell sandbox after a narrowly-scoped policy
+   proposal was approved by the developer.
+   ```
+
+2. The first attempt will fail with HTTP 403 and a JSON body containing
+   `"error": "policy_denied"`. Read the body — it tells you which layer denied
+   you (`l7`/`rest`), which method/path was missing, and where to learn more.
+
+3. Read `/etc/openshell/skills/policy_advisor.md` and follow it. Submit the
+   narrowest possible proposal to `http://policy.local/v1/proposals` — exact
+   host, exact port, exact method, exact path, binary `/usr/bin/curl`. Do not
+   include query strings. Do not propose wildcard hosts.
+
+4. After submitting, retry the PUT every few seconds for up to 120 seconds.
+   The developer is approving from outside the sandbox; once approved, the
+   sandbox hot-reloads policy and the same PUT will succeed.
+
+5. Stop as soon as the PUT returns HTTP 200 or 201. Print a short summary
+   showing whether it succeeded, plus `content.path` and `content.html_url`
+   from the GitHub response. Do not print the full response body.
+
+If anything is unclear, prefer making a narrower proposal and asking for
+approval again over widening the rule.