## Summary
- Bump catalog `@xsai/*`, `@xsai-ext/providers`, and `xsschema` to
**0.5.0-beta.8**, and delete the three `@xsai/*` pnpm patches — the
beta.2 ones from #1602 and the beta.8 regenerations that landed on main
in `38a008500`.
- Always capture tool failures on the core-agent chat path: xsAI beta.8
marks failed tool executions with `isError: true` on `tool-result.done`,
and `llm-service.ts` maps that to AIRI's `tool-error` event via
`toAiriStreamEvent`, so the agent loop continues instead of aborting.
- Remove the `captureToolErrors` request flag (and stop forwarding it
into `streamText`).
- Rebased onto latest `main` (`b230e16b2`). Includes one follow-up fix:
steps are marked settled before the finish listener runs, and finish
listener failures still reject the stream.
### Related
- Supersedes / follows up on
[#1602](https://github.com/moeru-ai/airi/pull/1602) (`captureToolErrors`
+ xsai patches).
### Scope of capture
| Case | Covered |
| --- | --- |
| A — unknown tool | yes |
| B — invalid / unparseable arguments JSON | yes |
| C — `validate` failure | yes |
| D — `execute` throw | yes |
| `missing_name` / `missing_arguments` | no (xsai still aborts) |
| `repairToolCall` | no |
Error copy on beta.8: `Tool "<toolName>" execution failed: …` (produced
by xsAI).
## Test plan
### Automated (Vitest)
- [x] core-agent `llm-service.test.ts` — 16/16
- [x] core-agent full suite — 82/82
- [x] stage-ui `llm.test.ts` + `chat.contract.test.ts` — 44/44 (the
previous `stepsSettled` timing failure is fixed in this branch)
- [x] stage-ui full suite — 594 passed / 0 failed (one
browser-test-runner teardown error, not a test failure)
- [x] typecheck — core-agent, stage-ui, component-calling, satori-bot
pass; telegram-bot fails only at `src/utils/velin.ts`, which is
pre-existing on main and untouched by this PR
### Real-environment E2E (rebase branch, DeepSeek V4 Flash via DeepSeek
API)
Harness: `/Users/lulu/GitHub/airi-e2e/pr2164/tool-error-e2e-rebase.mjs`
— drives the built `core-agent` `streamFrom` with a deliberately failing
tool.
| Case | Result | Evidence |
| --- | --- | --- |
| D — execute throw | **pass** | `tool-error` carried `Tool
"always_fail" execution failed: boom: deterministic tool failure`; the
model answered: "The always_fail tool threw a deterministic error as
expected." |
| A — unknown tool | **pass** | The model called the unavailable
`search_the_moon_database` after being told truthfully that this tests
AIRI's error capture; runtime returned `tool-error` and the conversation
continued. |
| B — bad arguments JSON | not observed on real model | providers rarely
emit invalid `arguments`; covered by unit test |
| C — `validate` failure | pass (earlier manual run with a temporary
validate-gated tool) | — |
Evidence artifacts:
`/Users/lulu/GitHub/airi-e2e/artifacts/pr2164/tool-error-e2e-2026-08-10T16-49-15-384Z.{json,log}`
### Notes / non-goals
- Fallout-only updates for the xsai beta.8 API rename: `textStream`,
`inputTokens` / `outputTokens` / `totalTokens` in component-calling /
telegram / satori.
---------
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
## Description
Screen capture in Stage Tamagotchi is denied before it ever reaches the
desktop picker: `navigator.mediaDevices.getDisplayMedia()` resolves with
`NotAllowedError: Permission denied`, so the vision screen-capture panel
can list sources but never start a stream.
The cause is in `shouldGrantElectronPermission`. Electron reports
**screen capture as the `media` permission**, not as `display-capture`,
and it only appends `audio`/`video` to `details.mediaTypes` for *device*
capture — so a `getDisplayMedia()` request arrives as `media` with an
**empty** `mediaTypes` list
([`web_contents_permission_helper.cc#L249-L274`](https://github.com/electron/electron/blob/v41.2.1/shell/browser/web_contents_permission_helper.cc#L249-L274)).
The handler took an early return for every `media` operation and
required audio-only details, so display capture was rejected before the
allowlisted `display-capture` entry could be consulted:
```ts
if (permission === 'media')
return shouldGrantAudioCapturePermission(webContents, permission, requestingOrigin, details)
return LOCAL_APP_PERMISSION_NAMES.has(permission) && shouldGrantLocalAppPermission(...)
```
The fix resolves a `media` operation that declares no device media type
back to `display-capture`, so the existing allowlist and local-frame
checks decide the outcome — which is what `LOCAL_APP_PERMISSION_NAMES`
already intended:
```ts
const allowlistPermission = isDisplayCaptureMediaPermission(permission, details) ? 'display-capture' : permission
return LOCAL_APP_PERMISSION_NAMES.has(allowlistPermission)
&& shouldGrantLocalAppPermission(webContents, requestingOrigin, details)
```
Camera and microphone operations always report their device media type
(`['video']`, `['audio']`, `mediaType: 'audio'`), so they never take
this path and stay exactly as strict as before. Remote frames are still
rejected, because the local-frame check is unchanged and still applies
to display capture.
Three regression tests are added: screen capture from a local page is
granted, screen capture from a remote page is rejected, and a camera
request is still denied now that it shares the `media` permission.
## Linked Issues
Closes#2177
## Additional Context
- **Regression range.** This was introduced by #2002 (`5e8bf75`,
2026-07-10), which added the permission allowlist. Nothing on the
failing path is platform-specific — the `media` vs `display-capture`
mismatch is in Electron's browser process — so although the issue was
reported on Windows, screen capture has been broken on macOS and Linux
since that commit too. Worth noting for anyone triaging similar reports.
- **Detection signal.** The predicate keys on `mediaTypes.length === 0`
rather than on the absence of the field, so a `media` operation with
*no* `mediaTypes` at all (e.g. permission *checks*, which send
`mediaType: 'unknown'` instead) is not silently promoted to display
capture. That keeps the change to exactly the shape Electron documents
for `getDisplayMedia()` requests.
- **Deliberately out of scope.** #2104 (camera snapshot denied) is a
policy decision — whether the camera should join the allowlist — not
this bug, and #2132 (`systemPreferences.getMediaAccessStatus` undefined
on Linux) is unrelated. Happy to follow up on either if you'd like them
addressed.
- **Second layer still applies.** `setDisplayMediaRequestHandler` in
`packages/electron-screen-capture` is only installed inside the
`setSource` mutex window, so a grant here still requires the renderer to
have selected a source first. This change does not widen that.
- **Verification.** `media-permissions.test.ts` goes 16/16 → 19/19; with
only the tests applied, the new local-screen-capture case fails as
expected. Type checking and the repo ESLint config both pass clean on
the two touched files.
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
## Summary
Adds a self-contained better-auth plugin
(`server/apps/api/src/libs/auth-plugins/steam.ts`) implementing Steam
OpenID 2.0 sign-in, account linking, and callback verification via "dumb
mode".
Steam's web login is OpenID 2.0, not OAuth2/OIDC, so it cannot be
registered as a `socialProviders` entry, and better-auth has no plugin
hook for extending its OAuth2 endpoints with a non-OAuth2 protocol. The
plugin therefore adds the endpoints Steam's protocol needs: `POST
/sign-in/steam`, `POST /link/steam`, and `GET /steam/callback`.
- Callback verification uses OpenID "dumb mode"
(`openid.mode=check_authentication`): one extra round trip to Steam
instead of managing RSA association state.
- New sign-ups get a placeholder `<steamid64>@steam.placeholder.local`
with `emailVerified: true`, mirroring Apple Sign In's
`<sub>@apple.placeholder.local`.
- The plugin's request/query schemas use Zod; a `// NOTICE:` documents
that better-auth's OpenAPI generator is Zod-native. Steam verification
uses `ofetch`.
- Wires Steam into `apps/ui-server-auth` sign-in and profile "Connected
accounts", plus the shared `OAuthProvider` / `defaultSignInProviders` in
`packages/stage-ui`.
- Linking routes through `/link/steam` via the client's `$fetch`;
unlinking needs no special-casing (`/unlink-account` already takes a
free-form `providerId`).
No Steam Web API key is required for this browser-based flow.
We intentionally do not depend on community Steam packages (e.g.
`better-auth-steam`) or the still-open upstream draft
([better-auth#4877](https://github.com/better-auth/better-auth/pull/4877)).
Steam never returns an email, and we need sign-up that does not ask the
user for one plus first-class account linking; the available options
either require an email at sign-in, lack linking, or are abandoned /
blocked — shipping a small in-tree plugin is the safer auth dependency
for this requirement.
## Test plan
- [x] `pnpm exec vitest run
server/apps/api/src/libs/auth-plugins/steam.test.ts` — 6/6 passing
- [x] `pnpm -F @proj-airi/ui-server-auth exec vitest run` — 32/32
passing
- [x] `pnpm -F @proj-airi/stage-ui exec vitest run
src/libs/steam-auth-client.test.ts
src/composables/use-linked-accounts.test.ts` — 5/5 passing
- [x] `pnpm -F @proj-airi/api-server typecheck`
- [x] `pnpm -F @proj-airi/ui-server-auth typecheck`
- [x] `pnpm -F @proj-airi/stage-ui typecheck`
## Follow-ups
- Desktop Steam ticket sign-in (top of this stack): silent startup
ticket exchange for Steam builds; the server resolves or creates the
AIRI user for the verified SteamID before issuing an OIDC code.
- Steam persona name/avatar via `GetPlayerSummaries` inside the plugin,
if display names beyond `Steam User <id>` are wanted.
---------
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
This pull request introduces the initial glossary for the project to
improve the translation quality.
Implements #2148.
### TODOs
- [x] Add the definition YAML
- [x] Add a generator to produce Crowdin-compatible (TBX v3) format
- [x] AGENTS.md
- [ ] ~Workflow~ (Split to another PR)
- [ ] ~Skills~ (Same as above)
