This is a comment left during a code review.
Path: ui/src/ui/app-render.ts
Line: 642-649

Comment:
`agentId` parameter ignored for content reload

`loadAgentFiles` is called with the `agentId` parameter, but the subsequent `loadAgentFileContent` call uses `resolvedAgentId` from the outer closure instead. If `agentId !== resolvedAgentId` (e.g., when reloading files for a non-active agent), the file list and its content would be fetched for two different agents, potentially displaying stale or mismatched content.

```suggestion
                onLoadFiles: async (agentId) => {
                  await loadAgentFiles(state, agentId);
                  if (state.agentFileActive && agentId) {
                    await loadAgentFileContent(state, agentId, state.agentFileActive, {
                      force: true,
                    });
                  }
                },
```

How can I resolve this? If you propose a fix, please make it concise.

This is a comment left during a code review.
Path: extensions/llm-task/src/llm-task-tool.ts
Line: 77-91

Comment:
`input` and `schema` type narrowing breaks non-object callers

Both `input` and `schema` were changed from `Type.Unknown` to `Type.Object({}, { additionalProperties: true })`. TypeBox's `Type.Object` only accepts plain JavaScript objects — it rejects arrays and primitives at the MCP validation layer.

The `execute` handler at line 174 (`const input = (params as any).input as unknown`) and line 177 (`JSON.stringify(input ?? null, ...)`) are perfectly capable of handling any JSON-serialisable value, including arrays (e.g. `input: [1, 2, 3]`). The schema change creates a silent inconsistency: callers that were previously accepted (passing an array as `input`) will now fail validation before reaching `execute`.

Similarly, `schema` validation at line 234 explicitly guards `!Array.isArray(schema)` before using it, implying that non-object values were always expected to be possible.

Consider restoring `Type.Unknown` for `input`, or at least using `Type.Union([Type.Object({}, { additionalProperties: true }), Type.Array(Type.Unknown())])` if only arrays + objects need to be supported.

How can I resolve this? If you propose a fix, please make it concise.

This is a comment left during a code review.
Path: src/agents/pi-embedded-subscribe.handlers.messages.ts
Line: 76-87

Comment:
Late `handleMessageEnd` can clobber the separator written here

`ctx.state.deltaBuffer` is set to `"\n\n"` (and `ctx.blockChunker.append("\n\n")` is called) after the reset. However, `handleMessageEnd` for the *previous* message (lines 430–432) unconditionally resets these same fields:

```ts
ctx.state.deltaBuffer = "";
ctx.state.blockBuffer = "";
ctx.blockChunker?.reset();
```

The existing comment in this file explicitly notes that providers may deliver late `text_end` (and by extension `message_end`) events *after* `message_start` for the next turn. If `handleMessageEnd` fires after the separator is written here, the `"\n\n"` separator is silently lost and the original text-concatenation bug (#35308) reappears.

Consider tracking a "separator pending" flag on `ctx.state` that `handleMessageEnd` respects, or guard the `handleMessageEnd` reset so it does not overwrite state that belongs to a newer message (e.g. only clear `deltaBuffer` if it does not equal `"\n\n"`, or check `ctx.state.assistantTexts.length` against the baseline).

How can I resolve this? If you propose a fix, please make it concise.