---
phase: 08-social-sign-in
plan: 04
type: execute
wave: 4
depends_on:
  - 08-02
  - 08-03
files_modified:
  - backend/templates/auth_forms.go
  - backend/templates/auth_login.templ
  - backend/templates/auth_signup.templ
  - backend/templates/*_templ.go
  - backend/internal/web/handlers_auth.go
  - backend/internal/web/handlers_auth_test.go
  - backend/internal/web/ui/button.css
autonomous: true
requirements_addressed: [AUTH-08, AUTH-10, AUTH-13]
requirements:
  - AUTH-08
  - AUTH-10
  - AUTH-13

must_haves:
  truths:
    - "D-09: Google and Apple sign-in buttons appear on both login and signup pages."
    - "D-10: Missing provider config renders disabled not-configured provider buttons."
    - "D-11: Google and Apple have equal prominence wherever provider buttons are shown."
    - "D-12: Successful social sign-in redirects to `/`; UI does not add provider-specific welcome pages."
    - "AUTH-08: User can start Google sign-in from login/signup."
    - "AUTH-10: User can start Apple sign-in from login/signup."
    - "AUTH-13: Existing email/password forms and validation remain available and tested."
  artifacts:
    - path: "backend/templates/auth_login.templ"
      provides: "login provider entry points"
    - path: "backend/templates/auth_signup.templ"
      provides: "signup provider entry points"
    - path: "backend/internal/web/ui/button.css"
      provides: "neutral provider button styling"
---

## Phase Goal

Expose the Google and Apple start routes in the existing auth pages while preserving the current simple auth UI.

<objective>
Implement the UI contract for provider buttons:

1. Login and signup show equal Google/Apple provider entry points.
2. Missing provider config renders visible disabled buttons with exact not-configured copy.
3. Provider buttons do not submit the email/password forms.
4. Existing form validation and layout stay intact.
</objective>

<execution_context>
@/Users/arthur.belleville/Documents/perso/projects/xtablo-source/.codex/get-shit-done/workflows/execute-plan.md
</execution_context>

<context>
@/Users/arthur.belleville/Documents/perso/projects/xtablo-source/.planning/phases/08-social-sign-in/08-UI-SPEC.md
@/Users/arthur.belleville/Documents/perso/projects/xtablo-source/.planning/phases/08-social-sign-in/08-CONTEXT.md
@/Users/arthur.belleville/Documents/perso/projects/xtablo-source/.planning/phases/08-social-sign-in/08-PATTERNS.md
</context>

<tasks>

<task type="auto">
  <name>Task 1: Add provider button template data and neutral button pattern</name>
  <files>
    backend/templates/auth_forms.go
    backend/internal/web/handlers_auth.go
    backend/internal/web/ui/button.css
  </files>
  <read_first>
    - backend/templates/auth_forms.go
    - backend/internal/web/handlers_auth.go
    - backend/internal/web/ui/button.templ
    - backend/internal/web/ui/button.css
    - .planning/phases/08-social-sign-in/08-UI-SPEC.md
  </read_first>
  <action>
    Add template data for provider availability and provider start URLs. Use exact labels from `08-UI-SPEC.md`: `Continue with Google`, `Continue with Apple`, `Google sign-in not configured`, `Apple sign-in not configured`, and separator `or`. Provider buttons must be full width, at least 44px high, neutral outline, stacked with 8px gap, and not submit the email/password form. Enabled controls link to `/auth/google/start` and `/auth/apple/start`; disabled controls use native disabled button semantics or `aria-disabled="true"` with no actionable `href`.
  </action>
  <verify>
    <automated>cd /Users/arthur.belleville/Documents/perso/projects/xtablo-source/backend && go test ./internal/web -run 'Test.*Auth.*Provider.*(Configured|Disabled)' -count=1</automated>
  </verify>
  <acceptance_criteria>
    - Provider label constants or template output include `Continue with Google` and `Continue with Apple`.
    - Disabled template output includes `Google sign-in not configured` and `Apple sign-in not configured`.
    - Provider controls do not live inside a form submit button path.
    - CSS or classes establish a neutral outline provider button with minimum height 44px.
  </acceptance_criteria>
  <done>
    Auth handlers can render enabled or disabled provider button states.
  </done>
</task>

<task type="auto">
  <name>Task 2: Render provider buttons on login/signup and regenerate templ output</name>
  <files>
    backend/templates/auth_login.templ
    backend/templates/auth_signup.templ
    backend/templates/*_templ.go
    backend/internal/web/handlers_auth_test.go
  </files>
  <read_first>
    - backend/templates/auth_login.templ
    - backend/templates/auth_signup.templ
    - backend/templates/auth_forms.go
    - backend/internal/web/handlers_auth.go
    - backend/internal/web/handlers_auth_test.go
    - backend/justfile
  </read_first>
  <action>
    Insert the provider block below each auth page heading and above the existing email/password form. Keep the centered card, `w-full max-w-sm`, existing padding, form labels, and validation error rendering. Add a separator with left line, center text `or`, and right line. Regenerate templ output using the repo's established command.

    Add handler/template tests for: login page with both providers configured has links to `/auth/google/start` and `/auth/apple/start`; signup page has the same; missing Google config shows disabled Google copy; missing Apple config shows disabled Apple copy; existing email/password form fields still render.
  </action>
  <verify>
    <automated>cd /Users/arthur.belleville/Documents/perso/projects/xtablo-source/backend && go test ./internal/web -run 'Test.*(Login|Signup).*Provider' -count=1</automated>
  </verify>
  <acceptance_criteria>
    - `/login` rendered HTML contains `Continue with Google`, `Continue with Apple`, and `or`.
    - `/signup` rendered HTML contains `Continue with Google`, `Continue with Apple`, and `or`.
    - Configured providers render actionable links to `/auth/google/start` and `/auth/apple/start`.
    - Missing provider config renders disabled not-configured copy and no actionable start URL for that provider.
    - Existing login/signup email and password inputs still render.
  </acceptance_criteria>
  <done>
    Login and signup satisfy AUTH-08, AUTH-10, and the approved UI-SPEC.
  </done>
</task>

</tasks>

<threat_model>
| Threat ID | Severity | Component | Mitigation |
|-----------|----------|-----------|------------|
| T-08-14 | medium | Provider buttons | Enabled buttons use GET start routes only; disabled buttons have no actionable href |
| T-08-15 | low | UI error copy | UI never exposes raw OAuth errors, token values, claim names, or secret names |
| T-08-16 | low | Auth form regression | Provider controls do not submit the email/password form or bypass existing CSRF on local POSTs |
</threat_model>

<verification>
Run:

```
cd /Users/arthur.belleville/Documents/perso/projects/xtablo-source/backend && go test ./internal/web -run 'Test.*(Login|Signup|Provider)' -count=1
```
</verification>

<success_criteria>
1. Login and signup pages both show Google and Apple entry points.
2. Disabled provider states are visible when config is missing.
3. Existing email/password form behavior remains available and tested.
</success_criteria>

