The 10-Minute Stakeholder Briefing

A skimmable, self-contained, eight-section white paper sized for the longest read a busy manager or VP gives you in one sitting. Designed to be shared as one link, read end-to-end without leaving the page, and remixed into a per-organization briefing using the three-path ladder in Section 8.

1. Executive Summary

AI coding tools get a feature from prompt to running code in minutes: and then leave the rest of the SDLC to humans. Plan Forge is the orchestration harness that closes that gap. It sits on top of GitHub Copilot (and any other AI coding tool that speaks the Model Context Protocol) and adds the four layers production software actually needs: planning, validation gates, memory, and reviewer separation. The receipt on the project's own seven-slice memory-QA plan is $0.07 on a single mid-tier model in roughly 51 minutes, zero failed slices, zero escalation. The system QA'd itself with the very upgrades it was QA'ing, for the price of a coffee.

• The problem. Vibe coding clears the 80% demo bar fast and stalls at the 20% that ships, tests, interfaces, DTOs, typed exceptions, cancellation, audit. The .NET A/B test measured the gap at 99 vs 44 on structural quality, same model, same time budget.
• The fix. Four named loops, Smelt (intake), Forge (execute), Guard (post-deploy defence), Learn (memory), each with its own concrete artifacts, gates, and hand-offs. The pipeline reads like a workshop, not a black box.
• The receipt. The Phase-MEMORY-QA plan (7 slices, full E2E, mock OpenBrain, lattice callers, hallmark show/verify, backward-compat checks) ran for $0.07 total in ~51 minutes, 100% on Sonnet-4.6, no escalation, zero failed slices. See the payoff section of the Memory chapter for the full breakdown.

Read more → Foreword — From Impossible to Seven Minutes (10 min, the year-long story behind the receipt).

2. What Plan Forge is — and is not

Plan Forge is the orchestration harness that sits on top of GitHub Copilot (and other AI coding tools). It does not replace your model or your IDE, it adds the SDLC layer GitHub deliberately leaves to the ecosystem: planning, validation gates, memory, cost control, and reviewer separation. It is also licensed MIT because your SDLC is yours, and your institutional memory lives in OpenBrain, a user-owned service, because your accumulated decisions should not be trapped inside any one AI vendor.

The two-axis claim, harness on substrate and your-SDLC-is-yours, matters in equal measure. The first one explains why Plan Forge does not compete with GitHub Copilot, Claude Code, Cursor, Codex, Gemini CLI, or Windsurf; it routes work through them. The second explains why nothing in the harness is rented, gated, or trapped behind a control plane the user does not own. The condensed positioning table:

Read more → Chapter 1 — What Is Plan Forge? (full IS / IS NOT table plus the four-station overview).

3. The four cost levers

Plan Forge is cheap to run because four mechanical levers compound, not because the model rate is low. Each lever is independently measurable and independently dial-able. A team that turns all four on can run a hardened plan end-to-end for cents; a team that turns them off pays whatever the model bills. The levers, in order of typical impact:

Read more → Advanced Execution — Cost Optimization (the canonical lever table, the full math, the quorum-mode A/B run) and Dashboard — Cost Tab (the cost-ledger walk-through).

4. The compounding flywheel

A vibe-coding pipeline runs the same plan tomorrow at the same cost it ran today. A Plan-Forge pipeline runs tomorrow's plan a bit colder, the gates that were tight yesterday are still tight, the patterns that worked are recalled, the patterns that failed are flagged in the lattice before the model touches the file. After ninety days, the same plan that cost a dollar on day one costs a fraction of that on day ninety, with fewer escalations, fewer failed slices, and fewer reviewer-found defects. That curve is what compounds.

Three concrete mechanisms make the curve real, not aspirational:

• OpenBrain recall. Every plan's outcomes, passing gates, failing gates, fix proposals, post-mortem notes, are written to a user-owned memory service. The next plan starts with that recall pre-pulled into its context. See the Memory chapter for the full architecture.
• Lattice callers. The repo is indexed semantically and structurally. Before the model edits a function, the orchestrator pulls the call sites the model would otherwise have to discover by guessing. Token spend on speculative reads drops materially.
• Pattern registry. Recurring fixes, "always inject the cancellation token", "the typed-exception base class lives here", are promoted from one-off comments into named patterns that the harden-plan step references by name. The same fix is not re-derived every plan.

Read more → Memory System chapter (architecture, the Phase-MEMORY-QA receipt, and the four pieces, Hallmark, Anvil, Lattice, sync_memories, that make the recall layer concrete).

5. What we add that you might not have asked for

The brief above covers the things teams come to Plan Forge for. A handful of capabilities ship in the same box without being part of the headline pitch, they exist because they kept being the missing piece in production AI-SDLC adoptions and adding them once was cheaper than re-explaining their absence to every new team. None of them is hidden, gated, or paywalled; they ship in the same MIT-licensed harness as everything else.

• A virtual engineering team, not a code generator. Every traditional role on a 20-person engineering team has an equivalent in the shop: you are the Product Owner; 20 specialised reviewer agents cover architecture, security, performance, DB, deploy, API, accessibility, multi-tenancy, CI/CD, observability, dependency, and compliance; Forge-Master Observer + Auditor plays engineering manager; the Tempering harness + testbed + regression guard play QA; LiveGuard plays SRE; the audit loop + bug registry play continuous-improvement / retros; the independent Session-3 fresh-session reviewer plays architecture-review board; OpenBrain plays the institutional-knowledge wiki. The whole discipline of software engineering, governed by 40 years of practice encoded into 17+ auto-loading instruction files, lands as agents and guardrails, not as a hammer. Read more: Chapter 1 — The Virtual Engineering Team.
• Three closed loops, not one. Agents supervising agents. The Forge builds. Forge-Master supervises, live and post-run, against the same plan the Forge executed. The Learn station feeds every finding (bugs, gate failures, drift, postmortems) back into the next plan. The audit loop ran for two weeks unattended on a real production Next.js site and surfaced 30+ defects the maintainer did not know existed. For a CTO who has been burned by AI demos that grade their own homework, this is the part to verify: autonomous execution, autonomous supervision, autonomous learning — three loops, not one.
• The human's role is exactly three things. (1) Make a few technology choices once: pick a preset, declare Project Principles, set forbidden patterns. (2) Own spec and direction as Product Owner: Crucible interviews you; you decide what to build and why; the shop will not deviate from the Scope Contract you signed. (3) Run manual acceptance testing: a green pipeline (all tests pass, no drift, no secrets, no regressions, Forge-Master independently audited) proves the code is correct against the spec; only you can decide whether it is what you actually wanted. That is Product Owner UAT, same as it has been for 40 years. Agents do not read minds; only the Product Owner makes the final call on what is done correctly.
• An open-source memory layer (OpenBrain). A user-owned memory service. Your decisions stay in your tenancy, on your hardware, behind your audit boundary, not in a vendor's control plane.
• Reviewer separation. The model that writes the code and the model that reviews the code are different sessions, different model selections (often different model families), and run against the same hardened plan but with different prompts. The reviewer cannot be flattered into approval by the author's framing.
• Validation gates baked into the plan, not the CI script. The plan owns its gates. The CI script verifies that the gates ran and passed; it does not get to redefine them. Plans cannot drift away from the verification they ship with.
• Plan provenance. Every plan carries a Scope Contract, a Forbidden Actions list, and an immutable record of which slices ran on which model, at what cost, with what outcome. Six months later, the reason any line of code landed is still answerable.
• Fleet operations. Multiple plans, multiple repos, multiple agents, the same dashboard, the same cost ledger, the same memory recall surface. Single-repo and multi-repo orgs do not pay different conceptual taxes.
• Audit trail. GitHub Issues, PRs, Actions runs, and the plan's commit history are the audit trail. Nothing is logged to a separate system the auditor has to chase.

Read more → Chapter 1 — The Virtual Engineering Team (role map + your three jobs), Forge-Master chapter (agents supervising agents), and Appendix J — Plan Forge for Enterprise (multi-tenancy, data residency, compliance posture).

6. Adoption path — two routes

There are two ways to adopt Plan Forge, and they are both first-class. Neither one is a downgrade of the other; the right route depends on whether your organization needs the harness to look like your shop or the community's shop. Both routes terminate at the same place: a hardened, gated, memory-backed pipeline running against your repo with audit trail on every artifact.

• Route A: adopt as-is. Clone the repo, run setup.ps1 (or setup.sh) against the preset that matches your stack, and start running pforge run-plan against your plans within the hour. Stay on the community upgrade cadence; PRs flow upstream when something is generally useful, locally when something is yours alone. Best for teams that want to skip the build phase and adopt a working pipeline today.
• Route B: fork and brand. Fork the repo into your org. Rebrand the presets, the agent set, the skill list, and the plan templates to match how your organization already talks about software. Rebase from upstream on a cadence that suits your release rhythm. Best for organisations whose SDLC vocabulary, agent naming, or compliance constraints make the as-is shop a poor fit out of the box.

Read more → Installation chapter (route A, step-by-step) and Customization chapter (route B, the customization spine).

7. Why open source matters here

An SDLC harness is the wrong layer to rent. Renting the model is fine, the model is interchangeable, replaceable, and improves on a vendor's roadmap that is not your problem to manage. Renting the orchestration on top of the model is a category mistake. The orchestration is where your decisions live, where your audit trail accumulates, where your compliance posture is encoded, and where your institutional memory is stored. The closer that layer sits to your business, the worse the lock-in if you do not own it.

Four things change when the harness is open source and the memory layer is user-owned:

• IP stays yours. The plans, the patterns, the memory entries, the agent definitions, the skill library, all of it is in your repo or your tenancy. No vendor takedown can strand any of it.
• Audit is in-place. The artifacts an auditor wants, the plan, the gates, the run log, the cost ledger, the reviewer's verdict, are GitHub objects under your existing access controls. There is no second system to grant the auditor a seat in.
• Customisation is unbounded. Anything in the harness can be forked, replaced, or augmented. The presets, the agents, the skills, the hooks, the notifier extensions, the orchestrator itself. The customization story is the customization story for the whole stack.
• No vendor lock-in on the orchestration layer. The model you use can change tomorrow; the harness does not. The cost lever can change tomorrow; the lever owner is you. The memory schema can change tomorrow; the migration tool ships in the harness.

Read more → Memory System chapter (the user-owned memory layer) and Customization chapter (the customization spine).

8. Make this yours — the tailoring flow

The eight sections above are the ~50% of any per-organization briefing that is canonical. The other ~50% (the parts that name your squads, your KPIs, your pilot timeline, your ask) cannot and should not be pre-written. They are the parts the internal champion has to author or commission. The tailoring flow is the path from this generic briefing to that per-organization briefing, without anyone needing to open an issue and wait for a maintainer to respond. Three paths, in increasing order of Plan Forge involvement:

The closing thought is deliberately recursive: the briefing about Plan Forge ends by inviting the reader to use Plan Forge to remix the briefing. That is the demo. A tool whose closing CTA is "open an issue and wait" is selling something other than what its first seven sections claimed. A tool whose closing CTA is "here is the template, here is the skill, here is the community, pick the one that matches your effort budget" has the same shape inside and outside.

A closing line, borrowed

A blacksmith doesn't hand raw iron to a customer. They smelt it, hammer it, temper it, and then they watch, because a blade that isn't maintained will dull.

The briefing above is the case made in ten minutes. The book is the case made in detail, station by station, decision by decision, with the receipts. The Foreword opens the door; the Reader-Journey Ladders pick the path; the chapters do the work. Start anywhere, the harness is yours either way.