[RTK+Ponytail] Remove invalid top-level `return 0` guard from inlined CSMA code in post-prioritize scripts

[guyoron1]

What happened

PR #3182 inlined the CSMA library into post-prioritize.sh (line 32) and post-prioritize-test.sh (line 287) but kept the library-style load guard: [[ -n "${GITHUB_API_CSMA_SH_LOADED:-}" ]] && return 0 followed by GITHUB_API_CSMA_SH_LOADED=1. These scripts are executed directly (not sourced) and use set -euo pipefail.

The Qodo code review bot flagged this as a bug on the PR, but neither the fullsend review agent (which dismissed it as harmless dead code) nor the human reviewer acted on it. The PR was merged on July 7 with the latent bug still present.

Reproduction confirms the crash: GITHUB_API_CSMA_SH_LOADED=1 bash post-prioritize.sh fails with return: can only 'return' from a function or sourced script and exit code 2.

What could go better

The Qodo finding should have been addressed before merge. The review agent's analysis led the human reviewer to believe the guard was safe. When multiple review bots produce conflicting assessments, the author or reviewer should investigate rather than merge.

Confidence: high. The bug is latent — it only triggers if GITHUB_API_CSMA_SH_LOADED is set in the environment, which is unlikely in normal operation but possible through environment contamination or future script composition changes.

Proposed change

Remove the two-line load guard from both files:

• internal/scaffold/fullsend-repo/scripts/post-prioritize.sh lines 32-33: remove [[ -n "${GITHUB_API_CSMA_SH_LOADED:-}" ]] && return 0 and GITHUB_API_CSMA_SH_LOADED=1
• internal/scaffold/fullsend-repo/scripts/post-prioritize-test.sh lines 287-288: remove the same two lines

The guard is a library pattern for preventing double-loading when sourced; it serves no purpose in inlined code and is actively harmful in an executed script.

Validation criteria

After the fix: (1) GITHUB_API_CSMA_SH_LOADED=1 bash post-prioritize.sh no longer crashes with a return error, (2) shellcheck passes clean on both files, (3) all 7 post-prioritize tests still pass via bash internal/scaffold/fullsend-repo/scripts/post-prioritize-test.sh.

---

Generated by retro agent from fullsend-ai#3182

[guyoron1]

/fs-triage

[guyoron1]

/fs-triage

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 4:21 PM UTC · Completed 4:23 PM UTC
Commit: 412767d · View workflow run →

[fullsend-ai-triage]

This issue appears to be a duplicate of #174 — both are mirrors of the same upstream issue (fullsend-ai/fullsend#3446) and describe the identical bug: the invalid top-level return 0 load guard left behind when CSMA library code was inlined into post-prioritize.sh and post-prioritize-test.sh.

Issue #174 was filed earlier and already has a triage analysis and an open clarifying question about whether PR fullsend-ai#3182 has been applied to this codebase. The discussion there is the right place to continue tracking this work.

Recommending closing this issue in favor of #174.

[guyoron1]

/fs-triage

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 11:13 AM UTC · Completed 11:15 AM UTC
Commit: 13920b5 · View workflow run →

[fullsend-ai-triage]

This issue is a duplicate of #174 — both are mirrors of the same upstream issue (fullsend-ai/fullsend#3446) and describe the identical bug: the invalid top-level return 0 load guard left behind when CSMA library code was inlined into post-prioritize.sh and post-prioritize-test.sh.

Issue #174 was filed earlier and already has a triage analysis with an open clarifying question about whether PR fullsend-ai#3182 has been applied to this codebase. That issue is the right place to continue tracking this work.

Recommending closing this issue in favor of #174.