# Evidence Topic: Local XML upload runtime re-enabled

## Metadata

- Date: 2026-07-29
- Status: Active
- Scope: Current local Web process on port 8765
- Confidence: Fact
- Source: launchd/process inspection, health response and in-app browser DOM inspection
- Last verified: 2026-07-30
- Stale trigger: Restart or reconfiguration of `com.chillishark.opera-arr-report`, route/Keychain changes, or replacement of the 8765 Web process

## Question

Why was ARR.XML upload disabled in the currently running page, and is it actually enabled after correction?

## Evidence

- Before correction, launchd PID 70702 ran `arr_web.run` with database, Agent writeback, monthly and company-report flags but omitted `--enable-processing`.
- The pre-correction health response was HTTP 200 with `database_ready=true` and `processing_ready=false`.
- The controlled launcher `/Users/chillishark/温德姆AR/start-lan.command` already loaded the private route configuration and Keychain-backed runtime credentials; only the final processing flag was missing.
- After adding `--enable-processing` and restarting label `com.chillishark.opera-arr-report`, PID 50730 runs with that flag and health reports both `database_ready=true` and `processing_ready=true`.
- The refreshed page exposes one XML input accepting `.xml`, `text/xml` and `application/xml`; it is enabled, the dropzone is not disabled and the service hint is empty. The process button remains disabled until a file is selected, as designed.
- No XML file was selected or submitted during this verification.

## Finding

The upload was disabled because the long-running local launcher omitted the explicit processing feature flag. The corrected process has passed both the runtime readiness gate and the page-level control check.

## 2026-07-30 PROGRAM_INPUT v3 reload

Job `arrjob-1fd0f5e182eb4056af53be7300174981` exposed that the then-running PID 2891 had started at 10:13, before the v3 source files were modified at 11:14. Its 11:34 trace therefore repeated `arr-opera-daily-program-input-2` and ended in `status=running` before any model tool call. The four visible `fetch_oss_file` strings came from the same attachment policy copied through middleware, not four tool calls.

PID 2891 was terminated only after its command and 8765 listener identity were revalidated. The same controlled launcher then started PID 10376 at 11:40. `GET /api/health` returned `database_ready=true`, `processing_ready=true`, `monthly_ready=true`, `download_ready=true`, `company_reports_ready=true` and `agent_writeback_ready=true`. A new job, rather than the old v2 job, is required to prove the loaded v3 contract at the remote Agent boundary.

## Impact

The user can now select ARR.XML on the current local page. A real end-to-end result still requires SuperAgent to call the published MCP tool and an MCP `committed`/`already_committed` receipt; merely selecting or dispatching the file is not a database success signal.

## Risk

The local launchd service remains bound to `0.0.0.0:8765`. Enabling upload therefore exposes a mutation surface to the reachable LAN; use only on a trusted network and move formal testing behind the operator-managed authenticated public boundary.
