Apply post-M1 corrections to the planning package

planning/SECURITY-THREAT-MODEL.md

@@ -783,6 +783,26 @@ LAN access to the **storyteller browser UI/API** is different and remains a futu
 
 Do not accidentally inherit storyteller LAN exposure because a candidate project binds to all interfaces.
 
+### Two different TLS questions — do not conflate them
+
+Clarified after M1, which implemented one of these and not the other.
+
+**Inbound TLS — serving the storyteller over HTTPS.** Deferred, and still
+deferred. It only becomes a question if storyteller LAN access is ever added.
+This is what "local certificate support" refers to in the deferred list further
+down.
+
+**Outbound TLS — verifying the certificate of a trusted-LAN inference host.**
+**Implemented in M1 and required for v1.** A LAN Ollama is often served over
+HTTPS with a privately issued certificate, so the storyteller must verify
+against the machine's own CA store as well as any bundled list, with
+certificate and hostname checking fully enabled and no bypass option
+(ADR 002; `TECHNICAL-DESIGN.md` §5).
+
+The storyteller remaining loopback-bound is unaffected by either. Outbound
+verification is about who the storyteller is willing to *talk to*; inbound TLS
+would be about who may talk to *it*.
+
 ## 54. Tailscale / VPN Access
 
 Treat remote access to the storyteller UI/API like storyteller LAN access.
@@ -1167,7 +1187,9 @@ Potential later improvements:
 - signed release builds,
 - dependency SBOM,
 - LAN authentication,
-- local certificate support,
+- local certificate support **for serving the storyteller over HTTPS** — note
+  that *outbound* verification of a trusted-LAN inference host's certificate is
+  a separate matter, is required for v1, and was implemented in M1 (see §53),
 - optional AppArmor/container confinement.
 
 These are not required for initial v1 unless Phase 0B reveals a specific need.