Bound document-reviewer reruns to the received findings

[shinpr]

Summary

A document-reviewer correction re-review (a rerun with prior_feedback) could turn into a second full review. Gaps that the initial review missed came back as new findings, and each one started another correction cycle. That breaks the convergence model, where the initial review reports everything and a rerun only confirms that the corrections are right.

This PR closes the rerun scope in agents/document-reviewer.md by rewording existing rules. It adds no new mechanism.

Cause

• The rerun rule, "re-check only the affected boundary and dependent consistency while confirming required safeguards still exist", set no limit on the rerun scope. Any unchanged section could count as "dependent".
• The output contract said reruns "also include" prior_feedback_reconciliation, so reruns still returned issues, and the verdict still came from issues.
• The other reconciliation reviewers already bound their reruns: code-reviewer ("The received findings and their changed boundaries define this re-review"), and code-verifier and design-sync ("only when the correction caused it"). document-reviewer was left out of those changes.

Changes (agents/document-reviewer.md, three sentences replaced)

• Rerun scope: The rerun scope is now the received items and the boundaries their corrections changed. The open-ended "dependent consistency" and "safeguards" phrases are removed. Regression detection stays: an applied item is resolved only when the changed boundary is still valid.
• Verdict: Derived only from the reconciliation entries, as in code-reviewer.
• Output: Reruns return prior_feedback_reconciliation in place of issues.
• Completion Check: The first item now covers both initial reviews and reruns. It no longer requires a full requirement-to-design mapping on every run.

Also included: the patch version is bumped to 0.27.3, and the plugin copies are synced.

Considered and not changed

• Review Resolution Verdict Gate (review-resolution.md): Adding "initial" looked needed, so that a rerun result without issues would not be read as complete. In testing, the existing sections 2 and 3 already routed rerun results correctly (6/6), so the change was dropped.
• Recipe reviewer prompts: These still reuse the initial review focus on reruns. With no issues channel on reruns, that focus can no longer produce new correction work, so the recipes are unchanged.

Verification

I tested with claude -p, using --plugin-dir and --agent dev-workflows:document-reviewer, on a synthetic repository. Its work plan had one applied finding (a verification command that could not run, now corrected) and a separate, pre-existing verification gap in a later phase that the correction did not touch. I compared the main and branch versions, 3 runs each:

Scenario	main	This branch
Correction is valid	3/3 raised a new finding on the unrelated later-phase gap	3/3 pass, finding resolved, no new findings
Correction introduced a regression (calls a script that does not exist)	3/3 caught the regression; 2/3 also raised the unrelated gap	3/3 caught the regression as maintained; no new findings

In two main runs, the new finding also reused an ID that was already in prior_feedback.

Orchestrator routing under review-resolution.md, 3 runs each for main and the rejected variant:

Scenario	Both versions
Rerun result with an extra issue plus a resolved entry	Converged; the extra issue was not routed
Rerun result with only a maintained apply entry	Routed back to the author

claude plugin validate passes for the marketplace and all plugins.

🤖 Generated with Claude Code