refactor(terminal): clarify Ctrl+C retry naming and comments per review (#266)

- rename ABORT_MAX_ATTEMPTS -> CTRL_C_SEND_LIMIT (total sends) and start the
  retry loop at sent=1 so the bound reads naturally
- document why both isListening and terminal.busy are checked
- cross-reference the mirrored test constants to the production ones
- note the double-abort send-count assumption in the test
- drop the unused changeset

Author: proyectoauraorg

.changeset/multiple-ctrl-c-terminate.md

@@ -8,11 +8,12 @@ import { Terminal } from "./Terminal"
 export class TerminalProcess extends BaseTerminalProcess {
 	// #266: Some processes (interactive tools, programs that trap SIGINT and
 	// prompt for confirmation) need more than one Ctrl+C to actually exit. We
-	// re-send Ctrl+C up to this many times, checking between attempts whether
-	// the process has exited, before giving up and letting dispose() proceed.
-	private static readonly ABORT_MAX_ATTEMPTS = 3
+	// send Ctrl+C up to this many times in TOTAL — the immediate send in abort()
+	// plus retries — checking between sends whether the process has exited, before
+	// giving up and letting dispose() proceed.
+	private static readonly CTRL_C_SEND_LIMIT = 3
 	// Delay between Ctrl+C re-sends. Kept short so cancel stays responsive; the
-	// whole retry window is bounded by ABORT_MAX_ATTEMPTS * ABORT_RETRY_DELAY_MS.
+	// retry window is bounded by (CTRL_C_SEND_LIMIT - 1) * ABORT_RETRY_DELAY_MS.
 	private static readonly ABORT_RETRY_DELAY_MS = 500
 
 	private terminalRef: WeakRef<Terminal>
@@ -290,15 +291,22 @@ export class TerminalProcess extends BaseTerminalProcess {
 	}
 
 	/**
-	 * Re-sends Ctrl+C up to ABORT_MAX_ATTEMPTS times, waiting ABORT_RETRY_DELAY_MS
-	 * between attempts and stopping early once the process exits (or once we stop
-	 * listening). Bounded so it can never loop indefinitely.
+	 * Re-sends Ctrl+C after the immediate send in abort(), up to CTRL_C_SEND_LIMIT
+	 * total sends, waiting ABORT_RETRY_DELAY_MS between sends and stopping early once
+	 * the process exits (or once we stop listening). Bounded so it can never loop
+	 * indefinitely.
 	 */
 	private async retryAbort(): Promise<void> {
-		for (let attempt = 1; attempt < TerminalProcess.ABORT_MAX_ATTEMPTS; attempt++) {
+		// abort() already sent Ctrl+C once, so `sent` starts at 1; re-send until we
+		// reach CTRL_C_SEND_LIMIT total.
+		for (let sent = 1; sent < TerminalProcess.CTRL_C_SEND_LIMIT; sent++) {
 			await new Promise((resolve) => setTimeout(resolve, TerminalProcess.ABORT_RETRY_DELAY_MS))
 
-			// Stop if the process already exited or we're no longer listening.
+			// Stop as soon as there's nothing left to interrupt. `isListening` (cleared
+			// by continue()) and `terminal.busy` (cleared by shellExecutionComplete() /
+			// the "completed" event) are set on different code paths and can diverge, so
+			// either one being false is a sufficient stop signal — we deliberately check
+			// both rather than collapsing them into one.
 			if (!this.isListening) {
 				return
 			}

src/integrations/terminal/TerminalProcess.ts

@@ -187,8 +187,12 @@ describe("TerminalProcess", () => {
 	})
 
 	describe("abort", () => {
-		const RETRY_DELAY_MS = 500
-		const MAX_ATTEMPTS = 3
+		// These MIRROR the private production constants in TerminalProcess.ts
+		// (ABORT_RETRY_DELAY_MS and CTRL_C_SEND_LIMIT) — they can't be imported, so if
+		// those values are ever tuned, update them here too or the timing assertions
+		// below will keep passing while asserting the wrong cadence.
+		const RETRY_DELAY_MS = 500 // mirrors ABORT_RETRY_DELAY_MS
+		const MAX_ATTEMPTS = 3 // mirrors CTRL_C_SEND_LIMIT (total Ctrl+C sends)
 
 		beforeEach(() => {
 			vi.useFakeTimers()
@@ -261,6 +265,10 @@ describe("TerminalProcess", () => {
 			terminalProcess.abort()
 
 			// Two immediate Ctrl+C from the two abort() calls, but only one retry loop.
+			// This count of 2 relies on the `aborting` guard being checked AFTER the
+			// immediate sendText in abort(): the second call still fires its own Ctrl+C
+			// before the guard short-circuits the duplicate retry loop. If the guard ever
+			// moves above the send, this would drop to 1 immediate send (total 3, not 4).
 			expect(mockTerminal.sendText).toHaveBeenCalledTimes(2)
 
 			await vi.advanceTimersByTimeAsync(RETRY_DELAY_MS * (MAX_ATTEMPTS + 2))