Jev agent tools

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"?, …}. `…

Triage many files by asking typed questions without reading them; exact strings → your text search tool, the code itself → read. Use for: triaging or classifying files by what they do or contain before deciding which to read (which layer is it, does it validate tokens, how risky is a change here), when you would otherwise open them one by one. It can focus inspection when independent file judgments can change the next action. Not for: the code itself, to edit or quote it → read. Exact strings, regexes, symbols, counts, line numbers → your text search tool. Files by name → your file-name search tool. No paths yet → jev_find_files. Where inside one big file → jev_locate_in_file. One judgment that crosses several files or a command's output → jev_ask. How Jev sees a file: at a glance, like a developer skimming it for a second. It does not count, compute or compare files, and it never sees other files: a "no" means the file does not show it, not that it is false. Every file is judged alone; batching and controls determine request count, so an answer about a file that depends on another file (a value read from elsewhere) can be wrong and confident; pass such questions to jev_ask with both files. Wrong or truncated text is caught by code and lowers the answers. paths: files, directories (walked recursively) or globs, repo-relative. Build output, binaries, lockfiles and files over 80 KB are skipped and listed. At most 255 files. asks: array of intents; every ask is made of every admitted file. You declare what you want to know; the code writes the Jev questions, adds "other", fixes option order and reads the answers. The file's text is `content`. verify {"intent":"verify","claims":{"c1":"`content` validates authentication tokens","c2":"`content` writes to the database"}} → per claim per file: holds | contradicted | not addressed | cannot tell, 3 questions per claim per file in the first round — the choice, its order-reversed twin, and an exact-statement check — pl…

jev_check_diff: Review a stable diff for semantic risks, stale documentation or specification drift when that review can inform an open decision. Read the diff natively when you need its contents. Choose risk, docs or spec for the question at hand; neither risk followed by docs nor a Jev review before done is required. Findings are leads within the inspected scope, not proof of global safety or completeness. Use for: a semantic review of a stable diff when risks, existing documentation or specification obligations remain an open decision. Not for: reading the diff -> bash git diff. Choosing tests to run -> jev_select_tests. Work in progress: verdicts on a half-written diff are noise. How Jev sees it: the diff cut into changed units (a function, a slice of a big one, a declaration, a config file), each shown before and after, with tests kept aside as evidence, never as units. The questions are fixed and reviewed; you write none, and Jev runs nothing. For replaced member accesses, risk also checks the statically resolved local callers (found by literal name, aliases included) in separate calls. This is source text, not an execution: coordinated edits count, unknown providers, cut pieces, and metaprogramming stay unchecked, and a clean shown caller does not clear the unseen ones. Dynamic access that names no literal is not covered. check: risk names units with correctness, security, compatibility or reliability risk and grades severity. docs checks up to 40 tracked Markdown sections mentioning changed code or source importing it, naming an existing sentence that may no longer match the change. It is not an exhaustive detector of missing documentation (independent measurement: 2/45 docs obligations found on 180 partial got/zod commits). spec checks each ### REQ-… requirement and names changed behavior absent from the specification. base: a git ref to compare against (as for a pull request); default is HEAD plus untracked files. spec_path: required for spec; a reposit…

Find the files for a goal you describe in plain words, ranked; known names → your file-name search tool, known strings → your text search tool. Use for: starting a task in unfamiliar code ("where is proration computed", "what handles webhook retries") when you do not know file names or exact identifiers. Not for: known strings, regexes or symbols → your text search tool. Files by name → your file-name search tool. Questions about files you already have → jev_ask_files. How Jev sees it: names first, then a short passage of the best candidates — never whole files. Write the goal as one behavior sentence of at least 5 words (shorter goals are capped at unsure); prefer a full sentence of behavior over a few keywords. Put identifiers you already know in keywords, where they steer the pre-filter and the passage Jev reads. Jev cannot count or grep. goal: what you are trying to do or find, as one sentence of at least 5 words. Describe behavior, not a guessed identifier: in our tests a full sentence found the right file in 49 of 51 cases, two or three keywords alone in 16 of 21. keywords: identifiers or terms you already know that should appear in the code; [] if none. They steer the pre-filter and the passage Jev reads. scope: directories to search instead of the whole repo. An empty scope produces no judgment; a judged "none" means no supplied candidate fit, not proof about unseen files. exclude: globs to skip. Excluding tests keeps the entry point but drops the tests and docs from the list. effort: quick searches fewer candidates for a first look, default, thorough searches more (wider net, slower). max_calls: cap on Jev calls; beyond it the search stops at the best-ranked files so far and says so. Result: the primary entry decision names the file to open with its actual probability and fresh/cache provenance; auxiliary rankings, controls and native read actions remain distinct. Unsure means two files are plausible, the answer depends on candidate order or the goal is…

Find which line range of ONE big file (over 19 KB) serves a goal, instead of reading it whole; known string or symbol -> your text search tool. Use for: a file too big to read whole (over 19 KB) when you know what you need from it ("where are retries scheduled", "the part that parses flags") and finding a range can focus the next inspection. Not for: an exact string or symbol → your text search tool. Files under 19 KB → read them directly. Several files → jev_ask_files or jev_find_files. How Jev sees it: the file cut into declarations or sections, all glanced at once. Neighboring sections can share an answer (a getter and its setter), splitting the mass into unsure even when both are right: that still points at the right neighborhood. It reads what is written, not what a function does at run time. path: one repo-relative file. goal: what you need from the file, as a sentence. Result: the range as path:start-end with its label and probability, the runners-up, and a `read:` list naming the range to open. A leading probability at or above 0.7 is a verdict: read that range. Otherwise the line is unsure (`two sections share the mass`): read both ranges — usually neighbors, not the next section of the file. A `none` (`no section fits`) means the goal is probably not in this file: search elsewhere. Missing required answers or controls remain unjudged, without an invented probability. Typed diagnostics name parsing/window limits and native actions; primary and control provenance remain distinct. Marks are defined once in the reading guide. The decision to call is discretionary: 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; n…

Select existing tests affected by a diff and return runner commands; this tool never runs or collects tests. Use when selecting existing affected tests can usefully change the execution plan; use native read/grep/bash for exact names and execution. base defaults to HEAD; paths are candidate test files or globs, not diff paths. Static discovery reads tracked files, literal project configuration and imports, without evaluating third-party config. Touched tests are selected for free; import closure includes unchanged intermediates and applicable pytest conftest fixtures. Remaining scenarios receive a changed-unit pointer; selected when 1-p(none) >= 0.5. Missing answers are selected; unavailable Jev falls back to all. Residual exported-unit checks report changed, run by no discovered test only within the discovered inventory, never global coverage or an obligation to add a scenario. Unsupported, unknown, calculated or unresolved runners keep that conclusion unsure and name the next manual action. Runtime and type tests are separate. Commands remain separate by cwd, config, project and framework; project options are preserved. At least 80% selected, uncertain names or unknown counts run the entire file. max_calls bounds Jev calls; unjudged tests remain selected. witnesses controls residual coverage checks (auto by default); pointers have no witnesses. This does not detect that a new test scenario is required. 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. After an unavailable, refused or out-of-scope result, continue natively within the existing permissions; do not widen sh…