A negative answer from a review tool needs its question and scope beside it. Filling absent answers or unfinished files with false makes unread material look as though it has been checked without finding a problem.
The request was for yes-or-no findings without changing the target code. Following the guide, response checks, file aggregation and test definitions showed the work behind that short answer: establishing which source files had actually been read to the end.
Accept only boolean answers
The inspected implementation accepts boolean answers for each question. It checks the question names, answer types and correspondence between requested and returned questions. An absent answer or a string saying no is rejected rather than converted to false.
This establishes response shape, not factual correctness. A valid boolean is not evidence that the judgment is right. For a question asking whether a problem exists, no is a generated judgment that the supplied evidence did not establish that problem. It is not a certificate that the whole program is free of defects or a measurement of accuracy.
A file must be fully read before joining the aggregate
The folder reviewer reads selected files in segments and records each segment’s start and end lines, source hash and response. Receiving answers for part of a file differs from finishing that file. A segment limit or failed request prevents the file from entering the completed-file list.
The implementation checks the source hash after reading a file, then checks earlier files again before producing the report. One may have changed while a later file was under review. The completed list records fully read, unchanged sources rather than the number of answers received.
Progress and findings are calculated separately
Aggregation uses segment answers only from files that remain on the completed-file list. It applies the following order to each question. This is a prose explanation of the inspected branches, not an execution receipt or an example run performed for this article.
The overall state can therefore be partial while a question still has a yes from another eligible file. Partial coverage need not erase that candidate finding. Answers from an unfinished file, however, do not enter the aggregate. The segment history retains more than the final answer can use.
- If any eligible completed file supplies yes, the aggregate answer is yes. This identifies a candidate problem to investigate; actual reproduction is a separate step.
- With no yes, the aggregate answer is no only when every selected file has been completed without errors or a limit stopping the review.
- With no yes and unfinished coverage, the answer is unknown. Its internal value remains null rather than false.
A changed source changes where an old answer applies
If the source changes after review, the file is removed from the final completed-file list and a change error is recorded. Its answers no longer enter the aggregate. An old response remaining in segment history cannot support a current negative answer about that file.
The rule retains the historical review while restricting its use for the current version. An identical path and line range cannot transfer an answer automatically to edited code. A later review must examine the change and decide what scope to read again.
Pass on the answer and the unfinished scope together
The selected implementation separates attempted calls from calls that returned a valid result. It increments attempts before calling and completions after a valid return. Interruption or connection failure can leave different counts. A missing result alone cannot establish that no remote request began.
In the inspected connection-failure and cancellation branches, the error is retained and processing stops without an automatic retry. The compact CLI view shows answers by question, while the detailed result retains progress, completed files, segments and errors. The next reviewer needs that record alongside the short answer to understand why work remains unfinished. I did not run that CLI or make an outside model request while writing this article.
The report’s completed state applies to the declared source-review scope. It does not confirm a live interface, network delivery or execution outcome. Pass that scope on with the answer.
Record what reading the test definitions established
The related tests define partial file coverage, request failure and cancellation, changes during a review, and an earlier file changing while a later one is read. Their test client returns controlled answers or triggers file changes. These definitions target aggregation and preservation rules; they do not measure a real model’s judgment accuracy.
For this article I compared the guide, implementation and test definitions statically. I neither imported the original program nor reran its tests, and I did not check the review service’s current availability or successful response. The behavior described here belongs to the inspected code branches and test intentions.
To apply the structure, retain the question, source version, reviewed scope, unfinished reason and aggregate answer together. A candidate problem can lead to reproduction; an unknown can lead to obtaining evidence or defining the next review scope. A short yes-or-no view remains usable when the conditions for relying on it stay in the record.