Files
makelore/.project-docs/30-worklog/tasks/20260928-agent-single-chat-27da516b.md

8.2 KiB

Task: Design one ongoing conversation per user and cloud agent

Identity

  • Task ID: 20260928-agent-single-chat-27da516b
  • Mode: Feature
  • Branch: codex/20260928-agent-single-chat-27da516b-agent-single-chat
  • Worktree: D:\Datas\OthersProjects.codex-worktrees\makelore\20260928-agent-single-chat-27da516b
  • Base commit: b26e25c9ed
  • Owner: codex
  • Status: Ready for Integration

Scope

  • User approved the proposed account + delivered-agent single ongoing chat and implementation.
  • Client store, per-turn scope/version, Host API, paged UI, legacy history, drafts, read receipts and focused regressions.
  • Coordination with the existing proactive-observer task was explicitly authorized. This task does not own its uncommitted implementation or its Reviewer.
  • No main merge, push, deployment, real paid model call, new subagent or worktree cleanup.

Intent And Constraints

  • Concurrent Task Gate and Planning Gate Passed on initial design and implementation resume; official start/status confirmed this task's feature ownership.
  • Refreshed 128 peer records, read only their task records; consultation-scope client task is read-only diagnosis. Observer code remains in a separately owned worktree.
  • Stable delivered config ID, account isolation, student payer and three readonly tools remain. Pi/project files stay project-owned.
  • Every accepted question freezes project, Pi source and released version. Switching UI never changes an accepted read scope.
  • Existing main foreign documents and unrelated worktrees remained untouched. Only this task record/proposal are changed in project memory; canonical promotion remains integration work.

Outcome

  • Main stores one account-agent chat under userData/agent-conversations//. A small message index and separate atomic turn files avoid rewriting every historical answer.
  • First question ensures the chat; repeated request IDs are idempotent, including older pages. One active manual question per account-agent. Snapshot progress/completion updates by request ID.
  • Latest 50 turns initially; older history pages remain available. SSE sends the current turn and metadata. Renderer merges delayed pages without overwriting newer streamed replies, preserves reading position while switching agents, and keeps account-agent text drafts.
  • Removed student new-topic plus and normal topic dropdown for delivered agents. Current project/source are shown. Cross-project/Pi references block sending until removed or the source is reopened; old reply actions cannot target another Pi session.
  • Contacts retain distinct unread state; read position is persisted in Main. Last selected disabled agent can reopen readonly history. Loaded-page/scroll cache is window-local; durable messages and read receipts survive restart.
  • Next question uses the current released definition. Same project/Pi/version reuses its internal thread; changing any starts an internal segment carrying bounded public history. Old imported cloud questions retain original cloudRequestId for cancellation.
  • Readonly conversation tool can retrieve older completed chat messages by ID through the frozen index without loading all bodies each question; prior-project message text does not grant prior-project file access.
  • Legacy topics are imported only on proven account/config identity, deduplicated by project/topic/request origin, and original files are retained. Body-before-index interruption recovers without duplicate import, including retry in the same process. Missing project directories can be retried later. Historical project and source topics, including unassigned/friend records, remain readonly via the old-records endpoint.
  • Discussion state is per project inside the chat; imported old cards retain their turn snapshots and newest project card. Legacy originals remain separately viewable.
  • README updated for the implemented client behavior. Accepted teacher ADR/domain/architecture changes are proposed, not promoted.

Verification

  • Relevant unit suite: 12 files, 365 tests passed. Includes Store/Service/actual HTTP + SSE/paging/legacy source archive/account isolation/concurrent duplicate acceptance/versions/Pi switching/frozen file roots/older message tool reads/import failure recovery/read receipts/UI delayed pages/old-record readonly/disabled history/independent agent drafts.
  • pnpm run typecheck: passed.
  • Focused ESLint over every changed TS/TSX file and new files: passed.
  • pnpm run build:vite: passed; existing chunk-size/dynamic-import/Browserslist warnings retained.
  • Real Electron test with deterministic Host fixtures: project consultations preserve student drafts and switch between work and chat without submitting advice, 1/1 passed. Screenshot manually inspected: topbar agents, one chat, no new-topic plus/select, project label, separate drafts, work tab preserved. Not a live cloud/model acceptance claim.
  • Expanded Main tsc: 66 diagnostics. Temporarily replayed original committed source inside this owned worktree under try/finally restoration; baseline also has the same 66 diagnostics (line positions normalized). No new diagnostics, but global Main typecheck is not clean.
  • Reproduced existing coding-teacher.test tool activity ID failure on original base: test expected parent run ID, existing implementation uses stable context/request ID. Corrected that assertion to the existing contract; the full related suite then passed.
  • No dependency lock/package change. Build output, local reports, runtimes and temporary checks are ignored and not committed.

Coordination And Integration Dependency

  • Authorized messages sent to existing thread 01a0dc9a-9b4e-7fa3-bb19-aea80abaaac4, task 20260928-agent-observer-design-9c41a872.
  • That task confirmed its Main suggestion contract in its own record: stable suggestion ID survives replacements; state.json is durably saved before advice delivery. Use projectId + suggestion.id for idempotent delivery; do not call sendConversation to invent a student message.
  • Actual manual APIs: GET /api/coding/agent-conversations/:agentId?before=...; POST /messages; /seen; /discussion; /save; /requests/:id/cancel; GET /events. service.conversation(agentId,before?) and service.sendConversation(agentId,input) own the unique chat.
  • Observer review was still in progress at this handoff; no observer code is in this branch. The combined integration MUST replace its discussObservation project-topic creation with inserting/opening this chat, plus delivery replay/read receipts. Its independent observation thread and Main project scheduler remain separate. Do not claim automatic advice has already been wired or combine branches without this adaptation and joint tests.
  • Observer coordinator source inspection confirmed Yuxi scope binds both project and Pi source, and native YuxiSummarizationMiddleware exists. This justified Pi-aware segment rotation; neither cloud deployment nor compression quality was independently exercised here.

Follow-ups

  • User-requested main merge is not yet authorized for this implementation.
  • During integration reconcile observer suggestions as above, and promote the approved account-agent/per-turn semantics; retain unrelated docs.
  • Validate configured Yuxi deployment against current client; no real cloud/paid-model run occurred. Cross-device history synchronization is outside this increment.
  • Retained worktree belongs to this completed feature; no cleanup requested.

Promotion Candidates

  • Targets: ADR-2026-09-22-coding-teacher.md, system-overview.md, data-flow.md, business-rules.md and current state.
  • Proposal: replace visible project/version topic identity with account-agent chat; bind project/Pi/version to individual execution turns; account-agent drafts/read receipts, paged files/index, retained source archives.
  • Evidence: approved user request, implementation, 365 related tests, Electron UI and cloud request contract tests.
  • Future impact: history lifecycle, cloud scope rotation/summary, old-context actions, observation delivery.
  • Semantic conflicts: accepted project-topic/version policy is intentionally revised by user approval; observer project-topic creation must be adapted at joint integration.
  • Human confirmation: single-chat direction and implementation approved. Main merge/deployment require their own corresponding user request.