homePageCar — Decision Log

Version: 9.0
Phases: 1 — Design Foundation through 9 — Developer Handoff

ID	Decision	Status	Rationale	Consequence
D-001	Use restrained operational blue as the main brand family	Approved	Supports trust, clarity, and product-led presentation	Blue carries navigation, links, selection, and routine primary actions
D-002	Reserve orange for demo conversion and tightly related emphasis	Approved	Preserves conversion salience and prevents visual noise	Orange is not a routine navigation or generic action color
D-003	Use Inter Variable for English and French	Approved	Screen-oriented, broad Latin support, strong UI and marketing utility	One Latin family across website and product-facing UI
D-004	Use Noto Sans Arabic for Arabic	Approved	Broad Arabic-script support and suitable sans-serif structure	Arabic receives separate metrics and locale loading
D-005	Use one token system with separate display and UI roles	Approved	Avoids two unrelated systems while respecting different density needs	Marketing headings and application labels do not share identical sizing
D-006	Adopt blue-600 `#1B5DD8` as brand anchor	Approved	Clear operational blue with useful lighter and darker neighbors	Accessible action background uses blue-700
D-007	Adopt orange-600 `#EA580C` as accent anchor	Approved	Strong conversion accent without becoming the whole brand	White-text conversion CTA uses orange-700
D-008	Ban orange-600 with white normal text	Approved restriction	3.56:1 contrast fails normal-text AA	Use orange-700 in light theme or orange-400 with dark text in dark theme
D-009	Use a 4 px spacing base	Approved	Predictable, scalable, compatible with compact and spacious layouts	Exceptions require explicit optical rationale
D-010	Use 4/8/12 column grids for mobile/tablet/desktop	Approved	Distinct responsive composition without device-specific hacks	Reference frames: 390, 1024, 1440 px
D-011	Cap primary container at 1280 px	Approved	Protects readability while allowing strong product visuals	Wider screens gain outer breathing room, not stretched text
D-012	Use CSS logical properties	Approved	Required for real LTR/RTL parity	Physical left/right spacing tokens are rejected
D-013	Use Lucide as the base icon family	Approved	Consistent 24 px grid and 2 px outline language	Mixing icon families requires a documented exception
D-014	Prefer 44 × 44 px interactive targets	Approved	Exceeds the WCAG 2.2 minimum and improves usability	Compact exceptions must remain accessible
D-015	Require formal Modern Standard Arabic	Approved	Prevents inconsistent regional dialect and preserves professional tone	All Arabic product and marketing copy must be linguistically reviewed
D-016	Avoid automotive racing clichés	Approved	Product is operational software, not performance-car entertainment	No speedometers, racing stripes, carbon fiber, or aggressive neon styling
R-001	Use orange for every primary button	Rejected	Destroys conversion hierarchy	Routine primary actions remain blue
R-002	Force identical line-height across scripts	Rejected	Damages Arabic readability and vertical rhythm	Arabic uses script-specific line heights
R-003	Use fixed-width translated buttons	Rejected	Breaks under French expansion and Arabic content	Buttons are content-driven
R-004	Mirror all icons in RTL	Rejected	Many icons are semantically direction-neutral	Mirror only directional meaning
R-005	Create one type scale for every context	Rejected	Marketing and dense UI have different jobs	Shared foundations, separate role scales
D-017	Use English as source, default, and fallback locale	Approved	Provides one controlled authoring source while all public locales remain independently addressable	Missing translations fail CI; production fallback is logged
D-018	Use locale-prefixed public URLs for every indexable page	Approved	Makes language state shareable, crawlable, and deterministic	All navigation and SEO generation use a central route manifest
D-019	Limit automatic locale detection to root `/`	Approved	Respects explicit URLs and prevents redirect loops or crawler interference	Locale-prefixed pages are never overridden by browser language
D-020	Persist explicit language selection in a first-party cookie	Approved	Allows SSR to honor user choice without relying on client-only state	Manual choice outranks Accept-Language
D-021	Use localized public slugs backed by stable route IDs	Approved	Improves localized readability while preventing routing logic from depending on translated strings	Switchers, sitemaps, and canonicals map by route ID
D-022	Use English/French LTR and Arabic document-level RTL	Approved	Correct browser bidi and layout behavior requires root direction	Arabic pages render `html lang=ar dir=rtl`
D-023	Use formal Modern Standard Arabic only	Approved	Maintains professional, region-neutral baseline	Dialect and colloquial copy fail linguistic review
D-024	Use Latin digits and Gregorian dates in the language-only baseline	Approved	Keeps operational data and identifiers consistent before market-specific preferences exist	Revisit only after Arabic market research
D-025	Use `فحص المركبة` for vehicle inspection	Approved	Clear operational term with broad formal comprehension	`معاينة المركبة` remains a documented secondary term
D-026	Use `عقد الإيجار` for rental agreement	Approved	Concise and standard legal-operational label	Jurisdictional legal review remains required
D-027	Use `مبلغ الضمان` for security deposit	Approved	Avoids confusion between deposit and insurance	Arabic `تأمين` alone is rejected
D-028	Use `معدل استخدام الأسطول` for fleet utilization rate	Approved	Describes use rather than occupancy	Occupancy language is rejected
D-029	Keep currency, country, timezone, tax, and phone behavior independent from language	Approved	Language-only locales do not define business jurisdiction	Formatting consumes explicit data and context
D-030	Use semantic namespaced translation keys	Approved	Supports reuse, context, QA, and refactoring	Source sentences, positions, and visual styles are not keys
D-031	Fail missing translations in CI	Approved	Prevents silent partial localization	Production fallback is a logged safety net, not the workflow
D-032	Use self-canonical locale pages and reciprocal language-only hreflang	Approved	Prevents English from swallowing localized indexing	`x-default` points to `/en` until a neutral selector exists
D-033	Omit regional Open Graph locale until target markets are approved	Approved	Avoids inventing country-region assumptions	Localized OG copy still ships
R-006	Use country flags as language controls	Rejected	Languages are not equivalent to countries	Display language names in their own language
R-007	Redirect explicit locale URLs based on browser language	Rejected	Breaks shareability, intent, crawling, and testing	Detection is root-only
R-008	Use IP geolocation to choose language	Rejected	Country is not language and geolocation is unreliable	Use explicit preference and Accept-Language
R-009	Use English source sentences as translation keys	Rejected	Copy edits become code changes and context is lost	Use semantic namespaced keys
R-010	Simulate Arabic by right-aligning an LTR document	Rejected	Does not provide correct bidi or layout behavior	Set document-level RTL
R-011	Translate check-in/check-out like hotel terminology	Rejected	Misstates rental operational processes	Use pickup, handover, and return terms by perspective
R-012	Infer currency or legal jurisdiction from locale	Rejected	English, French, and Arabic span multiple markets	Use explicit business data
R-013	Publish placeholder logos, metrics, testimonials, or certifications	Rejected	Creates unsupported evidence	Hide evidence sections until approved sources exist
D-034	Organize the library into foundations, behavior primitives, and marketing composites	Approved	Prevents page-specific composition from masquerading as a reusable primitive	Component APIs and ownership follow explicit tiers
D-035	Share behavior primitives with the future product dashboard, not marketing composites by default	Approved	Marketing and operational interfaces have different density and interaction requirements	Dashboard reuse requires a later density specification
D-036	Use one Button component with primary-blue and conversion-orange intents	Approved	Preserves hierarchy and avoids duplicated behavior	Orange remains restricted to demo and related conversion
D-037	Require content-driven dimensions and prohibit truncation of important copy	Approved	French/Arabic expansion and zoom invalidate fixed text geometry	Components change structure before collision
D-038	Require visible labels for all form fields	Approved	Placeholders disappear and are unreliable accessible context	Placeholder-only fields fail review
D-039	Use native HTML semantics as the baseline for controls, tables, disclosures, and dialogs	Approved	Native behavior reduces accessibility defects	Custom widgets require separate interaction contracts
D-040	Use a native date input as the Phase 3 Gregorian baseline	Approved	Custom date pickers are complex and requirements are unresolved	Custom calendar work is deferred
D-041	Use one culturally neutral full-name field in the demo form	Approved	First/last assumptions fail across naming systems	CRM mapping preserves the complete name
D-042	Keep the demo form minimally qualified	Approved	Extra fields increase abandonment and privacy burden	Required: full name, work email, company, fleet-size range
D-043	Evidence-gate metrics, testimonials, case studies, trust marks, and pricing	Approved	A visual component must not make unsupported content publishable	Missing or expired approval suppresses rendering
D-044	Approve pricing cards and pricing comparison as separate components	Approved	Plan orientation and detailed comparison are distinct tasks	Both may coexist; neither ships without approved pricing
D-045	Open mobile navigation from inline-start	Approved	Aligns navigation origin with document direction	Drawer opens left in LTR and right in RTL
D-046	Require overlay focus containment, inert background, Escape policy, and focus return	Approved	Visual layering without focus management is inaccessible	Drawer/modal implementations need behavioral tests
D-047	Place toasts at inline-end and keep critical errors persistent in context	Approved	Locale-aware placement and durable correction prevent missed failures	Error toasts cannot be the sole error record
D-048	Use the same component tree for LTR and RTL	Approved	Direction-specific implementations drift	Direction is resolved through document state, logical CSS, and selective mirroring
D-049	Respect reduced-motion preferences and keep motion non-essential	Approved	Motion should support continuity, not gate understanding	Shimmer and transforms are removed or minimized
D-050	Use English light/LTR only for the initial specimen while requiring full locale/theme tests	Approved	Gives a concrete first specimen without pretending it proves conformance	Acceptance still requires en/fr/ar and light/dark
R-014	Create separate LTR and RTL component implementations	Rejected	Guarantees drift and mismatched behavior	Use one semantic component tree
R-015	Use fixed-height cards, buttons, labels, or validation regions	Rejected	Breaks expansion, zoom, and Arabic metrics	Use content-driven block sizes
R-016	Publish placeholder metrics, logos, testimonials, certifications, or prices	Rejected	Converts missing evidence into deception	Omit until approval exists
R-017	Open navigation or critical content on hover only	Rejected	Excludes keyboard and touch users	Use explicit triggers and focus behavior
R-018	Use placeholder text instead of visible form labels	Rejected	Loses context after input and harms accessibility	Labels remain visible
R-019	Replace native select/date controls for visual consistency alone	Rejected	Adds keyboard, screen-reader, mobile, and localization risk	Native controls are baseline
R-020	Force marketing composites into the future product dashboard	Rejected	Shared appearance is not shared information architecture	Share primitives; specify product compositions later
R-021	Combine pricing cards and comparison into one shape-shifting component	Rejected	Merges distinct tasks and creates brittle responsive behavior	Maintain separate components
R-022	Auto-dismiss critical errors without a persistent correction path	Rejected	Users can miss failure and lose context	Keep errors in the owning form/page
D-051	Expose Light, Dark, and System as explicit appearance choices	Approved	Users need deterministic control while retaining platform preference support	Theme selector and persistence support all three values
D-052	Persist System as an explicit choice	Approved	System is a user preference, not merely missing state	OS changes update resolved theme while the selector remains System
D-053	Use `hpc-theme` cookie as canonical preference and local storage as a mirror	Approved	SSR needs a readable value; client tabs need immediate synchronization	Cookie wins disagreement; both are written together
D-054	Separate theme preference from resolved theme	Approved	System can resolve to Light or Dark without losing the user choice	Root uses `data-theme-preference` and `data-theme`
D-055	Apply theme before first paint with server state and a tiny inline bootstrap	Approved	Prevents incorrect-theme flash and hydration mismatch	Bootstrap runs before blocking CSS and receives a CSP nonce/hash
D-056	Use deep-navy dark surfaces rather than pure black or mechanical inversion	Approved	Preserves operational hierarchy and reduces glare without flattening the UI	Dark surface ladder uses canvas, surface, subtle, and raised roles
D-057	Use light blue with deep-navy text for routine primary actions in dark mode	Approved	Maintains brand recognition and high contrast without a luminous button wall	Dark primary action roles differ from light while preserving intent
D-058	Use orange-400 with dark text for conversion actions in dark mode	Approved	Meets contrast and preserves controlled conversion salience	Orange remains restricted to demo conversion and related emphasis
D-059	Use neutral-black dark shadows and prohibit colored glow elevation	Approved	Glow reduces precision and makes hierarchy noisy	Elevation uses borders, surface steps, and neutral shadows
D-060	Permit semantically equivalent light/dark hero artwork variants	Approved	Dark presentation may need art direction without changing the product claim	Same content/composition; only presentation treatment changes
D-061	Do not make product screenshots automatically follow website theme	Approved	A screenshot is evidence of an actual product state	Store capture theme metadata; never invert or recolor captures
D-062	Allow paired screenshot variants only for equivalent approved product states	Approved	Theme matching is useful only when evidence remains truthful	Content model records capture theme, locale, direction, and approval
D-063	Use theme-specific chart tokens plus redundant non-color encoding	Approved	Color-only data is inaccessible and fragile across themes	Charts use labels, markers, dashes, patterns, or data tables
D-064	Keep theme changes immediate and non-essential motion reduced	Approved	Global cross-fades create flash, noise, and intermediate contrast failures	No global theme transition; reduced motion removes shimmer/rotation
D-065	Update System mode live when the platform preference changes	Approved	System should continue following its stated source	Media-query changes update resolved theme only while preference is System
D-066	Set `color-scheme` from the resolved theme	Approved	Native controls and browser UI must match the rendered appearance	Selects, dates, autofill, scrollbars, and validation UI require browser testing
R-023	Create dark mode by inverting the light palette	Rejected	Numeric inversion destroys semantic hierarchy and brand intent	Map every role explicitly
R-024	Use pure black canvas and pure white text everywhere	Rejected	Produces harsh contrast and flattens hierarchy	Use deep navy and off-white/blue-gray text roles
R-025	Add blue/orange glows to cards, charts, buttons, or dialogs	Rejected	Turns operational software into decorative noise	Use neutral elevation and restrained emphasis
R-026	Store theme only in local storage and apply after hydration	Rejected	Causes incorrect-theme flash and prevents correct SSR	Use cookie, pre-paint bootstrap, and server state
R-027	Treat System as an unpersisted default	Rejected	Loses the user’s explicit preference	Persist System exactly like Light and Dark
R-028	Recolor, invert, or mirror screenshots for dark mode	Rejected	Misrepresents the product and can corrupt direction/data meaning	Use approved captures or a neutral frame
R-029	Encode chart series or status using color alone	Rejected	Fails accessibility and weakens print/forced-colors behavior	Add labels, markers, patterns, icons, or text
D-067	Use explicit bidi isolation for atomic mixed-direction values	Approved	Arabic labels frequently contain LTR operational identifiers whose punctuation otherwise reorders	Known technical values use `dir=ltr` and `bdi`/isolation at the smallest boundary
D-068	Use `dir=auto` only for genuinely unknown user-authored text	Approved	Known value classes have deterministic direction while free text may not	Translation resources and known identifiers never delegate direction to heuristics
D-069	Mirror icons by semantic metadata rather than global RTL CSS	Approved	Global mirroring corrupts object, status, brand, and evidence assets	Icon instances declare directional, fixed, or contextual behavior
D-070	Keep DOM order aligned with Arabic visual and focus order	Approved	CSS reversal creates inaccessible mismatch and brittle responsive behavior	`row-reverse`, `column-reverse`, CSS `order`, and positive tabindex are prohibited for RTL repair
D-071	Make Arabic mobile navigation enter from inline-start	Approved	Navigation origin should follow document direction	Drawer enters from the right in Arabic and retains full focus management
D-072	Let Arabic workflow progression run from right to left while preserving authored step order	Approved	Process reading should feel native without reversing data or source arrays	Natural RTL layout places step one on the right; mobile remains top-to-bottom
D-073	Keep chronological chart axes and trend meaning independent from RTL	Approved	Data chronology and increase/decrease meaning are domain semantics, not text direction	Charts are not automatically reversed and trend arrows are fixed
D-074	Preserve authoritative license-plate value and segment direction	Approved	Plate formats vary by country and may mix scripts	Latin, Arabic, and segmented plates use explicit direction; country templates remain market configuration
D-075	Require Arabic Light desktop and Arabic Dark mobile validation sheets	Approved	The riskiest direction/theme/responsive combinations need explicit evidence	1440 Light desktop and 390 Dark mobile become release gates
D-076	Confirm Latin digits and Gregorian dates as the Phase 5 language-only baseline	Approved	Phase 2 already separated language from market formatting	Arabic-Indic digits or alternate calendars require explicit market research and configuration
D-077	Use visual arrow-key movement for horizontal RTL tabs and similar composites	Approved	Keyboard commands should match spatial expectation while preserving authored sequence	ArrowLeft moves visually left and ArrowRight visually right; implementation maps to logical index
R-030	Mirror every SVG or image under `dir=rtl`	Rejected	Reverses logos, vehicles, screenshots, status icons, plates, and evidence	Mirror only explicitly directional icons
R-031	Reverse arrays or use CSS row-reverse to make Arabic look correct	Rejected	Breaks DOM/focus order and causes responsive drift	Preserve authored order and rely on document direction/logical layout
R-032	Insert Unicode bidi override characters into translation strings	Rejected	Hidden controls are fragile, difficult to audit, and can create spoofing risk	Use semantic markup and isolation wrappers
R-033	Reverse chronological charts because the page is RTL	Rejected	Text direction does not redefine time or data chronology	Chart order follows the chart specification
R-034	Infer license-plate format, currency, timezone, or country from Arabic language	Rejected	Arabic spans many jurisdictions	Consume explicit business and market configuration
R-035	Leave technical fields RTL and compensate with right text alignment	Rejected	Caret, punctuation, selection, and copy behavior remain broken	Use explicit LTR direction and isolation for known technical values
D-078	Use content-pressure breakpoints rather than device-name breakpoints	Approved	Translated copy, controls, and product evidence fail at different widths	Shared ranges coordinate layout, while intrinsic sizing and container queries control components
D-079	Validate 1440, 1024, and 390 px frames plus a 320 px reflow gate	Approved	Reference designs alone do not prove intermediate or zoom behavior	Automated tests include intermediate widths and 400% zoom equivalent
D-080	Collapse full navigation below 1120 px	Approved	French and Arabic header pressure makes 1024 too narrow for stable full navigation	The 1024 frame uses compact navigation and an inline-start drawer
D-081	Keep the hero stacked below 1120 px	Approved	A forced 1024 split makes either copy or product preview less informative	Tablet uses claim, CTAs, then a full-width readable preview
D-082	Keep the demo action reachable at every width	Approved	Primary conversion cannot disappear because the header becomes compact	Below 480 px the demo CTA is the first drawer action; above it may remain in the header when it fits
D-083	Use art-directed product previews instead of shrinking desktop screenshots below legibility	Approved	Tiny desktop UI ceases to provide product evidence	Mobile uses a focused crop, mobile capture, or coded responsive state
D-084	Prohibit swipe-only carousels for core modules, trust, testimonials, and case studies	Approved	Hidden slides reduce discoverability and create gesture/accessibility dependence	Core content uses grids or vertical stacks; optional carousels require a later explicit exception
D-085	Prohibit page-level horizontal scrolling	Approved	Horizontal page scroll breaks reflow, focus visibility, and mobile use	Tables and atomic technical values may own bounded, labelled overflow
D-086	Preserve semantic pricing tables at constrained widths	Approved	Plan comparison is genuinely tabular and should not become an image or inaccessible card duplicate	Use internal horizontal scroll and a sticky inline-start feature column
D-087	Use a 45rem container threshold for two-column demo-form fields	Approved	The form may sit in sections of different widths at the same viewport	Field layout responds to its own available space
D-088	Require at least 10rem per step for a horizontal workflow	Approved	Breakpoint width alone does not protect French or Arabic step labels	Workflow stays vertical whenever actual content pressure fails the minimum
D-089	Use 18rem module cards, 20rem pricing cards, and 11rem metric cards as minimum readable widths	Approved	Fixed column counts create unreadable intermediate states	Grids use auto-fit/minmax and reduce column count before compressing content
D-090	Never truncate critical headings, labels, buttons, errors, or evidence for responsive fit	Approved	Truncation hides meaning and disproportionately harms French and Arabic	Components wrap, stack, or change structure before reducing readability
D-091	Keep 44 × 44 px minimum targets across all responsive states	Approved	Compact layouts increase, rather than reduce, touch accuracy needs	Headers, drawers, accordions, pagination, and form controls preserve target size
D-092	Remove evidence sections entirely when approved content is absent	Approved	Empty responsive slots invite placeholder or fabricated evidence	No reserved logo rails, metrics, or testimonial gaps are rendered
R-036	Use one global breakpoint set as the only adaptation mechanism	Rejected	Components fail at different content widths	Use shared coordination ranges plus intrinsic and container rules
R-037	Keep desktop navigation at 1024 by shrinking gaps and labels	Rejected	Creates a fragile header that fails translation and zoom	Use compact navigation below 1120
R-038	Hide secondary actions on mobile	Rejected	Removes valid user paths and can trap users in one conversion route	Stack or move actions without deleting them
R-039	Scale a full desktop screenshot to fit mobile	Rejected	Makes product evidence unreadable	Use art-directed captures or coded responsive previews
R-040	Convert core module sections into swipe-only carousels	Rejected	Reduces discoverability and accessibility	Use visible grids/stacks
R-041	Allow body horizontal scrolling for comparison tables	Rejected	Breaks page navigation and reflow	Contain overflow inside the table region
R-042	Ellipsize French or Arabic headings and button labels	Rejected	Hides meaning and creates unequal localization quality	Use content-driven size and structural change
R-043	Use CSS order or DOM duplication to rearrange responsive content	Rejected	Creates focus, reading-order, maintenance, and analytics drift	Keep one semantic source order
R-044	Use fixed heights to maintain card and section alignment	Rejected	Translation, zoom, validation, and dynamic data overflow	Use content-driven block sizing
D-093	Use a workflow-first homepage narrative rather than a generic feature dump	Approved	Buyers need to understand the operating model before comparing modules	Hero, problem, workflow, roles, then modules establish the product story
D-094	Use the reservation-to-return promise as the five-second hero message	Approved	It states category, scope, and operating value without unsupported superlatives	Hero copy stays concrete across en/fr/ar
D-095	Render operational-coverage proof instead of unsupported customer-logo proof	Approved	Product scope can be shown without fabricating external trust	Lifecycle cards follow the hero; logos remain blocked
D-096	Show KPI definitions and measurement methodology instead of invented outcome numbers	Approved	Evaluation rigor is more credible than fictional percentages	Results section contains no claimed improvement values
D-097	Omit the case-study section until an approved customer evidence package exists	Approved	Empty or anonymous proof violates the evidence policy	Conditional insertion point remains after Security and before Pricing
D-098	Present integration categories without naming partners until connector availability is verified	Approved	Named logos imply working production support	Discovery confirms market, connector, and data ownership
D-099	Present security as an evidence-request checklist until certifications and reliability claims are approved	Approved	Badges without scope are decoration, not assurance	No certification, uptime, RTO, or SLA claim renders
D-100	Use quote-oriented pricing preview until the commercial model is approved	Approved	Invented tiers or prices create false expectations	Page explains scope factors and routes to pricing request
D-101	Use a coded, localized, explicitly illustrative product preview	Approved	It proves layout, theme, and RTL behavior without pretending to be production evidence	Replace or approve before launch
D-102	Repeat the demo conversion in header, hero, pricing, and final CTA while reserving orange for conversion	Approved	Repetition improves reach without flattening hierarchy	Routine navigation and product emphasis remain blue
D-103	Use a native dialog for the demo form baseline	Approved	Provides a testable accessible interaction with visible labels and error state	Production integration must complete focus, submission, consent, and analytics testing
D-104	Validate six named production frames plus a 320 px reflow gate	Approved	These frames cover the highest-risk locale, direction, theme, and responsive combinations	Screenshots and automated checks are package deliverables
R-045	Fill the trust strip with fictional customer logos	Rejected	Placeholder logos quickly become accidental production claims	Omit logos until approved
R-046	Publish “up to” performance percentages without methodology	Rejected	The qualifier does not rescue unsupported evidence	Publish only after baseline and source approval
R-047	Add anonymous testimonial quotes	Rejected	Anonymous praise is not verifiable customer evidence	Use an attributable approved case study or omit
R-048	Display common integration logos as visual shorthand	Rejected	A familiar logo still implies a connector exists	Show neutral categories until verified
R-049	Add security badges with “pending” labels to the public page	Rejected	Public users should not see internal evidence placeholders	Keep status in the internal asset and copy registers
R-050	Invent three pricing tiers to make the page look complete	Rejected	Visual completeness is not worth commercial misinformation	Use a quote-oriented preview
R-051	Hide unresolved evidence behind vague superlatives	Rejected	“Trusted,” “leading,” and “proven” are still claims	Use concrete scope, workflow, and evaluation language
R-052	Make the Arabic frame by mirroring the English screenshot	Rejected	It violates true RTL and corrupts product evidence	Render localized coded UI in document-level RTL

| D-115 | Treat the Phase 8 prototype as behavioral reference, not production source code | Approved | Prototype shortcuts and simulations are useful for testing but unsafe to ship | Production rebuild follows typed contracts, real integrations, and release gates | | D-116 | Use framework-agnostic contracts with a documented default capability profile | Approved | The architecture choice is unresolved, but UI behavior cannot remain ambiguous | Any selected stack must satisfy the same SSR, localization, theme, accessibility, and test contracts | | D-117 | Separate theme preference from resolved theme in production | Approved | System must remain an explicit persisted choice | Root exposes both preference and resolved theme before paint | | D-118 | Use hpc-theme cookie as canonical and hpc.theme.preference as local mirror | Approved | SSR and cross-tab behavior require two coordinated stores | Cookie wins disagreement; values are restricted to light/dark/system | | D-119 | Use a 768 px medium and 1120 px wide layout boundary | Approved | Matches distinct compact, medium, and wide composition decisions from prior phases | Reference regression frames include 320, 390, 768, 1024, 1280, and 1440 px | | D-120 | Use typed evidence status on public claim-bearing content | Approved | Rendering copy alone must not imply approval | Pending, expired, or rejected claims are suppressed or use an approved neutral variant | | D-121 | Keep analytics vendor-neutral and prohibit form values or free text | Approved | Vendor selection is open and PII is unnecessary for conversion analysis | Adapter gates events behind approved consent and schema validation | | D-122 | Require idempotent demo submission and preserve values on recoverable failure | Approved | Double leads and lost form data damage trust and sales operations | Submit is disabled in flight; backend accepts an idempotency key | | D-123 | Use relative evergreen browser coverage plus named assistive-technology combinations | Approved provisional baseline | Exact versions decay immediately while coverage obligations remain testable | Product and Engineering must approve an exception/retirement owner before beta | | D-124 | Adopt explicit project performance budgets for mobile conversion paths | Approved provisional baseline | “Fast” is not a test criterion | Release reports against LCP, INP, CLS, TTFB, transfer, request, and font budgets | | D-125 | Block release until participant acceptance and native French/Arabic review pass | Approved | Automated behavior checks cannot establish comprehension or linguistic quality | Phase 8 research and locale review remain High/Critical gates | | D-126 | Suppress unresolved login, sales-contact, pricing, evidence, and legal destinations rather than ship placeholders | Approved | Dead or fictional destinations are worse than omission | Components render only approved links and claims | | R-059 | Copy the Phase 8 prototype directly into production | Rejected | It contains simulation, placeholder destinations, and research-only instrumentation | Rebuild from contracts | | R-060 | Let each component choose raw colors or breakpoint values | Rejected | Creates drift across themes and responsive modes | Consume centralized tokens and matrices | | R-061 | Put locale or direction correction in a client hydration effect | Rejected | Causes incorrect first paint, SEO ambiguity, and accessibility instability | Render document state on the server | | R-062 | Send form values to analytics for “better funnel insight” | Rejected | PII and free text are unnecessary and risky | Track only non-PII state and source metadata | | R-063 | Treat a successful HTTP response as permission to publish success copy | Rejected | Backend semantics and operational routing must match the promise | Contract defines accepted state and next-step code |

38 KiB Raw Blame History Unescape Escape

homePageCar — Decision Log

38 KiB

Raw Blame History