Router should provide context-specific guidance when /fs-code is used on a PR

[guyoron1]

What happened

On PR #44, the human reviewer (fgiudici) commented /fs-code at 16:42 UTC to request the code agent fix the review findings. The routing logic in workflow run 30026246718 matched the /fs-code case block, but the ISSUE_IS_PR=true gate prevented dispatch: /fs-code is gated on ISSUE_IS_PR == "false" because it is designed for issues, not PRs. The route job logged 'No stage matched -- skipping dispatch' with no user-visible feedback. The user received no indication that the command was invalid in this context or that /fs-fix was the appropriate alternative. fgiudici ended up making the fix manually.

What could go better

When a recognized /fs-* command is used in a context where it cannot apply, the router should provide actionable feedback rather than failing silently. This is distinct from #5403 (generic feedback for unrecognized commands): /fs-code IS recognized — it matched a specific case block — but the context check (ISSUE_IS_PR) prevented dispatch. The feedback should be context-specific: 'Did you mean /fs-fix? The /fs-code command only works on issues.' This would have saved fgiudici from discovering the limitation through silence and doing the work manually. Confidence is high — the routing logic and log output are unambiguous.

Proposed change

In the Route step of reusable-dispatch.yml (and dispatch.yml), within the /fs-code case block, add an else-branch when ISSUE_IS_PR == "true" that posts a brief reply comment on the triggering comment explaining that /fs-code only works on issues and suggesting /fs-fix for PRs. Implementation sketch:

/fs-code)
  if [[ "${ISSUE_IS_PR}" == "false" ]]; then
    if [[ "${COMMENT_USER_TYPE}" != "Bot" ]] && is_authorized; then
      STAGE="code"
    fi
  else
    # Context-specific feedback: /fs-code on a PR
    gh api "repos/${GITHUB_REPOSITORY}/issues/comments/${COMMENT_ID}/reactions" \
      -f content=confused 2>/dev/null || true
    gh pr comment "${PR_NUMBER}" --repo "${GITHUB_REPOSITORY}" \
      --body "The \`/fs-code\` command only works on issues. To request fixes on a PR, use \`/fs-fix\`." \
      2>/dev/null || true
  fi
  ;;

The same pattern should be applied to /fs-fix when used on an issue (if applicable), and any other commands with context restrictions. This complements fullsend-ai#5403's generic catch-all with targeted guidance for known command/context mismatches.

Validation criteria

After the fix: (1) Comment /fs-code on a PR — within 60 seconds, the triggering comment receives a 'confused' reaction and a reply comment appears suggesting /fs-fix. (2) Comment /fs-code on an issue — behavior is unchanged (code agent dispatches normally). (3) The workflow run completes cleanly with exit code 0. Verify on 2-3 repos to confirm cross-repo consistency.

---

Generated by retro agent from release-engineering/fbc-update-planner#44

[guyoron1]

/fs-triage

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 8:48 AM UTC · Completed 8:51 AM UTC
Commit: c887fc4 · View workflow run →

[fullsend-ai-triage]

Triage Summary

Severity: Low · Category: Enhancement (workflow UX)

Problem

When /fs-code is commented on a PR, the routing logic matches the command but the ISSUE_IS_PR gate silently prevents dispatch. No reaction or reply is posted — the user gets no indication that the command is invalid in this context or that /fs-fix is the correct alternative. This was observed in practice on release-engineering/fbc-update-planner PR #44, where the reviewer received no feedback and ended up making the fix manually.

Root Cause

The /fs-code case block in the Route step of reusable-dispatch.yml (and dispatch.yml) only handles the ISSUE_IS_PR=false path. There is no else-branch for the PR context, so execution falls through silently.

Recommended Fix

Add an else-branch in the /fs-code case block for ISSUE_IS_PR=true that posts a confused reaction and a reply comment suggesting /fs-fix. Apply the same pattern to other context-restricted commands (e.g., /fs-fix on issues, if applicable). This complements the generic unrecognized-command feedback tracked in fullsend-ai#5403.

Proposed Test Case

Scenario 1: /fs-code on a PR
  Given a PR in an enrolled repository
  When a user comments /fs-code
  Then a 'confused' reaction appears on the comment
  And a reply suggests using /fs-fix instead
  And the workflow exits cleanly (exit 0)

Scenario 2: /fs-code on an issue (unchanged)
  Given an issue in an enrolled repository
  When a user comments /fs-code
  Then the code agent dispatches normally

⚠ Workflow File Changes Required

This fix requires modifying GitHub Actions workflow files (reusable-dispatch.yml and dispatch.yml). The code agent cannot modify workflow files under current permissions — manual intervention (a human-authored PR or maintainer action) is required to implement this change.

---

Labels: The issue involves the dispatch routing workflow (component/dispatch) and requests new UX behavior for existing commands (enhancement). Both labels are already applied.

---

Next steps:

• /fs-code — agent creates a PR to implement this issue
• /fs-code <your instruction> — agent implements with your specific guidance

Previous run

Triage Summary

Severity: Low · Category: Enhancement (workflow UX)

Problem

When /fs-code is commented on a PR, the routing logic matches the command but the ISSUE_IS_PR gate silently prevents dispatch. No reaction or reply is posted — the user gets no indication that the command is invalid in this context or that /fs-fix is the correct alternative.

Root Cause

The /fs-code case block in the Route step of reusable-dispatch.yml and dispatch.yml only handles the ISSUE_IS_PR=false path. There is no else-branch for the PR context, so execution falls through silently.

Recommended Fix

Add an else-branch in the /fs-code case block for ISSUE_IS_PR=true that posts a confused reaction and a reply comment suggesting /fs-fix. Apply the same pattern to other context-restricted commands.

Proposed Test Case

Scenario 1: /fs-code on a PR
  Given a PR in an enrolled repository
  When a user comments /fs-code
  Then a 'confused' reaction appears on the comment
  And a reply suggests using /fs-fix instead
  And the workflow exits cleanly (exit 0)

Scenario 2: /fs-code on an issue (unchanged)
  Given an issue in an enrolled repository
  When a user comments /fs-code
  Then the code agent dispatches normally

⚠ Workflow File Changes Required

This fix requires modifying GitHub Actions workflow files (reusable-dispatch.yml and dispatch.yml). The code agent cannot modify workflow files under current permissions — manual intervention (a human-authored PR or maintainer action) is required to implement this change.

Related

This complements the generic unrecognized-command feedback tracked in fullsend-ai#5403 — that issue covers unknown commands; this one covers known commands used in the wrong context.

---

Labels: This issue directly involves the dispatch routing workflow (component/dispatch) and is a UX enhancement to existing behavior (enhancement).

---

Next steps:

• /fs-code — agent creates a PR to implement this issue
• /fs-code <your instruction> — agent implements with your specific guidance

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 8:56 AM UTC · Completed 9:00 AM UTC
Commit: c887fc4 · View workflow run →

[guyoron1]

/fs-code

[fullsend-ai-coder]

🤖 Finished Code · ❌ Failure · Started 9:36 AM UTC · Completed 9:59 AM UTC
Commit: c887fc4 · View workflow run →

[fullsend-ai-coder]

⚠️ Post-code script failed — Pre-commit blocked (exit code 1)

The code agent completed, but the post-code script failed before finishing.

Workflow run: https://github.com/guyoron1/fullsend/actions/runs/30741796190

Details:
check toml...........................................(no files to check)Skipped
mixed line ending........................................................Passed
ruff (legacy alias)..................................(no files to check)Skipped
ruff format..........................................(no files to check)Skipped
ty check.............................................(no files to check)Skipped
bandit...............................................(no files to check)Skipped
Detect hardcoded secrets.................................................Passed
shellcheck...........................................(no files to check)Skipped
pinact (SHA-pin check)...................................................Failed
- hook id: pinact
- exit code: 2

�[31mERROR�[0m failed to handle a line: action can't be pinned
.github/workflows/fullsend.yaml:52
    uses: guyoron1/fullsend/.github/workflows/reusable-dispatch.yml@main
::error file=.github/workflows/fullsend.yaml,line=52,title=pinact error::action can't be pinned

Lint GitHub Actions workflow files.......................................Passed
gofmt....................................................................Passed
go vet...................................................................Passed
lint mint embed sync.................................(no files to check)Skipped
lint interface doc sync..............................(no files to check)Skipped
lint ADR statuses....................................(no files to check)Skipped
lint ADR numbers.....................................(no files to check)Skipped
lint ADR frontmatter.................................(no files to check)Skipped
lint broken symlinks.....................................................Passed
lint docs link scope.................................(no files to check)Skipped
lint markdown links......................................................Passed
lint workflow file size..................................................Passed
lint-staged (web)....................................(no files to check)Skipped

Please check the workflow logs for full details and retry with /fs-code if appropriate.