A process you can point at

Most teams keep their process in a wiki nobody reads and nothing enforces. The onMain Standard is written down once, published in versions, and read by the agent doing the work before it plans anything.

Three loops, and who does what

The Product Loop shapes a stream into a PRD a planner can build on, before any card is written. The Planning Loop turns a claimed card into a plan that has survived an attempt to destroy it. The Engineering Loop builds that plan one phase at a time and lands it on main. A further document says who does what, and what each role may write.

A published version never changes

Once a version is published it is frozen, and a revision to it is written once. So when a plan cites the process it followed, that citation still means the same thing a year later — which is the whole reason to have a version at all.

Your product pins one

A product names the version it follows. Moving the pin is a deliberate act by a person, not a background upgrade, so a change in process never arrives in the middle of somebody’s work.

Extension points are where your team differs

The Standard says every phase ends green; it does not say what your gate command is. Each extension point is filled per product, so the shared process fits your repository without being rewritten for it. Among them:

  • the gate: what must pass before a phase is done, and before a plan is;
  • how a fresh working copy is set up;
  • how plans, branches, worktrees and pull requests are named;
  • what each kind of change must produce;
  • when a phase needs a review in fresh context;
  • what landing means, and what shipping means.

Coming: a library a firm forks

A platform-owned library of Standard versions a firm can fork and make its own is planned, so a team can start from a process that already works rather than writing one. It does not exist yet.