When updating a gadget's UI (chatting with the agent) it got to a point where the agent's changes stopped making sense and old buttons were still lying around.
Telling it to remove the old buttons it became clear that it really could not see them. I could see and edit the references to the running code on the editor and could confirm that the gadget was loading the same version, the the agent was blind to those and kept pointing at browser caching issues (which were not the problem).
I had GLM-5.2 take a stab at it and it says that the technical issue is:
«The agent's session Y.Doc is built at a pinned code version (versionLock, latched from checkpoint?.observedCodeVersion in runAgent) rather than at current mainline. When mainline advances — e.g. another chat merges changes, or the user accepts changes and keeps editing — the agent still reads files at the old version via getSessionYDoc(), so readFile returns stale content. The preview iframe correctly builds at "current" via getUiBundle()/loadGadgetWorker(), so the agent's view diverges from what the user sees.»
And it's proposed fix:
«Always build the session Y.Doc at "current" (hooks.buildYDoc("current") in getSessionYDoc) and apply the chat's own proposed changes on top during history replay, matching what the preview serves. The observedCodeVersion latching/consistency checks in the replay loops can be removed — they no longer control the build version and only throw false inconsistency errors when mainline advances between turns. versionLock is still set to the current version for stamping tool results and flushed "changes" messages; it just no longer pins the session to a stale snapshot.»
Proposed fix available here: davide@5686469#diff-0f0e6a3908bb1398e36146be849a7e8e5b8cc85d51eddeb7dee60ecc70563483
When updating a gadget's UI (chatting with the agent) it got to a point where the agent's changes stopped making sense and old buttons were still lying around.
Telling it to remove the old buttons it became clear that it really could not see them. I could see and edit the references to the running code on the editor and could confirm that the gadget was loading the same version, the the agent was blind to those and kept pointing at browser caching issues (which were not the problem).
I had GLM-5.2 take a stab at it and it says that the technical issue is:
«The agent's session Y.Doc is built at a pinned code version (versionLock, latched from checkpoint?.observedCodeVersion in runAgent) rather than at current mainline. When mainline advances — e.g. another chat merges changes, or the user accepts changes and keeps editing — the agent still reads files at the old version via getSessionYDoc(), so readFile returns stale content. The preview iframe correctly builds at "current" via getUiBundle()/loadGadgetWorker(), so the agent's view diverges from what the user sees.»
And it's proposed fix:
«Always build the session Y.Doc at "current" (hooks.buildYDoc("current") in getSessionYDoc) and apply the chat's own proposed changes on top during history replay, matching what the preview serves. The observedCodeVersion latching/consistency checks in the replay loops can be removed — they no longer control the build version and only throw false inconsistency errors when mainline advances between turns. versionLock is still set to the current version for stamping tool results and flushed "changes" messages; it just no longer pins the session to a stale snapshot.»
Proposed fix available here: davide@5686469#diff-0f0e6a3908bb1398e36146be849a7e8e5b8cc85d51eddeb7dee60ecc70563483