Core concepts
Tasks and verification
Define the outcome, keep the work bounded and know what each result proves.
Define the outcome first
Say what to change, where, and how you will know it worked. Add any limits, such as not resetting the board.
Ask Flash
Investigate the intermittent sensor timeout. Keep the board running; do not reset or program it. Capture up to 20 seconds of serial output and propose the next check.Work in stages
For complex work, ask for an investigation and a plan before any change, and use each result to choose the next step.
Know what each result proves
| Result | Proves |
|---|---|
| Reviewed | The proposed change was inspected. |
| Built | That revision compiles with the selected toolchain. |
| Programmed | That build was written to the intended board. |
| Observed | A log, debugger state or measurement was captured from the device. |
| Verified | The observation met the success criterion. |
Results come from real operations
Build and programming results come from the operation itself, not from the model’s account of it. Flash only programs a build made from the current sources, and reads the board back before skipping an identical write.
Stop with a useful result
If a tool, permission or device is missing, a clear blocker and next step is a good outcome. After repeated failures, review the evidence before trying again.