diff --git a/.project-docs/30-worklog/tasks/20261013-publish-pending-explain-5dd70a31.md b/.project-docs/30-worklog/tasks/20261013-publish-pending-explain-5dd70a31.md
new file mode 100644
index 00000000..aecc2b25
--- /dev/null
+++ b/.project-docs/30-worklog/tasks/20261013-publish-pending-explain-5dd70a31.md
@@ -0,0 +1,50 @@
+# Task: Explain pending publication record on the channel page
+
+## Identity
+
+- Task ID: 20261013-publish-pending-explain-5dd70a31
+- Mode: Feature
+- Branch: codex/20261013-publish-pending-explain-5dd70a31-publish-pending-explain
+- Worktree: /Users/chillishark/Makelore 麦洛/.codex-worktrees/makelore/20261013-publish-pending-explain-5dd70a31
+- Base commit: 2899009215b1de8e28b84fc108e880c6e68a6098
+- Owner: codex
+- Status: Ready for Integration
+
+## Scope
+
+- Explain the screenshot's pending publication record, its appearance on the WeChat page, and retry/dismiss semantics. Read current recovery metadata and revision state if available; no business operation or source fix.
+
+## Intent And Constraints
+
+- User requests an explanation. Preserve the pending record, publication state, bindings, current UI/route/focus/runtime and credentials. Do not retry/discard/publish or change product source.
+
+## Project Context Loaded
+
+- Concurrent Gate passed: bundled start isolated this exact feature task/branch/worktree at deployed Renderer 2899009; status verified matching ownership/base. Main is unchanged 7c51bb4 / PID9968 / port58003.
+- Read active record, startup and retained unchanged positioning/current-state/decision/architecture/domain/evidence context from this same project; read relevant personal-cloud Agent/recovery source and accepted domain constraints. Canonical integrated state is historical; runtime current-pointer is authoritative for actual deployment.
+- Peer Scope/Intent/Promotion sections read-only. Draft-conflict, chat-repeat and WeChat UI tasks are active and have separate source/behavior scopes; their uncommitted work stays untouched. No semantic conflict for this read-only diagnosis; unknown legacy scopes have no dependency.
+- Goal: explain uncertain result recovery in product language. Main owns account-scoped journal/transport and Yuxi owns immutable publication/idempotency. Relevant modules: CloudRecovery, ChannelAccounts, cloud-agents service/journal, host-api and Yuxi publish service.
+- Gate result: Passed. Plan: trace receipt retention/replay/dismiss and global recovery display, then safely project only pending operation/revision/status metadata through the existing Main Host API; record findings and limitations without any publication/recovery mutation.
+
+## Outcome
+
+- The account has one pending publish record created at 2026-10-13 15:32:12 Asia/Shanghai. A safe existing Host API read maps it to 「整理小帮手」; its original expected draft revision is 5, while current draft revision is 7 and published version is 4, with the Agent enabled. It is an old publication intent, distinct from the WeChat card behind the dialog.
+- Main records publication before sending and removes it only after execution/response processing succeeds. Unlike fresh Agent creation, publication retains definite rejections such as 409/422 as unknown too. This conflates known failure with uncertain result and explains why a rejected attempt can remain under generic pending copy; the journal does not store the historical error/outcome.
+- Retry reuses the original operation ID and expected draft revision. Yuxi returns the same version if that operation was already accepted; otherwise it attempts that original draft and rejects a stale revision. It does not publish newer edits under the old request. Dismiss removes only the local reminder/record and does not undo saved cloud content.
+- ChannelAccounts reads the entire current-account recovery journal, not only channel operations, so publication records appear on the WeChat page. The publish entry itself does not set channel recovery-blocked state.
+- A read-only attempt to fetch publication/access history returned 502 cloud_service_unavailable; therefore the original request's terminal outcome and historical failure cause are not established. Do not label the actual old attempt definitively failed or successful based only on current draft/version numbers or a failing metadata read.
+
+## Verification
+
+- Inspected exact deployed client source 2899009 / immutable Main7c, current pointer and client/Yuxi journal/retry/idempotency source. Independent read-only agent review agrees with retry/dismiss/global-display semantics.
+- Existing Main-owned Host API recovery and Agent GET returned success with only operation/time/revision/name/status projected. No prompt/configuration text, credential, secret, raw journal file or auth token was read or recorded. Access action maps to an upstream GET; it returned safe 502 code, with no publication/recovery/channel mutation.
+- Actual Main PID9968 and current renderer pointer, route/UI and foreground were unchanged; Inspector closed after both brief read-only probes. No retry, discard, publication, real message or app update.
+- No tests/build required: product source is unchanged, only this task record is added. Task-aware document drift and whitespace checks run at completion.
+
+## Follow-ups
+
+- An outcome-aware publication recovery fix should distinguish a fresh definite rejection from a previously accepted/uncertain operation, and label its Agent. Any implementation must preserve original-ID deduplication and must not automatically replay or discard this existing unknown request. It is outside the user's explanation-only request.
+
+## Promotion Candidates
+
+- None recorded.