Plan ready under assumption: make avatar mandatory in onboarding and automatically compress avatars to stay below the profile-size limit.

• Read-only sandbox blocked actual edits.

• request_user_input UI unavailable, so please confirm verbally if avatar should remain optional instead.

• direnv export zsh attempted per repo rules but failed in read-only sandbox because mise tried to write trust/temp state.

1. Question 1: Should avatar upload become mandatory in onboarding, or should it stay optional but auto-compress when provided?

   • Recommended answer: make it mandatory during onboarding, with auto-compression before upload/storage. Reason: your issue says “users must add an image to their avatar,” and the network concern is size, not optionality.

   • Please answer one of:

     1. Mandatory + compress — recommended.

     2. Optional + compress — keep current skip behavior.

     3. Mandatory only — require avatar but don’t add compression beyond current limits.

2. Question 2 : What should the “easy fallback” be when they don’t have an image?

   Recommended answer: Generate a simple avatar from their display name: colored gradient/background + initials, saved as a small PNG/JPEG blob and treated exactly like an uploaded avatar.

   Why this is best:

   • zero extra user work,

   • satisfies “must add an avatar,”

   • deterministic/lightweight,

   • avoids shipping a library or asset pack,

   • works offline,

   • keeps profile objects small.

   Options:

   1. Generate initials avatar — recommended.

   2. Choose from preset icons/colors — more UI, more decisions.

   3. Use a generic default image — easiest, but many users look identical.

   4. Camera/selfie option — useful, but platform permissions/complexity.

3. Question 3 : What max size should the stored avatar target be?

   Current concern: profile data replicates many times, and there’s a 1 MiB limit. We should not aim for “just under 1 MiB”; that’s still heavy for replication.

   Recommended answer: target ≤100 KiB, hard fail only if optimizer cannot get it under 1 MiB.

   Why:

   • 512×512 PNG can be large for photos.

   • 256×256 or 320×320 JPEG/WebP is visually fine for avatars.

   • 100 KiB is much friendlier for replicated profiles.

   • The 1 MiB limit remains a safety ceiling, not the goal.

   Options:

   1. Target ≤100 KiB, hard max 1 MiB — recommended.

   2. Target ≤250 KiB, hard max 1 MiB — safer quality.

   3. Only enforce ≤1 MiB — simplest but misses “very light object.”

   4. Smaller target, e.g. ≤50 KiB — leanest, more quality risk.

4. Question 4 : What dimensions/format should optimized avatars use?

   Recommended answer: 256×256 WebP when supported, fallback JPEG, square-cropped center.

   Why:

   • 256px is enough for avatar UI and much lighter than 512px.

   • WebP usually hits ≤100 KiB easily.

   • JPEG fallback keeps compatibility if canvas WebP encode fails.

   • Square crop avoids layout surprises.

   One caveat: if profiles are consumed by environments that may not support WebP, JPEG-only is safer.

   Options:

   1. 256×256 WebP, JPEG fallback — recommended.

   2. 256×256 JPEG only — maximum compatibility.

   3. 512×512 WebP/JPEG — higher quality, heavier.

   4. Keep original dimensions, compress only — worse for replication.