@parity/product-lab 0.0.1-placeholder → 0.1.0

package/entrypoints/panel/README.md

@@ -0,0 +1,1773 @@
+# @product-lab/shell
+
+Failed steps and their Details show optional `abortDetail` beside the original error for configured and feature runs. This display field does not change failure classification or negative-control verdicts.
+
+The loopback control plane (`serveLab`), full-width app workspace, bottom controls
+and supporting overlay drawer.
+
+```ts
+import { serveLab } from '@product-lab/shell';
+
+// runtime: a LabRuntime (@product-lab/ports/driving) whose environment is running,
+// for example one the composition root built (createLabRuntime), then runtime.startEnvironment().
+const server = await serveLab(runtime, 5202, navigation);
+```
+
+Standalone, without the CLI: `src/main.ts` (refactor step 8, also `@product-lab/shell/main`) is the
+only file of this package that imports the composition root. It builds one `LabRuntime` through
+`createLabRuntime`, starts the selected environment and serves the panel over it; `serveLab` itself
+knows only the runtime. Once it listens, `serveLab` records the lab it serves at its address
+(`LabRuntime.claimRunningLab`, B1 step a, backlog B2), so another way into the lab's folder (the MCP server)
+finds the window; closing gives the record back (`tests/running-lab-claim.test.ts`). The record carries a token new
+at every start (file mode 600): `src/runtime-routes.ts` serves the runtime's live calls to whoever presents it
+(`POST /api/runtime` for calls, runs and long-polls; `GET /api/runtime/events`, the runtime's events as server-sent
+events; B1, [the MCP README's Tools](../mcp/README.md#tools)), so an agent's run shows in the window
+(`tests/attached-runtime-contract.test.ts`: the same behaviours on a lab of its own and through the window).
+
+```sh
+node --import tsx entrypoints/panel/src/main.ts [--config lab.config.ts] [--environment id] [--port 5202]
+```
+
+- `src/server.ts` binds to `127.0.0.1`, validates Host/Origin and accepts only
+  registered actions. It transpiles the panel's TypeScript once per file (cached by modification time, warmed when
+  the server starts). In the published package the client is compiled JavaScript (tools/eval/src/build.ts): `.js`
+  is served with only its domain imports rewritten (`rewriteBrowserImports`, which also reads the package's own
+  `@parity/product-lab…` specifiers), each module found with `siblingModule`, and the domain's actors in the form
+  they import each other (`.js` compiled; `tests/compiled-assets.test.ts`, tools/eval/tests/pack-build.test.ts). Until `client.ts` has built the app-first shell (`html[data-shell="ready"]`), `shell.css`
+  paints only a "Starting the lab…" bar, never the unstyled pre-shell controls (`tests/boot-cover.test.ts`). Since
+  refactor step 6 it only translates requests into `LabRuntime` calls: the
+  runtime plans and enforces switching, checks every confirmation token and
+  redacts every snapshot, evidence and observation it serves.
+- `src/client/` is the browser panel. Its only runtime imports are the domain's pure helpers (refactor
+  step 9; everything else it imports is types): `@product-lab/domain/actors` (`Actor.isRunning`,
+  `ActorRoster.removalBlockedReason`), served file by file under `/domain/actors/`;
+  `@product-lab/domain/runs` (`describeFailure`), served from `core/domain/src/runs/failure-description.ts`
+  as `/errors.js`; and `@product-lab/domain/navigation` (`routeFields`, for the tile address bar's pages list), served from
+  `core/domain/src/navigation/app-routes.ts` as `/navigation.js`. The server rewrites the bare specifiers to
+  those paths; any other runtime import from core or the domain fails loudly. The server itself validates
+  navigation (`validateNavigation`) and frame origins (`Actor.origin`) with the same domain code.
+  The Identities footer (`view-identities.ts`) shows a compact ready count when the environment
+  reports `identityReserve`; these hidden identities are never rows or picker options.
+  Pre-onboarded identities (backlog A3): an existing account's row has an `existing` chip and no Delete; a declared
+  one not open yet is a row with `not open` and an Open button (`POST /api/actors { preOnboarded }`, through
+  `client.ts`). On a public network (backlog A6, `snapshot.public`) the Environment view shows a warning banner
+  (`.environment-public`: nothing resets, or read only, with the reason and the finality timeout) instead of the
+  public target's notice among the notes (`tests/live-targets-served.test.ts`). On a read-only public target New
+  identity and Reset are disabled up front with the target's reason ("Creating an identity writes to <network>, and
+  this environment is read-only"; "Nothing resets on <network>…"); on a read-write one Reset says the same and New
+  identity is not offered (the default session creates none); a local environment keeps both.
+- `src/client/client.ts` holds the panel's state and controller (`render`, `action`, `startRun`, `poll`, the remaining
+  button handlers). Split by responsibility since 28 September 2026 (q10-panel),
+  each module served by `src/server.ts` as `/<name>.js`:
+  `dom.ts` (`element`, `text`, `replaceOptions`), `request.ts` (the loopback request), `window-bindings.ts`
+  (`runnerBinding`; `installRunnerOverlay` defines `__productLabRing` and `__productLabReveal`), `app-tiles.ts`
+  (`createAppTiles`: the tiles, frames and address bars), `run-progress.ts` (the legacy step list and the Runs model: one entry per run, step states, the dock's line),
+  `confirm-dialogs.ts` (delete identity, reset), `evidence-controls.ts` (evidence, landing, observation), `after-failure-view.ts`, `lab-actions.ts` and
+  `status-actions.ts` ([A failure never blocks](#a-failure-never-blocks))
+  and `panel-snapshot.ts` (the `LabSnapshot` type; types only, never loaded). Every file stays under the 600-line
+  `architecture/file-size` budget, which has no exception.
+- Work the panel starts without awaiting it (a button's action, the poll, a list a render asks for) goes through
+  `unawaited(report)` (`src/client/unawaited.ts`): a rejection shows in the status line (`client.ts`,
+  `features.ts`, `builder.ts`, `environment-lifecycle.ts`) or in the extension's own box (`extensions.ts`), never as
+  an unhandled rejection only a developer console would show; a failure inside a success handler (for example a
+  transaction report the panel cannot render) is shown the same way. The lab window's bindings
+  (`__productLabRun`, `__productLabFeatureRun`, `__productLabBuilderRun`, `__productLabRing`, `__productLabReveal`, `__productLabUiCalls`) are typed once, in
+  `src/client/run-mode.ts` (`labWindow()`). Tests: `tests/unawaited.test.ts`, `tests/client-unawaited.test.ts`
+  (headless Chromium, fails on any page error; each case was checked failing without the change).
+
+- The panel shows the lab registry (`compileLab` → `LabEnvironment.registry`,
+  served in `/api/lab`): every app with its availability and, when
+  unavailable, the exact reason (missing chain, service or capability, unusable
+  secret, failed operator). Each integration action is a block with a form
+  generated from its registry input descriptions; blocks that cannot run are
+  disabled with their reason (`src/client/registry.ts`). Secrets appear by name
+  and kind only. The panel is closed by default and the app fills the window.
+- Every integration is also a row of its own (`src/client/integrations.ts`):
+  ready, idle, unavailable, failed (with the error class, for example an
+  operator's `AuthorityError`) or blocked by a dependency, with the apps
+  that use it; app cards name the integrations blocking them.
+- The Environment section (`src/client/view-environment.ts`, `src/client/environment.ts`, since 28 September
+  2026) reads top to bottom: a header card (the configured label, the snapshot's `environment`: the one name the
+  bottom bar, the environment picker, the stop and switch dialogs and this header all show, never the session's own
+  `name`, since 29 September 2026; local or public, what stopping keeps, health, and
+  Start/Stop from `src/client/environment-lifecycle.ts`). Since 6 October 2026 (backlog D1) the whole Environment
+  section sits above the Run, Scenarios and Recordings tabs, outside their panels: one `<details id="environment-section">`
+  whose heading (`#environment-summary`: the section's icon, "Environment", the arrow) opens and closes it, open or
+  closed as the person left it across tab switches and reloads (`localStorage`, open the first time). Open, it takes at
+  most 40% of the panel and scrolls under its heading. The Lab menu's Environment entries (and the environment picker's)
+  open it where it is and leave the tab as it was. What stopping keeps reads "kept between starts" when this start kept its chains (backlog A5,
+  `keptChains`: `keepBetweenStarts.running` and the provider's `chains` words); that chip opens the environment
+  menu with the switch, and the section's rows and facts say the same. At a narrow panel (backlog D2) a fact's value
+  wraps between words only and goes under its label, a count beside an (i) ("5 notes") stays on one line, and Reset
+  takes its own line (`tests/environment-section.test.ts`, at the default width and 280 px). Then the fork's freshness as one line with a status dot and a
+  "Why?" tooltip; the chains table (finalized and best heads, the endpoint with copy, a health dot) and services (since 5 October
+  2026 each with the lab's own probe, server-side, said in words on the row: "answers" (green; the tooltip gives its
+  HTTP status), "not answering" (red; the tooltip says why), "not checked" for an endpoint that is not HTTP or a lab
+  without a probe;
+  `tests/environment-polish.test.ts`);
+  the apps; every configured environment as a row with Switch (disabled with the plan's reason; with one
+  environment, a hint that more come from `lab.config.ts`); the workspace's processes (one summary line, Stop/Start
+  workspace, groups Setup, Nodes, Collators, Services and Identity sessions); and Advanced: the resolved topology,
+  versions and provenance as facts (paths relative to the lab, ids short, each with copy), and Reset. Switching
+  selects another configured environment (its own state; the current one is stopped, never rewritten). While a
+  switch starts the new environment, the drawer's status names the operation once with its active phase, and a
+  vertical checklist (`#operation-phases`, `src/client/operation-phases.ts`) lists each phase the environment
+  reports with a status mark, its detail, count and time; the bottom bar shows the same summary (`Switching to … ·
+  Chains answering · 3/5 phases · 26s`). Leaving a disposable environment needs the session's `leave` token. The
+  runtime computes every plan (`SwitchEnvironment`) and the retention of the current environment
+  (`EnvironmentRetention`); the snapshot carries them (`switchPlans`, `retention`, `confirmations`) and the panel
+  only shows them. Reset and identity deletion send the tokens from `snapshot.confirmations`; both dialogs name
+  what they remove (Reset, A4: the environment's own words for its chains, `capabilities.resetDiscards`, and each
+  person by name, `reset-words.ts`; a disabled Reset's tooltip gives the real reason: a public network, the running
+  scenario or operation, or the environment's `capabilities.resetUnsupported`). The environment card says the chains' pace and
+  how long the chain's day has left ("Fast pace · the chain's day ends in 40 min", or "Real time · never goes stale",
+  `chain-day.ts`, from `snapshot.chainDays`, in `@product-lab/domain/lab/chain-pace`'s words, served as
+  `/chain-pace.js`), in the words the lab stops runs with at the crossing ("the chain's day has ended"), greys "Real
+  time not set · add `pace: "real-time"`" while a chain runs at another pace, and, with keeping on at the fast pace,
+  says once that a kept chain goes stale (so does the Keep switch's hover). A start or switch refused because the kept
+  chain's day had ended shows why and "Replace the kept chain" (`replace-kept.ts`; `lastFailure.chainDayEnded`,
+  `operation.chainDayEnded`), which starts it again with `replaceKept`. Editing is read-only in v1, except each environment's RPC per chain (3 October 2026): an
+  environment whose provider takes one (`EnvironmentProvider.rpc`) has an RPC disclosure under its row with a field
+  per chain, where each value comes from now (remembered, lab.config, a secret, the provider default; a secret and a
+  URL with a token show as scheme://host only) and, for an `endpoint` RPC on an environment that is not a public
+  target, a reason field. Remember posts `POST /api/environment-rpc` (`{ environment, action: "remember", rpc:
+  { chains, reason? } }`, `rememberEnvironmentRpc`); it applies on the environment's next start. Clear posts
+  `action: "clear"`. The field refuses a URL with credentials (naming the chain only) and a URL off this machine
+  without a reason, and the runtime refuses the same, plus a chain the provider does not list.
+  `/api/environment-start` and `/api/environment` also take `rpc` for one start (`tests/environment-rpc.test.ts`).
+- "Keep chain and people between starts" (backlog 183, `src/client/keep-switch.ts`; its words in `keep-words.ts`, which
+  the terminal app shares through `./words`) in the environment menu: a switch
+  with an (i), what this start did and why, what the next start will do once the switch changed, and one line per part
+  (chains: the environment's `keeps`; people: the lab's `keepBetweenStarts`), a part that keeps nothing greyed with why
+  (`snapshot.keepBetweenStarts`). Turning it saves `keepBetweenStarts` in the lab's settings (`setKeepBetweenStarts`);
+  it applies at the next start. Greyed, with why, in a lab that is not the interactive one (tests, CI, agents).
+- An environment's options (backlog 184, `src/client/environment-options.ts`): in the environment picker, under an
+  environment with options, one row per option (`.environment-way[data-environment][data-option]`) with its
+  description and a chip: "Runs now", "Picked" or "Your choice" (the next start's, why as its tooltip), "Next start" on
+  the running environment, "Needs more". An option this machine is too small for is greyed, its tooltip naming what it
+  needs, and stays choosable. Choosing one posts `POST /api/environment-option` (`{ environment, option }`,
+  `chooseEnvironmentOption`), then opens the switch to that environment; a refusal shows under the rows
+  (`tests/environment-options-served.test.ts`).
+- An environment that cannot start (its declaration has problems, for example a pre-onboarded actor's secret not set on
+  a live network) is greyed in the environment picker (`.environment-option.is-unavailable`, since 6 October 2026), with
+  a "can't start" chip whose tooltip is the reason, naming the variable and `.env` (`src/client/workspace-shell.ts`).
+- The Identities section (`src/client/view-identities.ts`): one view-mode control (Focus · Compare · Follow acting,
+  also in the identity picker) and one row per identity: avatar (the selected one in an accent ring), name,
+  username, its status (running as a green dot alone; starting, stopped, failed with its error in words), an Acting
+  chip while it acts (the selected row's outline says which one the stage shows), and beside
+  it Stop or Start, Delete (danger, confirmed by name: the dialog says what is lost for good, what stays on chain and,
+  while people are kept between starts, that the person will not come back; `deleteWords` in `identity-words.ts`, the
+  terminal app's prompt too, and the delete is sent with `from: "window"` so the environment records who asked) and More
+  (Reload app, Copy account address). Clicking a row
+  selects the identity; the row's buttons select it and press the legacy `#stop-identity`, `#start-identity`,
+  `#delete-identity` or `#restart`, so the rules in `client.ts` still decide. A disabled button says why in its
+  tooltip (`ActorRoster.removalBlockedReason`, an active run, a stopped workspace). Each row shows the identity's host
+  pill (CLI, WASM), as its tile does (`ui.ts` `hostIcon`). Every host chip (a tile's host pill, an Identities row's, New
+  identity's host menu, in the lab's own window too) is drawn in its host's colour (`ActorSession.host.color`,
+  `EnvironmentHost.color`; `ui.ts` `hostHued` sets `--host-hue`, and `components.css` `.host-hued` mixes its fill, border
+  and text with the theme's surface and ink, 5 October 2026); a host without one is slate (`HOST_COLOR_FALLBACK`). Tests:
+  `tests/host-colors.test.ts` (both themes, the lab's own window, 4.5:1 text on fill) and `tests/host-chip-contrast.test.ts`
+  (every adapter's colour, distinct, 4.5:1 in both themes, without a browser). New identity is a split button when the lab declares
+  several hosts (`snapshot.hosts`, 5 October 2026): New identity creates on the default host, and ▾ (`#new-identity-host`,
+  at least 32 px) opens "New identity on", exactly the declared hosts, the default one checked and the only filled row
+  (hover only outlines a row), each with one line (the lab's `description` for it, else its adapter's label; the default
+  says "Default ·"), an unavailable one disabled with its reason as that line; choosing one posts
+  `/api/actors` with `host`, which the runtime refuses for a host the lab does not declare. A lab with one host shows a
+  plain New identity. Test: `tests/new-identity-host.test.ts`. Backlog 185: under each host the options its adapter
+  declares (`EnvironmentHost.options`), at the lab's values: a small switch (`[data-host-option]`, `role="switch"`), or a
+  list for a choice; one the lab config sets only is shown fixed, its tooltip naming where it is set. Since 6 October
+  2026 (C2, C3) each host is a card (`.new-identity-host-group` when it has options) holding its button
+  (`#new-identity-on-<host id>`, what a test clicks) and its switches, lined up under the host's name; each option's
+  tooltip is its adapter's `why`. The picked card (`data-picked`) is highlighted: the default host's, until a switch of
+  another host is touched; the other cards' options are greyed (opacity), never disabled. The menu fits the panel at
+  280 px. Choosing the host posts
+  `/api/actors` with `host` and `hostOptions` (the values the person changed), and the identity's host chip names the
+  options on for it ("truAPI CLI · network locked", `data-host-options`). No option is named in the panel's code.
+  Test: `tests/host-options-served.test.ts` (a phone adapter the panel has never heard of).
+- Manual-mode actor binding (`src/client/bindings.ts`, tx-landed): a scenario
+  that declares actors (`snapshot.scenarios[].actors`, for example Ada and
+  Grace) shows one picker per actor: the saved identities (stopped ones
+  disabled) and Create new identity, defaulting to distinct running identities. A lab that declares several hosts
+  (the user's variant A, 5 October 2026) puts one actor per row with its host beside it:
+  - a new identity gets a host select listing exactly the declared hosts, the default preselected and an unavailable
+    one disabled with its reason;
+  - a saved identity shows its host read-only;
+  - a host the feature scenario's own step names (`actorHosts` in `/api/features`) is shown locked, "set by the
+    scenario";
+  - each host is drawn in its colour (`hostHued`).
+  A host other than the default is sent as `{ new: { host } }`: in `/api/run`'s `actors`, and as
+  `inProcess.hosts` for a feature or builder run. The runtime refuses an undeclared host, naming the declared ones.
+  Test: `tests/binding-host.test.ts`.
+  Run posts `/api/run` with `actors` instead of `actor`; the runtime binds them
+  (`BindActors`: a shared identity is refused before anything runs, a new one is
+  created for and named after its actor) and fixes them for the run. The run
+  shows under every identity that played in it, with who played whom
+  (`#bindings-summary`); the viewed identity is only a view. The lab window's
+  Watch runs them too (since 28 September 2026; before, it refused them): the runner's `__productLabRun`
+  accepts `actors` and hands the runtime every identity's displayed frame (`RunScenarioRequest.surface`), so each
+  step runs in the frame of the identity it acts as (`ScenarioStep.actor`, else the run's actor), checked when the
+  step starts, as feature and builder runs do. Background and every other tab run them headless.
+- A watched run that involves two or more actors (a registered scenario that binds several, a feature or builder
+  scenario with several actors) switches the view to Grid while it runs, so every acting identity's frame is on
+  screen, and gives back the view the person had when it ends, unless they chose a view during the run; a
+  one-actor run never changes it (`src/client/watch-layout.ts`). Tests: `tests/watch-layout.test.ts`,
+  `tests/watch-multi.test.ts` (the lab window, two fixture apps), `tests/visible-builder.test.ts` (Grid during a
+  two-actor builder run); live: `examples/notes` `bun run e2e:watch-multi`.
+- A run started outside the lab window (an agent over MCP, the terminal app: a process attached to this lab through
+  `src/runtime-routes.ts`) looks as the same scenario started from the window's own Run: the lab window follows it in
+  its snapshots and begins the same watch layout with the same count of people, so it shows Grid and the same tiles
+  while it runs, and the person's view after (`src/client/watch-layout.ts`, `follow`). A run is counted by the larger
+  of its scenario's people in the Scenarios list (by `path:line`, or by its name filter read as Cucumber reads it, a
+  regular expression: MCP's `name`, "…window$") and the people it has made or acted as so far (`runPeople` in
+  `src/client/views.ts`), so a run the list cannot count (several files, tags only, a name the list does not have)
+  shows Grid once it plays two people, and every person it makes or acts as has a mounted tile for the window's runner
+  to act and read in. Tests: `tests/outside-runs.test.ts` (a
+  three-person feature run, inside and outside, snapshot for snapshot, with today's window as the control),
+  `tests/watch-multi.test.ts` (the lab window: a run from its card and one started with the window's runtime).
+- Such a run also acts in the window's tiles as the window's own Run does. With the lab window open, the routes'
+  `run-scenario` and `run-features` go through the window's runner (`LabRunner.outside` in `src/visible/runner.ts`,
+  given to the routes by `product-lab dev` through `attachWindow`): each person acts and is read in their tile, the
+  run's network conditions apply in the tile, and the window's journal and UI calls have the run. With no window open
+  (a headless lab, CI) the runtime runs it as before. The terminal app inside `product-lab dev` does the same
+  (`throughWindow` in `entrypoints/cli/src/tui/start.ts`). Tests: `tests/watch-conditions.test.ts` (inside and outside,
+  step for step: each step's surface, what the tile showed, the UI calls and the conditions; the request handed to the
+  runtime as the routes did before is the control), `tests/attached-runtime-contract.test.ts` (with the window
+  attached, through its runner; with none, the runtime).
+- "Did its transactions land?" (`src/client/landing.ts`) under Execution
+  evidence calls `GET /api/transactions?job=<run>[&step=<n>]`
+  (`LabRuntime.checkTransactions`): one line per transaction the run recorded
+  or its evidence names, succeeded, failed, not included or unknown, with block,
+  index and reason. A step that failed after submitting shows `submission
+  <outcome>` (the Scheduler's reconciliation); a step that declares
+  `reportsSubmission` and failed before reporting shows `nothing submitted`.
+  When a failed step may have sent a transaction, the step shows the lab's own check of the chain and then
+  its answer; nothing is to press and nothing is blocked ([A failure never blocks](#a-failure-never-blocks)).
+
+- Scenario builder (Phase 5; redesigned in panel-builder, 28 September 2026):
+  `src/client/builder.ts` (the controller),
+  `builder-view.ts` (pure helpers: roles, slot labels, the actor roster, local edits), `builder-blocks.ts` (the
+  canvas blocks, fields and table editors), `builder-chrome.ts` (picker, library, read-only line, Background,
+  source) and `view-builder.css`. It looks like the Gherkin viewer (`gherkin-view.ts`): a top bar with the document
+  picker (`folder › file.feature › Scenario`, a popover with a sticky search and the lab's scenarios under their
+  folder; a repeated title shows its file), New scenario, Source, Save (file path and Replace behind its caret),
+  Pause after each step and Run; below, three columns: the step library, the canvas and the Gherkin source.
+  - Library: `GET /api/builder`'s palette grouped by role, Context (Given), Action (When) and Outcome (Then), from
+    `PaletteBlock.class`, each integration a small muted header inside. Parameters are neutral dashed slots with
+    human labels (`someone` for an actor, else the field's label); only a small icon says a step acts on chain or in
+    the app. The phase colours are the same in the library, the canvas section labels, keyword chips and rail dots.
+  - Canvas: the blocks as cards on the viewer's rail, one Context/Action/Outcome label per role (consecutive steps of
+    one role share it; a Context step after an action gets a quiet hint). Each block's generated fields (the
+    scenario's actors as a choice, an input's choices, text and numbers), a table editor, a toolbar on hover
+    (move, duplicate, checkpoint, remove), and a pick box for Repeat, Run together (saved as the
+    `these steps run together:` table, or since backlog 113 as its doc string when a block has its own table; a group
+    with a composed part is kept as written, its doc string shown on the locked block) and At the same time (since 29 September 2026: the same group saved as one step,
+    `<block> and <block> at the same time`; each button shows only when the lab registers the sentence it saves as,
+    `BuilderPaletteView.together` / `atTheSameTime`), and the runtime's gate refuses a group that could not overlap. A step that introduces an actor (`these actors exist:`, `{actor} is a new actor`)
+    has a free name field: new rows and blocks get the next unused roster name (Ada, Grace, Alan, Barbara, Edsger…,
+    the domain's `ACTOR_ROSTER`), and a name already in the cast is marked and blocks Save and Run. Add actors
+    extends the one actors table and refuses a name already in the cast. Tables stay tables (compact for more than
+    four columns, header names in `<th>`, a table that still does not fit scrolls in its own frame); below 480px
+    of card each row becomes a two-column card; more than 12 rows show the first 8 and Show all.
+  - A loaded file: a feature's Background is shown read-only at the top (one collapsed line with its step count);
+    its actors are in scope (`POST /api/builder/check` takes `bound`, the load's `backgroundActors`). Steps the
+    builder cannot edit are locked cards; custom steps (`step()` in the lab's step files, found by the runner's
+    preflight) show a Custom chip and run as written; only an undefined step warns. What the builder cannot keep is
+    one quiet line (`Read-only · runs as written`, the reasons behind Details); custom steps alone say
+    `3 custom steps · run as written`.
+  - Edits show at once: the controller applies each edit locally, sends it to the runtime's `ScenarioBuilder`
+    (`POST /api/builder/edit|check|save|load|run`), coalesces value edits and checks once after a burst
+    (250 ms); the runtime's answer replaces the local view. Run is the same in-process Cucumber run as the feature
+    scenarios, so Continue, Step, Pause and Cancel (`/api/continue`, `/api/pause`, `/api/cancel`) and its progress
+    are the same, shown on the canvas's rail. A background run keeps the builder open; the lab window's Watch
+    (its guarded `BUILDER_BINDING`, which supplies each executing actor's actual iframe) shows the app. Watch over
+    HTTP is refused. Request bodies may be up to 256 KB (builder documents). `src/builder-input.ts` checks nested
+    scenario blocks, each edit operation and `bound` before posted JSON reaches the builder.
+  - Authoring also works from the declared catalog while the environment is stopped; Run stays disabled until an
+    environment starts. Optional table columns are chosen under Columns (a table with only optional columns starts
+    with the first, never with none), with other cell values preserved. Palette and check responses from an older
+    environment cannot replace the current editor state.
+  - Tests: `tests/builder.test.ts` (served panel, headless: library by role, roster names, Add actors refusal, a
+    duplicate name blocking Save, save and load, run, a Background with a 10-column, 25-row register),
+    `tests/visible-builder.test.ts` (the lab window), `examples/notes/tests/e2e/panel-builder.test.ts` (real chain).
+
+- View modes and activity lanes (Phase 5, `src/client/views.ts`, `src/client/lanes.ts`): Identities and the identity
+  picker offer Focus (the selected identity), Compare (one tile per running identity, or while a run is on only its
+  people, so the lab's own idle identity steps aside until it ends: `runPeople`, `tests/run-tiles.test.ts`; the selected tile glows, and
+  clicking a tile or inside its app selects its identity, `tests/tile-selection.test.ts`) and Follow acting (the
+  default: whose step runs now, or acted last in the active run). A tile's caption is its avatar and name, its host
+  and device pills and one session dot (pulsing while it acts); under it the condition strip says "Acting · waiting
+  for finality" in words while it acts (`.tile-island`, never cut mid-word), beside the network condition and the
+  address bar; the app is named only when the lab has several. In the
+  lab window a stopped selected identity shows why, with Start. Choosing a
+  view sends nothing to the lab; tiles that stay are not re-created (`syncTiles`); in the lab window each actor in the active run remains visible alongside the requested view, including between steps when no action is marked running. An executing actor has an Acting marker in its existing header. Several actors' frames share one page, so the runner has one input lane per window (`VisibleOptions.input`, [Visible input lane](#visible-input-lane)): it holds only the frame checks, bringing the frame and target into view, the hit test and the trusted Playwright input; readiness waits (the frame appearing and following the actor's active app, the target becoming visible) and highlight delays run outside it, so one actor's slow app never holds another actor's input. A fill types its whole text before the next input starts. Run-together domain calls remain concurrent: a watched `… and … at the same time` step (or `these steps run together:`) drives each part in its own actor's frame while waits for finality overlap. Each acting identity has its own highlight ring (`__productLabRing(box, actor)`), placed inside its tile so it scrolls with the tile, so concurrent actors never move each other's ring. "Activity lanes" in Current run (`#lanes-table`) has one row per actor and
+  a shared row (shared resources, run-together groups), one column per Gherkin step of the current feature run (or
+  the latest run), from each step's `actor`, `role`, `resources` and `together`.
+
+- UI extensions (Phase 5 (d), `src/extensions.ts` on the server, `src/client/extensions.ts` in the panel; design
+  section 16, levels 2 and 3): the input renderers, result renderers and panels a lab's integrations declare
+  (`LabRuntime.extensions()`, each already through the client-bundle check: the `ClientBundleChecker` port,
+  `TranspiledClientBundles` in `adapters/lab/module`, which `product-lab lint` runs too). `GET /api/extensions` lists
+  each module with its URL or the reason it is refused: a bundle may import only files of its entry's
+  folder (type-only and unused imports are erased first); a package import (a signer library, the lab's own
+  packages), a path outside the folder, or a file containing one of the lab's secret values (the runtime's redactor)
+  refuses it. `/ext/<n>/<path>` serves only transpiled files of accepted bundles. `GET /api/resource?id=&actor=`
+  reads a published resource (`LabRuntime.readResource`, redacted). Panels appear in the closed-by-default
+  Extensions section (hidden when the lab declares no UI) and mount when opened; an input renderer hides the
+  generated field and writes its value, so the server validates it as before; a result renderer shows under the
+  evidence of a finished run of its action (the run's redacted evidence from `/api/evidence`; when that read fails,
+  the renderer's box shows the failure instead of mounting without the evidence). Each module gets a
+  `PanelApi` (`resource(id).read/subscribe`, `runAction`, `actors`, `selectedActor`, `onActivity`); `runAction`
+  starts the same run as the block's Run button (`/api/run`: same record, trace and Cancel). Every extension is
+  mounted inside an error boundary: a failing mount, subscriber or activity listener shows its error in its own box
+  and nothing else stops. Tests: `tests/extensions.test.ts` (headless, fixture lab `tests/fixtures/extensions/` with a
+  working panel, a panel that fails during a run, and two leaky panels that must be refused).
+- Extension API version: new modules should export `{ apiVersion: 1, mount(element, api) { ... } }`.
+  Existing modules with no `apiVersion` continue as legacy v1. Any other explicit value is refused in
+  the extension's own error box before `mount` is called; it does not affect other extensions or runs.
+  The version identifies the mount/API contract rather than the npm package, and adds no UI-library dependency.
+- Optional React helpers: `@product-lab/shell/react` exports `React`, `defineReactPanel`,
+  `defineReactInputRenderer` and `defineReactResultRenderer`; components receive `{ api }` and factories
+  return v1 modules. Their React root returns an idempotent unmount and catches rendering errors in its
+  own visible boundary. The ordinary panel does not import React. A lab without extensions requests no
+  React asset. As with plain modules, event handlers own their asynchronous errors.
+  Browser modules **do not import the package directly**: run the Node-only
+  `prepareReactUi({ directory })` from `@product-lab/shell/react/prepare` to create `react-ui.js`,
+  `react-ui.d.ts` and a digest manifest inside the consumer UI folder, conventionally its `dist/` subfolder.
+  Then import `{ React, defineReactPanel }` from `./dist/react-ui.js` in that UI module.
+  Preparation bundles only the fixed framework helper with pinned React/ReactDOM; it never accepts a
+  consumer source entry. It requires no environment variables, preserves unchanged files, and repairs a
+  modified generated asset. The original consumer graph and the generated asset both pass the normal
+  client-bundle checker before serving. Its manifest records API major, dependency versions, bytes and SHA256.
+  TSX/JSX use classic `React.createElement`/`React.Fragment`, with relative local imports and no injected
+  `react/jsx-runtime` package. Relative extensionless imports resolve `.ts`, `.tsx`, `.js` or `.jsx` within
+  the checked file list. Tests: `tests/react-prepare.test.ts`, `tests/react-extensions.test.ts`.
+- Extension lifetime: hiding the outer Lab drawer keeps mounts alive. Closing an extension's own panel,
+  replacing or detaching an input/result renderer, changing the environment, or stopping it disposes that
+  mount and its activity/resource subscriptions. Pending imports cannot mount after disposal; an asynchronous
+  mount's eventual cleanup runs once even if its owner has already closed. Stale extension lists and evidence
+  responses cannot replace the current environment or result. Calls through a disposed API cannot start actions
+  or deliver subscribed updates; detached input callbacks cannot change the generated control. Extension code
+  still owns its own asynchronous work and should return its cleanup. The lab cannot cancel arbitrary module
+  promises. Tests: `tests/extension-lifecycle.test.ts` uses real checked modules in Chromium and the actual
+  client's stop path; `tests/resource-watch-lifecycle.test.ts` checks disconnects before and during watch setup.
+- Resource change notifications (Phase 5 rest, design section 16): a resource declared with `watch` is served over
+  `GET /api/resource/watch?id=&actor=` (the same Host/Origin checks as every other route), server-sent events: the
+  current redacted value first, then one `resource` event per change (`LabRuntime.watchResource`, which re-reads
+  and redacts exactly like `readResource` on every notification), or one `static` event and the stream closes for a
+  resource without `watch`. `PanelApi.resource(id).subscribe` (`src/client/extensions.ts`) opens an `EventSource`
+  and falls back to its former 1.5 s poll on a `static` event or a connection error, never silently. Tests:
+  `tests/extensions.test.ts` (a resource with `watch`, one SSE connection instead of a request per tick, the pushed
+  value redacted like a read one; a negative control, bypassing the redactor on the push path only, was run and
+  reverted, see `docs/verification/2026-09-25-phase5.md`) and `core/lab/tests/ui-extensions.test.ts` (`watch()`
+  compiled: `undefined` without it, a kept-open scope released on stop). `examples/notes`'s `notes.account` resource
+  declares `watch` (a short poll of the chain's finalized head); proven live over a real chain in
+  `examples/notes/tests/e2e/panel-builder.test.ts` and, in the lab window, `visible-shell.test.ts`.
+- Extensions in the lab window (Phase 5 rest): the same served bundles, the same `/api/extensions`,
+  `/ext/<n>/<path>` and `/api/resource(/watch)` routes and the same error boundary as a normal panel tab (none of
+  these routes were ever gated on `options.visible`); `PanelApi.runAction` reaches the app through the window's
+  runner binding (Watch) or the server (Background) exactly as a generated block's Run button does (both go through the client's `startRun`).
+  `examples/notes/tests/e2e/visible-shell.test.ts` (`e2e:visible`) proves it: the note-input.ts input renderer
+  mounts and its value reaches the run, and the Notes account panel opens, shows the actor's account, publishes
+  through its own button, and its shown finalized block updates from the `watch` push, all inside the real lab
+  window, headless.
+
+## Tile address bar
+
+Every running actor's app tile has a compact, browser-like address bar in the condition strip under its header
+(`src/client/address-bar.ts`, `src/client/tile-strip.ts`; Grid shows one per tile). It replaced the drawer's former App navigation form
+(Page select, route fields, Open in app, "Last opened by lab").
+
+- **Address**: the frame's address after its origin (for example `/#/`). The origin and whether the address is
+  live or the one the lab opened appear on hover or focus, and in the field's tooltip. Type a subpath (`/#/claim/ada`,
+  `/deep/path`, `#/inside`, `?q=1`, resolved like a link on the page shown, or a full URL on the same origin) and press
+  **Enter** to open it in *that* actor's frame. **Escape** puts the current address back (and never closes the lab
+  drawer); leaving the field does the same.
+- **Host launch parameters are hidden**: the query of the address the host session opened the app at
+  (`ActorSession.appUrl`, or a followed app's active URL) is the session's launch parameters, which host and app URL
+  builders append to a query-less app URL: a deployed app's `?bridge=<its bootstrap.js>` on a truAPI CLI session (the
+  Bulletin gateway's `bridgeParam`, `examples/notes/lab/actors.ts`; an app served by its dev server carries no such
+  parameter since backlog item 64, because the lab's proxy adds the script), the WASM host page's `product`, `mock`,
+  `runtimeConfig` and so on. The bar hides exactly those name=value pairs (deployed Notes shows `/`, not
+  `/?bridge=…`), keeps every other query part as written, shows the full
+  URL in the tooltip, and adds any missing launch pair back to what it opens, so the app still boots in its host. A
+  parameter of the same name with another value is the app's or the person's, and is shown and kept.
+- **Pages** (the chevron, or **ArrowDown** in the field): the app's declared routes (`defineLab({ navigation })`,
+  `GET /api/navigation`), each with its path and parameter names (`/#/claim/:username`). **ArrowUp/ArrowDown** move,
+  **Enter** or a click fills the address; defaults are filled in and the first parameter without one is selected, so
+  typing replaces it. Enter then opens it; a `:name` still in place is refused ("Write Username in place of
+  :username"). The list is offered only while the frame shows the actor's own app (a followed navigation to another
+  app has no declared pages here) and hidden when the lab declares none.
+- **Reload** loads the address shown again as a new document in the same host session. A frame re-created on
+  purpose (the bar, Restart app) carries a per-actor generation in its tile key, so later snapshot polls keep it
+  instead of loading it a second time.
+- **Refusals are inline and nothing navigates**: an address off the origin the frame shows (another port, a
+  protocol-relative `//host`, `javascript:`, credentials) is refused by the bar and again by the client's
+  `openAddress`; a stopped identity has no bar; in the lab window, a frame whose step runs now (Acting) is not
+  navigated away from its step ("pause the run first"). The refusal is text only (`pointer-events: none`), so it never
+  covers a frame for the visible runner's hit test, and an acting frame's open pages list closes. Opening a page is a
+  location change only: no signer, scenario or chain access; the app's own route guards still run. Each actor keeps its
+  last opened address while you switch views or identities; a scenario that replaces the actor's app URL wins, and an
+  environment change discards them.
+- **Truthful location**: the apps are cross-origin to the panel, so a normal browser tab cannot see where an app went
+  after the lab opened it. There the bar shows the address the lab last opened, marked "opened by lab" (hover, focus,
+  tooltip). In the lab window (`bun run lab`, `product-lab [dev]`), `openLabWindow` calls
+  `reportFrameLocations`, which listens to Playwright's `framenavigated` for the shell's actor iframes (new documents,
+  hash changes, history pushes) and dispatches `product-lab:frame-location` (`{ actor, frame, url }`) on the shell
+  window; the bar then shows that address, marked "live". A report is applied only to the iframe element it names
+  (`data-frame`), so a re-created frame never receives an old frame's address. The bar never shows a guessed location.
+
+Tests: `node --import tsx --test entrypoints/panel/tests/address-bar.test.ts` (served shell, headless Chromium,
+loopback fixture apps on ephemeral ports; a normal tab and the lab window via `openLabWindow`, including real
+`framenavigated` reports and the acting guard). Optional `ADDRESS_BAR_SCREENS=<directory>` writes review screenshots
+(unset: none).
+
+## Visible execution: `@product-lab/shell/visible`
+
+Node-side, loads Playwright (the panel server does not). Promoted from the
+browser spike.
+
+- `openLabWindow({ url, runtime, headless?, viewport?, deviceScaleFactor?, videoDir?, reducedMotion?, cursor?, launch? })` launches Chromium on
+  the shell (`bun run lab`, `product-lab [dev]` without `--browser`) and attaches
+  the lab runner before the shell loads. It returns once the shell is built (`html[data-shell="ready"]`, at most 60 s),
+  not at the document's load event, which also waits for every tile's app frame (backlog 225: 22-26 s, and past
+  Playwright's 30 s under load, while a cold dev server compiled; `tests/window-open-ready.test.ts`). `launch` opens the browser instead of Chromium's own launch; the tests pass
+  `launchBrowser` (`tests/shared-browser.ts`) so the window and its detached windows open as GitHub's runner opens them. Its `close()` (`closeLabWindow`) closes the context, then the browser, and
+  rejects with both failures if either fails; a browser that already went away is not a failure
+  (`tests/window-close.test.ts`).
+  The window always runs Chromium's synthetic camera and microphone and accepts their media requests
+  (`LAB_WINDOW_MEDIA_ARGS`, the domain's `SYNTHETIC_MEDIA_ARGS`, built into every launch by `labWindowArgs` and
+  `withSyntheticMedia`, also when the caller passes its own `launch`), including from cross-origin actor frames that
+  delegate camera and microphone, and in every detached window (a context of the window's browser). No app in the
+  window can reach the machine's own camera or microphone, so a device held by another app (a video call) cannot fail
+  a run. Until 22 October 2026 this was the opt-in `syntheticMedia` (CLI `--synthetic-media`, still accepted and now
+  changing nothing); the default used the machine's devices (`tests/window-media.test.ts`). `videoDir` finalizes the
+  Playwright recording when the window closes.
+  `reducedMotion: "reduce"` is an opt-in browser preference that reaches cross-origin app frames;
+  Playwright's `page.emulateMedia` can change that preference in an already mounted frame;
+  apps can use their own accessible reduced-motion route. The default uses the browser's ordinary preference.
+  `cursor` (CLI `--cursor`, `--cursor-speed`) sets show mode ([Identity cursors](#identity-cursors)); absent, a headed
+  window opens with it on and a headless one with it off (`labWindowCursor`); `false` turns it off.
+  `deviceScaleFactor` (headless only; `startDev`'s option of the same name) opens the window at that pixel ratio, for
+  example 2 for sharp captures. Playwright then keeps it in the shell and every app frame, where an override sent from
+  another DevTools session was put back to 1x (`tests/address-bar.test.ts`).
+- **One journey: Watch | Background, and every tab runs** (`src/client/run-mode.ts`).
+  In the lab window a toggle beside the dock's Run (`#run-mode`, default Watch)
+  picks where a run happens: Watch calls the window's bindings (below) and drives
+  the displayed app frames; Background posts to `/api/run`, `/api/feature-run` or
+  `/api/builder/run` like any tab. Any other tab has no binding, so no toggle, and
+  runs in the background; while a lab window is open it says so in
+  `#runner-status` ("Runs in the background here; watch it in the lab window").
+  The server accepts those HTTP runs in every mode (`serveLab(…, { visible: true })`
+  only reports `shell.visible`): they run headless through the actor sessions and
+  never touch the window. A request that asks to be watched over HTTP
+  (`watch: true`) is refused 403 with `WATCH_REFUSAL`, or `NO_WINDOW_WATCH_REFUSAL`
+  when no window is open (`--browser`). Known limit: while a background run acts,
+  the lab window still keeps its acting frames shown and refuses address-bar
+  navigation in them, as for a watched run (the snapshot does not say which runs
+  are watched).
+- The runner (`attachLabRunner`) is a `page.exposeBinding`. The panel's Watch
+  calls it; calls from the app iframe (the binding is installed in every frame)
+  or from another origin are refused and recorded, and a normal browser tab has
+  no binding. Runs are serialized
+  (keyboard focus is page-global) and go through `runtime.runScenario`, so
+  validation, the Scheduler, progress, evidence and cancellation are the usual ones.
+- Before a run the actor's iframe must be displayed, uncovered and showing that
+  actor's app origin; each primitive then proves its target is on screen inside
+  that iframe (`elementFromPoint`), draws the highlight ring in the shell, acts
+  with real input events, and clears the ring. A hidden or covered frame fails.
+  Since 28 September 2026 the runner first brings the acting identity's frame into view, at the start and (since
+  29 September, inside the input lane) before each proof and gesture, including identities the run itself creates: the shell's `__productLabReveal(actor)` (`src/client/window-bindings.ts`)
+  scrolls the actor's tile into view (a grid that scrolls under its scale floor, a clipped grid) and closes a lab
+  overlay that covers it (the drawer, the Lab menu, a picker); a primitive whose target is still not visible asks
+  once more (`VisibleOptions.reveal`), then refuses. Only the shell's own layout changes: anything else covering
+  the frame still fails. Since the redesign no Run closes the lab: every Run (the bottom bar's, a scenario's, the
+  builder's) opens the Run tab beside the people (`tests/run-keeps-panel.test.ts`); the reveal still closes the lab
+  where it covers a tile (a phone-width window, the full size). The reveal measures the layout the shell settles on:
+  it first ends the drawer's slide-in and the stage's move aside, so a drawer opened just before a run stays docked
+  beside the people at desktop width and closes at phone width, whatever the timing (until 5 October 2026 it was
+  measured mid-slide and closed or not by timing; `tests/watch-multi.test.ts`). Before, a watched
+  `count-mismatch.feature` whose new identity Ada acted in a frame under the drawer failed with `Target is not
+  visible inside #application iframe[data-actor="Ada…"]`.
+- Feature scenarios (Phase 4): the Lab panel's "Feature scenarios" section (`src/client/features.ts`) lists the lab's
+  `.feature` scenarios (`GET /api/features`: file, name, tags and the actors its identity steps introduce; since
+  panel-gherkin every field the domain's `parseFeature` keeps, `PanelFeatureScenario`: `kind`, `ownTags`,
+  `featureTags`, `description`, `rule`, `backgroundName`, steps with tables and `docString`, `examplesBlocks`,
+  `markers`, an outline's `variants` named as Cucumber names them, and `feature`: name, description, tags, line; since
+  6 October 2026 read again within about a second of a save in any editor: `GET /api/features/events`,
+  `src/feature-events.ts`, streams the runtime's `features-changed` events from `LabRuntime.watchFeatures`, and
+  `followFeatureFiles` in features.ts reads the list again, keeping the chosen and the open scenario by file and name,
+  `tests/feature-hot-reload.test.ts`), lets the
+  person pick who plays each actor (manual binding; "Create new identity" leaves it to the scenario) and whether to
+  pause after each step, and runs it in the lab process through `runtime.runFeatures({ inProcess })`: the same
+  Cucumber and generated steps as CI, against the running environment. A listed scenario is selected by `path:line`
+  (`featureSelection`): the request's `name` (an outline's raw name, or a variant's), `line` (a scenario's, or an
+  Examples row's for one variant) or `example` (an outline's 1-based variant) becomes the scenario's or row's line,
+  because Cucumber names an outline's scenarios with the placeholders filled in and a filter on the raw name ran
+  nothing; a name the listing does not know keeps the
+  exact name filter (`exactName`). `POST /api/feature-run` starts it from a
+  normal tab or the lab window's Background (in the background; Watch over HTTP is refused); the lab window's Watch uses the runner's second binding
+  (`FEATURE_BINDING`, `runFeature`) starts it with a surface for each executing actor’s displayed iframe, including actors created by the feature. The run waits after a step at the `AfterStep` pause gate;
+  Continue, Step (`POST /api/continue` with `checkpointMode`), Pause and Cancel reach it through the runtime, and the
+  snapshot's `featureRun` carries its progress and checkpoint. Reports go to `<lab>/.product-lab/panel-features/`.
+- Actions reach the app through the Browser port's `AppSurface`: the runner
+  starts the run with the actor's iframe (`visibleAppSurface`) and the action
+  receives it as `ActionContext.ui` (scenario steps as `ScenarioContext.ui`).
+  Without a visible run `ui` is absent and the action uses the actor's own
+  headless page (CI, Cucumber). The action code is the same.
+- Visible primitives recheck the environment generation, actor account/status, current app origin and uncovered frame. The generation is the run's environment session or one that continues it (`LabSnapshot.environmentLineage`: a fixture save or restore reopened it, as an `@isolated` scenario does before and after it; 7 October 2026), with the identity running on the same account (`src/visible/surface-session.ts`, `tests/surface-session.test.ts`); a start, switch or reset is not, and the surface is refused as stale. Before acting, a surface waits (up to 30 s by default, `FOLLOW_TIMEOUT_MS`, outside the input lane) for the displayed frame to show the actor's current active app, because the panel follows a navigation on a later snapshot; whatever it shows when that time runs out is refused, never replaced by a provider page. `openLabWindow` accepts `followTimeoutMs` for a bounded fixture wait; the visible-builder fixture uses 5 s and still checks both permanent refusal and a frame that follows after 1 s. `screenshot()` returns PNG bytes of that exact iframe; it has no storage path or provider-page fallback. Consumers requiring an image must reject surfaces without the optional capability. This is on-demand step evidence, not recording or replay.
+- Focused fixture: `node --import tsx --test entrypoints/panel/tests/visible-builder.test.ts`. It uses the real builder/application/session and served panel with fake external apps and runner I/O; it is not a real-chain journey. The real-chain journey (F1) passed live on 26 September 2026.
+
+```ts
+async run({ actor, ui: shown }, inputs) {
+  const ui = shown ?? new HeadlessAppSurface(actorPage); // @product-lab/browser-playwright
+  await ui.fill(ui.app.getByLabel("Note"), text);
+  await ui.click(ui.app.getByTestId("note-publish"));
+}
+```
+
+
+## Visible input lane
+
+`visibleAppSurface.press` sends trusted keyboard input through the same serialized lane and records a `press` UI
+timing. It proves the owned actor/document and displayed, uncovered frame before input, and bounds locator calls by
+`laneTimeoutMs`. Ordinary focusable app controls use native focus without a pointer click. Prefer those controls for
+existing shortcuts. A tall document body can be targeted only with explicit `{ allowDocumentFocusClick: true }`:
+the surface chooses a visible neutral background point, proves it from the shell, rechecks it before a trusted
+pointer-focus click, verifies app/document focus, then sends the keys in the same lane. A changed point, absent
+capability or no neutral point refuses before key input. Semantic controls, inline handlers and pointer cursors are
+excluded, but geometry cannot rule out arbitrary delegated click handlers. The fallback refuses nested, animated or
+scaled document geometry rather than guessing a point. No app focusability attribute or synthetic event is added.
+`tests/visible-input-lanes.test.ts` covers trusted input, focus isolation, serialized gestures and these refusals.
+
+Disabled, inert and ordinary unfocusable keyboard targets refuse before keys can reach another actor's old focus.
+
+The lab window's runner (`attachLabRunner`, `src/visible/runner.ts`) gives every actor its own surface over its
+displayed iframe (`visibleAppSurface`), and all of them share one serial input lane, because the page's mouse,
+keyboard focus and layout (the grid's scroll, the drawer) are shared. Per UI call:
+
+| Phase | Where | What |
+| --- | --- | --- |
+| Readiness | outside the lane | the actor's frame is shown (bounded 10 s), displays the actor's active app (bounded `followTimeoutMs`, default 30 s), and the target is visible |
+
+A feature's `{actor} is a new actor` step ends only once that actor's tile is ready (`AppSurface.ready`,
+`src/visible/tile-ready.ts`, 5 October 2026): the shell gets `TILE_SHOWN_MS` (5 s) to show the tile (a view that
+shows no tile for the actor has nothing to wait for, including a truAPI WASM person's tile kept mounted out of view,
+hidden, because it holds their session), then the readiness above, the tile's document loaded, the app's
+declared `apps.<id>.ready` steps performed in the tile and its signal there (with the default, the host's report,
+which belongs to the session page, the document only). Before, a person who went offline before her tile loaded kept
+a blank tile to the end of the run. `tests/tile-ready.test.ts`; the feature session awaits it
+(`core/application/tests/feature-conditions.test.ts`).
+| Gesture (click, fill) | in the lane, one hold | the identity check (`verify`: same identity and environment, the displayed document on the actor's active app origin), the target scrolled into view and measured inside its frame, then one shell call: the tile brought into view (`tile`), the frame check (one match, a box, its centre not covered), the target placed in page coordinates and hit-tested from the shell (the element at its centre must be the actor's iframe), the actor's own ring and the cursor's glide; one reveal and a second try if the target is not hit; `visibleDelayMs` for the highlight; then trusted Playwright input: `click`, or click, clear and `pressSequentially` for a fill (the whole text in the same hold, in calls of 16 keys, `TYPED_CHUNK`, each bounded by the target wait plus each key's delay and `TYPED_KEY_MS`, 300 ms: a key's two round trips to the page, measured under load on 23 October 2026; a page that stops answering fails the fill within one call's bound, and typing stops at a call's end when focus left the field, read in the field's own root so a field in a shadow root counts as focused; every read of the field is bounded too), read back after typing (`verified-typing.ts`, 5 October 2026): when focus moved away mid-typing (a click in the window) the field is focused again and only what is missing typed, once, and the call's `note` says so; else the fill fails before any click, naming what the field holds and what took focus (`tests/verified-typing.test.ts`, `tests/visible-fill-focus.test.ts`) |
+| Release | outside the lane | `visibleDelayMs`, then the ring clears |
+
+**A person on a host that embeds its app (backlog 108, 5 October 2026).** The WASM test host runs its core inside its
+host page, which frames the app; a tile loading the bare app has no host and waits at "Connecting to the host…". The
+lab window therefore places such a person's session in their tile (`src/visible/tile-placement.ts`, `TilePlacements`;
+`LabRuntime.placeSessions` when the window opens, `undefined` when it closes, a macrotask after its page went so that
+an owner stopping the lab with its window starts closing the runtime first, which then moves no session): each tile is a `SessionPlacement`, a
+Browser (the port) whose one context is the tile and whose one tab is the tile's document, resolved on every call.
+The host's scripts go on the window's page (each acts only in its own tagged host page), its routes take only
+requests from its own tile's frames, and its sockets cannot be routed for one person in the shared page. C4 (6 October
+2026): the placement says so (`network.sockets`, `TILE_SOCKETS_OPEN`), so a locked host blocks and lists the tile's
+requests (its pages' and their worker's) and leaves sockets open. A route tells a tile's requests by its frames alone:
+the shell names a hosted tile's iframe (`tileFrameName`) before it loads, so no route asks the window's document (one
+that did deadlocked the window's own reload). C7: the window's page is observed from the moment it opens
+(`LabRuntime.observeWindowNetwork`, when the runtime was composed with it), and each tile's tab reads its own traffic
+by its frame's name (`networkEvidence`: its host page, the app inside it and their workers), so the host check sees
+the tile; such a tile's placement says its sockets are observed and listed, not blocked (`TILE_SOCKETS_OBSERVED`).
+The window's debugging port (lane wasm, 6 October 2026; `src/visible/window-hold.ts`): the window's browser opens it
+on 127.0.0.1, at a port the system chose and never logged, so the observer holds each new worker until it watches it,
+only when `LabRuntime.workerHold()` says everything at stake is the lab's own (a local environment, only lab-made
+identities); every local process of every user on the machine can reach it while it is open. A switch to an
+environment that needs it off (a public network) asks first in the switch's own confirm ("Using <network> needs the
+lab window without its debugging port: the window reopens (your runs and recordings stay), then switches. Reopen and
+switch?", `#environment-switch-reopen`, `src/client/window-switch.ts`): yes closes the window's browser, launches one
+without the port, restores the tab (its address, storage and open section) and then switches; Stay changes nothing.
+A switch made elsewhere (MCP, the terminal) reopens the window without the port as that environment starts. The
+`LabWindow` stays the same object across a reopen (`browser`, `page`, `runner` are the current ones, `holding` says
+whether the port is open) and `closed` resolves only when the window really goes. Back on a local environment the
+window stays without the port until it is opened again. Settings shows "Hold worker starts", set in lab.config.ts
+(`workerHold: false` turns it off), greyed with why when off. `tests/window-hold.test.ts`: the port on a local
+environment, the confirm's words, Stay changing nothing, the reopened browser without a port (the old port no longer
+answers), the tab restored, the window not closed, Settings' row on and off, and a switch from outside. The shell shows a hosted tile at the
+host page's address (`TILE_HOSTED_EVENT`, and `__productLabHostedTiles` for a shell that loads later), keeps it mounted
+(hidden) while the view does not show it, names the app's address in its bar (`reportFrameLocations` reads the app
+frame inside), and shows the session's network note in its strip ("network partly locked: sockets open", with why),
+from the person's host (`ActorHost.network`), the same words their row shows; a person with no note shows none. The runner drives the app frame
+inside a hosted tile (`displayedFrame(page, selector, inner)`, `visibleAppSurface({ inner })`, `appFrameSelector`), so
+steps act on and screen checks read what the person sees. `tests/wasm-tile.test.ts` (a fixture embedding host: two
+people each signed in as themselves, the run acting inside, Stop and Start, the window's close taking every session
+back, a control without placement, and C4: Ada locked, her app's request blocked and listed before and after the
+window is refreshed, Grace's same request not hers to block, her row and tile in the same words, and C6's limit chip
+on her row). Backlog 153 (6 October 2026): a person whose host embeds its app (`ActorHost.embedsApp`, from the host's `placement` capability) whose tile shows the app without the host page is refused by a Watch run at once, in plain words with what to do (`src/visible/embedded-host.ts`, `tests/embedded-host.test.ts`), instead of waiting 120 s for an account the app never gets.
+
+**The run view before the first gesture (30 September 2026, backlog 4b).** The shell learns about a run from its
+snapshot poll (about every 1.5 s) and then shows the run's tiles (the run view: its identities beside the requested
+view, Grid for a watched run with several actors). A gesture checked before that poll placed its ring and cursor in the
+old layout, which the switch then moved (the input still landed right). Now the first gesture of each new set of active
+runs asks the shell to draw the run view at once (`src/visible/run-view.ts`, `runViewSync`; the shell's
+`__productLabRunView` reads `/api/lab` and renders it), in the input lane because it moves the layout, bounded by
+`runViewTimeoutMs` (default 5 s); concurrent gestures share the request, later gestures of the same runs skip it, and a
+feature run's steps (one run each) ask once per step. A shell without the function, a timeout or a failure is recorded
+in `runner.runViews` and not retried for that set; the gesture's own checks still guard the input. Its time counts as
+follow time in the call's timing. Follow action in the lab window keeps the run's identities in the run's order while a
+run acts (`visibleRunTiles`), so following the step that runs now no longer reorders the tiles under a gesture. Tests:
+`tests/run-view.test.ts` (the sync), `tests/views-lanes.test.ts` (the order), `tests/run-view-switch.test.ts` (the lab
+window: every ring of a two-identity run started from Follow view is drawn in the run view).
+
+The checks run right before the input and no other actor can move the layout in between, so a gesture takes the lane
+once. (Until 30 September 2026 it took it twice, a proof with the highlight delay outside the lane and then the
+gesture repeating every check; in a live three-actor capture that doubled each hold, 3 to 10 s per click under
+load, and two of three runs missed the app's reporting deadline; a verification record of 29 September 2026.) Reads and waits take only the proof (checks and ring in
+the lane, the highlight delay outside it); a screenshot's capture and a reload's frame check run in the lane (a
+capture scrolls the frame into view). Nothing is dispatched from the DOM: the app sees `isTrusted` events.
+
+**Three page calls per check (30 September 2026, backlog 4a).** Each browser call made from the lane waits for the
+page's main thread, which the shell and every app frame share; with busy apps each call costs a frame or more, and the
+calls, not the input, made up most of a hold (live three-actor captures: 1.6 to 3.8 s median per click outside the input). The
+checks now make three calls where they made about ten:
+
+- Identity: `displayedFrame` resolves the iframe element's frame once and marks the element; later checks confirm with
+  one page call that the selector still matches exactly that element and read the frame's address locally (Playwright
+  updates it from the browser's navigation events). Another element, several matches or a detached frame resolve again.
+  The runner and the primitives share one cache per surface (`VisibleOptions.displayed`); `verify` receives the frame.
+- Target: one call inside the frame (`Locator.evaluate`) scrolls the target to its nearest edge (nothing moves when it
+  is fully in view) and measures it there, with the mark of its document. A target whose document is not the actor's
+  frame's document is refused ("Target is not inside ..."), since it is placed from that frame's box.
+- Shell: one call reveals the tile, checks the frame, waits until the frame's box holds still for a frame (bounded by
+  `laneTimeoutMs`; a shell transition slides or widens the tiles), places and hit-tests the target, draws the ring and
+  starts the cursor. A frame resized since the target was measured measures it again.
+- The old way (Playwright's wait for a stable box, then the browser's own box of the target) remains for a target in
+  a nested frame, a scaled frame, a target that a finite CSS animation moves, and a surface without `displayed`.
+- Playwright's input itself still waits for a stable, visible, enabled target and checks that the frame and the
+  target receive the event at the input point, right before it acts.
+
+Every wait for the target inside the lane (scroll into view, its box, the click, the field for a fill) is bounded by
+`VisibleOptions.laneTimeoutMs` (default `LANE_TARGET_TIMEOUT_MS`, 5 s; typing adds its own length times the delay).
+Readiness already waited for the target outside the lane; a target that changed since (re-rendered or relabelled)
+fails the call quickly instead of holding every other actor's input for the page's default timeout. Before 30
+September 2026 those waits used the page default: in a live three-actor capture one actor's vanished button held
+the lane 34.3 s while the others queued (the same record).
+`tests/visible-input-lanes.test.ts` checks the bound (a changed target fails within it and the next actor's input
+lands).
+
+### UI call timing
+
+Every call of a lab-runner surface is timed (`src/visible/ui-timing.ts`), so a capture can tell a slow app from input
+contention. The run's `runner.journal` entry carries `calls` (one `UiCallTiming` per call, in the order they
+settled) and `callSummary` (`summarizeUiCalls`); `openLabWindow({ onUiCall })` / `LabRunnerOptions.onUiCall` receives
+each call as it settles, for a live log. Times are milliseconds since the runner attached (the journal's clock).
+
+| Field | Meaning |
+| --- | --- |
+| `actor`, `call` | the actor session id of the surface; `click`, `fill`, `read`, `waitFor`, `screenshot` or `reload` |
+| `startedMs`, `durationMs` | when the call started; its whole wall time |
+| `readyMs` | readiness outside the lane: the frame shown, the target visible (without `followMs`) |
+| `followMs` | waiting for the displayed frame to show the actor's active app (the bounded follow) |
+| `laneWaitMs` | waiting to acquire the shared input lane (summed, if a call takes it more than once) |
+| `laneHoldMs` | holding the lane: the checks, the highlight delay of a gesture, and the input |
+| `inputMs`, `inputAtMs` | the physical input alone (a fill's click, clear and whole text) and when it started |
+| `ok`, `error` | the call's outcome |
+| `target` | what the call acted on, as its locator describes itself (`getByLabel('Note')`), when it says |
+| `segments` | where the time went, in order (the [run timeline](#run-timeline)'s app strip): `follow`, `ready`, `lane-wait`, `lane-hold` (with `input` inside it) and `hold` (the highlight delay), each `{ phase, startMs, endMs }`; each phase's stretches add up to its sum above |
+| `laneSteps` | where the lane holds went, ms per step (`LaneStep`): `identify` (the identity check; also re-reading a reloaded document's mark), `scroll` (the target brought into view and measured in its frame), `hit` (the shell call: reveal, frame check, stable frame, hit test, ring, cursor glide), `delay` (the highlight delay inside a gesture), `cursor` (sending the click ripple), `input`, and on the old way or a retry `reveal`, `frame`, `box`, `ring`, `capture` (a screenshot). Steps not taken are absent. Records from before 30 September 2026 have no `laneSteps`; the instrumented base (`22d8b9cd`) records `reveal`, `frame`, `box` and `ring` as their own calls |
+
+`callSummary.actors` sums them per actor (`calls`, `failed`, `firstCallMs`, `firstInputMs`, the sums, `maxLaneWaitMs`,
+`maxLaneHoldMs`), `entrySpreadMs` is the spread of the actors' first inputs, and `laneWaitMs`/`maxLaneWaitMs` cover
+all actors. A fill's `laneHoldMs` minus `inputMs` and `laneSteps.delay` is its checks; its `inputMs` grows with the text
+and `typingDelayMs`.
+
+Tests: `tests/visible-input-lanes.test.ts` (one page, two frames: a slow readiness holds no other input; the lane holds
+the checks, scroll and gesture; the timing fields; a target in another frame's document is refused; the frame cache
+resolves another element under the selector again; the identity check sees a navigation between two gestures; a
+moving target and a sliding frame are waited for, so the ring ends where the input lands; with a tile, a frame whose
+centre is covered is refused and the tile is revealed before a frame check), `tests/ui-timing.test.ts` (the summary)
+and `tests/visible-multi-actor.test.ts` (the lab window, three fixture actors in one run-together group, at 1440 px and
+in the scrolling grid at 700×500 px: a slow actor's readiness holds no other actor's input, every fill's text arrives
+whole with trusted events, each ring stays over its own tile, every call takes the three-call checks, and a covered
+frame or a frame showing another app is refused while the other actor completes). Their negative controls (readiness
+routed through the lane, typing outside it, fixed rings, the origin check removed;
+the document mark, the frame cache's element check,
+the stable-box fallback, the frame stability wait, the reveal, the frame check and verifying every gesture removed)
+each make them fail.
+
+For measuring the lane, `visible-multi-actor.test.ts` reads two optional variables: `VISIBLE_MULTI_ACTOR_CPU_RATE`
+(default 1: the lab page's CPU throttled this many times through Chromium's emulation) and
+`VISIBLE_MULTI_ACTOR_APP_BUSY_MS` (default 0: each fixture app keeps the main thread busy this many ms every animation
+frame, like an animated app); its `timing` diagnostic lists every call's lane wait, hold, input and `laneSteps`.
+
+## Run timeline
+
+Backlog item 10 (29 September 2026). Runs > Timeline
+(`src/client/view-timeline.ts`, `view-timeline.css`, model `src/client/timeline.ts`) draws the run Current shows as a
+waterfall: one row per identity that acted, plus Setup for the lab's own setup work, on one time axis; one bar per step
+(a lab run's step; a feature run's Gherkin action step), from when it started to when it ended, live while it runs (the
+bar grows and shows the phase it is in). Each bar has two strips:
+
+| Strip | Stretches | From |
+| --- | --- | --- |
+| App | navigation follow, readiness wait, input-lane wait, lane checks, input, highlight hold; the step's waits | the lab window's UI calls (`UiCallTiming.segments`), the activity's `waits` |
+| Chain | signing (until broadcast), submitted (until included), finality lag (included until finalized), a failure; striped: a transaction the identity's app sent by itself during the step | the activity's transactions: `startedAt`, `submittedAt` (new), `includedAt`, `finishedAt`, `block`; the activity's `observed` (the account watch) |
+
+Choosing a bar lists its stretches with offsets and facts (target, block numbers); "As a table" lists every bar with
+what each kind took. Nothing is estimated: a kind the run did not record is absent, and the timeline says what it cannot
+show (another tab or a Background run has no UI phases; a recording holds no UI calls).
+
+- UI calls reach the shell from the lab window's Node side (`src/visible/ui-activity.ts`, `uiActivityFeed`): each
+  phase a call enters and each call that settles is pushed as a `product-lab:ui-call` window event, in wall-clock
+  milliseconds (the window runs in the lab's own process, so they line up with the runtime's times); pushes are queued
+  and never awaited by the call. A (re)loaded shell reads the bounded history (2000 calls) once through the guarded
+  `__productLabUiCalls` binding (`src/client/ui-calls.ts`). A call belongs to the bar of the same identity that was
+  running when it started. Since backlog 110 the feed also keeps the settled calls in the order they settled
+  (`settledSince(cursor)`), which the window's frame source offers run recordings as `FrameCapture.uiCalls`
+  (`src/visible/window-frames.ts`, forwarded by `detachedFrameCapture`): a recording keeps each step's calls
+  (`tests/ui-activity-recorded.test.ts`).
+- A recording's frame from the lab window is taken once the tile holds still (backlog 110, `steadyFrameBox` in
+  `src/visible/window-frames.ts`): its box must stay the same across rendered frames with no animation running on
+  it, within `STEADY_MS` (2 s, at most half the capture's limit), and be the same after the image, else the image is
+  taken again once; tiles that keep moving give an unavailable frame saying so (`tests/window-frames.test.ts`).
+- The image is one capture of the whole window, never a clip (a headed window shows a clip alone for a frame:
+  `src/visible/viewport-shot.ts`), and each frame's part is cut and encoded in the PNG worker (`png-worker.mjs`, body
+  `png-work.ts`, pixels `png-parts.ts`): parts of one capture asked for together share a decode, and the lab's main
+  thread does no PNG work, which held up the highlight holds' timers (the cursor test's 457 and 486 ms holds on Linux).
+  The worker holds its process open only while it has work; a worker that fails or stops fails the frames it holds with
+  its message (`tests/png-worker.test.ts`, `tests/viewport-shot.test.ts`).
+- Recordings (backlog 192): a replay whose run kept its hosts' logs names each above "Where the time went", by its whole
+  path where the store keeps it, saying when only its tail was kept (`hostLogsNode`, `src/client/recordings.ts`; test
+  `tests/host-logs-served.test.ts`).
+- Recordings: the replay viewer's "Where the time went" draws the same waterfall from the recording's steps and
+  transactions (which keep `submittedAt` and `includedAt` since this change; older recordings show each transaction as
+  one stretch and say so). Choosing a bar selects that recorded step.
+
+Tests: `tests/timeline-model.test.ts` (rows and Setup, UI phases and transaction states per bar, totals, notes, a
+recording), `tests/timeline.test.ts` (browser: a finished Background run and a recording's replay over a served
+runtime; a live Watch run in the lab window where the waiting bar grows, the finished bars hold both identities' UI
+phases and transaction states, and a reloaded shell gets the calls back), `tests/visible-input-lanes.test.ts`
+(segments add up to the sums).
+
+## Release notice
+
+2 October 2026. `ServeOptions.release` (a `ReleaseNotice` from
+`@product-lab/domain/releases`, which `product-lab dev` passes when its command said what is new or that a newer
+version is published) is served as `shell.release` with its lines (`releaseNoticeLines`), and
+`src/client/release-notice.ts` shows it in a card above the dock (`#release-notice`, fixed so the app frame and the
+island never cover it): the first line as its title, breaking changes marked, and Dismiss, kept per version in the
+browser's `localStorage`. Without a notice nothing is shown. `tests/release-notice.test.ts` (browser).
+
+## Live activity bar
+
+Backlog item 11 (29 September 2026). "The island"
+(`src/client/island.ts`, `island.css`) says what the lab does now. Its own row above the apps is gone since the redesign
+(the user found it unreadable); the same facts live
+where people look. Per acting principal (an identity, or Setup) `islandState` (pure) knows:
+
+- its step (number and title) and how long it has run, against how long the same step (same title) took before in
+  this session (`stepEstimate`: the median of the earlier completed runs, with how many; absent when there were none);
+- what it does now (typing into, clicking a target) and what it waits for, each with its kind: `app` (an app element to
+  appear, or its frame to follow its app: the lab window's live UI call phases), `lane` (another identity's input),
+  `lock` (a run-together step waiting for resources an earlier step holds: `ExecutionStep.waitsFor`), `block`
+  (inclusion, or finality: "finality of #21: finalized #19, 2 behind"), `host` (host onboarding: the environment
+  operation that runs during the run, or an identity whose session is starting), or a step's own wait;
+- its transaction's state with block numbers and how far finality lags (the chain heads the lab observed).
+- Transactions an identity's app sent by itself ([App-sent transactions](#app-sent-transactions)): on the acting
+  step's item when the lab sent none ("App sent: Ada · included #22 · 3 behind finality"), else on that identity's
+  tile until 15 s after they were finalized; the live region names them too.
+
+Where it shows: each acting identity's tile header has a short form in words (`.tile-island`, `tileWords`: "typing…",
+"waiting for the app", "waiting for finality", "Publish included #21"), its title the whole detail (step, time and
+estimate, the target, the waits, the transaction); a Playwright locator never appears in a headline. The bottom bar
+says the run's line beside a spinner (`#compact-progress`, `src/client/dock-status.ts` `runLineText`: "Running step 4
+of 7 · 0:21", else Ready, Paused · step N, Passed · time, Failed at step N), with the run's own waits in its title. The
+environment pill's title carries the chains' heads ("People #23 · finalized #19"); the environment picker does not
+(since 5 October 2026: it chooses an environment, and each chain's heads are the Environment section's table). The
+pill shows its whole name: in the bar the run's line gives way first and in the pill its detail; the name shortens
+only when the bar has no room left, its title naming it whole (`tests/environment-polish.test.ts`, 1440, 1024, 760
+and 300 px). A polite live region
+(`#island-live`) announces a change of step, transaction state or wait, never the passing seconds;
+`prefers-reduced-motion` stills the spinner. Nothing in it acts: it reads the snapshot and the lab window's UI calls.
+
+Tests: `tests/island-model.test.ts` (items, waits of every kind, transaction text, estimates, the live-region sentence),
+`tests/island.test.ts` (the lab window, two fixture identities: a transaction included in #21 with finality at #19,
+an identity waiting for its app's element; the same facts on the tiles, the bottom bar, the environment pill and the
+live region, no locator in a headline, an estimate on the second run, reduced motion; control: without the chains'
+heads on the pill it fails).
+
+## App-sent transactions
+
+Backlog item 12 (29 September 2026). An app may sign
+and submit a transaction without the lab (a person publishing by hand in the lab window, or an app's own background
+work); the lab never sees those through its own reports. The runtime's account watch (`AccountWatch` in
+`@product-lab/application`, over the environment's `chains()`: new blocks, the pool, nonces) records each one as
+`activity.observed` (`ObservedTransactionActivity`: chain, hash, the identity, `pending`/`included`/`finalized`/
+`retracted`, block and index, dispatch result, when first seen, the run and step acting as that identity then). The
+panel shows them as "sent by the app": in the activity bar, on the run timeline's chain strip (striped), and under
+Evidence > Transactions ("Sent by the app, seen on chain"). They are never the lab's transactions: the run's
+Transactions count, receipts, landing and reconciliation do not include them, and one whose hash the lab reported as
+its own is not shown.
+
+## Devices
+
+`src/visible/device-catalogue.ts` (backlogs 31a and 31b, 3 October 2026): Playwright's named devices as the domain's
+`DeviceProfile`s (`deviceCatalogue`, with the desktop window "Desktop"), `deviceNames` (phones, then tablets, then
+desktops; landscape after portrait; `deviceKind`: a mobile device whose shorter side is 600 CSS pixels or more is a
+tablet), `deviceFor` (a name or a written-out profile through the domain's `resolveDevice`: an unknown name throws with
+the nearest names, never another device) and `deviceContextOptions` (the Playwright context options of a profile). The
+browser is Chromium whatever a device is called. Test: `tests/device-catalogue.test.ts`. `@product-lab/shell/visible`
+exports `deviceCatalogue` so `tools/verify/tests/device-catalogues.test.ts` can check it against the browser adapter's
+copy (`playwrightDevices`, used by `product-lab test --devices`, backlog 31c): every device the panel names is the
+adapter's, with the same profile.
+
+## Detached identity windows
+
+Window videos (backlog 18b, the window half, 4 October 2026): with
+`LabWindowOptions.recordingVideos` (the runtime's `RecordingListing.videos`, set by `dev` when
+`PRODUCT_LAB_RECORDINGS_VIDEO=on`) the lab window and each detached window (`DetachedWindowOptions.recordVideo`, at
+the window's opening size: a phone's or tablet's with its device frame, as the person saw it) record into the
+recordings' `videos/`. The window's frame capture names them
+(`FrameCapture.video`): `windowFrameCapture` the window's one video (`lab-window`, scope `window`: no identity), and
+`detachedFrameCapture` a detached identity's own window (`detached-window`), bounded like its frames. `window-video.ts`
+notes when each page opened and refuses a video recorded outside the recordings (`videoDir`, `--video <dir>`, which wins
+for the lab window) with why; it is a small copy of the Playwright adapter's helper, since an entry point never imports
+an adapter (`tests/window-video.test.ts`, `tests/window-video-recording.test.ts`).
+
+Backlog 31b (3 October 2026; live on Notes:
+`bunx nx run notes:e2e:detached`). In the lab window an identity can run in a window of its own, emulating a device,
+while its tile mirrors that window:
+
+- **Choosing.** `product-lab dev --detach "Ada=Pixel 7"` (repeatable; the lab window's `detach` option) detaches an
+  identity of that name once it runs and no run is going on (one a run creates moves when that run ends), once: a
+  reattached one stays in its tile. A tile's caption has one **Device** menu (backlog 31a: the device its
+  tile shows the app as) and **Open in own window**, which opens the identity's window as that device (Desktop when the
+  tile fills its space; in a narrow tile only its icon); a detached tile shows the device and **Reattach**. An app that
+  refuses framing (backlog 66) keeps the menu in its caption and gets **Open in own window** in its refusal. An identity
+  moves only between runs, the lab window's own in-process runs included (`LabSnapshot.featureRun`): during a run
+  both are refused ("Refused: a run is going on; detach Ada between runs"). An
+  unknown device is refused with the nearest names. A window the person closes brings its identity back to its tile.
+- **The window** (`src/visible/detached-window.ts`; detached-fix, 5 October 2026):
+  a browser context of its own in the lab window's
+  browser, opening the address the tile would show. It is the same host session and identity (the app through the
+  lab's proxy with the session's bridge); the app starts fresh in it, as after Restart app.
+  - A desktop device is a normal window: it opens at the device's size and the app follows the window when the person
+    resizes it (no fixed viewport).
+  - A phone or tablet is shown in its device frame (`#device`, `iframe#app`), centred and scaled to fit the window
+    (`data-scale`); the app inside has the device's own viewport, pixel ratio, touch and user agent
+    (`device-catalogue.ts`), whatever the window's size. The pixel ratio is set once when the window opens, on the
+    page and on the app's frame (a renderer of its own), never around a capture. `DetachedWindow.app` is the app's
+    frame and `appBox()` where the frame shows it.
+  - An app that refuses framing (X-Frame-Options, CSP `frame-ancestors`) is opened without the frame, at the device's
+    exact emulation, and its tile says so: "Ada's Pixel 7 window is shown without the device frame: the app refuses
+    framing" (`FRAMING_REFUSED`).
+  - `capture()` is a step's frame: the app alone, no device frame, its whole viewport at the pixels the window draws
+    (the display's when headed; 1 headless). It is one whole-window capture through a CDP session that emulates
+    nothing, with no clip (`viewport-shot.ts`'s rule): a clipped capture, or one through the session holding the pixel
+    ratio, is drawn on screen for a frame, and Playwright's own capture also dropped the device's pixel ratio for the
+    rest of the window's life. The app's part is cut, and fitted to its viewport, in the PNG worker (see the lab window's recording frames).
+- **Running** (`detached-surface.ts`, `runner.ts`): a detached identity's steps act on its window's page, in an input
+  lane of its own, with the tile's checks: the identity's active app, the target in view and on top at its centre
+  (`elementFromPoint`, a read), then trusted input at that point (a touchscreen tap when the device has touch, else a
+  mouse click). Nothing is injected into the app: its document is unchanged by the lab (a test plants an injection and
+  fails). A window closed during a step fails that step, "Ada's detached window was closed", never retried in the tile.
+  Run recordings take a detached identity's frames from its window (`detachedFrameCapture`): each screenshot is
+  bounded by the recorder's own limit (`timeoutMs` of the capture; 5 s, `DETACHED_CAPTURE_TIMEOUT_MS`, when it names
+  none) and a late one fails its frame by name, never a silent stall. `AppSurface.device` is
+  the device; `AppSurface.conditions` throttles its CPU alone (`detached-conditions.ts`); its network is named
+  unavailable until backlog 31's routed conditions (Chromium's own emulation would also cut the link to the host).
+- **Conditions on a tile** (lab-window finding 2d, 4 October 2026; `tile-conditions.ts`): before, Watch refused every
+  condition step ("The lab window's surfaces cannot apply a network condition") while a background run applied it. A
+  tile's surface now carries a network control: every request whose frame sits in that identity's tile
+  (`iframe[data-actor]`, nested frames included) goes through the domain's `trafficDecision` on the lab window's own
+  routes, the identity's local links to its host exempt (the runtime passes its session's); the lab's requests and
+  other tiles are untouched. The runtime applies the same condition to the identity's session beside it, since the
+  host's own connections (a native host's links) carry the tile's chain traffic. The Watch runner tells the plan what
+  each surface can apply (`surfaceConditions`): a tile its network, a detached window its CPU. Limits: a tile's own
+  WebSockets are not conditioned (Playwright's socket route names no frame, so one tile's socket cannot be told from
+  another's or the lab's); CPU is refused on a tile, "CPU per tile needs the detached window" (every tile shares the
+  lab window's renderer: all are 127.0.0.1, one site); a detached window's network stays unavailable.
+  `tests/watch-conditions.test.ts`: Grace offline in Watch, her tile's fetch fails and her session is told; Ada's tile
+  stays online; back online Grace reaches the server; a slower tile is refused with the reason; with the tile routing
+  disabled, Grace's tile still answered while offline (the control).
+- **The condition strip** (redesign step 3; `client/tile-strip.ts`): under each tile's header, the condition the lab
+  window applies to that tile ("online"; "offline" red with its seconds; "slow" amber with its delay and rate in the
+  mono face), then the address bar and the pop-out ("Open in own window"). `TileConditions` reports each change to the
+  shell (`product-lab:tile-condition`) and keeps a record on the window (`__productLabTileConditions`); a reloaded
+  shell is told again. A condition a scenario step set on the identity's session (a Background run, or any run in a
+  tab that is not the lab window) comes with the snapshot (`LabSnapshot.actorConditions`) and shows when no tile
+  report does: named by its profile ("slow 3G", the CPU slowdown beside it), back to "online" when the scenario ends;
+  a step's throttle reported by the tile is named by its profile too.
+  `tests/tile-conditions-served.test.ts`: offline, slow, back online and a reload, driven by `TileConditions` on a
+  served shell; Grace's tile stays online and reaches its server while Ada's fails (the control); a step's slow-3g
+  from the snapshot, and online once it is gone.
+- **The mirror** (`mirror.ts`, `client/detached-tiles.ts`): Chromium's DevTools screencast of the window, at most ten
+  JPEG frames a second, newest first, every frame acknowledged; Chromium only, refused by name elsewhere. The tile shows
+  the frames (`img[data-mirror]`), the ring of each gesture's target scaled onto them, and "mirror stopped: …" or "no
+  frame for 5 s" instead of an old frame shown as live. A framed window's mirror is cropped to the app
+  (`object-view-box`, `data-crop="app"`). The mirror only shows: input goes to the window.
+- **Wiring** (`detached-identities.ts`): the registry the lab window creates (`LabWindow.detached`), the shell's
+  `__productLabDetach` binding (list, devices, detach, reattach; from the shell's main frame only) and the events the
+  shell listens to (`product-lab:detached`, `product-lab:mirror-frame`, `product-lab:mirror-ring`).
+
+Tests: `tests/detached-window.test.ts` (the device the app sees, a desktop window the app follows when resized, a
+phone in its frame scaled to fit with the app's viewport and pixel ratio unchanged by the window or a capture, an app
+refusing framing, tap and click, the unchanged document, refusals, a window closed mid-call, the mirror, CPU) and `tests/detached-lab-window.test.ts` (in the lab window: `detach` by name,
+a scenario mixing a detached phone and a tile, the mirror and its ring, refusals during a run, Reattach, a closed
+window, backlog 66). Not yet: a lab's own `defineLab({ windows })`, hot reload of a detached window, and input from
+the mirror.
+
+## Lab menu and Settings
+
+Panel redesign step 6 (`src/client/lab-menu.ts`, `lab-menu.css`, `src/client/settings.ts`, `view-settings.css`;
+lab-mockups `6-lab-menu`, `8-settings`; tools-page `9-tools-menu`). The bottom bar's Lab button opens the menu: Current
+run (R), Scenarios (S), Recordings and replays (P), Builder (B), Chain console (C, the Environment view's console,
+opened), Environments (E), Tools (T) and Settings (,), then More: Identities, Run timeline, Past runs, Evidence & reports,
+Config and Find anything (⌘K). Config (`src/client/view-config.ts`, `view-config.css`; config redesign, 6 October 2026)
+shows the loader's resolved config (`registry.config`) grouped and worded as `product-lab config` prints it
+(`@product-lab/domain/lab/resolved-config`, served as `/resolved-config.js`): one card per group, each value with a
+source chip (yours, default, detected, advanced), its key and why, "Change it:" with the line to write (copyable) and the
+other values it takes, greyed; a search narrows it; a value from a secret shows its variable's name only
+(`tests/config-view.test.ts`, docked right and bottom at the default width and 280 px, over a fixture and over the
+loader's real resolved config; controls: no config shows the empty state, a squeezed value is caught as cut). While no
+environment runs (before the first start, or after Stop; backlog 194, 8 October 2026) the client reads `/api/config` once
+per stop: `LabRuntime.registry()`'s config, from the catalog's registry when nothing runs, or `null`, which draws the
+empty state ("a stopped lab", over the real loader; control: a stopped lab whose loader gives none). What a
+product config leaves off or unset (`offConfigItems`, `configEntryOff`) is shown greyed with the loader's line, never
+hidden: in Config ("Turn it on:", "Set it:", a set or not set chip on entries naming variables), in the Environments
+list and the chain picker under "Not on in this lab" (the local dev chain turned off, Local copy of Previewnet,
+Chopsticks, a live network not listed, one with no people, one whose person's variable is unset: "Not set · run
+export …"), and in New identity's host menu (a host turned off, dot.li), the config's line winning over the session's.
+Each line sits in a block of its own under its words, the copy button at its right (`configLine`), its tokens wrapping
+whole (`codeTokens`: never at a hyphen; a token breaks only when it alone is wider than the block; the Config view's line too)
+(`tests/greyed-config.test.ts`, over the real loader's resolved config, docked right and bottom at the default width and
+280 px, with the copy button on the code block's row and no token broken; controls: a hidden row, one at full strength,
+the copy button pushed under the code, a token broken mid-word and an entry gone each fail). An older definition keeps
+the kind-based rows (`ENVIRONMENT_KINDS`). The Environment view's Advanced facts name a topology's profile in people's words (`profileWords`: the local dev chain adapter
+is the "Local dev chain (Omni Node)"). Actions & blocks, Extensions and Characters are tabs of Tools ([the Tools page](#the-tools-page),
+user decision, 5 October 2026); `src/controls.ts`'s `openSection` reaches a tab through Tools. A key opens its place anywhere in the lab, its own window included, unless it is typed into a
+field or a dialog or carries a modifier (an app's keys stay in its frame); Escape or a press outside closes the menu.
+Settings is a sectioned list, one row per setting: Lab window (Show cursor, Cursor speed; outside the lab window they
+say why they cannot change) and Appearance (Theme: dark, light or system, which follows the system's preference live;
+nothing saved follows the system). Choices are kept in the lab's local state through the lab server (GET and POST
+`/api/settings`; `LabRuntime.settings()`, `<lab>/.product-lab/settings.json` by the composition root), read when the
+window starts, so they outlive the lab window's fresh browser context on every launch; a saved choice wins over the
+default. A change the server refuses is shown under the list and holds for that page only. Tests: `tests/lab-menu-model.test.ts` (keys, theme),
+`tests/lab-menu.test.ts` (the served menu and Settings in the lab window), `tests/cursor.test.ts`,
+`tests/cursor-mode.test.ts` (the default).
+
+## Identity cursors
+
+Backlog item 48, show mode (29 September 2026). For
+demos and for following several identities at once: each acting identity gets its own cursor over its tile, named and
+in the identity's colour (`--actor-tone`), which glides to the target while the highlight is held and ripples at the
+real click (`src/client/show-cursor.ts`, `show-cursor.css`). It is drawn by the shell, never inside the app, with
+`pointer-events: none` and `aria-hidden`, so hit tests and the app's own events are unchanged; a cursor that has not
+moved for 4 s fades. It is drawn above its identity's highlight ring (both in the tile, the ring one `z-index` below)
+and under the lab's menus, dialogs and toasts, since the tile is its own stacking context (`tests/cursor.test.ts`). On by default in the visible, headed lab window
+a person watches; off in a headless one (tests, CI) and in Background runs, which act on headless pages
+(`labWindowCursor`, docs/panel-redesign.md "Decisions"). `openLabWindow({ cursor: true | false | { speed } })` (CLI
+`--cursor`, `--cursor-speed slow|normal|fast|<ms>`) sets it, and [Settings](#lab-menu-and-settings) turns it on or off
+while the window runs: Show cursor, and Cursor speed slow (700 ms), normal (350 ms) or fast (150 ms). A choice saved
+in Settings wins over the window's mode at the next load. Settings talks to the runner through the window binding `__productLabCursorMode`
+(`CURSOR_BINDING`, `parseCursorMode` refuses a malformed request); the runner reads the mode before each gesture, so a
+change applies to the next one.
+
+- Timing: the glide is `cursorGlideMs(speed, visibleDelayMs)`, never longer than the highlight delay it runs in; it
+  starts in the lane's shell call with the ring (no call of its own, since 30 September 2026), and the ripple is a
+  `page.evaluate` the runner does not await, so input is never later than without the cursor. Off, the runner sends
+  nothing to the page for cursors (`VisibleOptions.cursor` returns undefined).
+- Reduced motion: the cursor moves without gliding and the ripple is a still ring.
+- Tests: `tests/cursor-mode.test.ts` (the cap, the request checks), `tests/cursor.test.ts` (the lab window, two
+  fixture identities acting at once: off sends no call; on, each cursor in its own tile with its name and colour, the
+  glide capped at the 300 ms delay, the ripple at the button's centre before the app's click, the point still hitting
+  the app frame, holds not lengthened, the speed item, reduced motion, off again removes the cursors).
+
+## Package
+
+| | |
+| --- | --- |
+| Nx project | `shell` (folder `entrypoints/panel`, the target name; the package keeps its pre-refactor name) |
+| Tags | `scope:core`, `layer:shell`, `type:driving` |
+| Exports | `.` (`src/index.ts`: `serveLab`, `WATCH_REFUSAL`, `NO_WINDOW_WATCH_REFUSAL`, `ServeOptions`; Phase 4: `panelFeatures`, `featureControl` (whether a run is a control its tags judge: `{}` for a tagged scenario or file), `featureBindings`, `exactName`, `PanelFeatureScenario`; backlog 182: `panelRunsDirectory` (where the window's feature runs keep their reports, which the terminal app's runs share); Phase 5 (d): `extensionViews`; panel-gherkin: `featureSelection`, `PanelFeatureSelection`), `./visible` (`src/visible/index.ts`: `openLabWindow`, `attachLabRunner`, `attachRunner`, `visibleAppSurface`, `VisibleSurfaceOptions`, `summarizeUiCalls`, `UiCallTiming`, `UiCallSummary`, `UiActorTiming`, `UiCall`, `UiCallSegment`, `UiPhase`, `uiActivityFeed`, `UiActivityFeed`, `UiActivityCall`, `UiActivitySegment`, `UI_CALL_EVENT`, `UI_CALLS_BINDING`, `describeTarget`, `visibleUi`, `showRing`, `assertFrameDisplayed`, `actorFrameSelector`, `reportFrameLocations`, `FRAME_LOCATION_EVENT`, `FrameLocation`, `labWindowFrameReloader`, `FRAME_RELOAD_TIMEOUT_MS`, `RUNNER_BINDING`, `FEATURE_BINDING`, `BUILDER_BINDING`, `CURSOR_BINDING`, `parseCursorMode`, `CursorMode`, `CURSOR_SPEEDS`, `cursorGlideMs`, `CursorSpec`, `CursorSpeed`, `LabBuilderRunRequest`, `LabFeatureRunRequest`, `LabFeatureRunResult`), `./main` (`src/main.ts`: `main`, `PANEL_USAGE`, the standalone panel entry), `./controls` (`src/controls.ts`: the lab window driven through its own visible controls, `openSection`, `closePanel`, `openScenario`, `featureScenarioId`, `runScenario`, `openBuilderDocument`, `openRecording` and the rest; the panel's browser tests and the capture scripts share it, so a control that moves changes in one place), `./rebuild-rule` (`src/rebuild-rule.ts`: `REBUILD_RULE`, `SHOWS_ATTRIBUTE`, the rebuild counters' one rule, for the panel's and examples' tests), `./host-bypass-words` (`src/client/host-bypass-model.ts`: `hostBypassAudit`, `CATEGORY_WORDS`, the evidence view's host-bypass words, pure; the CLI's HTML report says its summary with them, backlog 148), `./words` (`src/words.ts`: the window's words other views say the same way, `personLabel`, `clockWords`, `originWords`, `originHelp`, `runWrites`, `writesHeadline`, `wroteNothing`, `environmentFit`, `needsWords`, `isNegativeControl`, `keepWords`, `turned`, `KEEP_TITLE`, `KEEP_ABOUT`; the CLI's terminal app reads them, backlog 182), `./react` (optional browser factories and React), `./react/prepare` (Node-only `prepareReactUi`) |
+| Depends on | `@product-lab/composition`, `@product-lab/domain` (the pure helpers the browser panel and the server share), `@product-lab/ports` (the Browser port and `LabRuntime`), `@product-lab/core` and `@product-lab/application` (tests only: `compileLab` fixtures and `LabRuntimeService.adopt` over fixture environments), `typescript` (transpiles the panel on request), `playwright` 1.63.0 (`./visible` and the `Page` type of `./controls` only), `react`/`react-dom` 19.3.0 (optional `./react` helper only), `esbuild` 0.28.2 (Node-only `./react/prepare`) |
+| Used by | `@product-lab/cli`, `examples/notes` and another example, `tools/spikes/browser` |
+| May not be used by | `layer:core` projects (domain, ports, core, contracts) or `layer:mcp` |
+
+Tests: `bunx nx run shell:test` runs both `shell:test:unit` and
+`shell:test:browser` as independently cached Nx prerequisites. Each target
+hashes the exact discovered test files it runs, plus shared panel source,
+fixtures and production dependencies, including the Playwright browser adapter
+loaded by extension-lifecycle fixtures. A unit-only test edit can reuse the
+browser result. The same full suite runs with `bun run test` from this package.
+The runner discovers every `tests/*.test.ts` file, so a new file is always
+covered; browser fixtures are listed in `tests/run-tests.mjs` for the browser
+target, and since 6 October 2026 the runner refuses a file that launches a browser but is not listed
+(`tests/browser-launch.ts`). Node runs up to three unit files at once; browser files run at half the CPUs, between three and eight, within
+memory (`tests/browser-concurrency.ts`; `PANEL_BROWSER_CONCURRENCY=<1-16>` overrides; 109 s at three, 48-64 s at eight on a
+16-CPU machine, backlog 30). `PANEL_BROWSER_SHARD=<n>/<count>` runs one share of the browser files, dealt by
+their measured seconds (CI's three browser runners). Browser tests share one headless Chromium per file worker and
+open separate page contexts. `boot-cover.test.ts` and `release-notice.test.ts` keep their own launch
+(`launchBrowser`) for a distinct `handleSIGINT` option; the visible-window fixtures launch
+through `openLabWindow({ launch: launchBrowser })`.
+
+Every test page opens as GitHub's Linux runner opens it, on any machine: English (United States) at UTC
+(`tests/shared-browser.ts`, `PAGE_DEFAULTS`; `tests/page-defaults.test.ts`). A test that checks another locale or time
+zone passes its own `locale` or `timezoneId`. Text is a little wider on the runner than on macOS (the same fonts, drawn
+by Linux's Chromium): `PANEL_BROWSER_TEXT=wide` spaces every letter 0.03 em wider, so a row that only just fits here
+fails here as it fails there. Run the wrap and cut tests so before a change to the panel's layout:
+`PANEL_BROWSER_TEXT=wide node --import tsx --test tests/text-wrap.test.ts tests/identity-rows.test.ts tests/tile-header-fit.test.ts`.
+
+## The grid of tiles (backlog 125)
+
+In the grid (two or more tiles) each app is shown whole instead of cut. A fill tile at least the minimum layout
+(480×280, `FIT_REFERENCE`; within 5% of it, `FULL_SIZE_FROM`) shows its app at 100% in the tile's own size; a smaller one lays the app out at that minimum
+in the tile's aspect (so the app fills the tile) and draws it scaled from the top left (`fitStage`); a device tile fits
+by its device's viewport (below). The grid takes the column count that gives the largest scale across its tiles (a tie: fewer empty
+cells, then more columns), never with tiles narrower than 220 px (`MIN_TILE_WIDTH`, so the header keeps the name and
+both pills: fewer columns instead). Under 30% (`SCALE_FLOOR`) it stops shrinking: as many columns as keep every app at 30%,
+rows of that height (never taller than the stage), and the stage scrolls; the runner's reveal scrolls an acting tile
+into view. The header says the scale of a scaled app ("56%", `.tile-scale-chip`; none at 100%); when the room left would cut the name, the chip gives way first, then the name's
+ellipsis; the avatar stays. One tile (the single views) fills its space at scale 1, as before. The narrow window's
+side-scrolling row is gone: the same rule lays out every width. Measured at 1024×768 with the panel docked: four people
+2×2 at 56% (before: one column of 143 px tiles); at 1440×900, 2×2 at 100% as before. `src/client/tile-grid.ts` (`gridLayout`,
+`fitStage`), `layoutGrid` in `src/client/app-tiles.ts`; tests `tests/tile-grid.test.ts` (unit) and
+`tests/tile-grid-window.test.ts` (the lab window: two to six people at 760, 1024 and 1440 px, panel open and closed;
+every name shows six characters or in full; control: the old auto-fit), `tests/window-frames.test.ts` (a step frame of a scaled tile is its scaled box).
+
+## Device-sized tiles (backlog 31a)
+
+A tile can show its identity's app at a device's exact CSS viewport, scaled down to fit (never up). The device is the
+app's declared one (`defineLab({ apps: { <id>: { device } } })`), else the identity's choice in the tile's device menu,
+which lists `GET /api/devices` (`src/visible/device-catalogue.ts`, Playwright's registry, loaded on request) and keeps
+the choice in that browser per lab, environment and identity. The caption shows the device, its viewport and the
+scale (`Pixel 7 · 412×839 · 64%`); a change reloads the app ("Reloaded as Pixel 7") and is refused while that
+identity's step runs. A phone (a profile marked `mobile`) is drawn as one, as in the design: a 10 px bezel with a
+notch (`--phone-bezel`), centred in the tile with room around it, the screen scaled into the bezel (`PHONE_BEZEL`,
+`PHONE_ROOM`). Clicks, the target ring and the cursor place the target from the frame's box times its scale in a frame scaled
+evenly (`visible-ui.ts`, since backlog 125); any other transform uses Playwright's own box of the target (`transformed`). Pixel ratio, touch and the user agent are not emulated in a tile (backlog 31b). The menu is
+the header's device pill (a monitor or phone icon and the device's name), beside the host pill (`ActorSession.host`'s
+label, "truAPI CLI" or "truAPI WASM", or the lab's own `hosts.<id>.label`; none when the lab does not know the host). An identity that plays a scenario actor under
+another name in the latest run (a lab bound its own "Person 1" to "Ada") reads "Person 1 · as Ada" after its name, muted
+and smaller, and it gives way before the pills; an identity named after its actor reads just its name (`playedRoles` in
+`src/client/views.ts`, from the run's `bindings`; tests `tests/played-roles.test.ts` and `tests/tile-role.test.ts`). In a tile narrower than 560px the caption's device
+text hides; narrower than 320px, or on a phone (a window under 760px), both pills show their icon only, and the device
+pill still opens the same list. The strip shows the app's origin and path in the mono face ("127.0.0.1:5173/").
+`src/client/tile-device.ts`; tests `tests/tile-device.test.ts` (unit) and `tests/tile-device-served.test.ts` (browser:
+the device's viewport in the tile, a Watch click in the scaled app's bottom-right corner, refused during a step, fill
+back, the icon menu in a narrow tile).
+
+Each identity row says where the identity came from and when ("Opened when the lab started, at 23:40", "New identity,
+made at …", "Made by a run of …", "Came with the saved state …"; its tooltip says how to make one, `identity-words.ts`),
+its username only when it has one, and its host by name. New identity's host menu lists the hosts the lab could add but
+does not declare (`unconfiguredHosts`), greyed, each with what it is and the config that turns it on
+(`tests/identity-rows.test.ts`).
+
+## UI audit fixes (September 2026)
+
+Optional feature scenarios and the builder stay hidden when their runtime capability is absent. The panel API
+marks this case with `UNSUPPORTED_CAPABILITY`; other list or palette failures show a retry message instead of
+appearing empty. A failed extension list shows an inline alert. Switching environments clears the old lists and
+palette while the new requests run, and late replies from the old environment cannot replace them.
+
+Feature and builder results show failed steps, hook errors and runner failures inline, with full errors in
+expandable details. A tagged negative control without an expected step/reason verdict is never counted as verified
+(Runs above: "Failed at one step · reason not checked"); a red run alone does not count. Feature/builder bindings prefer fresh identities when creation is available and
+explain that choosing a saved identity keeps its app and chain state. Sessions that cannot create another identity
+disable that choice. Ordinary action bindings still default to saved identities.
+
+The toolbar follows feature/builder status and checkpoints as well as actions. Long labels preserve their status prefix; narrow screens show the execution state, with full detail in the title. Identity rows label app session status separately from execution. Short durations show milliseconds,
+and running step durations refresh between snapshots. Builder headers and fields wrap within the panel; a table too
+wide for its card scrolls in its own frame. Environment switching uses adapter prerequisite problems before offering a switch.
+
+Focused regression: `node --import tsx --test entrypoints/panel/tests/ui-functional.test.ts` from the repository root
+(served panel and headless Chromium on an ephemeral port; fixture records, not chain verification).
+
+## A failure never blocks
+
+6 October 2026, backlog 154 to 156. It replaces
+Reconcile (5 October 2026): a failed run never blocks
+the lab, so there is nothing to reconcile.
+
+- **The failed step** (`src/client/after-failure-view.ts`, `.rs-after-failure[data-state]` under its error,
+  `run-steps.ts`): when it may have sent a transaction, the lab checks the chain by itself after the run. The line
+  shows `checking` with a spinner and "This step may have sent a transaction. The lab is checking the chain; other
+  scenarios can run meanwhile.", then `answered` with what it found ("It did send: … landed in finalized people #N",
+  "Nothing was sent: …", "The lab cannot tell whether it sent anything: <why>. Check the chain before repeating it.").
+  The words wrap. Its Chain card shows the step's reconciliation (`#5 final`, `did not land`, `unknown`).
+- **Run scenario and New identity stay enabled** after any failed run: only the environment itself disables them
+  (`blockedReason`: its setup or cleanup failed, or it lost what it runs). Then the status line says so plainly with
+  one button, Reset. A run that would act as an identity whose failed step is still being checked is refused with
+  the reason in the status line, and runs a few seconds later.
+- **Any status message** that names Reset or Restart offers that button when the window can do it now
+  (`status-actions.ts` `namedActions`, `#status-<action>`; every button carries `data-lab-action`, one listener in
+  `lab-actions.ts` presses the window's own control); Restart (`environment-lifecycle.ts`) confirms, stops and
+  starts the environment (starts it when a failed start left it stopped). A list that failed to load (features,
+  builder: `RetryableError`; extensions in its own box) offers Try again. A tool report's paragraph that names them
+  offers them too (Explore's "Reset it, then explore again").
+- **The Shared activity lane** names a held account by who it is (`lanes.ts` `resourceName`: "Grace's account", the
+  address on hover) and keeps each chip on one line with an ellipsis, the full text as its title.
+- Tests: `tests/status-actions.test.ts`, `tests/lanes-shared.test.ts`, `tests/bindings.test.ts` (served: the failed
+  step's check then answer, no Reconcile anywhere, Run and New identity enabled, the next run at once),
+  `tests/client-list-errors.test.ts` (Try again).
+
+## Runs: Current, History, Evidence
+
+The Runs group (`src/client/view-runs.ts`, styles in `src/client/view-runs.css`, model in `src/client/run-progress.ts`)
+is a presentation over the existing controllers: it reads the snapshot and clicks the legacy buttons
+(`#continue`, `#pause`, `#cancel`, `#feature-continue`, `#feature-step`, `#feature-pause-now`, `#feature-cancel`),
+which stay in the document, hidden, as do `#steps`, `#feature-status`, `#feature-outcome` and `#feature-progress`.
+
+- **Current** shows the latest run (a configured run or a feature run, whichever started last), or the one chosen in
+  History: its heading is the scenario's name and where it is written ("team.feature:4"), then its steps, with no box
+  around them. The run's state is said by its steps and the bottom bar; a run picked in History and a negative
+  control's verdict keep a status chip. The controls are the bottom bar's (`#dock-run`, `#dock-step`, …); in the lab's
+  own window, which has no bottom bar beside it, the card shows them. A feature run's steps are drawn by `renderGherkin` (Background first) with each step's
+  live state: the running step shows what it waits for (a wait, a transaction in flight, the identity being created),
+  a paused run marks the next step, a failed step says why in plain words (no class name, no stack). The recorded
+  error and a terminal command are under "Details". Configured runs use the same timeline without keywords.
+  Continue, Step, Pause and Stop (click twice) are icon buttons in the card; transactions and activity lanes
+  (`#lanes-table`, one row per actor, a chip per thing it did) are disclosures; a failed step that may have sent a transaction
+  shows the lab's check, then its answer ([A failure never blocks](#a-failure-never-blocks)).
+- **Negative controls** are never shown as a plain failure or a pass. The file's `@negative-control` tag makes it a
+  control, everywhere (since 6 October 2026: before, its folder or a declaration alone did, so a file whose tag was
+  removed still read "expected to fail"; `src/feature-control.ts`, `tests/negative-control-tag.test.ts`). Its tags judge
+  it (tag-only controls, 6 October 2026: `@fails-at-step-N`, `@fails-with:<reason>`) when the panel or the terminal
+  runs it, in the background or in Watch: `/api/feature-run`, the lab window's feature binding and the TUI pass
+  `featureControl(listing, path, selection)` as the run's `control`, from the selected
+  scenario's own tags (one scenario of a file whose other scenarios are not controls runs unjudged; Watch did not judge
+  before 4 October 2026, `tests/watch-negative-control.test.ts`, with a planted `@fails-with` control). Under the
+  verdict, the failure it judged: `<reason>: <message>` (`.run-control-failure`, `.run-why-failure`,
+  `data-control-reason`), and the "Judge it from a terminal" command is `product-lab test <file> --negative-control`.
+  The tags are the only declaration (config redesign, step 8: lab.config.ts `negativeControls`, its warning chip and
+  the `--expect-*` command are gone; a run bundle's rerun alone is still judged at the step and text its run failed
+  with). A judged control
+  it reads **"Failed as intended"** (at its step, for its reason; since 6 October 2026 its failed step says "The lab caught
+  it: the negative control failed here, at its step and for its reason" in the control's info tone, `data-caught` and
+  `.rs-caught`, and "Why?" opens with "The lab caught it") or **"Failed for another reason"** (danger, with
+  "Why?" naming what did not match). A control run that was not judged and failed at exactly one scenario step
+  reads **"Failed at one step · reason not checked"** (warning; "Why?" says to run it as a control, its tags saying where and why). Anything
+  else (it passed, it failed in a hook or the runner, several steps failed) reads "Control not verified".
+- **Timeline** (29 September 2026): the same run as a waterfall, per identity and step ([Run timeline](#run-timeline)).
+- **History** (`#session-history`, rows `.run-list-item`) has one row per run: a feature run is one entry, never one
+  per step, grouped from the feature run records the page saw and, for runs from before it loaded, from their step
+  runs (`feature:<scenario>#<step>`). No internal ids are shown. Choosing a row shows the run in Current and Evidence.
+- **Evidence** has Steps, Transactions, Navigation (the "Follow navigation" switch, `#follow-navigation`, and
+  `#navigation-events`, a row per request with its outcome chip; the whole request is the row's tooltip) and Receipts
+  (`#load-evidence` and `#check-transactions`, pointed at the run shown; a feature run picks one of its step runs;
+  `#landing`; the run record `#evidence` as JSON). "Chain observations" (`#observe`) stays at the bottom.
+- **The dock's line** (`#compact-progress`, `data-compact`) is short, its first word (the state) bold: "Running step
+  3 of 10 · 0:21", "Paused after step 3 · your turn", "Passed · 12s", "Failed at step 3", "Failed at one step", "Replay
+  <run>" (read only is said once, by the replay's banner); the whole sentence (a pause names the step it waits after) is its tooltip. An environment
+  operation of its own (a switch) writes its phase there.
+- **The status lines under the tabs** (`.drawer-status`): the lab's own errors on every tab; the busy notice
+  ("Ada · running. The shared environment runs one scenario at a time…") outside the Run tab, whose steps already
+  say what runs; a failed run's own line (`#status[data-run]`) is left to its steps and the dock's line.
+- **The dock's controls** follow the run's state (lab-mockups 1 to 4, `tests/dock-controls.test.ts`): Run when ready;
+  Pause and Stop while a run runs; Continue, Step and Stop (its square alone) while paused; after a failure Replay (the
+  newest recording, in the Recordings tab), Rerun and a bug button that opens the run's Evidence; in a replay, the
+  previous step, Play and the next step. Each one clicks the control its view owns (`features.ts`, `client.ts`,
+  `recordings.ts`), so the rules about when it may act stay there. Watch | Background stays pressed, not faded, while
+  the choice is locked. Recordings sits beside it, apart: it opens the session's recorded runs to replay and runs
+  nothing (0e's first-time-user audit, 6 October 2026, item 11).
+- **No step caption over a tile** (the redesign): the step running now is in the Run tab's steps, and its place in
+  the dock's line ("Running step 3 of 7").
+- **A step's checks in words** (`src/client/run-steps.ts`, 5 October 2026, the user's feedback): under the selected
+  step a heading says where it was verified (`checksHeading`: "Verified on Grace's screen and on the chain"; a side
+  under way or failed says so, "…; checking on the chain"; a side with nothing to check, "…; no chain check for this
+  step"), not "Checked twice". Each UI call is a sentence with its target named as a person would (`callWords`:
+  "clicked Publish", "typed "Grace was here" into Note", "waited for the Publish button"): the name the lab read in
+  the app when the call found its target (`nameTarget` in `src/visible/app-ui.ts`, and the detached window's surface:
+  the accessible name or label, a button's text, else the test id in words; recorded as `UiCallTiming.targetName`,
+  `targetRole`, a fill's `typed` text shortened to 24 characters, never a password's or one-time code's,
+  `typedHidden`), else the locator's own words, else its test id in words. The locator itself is only under Evidence.
+  A row whose words already name its person later, beside a role ("Grace (Person 2) publishes"), opens with the
+  avatar alone, so the name is said once (`stepLead`).
+- **Setup** (29 September 2026): a run the setup
+  principal owns (a feature step whose calls include a sentence declared `actor: "none"`, once the scenario has actors;
+  `Execution.owner` setup, `actorId` empty) is labelled "Setup" in the busy notice, the status line and Cancel, and
+  "Setup" joins the names in Current, History and Evidence. Its setup steps say "Setup" where a step names who acts,
+  have an activity lane of their own ("Setup"), and their `principal:setup` lock is that lane's, like `actor:<id>`.
+  Setup work belongs to no identity: an identity's run list shows such a run only when one of its steps acted as
+  that identity, Show active points at no identity for it, and Follow action follows nobody while
+  a setup step runs. `src/client/principals.ts` applies the domain's rules (`@product-lab/domain/actors`,
+  `principal.ts`, served as it is).
+
+Tests: `tests/runs-model.test.ts` (the model), `tests/ui-functional.test.ts` (the served card: failure, control,
+runner error, configured run), `tests/views-lanes.test.ts` (Continue in the card, lanes), `tests/setup-principal-views.test.ts`
+(Setup in the labels, lanes, identity views and Follow action), `tests/bindings.test.ts`
+(Receipts, a failure that blocks nothing), `tests/navigation-follow.test.ts`, `tests/workspace-shell.test.ts` (the dock's line).
+
+## Breakpoints and the pause inspector
+
+Backlog 17 (30 September 2026). In the scenario detail
+(`src/client/view-scenarios.ts`) each step's rail is a toggle (`button.gk-break`, `aria-pressed`,
+`li[data-breakpoint]`; `renderGherkin`'s `breakpoints` option in `src/client/gherkin-view.ts`): it sets or clears a
+breakpoint on that step, and a bar above the steps counts them, says why one is stale (its step changed since it was
+set) and clears them all. Breakpoints are the lab's local state (`LabRuntime.breakpoints()`, stored in
+`<lab>/.product-lab/breakpoints.json` by the composition root), never written into the feature file; the CLI's
+`product-lab breakpoints` edits the same list.
+
+A feature run the panel starts (Watch through the lab window, `executeFeature`, or Background, `/api/feature-run`)
+passes `inProcess.breakpoints`, so it pauses **before** each breakpoint at the feature pause gate; a builder run or a
+fixture build does not. While it waits, Runs > Current shows the pause inspector (`src/client/pause-inspector.ts`,
+`#feature-inspect`, styles `.pause-*` in `view-runs.css`), read from `LabRuntime.inspectPause`: where it waits
+("Paused before step 3 (breakpoint)", `src/client/checkpoint.ts`), the next step's calls with their values (an output
+reference with what it resolves to now), the outputs so far, each identity the scenario bound (its nonce and balances
+on every chain, its app, the app the host shows now, and a fresh frame served by `GET /api/pause/frame`), the newest
+finalized blocks' events (those naming an identity first, the rest in a disclosure) and notes on anything that could not
+be read. Refresh reads it again; Continue, Step and Cancel are the dock's alone (until 5 October 2026 the inspection
+repeated them). Its headings are in sentence case, and step text and scenario names are in typographic quotes (“…”), so
+a step's own straight quotes read as its own; the breakpoint list and its reasons quote the same way. A run that stops at
+a breakpoint brings the Runs section forward. The inspection sits on the paused step, under its words (mockup 2; `RunStepsOptions.pausedDetail`), and the
+step's words are scrolled into the panel's view once per pause, so the step it waits at is shown without scrolling
+however tall the inspection is (until 5 October 2026 it sat above the steps and pushed the paused step out of view).
+While paused, the run card renders again only when what it shows changes: its key no longer holds the run's duration,
+which rebuilt the card every second and pulled a person's scroll back. It still rebuilds when a chain check settles, a
+transaction's age moves or a control's state changes; the card is emptied and refilled in one task, so the scroll
+holds (a real Notes lab, 5 October 2026: 11 rebuilds at two pauses, no movement; docs/verification/2026-10-05-paused-step.md). After the run `#feature-breakpoints` lists each
+breakpoint, before the steps: hit, missed (the run was cancelled before it, or an earlier step failed) or stale.
+
+Routes: `GET /api/breakpoints?path&scenario`, `POST /api/breakpoints` (`{ action: "set" | "clear", path, scenario,
+index? }`, answers the list), `GET /api/pause` (`frames=0`, `blocks=n`), `GET /api/pause/frame?identity=` (PNG).
+Tests: `tests/breakpoints.test.ts` (lab window: the rail sets one, a Watch run pauses before it with the inspection
+on the paused step, the step in view and the panel's scroll held for 3 s, also across a forced rebuild of the card (a guard against a rebuild that lays out an empty card in between), Continue passes; control: a Background run's breakpoint on a step that never runs is reported missed with why).
+
+## Runs: Recordings (read-only replay)
+
+Phase 9. The Recordings tab of the Runs group
+(`src/client/recordings.ts`, `src/client/view-recordings.css`, `src/client/view-replay.css`) lists the lab's recorded
+runs (`GET /api/recordings`, newest first) and opens one in a replay viewer (`GET /api/recordings/<id>`), laid out as
+the redesign's mockup 4. The panel keeps its normal width and lists the recorded steps (how each ended, who acted, how
+long it took), then the selected step's failure; its chain notes, compact (`src/client/replay-chain.ts`): a row per
+chain, "people #161 → #173 · final", with when each head was observed as its tooltip; a line per transaction, long ids
+(accounts, hashes) shortened with the full label as tooltip and a copy button; the blocks no transaction line names; and
+its redacted evidence; "Where the time went" draws the recording as a [run timeline](#run-timeline). The stage shows a tile per
+identity (`#replay-stage`, in the live app's place) with its frame before or after the selected step (`GET
+/api/recordings/<id>/frames/<frame>`, the stored PNG; a frame that is unavailable, failed or missing shows its reason,
+never another identity's image), the acting identity's tile outlined. In the stage's slots: a banner over the tiles
+(`#replay-ribbon` in `#stage-banner`: the step and its title, wrapped rather than cut; the before/after switch
+`#replay-side`; "Read only" with a lock, said nowhere else; an (i) `#replay-about` whose tooltip holds when and where it
+was recorded and the capture notes, synthetic camera and microphone media included (said there only, not on each tile
+nor in the panel's title); Back to live `#replay-back`, the only one) and a step
+scrubber under them (`#replay-scrubber` in `#stage-scrubber`: a dot per step at its time in the run, and the saved
+screenshots' controls `#replay-frame-previous`, `#replay-play`, `#replay-frame-next`, `#replay-frame-position`; Play
+shows them one by one, 1.5 s apart, each on its identity's tile). A step row, a scrubber dot, the arrow keys and the
+bottom bar's previous, Play and next (`RecordingsView.controls()`) step through it.
+
+- **Read-only.** The server has only GET routes under `/api/recordings` (a POST is "Unknown action"); they read the
+  store through `LabRuntime.recordings()`, `recording(id)` and `recordingFrame` and need no running environment. The
+  view sends nothing else.
+- **Visibly a replay.** The banner over the tiles and `body[data-replay="true"]`. The live app stays mounted (inert and hidden under the recorded tiles), never replaced.
+- **Back to live** (`#replay-back`, in the banner) closes the replay and the drawer; the app frames are never
+  replaced (the same iframe node, its unsaved input kept).
+- **Stopped environment.** The stopped cover has "Recorded runs" (`#environment-offline-recordings`), and the view's
+  controls stay enabled offline (`environment-lifecycle.ts` exempts `#recordings`).
+- **Frames of Watch runs.** While a run the lab window started runs (`attachLabRunner`'s queue), the window registers
+  `windowFrameCapture` (`src/visible/window-frames.ts`, source `lab-window`) with `runtime.captureFramesFrom` and releases
+  it when the run ends; a Background run keeps the environment's headless pages. The capture only reads pixels: the
+  visible part of the identity's displayed frame, from a clipped page screenshot, outside the input lane; it never
+  scrolls or reveals, so a frame that is not shown (another identity's tile, covered, below the fold) is recorded
+  unavailable with the reason. Media is `synthetic` (`device` in recordings made before 22 October 2026 without `--synthetic-media`). A visual check's capture
+  asks it to wait for the lab's `settled` selectors first (isolation-92b): `settle` (`window-frames.ts`) waits inside the
+  identity's frame (a detached window's capture, `detached-identities.ts`, inside its page) and names the selector and
+  the wait when one never shows; it only reads. Masks are not applied in the lab window's capture.
+- **Run bundle actions** (backlogs 20 and 26, 3 October 2026):
+  a feature scenario's replay has its own block (`#bundle-actions`, `src/client/bundle-actions.ts`), the only part of
+  the viewer that acts, and only when clicked.
+  - "Download bundle" (`#bundle-download`) calls `POST /api/bundles` (`LabRunBundles.bundleRecording`) and saves the
+    file from `GET /api/bundles/<id>.plbundle`. The server (`src/bundle-routes.ts`) serves only files that window bundled.
+  - "Reproduce" (`#bundle-reproduce`) bundles, then asks first when an environment runs: reproducing replaces its
+    state. It sends that session's reset or fixture-restore confirmation to `POST /api/bundles/reproduce`, which calls
+    `LabRunBundles.reproduce`, the use case `product-lab reproduce` runs. A refusal is a 409 with every reason, shown
+    one per line; the outcome shows the expected failure and the rerun's.
+  - Backlog 110: whether the run can be reproduced is said before the click (`#bundle-reproducible`), read from
+    `GET /api/bundles/reproducibility?recording=<id>` (`LabRunBundles.reproducibility`, which reads only): "Reproduce
+    elsewhere: not available for this run. It started on your saved Previewnet fork, whose starting state was not saved
+    with it. Replay works here.", with the bundle's own terms as the button's tooltip. Reproduce is off when it cannot;
+    Download bundle stays.
+- **Two checks on every step** (backlogs 160-162, 6 October 2026):
+  the Run tab's step cards (`stepChecks`, `src/client/run-steps.ts`) read a step's readings (`attached.readings`,
+  and for a step that ran no lab run, a new identity, the snapshot's `featureStepReadings`) beside its UI calls, chain
+  waits and the transactions the app sent: each chain row names where it read and at which block ("Bulletin · #481
+  (finalized)"). The lab's own transactions in the step (an XCM stand-in, funding, a root call) sit on their own card,
+  "Submitted by the lab (not a check)" (`data-kind="lab"`), and never make a step verified on the chain. Every finished
+  step line carries one short summary (`sidesSummary`: "screen ✓ · chain ✓ Bulletin #481"); a step that changes nothing
+  (`mutates: false`) says "changes nothing on chain", one whose action declares `screenCheck.none` gives that reason,
+  and a passed step that changes something but lacks a side says so (`.rs-checks-missing`). The replay's Evidence view
+  shows each chain side's block ("At"), and its new-identity rows list their readings (`.rec-step-readings`). The
+  Transactions tab lists every write the run caused (`src/client/run-writes.ts`): the lab's transactions, the apps',
+  the hosts' and declared services' writes from the finalized host-bypass ledger, and the steps' recorded writes
+  (`attached.writes`: a statement is "not a transaction"); "Nothing was written" only when every list is empty.
+- **The evidence view** (backlog 110, 5 October 2026; mockups in `_artifacts/evidence-redesign/`, outside git): a
+  replay's evidence is on the stage (`#replay-evidence`, `src/client/evidence-view.ts`, `evidence-view.css`), a column
+  beside the recorded frames, above them when the window is under 1200 px; the drawer keeps the steps, with the Gherkin
+  steps that ran no lab run (`.rec-step.is-static`, from `RunRecordingData.featureSteps`). A failed run opens at its
+  failed step with the verdict (`#evidence-verdict`): where it failed, what each side found, which side disagreed, and
+  "Go to step N". For the selected step: where it was verified (the Run tab's `checksHeading`), each side's Expected and
+  Found from its check's readings (`attached.readings`; red only for the side that disagreed), what the person's screen
+  did in the Run tab's words (`callWords`, from `RunRecordingData.uiCalls`), what the step reported itself ("The step
+  reported: typed and clicked: 148 ms · …", never checked by the lab), and the host lane: what the app asked its host
+  (the host's approvals in plain words, counted, `src/client/host-request-words.ts`; the host's own words on hover),
+  the connections around the host (endpoints by chain) and what landed on the chain during the step, each section seen,
+  not observed or not recorded with its source and an (i) saying why it is there. Locators and JSON are under "The
+  step's full record (JSON)"; the older blocks (chains, console, health, the run's host-bypass audit) under "Chains, console and
+  health". The model is pure (`src/client/evidence-model.ts`; `tests/evidence-model.test.ts`); the view's browser test
+  (`tests/evidence-view.test.ts`) checks the layout at 1440 and 1024 px and its readability (13 px or more, no all-caps,
+  no ellipsis), with a control.
+- **Step evidence** (backlogs 22, 23, 25 and 41, 3 October 2026): the replay's selected step shows, under its chain
+  observations, its chain changes (window, events with the identities they mention, account change, a window shared
+  with another step), its identity's console (unexpected and known errors, warnings, unwatched apps), machine and chain
+  health (findings with the numbers, from `RecordingView.health`; since backlog 241 the machine line has the CPUs' idle
+  share, the memory pressure and the lab's loop, in `describeStepMachine`'s words, served as `/step-machine.js`)
+  and what its apps asked their hosts. A recording
+  without one of these blocks says "Not recorded" for it; one that looked and found nothing says so
+  (`src/client/step-evidence.ts`, `step-evidence.css`; `tests/step-evidence.test.ts`).
+- **Chain console** (backlog 24, 3 October 2026): in
+  the environment view under the chains, `#chain-console` (`src/client/chain-console.ts`, `chain-console.css`), closed
+  by default. Open, it asks `GET /api/chain-console?since=<cursor>` (`src/chain-console-routes.ts`,
+  `LabRuntime.chainConsole`) every 2 s for what changed: the running identities' events newest first ("Mine"), or every
+  extrinsic event ("All"); each block says whether it is final, and a best block replaced at its height is struck
+  through with "replaced …: its events did not happen". Closed, it asks nothing. `tests/chain-console.test.ts`.
+
+Tests: `tests/bundle-actions.test.ts` (browser: the download saves the bundled bytes, and no other path is served;
+reproducing asks, sends the session's reset confirmation, lists every refusal reason, then shows the outcome; control:
+a window that does not send the confirmation fails it; backlog 110: the sentence before the click in both cases, Reproduce off and Download on when it cannot, nothing posted; control: a Reproduce left on fails it), `tests/recordings.test.ts` (browser: the frames of the selected step and identity by their pixels, the replay
+marks, Back to live keeping the frame and its input, only recording GETs and no runtime method that acts, with a
+negative control that plants a run request; reopening after the environment stops; the routes' GET-only and path
+refusals; the timeline's lanes and a CSP console error), `tests/window-frames.test.ts` (browser: the window's capture
+refuses a frame below the fold, covered or missing without scrolling; a Watch run is recorded from `lab-window`, a
+Background run from the environment's capture; control: without the registration the Watch run has no `lab-window`
+frame).
+
+### Hot reload of app code
+
+Backlog item 5. When `product-lab dev` watches the apps'
+sources (`LabRuntime.watchApps`), the runtime reloads each running identity's app between that identity's steps.
+
+- **The lab window's frames** (`src/visible/app-reload.ts`): `openLabWindow` registers `labWindowFrameReloader` with
+  `runtime.reloadFramesWith`; the runtime calls it inside the identity's step boundary together with the session's own
+  `reloadApp`. It reloads the identity's frames in place (Playwright `frame.goto` of the frame's current address, so a
+  host bridge in the address is kept) and waits for `load` (`FRAME_RELOAD_TIMEOUT_MS`, 60 s); the session checks the
+  app is ready with the same account. A frame not yet on the app has nothing to reload.
+- **What the panel shows** (`src/client/app-builds.ts`): each settled build's line in the status bar ("Notes
+  reloaded (build 3, 1.2 s)", "Notes build 3 is ready: it reloads after Person 1: Publish", a restart path's "not
+  reloaded: … Stop and Start each identity", a failed build), and `html[data-app-builds]` (`<app>:<build>:<state>`
+  per watched app). A tab other than the lab window mounts its running identities' frames again on a newer build;
+  it drives no step, so any moment is safe.
+- **The dev server's own updates** (backlog item 65): a
+  frame loads its app through the identity's proxy, so an update the runtime lets through reaches the frame in place,
+  like the identity's own page. Such a build has the state `updated` ("Notes updated in place by its dev server
+  (build 4)") and names the identities whose pages took it (`AppBuildView.updated`): a plain tab does not mount those
+  identities' frames again.
+
+Tests: `tests/hot-reload.test.ts` (browser, headless lab window, two loopback fixture apps serving one source file:
+an edit reaches both frames while each keeps its session and account and the environment is the same; controls: a
+running step holds its identity's reload while the other identity reloads at once, and records the build it ran
+against; a changed manifest reloads nothing and says so; a plain tab follows the new build).
+
+### Apps that refuse framing
+
+Backlog item 66. A tile shows its identity's app in an
+`iframe`. An app may forbid that (`X-Frame-Options`, the `frame-ancestors` directive of its
+`Content-Security-Policy`); the browser then leaves the frame empty and says nothing.
+
+- **The check** (`src/frame-check.ts`, `FrameChecks`): when `/api/lab` is asked, the server requests the document of
+  every running identity's app address (and of a followed app's active address), reads the two headers and decides as
+  a browser would for a frame in this window (the domain's `framingRefusal`, with the lab window's own origin as the
+  framing page). Loopback addresses only: a redirect is followed by hand, one hop at a time, and only to a loopback
+  address, so neither an app's redirect nor an address a page reported makes the lab ask another machine. An answer stands for 10 s (an app's headers change with its code), "did not
+  answer" for 2 s; the first snapshot that names an address waits up to 400 ms for its answer, so a tile is not mounted
+  as a frame first. The snapshot carries the refusals by origin (`frames`). The header is only read, never removed.
+- **The tile** (`src/client/app-tiles.ts`): instead of an empty frame it shows the sentence, with the header and its
+  value, and what still works (runs in the background on a host that opens the app as a page of its own). The element
+  carries `data-frame-refused` (the sentence), `data-header` and `data-value`. It is the seam for backlog item 31b:
+  "Open in its own window" goes there.
+- **Watch** (`src/visible/visible-ui.ts`): a Watch step on that identity fails with the same sentence, not with "No
+  displayed app frame matches".
+
+Tests: `tests/frame-check.test.ts` (the decision, the two lifetimes, a non-loopback address never asked) and
+`tests/frame-refusal.test.ts` (browser: six fixture apps; `DENY`, `SAMEORIGIN`, `frame-ancestors 'none'` and `'self'`
+get the sentence and no frame, and a Watch step is refused with it; controls: a policy that names the lab window,
+beside an `X-Frame-Options: DENY` that a browser then ignores, and an app that sends neither header, are shown).
+
+## The Tools page
+
+Lab menu > Tools (T) (5 October 2026, tools-page mockups 9 to 17).
+Its tabs (`shell-kit.ts`'s Tools group): **Find problems**, **Characters**, **Actions**, **Extensions**.
+
+- **Find problems** (`src/client/view-tools.ts`; it says "Reading the lab's tools…" from the moment it is shown until the
+  catalog comes, then draws the list at once): race hunting, explore, what if, test the tests, load and hostile apps
+  (a menu of the hosts product-lab's own targets modules define, run on the lab's environment),
+  then the newest-releases tools, nightly and bisect, each a card with one sentence and its latest result in a pill. A
+  tool's page says what it is for and what it needs, each need checked now by the runtime (`ToolNeed`: met, not met with
+  why, or a note); its options are plain controls with the CLI's defaults; "Copy the command" copies the CLI command of
+  exactly those options (`GET /api/tool-command`, the domain's `toolCommand`). Start is disabled while a need is unmet,
+  and the runtime refuses such a start too (`status: "refused"`, nothing runs). While it runs: a progress bar, one line
+  per run, phase, branch, change or probe (`ToolProgressItem`), each with its replay once recorded, and Stop. When it
+  ends, its report opens as a sheet over the stage (`src/client/tool-report.ts`, inside `#application`; the tiles stay
+  mounted): the verdict first, then tables of words, the smallest failing scenario as Gherkin with its failing step
+  marked, the commands that run it again, and "Open the replay" per finding (the Recordings tab). A narrow sheet shows
+  each table row as labelled lines. Times are in seconds with one decimal; dates in the lab's format (`ui.ts`'s
+  `dateTime`, as Recordings); the elapsed time is the runtime's (`ToolRunView.elapsedMs`). Nightly says plainly that
+  nothing runs it at night here.
+- **Save as a feature** (backlog 119): an exploration
+  that found a failure offers it beside "Copy the scenario". The runtime writes the smallest failing scenario into the
+  folder the lab's first features glob names (`features/explored-seed-<seed>.feature`, `-2`, `-3` beside a file already
+  there), and refuses with why when that folder is outside the lab's directory or the lab's features would not list the
+  file. The report then says where it was saved, shows the file's first lines as written, and offers "Open in
+  Scenarios" (the library, read again, with the file chosen). A reopened report shows it saved, not Save again.
+- **Watch** (backlog 117): in the lab window, race hunting
+  and test the tests (`ToolDescription.watch`) offer "Show the people", Watch or Background, the same choice as the
+  dock's (`run-mode.ts`'s `setRunMode`). Watched, the page starts the tool through the window's `TOOL_BINDING`
+  (`src/visible/runner.ts`): `LabRuntime.startTool` with `inProcess` (the tiles as each actor's surface, as a feature run
+  has them, never pausing), holding the window's run queue until the tool run ends; the stage shows every person in the
+  grid (`watch-layout.ts`) and the dock shows Watch, fixed until it ends (`setToolRun`). Background, and every other
+  tool or tab, starts it with `POST /api/tool-start`.
+- **Agents beside the lab** (`src/client/agents-tools.ts`, `src/agent-routes.ts`; the terminal app's `a`): Claude Code
+  and Codex, each with the command that opens it in the lab's folder (Copy the command) and Open where the lab's
+  terminal can open it beside the lab (a tmux split, a new tab or window of the same terminal app); one not installed
+  is greyed with its install line (Copy the install line). `GET /api/agents` (`{ directory, agents }`, each an
+  `AgentView`), `POST /api/agents/open` (`{ id }`: 200 `{ done }`, 409 with why, 400 without an id), served by `ToolRoutes`. The CLI gives the
+  launcher (`ServeOptions.agents`, an `AgentsService`); a lab served without one says so (`NO_AGENTS`, 501 on open).
+  Hooks: `.tools-agent[data-agent]`, `#agent-copy-<id>`, `#agent-open-<id>`.
+- **Characters** (`src/client/view-characters.ts`): each character the lab declares, its sentence and steps, every
+  scenario step that makes someone one, and the fixtures holding identities ready as one.
+- Routes (`src/tool-routes.ts`, through `LabRuntime.tools`, `startTool`, `toolRun`, `toolRuns`, `stopTool`,
+  `saveToolScenario`): `GET /api/tools`, `GET /api/tool-runs`, `GET /api/tool-runs/<id>`,
+  `GET /api/tool-command?tool=&options=`, `POST /api/tool-start`, `POST /api/tool-stop`, `POST /api/tool-save` (`{ id }`:
+  the `SavedToolScenario`, or 409 with why). A runtime without tools answers 501 with why.
+- Styles: `src/client/tools-page.css` (body text 13 px or more). Hooks: `.tool-card[data-tool]`, `#tool-form[data-tool]`,
+  `#tool-field-<key>`, `#tool-show`, `#tool-watching`, `.tool-need[data-met]`, `#tool-copy-command`, `#tool-start`, `#tool-progress[data-status]`,
+  `.tool-item[data-state]`, `#tool-stop`, `#tool-report`, `.tool-verdict[data-tone]`, `.tool-replay[data-recording]`,
+  `#tool-save-scenario`, `#tool-saved[data-path]`, `.tool-saved-lines`, `#tool-open-saved`, `.tool-save-error`,
+  `.character[data-character]`.
+- Tests: `tests/tools-page.test.ts` (served panel over the real `ToolRunner` and a fake host: every tool's start,
+  progress, report and copy-command, a failure, the refused what-if control, Characters; screenshots at 1440 and 1024 in
+  both themes with `PRODUCT_LAB_SCREENSHOTS_DIR`), `tests/tools-watch.test.ts` (the lab window: Watch's runs in the tiles
+  and the grid, the window's journal, the dock's mode; Background in no tile), `tests/tools-save.test.ts` (a lab folder
+  on disk: Save, the first lines, Open in Scenarios; no failure has no Save, a second save is `-2`; screenshots at 1440
+  in both themes), `tests/lab-menu.test.ts`,
+  `tests/lab-menu-model.test.ts`.
+
+## Tools: Actions & blocks and Extensions
+
+The Tools tabs render with the design system (`src/client/ui.ts`); their rules live in
+`src/client/view-tools.css`.
+
+- **Actions** (`src/client/registry.ts`, `src/client/integrations.ts`): one line of help, then the actions grouped by
+  app. Each app header shows an availability chip, plus chips for any integrations blocking it. An unavailable app
+  also gets a one-line banner with the reason. Each action is a row: a kind tile (`via`: chain, ui, check, lab), its
+  title and "N inputs". An action that cannot run shows an Unavailable chip, whose title is the full reason, and a
+  short reason as its subtitle. Only the row shows until it is opened. Opening it shows the generated form
+  (`src/client/forms.ts`) and one primary Run, which is disabled with the reason beside it. The row's chip shows the
+  latest run (Running, Paused, Passed, Failed or Cancelled). The opened row shows that run's banner and its evidence
+  as JSON behind an Evidence disclosure. A JSON text input becomes a monospaced editor that says when the text is not
+  JSON. An input that takes a table with an actor column (the action's sentence table, read from the builder
+  palette) becomes a picker of the lab's identities. It writes the same JSON into the generated control, so the
+  server validates it exactly as before. Integrations and secrets are rows with status dots and chips.
+- **Extensions** (`src/client/extensions.ts`): one line of help, then each panel in a card that mounts when opened.
+  Refused extensions appear in one warning banner with their reasons. With no panel, an empty state links to
+  [how to add one](../../README.md#custom-panels); the panel links the package README's "Custom panels"
+  section on the npm page (`HOW_TO_ADD_A_PANEL`), since the repository is private.
+
+Hooks kept for tests and controllers: `form[data-block]` (`data-expanded`, `data-runnable`),
+`button[data-block-run]`, `[data-block-reason]`, `article[data-app]`, `[data-app-reason]`, `[data-app-blocked-by]`,
+`article[data-integration-row]`, `[data-integration-reason]`, `[data-secret]`, `#extension-panels details[data-extension]`,
+`.extension-box`, `.extension-error` and `#extension-refused li[data-extension]`. Tests open an action with
+`openBlock(page, id)` (`tests/panel-controls.ts`).
+
+## Production workspace
+
+Since the redesign's step 2a the lab panel is docked beside the people
+on arrival, like DevTools: left by default, or bottom or right (`src/client/dock.ts`, the three buttons beside the
+brand in the panel's head; `body[data-dock]`; remembered on this machine as `product-lab-dock`). Docking only moves the
+panel: the app frames are never remounted, so sessions and typed input are kept (`tests/dock-modes.test.ts`, with a
+remount control). Below 760 px the panel waits to be opened, as before, and covers the stage when open. The stage has
+a header (`.stage-head`: how many people, the app and mode, the grid button `#stage-grid`, and `#stage-whole`, which
+sets the lab aside; Escape and the panel's close button still do) over a dotted grid. Its words and chip (`#stage-chip`)
+follow the run: Watch while a watched run drives the apps, "Paused · you can click inside any app" and Hands on while
+paused, "Stopped at the failure · state kept" after a failure (the failure itself is the bottom bar's and the
+failed step's to say), "Replay · <run>" and no chip in a replay (its banner says read only; `tests/dock-controls.test.ts`,
+`tests/recordings.test.ts`), and "the lab is in its own window" with Lab detached while it is
+(`tests/own-window.test.ts`). Two slots run across the stage for a view to fill: `#stage-banner` between the header and
+the tiles and `#stage-scrubber` under them (shown only while filled; the tiles shrink, never covered). The brand is Polkadot's dot
+mark (`logo()`, `brand()`) with the wordmark in Unbounded. Since step 2b the panel is resized from its edge toward
+the people (`src/client/resize.ts`, `.lab-resize`: a labelled separator, arrow keys move it 16 px, 64 px with Shift,
+Home and End go to the bounds, a double-click resets): width docked left or right, height docked bottom, at least
+280 px wide or 180 px tall, and the stage keeps 40% of the room. Each mode's size is remembered on this machine
+(`product-lab-panel-size-<mode>`); only a CSS variable changes, so the frames are never remounted during a drag
+(`tests/panel-resize.test.ts`, with remount and bounds controls). Today's sizes are presets in the menu beside the dock
+buttons (`.panel-size`): normal (the default), wide, and full (the lab over the whole frame, `body[data-panel-preset]`).
+A scenario's detail and the timeline keep the width the person chose; only the builder, an editor in three columns,
+takes the whole frame and gives the chosen width back when left (0e's first-time-user audit, 6 October 2026;
+`tests/inventory-gaps.test.ts`, "panel width"). Since step 2c the fourth dock
+button puts the lab in a window of its own (`src/client/own-window.ts`, `body[data-dock="window"]`): the panel's node
+moves into a same-origin window, the people take the whole lab window, and the panel's code keeps running in the lab
+window, so its controls, run bindings, views and unsaved input carry over and the app frames are never reloaded. The
+styles are copied rule for rule into the window's own constructed sheets and its fonts into its own font faces (the
+window requests nothing: with a route on the lab page, as a conditioned tile's network installs, an about:blank
+window's requests stall, which left a person's lab window unstyled on 5 October 2026) and the html and body attributes (theme, dock, panel state)
+mirrored. Lookups by id,
+document-wide keys and clicks, focus and dialogs reach the panel in either document through `src/client/lab-document.ts`
+(`findById`, `labQuery`, `onLabDocuments`, `showModal`). The choice is remembered (a reload opens the window again);
+closing the window, or choosing a docked mode in it, docks the lab back where it was (`product-lab-dock-return`); a
+browser that refuses the window leaves the lab docked and says so (`tests/own-window.test.ts`, with dock-back and
+remount controls). Since 5 October 2026 the bottom bar and its Lab menu go with the lab (`openOwnWindow`'s `along`):
+the lab's window has the bar at its bottom in two rows (Lab, the environment and the whole run line above; Watch,
+Background, Replay and Run, Pause or Stop below) under the panel, and the people's window is the stage only, down to its
+bottom, its chip saying "Lab detached · <the run's line>" (without the clock) while a run is on. The quick picker opens
+in the window of the control that opened it; the Lab menu's keys work from either window; docking back brings the bar
+home (`tests/detached-bar.test.ts`, with a control: the bar left behind fails it). What follows describes the panel's
+contents, unchanged.
+
+The app fills the window above one bottom dock. The side panel docks beside the app
+and the app narrows to make room (`body[data-panel="open"]`, `--panel-width`; the
+panel is `normal` or `wide`); it never covers the app, and changing sections does not
+remount it. Only the scenario builder takes the whole frame (`data-panel-size="full"`).
+The dock holds the Lab menu ([Lab menu and Settings](#lab-menu-and-settings)), the
+identity and environment pickers, and one run control: the chosen scenario and its
+live state in one piece beside Run. The environment picker lists each environment's fixtures under it
+(`src/client/fixtures.ts`, backlog 1h, 30 September 2026):
+each is Ready, Stale (every reason listed), Not
+saved, or Saved (another environment's, not checked), with its age and origin (its setup feature, or "saved from the
+running state"). Picking a ready fixture of the running environment asks once, then restores it with the session's
+`restoreFixture` confirmation (`POST /api/fixture` `restore`); Build (or Rebuild) runs a declared fixture's setup in
+this process and saves the state (`build`, `LabRuntime.buildFixture`; the row follows `snapshot.fixtureBuild`); "Save
+current state as fixture…" saves the running state under a new name (`save`, `saveFixture({ fromCurrentState })`).
+Every refusal is the runtime's reason. `GET /api/fixtures` lists them (`LabRuntime.fixtures()`). Test:
+`tests/fixtures-picker-served.test.ts` (browser; a stale fixture and another environment's cannot be picked). On a desktop the dock is one line (the scenario
+name gives way first); below 760px it is two rows, and below 480px Run is icon-only.
+Command/Ctrl-K opens a searchable command palette, Escape dismisses overlays, and the
+theme preference changes the lab controls independently of the embedded product.
+
+In compare (grid) view the selected identity's tile has the accent ring (its "Selected" element stays in the header
+for what reads it, and is not shown since the redesign: the ring says it; `tests/tile-header-fit.test.ts`). Pressing a tile's caption or clicking inside its app selects that
+identity; focus the runner moves into a frame (`__productLabReveal`/`__productLabRing`
+in the last 3 seconds, `window-bindings.ts` `drivenByRunner`) never changes it.
+
+### Design system
+
+One brand across every view: `src/client/tokens.css` (colours, type, radii, shadows,
+motion; light and dark; since the redesign's step 1, the approved design's values: Polkadot pink `#ff2670` for the
+primary action, the active state and selection, `--font-display` (Unbounded) for headings and names, and the radius
+system `--radius-control` 999px, `--radius-tile` 18px, `--radius-card` 14px, `--radius-row` 12px),
+`src/client/fonts.css` with the vendored variable fonts in `src/client/fonts/` (Inter, Unbounded, JetBrains Mono,
+Latin subset, SIL Open Font License beside each; served as `font/woff2` by the lab, so nothing is fetched from a CDN
+and the lab looks the same offline), `src/client/lucide.ts` (the Lucide icons the views draw, ISC licence in
+`lucide.LICENSE`, generated by `scripts/gen-lucide.mjs` from an unpacked `lucide-static`; `ui.ts`'s `icon()` draws
+today's names through it; `tests/design-assets.test.ts`), `ui.ts` + `components.css` (DOM factories: button, chip,
+row, card, dataTable, codeBlock, disclosure, tabs, searchField and more), and
+`gherkin-view.ts` + `gherkin.css`, the one renderer for any Gherkin (Background, Rule,
+Outline and Examples blocks, data tables, doc strings, markers, live step states) that
+the library, runs and the builder share. Wide tables become labelled cards when their
+columns stop fitting (5-6 columns below 480px, 7 or more below 720px); a cell that
+names an actor shows the actor's avatar. A table cell's colour comes from its value (`cellTone`): the lab's declared
+tones first (`LabRegistry.valueTones`, from its integrations' `valueTones`), else the panel's product-neutral defaults
+(`DEFAULT_VALUE_TONES`: yes, true, passed, ok, included; no, false, failed, blocked; none, n/a, dashes, empty), else
+none; the views pass the snapshot's registry tones to the renderer (`GherkinOptions.valueTones`).
+`frame.css` holds the dock, panel, menus and
+pickers; each view's styles live in its `view-*.css`. The served `/gallery.html` shows
+every component, a sample scenario with every construct, and the lab's own scenarios.
+
+Views update in place (backlog 157). The panel polls a
+snapshot every 1.5 s and redraws live times every second; a view builds its nodes as before (`h`) and hands them to
+`ui.ts`'s `patchChildren(parent, nodes)` instead of `replaceChildren`. It keeps every node that still stands for the same
+thing: a child keyed by `data-key` or `id` keeps its node wherever it moves, the others are matched in order by tag, and
+attributes, text and handlers change only where they differ, so a snapshot that changes nothing changes nothing on the
+page (an open disclosure, a focused field and a scroll position survive it). Rules for a view: register handlers with
+`h`'s `on<event>` props or `on(node, type, handler)` (never `addEventListener` on a node a patch may replace) and read the
+node from `event.currentTarget`; give a node the view keeps in a variable an `id` or `data-key`, or pass it through
+`keep`; inside a subtree built anew, put a kept node in as `ref(node)` so it stays where it is; mark a `<details>` whose
+`open` the view decides with `data-managed-open` (otherwise the person's choice stays). `dom.ts`'s `setText` changes a
+text only when it differs, as a text edit. `tests/no-flicker.test.ts` watches the whole page with a MutationObserver
+(at rest in every section, a run whose only change is time, a new identity), with chains whose blocks keep coming,
+provider notices and a finished feature run in the snapshot; `tests/patch.test.ts` covers the helper.
+
+The rebuild counters' one rule (6 October 2026, `src/rebuild-rule.ts`, export `./rebuild-rule`)
+applies to `tests/no-flicker.test.ts` and Notes' user
+path alike. A container that shows one thing names it in `data-shows`:
+- the run card and the Evidence body: `run:<key>`;
+- the holder of the latest run's live parts (`#runs-legacy`): `run:<key>`;
+- the replay stage: `recording:<id>`;
+- the drawer's title and tabs: `section:<id>`.
+
+When that id changes, nodes added or removed inside the container in the same batch of mutations are another run's
+content. The counters tally them apart (`excused`), never as rebuilt. A rebuild under the same id still counts
+(`tests/rebuild-rule.test.ts` and its controls). `REBUILD_RULE` is in-page code that defines `window.__rebuildRule`
+(`options`, `changed(records)`, `excused(node, changed)`).
+
+Text wraps everywhere (backlog 158). `#command-center` sets `overflow-wrap: anywhere`, so a content id, hash, address or
+error breaks rather than running past the panel's edge; a one-line label keeps `white-space: nowrap`. Text cut on
+purpose outside the panel (an ellipsis) carries the whole of it as a `title` on the element that cuts it or its
+parent: a tile's name, the stage line. `tests/text-wrap.test.ts` reads every visible text at the panel's default width
+(420 px) and its narrowest (280 px, `resize.ts` `MIN_SIZE`) in every section, before and after failed runs with long
+words (`tests/long-words.ts`), and fails on text past the panel's edge or cut without its tooltip.
+
+Inside the panel no text is cut at all (F2). `tests/text-cut.test.ts` opens every place a person reads (Run and its
+tabs, Scenarios, Recordings, Environment details with Advanced open, the New identity menu, the tools and their tabs)
+at both widths and fails on any visible text whose box is narrower than it (`scrollWidth` over `clientWidth`), that a
+box further out clips, or whose ordinary words split mid-word, naming the box and the text; an ellipsis or a clamp
+counts even with its tooltip. Only a box meant to scroll sideways is exempt, by the marker `data-scrolls` on it or an
+ancestor. So a scenario's description shows whole, a timeline bar holds its step's number (its title is the bar's
+tooltip, the detail's and the table's), and an identity's name wraps in the timeline.
+
+A tile's host pill follows the person's host (backlog 159, `app-tiles.ts` `syncHostPill`): a saved identity reopened
+can be listed before the lab knows its host; the pill appears in the same tile once it does
+(`tests/tile-host-switch.test.ts`).
+
+The shell reuses the existing controller elements, capabilities and visible-window
+bindings. Existing live progress, observations, reports and session history remain
+the source of displayed evidence. Recording and visual replay are deferred until
+after publication; the production shell has no simulated replay or chain rewind.
+
+`src/client/workspace-shell.ts` composes these controls. The served-browser
+regression `tests/workspace-shell.test.ts` checks stable app/dock bounds, unchanged
+iframe identity and typed input, section navigation, keyboard/theme and mobile width.
+`tests/inventory-gaps.test.ts` (the redesign's step 0b) covers what no other
+browser test did: the Identities actions (reserve count, Stop, Start, Delete with its dialog, Reload app, Copy account
+address), Environment > Advanced's notes and provenance, the busy notice of a run in progress with its step in the Run tab and its count in the bottom bar, the
+run's host-bypass summary in Evidence, and the panel sizes (normal, wide, full).
+
+Environment controls call the runtime's existing start/stop lifecycle. Stopping is
+confirmed against the current session; disposable state requires explicit discard
+confirmation, and active runs must finish or be cancelled first. The stopped view
+removes app frames, blocks actions and marks live chain observations unavailable.
+Restart creates a new frame session even when actor ids and URLs are reused. Within
+one running session, focus/compare retains unsaved input; hidden obsolete app URLs
+are disposed when the snapshot changes.
+
+Visual fidelity is being corrected against the frozen approved v3 reference. The
+Lab menu and drawer section switcher use anchored menus; a scenario row opens its
+detail with its actual metadata and the existing input/binding controllers. Actions and
+integration blocks remain accessible in their own section. Functional verification
+of the earlier shell does not constitute approval of this visual correction.
+
+The Lab menu opens every section (see [Lab menu and Settings](#lab-menu-and-settings)).
+A scenario row opens its detail (see Scenario library below). Current run
+drives the original pause/continue/step/cancel controls (see Runs: Current, History, Evidence). Past runs lists the
+current environment session only; it is not a durable recording or visual replay.
+Environment summarizes actual registry data and provider observations, with missing
+head telemetry explicit; Start/Stop sit in its header and the detailed configuration is under Advanced.
+
+### Scenario library (`src/client/view-scenarios.ts`, `view-scenarios.css`)
+
+- **Library**: a search field (name, path, group, description, tags, actors, apps and every step's text) and toggle
+  filter chips with counts (Multi-actor, Negative controls, Ready, Fast = `@fast-ci`, then one per app that tells
+  scenarios apart; a chip nothing matches is not offered, nor an app every scenario uses). In a lab with several apps
+  each row names the apps its steps use (`appsOf`: an app counts when its integration owns one of the scenario's
+  sentences, from the listing's `inspection.integrations`), so a notes lab's one shop journey reads "Shop".
+  Configured runs come first, then one collapsible group per first folder below `features/` (`groupOfPath`,
+  `groupEntries`). A group of more than six (`SECTION_THRESHOLD`) shows its second folder level as muted sub-headers;
+  a smaller one prefixes each row's file with it. A folder is a category even with one scenario; only four or more
+  one-scenario folders (`OTHER_THRESHOLD`) join a last "Other" group. The groups come
+  from every entry, so a search only removes rows. Each scenario is one `row` (the design's one-line rows): the last
+  run's dot, the title (two lines at most), `section · file.feature · N people · N steps` (Background included) with
+  the last run's outcome and time, then only what is not the usual: unavailable or missing readiness, variants,
+  "expected to fail", the apps of a lab with several. The actors, inputs and tags are the detail's.
+  The library renders again only when what it shows changes (a key of the entries, their last runs, the search,
+  filters and selection): a snapshot poll with the same content keeps every node, so hover, focus and selection
+  survive. Collapsing a group renders nothing (the `<details>` already shows it); the collapsed set is kept for the
+  next rebuild. Until 5 October 2026 a group's `toggle` cleared the key, and since a group created open fires `toggle`
+  once inserted, every poll rebuilt the list (`tests/scenario-library-served.test.ts`, "keeps its nodes across polls").
+- **Readiness** (`readiness`): ready (available and complete), unavailable (danger), a missing capability or a plan
+  issue (warning), and otherwise "partly checked" (neutral): an inspection that is merely incomplete is not a problem.
+  A row says neither "ready" nor "partly checked"; the detail does.
+- **Examples blocks not for this chain** (29 September 2026):
+  a condition written only on an Examples block leaves the outline listed and its fitting rows runnable. The
+  inspection's `examplesNotFor` names each unfit block; the detail marks that block's head with a neutral "not for
+  this chain" chip (tooltip: the reason, `data-not-for`) and its rows (`is-not-for`), the requirements list it
+  (`data-examples-not-for`), and choosing one of its rows disables Run with the reason (the runtime refuses that row
+  too). An outline whose every block is unfit is not for this chain as a whole (hidden, Run disabled).
+  `runNotForText` (`src/client/features.ts`) decides; `tests/scenario-conditions-served.test.ts` covers it.
+- **Where a scenario runs** (backlogs 163-165, 6 October 2026): from the inspection's
+  `runsOn` (`src/client/scenario-environment.ts`, `environmentFit`). A scenario tied to environments carries a chip
+  naming them (`.scn-env-chip`, `data-environment-fit`): "paseo-copy" when it runs here, "runs on paseo-copy" when it runs
+  on another local environment, "live network only" (or "no environment fits") when the lab window cannot run it. That
+  last row is greyed out, never hidden, its Run disabled; the chip's tooltip and the detail's line (`.scn-env-line`)
+  say what it does, why, and the configuration or command that runs it (`product-lab test <file> --environment
+  <live id>`). Run on a scenario for another local environment (the detail's button reads "Run on paseo-copy") warns
+  first (`src/client/switch-run.ts`, `#switch-run-dialog`): where it runs, then what the switch costs from the runtime's
+  own switch plan (the identities it stops, what the environment it leaves keeps, what it starts in) and the time a
+  start takes; "Stay in …" switches nothing. The warning names environments by their labels ("Run on Local copy of
+  Paseo?", "Switch to Local copy of Paseo and run"; the id joins a label two environments share, 22's audit, item 9).
+  An environment with more than one way to run (backlog 184) is named with the way it starts and why, from the plan's
+  `option` (the target's pick): "Switch to Local copy of Paseo (Light) and run" (both buttons name the target this short way since 6 October 2026), and a cost line "… starts as Light,
+  picked automatically: this machine has 4 cores and 8 GB; Full needs 8 cores and 16 GB". A switch that discards the
+  environment it leaves names where it goes too, in short labels (each label's head, `shortLabel`): "Discard Fast local
+  chain, switch to Local copy of Paseo (Light) and run".
+  Confirmed, the switch is the run's first step (`src/client/run-preludes.ts`, `.rs-prelude`: "Switch to Local copy of
+  Paseo", the run's first step, from fast, its start's progress and
+  how long it took; a failed switch is a failed run that says why), then the scenario runs on the new environment,
+  watched (a fresh environment shows no identity yet: the window's feature runner then starts with none shown,
+  `src/visible/runner.ts`). While a switch or a reset runs (`snapshot().operation.leaving`), each tile closes its app
+  ("Ada's app is closed", `.tile[data-leaving]`, `src/client/app-tiles.ts`), so no app keeps calling a host that stops;
+  the apps open again once the environment runs. "Can run here" (the library filter) counts scenarios this environment
+  runs now, so a scenario tied to another environment or a live network is not one; the bottom bar counts the same way
+  ("41 of 45 can run here", `scenarioCountWords`).
+- **Root calls from the lab window** (backlog 180, 6 October 2026): Run on a
+  scenario that makes root calls (its `runsOn.needs.rootCalls`), where the environment declares them and this session has
+  not confirmed them (`snapshot().rootCalls.confirmed`), asks first (`src/client/root-call-confirm.ts`,
+  `#root-calls-dialog`): what a root call does, the calls the lab allows, that the environment is a local copy with a
+  development sudo key, that a mainnet or a public network is still refused, how long it lasts and the CLI's
+  `--root-calls`. "Allow root calls and run" posts the session's token (`/api/root-calls`, `LabRuntime.allowRootCalls`)
+  and runs; "Don't allow" runs nothing.
+- **Not for this chain** (scenario conditions, 28 September 2026): a scenario whose inspection has `notFor` (a tag that
+  does not fit the running environment, from the lab's integrations' `scenarioConditions`) reads "not for this chain",
+  a neutral chip whose tooltip is the reason ("Not for this chain: this chain's identity threshold is 1 (@policy-3)",
+  for example). The library hides such scenarios until "Show N not for this chain" (`.scn-not-for-toggle`, below the
+  groups; its tooltip lists the reasons) shows them, so the list holds what can run here; a search that only they
+  match says so and offers the same toggle. Decision: hide by default rather than a filter, because a whole set of a
+  lab's scenarios may be for another chain configuration and none of them can run. A negative control
+  (`@negative-control`) is never hidden (6 October 2026): it stays in its group, greyed (`data-not-for` on the row; title,
+  subtitle and Run at 0.55 opacity, as an unrunnable row) with the reason, so what the lab
+  can prove shows on every host (the Notes host-check control on a host that locks the network, for example). The row's Run, the detail's `#feature-run`
+  (and so the dock's Run) are disabled with the reason as their title, and the detail's requirements line says
+  "Not for this chain" with the reason (`data-not-for` names the tags). The runtime refuses such a run anyway (400
+  with the reason; nothing starts). While nothing runs, or when the conditions cannot be read, nothing is marked.
+- **Detail**: a row opens it; the panel becomes wide (`body[data-panel-size="wide"]`) and the detail slides in; Back,
+  or reopening Scenarios from the menu or its tab, returns to the library at normal width. It shows the group, the file
+  (with a copy button for its path), the title with filled placeholders, the chips, the requirements on one line
+  (chains, services and capabilities as chips; reasons, unchecked steps and plan issues behind Details) and the
+  scenario drawn by `renderGherkin`. The Run setup is one line at the bottom of the panel: the actors' summary ("New
+  identities", or who plays whom), which opens each actor's choice, the Pause switch and the one primary Run. The
+  Run is the controller's own `#feature-run` / `#run`; the bar lays out `#features` and `#scenario-form` as they are.
+  Clicking an outline's Examples row fills the steps and makes the Run "Run example N": `features.ts` then sends
+  `line` and `example` (1-based across every block, `exampleNumber`) so only that variant runs.
+- **Dock picker** (`scenarioPicker`): search, the same groups, a check on the chosen scenario, Open library.
+- **Older servers**: a lab whose server lists only the merged `examples` (no `examplesBlocks`, `variants`, tag
+  levels, Rule or descriptions) still draws, numbers and runs its variants.
+- **Hooks**: `[data-scenario="scenario:<id>" | "feature:<option>"] .scenario-title` (with `aria-expanded`) is the
+  row's title and the detail's heading; `.run-small` is the row's Run and the detail's; the library's rows leave the
+  page while a detail is open, so each hook is unique. `tests/panel-controls.ts` `chooseScenario` opens the detail and
+  its Run setup.
+- **Tests**: `tests/scenario-library.test.ts` (grouping, readiness, variant numbering, phases);
+  `tests/scenario-library-served.test.ts` (served fixture with every Gherkin field, then an older server's listing:
+  groups, filters, search, the wide detail, the one-line Run setup, a one-variant run request, the picker);
+  `tests/scenario-requirements.test.ts` (requirements, coverage and the environment-response race).
+
+The requirements line does not run support modules or replace runtime preflight; intentional negative controls remain selectable and runnable. Metadata is refreshed for environment/session and registry changes; stale responses are discarded, including returning to a previously loaded environment while another request remains pending. A stopped lab displays declared-default inspection.
+
+Every panel test binds its fixture servers and the served shell on ephemeral loopback ports (`tests/ports.ts`:
+`listenEphemeral`, which rejects on a listen error, and `freePort` for `serveLab`), so overlapping panel runs, in one
+worktree or several, cannot collide; fixed ports (27300 in `tests/watch-multi.test.ts`, 26000 in the address bar
+test, ...) once hung a gate; `tests/window-media.test.ts` kept
+43020/43021 until 29 September 2026 and failed with `EADDRINUSE` in overlapping runs. A fixture that stands in for a
+server reply answers what the server answers (the scenario library's feature run returns the lab snapshot; an empty
+reply made the client's error reopen the panel, a load-dependent timeout). Tests reach the lab window's
+globals inside `page.evaluate` through `TestLabWindow` (`tests/lab-window.ts`), not a double type assertion.
+
+The Node test target runs at most three test files concurrently. This bounds browser memory on machines whose CPU count is large relative to RAM; the Linux qualification record contains the reproduced uncapped OOM and passing capped run.
+
+Browser tests read related layout positions in one page evaluation, so panel transitions cannot move the layout
+between the measurements. Tests that resize the lab window first flush recording frame captures and then check
+`window.innerWidth` and `window.innerHeight`; screenshot viewport restoration cannot silently undo a resize. The
+builder test keeps its edit route until the preview confirms both queued edits, before removing the route.
+
+The lab window's Evidence view, Past runs and the recording drawer show run and step host-bypass evidence in words, titled "Host check: the whole run" and "Host check: this step" with an (i) saying what the check does (0e's lab-window audit, 6 October 2026) (`src/client/host-bypass.ts`, its model `host-bypass-model.ts`; backlog 110, the user on 5 October 2026: "the evidence tab is still a dump of text"): one verdict line for the run ("Nothing went around the host · not complete: the lab could not fully read 2 entries in the blocks") with why it is incomplete one click away, each gap said once; the explained extrinsics as a count per kind that opens ("28 the chain wrote itself (each block's time and bookkeeping): expected"), each kind's reason on hover and first when opened; one row per extrinsic the lab could not attribute or not read in full (chain, block, step, why), rows that share a reason folded into one ("4 extrinsics not read in full (…): people #36, #45 (step 3), #47, #56 (step 4)") that opens on them; each person by name with their host, their policy and their app's traffic around the host counted by chain; the record itself under "The full record (JSON)". A step's audit is one line ("Host check: this step incomplete the run's check says why") unless the step has an extrinsic or traffic of its own, never the run's audit again. An extrinsic the lab could not read in full is "cannot be told", not a finding; absent evidence reads coverage unknown. `tests/host-bypass.test.ts` (control: the old dump shows the 28 explained extrinsics as 28 lines).
+
+Run and step host-bypass views include an overall verdict chip. An unexplained foreign extrinsic produces an overall warning while clean app verdicts and unknown transaction attribution remain intact; incomplete coverage and strict failures retain their own tones.
+
+The server explicitly serves the host-bypass view and the pure domain verdict helper (every client module a file imports must have its route: `tests/assets.test.ts`); browser imports use the dedicated `@product-lab/domain/runs/host-bypass-verdict` subpath.
+
+Framing reuse (item82): the framing section above retains the original item66 behavior and its evidence. Current `FrameChecks` invokes the optional driving runtime `inspectAppFraming`; it performs no Node fetch or adapter construction. Its10s successful/2s retry cache and400ms first wait remain local to the panel. `/api/lab` keeps the existing refusal map and lists serializable `frameInspections` for allowed/refused/unknown results. A missing inspection capability or failed reader is unknown, never evidence that the document allows framing.
+
+The drawer puts its existing tabs in a full-width row below the title and Close control. Tabs wrap at narrow widths, keeping Recordings reachable without replacing the live app frame. Watch controls the displayed app in a window opened through `openLabWindow`; the server can keep running in the background while that window remains visible.
+
+Opening a recording displays its captured screenshots over the mounted app, with Play/Pause and previous/next screenshot controls. The viewer labels its fixed1.5s image cadence and absence of video; it cannot recover typing or clicks between captures. Back to live restores the app and run controls. Active runs are checked before and after loading the recording, using the latest panel snapshot. The run audit remains available even with zero recorded steps, and incomplete audits explicitly explain that proof is missing.