recipes
0/6 steps
Tutorial V7 · 10 minutes

A ticket end to end

How the pieces combine on ordinary work: one ticket, implemented, proven, and opened as a pull request a reviewer can check without rebuilding it themselves.

prerequisites: V3 and V4
V7

Video recording in progress

The through-line: you steered at every gate, the system did the labour, and the pull request carries proof instead of claims.

The walkthrough

  1. Start from a working checkout

    Current harness, library declared, app reachable.

    $ mm-harness update
$ mm-harness doctor
$ mm-harness run --list

    If your team's recipes are not in that list, fix it now rather than mid-task — V3 covers it.

  2. Read the ticket for what is observable

    Separate the criteria that describe behaviour someone could watch happen from the ones that describe intent. The first kind is what a recipe can prove. Naming that split up front decides the shape of everything after it.

  3. Implement, using the harness to look

    call is the fast loop while developing — one action against the running app, no recipe needed. This is the same execution path a recipe uses, so what works here works there. 

    $ mm-harness call read_state
$ mm-harness call navigate page=perps
$ mm-harness logs

  4. Cook the proof for the criteria

    V4's flow, pointed at this ticket. Author against the discovered actions, validate with --plan, run it. 

    $ mm-harness run ./proof.json --plan
$ mm-harness run ./proof.json --artifacts-dir ./proof-artifacts

    Then revert your change and run it again. Green after a revert means the recipe is not testing your work.

  5. Open the pull request with the evidence

    Check your diff before you push, then link the criteria to the nodes that prove them. A reviewer should not have to guess which part of the bundle answers which criterion. 

    $ mm-harness check diff --profile fast

    The recipe is the durable half. It stays in the library and fails later if someone breaks the behaviour — the difference between evidence and a regression test is only whether you keep it.

  6. Look at it as the reviewer

    Open your own bundle the way V2 does: read the intents in order and ask whether they add up to the claim in the description. Anything you cannot answer from the trace is something you are asking a colleague to take on trust. 

    $ cat proof-artifacts/report.md

    If the agent's checklist asked for learnings, they are written beside the evidence — worth reading before you close the ticket, and the raw material for what eventually reaches the team's shared knowledge.

Back to the series The reviewer's guide Cheatsheet