docs(ops): record verified product-site release

[LauraGPT]

Summary

Records the completed www.funasr.com publication of source 460f00675499924fec0a14bdbeb7125ed505dbb2 (#3743), release 20260930T211757Z, verified at 2026-09-30T21:57:20Z (October 1 in Asia/Shanghai).

• Replace the stale production record with verified source/archive/backup checksums and the preserved previous release.
• Point the documented emergency configuration restore command at the matching pre-release backup.
• Record the actual staged/public acceptance and explain why the unchanged deployment-manifest checksum alone cannot prove page freshness.
• Preserve the existing deployment, rollback and follow-up monitoring procedure.

Publication Evidence

The official existing release script performed the atomic switch and graceful Nginx reload. All 273 deployed files match the transferred inventory; all 206 previous HTML routes remain present. Thirteen public routes returned HTTP 200 with exact response-body hashes and required security headers. Independent public-domain Chromium checks passed all four Chinese/English desktop/mobile cases. The previous release and fresh backup remain intact; Nginx master identity and configuration were unchanged. No model service restart, model inference or package release.

Live guides: Chinese, English.

Validation of This Documentation Change

• Release-script tests: 5 passed.
• Fresh build: 117 product pages; recursive comparison to the deployed artifact is identical. This operations note does not alter website output.
• Checked release/source/backup fields against the saved production receipt.
• git diff --check passed.
• Independent read-only review found no P1/P2.

The historical 521 site tests / 100 documentation passes plus one local Sphinx skip belong to the deployed source validation, not a new full-suite run for this one-file note. All five hosted workflows on the deployed source succeeded. One-hour and 24-hour health follow-ups are separate from immediate acceptance.

Integration and One-Hour Follow-Up

Merged as 23f50baacb593d9d841c86bf1ecad910731c3fe1; the merge tree exactly matches the signed, tested PR head. Exact-head Product site run 36786405949 passed all three jobs. Exact-merge Product site run 36790404660 and API documentation run 36790404640 both completed successfully. The five release-script tests were rerun before merging and passed. This documentation merge did not redeploy the website.

The one-hour production follow-up completed at 2026-09-30T23:24:45Z: 15 public pages returned 200, including exact release-body hashes for the 13 original acceptance routes; all 16 checks of the eight fixed redirects passed, including attempted query-target overrides. Release link, Nginx master identity/configuration, previous release and backup remain intact; the exact deployment lock is absent. No completed-request 5xx appeared in the inspected post-publication access-log window.

Scope limitation: legacy WebSocket demo upstreams still logged connection timeouts, also present before publication. Their existing error handling translates upstream 502/503/504 to a 302 deployment-guide redirect, so zero visible 5xx does not establish backend health. The static-site follow-up passed with this pre-existing warning; no model inference, backend restart or rollback was performed. The 24-hour follow-up is still pending (first scheduled check at/after 2026-10-01T21:57:20Z).

24-Hour Follow-Up Completed

The scheduled read-only follow-up is complete. Fifteen public pages matched their expected content (including all 13 original acceptance-route hashes), and all 16 fixed redirect checks passed. The release symlink, Nginx master identity/configuration, previous release, and backup hash remained unchanged. No deployment, restart, log-reopen signal, or rollback was performed.

Result: static release checks passed, with legacy upstream and log-rotation warnings. The examined completed-request logs contained no visible 5xx, but legacy WebSocket upstream connection timeouts were present both before and after publication; the existing Nginx error-page routing turns those upstream failures into 302 redirects. This is not a claim that the legacy backends are healthy.

The current .log files were empty after rotation while live Nginx descriptors still pointed to .log.1. Validation used those actual open inodes and rotated history, not the empty files. Log rotation remains an operational follow-up. Only aggregate counts were retained; traffic includes validation requests and is not evidence of organic conversions or star growth. The one-hour and 24-hour checks are now both complete and should not be repeated as pending work.