ali-alemi/CONTEXT.md

Ali Alemi Website Context

Keep this file current. Whenever a prompt changes scope, content, domain, or conventions, update the relevant section below in the same turn.

Project

• Farsi RTL storefront for استاد علی عالمی (private math/calculus tutor for the Iranian کنکور).
• Next.js 16 App Router, React 19, TypeScript, Tailwind 4 (@theme inline, no tailwind.config.js), src/app.
• lang="fa" dir="rtl" set in src/app/layout.tsx.
• Apex domain: alialemi.com (src/lib/site.ts → SITE_DOMAIN) — confirmed by the user. SITE_URL, CUSTOMER_URL (customer.alialemi.com), BUSINESS_URL (business.alialemi.com), the sitemap-config fallback, and metadata all derive from it.
• The live Meshkee tenant for this domain does not exist yet on api.meshkee.com (every API call currently 404s) — every fetch on the site is wrapped in safe() (src/lib/meshkee/client.ts) so pages render a friendly empty state instead of crashing. This is expected and will resolve itself once the business is provisioned on the backend; no code change needed then.
• Carousels use Swiper (swiper/react, swiper/modules) per explicit instruction — see src/components/home/Testimonials.tsx and src/components/home/FeatureCards.tsx.

Homepage layout fidelity

The user asked for the homepage's structure/layout to closely match the live original (http://ali-alemi.local:8000, a local Meshkee web-builder preview blocked by their VPN from this environment — they instead pasted screenshots directly). Corrections made after comparing against those screenshots:

• Header: solid bg-secondary (navy) bar, not white/blurred. On desktop (lg: and up) logo sits first in DOM (renders on the right in RTL — do not add order-* overrides here again, that was tried and was wrong), nav links, then phone/cart/login actions, matching the real desktop header exactly. Below lg: the header is a completely separate 3-column grid row (hamburger right / logo centered / cart left — Farsi readers expect the hamburger on the reading-start side, not the logo-adjacent corner) rendered via its own grid grid-cols-3 lg:hidden block, not responsive classes bolted onto the desktop flex row — the two arrangements are different enough (centered logo vs. edge logo, hamburger only exists on mobile) that trying to share one row fighting order-*/justify-* was worse than two small dedicated blocks. See Header.tsx.
• Hero (HeroSection.tsx): character + a large dotted ring backdrop (public/images/hero/ring.png — the accent dots are baked into that asset, don't draw separate circle divs), a second smaller student avatar peeking from behind the character, floating grad-cap/paper-plane/shape decorations. No CTA buttons in the hero — the original doesn't have any there. Two-column grid switches at md: (768px), not lg: — at lg: the in-between tablet/small-laptop range stacked to a single column and looked broken (large blank gap), since the image side has fixed-height containers.
• Feature cards (FeatureCards.tsx): a Swiper carousel (prev/next arrow buttons, not pagination dots) in a two-column row — cards on the left (wide column), a "ویژگی‌های ما" heading + short paragraph + the arrow buttons in a narrow 280px right-hand column. This grid must be md:grid-cols-[280px_minmax(0,1fr)] — not [280px_1fr]: a bare 1fr track let Swiper's internal width calculation blow the column out to ~16.7M px (classic CSS Grid blowout; Swiper needs minmax(0,1fr) to be constrained by its parent). The Swiper's own grid-item wrapper also needs min-w-0 directly (see the Reveal around it) — that's the part that matters below md, where there's no explicit grid-template-columns at all but the item is still a grid child with min-width: auto by default, so the same blowout happened on mobile too until that class was added. Any future Swiper placed inside a grid or flex container needs this same min-w-0 treatment regardless of breakpoint. Also must NOT have negative top margin overlapping the hero — that was tried first and the user flagged it as a bug ("باید با هیرو فاصله داشته باشه"), plain py-16 md:py-24 is correct.
• Quick-links row ("چرا استاد علی عالمی؟", QuickLinks.tsx): real icon assets (icons/play.png, exam.png, price.png, support.png) in sm:grid-cols-2 lg:grid-cols-4 — 4-in-a-row on real desktop widths, 2×2 on tablet. Ends with a "درباره ما بیشتر بدانید" CTA linking /about-us (that's the original frame's own link field, not invented).
• "چرا مارا انتخاب کنید؟" (WhyChooseUs.tsx): image on the left, text+CTA on the right (DOM order text-first renders right in RTL grid). Stat badges (آموزش با کیفیت / نظارت دقیق و ارزیابی عملکرد / بیش از ۱۵۰ ساعت آموزش / ۱۴,۵۰۰ نفر دانشجو+avatars) are floating cards scattered over the image's corners (absolute-positioned with physical left-*/right-*, not logical start/end — this composition doesn't flip with page direction), not a plain bulleted list in the text column. The two bottom badges must sit in mirrored corners — ۱۴,۵۰۰ نفر دانشجو at -bottom-6 -left-6 and بیش از ۱۵۰ ساعت آموزش at -bottom-6 -right-6 — an earlier right-1/3 on the second one drifted under the first at narrower widths (user flagged it as an overlap bug from a screenshot); symmetric corners is the fix, don't reintroduce a fractional/centered offset on either bottom badge.
• Testimonials: multi-per-view on desktop (breakpoints: {768:2, 1024:3}), pagination dots (not arrows) — opposite of the feature carousel.
• Stats bar (StatsBar.tsx): light/white background with teal numbers — not a navy full-bleed banner (that was tried first and was wrong).
• Scroll-reveal entrance animation on every section via src/components/Reveal.tsx (fade + translateY on IntersectionObserver, stands in for the original's WOW.js + animate.css) — requested explicitly ("انیمیشن‌ها ... باید دقیقا شبیه سایت اصلی باشه").
• General lesson: any two-column image + text grid using a fixed-height image container should switch at md: not lg:, or verify the lg: in-between range doesn't leave a tall single-column stack. Applies to WhyChooseUs.tsx, about/BioIntro.tsx, contact/ContactInfo.tsx (already fixed) — check any new two-column section against this before shipping.
• Hero second avatar (avatar-1.png, the girl peeking from behind the character): positioned top-16 end-0 (was bottom-6 end-2, which put almost the whole thing behind the character's body with only a sliver of hair visible) — user asked to raise it so it actually reads as a second figure. If the character illustration or its box size changes, re-check this is still clearly visible, not just technically in the DOM.
• Feature cards (FeatureCards.tsx) use border border-ink/15 shadow-md, not ring-1 ring-line — the --color-line token (#ececec) was too light to read as a border at all against the white card/white section background (flagged from a screenshot as "بوردرهاشون مشخص نیست"). If another white-on-white card ever looks edge-less, this is the fix, not a heavier shadow alone.

Header — logo/favicon, nav, categories (round 2 polish)

• Dynamic logo: RootLayout (src/app/layout.tsx) now fetches getFavicon() once and passes logoUrl/logoDarkUrl down to both Header and Footer (in addition to the favicon it already used for <head> icons). Header prefers logoDarkUrl (the dashboard's dark-background variant) → logoUrl → the bundled local /images/logo.png; the brightness-0 invert CSS filter is applied only when falling back to the local asset (it's the one known-teal file that needs forcing white for the navy bar — a real CMS-uploaded logo's color is unknown, don't invert it blind). Footer just uses logoUrl → local, no invert (white background, original color is correct there). Both use unoptimized on next/image when the src is a remote CMS URL, since that host isn't (and can't be, until a real tenant exists) in next.config.ts images.remotePatterns. The favicon itself was already dynamic before this round (generateMetadata) — this was specifically about the header/footer <img> logo not following the same rule yet.
• Active nav link + phone button styling: active link and the phone number both render as a solid white pill (rounded-full bg-white px-4 py-2, dark text-secondary) against the navy bar, not a transparent/tinted-text treatment — this was an explicit visual ask from a screenshot annotation ("دور لینک اکتیو ... یک مستطیل سفید با ردیوس ۵۰ بذار"). rounded-full (Tailwind's 9999px) reads as the same fully-pill shape as a literal 50px radius at this button height, so that's the correct utility, not an arbitrary rounded-[50px]. Inactive links stay text-white/80 on transparent. Applies only to the desktop nav row; the mobile dropdown panel keeps its own simpler hover-background treatment.
• Navbar reverted to exactly 5 static items (NAV_LINKS in src/lib/site.ts): صفحه اصلی، دوره‌های آموزشی، مقالات، درباره ما، تماس با ما — per explicit instruction, not محصولات/فروشگاه/نمونه‌کارها. A categories-driven dropdown for "محصولات" (src/components/CategoriesMenu.tsx, fetched via getCategories({ entityType: "product" }) in the root layout) was built and then removed again the same session once the user clarified the nav should stay to just those 5 until real CMS content exists — CategoriesMenu.tsx was deleted and the categories fetch/prop taken back out of layout.tsx/Header.tsx. /products, /store, /portfolios are still real, working pages — just not linked from the header nav right now. If nav-driven category browsing is wanted again later, it needs to be rebuilt (check git history for the deleted CategoriesMenu.tsx rather than starting from scratch).
• Header action buttons (search/cart/user, right side of the desktop row): redesigned to solid bg-primary filled circles/pills per a reference screenshot, not outlined/ghost buttons. Search was added then removed the same session — the site has no search backend, so don't re-add a search icon/box to the header without an actual /products?name= wiring decision first. CartButton (src/components/cart/CartButton.tsx) is now always a solid primary circle with a white-on-primary badge (no more light prop — it was only ever used inside this navy header, the conditional was dead weight). UserMenu (src/components/UserMenu.tsx) similarly dropped its light prop — both the logged-out "ورود / ثبت‌نام" pill and the logged-in "{name} عزیز" trigger are solid primary pills now.
• Mobile hamburger button bug: the button was flex items-center but not justify-center, so the 3-line icon span (and the X it morphs into when open) hugged one edge of the 40×40 square instead of sitting centered — reported from a screenshot ("۳ خط منو داخل مربع نیستن" / X not centered when open). Fix was adding justify-center alongside the existing justify-self-start (that one's unrelated — it positions the button itself within the mobile header's 3-column grid row; justify-center centers the icon inside the button). If another icon-only square button ever looks off-center, check for this exact same missing class rather than touching the icon's own SVG/span markup.
• Feature carousel must have all 4 real items: src/components/home/features-data.ts had been trimmed to 3 during the earlier "match the real 3-visible-at-once desktop screenshot" pass, silently dropping "انتخاب زمان کلاس" (choose class time) — the original theme has 4 features, the 4th just wasn't visible in that one screenshot because the carousel only shows 3 at a time on desktop. Restored as the 2nd item (clock icon, secondary tone) so the carousel actually has something to scroll to. Icon badges in FeatureCards.tsx also got a nested treatment — an outer h-16 w-16 rounded-2xl tone-colored square containing an inner h-10 w-10 rounded-full bg-white circle with the icon colored to match the outer tone — per a "flaticon-style" reference screenshot; a flat single-layer colored-square-with-white-icon read as low-effort by comparison. about/FeatureStrip.tsx reuses the same FEATURES array and benefits from the same fix (was showing an awkward 3-in-a-4-col grid before).

Scope (current)

Static pages: / (home), /about-us, /contact-us — content from old-site (see "Source clone" below).

Live-API-backed catalog pages (built against api.meshkee.com, real tenant not provisioned yet so every list/detail page currently shows its empty state — see "Meshkee API" below):

Module	List	Detail	Notes
Products	/products	/products/{id}/{nameFaSlug}	description / technical-data / comments tabs, "محصولات مشابه" row. No cart button (informational catalog).
Store items	/store	/store/{id}/{nameFaSlug}	same tabs plus add-to-cart with quantity. {id} is the product id, not a variant id — see "Store items architecture" below.
Product category	—	/products/category/{id}/{nameFaSlug}	lists products in that category.
Workshops	/workshops	/workshops/{slug}	no confirmed backend endpoint yet — see "Workshops" below.
Portfolios	/portfolios	/portfolios/{id}/{titleFaSlug}	lightbox gallery, "نمونه کارهای مشابه" row.
Blog	/blog	/blog/{id}/{titleSlug}	cover image, HTML content, comments.

There is no درمانگاران page — it was in an earlier draft of the brief and the user corrected that mid-session.

Source clone

• Original site: a Meshkee web-builder (Blade/PHP) export that was temporarily copied into old-site/ to port content/assets from, then deleted per explicit instruction once the rebuild below was complete and verified against it — it no longer exists in this repo or on disk. Everything it contained is now captured either as real content in the pages/components listed below or as extracted files under public/; there is no separate archive to fall back on, so treat this file's notes as the record of what came from where. (Its original structure, for history: old-site/custom/fa/pages/*/main.php listed each page's frame stack; old-site/custom/fa/frames/*.php and old-site/frames/**/content.blade.php held the actual field data and markup per frame.)
• old-site/settings.php gave the brand palette (primaryColor #008081, secondaryColor #324264, tertiaryColor #E7E7E7) and default font (iran-yekan) — both carried over as Tailwind tokens (src/app/globals.css) and the self-hosted font (src/app/fonts.ts).
• All page copy is the real content from old-site, including the lorem-ipsum placeholder paragraphs that were literally in the source (per instruction: "all data is valid"). One exception: the About page FAQ (old-site/custom/fa/frames/public-faq-yOxMt.php) contained a broken, irrelevant template Q&A ("چگونه می‌توانم محصول شما را با PayPal ادغام کنم؟" on a math-tutor site) — that was replaced with generic, non-fabricated tutoring FAQs (src/components/about/Faq.tsx) rather than keeping obviously mismatched boilerplate.
• Real, non-lorem content that was found and is now used prominently:
  • Bio/credentials (old-site footer frame footer-footer-hCR1y.php, field text): born 1366/12/22, mechanical engineering (Iran University of Science & Technology), aerospace M.Sc. (same university, aerospace structures), rank 243 in the national Konkur, 13 years teaching math/calculus, worked with top Konkur academies. Used in the footer bio list and as the About page's Resume section (src/components/about/Resume.tsx) — this is the standout real content on the site, feature it, don't bury it.
  • Contact info (public-info_1-ZWXoP.php): address "قم، میدان مفید، ساختمان پاسارگاد، طبقه سوم", phone 0912 607 3354, Instagram @Alialemiteacher. Lives in src/lib/site.ts → CONTACT.

Asset provenance (public/images, public/fonts, public/brand)

• public/fonts/iranyekanweb{light,bold}fanum.woff — copied from the sibling Meshkee project ../moallem/public/fonts (same font, already cleared for use across the Meshkee site fleet). cdn.meshkee.com (the original font CDN) was unreachable from this environment (TLS handshake blocked) — if that changes and more weights are wanted, fetch https://cdn.meshkee.com/web-builder/fonts/iran-yekan/iran-yekan.css.
• public/images/logo.png ← old-site/assets/files/E9jXiAxciH.png (teal "ALI ALEMI" wordmark; footer's mk7iCwJnYx.png is byte-identical). There's no separate white variant, so Header.tsx applies brightness-0 invert to render it white on the navy bar; Footer.tsx uses the original teal color on its white background.
• public/favicon.png / public/images/favicon-mark.png ← old-site/assets/files/9B5ryAVpXy.png (the infinity mark from the logo).
• public/images/hero/character.png ← XrfpuKYbWv.png — the 3D professor illustration (used in the hero, WhyChooseUs, and About BioIntro).
• public/images/hero/{ring,sketch,grad-cap,paper-plane,shape-1..5,avatar-1,avatar-2}.png ← decorative floaters from the same slider frame (RHLYjNnYj6, JtkpbKjrLA, 8d3ZPngaUQ, jWgzrcRljG, QpKmZ80xX1, hiDCqXhOI6, f8rjoyAIi9, wYNzYMZHz2, H11Q6Ni7hV, QeqN7XLmJY, yVeuSypizt).
• public/images/icons/{play,exam,price,support}.png ← YYrcDvSrtC, JGmzMzVo2I, wEkbnOuKHg, 7HZemBIE7S — the real gradient icons for the "چرا استاد علی عالمی؟" quick-links row.
• public/images/icons/quote.png ← j6FWn5p4aw.png; public/images/testimonial/avatar.png ← IRj6Zp6N2J.png (same avatar the original reused across all three testimonial cards — that's the real data, not a shortcut).
• public/images/contact-photo.jpg ← old-site/assets/img/contact/01.jpg (generic stock photo bundled with the original theme).
• public/brand/meshkee-logo-white.png — downloaded directly from https://safeteb.com/images/footer/MeshkeeLogo-White.png (see Footer credit below).
• Substituted with custom inline SVG icons (src/components/icons.tsx) instead of a missing asset: the four "ویژگی‌های ما" feature-card icons, the three small badge icons (pencil/search/check), contact icons (location/phone/instagram/whatsapp/telegram), and the About-page Resume icons. Their source files (e.g. files/vLZSFuYnkv.png, files/otHFQ7PVUQ.jpg, files/IyvhvDu45j.jpg, files/TXzEEuVLAR.png, files/6aCyDwfHgF.png, files/6r1iyxcLfi.png) were referenced in the Blade config but not present in old-site/assets/files (never actually uploaded on the live site) — rather than inventing stock photography, those slots became flat gradient backgrounds (StatsBar, PageHeader, CustomerClubBanner all use a teal→navy gradient + dotted pattern instead of a missing photo) or the custom icon set.

Footer Meshkee credit

Matches https://safeteb.com/ exactly, per instruction — markup, hover-frame animation, and CSS copied over in src/components/Footer.tsx / src/app/globals.css (.meshkee-credit*, .footer-bottom* classes). This is the same pattern already used on the sibling khiyal-studio project; keep the three in sync if the reference site's credit design ever changes.

Meshkee API layer (src/lib/meshkee/)

• client.ts — meshkeeFetch/tenantFetch (adds /tenants/{SITE_DOMAIN} prefix) wrap fetch with Next.js data-cache revalidate (default 60s; auth/mutating calls pass revalidate: false). safe(promise, fallback) swallows any error/404 and returns the fallback — every list/detail fetch on a page goes through safe() so a missing tenant or disabled module renders an empty state, never a crash. MeshkeeApiError carries the HTTP status if a caller needs to branch on it (nothing does yet).
• types.ts — deliberately loose interfaces. The public OpenAPI/Postman docs document endpoint shapes but not exact field names for product, store-item/variant, category, or comment objects (confirmed by querying both docs directly this session). Fields like nameFa/name/title, titleImageUrl/imageUrl, discountedPrice/price are best-effort guesses at Meshkee's conventions (matching what other modules — blogs, portfolios, user-products — do document). Once a real tenant exists, fetch one live response per entity and reconcile types.ts + the pickText()/normalize*() accessor chains in format.ts against the actual field names — don't assume the current guesses are correct.
• format.ts — pickText(...) tries field-name candidates in order; normalizeImage/normalizeGallery handle both bare URL strings and {url} objects (unconfirmed which shape the API actually returns); slugify() builds canonical-URL slugs (Farsi letters/numbers kept, spaces → -, other punctuation stripped) — always build links with slugify(name), never a raw item.slug field (the legacy DB slug must not appear in public URLs, per instruction); formatToman, formatDate.
• One file per module: tenant.ts, products.ts, store-items.ts, portfolios.ts, blogs.ts, workshops.ts, categories.ts, comments.ts, contact.ts.

Canonical URLs

Per the current brief (this supersedes anything the earlier AI_PROMPT.md fetch said about slug-only blog/portfolio routes):

• Product: /products/{id}/{nameFaSlug} → resolve via GET /tenants/{domain}/products/by-id/{id}.
• Product category: /products/category/{id}/{nameFaSlug} → GET /tenants/{domain}/categories/by-id/{id}, then list products with categoryId.
• Blog: /blog/{id}/{titleSlug} → GET /tenants/{domain}/blogs/by-id/{id}.
• Portfolio: /portfolios/{id}/{titleFaSlug} → GET /tenants/{domain}/portfolios/by-id/{id}.
• Store item: /store/{id}/{nameFaSlug} — not an official Meshkee canonical path (none exists for store-items in the docs); chosen to match the product pattern. {id} is the product id (see "Store items architecture").
• Workshop: /workshops/{slug} — no by-id resolve exists yet (no endpoint at all — see "Workshops"); kept slug-only since there's nothing to redirect against.

Every {id}/{slug} detail page fetches by id, computes slugify(name), and redirect()s to the canonical slug if the URL's slug segment doesn't match (same pattern on all four: products, store, portfolios, blog).

Store items architecture (read before touching /store)

Meshkee's own data model treats store-items as the sellable variant layer under a product, not an independent content catalog — GET /store-items/by-product/{productId} is the only store-item lookup AI_PROMPT.md itself documents, specifically for the mini-cart flow. There is no dedicated "rich content" (gallery/description/technical-info) on a variant; that lives on the product.

So /store/{id}/{slug} resolves {id} as a product id: it fetches the product (getProductById, for gallery/description/technical-info) and getStoreItemByProduct(id) (for sellable variants/pricing) in parallel, then renders one page combining both. /store (the list) calls GET /store-items directly and reads item.product for display fields — this nested product field on a store-item list response is unconfirmed (see types.ts note above); verify against a live tenant.

Workshops — no confirmed backend endpoint

Checked both openapi.json and the Postman collection directly this session: neither documents any workshops CRUD route — only a /tenants/{domain}/sitemap-workshops.xml placeholder exists (tag: SEO). src/lib/meshkee/workshops.ts still implements getWorkshops/getWorkshopBySlug/getWorkshopById following Meshkee's uniform module shape (same as products/portfolios/blogs) so it's a drop-in once the backend exposes it; until then every call 404s and safe() renders the "دوره‌ای برای ثبت‌نام باز نیست" empty state — this is expected, not a bug.

"Registration row": a workshop's productId (falls back to the workshop's own id) is looked up via getStoreItemByProduct(), and if that returns in-stock variants, the same AddToCartBar used on /store renders as the registration control ("ثبت‌نام" = adding the workshop's product variant to the cart, then continuing to the customer-dashboard checkout — there's no separate "enrollment" API). If no store item exists for it, a "برای ثبت‌نام تماس بگیرید" + phone-number fallback renders instead.

Auth (customer session)

• src/lib/auth.ts — server-only (next/headers cookies()). Reads meshkee_customer_access_token, including the chunked form ({name}_n count + {name}_0, {name}_1, ...) per AI_PROMPT.md's cookie contract. getSession() calls GET /auth/me with that token and returns { user, token } | null; called once in src/app/layout.tsx (root layout is now async) and passed down as props — no client component calls /auth/me itself.
• isAdminUser() is a best-effort check (user.isAdmin || user.role === "admin" || user.role === "owner" || user.roles?.includes("admin") || user.businessRoles?.length) — the real shape of the user object returned by /auth/me isn't documented publicly. Verify against a live logged-in session and trim to whichever field actually indicates admin/owner.
• src/components/UserMenu.tsx: logged-out → "ورود / ثبت‌نام" linking to customerLoginUrl(). Logged-in → "{firstName} عزیز" with a dropdown: پروفایل من (customer.{domain}/profile), مدیریت وبسایت (business.{domain}, only when isAdmin), خروج (customer.{domain}/logout). All three are plain cross-origin <a> tags (not next/link) — deliberately, they leave the site.
• No local login/register/OTP UI anywhere, per the hard rule — everything auth-related redirects to customer.{domain}.

Cart (guest cart, local-only)

• src/lib/cart.ts implements AI_PROMPT.md's guest-cart spec exactly: localStorage key meshkee-guest-cart, mirrored to a cookie (Domain=.{SITE_DOMAIN}, Path=/, SameSite=Lax, ~30 days, skipped if the encoded JSON exceeds ~3500 chars), encodeGuestCart() is the identical base64url encoder the customer dashboard uses. CartLine.id is always a storeItemVariantId — never a product id or store-item id.
• src/components/providers/CartProvider.tsx (client context, wraps the app in layout.tsx) holds cart state; reads localStorage in a useEffect deferred via queueMicrotask (avoids both a hydration mismatch and the react-hooks/set-state-in-effect lint error — same pattern as the sibling moallem project's CartProvider, keep them consistent if either changes) and writes back to storage on every change.
• src/components/cart/CartButton.tsx (header icon + quantity badge) and MiniCart.tsx (slide-over popup: line items, qty stepper, remove, total, Continue) — Continue uses continueToCheckoutUrl(): if the access-token cookie is present it links to customer.{domain}/checkout/cart?guestCart=..., otherwise to customer.{domain}/login?redirect=/checkout/cart?guestCart=.... No server cart/checkout code exists on this site at all, per the hard rule.
• AddToCartBar.tsx (src/components/catalog/) is the shared add-to-cart control used on /store/{id}/{slug} and workshop registration: filters variants to in-stock (stockQuantity === null or > 0), shows a <select> only when more than one in-stock variant exists, quantity stepper, "این محصول در حال حاضر موجود نیست" when none are in stock.

Comments

• GET/POST /tenants/{domain}/comments?entityType=...&entityId=... — the public docs list product|blog|portfolio|video as valid entityType values; workshop and store_item are passed the same way as a best-effort extension (unconfirmed — verify once live, blog/portfolio/product are the safe ones). Blog and portfolio also have entity-specific /blogs/{id}/comments routes but the generic one is used everywhere for one code path.
• The API itself does not require auth to POST a comment (no security scheme on that path in the OpenAPI doc) — but the user explicitly wants comments gated to authenticated users in the UI: src/components/catalog/CommentsPanel.tsx shows the comment form only when user is non-null (passed from the server page's getSession()), otherwise a "برای ثبت نظر ابتدا وارد حساب کاربری خود شوید" box linking to customerLoginUrl(pathname). When posting, authorName is built from the session's firstName/lastName and the access token is sent as Authorization: Bearer too (harmless if the API ignores it, useful if it actually does attribute comments server-side).

SEO / sitemap

• No public/sitemap.xml, public/robots.txt, app/sitemap.ts, or app/robots.ts — Meshkee nginx proxies /sitemap.xml (index) → /sitemap-main.xml + /sitemap-products.xml (+ other module sitemaps once enabled).
• src/app/meshkee/sitemap-config.json/route.ts scans src/app/**/page.tsx at request time (build-time-equivalent, since it's a dynamic route) and lists every static route, excluding dynamic [...] segments automatically — so /products/category/[id]/[slug] etc. never appear here; Meshkee's CMS fills those in from its own data per the canonical templates above. After deploy: business dashboard → Website → Settings → Sync sitemap config.
• Every page (static and dynamic) sets a unique <title>/description via metadata/generateMetadata, preferring seoMetaTitle/seoMetaDescription when the API provides them. Exactly one <h1> per page: PageHeader owns it; detail-page body sections that repeat the item name use <h2> (fixed a duplicate-H1 bug on the products/store/workshop detail pages this session — if you add a new detail page, don't reintroduce it). All content images carry a real alt (item name, never empty, decorative floaters use aria-hidden + empty alt instead).
• src/app/meshkee/static-image-slots/route.ts still returns STATIC_IMAGE_SLOT_CATALOG from src/lib/meshkee.ts (note: different file from the new src/lib/meshkee/ directory — src/lib/meshkee.ts predates this session's API layer and only holds that one constant, currently empty). Populate it if/when a homepage image becomes dashboard-editable.

Contact form

src/components/contact/ContactForm.tsx now POSTs to POST /tenants/{domain}/contact-submissions (src/lib/meshkee/contact.ts) with { title, name, cellNumber, text } (the title field is a fixed "پیام از فرم تماس با ما" — the endpoint appears to want a subject line, unconfirmed). On success: a toast (useToast()), an inline success banner inside the form for ~4s, and the form resets so the visitor can send another message without leaving the page. On failure: an error toast, fields are preserved (no reset) so nothing is lost.

Next steps

1. Once the tenant exists on the backend: fetch one real response per entity (product, store-item, category, comment, /auth/me user) and reconcile field names in src/lib/meshkee/types.ts + the pickText()/normalize*() chains — several are educated guesses (see "Meshkee API layer" above).
2. Confirm entityType values workshop/store_item actually work against /comments, or find/request the real ones.
3. Confirm whether a /workshops endpoint ever ships; if it lands under a different shape (e.g. folded into instructions or videos instead of its own module), update src/lib/meshkee/workshops.ts and the "registration row" fallback logic accordingly.
4. Resolve the tenant (GET /tenants/{domain}) for businessId and site-wide Organization JSON-LD (business-info.schema.jsonLd) in the root layout — not done yet, only favicon is fetched there.
5. Decide which homepage/about sections should become dashboard-editable and populate STATIC_IMAGE_SLOT_CATALOG (src/lib/meshkee.ts) accordingly.

Verification

• npm run lint and npm run build (standalone output at .next/standalone/server.js).
• Visually check every page in desktop and mobile widths; RTL layout, Swiper carousels, mobile nav toggle, cart badge/popup, user menu (logged-out state at minimum — no test account exists yet), contact form success + reset.
• Every catalog list/detail page should render its empty state, not crash, against the current (unprovisioned) tenant — that's the expected state until the backend is live.
• /meshkee/sitemap-config.json should list all static routes (/, /workshops, /products, /store, /portfolios, /blog, /about-us, /contact-us) and none of the [id]/[slug] dynamic ones.
• /meshkee/static-image-slots should return { "slots": [] } until slots are added.