diff --git a/data/outstanding-issues-snapshot.json b/data/outstanding-issues-snapshot.json
index 90e270f68..d82a6140a 100644
--- a/data/outstanding-issues-snapshot.json
+++ b/data/outstanding-issues-snapshot.json
@@ -10,7 +10,7 @@
     "p2": 49,
     "p3": 31,
     "queued": 7,
-    "pending": 3,
+    "pending": 4,
     "resolved": 431
   },
   "queue": [
@@ -830,6 +830,12 @@
       "summary": "/calculators/search keeps a 2px residual scroll range at 1280x1200 after the dead-scroll sweep",
       "created_at": "2026-08-27"
     },
+    {
+      "request_id": "8324c7e4-18fb-4073-ba6b-ae46920f768d",
+      "action": "update",
+      "summary": "#EFETZT: detail → UPDATE 2026-08-27 (PR #2413, second and third occurrences): this is not only a staleness problem, it also produces hard git merge conflicts that block auto-merge. data/repo-awareness-snapshot.json conflicted twice in fifteen minutes on one PR head — first when main advanced to be65b8a, again when main advanced to fb88b47 — each time setting mergeable_state=dirty, which suppresses refs/pull/<n>/merge so pull_request CI (CI, Gitleaks, Semgrep) does not run at all and the check list reads empty rather than red. Both were resolved identically: git merge origin/main, git checkout --theirs the snapshot, npm run snapshot:repo-awareness, commit, push. The staleness half also reproduced: check:repo-awareness-snapshot failed Static PR checks with 'review_state differs from the repository'. Cost per occurrence is one full CI round trip plus a push, and it scales with how many PRs are open, since every merge to main regenerates the file for all of them. Reinforces the fix direction already proposed on this row: exclude docs/branch-review-records/ from the compared content the way captured_revision already is, or compare a narrower key set. Adding .gitattributes merge guidance for this path would blunt the conflict half but not the CI-staleness half.",
+      "created_at": "2026-08-27"
+    },
     {
       "request_id": "8cf62eef-79a8-4b23-83cc-9290eb71dff3",
       "action": "add",
diff --git a/docs/outstanding-issues-inbox/8324c7e4-18fb-4073-ba6b-ae46920f768d.json b/docs/outstanding-issues-inbox/8324c7e4-18fb-4073-ba6b-ae46920f768d.json
new file mode 100644
index 000000000..5c862e2e3
--- /dev/null
+++ b/docs/outstanding-issues-inbox/8324c7e4-18fb-4073-ba6b-ae46920f768d.json
@@ -0,0 +1,11 @@
+{
+  "version": 2,
+  "id": "8324c7e4-18fb-4073-ba6b-ae46920f768d",
+  "createdOn": "2026-08-27",
+  "action": "update",
+  "payload": {
+    "id": "#EFETZT",
+    "detail": "UPDATE 2026-08-27 (PR #2413, second and third occurrences): this is not only a staleness problem, it also produces hard git merge conflicts that block auto-merge. data/repo-awareness-snapshot.json conflicted twice in fifteen minutes on one PR head — first when main advanced to be65b8a, again when main advanced to fb88b47 — each time setting mergeable_state=dirty, which suppresses refs/pull/<n>/merge so pull_request CI (CI, Gitleaks, Semgrep) does not run at all and the check list reads empty rather than red. Both were resolved identically: git merge origin/main, git checkout --theirs the snapshot, npm run snapshot:repo-awareness, commit, push. The staleness half also reproduced: check:repo-awareness-snapshot failed Static PR checks with 'review_state differs from the repository'. Cost per occurrence is one full CI round trip plus a push, and it scales with how many PRs are open, since every merge to main regenerates the file for all of them. Reinforces the fix direction already proposed on this row: exclude docs/branch-review-records/ from the compared content the way captured_revision already is, or compare a narrower key set. Adding .gitattributes merge guidance for this path would blunt the conflict half but not the CI-staleness half.",
+    "baseRowFingerprint": "d744cf0713c8975b6e505869fb973439e18cbe2fe92266da89af67602c9783fc"
+  }
+}