[tsapeta]

Why

With inline comments on, each finding on a diff line appears twice: once as an inline thread, and again in the main comment as a short entry with the title, location, id and the first 160 characters of the rationale. The reader sees the same finding twice (for example expo/expo#52187).

Change

• The main comment no longer lists a finding that has a live inline thread. Under 💬 Inline comments on the diff (n) it shows one row per severity with each finding's id:, linked to its thread, and a link to a reply when an author answered. The id stays visible because /dismiss takes it, and /dismiss is an issue comment, not a thread reply.
• Severity headings count only the findings listed under them. A finding without a live thread (outside the diff, over maxComments, a failed link, or a stubbed thread) is listed in full.
• /dismiss and /undismiss read the inline threads before they re-render, so a dismissal doesn't bring the full list back. Before, they rendered without the thread links. /undismiss restores a stubbed thread before the render and links it only when the restore succeeded.
• In the aggregate comment, the size cap trims inlined and listed findings on separate limits, inlined first, and both down to 3 per scope as before. A trimmed inlined finding keeps its thread on the PR, while a listed one appears nowhere else. Inlined findings stay trimmable because each still carries its full text in the embedded state.
• The embedded state still keeps every finding, so dismissals, reply matching and inline sync are unchanged.
• The short form and oneLineRationale are removed. Its "audit trail" reason no longer holds: the author can't edit or delete the bot's inline comment, and a resolved thread stays on the PR.
• LLP 0008 ("Inline Threads"), README, templates/config.jsonc, the inline schema comment and PLAN-inline-comments.md describe the new rendering.

Test Plan

bun test (887 pass), typecheck, lint, fmt:check and llp:check pass. New tests:

• single comment: an inlined and a listed finding, every finding inlined, and an inlined finding with a reply
• aggregate: a named scope's scoped ids, a scope with only inlined findings, truncation with 30 inlined and 10 large listed findings, and truncation with 20 large inlined and 10 listed findings
• aggregate: a scope with only inlined findings next to an oversized scope keeps 3 of them in the comment and the state, and drops its input hash
• applyDismissal through a fake gh: a live thread is linked by id and a stubbed one stays listed; /undismiss restores the thread before the main comment; a failed restore stays listed; a failed thread listing renders everything in full; an aggregate dismissal with scoped ids

The truncation and applyDismissal tests fail on the commits before their fixes, and the single-comment tests fail on main.

[github-actions]

🤖 AI code review

Decision: Ready for human review

Overall PR risk: Medium. This change modifies how inline findings render in the main comment, replacing full duplicate entries with linked id rows and adding a second trim limit for inlined findings. The aggregate size cap, dismissal logic, and /undismiss thread restoration could affect scope counts, the 'No findings.' text, and /dismiss id availability when findings are trimmed. The impact is limited to repositories with inline.enabled (off by default), and a revert rolls it back directly without affecting the embedded state format.

🔎 Reviewer summaries (3)

• consistency: I checked the inline id rows, the aggregate size cap, and the /dismiss thread links against the existing patterns in the repo. They match the sibling conventions. The earlier "No findings." concern is fixed because the trim keeps at least 3 inlined findings.
• correctness: I checked the id-row rendering, the aggregate size cap with its separate inlined limit, and the /dismiss and /undismiss thread reads before the render. I found no defects. The earlier "No findings." issue is fixed by the floor of 3.
• security: I reviewed the inline id rows, the aggregate trim, and the /dismiss thread read for security risks. The rendered ids are hex hashes, the thread URLs pass the github.com check, and only the bot's own comments supply links. I found no security issue.

🔗 Review setup:

• This PR changes code the reviewer prompts cite (src/tests, src/config/schema.ts, src/core/render.ts, templates/config.jsonc). Check that the guidance quoting it is still correct.

No findings.

---

This review is advisory — it never blocks a merge and never auto-approves.