RFC-003 — Events on ui_view

Status: ratified. Source: atomprd/specs/rfcs/RFC-003-events-on-ui-view.md.

Summary

UI section types that can trigger an event (button, form) carry a dispatch field naming a feature. The dispatch is resolved at codegen time against the project’s feature set.

Dispatch shape

{ "kind": "button", "label": "Create",
  "dispatch": "feat_create_habit_h14a", "variant": "primary" }

{ "kind": "form", "fields": [...],
  "submitLabel": "Save",
  "submitDispatch": "feat_save_profile_z9z9" }

Resolution rules

Feature ID lookup. The dispatch string must match an existing feature atom’s ID. Validator rejects dangling dispatches.
Args inferred. If the section is a form, the form’s fields[] map to feature.behavior.steps[*] arguments by name (form field name = step argument name).
No inline action chains. Earlier drafts allowed inline [{ $do: ... }] arrays. RFC-003 removed this — dispatches go through a feature atom so the feature is reusable, auditable, and Pattern-C-discoverable.

Why funnel through features

Reuse. The same dispatch lands in two different ui_views and they both trigger the same feature.
Audit. The feature is the unit of change; dispatch sites are read-only references.
Pattern C. The Pattern C inference for feature walks renders_feature reverse edges from ui_views — funnel-through-features makes this graph clean.

Built-in dispatches

A small set of built-in dispatch strings don’t refer to features:

Dispatch	Effect
`__navigate__:<screen_id>`	Navigate to a different screen within the same `ui_view`.
`__back__`	Pop one step in the navigation stack.
`__close_modal__`	Close the current modal.

These start with __ and are reserved.