- Translate the zh Agent Note's title and section headings and align
its rail terminology with the established zh READMEs (轨道).
- Disambiguate 'the browser's listener' to WorkspaceBrowser's in the
English note.
- Record the in-flight outside-click exception in the ui-workspace
README (both languages) and the owning workspace-sidebar feature
note, cross-linked to the bug-fix note.
- Add an apps/web real-browser scenario pinning the document-level
bubble the jsdom test cannot replay: one real rail click must leave
the search expanded and focused, and a genuine outside click must
dismiss it afterwards. Negative-controlled against the unguarded
code (fails in 12s on the aria-expanded assertion).
- Register the new e2e file in the host tsconfig face and the client
face's exclude list.
The rail search click flips the shell wide and mounts the outside-click
dismissal listener during its own dispatch; the click then bubbles to
document with the unmounted rail button as its target — outside
searchRoot — so the listener dismissed the search it just opened. The
listener now stays off while the rail gesture is in flight
(searchOnExpand), which already ends exactly when focus lands.
The regression test replays the document-level bubbling order that
fireEvent on the button alone does not exercise.
The upstream-type proof only ran covariantly, so it caught a profile
field wider than pi-ai's but not one narrower — the direction its own
JSDoc claimed to guard. It now asserts both directions; the reverse holds
today because every field is either derived from upstream or a boolean.
`ModelCompat` gained `BedrockCompat`, which the gate had already started
serving, and the per-field protocol lists now match what the gates
resolve: `docs/config-catalog.md` pastes that JSDoc verbatim, so a stale
list there contradicted the README in the same change. The interface
header names the Responses grouping, since a catalog reader never sees
the README passage that explains it.
Valueless keys are judged after the name, so a withheld or misspelled key
written bare is refused for being that name rather than sent back for a
value it would be refused with anyway; the remedy no longer promises an
installed catalog value that a hand-declared route does not have. The
check covers `undefined` beside `null`: schemastery keeps the key either
way, and a cordis.yml entry reaches that state through `!!js undefined`,
so it is a config boundary rather than a typed one.
Coverage follows the composed path: the rejection is asserted through a
written settings section, and a switch is carried from that section onto
the wire a provider receives.
Refs #2646
The message-feedback note editor previously expanded inline inside the
assistant message's shared IconActions row, overflowing the row at every
viewport and pushing the branch action and the clock out of the column.
Rework it into a portable popover: the note editor is a fixed-position panel
portaled to document.body and anchored to the note trigger, so the row keeps
its single 28px line whether the editor is open or not and the panel escapes
the column's overflow clip.
The like/dislike buttons and the note trigger stay in the row unchanged; the
trigger toggles the popover (textarea + Save/Cancel + note-save failure) which
auto-focuses the input and closes on Escape or an outside click, returning
focus to the trigger. Rating/list-load failures surface in the row, note-save
failures inside the popover. Reuse the Menu portal surface tokens and add
@types/react-dom so the createPortal usage typechecks.
Layout e2e sweeps six viewports and pins that opening the editor leaves the
row's overflow, line count, and out-of-column items unchanged, and that the
panel is outside the column, within the viewport, and anchored to its trigger.
Unit tests cover the popover's portal-to-body, toggle, Escape/outside-click
dismissal, and unmount early-returns.
The full switch list already exists and is generated from source, so the
guide needs a way in rather than a copy: `config-catalog.md` carries 107
plugin sections, and linking the whole file leaves a reader to find the
one that configures the page they are on. Both mentions now deep-link the
`dsh-llm-pi-ai` anchor.
Refs #2646
The Models page has no field for `compat`, and the symptom it addresses —
a gateway holding a working key at a reachable address while refusing
every request — reads as a credential or connectivity problem. Give it
the same treatment `input` already has: name the symptom, show the two
switches that account for most of it, and state the resolution order.
Refs #2646
Review found two live defects in the compat surface.
A valueless key (`supportsDeveloperRole:`) survives schemastery as null,
and resolution carried it forward as a configured value. It landed on
`Model.compat` as null, which replaced the installed catalog entry's
value and left pi-ai's `??` reaching for its baseURL detection — the
catalog layer skipped entirely, and the switch written but not applied.
The vocabulary check now refuses it where it is written, matching the
`reasoningEfforts` precedent in the same file.
The gates were keyed by protocol name, but pi-ai keys compat by type:
`openai-responses`, `azure-openai-responses`, and `openai-codex-responses`
share one `OpenAIResponsesCompat`, so two shipped catalog routes were
refused the fields their own models declare. Gates now group by compat
type, `bedrock-converse-stream` gains its own, and the protocol set is
derived from `Model.compat`'s conditional so a release that gives a
further protocol a compat type fails the gate list by name.
Field types are derived from upstream rather than restated, with a proof
pinning the profile assignable to the upstream types, so a widened value
union cannot silently narrow what configuration accepts.
The `undefined` filter stays removed: `exactOptionalPropertyTypes` keeps
a typed caller from writing one, and schemastery never materializes one,
so it was validation for a value the static interface already excludes.
Refs #2646