Examples: setup CI to verify that it is easy to run them on all supported platforms.

_↴ Ported from [flutter/genui#752](https://github.com/flutter/genui/issues/752) — originally opened by [polina-c](https://github.com/polina-c) on 2026-02-23._
_Original labels: P2, front-line-handled, a: api-simplicity_

---

Options:
- with VS Code UI
- with command line
- after copying code to just created Flutter project

---

### 4 comment(s) from the original issue

**[gspencergoog](https://github.com/gspencergoog)** commented on 2026-02-24:

Can you elaborate on what this entails? Do you want CI to launch VS Code and run examples?

---

**[polina-c](https://github.com/polina-c)** commented on 2026-02-24:

Sure!

It is a high ambiguity issue.

We need **confidence** that it is easy and frictionless to run examples on **each platform**. So, we need some continuos validation.

For example, we want to make sure:
1. It is clear how to get and how to provide api key or setup configuration for AI we support.
2. It does not require extra googling to update macos/ios entitlements in a right way, if code is copied to new project (should we add one more command 'enable-network-client' to Flutter plugin in VS Code or to `flutter` CLI?).

How to achieve this?

IMHO it should be some combination of test automation (most likely it will be evals with AI engaged) and manual testing (it should be done outside of immediate team, because we need fresh minds without assumptions).

This is P2, because API is still moving around, so we do not need to decide it now. However, we will need it to be done before marketing the SDK widely.

How does it sound?

---

**[gspencergoog](https://github.com/gspencergoog)** commented on 2026-02-24:

Sounds good! The only thing is that we don't currently have any accounting to pay for the AI inference to do the evaluation as part of CI. It would be good to add, but we need to have a funding discussion, and there should be limits/guard rails to prevent abuse.

---

**[polina-c](https://github.com/polina-c)** commented on 2026-02-24:

I think default github protection plus githib visibility plus internal limits are providing good guards.

Yes, we need funding discussion and discussion to review my assumption above.