## Repository context

`gpui-ce` is a standalone community fork of Zed's GPUI. It vendors crates from the upstream Zed
monorepo (`zed-industries/zed`). Two groups:

**Same relative path** (upstream dir == fork dir): `crates/gpui`, `crates/gpui_linux`,
`crates/gpui_macos`, `crates/gpui_macros`, `crates/gpui_platform`, `crates/gpui_shared_string`,
`crates/gpui_tokio`, `crates/gpui_web`, `crates/gpui_wgpu`, `crates/gpui_windows`.

**Vendored + renamed** (upstream dir → fork dir), formerly pulled as `zed-industries/zed` git
deps but now vendored in-tree by the fork:
`collections`→`gpui_collections`, `sum_tree`→`gpui_sum_tree`, `refineable`→`gpui_refineable`,
`refineable/derive_refineable`→`gpui_derive_refineable`, `scheduler`→`gpui_scheduler`,
`media`→`gpui_media`, `util`→`gpui_zed_util`, `gpui_util`→`gpui_ce_util`, `path`→`gpui_path`.
The sync remaps upstream's
content into these fork dirs, so a conflict here is upstream's version of the crate vs. the fork's
vendored+adapted version. Preserve the fork's adaptations (see rule 4) while taking upstream's real
changes. (`util_macros` is no longer used by the fork; `gpui_elements` and `tooling/perf` are
fork-only and never synced.)

A 3-way `git merge` of the upstream delta produced conflicts, and the raw merge — with conflict
markers committed in — is already its own commit. Your job is to resolve **every** marker in the
listed files so the result is correct gpui-ce code that incorporates the upstream changes. Your
edits land as a **separate, reviewable resolution commit** diffed against that raw merge.

## Rules

1. **Resolve every conflict marker** (`<<<<<<<`, `=======`, `>>>>>>>`, `|||||||`) in the listed
   files. Leave no markers behind. Do not touch files that aren't conflicted.

2. **gpui-ce keeps its own patches.** gpui-ce carries features/fixes not yet upstream (e.g. blur
   filters, kinetic scrolling on Wayland, the wgpu device-loss API). When a conflict pits an
   upstream change against a gpui-ce patch, **keep both behaviours** — integrate the upstream
   change around gpui-ce's additions rather than dropping either. Only drop a gpui-ce line if the
   upstream change genuinely supersedes it.

3. **Already-present (cherry-picked) changes.** gpui-ce frequently contributes to and cherry-picks
   from upstream, so an upstream commit may already be present here under a different hash. If a
   conflict exists *only* because the change is **already applied** in gpui-ce (semantically
   equivalent, even if worded differently), keep gpui-ce's version and do **not** duplicate the code.

4. **Vendored crate adaptations — preserve them.** The vendored+renamed crates carry mechanical
   gpui-ce adaptations on top of upstream. When a conflict pits upstream against one of these, KEEP
   the adaptation and take upstream's real code change around it:
   - **Package rename:** the package name is the fork's `gpui_*` name (e.g. `gpui_collections`, not
     `collections`), with the fork's `publish`/version/workspace metadata. Do **not** revert to
     upstream's package name.
   - **Path deps:** intra-fork deps are `{ path = "crates/gpui_*", package = "gpui_*" }`, not git or
     crates.io deps. Upstream referring to a sibling as `collections`/`util`/`sum_tree`/etc. maps to
     the fork's `gpui_*` path dep. Do not convert fork path deps back to git/registry deps.
   - **Stripped zed-internal crates:** the fork replaces zed-only infra with std/community crates —
     e.g. `ztracing`→`tracing`, and `zlog`/`zlog::init_test()` test-logger blocks are removed. Keep
     these substitutions; don't reintroduce `ztracing`/`zlog`.

5. **`Cargo.toml` (per-crate and root):**
   - KEEP gpui-ce packaging (names, `publish`, `edition`, workspace metadata) and the fork's dep
     *sources* (path deps for the vendored crates; `zed-font-kit` for font-kit).
   - **ADOPT upstream's real changes: newly added/removed dependencies, new features, new
     `[target.'cfg(...)']` blocks, and — importantly — dependency VERSION BUMPS.** If upstream bumped
     a crate (e.g. `resvg`/`usvg` 0.45→0.46, `taffy`, `accesskit`), take the new version; a bumped
     dep is often paired with a regression test that only passes on the new version. Wire any newly
     required workspace dependency through the fork's convention.

6. **Removed Zed-app / AGPL code.** gpui-ce stripped Zed-application-specific and non-Apache code.
   If an upstream change references a crate or module that doesn't exist in gpui-ce (e.g.
   `http_client`, `reqwest_client`, `util_macros`), drop that reference rather than reintroducing the
   removed code.

7. **Add/delete conflicts are handled for you** — the script settles `modify/delete` cases
   (files gpui-ce deleted that upstream changed are kept deleted) before calling you, so you
   only ever see content conflicts. Don't recreate a deleted file.

8. **Relocated files.** When upstream MOVES a file to another crate, the prompt lists it above as
   `old path → new path`. The script has already deleted the old path and the merge has already
   brought in the new one, so the code is not lost — but any **gpui-ce adaptation that lived in the
   old file is**. For each listed move: diff what the fork had at the old path against what arrived
   at the new one, re-apply the fork's adaptations (rule 4) at the NEW location, and update every
   `use`/`mod`/path reference to point there. Never leave the old copy behind alongside the new one —
   a duplicated type is worse than either version alone. Do **not** re-create the old file.

9. **Do not** run `git commit`, `git merge`, `git rebase`, or `git push`. Only edit files to
   resolve the conflicts — the surrounding script stages and commits. Do not change anything
   unrelated to the conflicts.

10. **No scratch files in the repo.** If you need to save a base/upstream/fork copy of a file to
   diff it, write it under `/tmp`, never inside the working tree (a stray `.merge_tmp/` or similar
   would be committed). Resolve strictly by editing the conflicted files in place.

When finished, briefly summarize what you resolved and any decisions worth a human's attention.