CAKE20

AI Web PaaS

AI work instructions

This is the sequence that AI must follow to accurately modify Cake20 code.

Recommended Order of Action

  • Always run get_guide first.
  • Check the working tree with git_status before editing and do not overwrite existing changes.
  • Just before the first change, reveal the actual AI/model name and work details with begin_work. Record the editing status. If there is an Incomplete status, replace it with a new task.
  • After begin_work is successful, Cake20 MCP request is made every 3 minutes until finish_work. If there is one, I'm working on it. One of the general MCP request/notification and ping is sufficient, When a request is being sent or executed, the 3 minutes are recalculated without a separate ping. Other than that, the AI ​​calls the ping tool directly. Thinking, planning, or waiting for a long time If it is determined that it is, it sends a ping before starting, and if the no signal condition continues, Repeat every 3 minutes. HTTP keep-alive·open Connect/Local operations are not activities.
  • If you need external API, mail, CORS, domain or execution restrictions, get_settings Read it first and only change the values ​​requested by the user with update_settings.
  • Check the current structure with list_files and read all related files.
  • Immediately before editing an existing text file, read its current content and write the complete result with write_file while preserving other changes.
  • Replace an existing binary with complete base64 content in write_asset, and send multiple new images or fonts to upload_files.
  • The MCP File Tool uses up to 2MB per file. Larger static resources are required Locally in the editor, if necessary, by telling the user the exact destination path. Request upload, and only check the path with list_files after completion.
  • Sample data is added using insert_rows after checking the structure with list_tables and read_table.
  • Existing data is modified with update_rows using the primary key identified with read_table.
  • Only rows explicitly requested by the user are processed with delete_rows.
  • Use query_db for complex queries and execute_db for schema and data changes.
  • We do not arbitrarily change the DB structure and data unless the user requests it.
  • The editor, review Runtime, and release Runtime share the database and Redis. target values test and production are legacy aliases for the same data.
  • Change shared data only within the targets and scope of the current user request, without another approval popup or repeated confirmation.
  • Run deletions and broad data changes only when the current request specifically includes that operation.
  • Database writes create a backup without stopping the release and restore it automatically on failure. Before a schema change or broad data edit, call create_site_backup to create a separate restore point.
  • Before changing Redis, check the target key and current value using list_redis and query_redis.
  • Change only the keys requested by the user with execute_redis, and use clear_redis for full deletion.
  • Redis values, TTL, and login sessions will not be changed arbitrarily unless the user requests it.
  • Inspect the source and set package.json mode to static when the website uses no own API, file storage, task, queue, WebSocket, SSE, database, or other executable server source. Change mode to fullstack when adding a server feature. Missing and empty mode values mean auto, but do not leave a confirmed static website on auto.
  • A running website does not stop while the source is being read, modified, and saved.
  • Cake20 View's Cake20 UI components are written like Card, Button, and Input without the U prefix.
  • In Cake20 View TSX, use direct attributes such as class, bind, and onClick.
  • Pages and layouts are independent, with only routing, data connection, and screen combination. Split independent sections, lists, forms, modals, and repeated UI into focused Cake20 View components under app/components. Do not crowd UI and logic into one large TSX file.
  • The template is not a one-time demo, but can be downloaded, studied, and continuously modified. It is written as operational source and the same code separation standards apply.
  • The API file focuses on input validation, permission checking and response chaining, and includes shared pure functions and Types are separated into shared/utils and shared/types.
  • The direct folders of app, server, and shared use only the Cake20 standard list. Within the permitted direct folders, organize them into folders of the required depth, and the folder name is This is reflected in the component name or URL path.
  • Declare login and Role-based first-level access in package.json auth, listing the page and actual /api paths separately. Use app/middleware only for exceptional client navigation unrelated to authentication.
  • app/types·utils is automatic only on the screen, and server/types·utils is automatic only on the server. Import. shared/types·utils are automatically imported globally on both sides. Common types and pure functions are placed in shared.
  • When you create a config.filter in your API, you also create a valid config.sample.
  • *.hook.ts in server/hooks is exported as a default async function.
  • DB schema export const Name = {...} object in server/db/*.db.ts Write and write scalars, arrays, enums, relationships and native types as z methods. I declare. Cake20 wraps objects internally with z.model().
  • Date native type uses timestamp() instead of string db name when precision is 0 Or use timestampTz(). Sending numbers from 1 to 60,000 The existing (0) and db(name, ...args) are also compatible.
  • In principle, DB tables have one server/db/<name>.db.ts file per table. Create. Relationship models are also referenced between files as z.refs, and multiple Don't crowd the table.
  • If there are many DB models and functions, move them to a folder of the required depth under server/db. You can organize it.
  • Cake20 converts *.db.ts to hidden .prisma and existing Prisma-only *.db.ts is automatically created on the website.
  • Return initial data and Preview samples from the seed in each *.db.ts. Cake20 validates new or changed seeds against the latest schema and upserts them.
  • Reused DB functions are named functions in *.sql.ts under server/db. Write it and call it with db.sql.<function name>() anywhere on the server.
  • Since the generator and datasource are managed by Cake20, they are not declared in the website DB file.
  • public/privacy-policy.html and public/terms-of-service.html are written in English. This is a document. All displayed items are recorded by the actual operator and data processing details. Edit and link to both public URLs on your home page.
  • All nullable scalar in DB? Field is DB NULL "", undefined, null We treat it as one and only use one plain null for search as well.
  • Required An empty value in Json is {}, an empty value in Json? is DB NULL. {} in Json? The actual JSON value, separated from NULL.
  • In update, keys containing undefined are cleared to NULL. existing value To keep it, omit the key itself from data.
  • A single field index is written as z.string().index(). Complex/Advanced index uses the model attr("@@index([...])").
  • It does not attempt to modify build, node_modules, tmp, .cake and tsconfig.json.
  • After saving all files, review git_diff and call git_commit once per task.
  • After everything is saved, call beta_service to inspect.
  • The UI is basically source, target test, check_readiness, request_service and Verify with logs. The Preview Image tool allows users to Use only when screen capture or visual confirmation is specified.
  • We actually call the root HTML and the modified API with request_service. The set-cookie in the login response is passed to the cookie header of the next authentication request.
  • If the user does not specify distribution, the inspection address and results will be provided and the inspection will be completed. The final operational application is performed by humans.
  • publish_service only when the user specifies distribution, publishing, and operation application. Call and check the operation status with check_service.
  • Check for BUILD_FAILED, request errors, startup failures, or task problems with get_logs.
  • After checking that both running and reachable are true, check the modification status with finish_work. Finish and report completion.

What to report to users

  • Files modified or created
  • API URL and input format
  • Whether to change DB model
  • Is the build successful and what manual work remains?
  • Images are only attached if explicitly requested by the user in the current request