Document abbreviate_rule's nat/rdr blind spot and ddclient's log gapHEADmaster

From a fresh-agent review of AGENTS.md against two hypothetical tasks:

- abbreviate_rule() in pf.sh has only ever been developed/tested
  against filter-rule (-sr) syntax, despite also running on -sn
  (nat/rdr) output. It degrades safely (unshortened passthrough) but
  a new nat/rdr rule shape isn't guaranteed to compress as tightly -
  noted both in the code comment and in AGENTS.md's compression
  writeup so this doesn't need rediscovering.

- ddclient logging isn't enabled on the box, so "is the last DNS
  update actually succeeding" can't be built by tailing a log that
  doesn't exist - it'd need the cache file or a public-IP comparison
  instead. Recorded in AGENTS.md's topology section since ddclient.sh
  currently only checks the process is running, not update success.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

2 files changed, 20 insertions, 1 deletions

diff --git a/AGENTS.md b/AGENTS.md
index d8e35b2..a3cbaeb 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -34,7 +34,13 @@ shaped the way they are:
 - Host services outside the jails: `wg0`, `caddy`, `ddclient` (dynamic DNS,
   since the box is on a residential/dynamic IP - this is also why
   `checks/wg-watcher.sh` exists, to catch the WAN-change-reaction daemon
-  dying silently).
+  dying silently). `checks/ddclient.sh` currently only checks the process
+  is running (`svc_status`), not that updates are actually succeeding -
+  **ddclient logging isn't enabled on this box**, so a "did the last
+  update actually succeed" check can't be built by tailing a log file
+  that doesn't exist. It'd need to read ddclient's cache file (records
+  the last IP it set) or compare against the box's actual public IP
+  instead - neither has been explored yet.
 
 ## Where code runs vs. where it's edited
 
@@ -141,6 +147,12 @@ approach for any future long-text row:
    ish bitmap font wrapping doesn't line up with raw string length in an
    obvious way.
 
+**Known gap**: `abbreviate_rule()`'s regexes were developed and tested
+against filter-rule (`-sr`) syntax only. It also runs on `-sn` (nat/rdr)
+output, but no nat/rdr rule shape has actually been exercised against it -
+a new nat rule may pass through unshortened rather than compressing as
+tightly as a filter rule. Check the rendered page after adding one.
+
 ## When cron + static HTML stops being enough
 
 This project started as a refactor of a single monolithic cron script
diff --git a/statuspage/checks/pf.sh b/statuspage/checks/pf.sh
index 651b638..d1f22d1 100755
--- a/statuspage/checks/pf.sh
+++ b/statuspage/checks/pf.sh
@@ -21,6 +21,13 @@ DIR=$(dirname "$0")
 # shipped. A rule shape this doesn't recognize just passes through
 # unshortened - still correct, just longer.
 #
+# Applied to both -sr (filter) and -sn (nat/rdr) output, but every regex
+# here was written and tested against filter-rule syntax only. NAT/rdr
+# shapes (e.g. `rdr on ... -> ...`) haven't been exercised against a real
+# ruleset - they'll degrade safely to unshortened text if a pattern
+# doesn't match, but don't assume a new nat/rdr rule will compress as
+# tightly as a filter rule without checking the rendered page.
+#
 # State-tracking mode is tagged with a single bracketed letter rather
 # than a symbol, since the four modes (no/keep/modulate/synproxy) have
 # meaningfully different security properties and a bracket+letter reads