For each criterion, tick or circle one level only: Excellent, Proficient, Basic, or Poor. There is no separate score column.
| Criteria | Excellent | Proficient | Basic | Poor |
|---|---|---|---|---|
| Diagnosis plan & intended behaviour | Clear intended behaviour plus ordered checks (compile, then runtime). | Intended behaviour stated with a sensible repair approach. | Short plan; limited structure to the diagnosis. | No plan; random edits without stating what the sketch should do. |
| Fault inventory completeness | Inventory covers capitalisation, pinMode, == vs =, braces and semicolons. | Most required defect classes listed before or during repair. | Some faults listed; classes missing. | No inventory, or only the fixed file submitted. |
| Capitalisation & identifiers | Fixed and explained why Arduino C++ identifiers are case-sensitive. | Fixed with a clear short explanation. | Fixed in code; explanation shallow. | Case errors remain or unexplained. |
| Pin modes vs wiring intent | Correct modes with clear explanation matching the verification circuit. | Correct pinMode linked to button/LED intent. | pinMode corrected; weak link to INPUT_PULLUP/active-low. | Wrong pinMode left in place, or mismatch with wiring. |
| Comparison == versus assignment = | Fixed with a clear == vs = example in the learner's own words. | Fixed with an adequate explanation. | Fixed; explanation incomplete. | = still used in conditions, or not understood. |
| Braces & block structure | Correct braces; learner can point to each repaired block. | Brace faults fixed and briefly explained. | Compiles after brace fixes; explanation thin. | Brace errors remain; sketch structure broken. |
| Semicolons & statement punctuation | Fixed; learner explains where semicolons are required vs not after if (). | Semicolon faults fixed with a short explanation. | Fixed; limited explanation. | Missing semicolons remain or were guessed without understanding. |
| Compile success & corrected sketch quality | Clean corrected sketch that clearly shows each repair. | Compiles cleanly with readable repairs. | Compiles; residual clutter. | Still fails to compile, or is a messy rewrite hiding the lesson faults. |
| Runtime I/O verification | Reliable demo; pinMode, read and write linked to wiring. | Correct button-to-LED behaviour demonstrated. | Works in demo; explanation of active-low read is weak. | Cannot show corrected button-to-LED behaviour. |
| Verification circuit layout | Neat INPUT_PULLUP button to GND and LED with series resistor. | Safe, tidy verification circuit. | Simple working button/LED circuit; ordinary layout. | Unsafe or nonexistent demo wiring. |
| Circuit diagram for verification build | Clear mini-schematic with pins labelled. | Matching diagram with adequate labels. | Basic diagram; labels incomplete. | No diagram, or contradicts the sketch. |
| BOM & component safety (verification) | Short BOM with resistor value and button wiring safety noted. | Parts and safety noted clearly for the test circuit. | Simple parts list; basic safety present. | No parts note; LED without resistor. |
| Resolved challenges / debug journal | Journal of compiler messages and logical faults with fixes. | Clear record of key faults and how they were resolved. | Mentions a few errors with little method. | No journal of what failed in the compiler or runtime. |
| Unresolved challenges & oral/written explanation | Honest remaining questions plus full explanation of all required defect classes. | Good explanation of the defect classes; some open questions named. | Explanation covers only part of the list. | No reflection; cannot explain defect classes without reading code aloud. |
If the fixed reference is used with no inventory, Fault inventory completeness is Poor. Excellent explanation rows require the learner to teach the defect class, not only show a working upload.
| Assessor signature | Learner signature | |||
| Result | Pass / Resubmit / Distinction (circle) Resubmit by: __________ | |||