shiyuyun/wyndham-ARR
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix: enable XML processing in container entry

Browse Source
This commit is contained in:
Wyndham ARR
2026-07-29 18:34:03 +08:00
parent 12881be17e
commit ad3d9878c5
13 changed files with 118 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
.project-docs/50-evidence/evidence-index.md
View File

@@ -4,7 +4,8 @@ Use this index for searchable, traceable evidence records.
| Date | Topic | Status | Source | Detail |
|---|---|---|---|---|
| 2026-07-29 | Controlled public deployment repository | Active until server E2E | [Evidence topic](topics/2026-07-29-public-deployment-repository.md) | Deployment entry explicitly enables XML processing behind Caddy HTTPS/Basic Auth; 259 tests and snapshot safety checks pass, but Docker/public runtime awaits the user's server. |
| 2026-07-29 | Local XML upload runtime re-enabled | Active until local restart/config change | [Evidence topic](topics/2026-07-29-local-xml-upload-runtime-reenabled.md) | The old launchd process omitted `--enable-processing`; its controlled launcher was corrected and restarted, health now reports database/processing ready, and the XML chooser is enabled without submitting a file. |
| 2026-07-29 | Controlled public deployment repository | Active until server E2E | [Evidence topic](topics/2026-07-29-public-deployment-repository.md) | Dockerfile default CMD and Compose explicitly enable XML processing while source CLI/runtime readiness remain fail-closed; 260 tests pass with 2 skips, but the refreshed image and public runtime still require server verification. |
| 2026-07-29 | Live synthetic XML upload vertical slice | Active blocker | [Evidence topic](topics/2026-07-29-live-synthetic-xml-vertical-slice.md) | Public MCP reachability and one-tool discovery are restored; stale SuperAgent config version 33 must now be refreshed before the next commit test. |
## When To Add Evidence

36
.project-docs/50-evidence/topics/2026-07-29-local-xml-upload-runtime-reenabled.md Normal file
View File

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

13
.project-docs/50-evidence/topics/2026-07-29-public-deployment-repository.md
View File

@@ -12,29 +12,30 @@
## Question
Does the publishable source snapshot open XML processing through an explicit authenticated HTTPS deployment entry without exposing local state, credentials or unfinished report claims?
Does the publishable source snapshot open XML processing through both supported container launch paths without exposing local state, credentials or unfinished report claims?
## Evidence
- Files: `Dockerfile`, `compose.yaml`, `deploy/Caddyfile`, `deploy/.env.production.example`, `deploy/README.md`, `arr_web/app.py`, `arr_web/run.py`, `tests/test_arr_web.py`.
- Git: initial deployment snapshot commit `a701de9f0eff7402fe1785c3b35de5652576152a` was pushed to `origin/main`; an independent `ls-remote` check is required after the documentation closeout commit as the final publication proof.
- Deployment command inspection: Compose Web command contains `--enable-processing` and `--secure-cookies`; only Caddy maps host ports 80/443, Web and MCP use internal `expose` ports.
- Tests: Python 3.12 full discovery ran 259 tests successfully; 2 environment-dependent tests were skipped.
- Deployment command inspection: Dockerfile default Web CMD and Compose Web command both contain `--enable-processing`; Compose also contains `--secure-cookies`. Only Caddy maps host ports 80/443 in the documented Compose topology, while Web and MCP use internal `expose` ports.
- Regression: `tests/test_deployment_entrypoints.py` parses the Dockerfile JSON CMD, requires `--enable-processing`, and rejects accidental enablement of monthly, company-report or legacy Agent-writeback mutations.
- Tests: Python 3.12 full discovery ran 260 tests successfully; 2 environment-dependent artifact-tool tests were skipped.
- Integrity: every entry in `CHECKSUMS.sha256` passed and 10 JSON contracts parsed.
- Snapshot audit: 271 final candidate files, about 2.0 MiB, zero files over 1 MiB, zero symlinks, eight ZIP/XLSX archives inspected and zero detected secret/private-endpoint hits after documented placeholder allowlisting.
- Configuration: Compose YAML parsed and assertions confirmed both required Web flags. Docker/Caddy executables are absent locally, so no image build or public TLS runtime result is claimed.
## Finding
The repository snapshot provides a fail-closed deployment profile that opens XML upload only when the database, guarded OSS and SuperAgent processing runtime initialize. Web traffic is protected by Caddy HTTPS plus Basic Auth, MCP traffic retains application bearer authentication, and application defaults remain closed outside this profile.
The repository snapshot now makes direct Docker-image launches and Compose launches consistent: both request XML processing, while the source CLI remains default-closed and the page opens upload only after the database, guarded OSS, SuperAgent and HMAC runtime initialize. The documented Compose topology protects Web traffic with Caddy HTTPS plus Basic Auth, and MCP retains application bearer authentication.
## Impact
The next test should use the stable deployed domains, not the temporary ngrok endpoint. `processing_ready=true` is a deployment prerequisite, but business completion still requires SuperAgent tool rediscovery and an MCP `committed`/`already_committed` receipt with matching database facts.
The server must rebuild/redeploy the image; a platform-level CMD override must retain `--enable-processing`. `processing_ready=true` remains the deployment prerequisite, but business completion still requires SuperAgent tool rediscovery and an MCP `committed`/`already_committed` receipt with matching database facts.
## Open Items
- Build and start the containers on the public Linux server; verify DNS, ACME, health and logs.
- Rebuild and start the latest containers on the public Linux server; verify that `/api/health` reports both `database_ready=true` and `processing_ready=true`.
- Rebind and republish the SuperAgent MCP configuration against the stable MCP domain.
- Execute one no-PII XML end-to-end commit test.
- Implement automatic post-commit monthly dispatch and the required `TOTAL PRICE` formula in separately authorized work.