Jev ask

Ask typed questions about one situation (note, files, command output); the same questions over many files → jev_ask_files. Use for: one judgment that combines things (is this test failure a bug, a wrong test or the environment; does this test cover the function changed in that file; is the user's request clear enough to plan). Not for: the same questions over many files, one answer each → jev_ask_files. Output or code you need to read or quote → bash or read. Exact matches → your text search tool.

How Jev sees the situation: at a glance, like a developer skimming what you assembled. It does not count, compute or chain inferences, and it does not notice what the state lacks: a missing piece looks like "no". What you put in the state outweighs what you tell it, so pass the evidence, not your argument, and do not explain roles ("this is a test"). Give both sides of a comparison: the failing test and the code it calls, the file before and after.

Give at least one of state, paths, command; code builds one situation and performs bounded judgments and controls, and you get only the answers back. state: your note, short: the request, your plan or hypothesis, what you know that the files do not show. Not for pasting file contents or output. Appears as state. paths: up to 20 files for code to read. Appear as files["<path>"]. base: a git ref. Each path is also given as it was at that ref, as files_before["<path>"] (null if it did not exist), so you can ask what changed. When the question is about what you changed, pass base (HEAD if uncommitted) so Jev sees the file before and after. Counts against the state budget. command: run with bash -c in the repo root, CI=1, same permissions and approval as bash. Appears as output with command, exit_code, timed_out, stdout, stderr. Repetitive lines are collapsed; if still too long, Jev keeps the passages that show a failure and the output is marked truncated. asks: array of intents, each {"intent", "about"?, …}. about names the part of the state it concerns (files["src/a.ts"], output, state). You declare what you want to know; the code writes the Jev questions, adds "other" and "cannot_tell", fixes option order, and reads the answers. verify {"intent":"verify","about":"files["src/domain/billing.ts"]","claims":{"c1":"prorate rounds down to the whole cent","c2":"prorate throws a RangeError for an empty period"}} → per claim: holds | contradicted | not addressed by the state | cannot tell classify {"intent":"classify","about":"output","categories":{"environment":"missing file, dependency, network, permission or config","bug_in_code":"the code under test does something its name or other assertions say it should not","wrong_test":"the code behaves as named and the failing assertion expects an inconsistent value"},"pick":"one"} locate {"intent":"locate","about":"files","target":"reads the Authorization header","among":["src/http/auth.ts","src/http/cors.ts"],"count":"one","attribution":true} → the candidates that match; attribution (count "one" only) adds one call without the file Jev pointed at and says "attributed" if the pick moves away, "does not rest on it" otherwise: use it before an action that rests on one pointed file rate {"intent":"rate","about":"files["src/domain/billing.ts"]","dimension":"risk of changing it","levels":["Isolated, covered by tests","Used by several modules","Security-sensitive, no tests"]} decide {"intent":"decide","about":"output","hypotheses":{"environment":"…","bug_in_code":"…","wrong_test":"…"}} exclusive hypotheses, exactly one is true; list the rivals, not only your thesis free {"intent":"free","question":{"type":"bool|choice|score","instructions":"…","criteria":…}} what no intent covers; the answer is marked uncalibrated max_calls: optional cap on Jev calls for this ask set; beyond it the tool stops and lists what it did not do. Claims are positive, self-contained statements of one fact that the state shows: write what you believe is the case, one fact each, never a question, no counts or dates. A negated claim is sent as written and flagged. Levels are concrete situations on one dimension, never "moderate" or numbers.

Write asks, not raw questions: one intent per judgment, every ask you need in one call. To tell a wrong test from a bug, pass the failing test and the code it calls in paths: the output alone cannot, and it looks just as sure of itself when it is wrong. If the output shows an assertion failure and the failing test is not in the state, the tool adds it when the log names it, or says "not identifiable"; treat any bug_in_code / wrong_test answer under that warning as unproven. Code you pass in paths uses declarations and data files that are not in the state: the tool adds those it finds by imports (depth 1, within a budget) and lists them on a closure: line, which is not a proof of completeness: files linked to yours by no import (config, docs, other flows) are not checked, so pass them yourself when the answer depends on them. An explicitly required file or output that is missing or empty excludes its question group; global-note requirements affect all groups. Ordinary lexical mentions are hints, not missing-file vetoes. Canonical file versions are stored once with alias metadata; before/current remain distinct. Over budget, files are refused with a split suggestion.

Result: per claim, category or hypothesis, your exact text next to the answer. An unmarked line is a verdict, still a lead to check. unsure means Jev does not see it clearly (choice under 0.85, a control failed, or scope/evidence disagreement between the exact-statement bool and the issues): the line shows both raw values and gives no verdict; read the passage or add the piece that would settle it, do not reword. A confident bool never overrides the issues or becomes proof of contradiction. abstain means the piece is missing: the line names it (paths or command); obtain it or leave the conclusion open; another call is optional when the changed evidence makes it useful. "Not addressed" means the state does not show it, not that it is false. Typed diagnostics name limits, scope and next actions; accounting separates HTTP attempts, questions sent, requested fresh/cache/static/unjudged results, auxiliary work and current reported cost. You never see the files or the output; if an answer surprises you, read them. The reading guide defines every mark once.

Use Jev for a bounded semantic judgment when its answer could change an open decision or focus the next inspection, and the relevant evidence is available. Use decisive reading, search or authorized execution directly when it settles the question. Exact lookup, counting and runtime causality belong to native tools. A Jev call is not a prerequisite for a conclusion, a review or task completion; no explanation is needed for choosing native tools.

Before a chosen call, identify the open decision and supply only the evidence needed for a bounded question; a complete prior analysis is not required. Ask about one positive, self-contained observable fact per claim, with its sources, and show both sides of a comparison.

• Failure: relevant output, the failing test and the implementation it exercises; output alone is a lead, not a bug-versus-wrong-test diagnosis. Include configuration or runtime evidence when the hypothesis depends on it. A static judgment does not establish runtime causality.

• Change: current evidence and the earlier reference via base. Use the checkout/root corresponding to the work and admitted by the tool; another clone is not the same context.

• Plan/documentation: precise observable commitments and the passages that constrain them. Local confirmation does not establish that omitted obligations were searched.

• Selection/review: compatible inventory, references and configuration. Suggested commands are not executed commands; existing tests need not cover a new scenario. Read the diff natively for its contents, not as proof of safety or global coverage.

After an unavailable, refused or out-of-scope result, continue natively within the existing permissions; do not widen sharing or confinement to obtain a judgment. For uncertainty or missing evidence, inspect or obtain the decisive piece, or leave the conclusion open. Revisit Jev only when new evidence, a material context change or a new useful question makes the judgment useful; rewording unchanged evidence is not a reason to retry. There is no retry quota for genuinely changed evidence, and no certification is needed once decisive evidence settles the question. A reached cap or an unjudged result is not evidence of safety or zero affected tests.