distill: 49 best practices from 5 projects (2026-03-27..2026-04-05)

Add 37 new entries and update 7 existing entries across 13 topic files.
Major contributions from agent-runtimes (K8s secrets, CI, Docker gotchas),
cluster-bootstrap (ArgoCD SSA, etcd tuning, DB migrations, Compose networking),
and cluster-apps/octopus-deploy (Helm vs raw manifests, ArgoCD source types).

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

debugging.md

@@ -89,3 +89,11 @@ Distroless and single-binary containers (Garage, distroless Go images, etc.) hav
 
 **For HTTP checks:** Use `kubectl port-forward svc/<name> <local-port>:<svc-port>` and run `curl` locally.
 **For verification scripts:** Don't assume exec-based checks will work. Design health checks around port-forward + local tools, or use Kubernetes-native probes.
+
+## Use Container Logs to Narrow the Failure Boundary
+
+When a service appears down, check its logs for successful requests from other clients before assuming a total outage. If some clients are connecting successfully (e.g., HTTP/3 but not TCP, or internal but not external), the issue is narrower than "service is down." This distinction dramatically reduces debugging scope.
+
+## Structured JSON Logging from Application Entry Points
+
+Web frameworks like uvicorn don't configure application-level loggers — only access logs appear by default. Named loggers have no handler unless `logging.basicConfig()` is called explicitly. This makes application logs invisible in production (K8s, Docker) with no error — just silence. Always call `logging.basicConfig()` with a structured format (JSON) early in application startup, before any `getLogger()` calls.