Assistant/Agent cannot read a comment

[ericvicenti]

Assistant/Agent cannot read a comment. Apparently it can only read documents

[ericvicenti]

@ion-lion this is about the built in assistant/agent in the desktop app. can you review the tool calls that it has, and make sure that it can pass a comment ID into the read tool?

[ion-lion]

I reviewed the desktop assistant tool calls and opened a fix: #576

The read tool can now accept commentId directly (record ID or version CID) without needing a document URL, and it reads the comment through the existing Comments gRPC getComment endpoint. I also kept the existing document comments flow working when both url and commentId are provided.

Validation: corepack pnpm --filter @shm/desktop run typecheck passes. Full workspace typecheck was attempted but the shared package typecheck process was killed with exit 137 in this environment.

[horacioh]

🌱 Germinator triage

Root cause hypothesis: The desktop assistant's read tool only accepts a url parameter — it has no commentId input, so the assistant cannot read a comment by its record ID or version CID directly. The underlying readComments function already supports commentId filtering, but the tool's JSON schema never exposes it to the AI.

Likely files:

• frontend/apps/desktop/src/app-chat.ts:630 — read tool's inputSchema only declares url; no commentId property exists. The AI has no way to pass a comment identifier.
• frontend/apps/desktop/src/app-chat.ts:443 — readComments(id, commentId?) already accepts and filters by commentId, so the backend plumbing is ready — the front door is just missing.
• frontend/apps/desktop/src/app-chat.ts:651 — calls readComments(id, viewArg) where viewArg can carry a commentId extracted from URL view terms only (hm://.../:comments/<id>). No direct-path code path exists.

Reproduction steps (expanded):

1. Open the desktop app and start an assistant chat session.
2. Ask the assistant: "Read comment z6MkAuthor/tsid123."
3. Observe that the assistant either errors out or attempts to read the entire document — it never retrieves the specific comment because the read tool has no commentId parameter to forward.

Plausible fix sketch:
Add an optional commentId property to the read tool's inputSchema (string, describing record ID or version CID format). In the execute handler, when commentId is provided without a url, resolve it via the existing grpcClient.comments.getComment endpoint (already available in request-cache.ts:32). When both commentId and url are provided, pass commentId to the existing readComments(id, commentId) call to filter results. This matches the approach in open PR #576 (fix(desktop): let assistant read comments by id).

Severity: medium

---

A maintainer can comment /fix to have Gardener attempt this fix on a bot/fix-555 branch.

[ion-lion]

Noted. One update since my earlier comment: after Eric’s review on #576, I changed the approach away from adding a separate commentId tool parameter.

The current PR keeps the assistant read tool URL-only and supports canonical comment URLs instead:

• <DOC_URL>/:comments/<COMMENT_ID>
• <DOC_URL>?panel=comments/<COMMENT_ID>

Those comment URLs are routed through the same Resource read API path as documents, aligned with the CLI/read API direction.