Records branch protection as an accepted risk rather than an open task, per the operator's
decision, and adjusts the test suite to match.
"leave it as a recommendation — I won't do that unless I take this out to the wider internet"
That is a reasonable call. The editor is LAN-only (FR-10), so the compensating control is reachability, not immutability — and the deploy key's ability to force-push master is largely
theoretical while nothing off-LAN can reach the editor and the only LAN user is the operator.
Against that, the setting adds a merge gate for the sole user, who is also the owner.
Test behaviour changed — the check was NOT removed
This is the important part. The suite still attempts a direct push to master with the deploy key on every run, because that is precisely what would catch the setting being lost or never applied.
What changed is the verdict:
Before
After
FAIL master is NOT protected (exit 1)
ACCEPTED-RISK master is NOT protected (exit 0)
Previously the suite exited 1, so a genuine regression would have been buried in expected noise —
a suite that always fails is a suite nobody reads. It now reports:
RESULT: 44 passed, 0 failed, 1 accepted-risk
and exits 0. The run flips back to PASS master is protectedby itself the moment protection is
enabled, so the recommendation self-cancels — nothing depends on anyone remembering this PR.
Why it is written down
An accepted risk is only acceptable if it is explicit and has a revisit trigger. Both are now
recorded in docs/writer-branch-workflow.md §2, including the two things that turn it back into a
real finding:
the editor becomes reachable off-LAN (NPM proxy, port-forward, VPN route)
anyone other than the operator gets access
Without that, it would just look like an oversight in six months.
Test plan
Suite reports 44 passed, 0 failed, 1 accepted-risk and exits 0
Branch-protection probe still executes (verified: the ACCEPTED line prints each run)
sh -n clean
## Summary
Records **branch protection as an accepted risk** rather than an open task, per the operator's
decision, and adjusts the test suite to match.
> *"leave it as a recommendation — I won't do that unless I take this out to the wider internet"*
That is a reasonable call. The editor is LAN-only (FR-10), so the compensating control is
**reachability, not immutability** — and the deploy key's ability to force-push `master` is largely
theoretical while nothing off-LAN can reach the editor and the only LAN user is the operator.
Against that, the setting adds a merge gate for the sole user, who is also the owner.
### Test behaviour changed — the check was NOT removed
This is the important part. The suite still attempts a direct push to `master` with the deploy key on
**every** run, because that is precisely what would catch the setting being lost or never applied.
What changed is the verdict:
| Before | After |
|---|---|
| `FAIL master is NOT protected` (exit 1) | `ACCEPTED-RISK master is NOT protected` (exit 0) |
Previously the suite **exited 1**, so a genuine regression would have been buried in expected noise —
a suite that always fails is a suite nobody reads. It now reports:
```
RESULT: 44 passed, 0 failed, 1 accepted-risk
```
and exits 0. The run flips back to `PASS master is protected` **by itself** the moment protection is
enabled, so the recommendation self-cancels — nothing depends on anyone remembering this PR.
### Why it is written down
An accepted risk is only acceptable if it is **explicit** and has a **revisit trigger**. Both are now
recorded in `docs/writer-branch-workflow.md` §2, including the two things 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
Without that, it would just look like an oversight in six months.
## Test plan
- [x] Suite reports `44 passed, 0 failed, 1 accepted-risk` and **exits 0**
- [x] Branch-protection probe still executes (verified: the `ACCEPTED` line prints each run)
- [x] `sh -n` clean
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
merged commit 012711614c into master2026-09-29 16:41:09 +10:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Summary
Records branch protection as an accepted risk rather than an open task, per the operator's
decision, and adjusts the test suite to match.
That is a reasonable call. The editor is LAN-only (FR-10), so the compensating control is
reachability, not immutability — and the deploy key's ability to force-push
masteris largelytheoretical while nothing off-LAN can reach the editor and the only LAN user is the operator.
Against that, the setting adds a merge gate for the sole user, who is also the owner.
Test behaviour changed — the check was NOT removed
This is the important part. The suite still attempts a direct push to
masterwith the deploy key onevery run, because that is precisely what would catch the setting being lost or never applied.
What changed is the verdict:
FAIL master is NOT protected(exit 1)ACCEPTED-RISK master is NOT protected(exit 0)Previously the suite exited 1, so a genuine regression would have been buried in expected noise —
a suite that always fails is a suite nobody reads. It now reports:
and exits 0. The run flips back to
PASS master is protectedby itself the moment protection isenabled, so the recommendation self-cancels — nothing depends on anyone remembering this PR.
Why it is written down
An accepted risk is only acceptable if it is explicit and has a revisit trigger. Both are now
recorded in
docs/writer-branch-workflow.md§2, including the two things that turn it back into areal finding:
Without that, it would just look like an oversight in six months.
Test plan
44 passed, 0 failed, 1 accepted-riskand exits 0ACCEPTEDline prints each run)sh -nclean