Kandev Canvas Authoring

Kandev canvas authoring

Use one read_canvas_authoring_skill_kandev call without path when you need the authoring contract. That response is the complete core bundle. It includes this workflow, the manifest and browser protocol summary, appearance rules, the minimal scaffold, and the exact supporting-file inventory. Do not read the core bundle again during the same authoring task.

Required workflow

1. Call create_canvas_kandev with a short title and an application summary. It creates an inactive task canvas and returns its source directory, manifest scaffold, initial permission policy, and exact scaffold inventory.
2. Use native file tools in that returned directory. The initial files are manifest.yaml, index.html, appearance.js, script.js, and styles.css. Replace or extend them in the same directory.
3. Keep every source path relative to the returned directory. Do not write outside it. Bundle executable dependencies. Node, a package manager, and a network build step are not available at runtime.
4. Run local checks, then call publish_canvas_kandev with the returned canvas ID and source path. Read validation diagnostics and correct rejected source before publishing again.

The first valid release of a new owner-authorized task canvas uses the returned initial permission policy. It can activate without a second approval for its declared supported permissions. Kandev data access is limited to the current workspace, while the canvas remains placed in its creating task. Imported packages and later permission increases need human review. Promotion changes workspace navigation. Do not add a trust flag to the manifest, and do not request permissions outside the policy.

Core application contract

• Include <meta name="viewport" content="width=device-width, initial-scale=1">.
• Use relative ./_kandev/v1 paths for Kandev data, state, actions, and events.
• Treat Kandev domain data as the source of truth. Derive filters and summaries in memory instead of storing a second copy of domain records.
• Store only small application-specific shared values in instance state. Keep temporary input in memory and use conditional revisions for writes.
• The canvas runs in a trusted same-origin iframe. Treat its source as trusted user-session code: it can use same-origin browser storage and cookies and can access the host DOM. It has the viewing user's ordinary API authority.
• Keep Kandev protocol requests relative and do not copy capability URLs or tokens into source, URLs, query strings, logs, or client state. Same-origin cookies do not replace capability validation or the grants on protocol routes.
• Render loading, empty, error, and retry states. Keep destructive actions explicit and explain their result.
• Use accessible labels, keyboard operation, visible focus, and touch targets.

Kandev injects a reserved startup bootstrap into the entry document before authored scripts. It reports early document errors and checks the relative context route after document load. The host reveals the frame only after a versioned acknowledgement for the current attempt. A missing acknowledgement or context failure becomes recoverable after 15 seconds. Keep the entry valid HTML and render loading, empty, error, and retry states in the app.

Minimal manifest

Use the returned manifest_scaffold as the starting point. New manifests use api_version: 2, one lowercase web-app key, a package-relative entry, and at least one task-canvas or workspace-canvas placement. Declare only the api_read, api_write, events, state, and network_origins permissions that the application needs. The owner-authorized first release can receive only its declared supported permissions, with Kandev data limited to the current workspace. The entry and all relative assets must be in the published package.