From 7d5d04985ac7443fd55181ddb6e119c14a446ef9 Mon Sep 17 00:00:00 2001
From: Adam Moussa <166072409+amoussa1229@users.noreply.github.com>
Date: Fri, 15 May 2026 17:13:47 -0400
Subject: [PATCH] Add deferred findings policy to code review page

Require PR authors to create a GitHub issue for any review
finding deferred past the current PR, and link it in the
review thread before merging. Prevents informal tracking
from dropping items.
---
 code-review.md | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/code-review.md b/code-review.md
index 0996616..576c71c 100644
--- a/code-review.md
+++ b/code-review.md
@@ -34,6 +34,20 @@ Code review exists to catch defects, share knowledge, and maintain consistency.
 - Ask questions instead of making assumptions. "Is this intentional?" is better than "This is wrong."
 - If a PR is good, say so. A simple "Looks good" is fine.
 
+## Deferred Findings
+
+When a reviewer identifies a finding that won't be addressed in the current PR, the PR author must create a GitHub issue for it before the PR merges. No exceptions -- if it's worth commenting on, it's worth tracking.
+
+### Requirements
+
+- The GitHub issue must reference the PR number and link to the specific review comment.
+- The PR author must reply to the review comment with a link to the created issue, acknowledging the deferral.
+- This applies to all severity levels: bugs, nits, refactors, missing tests, documentation gaps.
+
+### Why
+
+Deferred findings handled informally (retro notes, mental to-do lists, "we'll get to it") fall through the cracks. An issue in the backlog is the minimum bar for accountability.
+
 ## Turnaround
 
 - Aim to review within one business day of being requested