bullpen-up exists to enable and start its roster, so a unit an operator switched off by
hand came back on the next bring-up — with nothing in the output to say it had. That is
not a bug in bullpen-up; it is doing exactly its job. It does mean an operator's "off"
silently expires, which is the failure class markus has flagged before: re-arming an
inhibit is a decision, not housekeeping.
bullpen-selfimprove.timer was live proof — disabled on request 2026-08-01 while #100 and
#118 ran through the room, and `bullpen-up --dry-run` reported `WOULD … enable+start`.
Mechanism: a file named exactly like the unit in /etc/bullpen/inhibit/ or
~/.config/bullpen/inhibit/, whose CONTENT is the reason. Both paths are read so the same
mechanism works in either install layout, and cfg.inhibit_reason() reads at call time —
lifting an inhibit must not require restarting anything. The reason is mandatory by
construction: an empty file still reports "(no reason recorded)", because an inhibit
nobody can explain is archaeology six weeks later.
Deliberately NOT a tear-down: bullpen-up never stops or disables, so an inhibit that
arrives while the unit runs blocks the re-arm, not the current run. Reporting only
"INHIBIT" there would read as "it is off", so that case says ACTIVE explicitly and tells
the operator to stop it by hand if that is what they meant.
tests/test_bullpen_up_inhibit.py pins all four properties plus non-interference with
ordinary bring-up; with the inhibit check removed, exactly those four fail and the
bring-up test stays green.
marfrit
b03d89770f