docs(skill): check intent first on any failure-relevant code change (#875)

Replace the "uncommitted edit → Case 1 mandatory" gate with a
symmetric intent check that applies to BOTH committed and uncommitted
source changes on the failing handler's path — AND only when the
change could plausibly be causing the failure.

Why: validation runs against cursor-agent --print repeatedly
misclassified scenarios. The two-bucket framing
(uncommitted = revert, committed = mock) gave the model a permission
gradient that flipped its decision on the wrong axis. It rationalized
"preserve your source change" and silently patched the mock for what
was actually a half-finished regression.

The new wording:
  - treats committed and uncommitted symmetrically
  - ties the check to the actual failure (does the diff touch the
    drifted field / SQL / header / status code in the report?)
  - forces an explicit intent question when the diff doesn't decide
  - bans the most common misclassification phrase the model
    produces ("patch a mock to preserve an uncommitted edit")

Mirrored from .cursor/skills/keploy/SKILL.md in the test-12
validation workspace.

Signed-off-by: Charan Kamarapu <kamarapucharan@gmail.com>
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>

Author: charankamarapu

versioned_docs/version-4.0.0/quickstart/k8s-proxy-llm-workflow.md

@@ -264,7 +264,7 @@ Run all three **every time**, even when the tree looks clean. The empty result I
 
 **Allowlist of MCP calls permitted before Step 0** (Phase A1 discovery only): `listApps`, `getApp`, `create_branch`, `list_branches`, `listTestReports`, `getTestReport`, `tools/list`. EVERY other call — `getTestReportFull`, `getTestCase`, `getMock`, `listMocks`, `getRecording`, `listRecordings`, `updateTestCase`, `delete_recording` — is classifier/write and MUST come AFTER Step 0. Reading `getTestCase` first biases toward Case 2 framing.
 
-Any uncommitted edit touching the failing handler's source → **Case 1, mandatory.** Revert (or ask the dev); do NOT proceed to commit-history reasoning. Uncommitted edits beat any committed-history signal — they can't be the deliberate new contract.
+Any code change on the failing handler's path **that could be causing the failure** — committed OR uncommitted — **check intent FIRST**, then classify. Tie the change to the failure first: does the diff touch the same field / SQL / header / status code the report says drifted? If the working-tree edit is unrelated to what's failing, it's not what you're looking for — keep diagnosing. Was the change EXPECTED (intentional contract change) or UNEXPECTED (regression)? Don't assume uncommitted = intentional or committed = intentional. If intent isn't obvious from the diff alone (commit message that explicitly names the contract change, or matching dev request in this session), ASK THE DEV in one short question and stop. Once intent is known: **expected → Case 2** (fix test data on the branch); **unexpected → Case 1** (revert the source change). Never patch a mock to "preserve" an uncommitted edit without confirming intent — uncommitted edits are just as likely to be a half-finished regression as a deliberate contract change.
 
 **Step 1 — Identify the recording's snapshot anchor.**