Background

~/.crit.config.json currently exposes five overlapping author/identity fields:

• author — manually-set display name; falls back to git config user.name. Used as the local "Author" stamp on comments when not authenticated, and as the author_display_name fallback in share payloads.
• auth_user_name — display name from the OAuth provider, populated by crit auth login.
• auth_user_email — email from OAuth.
• auth_user_id — verified server-side user UUID (just added in feat: send + cache verified author identity on share #371).
• auth_token — bearer token.

The split is conceptually defensible (manual override vs. verified identity from OAuth), but in practice it surprises users — they see "their name" in two unrelated places, and the precedence rules between author and auth_user_name are non-obvious.

What to decide

• Which field wins for local comment display when both are present?
• Should author be deprecated (or auto-populated from auth_user_name) once the user is authenticated?
• Should the settings panel surface them as one "name" field with a "verified" indicator instead of exposing the raw config keys?
• Migration path: existing users have author set manually; we don't want to silently overwrite it.

Why now

Surfaced while debugging a prod bug (#371 follow-up) where stale auth_user_id from a previous account survived a re-login because crit auth login didn't atomically rewrite the identity fields. Investigation made it clear how many "who is this user" fields we're juggling.