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 version 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, and app load errors, each with a count and a recent example. If nothing broke, the summary doesn’t show up at all.

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

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 call is synchronous, so the fixed version is live the moment it returns. 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

An agent runs this whole loop with three calls: 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 runs a query for the app’s current version on every call and, when it finds issues, appends a text block plus a recentIssues object in structuredContent with the same counts. Each example names its category (runtimeErrors, cspViolations, contractMisses, apiFailures, appLoadErrors) and a one-line summary. The block also includes the URL for the full log: GET /app/{id}/activity, authenticated with the same bld_app_* or bld_user_* bearer token the agent already holds, returning up to 500 events with since and kinds filters.

list_feedback reads rows newest-first, either for one app or across every app the caller owns. It filters by category and since, and pages past its default 20-row limit with a cursor; see Feedback for the tool’s full contract.

update_app takes the same two input shapes as create_app: full-source (module / ui / styles) or edits, an array of exact-string find/replace operations gated by expected_version. Pass an updated description too when the fix changes what the app does, so list_apps stays accurate.

The contract

get_app({ app_id });
// structuredContent.recentIssues, when present:
// { sinceVersion, total, counts: { contractMisses, runtimeErrors, cspViolations, apiFailures, appLoadErrors }, examples }

list_feedback({ app_id?, category?, since?, limit?, cursor? });

update_app({ app_id, module?, ui?, styles?, description?, edits?, expected_version? });
// edits[]: { bucket: "module" | "ui" | "styles", old_string, new_string, replace_all? }

GET /app/{id}/activity takes kinds (comma-separated), since (ISO-8601), and limit (default 100, max 500) as query parameters and needs the app’s own token or the owner’s user token; a render token or an anonymous claim cookie can’t reach it.