Release Notes

What changed in each release of the SpecBinder IntelliJ plugin. Each version links to its page on the JetBrains Marketplace.

Release notes for the framework itself live under Docs → Release Notes.

2026.19.0

October 5, 2026Latest

Added

The Execution Report now shows a Background step's data table or doc string under each scenario's copy of the step, the same way a scenario's own steps show theirs; each copied row links back to the matching row of the Background.
A Feature or Background title, a description line, a tag line or a Background step that you have just edited stops being linked in the Test Code pane until the class is generated again — the Java beside it was written from the old words — while the lines around it stay linked.
With the caret in the Test Code pane on the comment the generated class writes above a step's call, the step it repeats is framed in the spec — and each repeated table row frames its row; the comment above an Examples block's values frames that Examples line, and each tag inside a block of several tags frames the spec line that tag was written on. A caret on the step or tag line itself still frames only its call or annotation.
In the Project view, a spec that has not run yet — or has changed since its run — now shows its own icon: a small play triangle in the green of the IDE's run button, in place of the right chevron, and folders containing such a spec show a green ▹. The grey icon now means only that a scenario was aborted, so a spec waiting to be run is no longer mistaken for one that stopped short.
A Refresh SpecBinder Status action in the Project view's context menu brings spec file icons and folder chevrons up to date on demand. Chosen on a spec file it reads that spec's latest results again; chosen on a folder it does the same for every spec file beneath it. It is offered while either the spec file icons or the folder chevrons are turned on.
With the caret in the Test Code pane, a step method used in several places now frames the use nearest the spec editor's caret, or the one after it when two are as near. A step's call or step method always frames the step itself, never a row of its table or a line of its doc string.
The Test Code pane now links a Scenario Outline's Examples to the parameterised test they became: each Examples keyword is framed against its own source annotation, and each row of the table against the same row in that annotation's list of values.
The Test Code pane now links a step's data table and doc string line by line: each table row is framed against the line that builds it in the generated class, and each line of a doc string against the same line of the text block it became.
The Test Code pane now links a Background to the set-up method it was generated as, and a tag line to the tag annotation it became on the generated class or method.
The Test Code pane now links each Rule to the nested class it was generated as: with the caret on a Rule's title, the title is framed against that class's declaration.
The Test Code pane now links each line of a Feature's, a Rule's, a Scenario's or a Background's description to the same line of it in the generated class, in either direction — whether the description was written as Javadoc, the default, or as a @Description annotation. A Scenario Outline's description links the same way, and each line of an Examples block's description links to the same line of the comment above that block's values.
A spec file's icon in the Project view, and the chevron on its folder, now show the results of the last test run made in the IDE when no SpecBinder execution report is on disk, as the spec's gutter already did. The icon updates once the run finishes, and a scenario that has not run since it was added or changed keeps the file at no result.
The test methods of a class SpecBinder generates as abstract now show the result of the last run in the gutter, as any other JUnit test does. The run goes through the class that extends it, so the icons were left as plain run buttons before; a Rule's group shows the worst result beneath it, and where several classes extend the same generated class, a failure in any of them shows.
The colour of the lines linked across the split view can now be set separately for light and dark IDE themes. The Split view settings page has a picker for each, and the highlight follows whichever theme the IDE is using, so it can stay readable against a dark background without washing out on a light one.
The Execution Report now carries a tab per run, each named after the test class that made it and marked with how that run came out. A spec run by more than one class keeps a set of results per class, so the tabs are how you move between them; the pane opens on the most recent run and comes back to whichever one you left it on
Failed steps are now marked in the gutter, and their inline error panel opened, for runs made without the SpecBinder execution reporter too. With no report on disk the plugin reads what the IDE itself recorded for the last run: which step failed, its message, the whole stack trace while the IDE still holds that run's output, and the Expected / Actual values when the failure carried them — with the same Approve and Show diff buttons a reported failure offers.
The status icons the gutter and the spec file's toolbar wear can now be picked between two sets on the Execution results settings page: JUnit-style circles, modelled on the badges the IDE shows beside JUnit tests and used unless another set is picked, or SpecBinder chevrons, which match the spec file's own icon in the Project view. Each set is shown with its own icons beside its name, so the choice is made against the icons themselves, with a line under each saying when it reads better.
A file shown in the Test Code pane now carries the IDE's own notices above it — the warning that a generated source will be overwritten among them — set off from the code the way they are in the file's own editor tab.
The Split view settings page now shows the buttons a spec file's editor puts in its top-right corner: what each of the three view buttons puts on screen, and the button each tab adds to that row once it is turned on.
Inline doc-string previews can now be turned off. A switch on the Editor settings page decides whether an HTML, SVG or image doc string can be shown as a picture below its text; with it off no preview icon is offered and those doc strings read as plain text.
Each tab on the Test Code pane now carries the IDE's own icon for its file, so a class, an interface and an abstract class are told apart at a glance.
The Test Code pane no longer scrolls in step with the spec, and its synchronize-scrolling toggle has gone with it — following the caret already brings the right method up. The Execution Report keeps its own synchronised scrolling.
The Test Code pane no longer marks the method a step resolved to with a highlighted line; the frames on both sides already say which pair belongs together. The Step Implementation tool window keeps its mark.
The Test Code pane's own controls now keep their place however narrow the pane is, and a file tab that no longer fits is reached from the chevron at the end of the row.
An Example you have just edited stops being linked to its generated method, while the Examples around it stay linked — the method came from wording that has since changed, so the link would point at the wrong place. It goes as you type and comes back once the spec matches the generated class again.
The Test Code pane now frames the spec line you are on against the Java it pairs with, and the two scroll together. A generated class pairs at every level the spec has, while a hand-written test or a shared base pairs steps with the methods that implement them. Each view carries its own toggles, so turning the frames off while reading results leaves them on while reading code.
The Test Code pane can follow the caret. A toggle on its banner, off until turned on, opens whichever class implements the step you are reading and scrolls to that method, so moving down a spec shows each step's code as you reach it.
Each tab a spec file can show beside it now has a switch of its own on the Split view settings page — one for the Execution Report, one for Test Code. Turning a tab off takes its button away rather than leaving a view that could only ever be empty, and with every tab off spec files open in the platform's standard text editor. Test Code is on out of the box; the Execution Report stays off until turned on, and a choice made in an earlier build is carried over.
The pane beside a spec file can now hold a second document, Test Code: the Java the spec compiles to and is wired by, opened with a button of its own. It offers one tab per class behind the spec, each the IDE's own editor, so highlighting, completion and refactoring work there exactly as they would in the file's own tab. A spec with nothing generated for it yet says so rather than showing an empty pane.
The Execution Report now has a button of its own in the top-right of the spec file's tab, saying what the right-hand pane is showing while the view-mode buttons go on deciding whether it is open. Clicking it while the spec file is on its own opens the pane beside it, and each file remembers the document it was last left showing.
Failed steps are now marked down the Execution Report's scrollbar, one mark each, so a long report shows how many failures it holds and where they are without being scrolled through. Hovering a mark names the step.
SpecBinder's settings can now be found from the Settings search box. Typing "SpecBinder", or the name of an option on one of its pages, brings up the matching page, along with the plugin's inspections and colour entries.
The wording a user story is written with is now coloured apart from the rest of a Feature's title and description — who it is for, what they want and why — each with its own colour under Settings > Editor > Color Scheme > Gherkin, so a story's role, capability and benefit can be told apart at a glance or left looking alike. Only a Feature's own title and description are read this way.
A step suggestion now says when the step wants a doc string or a data table, and picking it lays the block out for you: empty doc-string fences, or a table headed with the step's own column names, indented below the step with the caret waiting in place.
Step suggestions now spell the pronoun as "I" rather than "i", the way a spec file spells it. Only the pronoun standing alone is changed.
The Run icon beside an Examples row now runs just that row, so re-checking one row leaves the other rows' results alone. Under Gradle a row still runs the whole outline, whose test filter cannot name a single row.
A vertical rule now marks the boundary between a spec file and the pane beside it, matching the line the IDE draws between any two editors it puts side by side.

Changed

The Reload link on the Execution Report's banner now sits straight after the run's time instead of at the far right of the banner, so it reads together with the time it offers to replace.
In the split view, a divider now separates the tabs at the top right of the Execution Report and the Test Code pane from the buttons beside them. It is drawn like the divider between the IDE's own view buttons, so the run or class names no longer read as more buttons.
Text matched by a stripPatterns entry is now plum in the light scheme and pink plum in Darcula, while the two markers of a stripBetweenPatterns range keep vermilion and salmon. The two strip text in different ways, so they now look different out of the box rather than only once you choose colours for them yourself.
The Execution Report no longer links a scenario whose steps have changed since the run — reworded, given a different table, or run after a Background step that has changed — since its rows were recorded from steps the spec no longer has. A Scenario Outline whose template has changed links to nothing either, and an Examples row whose values have changed stops linking to the example run with its old values, while the other rows stay linked. Extra spacing between words does not count as a change. A scenario added since the run, or one the spec has since dropped, links to nothing either, while the scenarios around it stay linked.
The Execution Report now links line by line. A Feature, Rule or Scenario title is framed against its heading in the report alone, each description line against the same line of the description the report shows, and a step with a data table or doc string against its own step row, with each table row and doc-string line framed against the same row or line beneath it — in either direction. A Scenario Outline's title, description and template steps link the same way, each to its own line of the template the report rebuilds. A blank line, a comment or a tag, which the report leaves out, is no longer framed against the nearest line above it, and the lines after it still find their own rows.
The scenario counts on a spec file's toolbar now follow an edit as soon as you pause typing, without waiting for the file to be saved, so they always agree with the gutter icons beside them. A scenario you change — by typing, or by approving a failed step's actual value — moves to not executed in both at once. The Project view still updates its icons when the file is saved.
In the Test Code pane, a step is now framed against the line declaring the method that implements it, rather than the whole method, when a hand-written test class is shown.
In the Test Code pane, a Scenario's title is now framed against the line declaring its generated test method rather than the Scenario and the whole method being framed as one block, matching how a Feature and a Rule are linked; the steps inside a Scenario keep their own links to their calls.
On the Split view settings page, the light- and dark-theme pickers for the linked-ranges colour now sit side by side on one line, under a bold "Linked-ranges colour" heading.
The legend for the agent status badges on the Agent integration settings page now shows each badge on a spec file's icon, with the diamond between the chevrons as it appears in the Project view, rather than the diamond on its own.
The Run and Debug entries offered from a spec file's gutter now name the Feature, Rule or Scenario by its title in the spec, rather than by the generated test class or method (scenario_2, CartFeatureTest$Rule_1). A row of an Examples table is named after its outline with the row's number. Where two parts of one spec share a title, the name also carries the line it starts on, so each keeps a run configuration of its own. Run configurations saved before this change are renamed the first time the gutter reuses them, unless they were given a name by hand.
The explanations on the SpecBinder settings pages have been reworded to name what they refer to rather than address the reader or point back with "it" and "its". On the Split view page, each tab's option now opens with a line saying what that tab shows, the preview of its toolbar button comes before the note about where that button appears, and the Execution Report's extra-data options open with a short paragraph explaining the inline panels they control.
The time a run finished has moved off the toolbar into a banner over the Execution Report itself. A spec run by more than one test class has a time apiece, so the banner belongs to the run on screen and changes with the tab you pick. The Reload link that offers a newer run sits there too, and Alt+clicking the banner still opens the run's JSON report file.
⚠️ BREAKING: A spec's execution results are now found by following the spec to the test classes that run it, matching how SpecBinder names each report after the class rather than the spec file. A spec run by more than one test class keeps a set of results for each instead of the last run replacing the others, and the gutter, Project view and toolbar follow the most recent run. Results written by an older SpecBinder are no longer found and are replaced on the next run
When the Execution Report pane has no rows to show because something went wrong, what went wrong is now shown under the message in the pane itself rather than offered only on hover. A report that could not be read names the parser's reason and the file to fix; a pane that could not be built names its reason. Long text wraps to the width of the pane instead of running off its edge.
⚠️ BREAKING: Execution results are now read from the execution report whenever one exists for a spec file, and from the IDE's own last-test-run state when none does — there is nothing to turn on, and the option that decided it is gone. A spec file with no report yet shows the IDE's own run and status icons rather than reading as not executed.
⚠️ BREAKING: A step recorded as failed now always carries its error icon, and clicking it always opens the inline error panel; the option that turned both off is gone. The panel's own options — the Expected / Actual previews and the project-code stack-trace frames — now stand on their own instead of being greyed out until that option was on.
⚠️ BREAKING: One Show Expected / Actual previews option now covers the HTML, image and SVG previews in the inline error panel, replacing the three per-kind options. If you had turned all three off, the previews stay off; otherwise they are on, as before.
The project-code stack-trace frames' font style and colour now sit together on one row under a single heading on the Execution results settings page, since they shape the same lines.
The Failed-step error panel section of the Execution results settings page now shows the failed-step icons within its explanation, level with the words around them, rather than on a line of their own, and lists its options as project-code frames, then Expected / Actual previews.
The colour setting for the bar down the side of the published-entries panels is now called "Published test reporter entries bar colour". The colour it sets is unchanged.
The status counts above a spec file now count each row of a Scenario Outline's Examples table as a scenario of its own, since the rows are what actually run and what the gutter marks one by one. A partly-run outline no longer reads as fully passed, and clicking a count steps onto the individual row rather than the heading above it.
Execution results now tell apart how a scenario went wrong, the way the IDE's own test results do. A scenario whose assertion did not hold is marked failed in amber, one stopped by any other exception is marked error in red, and one that aborted is marked aborted in grey. A scenario with no current result — never run, skipped, or changed since its run — shows the IDE's run icon. Both icon sets follow the same meanings, a Rule or Feature shows the worst result beneath it (error, then failed, then aborted), and hovering the icon names the step it stopped at, with the exception for an error.
The status counts above a spec file now have one count per result — passed, error, failed, aborted and not executed — in that order, each stepping through only its own scenarios. The run tabs over the Execution Report are marked with the worst result of their run.
The Execution Report pane now draws its status icons in the icon set picked on the Execution results settings page, as the gutter and the toolbar do.
Spec file icons and folder chevrons in the Project view now show an error in red apart from a failed assertion in amber. A spec with nothing to report — not yet run, changed since the run, aborted, or with no generated test class — shows a single grey marker.
The icon beside a failed step now says how the step went wrong, matching the icon of the scenario it belongs to: amber with a cross for an assertion that did not hold, red with an exclamation mark for any other exception, and the grey aborted mark for a step that aborted. The bar down the side of its inline error panel, and its mark on the scrollbar, take the same colour. Results the IDE recorded without the SpecBinder execution reporter tell an assertion failure from an error the same way, and a step that aborted its scenario now carries the aborted mark too while the IDE still holds that run's output.
Everything that acts on the pane beside a spec file has moved onto the toolbar over that pane, and the notice strips those controls used to sit on are gone. Each half of the row is as wide as the pane under it, so dragging the divider narrower crowds only that side — what no longer fits is reached from a chevron at the end of that half. The panes gained the height the strips were using.
⚠️ BREAKING: The toolbar above a spec file can no longer be turned off, and the option that turned it off has gone from the Editor settings page: everything the row carries, including the tabs beside the spec, is reached from it and nowhere else. A recognized spec file therefore always opens in SpecBinder's editor; with every tab turned off it opens on its own.
⚠️ BREAKING: The frames that pair a spec line with the line it matches are now one setting for the pane rather than one per tab, so the toggle reads the same whichever tab is on screen. If you had the frames off for one tab and on for the other, they are on for both now.
A Test Code file tab whose class comes from a compiled dependency now carries a mark on its icon, so a tab that will open decompiled code says so before it is clicked.
Where there is no report time to show, the toolbar now says so in a short label — "No execution report", "Report unreadable", "Cannot display" — with the full explanation and the cause on hover.
The Project view settings page now leads with File structure, and the Execution status options follow below the divider. Each option's explanation now reads as regular text, and the plain spec file icon is shown beside the note on what the files look like with status icons turned off. The options, and their defaults, are unchanged.
The heavier-chevrons option no longer carries a legend row or a hint of its own. Selecting it redraws the chevrons already previewed above it, so the page shows what the option does as it is used rather than describing it twice.
The options for the published JUnit TestReporter entries — the entries themselves, their Playwright traces and the colour of their bar — have moved to the Split view page, nested under the switch for the Execution Report, and are greyed out while it is off. What each option does, and its default, are unchanged.
⚠️ BREAKING: Folding doc strings when a spec file opens is now one option rather than seven per content type. It starts off, so a spec file opens with every doc string expanded until it is turned on.
The Execution Report switch on the Split view settings page now says where the report comes from: it is written during a run by the SpecBinder Execution Reporter, a JUnit 5 extension shipped separately that has to be added as a test dependency. Turning the switch on used to be the only instruction on the page, leaving a tab that stays empty until a run records something.
The two dropdowns on the General settings page explain themselves more briefly, keeping the per-option lines and dropping the paragraph above them. The spell-checking hint now also says where spelling is not checked: tags, outline parameter names, and the cells of data tables and Examples tables.
The two options that colour the project tree by the last run's result have moved from Execution results to the Project view page, under a new Execution status section. What they do, and their defaults, are unchanged.
The settings for what a spec file can show beside it now have a page of their own, Split view, sitting after Editor: a switch for each tab, and the colour of the ranges linked across the divider. Execution results now covers only what a report drives.
The option that shows a spec file's Feature, Rule, Scenario, Background and Example elements in the Project view tree now has a page of its own, Project view, rather than sitting among the options about how spec files are treated on disk. The option, its default and what it does are unchanged.
The first page under Settings > Tools > SpecBinder is now called General rather than File handling. Its place in the tree and everything on it are unchanged.
The button that launches an AI agent for a spec file has moved to the far right of the spec file's toolbar, behind a divider, so it sits apart from the controls that act on the spec file itself. The divider is only drawn while the button is there.
The Execution Report's controls have all moved onto its notice strip, and the report's own toolbar is gone. Synchronised scrolling and linked-range highlighting appear only while the report is beside the spec file, since neither means anything when the report is on its own.
The colour of the linked ranges is now set in Settings > Tools > SpecBinder > Execution results instead of from a dropdown on the toolbar button, which is a plain on/off toggle now. Changing the colour still recolours every open spec file straight away.
The button that shows published reporter entries has moved from the Execution Report's toolbar onto its notice strip, beside the line-numbers toggle, since both act on what the report shows rather than on the run it describes. Nothing about the entries themselves changes.
The spec file keeps its line numbers on the left when the Execution Report is beside it. They used to move across to face the report, which left the traffic-light tick above the scrollbar flickering between the two top corners.
The toolbar is a single row across the top of the tab again, carrying only what acts on the spec file, and it is hidden while the Execution Report is showing on its own. Everything that acts on the report lives on that view's own notice strip instead.
When an execution report was last updated is shown on a notice strip at the top of the Execution Report view, beside the results it describes. Once a newer report is written, a Reload link appears next to the time.
Misspelled words in a spec file now have a colour of their own, under "Other > typo" in Settings > Editor > Color Scheme > Gherkin. They are a red dotted underline out of the box, in place of the green wave every language shares — which all but disappeared under a Feature, Rule or Scenario title coloured green itself — and can be recoloured without touching how typos look in any other language. The words that are checked, the suggestions offered on one, and adding a word to the dictionary are all unchanged.
The three revision-markup entries under Settings > Editor > Color Scheme > Gherkin now sit with the typo entry under an "Other" heading, and are named after the options they come from. The colours themselves are unchanged, and a colour already set against one of them is kept.
The preview on the Gherkin colour settings page now includes revision markup, so selecting a strip-pattern entry has something to scroll to and blink.
A parameter in a step suggestion is now written in quotes, as "{item}" rather than {item}. The quotes are what a spec file reads a parameter by, so a suggestion that left them out wrote a step its step method no longer answered to.
Each step suggestion now reads as the step text, with the class or interface holding the step method shown to the right of it. The method name and the icon beside the text are gone, so the suggestion is exactly what will be written into the spec file.
The colour chooser opened from a panel's "Panel bar colour" swatch now previews the colour on the open panels as you pick it, so it can be judged against the panels themselves. Cancelling puts back the colour that was in use before.
The inline error panel's display options now live in Settings > Tools > SpecBinder > Execution results, nested under the switch that offers the panel. Applying a change redraws any error panel that is already open.
The colour of the bar down the left edge of image, HTML and SVG doc-string previews is now set in Settings > Tools > SpecBinder > Editor, under "Doc-string previews". Applying a new colour redraws any preview that is already open.
⚠️ BREAKING: Published reporter entries and Playwright trace panels now open only in the Execution Report view, no longer under the steps of the spec file you are editing. The button that shows them is offered only while that view is on screen.
The colour of the bar down the left edge of published-entries and Playwright trace panels is now set in Settings > Tools > SpecBinder > Execution results, instead of from the toolbar button's dropdown, which is gone. Applying a new colour redraws the panels that are already open.
When an execution report was last updated is now shown at the top of the Execution Report view itself rather than at the right end of the spec file's toolbar. The date is labelled, so it no longer has to be read as a bare time out of context, and the Auto-reload checkbox and Reload link sit beside it.
The status lozenges and gutter icons beside a spec file now move to the newest execution report on their own as soon as a run writes one. Auto-reload governs only what the Execution Report view renders, so with it off the view stays on the run you were reading and says "Showing an earlier run" until Reload is clicked.
An Execution Report with no report in it is now empty all the way across. It kept an editor's gutter so the pane had a visible edge; the rule down the divider gives it one, so the gutter is gone.
An Execution Report with nothing to show now says why across the middle of the pane, the way the Test Code view says it has no test code, instead of in small type on the toolbar. It distinguishes a spec that was never run from a report that could not be read and from one that could not be displayed, with the cause on hover. The toolbar now carries only the time a report was last updated.

Fixed

The Execution Report pane now fills each Scenario Outline Example's steps with that row's values instead of showing the <placeholder> names, and colours each filled-in value like a step parameter.
With the Test Code pane following the caret, putting the caret on a description line now frames that line and its line of the Javadoc, and the pane scrolls to that Javadoc line. Before, the frames jumped to the Feature title and the class declaration, because the pane scrolling itself was read as if you had clicked into it.
A test run started while the IDE was still indexing — common right after a build — is no longer treated as one the plugin did not see: editing a scenario afterwards now shows it as not executed instead of keeping its old result. Spec file icons and folder chevrons in the Project view also catch up as soon as indexing finishes, rather than staying at a status worked out while it was still running.
The Run icon beside an Examples row now runs just that row even after the whole spec has been run, and its menu offers that row's own run. Before, it reused the spec's run configuration and ran every scenario, and the menu offered to run the whole spec. A row of an outline generated as an abstract class now runs through the class that extends it.
Running an Examples row of a Scenario Outline from the Run tool window now runs just that row, and running the outline's own node runs all its rows. Before, both failed to start, with JUnit reporting that the selected test could not be resolved.
Folder chevrons in the Project view now update after a save, a finished run or a build when they are turned on without the spec file icons. Before, they kept their first status until the IDE was restarted.
Opening an Examples row of a Scenario Outline from the Run tool window now goes to that row's line in its Examples table. Before, every row opened the Scenario Outline line.
With no execution report on disk, each Examples row of a Scenario Outline now shows its own result in the gutter, and the outline shows the worst of its rows. Before, every row showed only a run icon and the outline showed whichever row happened to run last, so a failing row could leave the outline marked passed. The toolbar counts each row too, and a row added or changed since the run shows as not executed.
A spec file's icon in the Project view now changes as soon as its status is refreshed — after a save, a finished run, a build or Refresh SpecBinder Status. Before, the folder chevron above it could already show the new result while the file kept its old icon, and an open editor tab could keep its old icon too.
With no execution report on disk, a scenario that has passed no longer shows the run icon as if it had been changed since its run when another module in the project generates a test class of the same name from different content. Its Rule and Feature no longer show the run icon on its account either.
With no execution report on disk, a Feature or Rule now shows as not executed in the gutter when one of its scenarios has not been run since it was added or renamed, instead of showing the passed result of the earlier run. A failure or error elsewhere in it still shows first.
Running a scenario from its gutter icon now runs that scenario when another scenario in the spec has the same title. The IDE used to pick up the run configuration of the first such scenario and offer to run it instead.
Double-clicking a failed or aborted scenario in the Run tool window now opens its line in the spec file, as it already did for a passed one, rather than the line in the generated Java test code where it stopped. Rerun Failed Tests keeps working for those scenarios.
Double-clicking the top node of a run of one test class in the Run tool window now opens the Feature line of its spec file, like every node beneath it, rather than the Java test class.
With no execution report on disk, a scenario edited since it was last run from the IDE now shows as not executed in the gutter and the count lozenges, instead of keeping the result recorded for its old wording; putting the wording back restores that result. The failed-step icon of such a scenario goes too, along with its inline error panel if it was open, and the icon comes back once the wording is put back. Results from runs made before this version, outside the IDE, or of test classes generated without scenario hashes keep showing as before.
A failed run made without the SpecBinder execution reporter now marks the failed step, and opens its inline error panel, for specs generated as an abstract class too, not only for those generated as a concrete one. The step can be found for as long as the IDE keeps that run's output. A failed comparison of Expected and Actual values now also shows its whole stack trace in that panel, not just its top line.
The button that highlights matching lines no longer shows while the pane beside the spec has nothing to link to — an Execution Report with no report loaded, or Test Code for a spec with nothing generated yet. The follow-caret toggle likewise stays hidden until Test Code has a class to show. Both appear once there is something in the pane.
Moving the caret or switching focus in a spec file shown beside its Execution Report or Test Code no longer holds up the editor while the plugin searches the project for what the line pairs with. The search now runs in the background, so the linked-range frame can appear a moment later, and the IDE no longer fills its error log with slow-operation reports that eventually stopped it reporting errors at all.
A colour picker on the settings pages no longer goes blank when the option it belongs to is turned off. It keeps showing the chosen colour, faded and with its code greyed out, so you can still see which colour is set while it cannot be changed.
The visual diff viewer's Clear highlight link now shows the not-allowed pointer while it is unavailable, as the dimmed wording already implied. The shape was asked for but never reached the screen, because the link stopped responding to the pointer at the same time.
The visual diff viewer's Clear highlight link now tells a screen reader it is available once it becomes clickable. It went on reporting itself as unavailable after the first difference was highlighted, so it was announced as dimmed while it could be used.
Collapsing a Scenario or a Rule now hides the error icons of the failed steps it hides. Until now the icon of a failure on the block's very last line stayed behind, drawn against the collapsed heading row, so whether a folded block kept showing an error came down to which of its steps had failed
A spec implemented by more than one test class can now be run. Running it asks which of them to run and launches that one, instead of reporting "No tests were found" — the run was targeting the generated class the tests extend, which cannot be run on its own. Dismissing the question runs nothing.
Running a spec now runs it, in projects where two modules hold spec files of the same name. The Run icon found the right generated class but then looked up the runnable test class by name across the whole project, landing in whichever module came first — so the run either tested a different module or reported "No tests were found". The status icons and counts read from the same lookup, so they could show a sibling module's results too.
The Test Code pane no longer throws when the class it is showing is rebuilt underneath it. Running a build while a spec file is open replaces the generated source, and the pane went on holding the file the build had already discarded — reporting an invalid-file error on the next caret move. It now waits for the replacement instead
The Execution Report pane no longer fails to display with an "Integer.intValue()" error for a spec holding a Scenario Outline. It happened when an example row recorded in the report could not be matched to a row of the Examples table in the editor and the run had recorded no line numbers — the pane gave up entirely instead of simply leaving that row unlinked
The Execution Report pane no longer shows a blank first row while there is no report to show. Beneath the banner saying there is no report, the pane is now simply empty, rather than drawing a line and a cursor that read as a run with an empty result.
The toggles on the Execution Report's banner are no longer offered while there is no report, since each of them changes how rows that are not on screen would read. They come back with the report.
The dropdown that picks which file extensions SpecBinder recognizes no longer cuts its own text short — ".feature and .specb" was drawn as ".feature...d .specb".
In the Execution Report, the rows of a recorded Rule now point back at the Rule that actually ran them. Once a Rule had been added or removed since the run, clicking a row highlighted whichever Rule had taken that position in the spec file, and the wrong Rule's background steps were inlined under the scenario.
A Rule left holding no scenarios now reads as not executed, and so does the Feature above it. Such a Rule is still run as a unit of its own, so a file could report as fully passed while one of the units under it had never run.
Adding, removing or retitling a Rule no longer costs every Rule below it the results of its last run. A recorded result is now recognised by the steps the scenario ran, wherever it has ended up in the file, so a scenario keeps its result when it moves between Rules and only genuinely new or edited scenarios read as not executed.
Everything that connects a spec file to its generated test code now goes quiet, instead of reporting an internal error, when the IDE cannot resolve Java for the project. The gutter Run icons, the toolbar's run button, navigation, step completion, Find Usages and the report's failure panels simply offer nothing, the way they do for a spec with nothing generated for it, and all of it comes back on its own once the project resolves again.
A spec file now opens even when the IDE cannot work out the Java version the project is written in, rather than leaving no way to read or edit the spec until the project itself is fixed. Should the results pane fail for any other reason, it is left empty and says so instead of taking the spec file with it.
Analysing a spec file no longer reports an internal error when indexing begins while the file is being checked. Typos, and the fixes offered on them, are unchanged.
Opening a spec file no longer reports an internal error on newer IDE versions. The editor's view buttons themselves are unchanged.
Find Usages on a step method, and renaming one, now stay within the module the generated test class belongs to. In a project whose modules keep their specs under the same relative path, they could list — or rewrite — steps belonging to another module's spec.
The Run menu offered by a scenario's gutter icon no longer writes an empty pair of brackets after the name: it reads "Run 'scenario_1'". What the entries do is unchanged.
A run started from a test method that carries no display name is now named after the method alone, without the empty pair of brackets that used to follow it. A method that does carry a display name is named by it, as before.
The Run icon beside an Examples row now appears whether or not gutter icons are driven by the execution report, and whether or not that row has ever run. The row naming the columns still carries none, since it stands for nothing to run.
Running a single Rule, or a single scenario inside one, no longer runs the same-numbered Rule in every other spec file of that package. The same correction applies when the failed tests of an earlier run are re-run.
The keyword suggestion list now opens under the first character of the keyword being written, wherever the line is indented to, instead of drifting further right the more you type. Picking a suggestion replaces the characters written so far rather than adding the keyword after them.
The step suggestion list now opens under the first character of the step text, wherever the caret stands within it, instead of being thrown left by the length of the whole step. Only the text written up to the caret decides where the list opens and what the suggestions are matched against.
Ctrl/Cmd+Click in a generated test class now opens the spec file of that class's own module, instead of a same-named spec in whichever module happened to be searched first. The same applies to Shift+Ctrl/Cmd+Click on a step method call and to the spec file the debugger highlights while stepping through a test.
The Run icon in a spec file now runs the tests generated for that file's own module. Where several modules each hold a spec of the same name, clicking a Feature keyword quietly ran a neighbouring module's tests, while clicking a Rule, a scenario or an Examples row offered nothing at all. The gutter status icons and the toolbar counts read the same way.
Step completion no longer offers steps from unrelated spec files. Only the generated class belonging to the open file, in the same module, contributes suggestions, so the list is limited to the steps the tests for that file can actually call.
Ctrl/Cmd+Click from a spec file now goes straight to the generated test class of that file's own module, instead of offering a list of identically named classes, one per module, to pick from. Navigation from a step behaves the same way.
Revision markup is now highlighted when the strip patterns are shared as constants rather than written out as string literals in each marker class. The editor used to behave as though no patterns were configured — markup painted as ordinary spec text, no navigation, Find Usages, completion or rename from a marked-up step, and recorded run status not matching — while the build stripped the markers correctly.
Re-running a single scenario no longer strips the status from every other scenario in the file. Each scenario keeps the result of its own last run, including scenarios inside a Rule and scenarios that have moved.
A result recorded for one scenario could be shown against a different scenario that happened to have identical steps. The scenario that actually ran now gets its result, and the other reads as not executed.
After re-running a single scenario, clicking a status lozenge on the editor toolbar could jump to the wrong scenario. Each scenario is now counted and navigated to from its own result.
In the split editor, clicking a scenario's row in the Execution Report pane could highlight and scroll to a different scenario after a single-scenario re-run. Highlighting and scroll-sync now follow the right one.
A spec file's icon in the Project view could show as passed when only part of the file had run. It now reads not executed until every scenario has a result of its own.
Undoing an edit brings a scenario's recorded status back, instead of leaving it not executed until the next run.
An Examples row edited since the run now reads as not executed, the same as a row that never ran, instead of showing the plain run icon.
A scenario wrapped in removal markup no longer holds its whole file at not executed. SpecBinder generates nothing for such a scenario, so no run could ever clear it — leaving a grey Feature line, a grey file and folder in the Project view, and a not-executed lozenge nothing could shift. Only the scenarios SpecBinder actually generates now count towards the status above them and towards the toolbar counts; the removed scenario still shows as not executed on its own line.
The time shown in the editor toolbar's report section no longer claims more than it can. A report can hold results from several runs, so it now reads as when the report was last updated rather than when it was generated.
An Examples row of a Scenario Outline could show the result of a neighbouring row. Each row is now matched to its result by its own values, so re-running one row leaves the others alone and reordering the table carries every row's status with it.
A scenario headed Example: or Scenario Template: is no longer invisible to the features that pair it with its generated test. Its gutter Run icon opened an empty "Nothing here" popup, its recorded status was blank in the gutter and on the toolbar, Find Usages left out its steps, and navigation from a step method call would not open it.
One panel that cannot be reopened no longer costs you the others: a panel that fails to come back is skipped and the rest are reopened as usual.
The plugin no longer installs its "Auto-select terminal tab" hook when the bundled Terminal plugin is turned off.
The IDE's warning over a generated class now looks the same in the Test Code view as it does in an ordinary editor tab. It was drawn without the framing the current theme gives it, and sat on a grey the editor never uses, so it read as a fainter, unfamiliar strip beside the one the same file gets in a normal tab.
The selected file tab in the Test Code view now takes the colour the IDE gives a selected editor tab. It was reading only the look-and-feel's value and showing grey, ignoring the colour scheme's own answer, which is what an editor tab uses first.
The Test Code view no longer stays empty for a spec opened while the IDE is still indexing. Java cannot be resolved from a half-built index, and that answer was kept for the rest of the session; the view now asks again as soon as indexing finishes. The gutter Run icon and the status counts were held the same way.
Resting the cursor on a step implementation no longer paints stray highlights over unrelated code in the Java file. The marks the editor puts on the symbol under the cursor now fall only where that symbol occurs in the file being read; the spec steps a step method stands behind are still listed by Find Usages.
The editor no longer freezes while the Test Code pane works out which classes carry a spec, or while the Execution Report is scrolled. That work now happens in the background, so the pane fills a moment after it is asked for rather than holding the IDE still until it can — most noticeably just after a project finishes indexing, where it could stall repeatedly.
Switching between the Test Code pane's file tabs no longer shows the file unfolded for a moment before its imports and other folded sections collapse. Each file keeps its editor now, so coming back to a tab also returns to where you had scrolled to and to any sections you had opened by hand.
The selected file tab in the Test Code pane, and the selected run tab over the Execution Report, now wear the same colour the IDE gives the selected editor tab above them, instead of the grey a pressed toolbar button wears.
The file and run tabs over the right-hand pane now line up with the toggle buttons beside them, and carry the same spacing between one another as those buttons do. They stood a little high and ran into each other with no gap at all.
The last tab over the right-hand pane is no longer clipped, with the space before the buttons beside it swallowed, when the pane is widened until a hidden tab reappears. The row was working out how many tabs fit before their icons had been drawn, so it measured each tab narrower than it turned out to be and fitted one more than there was room for.

Removed

The "Allow folding Rules" option is gone from the Editor settings page. A Rule that spans several lines can now always be folded, in the spec editor and in the Execution Report alike, and the "Rules" choice under "Fold on open" is always available.
The "Don't wrap long lines in spec files" option is gone from the Editor settings page. Spec files never wrap long lines, so the columns of a wide data table always stay lined up; a long line scrolls sideways instead, in the spec editor and in the Execution Report alike.
The "Error panel bar colour" setting is gone from the Execution results settings page. A failed step's error panel bar now takes the colour of the step's own icon.
The option that turned Playwright traces on and off. A step's recorded trace now always opens as an expandable trace panel beneath that step in the Execution Report, since a trace only ever reaches the report because a run was set up to record one.
⚠️ BREAKING: The Store the agent session id in the spec file option is gone from the Agent integration settings page, and a launched session's id is never written into a spec file. Each spec's agent sessions are now remembered only by the IDE, in a file alongside the project's other IDE settings, so launching an agent leaves your specs exactly as you wrote them and a read-only spec launches without complaint. If you had the option on, those sessions are not carried over — the # claude-session: lines already in your specs are now ordinary comments that nothing reads, and you can delete them at your leisure. Renaming or moving a spec in the IDE still keeps its sessions.
⚠️ BREAKING: The Auto-Enable Remote Control (Claude Code only) item is gone from the Launch AI agent button's dropdown, and sessions started from the button no longer ask for remote control. Turn it on from within the session instead, the way you would in any terminal.
⚠️ BREAKING: The Auto-reload checkbox is gone, and with it the automatic adoption of a newer execution report. A report is now only ever loaded when you ask for it, through the Reload link beside the time, so the results you are reading stay put until you choose to move on.
⚠️ BREAKING: The editor no longer reports an unusable revision-markup pattern of its own accord, and the plugin's inspection for it is gone from Settings > Editor > Inspections. Building the project already reports both an invalid pattern and a marked range missing one of its ends, in the same place and with the same detail. How a spec file is coloured while a pattern is unusable is unchanged.
The error-panels button on the spec file's editor toolbar, and its dropdown, are gone. Open or close a failed step's error panel from the red icon beside the step; in split view, each pane's icon opens the panel in that pane only. The dropdown's options moved to the Execution results settings page.
The "Show Previews" button on the spec file's editor toolbar, and its dropdown, are gone. Open or close a doc string's preview from the preview icon beside its opening fence; in split view, each pane's icon opens the preview in that pane only. The preview bar colour moved to the Editor settings page.

2026.17.0

August 29, 2026

Added

Revision markup in spec files is now highlighted in its own colour. Text that SpecBinder strips before generating tests — whatever the stripPatterns option matches — is painted as markup so it stands out from the spec text around it, wherever it appears: in steps, titles, descriptions, table cells and doc strings. Where two patterns match the same text, the one declared first wins, matching the order SpecBinder applies them in. The colour is configurable under Settings > Editor > Color Scheme > Gherkin.
A step's Playwright trace can now be opened in your browser from the trace row itself. Pointing at the row reveals a small arrow beside the trace's file name; clicking it opens that same recording full-size in Playwright's own trace viewer, while the row's file name still expands the viewer inline as before. The recording is handed over on a local address and never leaves your machine. Previously this was only reachable by Shift- or Alt-clicking the file name, which still works.
Ctrl/Cmd+Click on a step carrying revision markup now opens the same step method as the plain step would: the method name is worked out from the step text with the markup stripped, so annotating a step for traceability never costs you the jump to its implementation.
Find Usages on a step method now lists the spec steps that only match once their revision markup is stripped, so a step annotated for traceability is not silently missing from the usage list.
A range of spec text can now be marked by its two ends, using the stripBetweenPatterns option: one pattern for where the range opens and one for where it closes. Everything from the opening marker to the closing one is treated as stripped, so a range can wrap whole steps, a whole scenario or rows of a table without either pattern needing to match across lines. Each opening marker is closed by the nearest following one, so a marker written inside a range is part of what the range covers; an opening marker with nothing closing it leaves the text exactly as you wrote it, rather than swallowing the rest of the file. Ranges are applied before the stripPatterns entries, so a range keeps its whole span even when an entry would also have matched inside it.
Inside a marked range, only the two markers are highlighted — the spec text between them keeps its ordinary colouring and still reads as Gherkin, so a range wrapping a whole scenario looks like a scenario rather than a block of markup. Everything in the range is still stripped before the tests are generated, so the names, numbering and recorded status of what survives are worked out as if the range were not there: a scenario that gains a range around some of its steps keeps the result already recorded against it.
The text inside a marked range can now be given a look of its own, through a new Stripped range content entry under Settings > Editor > Color Scheme > Gherkin. It starts with nothing set, which leaves a range exactly as it reads today. Because each attribute of the entry is set on its own, a style chosen without a colour is laid over the range rather than replacing it — tick Effects > Strikeout and the wrapped text keeps its ordinary Gherkin colours with a line through it, which is a natural way to show wording that no longer reaches the tests. Choosing a foreground instead colours the range outright.
A range's two markers can now be coloured apart from a plain stripPatterns match, through a new Stripped range marker entry. It takes its colours from Strip pattern unless you set it, so nothing changes until you ask for it — it is there for authors who want "this whole span is going" to look different from "these tags are going".
An unusable stripBetweenPatterns pair is now reported in the editor on the offending pattern — whichever of the two will not compile, or either one left blank, since a pair with only one end cannot mark a range. Until the pair is usable the spec file is highlighted as if no ranges were configured, rather than guessing where you meant the range to close.
An unparseable stripPatterns entry is now reported in the editor, on the offending pattern itself, so you find out as you type instead of from a failed build. Until it compiles, the spec file is highlighted as if no patterns were configured.
Renaming a step method now updates the matching step in the spec file even when that step carries revision markup: the step is found by its text with the markup stripped, so annotating a step for traceability no longer leaves it behind, out of sync with the method it runs. The rewritten step is written plain — a method name records nothing about where the markers sat — and text a pair of markers wraps and removes goes with them. A marker no configured pattern matches is part of the step text the method name was built from, so it stays put: only the words the rename actually changed are rewritten, leaving the rest of the line exactly as you wrote it.
Step completion now suggests steps for a line carrying revision markup: the text you have typed is matched with the markup stripped, so annotating a step part way through typing no longer empties the suggestion list. Text wrapped by a pair of markers is dropped along with them, exactly as it is when the tests are generated.
Ctrl/Cmd+Click from generated code back to the spec now lands on the right place when revision markup is involved. Shift+Ctrl/Cmd+Click on a step method call opens the marked-up step it was generated from, and where two steps read alike once their markup is stripped, each call opens its own step rather than both opening the first. Ctrl/Cmd+Click on a generated test method or nested class opens the Scenario or Rule it came from even when that element's title carries markup — titles are matched with the markup stripped, the way SpecBinder writes them into the generated @DisplayName.
A scenario keeps its recorded execution status when you annotate it with revision markup. The scenario is matched to its recorded run by its content with the markup stripped — the same way SpecBinder records it — so adding traceability markup no longer blanks the status icon in the gutter, and a scenario beside an annotated one is unaffected. Editing what a step actually says still invalidates the match: the scenario then reads as not executed until the tests are run again.

Changed

Reformat Code now pulls doc string lines that start to the left of the opening triple quotes back in line with them, instead of leaving them hanging outside the block. Lines that already start at or beyond the triple quotes keep their own indentation relative to the block, and blank lines are left untouched.
A Playwright trace opened in your browser is now named after its own recording file, so a tab full of traces can be told apart. Previously every trace arrived under the same meaningless identifier, leaving the browser tab and the viewer's own heading identical for each one.
The doc-string previews and published reporter entries buttons on the editor toolbar now set their panels' left-bar colour from a single "Panel bar colour" swatch in their dropdown, opening the full colour picker in one click. This matches how the failed-step error panels dropdown already worked, so every panel colour is chosen the same way. The grid of preset colours and the separate "Custom…" button are gone from both dropdowns; a colour picked previously is kept.

Fixed

The execution report status counts now retire a scenario that was changed outside the IDE. A spec file rewritten on disk by another tool, a script, or a branch switch never saves through the editor, so its edited scenarios kept their recorded pass or fail; they are now counted as not executed as soon as the change reaches the file, exactly as they are after an in-editor save. Scenarios the change left alone keep their recorded status, and restoring the original content brings the recorded status back.
Scenarios and Rules that follow spec text removed by revision markup are no longer mapped onto the wrong generated test. A scenario after a removed one is numbered the way SpecBinder numbers it, so its gutter Run icon starts the right test, Ctrl/Cmd+Click from the generated class lands on the right scenario, Find Usages lists the right steps, and execution report statuses are drawn against the scenario that produced them.
Reformat Code now leaves a line that begins with revision markup exactly where it is. Previously a table row wrapped in markup was pushed out to the left margin; it now keeps its indentation and its own spacing, while the rows around it are aligned as if it were not there.
The spell checker no longer flags revision markup as typos, while still checking the words the markup wraps.
A spec file that was already open while the project was still loading could show "No execution report" for the rest of the session, even after the spec had been run and its report was on disk. The report is now picked up as soon as it is written.
The inline preview of an SVG doc string now draws the graphic on a high-resolution display. The preview opened at the right size but painted little or nothing of the picture, so a fine-lined graphic looked like an empty panel. The image preview is drawn the same way.
Approving a failed step's Actual value no longer stops the other open error panels from approving theirs. Accepting a value makes the spec file longer and pushes every step below it further down, and the panels still open carried on pointing at the lines their steps used to occupy — so from the second approval onwards the button reported "Cannot locate the expected value as a parameter on this step", and a run with several failures had to be approved one panel at a time, closing and reopening each. Each panel now follows the step it was opened on however far that step has moved, so the failures can be worked through in a single pass, in any order. Editing the file by hand while panels are open is handled the same way, and a failed step's gutter icon still closes that step's own panel after the step has shifted.

2026.16.0

July 31, 2026

Changed

The Step Implementation tool window no longer draws an icon in the loaded editor's gutter next to the linked method. The highlighted line already marks it, and dropping the icon keeps the gutter at its normal width.

Fixed

The Step Implementation tool window now reliably scrolls the linked method into view when it loads a class: previously the newly loaded file could appear scrolled to the top instead of centred on the method. The loaded file is also kept aligned to the left edge, so it no longer scrolls sideways to reveal the indented method name.
The step implementation preview (Quick Documentation on a step) and the Step Implementation tool window now show the actual step method body — the concrete implementation in your test class — instead of the empty abstract declaration, for steps whose implementation lives in a subclass of the generated test class. Ctrl/Cmd+Click on a step lands on the same concrete implementation.

2026.15.0

July 31, 2026

Fixed

The step implementation preview (Quick Documentation on a step) and the Step Implementation tool window now show the actual step method body — the concrete implementation in your test class — instead of the empty abstract declaration, for steps whose implementation lives in a subclass of the generated test class. Ctrl/Cmd+Click on a step lands on the same concrete implementation.

2026.14.0

July 31, 2026

Added

A new Auto-Enable Remote Control (Claude Code only) toggle in the Launch AI agent button's dropdown (below Auto-Select This Spec's Terminal Tab, off by default and remembered). When on, Claude Code sessions you start from the button launch with remote control enabled, so you can drive or watch each session from claude.ai or the mobile app without turning it on by hand. It only affects Claude Code launches — Copilot CLI sessions are unaffected — and whether a session actually connects for remote control depends on your Claude sign-in.
A new Step Implementation tool window (right dock) shows the Java implementation of the step under your caret in a spec file, and follows the caret: as you move through steps, it loads the step method's owning class and scrolls to that method, highlighting the linked method's line with a gutter marker so it stands out. It hosts a real editor, so you can read, edit, and refactor the class directly in the pane; the pane header shows the loaded file's name and icon, and a colour swatch there lets you choose the highlight colour for the linked method. When the caret is not on a step, nothing resolves, or the focused file is not a spec, it simply keeps showing the last class rather than blanking. It resolves to the same method Ctrl/Cmd+Click and Quick Documentation open.
Quick Documentation (Cmd+Q) on a step in a spec file now previews that step's Java implementation inline in the documentation popup, syntax-highlighted, so you can review what a step does without jumping to the generated test class. It appears only when you invoke the shortcut — not automatically on mouse-hover — and resolves to the same method Ctrl/Cmd+Click navigates to. When a step has no implementation yet (its generated test class isn't compiled, or no matching class was found), the popup says so instead of showing nothing.
When a step's execution recorded a Playwright trace, an expandable Playwright trace row now appears beneath that step — in both the spec editor and the Execution Report preview — alongside any published-reporter entries and controlled by the same toolbar toggle that shows those entries. Clicking the row opens the recorded trace inline in the embedded Playwright trace viewer (screenshots, DOM snapshots, network, console, and the action timeline); collapsing it releases the viewer. Shift- or Alt-clicking the row instead opens the trace full-size in your system browser. The viewer loads from trace.playwright.dev, so it needs an internet connection — the trace file itself stays on your machine and is served to the viewer locally. The trace is matched to its step from the recorded report, so the row keeps showing the run even after the spec file is edited.
New "Show Playwright traces" toggle (Execution results, nested under "Show published JUnit reporter entries", off by default) controls whether that recorded trace becomes the expandable trace-viewer row. When turned off, the trace is instead shown as an ordinary published-reporter entry — a plain specbinder.playwright.trace: <path> row with no embedded viewer.
Doc strings opened with an """xhtml fence are now treated the same as """html ones: their body gets HTML syntax highlighting, the body is foldable (and honours the "Collapse HTML doc strings" setting), a gutter icon renders an inline preview of the markup, and selecting the body and running Reformat Code pretty-prints it with the HTML formatter.
Selecting the body lines of a typed doc string (one opened with a content-type fence such as """json or """html) and running Reformat Code now pretty-prints that content in its own language — JSON, YAML, HTML, XML, and SVG — and re-indents the result under the doc string's fence. Only the selected doc string is affected: reformatting with nothing selected (or the caret elsewhere in the file) leaves every doc-string body untouched, and a doc string with no content type, or one whose type has no formatter, is left unchanged.
The Execution Report preview now reproduces a Scenario Outline (or Scenario Template) by rebuilding its heading and placeholder steps, then listing one nested Example per row of its examples table with each row's values substituted into the step text. The rebuilt heading and placeholder steps come from the recorded report; the Examples table itself is not repeated. Reports produced without the outline's template steps (older runs) instead show the substituted rows alone, without a rebuilt heading. As with the rest of the preview, the rows come from the recorded report, so the pane keeps showing the run even after the spec file is edited.
A doc string or data table attached to a Scenario Outline step is now reproduced in the Execution Report preview too: it appears once beneath the rebuilt placeholder step with its <> placeholders left in place, and again beneath each expanded Example with that row's values substituted in. As with the outline's step text, both come from the recorded report.
The active-pair link highlight now pairs a Scenario Outline with the template block the Execution Report pane rebuilds for it: putting the caret on the outline heading frames the rebuilt heading together with any description lines beneath it, on a Scenario Outline step frames its rebuilt placeholder step together with any doc string or data table attached to it, and on an examples table row frames just that row's expanded Example — each with a connecting divider polygon. The pairing works both ways: in the report pane, putting the caret on a rebuilt Example heading frames the examples table row it was expanded from, on a rebuilt placeholder step frames the outline step in the editor, and on a step inside an expanded Example frames the outline template step that row ran from. The Examples keyword and the table header row have no counterpart, so they highlight nothing.
The <> placeholders in a Scenario Outline's rebuilt heading and template steps now carry the same outline-parameter colour in the Execution Report preview that they have in the spec editor, so the parameterised template reads the same on both sides.
The active-pair link highlight now links a Background step with the copies the Execution Report pane inlines ahead of each scenario. Because a background step is repeated once per scenario in the report, putting the caret on the Background heading or one of its steps in the editor highlights nothing; instead, putting the caret on one of those inlined report lines frames just that line and, across the divider, the single Background step in the editor it came from — even when other scenarios inline the same step.
The Execution Report preview now shows each scenario's Background steps inline as its leading steps — the feature-level, and for a scenario under a Rule the rule-level, steps that ran before it, in run order — taken from the recorded report. There is no separate Background heading in the preview; the steps simply precede the scenario's own steps. This also applies to the per-row scenarios a Scenario Outline expands into.
Changing a Java step method's parameters with IntelliJ's Change Signature refactoring now updates the matching step text in associated feature files. Adding a parameter inserts the default value you give it as a quoted value at the corresponding position in each step; removing a parameter drops its quoted value (keeping any doc string or data table attached to the step); reordering parameters rearranges the quoted values to match the new order. Each quoted value follows its parameter, so this works even when the same change also renames the method.

Changed

Every option on the Execution results settings page now starts turned off, so all execution-report-driven features are opt-in: gutter and toolbar status indicators, failed-step error icons and their inline panel, Project-view spec file icons and folder status chevrons, the published-reporter-entry panels (and Playwright traces), and the Execution Report split view. Turn on the ones you want under Settings → Tools → SpecBinder → Execution results.
The editor "Collapse on open" folding option for HTML doc strings is now labelled "HTML/XHTML doc strings", reflecting that it also collapses """xhtml doc strings on open.
Outline placeholders (<name>) inside a Scenario Outline are now always shown in the single outline-parameter colour, whether or not the placeholder's name matches a column in the Examples table. The separate colour previously used for an unmatched placeholder has been removed, along with its "unresolved outline parameter" entry in Settings → Editor → Color Scheme → Gherkin.
Navigation, Find Usages, and step completion now recognise the renamed feature-level Background setup method in SpecBinder-generated test code, keeping Ctrl/Cmd+Click and Find Usages between a feature file's Background and its generated method working with the current generator output.
Ctrl/Cmd+Click on a step now goes to the step method itself in the generated test — its concrete implementation, or the abstract declaration when there is no implementation yet — and Ctrl/Cmd+Click on a step's quoted parameter, doc string, or data table goes to the matching parameter of that method. To jump to the step's call site inside the generated test method instead (the previous Ctrl/Cmd+Click destination), use Ctrl/Cmd+Shift+Click, which mirrors Ctrl/Cmd+Shift+Click from a generated call site back to its step. Both directions show the usual navigation link on hover. Call-site navigation lands on the whole step's call statement, not an individual argument.

Fixed

The agent status badge (the diamond drawn over a spec file's icon to show whether its linked agent is working, needs input, or has finished) now appears on a freshly installed IDE. Previously, on a machine where the plugin had not yet created its internal status folder, the launched agent's state was never recorded and no badge ever showed; the folder is now created when an agent is launched, and each state update recreates it if it has since been removed, so the badge lights up reliably.
The inline Playwright trace row no longer traps the editor's vertical scroll: hovering the collapsed row and using the mouse wheel now scrolls the editor as usual (previously scrolling stopped until the pointer moved off the row). The expanded trace viewer keeps its own scrolling, and once its content reaches the top or bottom the wheel continues scrolling the surrounding editor. The row also shows the normal pointer instead of a text cursor.
The failed-step error icon on a Scenario Outline's expanded example steps in the Execution Report pane is now clickable: clicking it (or opening all panels from the toolbar's error-panels button) reveals the inline error panel with that example's failure detail beneath the step, matching how it already works for a plain scenario's failed steps. Previously the icon appeared but did nothing. When the example step recorded Expected and Actual values, the panel also offers the Show diff (and, for HTML or image doc-string values, Visual diff) actions; Approve is not offered for an example step, because its expected value lives in the shared outline template.
Angle-bracket text such as <name> is now highlighted as an outline placeholder only where it can actually be one: inside a Scenario Outline or Scenario Template, and never inside an html, xml, or svg doc string (where <…> is the markup's own tags). In a plain Scenario, a Background, or a markup doc string the same <…> is shown as ordinary text — step text, a literal table value, or plain doc-string content — instead of the bold outline-parameter styling.
Report-driven gutter status icons now treat a Scenario Outline's example rows that the execution report never recorded as not executed: such a row, the Scenario Outline heading, and the Rule and Feature above it show the amber not-executed chevron instead of leaving the row without an icon and the heading passed. An outline that already has a failed row still shows failed.
Find Usages on a Java step method now lists its occurrences in steps belonging to scenarios nested under a Rule, not only scenarios at the top level of a spec file.
Reduced the chance of a spurious "stub index" error being reported when opening a project in a Gradle module, by reusing a cached lookup for the spec file's generated test class instead of re-running a project-wide search on every toolbar refresh.
Enabling, disabling, or updating the plugin now prompts to restart the IDE instead of reloading it in place. This avoids a rare crash where opening a spec file after re-enabling the plugin failed with an internal class-loading error.
Pressing Esc while a failed step's Visual diff window (the rendered HTML comparison or the image comparison) is open now closes it and returns to the editor, matching how the standalone text diff window already behaved. Previously Esc only refocused the main IDE window and left the Visual diff window open.

2026.13.0

July 12, 2026

Added

The left spec-editor toolbar now has a report section (after the collapse / expand buttons) showing the date and time the displayed Execution Report was generated, with an "Auto-reload" checkbox and a "Reload" link. With auto-reload off (the default) the pane keeps showing the current report when a newer one is written to disk and the "Reload" link appears to load it on demand; with auto-reload on, newer reports load automatically (the setting is global and also lives in Settings > Tools > SpecBinder > Execution results). Switching to editor-only view and back to a report view reloads the latest report automatically.
Every right-pane colour palette (failed-step error panels, image and HTML doc-string previews, published reporter entries, and the split-view link highlight) now shows a swatch of your last-picked custom colour next to the "Custom…" button, so the custom colour stays visible at a glance; clicking the swatch re-applies it.
Two new buttons on the left spec-editor toolbar (after the status lozenges) collapse or expand every Scenario and Background section in the file at once. They act on whichever editors are visible — both the spec editor and the Execution Report pane in split view, the spec editor alone in editor-only mode, and the report pane alone in preview-only mode.
A new "Show Previews" split button on the right-pane toolbar: its main button opens the inline preview for every previewable doc string in the file at once — image, HTML, and SVG alike — and clicking it again closes them; its dropdown arrow opens a colour palette (with a "Custom…" option) for the single shared colour of each preview's left bar. It acts on whichever editors are visible — both panes in split view, the spec editor in editor-only mode, the report pane in preview-only mode.
A new "show all error panels" split button on the right-pane toolbar (second from the left): its main button opens an inline error panel under every failed step at once, and clicking it again closes them all; its dropdown arrow opens a colour palette (with a "Custom…" option) for the colour of each panel's left bar. The panels appear in the Execution Report pane in split/preview modes and in the spec editor in editor-only mode. Whether inline error panels are available at all remains controlled by the SpecBinder settings.
New master "Use SpecBinder execution reports" checkbox (Execution results): when off, no execution-report data is read and all dependent features (gutter icons, failed-step error icons, inline error panel, split-view) are disabled. On by default.
New "Show inline error panel" toggle (Execution results): when on (default), clicking a failed-step error icon opens the inline error panel; when off, the icon is indicator-only.
New "Show HTML previews" and "Show image previews" toggles for the inline error panel's Expected / Actual values (both on by default).
The SpecBinder landing page now has shortcut links that jump to the Gherkin "Color scheme" and "Code style" pages (under the IDE's standard Editor sections).
Long lines in spec files can be kept on one line with a horizontal scrollbar instead of wrapping ("Don't wrap long lines in spec files", under Editor); also applies to the Execution Report view in split mode, and takes effect on next file open.
Clicking the gutter Run icon on a Feature, Rule, or Scenario keyword in a .specb / .feature file now creates a Gradle test run configuration (equivalent to ./gradlew :test --tests "<class>" or …--tests "<class>.<method>") when the file lives in a Gradle-managed module, so test execution flows through the Gradle build with the matching task graph, system properties, and IDE / build classpath rather than IntelliJ's direct JUnit runner. Maven and non-Gradle projects continue to use the existing JUnit run configuration.
The Execution Report preview now shows data tables and doc strings inline beneath each step, formatted in the same Gherkin shape as the source file (pipe-aligned table rows; triple-quoted doc string blocks)
The Execution Report preview now renders Feature, Rule, and Scenario description text inline beneath each heading, mirroring its position in the source file. Description text is taken from the JSON report when the test was generated with description-as-annotation support, and is silently omitted for older reports
A toolbar above the left editor pane shows coloured execution-status lozenges for the current Execution Report — an overall-status pill plus passed / failed / skipped / unexecuted scenario counts (a status with no scenarios is hidden). Clicking a count lozenge moves the caret to the next scenario of that status, wrapping after the last; clicking the overall pill steps through the scenarios that share the run's overall status
A toolbar above the right Execution Report pane provides a toggle for showing or hiding published reporter entries (off by default)
The right-pane toolbar now has a toggle for synchronising the Execution Report's scroll position with the editor (on by default); when on, scrolling either pane drives the other
The right-pane toolbar now has a toggle for showing the active-pair link highlight — the divider polygon together with the line tints on either pane — on by default; the toggle disables itself when the editor is in editor-only or preview-only mode where there's no divider to draw into
The right-pane toolbar now has a colour swatch button that opens a colour picker for the active-pair link colour used by the divider polygon and the line tints on either pane
Click the red error icon in the Execution Report pane's gutter next to a failed step to toggle an inline error panel showing the message, Expected vs Actual, and stack trace — the same affordance available on the spec editor pane, with independent open / closed state per pane
The body of a plain """ doc string (no media-type identifier) is now foldable from the editor gutter, the same way HTML / JSON / XML / YAML doc strings already are. A new "Collapse plain doc strings" checkbox under Settings > Tools > SpecBinder > Code folding controls whether plain doc-string bodies are collapsed by default when a feature file opens.
Doc-string bodies are now foldable in the Execution Report preview pane too, mirroring the editor-side behaviour: every doc string is foldable regardless of its media-type identifier, and the initial collapsed state respects the matching "Collapse … doc strings" setting (plain, HTML, JSON, XML, or YAML).
The HTML doc-string preview gutter icon now appears in the Execution Report preview pane next to every """html opening fence. Clicking it toggles the same inline rendered preview beneath the closing fence that the editor pane already offers.
The image doc-string preview gutter icon now appears in the Execution Report preview pane next to every """image (and """img) opening fence. Clicking it toggles the same inline rendered image preview beneath the closing fence that the editor pane already offers.
A new """image content-type identifier for doc strings: clicking the gutter preview icon next to a """image opening fence toggles an inline rendered preview of the base64-encoded image (PNG, JPEG, GIF, WebP, BMP — format auto-detected from the decoded bytes) beneath the closing fence, with the same thin frame, step-keyword-aligned indent, and editor background as the """html preview. An empty body, invalid base64, or bytes that aren't a recognised image format surface a red error icon and explanatory message in place of the preview. Spell-checking is automatically disabled inside """image bodies so the IDE's typo quick-fix can't silently corrupt the encoded bytes.
Two new checkboxes under Settings > Tools > SpecBinder for the """image doc-string family: "Auto-open image previews" (under Doc string previews) renders every image preview automatically when a feature file opens, and "Collapse image doc strings" (under Code folding) folds """image (and """img) doc-string bodies by default — both mirror the equivalent toggles already available for """html doc strings.
When a step fails comparing two """image (or """img) doc-string values, the inline error panel now embeds a decoded image preview beneath each of the Expected and Actual base64 rows, the same way it already does for """html doc strings, so the two images can be compared side by side without copy-pasting the base64 into an external viewer.
The inline error panel's action row now treats """image (and """img) doc-string parameters the same way as """html: the Approve button rewrites the failing step's doc-string body with the Actual base64 verbatim, and the Show diff button opens the textual diff viewer. The Visual diff button is omitted for """image step parameters (image rendering is already shown inline beneath each value row).

Changed

The Execution Report preview now renders Feature, Rule, Scenario, and step rows from the text recorded in the JSON report — Scenario Outline rows show parameter values exactly as they were executed, and the preview keeps working when the source file has uncommitted edits since the run. Older reports continue to render using the source file's text as a fallback.
Failed-step gutter icons now use a red circle with an X cut-out, visually distinct from the red circle with a white exclamation mark used on the Execution Report preview's aggregate failure rows for Feature, Rule, and Scenario — making it easy to tell at a glance which row is the actual failing step (and the clickable affordance for the inline error panel) versus the rows that summarise a descendant failure
When the caret sits anywhere inside a step block — its keyword line, its data table rows, or its doc string content — the active-pair link (line tint on both panes and connector polygon in the divider) now spans the full step block on both sides, rather than just the keyword line
When the caret sits on a description line of a Feature, Rule, or Scenario — or on its heading — the active-pair link now spans the full heading-plus-description block on both panes, the same way step blocks already widen for their data tables and doc strings
Published reporter entries (the indented "↳ key: value" rows under steps) are now hidden by default in the Execution Report preview and can be turned on from the new right-pane toolbar toggle
The Execution Report preview now shows DocString media-type identifiers (e.g. """html) on the opening fence and uses source-verbatim column headings (e.g. | User Name |) for data tables, matching how the spec was originally written rather than the sanitized field names used inside the row data
The Execution Report preview now applies the same per-language doc string support as the editor: a """html body is rendered with HTML syntax highlighting (and other supported media-type identifiers render with their respective languages). The run / re-run gutter icons remain editor-only and are not painted in the report preview
When a failed step has a doc string or data table argument, the inline error panel is now rendered immediately below that argument block instead of between the step keyword line and the argument rows, so the step and its argument stay visually together. This applies to both the spec editor pane and the Execution Report preview
Published reporter entries in the Execution Report preview are now shown in a dedicated inline panel under the step (a block with a teal left stripe) instead of inserting extra lines into the preview. Entry text inside the panel is selectable and can be copied like any other editor content, the panel adds vertical breathing space above, below, and between individual entries so the rows do not look squashed, the text scales with the editor's font zoom (Cmd / Ctrl + scroll or Increase / Decrease Font Size actions) to stay consistent with the surrounding right-pane text, the right-pane toolbar toggle still controls whether these panels are visible, the entry rendering rules and ordering are unchanged, and on a failed step the published-entries panel sits between the step row and the inline error panel so the contextual data the step recorded is read before the failure detail
The inline error panel for failed steps now scales with the editor's font zoom — increasing or decreasing the font size in the spec editor or the Execution Report preview also resizes the panel's Message, Expected, Actual, and stack-trace content text, so it stays consistent with the surrounding editor text on both panes
The inline panels under steps — the failed-step error panel on both panes and the published reporter entries panel on the Execution Report preview — are now indented so their coloured left stripe sits two columns to the right of the owning step keyword instead of starting flush against the editor's left edge. The indent stays aligned with the step keyword's column at every font zoom level, and in both single-pane editor and split editor / preview view modes
The inline rendered HTML preview for """html doc strings now uses the same step-keyword-aligned horizontal indent on both panes, and stays aligned in both single-pane editor and split editor / preview view modes; when the step also has published reporter entries and / or a failed-step error panel, the HTML preview is rendered first immediately under the doc-string closing fence, with the published-entries panel below it and the error panel at the bottom
The inline rendered HTML preview panel for """html doc strings now uses the editor's own background colour around its embedded browser — replacing the previous subtle grey panel background — so the preview blends seamlessly into the surrounding editor on both the spec editor and the Execution Report preview, in all view modes (editor-only, preview-only, and split editor / preview)
The inline rendered HTML preview panel for """html doc strings now draws a thin frame around its embedded browser, matching the frame the failed-step inline error panel draws around its Expected / Actual HTML previews, so both surfaces present rendered HTML with the same visual affordance
The toolbar row above the editor (failed-scenario counter + prev / next arrows on the left, rendering-option toggles on the right) is now shown in editor-only view as well, not only in split editor / preview and preview-only views — so the failed-scenario navigation arrows and the preview-related toggles remain reachable without having to switch the view mode first
The blank vertical strip between the spec editor and the Execution Report preview in split editor / preview view is now half as wide, giving more horizontal room to the editor panes themselves while still leaving space for the active-pair link connector polygon

Fixed

The active-pair link connector polygon in the split editor's divider no longer drifts out of alignment with the line tints on either pane after clicking inside an inline panel (published reporter entries, error panel, HTML preview) or after focus shifts between panes without a caret move; the polygon and the line tints now always reflect the same anchor element
Resolved an internal IDE exception that was raised on every repaint of the split editor's divider when the Execution Report preview was open
Opening a .specb or .feature file in split view no longer occasionally leaves the editor's gutter on its default left side; it now consistently sits next to the central divider from the first paint, without requiring a manual toggle of the view mode to fix it
The Execution Report preview no longer shows two stacked HTML preview toggle icons next to """html doc string fences; only the preview's own native toggle (wired to the right pane's inlay) is shown
Hovering the HTML preview toggle in the Execution Report preview's gutter now changes the mouse pointer to the hand cursor, matching the affordance shown for the same icon on the editor side
The "Message", "Expected", "Actual", and "Stack trace" field labels in the inline error panel for failed steps now use the same font size as their values, instead of the smaller UI font that made the labels read as a different rank
Published reporter entries in the Execution Report preview no longer occasionally appear twice under the same step; each step's published-entries panel is now installed exactly once
The inline error panel's action buttons (Approve, Show diff, Visual diff) and the diff viewers they open no longer fail silently in the released plugin — internal helper classes are now correctly preserved through obfuscation so the panel and its actions load reliably

Removed

The "Fold long values" setting (fold mode + line-count threshold) has been removed from the inline error panel options. Long values now always start collapsed to their first line — every multi-line value, plus any single line longer than 140 characters — with a chevron to expand. This is no longer configurable.

2026.11.0

May 26, 2026

Removed

Compatibility with IntelliJ IDEA 2024.2 — the minimum supported IDE build is now 2024.3 (243.0). Users still on 2024.2 should upgrade their IDE to install future versions of the plugin.

2026.10.0

May 25, 2026

Added

In the inline error panel, the cursor now reads as a hand-pointer when hovering the chevron and as a text I-beam when hovering the value text, so clickable and selectable regions of a Message, Expected, Actual, or Stack trace row are visually distinct at a glance.
The inline error panel's Stack trace now mirrors the same row layout as the Message, Expected, and Actual rows: the first line of the stack trace (typically the exception class plus message) is shown in the row header alongside a chevron, and the remaining frames are revealed when the row is expanded. Single-line stack traces render plainly with no chevron.
Navigation support for Gherkin keyword aliases: Ability, Business Need, Narrative (Feature), Example (Scenario), and Scenario Template (Scenario Outline)
Code Style settings page under Editor > Code Style > Gherkin (SpecBinder) with configurable tabs and indents, commenting, and blank line options
Step auto-completion now uses fuzzy word matching: typing any word will suggest every step whose text contains that word at any position; typing multiple words requires every word to appear in the step text, in any order
Gutter icons in feature files now reflect the latest execution state of the corresponding test: Feature, Rule, and Scenario keywords show a green check when the matching test has passed, or a red mark when the matching test has failed
Breakpoints can now be set directly on Gherkin step lines in feature files; running the test in debug mode pauses the JVM at the corresponding generated call site, and the editor highlights the step in the feature file rather than the generated Java source
HTML doc-string parameters (opened with """html) now show a preview icon in the editor gutter on the line of the opening fence
Clicking the HTML doc-string gutter preview icon displays an inline preview of the rendered markup below the closing fence of the doc string; clicking it again removes the preview
Open HTML doc-string previews update automatically and live-reload as you edit the markup, with rapid keystrokes debounced to avoid flicker
Gutter icons can now reflect per-scenario pass/fail outcomes recorded by the SpecBinder execution reporter's JSON files, including per-row icons on Scenario Outline data rows; failing scenarios get a tooltip naming the failing step
When the recorded outcome no longer matches the current spec content (e.g. the scenario was edited since the last run), the stale pass/fail icon is hidden by default so a green checkmark cannot mislead; an opt-in setting renders the stale outcome as a desaturated icon with a warning overlay instead
New "JSON-report results" section under Settings > Tools > SpecBinder with two checkboxes: a master toggle (off by default) to enable JSON-based gutter icons, and a "Hide stale icons" toggle (on by default) to control how stale outcomes are visualised
Failed steps now also show a red error icon in the gutter, anchored on the step keyword, with a tooltip carrying the recorded error type and message; only steps recorded as failed are decorated, passed and skipped steps remain untouched
Failed-step gutter icons are also subject to the existing staleness rules: when the recorded outcome no longer matches the current spec content (e.g. the scenario was edited since the last run), the failed-step icon is hidden by default so a stale red error icon cannot mislead
Stack-trace frames in the inline error panel are now clickable hyperlinks: each (FileName.java:line) reference becomes a link that opens the source file at the given line, mirroring the navigation experience of IntelliJ's run/debug console output. Frames without a navigable source location (Native Method, Unknown Source) stay as plain text. Frames pointing at a nested class (e.g. a SpecBinder-generated @Nested Rule class) navigate correctly even though the stack trace uses the JVM Outer$Inner form
Stack-trace frames whose class lives outside the project's source files (JDK, JUnit, and other library frames) are now rendered in a softened, lower-contrast colour, while frames pointing at the project's own source files are rendered with a teal accent in bold by default — together making user-code frames immediately spottable in long stack traces, matching the IntelliJ run/debug console convention
New "Inline error panel — in-module stack trace styling" section under Settings > Tools > SpecBinder lets you pick the colour and font style (Normal / Italic / Bold) used for in-module stack trace frames in the inline error panel
Doc strings tagged with an HTML fence (e.g. """html) are now treated as HTML by the editor: the contained markup gets HTML syntax highlighting, fold markers on multi-line elements, and HTML completion proposals — the same language services you would see in a standalone .html file. The fence identifier and surrounding Gherkin keep their normal Gherkin colours, and the doc-string indentation is removed before the content is handed to the HTML language services so embedded markup is parsed as if written at column zero. Editing inside the highlighted region is read-only in this release.
New "Collapse HTML doc strings" option under Settings > Tools > SpecBinder > Code folding: when enabled, the body of every """html doc string is folded by default when a feature file is opened, mirroring the existing Collapse Rules / Collapse Scenarios options.
Doc strings tagged with a """json, """xml, or """yaml (also """yml) fence are now treated as JSON / XML / YAML by the editor, with the same language services as HTML — syntax highlighting, fold markers on multi-line structures, and language-specific completion proposals — and matching "Collapse JSON / XML / YAML doc strings" toggles under Settings > Tools > SpecBinder > Code folding that fold their bodies on file open.
New "Auto-open HTML previews" option under Settings > Tools > SpecBinder > Doc string previews: when enabled, all """html doc strings are automatically rendered inline when a feature file is opened, without needing to click each gutter icon individually.
The HTML doc-string preview gutter icon now reflects the preview state at a glance: a neutral grey eye while the preview is hidden and a green eye while the preview is visible, so it is easy to see which """html doc strings are currently rendered.
When a failed step's execution report carries both expected and actual values, the inline error panel now shows a "Show diff" link beneath the Expected and Actual blocks. Clicking the link opens IntelliJ's standalone diff viewer on the two values, with line-level highlighting, so the comparison can be reviewed without leaving the editor.
The inline error panel now shows a "Visual diff" link beneath the Expected and Actual blocks when the failing step's parameter is an HTML-tagged doc string ("""html). Clicking it opens a side-by-side rendered HTML diff viewer in a separate frame: each side renders inside a sandboxed iframe (CSS-isolated), and a parallel DOM walk outlines differing elements with dashed coloured boxes — green for modified, red for elements only in Actual, and orange for elements only in Expected. Indicators are off by default; an "Indicators" toggle button in the toolbar reveals them. The toolbar adapts to the IDE theme (white in light themes, dark in dark themes), shows the colour-key legend on the right, and on the left provides up / down arrow buttons that step through differing elements in the Actual pane and ring the current element with a non-displacing blue halo (a box-shadow ring so layout is unaffected); when the Actual element has a positional counterpart in the Expected pane that pane's matching element is also ringed so the user can compare both sides at a glance plus a "Hide indicators" / "Show indicators" toggle that hides or restores all of the highlight boxes in both panes. The viewer supports zoom via keyboard (Ctrl/Cmd + =, Ctrl/Cmd + -, Ctrl/Cmd + 0 to reset) and Ctrl/Cmd + mouse wheel, scaling the rendered HTML in both panes between 50% and 300%.
The inline error panel now shows an "Approve" link next to "Show diff" when a failed step's execution report carries both expected and actual values. Clicking it writes the runtime Actual value directly into the failing step's matching parameter ("..." literal or """...""" doc string) — the same edit "Apply Expected to Step" performs in the diff viewer, but in one click and without opening the diff window. If the rewrite cannot be applied (no matching parameter, ambiguous match, or shape mismatch), the matcher's reason is shown as an editor hint so the failure is visible.
After a successful "Approve" or "Apply Expected to Step" rewrite, the editor caret is now placed at the end of the replaced value: just before the closing " for a simple parameter, or at the end of the last content line of a doc-string parameter. Editor focus is restored to the spec file so the user can keep typing.
When the failing step's parameter is an HTML-tagged doc string ("""html), the inline error panel now renders a live HTML preview directly below the Expected and Actual values. Each preview is hosted in its own sandboxed iframe with full DOM and CSS isolation so the two snapshots cannot interfere with each other or with the panel's own styling, and the iframe auto-resizes to fit its content.
New "Inline error panel — Message / Expected / Actual folding" section under Settings > Tools > SpecBinder lets you choose the *initial* state of multi-line Message, Expected, and Actual values in the inline error panel: Never (start expanded), Always (start collapsed to the first line with an ellipsis), or When longer than N lines (default 10) — the new default, so short multi-line values stop starting collapsed. The fold/unfold affordance is always available on multi-line values regardless of this setting; the setting only controls whether they start expanded or collapsed. Single-line values (including values with only a trailing newline) always render in full as non-foldable.
The standalone diff viewer opened from the error panel detects the failing step's doc-string fence ("""html, """json, """xml, """yaml, …) and applies language-aware syntax highlighting, matched-bracket highlighting, and folding to both panes; doc strings without a fence and simple "..." parameters continue to render as plain text.
The standalone diff viewer opened from the error panel makes the Expected side editable while keeping Actual as a read-only runtime snapshot, so the standard gutter chunk-arrows are usable for copying differing pieces from Actual into Expected and the Expected pane can also be hand-edited. Two actions are contributed to the diff toolbar: "Copy Actual to Expected" overwrites the Expected pane with the runtime Actual value (equivalent to pressing every chunk-arrow at once) without touching the spec file or closing the viewer, and "Apply Expected to Step" writes the current Expected pane contents into the failing step's matching parameter ("..." literal or """...""" doc string) and closes the viewer. The apply-to-step action is enabled only when exactly one parameter on the step has a literal value equal to the original expected and the candidate replacement legally fits the parameter shape; otherwise it is disabled with a tooltip explaining why.
New "Make Rules foldable" option under Settings > Tools > SpecBinder > Code folding: when enabled, multi-line Rule blocks show a fold marker in the editor gutter and can be collapsed; when disabled (the default) Rule blocks stay non-foldable so the gutter stays uncluttered. The "Collapse Rules" option is only available while Rules are foldable.

Changed

The embedded HTML previews under Expected and Actual in the inline error panel now align flush with the value text above them — the preview's left edge sits at exactly the same x-coordinate as the value column instead of starting one chevron-column further left
The Approve / Show diff / Visual diff action buttons row in the inline error panel now starts flush with the value column too, so its left edge lines up with the value text rows above and the embedded HTML previews below — previously the row started one chevron-column further left
HTML doc-string previews no longer show the IDE's CSS color-preview gutter swatches beside style="..." attributes that contain color literals, so the gutter stays clean and the preview's own gutter icon is the only marker on those lines
Long Message, Expected, and Actual values in the inline error panel now collapse to their first line by default, with an ellipsis (…) indicator at the end of the line; clicking the value expands it to reveal the remaining lines, and clicking it again collapses it back. Single-line values continue to render plainly without any disclosure affordance, so terse failures stay terse
Folding typed doc strings ("""html, """json, """xml, """yaml) now collapses the entire block into a single line showing the opening fence with a placeholder (e.g. """html...), with the fold/unfold gutter marker on the opening fence line — matching the standard IDE folding convention for other languages
Switched to calendar-year-based versioning (major version now reflects the release year)
Step auto-completion now always shows the suggestion popup, even when only one step matches, so the suggestion (including any parameter placeholders) can be reviewed before inserting
Text wrapped in <...> inside a doc string that does not match any Examples table column header is now rendered as plain doc-string text instead of being highlighted as an unresolved outline parameter

Fixed

Failed-step error gutter icons are now always hidden when the recorded outcome is stale, regardless of the "Show stale icons" setting; the setting continues to govern scenario, rule, and feature level icons
Indentation detection no longer overrides configured code style settings for .specb files, which could cause incorrect formatting (e.g., table rows moving to column 0)
Picking a step suggestion from the autocompletion popup now replaces the already typed step text instead of appending the chosen pattern to it
Gutter icons for Scenarios inside a Rule now correctly reflect the test execution state when the generated test class is abstract and a separate concrete subclass runs the tests
Feature and Rule gutter icons now stay red whenever any child scenario is recorded as failed, even after re-running only the passing siblings (which previously caused the container icon to incorrectly turn green)
The inline error panel and the inline HTML doc-string preview no longer show a spinner indefinitely when the embedded browser fails to render: a 5-second watchdog reveals the content at a fallback height, and an in-panel error message is surfaced if the browser reports a load failure

Removed

The "Duration" field has been dropped from the inline error panel; the error message, expected/actual values, and stack trace remain the on-demand failure summary, with the step's run time available in the standard run tool window if needed

0.9.0

April 26, 2026

Added

Re-running individual scenarios from the test results tree now correctly redirects to the concrete subclass when the test method is declared in an abstract generated class
Gutter run icons in feature files now also redirect to the concrete subclass when the generated test class is abstract
Run configuration names from feature files now show the Scenario/Rule/Feature title instead of the Java method name
Support for escaped double quotes (\") inside quoted step parameters, matching SpecBinder's escaping rules
Rename refactoring for annotation patterns with regex capture groups preserves captured values in step text

0.8.0

April 4, 2026

Added

Rename refactoring for Scenario Outline parameters — invoke Rename on a <parameter> placeholder or Examples table header to rename all occurrences within the same Scenario Outline

Fixed

Fix rename of step annotation patterns not propagating changes to matching step text in feature files

0.7.0

April 4, 2026

Changed

Updated Marketplace plugin description with comprehensive feature list

0.6.0

April 4, 2026

Fixed

Remove usage of deprecated IntelliJ Platform API

0.5.0

April 4, 2026

Added

Added autocompletion for Gherkin keywords
testing automated release process

0.2.1

March 11, 2026

Fixed

Fix crash when installed alongside the Cucumber/Gherkin plugin caused by conflicting TextAttributesKey names

0.2.0

March 11, 2026

Added

Ctrl/Cmd+Click navigation from feature file elements to SpecBinder-generated test classes
Ctrl/Cmd+Click navigation from Java test methods back to Gherkin steps
Auto-complete step text from Cucumber annotations and method names
Find Usages on Java step methods shows matching steps in feature files
Shift+F6 rename on Cucumber annotation strings updates step patterns across feature files
Gutter run icons on Feature/Rule/Scenario keywords with JUnit run configuration support
Structure tool window showing Feature/Rule/Scenario/Step outline
Code folding for Feature, Rule, Scenario, Background, Examples blocks
Code formatting with 2-space Gherkin indentation (Cmd+Alt+L)

0.1.0

March 11, 2026

Added

Gherkin syntax highlighting with per-keyword color customization
Color settings page (Settings > Editor > Color Scheme > Gherkin)

Added

Changed

Fixed

Removed

Added

Changed

Fixed

Changed

Fixed

Fixed

Added

Changed

Fixed

Added

Changed

Fixed

Removed

Removed

2026.10.0​

Added

Changed

Fixed

Removed

Added

Added

Fixed

Changed

Fixed

Added

0.2.1​

Fixed

0.2.0​

Added

0.1.0​

Added

2026.10.0

0.2.1

0.2.0

0.1.0