@webship.co/workspace 1.0.0-beta1 → 1.0.0-rc1

package/core/workspace-app/tests/features/actions-rail.feature

@@ -0,0 +1,44 @@
+Feature: The actions rail
+  The rail on the right of every page collapses to its icons and remembers the choice.
+
+  # This exists because the feature was broken by having TWO of it. A delegated handler near the
+  # top of ui.js toggled the class and wrote `actions-collapsed`; a second implementation at
+  # the bottom, from another line of work, bound its own listener to the same button, read the
+  # already-toggled class and toggled it straight back. Every click undid itself a millisecond
+  # later, so the rail simply did not move. Nothing in the suite noticed, because nothing asserted
+  # what a click DOES — only that the button was on the page.
+  #
+  # So these assert the state after the click, in both directions, and that it is remembered.
+
+  Scenario: The rail starts collapsed, because the page wants the width more than the labels do
+    Given I am on "/dev"
+     Then the element "#actions-rail" should be displayed
+      And the element ".actions-toggle" should be displayed
+      And the element "html" with the attribute "class" and the value containing "actions-collapsed" should exist
+      And the element ".actions-toggle" with the attribute "aria-expanded" and the value "false" should exist
+
+  Scenario: Clicking the toggle expands it
+    Given I am on "/dev"
+     When I click on the element ".actions-toggle"
+     Then the element "html" with the attribute "class" and the value containing "actions-collapsed" should not exist
+      And the element ".actions-toggle" with the attribute "aria-expanded" and the value "true" should exist
+      And I should see "All workspaces"
+
+  Scenario: Clicking it again collapses it — the click is not undone by a second handler
+    Given I am on "/dev"
+     When I click on the element ".actions-toggle"
+      And I click on the element ".actions-toggle"
+     Then the element "html" with the attribute "class" and the value containing "actions-collapsed" should exist
+      And the element ".actions-toggle" with the attribute "aria-expanded" and the value "false" should exist
+
+  # A layout preference that resets on every navigation is one you set on every page.
+  Scenario: The choice survives a navigation
+    Given I am on "/dev"
+     When I click on the element ".actions-toggle"
+      And I am on "/settings"
+     Then the element "html" with the attribute "class" and the value containing "actions-collapsed" should not exist
+
+  Scenario: The rail is on the settings page too, not only on a workspace page
+    Given I am on "/settings"
+     Then the element "#actions-rail" should be displayed
+      And the element ".actions-toggle" should be displayed

package/core/workspace-app/tests/features/ai-items.feature

@@ -0,0 +1,23 @@
+Feature: Installing agents, skills and prompts
+
+  Scenario: An item can be installed into the global Claude Code, or into one project
+    Given I am on "/ai-agents"
+     Then "select[name='toWorkspace']" should be attached
+      And "select[name='toProject']" should be attached
+      And "[hx-post='/actions/install-item']" should be attached
+
+  # htmx 4 fires after:swap on the element that MADE the request, not on the one
+  # swapped — so a listener reading e.target saw the button and never opened the
+  # modal. The content had loaded; nothing appeared.
+  Scenario: Editing a prompt opens the editor with its text in it
+    Given I am on "/ai-prompts"
+     When I click on the element "[hx-get^='/fragments/ai-prompts/edit/'] >> nth=0"
+     Then "#editor-modal.uk-open" should be visible
+      And "#editor-modal .ace_editor" should be visible
+      And "#editor-modal form[hx-post='/actions/save-item']" should be attached
+
+  Scenario: The same Edit works on the agents workspace
+    Given I am on "/ai-agents"
+     When I click on the element "[hx-get^='/fragments/ai-agents/edit/'] >> nth=0"
+     Then "#editor-modal.uk-open" should be visible
+      And "#editor-modal .ace_editor" should be visible

package/core/workspace-app/tests/features/assistant-speech.feature

@@ -0,0 +1,63 @@
+Feature: Talking to the assistant
+  The panel takes dictation and reads its answer back. Both are the browser's own — no key, no
+  service, nothing leaves the machine — so what is asserted here is that the component was actually
+  handed a working configuration, not that a remote service replied.
+
+  # Asserting the button EXISTS, not that speech works: a scenario cannot speak, and a browser will
+  # not grant a microphone to an automated run. What can go wrong without anyone noticing is the
+  # button being absent, or present with a config deep-chat silently ignored — so that is the target.
+  Scenario: The assistant offers a microphone
+    Given I am on "/"
+     Then "deep-chat" should be attached
+      And the assistant should offer voice input
+      And the assistant should read its replies aloud
+
+  # The microphone is what says voice is available. It used to be said in the placeholder as well
+  # ("Ask about dev… (or use voice)"), but the composer ships with no placeholder at all now: an
+  # empty field with a cursor in it already says "type here", and a prompt that suggests what to ask
+  # narrows what gets asked. So the button has to be there AND have a name — an icon-only control
+  # with no accessible name is a button a screen reader announces as nothing.
+  Scenario: The microphone is there, and it is named
+    Given I am on "/"
+     Then the assistant should show a named microphone button
+
+  # Nothing drawn in the box, and the box still has a name. These are one scenario because they are
+  # in tension: deep-chat resolves the placeholder as `text || "Ask me anything!"`, so an empty
+  # string does not remove its placeholder, it restores deep-chat's — and the text it is given also
+  # becomes the composer's aria-label. Removing what is drawn without removing the name is the whole
+  # trick, and either half alone is a bug.
+  Scenario: The composer shows no placeholder, and is still named
+    Given I am on "/"
+     Then the assistant composer should draw no placeholder
+      And the assistant composer should have an accessible name
+
+  # The recogniser's language is the setting that decides whether dictation works in a second
+  # language at all: left on the wrong one it does not fail, it returns confident nonsense. So a
+  # language is always pinned rather than inherited — en-US ships, and the dropdown offers the rest.
+  Scenario: A dictation language is always pinned, never left to chance
+    Given I am on "/"
+     Then the assistant speech language should be pinned
+
+  # An empty phrase is not a disabled command. If `commands` were built from blank strings, a
+  # command could fire on almost anything dictated — so with none configured the key must be absent.
+  Scenario: No voice commands are armed unless one is configured
+    Given I am on "/"
+     Then the assistant should have no voice commands
+
+  Scenario: Voice styling follows the theme rather than deep-chat's stock colours
+    Given I am on "/"
+     Then the assistant speech colours should be design tokens
+
+  # The panel is on every workspace page, not only the home page, and its context travels with it.
+  Scenario: A workspace page gets the same microphone
+    Given I am on "/dev"
+     Then "deep-chat" should be attached
+      And the assistant should offer voice input
+
+  # A browser with no synthesis voices accepts speak(), fires error: synthesis-failed, and is silent.
+  # Nothing reported it, so "read replies aloud" looked switched on and did nothing at all — the worst
+  # state a setting can be in.
+  Scenario: The settings file editor says which voices this browser actually has
+    Given I am on "/settings/settings.yml"
+     Then "[data-voice-name]" should be attached
+      And the voice list should report what this browser has

package/core/workspace-app/tests/features/checks.feature

@@ -0,0 +1,40 @@
+Feature: The checks a project already declares
+  Every package here carries its own quality scripts. The dashboard offers them without inventing any.
+
+  # One quality menu, not two. On a packages workspace there is no browser suite at all, and on a
+  # site there was no checks control — a separate button would have been the only one present in
+  # each case. They live together under Tests, with the checks nested inside it.
+  Scenario: A package row offers its checks inside the Tests menu
+    Given I am on "/products"
+     Then the element ".project-row .act-menu-tests" should be displayed
+      And ".act-menu-tests .act-menu-checks" should be attached
+      And I should see "Tests"
+
+  Scenario: The button says what the package covers without running anything
+    Given I am on "/products"
+     Then the element ".act-menu-tests + .act-status" should be displayed
+      And "[hx-post='/actions/checks-plan']" should be attached
+
+  # The pair is the point: the canonical name is what you type (--only js), the code beside it is
+  # the script the package itself declared. Listing them together is how the mapping is checkable.
+  Scenario: The nested menu lists each alias against the script it runs
+    Given I am on "/products"
+     Then ".checks-sub" should be attached
+      And ".checks-sub .checks-alias" should be attached
+      And ".checks-sub .checks-script" should be attached
+
+  @needs-check-aliases
+  Scenario: Each alias can be run on its own, and so can all of them
+    Given I am on "/products"
+     Then "[hx-post='/actions/checks']" should be attached
+      And "[hx-vals*='only']" should be attached
+
+  # A site gets the same nested list: its package.json declares the same vocabulary, and its
+  # ddev-dev-tools add-on adds the PHP and Twig checks on top.
+  @needs-testing-stack
+  Scenario: A site keeps its testing verbs and gains the checks beside them
+    Given I am on "/dev"
+     Then the element ".project-row .act-menu-tests" should be displayed
+      And "[hx-post='/actions/testing-configure']" should be attached
+      And "[hx-post='/actions/testing-run']" should be attached
+      And ".act-menu-tests .act-menu-checks" should be attached

package/core/workspace-app/tests/features/clone-project.feature

@@ -0,0 +1,30 @@
+Feature: Cloning a project
+  The clone modal validates before anything runs, and never clones over an
+  existing project or a name DDEV already tracks.
+
+  Scenario: The DDEV menu offers the clone
+    Given I am on "/dev"
+     Then "[hx-get^='/fragments/projects/clone-form/dev/']" should be attached
+
+  Scenario: The form arrives prefilled, with the live check wired
+    When I open the clone form of the first project in "dev"
+     Then the clone form proposes a copy of that project
+      And "select[name='toWorkspace']" should be attached
+      And "[hx-get='/fragments/projects/clone-check']" should be attached
+      And "textarea[name='prompt']" should be attached
+
+  Scenario: The live check refuses an existing project
+    When I ask the live check about the name of the first project in "dev"
+     Then I should see "already exists"
+
+  Scenario: The live check blesses a free name
+    Given I am on "/fragments/projects/clone-check?to=surely-free-name-zz&toWorkspace=dev"
+     Then I should see "is free"
+
+  Scenario: Cloning over an existing project is refused server-side too
+    When I post a clone of the first project in "dev" over itself
+    Then the action response should contain "already exists"
+
+  Scenario: A source that does not exist is refused
+    When I post "/actions/clone-project" with '{"workspace":"dev","projectName":"no-such-src","to":"whatever-zz","toWorkspace":"dev"}'
+    Then the action response should contain "Project not found"

package/core/workspace-app/tests/features/command-authoring.feature

@@ -0,0 +1,58 @@
+Feature: Writing and changing the workspace commands
+  A cmd-*.sh is executed by the dashboard and by a terminal, so nothing changes one unreviewed.
+
+  Scenario: A new command can be given a purpose, not just a name
+    Given I am on "/settings/commands"
+     Then I should see "New command"
+
+  # The scaffold alone is a correct command that does nothing. Saying what it is FOR is what makes it
+  # a command for that thing — the assistant reads the workspace's own conventions and writes it.
+  Scenario: The new-command form asks what the command should do
+    Given I am on "/fragments/commands/new"
+     Then "textarea[name='purpose']" should be attached
+      And "input[name='newName']" should be attached
+      And "select[name='target']" should be attached
+
+  Scenario: The editor offers the assistant a change to make
+    Given I am on "/fragments/commands/edit/dev/cmd-tools-checks.sh"
+     Then "textarea[name='instruction']" should be attached
+      And ".cmd-ai-row .field-mic" should be attached
+      And "[hx-post='/actions/command-ai']" should be attached
+      And I should see "Ask"
+
+  # The command is still what gets saved by hand: the assistant is an extra way in, not the only one.
+  Scenario: The editor still edits the command directly
+    Given I am on "/fragments/commands/edit/dev/cmd-tools-checks.sh"
+     Then "textarea[name='content']" should be attached
+      And "[hx-post='/actions/command-save']" should be attached
+      And I should see "bash -n"
+
+  # 239 commands is too many to scroll. Searching matches the file name, the human name AND the
+  # description, because "reclaim" and "back up" are what somebody types and neither is a file name.
+  # A file name is a string you are about to type. In the body font it reads as prose and loses its
+  # word boundaries, and cmd-tool-backup-product.sh has a lot of boundaries.
+  Scenario: File names are shown as code wherever they appear
+    Given I am on "/fragments/commands/edit/dev/cmd-tools-checks.sh"
+     Then "h3 code.fname" should be attached
+      And "p code.fname" should be attached
+
+  Scenario: Commands can be searched and narrowed to one workspace folder
+    Given I am on "/commands"
+     Then "input[name='q']" should be attached
+      And "select[name='source']" should be attached
+      And ".cmd-title" should be attached
+      And ".cmd-file" should be attached
+
+  # Every list in the app 500d the moment `auto` reached the query, which is the first click of the
+  # auto-search checkbox: lists.js called hubDomain() without importing it.
+  Scenario: A list survives the auto-search preference being sent
+    Given I am on "/fragments/commands/list?q=backup&ws=all&auto=0&page=1"
+     Then ".cmd-title" should be attached
+
+  # Six action buttons and a full sentence on the same line squeezed each other into two-word
+  # columns. What a command is reads first; what you can do to it follows underneath.
+  Scenario: A command row reads top to bottom, with its actions on their own line
+    Given I am on "/settings/commands"
+     Then ".cmd-row-stack" should be attached
+      And ".cmd-row-stack .cmd-id" should be attached
+      And ".cmd-row-stack .project-actions" should be attached

package/core/workspace-app/tests/features/dashboard.feature

@@ -0,0 +1,57 @@
+Feature: The workspace dashboard
+  The pages a person opens every day, asserted against the running site.
+
+  Scenario: The hub lists the workspaces
+    Given I am on "/"
+     Then the element "#workspace-cards" should be displayed
+      And the element ".ws-card-wrap" should be displayed
+      And I should see "Products"
+      And I should see "Dev"
+      And I should see "RAG"
+
+  Scenario: A card carries the handle that reorders it
+    Given I am on "/"
+     Then the element ".ws-card-handle" should be displayed
+      And the element "#workspace-cards" with the attribute "data-sortable" and the value containing "ws-card-wrap" should exist
+
+  Scenario: A workspace page offers its builder and its projects
+    Given I am on "/dev"
+     Then I should see "Build a new project"
+      And the element ".project-row" should be displayed
+      And the element "select" should be displayed
+
+  Scenario: The settings file editor is reachable and shows the style block
+    Given I am on "/settings/settings.yml"
+     Then I should see "Workspace name"
+      And I should see "theme"
+
+  Scenario: The assistant panel is on the page it belongs to
+    Given I am on "/"
+     Then I should see "AI Assistant"
+
+  # It is ONE assistant, whose conversation follows you between workspaces — the thread id is a
+  # cookie on the hub domain for exactly that reason. The panel used to prefix the workspace it was
+  # scoped to ("Dev AI Assistant"), which read as a different assistant on every page. The scope is
+  # still shown, where it belongs: in the command picker, which carries that workspace's commands.
+  Scenario: The assistant is called the same thing on a workspace page
+    Given I am on "/dev"
+     Then I should see "AI Assistant"
+      And I should not see "Dev AI Assistant"
+      And I should see "the agent decides (Dev)"
+
+  # What it is called is configuration: `assistant: name:` in settings.yml for the dashboard, and in
+  # a workspace's own file for that workspace's page. Shipped, both say AI Assistant.
+  Scenario: Its name comes from the settings file, where anyone can change it
+    Given I am on "/settings/settings.yml"
+     Then I should see "What the assistant is called"
+      And I should see "What the box says when it is empty"
+
+  Scenario: A workspace with no projects still renders its page
+    Given I am on "/projects"
+     Then I should see "Projects"
+      And "#webship-workspace-projects" should be attached
+
+  Scenario: The assistant is a deep-chat component with its own input
+    Given I am on "/"
+     Then "#ws-deep-chat" should be attached
+      And "deep-chat" should be attached

package/core/workspace-app/tests/features/menus.feature

@@ -0,0 +1,29 @@
+Feature: The menus on a project row
+  Every project row carries its state above the name and its verbs in menus.
+
+  Scenario: State is a line above the folder name, not a word after it
+    Given I am on "/dev"
+     Then ".project-row .pcard-state-line" should be attached
+      And ".project-row .pcard-head" should be attached
+
+  # The Graph menu is the graph plugin's, asserted by its own feature.
+  Scenario: The row offers the DDEV and Tests menus
+    Given I am on "/dev"
+     Then ".project-row .act-menu-ddev" should be attached
+      And ".project-row .act-menu-tests" should be attached
+      And ".project-row .act-menu-more" should be attached
+
+  Scenario: A menu that carries a state word captions it under the button
+    Given I am on "/dev"
+     Then the element ".act-with-status" should be displayed
+      And the element ".act-with-status .act-status" should be displayed
+
+  # Opened on /rag rather than /dev: the rag workspace holds exactly one instance, so a click by
+  # selector is unambiguous. On a page of twelve rows every selector matches twelve buttons, and a
+  # test that has to say "the third one" is a test that breaks when a project is built.
+  Scenario: The DDEV menu opens and holds the verbs that moved into it
+    Given I am on "/dev"
+      And I click on the element ".project-row >> nth=0 >> .act-menu-ddev button"
+     Then ".uk-dropdown.uk-open" should be visible
+      And I should see "Restart"
+      And I should see "Describe (URLs, services)"

package/core/workspace-app/tests/features/plugins/jira/jira.feature

@@ -0,0 +1,47 @@
+Feature: The Jira plugin on the project rows
+  A sites workspace project row offers its Jira surface, and the actions hold
+  their guards without ever needing Jira to answer.
+
+  # The menu is gated on twg + settings; in this environment both hold, so the
+  # rows carry the menu and the modal link.
+  Scenario: The JIRA menu is on the project rows
+    Given I am on "/dev"
+     Then "[hx-get^='/fragments/p/jira/list/dev/']" should be attached
+
+  # The guards answer without Jira: a malformed key never reaches twg.
+  Scenario: A malformed key is refused at the door
+    When I post "/actions/p/jira/task" with '{"workspace":"dev","projectName":"v11x00b1i18n","key":"not-a-key","mode":"view"}'
+    Then the action response should contain "Not a Jira key"
+
+  @needs-jira-writes-off
+  Scenario: Write modes are refused while Jira writes are off
+    When I post "/actions/p/jira/task" with '{"workspace":"dev","projectName":"v11x00b1i18n","key":"WEBSHIP-1","mode":"comment"}'
+    Then the action response should contain "Writing to Jira is off"
+
+  Scenario: An unknown project cannot host an agent
+    When I post "/actions/p/jira/task" with '{"workspace":"dev","projectName":"no-such-project","key":"WEBSHIP-1","mode":"view"}'
+    Then the action response should contain "Project not found"
+
+  Scenario: Watching a task nobody worked on says so
+    When I post "/actions/p/jira/task" with '{"workspace":"dev","projectName":"v11x00b1i18n","key":"WEBSHIP-424242","mode":"watch"}'
+    Then the action response should contain "No agent log"
+
+  Scenario: The Screens modal lists sessions or says there are none
+    Given I am on "/fragments/screens"
+     Then I should see "Screen sessions"
+
+  Scenario: Stopping a screen needs confirmation
+    When I post "/actions/screen-stop" with '{"session":"whatever-zz"}'
+    Then the action response should contain "requires confirmation"
+
+  Scenario: A hostile session name is refused
+    When I post "/actions/screen-stop" with '{"session":"x; rm -rf /","confirm":"yes"}'
+    Then the action response should contain "Not a screen session name"
+
+  Scenario: Remembering a Jira project refuses a bad key
+    When I post "/actions/jira-set-project" with '{"workspace":"dev","projectName":"v11x00b1i18n","key":"bad-key-1"}'
+    Then the action response should contain "Not a Jira project key"
+
+  Scenario: Remembering needs a real project
+    When I post "/actions/jira-set-project" with '{"workspace":"dev","projectName":"no-such","key":"WEBSHIP"}'
+    Then the action response should contain "Project not found"

package/core/workspace-app/tests/features/plugins.feature

@@ -0,0 +1,20 @@
+Feature: Settings → Plugins
+  Optional features are packages, turned on in four steps; the page shows every package the
+  dashboard can see and the step each is at.
+
+  Scenario: The Plugins page lists the packages with their steps
+    Given I am on "/settings/plugins"
+     Then I should see "Plugins"
+      And the element ".plugin-card" should be displayed
+      And the element ".plugin-steps" should be displayed
+      And I should see "required"
+      And I should see "configured"
+
+  Scenario: A package can be required from the page
+    Given I am on "/settings/plugins"
+     Then the element ".plugin-require input[name=spec]" should be displayed
+      And I should see "Require"
+
+  Scenario: Settings offers Plugins among the dashboard's own sections
+    Given I am on "/settings"
+     Then I should see "Plugins"

package/core/workspace-app/tests/features/project-actions.feature

@@ -0,0 +1,41 @@
+Feature: What a project row can actually do
+  The verbs on a row, asserted where they are rather than by opening every menu.
+
+  # Each menu carries the name of the verb it opens (act-menu-ddev, act-menu-tests, …). A page of
+  # thirteen projects has thirteen of each, so these assert that the control and its items EXIST
+  # rather than clicking one — a test that has to say "the third one" breaks the moment a project
+  # is built. The one click test lives on /rag, which holds exactly one row.
+
+  Scenario: A row carries a menu for each thing it can do
+    Given I am on "/dev"
+     Then the element ".project-row .act-menu-ddev" should be displayed
+      And the element ".project-row .act-menu-tests" should be displayed
+      And the element ".project-row .act-menu-graph" should be displayed
+      And the element ".project-row .act-menu-more" should be displayed
+
+  # These two are the whole testing feature as far as the interface is concerned: one sets the
+  # environment up, the other runs the suite. Both post to their own action.
+  @needs-testing-stack
+  Scenario: The Tests menu offers setting the environment up and running the suite
+    Given I am on "/dev"
+     Then "[hx-post='/actions/testing-configure']" should be attached
+      And "[hx-post='/actions/testing-run']" should be attached
+
+  # The state under the button is the answer to "is there anything to look at yet" — it says
+  # webship, webship-js or none, and it is a caption under the control rather than a word inside it.
+  Scenario: A menu that carries a state word captions it under the button
+    Given I am on "/dev"
+     Then the element ".act-with-status .act-status" should be displayed
+
+  Scenario: The DDEV menu opens and holds the verbs that moved into it
+    Given I am on "/rag"
+     When I click on the element ".project-row .act-menu-ddev button"
+     Then ".uk-dropdown.uk-open" should be visible
+      And I should see "Restart"
+      And I should see "Describe (URLs, services)"
+
+  # Launch belongs with the hostname it opens, not in the row of things you DO to a project.
+  @needs-running-project
+  Scenario: A running project shows its own host on its card
+    Given I am on "/dev"
+     Then ".project-row .pcard-host-name" should be attached

package/core/workspace-app/tests/features/screens.feature

@@ -0,0 +1,29 @@
+Feature: The Screens manager
+  Screen sessions are where long work lives — Jira agents, builds, anything
+  started with cmd-tools-screen.sh. The page must list them, refuse what would
+  reach a shell, and never let another site drive it.
+
+  Scenario: Screens is its own page, not a settings tab
+    Given I am on "/screens"
+     Then I should see "New screen"
+      And I should see "Remove ended sessions"
+
+  Scenario: The old settings URL still lands on the manager
+    Given I am on "/settings/screens"
+     Then I should see "New screen"
+
+  Scenario: A new session needs a place that the server offered
+    When I post "/actions/screen-new" with '{"session":"zz-nope","target":"/etc"}'
+    Then the action response should contain "Unknown place"
+
+  Scenario: A session name that screen would read as an option is refused
+    When I post "/actions/screen-new" with '{"session":"-S","target":"root"}'
+    Then the action response should contain "session name"
+
+  Scenario: Killing a session is refused without confirmation
+    When I post "/actions/screen-stop" with '{"session":"whatever-zz"}'
+    Then the action response should contain "requires confirmation"
+
+  Scenario: A hostile session name never reaches screen
+    When I post "/actions/screen-interrupt" with '{"session":"x; rm -rf /"}'
+    Then the action response should contain "Not a screen session name"

package/core/workspace-app/tests/features/settings.feature

@@ -0,0 +1,46 @@
+Feature: The settings editor
+  The one page that holds real credentials, so what it does NOT show matters as much as what it does.
+
+  Scenario: The editor lists the settings files and edits one at a time
+    Given I am on "/settings/settings.yml"
+     Then the element ".settings-tabs" should be displayed
+      And I should see "settings.yml"
+      And I should see "Workspace name"
+
+  # A secret's value never reaches the browser: the field renders empty with a note saying a blank
+  # submission keeps what is on disk. This asserts the mechanism rather than the absence of one
+  # particular string, which would pass on a page that simply failed to render.
+  # The note lives in the field's placeholder, not in the page text: it belongs to the box you are
+  # about to type in, and as body copy it would repeat itself once per secret on the page.
+  Scenario: A secret is offered as a field to replace, never as a value to read
+    Given I am on "/settings/settings.yml"
+     Then the element "input[type='password']" should be displayed
+      And the element "input[type='password']" with the attribute "placeholder" and the value containing "leave blank to keep" should exist
+      And the element "input[type='password']" with the attribute "value" and the value containing "-" should not exist
+
+  # account.pass is deliberately NOT a secret: it is the admin password a fresh local install is
+  # given, and masking it made the field useless for the one thing it is for.
+  Scenario: The local admin password stays readable, because that is what it is for
+    Given I am on "/settings/settings.yml"
+     Then I should see "pass"
+      And I should see "That admin password"
+
+  Scenario: A workspace has its own settings file with its card presentation in it
+    Given I am on "/settings/workspace.rag.settings.yml"
+     Then I should see "presentation"
+      And the element "#ws-presentation" should be displayed
+
+  # The icon chooser writes only the two fields it owns. The rest of the block — label, noun, kind,
+  # also_files — has to still be there afterwards, which is what the unit tests assert; here we
+  # assert the chooser is what the page offers rather than a free-text field.
+  Scenario: The icon is chosen from the icons that will actually render
+    Given I am on "/settings/workspace.rag.settings.yml"
+     Then the element ".icon-filter" should be displayed
+      And the element ".icon-grid" should be displayed
+
+  Scenario: The settings hub groups what can be configured and leads to the files
+    Given I am on "/settings"
+     Then I should see "The dashboard"
+      And I should see "Workspace settings"
+      And I should see "Styles"
+      And "a[href='/settings/settings.yml']" should be attached

package/core/workspace-app/tests/features/test-reports.feature

@@ -0,0 +1,32 @@
+Feature: The report a test run leaves behind
+  A finished run is readable in the dashboard and downloadable as a document.
+
+  # The report opens in a modal from the Tests menu, so the row links to the FRAGMENT that renders
+  # it. Asserted on the fragment itself rather than by opening thirteen menus to find one.
+  @needs-test-report
+  Scenario: The Tests menu links to the report of a project that has been tested
+    Given I am on "/dev"
+     Then "[hx-get^='/fragments/dev/test-report/']" should be attached
+
+  @needs-test-report
+  Scenario: The report offers itself as a PDF, for people who were not at the run
+    Given I am on "/fragments/dev/test-report/amd-website_starter-1-0-x-site-template-manager"
+     Then I should see "Download as PDF"
+      And "[href^='/report-pdf/dev/']" should be attached
+
+  # Not navigated to: the route answers with Content-Disposition: attachment, which a browser
+  # downloads rather than renders — so the PDF itself is asserted by the unit tests, which check
+  # the document it builds. This checks the interface offers it.
+  @needs-test-report
+  Scenario: The report leads with the counts, not with a list to scroll
+    Given I am on "/fragments/dev/test-report/amd-website_starter-1-0-x-site-template-manager"
+     Then I should see "passed"
+      And I should see "failed"
+      And I should see "scenarios"
+      And the element ".uk-label-success" should be displayed
+      And the element ".uk-label-danger" should be displayed
+
+  @needs-test-report
+  Scenario: The HTML report is reachable from it as well
+    Given I am on "/fragments/dev/test-report/amd-website_starter-1-0-x-site-template-manager"
+     Then I should see "Open the HTML report"

package/core/workspace-app/tests/features/theme.feature

@@ -0,0 +1,40 @@
+Feature: The theme system
+  One stylesheet is assembled from a base, the components, and the palette last.
+
+  Scenario: The page asks for the assembled stylesheet, not a file on disk
+    Given I am on "/"
+     Then "link[href*='/style.css?v=']" should be attached
+
+  # Which style is last is a per-machine setting, so naming one here asserted the machine rather
+  # than the code: the scenario failed on any machine not wearing `default`, which since the Styles
+  # page is most of them. What the assembly guarantees is the ORDER — base, components, then a
+  # style — so that is what is asserted.
+  Scenario: The assembled sheet carries the base, the components and a style
+    Given I am on "/style.css"
+     Then I should see "/* base */"
+      And I should see "/* component: workspace-cards */"
+      And I should see "/* component: project-rows */"
+      And I should see "/* theme:"
+
+  # Every style names itself and declares the palette tokens, whichever one is worn.
+  Scenario: The style in use names itself and declares its palette
+    Given I am on "/style.css"
+     Then I should see "@name"
+      And I should see "--brand-primary:"
+
+  # Not a button: the only primary button on the home page used to be the assistant's Send, and
+  # deep-chat renders its own inside a shadow root where a selector cannot reach it. The card chips
+  # carry the brand colour on every page, which is what this scenario is actually about.
+  Scenario: The dashboard still renders with its own brand colour
+    Given I am on "/"
+     Then the element "#workspace-cards" should be displayed
+      And the element ".ws-card-wrap .uk-label" should be displayed
+
+  # The favicon is the artwork from the brand tokens (node 5743:11748): a square with the emblem
+  # SUBTRACTED out of it, one boolean path. Its fill flips with the viewer's colour scheme, because a
+  # knocked-out mark has no colour of its own — asserted on the file in tests/unit/favicon.test.js,
+  # since a browser handed an SVG renders it as an image and there is nothing here to select.
+  Scenario: The tab carries the Webship favicon, not a bare emblem
+    Given I am on "/"
+     Then "link[rel='alternate icon'][href$='.png']" should be attached
+      And "link[rel='apple-touch-icon'][href$='.png']" should be attached

package/core/workspace-app/tests/step-definitions/actions-post.steps.js

@@ -0,0 +1,25 @@
+/**
+ * Steps that exercise an action's GUARDS over the wire, without a browser round
+ * trip: post the form, read the fragment that comes back. Used for actions whose
+ * happy path needs an external system (Jira through twg) — the guards answer
+ * locally and deterministically either way, and they are what must not regress.
+ */
+
+'use strict';
+
+const { When, Then } = require('@cucumber/cucumber');
+const assert = require('assert');
+
+When('I post {string} with {string}', async function (path, json) {
+  const form = JSON.parse(json);
+  const base = process.env.LAUNCH_URL || 'https://workspace.ddev.site';
+  const response = await this.page.request.post(`${base}${path}`, { form });
+  this.lastActionResponse = await response.text();
+});
+
+Then('the action response should contain {string}', function (needle) {
+  assert.ok(
+    (this.lastActionResponse || '').includes(needle),
+    `expected the response to contain ${JSON.stringify(needle)} — got: ${(this.lastActionResponse || '').slice(0, 300)}`,
+  );
+});