# ARR Job Trace Semantics for Internet Deployment ## Question Whether the ARR task trace is understandable when ARR is deployed on a server reachable through the internet, rather than being interpreted as if processing occurred on the operator's computer. ## Findings - The current `artifact_callback` path is owned by ARR's fixed processor. It does not create a remote Agent/MCP run, so `remote_run_id=null` is expected and is not a failure. - Persisted delivery keys such as `local-arrjob-...-a1` are delivery/idempotency identities. They are retained for compatibility and are not a claim about the user's machine or the server's geographic location. - A successful job with `current_stage=downstream` and `DOWNSTREAM_EVENT_QUEUED` has already committed the Finance version. `publish_status=pending` means the durable outbox event is waiting for its downstream consumer. ## Change The trace job summary now adds: | Field | `artifact_callback` | legacy `direct_mcp` | |---|---|---| | `execution_scope` | `arr_runtime` | `remote_agent` | | `processor_mode` | `fixed_processor` | `legacy_direct_mcp` | | `remote_dispatch` | `none` | `mcp` | User-visible messages now say `ARR 固定处理器输出` and explicitly state `Finance 数据库提交已完成` before the outbox wait. Existing `delivery_mode`, `remote_run_id`, trace version, persisted delivery IDs and privacy allowlist remain compatible. ## Verification - `python3 -m unittest tests.test_arr_web_job_trace tests.test_arr_web_task_log_ui tests.test_arr_web` — 27 passed. - `python3 -m py_compile arr_web/job_trace.py` — passed. - `node --check arr_web/static/app.js` — passed. - `git diff --check` — passed. - No live task was rerun, no service was restarted and no Finance/report/Booking business data was changed. ## Follow-up After deployment, inspect one successful `artifact_callback` trace and confirm the additive header fields appear in the deployed CLI/API/UI. This is a display/observability acceptance step; it is separate from rerunning the historical 2026-07 company-report `11-20` publication.