The Engineering Loop

A plan is built one phase at a time on the developer’s machine, and nothing leaves it until every phase is green. The Engineering Loop has two cadences: a cycle for each phase, and a cycle for the plan.

A test that never fails looks like one that works

So every phase starts with a test watched failing for the reason you expect, and every guard is proven by planting the defect it exists to catch, watching it fail, and taking the plant out.

Per phase, on the machine

The phase cycle never leaves the developer’s machine. It writes to onMain only to record the phase’s review and its status.

  1. TestWrite the failing test first, and watch it fail for the reason you expect.
  2. ImplementWrite the least code that makes it pass.
  3. VerifyRun the project’s own gate, and look at what changed on the screens and widths people use.
  4. ReviewCheck the batch against the project’s checklist; a phase that touches what the team marks risky gets a review in fresh context.record_review
  5. DocumentUpdate the documents the project names, wherever behaviour changed.
  6. Close the phaseGate green, tree clean, the phase’s status written to the plan. Then the next phase, on the same branch.

Per plan, the only part that touches origin

Once per plan, the loop proves the starting point, ships the work as one pull request, and hands it to whatever lands it.

  1. PlanRead the claimed card’s plan and set up a fresh working copy. A plan still in draft is never built.
  2. BaselineRun the whole gate before changing anything, and write down what passed.
  3. Pull requestOne push and one pull request, once every phase is green.
  4. Hand offRecord the pull request, file what the plan raised and did not take as cards, and prove nothing exists only on this machine. Then the session may close: it does not wait for the landing.record_pull_request
  5. Landing sweepWhatever lands, the next session to start records it first: the landing, the deploy, the plan complete, the card done.record_landing · record_deploy
  6. ShipThe team’s own step, by the team’s own definition of shipping. It is not on the plan’s list of done.

What the loop guarantees

Every phase ends green. A plan reaches main as one pull request, its phase commits preserved — a merge, never a squash. A session that hands off leaves nothing only on its machine. And a plan left built but unrecorded is recorded by whichever session starts next, so the board does not drift from main.

Questions

Does every step call the MCP?

No, and that is deliberate. The phase cycle runs on the machine; onMain is written when there is something to record — a review, a phase’s status, a pull request, a landing.

Who merges?

Whatever the project’s own landing says: a merge train, or a person merging once the checks are green on the head. From the hand-off on, the landing belongs to whatever lands it.

What does a team change?

The gate command, the environment, naming, what each kind of change must produce, when a review needs fresh eyes, and what landing and shipping mean — the Standard’s extension points, filled per product.