# Reflection: Remote Agent Success Is Not a Database Commit

## Trigger

Two direct-MCP vertical-slice runs reached a remote SuperAgent `success` state without creating an MCP submission or committed Finance facts.

## Expected Behavior

End-to-end acceptance should require all authoritative signals: an MCP `committed`/`already_committed` receipt, consumed one-time grant, accepted processing state, and matching Finance version/current/fact rows.

## Actual Behavior

The remote orchestration platform considered the run complete even though its cached MCP tool state prevented the business submission. The local processing state also lacked an automatic database mapping for the runner's `delivery_missing` outcome.

## Root Cause

- Weak gate
- Stale external tool discovery
- Missing terminal-state mapping

## Evidence

- Files: `.project-docs/50-evidence/topics/2026-07-29-live-synthetic-xml-vertical-slice.md`, `arr_processing/runner.py`, `arr_processing/postgres.py`
- Session/thread: live no-PII upload test on 2026-07-29
- Command output: remote status `success`; submission/version/current/record counts all zero; protected cleanup ended as `PROCESSING_RESULT_MISSING`
- Docs involved: current state, evidence index, commitments, stale items

## Lesson

Treat orchestration status as a progress signal, not the system-of-record outcome. Every live test must cross-check the one-time grant, MCP submission ledger, processing terminal state, Finance facts, and downstream current pointer before reporting success or enabling a mutation endpoint.

When remote completion lacks a business result, revoke any remaining grant and terminalize the exact run under identity locks; never leave a late submission path open.

## Action

- Update docs
- Add check/eval
- Record the missing automatic terminal-state mapping for separate implementation.

## Promotion

Promoted to the live E2E evidence record, current-state risk, future commitment, and stale-item tracking. No new product ADR is required.