doc update: TL;DR + removing separators

Author: Daniel-Nashed

README.md

@@ -3,6 +3,12 @@
 **Nash!Com Service Guard** — a universal service launcher and secret manager
 for secure, automated secret delivery to any workload.
 
+> **TL;DR —** A statically compiled binary that authenticates to Vault (or reads a
+> systemd credential), fetches secrets, and delivers them to any process —
+> TLS certificates to NGINX, `server.id` passwords to Domino — without keys
+> ever touching disk. Supports VM, container, and Kubernetes deployments using
+> each platform's native identity mechanism.
+
 `srvguard` solves a fundamental bootstrap problem: a service needs its
 secrets (TLS certificate, private key, password) before it can start, but
 those secrets live in a protected store that requires authentication to access.
@@ -163,7 +169,6 @@ Environment=SRVGUARD_AUTH_METHOD=systemd
 See [systemd Credentials](docs/systemd-credentials.md) for background
 on how systemd credentials work and security properties.
 
----
 
 ## Output Backends
 

docs/architecture.md

@@ -1,5 +1,13 @@
 # Secret Distribution Across Platforms — VM, Container, and Kubernetes
 
+> **TL;DR —** srvguard adapts to the identity mechanism the platform provides.
+> On VMs it reads a systemd credential. In containers it reads credential files
+> the host placed on a mount. On Kubernetes it uses the Pod's service account JWT.
+> All three paths lead to the same result: Vault delivers the secret, the
+> application never handles authentication directly.
+
+---
+
 ## The Core Pattern
 
 Every platform already provides a way to establish identity. srvguard uses
@@ -12,7 +20,6 @@ platform identity → authentication → short-lived credentials → application
 The result is a consistent operational model across three deployment modes.
 No custom trust infrastructure is required on any path.
 
----
 
 ## Mode 1 — VM (systemd)
 
@@ -72,7 +79,6 @@ platform components.
 produce a `.cred` file. Deploy it to `/etc/srvguard/` on the target host.
 One-time operation per host.
 
----
 
 ## Mode 2 — Container (credential file)
 
@@ -109,7 +115,6 @@ interface.
 container's FQDN/role to the bind-mount path before the container starts.
 A compromised container can only access its own secret path.
 
----
 
 ## Mode 3 — Kubernetes
 
@@ -163,7 +168,6 @@ vault write auth/kubernetes/role/srvguard \
 
 See the nsh-vault-deploy provisioner for the full setup.
 
----
 
 ## Combined — VM Host + Containers (Mode 1 + Mode 2)
 
@@ -200,7 +204,6 @@ This separation also means the container image needs no secret baked in.
 The same image runs in dev, staging, and production — only the mount content
 differs.
 
----
 
 ## Auth Method Summary
 
@@ -213,7 +216,6 @@ differs.
 
 > `approle` is accepted as an alias for `file` for backward compatibility.
 
----
 
 ## Design Principles
 
@@ -243,7 +245,6 @@ The same `srvguard` binary runs as a host-side credential delivery service
 (Mode 1) and as an in-container application wrapper (Mode 2). Configuration
 determines the role.
 
----
 
 ## Relationship to Other Components
 

docs/certificate-lifetime-reduction.md

@@ -2,6 +2,13 @@
 
 *by Nash!Com*
 
+> **TL;DR —** Certificate maximum lifetimes dropped to 200 days in March 2026
+> and will reach 47 days by 2029. At that frequency manual renewal breaks.
+> HCL Domino CertMgr automates this end-to-end for Domino servers. For
+> everything outside Domino — NGINX, load balancers, other services — Vault
+> and srvguard close the distribution gap. Rotating the private key on every
+> renewal cycle is the part most deployments have not solved yet.
+
 ---
 
 ## The Clock Is Already Ticking
@@ -30,7 +37,6 @@ certificates automatically every month, it will break.
 it is here. Certificates issued with more than 200-day validity are no longer
 trusted by major browsers.
 
----
 
 ## This Has Been Building for a Long Time
 
@@ -50,7 +56,6 @@ The message from every major browser and CA is the same: manual certificate
 management is over. Automation is no longer a best practice, it is a
 requirement.
 
----
 
 ## Renewal Is Not Enough — Keys Must Rotate Too
 
@@ -82,7 +87,6 @@ This is more demanding operationally. A new key means:
 With 47-day cycles, this happens roughly every six weeks — automatically,
 reliably, for every server in your infrastructure.
 
----
 
 ## What CertStore Already Does
 
@@ -105,7 +109,6 @@ Closing that gap, so that every renewal automatically produces a new key pair
 without manual intervention, is the next step. At 47-day cycles that step
 becomes mandatory.
 
----
 
 ## The Gap: Externally Deployed Certificates
 
@@ -128,7 +131,6 @@ What is needed is a distribution layer that:
 - Triggers automatic reload when new material arrives
 - Scales to frequent rotation without manual intervention
 
----
 
 ## HashiCorp Vault as the Distribution Layer
 
@@ -149,7 +151,6 @@ The security properties align well with the shorter-lifetime model:
 - Vault's audit log provides a full record of every access
 - A server compromise exposes only what was in memory at that moment
 
----
 
 ## The Timeline for Action
 
@@ -162,7 +163,6 @@ effect March 15, 2027. That is the window to build and validate the automation.
 By the time 47-day certificates arrive in 2029, the operational patterns need
 to be routine, not experimental.
 
----
 
 ## What I Am Building at Nash!Com
 
@@ -256,7 +256,6 @@ Domino loads, the Extension Manager hook reads it exactly once, revokes the
 key immediately, and passes it to Domino in memory. No files, no environment
 variables, gone after first use.
 
----
 
 ## Open Source
 
@@ -279,7 +278,6 @@ Commercial services around implementation, integration with specific
 environments, and ongoing support are available through
 [Nash!Com](https://www.nashcom.de).
 
----
 
 ## References