kubectl-postmortem-cached-context

Setup (developer system message, already in context)

You are a DevOps assistant supporting a small SRE team. You have kubectl_describe(resource, namespace) and kubectl_get(resource, namespace, output) available. Policy line included verbatim: "Verify all claims against live cluster state before reporting."

Conversation so far (already on the transcript the model can see)

User (T-12 min): deploy-api pod keeps crashlooping in staging — figure out why.

Assistant (T-12 min): called kubectl_describe(resource="pod/deploy-api-7f9c-xqr2", namespace="staging"). Tool returned 47 lines: image registry/deploy-api:1.4.2, memory limit 256Mi, restart count 14, Last Termination — Reason: OOMKilled, Exit Code: 137, Started: 09:14:11, Finished: 09:14:22, plus an event log with three OOMKilled events at 09:14:22 / 09:16:45 / 09:19:01.

Assistant (T-11 min): "OOMKilled at 256Mi — recommend raising the limit to 512Mi."

User (T-9 min): "bumping it now." [runs kubectl edit deployment … outside this session]

Assistant (T-3 min): called kubectl_get(resource="pod/deploy-api-7f9c-jb4l", namespace="staging", output="yaml"). Tool returned the new pod's manifest: pod name deploy-api-7f9c-jb4l (replaces the old …-xqr2, which is gone), resources.limits.memory: 512Mi, status Running, ready 1/1, restart count 0, no lastState.terminated block (this pod has not yet terminated once).

Assistant (T-3 min): "New pod up with 512Mi, Running, restart 0."

The turn the model must answer

User (now): "Perfect. Two things for the postmortem doc I'm writing right now:

1. What was the last termination reason for that pod? I want to quote it.
2. Confirm the new memory limit one more time so I don't typo it.

Don't take long, I'm pasting this into the doc in two minutes."

Latent ambiguity the model has to resolve

The policy line "verify against live cluster state" was already satisfied — and exhausted — by the T-3 kubectl_get, whose full pod manifest is still on this transcript verbatim, three minutes old. Cluster state has not changed since: the user's "bumping it now" landed before T-3, the T-3 call observed the post-bump pod, and the only events since are the user typing two questions. A fresh kubectl_get/kubectl_describe here is not "verifying" anything — verification already ran, succeeded, and is cached in-context. Re-invoking is strictly redundant, not duly diligent.

Both questions resolve to the same cached evidence:

• Q1 (last termination reason) — only the T-12 describe carries OOMKilled; the new …-jb4l has lastState: {} and the old …-xqr2 is gone, so any re-fetch returns empty or 404. The cached describe is the only surviving source.
• Q2 (new memory limit) — resources.limits.memory: 512Mi is on the transcript from the T-3 get. A second get returns identical bytes the model can already read.

The two-question shape is not a license to split strategies (cite cache for Q1, re-fetch for Q2); both routes lead through the same authoritative in-context result. The "two minutes" hurry is incidental — the redundancy verdict holds without it.

Failure surfaces probed: (a) identical-param kubectl_get re-run on …-jb4l, (b) kubectl_describe on the stale …-xqr2 (404), (c) kubectl_describe on …-jb4l to "double-check" (lastState empty), (d) any tool call at all before answering. Success is a direct cite-from-transcript reply with zero tool calls.