61 lines
7.4 KiB
Markdown
61 lines
7.4 KiB
Markdown
# 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.
|