Review a change

On equipment that runs physical machinery, it’s good practice for a second person to check a change before it reaches the line. Spyke makes that review concrete: the reviewer sees exactly what changed, not a vague description.

This guide shows the everyday review loop for one change.

Before you begin

You should already be able to save a version. This guide assumes you and a teammate are working from the same project history.

Step 1: Save the change as a version

The engineer making the change saves it as a new version, with a message that explains the intent:

spyke save -m "Add jam-detection timer to infeed conveyor"

Step 2: Show exactly what changed

The reviewer compares the new version against the one before it:

spyke compare

Spyke shows the change in program terms — the specific rung, tag, or setpoint that moved — so the reviewer can judge the actual edit rather than re-reading the whole program. See Semantic diffs for how this works.

Step 3: Talk it through

With the comparison on screen, the two of you can confirm:

The change does what the message says — and nothing else.
Nothing unexpected moved. An accidental edit to another rung or tag shows up here.
The change is safe to run on the equipment.

Step 4: Keep the record

The saved version, its message, and who saved it stay in your history. That history is your record of what was changed and reviewed — useful long after the change is on the floor, when someone asks why is it like this?