From 108c9fbf9657a04c55d2cc935f36b42627d71d7d Mon Sep 17 00:00:00 2001 From: Charan Kamarapu Date: Tue, 9 Jun 2026 16:14:14 +0530 Subject: [PATCH] docs(skill): check intent first on any failure-relevant code change MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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. Co-Authored-By: Claude Opus 4.7 Signed-off-by: Charan Kamarapu --- .../version-4.0.0/quickstart/k8s-proxy-llm-workflow.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/versioned_docs/version-4.0.0/quickstart/k8s-proxy-llm-workflow.md b/versioned_docs/version-4.0.0/quickstart/k8s-proxy-llm-workflow.md index d8de1496d..21e6c6a9b 100644 --- a/versioned_docs/version-4.0.0/quickstart/k8s-proxy-llm-workflow.md +++ b/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.**