trustlisted

Review permission/onboarding/interruption timing, destructive-action safety, and trust signals for the evidence provided. ## Procedure 1. Check whether permissions are requested in context (when the user invokes the feature that needs them) rather than at startup — see `references/mobile.md`'s onboarding/permission rules, and check that denial degrades gracefully rather than blocking the app. 2. Check destructive actions: routine reversible ones should offer undo rather than a confirmation dialog; irreversible or high-cost ones need a specific confirmation naming the action and consequence, not a generic Yes/No — see `references/core.md`'s destructive-action rules and "Folk-rule guards" (the "always confirm delete" myth). 3. For high-stakes or security-sensitive actions specifically, check whether deliberate brief friction/staging is used (or missing) as a trust signal — see `references/core.md`'s E08, and apply it narrowly in both directions (not a license for friction on routine actions; missing friction on genuinely high-stakes actions is a finding). 4. Check notifications for honesty: marketing content must not be framed as urgent/system-critical, and users should be able to manage notification categories when notifications matter to the product — see `references/mobile.md`'s interruption rules. 5. If the evidence cannot show actual permission-flow behavior or notification content (e.g. a single static screenshot), mark those findings `NOT ASSESSABLE` — see `../../share