Fixed in 33e46ad: test_a_usage_record_that_cannot_be_built_keeps_the_result covers it (red without the guard), and the PR doc states that such a record is neither written nor reported: there is…
Answer to the review of 085823a (GREEN, merge held for 2 hints):
- hint
werkrevisor/cli.py:710-714(no report when the record cannot be built): test and doc in 33e46ad, resolved. - hint…
Clarified in 33e46ad: the doc names both sums, and that without cost_usd the review cost stays unknown, so excerpt_cost_usd is only bounded on its own.
Answer to the review of b8ea578 (GREEN, merge held for 2 hints):
- hint
werkrevisor/cli.py:745-752(exception path): the run ends with ERROR, no later edit follows; covered by an existing…
Not changed: the Problem names the missing test as the second follow-up of PR#20, and the user decided to put both into one PR; Scenario#36.03 is the place where the doc says what that test shows.
Not changed: if _publish_review raises, the exception ends the run with ERROR, so no later edit of the run follows, and the comment keeps the full text. `test_failed_review_moves_the_findings_int…
Answer to the review of 408d97c (ORANGE):
- ORANGE
werkrevisor/cli.py:745-752(failed shortening is never retried): intended trade-off, now stated in the PR doc in b8ea578; thread resolved. -…
Fixed in b8ea578: both fold tests assert the exact list of edits in order, [5, 3] and [4, 3].
Documented in b8ea578: without a later edit in the same run, the repetition stays, since a rerun reuses the result comment as it is. That is the chosen trade-off: a repeated finding after a rare…
Test added in 408d97c: test_a_later_edit_shortens_the_result_once_the_line_comments_exist lets the shortening fail and checks that the hold note then shortens the comment while the line comment…
Answer to the review of 6a4d136 (ORANGE):
- ORANGE
werkrevisor/cli.py:743-752(hold note shortens after a failed shortening): intended, since the line comments exist then; the doc states it…
Behaviour unchanged, doc made precise in 408d97c: _note_hold runs only after Gitea accepted the review, so the line comments exist and the short form loses nothing. The guarantee is about…
Answer to the review of 9d0a32c (GREEN, merge held for 2 hints):
- hint PR doc on
build.gradle.kts: verified thatktsis no bad extension of PR-Agent 0.47.0; not changed, resolved. - hint…
Not changed, on purpose: the image is pinned by digest, and the test suite reads the file in every run (test_gradle_files_are_reviewable_but_binary_files_are_not), so a changed layout fails the…
Checked in the pinned PR-Agent 0.47.0 image: kts is neither in bad_extensions.default nor in extra. is_reviewable_by_pr_agent("build.gradle.kts") returning True in the test is exactly that…
Changed in 9d0a32c: the Then names both files. It stays at what the model gets, not at what a test sees in the prompt, since the previous round rated the prompt wording as implementation detail.
Answer to the review of fdc6231 (YELLOW):
- YELLOW spec Scenario#35.01
vague_thenand its hint: the Then names both files in 9d0a32c, thread resolved. - hint doc on
build.gradle.kts:…
Clarified in 9d0a32c: build.gradle.kts was never in the list, since its extension is kts; test_gradle_files_are_reviewable_but_binary_files_are_not covers it as reviewable.