docs: plan accurate Agent message and waiting times

.project-docs/30-worklog/tasks/20261013-chat-message-time-64ebac32.md

@@ -0,0 +1,60 @@
+# Task: Plan accurate Agent chat message times and waiting status
+
+## Identity
+
+- Task ID: 20261013-chat-message-time-64ebac32
+- Mode: Feature
+- Branch: codex/20261013-chat-message-time-64ebac32-chat-message-time
+- Worktree: /Users/chillishark/Makelore 麦洛/.codex-worktrees/makelore/20261013-chat-message-time-64ebac32
+- Base commit: 2899009215b1de8e28b84fc108e880c6e68a6098
+- Owner: codex
+- Status: Ready for Integration
+
+## Scope
+
+- Inspect existing timestamp contracts and propose per-message send/reply times plus waiting-status timing in personal Agent chat.
+
+## Intent And Constraints
+
+- User asks how to add time to the proposed queue display. This turn prepares an accurate interaction and source-backed implementation approach; no product change, live probe, message submission, runtime update, cancelled publication repair, deployment, merge/push or cleanup. Preserve existing temporary app/profile/inputs and desktop focus.
+
+## Outcome
+
+- Proposed compact per-message time integrated with the approved queue/status direction. User question: local-timeHH:mm plus sent/confirmed waiting status; waiting duration tied to cloud request acceptance, not history poll time. Assistant reply: pending/processing state while running, completion time only after actual recorded finish. Completion clears transient status but retains the time; cancelled/failed states remain identifiable. Today usesHH:mm; older dates add month/day and year when needed; tooltip carries full date/seconds.
+- Existing CloudMessage.created_at already passes through Main and can expose a stable recorded-message time. Current TrialMessages/live articles render no time. Existing formatMessageTimestamp/MessageTimestamp in Code chat provides local-time formatting, date fallback, semantictime element and full-time tooltip; retain Makelore typography/light palette and adjust label to actual semantics.
+- Crucial semantic boundary: assistant created_at can be established at model start with empty content, not finish; historical/legacy paths may create rows at final storage. Therefore do not label it reply-completion time. Yuxi Run timing already records created/started/first-output/finished, but client CloudRun/Main projection currently drop it. first_output_at may include reasoning/tools, so do not call it first visible answer time.
+- Current Yuxi personal request_view and history.queued_requests return only IDs/status/version, not requestcreated_at. Main/CloudRequest use the same five fields. Accurate persistent send/wait durations therefore require exposing the original request timestamp in personal DTO/history and forwarding it; existing older dates remain unknown unless their durable request/run records can supply them. The current user-message created_at is server input acceptance before enqueue/dispatch (agent_run_service.py636–656, queue service256–275), so it can serve as the confirmed sent time; it is not the physical local click time. Requestcreated_at is queue entry, while Runcreated_at occurs only at dispatch.
+- No product source, runtime, server, message data or configuration changed. This is a source-backed proposal, not an activated UI.
+
+## Verification
+
+- Read current committed client shared DTOs, Main operation whitelist/history projection, CloudChat TrialMessages/stream type and existing MessageTimestamp/formatMessageTimestamp. Read committed YuxiHEAD784b7dcf25b0b27dccc4c3e3486cd466a6e7a6dc reference only; no Yuxi ownership adoption or uncommitted product reads.
+- Known paths: client CloudChat.tsx426, shared/cloud-agents.ts88–120, electron/services/cloud-agent-operations.ts8/71/95/271–277, src/pages/Chat/MessageTimestamp.tsx and src/lib/message-timestamp.ts. Yuxi makelore_conversation_service.py209/227/306 and agent_run_service.py888 carry the data boundary. Independent timestamp-contract review confirmed audit-start/finish semantics and first-output ambiguity.
+- No new test/build or live probe needed because product code and application are unchanged.
+
+## Follow-ups
+
+- If implementation is requested, bind it to the then-current committed app source and the message replay repair. Backend should expose durable request acceptance and actual reply completion timestamps for history/queue without new invented times; Main/shared DTOs retain those approved fields; Renderer uses consistent local-time formatting and preserves original intent timestamps on retries. Test queue/reload, delayed dispatch, multi-message answer, completion/cancellation, invalid/legacy times, cross-day/year/timezone and old-message replay. Missing times should be omitted or explicitly unknown, never reset to now.
+
+## Promotion Candidates
+
+- None recorded.
+
+## Project Context Loaded
+
+- Task ID20261013-chat-message-time-64ebac32, modefeature, exact branch/worktree/base2899009215b1de8e28b84fc108e880c6e68a6098 verified against bundled start/status. Isolated from all occupied worktrees. No unknown work adopted.
+- Entry/memory/AGENTS, project-positioning/current-state/decisions/system, personal-cloud-Agents ADR, domain/success criteria and evidence/reflection/commitments are already loaded in this continuing project session; canonical trees match previously reviewed2899009 context. Own generated record read before planning. All current peer Scope/Intent/Promotion sections reread; adjacent prior chat replay diagnosis is complete/read-only; publication repair remains cancelled. Existing teacher/time presentation belongs to separate consultation path. No semantic conflict blocks this read-only planning.
+- Main owns authenticated APIs and whitelisted DTO fields. UI must show real message times, preserve task/account/message identity and avoid attributing final storage time to initial output or request dispatch time to initial click/queue entry. A missing timestamp must remain unknown rather than fabricate exact cloud time. Existing Makelore light/compact message style remains.
+- Likely files: shared CloudMessage/CloudRequest/CloudRun, Main cloud-agent operation projection, CloudChat TrialMessages/stream messages, committed Yuxi request/run/history views. Unknowns: precise semantics of history.created_at and queue/start/first-output fields. No live inspection needed.
+- Planning Gate: Passed.
+
+## Plan
+
+1. Verify message/send/reply/queue timestamp availability and semantic boundaries in client and committed backend source.
+2. Propose compact per-message time plus status/wait-duration interaction, including dates/timezone/history/streaming rules.
+3. Record source evidence and exact client/backend work required; explain in plain Chinese. No implementation/app update in this proposal.
+
+## Timestamp Contract Review Detail
+
+- Model audit begins an assistant row at start and publishes it later with the same created_at; finish updates actualfinished_at/content. Legacy creation may occur at final storage. Accurate reply-completion presentation therefore needs messagefinished_at or the associated completed Runfinished_at rather than barecreated_at. Historical personal pages include only the latest Run and cannot stamp every earlier reply with that one finish time.
+- Current-page wait fallback may correlate queue request_id with the user message's servercreated_at, but durable queue/requestcreated_at anddispatched_at should be exposed for complete pagination/restart recovery. Columns already exist; no database migration or made-up local time is needed. Same local request retries retain first send identity/time. Group multi-message answer timing by actual request/run, preserving each message's provenance.