issues: queue #EFETZT update with PR #2413 snapshot-conflict evidence

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",

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"
+ }
+}