Report bugs and request features

Two commands, typed directly in chat

/bug followed by a description files a bug report. /request followed by a description files a feature request. Common variations — /feedback, /issue for the first, /feature, /idea for the second — are recognized the same way. Both are caught before your message ever reaches Charyl’s reasoning, so filing a report doesn’t use any of her thinking budget — deliberately, since you’re most likely to want to report something right when things have already gone wrong.

A bare /bug with nothing after it isn’t an error. She’ll ask what happened and use your next message as the report.

What she shows you before anything sends

Before a report leaves your home, Charyl opens a consent card showing exactly what’s about to go out. You have to tap Send yourself.

Included: the text of your report, which surface you’re using (web or mobile), your last several chat turns for context, a short slice of recent activity, and basic version information. Left out, always: raw system logs, any API keys or tokens, and any attached images or PDFs. Anything that looks like a key or a token is stripped out automatically before the card even renders, so what you see is genuinely what would be sent.

The card reflects your conversation as it stood when you started typing the report, not whatever you’ve said since — so it’s worth reading it before you tap Send rather than assuming it caught something you mentioned afterward.

A quick example

Typing /bug the porch light card on my dashboard shows the wrong color opens the consent card immediately — no need to explain what a dashboard or a porch light card is beforehand; that context comes from the report itself and from what’s already in the conversation.

What happens depends on your connection

• If your home is connected, the report sends and you get a confirmation.
• If Charyl Cloud is temporarily unreachable, the report is queued locally and retried automatically over the following hours, up to about a week.
• If your box was never paired to Charyl Cloud at all, she won’t attempt an upload. Instead she offers to copy the report to your clipboard or save it as a file, so you can send it however works for you.
• If your subscription has lapsed, reporting still goes through normally — feedback is never held back by billing.

Crashes are reported automatically, separately

Unrelated to /bug and /request: if something crashes outright — an error in the app itself rather than something Charyl said or did — that’s captured and reported automatically, without you needing to type anything. Those reports never include your own content, only what’s needed to understand what broke.

When to use which

Use /bug when something doesn’t work the way it’s supposed to — an error, a proposal that never appeared, a page that didn’t load right. Use /request when everything’s working as designed, but you’d like it to work differently — a feature you wish existed, or a change to how something behaves.

If you’re not sure which one applies, either one gets read; /bug is the safer default when in doubt.