[alejandrorpascual]

A board run stopped itself because one command asked GitHub about two tickets at once, in a slot that holds one. GitHub refused, the run counted that as GitHub failing, retried three times and halted every read. Now the board tool checks that it got exactly one ticket number and turns anything else down on the spot, so a typo fails just that command instead of the whole run.

Check it by hand

1. Check out the branch: git fetch https://github.com/alejandrorpascual/super-board fix/card-refuse-malformed-issue && git switch --detach FETCH_HEAD. You should be on commit 7b94aff.
2. Run bash tests/test-card.sh. It should end with ✅ bad card number → 64, no GitHub call, no halt and PASS: 10 card-helper checks.
3. Revert just the script (git checkout HEAD~1 -- scripts/super-board-card.sh) and run the test again. It should stop at FAIL: status '26 53' should exit 64 (rc=0). Restore with git checkout HEAD -- scripts/super-board-card.sh.
4. Run the original failing command in zsh: zsh -c 'pair="26 53"; set -- $pair; scripts/super-board-card.sh --owner acme --number 1 --repo acme/app status $1; echo rc=$?'. It should print invalid issue: '26 53' — pass one issue number per call and rc=64 at once, with no retries.

Tried by Claude: steps 2 to 4 ran on this branch on macOS (zsh, Python 3.14.7). Step 1 is written from the branch name.

Note

⏳ In review · round 1 · ✅ 4/4 AC · head 7b94aff

Problem

• Where: scripts/super-board-card.sh, during a super-board run on 2026-10-19 (installed as .claude/bin/super-board-card.sh, kit 3.1.2)
  • a. The orchestrator ran for pair in "26 53" "40 52"; do set -- $pair; n=$1; …; super-board-card.sh --config $C move $n Done; done
  • b. zsh does not word-split $pair, so n was 26 53; the arg-count check saw one argument and passed it
  • c. read_card sent -F issue="26 53" to a GraphQL Int!. The helper runs strict (SB_GITHUB_READ_STRICT=1), so the rejection counted as a GitHub failure: 3 retries, then a halt of every read in the run
• Who: any orchestrator or lane agent calling the card helper from zsh, the default shell on macOS

Solution

• New issue_arg check in the verb dispatch: move, status and item-id refuse an issue that doesn't match ^[1-9][0-9]*$
• A refusal exits 64 (the script's documented usage code) with invalid issue: '<arg>' — pass one issue number per call, before any gh call, so no retry and no halt file
• This keeps the strict-read rule (🐛 [bug] wave: agents guess github-read shapes and halt the whole wave #32) true: once the helper checks its own arguments, a rejected read really is GitHub's fault
• ids and items take no issue and are unchanged

Acceptance criteria

• status, item-id and move exit 64 for "26 53", "#26", "abc", "0" and ""
  ↳ tests/test-card.sh case 10
• None of those make a gh call or write a halt file
  ↳ tests/test-card.sh case 10 (fake gh call log empty, SB_GITHUB_HALT_FILE absent)
• Valid issue numbers behave as before
  ↳ tests/test-card.sh cases 1 to 9 unchanged and passing
• The new case fails without the fix
  ↳ FAIL: status '26 53' should exit 64 (rc=0) with the old script

Iteration history

Lane	Done	Time	Details
🔨 builder	✅	Oct 20	bash tests/test-card.sh → PASS 10 · bash tests/run-safety.sh → 61 of 62 suites pass; test-ui-refine-loop-setup.sh fails the same way (16 passed, 42 failed) on untouched main at f014cfa, so it predates this change · 7b94aff

Risk

🟢 Low · one argument check in the card helper; valid issue numbers take the same path as before

• A caller that passed a leading # (#26) or zero-padded number now gets 64 instead of a GitHub error. The kit's docs and scripts show bare numbers (move <issue> <Status>), so a correct caller is unaffected

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →