docs: clarify publication query error attribution

.project-docs/30-worklog/tasks/20261013-publish-pending-explain-5dd70a31.md

@@ -48,3 +48,11 @@
 ## Promotion Candidates
 
 - None recorded.
+
+## Follow-up: 502 attribution and repair ownership
+
+- Same-task ownership resumed and verified. Startup/context and current active peer Scope/Intent/Promotion sections re-read; this remains read-only diagnosis. Gate Passed. No product, cloud state, pending record or runtime update.
+- Corrected earlier wording: the actual evidence is a 502 cloud_service_unavailable response from the running desktop Main Host API. It is not a verbal report from a teammate and does not by itself establish an upstream HTTP 502.
+- The Main route maps non-CloudAgentsError exceptions to 502. The service also synthesizes 502 for invalid/oversized upstream data, session metadata or projection failures, while preserving status when fetchJson receives a non-success JSON response. Thus transport, parsing/projection, service response and gateway causes require further correlation; no single-party backend fault is established.
+- Client repair ownership: known-failure/uncertain publication classification and reminder context are client behavior. Query availability/contract is an integration investigation involving the desktop client and Yuxi backend; the exact failing layer is still unverified. The supplied backend chat is titled YUXI-智能体后端 and was only read, not messaged.
+- Verification: re-inspected route/service operation sources and the existing read-only diagnostic result. No live action retried, no raw errors or credentials inspected, and no source edits/tests/build required.