Implement independent per-repo installer

[fullsend-ai-triage]

Note

This issue was automatically generated from meeting notes by the scribe agent.
Please review, edit, and add any missing context before prioritizing.

Problem

Fullsend currently only supports organization-level installation. The team has decided to prioritize a per-repo installation mode that is mutually exclusive with org-level installation. Each repo-level installation needs its own GitHub App and cloud service accounts, operating independently from any org-level setup.

Supporting both modes simultaneously introduces maintenance overhead, security model complexity, and potential configuration conflicts. The per-repo installer must be designed as a first-class path, not an afterthought bolted onto the org installer.

Options considered

• Shared infrastructure with org installer: Reuse existing GitHub Apps and cloud accounts. Rejected due to security model conflicts and the difficulty of isolating permissions.
• Fully independent per-repo installer: Each repo gets its own GitHub App and cloud service accounts. Chosen for cleaner security boundaries and simpler reasoning about permissions, at the cost of more resources per installation.
• Hybrid approach with shared cloud accounts: Share cloud infrastructure but separate GitHub Apps. Rejected as a half-measure that doesn't fully resolve configuration conflicts.

Acceptance criteria

• fullsend admin install --repo creates a dedicated GitHub App scoped to a single repository
• Per-repo installation provisions independent cloud service accounts
• Per-repo and org-level installations are mutually exclusive — the installer prevents both from targeting the same repository
• Per-repo installation does not depend on any org-level configuration or infrastructure
• Installation, uninstallation, and enrollment workflows function correctly for repo-level installs
• Documentation updated to cover the per-repo installation path

Related

• ADR for this decision: PR docs: ADR 0033 — per-repo installation mode #707 (docs: ADR 0031 — per-repo installation mode)
• Org installer detection of repo-level installs: Org installer should detect and skip independently installed repos #725
• Source: Meeting notes

[fullsend-ai-triage]

RICE Priority Score: 0.79

Score breakdown

Dimension	Score	Reasoning
Reach	1.5	Per-repo installation directly addresses friction for multiple strategic customers. @deboer-tim (openkaiden) created a workaround fork org because he couldn't install on the real org, and @mrizzi (guacsec) hasn't onboarded yet partly due to trust concerns around org-level access. konflux-ci is already org-installed so less affected, but the mutual exclusivity logic touches their path too.
Impact	1.5	For users who cannot get org-admin approval or who need tighter permission scoping, this unblocks adoption entirely. However, workarounds exist (e.g., fork orgs like openkaiden-fullsend), so it's a significant pain point rather than a complete blocker. The feature meaningfully expands who can adopt fullsend-ai.
Confidence	0.7	The issue is well-structured with clear acceptance criteria, an associated ADR (PR #707), and a related issue (#725). The scope is well-defined. Slight uncertainty remains around the full effort required for independent cloud service account provisioning and the installer UX, which prevents a higher confidence score.
Effort	2	This is a complex change: it requires a new GitHub App creation flow scoped to a single repo, independent cloud service account provisioning, mutual exclusivity enforcement between install modes, and updates to install/uninstall/enrollment workflows plus documentation. Multiple components are affected and there is meaningful architectural work, as evidenced by the dedicated ADR.

Formula: (1.5 × 1.5 × 0.7) / 2 = 0.79

[fullsend-ai-triage]

Meeting update — 2026-05-14

Relevant to this issue: The team defined the deployment model strategy, directly informing the scope and priority of the per-repo installer.

• Conflux CI will remain on an org-level deployment model
• Full Send AI will pilot a mix of org and repo-based deployments
• Long-term goal: unify toward a single repo mode that supports org-level features
• Per-repo deployment is prioritized in part to limit potential key leaks

Related PRs: #862 (sync org variable visibility when enabling repos)

Next steps: Per-repo installation mode to be piloted alongside org-level, with eventual unification.

Meeting notes