[ZASI v33 P2] Typed intent/plan policy engine, approvals, and evidence-backed capability registry #11

Objective

Make policy, approval, verification, and evidence first-class runtime primitives so models/personas can propose work but cannot authorize side effects.

Source-grounded findings

• /api/tick mutates daemon state through GET and /api/execute/{key} executes subsystem behavior through GET.
• /api/mutate and /api/rsi/upgrade expose powerful mutation/self-improvement surfaces.
• MCPProtocolServer.handle_json_rpc_request() dispatches tools/call directly without a shared session/capability/approval broker.
• README/docs describe formal, hardware, quantum, CAD, and RSI capabilities more strongly than the implementation evidence supports.

Scope

• Define canonical typed contracts: Intent, Plan, PlanStep, Approval, Action, Run, Observation, Verification, Evidence.
• Add R0–R5 risk classification and deterministic policy evaluation.
• Bind approvals to exact plan digest, tool version, tenant/principal scope, and expiry.
• Make GET/HEAD/OPTIONS side-effect free; retire or gate legacy side-effecting GET routes.
• Add evidence provenance, source, adapter version, observed/fresh timestamps, artifact refs, verification procedure, disclosure, and supersession.
• Registry must separate implementation state, runtime state, evidence state, and allowed risk tiers.
• Models, JARVIS/FRIDAY/EDITH personas, voice output, and UI modes must never be authorization decisions.

Acceptance criteria

• Policy matrix tests cover R0–R5.
• No GET route can mutate state or execute a tool.
• Plan generation has no external side effect.
• Approval reuse against a changed plan/tool/scope is rejected.
• Fixed/demo values cannot be emitted as measured/verified evidence.
• Every operator-visible capability status links to provenance or an explicit unavailable/simulated disclosure.
• MCP tool execution follows the same policy/approval/audit/evidence path as REST actions.

Depends on

#9 #10

Priority

P2 / governance release gate.