Shadow mode: Housecarl beside the firewall in force, changing nothing

shadow.enabled in housecarl.yaml loads Housecarl's ruleset so that it
blocks, rejects and translates nothing: drops and rejects count and
accept (an accept only ends Housecarl's chain), policies accept and log
what they would drop, NAT only counts, MSS clamping and the flowtable
are left out, and raw rules that do more than accept, drop or reject are
left out with a warning. Comments mark what would happen ([would drop]).
Filter chains run after the other firewall's (+10) or before (-10); NAT
chains always first. Every change is checked by nftables in both forms.
No probation; takeovers and closing connections are refused. The boot
fallback filters nothing. internal/tablewatch puts the table back after
a flush ruleset. Mode in status, healthz, whoami, the web UI, the log
and the tracer; hc ruleset --enforcing. docs/shadow.md.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/operations.md

@@ -28,7 +28,8 @@ edits) applies each edit at once instead. With hc, see
 ## Changes on probation
 
 Changes made over the network roll back unless confirmed
-([design.md](design.md#not-locking-yourself-out)). The web UI and `hc`
+([design.md](design.md#not-locking-yourself-out)); in shadow mode, where
+a change can't cut anyone off, none do ([shadow.md](shadow.md)). The web UI and `hc`
 confirm their own changes once they reach Housecarl again over a new
 connection, so normally nothing waits:
 
@@ -79,6 +80,9 @@ sudo cat /var/lib/housecarl/ruleset.nft
 sudo nft -c -f /var/lib/housecarl/ruleset.nft     # check it
 ```
 
+In shadow mode both files are shadow mode's, and the fallback filters
+nothing ([shadow.md](shadow.md#what-works-differently)).
+
 Dynamic sets start empty after a reboot. The saved ruleset has no
 flowtable, since its devices may not exist yet: housecarld adds it when
 it starts, and whenever a flowtable device appears
@@ -177,6 +181,10 @@ hc log --search 198.51.100.7
 10:02:15  hc forward policy drop: wan  eth1  198.51.100.9:443 -> 192.168.1.20:51432  tcp
 ```
 
+In shadow mode ([shadow.md](shadow.md)) what the policies would drop is
+always logged, in all three chains, and drops are marked as what would
+have been done: the packets went on.
+
 The packets go to netlink log group 4171, where housecarld reads them;
 the last 2000 are kept in memory. They aren't written to the kernel log
 or the journal. A rule's log isn't rate-limited: on a busy rule, give it
@@ -281,13 +289,14 @@ it is asked):
 
 ```sh
 $ curl -s https://firewall.example.net:8070/healthz
-{"ok":true,"version":"0.1.0","firewall":"applied","probation":0,"warnings":[]}
+{"ok":true,"version":"0.1.0","firewall":"applied","mode":"enforcing","probation":0,"warnings":[]}
 ```
 
 | Field | |
 |---|---|
 | `ok` | `true` with HTTP 200 when the firewall is as it should be; `false` with HTTP **503** otherwise |
 | `firewall` | `applied` (Housecarl's ruleset is in force), `unconfigured` (nothing configured yet, so nothing to apply), `fallback` (the [boot fallback](#if-the-ruleset-fails-to-load-at-boot) is in force), `missing` (no Housecarl table: flushed, or never applied) |
+| `mode` | `enforcing`, or `shadow`: Housecarl's ruleset is loaded but blocks nothing, and another firewall decides ([shadow.md](shadow.md)). `ok` doesn't depend on it; to be told when a machine isn't enforcing, also expect `"mode":"enforcing"` |
 | `probation` | changes waiting to be confirmed, rolled back unless they are |
 | `warnings` | codes of problems with the machine, as `hc status` shows them (`nftables_service`) |