# Ubiquitous Language

## Component Support

**Supported component** — A component registered in this Skill that has passed
the real platform temporary-save and temporary-snapshot-readback verification.
It may be selected and generated by the Skill.

The registry and the supported-component list contain supported components only.
There is no experimental or partially-supported registry state.

A component is supported only when all of the following hold: its real frontend
fields and dynamic required/exclusive rules are documented; every public
parameter has a verified native DTO conversion; conversion and validation have
automated tests; at least one real temporary-save and temporary-snapshot
readback succeeds; and its documentation states the supported property scope.

An individual supported component exposes only its verified properties. An
unverified property is absent from its public parameter contract and is rejected
when requested; it does not make already-verified properties unavailable.

**Component contract** — The machine-readable source of truth for a supported
component's name, public properties, types, required rules, and context
inputs/outputs. Derived component lists are updated by an explicit sync command
and checked for drift before a change is accepted.

**Core capability** — A stable shared operation such as temporary save/readback
or workflow compilation. Component-specific logic remains private by default;
it is promoted to the core only after a second real component needs the same
operation.

**Unsupported capability** — A platform capability lacking the required
component contract or verified native DTO. It is not registered in the Skill;
the Skill must report it as unsupported rather than fabricate a value.

## Generation Lifecycle

**Generation attempt** — An actionflow application created by one execution of
the generator for a semantic plan; a failed attempt may be disabled and
removed, while an old unmarked attempt remains a manual-cleanup candidate.

**Formal actionflow** — The one current generated application whose save,
enablement, and formal readback have all succeeded.

**Duplicate generated actionflow** — A non-current `AI-` application carrying
the same generator identity as the current formal actionflow, even when its
display name is different.

**Generator identity** — The stable identity derived from the semantic plan
while excluding only its display name and description; it is distinct from the
human-readable actionflow name.

## Existing Actionflow Modification

**Modification target actionflow** — The exact existing application identified
by `appId`; a display name or fuzzy search is never sufficient to select it.

**Original formal design** — The current design returned by the target
actionflow's active scene before an update. It is the update baseline and is
backed up before any write.

**Preserving update** — An update that applies only explicitly declared
operations to the original formal design and retains every unmentioned node
and property. The save request keeps the baseline IDs, but the platform may
reallocate action/output IDs when creating a new version; readback must match
the new version by tree position/type when an ID changes.

**Modification backup** — The complete original formal-design response stored
before a preserving update. It is evidence for review and manual recovery; the
CLI does not silently use it to overwrite the target after a failed save or
readback.