prioritize workflow should use the reusable workflow pattern

[ralphbean]

What happens

The five stage workflows (triage, code, review, fix, retro) follow a reusable workflow pattern: callers invoke reusable-*.yml with a fullsend_ai_ref input, and the reusable workflow handles the checkout, workspace prep, and action resolution from .defaults/.

prioritize.yml and repo-maintenance.yml in internal/scaffold/fullsend-repo/.github/workflows/ still use the old pattern: hardcoded ref: v0, sparse-checkout, rm -rf .defaults, and remote action refs (fullsend-ai/fullsend/.github/actions/*@v0).

What should happen

prioritize should follow the same reusable workflow pattern as the other stages, with a reusable-prioritize.yml upstream and a thin caller in the scaffold. This would bring it into the fullsend_ai_ref version-pinning story and keep the checkout/action-resolution logic consistent across all workflows.

Context

Came up during review of #1278 (version pinning). The author noted that prioritize doesn't have a reusable workflow, so the pattern can't be applied without a larger change. #1611 (synchronous dispatch, ADR 41) touches prioritize but doesn't convert it to the reusable pattern. See the discussion thread.

Related: #1075 (SHA pinning for reusable workflows and actions).

[fullsend-ai-triage]

Triage Summary

Category: Feature — convert prioritize workflow to reusable pattern
Severity: Medium

Problem

The prioritize.yml scaffold workflow uses the old inline pattern (sparse-checkout with ref: v0, manual workspace prep, rm -rf .defaults, hardcoded remote action refs) while the other five stages (triage, code, review, fix, retro) all use the reusable workflow_call pattern. This prevents prioritize from participating in fullsend_ai_ref version pinning and creates maintenance divergence.

Recommended Approach

1. Create .github/workflows/reusable-prioritize.yml upstream, mirroring the structure of reusable-triage.yml — accept workflow_call inputs for event routing, mint URL, GCP region, and fullsend_version.
2. Convert the scaffold's prioritize.yml into a thin caller that invokes the reusable workflow, passing through inputs and secrets.
3. Check repo-maintenance.yml — the issue notes it uses the same old pattern and may warrant the same conversion.

Dependencies

• Related to feat(workflows): add fullsend_ai_ref for self-consistent version pinning #1278 (version pinning) which motivated this request — that PR cannot fully apply fullsend_ai_ref to prioritize without this change.
• feat(dispatch): synchronous workflow_call event dispatch (ADR 41) #1611 (synchronous dispatch / ADR 41) touches prioritize but does not convert it.
• admin install should pin reusable workflows and actions to a commit SHA instead of v0 #1075 (SHA pinning) is a broader follow-up that would also benefit from this consistency.

Proposed Test

1. Deploy reusable-prioritize.yml and thin caller to a test .fullsend org
2. Trigger prioritize via workflow_dispatch with valid event payload
3. Verify workspace prep produces correct layered directory structure
4. Verify prioritize agent runs with correct env vars
5. Test fullsend_ai_ref with a non-default ref to confirm version pinning works
6. Edge case: verify customized/ overrides are still layered correctly

---

Labels: Prioritize agent workflow refactor touching dispatch/scaffold patterns, medium priority consistency improvement.

[ralphbean]

Took a look at the current state. The scaffold's prioritize.yml has the full checkout → sparse-checkout → layer-defaults → validate-enrollment → mint-token → setup-gcp → setup-agent-env → run-agent sequence inlined (~109 lines), with hardcoded ref: v0 and direct fullsend-ai/fullsend/.github/actions/*@v0 refs. Compare that to triage's caller which is ~39 lines delegating to reusable-triage.yml.

The workspace-prep logic in the current prioritize caller is also a stale copy — it doesn't have the per-repo install mode support or the fullsend_version input that the reusable workflows already picked up.

The only real differences from the other stages are minor:

• No target-repo checkout (prioritize just mkdir -p target-repo)
• Passes PRIORITIZE_ORG and PRIORITIZE_PROJECT_NUMBER env vars

Neither of those would be hard to parameterize in a reusable workflow. Looks like it was just written before the pattern was established and never converted.

[ifireball]

ADR 41 suggests coming up with a reusable-custom.yaml file for custom agents instead of having to make a reusable-XXX file for each and every agent. Not sure if that is applicable here.

[ralphbean]

Per-agent settings (like PRIORITIZE_PROJECT_NUMBER) via .fullsend/config.yaml is related to #1605 / PR #1848 (forge-portable harness schema). For now, project_number is threaded as a vars.* input through workflow_call.