Default Object Lifecycle Actions

One area where the Builder seems to experience break down is in how it handles object lifecycle actions by default. The Builder correctly generates the core domain objects we need, but it does not automatically provide the corresponding UI affordances to manage them.

In our case, the application introduces three primary entities: Readiness Projects, Flows, and Testers. While these objects were created successfully in the data model, the generated UI did not include any navigation or controls to add instances of these objects. When we explicitly requested “Add” buttons, those were added, but the UI still lacked standard Edit and Delete actions.

From a UX perspective, it seems a surprising omission. CRUD actions (Create, Read, Update, Delete) are a foundational expectation when introducing new object types into an application. In most enterprise and internal tools, it would be the exception, not the rule, that a user does not want to create, edit, or remove instances of newly introduced objects. Requiring explicit prompts for each of these actions creates unnecessary friction and increases the likelihood of incomplete or nonfunctional UI states.

For example, our intended navigation model was:

• A Readiness Projects landing view with a clear “Add Project” primary action, and row‑level Edit/Delete actions for existing projects.

• Within a Project, a Flows section with an “Add Flow” action, plus Edit/Delete controls per flow.

• Within a Flow, a Testers list with standard Add/Edit/Delete capabilities.

This follows a common master‑detail and nested‑object interaction pattern that users intuitively understand.

I believe the Builder should treat this as a UX rule of thumb:
When new objects are introduced, default to generating full lifecycle actions (Add, Edit, Delete) unless explicitly told otherwise.

Alternatively, the Builder could surface this as a structured confirmation step, listing the objects it has introduced and asking where it is acceptable or not acceptable to provide standard navigation and management actions. This would preserve flexibility while still aligning the generated UI with common UX and usability expectations.