Parse any validator message into refdes, subject, and remedy.
Fix a multiply-broken spec in dependency order.
Predict which fixes reveal new errors, and why.
Distinguish a validation failure from a generator failure by its voice.
The validator's messages share one grammar: a refdes, a colon, what is wrong, and — after the dash — what right would look like. "RV1: potentiometer needs an analog pin — GP15 is not an ADC pin (GP26/GP27/GP28)". Read it as three answers: WHO (RV1), WHAT (wrong pin kind), and WHICH PINS WOULD DO. Nothing to decode; the skill is believing it.
When a spec is broken several ways, fix in DEPENDENCY ORDER — the order the validator itself checks each peripheral, because later checks reason about facts the earlier ones establish. First the shape messages (a missing peripherals array stops everything). Then unknown parts — a peripheral the library cannot resolve reports once and is skipped, so its pins are invisible to later checks. Then required fields and signals, and a pins map that hands two signals one GPIO: "DS1: sevenseg_cc pins must be distinct (got GP2, GP2, GP4, GP5, GP6, GP7, GP8)". Then pin legality. Last, pin conflicts. One pass per fix, regenerate, read again.
That skipping is why fixes CASCADE. You met it in the PS-1 capstone: move the light sensor off GP15 to satisfy the analog check, and the conflict check — which could finally see a legal assignment — reports the pin was already spoken for. A new error after a fix is not the validator being fickle; it is the next layer of the same truth becoming visible. The board is done when a generate returns silence.
One failure class lives PAST the validator. Omit an LED's pin entirely and no named message fires — the generator itself fails, loudly and less politely, with tscircuit's own errors about components that could not connect. PS-1 Lesson 2 named the three classes: V7-checked, generator-failed, and optional. When you see machine noise instead of a sentence, look for what the spec never said at all.
Three seeded faults — find all three before reading on:
First generate, three messages: "DS1: unknown part "sevenseg" — not in the parts library", "RV1: potentiometer needs an analog pin — GP8 is not an ADC pin (GP26/GP27/GP28)", "SW1: pushbutton requires wiring". No conflict appears, because the skipped DS1 claimed no pins.
Fix the part name (sevenseg is not sevenseg_cc) and regenerate. The analog message stays; what is NEW is the collision the validator can finally see: "RV1: GPIO GP8 already used by DS1 — no pin may serve two peripherals". The missing field is still reported: "SW1: pushbutton requires wiring".
Move RV1 to GP26 and regenerate: one message left, "SW1: pushbutton requires wiring".
Add wiring to SW1 and regenerate: silence. 11 components, 22 traces, 0 errors.
Unknown part, wrong pin kind, missing field — fixed in that order, three generates, then silence.
PRACTICE
Q1
Order these for fixing: a V5 conflict, "spec.name is required", an unknown part, a missing series_resistor.
Q2
Why does one misspelled part produce exactly one message instead of a message plus phantom pin conflicts?
Q3
Which spec omission produces generator noise instead of a validator sentence, and how do you recognise the situation?
Q4
A fix reveals a new error. Write the one-sentence explanation you would give a frustrated classmate.