fix(lifecycle): stop naming a worklog command; add F3b, control-grading, identity lookup

A /retro over a Round-1 QA session found four gaps, one of them harmful.

Stage 5 handed the reviewer `jira-worklog.py add` as the way to log QA
time. On a team whose time tracker syncs its entries into Jira, that
command is the wrong end of the pipe: it double-books, the duplicate is
hard to spot because the synced entry looks identical, and the CLI
offers no matching delete. The reviewer in that session followed the
example and had to undo the booking through the REST API by hand. The
step now states the requirement — book in the system of record, find out
which one that is first — and deliberately names no command.

Three additions from the same session:

- F3b: when a session log is attached next to pasted {code} excerpts,
  reconcile the excerpt against the artefact. F3 only asked that output
  be present, so a hand-copied block passed unchecked.
- Pillar G: grade a surprising probe (404, default certificate, empty
  result) against a sibling in a known state before assigning severity.
  Without the control the same output supports both "regression" and
  "baseline", and both readings look equally confident.
- Stage -1: every row of the claim table compares the assignee to you,
  but the step never said how to resolve either value. Point at the
  identity lookup instead of leaving it to be inferred from git config
  or a credentials file.

Evals E7-E9 cover the three behaviours.

Signed-off-by: Sebastian Mendel <sebastian.mendel@netresearch.de>

Author: CybotTM

skills/peer-qa-review/evals/qa-discipline.md

@@ -110,3 +110,54 @@ superseded.
 
 **Fail signal**: reviewer flags the stale description as a `(!)` should-fix and
 resolves anyway, leaving the description contradicting what was delivered.
+
+## E7: Time booked into the wrong system of record (Stage 5)
+
+**Situation**: the team books time in a dedicated time tracker that syncs its
+entries into the ticket system. The ticket system's CLI also exposes an
+"add worklog" command.
+
+**Input**: reviewer reaches the Stage 5 "Log your QA time" step.
+
+**Expect**:
+- Reviewer establishes which system owns time *before* booking, and books there.
+- Reviewer does **not** reach for the ticket system's worklog command because it
+  is the closest tool to hand.
+
+**Fail signal**: the review is booked directly onto the ticket, duplicating the
+entry the tracker syncs in later — a double-booking that is hard to spot
+afterwards because both entries look alike.
+
+## E8: Quoted output is not reconciled with the attached log (F3b)
+
+**Situation**: the implementer pasted a `{code}` excerpt (a run recap, an exit
+code, an image digest) *and* attached the full session log it came from.
+
+**Input**: reviewer reaches the F3 evidence check.
+
+**Expect**:
+- Reviewer opens the attachment and reconciles the load-bearing values in the
+  excerpt against it, then states in the QA comment that the two agree.
+
+**Fail signal**: reviewer records F3 as `(/)` because output "is present",
+treating a hand-copied excerpt as equivalent to the artefact it was copied from.
+
+## E9: Surprising probe graded without a control (Pillar G)
+
+**Situation**: a reachability or behavioural probe returns something that looks
+wrong — a 404, a default certificate, an empty result — on the thing the ticket
+just changed.
+
+**Input**: reviewer must assign a severity to it.
+
+**Expect**:
+- Reviewer runs the identical probe against a sibling whose state is already
+  known, and grades the finding from the comparison.
+- The comparison appears in the QA comment as rows, not as the claim "behaves
+  like its peers".
+- Where the control shows the result is the baseline, it is recorded as `(i)`
+  context, not `(x)` against this ticket.
+
+**Fail signal**: reviewer either bounces the ticket on a result that is normal
+for every peer, or waves it through as "probably expected", in both cases from a
+single uncontrolled probe.

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

@@ -10,6 +10,7 @@ All checks, organised by pillar. Apply the severity in the rightmost column when
 | F1.5 | **Description currency**: does the description still accurately describe what was actually delivered? Scope shifts, emerged requirements, surfaced constraints, and important tradeoffs that came up during work should be folded back into the *description* (not buried in comments). The description is the canonical record for future readers. Concrete drift to scan for: task checkboxes still unticked for work that was completed, status/phase tables showing outdated states, and version strings the deploy has since superseded (description claims vX while production runs vY). | `(x)` at resolve time if the description **contradicts the delivered outcome**, i.e. still frames the work as not-yet-done (in-progress status/phase table, unticked boxes for completed work, or a superseded version), same principle as §J; `(!)` if stale and misleading but not contradictory; `(i)` if minor drift |
 | F2 | **Implementer-side comments** document each step with `{code}` blocks containing both the command and its output | `(!)` per missing block |
 | F3 | **Console output / screenshot** for the actual fix is present | `(x)` if no proof at all; `(!)` if partial |
+| F3b | **Quoted output reconciles with the raw artefact** — when a session log, terminal recording, or screenshot is *attached* alongside pasted `{code}` blocks, open the artefact and check the quoted excerpt against it. A pasted block is hand-copied: it can be trimmed, reordered, or taken from a different run than the one being described. Reconcile the load-bearing values — recap/summary counts, exit codes, digests or hashes, timestamps — and say in the QA comment that you did. | `(x)` if the quote contradicts the artefact; `(!)` if the artefact is unreadable or covers only part of the quoted work |
 | F4a | **Structured issue links** — related issues, predecessor, inventory item are linked via the ticket system's *issue-link feature* (not just mentioned in prose). Bidirectional traceability matters: someone navigating from the inventory item should find this ticket. **Verify by querying issue links, not by reading the description**. *Parent Epic / Parent / Sprint are out of scope here — see the "parent-Epic exception" note below.* | `(!)` per missing link |
 | F4b | **External work artefacts** — MR/PR, pipeline, registry/release — present in comments or as web/remote links, and reachable. Prefer GitHub/GitLab native shorthand (`owner/repo#123`, `group/project!456`, `owner/repo@7c12680`) over full URLs for trusted shared-namespace projects; full URLs for pipelines, branches, releases, and cross-org links. See `comment-template.md` "Link conventions". | `(!)` per missing or 404 |
 | F5 | *(merged into F4b)* | — |
@@ -66,6 +67,14 @@ The R pillar verifies the change fixed what the ticket said it would. The G pill
 
 Severity uses the standard icon vocabulary `(/)` `(x)` `(!)` `(i)` `(?)`. A G-finding that demonstrates a real regression is `(x)` MUST and bounces the ticket. A G-finding that surfaces "I cannot tell if X is affected" is `(?)` and blocks on the answer.
 
+### Grade a surprising probe against a control, never in isolation
+
+A probe that comes back wrong-looking — a 404, a default/self-signed certificate, a redirect, an empty list, a permission denial — carries no severity on its own. The same output can mean "this change broke it" or "this is what every peer in the same lifecycle state returns". Guessing between those two is how a reviewer either bounces a healthy ticket or waves through a real regression, and both failures look equally confident in the comment.
+
+Before grading it, **run the identical probe against a sibling you already know the state of**: another host behind the same proxy, another tenant on the same platform, another entry of the same kind in the same config. Pick the sibling for the comparison you need — one known-good peer tells you whether the mechanism works at all; one peer in the *same* pending state tells you whether the result is simply the baseline for "not deployed yet".
+
+Put the comparison in the QA comment as a small table, not as a claim. "Behaves like its peers" is an assertion; three rows showing the same result is evidence, and it survives someone re-reading the ticket a year later. Where the control shows the result *is* the baseline, the finding is `(i)` context for the requester — not a `(x)` against the ticket under review, and not something to leave out because it looked fine.
+
 ### Common false negatives this catches
 
 - Bugfix touched a shared helper; the helper has three callers and only one was tested.

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

@@ -13,6 +13,8 @@ The QA queue is normally a **team queue** with no assignee. Reviewer self-assign
 | Me, from a prior implementation phase | Stop — cannot self-QA. Hand off to another teammate. See `edge-cases.md`. |
 | Me, from a prior abandoned QA attempt | Continue |
 
+Every row in that table compares the current assignee against **you**, so resolve both before deciding — and resolve them by *asking the ticket system*, not by inferring. Your own account name is a lookup (`jira-communication`: `jira-user.py me`), not something to reconstruct from git config, a shell environment, or a credentials file — those hold a token or a commit identity, which need not match the ticket-system account. Read the current assignee off the ticket the same way: from the Stage-0 bundle if it reports one, otherwise by querying the field directly. Neither value is worth guessing, and both are one call.
+
 The claim is a loan, not ownership: clear your reviewer assignment on a passing verdict — unassign on resolve, hand to the product owner on QA2 (Stage 5, "Assignee on exit").
 
 ## Stage 0: Discover
@@ -88,6 +90,10 @@ One structured comment per template (`comment-template.md`), then transition the
 
 Gotcha: a **Resolve** transition often does **not** clear the assignee, whereas **Close** does — so a "Resolved but still assigned to me" ticket is the one to clean up. Verify the assignee after a resolve, and unassign explicitly (e.g. set the field to null) if it stuck.
 
-**Log your QA time** — before you transition, book a worklog for the review against the ticket (e.g. `jira-worklog.py add <KEY> <duration> -c "Round-1 IT QA: ..."`). Stage 1 already flags a missing *implementer* worklog (checklist F6); the reviewer's own review time is part of the **same** audit / billing / capacity trail, so log it as a closing step rather than waiting to be asked. Cover the actual review work — re-running verification, reading pipelines/logs, root-cause forensics, writing the comment — not just the transition click.
+**Log your QA time** — before you transition, book the review against the ticket. Stage 1 already flags a missing *implementer* worklog (checklist F6); the reviewer's own review time is part of the **same** audit / billing / capacity trail, so log it as a closing step rather than waiting to be asked. Cover the actual review work — re-running verification, reading pipelines/logs, root-cause forensics, writing the comment — not just the transition click.
+
+**Book in your team's system of record, and find out which one that is before booking.** Do not assume it is the ticket system. Where a separate time tracker feeds worklogs into the ticket system, the tracker is the system of record and writing a worklog directly onto the ticket **double-books** — the direct entry plus the one the tracker syncs in later. That is a billing error, and it is not always visible on the ticket afterwards, because the synced entry looks identical to the one you wrote. Booking through the wrong end is also awkward to undo: ticket-system CLIs commonly expose "add worklog" without a matching "delete worklog".
+
+So: check your team's convention (an `AGENTS.md`, a team runbook, or the tracker's own docs) for which system owns time, and use that one. This skill deliberately names no command — the right one is team-specific.
 
 Optional addendum comments are fine for separable concerns (e.g. a separate Confluence-runbook review). Keep the main verdict comment self-contained.