- update-Nitrov3.sh: build CMS into .next-staging and swap atomically so a
failed build never takes the live site down; auto-merge new variables
from .env.example; validate env for duplicates/broken lines; restart the
emulator/CMS only when rebuilt or unhealthy; fix step renumbering
- next.config.ts: support NEXT_DIST_DIR for staged production builds
- fix all TS errors (unused imports, missing tryDownloadCandidates helper)
so tsc and the production build pass clean
- add Dockerfile/.dockerignore and switch docker-compose to a CMS container
- include prevailing UI/refactor changes (SurfaceCard, ticketing, tsconfig)
resolveHotelName() now returns env.HOTEL_NAME directly — the single source
of truth. The CMS hotel_name site setting and its DEFAULTS entry are removed
as dead code since they no longer influence the displayed name.
Call sites are unchanged (still await resolveHotelName()); only the lookup
behind it is gone, so the public site always shows the configured env name
with no DB round-trip and no preset.
Drop the hardcoded FALLBACK_HOTEL_NAME ("Atom") preset and the brand.ts
module. HOTEL_NAME is now a required env var: if it (and the CMS hotel_name
setting) is missing the site fails validation at startup/build with a clear
message instead of silently rendering a placeholder hotel name.
resolveHotelName() resolves CMS hotel_name -> required HOTEL_NAME only.
Callers that used the preset (api/home route catch branch, CMS settings form
default, mobile-nav/logo-generator prop defaults) now use the configured name
or an empty default; the real name is already passed in by server parents.
Replace the three near-identical public card primitives (ContentCard for
content pages, SectionCard for auth/account, and the new SurfaceCard) by
merging SectionCard into SurfaceCard, which now supports an optional header
(title/icon/action). Every remaining ad-hoc inline `rounded-2xl border`
card across (site) is converted to SurfaceCard, preserving each card's unique
visuals (background images, blur, gradients) via the style passthrough.
Net result: the public site uses exactly two card components — ContentCard
(CMS/content pages) and SurfaceCard (everything else) — and the shadcn Card
in components/ui/card.tsx is left untouched for admin.
Also deletes the now-unused components/home-section.tsx.
Introduce components/surface-card.tsx (Card + CardBody) mirroring the
.content-card / SectionCard token set, and use it on the (site) pages that
still hand-rolled card markup: me, search, and verify. This puts every
public page on one of the shared card components (ContentCard, SectionCard,
or SurfaceCard) for consistent radius/shadow/border.
Unify the public site by making SectionCard and the verify status card use
the same --radius-lg / --shadow-card tokens and primary-tint header as the
existing CSS .content-card used by all content pages. This makes the entire
(site) group visually consistent without rewriting every page, and keeps the
shadcn Card in components/ui/card.tsx (used by admin) intact.
Convert the settings page neon gradient section headers (blue/purple/green)
to the shared SectionCard, and replace the verify page's harsh multi-stop
status gradients with subtle status-tinted headers while keeping the
green/amber/red/blue semantics. The me page already used a consistent
rounded-2xl card style, so it needed no change.
Reuse the SectionCard component to unify the neon section headers, center
the page in a max-w-6xl container, and give the welcome panel and login
card consistent rounded corners and subtle shadows, matching the home
and register pages.
Reuse the SectionCard component to unify the green/purple/blue neon
section headers, center the page in a max-w-6xl container, and give the
welcome panel and form card consistent rounded corners and subtle
shadows, matching the home page.
Unify the per-section neon gradient headers (blue/green/purple) into a
single consistent SectionCard component with a calm surface header and
hairline divider, constrain the page to a centered max-w-6xl container,
and soften the hero/cards with rounded-3xl corners and subtle shadows.
The username normalization, dummy-hash constant, password check and
email-verification gate were duplicated between precheckLogin and the
NextAuth credentials authorize handler. Move them into a single
login-core module so both paths share one source of truth and stay
consistent.
precheckLogin already normalized the username with NFC, but the
NextAuth credentials authorize handler only trimmed it. This caused a
mismatch for accounts with accented/non-ASCII usernames: the precheck
passed while the actual sign-in lookup found no user and returned
'invalid username or password'.
Also normalize the password to NFC in both the precheck and the
authorize handler to match how register.ts hashes it.
Simo
openhands