You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Browse filesBrowse the repository at this point in the historyBrowse files
authored
Replace blocking Bun.spawnSync with async Bun.spawn across backend (#9)
* Make PR fetching non-blocking with async Bun.spawn and parallel repo queries
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* Fetch only open PRs to avoid GitHub GraphQL 504 timeouts on large repos
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* Make CI log fetching non-blocking with async Bun.spawn
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* Replace Bun.spawnSync cat with native Bun.file for .env.local reads and writes
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* Replace blocking sleep subprocess with await Bun.sleep in sandbox worktree creation
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* Make sendPrompt async to fix event loop blocking on large payloads
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* Replace working status spinner with static ellipsis icon
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Add root CLAUDE.md with feature implementation workflow and debugging guidelines
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Send Enter from frontend via terminal WebSocket after CI fix prompt is pasted
- Backend no longer sends send-keys Enter (frontend owns submission)
- Add sendInput() export to Terminal.svelte
- Add onfixsuccess callback to CiDetailsDialog, close dialog then send \r after 300ms delay
- Flush FileSink after every write() to ensure single-byte input is sent immediately
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* Use named ENTER_DELAY_MS const (200ms) for post-paste Enter delay
Backend already awaits paste-buffer completion before returning,
frontend already awaits the API response, so 200ms is sufficient
as a PTY flush safety buffer (down from 300ms).
Co-authored-by: centdix <centdix@users.noreply.github.com>
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com>
Co-authored-by: centdix <centdix@users.noreply.github.com>
-**Full-stack feature** → Read both. Start with the backend.
16
+
17
+
### 2. Types first, code second
18
+
19
+
1. Define the data types/interfaces that the feature needs.
20
+
- Backend types go in the relevant module file.
21
+
- Frontend shared types go in `frontend/src/lib/types.ts` (types and interfaces only — no runtime logic).
22
+
2. Define the API contract — endpoint path, request body, response shape — before implementing either side.
23
+
3. On the frontend, add the typed fetch call to `frontend/src/lib/api.ts` before building UI.
24
+
25
+
### 3. Build incrementally
26
+
27
+
-**Backend**: implement the handler, delegate logic to pure testable functions, wire it into `server.ts` routing.
28
+
-**Frontend**: build the component with mock data first, then connect the real API.
29
+
- Test each layer independently before integrating.
30
+
31
+
### 4. DRY — no exceptions
32
+
33
+
- If a UI pattern already exists in another component, extract it into a shared component immediately. Do not copy-paste.
34
+
- If a helper function is needed in more than one file, put it in a shared `lib/` utility. Never duplicate logic across files.
35
+
- Check existing components and utilities before creating new ones.
36
+
37
+
### 5. Keep it minimal
38
+
39
+
- Only implement what was asked for. No speculative features, no extra configurability, no "while I'm here" refactors.
40
+
- Don't add comments, docstrings, or type annotations to code you didn't change.
41
+
- Don't add error handling for scenarios that can't happen. Trust internal code and framework guarantees.
42
+
43
+
## Debugging
44
+
45
+
When you are uncertain about the root cause of an issue, **add extensive debug logging before guessing at a fix**. This is mandatory, not optional.
46
+
47
+
### The rule
48
+
49
+
If you are not 100% sure where a bug comes from, do not propose a speculative fix. Instead:
50
+
51
+
1.**Add `console.log` / `console.debug` statements** at every relevant point in the code path — function entry/exit, variable values, branch decisions, API request/response payloads, WebSocket message contents.
52
+
2.**Log enough context** to pinpoint the problem: timestamps, identifiers (worktree name, session id), the actual values vs. what you expected.
53
+
3.**Run the code** with the logging in place and read the output.
54
+
4.**Only then** propose a fix based on what the logs reveal.
55
+
5.**Remove the debug logging** after the fix is confirmed.
56
+
57
+
### Why
58
+
59
+
- A targeted fix based on observed data is worth ten speculative patches.
60
+
- Logging proves your assumption before you change production logic.
61
+
- It avoids the cycle of guess-fix-test-revert that wastes time.
62
+
63
+
### What to log
64
+
65
+
- Function arguments and return values at the boundary where the bug might live.
66
+
- Conditional branches — log which branch was taken and why.
67
+
- Async timing — log before and after `await` calls to catch ordering issues.
68
+
- State mutations — log the before/after value of any state that's being updated.
69
+
- External process output — log stdout/stderr from spawned commands (`Bun.spawn`, `Bun.$`).
0 commit comments