[Zaimwa9]

Adds a harness for Dart and Flutter SDKs, and runs the spec against flagsmith-flutter-client in the compatibility matrix. Built on v0.3.0 (#4).

• harness/dart/build.dart: Dart cannot call a function by name at runtime, so this reads sdk-spec/steps.dart, finds each step marker (Create the SDK client or When …) and the first top-level function after it, and generates an entrypoint that passes those functions to the harness, keyed by step text.
• harness/dart/harness.dart: speaks the stdio protocol and calls steps with Function.apply, awaiting Futures. print output goes to stderr.
• harness/dart/README.md: the steps-file conventions, Dockerfiles for Flutter and Dart packages, and how to run it locally.
• .github/workflows/compatibility.yml: adds flutter (Flagsmith/flagsmith-flutter-client, feat/sdk-spec, language dart).

A Flutter package needs dart:ui, so it cannot run on the plain Dart VM. The README's Flutter Dockerfile compiles the entrypoint with flutter build bundle and runs the kernel on flutter_tester, the headless engine flutter test uses. Unlike flutter test, this keeps the process's stdin and stdout.

The Flutter SDK currently returns flag values as strings, so its two scenarios fail on value types ("42" instead of 42). That is an SDK gap, tracked in Flagsmith/flagsmith-flutter-client#99. Everything else works: with values decoded in a local experiment, both scenarios pass, including trait persistence.

[Zaimwa9]

@themis-blindfold review

[Zaimwa9]

@themis-blindfold review

[themis-blindfold]

⚖️ Themis review: 🟠 Fix before merge

The added Flutter compatibility-matrix entry has a completed failing check, so this would leave the repository's regular compatibility signal red from the outset. Eight other completed SDK spec checks passed; the Ruby check was still in progress.

Area	Score
🎯 Correctness	2/5
🧪 Test coverage	2/5
📐 Code quality	3/5
🚀 Product impact	2/5

🟠 Majors

• .github/workflows/compatibility.yml — the Flutter SDK adds a failing compatibility check to every normal run.

🧹 Nits

• HARNESS.md — add Dart to the language table so the public harness index lists the new supported language.

📝 Walkthrough

• Dart harness — adds a generated dispatcher plus a JSON-lines runtime for Dart and Flutter steps files.
• Compatibility matrix — runs the Flutter SDK through that harness with the rest of the supported SDKs.

🧪 How to verify

1. Update the Flutter SDK step output to preserve JSON value types, then build its SDK-spec image using the documented Flutter Dockerfile.
2. Run SDK_COMMAND="docker run --interactive --rm --network sdk-spec_default sdk-spec-sdk:local" uv run pytest -v from runner and confirm both Flutter scenarios pass.
3. Re-enable the matrix row and confirm the Flutter compatibility job passes alongside the existing SDK jobs.
4. Check that HARNESS.md links to harness/dart in its language table.

Automate: Add a minimal Dart fixture that exercises entrypoint generation and one JSON-lines request/response round trip.

Product take: This extends behavioural-spec coverage to Flutter, a worthwhile capability, but a permanently failing compatibility row would make the signal unreliable until the SDK gap is fixed.

🧭 Assumptions & unverified claims

No unverified assumptions or claims.

One new dialect, one currently red signal — let’s get them introduced after the values agree. · reviewed at fe4e135

[themis-blindfold]

⚖️ Themis review: 🟠 Fix before merge

The Flutter SDK ref is explicitly described as failing the typed-value scenarios, yet it is added to the standard compatibility matrix. The documented Dart container recipe also relies on an undeclared runtime directory. The nine completed language compatibility jobs passed; the Flutter job was still running.

Area	Score
🎯 Correctness	2/5
🧪 Test coverage	2/5
📐 Code quality	3/5
🚀 Product impact	3/5

🟠 Majors

• .github/workflows/compatibility.yml:70 — the known-failing Flutter SDK scenarios are run in the standard compatibility matrix.
• harness/dart/README.md:61 — the documented Dart image build depends on a runtime path the recipe does not establish.

📝 Walkthrough

• Dart dispatch generation - scans step markers and writes an SDK-package entrypoint for the callable step functions.
• Stdio harness - maps line-delimited protocol requests to those functions, retains client handles, and emits JSON responses.
• Packaging guidance - supplies separate Flutter-kernel and Dart-executable container recipes plus a local Flutter command.
• Compatibility matrix - adds the Flutter SDK branch using the new Dart harness.

🧪 How to verify

1. Build a minimal pure-Dart SDK image using the documented multi-stage recipe and confirm the resulting container starts.
2. Build the Flutter recipe against the Flutter SDK branch and send a hello request over stdin.
3. Run both feature files through the built Flutter image and confirm numeric, boolean, and null flag values retain their JSON types.
4. Run the full compatibility matrix only after the Flutter branch passes those scenarios.
   Automate: build fixture Dart and Flutter images in CI, then exercise the hello and one client-step protocol paths.

Product take: Adding Dart and Flutter support is a solid expansion of the SDK spec, but onboarding and compatibility need to be dependable before it can protect SDK users.

🧭 Assumptions & unverified claims

• The exact filesystem layout of the mutable dart:stable image was not available locally; the Dart image finding is based on the recipe not creating or documenting /runtime and Docker requiring a COPY source to exist.
• The Flutter job had not completed, and the typed-value failures were not independently reproduced here; they are stated in the proposed change's description.

A promising bridge to Dart, with one missing plank. · reviewed at fe4e135

[Zaimwa9]

@themis-blindfold review

[Zaimwa9]

@themis-blindfold review