logicamp/zed
3
0
Fork 0
Code Issues Pull Requests Actions 9 Packages Projects Releases Wiki Activity

logiguard fork v3: full patch set on verified 8c74db0 tree

Browse Source 
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>
This commit is contained in:
Mohamad Khani
2026-07-14 01:52:12 +03:30
commit b9819977a5
3984 changed files with 1487015 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

84
.factory/prompts/crash/fix.md Normal file
View File

@@ -0,0 +1,84 @@
# Crash Fix
You are fixing a crash that has been analyzed and has a reproduction test case. Your goal is to implement a minimal, correct fix that resolves the root cause and makes the reproduction test pass.
## Inputs
Before starting, you should have:
1. **ANALYSIS.md** — the crash analysis from the investigation phase. Read it thoroughly.
2. **A failing test** — a reproduction test that triggers the crash. Run it first to confirm it fails as expected.
If either is missing, ask the user to provide them or run the investigation phase first (`/prompt crash/investigate`).
## Workflow
### Step 1: Confirm the Failing Test
Run the reproduction test and verify it fails with the expected crash:
```
cargo test -p <crate> <test_name>
```
Read the failure output. Confirm the panic message and stack trace match what ANALYSIS.md describes. If the test doesn't fail, or fails differently than expected, stop and reassess before proceeding.
### Step 2: Understand the Fix
Read the "Suggested Fix" section of ANALYSIS.md and the relevant source code. Before writing any code, be clear on:
1. **What invariant is being violated** — what property of the data does the crashing code assume?
2. **Where the invariant breaks** — which function produces the bad state?
### Step 3: Implement the Fix
Apply the minimal change needed to resolve the root cause. Guidelines:
- **Fix the root cause, not the symptom.** Don't just catch the panic with a bounds check if the real problem is an incorrect offset calculation. Fix the calculation.
- **Preserve existing behavior** for all non-crashing cases. The fix should only change what happens in the scenario that was previously crashing.
- **Don't add unnecessary changes.** No drive-by improvements, keep the diff focused.
- **Add a comment only if the fix is non-obvious.** If a reader might wonder "why is this check here?", a brief comment explaining the crash scenario is appropriate.
- **Consider long term maintainability** Please make a targeted fix while being sure to consider the long term maintainability and reliability of the codebase
### Step 4: Verify the Fix
Run the reproduction test and confirm it passes:
```
cargo test -p <crate> <test_name>
```
Then run the full test suite for the affected crate to check for regressions:
```
cargo test -p <crate>
```
If any tests fail, determine whether the fix introduced a regression. Fix regressions before proceeding.
### Step 5: Run Clippy
```
./script/clippy
```
Address any new warnings introduced by your change.
### Step 6: Summarize
Write a brief summary of the fix for use in a PR description. Include:
- **What was the bug** — one sentence on the root cause.
- **What the fix does** — one sentence on the change.
- **How it was verified** — note that the reproduction test now passes.
- **Sentry issue link** — if available from ANALYSIS.md.
We use the following template for pull request descriptions. Please add information to answer the relevant sections, especially for release notes.
```
<Description of change, what the issue was and the fix.>
Release Notes:
- N/A *or* Added/Fixed/Improved ...
```

89
.factory/prompts/crash/investigate.md Normal file
View File

@@ -0,0 +1,89 @@
# Crash Investigation
You are investigating a crash that was observed in the wild. Your goal is to understand the root cause and produce a minimal reproduction test case that triggers the same crash. This test will be used to verify a fix and prevent regressions.
## Workflow
### Step 1: Get the Crash Report
If given a Sentry issue ID (like `ZED-4VS` or a numeric ID), there are several ways to fetch the crash data:
**Option A: Sentry MCP server (preferred if available)**
If the Sentry MCP server is configured as a context server, use its tools directly (e.g., `get_sentry_issue`) to fetch the issue details and stack trace. This is the simplest path — no tokens or scripts needed.
**Option B: Fetch script**
Run the fetch script from the terminal:
```
script/sentry-fetch <issue-id>
```
This reads authentication from `~/.sentryclirc` (set up via `sentry-cli login`) or the `SENTRY_AUTH_TOKEN` environment variable.
**Option C: Crash report provided directly**
If the crash report was provided inline or as a file, read it carefully before proceeding.
### Step 2: Analyze the Stack Trace
Read the stack trace bottom-to-top (from crash site upward) and identify:
1. **The crash site** — the exact function and line where the panic/abort occurs.
2. **The immediate cause** — what operation failed (e.g., slice indexing on a non-char-boundary, out-of-bounds access, unwrap on None).
3. **The relevant application frames** — filter out crash handler, signal handler, parking_lot, and stdlib frames. Focus on frames marked "(In app)".
4. **The data flow** — trace how the invalid data reached the crash site. What computed the bad index, the None value, etc.?
Find the relevant source files in the repository and read them. Pay close attention to:
- The crashing function and its callers
- How inputs to the crashing operation are computed
- Any assumptions the code makes about its inputs (string encoding, array lengths, option values)
### Step 3: Identify the Root Cause
Work backwards from the crash site to determine **what sequence of events or data conditions** produces the invalid state.
Ask yourself: *What user action or sequence of actions could lead to this state?* The crash came from a real user, so there is some natural usage pattern that triggers it.
### Step 4: Write a Reproduction Test
Write a minimal test case that:
1. **Mimics user actions** rather than constructing corrupt state directly. Work from the top down: what does the user do (open a file, type text, trigger a completion, etc.) that eventually causes the internal state to become invalid?
2. **Exercises the same code path** as the crash. The test should fail in the same function with the same kind of error (e.g., same panic message pattern).
3. **Is minimal** — include only what's necessary to trigger the crash. Remove anything that isn't load-bearing.
4. **Lives in the right place** — add the test to the existing test module of the crate where the bug lives. Follow the existing test patterns in that module.
5. **Avoid overly verbose comments** - the test should be self-explanatory and concise. More detailed descriptions of the test can go in ANALYSIS.md (see the next section).
When the test fails, its stack trace should share the key application frames from the original crash report. The outermost frames (crash handler, signal handling) will differ since we're in a test environment — that's expected.
If you can't reproduce the exact crash but can demonstrate the same class of bug (e.g., same function panicking with a similar invalid input), that is still valuable. Note the difference in your analysis.
### Step 5: Write the Analysis
Create an `ANALYSIS.md` file (in the working directory root, or wherever instructed) with these sections:
```markdown
# Crash Analysis: <short description>
## Crash Summary
- **Sentry Issue:** <ID and link if available>
- **Error:** <the panic/error message>
- **Crash Site:** <function name and file>
## Root Cause
<Explain what goes wrong and why. Be specific about the data flow.>
## Reproduction
<Describe what the test does and how it triggers the same crash.
Include the exact command to run the test, e.g.:
`cargo test -p <crate> <test_name>`>
## Suggested Fix
<Describe the fix approach. Be specific: which function, what check to add,
what computation to change. If there are multiple options, list them with tradeoffs.>
```
## Guidelines
- **Don't guess.** If you're unsure about a code path, read the source. Use `grep` to find relevant functions, types, and call sites.
- **Check the git history.** If the crash appeared in a specific version, `git log` on the relevant files may reveal a recent change that introduced the bug.
- **Look at existing tests.** The crate likely has tests that show how to set up the relevant subsystem. Follow those patterns rather than inventing new test infrastructure.

89
.factory/prompts/crash/link-issues.md Normal file
View File

@@ -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.