led-polarity

Remedy ¶

Swap the LED’s anode and cathode connections so the anode faces the supply side and the cathode the return path through its series resistor.

What it means ¶

An LED’s anode pin is on a ground-named net and its cathode is on a power-rail-named net. Current would have to flow from ground to the rail; the LED never conducts.

Why engineers want it ¶

LED polarity is the classic capture slip, because the symbol is symmetric-looking, the footprint is not, and the netlist connects fine either way. Review checklists carry “check LED orientation” because no electrical check catches it, since both pins are properly wired, just to the wrong ends.

Impact ¶

A dead indicator discovered at bring-up; rework if the footprint is not hand-flippable.

Pin roles are derived, not stated ¶

No format carries polarity as data (KiCad LED pins are electrically passive; “A”/“K” are pin names), so the anode/cathode roles come from the name convention, gated by device class, through pin.role. component.class takes the same projection posture. If an LED’s pins carry no recognizable names, they yield RoleUnknown. The rule then raises no finding, because it never guesses, though the LED still records a pass.

LED-only, on purpose ¶

A zener or TVS wired cathode-to-rail is correct usage; the general diode-orientation rule needs net-polarity facts and is tracked with the WS3-003 corpus row, not here.

Query structure ¶

select LEDs whose role-resolved pins sit on opposing rails.

select C in components where class(C) == led
  and ground_name(net_of(anode(C))) and rail_name(net_of(cathode(C)))

Reads: component.class, net.names, on_net, pin.role. Tier R.