Fix and improve your app

Once your app is live, ask your agent to check it for problems, read what people said, and ship the fix, all in one pass.

Check for problems

Ask your agent to open the app. Every get_app call attaches a summary of what broke since the current revision was published: runtime errors, CSP violations (the browser blocking something the app tried to load), mismatches between the app’s interface and its backend, failed API calls, app load errors, and external image failures, each with a count and a recent example. If nothing broke, the summary doesn’t show up at all.

External image failures remain visible to the agent even when the app catches the failed load and shows its own fallback. Use the reported provider status and recovery suggestion to choose a working source or a permitted uploaded copy. A placeholder does not prove the image was repaired.

That summary only covers the current revision. The full log goes back across every revision.

When someone using a shared app hits a failure, the widget shows you a notification with a Fix with agent button. It copies a prompt for your agent with a private reference to the problem. Paste it within 10 minutes; after that the reference expires and you click the button again. An agent connected over MCP resolves the reference with resolve_handoff; a CLI agent uses charming api request get-widget-runtime-issue-handoff. Either way the agent gets the failing action, path, and the app’s error message, and only your account can read them.

Read what people said

People using the app can send a bug report or a suggestion from a button Charming puts in the app’s toolbar, no code required on your end. Ask your agent to check an app’s feedback and it lists what people said, newest first. See Feedback for how the button works and what a submission looks like.

Ship the fix

Once your agent knows what’s broken, from the runtime summary, the feedback, or both, ask it to fix the app. It calls update_app with either full replacement source or a small set of exact-string edits; the existing contract publishes synchronously. With the ESM contract, the tool returns an accepted build. Poll get_app_build until published, then call get_app to verify the fix. The last working app stays active while the desired source builds. Whatever the app has stored survives the update: only the code changes, not the data. See Data storage for what “survives” covers and How Charming works for the full build-and-update cycle.

Technical

For an existing-contract app, the core calls are: get_app for the runtime summary, list_feedback for what people said, and update_app to ship the fix. None of them needs the app’s activity log to run the loop day to day; that log is there for when the summary isn’t enough.

Copy this prompt for your agent

Check my Charming app for problems and fix what you find. Read
https://charm.ing/docs/guides/fix-and-improve-your-app.md first. Open
the app, review any runtime issues and feedback attached to it, and
ship a fix for anything actionable. Ask me before making a change
that isn't obvious from the issues or feedback text.

How an agent performs this job

get_app returns current-revision issues when present and names the CLI command for the full activity timeline.

resolve_handoff turns a pasted Fix with agent reference into the failing operation, path, and error message. Only the app owner’s account can resolve it.

list_feedback reads user and agent feedback. See Feedback for the workflow.

update_app accepts full source or exact edits. Update the description when app behavior changes.

Read the activity timeline with the CLI

Use a personal access token for a user who can manage the app:

charming api request get-app-activity-timeline --param appId=APP_ID --param limit=50

This calls GET /api/v1/apps/{appId}/activity for published versions, renders/runs, API-call outcomes, sharing changes, and feedback. Its response includes items, hasMore, and retention. To fetch older entries when hasMore is true, pass both --param before=OLDEST_TS and --param beforeId=OLDEST_ID from the oldest returned item. Optional kinds and since filters narrow the results.

charming api request get-app-activity --param id=APP_ID remains the separate durable runtime-failure log at GET /app/{id}/activity, with its existing {ok,value:{items,retention}} response.

The contract

The generated MCP reference and REST API reference define schemas, filters, and auth errors.