Review code with bounded evidence and real test output

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.

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.
2. Read the workflow: lithi workflow explain <workflow-id>, 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 <workflow-id> --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 <job-id>.

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.

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.