No Alert Use Toast

All user-facing notifications in views/admin/ must go through the canonical showToast(message, type) helper, never browser alert()

Source memory file: feedback_no_alert_use_toast.md · Category: Feedback / working-preference This is a verbatim dump of Claude's persistent memory for the Octopus project. Rendered inside a code block so nothing is altered.

---
name: No alert() in admin UI — use showToast
description: All user-facing notifications in views/admin/ must go through the canonical showToast(message, type) helper, never browser alert()
type: feedback
originSessionId: 2130eb26-f4a9-405f-a19f-b1a1fa5a2f96
---
Never use browser `alert()` in admin views (`views/admin/**/*.jet`). All user-facing notifications go through the canonical toast helper:

```js
showToast(message, type)  // type: 'success' | 'error' | 'danger' | 'warning' | 'info'
```

The canonical `showToast(message, type = 'success')` is defined globally in [views/layouts/admin/base.jet](views/layouts/admin/base.jet) and is available on every admin page. Some pages keep a local `showToast` (with the same signature) when they have static toast DOM — that's fine; signature must match.

**Why:** `alert()` is jarring, blocks the UI, breaks button-restoration timing, and looks unprofessional. The codebase was unified in this pass — re-introducing `alert()` would split the convention again. There were also latent bugs from `const alert = ...` shadowing the global so an in-scope `alert(...)` call would throw.

**How to apply:**
- For new admin views or edits: call `showToast(msg, 'error')` (or `'success'` / `'warning'`) instead of `alert(msg)`.
- Signature is **always** `(message, type)` — never `(type, message)`. Don't bring back the old type-first form.
- `confirm()` is fine — it's a modal dialog, not a notification.
- The rule is admin views specifically; if you ever touch other Jet templates (client/, etc.), check what helper they use before assuming.