| { | |
| "id": "skupper-tutorial-flow", | |
| "title": "Skupper Tutorial Steps", | |
| "abstract": "A step-by-step dependency map for the Skupper Hello World tutorial, tracing from platform setup to application access and cleanup.", | |
| "categories": [ | |
| { | |
| "id": "network", | |
| "title": "Skupper Network", | |
| "items": [ | |
| { |
| { | |
| "id": "kubernetes-observability", | |
| "title": "Observability in Kubernetes", | |
| "abstract": "End users and operators need fast answers about service health, performance, and failures. In Kubernetes this is delivered via dashboards, explorers, and alerting that sit on top of signal stores (metrics, logs, traces). These stores are fed by collection and processing pipelines (agents, collectors, aggregators) that rely on Kubernetes primitives and underlying infrastructure (compute, storage, networking).", | |
| "categories": [ | |
| { | |
| "id": "experience", | |
| "title": "User Experience", | |
| "items": [ | |
| { |
chatkeeper 1.3.0 accepts a top-level conversations.json, but newer ChatGPT exports split conversations across files such as conversations-000.json, conversations-001.json, and so on.
If you only care about conversations, the easiest fix is to merge those shards back into a single conversations.json and build a minimal zip containing only that file.
The script for that is:
/home/paulwright/Downloads/chats/chatkeeper-normalize-conversations.sh
You have your "source" repos sitting in ~/repos. Instead of messy stashing or constant branch switching, you’re going to project specific branches into a clean folder called featureA.
This allows your main repos to stay on main (or whatever stable branch they need) while you do the heavy lifting in your feature-specific workspace.
Integrate MkDocs Material to provide enhanced sidebar navigation for documentation at https://skupper.io/docs/ while preserving the existing Transom-based site structure.
input/docs/input/docs/index.md (MkDocs) vs input/docs/index.html.in (Transom)ignored_file_patterns only matches filenames, not directory paths
| { | |
| "id": "karpenter-autoscaling-landscape", | |
| "title": "Karpenter Autoscaling Landscape", | |
| "abstract": "Karpenter provisions Kubernetes worker nodes on AWS just in time for unschedulable pods. This map follows the value chain from application capacity and cost control down through pod scheduling signals, Karpenter policy objects, concrete node claims, AWS infrastructure integration, and operational controls.\n\nLegend: blue = user-visible platform outcomes; green = Kubernetes scheduling inputs; amber = Karpenter control objects; purple = cloud-provider integration; red = disruption and risk controls.", | |
| "categories": [ | |
| { | |
| "id": "platform-outcomes", | |
| "title": "Platform Outcomes", | |
| "items": [ | |
| { |