← graph

fix-last-interaction

Fix: last_interaction_at not updated on TUI chat typing (fix-chat-tasks missed the actual user flow)

Metadata

Statusdone
Assignedagent-2281
Agent identityf51439356729d112a6c404803d88015d5b44832c6c584c62b96732b63c2b0c7e
Modelcodex:gpt-5.5
Created2026-05-04T14:59:13.810118068+00:00
Started2026-05-04T15:00:22.126231066+00:00
Completed2026-05-04T15:21:54.207424506+00:00
Tagspriority-high,fix,bug,tui,sort,chat, eval-scheduled
Eval score0.77
└ blocking impact0.85
└ completeness0.90
└ constraint fidelity0.85
└ coordination overhead0.90
└ correctness0.85
└ downstream usability0.85
└ efficiency0.80
└ intent fidelity0.68
└ style adherence0.85

Description

Description

fix-chat-tasks (commit 6a3fc523e) wrote the last_interaction_at field and wired the wg chat send CLI path to update it. But the actual user flow (typing in a TUI chat tab) does NOT update the field.

User report 2026-05-04: '.chat-27 still not sorting at the top even though we talking in that one' ... 'the fix was clearly not tested'

Hard evidence:

$ grep chat-27 .wg/graph.jsonl | tail -1
  last_interaction_at: 2026-05-04T02:28:38   ← over 12h before user observed bug

User has been actively chatting in .chat-27 the whole session; the field is frozen.

Root cause hypothesis

fix-chat-tasks only added the bump in CLI command paths (wg chat send, possibly wg log). It did NOT add the bump on:

  • Keystroke typed in chat tab → message sent through TUI's chat-input handler
  • Agent response appended to chat history (chat history append event)
  • Maybe other interaction types (state transitions, etc.)

Required fix

Find ALL the interaction sites and ensure they ALL bump last_interaction_at:

  1. TUI chat tab user-typed-message handler — wherever the chat input is committed
  2. Chat history append (agent's response written to JSONL) — both directions of conversation should count
  3. Worker agent activity / heartbeat (debounced — don't trigger constant re-sort, per the recurring perf concern)
  4. State transitions (already wired probably; verify)
  5. wg log entries (already wired probably; verify)

Use ONE central helper that wraps any task mutation with timestamp-bump (per the original revert-redo-fix design). If the helper exists, audit ALL mutation paths and ensure they go through it. If sites bypass the helper, that's the bug.

Validation — STRICT live test

The validation rubric for fix-chat-tasks was inadequate. This task requires:

  • Failing test written first: simulate user-typed message in TUI chat tab; assert last_interaction_at on that chat task updates
  • LIVE smoke against the user's actual flow: wg tui → click into an existing chat tab → type and send a message. ASSERT last_interaction_at on that chat updates within 5 seconds. Capture the BEFORE timestamp, the typing event, the AFTER timestamp; paste evidence.
  • Same test for agent response append (the chat reply that arrives) — receiving a reply should ALSO bump last_interaction_at
  • Sort behavior: the user-active chat bubbles to top of its status group within 5s of typing
  • No regression of existing wired paths (wg chat send, etc.)
  • No regression of revert-redo-fix's sort-stability + render-debounce work
  • cargo build + cargo test pass
  • cargo install --path . was run before claiming done — and binary timestamp verified
  • Call wg done at completion

Process note

This is the SECOND time fix-chat-tasks-class work has shipped without testing the actual user flow. The pattern: 'CLI command paths exist and tests pass' → 'shipped' → 'user observes the user-flow path is unfixed.' Worth a deeper look at why the agent's validation rubric was self-referential (testing only the paths the agent thought of, not the user flow).

Suggest amending the doc-sync function template OR a separate process improvement: any 'user-visible behavior' fix MUST validate via live human-flow simulation, not just CLI invocation paths.

Depends on

Required by

Log