Andrea redesign 1: account readiness audit

Date: 2026-09-24 (America/Bogota). Branch: jm/andrea-redesign-1.

Read-only source and local-prerequisite audit for Step 5. No code, customer records, production services, or email destinations were changed or used. Account and verification journeys have not been exercised against a running Medusa instance or mail provider.

Readiness summary

The repository contains real Medusa customer registration, password login, logout, authenticated customer retrieval/update, address management, order views, and cart transfer. This is implemented application code, not the old portfolio simulator. It is not verified as an operational customer journey: there are no account/auth tests in apps/storefront/tests, the local commerce services were not running during this audit, and no configured email/notification provider was found in apps/backend/medusa-config.ts or Compose. The account UI is still mostly English starter-template copy, even on Spanish public routes.

Capability	Code evidence	Audit state
Registration and password login	apps/storefront/src/lib/data/customer.ts calls Medusa auth.register and auth.login; modules/account/components/register and login render the forms. Registration keeps name/phone in a pending cookie, then creates the customer record after successful authentication.	Implemented; runtime, backend policy and persistence untested.
Email verification	Customer actions request and confirm a Medusa email verification token. verify-account consumes the query token in a client effect. Login requests verification when the backend requires it; request failures are swallowed.	Code path exists; backend policy, link generation and delivery unverified. A displayed “we sent” message is not evidence of delivery.
Session	_medusa_jwt is an HttpOnly, SameSite=Strict, seven-day cookie and is Secure in production. Authenticated customer reads use it.	Cookie handling is implemented; login persistence, expiry and logout not runtime tested.
Logout	signout logs out, clears auth and cart cookies/cache, then redirects to /{countryCode}/account.	Implemented; redirect/cookie behavior not runtime tested.
Cart transfer	Successful login calls Medusa transferCart for the cart ID in _medusa_cart_id and revalidates the cart cache. A mismatch banner also offers transfer for signed-in customers.	Implemented; guest-to-customer continuity and failed-transfer behavior untested.
Account areas	Routes include overview, profile, addresses, order list/details and a transfer-request form. The account shell renders dashboard for a retrieved customer and login otherwise.	Components/routes exist; authenticated journeys and ownership behavior untested.
Account localization	Registration, login, verification, account navigation/dashboard and some forms contain English-only or starter-brand text; shared dictionaries do not cover the full journey.	Incomplete for the release's Spanish/English contract.
Account-specific test coverage	Current storefront tests cover routes/links, catalog, cart inquiry and origin checks, but not signup, login, logout, verification, customer sessions or cart transfer.	Untested.

At audit time, legacy storefront routes still exposed /account in their header/footer and side menu, and their cart included a sign-in prompt. The new Guanza header and public cart now omit account entry points. publicLinks() still reserves /guanza/cuenta and /en/guanza/cuenta for a future release, but this string builder does not make those routes render or preserve authentication.

Email and backend configuration

apps/backend/medusa-config.ts configures database/Redis, HTTP secrets, file storage, cache, event bus, workflow engine and locking. It does not declare an email/notification module or provider. Neither compose.yaml nor compose.prod.yaml supplies mail-provider settings. The backend/storefront example environment files likewise contain no SMTP or transactional-email settings. The storefront call to sdk.auth.verification.request() is not evidence that email can be delivered in the deployed environment. Its failure is caught and suppressed by completeLogin(), while the UI says an email was sent; this needs provider configuration and an end-to-end check before verification-dependent signup is advertised.

This audit does not establish whether email verification is enabled in the current Medusa runtime. That is runtime state and was not queried. No local customer was created and no verification email was requested.

Route and legacy bridge assessment

Customer pages are compiled under apps/storefront/src/app/[countryCode]/(main)/account/...; verification is at [countryCode]/(main)/verify-account. The public route helper recognizes /guanza/... and /en/guanza/... as Colombia (co) requests so the proxy does not prepend a market code, but it does not rewrite /cuenta to /co/account. /guanza/cuenta is not an App Router account route today. Existing account links and post-logout redirects still target old account paths. Verification links also need a public destination that reaches the verifier while public shop paths are active.

Do not expose a clickable Guanza account entry for this release yet, and do not ship a proxy alias from /guanza/cuenta to the legacy account as if it were safe. An internal rewrite to /co/account is plausible, but unproven across server actions, Next navigation, verification callback URLs, locale routes, redirects, cookie scope and deployment cutover. Redirecting to /cementos/co/account would couple the new release to a legacy deployment path and show a different, unlocalized experience. Keep guest shopping primary and preserve backend authentication and existing account data. Reconsider a bridge only after local integration proves it across both locales and verification callbacks. If an existing customer needs access meanwhile, use the currently deployed legacy entry only if its actual production availability is separately confirmed.

Local verification prerequisites at audit time

The authoritative checkout is /home/justin/repos/AndreaWeb on jm/andrea-redesign-1. The ignored local environment files were present, but their values were not read or recorded. The commerce services were not running during this specific audit. Subsequent Step 6 review started the local stack and used WSL's initialized fnm Node/npm; it did not exercise registration, verification, or login. The checklist below remains the gate before exposing account creation in the new Guanza header.

Local verification checklist before exposing accounts

Run with isolated local Medusa/Postgres/Redis/Garage state and a test email sink/provider. Do not use production customer addresses, production services or real customer data. Capture sanitized results only.

1. Initialize the WSL fnm Node version required by the repository; verify node --version and npm --version, and confirm local Compose configuration without displaying secrets. Start the documented local commerce profile. Wait for Medusa health and the storefront. Confirm a Colombia region and local publishable key are available.
2. Inspect local Medusa auth policy to establish whether verification is enabled. Configure a test-only sink/provider and verify generated message destination, sender, callback origin, expiry and single-use token behavior without sending to a real mailbox.
3. As a browser guest, create a cart with a test item, record its local cart identity and quantity, then register a disposable local customer. Verify form validation, duplicate-email behavior, safe errors, pending-customer cookie flags, and that no customer session is granted before verification when the backend requires it.
4. For verification-required mode, inspect the captured message, follow its link on the same and a second browser, verify success/expired/invalid token outcomes, then log in. For verification-disabled mode, prove registration/login completes without presenting a false verification claim.
5. Confirm successful login creates/links exactly one local customer, sets an HttpOnly session cookie with expected Secure/SameSite behavior, retrieves only that customer's data, and transfers the guest cart once with items and quantities intact. Check cache refresh and retry/error behavior without duplicate lines.
6. Exercise overview, profile edits, address add/edit/default changes, orders/details and transfer-request UI as applicable. Confirm unauthenticated deep links return to login and authenticated requests cannot access another customer's records. Note unsupported actions such as email/password changes instead of presenting inert controls.
7. Log out and verify server session invalidation, cookie removal, redirect, browser Back behavior and documented cart-removal behavior. Verify a stale session cannot retrieve customer information.
8. Repeat the intended journey in Spanish and English, including validation/errors, verification, navigation, accessible names, formatting and responsive keyboard operation. Resolve or label untranslated starter text and policy links before launch.
9. Rehearse /guanza/cuenta and /en/guanza/cuenta under the local routing spike. Prove page load, server actions, Next links, callback links, redirects, locale switching and auth/cart cookies work under public paths, with no /co or /cementos leakage. Include Nginx/proxy and built asset paths. If any leg fails, keep the entry hidden and retain legacy behavior until a tested bridge exists.
10. Add focused automated coverage for signup/login/verification states, logout, session/customer isolation, guest-cart transfer and public-route callbacks; then run storefront tests/build and browser journey checks. Do not create a production account or send a production email as a test.

Decision for Step 5

Account code is present, but delivery, runtime auth policy, cart transfer, public routing and localization are not release-verified. Keep guest shopping primary; hide or demote account entry points in the redesign until the local checklist passes. Preserve existing backend auth and accounts. Do not route /guanza/cuenta to the legacy account in this release without an integration proof for both locales and verification callbacks.