docs: S03.11 promote TLS to Available and sweep markdown drift

Bdd/syslog-ng/tls/README.md

@@ -1,16 +1,19 @@
 # BDD TLS test material
 
 **TEST ONLY.** These keys and certificates exist solely to drive the BDD TLS
-scenarios (`Bdd/features/tls_transport.feature` et al.) against syslog-ng
-running in a BDD compose container. They must never be used for any purpose
-that touches real data.
+and mTLS scenarios (`Bdd/features/tls_transport.feature`,
+`Bdd/features/mtls_transport.feature`) against syslog-ng running in a BDD
+compose container. They must never be used for any purpose that touches real
+data.
 
 | File | Role |
 |---|---|
-| `ca.key` | Test CA private key. Signs the server cert. |
-| `ca.pem` | Test CA certificate. Bundled into the example binary via `--tls-ca`. |
+| `ca.key` | Test CA private key. Signs the server and client certs. |
+| `ca.pem` | Test CA certificate. Trust anchor for both the example binary (verifies the server) and syslog-ng (verifies the client in mTLS mode). |
 | `server.key` | syslog-ng server private key. |
 | `server.pem` | syslog-ng server certificate, signed by the test CA. SANs: `syslog-ng`, `localhost`, `127.0.0.1`. |
+| `client.key` | Client (SolidSyslog-under-test) private key for mTLS. |
+| `client.pem` | Client certificate for mTLS, signed by the test CA. CN: `solidsyslog-bdd-client`. |
 
 Validity is 10 years from generation, so these effectively never expire for
 test purposes.

DEVLOG.md

@@ -1,5 +1,50 @@
 # Dev Log
 
+## 2026-04-22 — S03.11 TLS promoted to Available + docs sanity pass
+
+### Decisions
+- Promoted TLS from Planned to Available in `docs/iec62443.md`: new
+  `SolidSyslogTlsStream` row in the SL4 components table, present-tense
+  bullets for what SL4 now adds, and a "Still to come" block carrying the
+  remaining E17 (integrity + encryption at rest) and S12.x (string hygiene)
+  items. Dropped the "Remaining E03 work" paragraph — there's no
+  compliance-relevant E03 work left; S03.12 / S03.13 are architectural.
+- Added CR 1.5 (Authenticator management) and CR 1.8 (PKI certificates) to
+  the Relevant Requirements table at SL4 and wired both into the
+  traceability matrix. Both are honestly claimed: library covers the bits
+  it can (load / refresh / authenticity / integrity), and the notes call
+  out the integrator-owned pieces (at-rest key protection is filesystem /
+  HSM; revocation is deferred to the OS trust store per the S03.08 ADR;
+  enrolment is the caller's PKI process). Better to state the gaps than
+  to overclaim.
+- README Status section rewritten: "Approaching feature-complete for POSIX
+  and Windows"; not production-ready; explicit known-gaps list covering
+  API churn, at-rest cryptography, CRL/OCSP, PRINTUSASCII / UTF-8 hygiene,
+  and error-guard rollout. Keeps the "not production-ready" signal but
+  stops undersellling where the library actually is.
+- Sanity-checked the other repo markdown and fixed the drift that was
+  visible: `docs/rfc-compliance.md` RFC 5425 section (all rows were
+  Planned — now 6 Supported + 1 Partial for the absent
+  `SOLIDSYSLOG_TLS_DEFAULT_PORT` constant); `docs/bdd.md` architecture
+  diagram + syslog-ng source list + `@tls` / `@mtls` feature tags;
+  `Bdd/syslog-ng/tls/README.md` now lists `client.key` / `client.pem` and
+  mentions `mtls_transport.feature`; `docs/ci.md` gains
+  `openssl-integration` and `bdd-windows` rows; `SKILL.md` lists RFC 6587
+  and notes the epic-number range has grown beyond the original #2–#12.
+- Epic #5 story table synced: S03.06 / S03.07 / S03.08 / S03.09 marked Done
+  with PR links.
+
+### Deferred
+- `SOLIDSYSLOG_TLS_DEFAULT_PORT = 6514` constant — would promote the RFC
+  5425 §4.2 row from Partial to Supported. Small, mechanical, not urgent.
+- `docs/template-updates.md` claims `docs/` is template-owned. That
+  conflicts with the reality that `docs/iec62443.md` /
+  `docs/rfc-compliance.md` are clearly project-specific. Worth tightening
+  the template-ownership list on a later pass.
+
+### Open questions
+- None.
+
 ## 2026-04-22 — S03.10 retired (cert rotation covered by reconnect)
 
 ### Decisions

README.md

@@ -14,7 +14,25 @@ Designed for resource-constrained environments:
 
 ## Status
 
-Early development. Walking skeleton in place. Not yet suitable for production use.
+Approaching feature-complete for POSIX and Windows: RFC 5424 structured
+formatting, UDP / TCP / TLS / mTLS transport, asynchronous buffering, rotating
+file store-and-forward with CRC-16 integrity, and the full
+[IEC 62443 SL1–SL4 component set](docs/iec62443.md).
+
+**Not yet production-ready**, and no API stability guarantee yet. Known gaps:
+
+- Public API may evolve — multi-instance senders / streams
+  ([#169](https://github.com/DavidCozens/solid-syslog/issues/169)) and
+  additional platform backends (RTOS, custom) are still to land.
+- At-rest integrity is CRC-16 only; HMAC + AES-at-rest are planned for SL4
+  ([E17 #105](https://github.com/DavidCozens/solid-syslog/issues/105)).
+- TLS revocation (CRL / OCSP) is deferred to the OS trust store; the library
+  itself does not perform revocation checks.
+- PRINTUSASCII header validation and UTF-8-safe body truncation not yet
+  enforced ([#120](https://github.com/DavidCozens/solid-syslog/issues/120),
+  [#121](https://github.com/DavidCozens/solid-syslog/issues/121)).
+- Comprehensive error guards still rolling out
+  ([E12 #31](https://github.com/DavidCozens/solid-syslog/issues/31)).
 
 ## Building and testing
 
@@ -34,9 +52,12 @@ Public headers are split by audience (Interface Segregation Principle):
 - **`SolidSyslogNullBuffer.h`** — direct-send buffer for single-task systems
 - **`SolidSyslogPosixMessageQueueBuffer.h`** — thread-safe POSIX message queue buffer
 - **`SolidSyslogUdpSender.h`** — UDP transport (RFC 5426)
-- **`SolidSyslogStreamSender.h`** — octet-framed syslog (RFC 6587) over any Stream (TCP today, TLS in future). Note: RFC 6587
+- **`SolidSyslogStreamSender.h`** — octet-framed syslog (RFC 6587) over any Stream. Note: RFC 6587
   is a Historic RFC — the IESG recommends TLS (RFC 5425) over plain TCP for new deployments.
   TCP is provided for interoperability with existing infrastructure
+- **`SolidSyslogTlsStream.h`** — OpenSSL-backed TLS 1.2+ Stream (RFC 5425): server cert validation,
+  hostname verification, cipher pinning, optional mutual TLS. Plugs into `SolidSyslogStreamSender`
+  as a drop-in for `SolidSyslogPosixTcpStream`
 - **`SolidSyslogSwitchingSender.h`** — composition sender delegating to one of several
   inner senders via an application-supplied selector callback; `Disconnect`s the
   outgoing inner on every change
@@ -54,7 +75,7 @@ Public headers are split by audience (Interface Segregation Principle):
 
 Two example programs demonstrate usage:
 - **`Example/SingleTask/`** — NullBuffer, single-task bare-metal model
-- **`Example/Threaded/`** — PosixMessageQueueBuffer, two pthreads (logger + service), SwitchingSender over UDP + TCP; `--transport` sets the initial transport, `switch <name>` flips it at runtime
+- **`Example/Threaded/`** — PosixMessageQueueBuffer, two pthreads (logger + service), SwitchingSender over UDP + TCP + TLS + mTLS (TLS build required for the last two); `--transport` sets the initial transport, `switch <name>` flips it at runtime
 
 ## Compliance
 

SKILL.md

@@ -2,9 +2,9 @@
 
 ## What this project is
 
-SolidSyslog is a C syslog client library implementing RFC 5424/5426/5425 for embedded
-and industrial systems. It is developed under the "Crafted with AI" blog series by
-Cozens Software Solutions Limited.
+SolidSyslog is a C syslog client library implementing RFC 5424/5426/6587/5425 for
+embedded and industrial systems. It is developed under the "Crafted with AI" blog
+series by Cozens Software Solutions Limited.
 
 ## Collaboration architecture
 
@@ -91,7 +91,8 @@ Test progression follows ZOMBIES order.
 
 ## Key references
 
-- Epics tracked as GitHub Issues #2–#12, Project board "SolidSyslog" (project #1)
+- Epics tracked as GitHub Issues, Project board "SolidSyslog" (project #1); active and future epics are labelled `epic` and numbered beyond the original #2–#12 range (e.g. E12 #31, E14 #64, E17 #105, E18 #112)
 - RFC 5424 — structured syslog message format
 - RFC 5426 — syslog over UDP
+- RFC 6587 — syslog over TCP (octet counting)
 - RFC 5425 — syslog over TLS

docs/bdd.md

@@ -24,7 +24,8 @@ fail here.
                               │   binary     ││
                               └──────┬───────┘│
                                      │        │
-                                UDP 5514      │
+                            UDP 5514 / TCP 5514│
+                            TLS 6514 / mTLS 6515
                                      │        │
                                      ▼        │
                               ┌──────────────┐│
@@ -33,14 +34,14 @@ fail here.
                               └──────┬───────┘│
                                      │ writes │
                                      ▼        ▼
-                              Bdd/output/received.log
+                              Bdd/output/received*.log
 ```
 
 Two Docker Compose services collaborate:
 
 | Service | Role |
 |---|---|
-| `syslog-ng` | Receives UDP syslog on port 5514, parses RFC 5424, writes parsed fields to a log file |
+| `syslog-ng` | Receives syslog on UDP / TCP 5514, TLS 6514, and mTLS 6515; parses RFC 5424; writes parsed fields to per-transport log files |
 | `behave` | Runs Gherkin scenarios that invoke the example binary and assert on the parsed output |
 
 The example binary is built in the `gcc` container but executed by Behave via `subprocess.run`.
@@ -60,9 +61,11 @@ syslog-ng (writer) and Behave (reader) without any network file transfer.
 
 ## syslog-ng configuration
 
-The syslog-ng config (`Bdd/syslog-ng/syslog-ng.conf`) uses the `syslog()` source driver,
-which understands RFC 5424 natively. It writes one line per received message using a key=value
-template:
+The syslog-ng config (`Bdd/syslog-ng/syslog-ng.conf`) declares four `syslog()` sources —
+UDP and TCP on 5514, server-auth TLS on 6514, and mutual TLS (`peer-verify(required-trusted)`)
+on 6515 — all parsing RFC 5424 natively. Every message is tee'd to both `received.log`
+(catch-all) and a per-transport log file (`received_udp.log`, `received_tcp.log`,
+`received_tls.log`, `received_mtls.log`) using a key=value template:
 
 ```
 PRIORITY=14 TIMESTAMP=2009-03-23T00:00:00+00:00 HOSTNAME=TestHost APP_NAME=TestApp PROCID=1234 MSGID=TestMsgId STRUCTURED_DATA= MSG=Test message
@@ -103,8 +106,9 @@ response = sock.recv(1024)  # b'OK Config reload successful\n.\n'
 sock.close()
 ```
 
-This will be needed when BDD scenarios require different syslog-ng source configurations —
-for example, switching from UDP to TLS transport in E3.
+This is exercised by scenarios that need a different syslog-ng source configuration — for
+example, the TLS and mTLS scenarios swap in tighter `peer-verify` settings and reload without
+restarting the container.
 
 ## Feature tags
 
@@ -117,6 +121,8 @@ etc.) without rewriting feature tags.
 | --- | --- |
 | `@udp` | Needs UDP transport |
 | `@tcp` | Needs TCP transport (RFC 6587 framing) |
+| `@tls` | Needs TLS transport (RFC 5425, server-auth) |
+| `@mtls` | Needs mutual TLS (client cert + key) |
 | `@buffered` | Drives the long-running threaded example (interactive process protocol — buffer + service thread; transitively covers store-and-forward, oracle reload, signal-kill scenarios) |
 
 Two rollout markers are also used (temporary; remove once the scenario passes):

docs/ci.md

@@ -14,7 +14,9 @@ GitHub Actions runs all jobs in parallel on every push and pull request to `main
 | `cppcheck` | `cppcheck` | cppcheck static analysis |
 | `format` | — | clang-format dry-run; fails if any file needs reformatting |
 | `windows-build-and-test` | `msvc-debug` | MSVC build on `windows-latest`; CppUTest via vcpkg; test results annotated on PR |
-| `bdd` | — | End-to-end BDD test via Docker Compose (syslog-ng + Behave) |
+| `openssl-integration` | `debug` | Runs the in-process TLS integration tests against libssl (no network oracle) |
+| `bdd` | — | End-to-end BDD test via Docker Compose (syslog-ng + Behave), Linux runner |
+| `bdd-windows` | — | Windows-eligible BDD scenarios driven against an OTel Collector oracle |
 
 ## Branch protection