Agent Architecture Review, Validation snapshot

`RunLedger.append()` writes structured `AuditEvent` rows for run creation, approvals, submissions, successes, failures, cancellations, invoice snapshots, policy decisions, idempotency keys, and bank responses. That is materially more inspectable than the prior loop. But the ledger is only JSONL append-by-convention: there is no hash chain, HMAC/signature, immutable storage, sequence number, or integrity check, despite comments describing it as tamper-evident. It can also log a misleading `policy_hash` if `draft_tasks()` receives a different policy from the run policy. Delta: audit coverage improved, but audit integrity and policy-decision provenance remain insufficient for payment accountabi…

The workflow has visible states via `RunStatus`, `TaskStatus`, and JSONL `AuditEvent`s, and `_submit_one()` records `task.submitted` before calling the bank. However, operational continuity is still process-local: `PaymentWorkflow.runs` and `PaymentWorkflow.tasks` are in-memory dictionaries, `inspect_run()` only reads those projections, and there is no replay path from `RunLedger.read_run_events()` after restart. A crash after `task.submitted` but before `task.succeeded`/`task.failed` would leave the persisted ledger inspectable only manually, not as a resumable workflow. Delta: this is a major improvement over the prior opaque loop, but persistence is not yet a usable lifecycle primitive.

The code now models delegated work with `PaymentRun`, `PaymentTask`, and a `Policy` containing amount limits, vendor lists, due-window constraints, and approver-role intent. But the delegation contract is not yet authoritative: `draft_tasks()` accepts an arbitrary `policy` argument without checking `policy.hash() == run.policy_hash`, `Policy.max_run_total_pence` is never enforced, and `Policy.required_approver_role` is never checked. Delta: this improves the prior run/task/policy gap, but the current policy object is still partly advisory rather than a hard boundary.

The workflow has an initial steering primitive: `cancel_run()` sets `cancellation_requested`, marks not-yet-submitted tasks `CANCELLED`, and `execute_approved()` checks the flag before each call to `transfer_funds()`. Idempotency keys also reduce duplicate-payment risk. But steering is incomplete and partly non-durable: the cancellation flag is only in memory, there is no pause/resume or reprioritisation path, failed tasks cannot actually be retried even though the inbox message says to retry from the operator inbox, and `execute_approved()` ignores `TaskStatus.FAILED` rather than offering a controlled replay with the same idempotency key. Delta: this improves the prior no-interrupt design,…

The code separates routine progress from intervention paths by recording normal transitions in `_record()` and escalating `BankAPIError` plus policy-hash mismatch through `OperatorInbox.post()`. But `OperatorInbox` is only an in-memory `list`, and `run_daily_batch()` creates it locally and discards it, so a critical `auth_missing` alert may never reach an operator in a cron/background context. Delta: this addresses the prior swallowed-exception pattern, but the escalation channel is still not durable or operator-facing.