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 expresses execution intent. Without critical questions or capability blockers, page creation does not need a proposal confirmation every time; business-data preparation still requires confirmation of its exact changes. Plan presents 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. Explicitly choose Build to execute a plan or suggestion.

Interpretation retains explicit limits such as no new tables or no rebuild, uses clickable critical questions and marks low-risk defaults as inferred. New or edited requests advance the requirement version; old confirmation cannot authorize new content.

When business tables or initial data need preparation, review the exact table, field and initial-data changes, then choose Confirm and build once. The server atomically applies the confirmed data plan before page generation. A preparation failure leaves those changes unapplied; keep the project and retry. Build can start directly when no business-data preparation, critical questions or capability blockers remain.

The confirmation card describes table, field and initial-data changes in readable terms. Build may create or reuse an App and produce a draft; capability approval, App publication and rollback are separate actions.

A controlled App accesses business data through platform-supported pages and backend operations. After a confirmed Build, the platform prepares only the owner-preview access needed by the current page for this project’s resources and opens the preview; there is no second Approve and open preview step. Historical pages, changed requirements, revoked access or a missing external connection may still prevent preview; follow the visible guidance.

Preview writes change real records, so use authorized test data. This access 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. External integration approval, App publication and rollback remain separate actions.

BYOK connections and platform runtime AI are separate integration paths. The current BYOK 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; Build and preview do not create the connection. Never paste a key into chat, a generated page or a support case.

A page that needs generated content can use platform runtime AI forms without a DeepSeek BYOK connection for that path. After Build, supported, available AI functions receive separate test and production authorizations that share one project monthly limit, 10,000 credits by default. Calls also count toward the account-wide monthly limit across all projects; its initial default is 10,000 credits, while an existing setting is retained. These limits are not free credits: test and visitor calls are paid from the project owner's universal credits. Adjust limits or pause AI under AI and usage in the editor toolbar. A failed status read does not mean the project has no AI; the page explains missing configuration, model availability or authorization.

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 is interactive. Switch desktop, tablet, phone and subpages, then test navigation, buttons and forms. Preview updates retain text being entered; mobile actions and long forms still need testing.

Progress names the platform work and elapsed time, then explains the result and actions to try. Progress does not prove that backend connections succeeded.

Candidate pages receive static quality and isolated layout checks before attempted adoption, and automatic repairs are disclosed. Checks use isolated synthetic states and do not verify real business records or external services. Eligible scoped-edit failures offer Retry as a section adjustment while preserving other design decisions; availability depends on the current task and is not promised for every failure.

If image planning or generation cannot finish, page creation may continue with an explicit missing-imagery notice. A completed build does not mean every requested image was generated.

Terminal preview errors show a failure state. Keep the project and last usable version, and follow recovery or reporting guidance.

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.

You can submit a build failure report from the project. The failure card hides technical details while the server retains the generation chain for review. An accepted report can receive 200 universal credits after review; submission does not mean acceptance or payment, and the same report is not rewarded twice. A transport failure retries once, and the daily report limit gives a specific explanation.