Hey, thanks for the detailed reports.
@SonidoTribal17, the feedback is super specific, that’s really helpful. Point by point:
- Scope control and approval before large changes is on our radar. In Composer 2 this is a weak spot. As a workaround, add a strict Cursor rule like
only modify files explicitly listed in the request, ask before touching anything else, and use Plan mode for bigger tasks. - “Builds successfully” vs “works on device”. The model is only relying on static analysis, it’s not running real device tests. For Flutter it helps to enable the browser tool or terminal tool, with a clear instruction to run
flutter runor integration tests after changes. - Model switching after limits is Auto mode behavior. If you want full control, turn off Auto and pick the model manually.
@Orgoth_Dorngree, about hardcoding keys or tokens. If you can reproduce it reliably, send the Request ID and I’ll pass it to the team. By default the model rules forbid this, but a specific case is a great example to review.
One more thing, Composer 2.5 is out, and it addresses a lot of the quality and over-engineering feedback. If you test it, please leave feedback in the main thread: Share your Thoughts on Composer 2.5!