Forge Platform

Handbook

Forge Campaign for Governed Multi-Repo Automation

Forge Campaign is a standout idea because it treats multi-repo automation as a governed SDLC unit, not just an agent touching several repositories.

Updated

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:

  1. A campaign manifest with stable identifiers.
  2. Explicit repo roles and branch naming conventions.
  3. Run-level governance through ForgeRun.
  4. Separate AgentRuns for participating workers.
  5. Evidence expectations by repo and by campaign phase.
  6. Clear distinction between job execution and campaign decision state.
  7. Human approval for merge or final adoption.
  8. 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.

Who this is for

Architects and platform engineers evaluating Forge (evaluate stage). Executives can stop after the core thesis; agents should honor the agent contract in the page frontmatter.

Evidence and maturity

Maturity: defined — this page records design intent captured from the Agentic SDLC standout analysis and reviewed for the platform handbook. Where behavior is shipped and observable it is called out explicitly; everything else should be read as direction, not commitment. Evidence trail: the hydration pack seed, the content registry entry for this content_id, and the claim registry entries linked via claim_ids.

How to use this page

  • Evaluating Forge? Read the core thesis and ecosystem hooks, then continue with the standout index.
  • Designing against the platform? Verify boundaries in the platform reference architecture before implementation.
  • Automating? Use the frontmatter agent_contract and cite content_id in generated output.

Agent contract

Allowed actions
  • summarize this page for evaluation questions
  • cross-reference claims via claim_ids and source_refs
Safe to infer
  • the architectural boundary described here is the intended design
Do not infer
  • production readiness beyond the stated maturity level
  • specific vendor, customer, or benchmark commitments
Key artifacts
  • forge-platform/docs-governance/content_registry.yaml

Machine-readable guidance from this page's frontmatter: what automated consumers may do, infer, and must not infer.