@revenexx/studio-integrations 1.2.0 → 1.4.0

package/CHANGELOG.md

@@ -1,5 +1,586 @@
 # @revenexx/studio-integrations
 
+## 1.4.0
+
+### Minor Changes
+
+- 388babd: Installing a template takes the same step from both routes into it (PO-244).
+
+  A template could be installed from two places, and the two gave the user different
+  workflows. From the "New workflow" dialog one press of a card installed it there and
+  then: the copy arrived under the template's own name, bound to none of the tenant's
+  credentials, with nothing said about either — and a refusal came back as a message
+  that disappeared. From the template's own page the same act named the copy first,
+  offered a credential per place that needs one, listed the secrets it references as
+  stored or missing, and kept a refusal on screen with what had been entered. Nobody
+  had decided that; the richer route simply arrived later.
+
+  The dialog's card now opens that same step in place of the list of templates, with
+  the way back to the list beside the name. Both routes therefore create the same
+  workflow, and it is created when the user confirms rather than when they press a
+  card. The step is one component reached from both places, so what it offers cannot
+  drift apart again, and while it works out what the template needs it says so —
+  "needs no credentials" and "not asked yet" used to look the same.
+
+  Two things a host should know. **Pressing a card no longer creates anything**, so a
+  test or a script that pressed one and waited for the editor now has to confirm the
+  step. And the template card has lost its `busy` and `disabled` props, which existed
+  for the install that used to start on the card itself; nothing acts on a card any
+  more.
+
+- 79f42db: The run replay replays the run it was handed, and nothing else (PO-350).
+
+  The replay carried a second mode, switched by a `single` prop: a 320 px sidebar
+  listing the workflow's runs to browse, beside the canvas. No route in the studio
+  ever mounted it — the run record took the replay over and passed `single` from the
+  day it did — so what shipped was a surface with a defect nobody could reach: asked
+  for a run it did not find among the most recent ones, it replayed the newest run
+  instead, under a label naming the newest run. A host mounting the component the way
+  its own prop documented got that, quietly.
+
+  The mode is gone. The replay now walks the run it is given, whatever else the
+  workflow has run, and with no run given it says so rather than choosing one. Runs
+  are browsed on the studio's own runs table, which filters, pages and offers the row
+  actions the sidebar never had — and the replay no longer asks for a run list it had
+  no use for.
+
+  `single` is still accepted and now ignored, so a host passing it keeps working; it
+  is deprecated and will be dropped at the next major. The four `runsList` strings
+  and the run-list failure message leave with the mode.
+
+  Two more strings stay but stop pointing at it: a panel given no run to replay used
+  to answer _Pick a run on the right to replay it._, where the right-hand side was
+  that sidebar. It now says _No run to replay._ — the state, rather than an
+  instruction with nothing to follow it.
+
+- 3ddba20: A workflow that leaves the run mode to its caller is asked which one, instead of
+  being run asynchronously (PO-428).
+
+  Pressing Run in the editor opened a dialog only where the workflow read something
+  from its trigger payload. A workflow whose execution mode is **Caller decides** and
+  whose nodes read no payload therefore never reached the offer at all: it was started
+  in the mode that does not wait, and a run whose result the author wanted to wait for
+  could not be started by hand. It now opens the same dialog, with both modes on it.
+  `mod+enter` follows the button, as it always has.
+
+  The dialog is named after the run rather than after the payload: **Run workflow**,
+  "Starts a manual run of this workflow. What it returns is shown here when it ends."
+  The payload is a field on it and names itself. The old description also still
+  promised the result on the Runs tab, which stopped being where it appears when the
+  dialog began showing what the run returned.
+
+  Where both modes are offered, the one that waits for the result is now the suggested
+  one, on the right, and it stays the suggested one however the last run was started —
+  the offer follows the workflow, not the last press. The mode words on the buttons are
+  unchanged.
+
+  Promised behaviour: `specs/run-from-editor.md` AC-1, AC-2 and AC-10.
+
+- 1cb60f7: Every key the workflow canvas answers can be read in one place, and one of them
+  could not be pressed on a German keyboard (PO-431).
+
+  **Press `?` on the canvas** for a list of its keys, grouped and written the way your
+  own keyboard is labelled. The canvas answers two dozen shortcuts, and until now
+  learning them meant hovering thirteen controls and right-clicking three different
+  things — two of them, activating the workflow and renaming a node with Space, were
+  shown nowhere at all.
+
+  **Zooming in now works on every layout.** The binding was `=`, which a German
+  keyboard types as Shift+0 — and a Shift the layout requires to produce a character
+  was being counted as part of the shortcut, so the key answered on a US keyboard and
+  on no other. A character key is now reached however a layout types it, while a
+  shortcut that means Shift over a letter still needs Shift held. **Zooming in is now
+  `+`** — the key a German keyboard has of its own and a US one reaches with Shift; the
+  old `=`, which only ever worked on a US layout, is gone rather than kept as a second
+  undocumented way in. Zooming out is `-`, as before.
+
+  **A modifier is spelled the way its platform spells it.** The command and option keys
+  already followed the platform; the shift key was the glyph ⇧ everywhere, so a Windows
+  or Linux reader got `Ctrl+⇧+G`. On those platforms it now reads `Ctrl+Shift+G`; on a
+  mac nothing changes.
+
+  Behind all three: the keys live in one list that the overview, the canvas's context
+  menu and the control pane's tooltips all read, so a key cannot be shown in one place
+  and answered in another. The menu had already drifted — it offered renaming as `F2`
+  for a key that answers `Space` too.
+
+  Promised behaviour: `specs/canvas-keyboard-shortcuts.md` AC-4, AC-5 and AC-6.
+
+- 4aa26a6: The editor points out an error output nobody connected, and attaches the ending
+  our own templates use (PO-443).
+
+  **A step that fails on a path nobody drew is not handled.** Most nodes have a red
+  error output; if the author never drew a line out of it, a failure there is not
+  carried anywhere. The platform now ends the run on it — but by then the workflow
+  has been running unattended for weeks. This is the half that says so while it is
+  still being drawn.
+
+  **A slate strip above the canvas names each step whose error output leads
+  nowhere**, and a line jumps to that step on the canvas. Deliberately not amber:
+  amber already means "fix this before it runs" in this editor twice over, and this
+  is not that.
+
+  **It blocks nothing.** Not activation, not saving, not starting a run. That is the
+  whole point of it being advice: the same fact expressed as a validation finding
+  would have closed the activation gate — and the run gate — on every workflow that
+  has an unconnected error output, including ones that have run nightly for months.
+  The rule is therefore computed in the editor, where no gate can read it.
+
+  **One click attaches the ending.** _Stop the run on error_ drops a Stop and Error
+  step below the node, wires it to the error output, and pre-fills its message the
+  way all eight shipped templates write theirs — the failing step by name, then its
+  own reason quoted out of the port that carried it. Nothing is saved until the
+  author saves; deleting the step undoes it.
+
+  A step nobody has connected yet is left alone, so laying out a workflow before
+  wiring it does not produce a wall of complaints. A step whose ports are named only
+  once its settings resolve is left alone too — nothing is claimed about an output
+  the declaration cannot name.
+
+  Promised behaviour: `specs/workflow-advice.md`, a new spec that owns what the
+  editor says about a workflow it has no objection to. `specs/workflow-validation.md`
+  keeps the gate, and the two now say so about each other.
+
+- 1a1edc3: A node's settings keep the order it declares them in, and only the tail is
+  folded (PO-463).
+
+  The node configuration dialog used to draw every required setting first and fold
+  every optional one away. That discarded the order the node author chose and made
+  requiredness stand for importance, which it cannot: the API refuses a required
+  setting that is empty, so a setting that is central and legitimately empty — Text
+  Replace's replacement, whose empty value is how a search value is deleted — had
+  to be optional, and therefore disappeared. Text Replace showed one of its six
+  settings, and not the one it is named after.
+
+  The Parameters tab now draws the settings a node declares as one list, in that
+  order. Four or fewer are all shown; beyond four the first three are always shown
+  and, from the fourth on, a setting is shown when it is required and folded when
+  it is not. The fold keeps its single control and its count, and now stands at the
+  first setting it hides, so opening it puts the tail back where the node declared
+  it. Counted over the 51 published core node types, 157 of 203 settings reach the
+  open form where 103 did before, and no node shows fewer than it did.
+
+  Nothing is required of a node package: the lever is the order a node already
+  declares. A node whose central setting still sits past the third — HTTP Request's
+  body, Send Email's two bodies — moves it up in its own manifest.
+
+- 633f3bf: The workflows list says whether it is grouped by tag, and now promises what
+  grouping does (PO-468).
+
+  Grouping the list by tag was offered by a button that read "Group by tags"
+  whether or not the list was already grouped — so pressing it once more ungrouped
+  a list whose control still invited grouping, and the only sign of the state was
+  the button's colour. It is now a switch: it shows whether grouping is on, to a
+  reader and to a screen reader alike.
+
+  Two behaviours the list already had are promises from here on, with tests behind
+  them: the grouping an operator chose is the one the list arrives in on the next
+  visit, kept in that browser alone, and a workflow carrying several tags stands
+  under each of them, with the untagged ones together under "No tags" at the end.
+  No shipped string changes.
+
+- 652a08f: Every canvas now zooms between the same two ends, and the editor no longer offers a
+  reach that shows nothing (PO-470).
+
+  The editor went to four times full size while the run replay and the history preview
+  stopped at twice. That was never decided: all three stopped at twice until the
+  editor's zoom picker was given a 400% preset and its ceiling was raised to match.
+  Asked what the extra reach was for, the answer turned out to be nothing — a step's
+  card carries a name, a version and a mark, and at four times full size a single card
+  fills the canvas without saying more than it did at half that.
+
+  So the editor comes down to twice full size, where the other two canvases already
+  were, and the 300% and 400% entries leave its zoom menu. The menu gains 25%, the
+  level the wheel could always reach and the list never offered — it now spans the
+  whole range, ends included. Anything typed into the zoom field beyond the range
+  still lands at the range's end rather than being refused.
+
+  Three criteria hold it from here on: the range on all three canvases, the clamping,
+  and the six levels the menu offers — 25%, 50%, 75%, 100%, 150% and 200%. That last
+  one is named rather than described on purpose: adding, removing or moving a level
+  changes what the editor offers an author, and it should take a decision rather than
+  a tweak.
+
+### Patch Changes
+
+- 2b6af97: Three copy-catalogue entries have their source back (PO-244).
+
+  The catalogue records where each shipped string is used, and recomputing those
+  references after the template install step moved lost three of them: the
+  publisher badges — Official, Partner, Community — are looked up through a map
+  rather than named in a `t()` call, so a scan for `t('…')` did not find them. A
+  unit test guards exactly that, and it is why this was caught on `main` rather
+  than by a reader finding an entry that points nowhere. No shipped string changes.
+
+- aff19fa: One answer to whether a response carries a `data` envelope, checked against the
+  service (PO-394).
+
+  Nine expressions in five composables each decided for themselves whether the
+  Integrations API had wrapped a single record, with a spelling that worked either
+  way — so nothing recorded which endpoints wrap, and a response in an unexpected
+  shape was handed to the caller as the envelope itself and drawn as empty fields.
+  They now share `unwrapRecord` and `unwrapList` in `src/runtime/utils/`, which
+  carry the service's rule as a table read from its controller bodies: **a
+  collection is wrapped in `data`, a single record is bare** — with templates as
+  the exception, because there the envelope follows the presenter rather than the
+  shape. A record that arrives in neither shape now fails visibly instead of
+  rendering blank, and the message a person sees is the page's own copy.
+
+  No promised behaviour changes. Three routes in the test mock answered a wrapped
+  record where the service answers a bare one — one of them contradicting a
+  contract this repository had signed a fortnight earlier — and now answer as the
+  service does; the envelope question is signed for the templates, workflows and
+  runs surfaces in `e2e/support/api-contract.json`.
+
+- 2db01ec: A step in a run's timeline opens on what it was handed and what it gave back (PO-421).
+
+  The **Show payloads** button is gone. It was a fetch switch dressed as a display
+  switch: a step opened on an instruction to press it, and pressing it re-read every
+  step of the run with its payloads, whether or not the operator went on to open a
+  second one. Opening a step now reads them itself, once, and says so while they are
+  on their way.
+
+  What comes back is kept per step scheduling and merged into the reads that keep a
+  live run current, so the three-second poll neither blanks an open step nor goes back
+  to storage for payloads it already has. A step opened while it was still running is
+  read once more when it ends, and only then — the status a payload was read in is
+  what decides, so a step that legitimately returned nothing is not re-read on every
+  poll, and a read that failed is not retried three seconds later.
+
+  A failed payload read now leaves the timeline standing and says so inside the open
+  step. Before, it shared the read that draws the list of steps, which empties that
+  list when it fails.
+
+  Promised behaviour: `specs/run-detail.md` AC-7, and AC-15 for what an open step keeps
+  while its run goes on.
+
+- 122659e: An option that stands for no choice can be chosen, and no longer takes the node
+  dialog with it (PO-422).
+
+  A node may offer "no choice" as an entry in a list — the format the file came in as,
+  unchanged, all kinds — by declaring an option with an empty value. Three published
+  node types do. The control underneath the studio's lists reserves the empty value for
+  "nothing selected" and refused the entry outright: the list did not open, and the
+  refusal tore down the dialog's dismissal machinery on its way out. From that click
+  on, the next list opened anywhere in the form stayed open — Escape and a click
+  outside both did nothing — and the only way out was to abandon the dialog with
+  everything half set in it.
+
+  Such an option is now carried through the list under a substitute value and written
+  back as the empty string the node reads. It keeps its own label and its place, and it
+  is still there once another option has been chosen, so a setting given a value can be
+  put back to no choice. A setting the platform is holding as nothing — the empty string
+  comes back as null — reads as that option rather than as a placeholder; a setting the
+  workflow holds nothing at all for still reads as the placeholder, because no choice
+  has been made.
+
+- 107db51: Running a run again, above an open run's record, is offered for a run that failed
+  (PO-427).
+
+  It used to be offered for every run that had ended, a successful one included, under
+  the word **Retry** — and the press does not repeat that run: it starts a fresh run of
+  the workflow as it is saved now, carrying the old run's trigger payload. Over a run
+  that had succeeded, that meant doing everything the run already did to the systems at
+  the far end, behind a word saying nothing had happened yet. The button now reads **Run
+  again**, says in its title what it really runs, and stands over a failed run only. A
+  run's own row still offers it whatever the outcome, from behind its actions menu.
+
+  A press that the platform accepts now leaves the operator looking at the run it
+  started, instead of on the run they had just replaced with only a message naming the
+  new one. Stepping back returns to the run that failed, so the two can be compared —
+  and because the run just started is not over, the button that started it is gone
+  rather than standing ready to start a third.
+
+  Promised behaviour: `specs/run-detail.md` AC-16 and AC-17.
+
+- 4a90a4b: A setting inside a list row is drawn as what it declares, and a new row starts from
+  what the node declared (PO-436).
+
+  A node setting that sits inside a repeating row was always drawn as an empty text
+  box, whatever its manifest said: the choices it offers, its default, whether it is
+  required, the sentence under it. The manifest schema permits all of that on a nested
+  setting and the engine reads it — only the form stopped one level short. Each
+  sub-setting is now drawn by the same renderer the rest of the form uses, so a
+  declared choice arrives as a list of its named options, a boolean as a switch, an
+  expression-capable setting as the mapping control, each with its own description and
+  required marker. Every control in a row still says which setting and which row it
+  belongs to, so a screen reader can still tell two rows apart.
+
+  The sharper half was the seeding. A new row was created with an empty string under
+  every one of its keys, which is a value rather than an absence — so a node's own
+  default could not apply, and the one published node with a choice inside its rows
+  (Set Fields) stopped every run with `Unknown operation ""` until the author guessed
+  one of three words nothing on screen named. A new row now carries each sub-setting's
+  declared default and leaves a setting that has none out of the row entirely.
+
+  One kind of setting is still withheld inside a row: the kind whose options — or
+  whose whole set of settings — the platform is asked for while the dialog is open.
+  That request carries the values the setting belongs to, and a row is not those
+  values. No published node declares one there.
+
+  **And a row's settings now answer their own conditions.** A node may say that one setting
+  in a row means something only under one of another's choices — Set Fields says it about
+  the value it writes and about the path it moves a field to. That condition was read by the
+  platform when it judged a saved workflow and by nothing on screen, so both boxes stood
+  under every action, each explaining in its own small print when it counted.
+
+  The condition is read against **the row**, which is where the node wrote it and where the
+  platform resolves it: two rows of one list show different settings, each according to its
+  own choice. And what was typed into a setting a row withdraws goes with it, in that row
+  alone — a value nowhere on screen is a value nobody can correct, and it would otherwise be
+  saved and read as though the author had meant it.
+
+  AC-27 and AC-28 gained the clause, and the gap the spec recorded about a row is closed. A
+  group is now the one shape left where a declared condition has nothing to hide.
+
+- c0d4083: The view a workflow opens on is fitted to the canvas as it actually is (PO-446).
+
+  `fitView` reads the canvas out of the DOM, and it was being asked before Vue's
+  pending changes had been applied — the band above the canvas that points out an
+  unconnected error output among them. So the drawing was placed for a canvas a
+  frame out of date, and the same workflow opened at two different zooms depending
+  on which side of that frame it landed: measured at `scale(0.717)` with the layout
+  settled and `scale(0.626)` without.
+
+  At the smaller zoom the drawing sits far enough to the left that a step — or a
+  connection dot on one — can end up behind the node palette, and a card behind a
+  panel takes no pointer at all: it can be seen, and clicking it does nothing. The
+  opening view is now placed after the layout has settled, so a workflow opens the
+  same way every time.
+
+  What this does not do is stop a panel covering a card where the drawing genuinely
+  reaches under one. That is the older question PO-443 left open — the fit knows
+  nothing about what floats over the canvas — and it stays open, with what two
+  attempted fixes cost measured in PO-446.
+
+- 9f155b3: A run's record offers the addresses in its result whole or not at all: every one of
+  them where there are at most fifty, none where there are more. It used to offer the
+  first eight and drop the rest without saying so. Promised by `specs/run-detail.md`
+  AC-19.
+- 6a9a97f: The workflow editor's header survives a long workflow name (PO-461).
+
+  Beside a name too long for the room, the badge saying how the workflow
+  dispatches was cut off mid-word, and the two status texts next to Save — the
+  chip reporting a queued build and the unsaved-changes marker — broke onto a
+  second line inside boxes one line high, so their text ran over its own border.
+  The breadcrumb was laid out inline, so it sized to its content rather than to
+  the heading it sits in and nothing in it ever shrank; the two status texts were
+  the only items in the actions row not drawn as buttons, and so the only two that
+  could wrap. The name is now the only thing in the header that gives way, and it
+  gives way as an ellipsis — with the whole of it on the name itself, so pointing
+  at a shortened name shows what was cut.
+
+  The control that folds the studio navigation away is icon-only while the
+  navigation is standing, and carries its words again once it is folded — the way
+  back is the direction that needs them. Its accessible name is unchanged in both
+  directions, so anything addressing it by name is unaffected.
+
+- 7bb3a25: Space renames a node on the canvas, which the Keyboard shortcuts list has been
+  promising since it existed (PO-472).
+
+  **Press `Space` on a selected node** and its configuration opens with the name
+  selected, exactly as `F2` does. The list under `?` has offered both keys all along,
+  and the second of them answered nothing: the library that draws the canvas binds
+  Space as a pan key of its own, on the document, and claimed the keystroke before the
+  canvas's own bindings were consulted. That pan key is now switched off, and holding
+  Space gains rather than loses: with the key claimed, Space over a drag neither panned
+  the canvas nor drew the selection rectangle, so the gesture did nothing at all. The
+  one thing that changes is Space held over the scroll wheel, which zooms now instead
+  of panning, the way the wheel alone already did.
+
+  **Every key in that list is now pressed by a test.** The test this shipped past
+  read the `Space` cap out of the list and never pressed it — and it was not alone:
+  of the twenty-six gestures the list offers, ten were proven by a test that pressed
+  them and sixteen were not, `Space` among the sixteen. All sixteen have one now, so
+  the surface built so that the list and the keyboard could not disagree is checked in
+  the direction that matters.
+
+  Promised behaviour: `specs/canvas-keyboard-shortcuts.md` AC-7.
+
+- 3d07d03: Six behaviours the studio already had are now promises with tests behind them
+  (PO-475).
+
+  Nothing ships differently. What changes is what may change silently afterwards:
+  each of these was deliberate in the code, visible on screen, and held by no test,
+  so any of them could have gone the day somebody touched the surface.
+
+  - **A credential cannot be saved without a name**, and picking a system fills one
+    in so nobody starts from an empty field. Clearing it puts saving out of reach
+    again.
+  - **A node's mark is the same wherever the node is named in full** — on the canvas,
+    in the header of its own configuration, and in a template's drawing of the flow
+    it installs.
+  - **A node the catalogue marks with nothing is still marked**, with the same
+    generic mark every such node gets. Nothing in today's catalogue is in that state,
+    so this had never been seen.
+  - **A node whose type this installation does not know still opens.** It says it has
+    no configuration, and the settings the engine applies around every node are still
+    there — which is what makes a workflow with a withdrawn package repairable.
+  - **A double-click zooms the run replay and the history preview.** Neither carries
+    a zoom control, so it is the only way in; the editor answers the same gesture by
+    opening a node, which is why it turns the zoom off and these two do not.
+  - **A group folded shut is drawn open on those two surfaces.** A fold is how an
+    author makes their own canvas fit; a replay answers which nodes ran.
+
+  Promised behaviour: `specs/credential-create.md` AC-10, `specs/node-marks.md` AC-5
+  and AC-6, `specs/node-configuration.md` AC-32, `specs/readonly-canvases.md` AC-4,
+  `specs/group-frames.md` AC-11.
+
+## 1.3.0
+
+### Minor Changes
+
+- 593c0d5: A step can be changed onto another version of its node
+
+  The editor could say precisely that a step sat on a node version the platform
+  cannot run, and name the version that would work — and there it stopped. Getting
+  there meant deleting the step and inserting a fresh one, which throws away its
+  settings, its name, its note and its connections.
+
+  The version is now a control wherever there is somewhere to go, and two states
+  reach it. Where the pinned version cannot run, the red notice keeps every word it
+  had and gains the button it was missing. Where the step runs fine and a newer
+  version exists, one grey line in its dialog says so — **and nothing else does**.
+  No mark on the canvas card: nothing is wrong there, and a fourth mark for a
+  non-problem is what teaches an operator to stop reading marks. A node with a
+  single usable version says nothing at all.
+
+  Older versions are offered too, not only newer ones. A version that turns out to
+  behave badly otherwise has no way back.
+
+  **What the change costs is said before it happens.** The two versions are read
+  against the settings the step actually holds, and split three ways: what travels,
+  what the chosen version does not have and will be taken out, and what arrives
+  needing an eye — a setting it requires and the step has no answer for, or one
+  whose type or choices moved. A setting nobody filled in appears nowhere; there is
+  nothing to lose. A change that costs nothing says so in a sentence rather than
+  showing three empty lists, and where the version being left is no longer in the
+  catalogue the answer says the two could not be compared at all.
+
+  Values the chosen version does not declare are removed rather than left behind.
+  The service keeps such a key on save without complaint, so it would otherwise sit
+  in the workflow as invisible dead data.
+
+  Nothing about the step's identity moves: same id, same connections, same name,
+  same note, same place on the canvas. It lands as an unsaved change like editing
+  any setting, so discarding the editor's changes undoes it.
+
+  Promised as `specs/node-configuration.md` AC-24 to AC-26. `specs/node-palette.md`
+  AC-7 gains the clause that the version it names is somewhere the step can
+  actually go, and loses the gap entry that described the dead end.
+
+- bb8a80a: Declare what a workflow may remember between runs (PO-374).
+
+  A new **State** entry in the editor's floating control pane (Shift+T) opens a
+  dialog for the blob's `state` block: each namespace with its role — mapping,
+  cursor, dedupe or digest — and whether it belongs to this workflow alone or to
+  every workflow in the tenant. The engine mints a run's grant from exactly this
+  list, so until now a workflow could not reach the state store from the studio at
+  all.
+
+  The role is chosen when the namespace is added and stated as text afterwards:
+  entries written with one meaning cannot be read back with another. What sharing
+  costs — tenant-wide reads _and_ writes, and a namespace that outlives this
+  workflow — is on screen next to the control that chooses it.
+
+  Also fixes a silent loss in both directions of the workflow mapper, which
+  enumerates blob keys one by one: `state` was neither read from the API nor sent
+  back on save, so a declaration made anywhere else would have disappeared on the
+  next save from the studio.
+
+  A node setting of the new type `state-ref` picks one of the workflow's declared
+  namespaces **of that setting's kind**, and declares a new one from inside the
+  picker — the same shape a `credentials-ref` has, so the author never leaves the
+  node to type a name that nothing would have compared.
+
+  A namespace declared inside the picker waits in the node's draft until the
+  inspector keeps it — Save, or prev/next — so Esc discards the declaration
+  together with the setting that named it, and the workflow does not report
+  unsaved changes for something nobody chose to keep.
+
+  A node's test run now names the workflow being edited, which lets it read that
+  workflow's namespaces. Writes stay refused at author time.
+
+  Promised behaviour: `specs/state-namespaces.md`.
+
+- ddff18a: A setting that cannot apply is no longer put in front of the author
+
+  A node can now say in its manifest when one of its settings applies — another
+  setting's key, an operator, and the value to compare against — and the
+  configuration form draws it only while that holds. Until now the only thing
+  warning an author off a meaningless field was a sentence in small print under
+  it, which they read last, having already filled it in. Date Time's **Source**
+  is the plainest case: under "Now" it still asked which field to read the date
+  out of.
+
+  What changed on screen:
+
+  - A setting whose condition does not hold is not drawn, and is not counted
+    among the optional ones either — a fold that offers four settings and shows
+    three teaches the reader to distrust the number.
+  - What was typed into a setting that stops applying is dropped, the same
+    cascade the studio already runs for a setting whose options another one
+    resolves. A value nowhere on screen is a value nobody can correct.
+  - Settings a node resolves while the author edits are treated the same way.
+
+  The words a condition is written in are the fourteen the condition and filter
+  nodes already offer — `equals`, `isEmpty`, `contains`, `>` and the rest — so an
+  author who has met them in one place does not learn a second set for the other.
+  `specs/node-configuration.md` AC-27 and AC-28 carry the promise.
+
+  Nothing changes for a node that says nothing: every setting is drawn exactly as
+  before. A condition written on a setting _inside a group_ is not honoured here —
+  a group is drawn as one value editor rather than as its own settings — and that
+  is written into the spec's Gaps rather than left to be discovered.
+
+### Patch Changes
+
+- 4dd5b12: The answer that keeps unsaved work is legible, and is the one the question emphasises
+
+  Leaving a workflow with unsaved changes asks whether to discard them, and the
+  question offers two answers. Only one of them looked like an answer: "Keep editing"
+  was drawn in a colour its own background shares, so it read as an empty button beside
+  "Discard and leave" and its label appeared only once the pointer rested on it. Which
+  is the wrong half of the dialog to hide — that button is the one the keyboard lands
+  on, so the answer the question exists to make easy was the answer nobody could see.
+
+  It is now drawn as the filled answer, the way every other dialog in the module draws
+  the answer on the right, so the question also says which answer it falls back to. The
+  cause was two button variants on one element: the dialog's cancel element applies the
+  outline variant itself, and the button inside it was left on the default one, so the
+  merge took the background from the first and the text colour from the second. Nothing
+  else about the question moves — the wording, the keyboard default and what each answer
+  does are unchanged.
+
+  Promised as `specs/workflow-save.md` AC-13 and AC-14: the label is checked as a
+  contrast ratio against the button it sits on, unhovered, and the emphasis as a
+  difference between the two answers' surfaces rather than against a class name or a
+  colour value.
+
+- ab2eb96: A build state stops saying "still building" wherever it is shown
+
+  Saving a workflow queues the platform to build an executable bundle from it, and
+  until that build lands the workflow cannot run. Two surfaces say so: the chip beside
+  Save in the editor, and the build column in the workflows list. Only the editor's
+  ever became true on its own — the list said whatever its last read said, so a
+  workflow that finished building while the list stood open kept reading "Building…"
+  until something reloaded the page. Save in the editor, come back to the list, and the
+  row never moved.
+
+  The list now watches a build out the way the editor does: one read of the tenant per
+  turn, so thirty workflows building at once cost what one costs, and it stops as soon
+  as nothing is waiting. A platform build report still makes it quicker where there is
+  one; nothing depends on one arriving any more, on either surface.
+
+  The two waits now share one interval and one ceiling instead of the editor owning
+  both, so neither surface can drift into asking twice as often as the other.
+
+  Promised as `specs/workflow-build.md`, a new spec for the subject: what becomes of a
+  saved workflow before it can run. AC-1 is the editor's promise, moved out of
+  `specs/workflow-save.md`, where a reader asking what a build state means would not
+  have looked; AC-2 is the list's. `specs/realtime-updates.md` AC-7 keeps the
+  announcement half and now says which of the two makes a build state true.
+
 ## 1.2.0
 
 ### Minor Changes

package/dist/module.json

@@ -1,7 +1,7 @@
 {
   "name": "@revenexx/studio-integrations",
   "configKey": "studioIntegrations",
-  "version": "1.2.0",
+  "version": "1.4.0",
   "builder": {
     "@nuxt/module-builder": "1.0.2",
     "unbuild": "unknown"

package/dist/runtime/components/Integrations/CanvasShortcutsDialog.d.vue.ts

@@ -0,0 +1,9 @@
+type __VLS_Props = {
+    open: boolean;
+};
+declare const _default: import("vue").DefineComponent<__VLS_Props, {}, {}, {}, {}, import("vue").ComponentOptionsMixin, import("vue").ComponentOptionsMixin, {
+    "update:open": (args_0: boolean) => any;
+}, string, import("vue").PublicProps, Readonly<__VLS_Props> & Readonly<{
+    "onUpdate:open"?: ((args_0: boolean) => any) | undefined;
+}>, {}, {}, {}, {}, string, import("vue").ComponentProvideOptions, false, {}, any>;
+export default _default;

package/dist/runtime/components/Integrations/CanvasShortcutsDialog.vue

@@ -0,0 +1,53 @@
+<script setup>
+import { computed } from "vue";
+import { Dialog, DialogContent, DialogDescription, DialogHeader, DialogTitle } from "@revenexx/studio";
+import { CANVAS_SHORTCUTS, SHORTCUT_GROUPS, SHORTCUT_GROUP_LABELS, shortcutCaps } from "../../data/canvasShortcuts";
+import { formatShortcut } from "../../utils/shortcutLabel";
+defineProps({
+  open: { type: Boolean, required: true }
+});
+const emit = defineEmits(["update:open"]);
+const t = useIntegrationsT();
+const groups = computed(() => SHORTCUT_GROUPS.map((group) => ({
+  group,
+  label: t(SHORTCUT_GROUP_LABELS[group]),
+  items: CANVAS_SHORTCUTS.filter((s) => s.group === group).map((s) => ({
+    id: s.id,
+    label: t(s.labelKey),
+    // One cap per gesture, in the platform's own alphabet.
+    caps: shortcutCaps(s.id).map((k) => formatShortcut(k))
+  }))
+})).filter((g) => g.items.length > 0));
+</script>
+
+<template>
+  <Dialog :open="open" @update:open="(v) => emit('update:open', v)">
+    <DialogContent class="max-w-[94vw] sm:max-w-2xl">
+      <DialogHeader>
+        <DialogTitle>{{ t("integration.canvas.shortcuts.dialog.title") }}</DialogTitle>
+        <DialogDescription class="text-sm">
+          {{ t("integration.canvas.shortcuts.dialog.description") }}
+        </DialogDescription>
+      </DialogHeader>
+
+      <div class="grid max-h-[70vh] gap-x-8 gap-y-5 overflow-y-auto sm:grid-cols-2">
+        <section v-for="g in groups" :key="g.group" class="min-w-0">
+          <h3 class="mb-1.5 text-xs font-semibold uppercase tracking-wide text-muted-foreground">
+            {{ g.label }}
+          </h3>
+          <ul class="space-y-1">
+            <li v-for="item in g.items" :key="item.id" class="flex items-baseline justify-between gap-3 text-sm">
+              <span class="min-w-0 truncate">{{ item.label }}</span>
+              <span class="flex shrink-0 items-baseline gap-1">
+                <template v-for="(cap, i) in item.caps" :key="cap">
+                  <span v-if="i > 0" class="text-xs text-muted-foreground">{{ t("integration.canvas.shortcuts.or") }}</span>
+                  <kbd class="rounded border border-black/[0.08] bg-slate-50 px-1.5 py-0.5 text-xs tabular-nums text-foreground">{{ cap }}</kbd>
+                </template>
+              </span>
+            </li>
+          </ul>
+        </section>
+      </div>
+    </DialogContent>
+  </Dialog>
+</template>