llm-assisted-api-debugging-lab 0.1.0

Deterministic API failure diagnoser with an LLM-assisted prompt template generator.
Documentation
---
source: crates/llm-assisted-api-debugging-lab/tests/reports.rs
expression: rendered
---
CASE: tls_failure
RULE: tls_failure
SEVERITY: critical (author judgment: transport-layer failure; no HTTP request was transmitted)
LIKELY CAUSE: TLS handshake to "api.example.com" failed; no HTTP request was sent.

EVIDENCE:
- TLS handshake to api.example.com failed: certificate has expired (NotAfter: 2025-12-31T23:59:59Z)

HYPOTHESES (consistent with evidence; not asserted as fact):
- Server certificate is expired, not yet valid, or signed by an untrusted CA.
- Hostname requested does not match any name on the presented certificate.
- Client trust store is missing an intermediate or root certificate.
- TLS protocol or cipher mismatch between client and server.

UNKNOWNS (do not invent answers):
- Whether the same client successfully completed TLS to this peer recently.
- The full certificate chain the server presented (subject, SANs, issuer, NotAfter).
- Client TLS library, version, and configured trust store.

REPRODUCTION:
cargo run -p llm-assisted-api-debugging-lab -- diagnose tls_failure

NEXT STEPS:
1. Run `openssl s_client -connect <peer>:443 -servername <peer>` and inspect the chain.
2. Check the leaf certificate's NotAfter and Subject Alternative Names against the requested hostname.
3. Verify the client's trust store includes the issuer's intermediate and root.
4. Compare against another client (e.g. `curl -v`) from the same network to isolate client vs server.

ESCALATION NOTE:
Connection failed at the TLS layer: no HTTP request was ever transmitted, so no application-level evidence is available. Resolution requires inspection of the certificate chain or client trust store; the failure is in the transport, not the API.