The handoff to the build loop

Recipe → contract Shipped

A recipe describes what should exist. An acceptance contract is testable. The recipe build command is the translation between them.

This is the seam that makes the two halves of the system one system: cookbookteam writes what good looks like, and the translation turns that into atomic criteria the build loop can be gated against. cookbookteam project build does the same thing across a whole project's worth of recipes, aggregating them into one contract — it is a cookbookteam command despite the name, and nothing to do with projectteam.

The shared spine

  1. CookbookRecipes, principles and guidelines — what good looks like.
  2. Review lensesSpecialties cite that corpus when critiquing code.
  3. Build lanesThe same corpus, distilled into imperative build guidance.
  4. Contractsrecipe build turns a recipe into criteria a loop can be gated on.

One corpus, read three ways. That is why cookbookteam is upstream of both the reviewing and the building halves rather than sitting beside them.

The contract is still yours to approve

A generated contract is a starting point, not a pinned one. It goes through the same review as a hand-written contract, because a soft or non-atomic criterion is exactly what lets a build loop declare victory without earning it.