Make the brief clear and shape the product through conversation

A strong brief does not need technical language, but it should cover:

• Business: what product or service you offer.
• Audience: whose problem you are solving.
• Scope: which pages and actions belong in the first version.
• Style: the intended tone and any direction to avoid.
• Outcome: whether visitors should sign in, enquire, purchase or register interest.

Build implements confirmed requirements. Plan shows a proposal and generates a plan after Confirm and generate plan; Chat discusses, explains or suggests. Plan and Chat may save conversations, requirement versions and plans, but do not change business tables, fields or records, approve capabilities or publish an App. Executing a plan or suggestion still requires entering Build and confirming the current proposal.

Interpretation distinguishes the current project from a new project, explicit requirements from inferred suggestions, and preserves constraints such as no tables or no rebuild. Reversible, low-risk first-version gaps receive minimal defaults marked as inferred. Only critical questions that materially change the direction appear, and they use clickable choices only. Submitting or editing a request advances its requirement version; an old confirmation cannot authorize new content. Interpretation failure or unresolved critical questions stop the build from starting.

The Build proposal uses understandable names and descriptions to summarize pages, features and the business information that will be saved; it does not display technical Schema diffs or internal identifiers. Whether or not the proposal includes new business tables, the user chooses Confirm and build only once. When data is needed, the server prepares the plan and atomically applies its data changes in the same flow. Page generation starts only after that succeeds, and the browser does not create tables one by one.

If data setup fails, page generation has not started and no partially applied data changes remain; choose Retry and build to try again. A tableless Build does not create an empty data changeset. Build can create or reuse an App and produce a draft, but capability approval, App publication and rollback are separate actions.

A controlled App uses platform-supported declarative pages and backend operations to access business data. After Build, use Review private preview access to inspect resources and actions such as query, create, update and delete, then choose Approve and open preview. Writes in this preview change real records; they are not automatically simulated.

Approval is for this App's owner preview only and does not grant access to other projects or visitors. Revocation immediately denies subsequent access. An ordinary HTML preview has no private-data access; a clickable form does not prove that a backend is connected.

The current controlled integration is limited to the fixed DeepSeek chat operation. The owner must separately configure a BYOK (bring your own key) connection and approve this App's operation. Neither Build nor preview approval creates that connection; missing configuration, authorization or service availability must not be presented as connected. Never paste a key into chat, a generated page or a support case.

When a request needs generated content, the page uses platform runtime AI forms, and the recorded DeepSeek chat operation is no longer the page's execution path. Finishing the build enables the app's test and production AI authorization automatically, 10,000 credits each per month by default; test and visitor calls are paid from the project owner's universal credits, and you can adjust the limit or pause AI under AI and usage in the editor toolbar. Without the owner's connection or authorization, approval does not succeed: the preview states the missing prerequisite and points to the platform-AI implementation.

Generated pages cannot add login providers, custom role permissions, arbitrary external APIs or arbitrary backend code. Authentication must use existing App runtime configuration. Unsupported implementation requests stop explicitly; capability questions can remain in Chat.

The preview displays the current page and switches between desktop, tablet and phone widths. Multi-page projects include a page list, and navigation is generated together with the pages.

Each completed generation creates a project version. Open version history to review an earlier result and restore it as a new current version; existing history is not overwritten. Editor version restoration is not App Release rollback and does not restore a backup of business records.

If a task is interrupted, keep the current project and use Resume when the editor exposes a safe recovery point. Resume continues the original task without requiring the same request to be sent again. If an older task lacks a verifiable requirement version or its confirmation is stale, preserve existing results and review the current request again as directed.