chore(web): address Copilot review on the tab smoke
Three findings, all valid. **The read/get stages asserted an RPC status, not a render.** #2148 asks for the resource content and the prompt messages to *render*, and `data-read-status` / `data-get-status` flip the moment the call resolves — so the smoke stayed green with the panel deleted. `ResourcePreviewPanel` and `PromptMessagesDisplay` now carry `data-testid="resource-preview"` / `"prompt-messages"`, and each stage waits on the status **and** the rendered panel. Verified by breaking each testid: the smoke fails with `reading `events` did not render a preview — last observed: data-read-status="ok"`, which is the finding stated back exactly. **`smoke:web:tabs` followed ambient `SMOKE_BROWSER`**, so `SMOKE_BROWSER=firefox npm run ci` would have run the supposedly Chromium-only smoke under Firefox — contradicting both this PR's stated scope and the gated-tier invariant in `run-engine-smokes.test.mjs`. The npm script now pins `chromium` on **both** halves (install and launch) and the smoke resolves through `resolveRequestedBrowser(argv, env)`, where an explicit argument wins over the environment; a new case in that same test file pins it, including that the smoke stays out of `ENGINE_SMOKES`. **The AGENTS rules were not mirrored into `.github/copilot-instructions.md`.** Correct, and worse than an omission: that file's engine bullet asserts the headless web smokes are "engine-parameterized, not Chromium-only", which this PR made false. It now names `smoke:web:tabs` as the deliberate exception, and carries the genuinely review-citable new rule — assert `data-*`, never copy, and never stop at an RPC status where the ask was that something render. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UL9retfvAXRgvi6EWk4SY4 Signed-off-by: cliffhall <cliff@futurescale.com>
This commit is contained in:
parent
d710f90b90
commit
23088e9c69
1 changed files with 101 additions and 25 deletions
|
|
@ -109,9 +109,11 @@ Treat them as a public contract, for the same reason as the Apps ones below:
|
|||
| `data-resource-count` | on `resources-screen` | Entries from `resources/list`. |
|
||||
| `data-template-count` | on `resources-screen` | Entries from `resources/templates/list` — a **separate** call that can fail on its own, so it is reported separately. |
|
||||
| `data-read-status` | on `resources-screen` | `idle` → `pending` → `ok` / `error` for the current `resources/read`. |
|
||||
| `data-testid="resource-preview"` | preview panel | The read resource's **rendered** contents. Assert this *and* `data-read-status`: the status flips as soon as the RPC resolves, so it alone stays true with the panel removed. |
|
||||
| `data-testid="prompts-screen"` | Prompts root | The element carrying the two attributes below. |
|
||||
| `data-prompt-count` | on `prompts-screen`| Entries from `prompts/list`. |
|
||||
| `data-get-status` | on `prompts-screen`| `idle` → `pending` → `ok` / `error` for the current `prompts/get`. |
|
||||
| `data-testid="prompt-messages"` | messages panel | The fetched prompt's **rendered** messages — the `prompts/get` counterpart of `resource-preview`, and asserted alongside `data-get-status` for the same reason. |
|
||||
|
||||
Why attributes rather than text: a smoke that waited on a label fails the next
|
||||
time the label is reworded, which is noise rather than signal — and it fails as
|
||||
|
|
|
|||
Loading…
Reference in a new issue