b9819977a5
Includes prior-session patches (carry forward so the app compiles): - crates/gpui/build.rs: cross-compile manifest fix - crates/gpui/src/platform.rs: PlatformWindow::activate_with_token trait method - crates/gpui/src/window.rs: Window::activate_with_token public API - crates/gpui_linux/src/linux/wayland/window.rs: WaylandWindow::activate_with_token + activate() keyboard-serial fix Plus the focus-serial fix: - serial.rs: SerialKind::KeyboardEnter - client.rs: store wl_keyboard.enter serial; latest_serial_of() Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
90 lines
2.6 KiB
Markdown
90 lines
2.6 KiB
Markdown
# 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.
|