# 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-105 | Treat Phase 8 as behavior validation, not aesthetic preference collection | Approved | Completion, comprehension, recovery, accessibility, and confidence are actionable; taste polling is not | Script uses task outcomes and neutral probes |
| D-106 | Use a coded local prototype with deterministic query states | Approved | Reproducible states support moderation, accessibility checks, and automation | Demo, tour, locale, theme, navigation, failure, and research modes are addressable |
| D-107 | Persist explicit locale and theme choices while preserving URL state and section hash | Approved | Context loss invalidates language and appearance tasks | Locale reload keeps hash; theme applies immediately and survives reload |
| D-108 | Replace the Phase 7 product-tour anchor with a four-step guided tour | Approved | A control labeled “Watch product tour” must produce tour behavior rather than merely scroll | Final media may replace it after asset approval |
| D-109 | Simulate demo success and service failure without sending participant data | Approved | The flow can be tested before CRM and consent integration without creating accidental leads | Prototype clearly states no request was sent |
| D-110 | Keep prototype analytics session-local and exclude all entered values | Approved | Research needs interaction evidence without collecting names, emails, companies, or free text | Export contains event metadata only |
| D-111 | Require 15 core participants across EN/FR/AR plus dedicated accessibility evidence | Approved | One-language five-user testing cannot establish multilingual or RTL behavior | Pilot and accessibility rounds remain separate evidence classes |
| D-112 | Report locale cohorts separately before aggregating | Approved | An English majority can conceal Arabic or French failure | Acceptance includes per-locale floors |
| D-113 | Treat multi-location support as a comprehension and evidence question until capability is approved | Approved | Existing copy implies location awareness but does not prove feature scope | Task measures over-inference and required clarification |
| D-114 | Block release on unresolved Critical or High usability and accessibility issues | Approved | Conversion averages cannot excuse exclusion or a broken primary path | Fix and retest affected cohorts |
| R-053 | Ask participants whether they like the design | Rejected | Preference is weak evidence and invites politeness bias | Ask users to perform real tasks and explain expectations |
| R-054 | Use five English desktop participants as proof for all locales and devices | Rejected | It ignores translation expansion, RTL, mobile behavior, and cohort differences | Balance language, role, device, and accessibility coverage |
| R-055 | Send prototype form data to a real CRM | Rejected | Creates privacy, consent, routing, and accidental-sales risk | Simulate success and failure locally |
| R-056 | Record participant-entered form values in analytics | Rejected | Names, emails, companies, and free text are unnecessary for interaction analysis | Capture event names and non-PII context only |
| R-057 | Aggregate results before inspecting locale cohorts | Rejected | Strong English results can hide Arabic failure | Apply cohort floors and report separately |
| R-058 | Close a severe issue after designer inspection alone | Rejected | The affected users, device, locale, or access method must prove the repair | Retest with the cohort that exposed it |

| 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 |