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

Point per-repo Fullsend dispatch at main

⚙️ Configuration changes 🕐 Less than 5 minutes

AI Description

• Routes per-repository Fullsend dispatches through the reusable workflow's main branch.
• Replaces the v0 reference so installations receive current workflow behavior.

High-Level Assessment

The following are alternative approaches to this PR:

1. Pin an immutable commit

• ➕ Provides reproducible workflow execution
• ➕ Prevents unreviewed upstream changes from affecting this repository
• ➖ Requires manual updates for every upstream workflow change
• ➖ Does not automatically receive Fullsend fixes and installation changes

2. Retain a versioned tag

• ➕ Balances update control with readable release versioning
• ➕ Limits adoption to explicitly published workflow versions
• ➖ Depends on timely tag maintenance
• ➖ Can leave per-repository installations behind current scaffold behavior

Recommendation: Use the main branch reference when the installation must continuously follow Fullsend's current reusable workflow. Prefer an immutable commit or release tag instead if reproducibility and controlled rollout are more important than automatic updates.

Files changed (1) +1 / -1

Other (1) +1 / -1

fullsend.yamlUse the main reusable dispatch workflow +1/-1

Use the main reusable dispatch workflow

• Changes the per-repository Fullsend dispatch job from the v0 reusable workflow reference to main, allowing it to consume current upstream workflow behavior.

.github/workflows/fullsend.yaml

[qodo-code-review]

Code Review by Qodo

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

1. fullsend.yaml requires human approval 📜 Skill insight § Compliance

Description

This PR modifies a protected .github/ workflow without a linked issue or explicit justification.
The governance change must receive human approval and block automatic approval.

Code

.github/workflows/fullsend.yaml[48]

+    uses: fullsend-ai/fullsend/.github/workflows/reusable-dispatch.yml@main

Relevance

●●● Strong

Protected workflow governance findings align with accepted security and release-stability reviews;
this change lacks authorization justification.

PR-#25
PR-#80

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 1538392 requires a finding whenever a protected .github/ file is modified and
requires high severity when no linked issue or explanation is provided. The cited workflow line is
changed by this PR from the v0 reference to main, while the PR description contains no linked
authorization.

.github/workflows/fullsend.yaml[48-48]
Skill: pr-review

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 PR modifies a protected workflow path and changes the reusable workflow reference from `v0` to `main`, but provides no linked issue or explicit authorization for this governance/infrastructure change.

## Issue Context
Changes under `.github/` require human approval. Add a linked issue or ADR explaining and authorizing the mutable workflow-reference change, then route the PR for human review.

## Fix Focus Areas
- .github/workflows/fullsend.yaml[48-48]

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

---

2. Unreleased workflow gains credentials 🐞 Bug ⛨ Security

Description

Switching dispatch from stable v0 to main makes every upstream commit immediately executable
with this repository’s write permissions, OIDC token, and passed secrets. This bypasses the
documented stable-release gate, so a faulty or compromised upstream commit could mutate the
repository or expose credentials before a stable release is cut.

Code

.github/workflows/fullsend.yaml[48]

+    uses: fullsend-ai/fullsend/.github/workflows/reusable-dispatch.yml@main

Relevance

●●● Strong

Recent reviews accepted hardening against drifting or unverified workflow dependencies, especially
where CI handles privileged credentials.

PR-#80
PR-#776

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The changed uses line selects upstream main, while the surrounding job grants actions, contents,
issues, and pull-request write access, an OIDC token, and four named secrets. Repository
documentation explicitly states that v0 tracks only the latest stable non-prerelease release,
proving that this change bypasses the established stable-delivery boundary.

.github/workflows/fullsend.yaml[41-59]
AGENTS.md[61-79]

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 reusable dispatch workflow now references the mutable upstream `main` branch. Consequently, unreleased upstream code can run with write permissions, OIDC access, and repository secrets.

## Issue Context
The repository documents `v0` as the floating reference for the latest stable non-prerelease version. Restore `@v0`, or preferably use an immutable commit SHA corresponding to an approved stable release.

## Fix Focus Areas
- .github/workflows/fullsend.yaml[48-48]

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

---

Context sources

✅ Compliance rules (platform): 55 rules

✅ Skills: 4 invoked

  code-review

  code-implementation

  pr-review

  docs-review

Tip of the day

💡 Did you know, you can keep summaries lean with Finding overflow, which tucks the rest behind 'View more'

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[waynesun09]

Approving: shim tag change @v0 → @main to dogfood the fullsend dispatch/orchestration workflow at main before users. CLI binary intentionally stays on the latest release (fullsend_version unset → latest); workflow-only dogfooding is the intent.