[bkataru]

Status: LANDED — graph resolved, all pieces implemented, full suite executed. The earlier BLOCKED state is closed: the last conflicting sqlite edge is gone (pawan-core's rusqlite 0.34→0.40 in one cast; dermacs/deagle-core 0.3.1 published with rusqlite 0.40 — cargo tree -i libsqlite3-sys = exactly one, 0.38.2).

What this PR is

The OpenAPPA guardrail embedded as a lib crate at pawan's agent-loop seams: the pre-call check inside check_tool_permissions (before the tool's execute path is ever entered) and the post-call check after tools.execute returns, before the result reaches the model. The engine answers one question each way — is this data allowed to go to this destination? and may this result re-enter the conversation?

The merge changes no production behavior. The guard is off by default: [appa] enabled = false (or the section absent) leaves pawan's permission gates exactly as they were; activation needs an explicit enabled = true and a policy_path. The production policy configuration is a separate, deliberate act awaiting the owner's decisions — this PR ships the mechanism, its proof, and its gate.

Evidence (all executed on this head)

• rustc 1.95.0 (pawan pins none); cargo test --workspace ALL GREEN — 969 pawan-core lib (incl. 11 guard tests), 59 integration, 42 pawan-api (incl. 8 identity-fence tests), 46 pawan-mcp, the cli suites, doc tests — 0 failures; cargo clippy -p pawan-core -p pawan-api -p pawan-mcp 0 warnings; cargo fmt --check clean.
• The three invariants, each with its control:
  • A denied call never executes — DenyCall(offers=0) ⇒ the canary tool's execute path recorded ZERO invocations and the canary file is absent; the model read the engine's feedback.
  • A blocked result never reaches the model — the tool DID run (result-side proof); with the sanitizer battery down, the raw canary never enters the history (ReplaceOutput "no registered sanitizer answered"); the healthy control delivers the sanitized derivation (DeliverValue("scrubbed")).
  • An outage stops the flow — a closed-port battery ⇒ Refuse with zero invocations; the same battery answering ⇒ AllowCall + the tool executes.
  • Plus: the remedy flow end-to-end (DenyCall(offers=2) → PassControl → Authorized → AllowCall → scrubbed DeliverValue), undeclared-tool Refuse, missing-callback hard deny, Prompt defaults, real mutating() overrides, fail-closed-at-open.
• Gate: scripts/appa-gate.sh — describe --check rc=0, replay pass rc=0 (2 ok), negative control rc=1 ("got deny, want allow" — the harness discriminates). The CI job clones the pinned engine rev and builds the CLI from source, never an installer. CI on the head: Check & Lint, Doc, OpenAPPA policy gate, Test (nextest), cargo audit, macOS TUI smoke — all success.
• The engine is pinned at rev 1c52575176330bc88a3c346abe678af5d42083b3 (v0.31.1, MIT, edition 2024; appa + appa-runtime-api + appa-eventlog, default-features = false, Backend::Memory for embeds — the sqlite format is version-bound).

Behaviors found and fixed while landing (recorded in tests)

• A remedy must be vouched by the control call before execute_embedded_remedy (unvouched = Refused{Unvouched}) — take_remedy now vouch-then-executes.
• The pre-call must identify the call through the adapter (ToolNaming::Canonical — a raw spelling reads as "not declared").
• The read-only-bash exemption now also applies in the mutating gate, so headless read-only commands are not denied while non-read-only mutating tools hard-deny.

Honest limitations (standing gaps, none silently assumed covered)

• dims-auth composition is verified against the real /v1/validate CONTRACT (auth-src ff314e1: request {token, required_role, resource_id} → response {user_id, email, roles} on 2xx; 401 invalid_token; 503 store outage), not against a live dims-auth instance — the fence's tests mock that exact contract. The first live wire-up re-pins live response fields against ValidateResponse.
• Unwired: spawn_agent subprocess loops, heal()'s direct cargo calls, post-dispatch bash/sd/ast_grep internals, MCP server-side effects, append_file's missing validate_file_write, coordinator mode runs without the guard.

[bkataru]

Status: BLOCKED on a dependency-graph conflict — the integration is complete but cannot compile until it resolves. Recorded here so this PR is not mistaken for merge-ready.

The conflict (measured): Only one package in the dependency graph may specify the same links value: libsqlite3-sys 0.32.0 (rusqlite 0.34, via deagle-core) conflicts with libsqlite3-sys 0.38.x (rusqlite 0.40, via appa-eventlog). deagle-core pins rusqlite ^0.34 at every published version (0.1.4, 0.1.5, 0.1.6, 0.2.0, 0.2.1, 0.3.0 — all measured on the crates.io index), so no dependency-resolution path exists on pawan's side: either appa loses its event log (Backend::Memory types live in appa-eventlog, and they are not re-exported by appa), or deagle-core moves to rusqlite 0.40.

The fix being routed: a deagle-core rusqlite-0.40 release with its own build/test proof. Until it lands, this PR stays blocked with the integration intact — no [patch.crates-io] band-aid, because that would diverge the estate's rusqlite version per repo.

What is DONE and measured in this PR (via a path-dep probe harness against the real pinned engine, since the graph conflict prevents the in-repo test run): the pre-call hook in front of every permission layer (denied calls never enter the tool's execute path), the post-call hook before the record build and history write, no-callback mutating tools now HARD DENY (was auto-approve), mutating() made real for the 11 tool families, the pawan-api identity fence (bearer or X-API-Key; static token or dims-auth composition via the real /v1/validate contract; unconfigured=503, outage=503, rejection=401; CORS allow-list driven), and the engine's decision shapes: outage→Refuse (with the healthy-battery AllowCall reverse control), denied→DenyCall(offers=0) with undeclared tools refusing, a confined result with the sanitizer down→ReplaceOutput (the raw canary never crosses), and the remedy flow DenyCall→PassControl→Authorized→AllowCall with stale offers refused.

What lands WITH the graph fix: the three-invariant Rust tests, config/appa.test.toml, the policy-tests/ replay traces, and the CI gate (describe --check + replay). Recorded unwired: spawn_agent subprocess loops, heal()'s direct cargo calls, post-dispatch bash/sd/ast_grep internals, MCP server-side effects, model-internal actions, and append_file's missing validate_file_write (that one is a pre-existing defect deserving its own issue — noted in the PR).

[bkataru]

Ready for review — final state (this supersedes the earlier BLOCKED status).

What to review: the appa gate at pawan's agent-loop seams (pre-call in check_tool_permissions, post-call before results reach the model), the remedy flow, the policy gate job, and the test corpus. The merge changes no production behavior — the guard is off by default ([appa] enabled = false or the section absent; opening also requires an explicit policy_path), so pawan's permission gates are untouched until a policy is deliberately configured.

CI on the head (90f8a53) — all six green: Check & Lint, Doc, OpenAPPA policy gate (describe rc=0, replay pass rc=0 ×2, negative control rc=1 — the harness discriminates), Test (nextest) — 969 pawan-core lib incl. 11 guard tests, 59 integration, 42 pawan-api incl. 8 identity-fence tests, 46 pawan-mcp, 0 failures, clippy 0 warnings, fmt clean — macOS TUI smoke, cargo audit. (PR #141 adds the sixth job your protection requires: Coverage + CRAP.)

The three invariants, each executed with its control:

1. A denied call never executes — the canary tool's execute path records zero invocations and the canary file is absent; the model reads the engine's feedback.
2. A blocked result never reaches the model — the tool DID run (result-side proof); the sanitizer battery down ⇒ the raw canary never enters the history; the healthy control delivers the scrubbed derivation.
3. An outage stops the flow — a closed-port battery ⇒ Refuse with zero invocations; the same battery answering ⇒ AllowCall + execution.
   Plus the full remedy flow (DenyCall(offers=2) → PassControl → Authorized → AllowCall), undeclared-tool Refuse, missing-callback hard deny, fail-closed-at-open.

Honest limitations carried in the body (not silently closed): the dims-auth composition is verified against the real /v1/validate contract, not a live instance (the first live wire-up re-pins it); the unwired list (spawn_agent subprocess loops, heal()'s cargo calls, post-dispatch internals, MCP server-side effects, append_file's missing write-validation, coordinator mode) stands.

Merge sequencing: this PR is behavior-neutral and needs your approval like any protected merge; #141 (the required Coverage + CRAP gate) is independent and can land first — once it's on main I'll update this branch so the gate runs on its head too, then this merges with all seven jobs green. The production policy configuration remains a separate, deliberate act pending the owner's decisions on #316.