Summary
LoginWindow does sync-token sign-in, register and forgot-password. Twenty-three /api/auth/* operations are unimplemented — most are OAuth provider legs (covered in the Cross-posting epic), but several core flows are missing and some are genuinely cookie-only.
Unimplemented core flows
| Method |
Path |
Auth reality |
POST |
/api/auth/reset-password |
bearer/cookie per spec |
POST |
/api/auth/verify-email |
bearer/cookie per spec |
POST |
/api/auth/verify-email-change |
bearer/cookie per spec |
POST |
/api/auth/undo-email-change |
bearer/cookie per spec |
POST |
/api/auth/logout |
bearer/cookie per spec |
POST |
/api/auth/login |
cookie-session login — not this client's path |
GET |
/api/auth/accounts |
cookieAuth only |
POST |
/api/auth/switch |
cookieAuth only |
POST |
/api/auth/remove-account |
cookieAuth only |
POST |
/api/auth/send-verification-email |
cookieAuth only |
Live verification (2026-09-15)
GET /api/auth/accounts -> 401 {"error":"Unauthorized","code":"unauthorized"}
Confirms the cookie-only group. A bearer-token client structurally cannot obtain a cookie session, so multi-account switching is auth-model-blocked — the correct outcome is to document it, not to build a failing button.
Repo conventions to follow
- Service: one
partial class InterlinedApiClient file per domain in InterlinedList/Services/.
- Wire types in
InterlinedList/Models/ matching real API JSON.
- ViewModel per view in
InterlinedList/ViewModels/ (CommunityToolkit.Mvvm ObservableObject + [RelayCommand]).
- View is a self-contained
UserControl in InterlinedList/Views/ that news up its own VM from AppServices.Session.
- Strata tokens only — no colors/fonts/radii outside
Resources/Palette.xaml + Theme.*.xaml.
- Read-after-write for any mutating endpoint whose response envelope has not been live-verified.
Summary
LoginWindowdoes sync-token sign-in, register and forgot-password. Twenty-three/api/auth/*operations are unimplemented — most are OAuth provider legs (covered in the Cross-posting epic), but several core flows are missing and some are genuinely cookie-only.Unimplemented core flows
POST/api/auth/reset-passwordPOST/api/auth/verify-emailPOST/api/auth/verify-email-changePOST/api/auth/undo-email-changePOST/api/auth/logoutPOST/api/auth/loginGET/api/auth/accountscookieAuthonlyPOST/api/auth/switchcookieAuthonlyPOST/api/auth/remove-accountcookieAuthonlyPOST/api/auth/send-verification-emailcookieAuthonlyLive verification (2026-09-15)
Confirms the cookie-only group. A bearer-token client structurally cannot obtain a cookie session, so multi-account switching is auth-model-blocked — the correct outcome is to document it, not to build a failing button.
Repo conventions to follow
partial class InterlinedApiClientfile per domain inInterlinedList/Services/.InterlinedList/Models/matching real API JSON.InterlinedList/ViewModels/(CommunityToolkit.MvvmObservableObject+[RelayCommand]).UserControlinInterlinedList/Views/that news up its own VM fromAppServices.Session.Resources/Palette.xaml+Theme.*.xaml.