docs: diagnose stale Coding foreground state

This commit is contained in:
inman
2026-09-02 14:17:00 +08:00
parent 774beee508
commit 301c1496b0

View File

@@ -0,0 +1,84 @@
# Task: Check latest session after Bash fix
## Identity
- Task ID: 20260902-check-session-after-bash-fix-a6d12f39
- Mode: Feature
- Branch: main
- Worktree: /Users/inmanx/Documents/makelore
- Base commit: 774beee50867b1da3a25fda8fbff559f570d4e56
- Owner: codex
- Status: Completed
## Scope
- Determine whether the newest visible Makelore Code turn after the write-leased
Bash batch fix is still making useful progress or is functionally stuck.
- Correlate the live UI with the target Pi JSONL timeline, Electron/Agent Server
logs, process activity, child processes, and sockets.
- Keep the diagnosis read-only: do not abort, recover, resend, or otherwise
mutate the current Conversation or project files.
## Intent And Constraints
- Distinguish normal model/tool latency from the previously fixed prepare-all
write-lease self-deadlock and from a missing terminal-settlement handshake.
- Treat the visible timer, model response, tool start/result, child-process
activity, and terminal settlement as separate evidence.
- Do not expose credentials, unrelated account data, or unrelated project
content in the task record or user-facing conclusion.
## Outcome
- Confirmed a user-visible stale-running state in project `肉鸽小游戏`, Agent
`小小明`, Conversation `新对话`. The UI advanced from 55 to 58 minutes of
processing and continued to show one `uv pip install` Bash call as executing.
- Confirmed that the displayed Bash call was not running or deadlocked. Its Pi
JSONL tool call began at 13:13:12 local time and recorded a successful result
at 13:13:33 with `requests` and `Pillow` installed. Later Bash and task-state
tools also succeeded, and Pi persisted the final assistant `stop` response at
13:14:42.
- Electron Main stopped both idle logical workers and the parent Agent Server at
13:14:55 with the intentional `background_sleep` reason. At inspection time
there was no Agent Server, Bash, `uv`, `tail`, or skill virtual-environment
child process, and the session JSONL had not changed since the final response.
- This is not a recurrence of the prepare-all write-lease deadlock. The durable
work completed; the Renderer retained a stale live Snapshot after background
sleep and continued animating an earlier tool call.
- The likely foreground-recovery gap is supported directly by the current code:
Main sends `lifecycle:sleep`, but the Renderer has no subscriber that invalidates
or refreshes Coding state. `selectConversation` also skips `getSnapshot` when
its cached entry remains `live`, so refocusing the existing window does not
hydrate the already-persisted final response.
- No UI action, Conversation mutation, process stop, retry, project-file change,
or source-code change was performed during diagnosis.
## Verification
- Read the live Electron accessibility tree twice without clicking or typing;
the timer increased while the same earlier Bash call remained focused.
- Correlated the exact target JSONL timeline with the current UI. The displayed
120-second Bash call settled successfully in about 21 seconds, later tool
results succeeded, and the final assistant response has `stopReason: stop`.
- Correlated Main logs showing the final Provider stream at 13:14:42 and the
intentional `background_sleep` worker/Agent Server shutdown at 13:14:55.
- Inspected the live process table and target Agent Server PID; no runtime or
shell child remained while the UI reported processing.
- Inspected the Renderer store and lifecycle wiring: `lifecycle:sleep` is exposed
but not consumed, and a cached `live` Conversation bypasses Snapshot loading.
## Follow-ups
- If implementation is requested, invalidate/disconnect Coding event state on
`lifecycle:sleep` and force a target Snapshot refresh when the programming
window becomes visible again. Cover hidden-run completion, idle runtime sleep,
second-instance focus, persisted final hydration, and no accepted-mutation
replay in focused Renderer/Main tests.
- Immediate non-destructive recovery is to reload/restart the Renderer so it
hydrates the persisted final response. Do not rerun dependency installation;
that work already succeeded.
## Promotion Candidates
- None yet. Promote the foreground rehydration contract only after a focused fix
and regression tests are implemented and integrated.