github_review_threads caps each thread body at 1000 chars of mostly CodeRabbit boilerplate, and no tool reads one thread in full #63

Problem

On protoLabsAI/protoAgent#4770, both CodeRabbit threads came back cut off inside their "Script executed" preamble, before any finding text. No github_* tool takes a thread_id and returns the full body, and github_issue_comments only covers top-level comments. So the agent had to drop to gh api …/pulls/N/comments, which needed approval. Source: protoEngineer friction edfc7442 (2026-11-06), found in the fleet friction triage on 2026-11-07.

Evidence

read_tools.py github_review_threads:

body = " ".join(str(first.get("body") or "").split())
if len(body) > _MAX_COMMENT_CHARS:          # 1000
    body = body[: _MAX_COMMENT_CHARS - 1] + "…"

The cap is applied to the raw markdown. CodeRabbit bodies open with <details> / HTML-comment / "Script executed" blocks that often run past 1000 chars, so the finding itself is always cut.

Steps to reproduce

1. Get a review thread whose first comment is 1500 chars of <details><summary>🧩 Analysis chain</summary>…</details> followed by the finding text.
2. Call github_review_threads: the output ends in … before the finding.

Expected vs actual

• Expected: the finding text is visible.
• Actual: only boilerplate is shown.

Proposed direction

• Strip <details>…</details> blocks and HTML comments before applying the cap. Keep the first line of a <summary> if it's useful.
• Add body_max_chars (default 1000, max ~8000), or a github_get_thread(thread_id) that returns every comment in one thread in full, boilerplate stripped.