docs: explain stale publication recovery record

This commit is contained in:
鲨鱼辣椒 committed 2026-10-13 16:40:29 +08:00
1 parent 2899009215
commit 05d5182178
1 file changed
+50
@@ -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.