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.

3.1 KiB Raw Blame History