Conversation
SonarCloud labelled every analysis "projectVersion: not provided", so the "previous version" new-code baseline had nothing to anchor to and counted the whole history as new: it reported 21800 new lines against a project of 11440. The coverage gate was therefore measuring all code, not new code, which is why 57.5% showed up against a threshold meant for freshly written lines. The scanner now reads the version out of pyproject.toml and passes it as sonar.projectVersion. This takes effect from the next release: that analysis establishes the baseline, and the one after it measures only what changed between them.
Three of the least-covered areas, chosen for being reachable headlessly rather than for being easy: each test drives the real widget with the modal dialogs stubbed to whatever the user would have answered. - The prthinker settings form: every field gets an editor, keys are echoed as dots, the backend and platform come from the supported lists, a stored value that is no longer on offer does not silently persist, and a save that fails leaves the window open rather than looking like it worked. - The project tree's right-click actions: where a new item lands, refusing to overwrite an existing name, an open editor tab following a rename and closing with a delete, absolute against tree-relative path copying, and an OSError surfacing as a dialog rather than a traceback. - The plugin and "Run with" menus: entries built from a supplied registry rather than whatever is installed, sorted and labelled by suffix, and the suffix mismatch that must warn instead of running the wrong compiler. 64 new tests, 937 total. Coverage 57% to 60%: the settings dialog reaches 100%, editor_main 20% to 58%, menu 40% to 54%.
judge, judge_single_review and step_by_step_analysis were never imported: 217
lines of prompt that no chain ran and the editor did not even offer. They are
now steps in the chain, placed where their inputs exist.
first_summary -> first_code_review -> judge_single_review
-> linter -> code_smell_detector -> step_by_step_analysis
-> total_summary -> judge
judge_single_review scores the review written just before it. step_by_step
walks each lint message and code smell through cause, impact and fix. judge
scores the finished summary with the findings it was meant to cover in hand,
which needed the total summary's answer kept rather than discarded.
Eight steps would have taken the match statement in _run_templates past the
complexity the project allows, so the wiring moves into cot_chain: two tables
saying where each answer is stored and which placeholder each fills. The order
is now a dependency order a test can check, rather than a sequence held in one
function's local variables.
Two behaviours change with it. A step whose input never ran quotes an empty
section instead of the literal word "None". A step that fails is still shown to
the user but no longer stored, so a later step cannot quote "could not send"
back to the model as if it were a review.
The prompt editors wrote .md files that nothing ever read: a review always sent the template compiled into the source tree, so editing a prompt changed nothing. The editor existed to adjust what a review asks, and did not. prompt_store resolves a prompt to the file the editor writes, falling back to the built-in constant. The files move from the working directory to ~/.pybreeze/prompts/, beside the SSH known hosts and the prthinker settings, so the prompts someone has written are the same whichever folder the IDE was started from; both editors now show that path. Nothing is orphaned by the move -- no prompt file existed anywhere yet. A missing, empty or unreadable file falls back to the built-in, and so does an edited prompt naming a placeholder the chain cannot fill: a KeyError there would take down a review the user has no way to debug from the UI. Reading a prompt no longer creates the directory, so a session that only looks at built-ins leaves nothing behind. The skill selector in the send window was connected to nothing at all -- picking a template did not load it. It now loads the chosen prompt, edited version first.
The CoT and Skill editors were the same 157 lines each, differing only in which
templates they list and which language keys label them. Loading the selected
file, creating it from its built-in template, saving, and picking up an external
edit were all written out twice, so a fix to one of them was a fix to half the
editors.
PromptEditorWidget holds that behaviour; each editor is now the file list, the
templates and a PromptEditorLabels of its language keys. 314 lines become 233.
The keys stay literal strings at the subclass rather than being built from a
prefix, because the parity test finds keys by reading the source for
language_word_dict.get("..."). A prefix would have slipped past it, so the keys
are declared plainly and a new test walks the two label sets directly -- a
renamed key is still caught rather than showing up as a blank button.
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | 10 |
| Duplication | -6 |
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



Five commits on
dev, all verified green across Python 3.10–3.14.The prompt editors now change what a review sends
The editors wrote
.mdfiles that nothing read — a review always sent thetemplate compiled into the source tree, so editing a prompt changed nothing.
prompt_storeresolves a prompt to the file the editor writes, falling back tothe built-in constant, and the files move to
~/.pybreeze/prompts/so they nolonger depend on which folder the IDE was started from. Nothing is orphaned by
the move: no prompt file existed anywhere yet.
A missing, empty or unreadable file falls back to the built-in, and so does an
edited prompt naming a placeholder the chain cannot fill — a
KeyErrortherewould take down a review the user cannot debug from the UI. Reading a prompt no
longer creates the directory.
The skill selector in the send window was connected to nothing at all; picking a
template did not load it. It now does.
Three prompt templates that were never run
judge,judge_single_reviewandstep_by_step_analysiswere never imported.They are now steps in the chain, placed where their inputs exist:
Eight steps would have taken
_run_templatespast the complexity the projectallows, so the wiring moves into
cot_chain: two tables saying where each answeris stored and which placeholder each fills. The order is now a dependency order a
test can check. A step that fails is shown to the user but no longer stored, so a
later step cannot quote "could not send" back as if it were a review.
Coverage and cleanup
Tests for the prthinker settings dialog (28% to 100%), the project tree's
right-click actions (20% to 58%) and the plugin menus (40% to 54%). The two
prompt editors were the same 157 lines each and are now one shared widget plus
two declarations, 314 lines down to 233.
SonarCloud analyses now carry
sonar.projectVersion. Without it the "previousversion" new-code baseline had nothing to anchor to and counted the whole history
as new — it reported 21800 new lines against a project of 11440. This release
establishes the baseline; the one after it measures only what changed between
them.
Tests: 873 to 985.