`gh stack view` silently ignores positional arguments, including a valid different stack number

gh stack view コマンドの引数解析から始め、issue にある 2 つのコマンドを、終了ステータスと出力を含めて再現してください。gh stack checkout が stack 番号をどのように処理するかを確認し、その後、有効および無効な位置引数のテストカバレッジを追加してください。完了の条件は、コマンドがそれらを暗黙的に無視しなくなることです。明確に拒否するか、stack の選択を一貫してサポートする必要があります。

Summary

gh stack view accepts no positional argument, but supplying one is silently discarded instead of rejected. The harmful case is passing a valid stack number that isn't the current one — you get a different stack's contents, with that stack's number in the header, and no indication your argument was ignored.

On a branch belonging to stack #6, asking for stack #3 (which exists):

$ gh stack view --short 3
Stack #6                          <-- rendered #6, not the #3 that was requested
├ stack-b-two ○ #5
» stack-b-one ○ #4 (current)
└ main

$ gh stack view --short garbage999
Stack #6                          <-- also silently succeeds
├ stack-b-two ○ #5
» stack-b-one ○ #4 (current)
└ main

Exit status is 0 in both cases.

Why this matters

The output carries a stack number in its header, so it reads as authoritative. Anyone comparing two stacks — or scripting against view — can act on the wrong one without any signal. It is also a natural mistake to make, because gh stack checkout does take a stack number, so the two commands look like they share a selector.

Reproduction

In a repo with two stacks:

git switch <a-branch-in-stack-B>
gh stack view --short <stack-A-number>   # shows stack B
gh stack view --short garbage999         # shows stack B

Public repo with two stacks set up for this: https://github.com/xn/gh-stack-repro

Expected

Either error with unknown argument "3" (the usual gh behaviour for unexpected positionals), or accept a stack selector here the way gh stack checkout does. The latter would also give a non-interactive escape hatch for the ambiguity in #415.

Environment

• gh 2.97.0
• gh-stack v0.1.0
• git 2.50.1
• macOS 26.4.1, darwin/arm64