ForgeSDLC
Navigate
Home
Discover ForgeSDLC (101)
Practice (201)
Master (301)
Blog

Forge Platform ecosystem

Forge SDLC (this site) describes how teams govern human + agent delivery. Forge Platform describes how the products connect — runs, agents, execution, and evidence — on infrastructure you control.

Operators maintain the full handbook at platform.forgesdlc.com (private Firebase hosting). This page is a public orientation only.

Core concepts

Term Plain meaning
ForgeRun One governed delivery run from intent toward evidence (frun_*), visible in Forge Lenses
Forge Agent A bounded agent session inside that run (recorded as AgentRun, arun_*) — Hermes, Factory, Fleet workers, Cursor CLI steps, etc. Forge is not an agent.
Forge Campaign A multi-repo automation effort (branches, Fleet jobs, integration) under one ForgeRun, driven by a campaign manifest — not a marketing campaign and not a charge/* Git branch
EvidencePacket Human-reviewable bundle linking intent, execution artifacts, and decision state
Fleet Token-protected job plane for containerized work on your hosts
LCDL Governed, schema-aware LLM tasks in Python — reasoning, not orchestration
Lenses Local-first control plane for workspace and run review

Typical flow

Intent → Blueprint context → governed reasoning (LCDL) → human approval
      → Fleet execution → Forge Agent workcells → evidence → Lenses → decision

A Forge Campaign adds a manifest (which repos, which branches, which Fleet worker) so an orchestrator workcell can submit remote jobs, watch progress, and land stacked pull requests — still under the same ForgeRun.

Product boundaries (short)

  • Lenses owns run state and human review — not Docker execution.
  • Fleet runs approved container jobs — not git policy or PR titles.
  • Blueprints owns methodology and branching policy — not live run JSON.
  • Campaign orchestrator (when enabled) owns git/PR steps on the operator machine or CI — not final merge approval.

See the platform handbook: Forge Agent, Forge Campaign, Product boundaries.