pi-pr-review 1.10.1 → 1.10.2

package/.release-please-manifest.json

@@ -1,3 +1,3 @@
 {
-  ".": "1.10.1"
+  ".": "1.10.2"
 }

package/CHANGELOG.md

@@ -1,5 +1,12 @@
 # Changelog
 
+## [1.10.2](https://github.com/10ego/pi-pr-review/compare/v1.10.1...v1.10.2) (2026-07-15)
+
+
+### Bug Fixes
+
+* **publish:** preserve findings with duplicate anchors ([#25](https://github.com/10ego/pi-pr-review/issues/25)) ([1df420f](https://github.com/10ego/pi-pr-review/commit/1df420f30b1dd1a74017c0442b2a880949d4b864))
+
 ## [1.10.1](https://github.com/10ego/pi-pr-review/compare/v1.10.0...v1.10.1) (2026-07-14)
 
 

package/README.md

@@ -184,7 +184,7 @@ Publishing is off by default.
 
 The extension—not the model—owns publishing. It creates one formal review with the event hardcoded to `COMMENT`; it never submits `APPROVE` or `REQUEST_CHANGES`. Before writing, it verifies the current PR head, validates inline anchors, and checks for a review of the same head by the current GitHub identity.
 
-Closed or merged PRs use a body-only review. Open PRs attach eligible P0–P3 findings as inline comments and keep nits or off-diff findings in the review body.
+Closed or merged PRs use a body-only review. Open PRs attach eligible P0–P3 findings as inline comments and keep nits or off-diff findings in the review body. When multiple findings target the same diff anchor, the first is attached inline and later findings remain in the review body so publication neither fails nor drops review content.
 
 After a review completes, you can directly ask the agent to “post the inline review” or “post it as an inline review.” The extension handles that request directly before an agent turn, selecting the latest cached review for an unnumbered request or the named PR in “publish the review for PR #123.” Only fresh interactive/RPC input can trigger this path; extension-generated, queued, or steering input cannot. The extension publishes only validated cached content, never replacement model-authored text, and never starts or reruns review agents. A direct request permits stale publication.
 

package/lib/pr-review-publish.ts

@@ -734,11 +734,20 @@ export function buildReviewSummary(review: ReviewLike, inlineComments: PublishCo
 		lines.push("### Strengths", "", ...review.strengths.map((strength) => `- ${String(strength).replace(/^\s*-\s*/, "").trim()}`), "");
 	}
 	const findings = Array.isArray(review.findings) ? review.findings : [];
-	const inlineAnchors = new Set(inlineComments.map(publishCommentAnchor));
+	const inlineAnchors = new Map<string, number>();
+	for (const comment of inlineComments) {
+		const anchor = publishCommentAnchor(comment);
+		inlineAnchors.set(anchor, (inlineAnchors.get(anchor) ?? 0) + 1);
+	}
 	const summaryFindings = findings.filter((finding) => {
 		if (!finding.code_location?.commentable || !isInlineSeverity(finding)) return true;
 		const anchor = findingAnchor(finding);
-		return !anchor || !inlineAnchors.has(anchor);
+		if (!anchor) return true;
+		const remaining = inlineAnchors.get(anchor) ?? 0;
+		if (remaining === 0) return true;
+		if (remaining === 1) inlineAnchors.delete(anchor);
+		else inlineAnchors.set(anchor, remaining - 1);
+		return false;
 	});
 	lines.push(
 		`### Findings — ${findings.length} total (${inlineComments.length} inline, ${summaryFindings.length} summary-only)`,
@@ -879,11 +888,6 @@ export function validateInlineComments(
 			continue;
 		}
 		const anchor = `${path}:${side}:${start}:${end}`;
-		if (anchors.has(anchor)) {
-			errors.push(`${label}: duplicate inline anchor`);
-			continue;
-		}
-		anchors.add(anchor);
 		const body = [`**${String(finding.title ?? "Review finding").trim()}**`, finding.body?.trim()]
 			.filter(Boolean)
 			.join("\n\n");
@@ -895,6 +899,9 @@ export function validateInlineComments(
 			errors.push(`${label}: comment body contains a reserved pi-pr-review marker`);
 			continue;
 		}
+		// GitHub receives one comment per anchor; later findings remain in the top-level summary.
+		if (anchors.has(anchor)) continue;
+		anchors.add(anchor);
 		comments.push({
 			path,
 			body,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-pr-review",
-  "version": "1.10.1",
+  "version": "1.10.2",
   "description": "Parallel AI code review for GitHub pull requests in the Pi coding agent, with model-agnostic tiered subagents, structured findings, optional verification, and safe COMMENT-only publishing.",
   "keywords": [
     "pi-package",

package/prompts/pr-review.md

@@ -194,7 +194,7 @@ The orchestrator must never call `gh` to post comments or reviews. Always finish
 - `--comment` → force publication for this run, but never bypass validation, stale-head checks, or duplicate checks
 - `--no-comment` → suppress publication for this run
 
-When enabled, the extension creates exactly one formal GitHub pull-request review. Its top-level body contains the overview, verification, strengths, suggested verdict, counts, nits, and findings that cannot be attached inline. Eligible P0–P3 diff-anchored findings are attached as inline comments within that same review and are omitted from the top-level issue list to avoid duplication. The API event is hardcoded to `COMMENT`: publication never sends `APPROVE` or `REQUEST_CHANGES`, even when the suggested verdict is `request_changes`. It appends the same-head marker, verifies the current head, validates every inline anchor against GitHub diff metadata, and refuses partial open-PR publication. For a known closed/merged PR it requires either trusted `--include-closed`/`--review-closed` invocation authority or the one-shot affirmative confirmation flow, then posts one body-only `COMMENT` review with each inline finding folded into the body exactly once. Unknown lifecycle states and unconfirmed non-open writes fail without posting or falling back to an issue comment.
+When enabled, the extension creates exactly one formal GitHub pull-request review. Its top-level body contains the overview, verification, strengths, suggested verdict, counts, nits, and findings that cannot be attached inline. Eligible P0–P3 diff-anchored findings are attached as inline comments within that same review and are omitted from the top-level issue list to avoid duplication. If multiple findings share one diff anchor, the first is attached inline and later findings remain in the top-level body instead of failing publication or dropping content. The API event is hardcoded to `COMMENT`: publication never sends `APPROVE` or `REQUEST_CHANGES`, even when the suggested verdict is `request_changes`. It appends the same-head marker, verifies the current head, validates every inline anchor against GitHub diff metadata, and refuses partial open-PR publication. For a known closed/merged PR it requires either trusted `--include-closed`/`--review-closed` invocation authority or the one-shot affirmative confirmation flow, then posts one body-only `COMMENT` review with each inline finding folded into the body exactly once. Unknown lifecycle states and unconfirmed non-open writes fail without posting or falling back to an issue comment.
 
 The extension caches the latest valid completed review per repository and PR before publication preflight in the current Pi session. The session-backed cache survives extension reloads and session resumes but is bound to the originating session instance and repository. On a later turn, the extension intercepts that direct input before an agent turn, publishes only extension-cached content, permits stale publication, and cannot rerun review agents. Stale publication is also enabled by default through the invocation-captured `allowStalePublish` setting. Every stale review is body-only, displays a warning with the reviewed and preflight-observed commit hashes, and omits potentially invalid inline anchors. If the captured setting disabled stale publication, the user can still run `/pr-review-publish <PR-NUM> --allow-stale`. Never rerun the review merely to change posting intent, and never attempt a direct GitHub write yourself.
 

package/tests/pr-review-publish.test.ts

@@ -648,6 +648,34 @@ describe("atomic COMMENT review payload", () => {
 		expect(summary).toContain("[P3] Summary-only collision");
 	});
 
+	test("summarizes additional inline findings that share an anchor", () => {
+		const colliding: ReviewLike = JSON.parse(JSON.stringify(review));
+		colliding.findings!.push({
+			title: "[P2] Preserve the second issue",
+			severity: "P2",
+			blocking: false,
+			body: "This distinct issue targets the same diff range.",
+			confidence_score: 0.85,
+			code_location: {
+				absolute_file_path: "src/parser.ts",
+				line_range: { start: 2, end: 3 },
+				side: "RIGHT",
+				commentable: true,
+			},
+		});
+
+		const validated = validateInlineComments(colliding, changedFiles);
+		expect(validated.errors).toEqual([]);
+		expect(validated.comments).toHaveLength(1);
+		expect(validated.comments[0]?.body).toContain("[P2] Handle empty input");
+
+		const summary = buildReviewSummary(colliding, validated.comments);
+		expect(summary).toContain("3 total (1 inline, 2 summary-only)");
+		expect(summary).not.toContain("#### [P2] Handle empty input");
+		expect(summary).toContain("#### [P2] Preserve the second issue");
+		expect(summary).toContain("This distinct issue targets the same diff range.");
+	});
+
 	test("rejects anchors outside changed diff metadata", () => {
 		const invalid: ReviewLike = JSON.parse(JSON.stringify(review));
 		invalid.findings![0]!.code_location!.line_range = { start: 20, end: 20 };