chore: update fullsend per-repo installation

[ggallen]

The default branch (main) has branch protection rules that prevent direct pushes.

Merge this PR to deliver the scaffold files.

[qodo-code-review]

PR Summary by Qodo

Pin fullsend reusable workflows and add per-repo scaffold workflow

⚙️ Configuration changes ✨ Enhancement 🕐 20-40 Minutes

AI Description

• Pin fullsend reusable workflow references to a specific commit for reproducible runs.
• Extend per-repo installation inputs (project number) and permitted remote resources.
• Add managed Prioritize workflow scaffold to invoke fullsend’s reusable prioritize pipeline.

Diagram

graph TD
  A["Repo fullsend config"] --> B["GitHub Actions"] --> C["fullsend.yaml dispatch"] --> D["Reusable dispatch (pinned)"]
  B --> E["prioritize.yml"] --> F["Reusable prioritize (pinned)"]
  B --> G[("Repo vars/secrets")]
  D --> G
  F --> G

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Keep using @main for reusable workflows

• ➕ No need to update SHAs when upstream changes
• ➕ Always picks up latest fixes/features automatically
• ➖ Non-reproducible runs; upstream changes can break this repo unexpectedly
• ➖ Harder to audit what code executed for a given run

2. Pin to a version tag or release branch instead of a commit SHA

• ➕ More stable than @main while reducing update churn vs raw SHAs
• ➕ Easier to understand and communicate supported versions
• ➖ Requires upstream to publish/maintain tags/releases reliably
• ➖ Still not as immutable as a commit SHA if tags are moved (rare but possible)

3. Vendor reusable workflows into this repo

• ➕ Full control and auditability; no external fetch at runtime
• ➕ Can customize behavior without upstream coordination
• ➖ Higher maintenance burden and drift from upstream
• ➖ Loses benefits of centrally managed reusable workflows

Recommendation: Pinning reusable workflows to an immutable commit SHA is the safest approach for branch-protected repos because it improves reproducibility and reduces surprise breakages. If update cadence becomes painful, consider switching to upstream version tags/releases, but keep avoiding @main for stability.

Files changed (3) +52 / -8

Other (3) +52 / -8

config.yamlAlign per-repo fullsend config with upstream resources and roles +4/-7

Align per-repo fullsend config with upstream resources and roles

• Removes legacy runtime/agent configuration and updates allowed remote resources to fullsend-ai endpoints. Adds the "fix" role and tightens the per-repo installation configuration for issue creation targets.

.fullsend/config.yaml

fullsend.yamlPin reusable dispatch workflow and pass project_number input +2/-1

Pin reusable dispatch workflow and pass project_number input

• Switches the reusable workflow reference from @main to a specific commit SHA for deterministic execution. Adds a project_number input sourced from repo variables.

.github/workflows/fullsend.yaml

prioritize.ymlAdd managed Prioritize workflow scaffold invoking fullsend reusable workflow +46/-0

Add managed Prioritize workflow scaffold invoking fullsend reusable workflow

• Introduces a new workflow_dispatch-driven Prioritize workflow managed by fullsend. It forwards event inputs to the pinned reusable prioritize workflow, sets concurrency per issue, and wires required vars/secrets for GCP/WIF and telemetry.

.github/workflows/prioritize.yml

[ggallen]

Closing — will re-install after #6490 lands with project_number passthrough.

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0) 📜 Skill insights (0)

1. Prioritize concurrency collisions 🐞 Bug ☼ Reliability

Description

The new prioritize thin-caller sets concurrency.group using only
fromJSON(inputs.event_payload).issue.number, but the called reusable-prioritize.yml explicitly
supports either an issue or a pull_request payload; when the payload is PR-shaped, the group suffix
becomes empty and cancel-in-progress: true can cancel unrelated runs for the same repo.

Code

.github/workflows/prioritize.yml[R26-28]

+concurrency:
+  group: fullsend-prioritize-${{ inputs.source_repo }}-${{ fromJSON(inputs.event_payload).issue.number }}
+  cancel-in-progress: true

Relevance

●●● Strong

Recent workflow reviews accept fixes preventing concurrency collisions and unintended cancellation
across event types.

PR-#5482
PR-#2106

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The new thin caller keys concurrency solely off issue.number, while the reusable prioritize
workflow demonstrates that payloads may contain either issue or pull_request and guards against
that with an explicit fallback; without that fallback, the caller’s group can collapse and trigger
unintended cancellations.

.github/workflows/prioritize.yml[26-33]
.github/workflows/reusable-prioritize.yml[58-60]
PR-#603

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`concurrency.group` in `.github/workflows/prioritize.yml` uses only `.issue.number` from the JSON payload. When the payload is for a pull request (no `issue` object), the group string can become `fullsend-prioritize-<repo>-`, causing cross-run cancellations due to `cancel-in-progress: true`.

## Issue Context
The called workflow (`.github/workflows/reusable-prioritize.yml`) already anticipates both issue and PR payloads by using `issue.number || pull_request.number` in its own concurrency group.

## Fix Focus Areas
- .github/workflows/prioritize.yml[26-28]

## Suggested change
Update the group to mirror the reusable workflow’s fallback logic, e.g.:
```yaml
concurrency:
 group: fullsend-prioritize-${{ inputs.source_repo }}-${{ fromJSON(inputs.event_payload).issue.number || fromJSON(inputs.event_payload).pull_request.number }}
 cancel-in-progress: true
```
(Optionally add a final fallback like `${{ github.run_id }}` if neither exists.)

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Duplicate allow_targets repo 🐞 Bug ⚙ Maintainability

Description

.fullsend/config.yaml lists fullsend-ai/fullsend twice under
create_issues.allow_targets.repos, which is redundant and can cause confusing or duplicated
downstream behavior in any logic that iterates these targets.

Code

.fullsend/config.yaml[R19-21]

        repos:
            - fullsend-ai/fullsend
+            - fullsend-ai/fullsend

Relevance

●●● Strong

Recent precedents accept removing duplicate or redundant entries; this is a trivial deterministic
cleanup.

PR-#848
PR-#1016

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The config file in this PR contains the duplicate entry. The config validation for create_issues
checks only formatting (owner/name) and does not reject duplicates, so this redundancy will persist
undetected unless cleaned up.

.fullsend/config.yaml[17-21]
internal/config/config.go[821-836]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The per-repo fullsend config includes the same repo twice in `create_issues.allow_targets.repos`.

## Issue Context
`create_issues.allow_targets.repos` is an allowlist used to control where agents may create issues. Duplicates provide no additional capability and increase the risk of confusion or duplicated actions in any consumer that iterates this list.

## Fix Focus Areas
- .fullsend/config.yaml[17-21]

## Suggested change
Remove one of the duplicated entries so the list contains each repo only once.

Example:
```yaml
create_issues:
 allow_targets:
   repos:
     - fullsend-ai/fullsend
```

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context sources

✅ Compliance rules (platform): 58 rules

✅ Skills: writing-user-docs, writing-adrs

Tip of the day

💡 Did you know, you can commit Qodo's fix in one click with committable suggestions (GitHub & GitLab)

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-code-review]

1. Prioritize concurrency collisions 🐞 Bug ☼ Reliability

The new prioritize thin-caller sets concurrency.group using only
fromJSON(inputs.event_payload).issue.number, but the called reusable-prioritize.yml explicitly
supports either an issue or a pull_request payload; when the payload is PR-shaped, the group suffix
becomes empty and cancel-in-progress: true can cancel unrelated runs for the same repo.

Agent Prompt

## Issue description
`concurrency.group` in `.github/workflows/prioritize.yml` uses only `.issue.number` from the JSON payload. When the payload is for a pull request (no `issue` object), the group string can become `fullsend-prioritize-<repo>-`, causing cross-run cancellations due to `cancel-in-progress: true`.

## Issue Context
The called workflow (`.github/workflows/reusable-prioritize.yml`) already anticipates both issue and PR payloads by using `issue.number || pull_request.number` in its own concurrency group.

## Fix Focus Areas
- .github/workflows/prioritize.yml[26-28]

## Suggested change
Update the group to mirror the reusable workflow’s fallback logic, e.g.:
```yaml
concurrency:
  group: fullsend-prioritize-${{ inputs.source_repo }}-${{ fromJSON(inputs.event_payload).issue.number || fromJSON(inputs.event_payload).pull_request.number }}
  cancel-in-progress: true
```
(Optionally add a final fallback like `${{ github.run_id }}` if neither exists.)

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[qodo-code-review]

2. Duplicate allow_targets repo 🐞 Bug ⚙ Maintainability

.fullsend/config.yaml lists fullsend-ai/fullsend twice under
create_issues.allow_targets.repos, which is redundant and can cause confusing or duplicated
downstream behavior in any logic that iterates these targets.

Agent Prompt

## Issue description
The per-repo fullsend config includes the same repo twice in `create_issues.allow_targets.repos`.

## Issue Context
`create_issues.allow_targets.repos` is an allowlist used to control where agents may create issues. Duplicates provide no additional capability and increase the risk of confusion or duplicated actions in any consumer that iterates this list.

## Fix Focus Areas
- .fullsend/config.yaml[17-21]

## Suggested change
Remove one of the duplicated entries so the list contains each repo only once.

Example:
```yaml
create_issues:
  allow_targets:
    repos:
      - fullsend-ai/fullsend
```

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools