Every FTC team rewrites its codebase roughly every two years, and it is almost never because the old code stopped working. It is because the person who understood it graduated. The wiring lived in their head, the reason for a strange offset lived in their head, and the code that remains is correct but unreadable.
So the interesting design constraint was not performance. It was legibility to someone who was not in the room when the decisions were made.
A codebase that only its author can maintain has a shelf life, not an architecture.
Commands, subsystems, hardware abstraction and opmodes are kept strictly apart. A subsystem never knows which opmode is running it; hardware abstraction is the only layer that names a physical port. Swapping a motor becomes an edit in one file rather than a search across the repository.
On top of that sit the parts that are usually missing: architecture decision records explaining why each structural choice was made, a wiring map that matches the code, a six-phase bring-up checklist for a new robot, and GitHub Actions validating the build on every push. SolversLib handles control, Pedro Pathing autonomous navigation, Panels telemetry, goBILDA Pinpoint localisation and Limelight3A vision.
The six-phase checklist a new robot goes through. Each phase is gated: you cannot advance while a check in the current phase is still failing.
The behaviour-tree engine that decides what this stack should be doing.
An AI plugin suite that reads a config like this one before writing a line.
The team, the competition record, and the robot this stack runs on.