Skip to content
Ocean-Atlasv0.1.0Canonical Knowledge

Make the First Change

This is the moment the rest of this path has been building toward: you change the model, not the generated code, and the system changes with it — entirely inside Ocean App, on the Onboarding: Task Manager project you already opened.

Priority — one of the two enums in app-todo-dt.ocn — currently has three values:

enum Priority
low
medium
high

Add a fourth:

enum Priority
low
medium
high
urgent

That’s the entire change: one new line in one definition.

Open the Priority datatype in Ocean App and add the urgent value above. Nothing else in the Bundle needs to change — adding an enum value doesn’t break anything that already references Priority by type. It only adds a possibility, and every existing reference stays valid.

Use Ocean App’s generation action again, the same way you did in Run the First Example. Ocean App validates the edited Bundle and regenerates the application from it.

Search app-todo-dt.ocn for Priority, and you’ll find it used far beyond the field it’s declared on:

  • TodoApi’s findItemByTitleAndPriority and findItemByTitleOrPriority operations both take a priority:Priority parameter — they now accept urgent without a single line of API DSL changing.
  • Three dashboard forms — TodoSearchDashboard, TodoSubmitDashboard, and TodoEditDashboard — each have a priority Priority field, and each should offer urgent as an option once regenerated, without any dashboard or UI DSL changing either.

Nobody edited the API. Nobody edited three separate forms by hand. One enum value, declared once, reached every place that referenced its type — because those places reference the type, not a hardcoded list of its values.

Once regeneration finishes, confirm the result through the running application:

  1. Open the generated Submit form.
  2. Confirm that urgent appears among the priority options.
  3. Create a task whose priority is urgent.
  4. Open or search for that task.
  5. Confirm that its displayed priority remains urgent.

This single interaction verifies the whole path: the generated form knows the new enum value, the API accepts it, persistence retains it, and the UI reads it back correctly.

If you downloaded the generated project in Run the First Example, download it again after this change and diff the two — a concrete way to see exactly what one model edit changed in the generated output, beyond what’s visible in the running UI.

You changed one line in the model. The API’s accepted values, the search form, the create form, and the edit form all changed with it — because all four were always describing the same Priority, not four independent copies of it. This is the whole point of a model-first system: change the description once, and everything downstream stays in sync by construction, not by remembering to update every place separately.

The Everyday Workflow turns this one change into the loop you’ll repeat for every change from here on.