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

Migrate Fullsend scaffold to per-repository installation

⚙️ Configuration changes ✨ Enhancement 🕐 10-20 Minutes

AI Description

• Adds repository-scoped Fullsend configuration with pinned agents and approved remote resources.
• Routes repository events through the reusable per-repository dispatcher with required credentials
 and permissions.

Diagram

graph TD
  EVENTS["GitHub Events"] --> SHIM["Fullsend Shim"] --> DISPATCH["Reusable Dispatch"] --> AGENT["Selected Agent"] --> OPERATIONS["Repo Operations"]
  SOURCES["Pinned Sources"] --> CONFIG["Repo Config"] --> DISPATCH

Loading

High-Level Assessment

The repository-local configuration and canonical reusable dispatcher are the appropriate scaffold-defined approach. Retaining centralized configuration was considered but would preserve the external config-repository dependency that per-repository installation is intended to remove.

Files changed (2) +57 / -27

Other (2) +57 / -27

config.yamlAdd repository-scoped Fullsend configuration +33/-0

Add repository-scoped Fullsend configuration

• Defines the Claude runtime, supported roles, and integrity-pinned Fullsend and QualityFlow agent sources. Restricts remote resources and issue creation to approved Fullsend organizations and repositories.

.fullsend/config.yaml

fullsend.yamlRoute events through the per-repository dispatcher +24/-27

Route events through the per-repository dispatcher

• Replaces the centralized dispatch workflow with Fullsend's versioned reusable dispatcher in per-repository mode. Supplies runtime variables and infrastructure secrets, expands required repository permissions, and delegates stage concurrency and routing to the reusable workflow.

.github/workflows/fullsend.yaml

[qodo-code-review]

Code Review by Qodo

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

1. Permission expansion lacks authorization 📜 Skill insight ⛨ Security

Description

The dispatch job expands contents and pull-requests from read to write and adds issues: write
without a linked issue or ADR explicitly authorizing these permissions. The routing and concurrency
references do not justify why each write capability is necessary or why a lower-privilege
alternative is insufficient.

Code

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

+      contents: write
+      issues: write
+      packages: read
+      pull-requests: write

Relevance

●● Moderate

Permission-related write access documentation was accepted, but authorization requirements for this
exact expansion have mixed evidence.

PR-#38
PR-#631

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance IDs 1538316 and 1538383 require permission expansions to be least-privileged and
explicitly authorized. The changed workflow grants contents: write, issues: write, and
pull-requests: write, while the PR description contains no linked issue and the nearby ADR
references concern routing rather than these permission grants.

.github/workflows/fullsend.yaml[41-48]
Skill: code-review
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 workflow expands multiple job permissions without explicit least-privilege justification or linked authorization.

## Issue Context
Document why each write permission is required by the per-repository installation and link the authorizing issue or ADR. Remove or downgrade any permission not required by the reusable workflow.

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

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

---

2. Write workflow uses mutable tag 🐞 Bug ⛨ Security

Description

The dispatch job delegates to the mutable @v0 tag while granting contents, issues, and
pull-request write access plus OIDC token issuance. Moving or compromising that upstream tag would
execute a different workflow with repository-write and cloud-authentication capabilities without any
change reviewed in this repository.

Code

.github/workflows/fullsend.yaml[48]

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

Relevance

●● Moderate

The repository accepts deliberate floating-v0 usage documentation, but lacks a close precedent for
privileged reusable-workflow tag pinning.

PR-#25
PR-#776

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The caller explicitly grants several write and OIDC permissions at lines 41-47, then invokes the
external reusable workflow through the non-immutable v0 reference at line 48 and forwards secrets
at lines 55-59.

.github/workflows/fullsend.yaml[41-48]
.github/workflows/fullsend.yaml[55-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 write-capable reusable dispatch workflow is referenced by the mutable `v0` tag, allowing upstream tag movement to change privileged code executed in this repository.

## Issue Context
The caller grants `contents: write`, `issues: write`, `pull-requests: write`, `actions: write`, and `id-token: write`, and also forwards repository secrets.

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

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

---

3. Install config bypasses tests 🐞 Bug ☼ Reliability

Description

Changes to .fullsend/config.yaml are absent from the functional-test push paths and
agent-selection rules, so config-only changes produce no functional-test matrix on PRs or merge
queues and do not trigger the workflow after merging. An incompatible installation configuration can
therefore reach main without exercising any agent.

Code

.fullsend/config.yaml[R6-7]

+version: "1"
+runtime: claude

Relevance

●●● Strong

PR #78 accepted the same trigger-and-selector update for a newly added operational config.

PR-#78

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The added file is operational configuration, but the functional workflow's push allowlist contains
only root config.yaml; its selector recognizes harness, eval, and harness-referenced paths, and
the matrix is skipped when that selector returns []. Past PR #78 documents the same required
trigger-and-selector update for a newly added configuration file.

.fullsend/config.yaml[6-33]
.github/workflows/functional-tests.yml[9-27]
.github/workflows/functional-tests.yml[180-205]
.github/scripts/select-eval-agents.sh[74-101]
PR-#78

Agent prompt

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

## Issue description
Changes to the new `.fullsend/config.yaml` bypass functional testing: pushes do not match the workflow path filter, while PR and merge-group runs select an empty agent matrix.

## Issue Context
The operational config controls runtime, roles, remote harnesses, resource access, and issue targets. A prior accepted fix for the root configuration established that configuration files must participate in both workflow triggering and changed-file relevance detection.

## Fix Focus Areas
- .github/workflows/functional-tests.yml[9-27]
- .github/scripts/select-eval-agents.sh[74-101]
- .fullsend/config.yaml[1-33]

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

---

4. Structural change lacks linked issue 📜 Skill insight § Compliance

Description

The PR introduces a new repository configuration and structurally replaces workflow routing,
permissions, inputs, and secrets without linking an authorizing issue. The PR description only
instructs maintainers to merge the scaffold files and does not provide the authorization required
for this non-trivial change.

Code

.github/workflows/fullsend.yaml[R48-51]

+    uses: fullsend-ai/fullsend/.github/workflows/reusable-dispatch.yml@v0
    with:
      event_action: ${{ github.event.action }}
+      install_mode: per-repo

Relevance

●● Moderate

Authorization-artifact requests for structural protected changes were rejected, but this broader
migration requirement lacks a decisive precedent.

PR-#631
PR-#476

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 1538390 requires non-trivial or structural changes to have authorization through a
linked issue. The new reusable-workflow target and install_mode contract are representative of the
structural migration, while no issue is linked in the supplied PR description.

.github/workflows/fullsend.yaml[41-59]
.fullsend/config.yaml[1-33]
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
This structural workflow and installation change has no linked issue authorizing its scope.

## Issue Context
Add a linked issue to the PR description that authorizes the per-repository installation, reusable workflow migration, permission changes, inputs, and secret forwarding.

## Fix Focus Areas
- .github/workflows/fullsend.yaml[41-59]
- .fullsend/config.yaml[1-33]

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

---

5. Protected workflow requires human review 📜 Skill insight § Compliance

Description

This PR modifies .github/workflows/fullsend.yaml, a protected governance/infrastructure path. The
workflow change must receive human approval and cannot be auto-approved.

Code

.github/workflows/fullsend.yaml[48]

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

Relevance

● Weak

Comparable protected-path human-approval findings were rejected in recent governance-file reviews.

PR-#609
PR-#753

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 1538392 explicitly identifies .github/ as protected and requires a finding
whenever such a file is modified. The changed reusable-workflow reference demonstrates that this PR
modifies that protected workflow.

.github/workflows/fullsend.yaml[41-59]
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 `.github/` workflow and therefore requires human governance review.

## Issue Context
Do not auto-approve this PR. Route it to the appropriate human or code owner for review of the workflow, permissions, reusable-workflow reference, inputs, and secrets contract.

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

ⓘ 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: standard per-repo fullsend scaffold generated by the setup CLI (config.yaml + shim → reusable-dispatch.yml@v0, install_mode: per-repo). Qodo bot findings are expected for scaffold output and not blocking.