thumbnails, or replay chunks in app tables, `application_state`, `settings`,
or `resources`; persist URLs, ids, or handles instead.
- Never hardcode API keys, tokens, webhook URLs, signing secrets, private Builder/internal data, customer data, or credential-looking literals. Use secrets/OAuth/runtime configuration and obvious placeholders in examples.
- Follow the root framework contract: data in SQL, actions first, application
state for navigation/selection, and shared agent chat for AI work.
- Use actions for app operations and keep frontend/API parity.
- Treat the chat as the default UI. When the user asks for a capability, prefer
adding or improving the action surface first, then add a page, table, form, or
widget only when the user needs to inspect, compare, approve, or share durable
objects.
- If the user wants to plug in their own agent backend, keep the app shell and
thread UI intact and adapt the chat through the framework's `AgentChatRuntime`
connector helpers instead of forking the transcript/composer UI.
- Keep the action surface small and orthogonal: every action is a tool in the
model's context window, so prefer one CRUD-style `update` (patch of fields)
over many per-field actions, reach for an existing generic query / escape
hatch (`provider-api-*`, dev `db-query`) before minting a new read action,
mark UI-only or programmatic actions `agentTool: false` to hide them from the
model (distinct from `toolCallable: false`, which only gates the extension
iframe), and delete or hide actions the UI no longer uses. See the `actions`
skill.
- Keep database code provider-agnostic and additive.
- Use `view-screen` or application state when the active page/selection is
unclear.
- For new features, update UI, actions, skills/instructions, and application
