feat: prepare ARR for controlled public deployment

.project-docs/60-reflection/cases/.gitkeep

@@ -0,0 +1 @@
+

.project-docs/60-reflection/cases/2026-07-29-internal-parameters-are-not-user-inputs.md

@@ -0,0 +1,38 @@
+# Reflection: Internal Parameters Are Not User Inputs
+
+## Trigger
+
+The user corrected two successive workflow descriptions: first, year/month/cutoff values were incorrectly treated as user submissions; then a monthly-report button was still incorrectly retained as a separate user action.
+
+## Expected Behavior
+
+Trace the complete business event chain before designing the interaction boundary: XML upload → Agent structured result → successful database commit → automatic monthly-report dispatch.
+
+## Actual Behavior
+
+Internal `RunRequest` fields and an existing manual endpoint were mistaken for the intended user workflow.
+
+## Root Cause
+
+- Unclear ownership
+- Stale docs
+- Conflation of an internal execution contract with a user-facing product contract
+
+## Evidence
+
+- Files: `.planning/monthly_reports_database_audit/findings.md`, `arr_web/app.py`, `arr_web/static/app.js`
+- Session/thread: user correction on 2026-07-29
+- Docs involved: ADR-001 and `.project-docs/40-domain/business-rules.md`
+
+## Lesson
+
+When a report program accepts year, month, or as-of values internally, do not infer that a person supplies them. Establish who initiates the business event, where values are derived, and which boundary owns the trigger before proposing UI or API behavior.
+
+## Action
+
+- Update docs
+- Add the confirmed boundary to the durable business rules and architecture decision.
+
+## Promotion
+
+Promoted to ADR-001, the business-rules document, architecture data flow, and stale-item tracking.

.project-docs/60-reflection/cases/2026-07-29-remote-success-is-not-a-database-commit.md

@@ -0,0 +1,42 @@
+# 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.