English source · 9 min

Connected creation and app workbench — 12 October 2026

See the connected AI workspace for the 20 October context, reviewed private execution, complete app composition, real preview, editable list handoff and remembered merchant-guidance workflow. Current status.

This change extends existing owners. It does not introduce a second app language, translation queue, checkout or model registry. Hosted availability is a separate acceptance step; the checks below use isolated shops and local provider fixtures.

Build an app with a working starting point

Open Developers → New app and choose Product advisor, Returns workspace or ERP handoff. Each opens an ordinary editable Manifest with translated labels.

Five illustrated workshops walk through these patterns, additional customer fields and scheduled Flow automation with current English captures, agent tasks and explicit preview/staging/live differences.

This capture uses a synthetic local shop. Choose a pattern, edit its controls and data bindings, preview it in a private sandbox, then review the version before staging. The same workflow is available to coding agents.

The existing Visual Basic-style designer, F4 property inspector, typed code-behind, model workspace wizard, F5 preview, undo/redo, private drafts and versioned release remain the same system. Buttons and fields bind to the real app gateway. New data controls inherit the current product/customer/order binding when the existing controls on that model agree. Changing the selected model uses that model's binding. Ambiguous or unrelated bindings are not guessed; the property inspector still lets you choose explicitly. Missing host context never triggers an unfiltered request. Standalone inputs update the local form buffer only when exactly one registered form has the same entity and record ID. Ambiguous forms, unrelated records/models and protected core-reference fields do not join. Typing makes no server write; the existing validated Save action sends the form's record and revision. At runtime, raster rows grow to fit actual labels and editor contents; small model-supplied heights no longer hide inputs behind a card's internal scrollbar. Tables retain their own bounded scrolling and mobile layouts stack normally.

flowchart LR
  Recipe[Working pattern] --> Manifest[One Manifest]
  Canvas[Visual designer and BASIC instructions] --> Manifest
  Agent[Coding agent or model proposal] --> Review[Review models, UI and access]
  Review --> Manifest
  Manifest --> Preview[F5 private preview]
  Preview --> Version[Immutable version]
  Version --> Stage[Explicit staging approval]
  Stage --> Release[Select app and data changes]
  Release --> Runtime[Same API, MCP and UI gateway]

Both in-app model generation and coding-agent JSON imports now produce an explicit review. They do not replace the current canvas automatically. A changed draft or selected environment blocks acceptance. Rejecting a proposal keeps the current draft; the immutable server build is still visible in version history and can be archived through the existing controls.

Generation supports the native input/button/image/frame/tabs/KPI/chart vocabulary, not only table/cards/form/text. A local model receives an 8,192-token output ceiling for app definitions instead of the 2,000-token ceiling for smaller tasks. This is a maximum, not a guarantee of complete or correct output. Model quality itself was not benchmarked against a paid/live model in these hermetic checks. Existing-app editing now asks for bounded RFC 6902 changes instead of rewriting the entire Manifest. The model sends JSON-encoded patch values; Rust applies them to a clone, preserves storage/access contracts and assigns the next free patch version. The resulting normal Manifest passes the same native validator and immutable-build path. Empty/no-op proposals, protected metadata, invalid pointers and destructive schema edits fail before a build is saved. Creation without a current Manifest continues to use the complete native schema. No second app language/runtime exists.

The initial full-regeneration Qwen checks did not reliably add the requested controls. After targeted editing and concrete instruction/raster examples, a real local Qwen 3.6 35B call added the requested notes textbox and validated save button in 4.8 seconds, with all four configured translations and order context preserved. The generated button saved an edited form in the real browser through the native gateway. A second check entered text directly in the generated input, used the generated button and reloaded the persisted value; the shared form-buffer binding is also checked against ambiguous forms, unrelated models and different records. Explicit control refresh reloads persisted values and clears an old record value. Typing remains local until an explicitly bound action runs. This is one observed task, not a model-quality benchmark or general guarantee. Preview and proposal review remain necessary; patterns are the deterministic start.

Existing app identity, persisted entities/field types, core references, validation, public exposure and surface/action rights survive generated edits. External service runtime, event/schedule/webhook metadata and manual actions are retained. The model cannot remove persisted fields or silently expose private order/customer data. Handlers of matching controls are retained recursively inside frames and tabs. Invalid output is rejected by the existing native validator; no automatic paid repair loop or arbitrary executable code is added.

A connected merchant translation task

Enable the target language, then ask the merchant assistant to prepare missing translations for the whole catalogue. Review and approve the proposed target. The approval atomically creates one job in the existing translation queue. Repeated approval returns the same task/job identity. No autonomous translation application is permitted.

The applied proposal links directly to Settings → Languages, with the job selected. Review the drafts and apply selected products with optimistic revision checks. Existing translations are retained. Product history and restoration remain in the native product owner. Changed settings invalidate stale proposals.

This is a catalogue translation task, not a claim that a collection-specific France launch automatically configures domains, tax, shipping or sales channels. Those remain explicit existing configuration operations.

Creation recovery and personalization

The companion private Experience change records completed product IDs and caches translations in the same encrypted leased job. Resuming skips committed products, orders parents before variants and preserves the original Storyfront build/editor path. Stage changes clear obsolete counters; displayed completed counts no longer add one before a product actually finishes. Progress history is bounded to thirty stage/detail transitions. Visual inputs are not refetched after a saved design revision when publication can resume without them. Image requests retain their existing unknown-outcome/paid-retry rules.

Storefront personalization now explains its category signals and explicitly states that authoritative prices are unchanged. Local preference state is scoped to shop and cart; delayed responses cannot reorder a different shop/cart. Withdrawal of consent restores ordinary ordering. The response includes machine-readable signal weights/window/scope, not a causal lift claim. Existing fixed-horizon randomized layout experiments remain the measurement owner; no fabricated improvement is reported.

Responsibility and repeatable checks

Run the frontend suite, Rust units/clippy, and registered integration suites app_generation, translations, app_assistants, app_studio, app_preview, checkout_handoff and cognitive_experiments. Use a disposable database. app_generation performs local HTTP inference contracts, not actual model inference. The private repositories retain their own checks and native runtime acceptance. The formal policy checks do not prove SQL, UI, model or external provider correctness.

Private Shopware Payments additionally verifies lost-referral replay, explicit merchant disconnect, signed account callbacks, capture, authorize/void, pending refund reconciliation, process restart and scoped SEPA input. Actual authorized PSP Sandbox/Live onboarding, every browser wallet/3DS variant, load behavior and complete original plugin parity remain separate acceptance requirements.

Local acceptance for this update: 193 Rust units; 418 frontend tests; four-language localization and exact module inventory; 216 private Experience tests plus 17 integration cases, packaged-runtime boot and PostgreSQL process restart; eight private payment units plus the actual two-service PostgreSQL/PSP-fixture path. The documentation build verifies every Markdown source and its rendered page.

App-owned packages and designer previews

The three editable patterns now live in extensions/apps/, loaded directly by app-recipes.ts. The designer shows translated model/field labels and passive form/table/control previews rather than raw entries IDs. Each control and workspace tab has a distinct semantic icon. The design preview performs no data calls; F5 still uses the original bounded actor-private runtime. All-app ownership.

Captured from the real local private sandbox on 12 October 2026. This is the passive design view with labelled sample controls; switch to the existing working preview to exercise actual app records.

The package-ownership follow-up passes 193 Rust tests and 421 frontend tests across 71 files. The complete frontend snapshot measures 64.05% lines, 62.82% statements, 55.98% branches and 51.97% functions; this is not 100% coverage. Actual local PostgreSQL/provider fixtures verify app development, private previews, connector delivery and payment compatibility. A browser edit to an installed order-bound app remains present after reloading and reselecting its private sandbox.

Lifecycle and reference-app follow-up — 12 October 2026

• App versions are filtered to the selected app. Saving an unchanged restored draft reconnects its exact immutable build; other drafts stay dirty. New patch versions are chosen from the complete history, including archived versions.
• Native editor save controls are deduplicated only when the explicit action validates and writes that same form. Missing/disabled/unrelated handlers retain the host Save control. Order-bound forms support multiple named cases and one save per confirmed status transition without reopening.
• Data-model editors expose the generic workflow field, initial state, allowed edges and immutable fields. The Returns package owns its own lifecycle. AI presentation edits preserve this contract; they cannot quietly remove it.
• Studio distinguishes pending workspace load from expired login and offers retry for actual load failure. Assistant conversations remain mounted through reauthentication, preserving the current question.
• The ERP reference package now includes its own Rust service, app-private forced RLS receipts, signed events, restart-safe deduplication and explicit uncertain result reconciliation. Required operator deployment is still separate from editing or publishing the Manifest. No commercial ERP parity is claimed.

Actual HTTP/PostgreSQL tests reject queued writes using a superseded package, foreign order references and invalid transitions without record/outbox changes. The reference adapter tests use real Rust processes and a local ERP fixture; these do not establish a live merchant's ERP credentials or provider settlement.

Repeatable public lifecycle acceptance

A fresh sample shop created through start.veyndo.ai was used for package creation, staging installation, selected package/data releases, public product advice, edit/upgrade, restoration through a new immutable revision, recoverable archive/restore and simulated checkout. The dated release evidence includes exact app/order identifiers and screenshots. Restoring a version does not rewind order/payment state or erase version history.

sequenceDiagram
  participant Editor as Visual editor / coding agent
  participant Stage as Private staging
  participant Core as Current-package transaction
  participant Live as Live shop
  Editor->>Stage: Save and install reviewed version
  Stage->>Core: Validate owned record + revision + workflow
  Core-->>Stage: Confirm record and revision
  Editor->>Live: Publish selected package / records
  Editor->>Stage: Reopen prior build as next free version
  Stage->>Live: Publish reviewed restoration
  Note over Core,Live: Orders, payments and customer state are never rewound

Native standalone controls hydrate their server value before becoming interactive, so delayed initialization cannot restore a text the user just cleared. The workspace Refresh control also refreshes the shared app registry after a successful authorized load, including apps installed through API/agents. Forms show their model label without an obsolete loaded-record count after saving.