The editor's step is an application authoring activity; the executor runs only closed Template syntax. An activity visit is an occurrence within a Process, not another kind of template.
Source firstStepKey, nextStepKey and condition branch keys define the authoring graph. Compilation
lowers that graph to ordinary choice/composition/iteration and named scopes. Reaching the same activity
again creates a new visit. Source graph metadata is not an engine dispatch table.
Keys, titles, links, phases and descriptions live in the app authoring model. Provider configuration
comes from Integrations; generic field schemas from Platform; field macro references from Domain.
enabledExpression is still round-tripped metadata, not an implemented activity gate.
Human input suspends at a generic interaction contract. Automatic work is driven by the separate worker; it may itself wait for clock, IO or a child-creation receipt. Automatic work cannot be skipped by calling the human completion endpoint.
Process sharing/access, activity permissions and field permissions are separate gates. Only permitted writable fields are accepted. Required-field and compiled completion predicates validate completion. Hidden/read-only fields are not treated as ordinary mandatory edits. Rich HTML is sanitized when rendered, without altering stored values or downloads.
Condition, set-context and wait notation compile to generic expressions/state/effects. Wait schedules are recorded once; host date parsing is explicit. Pure expressions receive time rather than consulting ambient state. Their resource bounds are trusted host policy.
Integration definitions build inspectable HTTP/data/loop/error programs. They do not install native
callbacks. An inline template activity can reuse any closed composition, so simple and composite
behavior can be substituted uniformly.
Definitions carry capability names, not secret strings. Deployment binds those names to constrained endpoints, placements and protected signing policies. See deployment bindings.
Soft warnings, hard failure and explicit known-error recovery differ by library policy. When an
HTTP effect's outcome is unknown (a timeout or dropped connection after it may have been sent), the
effect's declared repeat policy decides: safe effects are retried with bounded backoff and then
fail with effect-unavailable; checked effects fail with outcome-unknown so the definition's
recovery can check what happened; undeclared effects hold the process for reconciliation. A request
the host knows was never sent (DNS, refused connection, failed TLS handshake) is retried whatever its
declaration. Reads of the platform's own records are always safe to repeat. A generic scheduler
catches one process's errors without making all other processes fail, but that is not transparent
durability.
Arbitrary JavaScript is no longer executable. Five known repository scripts have closed replacements;
unknown old source must be rejected by offline migration. A Custom callback is not a valid extension.
App source strings are authoring syntax, compiled before registration. Execution/presentation contain closed expressions. See expression reference for scope and error boundaries.
Prefer a reusable library composition. If new editor notation helps, use the app-owned model and compiler, not a Platform provider union. Follow add an activity.