logiguard fork v2: patched GPUI on verified 8c74db0 tree

Rebuilt from the exact zed-industries/zed @ 8c74db00c4053d6c0a9037863d7bd048658da4ca tree (previous orphan was based on a stale/wrong fetch). Same 3-file patch: - serial.rs: add SerialKind::KeyboardEnter - client.rs: store wl_keyboard.enter serial; add latest_serial_of() - window.rs: activate() uses keyboard-enter serial (Mutter focus gate) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-14 01:44:22 +03:30
commit 46c7879954
3984 changed files with 1487015 additions and 0 deletions
@@ -0,0 +1,89 @@
+# Crash Issue Linking
+
+You are linking a crash to potentially related GitHub issues so human reviewers can quickly validate whether a fix may resolve multiple reports.
+
+## Inputs
+
+Before starting, you should have:
+
+1. **Crash report** (from `script/sentry-fetch <issue-id>` or Sentry MCP)
+2. **ANALYSIS.md** from investigation phase, including root cause and crash site
+
+If either is missing, stop and report what is missing.
+
+## Goal
+
+Search GitHub issues and produce a reviewer-ready shortlist grouped by confidence:
+
+- **High confidence**
+- **Medium confidence**
+- **Low confidence**
+
+The output is advisory only. Humans must confirm before adding closing keywords or making release claims.
+
+## Workflow
+
+### Step 1: Build Search Signals
+
+Extract concrete signals from the crash + analysis:
+
+1. Crash site function, file, and crate
+2. Error message / panic text
+3. Key stack frames (especially in-app)
+4. Reproduction trigger phrasing (user actions)
+5. Affected platform/version tags if available
+
+### Step 2: Search GitHub Issues
+
+Search **only** issues in `zed-industries/zed` (prefer `gh issue list` / `gh issue view` / GraphQL if available) by:
+
+1. Panic/error text
+2. Function/file names
+3. Crate/module names + symptom keywords
+4. Similar reproduction patterns
+
+Check both open and recently closed issues in `zed-industries/zed`.
+
+### Step 3: Score Confidence
+
+Assign confidence based on evidence quality:
+
+- **High:** direct technical overlap (same crash site or same invariant violation with matching repro language)
+- **Medium:** partial overlap (same subsystem and symptom, but indirect stack/repro match)
+- **Low:** thematic similarity only (same area/keywords without solid technical match)
+
+Avoid inflated confidence. If uncertain, downgrade.
+
+### Step 4: Produce Structured Output
+
+Write `LINKED_ISSUES.md` using this exact structure:
+
+```markdown
+# Potentially Related GitHub Issues
+
+## High Confidence
+- [#12345](https://github.com/zed-industries/zed/issues/12345) — <title>
+  - Why: <1-2 sentence evidence-backed rationale>
+  - Evidence: <stack frame / error text / repro alignment>
+
+## Medium Confidence
+- ...
+
+## Low Confidence
+- ...
+
+## Reviewer Checklist
+- [ ] Confirm High confidence issues should be referenced in PR body
+- [ ] Confirm any issue should receive closing keywords (`Fixes #...`)
+- [ ] Reject false positives before merge
+```
+
+If no credible matches are found, keep sections present and write `- None found` under each.
+
+## Rules
+
+- Do not fabricate issues or URLs.
+- Do not include issues from any repository other than `zed-industries/zed`.
+- Do not add closing keywords automatically.
+- Keep rationale short and evidence-based.
+- Favor precision over recall.