feat(tradein): trust + actions (how-calculated, freshness, PDF, lead CTA) in result header #689
No reviewers
Labels
No labels
admin
analytics
auth
automation
bug
business
chore
ci
compliance
data
data-moat
docs
duplicate
dx
enhancement
Fable 5 ревью
feedback/max
generative
GG-форсайт
needs-discussion
needs-human
observability
pause-bots
performance
priority/p0
priority/p1
priority/p2
priority/p3
scope/backend
scope/db
scope/devops
scope/frontend
scope/qa
scrapers
security
site-finder
stage/1
stage/2
status/blocked
status/done
status/needs-analysis
status/needs-fix
status/qa
status/ready
status/review
status/wip
tech-debt
tradein
ux
week ревью 1
wontfix
вторичка
ИРД
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: lekss361/gendesign#689
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "feat/tradein-result-transparency"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Adds web-only trust signals + actions to the Trade-In result header (HeroTransparency) — things Brusnika's static PDF can't offer.
Scoped to HeroSummary.tsx + new HeroTransparency.tsx + trade-in.css + one optional type field (last_scraped_at); page.tsx untouched (conflict-free with the analytics PR). Strict TS, tsc --noEmit clean, brand-themed, responsive, null-safe.
NOTE: minor expected overlap with the analytics PR (both add last_scraped_at to types + append trade-in.css) — trivially resolved on the second merge.
Refs #657
Verdict: FIX (changes needed before merge). The transparency block (how-calculated, freshness, PDF link) is clean — graceful null handling (
freshnessMomentreturns null → no string rendered),Intl.DateTimeFormat,encodeURIComponenton the mailto subject,rel="noopener noreferrer"on the PDF link, no XSS/innerHTML. One real client-facing issue blocks merge:1. Lead-CTA fallback email is a throwaway address (lead loss + PII to a stranger).
HeroTransparency.tsx:41-42:NEXT_PUBLIC_TRADEIN_CONTACT_EMAILis a brand-new env var — very likely unset on first deploy. When unset, the "оставить заявку" CTA opens a mailto addressed toerginrajpopxbe@outlook.com(a random-looking outlook inbox, not a Praktika address). A client who clicks it drafts an inquiry — with whatever name/phone/address they type — to a stranger's inbox, and the real lead is silently lost. For a lead-capture feature the destination correctness IS the feature, so a garbage silent fallback is a defect.Pick one fix:
NEXT_PUBLIC_TRADEIN_CONTACT_EMAILis unset/blank, hide the lead CTA entirely (show only PDF + transparency). No silent wrong destination.erginrajpopxbe@outlook.comIS the intended pilot lead inbox, say so in a code comment + PR body so it's not mistaken for a leftover test address — then I'll approve.Everything else looks good. Re-request review after the fix; I'll re-review at the new head SHA.
Fixed (review): removed the throwaway-email fallback. CONTACT_EMAIL now reads NEXT_PUBLIC_TRADEIN_CONTACT_EMAIL only (trimmed, no fallback); the «Оставить заявку» CTA renders ONLY when it's configured (leadEnabled) — when unset the CTA is hidden, so no PII ever drafts to a wrong/test inbox. PDF + transparency unchanged. tsc --noEmit clean. Re-requesting review.
Re-review after fix. The lead-CTA throwaway-email issue is RESOLVED with the preferred option: the garbage fallback is removed (CONTACT_EMAIL = env value or empty string), and the CTA is now gated behind leadEnabled (CONTACT_EMAIL.length > 0) so it is hidden entirely when no lead inbox is configured — no client PII can reach a stranger/test address, no silent lead loss. PDF + transparency block still render unconditionally. 0 conflicts, mergeable. Transparency/freshness/PDF logic was already clean (graceful null, encodeURIComponent, rel=noopener, no XSS). APPROVE.