Prototype progressive workflow-to-app authoring experience

[enricopiovesan]

Problem

The current authoring surface exposes contracts, registry, WASM, hosts, traces, MCP, and governance before a median developer can first consume a capability.

Scope

Prototype a progressive reference-app journey from a structured workflow description to a governed app shell. This is not authority for natural-language runtime execution or automatic publication.

Definition of done

• The journey starts from a bounded workflow description and produces a gap list, proposed existing capabilities, and explicit unresolved decisions.
• Consumption of an existing capability succeeds before capability authoring/governance detail is introduced.
• Any proposed new capability is emitted only as a reviewable draft; publication requires the normal governed process.
• The experience distinguishes app shell code, contract configuration, and capability implementation.
• At least one novice-oriented walkthrough and one expert escape-hatch walkthrough are documented.
• Usability evidence from a small, recorded evaluation identifies completion rate, confusion points, and excluded cohorts; conclusions stay bounded.
• No model prompt, credential, or user payload is retained without an explicit documented policy.

Product decision

The desired workflow-description input and allowed automation level need owner approval before implementation.

[enricopiovesan]

Decision inventory

D1 — workflow-description input

• Structured workflow form only: deterministic and readily reviewable; less natural for new users.
• Natural language accepted as an untrusted draft: accessible; requires explicit handling of ambiguity, prompt data, and unsafe suggestions.
• Both: progressive experience; higher implementation/test surface.

Recommendation: start with structured input and permit natural language only as an optional draft-to-structured transformation with no publication or execution authority.

D2 — automation boundary

• Generate an app shell and reviewable drafts only: preserves governance and clear ownership; leaves more user work.
• Automatically publish/activate generated artifacts: fast; violates the current manual approval and trust model.

Recommendation: generate only reviewable app-shell/configuration drafts; normal publication, activation, and approval remain mandatory.

D3 — data retention

• No prompt retention: strongest privacy; weaker iterative UX.
• Opt-in local retention: supports iteration without third-party disclosure; requires local lifecycle controls.
• Remote retention: broadest UX; adds material privacy/security scope.

Recommendation: no retention by default; optional local-only retention if needed.

Governing consequence

A reference-app policy/ADR is needed if natural language or retained drafts ship. No runtime spec is needed for the structured-only prototype.