Let's pretty up the login and sign up pages

[utricularian]

The Login and Sign Up page look pretty sad. The styling of the rest of the pages seem consistent, including buttons. Can we take a pass at the Signup and Login page to iterate on how it looks?

Clarified Requirements

Improve the appearance of the existing login and sign-up pages.

Scope

• Make presentation-only changes.
• Preserve authentication behavior, routes, fields, and copy.
• Apply the application’s existing dark-and-gold visual language.
• Use a constrained form layout, gold labels and buttons, and light input fields.
• Keep both pages polished and usable on mobile and desktop.
• Provide visible keyboard-focus and validation-error states.

Review Constraint

Run the application locally at http://localhost:8000 for visual review. Stop after implementation and local verification without creating a commit, pushing changes, or opening or updating a pull request.

Question Completion

Requirements are ready for Structure.

Structure

Work Areas

1. Shared authentication-page presentation

   • Give the existing login and sign-up pages a consistent, constrained layout that uses the application’s dark-and-gold visual language.
   • Keep the presentation cohesive with established header and profile-form styling.

2. Authentication form styling

   • Present the existing labels, light input fields, remember-me control, password guidance, submit buttons, and cross-page links as a coherent form system.
   • Use the application’s existing gold button and label treatment without changing form contents.

3. Interaction and feedback states

   • Provide clearly visible keyboard-focus treatment for every interactive control.
   • Present existing validation errors and authentication alerts prominently and accessibly.

4. Responsive presentation and verification

   • Ensure both pages remain polished and usable across mobile and desktop viewport sizes.
   • Preserve the existing request-level authentication coverage and make the result available for local visual review at http://localhost:8000.

Acceptance Criteria

• The login and sign-up pages use a consistent dark background, gold accents, constrained form width, gold labels and submit buttons, and light input fields.
• Each page remains readable and usable at mobile and desktop sizes without horizontal overflow, clipped content, or unusable controls.
• Keyboard focus is visibly apparent on inputs, the remember-me control, buttons, and links.
• Existing validation errors and authentication alerts remain semantically exposed and are visually distinct from normal form content.
• Existing authentication routes, fields, copy, autocomplete behavior, submissions, validation behavior, redirects, remember-me behavior, and login/sign-up navigation continue to work unchanged.
• The application can be run at http://localhost:8000 for user visual review.

Dependencies

• Existing Devise login and registration templates and the shared Devise error-message partial.
• Existing application stylesheet and established header/profile-form visual patterns.
• Existing authentication request coverage and the local development runtime.

Boundaries

• Changes are limited to presentation-layer markup and styling needed for the approved aesthetic and accessibility treatment.
• Do not change authentication controllers, models, routes, Devise configuration, persistence, validations, fields, or user-facing copy.
• Do not add new authentication features, flows, dependencies, or unrelated page redesigns.
• Stop after implementation and local verification for user critique; do not create a commit, push changes, or open or update a pull request without subsequent user approval.

Research

Current Authentication Presentation

• app/views/devise/sessions/new.html.erb and app/views/devise/registrations/new.html.erb both render inside a generic main.page-shell, but the stylesheet currently defines no .page-shell or authentication-specific rules.
• Both templates use Devise form_for helpers with unclassified wrapper elements and browser-default controls. The login form contains email, password, remember-me, and submit controls; the registration form contains email, password, password confirmation, preferred name, minimum-password guidance, and submit controls.
• The existing labels remain programmatically associated with their controls through Rails form helpers. Existing autofocus and autocomplete values are:
  • login email: email
  • login password: current-password
  • registration email: email
  • registration password and confirmation: new-password
  • preferred name: name
• Each page already links to the other authentication page using the canonical Devise route helper.
• Registration validation failures render through app/views/devise/shared/_error_messages.html.erb. The partial uses #error_explanation, a heading, a list of full messages, and role="alert", but it has no corresponding visual treatment.
• Failed login feedback is exposed through the application layout’s flash rendering. Alert flashes use role="alert", assertive live-region behavior, and the existing .site-notice.site-notice--alert presentation.

Established Visual and Interaction Patterns

• app/assets/stylesheets/application.css establishes the approved palette:
  • page background: #181818
  • primary light text and fields: #f5f1e8
  • gold accent: #e5b85b
  • gold hover accent: #f5d284
  • dark text on light or gold controls: #191714
  • alert accent: #f08a73
• The site header already provides the relevant gold button treatment, rounded corners, dark text, and a visible focus outline through .account-actions__button.
• The profile presentation provides the closest existing form vocabulary: constrained centered width, responsive padding, large fluid heading, uppercase gold labels, light fields with dark text, grid-based field spacing, gold submit treatment, gold links, and an alert-like error block.
• Game forms demonstrate an additional high-contrast :focus-visible pattern using layered rings. Existing focus treatments are scoped to their components; there is no global focus rule that automatically covers the authentication controls.
• The application layout loads the :app stylesheet collection through Propshaft and includes the viewport meta tag needed for responsive layouts.

Behavioral and Scope Constraints

• Authentication routes are provided by Devise for sessions and registrations. Registration uses Users::RegistrationsController solely to permit preferred_name and build the associated profile.
• User behavior depends on Devise database authentication, registration, remember-me, and validation modules. The configured failed-response status is 422 Unprocessable Entity, successful redirects use 303 See Other, and remember-me lasts one month.
• Presentation work must preserve field names, action URLs, methods, route helpers, CSRF behavior, autofocus, autocomplete values, remember-me submission, minimum-password guidance, validation rendering, flash rendering, and all existing user-facing copy.
• The shared header remains in normal document flow and is approximately 4.75rem high. Authentication-page minimum-height or vertical layout calculations need to account for it.
• The fixed flash notice can occupy the lower-right viewport area. Responsive presentation must avoid making important authentication controls or feedback effectively unreachable or obscured on small screens.
• The current worktree contains a pre-existing untracked config/credentials/ directory. Implementation must not alter, remove, stage, or otherwise absorb it into this work.

Validation Evidence and Gaps

• spec/requests/local_authentication_spec.rb currently covers page availability and core copy, registration success, normalized email, profile creation, invalid and duplicate registration, remember-me login, failed login, and logout.
• spec/requests/authentication_routes_spec.rb covers the expected session and registration routes and confirms password-reset and OAuth routes remain absent.
• Existing profile and site-header request specs show repository precedent for asserting semantic structure and component classes directly from rendered HTML and stylesheet source.
• The repository has Selenium/Capybara system-test support with headless Chrome and a default 1280x900 browser size, but it has no authentication-specific browser or responsive-layout coverage.
• Validation can combine:
  • focused request coverage for preserved form semantics, fields, attributes, actions, links, error roles, and unchanged authentication behavior;
  • browser-level checks for keyboard focus visibility and usable layout at representative desktop and narrow mobile viewports;
  • invalid registration and failed-login checks to exercise both inline validation errors and flash alerts;
  • local visual review of login, sign-up, focused controls, invalid states, and responsive widths at http://localhost:8000.
• bin/dev defaults to port 8000 and is the repository entrypoint that matches the requested review environment. Procfile.dev uses port 3000, so it should not be treated as evidence that the requested URL is unavailable.

Risks and Unknowns

• Reusing broad profile selectors directly could unintentionally couple authentication styling to profile behavior; authentication markup needs a scope that prevents unrelated page changes.
• Native checkbox styling varies by browser and operating system. Any presentation treatment must retain an operable native control and a visible keyboard-focus state.
• Light form controls within a document declaring color-scheme: dark need explicit foreground, background, border, placeholder, autofill, and focus behavior where browser defaults could reduce contrast.
• Error summaries can grow with several validation messages, so the constrained layout must allow wrapping and vertical expansion without overflow.
• No consequential product ambiguity remains. Exact spacing, width, and decorative treatment can be evaluated during implementation against the approved palette, established components, responsive acceptance criteria, and the required user visual-review checkpoint without changing behavior or copy.

Plan

Implementation Approach

• Add authentication-specific presentation classes to the existing Devise login and registration templates and shared validation-error partial. Preserve every form helper, field, route, method, label, copy string, autofocus and autocomplete value, remember-me control, and error or flash semantic already identified in Research.
• Style those scoped classes in the existing application stylesheet using the established dark background, light fields, gold labels, buttons, and links, constrained centered layout, and existing alert palette. Include explicit hover, keyboard-focus, autofill, checkbox, wrapping, and narrow-viewport behavior without coupling the rules to profile or unrelated pages.
• Extend focused authentication coverage before implementation so the rendered component structure and preserved form semantics are enforced. Add browser-level coverage for representative desktop and mobile layouts, visible keyboard focus, registration validation errors, and failed-login alerts where those outcomes can be asserted reliably.
• Run focused authentication and route specs, relevant browser coverage, and the broader test suite needed for regression confidence. Start the development server through bin/dev on http://localhost:8000, verify login and sign-up at desktop and mobile widths including focus and error states, then stop for user critique with the worktree changes uncommitted.

Implementation Tasks

1. Add scoped authentication form structure and semantic coverage. Introduce authentication-specific classes in the login, registration, and shared Devise error templates, and add focused request specifications that lock in the component structure while proving routes, fields, labels, copy, form actions, autocomplete behavior, remember-me behavior, navigation, and alert semantics remain unchanged.
2. Style and visually verify the responsive authentication experience. Add scoped dark-and-gold authentication styles and browser coverage for desktop, mobile, focus, validation-error, failed-login, checkbox, autofill, wrapping, and overflow behavior; run the relevant regression suite and make the finished pages available at http://localhost:8000 for user review without committing, pushing, or creating or updating a pull request.

Validation

• RBENV_VERSION=4.0.5 rbenv exec bundle exec rspec spec/requests/local_authentication_spec.rb spec/requests/authentication_routes_spec.rb
• Run the authentication-specific system specs added by this work at representative desktop and narrow mobile viewport sizes.
• Run any broader affected request or system coverage needed to confirm shared header, profile presentation, routing, and authentication behavior remain unchanged.
• Run git diff --check.
• Inspect login, sign-up, keyboard-focus, invalid-registration, and failed-login states locally at http://localhost:8000 before handing the uncommitted worktree to the user for critique.

Delivery Constraint

• Stop after implementation and local verification. Do not create a commit, push changes, or open or update a pull request unless the user subsequently approves the visual result and explicitly authorizes those actions.
• Do not alter or stage the pre-existing untracked config/credentials/ directory.

[fairybladderwort]

AUTO RPI CHECKPOINT

• Phase: Implementation
• Status: Ready for Review
• Implementation tasks: Add scoped authentication form structure and semantic coverage #174, Style and visually verify the responsive authentication experience #175 complete
• Shared PR: Pretty up login and sign up pages: Feature #173 #176
• Blocked by: Nothing
• Updated: 2026-08-27