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

Scaffold fullsend per-repo installation configuration and workflow

⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Add per-repo fullsend configuration and pin agent harness sources.
• Switch GitHub Actions shim to fullsend reusable-dispatch per-repo mode.
• Expand workflow permissions and pass required vars/secrets for mint/GCP/WIF.

Diagram

graph TD
  A["GitHub Events"] --> B[".github/workflows/fullsend.yaml"] --> C["fullsend reusable-dispatch.yml"] --> D["In-repo agent runs"]
  D --> E[".fullsend/config.yaml"]
  D --> F[("Mint / GCP via OIDC")]

  subgraph Legend
    direction LR
    _wf["Workflow"] ~~~ _cfg["Config file"] ~~~ _ext[("External service")]
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Pin reusable workflow to an immutable commit SHA

• ➕ Stronger supply-chain guarantees than a moving tag like v0
• ➕ Reproducible behavior across reruns
• ➖ Requires periodic manual/automated bump PRs to receive updates
• ➖ Less convenient than tag-based upgrades

2. Vendor the dispatcher workflow into this repo

• ➕ Full control/auditability of workflow code
• ➕ No dependency on external workflow availability
• ➖ More maintenance burden and higher drift risk from upstream fullsend
• ➖ Larger surface area for local changes and mistakes

Recommendation: The PR’s approach (reusable-dispatch per-repo mode) is a good default for keeping routing logic upstream while executing in-repo. Consider pinning the referenced reusable workflow to a commit SHA (or a semver tag) to reduce supply-chain risk versus using @v0, especially given the elevated permissions and injected secrets.

Files changed (2) +57 / -27

Other (2) +57 / -27

config.yamlAdd per-repo fullsend configuration with pinned agent sources +33/-0

Add per-repo fullsend configuration with pinned agent sources

• Introduces the per-repo fullsend config declaring runtime, roles, and agent harness sources pinned to specific upstream SHAs. Restricts remote resource origins and defines allowed org/repo targets for issue creation.

.fullsend/config.yaml

fullsend.yamlSwitch fullsend shim workflow to per-repo reusable dispatcher +24/-27

Switch fullsend shim workflow to per-repo reusable dispatcher

• Updates the managed shim workflow to call fullsend's reusable-dispatch.yml in per-repo installation mode. Adjusts routing commentary, expands required permissions, and passes required vars/secrets for mint URL, GCP region/WIF, runner image, and OTEL headers.

.github/workflows/fullsend.yaml

[qodo-code-review]

Code Review by Qodo

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

1. Unpinned external workflow 🐞 Bug ⛨ Security

Description

The dispatch job executes a reusable workflow from another repository pinned only to the mutable ref
@v0 while granting contents/issues/pull-requests: write and forwarding multiple secrets. If that
ref is moved or the upstream repo is compromised, arbitrary workflow code could run with this repo’s
token permissions and whatever forwarded secrets are available for the triggering event.

Code

.github/workflows/fullsend.yaml[R44-48]

+      contents: write
+      issues: write
+      packages: read
+      pull-requests: write
+    uses: fullsend-ai/fullsend/.github/workflows/reusable-dispatch.yml@v0

Relevance

●● Moderate

Security concern is valid, but workflow is scaffold-managed; no repo precedent requiring SHA pinning
for reusable workflows.

PR-#13
PR-#46

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The updated shim grants write-scoped permissions and forwards secrets while calling a reusable
workflow by a mutable ref, expanding the blast radius if the referenced workflow content changes
upstream.

.github/workflows/fullsend.yaml[41-59]

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 workflow calls an external reusable workflow (`fullsend-ai/fullsend/.github/workflows/reusable-dispatch.yml@v0`) using a mutable ref while granting broad write permissions and passing secrets. This creates a supply-chain risk because the exact executed workflow content can change without review in this repo.

### Issue Context
- The caller job’s `permissions` apply to the called reusable workflow.
- Secrets explicitly mapped under `secrets:` are forwarded to the reusable workflow when available for the event.

### Fix Focus Areas
- `.github/workflows/fullsend.yaml[41-59]`

### What to change
1. Pin the reusable workflow to an immutable commit SHA (or a verifiably immutable, protected ref) instead of `@v0`.
2. Reduce `permissions:` to the minimum required by the reusable workflow (ideally start from `contents: read` and add only what is strictly necessary).
3. Forward only the secrets that are strictly required; if some are optional, consider guarding the job (or failing fast with a clear message) when required secrets/vars are not configured.

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

---

Context

✅ Compliance rules (platform): 19 rules

✅ Skills: writing-how-to

Tip of the day

💡 Did you know, you can describe a rule in plain language on the Rules page and Qodo drafts it for you

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-code-review]

1. Unpinned external workflow 🐞 Bug ⛨ Security

The dispatch job executes a reusable workflow from another repository pinned only to the mutable ref
@v0 while granting contents/issues/pull-requests: write and forwarding multiple secrets. If that
ref is moved or the upstream repo is compromised, arbitrary workflow code could run with this repo’s
token permissions and whatever forwarded secrets are available for the triggering event.

Agent Prompt

### Issue description
The workflow calls an external reusable workflow (`fullsend-ai/fullsend/.github/workflows/reusable-dispatch.yml@v0`) using a mutable ref while granting broad write permissions and passing secrets. This creates a supply-chain risk because the exact executed workflow content can change without review in this repo.

### Issue Context
- The caller job’s `permissions` apply to the called reusable workflow.
- Secrets explicitly mapped under `secrets:` are forwarded to the reusable workflow when available for the event.

### Fix Focus Areas
- `.github/workflows/fullsend.yaml[41-59]`

### What to change
1. Pin the reusable workflow to an immutable commit SHA (or a verifiably immutable, protected ref) instead of `@v0`.
2. Reduce `permissions:` to the minimum required by the reusable workflow (ideally start from `contents: read` and add only what is strictly necessary).
3. Forward only the secrets that are strictly required; if some are optional, consider guarding the job (or failing fast with a clear message) when required secrets/vars are not configured.

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