pm-ai-shipping: add the code-review skill (correctness / performance / security, each optional)

NOT RELEASED. No version bump - versions stay at 2.0.0 across all 9 plugins and
marketplace.json, because bumping is the release action and this ships only after
it has been tested. On a branch for the same reason.

WHY A SKILL AND NOT A FOURTH COMMAND. /security-audit-static is already mature -
sink analysis, self-refutation with attacker/victim rules, OWASP backstop, fan-out.
Rebuilding that inside something new would duplicate it. The hole in this plugin is
CORRECTNESS: there is no bug-finding review at all. So this is one skill with three
independently activated dimensions that defers to the existing command for security
and points at intended-vs-implemented for the doc-vs-code axis.

THE ANCHOR IS THE AGREEMENT, NOT THE FILE. The defects reviewers miss are rarely
visible inside one file - they are disagreements between two participants that each
read sensibly alone. Engine: map a flow, identify an obligation, inspect EVERY
participant, construct a violating execution, trace the consequence, refute, report.
Two lenses get a forced probe rather than a checklist mention: authority
reconciliation (a requested value is not an applied value) and identity correlation
(is the key unique, stable and live under overlap and reuse).

Refutation discipline is deliberately stricter than the security command's: a
correctness defect can harm only the person who triggered it and still be serious,
so the attacker/victim test does not transfer, and 'keep unless disproved' is too
permissive. Keep / Drop / Unresolved, with unresolved kept out of the findings list.

Parallelism fans out over complete flows, never over files - partitioning by file is
exactly the split that hides cross-boundary defects. Overlapping reads are allowed
and encouraged.

Coverage reports work performed in four states; zero findings is not 'not covered'.

Co-designed with GPT-6 Astra (Codex CLI). Contains no project-specific content: no
repo names, no paths, no bug identifiers, no defect text - verified by scan.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01G42vsxSKL7je39AsHZ5aJm

pm-ai-shipping/skills/code-review/references/correctness-taxonomy.md

@@ -0,0 +1,92 @@
+# Correctness taxonomy — twelve lenses, with detection tells
+
+Overlapping diagnostic lenses, not a classification scheme and not a quota. Each entry says **how you
+detect it**, because a class name alone changes nothing about what a reviewer looks at.
+
+Lenses 1 and 2 are the ones strong reviewers — human and machine — miss most often, and the only two
+that warrant an explicit forced probe rather than a read-through. Both are failures of *looking*, not
+of judgement: the code reads sensibly at each participant, and the defect exists only in the
+relationship between them.
+
+---
+
+### 1. Authority reconciliation
+Follow a proposed value through validation, normalisation, negotiation or commit. Identify downstream
+state still derived from the **proposal** when the authority can legitimately return something
+different. Check that reconciliation happens *before* the first consequential use.
+
+> **A requested value is not an applied value.** Anywhere a system can say "I heard you, and here is
+> what I actually did", the reply is the authority — and the request is not.
+
+**Probe:** construct an execution where the effective answer differs from the requested one, then ask
+which stored state, which UI, which later call and which log line still carry the request.
+
+### 2. Identity and correlation
+Trace how an operation's result finds its originating entity. Establish the correlation key's
+**uniqueness, stability and lifetime** under overlapping operations, reordering, removal and reuse. A
+label, an index, a position or arrival order is suspicious exactly when one of those can fail.
+
+**Probe:** run two operations concurrently and complete them out of order. Then remove one mid-flight
+and reuse its slot.
+
+### 3. Freshness and generations
+Mark every value captured before a yield, await, callback, timer or lock release. Determine what can
+change before it is used, and whether the operation still targets the intended entity *and version*.
+Check what the code actually does with a stale result — ignore, apply, or apply silently.
+
+### 4. Lifecycle and derived state
+Compare every reachable construction, replacement, restoration, reset, failure and termination path.
+Look for derived fields or cached decisions correctly re-established on one path and wrongly retained
+on another. Two paths that should end in equivalent state are an agreement like any other.
+
+### 5. Atomicity and partial failure
+Split multi-effect operations at each failure and cancellation point. Is partial state permitted,
+recoverable and accurately reported? Look for success reported before the required effects are
+durable.
+
+### 6. Replay and effect cardinality
+Follow retries, duplicate delivery, repeated callbacks and re-entry into effects. Compare the actual
+delivery guarantee against the required effect count — especially where an effect costs money, sends
+a message or mutates a shared total. Inspect deduplication scope, lifetime, and behaviour after
+partial success.
+
+### 7. Composition and precedence
+Trace independently produced pieces through merge, reduction, ordering and dispatch. Compare the real
+overwrite and selection rules against the intended authority or priority — including transformations
+applied *after* the merge that quietly re-order or re-key it.
+
+### 8. Bounds, units and accounting
+Follow counts, lengths, offsets, capacities and totals through every transformation. Check empty and
+boundary cases, overflow, rounding, and whether measurement and consumption use the same unit and
+representation.
+
+### 9. Framing and incremental processing
+Compare logical item boundaries against actual read, write, iterator and callback boundaries. Test
+split items, combined items, partial writes and early termination. Inspect buffering, flush and
+finalisation — especially the last item.
+
+### 10. Representation and information loss
+Compare the values a producer can emit against the distinctions a consumer relies on: absent versus
+empty, zero versus missing, signed versus unsigned, canonical forms, precision, encoding, equality
+semantics. Trace round-trips and derived outputs for distinctions that disappear.
+
+### 11. Ownership, completion and progress
+Trace who may mutate, release, cancel and complete an operation or resource. Inspect exceptional
+exits and competing terminal paths for premature release, missing completion, deadlock, or use after
+ownership changed hands.
+
+### 12. Decisions and dispatch
+Enumerate the meaningful states and inputs for consequential predicates and dispatch tables. Compare
+branches against supported expectations: overlapping conditions, inverted tests, missing cases, and
+what the fallback actually does.
+
+---
+
+## Using these
+
+- They overlap on purpose. One defect can be lens 1 and lens 3 at once; report the root cause once.
+- Absence of findings under a lens is a valid result. Do not manufacture one to fill the table.
+- Finding nothing under lenses 1 and 2 is worth a second look *only* if you never constructed their
+  probes — a read-through reliably returns nothing here, which is exactly the failure mode.
+- None of these is language- or framework-specific. If a lens seems inapplicable, say which property
+  of the system makes it so.