fix: keep follow-up reviews from repeating open findings

[frostming]

Purpose

After a new commit, Landing's automatic review posted inline comments that repeated findings already raised in open review threads. Each CI run starts from an empty SQLite database, so the agent has no model history of earlier reviews, and the review guidance never asked it to read the PR's existing threads.

The review guidance now has the agent read existing review threads, including resolved and outdated state, before publishing. It comments inline only on new findings, refers to still-applicable open findings from the review body by link, replies in a thread only when the candidate changes its conclusion or location, and keeps resolved threads settled unless new evidence changes them. The GitHub guide describes this behavior.

The long GitHub guidance constants are also wrapped with implicit string concatenation; their rendered text is byte-for-byte unchanged.

Validation

• uv run ty check: passed.

• uv run pre-commit run --all-files: passed.

• uv run python -m pytest tests/test_github.py: 32 passed.

• make docs-test: no issues.

• Compared every *_GUIDANCE constant before and after wrapping: identical.

• tests/test_mcp.py::test_cancellation_closes_mcp_subprocess failed once on ubuntu/3.12 with JSONDecodeError: the fixture MCP server creates its receipt before writing the record, so the test could read an empty file. The test now waits for the complete record; it passed in five consecutive local runs.

This changes prompt guidance only, so no test asserts its wording. Whether follow-up reviews actually stop repeating findings still needs observation on a real PR with an open Landing finding and a later commit.

AI assistance

Implemented with Claude Code (Claude Opus 5.5, claude-opus-5-5[1m]).

🤖 Generated with Claude Code

[github-actions]

No blocking findings.

The guidance change stays inside the review path it describes: REVIEW_GUIDANCE renders only when no thread reply is required (expected_review requires not thread), so the new "reply in that thread only when…" sentence cannot override the confirmed-reply contract for thread follow-ups, and the existing-thread step is reachable with the prepared gh CLI. Comparing every *_GUIDANCE constant between e4fc599 and c6bae1b shows only REVIEW_GUIDANCE changed, so the wrapping claim holds.

The failing native leg is unrelated to this candidate. tests-and-type-check (ubuntu-latest, 3.12) failed in tests/test_mcp.py::test_cancellation_closes_mcp_subprocess: the test waits for the receipt file to exist and then parses it (tests/test_mcp.py:172-174), while the fixture server creates that file with open("a") before writing its JSON (tests/test_mcp.py:37-40), so an empty read is possible on the base revision too. This candidate changes two prompt-string files and one documentation sentence, does not touch that test or MCP execution, and the other three matrix legs plus a local five-run replay of the single test passed. Treat it as a separate follow-up if it recurs.

[github-actions]

No blocking findings.

The only change since the previous review at c6bae1b is the receipt wait in tests/test_mcp.py, which repairs the flake that pass reported as a separate follow-up. tests-and-type-check passes on all four legs of run 37561856275 covering this head, and the single test passed on the merge checkout here. Waiting for a line terminator, rather than file creation, still requires a complete record and leaves the cancellation and process-exit assertions intact.

The review guidance added in c6bae1b is byte-identical at this head, so the earlier verification of its rendered text and of the review-only delivery path still applies. Whether the new instructions reduce repeated findings is only observable on a later review of a PR with an open Landing thread; that is not a blocking acceptance condition.