The operator has decided not to enable branch protection on armistace/blog while the editor
is LAN-only:
"leave it as a recommendation - I won't do that unless I take this out to the wider internet"
That is a reasonable call, so this records it as an ACCEPTED RISK rather than an open task.
Test behaviour changed to match. The suite still attempts a direct push to master with the
deploy key on EVERY run - the check is not removed, because that is what would catch the
setting being lost or never applied. But when protection is off it now reports
ACCEPTED-RISK master is NOT protected - the deploy key CAN push master directly
instead of FAIL, so the suite is green and CI-usable (it previously exited 1, meaning a
genuine regression would have been buried in expected noise).
The run flips back to "PASS master is protected" by itself the moment protection is enabled,
so the recommendation self-cancels with nobody having to remember it. Summary line now reads
RESULT: 44 passed, 0 failed, 1 accepted-risk
Docs record WHY the risk is acceptable (the compensating control is reachability, not
immutability - nothing off-LAN can reach the editor, and the only LAN user is the operator)
and the two triggers that turn it back into a real finding:
1. the editor becomes reachable off-LAN (NPM proxy, port-forward, VPN route)
2. anyone other than the operator gets access
Written down because an accepted risk is only acceptable if it is explicit and has a
revisit trigger - otherwise it just looks like an oversight later.
hermes
c57aff3c33