zqlz — Windsurf Rules

• Prioritize code correctness and clarity. Speed and efficiency are secondary priorities unless otherwise specified. • Do not write organizational or comments that summarize the code. Comments should only be written in order to explain "why" the code is written in some way in the case there is a reason that is tricky / non-obvious. • Prefer implementing functionality in existing files unless it is a new logical component. Avoid creating many small files. • Avoid using functions that panic like unwrap(), instead use mechanisms like ? to propagate errors. • Be careful with operations like indexing which may panic if the indexes are out of bounds. • Never silently discard errors with let _ = on fallible operations. Always handle errors appropriately: • Propagate errors with ? when the calling function should handle them • Use .log_err() or similar when you need to ignore errors but want visibility • Use explicit error handling with match or if let Err(...) when you need custom logic • Example: avoid let _ = client.request(...).await?; - use client.request(...).await?; instead • When implementing async operations that may fail, ensure errors propagate to the UI layer so users get meaningful feedback. • Never create files with mod.rs paths - prefer src/some_module.rs instead of src/some_module/mod.rs. • When creating new crates, prefer specifying the library root path in Cargo.toml using [lib] path = "...rs" instead of the default lib.rs, to maintain consistent and descriptive naming (e.g., gpui.rs or main.rs). • Avoid creative additions unless explicitly requested • Use full words for variable names (no abbreviations like "q" for "queue") • Use variable shadowing to scope clones in async contexts for clarity, minimizing the lifetime of borrowed references. Example: `rust executor.spawn({ let task_ran = task_ran.clone(); async move { *task_ran.borrow_mut() = true; } }); `

GPUI is a UI framework which also provides primitives for state and concurrency management.

Context types allow interaction with global state, windows, entities, and system services. They are typically passed to functions as the argument named cx. When a function takes callbacks they come after the cx parameter. • App is the root context type, providing access to global state and read and update of entities. • Context<T> is provided when updating an Entity<T>. This context dereferences into App, so functions which take &App can also take &Context<T>. • AsyncApp and AsyncWindowContext are provided by cx.spawn and cx.spawn_in. These can be held across await points.

Window provides access to the state of an application window. It is passed to functions as an argument named window and comes before cx when present. It is used for managing focus, dispatching actions, directly drawing, getting user input state, etc.