> ## Documentation Index > > Fetch the complete documentation index at: https://lithi.ai/llms.txt > > Use this file to discover all available pages before exploring further. --- title: Review code with bounded evidence and real test output description: >- Get review findings tied to exact lines, plus the output of tests and analyzers that actually ran. Nothing is edited in your source and nothing is committed. route: /docs/compute/examples/code-quality page_id: docs-compute-examples-code-quality page_type: tutorial content_layer: guided documentation surface_profile: guided_docs audience: Engineering teams reviewing a bounded set of source files voice: D reader_question: How do I get code review findings backed by tests and analyzers that actually ran? primary_action: Run a six-file review test source_locale: en-US source_status: APPROVED source_version: docs-compute-examples-code-quality-en-us-2026-09-05-v1 last_updated: '2026-09-05' robots: index claim_registry_pinned: true claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write" --- ## What you get Two kinds of output, deliberately kept in different places. - Suggested findings, each pinned to a file and a line range in `lithi_evidence`. - Executed evidence: the actual exit status and output of the analyzers and tests the run was told to execute. - Files the run could not read or parse, in `failures/part-*`, with a typed code and a next action. - `provenance.json`, carrying the digest of the exact source snapshot that was read. A finding is a suggestion about your code. A test result is a fact about a run. Treating them as one list is how a plausible guess gets the authority of a passing test, so this example never merges them. ## What you need Six files and a manifest, chosen to include the awkward cases rather than your cleanest module. ```text file_id,path,language,line_count,role SRC-01,src/pricing/rounding.ts,typescript,84,library SRC-02,src/pricing/rounding.test.ts,typescript,120,test SRC-03,src/pricing/discount.ts,typescript,211,library SRC-04,src/api/handler.ts,typescript,340,entrypoint SRC-05,vendor/legacy.min.js,javascript,1,generated SRC-06,src/pricing/broken.ts,typescript,57,library ``` Declare `file_id` as your `item_id_field`. File five is a minified vendor file that should be skipped rather than reviewed. File six does not compile, so it exercises the difference between a review comment and a build failure. Bound the evidence explicitly. Name the files the run may read, and name the analyzer or test command it may execute. An unbounded "review the repository" request cannot be quoted, reproduced or checked. ## Run it 1. Inspect locally: `lithi inspect ./review-fixture`. It reports encoding, generated-file markers and files too large for the workflow's bounds: [check an input before you send it](/docs/compute/inputs/local-inspection). 2. Read the workflow: `lithi workflow explain `, and read which analyzers and test runners it accepts as parameters. 3. Declare two output partitions in your submission: one for suggested findings, one for executed test and analyzer results. Separate files are much harder to confuse than a `kind` column. 4. Quote it: `lithi quote --workflow --input ./review-fixture/manifest.csv`. The quote gives a maximum charge and an expiry, and authorizes nothing. 5. Approve the quote separately, then submit with `lithi batch submit` and track with `lithi status `. ## Read the result Open `result-manifest.json` first, then read the executed partition before you read a single finding. A test that ran and failed tells you more than twenty suggestions. Check the exit status and the reported command, and confirm the command is the one you declared. If the analyzer never ran, every finding beside it is unverified opinion, and reading them first will mislead you. Then work through the findings. Open the cited file and line range for at least five of them. A finding whose cited lines do not support it is a defect in the run, not a subtle insight. Confirm the vendor file was skipped rather than reviewed. The file that does not compile should appear as a typed failure with a next action. Check the source digest in `provenance.json` against the snapshot you submitted, so you know which bytes were read: [what a receipt proves](/docs/compute/results/receipts-and-provenance). ## Where it stops You get findings and test evidence. You do not get changed code. Nothing is edited in your source, nothing is committed, no branch or review is opened, and no build is promoted. Every suggestion arrives as text for a person to accept, adapt or reject. A suggested finding carries no accuracy promise. It is a reading of bounded evidence under the parameters you set, and the run will miss things that live outside the files you named. Widen the bounds deliberately rather than assuming silence means clean.