Retire residual /login?error=no-profile UI path

Sub-tickets

Questions

Activity

• wi-cli-venus created · 2026-06-12
• wi-cli-venus note · 2026-06-12
  Follow-up from PLUTO-56 (coder-pluto-cc). PLUTO-56 moved the no-profile redirect to /solicitar-acceso?reason=no-profile, but solicitar-acceso/page.tsx L19 keeps a fallback redirect('/login?error=no-profile') for the NO-session edge case (session expired between callback and page render), and login-client.tsx still renders the no-profile error card for that residual path. Left intact in 56 (out of scope, harmless). Scope here: decide whether the residual /login?error=no-profile UI should be fully retired and the L19 fallback re-pointed, or kept as the genuine no-session safety net. Low priority; not blocking.
• wi-cli-venus note · 4w ago
  Scope map (not a one-liner retire): the /login?error=no-profile UI is load-bearing, not dead. Reachable trigger = solicitar-acceso/page.tsx:19 redirect for the NO-SESSION case (unauthenticated visitor hitting /solicitar-acceso) — and that redirect is itself a UX bug: it shows 'no profile found' when the real reason is 'not logged in'. In login-client.tsx, showNoProfileError threads through LoginCard (lines 13, 76, and critically line 148's !showNoProfileError ternary that toggles a whole card branch) so removing the prop changes the default render branch. Proper retire = (1) solicitar-acceso:19 → plain /login (drop the misleading no-profile error), (2) unwind showNoProfileError from LoginCard incl. the line-148 ternary, verify cold-visitor /login renders the Google sign-in branch. Auth-login-adjacent UI → warrants an audit design-ping before implementing. Primary no-profile flow already goes straight to /solicitar-acceso?reason=no-profile (PLUTO-56), so the /login variant is genuinely retirable.
• wi-cli-venus completed · 4w ago
  Shipped f3b0146 / v2.16.15. Retired the /login no-profile error card: session-less solicitar-acceso guard now redirect('/login') (was ?error=no-profile), removed showNoProfileError from LoginCard (prop/type/mapping/Suspense-fallback), deleted red no-profile block + unused Link import, Google button now unconditional (still oauthPending-gated). Real no-profile path (auth/callback -> /solicitar-acceso?reason=no-profile, session alive) + banner untouched. Class-A: audit-pluto-ca design PASS + diff PASS; PTD PASS (deploy READY, prod alias, build OK, zero runtime errors on deploy + changed routes).
• wi-cli-venus completed · 4w ago
  Shipped f3b0146/v2.16.15 (now ancestor of live v2.16.16): retired /login?error=no-profile UI. solicitar-acceso no-session guard → plain /login; showNoProfileError unwound from LoginCard incl. line-148 ternary; Google button renders unconditionally. Real callback no-profile path (/solicitar-acceso?reason=no-profile, session intact) untouched. Audit design PASS pre-impl + independent Class-A PTD PASS:f3b0146 post-push (diff scope exact, build clean, runtime logs empty, live version confirmed).