docs(review): drop praise from approve summaries, print inline text at the gate

An approve summary now carries no praise, not even a bare positive like "Clean." or "Solid fix." Lead with the substantive pointer (the design note pinned inline) and close with the verdict. This removes the bare-positive carve-out from review-code's Posted Summary Voice and from voice pattern #40, and updates the worked examples.

The review gate must also print the full prose of every inline comment, never a description of it. The exact words post under my name, so I have to see them before I approve. Made explicit in review-code Phase 5 and commits.md Shape 1.

From a DeepSat review session where I approved "One design note inline, not a blocker. Approving."

1 files changed, 3 insertions, 3 deletions

diff --git a/voice/SKILL.md b/voice/SKILL.md
index 4690b97..19eb38b 100644
--- a/voice/SKILL.md
+++ b/voice/SKILL.md
@@ -44,9 +44,9 @@ Terse is a budget, not an adjective. Each publish-artifact type has a target sha
 |----------|--------|
 | Commit body | Skip entirely when the subject line carries the change. Otherwise short paragraphs: the constraint, bug, or tradeoff. No play-by-play. |
 | PR description | Problem / Fix / Why / Testing, each section tight. |
-| PR review summary | One long sentence or a few short ones. Verdict closes it. Verdict formulas ("Approving.", "Requesting changes.") are valid sentences here. |
+| PR review summary | Lead with the substantive pointer, verdict closes it. No praise, not even a bare positive (#40). Verdict formulas ("Approving.", "Requesting changes.") are valid sentences here. |
 | Inline pin (finding) | ~4 sentences in stems shape (#42): where the bug is, the fix, why it's better. |
-| Praise comment | One sentence naming what's good. Nothing else (#40). |
+| Praise comment (inline only) | One sentence naming what's good. Nothing else (#40). Never in the summary body. |
 | Follow-up approval after prior feedback was addressed | Exactly "Approved." |
 
 ## Your Task
@@ -348,7 +348,7 @@ See `voice/references/voice-profile.org` §39 for problem, basis, examples, and
 
 ### 40. Praise vs Correction Asymmetry [personal]
 
-**Rule.** Praise on a PR review is short and unjustified (the author knows why their good change is good). Correction always explains the why, gently and briefly, the way a mentor would. Never as a verdict from on high. **Verification narration is the same defect as justified praise:** "I traced X and it's safe because..." pads the compliment with the reviewer's homework. Tracing the code is the reviewer's job, not content for the comment — if verification found a problem, the problem gets the words; if it found nothing, it gets zero words.
+**Rule.** Praise on a PR review is short and unjustified (the author knows why their good change is good). Correction always explains the why, gently and briefly, the way a mentor would. Never as a verdict from on high. **Verification narration is the same defect as justified praise:** "I traced X and it's safe because..." pads the compliment with the reviewer's homework. Tracing the code is the reviewer's job, not content for the comment — if verification found a problem, the problem gets the words; if it found nothing, it gets zero words. **An approve summary carries no praise at all** — not even a bare positive ("Clean.", "Solid fix."). Lead the summary with the substantive pointer (the design note pinned inline) and close with the verdict: "One design note inline, not a blocker. Approving." An approve with nothing to flag is just "Approving." Short unjustified praise survives only as an inline pin on the line it refers to, never in the summary body.
 
 See `voice/references/voice-profile.org` §40 for problem, basis, examples, and history.