Forge Campaign for Governed Multi-Repo Automation
Core Thesis
Forge Campaign is a standout idea because it treats multi-repo automation as a governed SDLC unit, not just an agent touching several repositories.
The key message is: a multi-repo agent run should be a campaign with intent, manifest, branches, evidence, and decision state.
Condensed Thought
Modern software changes often cross repository boundaries: design system updates, docs site updates, API changes, SDK updates, integration changes, migration work, and platform-wide remediation. Agents can help with this work, but multi-repo automation becomes risky if it is only tracked through scattered branches and pull requests.
Forge Campaign defines a campaign as a multi-repo, branch-aware automation effort governed under one ForgeRun. It uses a manifest, one or more AgentRuns, optional Fleet execution, EvidencePackets, and Lenses review.
Why It Stands Out
Many tools can operate across repositories, but Forge's differentiator is governance around that work. The campaign is not just execution. It includes intent, repo list, branch naming, evidence expectations, orchestration, and final human decision.
That framing is valuable because multi-repo work has higher coordination risk. A change may be correct in one repo and incomplete in another. Evidence has to show cross-repo consistency, not only local success.
Forge Ecosystem Hooks
- ForgeRun anchors the campaign.
- Campaign manifest records repos, branches, phases, and expectations.
- AgentRuns record the participating workcells.
- Fleet can execute containerized audit or remediation steps.
- Workcells such as campaign_orchestrator and fleet_ux_worker perform scoped campaign work.
- EvidencePacket includes audit results, quality gates, artifacts, and cross-repo findings.
- Lenses provides human review and decision.
Architecture Implications
Governed multi-repo automation requires:
- A campaign manifest with stable identifiers.
- Explicit repo roles and branch naming conventions.
- Run-level governance through ForgeRun.
- Separate AgentRuns for participating workers.
- Evidence expectations by repo and by campaign phase.
- Clear distinction between job execution and campaign decision state.
- Human approval for merge or final adoption.
- A way to represent partial success and cross-repo inconsistency.
Forge Campaign can become the bridge from L3 use-case slice autonomy toward L4 and higher feature/component or subsystem work.
Blog Post Seed Paragraph
A multi-repo agent run is not just a bigger pull request. It is a coordination problem. Which repos are in scope? Which branches were created? Which phases ran? Which workcells participated? What evidence proves the change works across boundaries? Forge Campaign answers those questions by wrapping multi-repo automation in a ForgeRun-backed campaign. The manifest defines the effort, AgentRuns perform scoped work, Fleet may execute jobs, and Lenses presents the evidence for human decision.
Risks And Counterarguments
Multi-repo automation has high blast radius. Forge Campaign should default to conservative gates, explicit manifests, and strong evidence. It should be easy to stop, defer, or split a campaign when the work exceeds its declared boundary.