Bridge Checkpoint: WPILib Adds a Framework Contract

A WPILib subsystem is still Java code, but it exists inside a robotics framework with scheduler and command semantics.

The bridge question is not how to learn inheritance or classes again. It is what additional claims become possible when ordinary Java code participates in WPILib.

Inspect one subsystem example and identify:

• its declared responsibility;
• scheduler or command relationships;
• framework lifecycle expectations;
• simulation/test evidence available on the Java side;
• what remains outside WPILib evidence.

A subsystem can be well tested and still tell you nothing about ROS graph state.

Likewise, a WPILib method named publishRange() does not become a ROS publisher because of its name.

Compare the evidence

Write one claim that plain Java evidence can prove, one stronger claim WPILib framework evidence can prove, and one ROS claim that remains unproved.

The useful architecture boundary is:

Java object
→ WPILib framework participation
!= ROS graph participation

If WPILib is unfamiliar, use the current WPILib documentation for the specific framework behavior. Do not substitute generic Java knowledge for framework evidence.