A capability is only real if the path to it is
The most expensive defect I keep meeting: a feature that is written, reviewed, tested — and never runs, because nothing that runs calls it. A note on reachability as a design constraint.
Loop closure was implemented. It had code, it had tests, it had a launch file. And it did nothing on the vehicle — because it was wired into a launch file that the documented bringup command does not include. The capability existed. The path to it did not.
This is the oldest and most expensive defect in the codebase, and it has a family: the lock ladder in no launch file, a hold time held at zero, a bank storing a position nothing ever passed, a device path read and then ignored. Every one looked finished. Correct code, passing tests, nothing on the vehicle.
A capability is only real if the path to it is.
The fix is a decision, not more code
The instinct is to add the missing switch — declare it in the second launch file too. That is how you get two places that must be kept in step, which is the same bug with a longer fuse. Instead the node configures itself from a single deck-editable file, the same pattern the course priors already use: module constants as defaults, an explicitly-set parameter still winning, and a test that fails if the capability ever reappears in a launch file again.
And it degrades loudly. A malformed config falls back to defaults and says so — because silently ignoring an operator’s edit means they stand on the deck watching for a change that never loaded. The point is not the loop closure. The point is that reachability is a property you design in at write time, because that is the only moment anyone knows whether a consumer exists.