English source · 9 min
App system: delivered foundations and remaining gates
See current public status for the running release and observed journeys. The connected AI workspace explains contextual planning, reviewed private execution, app composition, real preview, editable list handoff and remembered merchant guidance.
Updated 2 November 2026: the public Core includes the shared shop/app Canvas with zoomable placement previews, graphical elements, direct behavior editing and the contextual agent dock. Product, page and app imagery share localized caption controls. The current visual workflow, App Studio guide and new product advisor film show those connected owners. The wider source-build, replay and managed-service programme below remains open.
Updated 29 October 2026: the connected follow-ups add agent-composed native working views, description-led consultation app generation, upgrade checks against saved data and current consumers, actual browser designer/customer acceptance, an actual WooCommerce source migration and an isolated 150-table restore with the native operational chain. Current implementation and delivery and public steps distinguish their exact environments. Apple's new callbacks are saved and admitted; an authenticated Apple return remains separate.
Updated 22 October 2026: the public release includes app-reference diagnostics, shared private customer-agent testing, catalogue language/image readiness and editable native shopper selections. The current illustrated acceptance records the deployed result. Connected collection preparation and selected publication, configured B2B purchase/reorder, reuse as a Flow and recorded-rule comparison retain their 21 October public evidence. The tables below retain the wider programme's remaining boundaries. The integrated app builder is usable. The complete business-capability proposal — describe an individual business model and have Veyndo build, verify, operate and maintain it — remains an implementation programme. This page maps that distinction; it is not a completion percentage.
The comparison uses the 15 October proposal, the hardening baseline 7a4388d,
the deployed agent-control/message follow-ups linked from current status,
the actual source owners below and dated release receipts. Source implementation,
local integration tests and hosted acceptance are different evidence. A later
branch, build or documentation change does not update a hosted result by itself.
Start with what you want to do
| Need | Read next |
|---|---|
| Create an app visually or with agent assistance | App Studio, workspace controls, five illustrated examples |
| Extend native object fields | Core object extensions: canonical private bindings, native details/grids/exact filters and current rights; hosted acceptance is separate |
| Understand data, permissions and API/Flow/MCP calls | App platform, security, shared storage |
| Continue saved merchant-agent work | Durable runs and their boundaries |
| Check app connections and test private shopping | App Studio diagnostics, customer simulator, public screenshots and outcomes |
| Understand the full product direction | Business capabilities |
| Check the latest recorded hosted release | Current status and public acceptance; older releases retain their dates in the historical release record |
Agent controls reuse existing keys/tasks and central inference. Hosted stop/re-enable and checkout acceptance is recorded separately; it does not close arbitrary app execution or real-provider billing gates.
The 18:26 hosted buyer/POS follow-up also accepts a preserved POS cart, one native invoice/PDF and completion through the accepted 0.1.3 app snapshot. Current payment/delivery guards remain enforced. It fixes the standard storefront's shared-demo login attempt, but does not newly accept a hosted signed-buyer RFQ or original embedded Storyfront purchase.
Implemented foundations
| Capability | Actual implementation | Boundary |
|---|---|---|
| One app contract | Versioned Manifest for models, native views, actions, placements, configuration, events and optional decision hooks; shared visual, API, Flow, MCP and agent consumers. | Complete typed request/response/WIT generation for every native operation remains open. |
| Visual workspace | Compact resizable toolbox, drag/reorder, actual field properties, shared Flow topology for bounded UI instructions and separate contextual assistant. | The design canvas uses sample data; F5 is the working private preview. Codex/Claude use task export/import, not automatic shell execution. |
| Multiple placements | A single app can contribute product, header, checkout, account and private Studio areas with distinct context/action allowlists. | A placement neither grants rights nor makes an unpublished app public. |
| Installed settings | Declared localized text/secret/boolean/integer settings, encrypted live values, digest/revision consent and write-only secret inputs. | Only approved private service actions receive resolved secrets; no browser, preview, release or task export receives them. |
| Fixed data storage | Four physical tables: logical models, records, lookup values and relationships; full tenant/app/model identity, signed forced RLS and composite references. | Logical row/byte/model budgets remain. Fixed table count is not evidence of unlimited throughput. Independent services retain their own explicit storage contracts. |
| Versions and private releases | Immutable package versions, current consent/digest, actor-private preview, staging and selected publication through native owners. Upgrade review checks stored records, migrations, saved examples, current Flow rights and active payment consumers through a rollback-only ordinary installation. | Package and record publication are separate selections. Code/data recovery cannot undo sent mail or payments. |
| Pure decisions | Existing WIT components receive bounded read-only snapshots and return accepted/adjustment/reason results; native money, tax, inventory and checkout validate and apply effects. | Four hooks do not constitute a generated before/after/replace contract for every commerce operation. No arbitrary WASI network/filesystem access. |
| Executable app goals | Optional capability v1: localized intent/assumptions and up to twelve frozen synthetic decision examples; mismatch/trap blocks save or installation. |
Expected examples are not server-proven human confirmations, historical business replay or proof over every input. |
| Saved merchant planning | Existing PostgreSQL tasks/conversations and fenced Rust workers execute reviewed native plans, retain completed steps, yield to translation work and resume explicitly. Collection preparation can join selected products, a category, translations and a landing page; completed native work can become an inactive Flow draft. | Current rights, scope, revision and personal review still apply. Supported native operations do not establish general durable execution of arbitrary app code or external effects. |
| Connected app diagnostics and customer testing | App Studio identifies unresolved view/model/action/API/Intelligence references and opens their native editors. Installed sandbox apps open the shared customer simulator, whose durable fictional buyers use native products, baskets, budgets and simulated checkout. | Declaration checks are not runtime certification; shopper agents exercise commerce APIs rather than visual browser usability. Publication remains a separate selected review. |
| Database/browser authority | Separate restricted tenant/system pools, role-bound signed scopes, forced policies; existing HttpOnly session ledgers, exact origins and build-owned Studio scripts. Dedicated bounded planning credentials now have separate authority from ordinary integration keys. | Broader operational/security work and authenticated Apple account return remain. Selected negative tests are not exhaustive security certification. |
What “build”, “replay” and “workflow” mean today
- An immutable App Studio build validates and stores a Manifest. It does not compile arbitrary Rust/TypeScript source in a microVM.
- Event replay redelivers authorized saved events with original IDs. It does not calculate what the last thirty days of orders would have cost under new logic.
- Recorded-rule comparison evaluates a saved condition and unsaved draft on
bounded frozen
order.placedinputs. Its public acceptance establishes meaningful condition differences without writes, not full historical checkout repricing. - Frozen decision examples execute a real component with synthetic inputs. They do not import customer history or establish a fleet-wide compatibility check.
- App-record workflows guard their own records. The native lifecycle change also adds bounded declarative order/RFQ states and version-bound running objects. It does not run arbitrary guard code or grant app control of payment/offer acceptance; hosted delivery is tracked separately.
- Sandbox publication selects reviewed changes. It is not percentage-based canary traffic routing with automatic KPI rollback.
- A configured independent service is not evidence that Veyndo built and provisioned a safely isolated tenant service on demand.
Required implementation and acceptance
The requested full integration remains open until these connected outcomes work. The B2B furniture configurator is the acceptance case across the existing owners; its code belongs in its app package. Shared Core code owns generic admission and invariants, not the app's material or furniture business rules.
| Gate | Observed implementation and boundary | Required outcome before calling it complete |
|---|---|---|
| B2B configurator | The connected app-owned implementation joins materials, dimensions, frozen surcharges, independent native approval, saved inputs and current-rule reorder. 21 October public acceptance completes browser purchase/list restoration with a separate native API approver: EUR 427, then EUR 447 after a material change; buyer self-approval is rejected and the old order stays unchanged. The subsequent all-browser repetition on 7f0d4266 completes separate-account approval, RAC-34c09fc1, return/reload and reopened order details; current and original configurations remain visible and distinct. |
The connected purchase/reorder outcome is observed with simulated payment. Retain exact-cart approval, immutable accepted snapshots, current-rule reorder and the transport-specific evidence; real provider settlement remains separate. |
| Core entity extensions | Private version-1 bindings now join all four object types to native details, product/customer/order columns and exact filters, current rights, HTTP/MCP and source-bound graph projections. Product/company configuration can clone and publish; customer/order records remain operational. | Namespaced Product/Customer/Order/Company fields share schema/version/current rights across grids, filters/search, API, MCP, supported UCP and knowledge projections; no direct app SQL or cross-tenant/PII leakage. |
| Native lifecycle extensions | Declarative v1 implementation joins app package consent, native order/RFQ states, fixed pure guards, current rights, accepted object snapshots, API/MCP/Flow/history and selected release. Full required CI and the 17 October public order/version-upgrade walkthrough passed. RFQ preparation has local/restricted-runtime coverage; a hosted RFQ buyer walkthrough remains separate. | Reviewed declared order/offer states and transitions, pure guards, version-bound running objects and immutable traces; native payment, stock and refund invariants cannot be waived. |
| Historical business replay | Synthetic component cases, operational event replay and public read-only comparison of recorded rule conditions exist. | Full checkout repricing still needs admitted revision-bound inputs without mail/payment/order effects; actual money/decision/conflict diffs must identify inputs, package digest and uncertainty. |
| Isolated source builds | Manifest admission and component validation exist. | Supported Rust/TypeScript source → real isolated build without production secrets → validated immutable artifact → actual runtime consumer; bounded resources, malicious input/egress cases and cleanup verified. |
| Managed services | Approved independent services have guarded egress, jobs and secrets. | Platform-owned isolated execution, current capability admission, leases, monitoring, costs, restart and uncertain-effect reconciliation. |
| Commerce Crater | Package-owned frozen cases execute on admission/install. | A Core candidate executes supported app/version cases and authorized tenant replay corpora, detects incompatibility and creates a reviewed repair; report the actual evaluated population. |
| Enterprise cells | Cell/relocation architecture and worker roles are documented. | Real provisioning, isolation, update, backup/restore and fenced tenant movement; measured workload/fairness and one authoritative writer. No tenant Core fork. |
| Complete business-capability release | Existing app versions and selected publication exist. | Data/UI/decision/migration changes remain coordinated, old carts/orders have defined behavior, and measured canary routing/rollback respects irreversible effects. |
Separate experiments
Original Shopware execution and native PHP-plugin translation are parked on
experiment/shopware-compatibility.
They are outside the main app-system implementation gates. The native platform
retains inward shop migration and original PHP comparison
fixtures for its own commerce calculations.
Source and evidence map
| Responsibility | Existing source owner | Evidence / guide |
|---|---|---|
| Canonical contract and example checks | src/apps/manifest.rs, business_capability/, commerce_hooks.rs; src/developer/builds.rs |
Business goals and exact test boundary |
| Shared storage | src/apps/records.rs, record_*, storage.rs; migrations 101–102 |
Migration, invariants and hosted counts |
| Studio / installed settings | frontend/src/admin/developer/, frontend/src/admin/apps/; src/apps/settings.rs |
Illustrated controls and actual configuration admission |
| Pricing and order truth | src/apps/cart_contributions.rs, commerce_hooks.rs, src/commerce/, src/order_checkout.rs |
Checkout, app components |
| B2B buying | src/b2b/, existing account and Studio consumers |
Company purchasing and explicit remaining scope |
| Saved agent work | src/agent_runs/, existing tasks/conversations and central inference |
Worker-kill/provider-fixture and hosted reload acceptance |
| Security | src/database_scope.rs, src/database_scope/provision.rs, src/scoped_pool.rs, native auth and session owners |
Hosted enforced database receipt, browser release |
The 15 October shared-storage cutover retired eight verified legacy app tables. After new installations the hosted audit still found four fixed forced-RLS tables, with 27 packages, 12 logical models, five records, fourteen lookup rows and two references. These are that audit's counts, not live counters or a capacity estimate. The same release receipt records new SaaS/Experience and existing Storyfront simulated purchases, embedded confirmation/bag clearing and selected app-page publication. It does not establish real settlement, inbox delivery, issuer setup, completed restore, large-tenant throughput or every feature's correctness.
Earlier receipts keep their original results, including a blocked embedded-browser check in the PR 135 release. The later shared-storage receipt records a separate successful embedded purchase on its later tree. Neither is relabeled as a new test. Follow-up authentication/localization branches need their own merge, deployment and acceptance; their presence in a working tree is not public availability.
Keep this map current
Update this page, the owning guide, README/changelog and relevant public navigation when behavior changes. Name the actual runtime consumer and evidence environment. Retain dated receipts and mark supersession explicitly. Regenerate/check the full Markdown publication with the handbook workflow. Do not mark a gate complete from a form, stub, source file, green unrelated test or configured infrastructure alone.