> For the complete documentation index, see [llms.txt](https://beamline.gitbook.io/beamline-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://beamline.gitbook.io/beamline-docs/getting-started/known-limitations.md).

# Known limitations

What Beamline does not do or has not been checked to do: backends and services, environments, layouts and themes, particular parts, licences.

> The original of this page is on beamline.io: [beamline.io/docs/limitations](https://beamline.io/docs/limitations).

> Beamline code and your custom style files stay in your repo; your app has no Beamline runtime dependency. This documentation ships with the complete system (docs/LIMITATIONS.md in the kit). Use [local kit tools](https://beamline.io/docs/install) or [connect an agent](https://beamline.io/connect) to install parts.

What this release does not do, or has not been checked to do. Each item says what to expect and what to do about it. Per-entry limitations also appear in the catalog under the entry.

## Backends and services

* **No backend is included.** Beamline is the interface. Your app supplies data, persistence, authentication and the actions behind every button. Screens show the state your data and handlers report.
* **Demonstrations are labelled.** `@beamline/ui/demo/*` (simulated market feed and paper trading account, sample CRM and analytics data, simulated text stream, agent runs, voice sessions, CSV import assessment and renewal task service) exists to show the screens working. It calls nothing external and never reports a real operation as done.
* **No trading execution.** The trading components display market data and collect order details. Placing, filling and cancelling orders is your exchange integration; the reference app's paper-trading adapter is a local simulation.

## Environments

* Exercised locally: Node 24.19.0, React/ReactDOM 19.3.0, Vite 8.3.2 and TypeScript 5.9.3 with npm 11.17.0 and pnpm 11.22.0 in Chromium. The reference app and selected compiled/source consumers use real production builds; the complete 332-export declaration surface was checked with `skipLibCheck: false`.
* Next.js 16.3.8 App Router was exercised with TypeScript 6.0.3 for server-side pure helpers, Button hydration, Dialog portals/focus and Table context with explicit CSS. This is a named subset, not a claim that every component or application works in every Next configuration. The older TypeScript 5.9.3 setup did not supply Next's required URLPattern globals.
* A pnpm workspace app and separate consumer UI package were exercised with one shared runtime. The separate 11 October 2026 Bun/Yarn matrix below covers fresh standalone apps, not Yarn/Bun workspaces.
* **Bun and Yarn, 11 October 2026:** the local `0.2.0-compat2.1` candidate passed 32 profiles: Bun 1.4.3, Yarn Classic 1.22.22, Yarn Berry 4.18.1 with `node-modules`, and Berry with PnP; each manager/linker used fresh Next.js 16.4.0 App Router (webpack) and Vite 8.3.4 apps for compiled CLI, full source, generated shadcn 4.21.4 registry and public sample source. Node 24.21.0, React/ReactDOM 19.3.0, TypeScript 6.0.3 and source Tailwind 4.3.3 were pinned. Every profile installed, passed strict types and a production build, rendered three Settings URLs, saved/reloaded, and exercised Button/Dialog in Chromium 153.0.8010.12 on Linux at 1512×982. This is named-component coverage, not every component or browser. Registry content was served locally; live paid-key authorization was not exercised. [Matrix, exact commands and source boundaries](https://beamline.io/docs/install#package-managers-checked-11-october-2026).
* In an npm workspace member, npm applies `overrides` only at the workspace root and resolves a relative archive path from each dependent's folder, so compiled installs there list every Beamline unit the selection uses in the member's `dependencies` (Beamline archives only; registry packages and React stay out). A standalone npm app and pnpm list only the chosen packages.
* The bundled CLI supports Node 20 or newer; the tested Vite version declares `^20.19.0 || >=22.12.0`, and the tested Next version declares `>=20.9.0`. Follow the installed application toolchain's requirement. Earlier runs used Node 24.19.0; the dated Bun/Yarn matrix used 24.21.0.
* React 18 and older are not supported (components use React 19 APIs such as `ref` as a prop).
* On 10 October 2026, Playwright 1.63.0 on Linux exercised Firefox 155.0 and WebKit 26.6 at 1512×982 desktop and 390×844 phone with touch, starting in dark. All 220 unique gallery routes rendered at both widths in both engines. Of 162 interaction scenarios per width, desktop passed 162 in each; phone passed 161 in Firefox and 159 in WebKit. This combines complete sweeps with focused replays on the rc.32 base and three browser fixes, not a clean sweep of every later release. Focused production-build checks on 11 October closed the Foundations phone overflow (34 checks per engine across both widths), the WebKit dialog origin offset, and the reduced-motion caption finding (the documented short opacity fade is allowed; moving keyframes are rejected). Those are focused local release-candidate checks, not a rerun of the published site. That Linux matrix does not establish Safari or real-iPhone coverage. See [the dated results](https://beamline.io/tested).
* **Public sample CI, 11 October 2026:** the [public run](https://github.com/dprvda/beamline/actions/runs/38139104422) passed fresh Next.js App Router and Vite installs, typecheck/build, three Settings routes, save/reload, dialog focus, overflow and axe in Chromium, Firefox and WebKit at desktop and touch-phone widths. **Safari 26.6.2 on macOS (GitHub runner)** passed those journeys at 1512×982 for both apps. Safari is required for the routine workflow to pass. The [first](https://github.com/dprvda/beamline/actions/runs/38138754734) and [second](https://github.com/dprvda/beamline/actions/runs/38139104422) main runs on that date each passed all four jobs. [Rerun without a Beamline account or secret](https://github.com/dprvda/beamline/tree/main/tests/public-proof). This covers the free sample's named journeys, not every paid component. **iOS Simulator is not yet qualified**: route interaction failed, so [its workflow is manual-only](https://github.com/dprvda/beamline/actions/workflows/ios-qualification.yml). Broader Safari coverage, Mobile Safari and real iPhones remain unverified.
* **Next.js Turbopack, 11 October 2026:** six additional Next 16.4.0 source/registry profiles passed production build, strict types, three routes and computed CSS Module checks with Bun 1.4.3, Yarn Classic 1.22.22 and Yarn Berry 4.18.1 (`node-modules`). The candidate hoists module composition declarations outside cascade layers; visual declarations keep their layer. No custom loader or CSS bypass was used. Turbopack with Yarn PnP remains unchecked.
* **Older public sample source:** the [pinned public snapshot](https://github.com/dprvda/beamline/tree/c2392c13c8154017b354b5cea97d84b901ceff89) still uses `next build --webpack` with Tailwind PostCSS. Its unchanged source reproduced Next 16.4.0's failure on `composes` inside `@layer` in `toast.module.css`. This is [Next.js issue #85200](https://github.com/vercel/next.js/issues/85200). Keep webpack for that older source; the candidate's successful Turbopack checks do not retroactively qualify it.

## Layout and themes

* Dark and light are both complete in all nine looks; dark is the default. The gallery checks use desktop width (1512×982) and phone width (390 px); the dated contrast run measures selected token pairs in every look and theme. Automated accessibility evidence is partial and does not establish WCAG conformance. Where an entry has a known limit, the catalog lists it under that entry ("Limitations"; `find.mjs --id <id>` prints it too).

## Limits of particular entries

* **Area, line, bar and composed charts** draw their plot in the browser once its width is known: a server-rendered page shows the chart's frame and title, and the plot appears on hydration. Every chart is plain SVG; the only chart dependency is d3-shape's curve maths.
* **Sankey chart:** flows must not loop, and the layout is clearest up to about 30 nodes.
* **Video player:** plays what the browser plays natively (MP4/H.264, WebM); there is no adaptive streaming (HLS, DASH). Picture-in-picture appears only where the browser offers it.
* **Phone input:** number formats and length checks cover common shapes for 48 countries, not every numbering plan. Validate numbers on your server.
* **Voice:** components take provider adapters (`@beamline/ui/lib/voice`). The one adapter that ships is `browserSpeechToText()`, the browser's own recognition: free and keyless, but its quality and privacy are the browser vendor's (some send the audio to their servers), and it is missing in some browsers. Connecting a hosted speech or voice-agent service is your adapter; the integration notes in the speech-input and conversation-bar entries show the shape. Switching microphones mid-call reaches the service only if your adapter implements `replaceStream`. The gallery's voice audio is placeholder tones with synthetic timings.
* **Import mapping:** assessment, import and retry are your handlers; the gallery's assessment is a labelled demo.
* **Liquid Gooey advanced physics:** plain mirrored Items support scope speed, reduced/no motion and offscreen settling. The optional upstream `observe`, shape, move, bend and melt modes do not expose managed motion or visibility controls; choose plain Items or ordinary controls when those policies are required. Their appearance is not a guarantee of paused work.

## Licences and content

* `LICENSE.md` is the full licence; beamline.io/terms and beamline.io/licence summarise it.
* Third-party runtime packages keep their own licences; the `THIRD-PARTY-LICENSES.md` file in each package lists them, and `docs/DEPENDENCIES.md` names the obligations that reach your product (keep TradingView's attribution on the price chart).
* Demonstration figures, people's and companies' names are invented, and demo images are the product's own renders. People in demos show initials avatars rather than photographs.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://beamline.gitbook.io/beamline-docs/getting-started/known-limitations.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.