bermudalamb/redefined-designs
1
0
Fork 0
Code Issues 2 Pull Requests 1 Actions Packages Projects 3 Releases Wiki Activity

Initial Build UI issues and clean-up #31

New Issue
Closed
opened 2026-08-17 16:47:55 -05:00 by bermudalamb · 1 comment
bermudalamb commented 2026-08-17 16:47:55 -05:00
Owner
Copy Link
Copy Source
  • The customer should have a forgot password option on the login page.
  • They customer should be able to reset their password through round trip email verification.
  • The admin should have the discretion to disable a customer's account.
  • The customer should also be able to favorite/unfavorite an item. It the item is sold to another customer, and the customer has opted in for emails, they should receive an email notification that the item is no longer available. If they're not opted in, they should be offered the option to opt-in and the reason why we're asking them, to be notified if the item is sold.
  • The customer should be able to filter on their favorited items.
  • I would like to support passkeys for customer login.
- The customer should have a forgot password option on the login page. - They customer should be able to reset their password through round trip email verification. - The admin should have the discretion to disable a customer's account. - The customer should also be able to favorite/unfavorite an item. It the item is sold to another customer, and the customer has opted in for emails, they should receive an email notification that the item is no longer available. If they're not opted in, they should be offered the option to opt-in and the reason why we're asking them, to be notified if the item is sold. - The customer should be able to filter on their favorited items. - I would like to support passkeys for customer login.
bermudalamb self-assigned this 2026-08-17 17:00:36 -05:00
bermudalamb added this to the Initial Build project 2026-08-17 17:00:50 -05:00
bermudalamb moved this to In Progress in Initial Build on 2026-08-17 17:01:10 -05:00
bermudalamb commented 2026-08-17 17:10:42 -05:00
Author
Owner
Copy Link
Copy Source

Decomposed into five issues

This issue described six features rather than a set of fixes, and one of them is a project in its own right. Speccing them as a single unit would have produced one long-lived branch mixing a new auth path, a notification system, and a WebAuthn integration — hard to review, hard to QA, and impossible to roll back a single piece of.

Treating this as the tracking issue:

Issue Covers Size Depends on
#32 — Password reset via email round-trip items 1, 2 Small–medium —
#33 — Admin: disable a customer account item 3 Small —
#34 — Favorites, with notification when a favorite sells item 4 Medium–large —
#35 — Filter the storefront by favorited items item 5 Small #34
#36 — Passkey (WebAuthn) login item 6 Large #32, #33

Order

#32 → #33 → #34 → #35 → #36.

#33 defines a rule — a disabled account cannot authenticate — that #32, #34 and #36 all have to honor, so it lands early enough to be written once rather than retrofitted three times. #36 is last because it depends on account recovery existing and carries the most risk.

What each already has going for it

  • #32 reuses customer_tokens, which already carries a kind discriminator (currently only verify_email), and the existing sendMail that degrades gracefully when SMTP is unconfigured. /verify-email already establishes the token-carrying page pattern.
  • #33 introduces the first disabled/suspended concept in the schema — there is nothing like it today. The substantive part is that it must invalidate existing sessions, not just block the login form.
  • #34 has a genuine consent question flagged on the issue: asking a customer to opt in specifically to hear about one item is arguably a different purpose from the existing marketing consent, and bundling them would undermine a consent record that is currently clean and well-timestamped.
  • #36 carries constraints worth knowing before it starts: the Relying Party ID is domain-bound, so passkeys registered in QA will never work in production — QA can prove the flow but not the credentials.

Each issue lists the design questions to resolve before implementation, so none of them starts from a blank page.

Starting on #32 now.

## Decomposed into five issues This issue described six features rather than a set of fixes, and one of them is a project in its own right. Speccing them as a single unit would have produced one long-lived branch mixing a new auth path, a notification system, and a WebAuthn integration — hard to review, hard to QA, and impossible to roll back a single piece of. Treating this as the tracking issue: | Issue | Covers | Size | Depends on | | --- | --- | --- | --- | | #32 — Password reset via email round-trip | items 1, 2 | Small–medium | — | | #33 — Admin: disable a customer account | item 3 | Small | — | | #34 — Favorites, with notification when a favorite sells | item 4 | Medium–large | — | | #35 — Filter the storefront by favorited items | item 5 | Small | #34 | | #36 — Passkey (WebAuthn) login | item 6 | Large | #32, #33 | ### Order **#32 → #33 → #34 → #35 → #36.** #33 defines a rule — a disabled account cannot authenticate — that #32, #34 and #36 all have to honor, so it lands early enough to be written once rather than retrofitted three times. #36 is last because it depends on account recovery existing and carries the most risk. ### What each already has going for it - **#32** reuses `customer_tokens`, which already carries a `kind` discriminator (currently only `verify_email`), and the existing `sendMail` that degrades gracefully when SMTP is unconfigured. `/verify-email` already establishes the token-carrying page pattern. - **#33** introduces the first disabled/suspended concept in the schema — there is nothing like it today. The substantive part is that it must invalidate *existing sessions*, not just block the login form. - **#34** has a genuine consent question flagged on the issue: asking a customer to opt in specifically to hear about one item is arguably a different purpose from the existing marketing consent, and bundling them would undermine a consent record that is currently clean and well-timestamped. - **#36** carries constraints worth knowing before it starts: the Relying Party ID is domain-bound, so passkeys registered in QA will never work in production — QA can prove the flow but not the credentials. Each issue lists the design questions to resolve before implementation, so none of them starts from a blank page. Starting on **#32** now.
bermudalamb removed their assignment 2026-08-17 17:22:09 -05:00
bermudalamb moved this to Ready for Review in Initial Build on 2026-08-17 18:56:18 -05:00
bermudalamb moved this to Released in Initial Build on 2026-08-19 10:41:53 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Initial Build
Released
Assignees
Clear assignees
calamb (Chelsea Lamb) bermudalamb (Thom Lamb)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: bermudalamb/redefined-designs#31