Add PTY mouse menu interaction coverage

[benvinegar]

Summary

• add tuistory PTY coverage for mouse-driven menu interactions
• verify clicking the View menu in a real terminal opens the dropdown
• verify selecting Stacked view switches the live diff layout from split to stack

Testing

• bun run test:integration
• bun run typecheck
• bun test test/app-interactions.test.tsx --test-name-pattern "new shortcuts d, u, and f work without errors"

This PR description was generated by Pi using OpenAI o4-mini

[greptile-apps]

Greptile Summary

This PR adds one integration test (\"scrollbar track clicks page the review pane up and down\") to the existing tuistory PTY suite. It covers the two remaining track-click cases: clicking below the thumb to page the review pane down and clicking above the thumb to page it back up, using the same fixture, harness helpers, and try/finally pattern as all sibling tests.

Key observations:

• Test structure and lifecycle management (try/finally, waitForSnapshot predicates, session.close()) are consistent with the rest of the suite.
• The initial negative assertion (not.toContain(\"line10 = 110\")) is weaker than the not.toContain(\"line08 = 108\") boundary used by the sibling scroll test on the same fixture; since the very next step relies on line08 not being visible, matching that boundary would make the guard more precise.
• scrollbarX = terminalCols - 2 lacks a comment explaining the -2 offset (border/gutter convention)."

Confidence Score: 5/5

Safe to merge — the new test is additive, well-structured, and all remaining findings are minor style suggestions.

Both findings are P2 style suggestions (weaker assertion boundary and missing comment). Neither affects correctness, data integrity, or the test's ability to catch regressions under normal conditions. No production code is changed.

No files require special attention.

Important Files Changed

Filename	Overview
test/integration/tuistory-hunk.integration.ts	Adds a new PTY integration test for scrollbar track click paging; follows existing patterns (try/finally, waitForSnapshot predicates) with two minor style issues: weaker initial assertion and unexplained scrollbar column offset.

Sequence Diagram

sequenceDiagram
    participant T as Test
    participant S as PTY Session
    participant H as Harness

    T->>S: launchHunk(split, 220x12)
    S-->>T: session
    T->>S: waitForText(menu bar)
    S-->>T: initial snapshot
    Note over T: assert line01 visible, line10 not visible

    T->>S: scrollDown(2)
    T->>H: waitForSnapshot(line08 visible)
    H-->>T: primed snapshot
    Note over T: assert line08 visible

    T->>S: clickAt(scrollbarX=218, row=9) [below thumb - page down]
    T->>H: waitForSnapshot(line12 visible, line08 absent)
    H-->>T: pagedDown snapshot
    Note over T: assert line12 visible, line08 not visible

    T->>S: clickAt(scrollbarX=218, row=3) [above thumb - page up]
    T->>H: waitForSnapshot(line01 visible, line12 absent)
    H-->>T: pagedUp snapshot
    Note over T: assert line01 visible, line12 not visible

    T->>S: session.close() [finally]

Loading

_{Reviews (1): Last reviewed commit: "Add PTY scrollbar track click coverage" | Re-trigger Greptile}

[greptile-apps]

Weaker initial-state assertion than the sibling test

The adjacent "mouse wheel scrolling" test uses the same fixture and terminal dimensions (220×12) and guards its initial state with not.toContain("line08 = 108"). This test uses not.toContain("line10 = 110"), which is a weaker bound—it would still pass even if the panel showed nine content lines instead of the expected seven.

Because the very next action (scrollDown(2)) relies on line08 not being visible yet, the initial negative assertion should mirror that boundary to prevent a silent false-positive if layout ever renders more content rows:

Suggested change

	expect(initial).not.toContain("line10 = 110");
	expect(initial).toContain("line01 = 101");
	expect(initial).not.toContain("line08 = 108");

[benvinegar]

This one no longer applies — I reworked the PR away from the scrollbar-track test and into a mouse menu interaction test because the scrollbar path was too flaky on CI. The current test no longer uses that initial scroll boundary.

This comment was generated by Pi using OpenAI o4-mini

[greptile-apps]

Magic - 2 offset should be commented

scrollbarX = terminalCols - 2 produces column index 218 in a 220-column terminal. The offset is not obvious—readers will wonder whether it accounts for a right-side border cell, a 1-indexed/0-indexed conversion, or the gutter width. A brief comment would make the intent clear:

Suggested change

	const scrollbarX = terminalCols - 2;
	const scrollbarX = terminalCols - 2; // scrollbar track sits one column left of the right edge

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

[benvinegar]

Also obsolete after the test rewrite: the current PR no longer computes a scrollbar column offset, since it now exercises mouse-driven menu interaction instead of scrollbar clicks.

This comment was generated by Pi using OpenAI o4-mini