@webship.co/workspace 1.0.0-alpha1 → 1.0.0-beta2

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,40 @@
+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.
+  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.
+  Scenario: A running project offers its own URL beside the Launch button
+    Given I am on "/dev"
+     Then the element ".proj-launch-line" should be displayed
+      And the element ".proj-launch-line .proj-alias" should be displayed

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)}`,
+  );
+});

package/core/workspace-app/tests/step-definitions/assistant-speech.steps.js

@@ -0,0 +1,152 @@
+/**
+ * Steps for the assistant's voice configuration.
+ *
+ * These read the LIVE properties off the deep-chat element rather than the page source, because the
+ * page source cannot tell you whether the component accepted anything. deep-chat is configured with
+ * JavaScript properties (the objects cannot survive an HTML attribute), and it silently ignores keys
+ * it does not recognise — so "the config is in ui.js" and "the component is using it" are different
+ * facts, and only the second one matters.
+ *
+ * Nothing here speaks or listens. An automated browser is not granted a microphone, and a scenario
+ * cannot talk. What CAN break without anyone noticing is the microphone being absent, or present
+ * with a configuration deep-chat quietly dropped, and that is what these assert.
+ */
+
+'use strict';
+
+const { Then } = require('@cucumber/cucumber');
+const assert = require('assert');
+
+/** The properties deep-chat is actually holding, read from inside the page. */
+async function speechConfig(page) {
+  return page.evaluate(() => {
+    const el = document.querySelector('deep-chat');
+    if (!el) return null;
+    return {
+      speechToText: el.speechToText === undefined ? 'unset' : el.speechToText,
+      textToSpeech: el.textToSpeech === undefined ? 'unset' : el.textToSpeech,
+      placeholder: (el.textInput && el.textInput.placeholder && el.textInput.placeholder.text) || '',
+    };
+  });
+}
+
+Then(/^the assistant should offer voice input$/, async function () {
+  const cfg = await speechConfig(this.page);
+  assert.ok(cfg, 'there is no deep-chat element on this page');
+  assert.notStrictEqual(cfg.speechToText, 'unset', 'deep-chat was never given a speechToText config');
+  assert.notStrictEqual(cfg.speechToText, false, 'voice input is switched off');
+  assert.ok(cfg.speechToText.webSpeech, 'no speech backend is configured, so the microphone does nothing');
+});
+
+Then(/^the assistant should read its replies aloud$/, async function () {
+  const cfg = await speechConfig(this.page);
+  assert.ok(cfg, 'there is no deep-chat element on this page');
+  assert.notStrictEqual(cfg.textToSpeech, 'unset', 'deep-chat was never given a textToSpeech config');
+  assert.notStrictEqual(cfg.textToSpeech, false, 'voice output is switched off');
+  // Its presence IS the read-aloud behaviour; there is no separate switch to check.
+  assert.ok(Number.isFinite(cfg.textToSpeech.rate), 'no speech rate, so the config is not the resolved one');
+});
+
+/**
+ * What the composer LOOKS like, from inside deep-chat's shadow root.
+ *
+ * Its input lives in that shadow root, and so does the microphone, so neither is reachable from the
+ * page's own DOM — and the placeholder is drawn as a pseudo-element, which has no node at all. The
+ * only honest way to ask "is anything drawn there" is the computed `content`, which is why this
+ * reads styles rather than text.
+ */
+async function composer(page) {
+  return page.evaluate(() => {
+    const el = document.querySelector('deep-chat');
+    const root = el && el.shadowRoot;
+    if (!root) return null;
+    const input = root.querySelector('#text-input');
+    const mic = root.querySelector('#microphone-button');
+    return {
+      drawn: input ? getComputedStyle(input, '::before').content : null,
+      name: input ? input.getAttribute('aria-label') : null,
+      mic: !!mic,
+      micName: mic ? (mic.getAttribute('aria-label') || '') : '',
+    };
+  });
+}
+
+Then(/^the assistant should show a named microphone button$/, async function () {
+  const c = await composer(this.page);
+  assert.ok(c, 'there is no deep-chat element on this page');
+  assert.ok(c.mic, 'there is no microphone in the composer, so nothing says voice is available');
+  // deep-chat's own buttons are role="button" with an SVG inside and no accessible name, so this is
+  // a name ui.js puts on. Without it a screen reader announces an unnamed button.
+  assert.ok(c.micName.trim(), 'the microphone has no accessible name');
+});
+
+Then(/^the assistant composer should draw no placeholder$/, async function () {
+  const c = await composer(this.page);
+  assert.ok(c, 'there is no deep-chat element on this page');
+  // An empty `content` is the only thing that means nothing is drawn. "none" would mean the
+  // pseudo-element is absent, which is also fine; a string means deep-chat's "Ask me anything!" is
+  // back, which is what an empty placeholder.text silently restores.
+  assert.ok(c.drawn === '""' || c.drawn === 'none' || c.drawn === '',
+    `the composer is drawing a placeholder: ${c.drawn}`);
+});
+
+Then(/^the assistant composer should have an accessible name$/, async function () {
+  const c = await composer(this.page);
+  assert.ok(c, 'there is no deep-chat element on this page');
+  assert.ok(c.name && c.name.trim(),
+    'the composer has no accessible name, so a screen reader announces an unlabelled text box');
+});
+
+Then(/^the assistant speech language should be pinned$/, async function () {
+  const cfg = await speechConfig(this.page);
+  // A pinned language is the shipped default (en-US), because a recogniser left on the browser's
+  // language does not fail on the wrong one — it returns confident nonsense. `true` here would mean
+  // nothing is pinned, which is a valid choice but not what ships.
+  const ws = cfg.speechToText.webSpeech;
+  assert.ok(ws && typeof ws === 'object' && ws.language,
+    `no language is pinned (webSpeech is ${JSON.stringify(ws)}); the shipped default is en-US`);
+  assert.match(ws.language, /^[a-z]{2}-[A-Z]{2}$/, `"${ws.language}" is not a BCP-47 tag`);
+});
+
+Then(/^the assistant should have no voice commands$/, async function () {
+  const cfg = await speechConfig(this.page);
+  // Absent, not empty. An empty phrase is not a disabled command — it is one that fires on anything.
+  assert.ok(!('commands' in cfg.speechToText),
+    `voice commands are armed with nothing configured: ${JSON.stringify(cfg.speechToText.commands)}`);
+});
+
+Then(/^the assistant speech colours should be design tokens$/, async function () {
+  const cfg = await speechConfig(this.page);
+  const { textColor } = cfg.speechToText;
+  assert.ok(textColor, 'interim and final speech text have no colours set');
+  for (const key of ['interim', 'final']) {
+    assert.match(textColor[key], /^var\(--/,
+      `speech ${key} colour is "${textColor[key]}", a literal that cannot follow the theme`);
+  }
+});
+
+Then(/^the voice list should report what this browser has$/, async function () {
+  // The reading voice is a dropdown the server cannot fill in: which voices exist belongs to the
+  // browser and the OS. Either it gained real options, or it says there are none — an empty select
+  // with no explanation is the failure this guards, because that reads as "still loading" forever.
+  const state = await this.page.evaluate(async () => {
+    const select = document.querySelector('select[data-voice-name]');
+    const note = document.querySelector('[data-voice-list]');
+    if (!select) return { missing: true };
+    for (let i = 0; i < 20 && select.dataset.done !== '1'; i += 1) {
+      await new Promise((r) => setTimeout(r, 200));
+    }
+    return {
+      resolved: select.dataset.done === '1',
+      options: select.options.length,
+      hasDefault: [...select.options].some((o) => o.value === 'default'),
+      warns: !!(note && note.querySelector('.uk-text-danger')),
+      note: (note ? note.textContent : '').trim().slice(0, 80),
+    };
+  });
+  assert.ok(!state.missing, 'the reading voice is not a dropdown');
+  assert.ok(state.resolved, 'the voice list never resolved — it waits for voiceschanged with a timeout');
+  assert.ok(state.hasDefault, 'there is no "default" option, so the browser default is unreachable');
+  assert.ok(state.options > 1 || state.warns,
+    `only the default option and no explanation of why: "${state.note}"`);
+});