tempestai-dev/tempest

What problem are you trying to solve? Opening a PR row in the Tasks tab shows tabs Description | Comments | Files | Checks | Activity, but Files and Checks render a placeholder (src/components/tasks/RowAccordion.tsx:181): {stubLabel && <p>Loads from the provider on demand — not wired yet.</p>} Reviewing a PR from Tempest therefore still means bouncing to the browser to see files or CI status. What would the solution look like? Files — GET /repos/{owner}/{repo}/pulls/{number}/files, render filenames + additions/deletions counts. Full diff rendering out of scope for a first pass. Checks — GET /repos/{owner}/{repo}/commits/{head_sha}/check-runs (needs PR head SHA — either extend GhItem with head_sha, or fetch on tab open via /pulls/{number}), render name + conclusion + duration. Both should live in src-tauri/src/tasks.rs behind new #[tauri::command]s (tasks_github_pr_files, tasks_github_pr_checks), reusing the same cache pattern the thread endpoint uses. Alternatives you've cons

What problem are you trying to solve? Two spots in src-tauri/src/tasks.rs run gh calls back-to-back when they don't depend on each other, doubling the latency the user sees: tasks_github_list with kind == "both" runs gh_search("issues") then gh_search("prs") serial (src-tauri/src/tasks.rs:302-308). tasks_github_thread runs the comments API call, then the timeline API call, serial (src-tauri/src/tasks.rs:448-467) — so every drawer expand pays 2× round-trips. What would the solution look like? Run each pair concurrently — std::thread::spawn + join, or a small pool. Same result, roughly half the wall time. Alternatives you've considered An async runtime for the two calls, but threads are enough here — this is bounded fan-out, not a general async need. Which area does this touch? Other (Tasks tab) Before submitting I searched existing issues and this hasn't been requested yet

What happened? On macOS, codebase indexing gets stuck indefinitely at: Indexing your codebase → Starting... The Web Inspector console shows that Tempest cannot find its bundled Atlas entry point: [Atlas] start_atlas_index failed: Atlas not bundled — entry not found at: /Applications/Tempest.app/Contents/MacOS/resources/atlas/node_modules/@usetempest/atlas/dist/mcp/server-entry.js However, the Atlas entry point is actually present in the application bundle at: /Applications/Tempest.app/Contents/Resources/resources/atlas/node_modules/@usetempest/atlas/dist/mcp/server-entry.js Steps to reproduce Install Tempest on macOS. Open a project. Start codebase indexing. Indexing remains stuck at Starting.... Open Web Inspector and check the Console. Tempest version 0.1.18 Operating system macOS (Apple Silicon) OS version macOS 14.4.1 Relevant logs or screenshots CLI agents such as Claude Code and Codex work correctly when Tempest is launched with the appropriate PATH, so this indexing failur

Hi everyone 👋 first off, thank you for taking the time to even read this. We'd genuinely love some help here, and any contribution (an idea, a comment, a small PR) would mean a lot. Where we could use a hand Tempest's threads canvas has a "Tidy canvas" action (right-click the canvas, then Tidy canvas). Its job is to untangle the connections between nodes when a canvas gets messy, when wires cross over each other and run on top of nodes. It works, but it isn't quite there yet, and we think this is a lovely, self-contained problem for anyone who enjoys graph layout. We'd be really grateful for help making it better. 🙏 What it does today The current approach is a force-directed layout built on d3-force (already a dependency, so no new packages needed). We went this route because the edges on the canvas are associative, not directional. There's no real parent to child flow to rank into layers, so a Sugiyama/hierarchical layout would invent a hierarchy that isn't in the data. The simu