Deprecate and remove per-org installation mode

[ggallen]

Summary

Deprecate the per-org GitHub installation mode in favor of per-repo (ADR 0033) as the sole supported installation model.

Motivation

Maintaining both installation modes creates significant complexity:

• Dual code paths across CLI, layers, config, scaffold, forge, dispatch, and e2e tests
• Content exposure risk for private repos routing event payloads through the public .fullsend config repo
• Higher OAuth scope requirements (admin:org) for per-org
• Three-level workflow nesting vs per-repo's two-level chain
• Enrollment machinery (config.yaml, repo-maintenance.yml, reconciliation)

Per-repo achieves feature parity while being simpler and more secure by default. ADR 0045 (harness composition via base URLs) and ADR 0038 (URL-based resource references) further eliminate the .fullsend config repo's role.

Plan

• Phase 1 (v1.x): Deprecation warnings, documentation updates, migration command, migration e2e test
• Phase 2 (v2.0): Remove all per-org code paths (breaking change)

See ADR-0044 and implementation plan for details.

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 7:01 PM UTC · Completed 7:04 PM UTC
Commit: 4e21a60 · View workflow run →

[fullsend-ai-triage]

Triage Summary

Deprecate per-org installation mode in favor of per-repo · Medium severity · Feature

Problem

Maintaining dual installation modes (per-org and per-repo) creates significant complexity across CLI, dispatch, scaffold, layers, and tests, while per-org carries additional security risks (content exposure for private repos, elevated OAuth scopes).

Relationship to existing issues

• ADR: evaluate deprecation of per-org install mode #2302 (ADR: evaluate deprecation of per-org install mode) — tracks the ADR evaluation specifically. This issue appears to supersede it by covering both the decision and full implementation. Consider whether ADR: evaluate deprecation of per-org install mode #2302 should be closed in favor of this issue.
• Simplify install command implementation while retaining single entry point #2033 (Simplify install command) — currently blocked, likely waiting on this deprecation. Per-org removal is described there as the primary simplification lever.
• Related: fullsend github status does not support per-repo install mode #2243, fullsend github: no uninstall command for per-repo setup #2161, dispatch: per-org repos.<name>.roles override ignored by role-check step #2203 — per-org-specific issues that may be closeable once deprecation lands.

Note on referenced documents

The issue references ADR-0044 and an implementation plan (docs/plans/deprecate-per-org-install.md) that do not exist on main yet. These are presumably deliverables of this work or exist on a branch.

Recommended approach

1. Finalize ADR-0044 documenting the deprecation decision and migration strategy
2. Phase 1 (v1.x): Deprecation warnings, migration command, documentation updates, migration e2e test
3. Phase 2 (v2.0): Remove all per-org code paths (breaking change)

Proposed test case

Migration e2e test:
- Given: An org with per-org installation (config repo, org-level 
  variables/secrets, enrolled repos)
- When: Run `fullsend migrate org-to-repo <org>`
- Then: Each enrolled repo becomes a standalone per-repo install with 
  correct configuration
- Verify: Deprecation warning appears on per-org CLI commands in v1.x
- Verify: Per-org commands are removed in v2.0 builds

---

Labels: Per-org deprecation is a chore spanning install and dispatch components, with medium priority given the phased timeline.

[fullsend-ai-prioritize]

RICE Priority Score: 0.53

Score breakdown

Dimension	Score	Reasoning
Reach	2	This is a platform-wide architectural change affecting all users who interact with the installation system. Both current per-org users (who must migrate) and per-repo users (who benefit from reduced complexity and fewer bugs) are impacted. The triage notes multiple related issues (#2033, #2243, #2161, #2203) indicating broad surface area.
Impact	1	The impact per user is medium — this is primarily a maintenance/simplification chore that reduces internal complexity and improves security posture (eliminating content exposure risk for private repos, reducing OAuth scope requirements). End users gain a simpler, more secure installation model, but existing workflows aren't broken today.
Confidence	0.8	High confidence. The issue is exceptionally well-described with a clear phased plan, references to ADRs, and a detailed triage summary identifying related issues. The scope is well-understood across CLI, dispatch, scaffold, layers, and tests.
Effort	3	Very complex. The change spans CLI, layers, config, scaffold, forge, dispatch, and e2e tests — touching nearly every major component. It requires a migration command, deprecation warnings, documentation updates, a migration e2e test (Phase 1), and full removal of all per-org code paths as a breaking change (Phase 2). The two-phase rollout across major versions adds coordination overhead.

Formula: (2 x 1 x 0.8) / 3 = 0.53

[fullsend-ai-triage]

Meeting update — 2026-06-17

Relevant to this issue: The team discussed merging the ADR proposing deprecation of per-org installation mode but deferred the decision to allow for additional review and broader consensus on the migration strategy.

• Decision on merging the per-org deprecation ADR was explicitly deferred
• The team wants additional review cycles before committing to the removal strategy
• Consensus-building is needed on migration planning for existing per-org users

Related PRs:

• docs(adr): deprecate per-org installation mode #2340 — docs(adr): deprecate per-org installation mode
• docs(adr): multi-repo management for per-repo installations #2392 — docs(adr): multi-repo management for per-repo installations

Next steps: Broader team review of the ADR before re-evaluating the merge decision.

Meeting notes

[fullsend-ai-triage]

Meeting update — 2026-06-18

Relevant to this issue: The manifest file approach for managing fullsend repositories was adopted, with the ADR approved. This supports the transition to per-repo as the sole installation mode.

• Decision: Manifest file approach for managing fullsend repositories is approved (ADR accepted)
• This provides a structured way to manage per-repo installations at scale

Related PRs: PR #2392 — multi-repo management for per-repo installations

Next steps: Merge the ADR PR and begin implementation.

Meeting notes