diff --git a/.claude/agents/contract-generator.md b/.claude/agents/contract-generator.md
index d4baec2a..9aa8192d 100644
--- a/.claude/agents/contract-generator.md
+++ b/.claude/agents/contract-generator.md
@@ -17,7 +17,7 @@ You are the **contract generator**: you turn a human-friendly KB markdown templa
 1. **Check the cache first**: `node .claude/workflows/contracts/ensure-contract.mjs check <template> <contract>`.
    - `fresh` → cache-hit: return the contract file's parsed content **unchanged**, status `cache-hit`. Do NOT regenerate, do NOT rewrite the file.
    - `missing` / `stale` / `invalid` → generate (next steps).
-2. **Read the template** and extract its vocabulary — e.g. the verdict options (checklist under "Overall Assessment"), the severity levels (the "Detailed Review Comments" issue sections), the per-finding fields. Adapt to the template's *current* structure: headings may have moved or been reworded; you are the parser precisely because a deterministic one would break here.
+2. **Read the template** and extract its vocabulary — e.g. the verdict options (the decision values on the `## Verdict` line), the severity levels (the severity labels under `## Details` → "Findings by severity"), the per-finding fields. Adapt to the template's *current* structure: headings may have moved or been reworded; you are the parser precisely because a deterministic one would break here.
 3. **Build the contract draft**:
    - `vocabulary`: an object of non-empty string arrays. **`verdictOptions` and `severities` are canonical, required key names** — always emit both (the orchestrator threads its reviewer-prompt vocabulary from exactly these two keys as the single source of truth, and `ensure-contract.mjs write` rejects a draft missing either). Add other keys as needed (e.g. `findingFields`) — those are not required.
    - `schema`: the caller's skeleton with ONLY the template-mirroring fields tightened into `enum`s (per the caller's `mirrors` note). Every other field — especially orchestration-only fields like `needsHumanDecision` and `nonActionable`, which have no template counterpart — stays byte-identical to the skeleton.
diff --git a/.claude/agents/reviewer.md b/.claude/agents/reviewer.md
index 84154568..bab8d634 100644
--- a/.claude/agents/reviewer.md
+++ b/.claude/agents/reviewer.md
@@ -14,7 +14,7 @@ You are an **independent code reviewer** for one Pair pull request. Your job is
 
 ## What to do
 
-- **Execute `/pair-process-review` as the process of record — do not improvise a review.** Run its phases, and **produce the review report using the code-review template** (`.pair/knowledge/guidelines/collaboration/templates/code-review-template.md`) and **post it as a PR comment**, exactly as the skill's decision phase specifies. The skill defines *how* you review and *what* you emit; follow it.
+- **Execute `/pair-process-review` as the process of record — do not improvise a review.** Run its phases, and **produce the review report using the code-review template** (`.pair/knowledge/guidelines/collaboration/templates/code-review-template.md`). The skill defines *how* you review and *what content* you emit; follow it for both. **Delivery differs on purpose:** the skill's decision phase submits the verdict as the native review body (its self-review flow), but you are an *independent* reviewer — a different actor, with self-approve blocked — so you **post the report as a PR comment** (see Constraints below) instead of as a native review action.
 - Reconstruct understanding yourself from AC + diff + code.
 - Verify every acceptance criterion is actually met by the diff (not just claimed). Hunt real bugs, check technical standards, security, template/skill conformance, test coverage.
 - **On re-review:** you also receive the *previous findings* (from the PR comment) — verify each was genuinely resolved, not merely acknowledged. Previous findings are review artifacts, not author bias; the handoff prohibition still holds.
@@ -29,6 +29,6 @@ You are an **independent code reviewer** for one Pair pull request. Your job is
 
 ## Output
 
-Post the full review report (code-review template) to the PR, then **return** to the orchestrator a compact structured summary that **mirrors the code-review template** (single source of truth): findings ranked most-severe first — each with `location` (File:Line), `severity` (`Critical` | `Major` | `Minor`), `description` (issue + impact), `recommendation`, and, for by-design/won't-fix, `nonActionable: true` **with a `disposition`** (the specific reason — `Deferred to #<number>` when deferred to a tracked story, never a bare "non-actionable") — plus a `verdict` from the template's Overall Assessment options: `Approved` | `Approved with Comments` | `Request Changes` | `Comment Only`. The posted report is the artifact; the return value is orchestration data.
+Post the full review report (code-review template) to the PR, then **return** to the orchestrator a compact structured summary that **mirrors the code-review template** (single source of truth): findings ranked most-severe first — each with `location` (File:Line), `severity` (`Critical` | `Major` | `Minor` | `Questions`), `description` (issue + impact), `recommendation`, and, for by-design/won't-fix, `nonActionable: true` **with a `disposition`** (the specific reason — `Deferred to #<number>` when deferred to a tracked story, never a bare "non-actionable") — plus a `verdict` from the template's `## Verdict`-line options: `APPROVED` | `CHANGES-REQUESTED` | `TECH-DEBT`. The posted report is the artifact; the return value is orchestration data.
 
 The severities and verdict options above are illustrative defaults (today's `code-review-template.md` wording). If the caller's prompt/schema for this run supplies its own severity or verdict vocabulary (e.g. an orchestrator threading it from a generated machine contract), use that vocabulary instead — it takes precedence, since it is the one derived from the template's current, actual content.
diff --git a/.claude/skills/pair-capability-assess-security/SKILL.md b/.claude/skills/pair-capability-assess-security/SKILL.md
index 423289da..65353a7e 100644
--- a/.claude/skills/pair-capability-assess-security/SKILL.md
+++ b/.claude/skills/pair-capability-assess-security/SKILL.md
@@ -58,7 +58,7 @@ Every rule the skill applies is resolved through the same layered set, most-spec
 ### Step 4: Emit Review Verdict
 
 1. **Act**: Compute the overall verdict = highest severity among introduced findings (pre-existing findings are reported but don't raise the verdict past what introduced findings justify, consistent with the review floor in quality-model.md §3.2: this review pass may only raise the tier's Security relevance dimension, never lower a value the story's own refinement-time assessment already set).
-2. **Act**: Render the 1-line verdict + collapsed findings list (severity, rule/category, file:location) per Output Format below — output-only, no files written; this is embedded by the caller into the review report's Security Review section (D22 — verdict in ~1 line, details in `<details>`).
+2. **Act**: Render the 1-line verdict + collapsed findings list (severity, rule/category, file:location) per Output Format below — output-only, no files written; this is embedded by the caller into the review body's five Security sections (D22 — verdict in ~1 line, details in `<details>`).
 3. **Verify**: Verdict emitted. If any **introduced** finding is red → flag explicitly for the caller: this is the AC4 signal that drives `/pair-process-review`'s CHANGES-REQUESTED decision (the decision itself stays `/pair-process-review`'s, per its own Step 5.2 table — this skill only reports the finding).
 
 ## Audit Mode (one-shot)
@@ -133,7 +133,7 @@ SECURITY AUDIT COMPLETE:
 When composed by `/pair-process-review` (Phase 2):
 
 - **Input**: `/pair-process-review` invokes `/pair-capability-assess-security` with `$mode: review` against the PR diff.
-- **Output**: Returns the verdict + collapsed findings (Review Mode output above). `/pair-process-review` embeds it verbatim into the review report's Security Review section and, if any introduced finding is red, factors it into its own CHANGES-REQUESTED decision (Step 5.2).
+- **Output**: Returns the verdict + collapsed findings (Review Mode output above). `/pair-process-review` embeds it verbatim into the review body's five Security sections and, if any introduced finding is red, factors it into its own CHANGES-REQUESTED decision (Step 5.2).
 - **Persistence**: None — review mode writes nothing.
 
 When invoked **independently** in audit mode:
diff --git a/.claude/skills/pair-process-review/SKILL.md b/.claude/skills/pair-process-review/SKILL.md
index 7275ad7a..0c8ae72c 100644
--- a/.claude/skills/pair-process-review/SKILL.md
+++ b/.claude/skills/pair-process-review/SKILL.md
@@ -19,11 +19,13 @@ Review a pull request through 6 sequential phases (5 review + 1 optional merge).
 | `/pair-capability-record-decision`      | Capability | Yes      | Any   | Record missing ADR (HALT condition)          |
 | `/pair-capability-analyze-debt`         | Capability | Yes      | 4     | Flag tech debt items                         |
 | `/pair-capability-assess-security`      | Capability | Yes †    | 2     | Security posture verdict + findings (D22)    |
+| `/pair-capability-assess-cost`          | Capability | Yes †    | 2     | Cost class verdict + signals (D22)           |
+| `/pair-capability-assess-coupling`      | Capability | Optional | 2     | Architecture/coupling balance verdict (D22)  |
 | `/pair-capability-verify-adoption`      | Capability | Optional | 3     | Full adoption compliance                     |
 | `/pair-capability-assess-stack`         | Capability | Optional | 3     | Tech-stack resolution                        |
 | `/pair-capability-execute-manual-tests` | Capability | Optional | 6     | Post-merge release validation (manual tests) |
 
-† **Required _when installed_.** `/pair-capability-classify` and `/pair-capability-assess-security` carry Required = Yes because `/pair-process-review` composes them by default — but both **degrade gracefully**: `/pair-process-review` **warns and continues** when the skill is absent (`/pair-capability-classify` → Step 1.5 Skip; `/pair-capability-assess-security` → Step 2.4 / Graceful Degradation), never HALTing on their absence. "Required" here means _composed by default_, not _a hard prerequisite_, so the flag never contradicts the graceful-skip steps.
+† **Required _when installed_.** `/pair-capability-classify`, `/pair-capability-assess-security` and `/pair-capability-assess-cost` carry Required = Yes because `/pair-process-review` composes them by default — but all **degrade gracefully**: `/pair-process-review` **warns and continues** when the skill is absent (`/pair-capability-classify` → Step 1.5 Skip; `/pair-capability-assess-security` → Step 2.4; `/pair-capability-assess-cost` → Step 2.5; each also under Graceful Degradation), the affected section reading **not assessed**, never HALTing on their absence. `/pair-capability-assess-coupling` (#263) is Optional — until it ships the Architecture (Coupling) section reads **not assessed**. "Required" here means _composed by default_, not _a hard prerequisite_, so the flag never contradicts the graceful-skip steps.
 
 ## Arguments
 
@@ -98,8 +100,8 @@ Ask: _"Proceed with review?"_
 
 1. **Check**: Has `/pair-capability-classify` already run with `$context: review` on the current PR head commit?
 2. **Skip**: If already run — reuse the matrix + tier, move to Phase 2. If `/pair-capability-classify` is not installed → warn (`/pair-capability-classify not installed — no review-time risk matrix`) and move to Phase 2.
-3. **Act**: Compose `/pair-capability-classify` with `$context: review` against the PR diff. It applies the [quality model](../../../.pair/knowledge/guidelines/quality-assurance/quality-model.md) to the diff footprint, reads the story's refinement-time tier, and produces the review matrix as a **floor** — it confirms or **raises** the tier, and **never lowers** it (D17). The Security relevance and Coupling balance dimensions are reconciled in Phase 2 (Step 2.4) as `/pair-capability-assess-security` / `/pair-capability-assess-coupling` verdicts land — raise-only.
-4. **Verify**: The review matrix + `risk:*` tier are recorded on the PR (matrix in the body as 1 line + `<details>`, D22; tags applied only when a `## Tag Projection` is declared). This body matrix is the single rendered artifact — if Phase 2 raises Security relevance or Coupling balance, `/pair-process-review` updates it **in place** (Step 2.4), it is not re-emitted by `/pair-capability-classify`. A raise to `risk:red` is carried into the Step 5.2 decision. `/pair-capability-classify` HALTs only if the quality model doc (#221) is absent.
+3. **Act**: Compose `/pair-capability-classify` with `$context: review` against the PR diff. It applies the [quality model](../../../.pair/knowledge/guidelines/quality-assurance/quality-model.md) to the diff footprint, reads the story's refinement-time tier, and produces the review matrix as a **floor** — it confirms or **raises** the tier, and **never lowers** it (D17). The Security relevance and Coupling balance dimensions are reconciled in Phase 2 (Steps 2.4 and 2.6) as `/pair-capability-assess-security` / `/pair-capability-assess-coupling` verdicts land — raise-only.
+4. **Verify**: The review matrix + `risk:*` tier are recorded on the **PR description** (matrix as 1 line + `<details>`, D22; tags applied only when a `## Tag Projection` is declared). This PR-description matrix is the **live, editable** copy — if Phase 2 raises Security relevance or Coupling balance, `/pair-process-review` updates it **in place** (Step 2.4), it is not re-emitted by `/pair-capability-classify`. (Phase 5 additionally embeds a point-in-time **snapshot** of this matrix in the Verdict block of the review report; that copy belongs to the **append-only** native review body and is **never** edited in place — a post-submission raise surfaces in the next fresh review, see Step 5.3 / idempotency #5. So "in place" applies only to the editable PR description, not the review body.) A raise to `risk:red` is carried into the Step 5.2 decision. `/pair-capability-classify` HALTs only if the quality model doc (#221) is absent.
 
 ## Phase 2: Technical Review
 
@@ -137,9 +139,25 @@ Ask: _"Proceed with review?"_
 ### Step 2.4: Security Assessment
 
 1. **Check**: Has `/pair-capability-assess-security` already run with `$mode: review` on the current PR head commit?
-2. **Skip**: If already run — reuse the verdict + findings, move to Phase 3.
-3. **Act**: Compose `/pair-capability-assess-security` with `$mode: review` against the PR diff. It resolves the rule set (KB global + per-service + per-web-app + adoption project rules) and returns a 1-line verdict + collapsed findings, each tagged **introduced** or **pre-existing**.
-4. **Verify**: Verdict + findings recorded — feeds the Security Review section (Step 5.1) and the **Security relevance** dimension of the Step 1.5 classification matrix (`/pair-capability-classify` folds this verdict in **raise-only** — it may raise the tier, never lower it). **Body re-render**: when the verdict raises Security relevance (or the Coupling verdict raises Coupling balance), `/pair-process-review` updates the already-written Step 1.5 body matrix **in place** — re-rendering the affected `<details>` row and the 1-line `risk:*` tier so the PR body reflects the final, raised tier; `/pair-capability-classify` is **not** re-invoked (its Phase-1 run stands, and a raise-only edit needs no recompute). **Tag re-apply**: when a `## Tag Projection` is declared (e.g. `Active: risk`), this in-place Phase-2-originated raise **also re-applies the projected chromatic tag on the PR** — swapping the stale label for the raised tier (e.g. `risk:yellow` → `risk:red`) via the same §5 projection `/pair-capability-classify` uses in its Step 5, applied here by `/pair-process-review` on the raise-only edit — so the PR label matches the raised body tier (AC3); when no projection is declared, only the body matrix is updated and no label is touched. If any **introduced** finding is red → flag explicitly: this is the AC4 signal that drives the CHANGES-REQUESTED decision in Step 5.2. Does not itself HALT — `/pair-capability-assess-security` has no merge authority, this skill's own decision step does.
+2. **Skip**: If already run — reuse the verdict + findings, move to Step 2.5.
+3. **Act**: Compose `/pair-capability-assess-security` with `$mode: review` against the PR diff. It resolves the rule set (KB global + per-service + per-web-app + adoption project rules) and returns a 1-line verdict + collapsed findings, each tagged **introduced** or **pre-existing**. The verdict feeds the five verdict-first Security sections of the review body — **input validation, output handling, authentication, authorization, introduced vulnerabilities** (Step 5.1, per the [code-review-template](../../../.pair/knowledge/guidelines/collaboration/templates/code-review-template.md)).
+4. **Verify**: Verdict + findings recorded — feeds the Security sections (Step 5.1) and the **Security relevance** dimension of the Step 1.5 classification matrix (`/pair-capability-classify` folds this verdict in **raise-only** — it may raise the tier, never lower it). **PR-description re-render**: when the verdict raises Security relevance (or the Coupling verdict raises Coupling balance), `/pair-process-review` updates the already-written Step 1.5 **PR-description** matrix **in place** — re-rendering the affected `<details>` row and the 1-line `risk:*` tier so the PR **description** reflects the final, raised tier (the append-only review body is never edited in place — Step 5.3); `/pair-capability-classify` is **not** re-invoked (its Phase-1 run stands, and a raise-only edit needs no recompute). **Tag re-apply**: when a `## Tag Projection` is declared (e.g. `Active: risk`), this in-place Phase-2-originated raise **also re-applies the projected chromatic tag on the PR** — swapping the stale label for the raised tier (e.g. `risk:yellow` → `risk:red`) via the same §5 projection `/pair-capability-classify` uses in its Step 5, applied here by `/pair-process-review` on the raise-only edit — so the PR label matches the raised body tier (AC3); when no projection is declared, only the body matrix is updated and no label is touched. If any **introduced** finding is red → flag explicitly: this is the AC4 signal that drives the CHANGES-REQUESTED decision in Step 5.2. Does not itself HALT — `/pair-capability-assess-security` has no merge authority, this skill's own decision step does.
+5. **Degrade**: `/pair-capability-assess-security` not installed → the five Security sections read **not assessed** (never dropped); a manual security read of the diff is still expected.
+
+### Step 2.5: Cost Assessment
+
+1. **Check**: Has `/pair-capability-assess-cost` already run against the current PR head commit?
+2. **Skip**: If already run — reuse the class + signals, move to Step 2.6.
+3. **Act**: Compose `/pair-capability-assess-cost` against the PR diff. It resolves the cost-signal catalog from the project's stack/architecture/infrastructure adoption and returns the `cost:green|yellow|orange|red` class as a 1-line verdict + collapsed signals table (D22). This is a genuine re-assessment of the diff — never a restatement of the story's refinement-time `cost:*` tag.
+4. **Verify**: Class + signals recorded — feed the **Cost** section of the review body (Step 5.1, 1 line + `<details>`). The `cost:*` class is carried as its own dimension of the matrix (never folded into the risk `max`). A **red** cost class surfaces the **blocking human sign-off** requirement in the Verdict area (Step 5.1) and is carried into the Step 5.2 decision. Tag re-apply on the PR follows the same rule as Step 2.4 when `cost` is in the declared `## Tag Projection`. Does not itself HALT — `/pair-capability-assess-cost` has no merge authority.
+5. **Degrade**: `/pair-capability-assess-cost` not installed → the Cost section reads **not assessed** (never dropped).
+
+### Step 2.6: Architecture (Coupling) Assessment
+
+1. **Check**: Is `/pair-capability-assess-coupling` installed (ships with #263)?
+2. **Skip**: If not installed → the **Architecture (Coupling)** section reads **not assessed** explicitly; move to Phase 3.
+3. **Act**: Compose `/pair-capability-assess-coupling` with `$scope: diff`. It returns a 1-line balance verdict on the integrations the diff touches (integration strength, socio-technical distance, volatility) + collapsed findings (D22).
+4. **Verify**: Verdict + findings recorded — feed the **Architecture (Coupling)** section of the review body (Step 5.1) and the **Coupling balance** dimension of the Step 1.5 matrix (`/pair-capability-classify` folds it in **raise-only**, same in-place body re-render + tag re-apply rule as Step 2.4). Does not itself HALT.
 
 ## Phase 3: Adoption Compliance
 
@@ -191,17 +209,13 @@ Run the procedure for the level determined in Step 3.1 — see [degradation-leve
 
 ### Step 5.1: Compile Review Report
 
-1. **Act**: Compile all findings into a review report following the [code-review-template.md](../../../.pair/knowledge/guidelines/collaboration/templates/code-review-template.md) (resolve override-first — [template resolution](../../../.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/template-resolution.md)):
-   - **Review Information**: PR number, author, reviewer, date, story, review type
-   - **Review Summary**: overall assessment, key changes, business value
-   - **Code Review Checklist**: functionality, code quality, technical standards (from Phase 2)
-   - **Security Review**: verdict + collapsed findings from `/pair-capability-assess-security` (Step 2.4) — 1-line + `<details>` (D22)
-   - **Testing Review**: test coverage and quality (from /pair-capability-verify-quality)
-   - **Documentation Review**: documentation completeness (from /pair-capability-verify-done)
-   - **Detailed Review Comments**: issues by severity, positive feedback
-   - **Risk Assessment**: technical and business risks
-   - **Tech Debt**: items flagged by /pair-capability-analyze-debt
-   - **Adoption Compliance**: results from Phase 3 (with degradation level noted)
+1. **Act**: Compile all findings into a **verdict-first** review body following the [code-review-template.md](../../../.pair/knowledge/guidelines/collaboration/templates/code-review-template.md) (resolve override-first — [template resolution](../../../.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/template-resolution.md)). The body is ordered so verdict, tier and cost class read in **~30 seconds** (D22, R6.6):
+   - **Verdict** (top): classification tags (`risk:<tier>` · `cost:<class>`) + the decision + a 1-line reason + PR/author/story metadata. Include the **`Classification changed:`** drift note **only** when the review-time tier/cost differs from the story's refinement-time classification — it fires **upward only** (e.g. `risk:yellow` → `risk:red`, raise-only per quality-model §3.2 / D17); a review that would lower a dimension records the reduction as a finding in the collapsed details, never as a silent downgrade. A **red** cost class states the **blocking human sign-off** requirement here.
+   - **Assessments** (each a 1-line verdict + `<details>`, "not assessed" when the capability is absent):
+     - **Security — input validation, output handling, authentication, authorization, introduced vulnerabilities** (five verdicts from `/pair-capability-assess-security`, Step 2.4)
+     - **Cost** — `cost:*` class + signals (from `/pair-capability-assess-cost`, Step 2.5)
+     - **Architecture (Coupling)** — balance verdict (from `/pair-capability-assess-coupling`, Step 2.6; "not assessed" until #263)
+   - **Details** (collapsed): findings by severity + positive feedback (Phase 2); functionality / AC coverage; testing & quality gates (from /pair-capability-verify-quality); adoption compliance with degradation level (Phase 3); tech debt (from /pair-capability-analyze-debt); documentation (from /pair-capability-verify-done).
 
 ### Step 5.2: Make Review Decision
 
@@ -210,18 +224,21 @@ Based on compiled findings:
 | Decision              | Condition                                                                                 |
 | --------------------- | ----------------------------------------------------------------------------------------- |
 | **APPROVED**          | No critical or major issues. All AC met. Quality gates pass.                              |
-| **CHANGES-REQUESTED** | Critical issues found, missing ADRs, any **introduced** red security finding from `/pair-capability-assess-security` (AC4), failing tests, AC not met. |
+| **CHANGES-REQUESTED** | Critical issues found, missing ADRs, any **introduced** red security finding from `/pair-capability-assess-security` (AC4), failing tests, AC not met. A **red** `cost:*` class does not itself block — it surfaces a **blocking human sign-off** requirement in the Verdict (the human, not the skill, gates on cost). |
 | **TECH-DEBT**         | Only minor issues or debt items. Approve current PR, track debt separately.               |
 
-### Step 5.3: Post Review
+### Step 5.3: Submit Review
+
+The compiled report **is the body of the native GitHub review** — the verdict is the review action; there is **no separate PR comment** (decision Q5, AC2).
 
-1. **Act**: Post the review report as a PR comment.
-2. **Act**: Set PR review status using the PM tool (per [github-implementation.md](../../../.pair/knowledge/guidelines/collaboration/project-management-tool/github-implementation.md)):
-   - **APPROVED / TECH-DEBT**: Submit review with `event = APPROVE`.
-   - **CHANGES-REQUESTED**: Submit review with `event = REQUEST_CHANGES`.
-   - MCP-first: use `pull_request_review_write` with `method = create` and appropriate `event`.
-   - CLI fallback: `gh pr review <number> --approve` or `--request-changes`.
-3. **Verify**: Review posted and status updated.
+1. **Act**: Submit the native review using the PM tool (per [github-implementation.md](../../../.pair/knowledge/guidelines/collaboration/project-management-tool/github-implementation.md)), passing the compiled verdict-first report as the review **body**:
+   - **APPROVED / TECH-DEBT**: `event = APPROVE`.
+   - **CHANGES-REQUESTED**: `event = REQUEST_CHANGES`.
+   - MCP-first: `pull_request_review_write` with `method = create`, the report as `body`, and the appropriate `event`.
+   - CLI fallback: `gh pr review <number> --approve|--request-changes --body-file <report>`.
+   - **Self-authored PR** (solo/self-review): GitHub rejects `APPROVE` / `REQUEST_CHANGES` on your own PR. Submit the same verdict-first report with `event = COMMENT` (`gh pr review <number> --comment --body-file <report>`) — the verdict token (APPROVED / CHANGES-REQUESTED / TECH-DEBT) still leads the body, so the decision and full report are recorded, never lost. See Graceful Degradation.
+2. **Act**: On re-review, submit a **fresh** native review — both documented paths append (MCP `create`; `gh pr review` CLI), neither edits a submitted body. GitHub's latest-review-governs semantics mean the newest review carries the verdict while earlier reviews stay as visible history, so re-invocation is safe without editing in place (idempotency).
+3. **Verify**: The native review is submitted with the verdict-first body — no separate review-comment artifact exists.
 
 ### Step 5.4: Determine Next Action
 
@@ -249,12 +266,14 @@ REVIEW COMPLETE:
 ├── Story:      [#ID: Title | N/A]
 ├── Decision:   [APPROVED | CHANGES-REQUESTED | TECH-DEBT]
 ├── Issues:     [critical: N | major: N | minor: N]
-├── Security:   [green | yellow | red — N findings, N introduced | N/A — not installed]
+├── Security:   [green | yellow | red — N findings, N introduced | not assessed]
+├── Cost:       [green | yellow | orange | red | not assessed]
+├── Coupling:   [green | yellow | red | not assessed — until #263]
 ├── Quality:    [PASS | FAIL — N gates]
 ├── DoD:        [N/N criteria met]
 ├── Adoption:   [Level N — summary]
 ├── Debt:       [N items flagged]
-└── Report:     [Posted as PR comment]
+└── Review:     [Submitted as native review body — no separate comment]
 ```
 
 At merge (Phase 6): see [merge-and-cascade.md](./merge-and-cascade.md).
@@ -277,7 +296,7 @@ See [idempotency convention](../../../.pair/knowledge/guidelines/technical-stand
 2. **Phases**: checks which phases completed (via session state or PR review comments). Resumes from first incomplete phase.
 3. **Skill compositions**: /pair-capability-verify-quality, /pair-capability-verify-done, /pair-capability-assess-security results cached in session. Not re-run if already passing/current on current commit.
 4. **New commits**: if PR updated since last check, re-validates affected phases only.
-5. **Review report**: updates existing report rather than posting duplicates.
+5. **Review report**: re-review appends a fresh native review (MCP `create` / `gh pr review`); GitHub's latest-review-governs semantics make the newest one carry the verdict while prior reviews remain as history. The report is always the review body, never a separate comment — so no duplicate comment artifact is created.
 6. **Merge**: detects already-merged PR. Skips Phase 6 if already merged. Resumes parent cascade if merge succeeded but status updates are incomplete.
 
 ## Graceful Degradation
@@ -287,7 +306,10 @@ See [graceful degradation](../../../.pair/knowledge/guidelines/technical-standar
 - **/verify-adoption not installed**: Falls back to inline dependency checking against [tech-stack.md](../../../.pair/adoption/tech/tech-stack.md). Warning logged. See degradation cascade (Phase 3).
 - **/assess-stack not installed**: Unlisted dependencies flagged as warnings for manual verification. Does NOT HALT.
 - **/analyze-debt not available**: Skip debt assessment, note in report.
-- **/assess-security not installed**: Skip Step 2.4. Security Review section notes "manual judgment only — /pair-capability-assess-security not installed". Does NOT HALT; a manual security read of the diff is still expected per [how-to-11](../../../.pair/knowledge/how-to/11-how-to-code-review.md).
+- **/assess-security not installed**: Skip Step 2.4. The five Security sections (input validation, output handling, authentication, authorization, introduced vulnerabilities) read **not assessed** — never dropped. Does NOT HALT; a manual security read of the diff is still expected per [how-to-11](../../../.pair/knowledge/how-to/11-how-to-code-review.md).
+- **/assess-cost not installed**: Skip Step 2.5. The Cost section reads **not assessed**. Does NOT HALT.
+- **/assess-coupling not installed** (until #263): Skip Step 2.6. The Architecture (Coupling) section reads **not assessed**. Does NOT HALT.
+- **Self-authored PR (self-review)**: GitHub blocks `APPROVE` / `REQUEST_CHANGES` on your own PR, so the native verdict action is rejected for solo authors. Fall back to `event = COMMENT` (`gh pr review <number> --comment --body-file <report>`), keeping the verdict token at the head of the body — the full verdict-first report is still recorded as a review, so nothing is lost (unlike a rejected APPROVE/REQUEST_CHANGES). Does NOT HALT.
 - **Story not found**: Review proceeds with PR-only validation (no AC check). Phase 6 skips parent cascade.
 - **Code review template not found**: **HALT** — cannot produce review without template (a required dependency, not optional).
 - **PM tool not accessible**: Phase 6 merge via CLI only.
@@ -297,7 +319,7 @@ See [graceful degradation](../../../.pair/knowledge/guidelines/technical-standar
 
 ## Notes
 
-- This skill **reads code, posts review comments, and optionally merges PRs** — it does not modify source code.
+- This skill **reads code, submits the native review (verdict = the review action), and optionally merges PRs** — it does not modify source code and posts no separate review comment (AC2).
 - Review phases are sequential — each phase builds on findings from prior phases.
 - The reviewer can stop between phases; re-invoke to resume (see [idempotency convention](../../../.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/idempotency.md)).
 - Output follows [code-review-template.md](../../../.pair/knowledge/guidelines/collaboration/templates/code-review-template.md) — the template defines structure, /pair-process-review fills it with findings.
diff --git a/.claude/workflows/contracts/ensure-contract.test.mjs b/.claude/workflows/contracts/ensure-contract.test.mjs
index 2c4794f9..c0dae897 100644
--- a/.claude/workflows/contracts/ensure-contract.test.mjs
+++ b/.claude/workflows/contracts/ensure-contract.test.mjs
@@ -24,6 +24,10 @@ const CLI = fileURLToPath(new URL('./ensure-contract.mjs', import.meta.url))
 const TEMPLATE_V1 = '# Code Review Template\n\n- [ ] **Approved**\n'
 const TEMPLATE_V2 = '# Code Review Template\n\n- [ ] **Approved**\n- [ ] **Rejected**\n'
 
+// NB: the verdict/severity values below are INTENTIONALLY ARBITRARY — this suite
+// tests the mechanism (hash / decide / validate / stamp) and is deliberately
+// decoupled from the real code-review template. They are NOT the canonical vocab
+// (canonical is APPROVED / CHANGES-REQUESTED / TECH-DEBT); do not treat as an example.
 function goodDraft() {
   return {
     vocabulary: {
diff --git a/.claude/workflows/implement-batch.js b/.claude/workflows/implement-batch.js
index f495f4c5..271fbff2 100644
--- a/.claude/workflows/implement-batch.js
+++ b/.claude/workflows/implement-batch.js
@@ -77,8 +77,8 @@ const PR_SCHEMA = {
   required: ['prNumber'],
 }
 const LOOSE_REVIEW_SCHEMA = {
-  // Mirrors code-review-template.md: the Overall Assessment verdict options and the
-  // Detailed Review Comments finding fields (File:Line / severity / description /
+  // Mirrors code-review-template.md: the `## Verdict`-line verdict options and the
+  // `Findings by severity` finding fields (File:Line / severity / description /
   // recommendation). The posted report is the artifact; this is the return value.
   // This is the loose FALLBACK skeleton: phase-0 (ensure-contract, below) derives an
   // enum-locked version from the template via an AI-generated contract.json; when
@@ -86,9 +86,9 @@ const LOOSE_REVIEW_SCHEMA = {
   // used as-is so the run never breaks.
   type: 'object',
   properties: {
-    // Free string mirroring code-review-template.md's "Overall Assessment" options
-    // (Approved / Approved with Comments / Request Changes / Comment Only) — NOT
-    // enum-locked here, so a template vocabulary change doesn't break validation.
+    // Free string mirroring code-review-template.md's `## Verdict`-line options
+    // (APPROVED / CHANGES-REQUESTED / TECH-DEBT) — NOT enum-locked here, so a
+    // template vocabulary change doesn't break validation.
     // Control flow keys on `nonActionable` + actionable count, never on specific
     // verdict strings.
     verdict: { type: 'string' },
@@ -99,7 +99,7 @@ const LOOSE_REVIEW_SCHEMA = {
         type: 'object',
         properties: {
           location: { type: 'string' }, // File:Line
-          severity: { type: 'string' }, // Critical | Major | Minor per template (not enum-locked)
+          severity: { type: 'string' }, // Critical | Major | Minor | Questions per template (not enum-locked)
           description: { type: 'string' }, // the issue and its impact
           recommendation: { type: 'string' }, // suggested resolution
           // true = by-design / won't-fix: fixing it would be wrong (byte-consistent
@@ -162,7 +162,7 @@ const CONTRACT_SPECS = [
     contract: '.claude/workflows/contracts/code-review.contract.json',
     skeleton: LOOSE_REVIEW_SCHEMA,
     mirrors:
-      'verdict ← the "Overall Assessment" options; findings[].severity ← the "Detailed Review Comments" severity levels',
+      'verdict ← the `## Verdict`-line options; findings[].severity ← the `Findings by severity` severity levels',
   },
 ]
 
@@ -225,8 +225,8 @@ const REVIEW_SCHEMA = crContract?.schema ?? LOOSE_REVIEW_SCHEMA
 // contract at all, `crContract?.contract` is null) — never a second,
 // independently-drifting vocabulary source.
 const REVIEW_VOCAB = crContract?.contract?.vocabulary
-const DEFAULT_SEVERITIES = ['Critical', 'Major', 'Minor']
-const DEFAULT_VERDICTS = ['Approved', 'Approved with Comments', 'Request Changes', 'Comment Only']
+const DEFAULT_SEVERITIES = ['Critical', 'Major', 'Minor', 'Questions']
+const DEFAULT_VERDICTS = ['APPROVED', 'CHANGES-REQUESTED', 'TECH-DEBT']
 const SEVERITIES = (REVIEW_VOCAB?.severities ?? DEFAULT_SEVERITIES).join(', ')
 const VERDICTS = (REVIEW_VOCAB?.verdictOptions ?? DEFAULT_VERDICTS).join(', ')
 
diff --git a/.claude/workflows/implement-batch.test.mjs b/.claude/workflows/implement-batch.test.mjs
index f298e246..5ce8d711 100644
--- a/.claude/workflows/implement-batch.test.mjs
+++ b/.claude/workflows/implement-batch.test.mjs
@@ -190,8 +190,8 @@ test('contract with usable schema but missing canonical vocabulary keys: prompt
   // are absent. In practice ensure-contract.mjs's validateContract now rejects
   // such a contract before it is ever persisted — this exercises the
   // consumer-side fallback as defense in depth.
-  assert.ok(rev.prompt.includes('Critical, Major, Minor'), 'default severities fallback')
-  assert.ok(rev.prompt.includes('Comment Only'), 'default verdict fallback')
+  assert.ok(rev.prompt.includes('Critical, Major, Minor, Questions'), 'default severities fallback')
+  assert.ok(rev.prompt.includes('CHANGES-REQUESTED'), 'default verdict fallback')
 })
 
 test('story.notes: scope directive threaded into implement and PR prompts', async () => {
diff --git a/.pair/adoption/decision-log/2026-07-18-d22-classification-verdict-collapsed-details.md b/.pair/adoption/decision-log/2026-07-18-d22-classification-verdict-collapsed-details.md
index 9f5ce6ab..56bcd6ea 100644
--- a/.pair/adoption/decision-log/2026-07-18-d22-classification-verdict-collapsed-details.md
+++ b/.pair/adoption/decision-log/2026-07-18-d22-classification-verdict-collapsed-details.md
@@ -31,6 +31,7 @@ Rationale: a reviewer or PM-tool viewer scanning many cards/PRs needs the verdic
 
 - `pair-capability-assess-security/SKILL.md` and `pair-process-review/SKILL.md`'s existing "D22" citations now resolve to a real record instead of only epic-body prose.
 - Story #228 (code-review-template rewrite) should update this ADL rather than create a separate one when it lands, since it's the same decision applied to the rest of the review template's dimensions.
+  - **Update (#376):** #228/PR #376 delivers the full verdict-first `code-review-template.md` rewrite — the `## Verdict` line (risk tier + cost class + 1-line decision) plus the seven-section structure (input validation, output handling, authentication, authorization, introduced vulnerabilities, cost, architecture/coupling), each a 1-line verdict + `<details>`. This extends D22 from security-only (#227) to every review-template dimension; no new decision is introduced (same reporting/UX convention), so this ADL is updated in place per the note above rather than superseded.
 
 ## Adoption Impact
 
diff --git a/.pair/adoption/decision-log/2026-07-24-review-template-lane-226-228-one-pr.md b/.pair/adoption/decision-log/2026-07-24-review-template-lane-226-228-one-pr.md
new file mode 100644
index 00000000..c5725140
--- /dev/null
+++ b/.pair/adoption/decision-log/2026-07-24-review-template-lane-226-228-one-pr.md
@@ -0,0 +1,57 @@
+# Decision: AC3 of #226 delivered in the #228 PR (shared review-template lane)
+
+## Date
+
+2026-07-24
+
+## Status
+
+Active
+
+## Category
+
+Process Decision
+
+## Context
+
+Story #228 (verdict-first code-review template) and story #226 (AC3:
+review-side cost section + classify-on-review floor) both mutate the same
+exclusive lane — the code-review template plus `/pair-process-review`'s output
+and classification-on-review behaviour. Splitting them into two PRs would put
+two changes on the same files in flight at once, forcing merge-order
+coordination and a near-guaranteed rebase conflict on `code-review-template.md`
+and the review SKILL.
+
+A scope directive (from the orchestrator driving the batch) folded #226's AC3
+into the single #228 PR (#376) for this reason. Per the one-PR-per-story
+default (`2026-07-12-one-pr-per-story-default.md`), crossing a story boundary
+needs an explicit reason; this records it, since the rationale otherwise lived
+only in the PR description and would not outlive the PR (CLAUDE.md requires
+project decisions to be recorded as ADR/ADL).
+
+## Decision
+
+Deliver AC3 of #226 (review-side cost section + classify-on-review raise-only
+floor) inside the #228 PR (#376), not a separate PR. The two stories share one
+exclusive review-template lane; co-delivering them avoids a self-inflicted
+merge conflict on identical files. #226's remaining ACs (if any) stay tracked
+on #226.
+
+## Alternatives Considered
+
+- **One PR per story (the default)**: rejected here — both stories edit the
+  same template + review-skill files, so parallel PRs would conflict and need
+  serialized merge ordering with a rebase in between, for no isolation benefit
+  (the two changes are one coherent edit to the review artifact).
+- **Defer #226 AC3 to a follow-up PR after #228 merges**: rejected — leaves the
+  cost section half-specified in the template between merges and duplicates the
+  review-skill edit surface.
+
+## Consequences
+
+- PR #376 closes #228 and satisfies #226 AC3; the #226 issue is updated to
+  reference #376 for that AC.
+- Reviewers see both changes in one diff — larger surface, single coherent
+  review of the review artifact.
+- This is an explicit exception to the one-PR-per-story default, scoped to the
+  shared-lane rationale above; it does not loosen the default generally.
diff --git a/.pair/knowledge/guidelines/collaboration/templates/code-review-template.md b/.pair/knowledge/guidelines/collaboration/templates/code-review-template.md
index 7cacec41..da1a7b56 100644
--- a/.pair/knowledge/guidelines/collaboration/templates/code-review-template.md
+++ b/.pair/knowledge/guidelines/collaboration/templates/code-review-template.md
@@ -1,279 +1,209 @@
 # Code Review Template
 
-## Review Information
+> **Verdict-first (D22, R6.6).** This is the **native GitHub review body** submitted with the review action (Approve / Request Changes / Comment). In `/pair-process-review`'s own self-review flow it is submitted as that native review body — **not a separate PR comment** (decision Q5). (An independent reviewer agent, or a self-authored PR where GitHub blocks self-approval, delivers this **same body** via a PR comment instead — see `.claude/agents/reviewer.md` and review Step 5.3; the artifact is identical, only the delivery event differs.) The top of the body — classification tags, tier, cost class and the 1-line verdict — reads in **~30 seconds**; every assessment is a 1-line verdict with the breakdown collapsed in `<details>`. A reader scanning the top understands verdict, tier and cost class inside the 30-second reading budget without opening a single `<details>`.
+>
+> **Not assessed is explicit.** When the backing capability is missing or failed (`/assess-security`, `/assess-cost`, `/assess-coupling`), the section verdict reads **not assessed** — never silently omitted.
 
-**PR Number:** [#XXX]  
-**Author:** [Developer name]  
-**Reviewer:** [Your name]  
-**Review Date:** [YYYY-MM-DD]  
-**Story/Epic:** [US-XXX or EP-XXX]  
-**Review Type:** [Feature/Bug Fix/Refactor/Hotfix]  
-**Estimated Review Time:** [XX minutes]
+## Verdict
 
-## Review Summary
+`risk:<tier>` · `cost:<class>` — **[APPROVED | CHANGES-REQUESTED | TECH-DEBT]** — [one-line reason]
 
-### Overall Assessment
+<!-- Unassessed-chip fallback: the chip is NEVER dropped — the verdict line always carries both `risk:` and `cost:` prefixes and stays scannable. `cost:n/a` renders when `/assess-cost` is absent (cost is a single-source dimension). `risk:n/a` renders ONLY when `/classify` is entirely absent (no matrix at all, per skill Step 1.5) — a single unassessed dimension (Security relevance, or Coupling until #263) is EXCLUDED from `max(assessed)` (§3.1 / D21), NOT propagated to the tier, so the risk chip still shows the max of the other assessed dimensions. `n/a` is a rendering placeholder, not a tag value (no `cost:not assessed` / `risk:not assessed` tag is ever emitted). This keeps the top-line degradation consistent with the section degradation, whose collapsed body reads "not assessed". -->
 
-- [ ] **Approved** - Ready to merge
-- [ ] **Approved with Comments** - Minor issues noted, can merge
-- [ ] **Request Changes** - Issues must be addressed before merge
-- [ ] **Comment Only** - Feedback provided, no blocking issues
+<!-- Classification-changed drift note: include ONLY when the review-time tier/cost differs from the story's refinement-time classification. Raise-only per quality-model §3.2 / D17 — a drift note fires upward, never records a silent downgrade. Omit the line entirely when unchanged. -->
+> **Classification changed:** `risk:<from>` → `risk:<to>` — [one-line reason]
 
-### Key Changes Summary
+**PR:** [#XXX] · **Author:** [name] · **Reviewer:** [name] · **Date:** [YYYY-MM-DD] · **Story:** [US-XXX] · **Type:** [feature | bug | refactor | docs | config]
 
-[Brief summary of what was reviewed and the main changes]
+<details>
+<summary>Classification matrix — per dimension</summary>
 
-### Business Value Validation
+| Dimension                   | Tier    | Source                     | Note              |
+| --------------------------- | ------- | -------------------------- | ----------------- |
+| Service/domain criticality  | [color] | [KB default / table]       | [note]            |
+| Change/diff risk            | [color] | [diff footprint]           | [note]            |
+| Business impact             | [color] | [subdomain class]          | [note]            |
+| Security relevance          | [color] | `/assess-security`         | [raise-only, D17] |
+| Coupling balance            | [color] | `/assess-coupling`         | [not assessed until #263] |
 
-[Confirm the changes deliver the expected business value]
+Tier = max(assessed). Cost = highest detected signal. Review value is a **floor** (D17): confirm or raise, never lower.
 
-## Code Review Checklist
+</details>
 
-### Functionality Review
+## Assessments
 
-- [ ] **Requirements Met** - Implementation matches acceptance criteria
-- [ ] **Business Logic** - Logic is correct and handles edge cases
-- [ ] **User Experience** - Changes improve or maintain user experience
-- [ ] **Integration** - Works correctly with existing systems
-- [ ] **Error Handling** - Appropriate error handling and recovery
-- [ ] **Performance** - No performance regressions introduced
+Each assessment is a **1-line verdict**; open the `<details>` for the breakdown. An unavailable capability shows **not assessed** (the section is never dropped).
 
-### Code Quality Assessment
+### Security — Input validation
 
-- [ ] **Readability** - Code is clear and easy to understand
-- [ ] **Maintainability** - Code is organized and well-structured
-- [ ] **Reusability** - Common functionality properly abstracted
-- [ ] **Naming** - Variables, functions, and classes well-named
-- [ ] **Comments** - Appropriate documentation and comments
-- [ ] **Complexity** - Code complexity is reasonable and justified
+**Verdict:** [green | yellow | red | not assessed] — [one-line]
 
-### Technical Standards Compliance
+<details>
+<summary>Details</summary>
 
-- [ ] **Style Guide** - Follows established coding standards
-- [ ] **Architecture** - Aligns with system architecture principles
-- [ ] **Design Patterns** - Uses appropriate design patterns
-- [ ] **Dependencies** - Dependencies are justified and minimal
-- [ ] **API Design** - API changes are backward compatible
-- [ ] **Database** - Database changes are optimized and indexed
+- Inputs touched by the diff and whether each is validated / sanitized.
+- Feeds from `/assess-security` (`$mode: review`).
 
-## Security Review
+</details>
 
-### Security Checklist
+### Security — Output handling
 
-- [ ] **Input Validation** - All user inputs properly validated
-- [ ] **Output Encoding** - Data properly encoded for output
-- [ ] **Authentication** - Authentication mechanisms properly implemented
-- [ ] **Authorization** - Access controls correctly enforced
-- [ ] **Data Protection** - Sensitive data properly handled
-- [ ] **Dependency Security** - No known security vulnerabilities
-- [ ] **Secrets Management** - No hardcoded secrets or credentials
-- [ ] **HTTPS/TLS** - Secure communication protocols used
+**Verdict:** [green | yellow | red | not assessed] — [one-line]
 
-### Security Concerns
+<details>
+<summary>Details</summary>
 
-| Concern   | Severity        | Description   | Recommendation |
-| --------- | --------------- | ------------- | -------------- |
-| [Issue 1] | High/Medium/Low | [Description] | [How to fix]   |
-| [Issue 2] | High/Medium/Low | [Description] | [How to fix]   |
+- Output encoding / escaping on the touched surfaces (XSS, injection).
 
-## Testing Review
+</details>
 
-### Test Coverage Assessment
+### Security — Authentication
 
-- [ ] **Unit Tests** - Adequate unit test coverage (target: 80%+)
-- [ ] **Integration Tests** - Integration scenarios covered
-- [ ] **End-to-End Tests** - Critical user journeys tested
-- [ ] **Edge Cases** - Boundary conditions and edge cases tested
-- [ ] **Error Scenarios** - Error conditions and recovery tested
-- [ ] **Performance Tests** - Performance requirements validated
+**Verdict:** [green | yellow | red | not assessed] — [one-line]
 
-### Test Quality Review
+<details>
+<summary>Details</summary>
 
-- [ ] **Test Clarity** - Tests are clear and well-named
-- [ ] **Test Independence** - Tests don't depend on each other
-- [ ] **Test Data** - Test data is appropriate and realistic
-- [ ] **Mocking** - External dependencies properly mocked
-- [ ] **Assertions** - Assertions are specific and meaningful
-- [ ] **Test Organization** - Tests are well-organized and grouped
+- Authentication mechanisms on the changed paths.
 
-### Testing Feedback
+</details>
 
-```text
-Current Coverage: XX%
-New Coverage: XX%
-Coverage Change: +/-XX%
+### Security — Authorization
 
-Test Results: ✅ All Passing / ❌ X Failing
-Performance Tests: ✅ Within Limits / ⚠️ Degradation Detected
-```
+**Verdict:** [green | yellow | red | not assessed] — [one-line]
 
-## Performance Review
+<details>
+<summary>Details</summary>
 
-### Performance Analysis
+- Access-control enforcement on the changed paths.
 
-- [ ] **Response Time** - API response times within acceptable limits
-- [ ] **Memory Usage** - Memory consumption is reasonable
-- [ ] **Database Performance** - Database queries are optimized
-- [ ] **Caching** - Appropriate caching strategies implemented
-- [ ] **Resource Usage** - CPU and I/O usage is efficient
-- [ ] **Scalability** - Changes support system scalability
+</details>
 
-### Performance Metrics
+### Security — Introduced vulnerabilities
 
-| Metric           | Before | After | Change | Acceptable |
-| ---------------- | ------ | ----- | ------ | ---------- |
-| Response Time    | XXXms  | XXXms | +/-XX% | ✅/❌        |
-| Memory Usage     | XXXMb  | XXXMb | +/-XX% | ✅/❌        |
-| Database Queries | XX     | XX    | +/-XX  | ✅/❌        |
+**Verdict:** [green | yellow | red | not assessed] — [N introduced, N pre-existing]
 
-## Documentation Review
+<details>
+<summary>Details</summary>
 
-### Documentation Checklist
+| Severity | Category | File:location | Introduced / pre-existing | Recommendation |
+| -------- | -------- | ------------- | ------------------------- | -------------- |
+| [P0/P1]  | [OWASP]  | [file:line]   | [introduced]              | [fix]          |
 
-- [ ] **Code Comments** - Complex logic appropriately commented
-- [ ] **API Documentation** - API changes documented
-- [ ] **README Updates** - README reflects new functionality
-- [ ] **User Documentation** - User-facing documentation updated
-- [ ] **Technical Documentation** - Architecture/design docs updated
-- [ ] **Change Log** - Changes documented in CHANGELOG
+Any **introduced** red finding drives **CHANGES-REQUESTED** (introduced-red-security rule, defined by the security-assessment story #227/AC4 — not an AC of #228). Pre-existing findings are surfaced, not blocking.
 
-### Documentation Quality
+</details>
 
-- [ ] **Accuracy** - Documentation matches implementation
-- [ ] **Completeness** - All new features documented
-- [ ] **Clarity** - Documentation is clear and understandable
-- [ ] **Examples** - Appropriate examples provided
-- [ ] **Up-to-date** - Existing documentation updated
+### Cost
 
-## Detailed Review Comments
+**Verdict:** `cost:<class>` — [one-line rationale]
 
-### Positive Feedback
+<details>
+<summary>Details</summary>
 
-#### What's Done Well:
+| Signal | Class | Provider | Note |
+| ------ | ----- | -------- | ---- |
+| [signal] | [color] | [stack] | [note] |
 
-- [Specific positive observations about code quality, approach, or implementation]
-- [Recognition of good practices, clever solutions, or improvements]
-- [Appreciation for thorough testing or documentation]
+Feeds from `/assess-cost` against the diff. A **red** cost class surfaces a **blocking human sign-off** requirement in the Verdict area. Capability absent → not assessed.
 
-### Issues to Address
+</details>
 
-#### Critical Issues ⚠️
+### Architecture (Coupling)
 
-#### Must fix before merge:
+**Verdict:** [green | yellow | red | not assessed] — [one-line balance verdict]
 
-- [ ] **[File:Line]** - [Critical issue description and impact]
-- [ ] **[File:Line]** - [Another critical issue requiring resolution]
+<details>
+<summary>Details</summary>
 
-#### Major Issues 🔍
+- Integration strength / socio-technical distance / volatility on the integrations the diff touches.
+- Feeds from `/assess-coupling` (`$scope: diff`). Capability absent (until #263) → not assessed.
 
-#### Should fix before merge:
+</details>
 
-- [ ] **[File:Line]** - [Major issue description and suggested solution]
-- [ ] **[File:Line]** - [Another major issue with improvement recommendation]
+## Details
 
-#### Minor Issues 💡
+<details>
+<summary>Findings by severity</summary>
 
-#### Consider addressing:
+**Critical (must fix before merge)**
 
-- [ ] **[File:Line]** - [Minor improvement suggestion]
-- [ ] **[File:Line]** - [Code style or best practice recommendation]
+- [ ] **[File:Line]** — [issue + impact]
 
-#### Questions ❓
+**Major (should fix before merge)**
 
-#### Clarification needed:
+- [ ] **[File:Line]** — [issue + suggested fix]
 
-- [ ] **[File:Line]** - [Question about implementation approach or decision]
-- [ ] **[File:Line]** - [Request for explanation of complex logic]
+**Minor (consider)**
 
-## Suggestions and Improvements
+- [ ] **[File:Line]** — [suggestion]
 
-### Code Improvements
+**Questions**
 
-```diff
-[Suggested code change in diff format]
-```
+- [ ] **[File:Line]** — [clarification]
 
-### Architecture Suggestions
+</details>
 
-- [Suggestion for better design pattern or architectural approach]
-- [Recommendation for improved separation of concerns]
-- [Advice on better abstraction or interface design]
+<details>
+<summary>Positive feedback</summary>
 
-### Best Practices
+<!-- Feedback bucket, NOT a severity — kept outside "Findings by severity" so the contract-generator's severity extraction (the severity labels under that grouping) stays clean. -->
 
-- [Recommendation for following established team practices]
-- [Suggestion for improved error handling patterns]
-- [Advice on better testing strategies]
+- [what's done well]
 
-## Risk Assessment
+</details>
 
-### Technical Risks
+<details>
+<summary>Functionality & requirements (AC coverage)</summary>
 
-| Risk               | Impact       | Probability  | Mitigation            |
-| ------------------ | ------------ | ------------ | --------------------- |
-| [Technical risk]   | High/Med/Low | High/Med/Low | [Mitigation strategy] |
-| [Integration risk] | High/Med/Low | High/Med/Low | [Risk reduction plan] |
+- [ ] Acceptance criteria met
+- [ ] Business logic + edge cases correct
+- [ ] Integrates with existing systems
+- [ ] Error handling appropriate
 
-### Business Risks
+</details>
 
-| Risk            | Impact       | Probability  | Mitigation             |
-| --------------- | ------------ | ------------ | ---------------------- |
-| [Business risk] | High/Med/Low | High/Med/Low | [Business mitigation]  |
-| [User impact]   | High/Med/Low | High/Med/Low | [User experience plan] |
+<details>
+<summary>Testing & quality gates</summary>
 
-## Deployment Considerations
+- [ ] Adequate coverage (unit / integration / e2e as applicable)
+- [ ] Edge + error scenarios tested
+- [ ] Quality gates: [PASS | FAIL — which]
 
-### Deployment Checklist
+</details>
 
-- [ ] **Database Migration** - Migration scripts reviewed and tested
-- [ ] **Configuration** - Environment configuration reviewed
-- [ ] **Feature Flags** - Feature toggles properly configured
-- [ ] **Rollback Plan** - Rollback procedure defined and tested
-- [ ] **Monitoring** - Appropriate monitoring and alerting in place
-- [ ] **Documentation** - Deployment documentation updated
+<details>
+<summary>Adoption compliance</summary>
 
-### Post-Deployment Monitoring
+- Degradation level: [1–4]
+- Dependencies match `tech-stack.md`; patterns match `architecture.md`
+- ADRs present for new technical decisions (missing ADR → CHANGES-REQUESTED)
 
-- [ ] **Error Rates** - Monitor error rate changes
-- [ ] **Performance Metrics** - Track performance indicators
-- [ ] **User Behavior** - Monitor user interaction patterns
-- [ ] **System Health** - Overall system health monitoring
+</details>
 
-## Follow-up Actions
+<details>
+<summary>Tech debt</summary>
 
-### Author Action Items
+- Items flagged by `/analyze-debt` (surfaced, never blocking on debt grounds alone).
 
-- [ ] **[Priority]** - [Action item for the author to complete]
-- [ ] **[Priority]** - [Another action item with deadline if applicable]
-- [ ] **[Priority]** - [Follow-up task or improvement]
+</details>
 
-### Reviewer Follow-up
+<details>
+<summary>Documentation</summary>
 
-- [ ] **Re-review** - Schedule re-review after changes
-- [ ] **Pair Programming** - Offer pairing session for complex issues
-- [ ] **Knowledge Sharing** - Share relevant resources or documentation
+- [ ] Code / API / user / architecture docs updated as applicable.
 
-### Team Actions
+</details>
 
-- [ ] **Process Improvement** - Identify process improvements from this review
-- [ ] **Standards Update** - Update coding standards based on findings
-- [ ] **Training Need** - Identify training opportunities for team
+<details>
+<summary>Performance & deployment</summary>
 
-## Review Timeline
+<!-- Lightweight prompt only — kept collapsed so it does not compete with the verdict for the 30s budget. -->
 
-### Review Process
+- [ ] No performance regression on hot paths (added queries / N+1, large allocations, sync work on the request path).
+- [ ] Deployment / rollback considered (reversible migrations, feature-flag or staged rollout, a known rollback path).
 
-- **Review Started:** [YYYY-MM-DD HH:MM]
-- **Initial Review Completed:** [YYYY-MM-DD HH:MM]
-- **Changes Requested:** [YYYY-MM-DD HH:MM]
-- **Changes Made:** [YYYY-MM-DD HH:MM]
-- **Final Approval:** [YYYY-MM-DD HH:MM]
-
-### Review Effort
-
-- **Time Spent Reviewing:** [XX hours]
-- **Complexity Level:** [Low/Medium/High]
-- **Review Thoroughness:** [Quick/Standard/Deep]
+</details>
 
 ---
 
diff --git a/.pair/knowledge/how-to/11-how-to-code-review.md b/.pair/knowledge/how-to/11-how-to-code-review.md
index f6914ba6..c9561ffe 100644
--- a/.pair/knowledge/how-to/11-how-to-code-review.md
+++ b/.pair/knowledge/how-to/11-how-to-code-review.md
@@ -91,8 +91,8 @@ Follow [project management tool guidelines](../guidelines/collaboration/project-
 
 ### Phase 3: Review Report & Decision
 
-1. **Generate review report** using [code-review-template.md](../guidelines/collaboration/templates/code-review-template.md)
-2. **Post report as PR comment** with all findings by severity
+1. **Generate a verdict-first review report** using [code-review-template.md](../guidelines/collaboration/templates/code-review-template.md) — classification tags + 1-line verdict at the top (~30-second reading budget, D22), assessment sections (security / cost / architecture) collapsed
+2. **Submit the report as the native review body** (verdict = the review action: Approve / Request Changes / Comment) — no separate PR comment (Q5)
 3. **Set PR status** based on findings:
 
 #### Review Decisions:
@@ -120,7 +120,7 @@ Follow [project management tool guidelines](../guidelines/collaboration/project-
 - [ ] ADR and adoption compliance validated for all new technical decisions
 - [ ] All technical standards verified against adoption guidelines
 - [ ] Review report generated using [code-review-template.md](../guidelines/collaboration/templates/code-review-template.md)
-- [ ] Report posted as PR comment
+- [ ] Report submitted as the native review body (verdict-first, no separate comment)
 - [ ] PR status updated (pending/changes-requested/approved)
 - [ ] Review decision made
 
diff --git a/apps/website/content/docs/developer-journey/execution.mdx b/apps/website/content/docs/developer-journey/execution.mdx
index 118fb4bc..036130d0 100644
--- a/apps/website/content/docs/developer-journey/execution.mdx
+++ b/apps/website/content/docs/developer-journey/execution.mdx
@@ -74,9 +74,9 @@ Review a pull request through a structured 6-phase process.
 ### The Review Phases
 
 ```text
-Phase 1 ── Validation ────── PR structure, linked story, template compliance
+Phase 1 ── Validation ────── PR structure, linked story, classification (risk floor)
        │
-Phase 2 ── Technical ─────── Code quality, architecture match, security
+Phase 2 ── Technical ─────── Code quality, security, cost, architecture (coupling)
        │
 Phase 3 ── Adoption ──────── Libraries match tech-stack.md, patterns match architecture.md
        │
@@ -87,6 +87,14 @@ Phase 5 ── Decision ──────── APPROVED, CHANGES REQUESTED, or
 Phase 6 ── Merge ─────────── Merge PR, update story/epic/initiative status
 ```
 
+### The Verdict-First Review Body
+
+The review is submitted as the **native GitHub review** (the verdict *is* the Approve / Request Changes / Comment action) — there is no separate review comment. Its body is **verdict-first** so a reader understands the outcome in about 30 seconds (D22):
+
+- **Top:** classification tags (`risk:<tier>` · `cost:<class>`), the decision, and a one-line reason. If the review-time classification differs from the story's refinement-time one, a **Classification changed** line states the change — it only ever fires *upward* (the review value is a floor: it may raise a tier, never lower it).
+- **Assessments** (each a one-line verdict, details collapsed): security — input validation, output handling, authentication, authorization, introduced vulnerabilities (from `/pair-capability-assess-security`); **cost** class (from `/pair-capability-assess-cost`); **architecture / coupling** balance (from `/pair-capability-assess-coupling`).
+- When a capability is not installed, its section reads **not assessed** — explicit, never silently dropped.
+
 ### ADR Enforcement
 
 If the review detects a new library not listed in `tech-stack.md` or an architecture pattern not recorded in `architecture.md`, it **blocks** and requests an Architecture Decision Record before approval. This ensures every technical choice is deliberate and documented.
diff --git a/packages/knowledge-hub/dataset/.pair/knowledge/guidelines/collaboration/templates/code-review-template.md b/packages/knowledge-hub/dataset/.pair/knowledge/guidelines/collaboration/templates/code-review-template.md
index 7cacec41..da1a7b56 100644
--- a/packages/knowledge-hub/dataset/.pair/knowledge/guidelines/collaboration/templates/code-review-template.md
+++ b/packages/knowledge-hub/dataset/.pair/knowledge/guidelines/collaboration/templates/code-review-template.md
@@ -1,279 +1,209 @@
 # Code Review Template
 
-## Review Information
+> **Verdict-first (D22, R6.6).** This is the **native GitHub review body** submitted with the review action (Approve / Request Changes / Comment). In `/pair-process-review`'s own self-review flow it is submitted as that native review body — **not a separate PR comment** (decision Q5). (An independent reviewer agent, or a self-authored PR where GitHub blocks self-approval, delivers this **same body** via a PR comment instead — see `.claude/agents/reviewer.md` and review Step 5.3; the artifact is identical, only the delivery event differs.) The top of the body — classification tags, tier, cost class and the 1-line verdict — reads in **~30 seconds**; every assessment is a 1-line verdict with the breakdown collapsed in `<details>`. A reader scanning the top understands verdict, tier and cost class inside the 30-second reading budget without opening a single `<details>`.
+>
+> **Not assessed is explicit.** When the backing capability is missing or failed (`/assess-security`, `/assess-cost`, `/assess-coupling`), the section verdict reads **not assessed** — never silently omitted.
 
-**PR Number:** [#XXX]  
-**Author:** [Developer name]  
-**Reviewer:** [Your name]  
-**Review Date:** [YYYY-MM-DD]  
-**Story/Epic:** [US-XXX or EP-XXX]  
-**Review Type:** [Feature/Bug Fix/Refactor/Hotfix]  
-**Estimated Review Time:** [XX minutes]
+## Verdict
 
-## Review Summary
+`risk:<tier>` · `cost:<class>` — **[APPROVED | CHANGES-REQUESTED | TECH-DEBT]** — [one-line reason]
 
-### Overall Assessment
+<!-- Unassessed-chip fallback: the chip is NEVER dropped — the verdict line always carries both `risk:` and `cost:` prefixes and stays scannable. `cost:n/a` renders when `/assess-cost` is absent (cost is a single-source dimension). `risk:n/a` renders ONLY when `/classify` is entirely absent (no matrix at all, per skill Step 1.5) — a single unassessed dimension (Security relevance, or Coupling until #263) is EXCLUDED from `max(assessed)` (§3.1 / D21), NOT propagated to the tier, so the risk chip still shows the max of the other assessed dimensions. `n/a` is a rendering placeholder, not a tag value (no `cost:not assessed` / `risk:not assessed` tag is ever emitted). This keeps the top-line degradation consistent with the section degradation, whose collapsed body reads "not assessed". -->
 
-- [ ] **Approved** - Ready to merge
-- [ ] **Approved with Comments** - Minor issues noted, can merge
-- [ ] **Request Changes** - Issues must be addressed before merge
-- [ ] **Comment Only** - Feedback provided, no blocking issues
+<!-- Classification-changed drift note: include ONLY when the review-time tier/cost differs from the story's refinement-time classification. Raise-only per quality-model §3.2 / D17 — a drift note fires upward, never records a silent downgrade. Omit the line entirely when unchanged. -->
+> **Classification changed:** `risk:<from>` → `risk:<to>` — [one-line reason]
 
-### Key Changes Summary
+**PR:** [#XXX] · **Author:** [name] · **Reviewer:** [name] · **Date:** [YYYY-MM-DD] · **Story:** [US-XXX] · **Type:** [feature | bug | refactor | docs | config]
 
-[Brief summary of what was reviewed and the main changes]
+<details>
+<summary>Classification matrix — per dimension</summary>
 
-### Business Value Validation
+| Dimension                   | Tier    | Source                     | Note              |
+| --------------------------- | ------- | -------------------------- | ----------------- |
+| Service/domain criticality  | [color] | [KB default / table]       | [note]            |
+| Change/diff risk            | [color] | [diff footprint]           | [note]            |
+| Business impact             | [color] | [subdomain class]          | [note]            |
+| Security relevance          | [color] | `/assess-security`         | [raise-only, D17] |
+| Coupling balance            | [color] | `/assess-coupling`         | [not assessed until #263] |
 
-[Confirm the changes deliver the expected business value]
+Tier = max(assessed). Cost = highest detected signal. Review value is a **floor** (D17): confirm or raise, never lower.
 
-## Code Review Checklist
+</details>
 
-### Functionality Review
+## Assessments
 
-- [ ] **Requirements Met** - Implementation matches acceptance criteria
-- [ ] **Business Logic** - Logic is correct and handles edge cases
-- [ ] **User Experience** - Changes improve or maintain user experience
-- [ ] **Integration** - Works correctly with existing systems
-- [ ] **Error Handling** - Appropriate error handling and recovery
-- [ ] **Performance** - No performance regressions introduced
+Each assessment is a **1-line verdict**; open the `<details>` for the breakdown. An unavailable capability shows **not assessed** (the section is never dropped).
 
-### Code Quality Assessment
+### Security — Input validation
 
-- [ ] **Readability** - Code is clear and easy to understand
-- [ ] **Maintainability** - Code is organized and well-structured
-- [ ] **Reusability** - Common functionality properly abstracted
-- [ ] **Naming** - Variables, functions, and classes well-named
-- [ ] **Comments** - Appropriate documentation and comments
-- [ ] **Complexity** - Code complexity is reasonable and justified
+**Verdict:** [green | yellow | red | not assessed] — [one-line]
 
-### Technical Standards Compliance
+<details>
+<summary>Details</summary>
 
-- [ ] **Style Guide** - Follows established coding standards
-- [ ] **Architecture** - Aligns with system architecture principles
-- [ ] **Design Patterns** - Uses appropriate design patterns
-- [ ] **Dependencies** - Dependencies are justified and minimal
-- [ ] **API Design** - API changes are backward compatible
-- [ ] **Database** - Database changes are optimized and indexed
+- Inputs touched by the diff and whether each is validated / sanitized.
+- Feeds from `/assess-security` (`$mode: review`).
 
-## Security Review
+</details>
 
-### Security Checklist
+### Security — Output handling
 
-- [ ] **Input Validation** - All user inputs properly validated
-- [ ] **Output Encoding** - Data properly encoded for output
-- [ ] **Authentication** - Authentication mechanisms properly implemented
-- [ ] **Authorization** - Access controls correctly enforced
-- [ ] **Data Protection** - Sensitive data properly handled
-- [ ] **Dependency Security** - No known security vulnerabilities
-- [ ] **Secrets Management** - No hardcoded secrets or credentials
-- [ ] **HTTPS/TLS** - Secure communication protocols used
+**Verdict:** [green | yellow | red | not assessed] — [one-line]
 
-### Security Concerns
+<details>
+<summary>Details</summary>
 
-| Concern   | Severity        | Description   | Recommendation |
-| --------- | --------------- | ------------- | -------------- |
-| [Issue 1] | High/Medium/Low | [Description] | [How to fix]   |
-| [Issue 2] | High/Medium/Low | [Description] | [How to fix]   |
+- Output encoding / escaping on the touched surfaces (XSS, injection).
 
-## Testing Review
+</details>
 
-### Test Coverage Assessment
+### Security — Authentication
 
-- [ ] **Unit Tests** - Adequate unit test coverage (target: 80%+)
-- [ ] **Integration Tests** - Integration scenarios covered
-- [ ] **End-to-End Tests** - Critical user journeys tested
-- [ ] **Edge Cases** - Boundary conditions and edge cases tested
-- [ ] **Error Scenarios** - Error conditions and recovery tested
-- [ ] **Performance Tests** - Performance requirements validated
+**Verdict:** [green | yellow | red | not assessed] — [one-line]
 
-### Test Quality Review
+<details>
+<summary>Details</summary>
 
-- [ ] **Test Clarity** - Tests are clear and well-named
-- [ ] **Test Independence** - Tests don't depend on each other
-- [ ] **Test Data** - Test data is appropriate and realistic
-- [ ] **Mocking** - External dependencies properly mocked
-- [ ] **Assertions** - Assertions are specific and meaningful
-- [ ] **Test Organization** - Tests are well-organized and grouped
+- Authentication mechanisms on the changed paths.
 
-### Testing Feedback
+</details>
 
-```text
-Current Coverage: XX%
-New Coverage: XX%
-Coverage Change: +/-XX%
+### Security — Authorization
 
-Test Results: ✅ All Passing / ❌ X Failing
-Performance Tests: ✅ Within Limits / ⚠️ Degradation Detected
-```
+**Verdict:** [green | yellow | red | not assessed] — [one-line]
 
-## Performance Review
+<details>
+<summary>Details</summary>
 
-### Performance Analysis
+- Access-control enforcement on the changed paths.
 
-- [ ] **Response Time** - API response times within acceptable limits
-- [ ] **Memory Usage** - Memory consumption is reasonable
-- [ ] **Database Performance** - Database queries are optimized
-- [ ] **Caching** - Appropriate caching strategies implemented
-- [ ] **Resource Usage** - CPU and I/O usage is efficient
-- [ ] **Scalability** - Changes support system scalability
+</details>
 
-### Performance Metrics
+### Security — Introduced vulnerabilities
 
-| Metric           | Before | After | Change | Acceptable |
-| ---------------- | ------ | ----- | ------ | ---------- |
-| Response Time    | XXXms  | XXXms | +/-XX% | ✅/❌        |
-| Memory Usage     | XXXMb  | XXXMb | +/-XX% | ✅/❌        |
-| Database Queries | XX     | XX    | +/-XX  | ✅/❌        |
+**Verdict:** [green | yellow | red | not assessed] — [N introduced, N pre-existing]
 
-## Documentation Review
+<details>
+<summary>Details</summary>
 
-### Documentation Checklist
+| Severity | Category | File:location | Introduced / pre-existing | Recommendation |
+| -------- | -------- | ------------- | ------------------------- | -------------- |
+| [P0/P1]  | [OWASP]  | [file:line]   | [introduced]              | [fix]          |
 
-- [ ] **Code Comments** - Complex logic appropriately commented
-- [ ] **API Documentation** - API changes documented
-- [ ] **README Updates** - README reflects new functionality
-- [ ] **User Documentation** - User-facing documentation updated
-- [ ] **Technical Documentation** - Architecture/design docs updated
-- [ ] **Change Log** - Changes documented in CHANGELOG
+Any **introduced** red finding drives **CHANGES-REQUESTED** (introduced-red-security rule, defined by the security-assessment story #227/AC4 — not an AC of #228). Pre-existing findings are surfaced, not blocking.
 
-### Documentation Quality
+</details>
 
-- [ ] **Accuracy** - Documentation matches implementation
-- [ ] **Completeness** - All new features documented
-- [ ] **Clarity** - Documentation is clear and understandable
-- [ ] **Examples** - Appropriate examples provided
-- [ ] **Up-to-date** - Existing documentation updated
+### Cost
 
-## Detailed Review Comments
+**Verdict:** `cost:<class>` — [one-line rationale]
 
-### Positive Feedback
+<details>
+<summary>Details</summary>
 
-#### What's Done Well:
+| Signal | Class | Provider | Note |
+| ------ | ----- | -------- | ---- |
+| [signal] | [color] | [stack] | [note] |
 
-- [Specific positive observations about code quality, approach, or implementation]
-- [Recognition of good practices, clever solutions, or improvements]
-- [Appreciation for thorough testing or documentation]
+Feeds from `/assess-cost` against the diff. A **red** cost class surfaces a **blocking human sign-off** requirement in the Verdict area. Capability absent → not assessed.
 
-### Issues to Address
+</details>
 
-#### Critical Issues ⚠️
+### Architecture (Coupling)
 
-#### Must fix before merge:
+**Verdict:** [green | yellow | red | not assessed] — [one-line balance verdict]
 
-- [ ] **[File:Line]** - [Critical issue description and impact]
-- [ ] **[File:Line]** - [Another critical issue requiring resolution]
+<details>
+<summary>Details</summary>
 
-#### Major Issues 🔍
+- Integration strength / socio-technical distance / volatility on the integrations the diff touches.
+- Feeds from `/assess-coupling` (`$scope: diff`). Capability absent (until #263) → not assessed.
 
-#### Should fix before merge:
+</details>
 
-- [ ] **[File:Line]** - [Major issue description and suggested solution]
-- [ ] **[File:Line]** - [Another major issue with improvement recommendation]
+## Details
 
-#### Minor Issues 💡
+<details>
+<summary>Findings by severity</summary>
 
-#### Consider addressing:
+**Critical (must fix before merge)**
 
-- [ ] **[File:Line]** - [Minor improvement suggestion]
-- [ ] **[File:Line]** - [Code style or best practice recommendation]
+- [ ] **[File:Line]** — [issue + impact]
 
-#### Questions ❓
+**Major (should fix before merge)**
 
-#### Clarification needed:
+- [ ] **[File:Line]** — [issue + suggested fix]
 
-- [ ] **[File:Line]** - [Question about implementation approach or decision]
-- [ ] **[File:Line]** - [Request for explanation of complex logic]
+**Minor (consider)**
 
-## Suggestions and Improvements
+- [ ] **[File:Line]** — [suggestion]
 
-### Code Improvements
+**Questions**
 
-```diff
-[Suggested code change in diff format]
-```
+- [ ] **[File:Line]** — [clarification]
 
-### Architecture Suggestions
+</details>
 
-- [Suggestion for better design pattern or architectural approach]
-- [Recommendation for improved separation of concerns]
-- [Advice on better abstraction or interface design]
+<details>
+<summary>Positive feedback</summary>
 
-### Best Practices
+<!-- Feedback bucket, NOT a severity — kept outside "Findings by severity" so the contract-generator's severity extraction (the severity labels under that grouping) stays clean. -->
 
-- [Recommendation for following established team practices]
-- [Suggestion for improved error handling patterns]
-- [Advice on better testing strategies]
+- [what's done well]
 
-## Risk Assessment
+</details>
 
-### Technical Risks
+<details>
+<summary>Functionality & requirements (AC coverage)</summary>
 
-| Risk               | Impact       | Probability  | Mitigation            |
-| ------------------ | ------------ | ------------ | --------------------- |
-| [Technical risk]   | High/Med/Low | High/Med/Low | [Mitigation strategy] |
-| [Integration risk] | High/Med/Low | High/Med/Low | [Risk reduction plan] |
+- [ ] Acceptance criteria met
+- [ ] Business logic + edge cases correct
+- [ ] Integrates with existing systems
+- [ ] Error handling appropriate
 
-### Business Risks
+</details>
 
-| Risk            | Impact       | Probability  | Mitigation             |
-| --------------- | ------------ | ------------ | ---------------------- |
-| [Business risk] | High/Med/Low | High/Med/Low | [Business mitigation]  |
-| [User impact]   | High/Med/Low | High/Med/Low | [User experience plan] |
+<details>
+<summary>Testing & quality gates</summary>
 
-## Deployment Considerations
+- [ ] Adequate coverage (unit / integration / e2e as applicable)
+- [ ] Edge + error scenarios tested
+- [ ] Quality gates: [PASS | FAIL — which]
 
-### Deployment Checklist
+</details>
 
-- [ ] **Database Migration** - Migration scripts reviewed and tested
-- [ ] **Configuration** - Environment configuration reviewed
-- [ ] **Feature Flags** - Feature toggles properly configured
-- [ ] **Rollback Plan** - Rollback procedure defined and tested
-- [ ] **Monitoring** - Appropriate monitoring and alerting in place
-- [ ] **Documentation** - Deployment documentation updated
+<details>
+<summary>Adoption compliance</summary>
 
-### Post-Deployment Monitoring
+- Degradation level: [1–4]
+- Dependencies match `tech-stack.md`; patterns match `architecture.md`
+- ADRs present for new technical decisions (missing ADR → CHANGES-REQUESTED)
 
-- [ ] **Error Rates** - Monitor error rate changes
-- [ ] **Performance Metrics** - Track performance indicators
-- [ ] **User Behavior** - Monitor user interaction patterns
-- [ ] **System Health** - Overall system health monitoring
+</details>
 
-## Follow-up Actions
+<details>
+<summary>Tech debt</summary>
 
-### Author Action Items
+- Items flagged by `/analyze-debt` (surfaced, never blocking on debt grounds alone).
 
-- [ ] **[Priority]** - [Action item for the author to complete]
-- [ ] **[Priority]** - [Another action item with deadline if applicable]
-- [ ] **[Priority]** - [Follow-up task or improvement]
+</details>
 
-### Reviewer Follow-up
+<details>
+<summary>Documentation</summary>
 
-- [ ] **Re-review** - Schedule re-review after changes
-- [ ] **Pair Programming** - Offer pairing session for complex issues
-- [ ] **Knowledge Sharing** - Share relevant resources or documentation
+- [ ] Code / API / user / architecture docs updated as applicable.
 
-### Team Actions
+</details>
 
-- [ ] **Process Improvement** - Identify process improvements from this review
-- [ ] **Standards Update** - Update coding standards based on findings
-- [ ] **Training Need** - Identify training opportunities for team
+<details>
+<summary>Performance & deployment</summary>
 
-## Review Timeline
+<!-- Lightweight prompt only — kept collapsed so it does not compete with the verdict for the 30s budget. -->
 
-### Review Process
+- [ ] No performance regression on hot paths (added queries / N+1, large allocations, sync work on the request path).
+- [ ] Deployment / rollback considered (reversible migrations, feature-flag or staged rollout, a known rollback path).
 
-- **Review Started:** [YYYY-MM-DD HH:MM]
-- **Initial Review Completed:** [YYYY-MM-DD HH:MM]
-- **Changes Requested:** [YYYY-MM-DD HH:MM]
-- **Changes Made:** [YYYY-MM-DD HH:MM]
-- **Final Approval:** [YYYY-MM-DD HH:MM]
-
-### Review Effort
-
-- **Time Spent Reviewing:** [XX hours]
-- **Complexity Level:** [Low/Medium/High]
-- **Review Thoroughness:** [Quick/Standard/Deep]
+</details>
 
 ---
 
diff --git a/packages/knowledge-hub/dataset/.pair/knowledge/how-to/11-how-to-code-review.md b/packages/knowledge-hub/dataset/.pair/knowledge/how-to/11-how-to-code-review.md
index a1c1f3c8..de5cc305 100644
--- a/packages/knowledge-hub/dataset/.pair/knowledge/how-to/11-how-to-code-review.md
+++ b/packages/knowledge-hub/dataset/.pair/knowledge/how-to/11-how-to-code-review.md
@@ -91,8 +91,8 @@ Follow [project management tool guidelines](../guidelines/collaboration/project-
 
 ### Phase 3: Review Report & Decision
 
-1. **Generate review report** using [code-review-template.md](../guidelines/collaboration/templates/code-review-template.md)
-2. **Post report as PR comment** with all findings by severity
+1. **Generate a verdict-first review report** using [code-review-template.md](../guidelines/collaboration/templates/code-review-template.md) — classification tags + 1-line verdict at the top (~30-second reading budget, D22), assessment sections (security / cost / architecture) collapsed
+2. **Submit the report as the native review body** (verdict = the review action: Approve / Request Changes / Comment) — no separate PR comment (Q5)
 3. **Set PR status** based on findings:
 
 #### Review Decisions:
@@ -120,7 +120,7 @@ Follow [project management tool guidelines](../guidelines/collaboration/project-
 - [ ] ADR and adoption compliance validated for all new technical decisions
 - [ ] All technical standards verified against adoption guidelines
 - [ ] Review report generated using [code-review-template.md](../guidelines/collaboration/templates/code-review-template.md)
-- [ ] Report posted as PR comment
+- [ ] Report submitted as the native review body (verdict-first, no separate comment)
 - [ ] PR status updated (pending/changes-requested/approved)
 - [ ] Review decision made
 
diff --git a/packages/knowledge-hub/dataset/.skills/capability/assess-security/SKILL.md b/packages/knowledge-hub/dataset/.skills/capability/assess-security/SKILL.md
index 2cf55825..0cad0869 100644
--- a/packages/knowledge-hub/dataset/.skills/capability/assess-security/SKILL.md
+++ b/packages/knowledge-hub/dataset/.skills/capability/assess-security/SKILL.md
@@ -58,7 +58,7 @@ Every rule the skill applies is resolved through the same layered set, most-spec
 ### Step 4: Emit Review Verdict
 
 1. **Act**: Compute the overall verdict = highest severity among introduced findings (pre-existing findings are reported but don't raise the verdict past what introduced findings justify, consistent with the review floor in quality-model.md §3.2: this review pass may only raise the tier's Security relevance dimension, never lower a value the story's own refinement-time assessment already set).
-2. **Act**: Render the 1-line verdict + collapsed findings list (severity, rule/category, file:location) per Output Format below — output-only, no files written; this is embedded by the caller into the review report's Security Review section (D22 — verdict in ~1 line, details in `<details>`).
+2. **Act**: Render the 1-line verdict + collapsed findings list (severity, rule/category, file:location) per Output Format below — output-only, no files written; this is embedded by the caller into the review body's five Security sections (D22 — verdict in ~1 line, details in `<details>`).
 3. **Verify**: Verdict emitted. If any **introduced** finding is red → flag explicitly for the caller: this is the AC4 signal that drives `/review`'s CHANGES-REQUESTED decision (the decision itself stays `/review`'s, per its own Step 5.2 table — this skill only reports the finding).
 
 ## Audit Mode (one-shot)
@@ -133,7 +133,7 @@ SECURITY AUDIT COMPLETE:
 When composed by `/review` (Phase 2):
 
 - **Input**: `/review` invokes `/assess-security` with `$mode: review` against the PR diff.
-- **Output**: Returns the verdict + collapsed findings (Review Mode output above). `/review` embeds it verbatim into the review report's Security Review section and, if any introduced finding is red, factors it into its own CHANGES-REQUESTED decision (Step 5.2).
+- **Output**: Returns the verdict + collapsed findings (Review Mode output above). `/review` embeds it verbatim into the review body's five Security sections and, if any introduced finding is red, factors it into its own CHANGES-REQUESTED decision (Step 5.2).
 - **Persistence**: None — review mode writes nothing.
 
 When invoked **independently** in audit mode:
diff --git a/packages/knowledge-hub/dataset/.skills/process/review/SKILL.md b/packages/knowledge-hub/dataset/.skills/process/review/SKILL.md
index a4425d85..c06427f2 100644
--- a/packages/knowledge-hub/dataset/.skills/process/review/SKILL.md
+++ b/packages/knowledge-hub/dataset/.skills/process/review/SKILL.md
@@ -19,11 +19,13 @@ Review a pull request through 6 sequential phases (5 review + 1 optional merge).
 | `/record-decision`      | Capability | Yes      | Any   | Record missing ADR (HALT condition)          |
 | `/analyze-debt`         | Capability | Yes      | 4     | Flag tech debt items                         |
 | `/assess-security`      | Capability | Yes †    | 2     | Security posture verdict + findings (D22)    |
+| `/assess-cost`          | Capability | Yes †    | 2     | Cost class verdict + signals (D22)           |
+| `/assess-coupling`      | Capability | Optional | 2     | Architecture/coupling balance verdict (D22)  |
 | `/verify-adoption`      | Capability | Optional | 3     | Full adoption compliance                     |
 | `/assess-stack`         | Capability | Optional | 3     | Tech-stack resolution                        |
 | `/execute-manual-tests` | Capability | Optional | 6     | Post-merge release validation (manual tests) |
 
-† **Required _when installed_.** `/classify` and `/assess-security` carry Required = Yes because `/review` composes them by default — but both **degrade gracefully**: `/review` **warns and continues** when the skill is absent (`/classify` → Step 1.5 Skip; `/assess-security` → Step 2.4 / Graceful Degradation), never HALTing on their absence. "Required" here means _composed by default_, not _a hard prerequisite_, so the flag never contradicts the graceful-skip steps.
+† **Required _when installed_.** `/classify`, `/assess-security` and `/assess-cost` carry Required = Yes because `/review` composes them by default — but all **degrade gracefully**: `/review` **warns and continues** when the skill is absent (`/classify` → Step 1.5 Skip; `/assess-security` → Step 2.4; `/assess-cost` → Step 2.5; each also under Graceful Degradation), the affected section reading **not assessed**, never HALTing on their absence. `/assess-coupling` (#263) is Optional — until it ships the Architecture (Coupling) section reads **not assessed**. "Required" here means _composed by default_, not _a hard prerequisite_, so the flag never contradicts the graceful-skip steps.
 
 ## Arguments
 
@@ -98,8 +100,8 @@ Ask: _"Proceed with review?"_
 
 1. **Check**: Has `/classify` already run with `$context: review` on the current PR head commit?
 2. **Skip**: If already run — reuse the matrix + tier, move to Phase 2. If `/classify` is not installed → warn (`/classify not installed — no review-time risk matrix`) and move to Phase 2.
-3. **Act**: Compose `/classify` with `$context: review` against the PR diff. It applies the [quality model](../../../.pair/knowledge/guidelines/quality-assurance/quality-model.md) to the diff footprint, reads the story's refinement-time tier, and produces the review matrix as a **floor** — it confirms or **raises** the tier, and **never lowers** it (D17). The Security relevance and Coupling balance dimensions are reconciled in Phase 2 (Step 2.4) as `/assess-security` / `/assess-coupling` verdicts land — raise-only.
-4. **Verify**: The review matrix + `risk:*` tier are recorded on the PR (matrix in the body as 1 line + `<details>`, D22; tags applied only when a `## Tag Projection` is declared). This body matrix is the single rendered artifact — if Phase 2 raises Security relevance or Coupling balance, `/review` updates it **in place** (Step 2.4), it is not re-emitted by `/classify`. A raise to `risk:red` is carried into the Step 5.2 decision. `/classify` HALTs only if the quality model doc (#221) is absent.
+3. **Act**: Compose `/classify` with `$context: review` against the PR diff. It applies the [quality model](../../../.pair/knowledge/guidelines/quality-assurance/quality-model.md) to the diff footprint, reads the story's refinement-time tier, and produces the review matrix as a **floor** — it confirms or **raises** the tier, and **never lowers** it (D17). The Security relevance and Coupling balance dimensions are reconciled in Phase 2 (Steps 2.4 and 2.6) as `/assess-security` / `/assess-coupling` verdicts land — raise-only.
+4. **Verify**: The review matrix + `risk:*` tier are recorded on the **PR description** (matrix as 1 line + `<details>`, D22; tags applied only when a `## Tag Projection` is declared). This PR-description matrix is the **live, editable** copy — if Phase 2 raises Security relevance or Coupling balance, `/review` updates it **in place** (Step 2.4), it is not re-emitted by `/classify`. (Phase 5 additionally embeds a point-in-time **snapshot** of this matrix in the Verdict block of the review report; that copy belongs to the **append-only** native review body and is **never** edited in place — a post-submission raise surfaces in the next fresh review, see Step 5.3 / idempotency #5. So "in place" applies only to the editable PR description, not the review body.) A raise to `risk:red` is carried into the Step 5.2 decision. `/classify` HALTs only if the quality model doc (#221) is absent.
 
 ## Phase 2: Technical Review
 
@@ -137,9 +139,25 @@ Ask: _"Proceed with review?"_
 ### Step 2.4: Security Assessment
 
 1. **Check**: Has `/assess-security` already run with `$mode: review` on the current PR head commit?
-2. **Skip**: If already run — reuse the verdict + findings, move to Phase 3.
-3. **Act**: Compose `/assess-security` with `$mode: review` against the PR diff. It resolves the rule set (KB global + per-service + per-web-app + adoption project rules) and returns a 1-line verdict + collapsed findings, each tagged **introduced** or **pre-existing**.
-4. **Verify**: Verdict + findings recorded — feeds the Security Review section (Step 5.1) and the **Security relevance** dimension of the Step 1.5 classification matrix (`/classify` folds this verdict in **raise-only** — it may raise the tier, never lower it). **Body re-render**: when the verdict raises Security relevance (or the Coupling verdict raises Coupling balance), `/review` updates the already-written Step 1.5 body matrix **in place** — re-rendering the affected `<details>` row and the 1-line `risk:*` tier so the PR body reflects the final, raised tier; `/classify` is **not** re-invoked (its Phase-1 run stands, and a raise-only edit needs no recompute). **Tag re-apply**: when a `## Tag Projection` is declared (e.g. `Active: risk`), this in-place Phase-2-originated raise **also re-applies the projected chromatic tag on the PR** — swapping the stale label for the raised tier (e.g. `risk:yellow` → `risk:red`) via the same §5 projection `/classify` uses in its Step 5, applied here by `/review` on the raise-only edit — so the PR label matches the raised body tier (AC3); when no projection is declared, only the body matrix is updated and no label is touched. If any **introduced** finding is red → flag explicitly: this is the AC4 signal that drives the CHANGES-REQUESTED decision in Step 5.2. Does not itself HALT — `/assess-security` has no merge authority, this skill's own decision step does.
+2. **Skip**: If already run — reuse the verdict + findings, move to Step 2.5.
+3. **Act**: Compose `/assess-security` with `$mode: review` against the PR diff. It resolves the rule set (KB global + per-service + per-web-app + adoption project rules) and returns a 1-line verdict + collapsed findings, each tagged **introduced** or **pre-existing**. The verdict feeds the five verdict-first Security sections of the review body — **input validation, output handling, authentication, authorization, introduced vulnerabilities** (Step 5.1, per the [code-review-template](../../../.pair/knowledge/guidelines/collaboration/templates/code-review-template.md)).
+4. **Verify**: Verdict + findings recorded — feeds the Security sections (Step 5.1) and the **Security relevance** dimension of the Step 1.5 classification matrix (`/classify` folds this verdict in **raise-only** — it may raise the tier, never lower it). **PR-description re-render**: when the verdict raises Security relevance (or the Coupling verdict raises Coupling balance), `/review` updates the already-written Step 1.5 **PR-description** matrix **in place** — re-rendering the affected `<details>` row and the 1-line `risk:*` tier so the PR **description** reflects the final, raised tier (the append-only review body is never edited in place — Step 5.3); `/classify` is **not** re-invoked (its Phase-1 run stands, and a raise-only edit needs no recompute). **Tag re-apply**: when a `## Tag Projection` is declared (e.g. `Active: risk`), this in-place Phase-2-originated raise **also re-applies the projected chromatic tag on the PR** — swapping the stale label for the raised tier (e.g. `risk:yellow` → `risk:red`) via the same §5 projection `/classify` uses in its Step 5, applied here by `/review` on the raise-only edit — so the PR label matches the raised body tier (AC3); when no projection is declared, only the body matrix is updated and no label is touched. If any **introduced** finding is red → flag explicitly: this is the AC4 signal that drives the CHANGES-REQUESTED decision in Step 5.2. Does not itself HALT — `/assess-security` has no merge authority, this skill's own decision step does.
+5. **Degrade**: `/assess-security` not installed → the five Security sections read **not assessed** (never dropped); a manual security read of the diff is still expected.
+
+### Step 2.5: Cost Assessment
+
+1. **Check**: Has `/assess-cost` already run against the current PR head commit?
+2. **Skip**: If already run — reuse the class + signals, move to Step 2.6.
+3. **Act**: Compose `/assess-cost` against the PR diff. It resolves the cost-signal catalog from the project's stack/architecture/infrastructure adoption and returns the `cost:green|yellow|orange|red` class as a 1-line verdict + collapsed signals table (D22). This is a genuine re-assessment of the diff — never a restatement of the story's refinement-time `cost:*` tag.
+4. **Verify**: Class + signals recorded — feed the **Cost** section of the review body (Step 5.1, 1 line + `<details>`). The `cost:*` class is carried as its own dimension of the matrix (never folded into the risk `max`). A **red** cost class surfaces the **blocking human sign-off** requirement in the Verdict area (Step 5.1) and is carried into the Step 5.2 decision. Tag re-apply on the PR follows the same rule as Step 2.4 when `cost` is in the declared `## Tag Projection`. Does not itself HALT — `/assess-cost` has no merge authority.
+5. **Degrade**: `/assess-cost` not installed → the Cost section reads **not assessed** (never dropped).
+
+### Step 2.6: Architecture (Coupling) Assessment
+
+1. **Check**: Is `/assess-coupling` installed (ships with #263)?
+2. **Skip**: If not installed → the **Architecture (Coupling)** section reads **not assessed** explicitly; move to Phase 3.
+3. **Act**: Compose `/assess-coupling` with `$scope: diff`. It returns a 1-line balance verdict on the integrations the diff touches (integration strength, socio-technical distance, volatility) + collapsed findings (D22).
+4. **Verify**: Verdict + findings recorded — feed the **Architecture (Coupling)** section of the review body (Step 5.1) and the **Coupling balance** dimension of the Step 1.5 matrix (`/classify` folds it in **raise-only**, same in-place body re-render + tag re-apply rule as Step 2.4). Does not itself HALT.
 
 ## Phase 3: Adoption Compliance
 
@@ -191,17 +209,13 @@ Run the procedure for the level determined in Step 3.1 — see [degradation-leve
 
 ### Step 5.1: Compile Review Report
 
-1. **Act**: Compile all findings into a review report following the [code-review-template.md](../../../.pair/knowledge/guidelines/collaboration/templates/code-review-template.md) (resolve override-first — [template resolution](../../../.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/template-resolution.md)):
-   - **Review Information**: PR number, author, reviewer, date, story, review type
-   - **Review Summary**: overall assessment, key changes, business value
-   - **Code Review Checklist**: functionality, code quality, technical standards (from Phase 2)
-   - **Security Review**: verdict + collapsed findings from `/assess-security` (Step 2.4) — 1-line + `<details>` (D22)
-   - **Testing Review**: test coverage and quality (from /verify-quality)
-   - **Documentation Review**: documentation completeness (from /verify-done)
-   - **Detailed Review Comments**: issues by severity, positive feedback
-   - **Risk Assessment**: technical and business risks
-   - **Tech Debt**: items flagged by /analyze-debt
-   - **Adoption Compliance**: results from Phase 3 (with degradation level noted)
+1. **Act**: Compile all findings into a **verdict-first** review body following the [code-review-template.md](../../../.pair/knowledge/guidelines/collaboration/templates/code-review-template.md) (resolve override-first — [template resolution](../../../.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/template-resolution.md)). The body is ordered so verdict, tier and cost class read in **~30 seconds** (D22, R6.6):
+   - **Verdict** (top): classification tags (`risk:<tier>` · `cost:<class>`) + the decision + a 1-line reason + PR/author/story metadata. Include the **`Classification changed:`** drift note **only** when the review-time tier/cost differs from the story's refinement-time classification — it fires **upward only** (e.g. `risk:yellow` → `risk:red`, raise-only per quality-model §3.2 / D17); a review that would lower a dimension records the reduction as a finding in the collapsed details, never as a silent downgrade. A **red** cost class states the **blocking human sign-off** requirement here.
+   - **Assessments** (each a 1-line verdict + `<details>`, "not assessed" when the capability is absent):
+     - **Security — input validation, output handling, authentication, authorization, introduced vulnerabilities** (five verdicts from `/assess-security`, Step 2.4)
+     - **Cost** — `cost:*` class + signals (from `/assess-cost`, Step 2.5)
+     - **Architecture (Coupling)** — balance verdict (from `/assess-coupling`, Step 2.6; "not assessed" until #263)
+   - **Details** (collapsed): findings by severity + positive feedback (Phase 2); functionality / AC coverage; testing & quality gates (from /verify-quality); adoption compliance with degradation level (Phase 3); tech debt (from /analyze-debt); documentation (from /verify-done).
 
 ### Step 5.2: Make Review Decision
 
@@ -210,18 +224,21 @@ Based on compiled findings:
 | Decision              | Condition                                                                                 |
 | --------------------- | ----------------------------------------------------------------------------------------- |
 | **APPROVED**          | No critical or major issues. All AC met. Quality gates pass.                              |
-| **CHANGES-REQUESTED** | Critical issues found, missing ADRs, any **introduced** red security finding from `/assess-security` (AC4), failing tests, AC not met. |
+| **CHANGES-REQUESTED** | Critical issues found, missing ADRs, any **introduced** red security finding from `/assess-security` (AC4), failing tests, AC not met. A **red** `cost:*` class does not itself block — it surfaces a **blocking human sign-off** requirement in the Verdict (the human, not the skill, gates on cost). |
 | **TECH-DEBT**         | Only minor issues or debt items. Approve current PR, track debt separately.               |
 
-### Step 5.3: Post Review
+### Step 5.3: Submit Review
+
+The compiled report **is the body of the native GitHub review** — the verdict is the review action; there is **no separate PR comment** (decision Q5, AC2).
 
-1. **Act**: Post the review report as a PR comment.
-2. **Act**: Set PR review status using the PM tool (per [github-implementation.md](../../../.pair/knowledge/guidelines/collaboration/project-management-tool/github-implementation.md)):
-   - **APPROVED / TECH-DEBT**: Submit review with `event = APPROVE`.
-   - **CHANGES-REQUESTED**: Submit review with `event = REQUEST_CHANGES`.
-   - MCP-first: use `pull_request_review_write` with `method = create` and appropriate `event`.
-   - CLI fallback: `gh pr review <number> --approve` or `--request-changes`.
-3. **Verify**: Review posted and status updated.
+1. **Act**: Submit the native review using the PM tool (per [github-implementation.md](../../../.pair/knowledge/guidelines/collaboration/project-management-tool/github-implementation.md)), passing the compiled verdict-first report as the review **body**:
+   - **APPROVED / TECH-DEBT**: `event = APPROVE`.
+   - **CHANGES-REQUESTED**: `event = REQUEST_CHANGES`.
+   - MCP-first: `pull_request_review_write` with `method = create`, the report as `body`, and the appropriate `event`.
+   - CLI fallback: `gh pr review <number> --approve|--request-changes --body-file <report>`.
+   - **Self-authored PR** (solo/self-review): GitHub rejects `APPROVE` / `REQUEST_CHANGES` on your own PR. Submit the same verdict-first report with `event = COMMENT` (`gh pr review <number> --comment --body-file <report>`) — the verdict token (APPROVED / CHANGES-REQUESTED / TECH-DEBT) still leads the body, so the decision and full report are recorded, never lost. See Graceful Degradation.
+2. **Act**: On re-review, submit a **fresh** native review — both documented paths append (MCP `create`; `gh pr review` CLI), neither edits a submitted body. GitHub's latest-review-governs semantics mean the newest review carries the verdict while earlier reviews stay as visible history, so re-invocation is safe without editing in place (idempotency).
+3. **Verify**: The native review is submitted with the verdict-first body — no separate review-comment artifact exists.
 
 ### Step 5.4: Determine Next Action
 
@@ -249,12 +266,14 @@ REVIEW COMPLETE:
 ├── Story:      [#ID: Title | N/A]
 ├── Decision:   [APPROVED | CHANGES-REQUESTED | TECH-DEBT]
 ├── Issues:     [critical: N | major: N | minor: N]
-├── Security:   [green | yellow | red — N findings, N introduced | N/A — not installed]
+├── Security:   [green | yellow | red — N findings, N introduced | not assessed]
+├── Cost:       [green | yellow | orange | red | not assessed]
+├── Coupling:   [green | yellow | red | not assessed — until #263]
 ├── Quality:    [PASS | FAIL — N gates]
 ├── DoD:        [N/N criteria met]
 ├── Adoption:   [Level N — summary]
 ├── Debt:       [N items flagged]
-└── Report:     [Posted as PR comment]
+└── Review:     [Submitted as native review body — no separate comment]
 ```
 
 At merge (Phase 6): see [merge-and-cascade.md](merge-and-cascade.md).
@@ -277,7 +296,7 @@ See [idempotency convention](../../../.pair/knowledge/guidelines/technical-stand
 2. **Phases**: checks which phases completed (via session state or PR review comments). Resumes from first incomplete phase.
 3. **Skill compositions**: /verify-quality, /verify-done, /assess-security results cached in session. Not re-run if already passing/current on current commit.
 4. **New commits**: if PR updated since last check, re-validates affected phases only.
-5. **Review report**: updates existing report rather than posting duplicates.
+5. **Review report**: re-review appends a fresh native review (MCP `create` / `gh pr review`); GitHub's latest-review-governs semantics make the newest one carry the verdict while prior reviews remain as history. The report is always the review body, never a separate comment — so no duplicate comment artifact is created.
 6. **Merge**: detects already-merged PR. Skips Phase 6 if already merged. Resumes parent cascade if merge succeeded but status updates are incomplete.
 
 ## Graceful Degradation
@@ -287,7 +306,10 @@ See [graceful degradation](../../../.pair/knowledge/guidelines/technical-standar
 - **/verify-adoption not installed**: Falls back to inline dependency checking against [tech-stack.md](../../../.pair/adoption/tech/tech-stack.md). Warning logged. See degradation cascade (Phase 3).
 - **/assess-stack not installed**: Unlisted dependencies flagged as warnings for manual verification. Does NOT HALT.
 - **/analyze-debt not available**: Skip debt assessment, note in report.
-- **/assess-security not installed**: Skip Step 2.4. Security Review section notes "manual judgment only — /assess-security not installed". Does NOT HALT; a manual security read of the diff is still expected per [how-to-11](../../../.pair/knowledge/how-to/11-how-to-code-review.md).
+- **/assess-security not installed**: Skip Step 2.4. The five Security sections (input validation, output handling, authentication, authorization, introduced vulnerabilities) read **not assessed** — never dropped. Does NOT HALT; a manual security read of the diff is still expected per [how-to-11](../../../.pair/knowledge/how-to/11-how-to-code-review.md).
+- **/assess-cost not installed**: Skip Step 2.5. The Cost section reads **not assessed**. Does NOT HALT.
+- **/assess-coupling not installed** (until #263): Skip Step 2.6. The Architecture (Coupling) section reads **not assessed**. Does NOT HALT.
+- **Self-authored PR (self-review)**: GitHub blocks `APPROVE` / `REQUEST_CHANGES` on your own PR, so the native verdict action is rejected for solo authors. Fall back to `event = COMMENT` (`gh pr review <number> --comment --body-file <report>`), keeping the verdict token at the head of the body — the full verdict-first report is still recorded as a review, so nothing is lost (unlike a rejected APPROVE/REQUEST_CHANGES). Does NOT HALT.
 - **Story not found**: Review proceeds with PR-only validation (no AC check). Phase 6 skips parent cascade.
 - **Code review template not found**: **HALT** — cannot produce review without template (a required dependency, not optional).
 - **PM tool not accessible**: Phase 6 merge via CLI only.
@@ -297,7 +319,7 @@ See [graceful degradation](../../../.pair/knowledge/guidelines/technical-standar
 
 ## Notes
 
-- This skill **reads code, posts review comments, and optionally merges PRs** — it does not modify source code.
+- This skill **reads code, submits the native review (verdict = the review action), and optionally merges PRs** — it does not modify source code and posts no separate review comment (AC2).
 - Review phases are sequential — each phase builds on findings from prior phases.
 - The reviewer can stop between phases; re-invoke to resume (see [idempotency convention](../../../.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/idempotency.md)).
 - Output follows [code-review-template.md](../../../.pair/knowledge/guidelines/collaboration/templates/code-review-template.md) — the template defines structure, /review fills it with findings.
diff --git a/packages/knowledge-hub/src/conformance/code-review-verdict-first.test.ts b/packages/knowledge-hub/src/conformance/code-review-verdict-first.test.ts
new file mode 100644
index 00000000..41d6226c
--- /dev/null
+++ b/packages/knowledge-hub/src/conformance/code-review-verdict-first.test.ts
@@ -0,0 +1,191 @@
+import { describe, it, expect } from 'vitest'
+import { readFileSync } from 'fs'
+import { join } from 'path'
+
+// Conformance guard for #228: the code-review template is verdict-first (D22, R6.6)
+// and carries the seven required assessment sections — input validation, output
+// handling, authentication, authorization, introduced vulnerabilities, cost,
+// architecture (coupling) — each a 1-line verdict + <details>. The review artifact is
+// the NATIVE GitHub review body (verdict = the review action), not a separate comment
+// (decision Q5, AC2). /pair-process-review composes /assess-cost, surfaces the
+// architecture/coupling verdict (assess-coupling, "not assessed" until #263), keeps
+// the review-time classification a floor (raise-only, D17) and emits the
+// "Classification changed" drift note upward only. Asserted on BOTH the dataset
+// (source of truth) and the installed root mirror, name-mapped — the drift class this
+// repo's parity guards exist to catch.
+
+const DATASET_SKILLS = join(__dirname, '../../dataset/.skills')
+const MIRROR_SKILLS = join(__dirname, '../../../../.claude/skills')
+const DATASET_TEMPLATES = join(
+  __dirname,
+  '../../dataset/.pair/knowledge/guidelines/collaboration/templates',
+)
+const MIRROR_TEMPLATES = join(
+  __dirname,
+  '../../../../.pair/knowledge/guidelines/collaboration/templates',
+)
+const DATASET_HOWTO = join(__dirname, '../../dataset/.pair/knowledge/how-to')
+const MIRROR_HOWTO = join(__dirname, '../../../../.pair/knowledge/how-to')
+
+const TEMPLATE_DATASET = readFileSync(join(DATASET_TEMPLATES, 'code-review-template.md'), 'utf-8')
+const TEMPLATE_MIRROR = readFileSync(join(MIRROR_TEMPLATES, 'code-review-template.md'), 'utf-8')
+const REVIEW_DATASET = readFileSync(join(DATASET_SKILLS, 'process/review/SKILL.md'), 'utf-8')
+const REVIEW_MIRROR = readFileSync(join(MIRROR_SKILLS, 'pair-process-review/SKILL.md'), 'utf-8')
+const HOWTO11_DATASET = readFileSync(join(DATASET_HOWTO, '11-how-to-code-review.md'), 'utf-8')
+const HOWTO11_MIRROR = readFileSync(join(MIRROR_HOWTO, '11-how-to-code-review.md'), 'utf-8')
+
+// The seven required assessment sections (AC1), matched case-insensitively as `###` headings.
+const REQUIRED_SECTIONS = [
+  'Input validation',
+  'Output handling',
+  'Authentication',
+  'Authorization',
+  'Introduced vulnerabilities',
+  'Cost',
+  'Architecture',
+] as const
+
+const TEMPLATE_VARIANTS = [
+  ['dataset', TEMPLATE_DATASET],
+  ['mirror', TEMPLATE_MIRROR],
+] as const
+
+describe('code-review-template — verdict-first reading budget (AC3, D22) (#228)', () => {
+  for (const [label, content] of TEMPLATE_VARIANTS) {
+    it(`${label} opens with a Verdict section carrying risk tier + cost class + decision`, () => {
+      // Verdict must be the first `##` section so the reader hits it in ~30s.
+      const firstSection = content.slice(content.search(/^##\s+/m)).split(/\n## /)[0]
+      expect(firstSection).toMatch(/##\s+Verdict/)
+      expect(firstSection).toMatch(/risk:/)
+      expect(firstSection).toMatch(/cost:/)
+      expect(firstSection).toMatch(/APPROVED|CHANGES-REQUESTED|TECH-DEBT/)
+    })
+
+    it(`${label} states the ~30-second reading budget (D22, R6.6)`, () => {
+      expect(content).toMatch(/D22/)
+      expect(content).toMatch(/30\s*[- ]?\s*second|~?30s/i)
+    })
+
+    it(`${label} declares it is the native review body, not a separate comment (AC2, Q5)`, () => {
+      expect(content.toLowerCase()).toMatch(/native (github )?review/)
+      expect(content.toLowerCase()).toMatch(/no separate.*comment|not a separate.*comment/)
+    })
+  }
+})
+
+describe('code-review-template — seven verdict-first assessment sections (AC1) (#228)', () => {
+  for (const [label, content] of TEMPLATE_VARIANTS) {
+    for (const section of REQUIRED_SECTIONS) {
+      it(`${label} has a "${section}" section that is 1-line verdict + <details>`, () => {
+        const re = new RegExp(`^###\\s+.*${section}`, 'im')
+        const idx = content.search(re)
+        expect(idx).toBeGreaterThan(-1)
+        // Slice to the next `###`/`##` heading — isolate this section only.
+        const body = content
+          .slice(idx)
+          .replace(re, '')
+          .split(/\n#{2,3}\s/)[0]
+        // A 1-line verdict marker...
+        expect(body).toMatch(/\*\*Verdict:\*\*|Verdict:/i)
+        // ...backed by a collapsed details block.
+        expect(body).toContain('<details>')
+      })
+    }
+
+    it(`${label} shows an unavailable assessment as "not assessed" explicitly (edge case)`, () => {
+      expect(content.toLowerCase()).toContain('not assessed')
+    })
+  }
+})
+
+const REVIEW_VARIANTS = [
+  { label: 'dataset', content: REVIEW_DATASET, cost: '/assess-cost', coupling: '/assess-coupling' },
+  {
+    label: 'mirror',
+    content: REVIEW_MIRROR,
+    cost: '/pair-capability-assess-cost',
+    coupling: '/pair-capability-assess-coupling',
+  },
+] as const
+
+describe('review skill — composes assess-cost into the review (AC1 #228, AC3 #226)', () => {
+  for (const v of REVIEW_VARIANTS) {
+    it(`${v.label} lists assess-cost as a composed skill`, () => {
+      const row = v.content
+        .split('\n')
+        .find(line => line.includes(`\`${v.cost}\``) && line.includes('Capability'))
+      expect(row).toBeDefined()
+    })
+
+    it(`${v.label} composes assess-cost against the diff and shows the cost class 1-line + collapsed`, () => {
+      expect(v.content).toContain(`Compose \`${v.cost}\``)
+      expect(v.content).toMatch(/D22/)
+    })
+
+    it(`${v.label} surfaces the architecture/coupling verdict, "not assessed" until assess-coupling ships`, () => {
+      expect(v.content).toContain(v.coupling)
+      // Architecture/coupling degrades to "not assessed" when the capability is absent.
+      const gd = v.content.slice(v.content.indexOf('## Graceful Degradation'))
+      expect(gd.toLowerCase()).toContain('not assessed')
+    })
+  }
+})
+
+describe('review skill — review-time classification is a floor, drift note fires upward (AC3 #226, #228)', () => {
+  for (const v of REVIEW_VARIANTS) {
+    it(`${v.label} keeps the review matrix raise-only (never lowers the tier, D17)`, () => {
+      expect(v.content).toMatch(/never\s+lower|raise-only|raise only/i)
+      expect(v.content).toMatch(/D17/)
+    })
+
+    it(`${v.label} emits a "Classification changed" drift note when review-time differs`, () => {
+      expect(v.content).toMatch(/Classification changed/)
+    })
+
+    it(`${v.label} applies the projected classification tags on the PR (not only the story)`, () => {
+      expect(v.content.toLowerCase()).toMatch(/tag.*on the pr|label.*on the pr|re-apply.*tag/)
+    })
+  }
+})
+
+describe('review skill — review IS the native review body, no separate comment (AC2, Q5) (#228)', () => {
+  for (const v of REVIEW_VARIANTS) {
+    it(`${v.label} submits the report as the native review body, not a separate PR comment`, () => {
+      const post = v.content.slice(v.content.indexOf('### Step 5.3'))
+      expect(post.toLowerCase()).toMatch(/native (github )?review|review body/)
+      expect(post.toLowerCase()).not.toMatch(/post the review report as a pr comment/)
+      // Positive behavioral invariant (not just the absence of one phrasing): the report
+      // is delivered via a native-review EVENT + a body-file, so a differently worded
+      // "post as a separate comment" reintroduction still fails this guard.
+      expect(post).toMatch(/APPROVE|REQUEST_CHANGES/)
+      expect(post.toLowerCase()).toMatch(
+        /--body-file|as (the |its )?(native )?(github )?review body|report .*as .*body/,
+      )
+    })
+  }
+})
+
+describe('how-to-11 — aligned to native-review-body verdict (AC2) (#228)', () => {
+  for (const [label, content] of [
+    ['dataset', HOWTO11_DATASET],
+    ['mirror', HOWTO11_MIRROR],
+  ] as const) {
+    it(`${label} no longer instructs a separate "post report as PR comment"`, () => {
+      expect(content.toLowerCase()).not.toMatch(/post report as pr comment/)
+    })
+  }
+})
+
+describe('code-review-template — root/dataset structural parity (#228)', () => {
+  const headings = (content: string) => content.match(/^##+ .*$/gm) ?? []
+  it('has the same number of section headings in root and dataset', () => {
+    expect(headings(TEMPLATE_MIRROR).length).toBe(headings(TEMPLATE_DATASET).length)
+  })
+
+  // Count parity proves structure, not content. The PR declares the two files an
+  // identical mirror — enforce that fully with byte-equality (analogous to the
+  // skills-guide-mirror byte-equality guard), so a body-only drift can't slip past.
+  it('is byte-identical between root and dataset (identical-mirror invariant)', () => {
+    expect(TEMPLATE_MIRROR).toBe(TEMPLATE_DATASET)
+  })
+})