{
  "version": 1,
  "state": "010-kubernetes-runtime",
  "title": "Move the runtime without changing the trading lesson",
  "purpose": "An application that works on Compose still needs service discovery, readiness and ingress when moved to a cluster. This chapter is for developers learning Kubernetes through a familiar workload: keep the order workflow fixed while investigating its new runtime boundaries.",
  "entryAssumptions": "C2 combines orders, pricing and observability on Compose.",
  "concepts": [
    "A pod is a scheduling unit. A Service gives stable routing to selected pods. Readiness determines whether a pod should receive traffic; replicas alone do not make a workflow correct."
  ],
  "runtimePrerequisites": "Use the state quickstart for tool versions, generation, start and stop commands. Run one local state at a time because ports and generated output directories are shared.",
  "entryMode": "combined",
  "transitions": [
    {
      "from": "009-order-management-matcher",
      "carriesForward": "Introduce limit orders, matching and fills while keeping orders distinct from executed trades.",
      "motivation": "C2 combines orders, pricing and observability on Compose.",
      "increment": "Run C2 on Kubernetes and explain ingress, service routing and pod readiness.",
      "objectiveIds": [
        "trace-increment",
        "interpret-evidence"
      ],
      "evidence": "Runtime objects replace Compose placement while the order lifecycle remains. The namespace and service selectors explain where traffic goes. An unready backend and a missing ingress route require different fixes. Healthy pods alone do not establish working end-to-end routing."
    }
  ],
  "before": "C2 combines orders, pricing and observability on Compose.",
  "after": "Run C2 on Kubernetes and explain ingress, service routing and pod readiness.",
  "objectives": [
    {
      "id": "trace-increment",
      "outcome": "Map an ingress request through a Kubernetes Service to ready pods and verify the retained order behavior."
    },
    {
      "id": "interpret-evidence",
      "outcome": "Explain the evidence boundary: An unready backend and a missing ingress route require different fixes. Healthy pods alone do not establish working end-to-end routing."
    }
  ],
  "walkthrough": [
    {
      "id": "observe",
      "objectiveIds": [
        "trace-increment"
      ],
      "availability": "available",
      "action": "Follow the kind quickstart, including the wait-ready status command and smoke test. Use kubectl get pods,svc -n traderx to map one trade request from ingress to its backend. Submit a small order through the UI and compare with C2 behavior.",
      "expected": "Runtime objects replace Compose placement while the order lifecycle remains. The namespace and service selectors explain where traffic goes.",
      "references": [
        "/specs/kubernetes-runtime/quickstart",
        "/specs/kubernetes-runtime/system/architecture",
        "/specs/kubernetes-runtime/system/runtime-topology"
      ]
    },
    {
      "id": "challenge",
      "objectiveIds": [
        "interpret-evidence"
      ],
      "availability": "available",
      "action": "Inspect kubectl describe pod for a service that is starting or unready, or inspect its readiness probe definition when all pods are ready. Compare process state with the readiness condition before diagnosing ingress.",
      "expected": "An unready backend and a missing ingress route require different fixes. Healthy pods alone do not establish working end-to-end routing.",
      "references": [
        "/specs/kubernetes-runtime/spec",
        "/specs/kubernetes-runtime/contracts/contract-delta"
      ]
    }
  ],
  "assessments": [
    {
      "objectiveIds": [
        "trace-increment",
        "interpret-evidence"
      ],
      "question": "Which observations separate a scheduling problem from an application routing problem?",
      "guidance": "Use pod events/readiness and Service endpoints, then test ingress and the business result. Explain which boundary each observation tests."
    }
  ],
  "limitations": [
    "An unready backend and a missing ingress route require different fixes. Healthy pods alone do not establish working end-to-end routing.",
    "This is an educational local demonstration. Passing its checks does not establish production readiness, financial settlement, or correctness under every failure mode."
  ],
  "coaching": [
    {
      "objectiveIds": [
        "trace-increment",
        "interpret-evidence"
      ],
      "diagnosticQuestion": "How did Compose route the retained order workflow, and what does readiness mean?",
      "predictionPrompt": "Predict whether healthy pods alone establish that the public ingress route works.",
      "hints": [
        "Map ingress to the Service and inspect which ready endpoints it selects.",
        "Use pod events and readiness to separate scheduling trouble from application routing trouble."
      ],
      "misconception": "Pod health proves end-to-end reachability or correct order processing.",
      "evidenceToRequest": "Ask for pod/readiness, Service routing and ingress observations plus an order result; require a boundary-by-boundary explanation."
    }
  ]
}