43 lines
3.1 KiB
Markdown
43 lines
3.1 KiB
Markdown
# 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.
|