I propose the development of the Outsystems Advisor , a tool designed to ensure adherence to Outsystems best practices. This solution will provide personalized recommendations to optimize deployments across five key pillars : Cost , Security, Reliability, Operational Excellence, and Performance.

Introduce a configuration mechanism that allows to enable or disable Code Quality analysis for specific applications and libraries. This capability would make it possible to exclude test applications, sandbox applications, or temporary applications, preventing them from affecting overall code quality metrics. With this configurable approach, we would gain greater control over which artifacts are included in quality measurements, ensuring that reports remain accurate, relevant, and focused on production-relevant systems.

I would like to suggest that applications relying on deprecated elements (marked as DEPRECATED_) be considered as technical debt in the AI Mentor platform. By considering applications that depend on deprecated elements as technical debt, we can prioritize their resolution and allocate resources to address them accordingly. This approach will help us ensure that the AI Mentor platform remains up-to-date, efficient, and aligned with industry best practices. Thank you for considering this suggestion. I believe that by actively managing technical debt related to deprecated elements, we can enhance the overall quality and maintainability.

I would like to propose the development of an API that allows integration with CI/CD tools to check for unused dependencies in an application. This API would provide a boolean value indicating whether there are any unused dependencies, enabling automatic detection during the CI/CD pipeline. By integrating this API into the CI/CD workflow, developers can easily identify and remove unnecessary dependencies, improving application performance and reducing resource consumption early in the development process.

Ai mentor should have the same capability of the new mentor in odc service studio, that could allow us not only observe the Tech Debt but take immediate action and solve It using the chat like mentor to prompt and tweek the findings!

ODC Portal should have a screen with a interface to manage all the setting of the OuSystems Cloud connector, instead of a command line.

Hey guys,I think it would be really helpful to have a new tab besides the TrueChange tab that shows the Architecture Dashboard report for the specific module we're seeing.Apart from being more accessible, developers can easily look at the report in the module scope and more proactively reduce technical debt.

 Problem: Even after years of development, maintaining consistent code quality across large teams is a persistent challenge. Despite the existence of best-practice documentation, junior and even senior developers frequently bypass critical standards—such as proper documentation, naming conventions, Max. Records settings, or inefficient operations like lists within loops. Currently, code review is a manual, reactive process that happens too late in the development lifecycle. Proposed Solution: I propose a new "Governance Gatekeeper" feature for Service Studio, powered by existing AI Mentor capabilities, that moves code quality from "suggestion" to "enforcement." Policy-Driven Publishing: Allow Admins to configure a set of "Strict Quality Rules" for specific modules. If the modified code fails to meet these pre-defined standards (e.g., missing descriptions, non-compliant naming, or performance anti-patterns), the 1-Click Publish button is disabled, preventing the deployment of substandard code. Granular Control: Provide the ability to toggle these restrictions on or off per module or application. This allows organizations to apply strict "Production-Level" enforcement on core systems while maintaining flexibility in "Sandbox," "Learning," or "PoC" modules. AI-Powered Feedback: Integrate the AI Mentor to not only block the publish action but to provide a clear, real-time "Action Plan" telling the developer exactly what needs to be fixed to unlock the publish button. Impact: By integrating automated enforcement into the development loop, we can: Guarantee Technical Debt Reduction: Prevent bad patterns from entering the codebase at the source. Scale Mentorship: Use the platform to train developers in real-time, effectively automating the role of a lead developer in enforcing standards. Elevate Enterprise Reliability: Ensure that all production-bound code meets a uniform level of quality, documentation, and performance before it ever hits the server. Thanks

Currently, ODC does not provide a mechanism to extract or automatically generate documentation for applications. In previous versions, such as OS11, tools like OutDoc and direct access to OutSystems metadata allowed teams to generate technical documentation more easily. The proposal is to introduce an AI-powered capability that can analyze an existing application or library within ODC and automatically generate technical documentation, such as: application architecture overview dependencies and libraries used module and component structure APIs and integrations main functional flows This feature would significantly reduce the manual effort required to create documentation, improve knowledge sharing across teams, and ensure that documentation remains up-to-date with the evolution of the codebase.

Hi everyone, I’ve noticed something with the "Duplicated Code" pattern in AI Mentor that has been causing a lot of false positives in real projects. Right now, the detection seems to focus mostly on the Action flow structure (basically the “shape” of the logic). The problem is that many Actions in OutSystems naturally share the same simple pattern, like: Start → SQL → Assign → End So even when two Actions have completely different SQL queries and return different Output Structures, AI Mentor still flags them as duplicated just because the flow looks the same. In practice, these aren’t duplicates at all. They just follow the same architectural pattern. Trying to merge them usually doesn’t make sense, can hurt readability, and sometimes even impacts performance. Suggestion It would help a lot if the duplication check also considered the SQL widget details and the Action contract, not only the flow. For example, avoid flagging when: the SQL statement text is clearly different the Output Structure is different the returned data shape is different Maybe duplication should only be reported when the flow and the SQL and the outputs are very similar. This would make the detection more semantic instead of purely structural. Benefits Reducing these obvious false positives would: • Reduces false positives • Less time wasted marking valid code as “Won’t Fix” or "False Positive" • Prevents unnecessary refactoring that may hurt performance • Increases developer trust and adoption of the tool I think this small change could make the Duplicated Code pattern much more accurate and much more valuable in day-to-day development. Thanks!