A communityA Flutter fork can involve Dart framework source, native engine code and the tools that assemble them. A change in one layer does not automatically prove the other layers are compatible.
Framework: Dart source → Engine: native artifacts → Tooling: selection & CLI → Target: observed behaviour.
Three questions before changing code
What behaviour is failing?
Name the user action and target. A layout symptom, an input failure and a compiler error may involve different layers; the symptom alone does not establish ownership.
Which source or artifact changed?
Record the framework revision, engine revision and toolchain output. If the candidate depends on custom engine binaries, identify where those binaries come from and which platforms they cover.
What evidence will distinguish the layers?
Reduce the reproduction and compare the same target and mode. Keep version output alongside the relevant build and runtime logs. Do not infer an engine fix from a framework-only change.
| Layer | What to identify | What that does not prove |
|---|---|---|
| Framework | Dart source revision and patch | Native engine compatibility |
| Engine | Binary revision, target and origin | Correct app behaviour |
| Tooling | CLI, SDK selection and build logs | That another SDK was actually tested |
Worked example
A candidate changes a widget’s focus handling in Dart. The review records the framework patch, runs widget checks and repeats the keyboard interaction on the target desktop build. It also records the engine revision rather than assuming it is unchanged. A successful widget check and a failing native interaction remain two distinct results.
The original three stages of Flock describes why framework mirroring and engine delivery were separate milestones. It is a 2024 plan, not a statement that every milestone is complete today. Follow the patch review worksheet when evaluating a concrete change.
Sources & further reading
Resolve the next specific question
- Trace a missing Flutter image or font
Follow a resource from its source path and pubspec declaration through build output to the rendered result.
- Diagnose a Flutter web release that shows a blank page
Trace deployed startup from document and bootstrap through resource responses to the first application frame.
- Hot reload, restart and the state you are testing
Distinguish retained development state from a reproducible cold-start failure with a three-run worksheet.