Issue #1575 needs cross-repo redirect to prevent futile re-implementation in scaffold copies

[fullsend-ai-retro]

What happened

Issue #1575 ('Code agent should follow the target repo's PR template') was created May 27 in fullsend-ai/fullsend. PR #2979 by rh-hemartin implemented the feature on Jul 3 by modifying files under internal/scaffold/fullsend-repo/. The PR received 4 review agent runs (2 failed, 1 succeeded, 1 still running), review comments from qodo-code-review and waynesun09's Review Squad, and a CHANGES_REQUESTED from ralphbean on Jul 6 noting that agent content was moving to fullsend-ai/agents. The PR was closed without merge on Jul 8 and work moved to fullsend-ai/agents#56. Issue #1575 remains open with triaged, priority/medium, feature, and component/dispatch labels — all pointing at the fullsend repo with no cross-reference to the agents repo.

What could go better

Issue #1575 retains labels that could trigger code agent dispatch (triaged, component/dispatch) in the fullsend repo. Without a redirect, an agent or contributor could repeat the mistake of implementing against internal/scaffold/fullsend-repo/. This is the exact same pattern already documented in issue #3469 (which covers issue #1789 and PR #2775 — same author, same week). Two instances of the same pattern in 5 days, both by the same author, indicate the redirect mechanism is not yet well-known or systematically applied. Confidence is high that this is a real re-dispatch risk based on the #3469 precedent.

Proposed change

Update issue #1575 with: (1) a comment noting that implementation should target fullsend-ai/agents, referencing the active follow-up PR fullsend-ai/agents#56; (2) removal of dispatch-triggering labels or addition of a blocking label to prevent code agent dispatch in the fullsend repo; (3) close the issue once agents#56 merges, or transfer it to the agents repo.

Validation criteria

Issue #1575 has a comment or body edit pointing to fullsend-ai/agents as the implementation target and referencing agents#56. Dispatch-triggering labels are removed or a blocking label is added. No future PRs in fullsend attempt to implement this issue against internal/scaffold/.

---

Generated by retro agent from #2979

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 7:34 AM UTC · Completed 7:37 AM UTC
Commit: e8381e3 · View workflow run →

[fullsend-ai-triage]

Triage Summary

This is a well-defined housekeeping task to prevent wasted agent dispatch on issue #1575.

Problem: Issue #1575 still carries dispatch-triggering labels (triaged, component/dispatch, agent/code) in the fullsend repo, even though PR #2979 was closed without merge and implementation moved to fullsend-ai/agents (PR agents#56, still open). Without a redirect, the code agent could be dispatched against the wrong repo — exactly what already happened once.

Pattern match: This is the same cross-repo redirect gap documented in #3469 (for issue #1789). Two instances in 5 days suggest a systemic gap in the hand-off process when work moves between repos.

Recommended actions on #1575:

1. Add a comment pointing to fullsend-ai/agents#56 as the active implementation target
2. Add the blocked label and remove component/dispatch to prevent code agent dispatch
3. Close Code agent should follow the target repo's PR template #1575 once agents#56 merges, or transfer it to the agents repo

Proposed verification:

1. Confirm #1575 has 'blocked' label, lacks 'component/dispatch'
2. Confirm a comment references agents#56 as the implementation target
3. Verify dispatch workflow would not pick up #1575 for code agent runs
4. After agents#56 merges, confirm #1575 is closed or transferred

Systemic consideration: Both this issue and #3469 point to a need for a systematic mechanism to prevent dispatch when implementation moves cross-repo. Consider tracking that as a separate improvement.

---

Labels: This is a housekeeping/chore issue about updating metadata on another issue. Adding type/chore and priority/medium. The issue is immediately actionable.