Switch managing docker from script or script-only to gradle
Modernize gradle with newer APIs that allow lazy evaluations of the task graph.
Provide warnings on EntityValue to prevent shadowing keys with functions due to groovy 4+ mapping of properties.
Modernize the UI and upgrade to latest versions
Introduce more dynamic client-rendered constructs into the widget / theaming system, specifically try to introduce an event management system for the various UI components to communicate with each other, possibly with a state store shared between them.
Further improve the newer groovyshell implementation to make it a main tool for daily development.
Introduce AI guiding files (AGENTS.md, SKILL.md, etc …) and document on how to add sub-files to augment behavior
Add or introduce an AI component to help integrate with the AI ecosystem.
This is a quick brain dump of ideas that I think should be tackled moving forward now that we got Moqui 4.0 completed and about to be released. Feel free to share thoughts so we can collect more ideas.
I am quite interested in this point. What do you mean, or what is your use case for this? Could you explain a bit more? I have very little experience in the frontend, but I played a bit with Vue, and it seems that you can define variables and when they change the UI is updated automatically. So I think if we somehow update the variable the ui will get updated without reloading the page. I did a little research on the Moqui side and it looks like we could use websockets, because they are already implemented, but currently only used for notifications. I was looking to provide a way to reload tables asynchronously, which I think might be similar functionality to what you are describing.
Are you talking about the groovy shell that you have on the frontend, somewhere in the System or Tools? What do you use that for?
First of all, thank you for your continuous contribution and for driving Moqui 4.0 to this stage. Releasing 4.0 is a big milestone for the community, and your effort behind it is truly appreciated.
Switch managing docker from script or script-only to gradle
I agree with this direction. From a production and CI/CD perspective, having Docker tasks integrated into Gradle gives better consistency, reproducibility, and cleaner lifecycle management. It also avoids splitting build and deployment logic across different places. If we modernize Gradle further with lazy configuration and newer task APIs, it can become a strong foundation for both development and production workflows going forward.
Introduce AI guiding files (AGENTS.md, SKILL.md, etc …) and document on how to add sub-files to augment behavior
I strongly support this idea. I have already submitted a PR to the Moqui Framework adding initial instruction files in this direction:
The goal is to make Moqui projects more structured and AI-aware, so tools can better understand entities, services, conventions, and architectural boundaries. This can reduce ambiguity and make AI-assisted development more reliable.
Add or introduce an AI component to help integrate with the AI ecosystem.
Along the same lines, I have pushed a separate moqui-ai-skill component:
The idea is to define reusable “skills” for Moqui projects so AI agents can work with clearer context and structured guidance. I see this as a practical step toward integrating with the broader AI ecosystem, while still keeping the core framework clean and modular.
Overall, I’m really excited about the direction you outlined. If we align build modernization, better developer tooling, and structured AI integration, we can bring something genuinely new to the Moqui community.