Interactive mode SIGINT tests skipped due to TTY requirement

[umair-ably]

Problem

The interactive mode has 4 unit tests for SIGINT/Ctrl+C handling that are it.skip/describe.skip because they are fundamentally unreliable with piped stdio:

• Ctrl+C on empty prompt
• Ctrl+C with partial command input
• Ctrl+C during command execution (exit code 130)
• Ctrl+C on empty prompt (direct spawn variant)

Root cause: Node.js readline's SIGINT handler only fires when connected to a real TTY. When tests spawn the CLI with stdio: "pipe" (as unit/integration tests do), the signal is never delivered to readline, making these tests permanently flaky — not intermittently flaky.

This is a Node.js limitation, not a bug in the CLI code.

Expected outcome

These tests should run reliably in a real pseudo-terminal environment, verifying that interactive mode handles Ctrl+C correctly in all scenarios.

[umair-ably]

Update: Interactive SIGINT tests fixed

The 4 skipped interactive mode SIGINT tests have been resolved.

What was done

Solution: We created a new test/tty/ test suite that uses node-pty (already a devDependency) to spawn the CLI inside real pseudo-terminals. All 4 previously-skipped tests now pass reliably:

• Ctrl+C on empty prompt
• Ctrl+C with partial command input
• Ctrl+C during command execution (exit code 130)
• Ctrl+C on empty prompt (direct spawn variant)

The tests were removed from test/unit/ (where they were it.skip/describe.skip) and migrated to test/tty/commands/interactive-sigint.test.ts. Run locally with:

pnpm run test:tty

Why these don't run in CI

GitHub Actions runners don't provide a TTY, so node-pty can't create functioning pseudo-terminals. The tests are excluded from CI pipelines by being in a separate vitest project (tty) that isn't included in pnpm test:unit.

What would be needed for CI

To run these in CI, you'd need one of:

1. script wrapper — Run the test command inside script -c "pnpm run test:tty" on Linux, which allocates a PTY. This is the simplest option but may have quirks with output capture.
2. Docker with TTY — Run tests in a Docker container with docker run -t (allocates a pseudo-TTY). More reliable but adds Docker overhead to CI.
3. macOS runner — GitHub Actions macOS runners have better TTY support. Adding a separate CI job on macos-latest for TTY tests would work but is more expensive.

For now, the local-only approach is pragmatic — these tests cover niche signal-handling behavior that rarely changes.