Final configuration

docs/ENVIRONMENT.md

@@ -4,9 +4,9 @@ Specification for a Mechanical Compiler instance.
 
 | | |
 |---|---|
-| Revision | 5.1 (2026-08-17) |
+| Revision | 5.2 (2026-08-17) |
 | Supersedes | Revisions 1 through 4 |
-| Basis | Revision 4, reconciled against the proven staging build, then work order 002 |
+| Basis | Revision 4, reconciled against the proven staging build, then work orders 002 and 003 |
 | Scope | **Host-agnostic.** Applies to any instance. |
 | Instance state | `STAGING-STATE.md`, and later `PRODUCTION-STATE.md` |
 | Failure evidence | `FAILURES.md` |
@@ -174,10 +174,18 @@ nat POSTROUTING
   -s <SVC_NET>            -o <MGMT>  -j MASQUERADE
 
 filter FORWARD
+  -s <SVC_NET> -d <WG_NET> -p tcp
+     -m multiport --dports 25,465,587 -j DROP     # containers do not send mail
   -s <SVC_NET> -d <SVC_NET>          -j ACCEPT
   -s <SVC_NET> -d <LAN_NET>          -j DROP
 ```
 
+**PROVEN (F-025)** — The SMTP rule is not optional where the host masquerades
+containers onto a network carrying a mail relay. Without it the containers
+inherit whatever relay authority the host's source address holds. The host's own
+alerting is unaffected: it originates mail locally, so it takes OUTPUT and never
+enters FORWARD. Prove that rather than assuming it.
+
 **REQ** — Rule order is load-bearing. `RETURN` must precede both masquerades.
 Rules must be persisted, and the persisted set verified to match the live set.
 
@@ -254,6 +262,12 @@ large data volume in a container snapshot is how a backup store fills.
 **REQ** — Do not over-commit a thin pool. Thin-pool exhaustion is an ugly
 failure mode.
 
+**PROVEN (F-026)** — Every container that must survive a host restart carries
+`onboot: 1`. This is not the default. It is also invisible to `pct reboot`,
+which restarts a guest without exercising host-boot autostart at all — so a
+container proven to survive `pct reboot` is **not** thereby proven to survive a
+host reboot.
+
 ### 4.3 Base OS
 
 **REQ** — Debian 12 bookworm, both containers. It matches YunoHost 12 stable and
@@ -638,12 +652,34 @@ coinciding with it.
 Automation that greps a logfile path finds nothing silently, which is worse than
 failing.
 
-**REQ** — Disk monitoring must be configured **explicitly per device** where the
-controller does not present members to automatic scanning. An active
+**PROVEN** — Disk monitoring must be configured **explicitly per device** where
+the controller does not present members to automatic scanning. An active
 `smartmontools.service` monitoring zero devices is not monitoring, and is easy
-to mistake for success. Acceptance is a delivered test alert, not an active
+to mistake for success. Acceptance is a **delivered** test alert, not an active
 unit.
 
+Behind an HP Smart Array controller the working pattern is:
+
+```
+DEFAULT -a -m root -M exec /usr/share/smartmontools/smartd-runner
+/dev/sda -d cciss,0
+/dev/sda -d cciss,1
+/dev/sda -d cciss,2
+/dev/sda -d cciss,3
+```
+
+`-M test` proves the alert path — one message per monitored device — and must be
+**reverted afterwards**. Left in place it produces an alert storm on every
+restart, which trains everyone to ignore disk alerts. That is worse than no
+monitoring.
+
+**REQ (F-028)** — Query `smartmontools.service`, not `smartd.service`. The
+latter is an alias and owns no journal; `journalctl -u smartd` returns nothing
+on a host where monitoring is working perfectly.
+
+**REQ** — Record each member's **serial number** at configuration time. That is
+the only thing that maps a future alert to a physical drive in a caddy.
+
 ### 12.1 Downstream infrastructure is out of bounds
 
 **REQ** — An instance may configure its own relay client. It may not alter the
@@ -705,6 +741,30 @@ committed; an example with empty values is.
 11. AGPL-3.0 §13 requires network users be offered the source. The web tier
     carries a visible source link to the repository. A licence obligation.
 
+### 14.1 Test validity
+
+**REQ (F-027)** — A test must be able to distinguish failure of the **tool**
+from failure of the **thing under test**.
+
+```bash
+# WRONG — any failure of the wrapper reads as a pass
+run_in_guest "$c" 'connect to X' && echo "reachable — WRONG" || echo "blocked — correct"
+
+# RIGHT — establish that the test could have observed the positive case
+if [ "$(guest_state "$c")" != "running" ]; then
+    echo "CT $c NOT RUNNING — TEST INVALID"
+elif run_in_guest "$c" 'connect to X'; then
+    echo "reachable — WRONG"
+else
+    echo "blocked — correct"
+fi
+```
+
+This applies to **every negative assertion** — "X is unreachable", "Y is
+absent", "Z is refused". A test whose failure mode is indistinguishable from
+success is worse than no test, because it manufactures confidence. In WO-003 the
+wrong form reported a pass against containers that were not running.
+
 ---
 
 ## 15. Acceptance gates
@@ -728,6 +788,12 @@ scaffolding survives a reboot.
 **PROVEN (F-021)** — the reboot is not optional. Connectivity can be perfect
 while boot is degraded.
 
+**PROVEN (F-026)** — it must be a **host** reboot, and every guest must return
+automatically and report `running`. A guest reboot does not exercise autostart.
+
+**PROVEN (F-027)** — every negative assertion in this gate must satisfy §14.1
+before its result means anything.
+
 ### Gate 2 — Operational services
 
 Mail delivered **end to end and received twice**, with full headers captured, an