docs(qa): mandate clickable refs, [~] mentions, and explicit F1.5

skills/peer-qa-review/references/checklist.md

@@ -19,6 +19,8 @@ All checks, organised by pillar. Apply the severity in the rightmost column when
 
 Note F1: "acceptance criteria absent" is the one finding you should bounce on without going further. Without criteria, there is no testable bar.
 
+Note F1.5: **record F1.5 explicitly in the Formal section of every QA comment, even when it passes `(/)`.** It is the check most often skipped silently — a reviewer confirms F1 (criteria exist) and moves on without ever asking whether the *summary and description still match what was delivered and whether the scope held*. A silently-skipped currency check reads as "verified" when it wasn't. State the verdict as a bullet (per `comment-template.md` formatting): `* (/) F1.5: summary + description current, scope held`, or the drift finding. If your review is fanned out across sub-agents, require the F1.5 line in each one's output so it cannot be dropped.
+
 Note F4a: don't conflate "mentioned in description prose" with "linked via issue-link feature". A common self-deception is reading the description, seeing `INV-146`, and assuming it must be linked. **Always verify against the actual issue-link list** (Jira: `Issue Links` section / API `issuelinks` array). If a related ticket is mentioned in prose but not linked, that's a `(!)` — and an easy fix (add the link).
 
 Note F4a (reviewer-side): apply the same rule to *your own* QA comment. Every ticket key, MR/PR URL, commit hash, runbook page, or vault entry you mention as a reviewer should also exist as a structural link on the ticket. If the QA comment introduces a *new* reference — typical case: "filed follow-up as NEW-TICKET", "see MR !N", "fixed by commit abc123" — create the structural link (issue link for tickets, web link for external URLs) *before* posting the comment, not after. The inline mention is for narrative; the link is the relationship that survives someone navigating in from the *other* side. Anti-pattern caught the hard way: QA comments referencing a follow-up ticket only inline, leaving the navigation one-way.

skills/peer-qa-review/references/comment-template.md

@@ -140,10 +140,12 @@ Re-read your own comment before clicking *Add*. Common self-introduced bugs:
 1. **Severity inconsistency** — declaring "all must-haves pass" while a `(x)` is present elsewhere. Scan for `(x)` first; if any, the verdict must be Bounce or Won't-do.
 2. **Reviewer-side limitations marked `(x)`** — "I couldn't SSH" is `(!)` or `(i)`, not `(x)`. See `severity.md`.
 3. **F7 violations in your own comment** — display-text links where convention is full URLs, `{{monospace}}` for commands when convention is `{code}` blocks, Markdown leakage (`**bold**`, `# heading`).
+3a. **Bare references that don't click** — in Jira, a bare `group/project!456`, `owner/repo#123`, `pipeline 233639`, `PR 6428`, `vX.Y.Z` tag, or short commit SHA is **plain text, not a link** (Jira only auto-links its own issue keys). Every such reference MUST be wrapped as a `[shorthand|url]` macro (see "Link conventions") so it is clickable — the shorthand stays the readable anchor. Scan the whole comment, not just the F4b line; refs recur in R, G, I, D findings too. The single most common miss in machine-generated QA comments.
+3b. **Person named in plain text instead of mentioned** — every person you name (implementer, reviewer, approver, changelog author) MUST be a `[~username]` mention, never a plain display name like "Björn Marten" or a bare first name. This includes the **customer-handover greeting** ("Hallo [~michael.kunze]", not "Hallo Michael"). A mention notifies the person and links their profile; a plain name does neither.
 4. **Transition-name vs verdict mismatch** — the verdict's *meaning* and the *literal transition name* must agree (see above).
 5. **Pillar P claims vs actual content** — if your P-pillar says "comments use `{code}` blocks" while your comment uses `{{monospace}}` for commands, that's the very contradiction the runbook is meant to prevent.
 6. **Link audit on your own references** — every issue key, MR/PR, commit, or external URL you introduce must also exist as a structural link (issue link or web link), not just inline. See F4a (reviewer-side). *Anti-pattern:* "filed as NEW-TICKET" without the link.
-7. **Unescaped block-markup tags in prose** — writing *about* `{code}` (or `{noformat}`, `{quote}`, `{panel}`) opens a real block right there in the rendered comment and swallows the rest of the line. These tags are block markup; any inline occurrence in prose is a smell. Escape as `\{code\}` when you mean the literal tag.
+7. **Unescaped block-markup tags in prose** — writing *about* `{code}` (or `{noformat}`, `{quote}`, `{panel}`) opens a real block right there in the rendered comment and swallows the rest of the line. These tags are block markup; any inline occurrence in prose is a smell. Escape as `\{code\}` when you mean the literal tag. This applies equally to **machine-/sub-agent-generated** comments — escape literal block tags at generation time; a comment that says "commands go in `{code}` blocks" is the classic offender and the wiki-markup linter will reject it on post.
 8. **Attachment mentioned but not linked** — when your comment references an attached file (session log, screenshot, report), link it with `[^filename.log]` so the reader gets a one-click open. A bare filename forces a scroll-and-hunt through the attachment list.
 9. **Self-fixed findings carry paired icons** — a finding you fixed yourself during QA is written as `(!) finding — (/) fixed <how> during QA` (or with the fix as a nested `**` sub-item carrying its evidence link). Neither a bare `(/)` nor a bare `(!)` tells the whole story; see `severity.md` ("Findings fixed by the reviewer"). Every MR, commit and repo you name in the finding gets its `[shorthand|url]` link.
 10. **QA2 verdict but no customer handover** — if the verdict routes to QA2, the internal QA comment is *not* enough; a separate plain-language handover for the approver must accompany it (see § "Customer handover comment (QA2 only)"). Posting only the internal QA comment leaves the customer lost.