{"slug":"business/V0_RENDERED_UI_REALITY_AUDIT","title":"V0 Rendered UI Reality Audit","section":"business","sectionLabel":"Business","status":"unclassified","type":"document","path":"business/V0_RENDERED_UI_REALITY_AUDIT.mdx","bytes":27977,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n> **Tier C — Historical.** This document is a point-in-time snapshot preserved for reference. For current architecture, see [CANONICAL_PLATFORM_ARCHITECTURE.md](../architecture/CANONICAL_PLATFORM_ARCHITECTURE.md).\n\n**Audit date:** July 11, 2026  \n**Repository:** `NirmalPrinceJ/integratewise-live`  \n**Branch:** `v0/integratewi-1ebfc754`  \n**Primary runnable frontend:** `apps/live` (`@integratewise/live`, Next.js 15.5.20 at runtime)  \n**Audit viewport:** 593 × 765 CSS px, with a 375 × 667 responsive check  \n**Method:** Browser-first route rendering with `agent-browser`, interaction testing, screenshots, console inspection, then source tracing only where rendering was blocked.\n\n## 1. Executive verdict\n\nThe repository contains a very large UI component inventory, but the currently reachable product is not a stable, coherent application shell. The browser-visible reality is:\n\n1. `/` redirects to `/landing`, but the browser is then diverted into a Clerk development/keyless sign-in surface instead of reliably showing the public landing page.\n2. Public onboarding pages render, but visibly carry two overlapping brand treatments, a Clerk missing-keys overlay, stale 2024 footer copy, and a progression action that can remain disabled as `Continuing...`.\n3. Authenticated routes are protected by Clerk, while the embedded `/workspace` application has a second, Cloudflare-auth-based state machine and internal React Router. This creates two auth models and two routing models in one user journey.\n4. The requested Leads route is not a real Next.js page. Marketing Leads exists only as an internal module at `/app/work/leads` inside the `/workspace` MemoryRouter shell. A separate BizOps CRM lead pipeline also exists. There is no routed lead-detail page.\n5. Many screens are coded as polished-looking shells with data hooks, but important visible controls are inert: `Add Lead`, lead rows/cards, `New Campaign`, and numerous card affordances have no handlers or destinations.\n\n**Overall classification: non-deployable UI shell with substantial prototype/component coverage.** The strongest asset is breadth of domain component work. The primary blocker is not lack of screens; it is the absence of one authoritative runtime, route grammar, auth boundary, data contract, and interaction standard.\n\n## 2. Evidence captured\n\n| Evidence                                                                                                                             | Observation                                                                                                                   |\n| ------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |\n| [`audit-evidence/v0-rendered-ui/landing-593x765.png`](audit-evidence/v0-rendered-ui/landing-593x765.png)                             | The nominal landing journey resolves to Clerk's generic development sign-in card, not IntegrateWise marketing UI.             |\n| [`audit-evidence/v0-rendered-ui/onboarding-department-593x765.png`](audit-evidence/v0-rendered-ui/onboarding-department-593x765.png) | Department onboarding at the active preview width: overlapping wordmarks and a Clerk environment warning obscure the product. |\n| [`audit-evidence/v0-rendered-ui/onboarding-department-375x667.png`](audit-evidence/v0-rendered-ui/onboarding-department-375x667.png) | On mobile, the same header collision persists; warning UI obscures middle choices and footer text wraps poorly.               |\n\nBrowser console evidence included:\n\n- Clerk development-key warnings.\n- Clerk structural-CSS warning.\n- Failed RSC payload fetch during Clerk keyless synchronization.\n- Missing `/icon.svg` and `/icon-light-32x32.png` responses.\n- Repeated missing `chat-static` CSS, JavaScript, and font assets during the keyless redirect flow.\n- Clerk's visible `Missing environment keys` prompt on public onboarding pages.\n\n## 3. Runnable frontend and route reality\n\n### 3.1 Which frontend actually boots\n\nThe root `package.json` points `dev` to `@integratewise/live`. `vercel.json` also targets `apps/live/.next`, although its build filter says `live` while the package is named `@integratewise/live`. `apps/web` exists as a separate Next.js 16 package but currently has no `app/**/page.tsx` route inventory in this checkout. No runnable `apps/workspace` package was found.\n\n`apps/live` does boot directly with `pnpm dev` and compiled the tested public routes. However, the root Turbo configuration contains unresolved Git conflict markers around `concurrency`, so the normal monorepo task path is invalid.\n\n### 3.2 Next.js route inventory\n\n| Route family                                 | Browser/HTTP reality                                                       | Classification                                       |\n| -------------------------------------------- | -------------------------------------------------------------------------- | ---------------------------------------------------- |\n| `/`                                          | 307 to `/landing`                                                          | Redirect only                                        |\n| `/landing`                                   | HTTP 200, but browser was taken into Clerk keyless sign-in synchronization | Broken public entry                                  |\n| `/login`, `/signup`                          | HTTP 200; Clerk-backed pages                                               | Auth prototype; brand/runtime mismatch               |\n| `/onboarding`                                | 307 to `/onboarding/email-verification`                                    | Redirect only                                        |\n| 14 onboarding step routes                    | Source pages exist; first steps compiled and rendered publicly             | UI prototype; progression not trustworthy            |\n| `/dashboard`                                 | Protected by Clerk; simple zero-state dashboard in source                  | Stub/prototype                                       |\n| `/workspace`                                 | Protected by Clerk; mounts the large internal app in a MemoryRouter        | Main product prototype, not externally deep-linkable |\n| `/capabilities`                              | Protected standalone page                                                  | Prototype                                            |\n| `/integrations`                              | Protected standalone page                                                  | Prototype                                            |\n| `/schema`                                    | Protected standalone page                                                  | Prototype                                            |\n| `/leads`, `/lead/:id`, `/admin`, `/settings` | No Next.js pages                                                           | Missing as actual routes                             |\n\n### 3.3 Route grammar conflict\n\nThree incompatible route grammars coexist:\n\n- Next.js pages: `/dashboard`, `/workspace`, `/integrations`, `/schema`, `/capabilities`.\n- Internal MemoryRouter paths: `/app/work/<module>` and `/app/personal/<module>`.\n- Dashboard links to absent Next.js routes such as `/settings/team`.\n\nBecause `/workspace` mounts a `MemoryRouter`, internal navigation changes memory history rather than the browser's actual Next.js route. Source comments and handlers refer to `/app/work/dashboard`, but there is no Next.js `/app` route. A refresh or pasted deep link therefore does not reliably reconstruct the intended product surface.\n\n## 4. Auth and onboarding reality\n\n### Critical: two independent auth systems\n\nThe root Next.js application is wrapped in `ClerkProvider`; middleware and the protected app layout use Clerk. Inside `/workspace`, `AppShell` uses a separate Cloudflare auth context and a local onboarding metadata cache. The source documentation still mentions Supabase PKCE in places. This is not merely stale copy: it produces two login/onboarding state machines with different session assumptions.\n\n### Browser-observed onboarding defects\n\n1. **Header collision:** a green `Integrate Wise` mark and black `IntegrateWise` title occupy the same horizontal position. This is visible at both tested widths.\n2. **Environment prompt blocks the flow:** Clerk's dark missing-keys card overlays department options.\n3. **Interaction can dead-end:** selecting Customer Success and clicking `Next: Business Goals` changed the button to disabled `Continuing...`, but the URL remained `/onboarding/department` after the check.\n4. **Cards are generic clickable containers:** the accessibility tree exposes department cards as generic clickable elements, not radio inputs or buttons with selected state.\n5. **Progress lacks meaning:** the header exposes the literal text `Step indicators`, not a useful current-step/total-step label.\n6. **Copy is stale:** footer says `© 2024` in a 2026 product build.\n7. **Onboarding taxonomy diverges from workspace taxonomy:** onboarding offers Sales, Customer Success, Finance, Operations, Executive, and Support, while the workspace domain model includes 12 different domain keys and labels.\n\n## 5. Leads page audit\n\n### 5.1 The canonical Leads route does not exist\n\nThere is no `/leads` Next.js page and no `/lead/:id` page. The visible product has two competing lead concepts:\n\n- **Marketing Leads**: internal module ID `leads`, intended path `/app/work/leads`, implemented by `MarketingLeadsView`.\n- **BizOps CRM**: internal module ID `crm`, a lead pipeline with Kanban/list modes, implemented by `CRMView`.\n\nThis ambiguity should be resolved before visual redesign. Marketing-qualified leads and sales/CRM leads may be related projections, but they should not be two unrelated UI grammars without explicit ownership and navigation.\n\n### 5.2 Marketing Leads information architecture\n\nCurrent structure:\n\n- Header: `Leads`\n- Search input\n- `Add Lead` button\n- Table-like CSS grid columns: Lead, Source, Score, Status, Last Activity\n- Empty state when no projection data exists\n\nWhat is good:\n\n- Compact scanning hierarchy.\n- Search is implemented as local filtering.\n- The empty state accurately states a connector dependency.\n- Lead score uses visual severity coloring.\n\nWhat fails:\n\n- `Add Lead` has no handler.\n- Rows look clickable but have no click handler, link, selected state, keyboard behavior, or destination.\n- No lead detail route, drawer, or side panel exists.\n- No sorting, stage filter, ownership filter, bulk selection, pagination, saved view, import, or deduplication path.\n- Fixed five-column CSS grid has no responsive fallback and will compress or overflow at narrow widths.\n- Loading, request failure, stale data, and permission-denied states are not separately rendered.\n- “Last Activity” is raw unformatted source data.\n\n**Classification:** read-only projection prototype.\n\n### 5.3 BizOps CRM information architecture\n\nCurrent structure:\n\n- CRM title and descriptive subtitle\n- `Add Lead`\n- Four KPI cards\n- Search, stage filter, and Kanban/list toggle\n- Four pipeline stages\n- Lead cards or table rows\n\nWhat is good:\n\n- Better operational hierarchy than Marketing Leads.\n- Provides stage and view filters.\n- Includes pipeline value, conversion rate, qualified count, score, owner, source, and value.\n\nWhat fails:\n\n- `Add Lead` has no handler.\n- Cards and rows appear clickable but do nothing.\n- No drag/drop or explicit stage transition action exists.\n- No lead detail, activity composer, audit trail, conversion confirmation, duplicate management, or owner reassignment.\n- Source is represented with emoji, conflicting with the rest of the Lucide icon system and reducing enterprise consistency.\n- At 593 px, the `grid-cols-2` Kanban still forces two dense columns; at 375 px it remains two columns because the base is `grid-cols-2`.\n- The list table has no horizontal-scroll wrapper.\n- `company.toLowerCase()` and other assumptions can throw on incomplete records.\n\n**Classification:** richer interactive-looking prototype; most consequential actions are missing.\n\n### 5.4 Expected Leads interaction grammar\n\nA real Leads surface needs one consistent grammar:\n\n- `/app/work/leads` or a real Next.js equivalent as the collection route.\n- `/app/work/leads/:leadId` or a deterministic side-panel deep link as detail.\n- Search, filter, sort, saved views, and bulk selection.\n- Add/import lead flows with validation, duplicate detection, ownership, and source attribution.\n- Stage change with confirmation or undo and an audit event.\n- Detail tabs: Overview, Activity, Relationships, Evidence, Decisions, Governance.\n- Clear loading, empty, error, offline, stale, and unauthorized states.\n- Every row/card reachable by keyboard with a visible focus state and semantic link/button behavior.\n\n## 6. Major product surfaces\n\n| Surface                          | Actual state                                                                                        | User-risk                                         |\n| -------------------------------- | --------------------------------------------------------------------------------------------------- | ------------------------------------------------- |\n| Landing                          | Implemented in source, not reliably reachable in browser due Clerk keyless flow                     | Critical acquisition failure                      |\n| Login/signup                     | Clerk surface plus separate Cloudflare auth inside workspace                                        | Critical identity inconsistency                   |\n| Onboarding                       | 14 source routes plus a second six-step embedded onboarding flow                                    | Critical duplicated journey                       |\n| Dashboard                        | Basic zero-state cards with hard-coded 0/1 values                                                   | High; looks disconnected from product             |\n| Workspace shell                  | Broad internal UI with Work/Personal views and projected nav                                        | High-potential prototype, blocked by auth/routing |\n| Account Success                  | Deepest component family; many views and an entity-centric model                                    | Medium-to-high; needs runtime proof               |\n| Sales                            | Dashboard, pipeline, Kanban, deals, contacts, activities, forecasting, quotes, sequences, analytics | Prototype coverage                                |\n| Marketing                        | Campaigns, leads, analytics, channels, forms                                                        | Read-heavy prototype                              |\n| RevOps                           | Pipeline, forecast, quotas, cohorts, metrics, review, decisions                                     | Prototype coverage                                |\n| Product & Engineering            | Incidents, roadmap, features, bugs, sprints, releases, analytics, feedback                          | Prototype coverage                                |\n| Finance                          | Revenue, expenses, reports, forecast, budget, approvals                                             | Prototype coverage                                |\n| Service                          | Tickets, customers, knowledge, analytics, satisfaction, SLA                                         | Prototype coverage                                |\n| Procurement                      | Renewals, vendors, orders, contracts, spend, savings                                                | Prototype coverage                                |\n| IT Admin                         | Systems, incidents, vulnerabilities, certificates, licenses                                         | Prototype coverage                                |\n| Student/Teacher                  | At-risk, students, courses, assignments, gradebook                                                  | Prototype coverage                                |\n| Personal                         | Dashboard, today, projects, decisions, knowledge, tasks, calendar, notes                            | Prototype coverage                                |\n| BizOps                           | Very broad super-domain with cross-department copies of modules                                     | Severe navigation overload risk                   |\n| Admin                            | Large component inventory but no standalone Next.js `/admin` route                                  | Inaccessible/inconsistent                         |\n| Settings                         | Internal module exists; dashboard links to missing `/settings/team`                                 | Broken navigation                                 |\n| Capabilities/integrations/schema | Standalone protected pages outside the main internal route grammar                                  | Fragmented architecture                           |\n\n## 7. Navigation and shell audit\n\n### Strengths\n\n- Work and Personal are explicit top-level concepts.\n- Domain configuration centralizes much of the menu vocabulary.\n- Command palette and notification center exist.\n- Lazy module loading and module error boundaries are present.\n\n### Problems\n\n1. **Navigation authority is not singular.** Projection-native navigation, database product navigation, domain config fallback, and a static `MODULE_PATH_MAP` all compete.\n2. **Declared links and loaded modules do not fully match.** Example: Account Success nav declares `risk-matrix`, `engagement-log`, `cs-queue`, and `knowledge`, while the content map uses other keys or omits some mappings.\n3. **MemoryRouter masks route integrity.** Browser URL, Next.js route, and internal active path can diverge.\n4. **Domain config uses emoji icons**, while the shell otherwise relies on Lucide.\n5. **BizOps duplicates every other domain** through prefixed module IDs, producing an enormous navigation surface rather than a task-oriented operations center.\n6. **Admin/settings live in multiple places** and do not have a coherent permission-aware route hierarchy.\n7. **Error recovery points to nonexistent `/app/work/dashboard`** at the Next.js layer.\n\n## 8. Visual consistency and density\n\nThe UI is not one design system in practice. Observed and source-traced patterns include:\n\n- Clerk's purple generic auth UI versus IntegrateWise forest/gold product styling.\n- Onboarding's pale blue cards and black CTA versus the forest/gold workspace.\n- Simple dashboard cards using direct Tailwind slate/blue/green/purple/orange values.\n- Workspace modules using `--iw-*` tokens, semantic tokens, direct hex values, inline styles, gradients, and emoji in parallel.\n- Multiple shell concepts: standalone Next pages, `WorkspaceShellNew`, `UnifiedShell`, `WorkShell`, `PersonalShell`, plus deprecated shells.\n\nDensity also varies sharply: onboarding is spacious and card-heavy, the dashboard is generic SaaS spacing, and domain tables use 10–12 px labels and fixed desktop grids. The product does not yet feel like a deliberate adaptive-density system; it feels like several design eras composed together.\n\n## 9. Loading, empty, error, and failure states\n\n### Existing\n\n- Generic module Suspense/loading support.\n- Module error boundary with Retry.\n- Empty messages in several domain views.\n- Onboarding buttons expose loading labels.\n- A top-level “Something went wrong” screen exists.\n\n### Missing or misleading\n\n- Data loading often collapses to an empty collection, making “no data” indistinguishable from “not loaded” or “request failed.”\n- No common stale/offline/permission-denied state grammar.\n- Top-level error state uses an emoji and a gradient, unlike the normal product system.\n- Retry resets the local boundary but does not guarantee refetch or invalidation.\n- Error action routes are not valid Next.js routes.\n- Buttons can enter indefinite disabled states.\n- Connector-dependent empties often provide no direct, working connector CTA.\n\n## 10. Responsive behavior\n\n### Browser-observed\n\n- At 593 × 765 and 375 × 667, the onboarding wordmark/title collision persists.\n- The Clerk environment warning obscures interactive cards at both widths.\n- Footer text wraps into a visually weak two-line block on mobile.\n- The page itself remains scrollable and the primary button stays within viewport width.\n\n### Source-traced risks\n\n- Marketing Leads uses a fixed five-column grid without mobile collapse or horizontal scrolling.\n- BizOps CRM uses two Kanban columns at its smallest breakpoint rather than one.\n- Several data tables have no `overflow-x-auto` parent.\n- The shell is designed around a full desktop navigation/content frame; mobile navigation behavior could not be authenticated and proven.\n- Widespread 10 px labels and compact controls are below a comfortable enterprise-mobile reading target.\n\n## 11. Interaction matrix\n\n| Interaction                   | Observed/implemented behavior                 | Verdict                           |\n| ----------------------------- | --------------------------------------------- | --------------------------------- |\n| Root entry                    | Redirects into Clerk keyless flow             | Broken                            |\n| Department select             | Selection changes visually                    | Partial                           |\n| Department Next               | Can remain `Continuing...` without navigation | Broken                            |\n| Marketing lead search         | Local filter                                  | Works in source                   |\n| Marketing Add Lead            | No handler                                    | Inert                             |\n| Marketing lead row            | Cursor/hover only                             | Inert                             |\n| CRM search/filter/view toggle | Local state logic exists                      | Prototype functional              |\n| CRM Add Lead                  | No handler                                    | Inert                             |\n| CRM lead card/row             | Cursor/hover only                             | Inert                             |\n| Dashboard Manage Team         | Links to nonexistent `/settings/team`         | Broken                            |\n| Workspace deep links          | Internal MemoryRouter only                    | Not refresh-safe                  |\n| Module error Retry            | Resets boundary state                         | Partial                           |\n| Command palette               | Implemented in shell                          | Not runtime-proven due auth block |\n| Notifications                 | Implemented in shell                          | Not runtime-proven due auth block |\n\n## 12. Broken UI and engineering defects\n\n### P0 — prevents trustworthy evaluation or deployment\n\n1. Clerk keys/environment are not configured for the active preview; warning UI and keyless synchronization alter the rendered experience.\n2. Public landing is not reliably public in the browser.\n3. Clerk-protected Next shell conflicts with Cloudflare auth inside `/workspace`.\n4. Internal `/app/...` routing has no corresponding Next.js route ownership.\n5. Root `turbo.json` contains unresolved merge-conflict markers.\n\n### P1 — breaks core product journeys\n\n1. Onboarding can dead-end on `Continuing...`.\n2. Two different onboarding systems exist.\n3. Leads has no detail route and primary actions are inert.\n4. Dashboard contains missing-route links and hard-coded zero values.\n5. Navigation/module keys can diverge.\n6. No unified loading/error/empty/offline grammar.\n\n### P2 — damages usability and product confidence\n\n1. Overlapping onboarding brand header.\n2. Missing icon assets and Clerk static-asset errors.\n3. Fixed desktop grids on Leads and other tables.\n4. Emoji mixed with Lucide icons.\n5. Stale copy and architecture comments.\n6. Multiple visual token systems and direct color usage.\n\n## 13. Prioritized fix backlog\n\n### Phase 0 — establish one runtime contract\n\n1. Choose the production auth owner: Clerk **or** Cloudflare auth. Remove the other from the user-facing runtime.\n2. Choose the route owner: Next.js App Router is recommended. Replace MemoryRouter-only paths with actual App Router segments or a single intentional catch-all route.\n3. Fix `turbo.json` conflict markers and verify the root dev/build commands.\n4. Make `/landing`, `/login`, and `/signup` deterministic without keyless detours.\n5. Add a sanctioned audit/demo tenant or test-session mechanism so every protected surface can be rendered in CI and browser audits.\n\n### Phase 1 — restore coherent first-run experience\n\n1. Keep one onboarding flow and one domain taxonomy.\n2. Repair the overlapping brand header and remove environment overlays from production UI.\n3. Make each step semantic, keyboard-accessible, resumable, and failure-aware.\n4. Add explicit step count, Back, Save and exit, retry, and support paths.\n5. Verify every step at desktop and mobile widths with persisted state.\n\n### Phase 2 — make Leads the reference L1 surface\n\n1. Define canonical collection and detail routes.\n2. Reconcile Marketing Leads and BizOps CRM ownership.\n3. Implement Add, import, row navigation, detail, stage changes, owner assignment, and activity timeline.\n4. Add loading, empty, error, stale, offline, unauthorized, and connector-not-configured states.\n5. Add responsive list/card behavior and table horizontal scrolling where necessary.\n6. Use this screen as the template for Accounts, Deals, Contacts, Tickets, Vendors, and other entity collections.\n\n### Phase 3 — normalize the shell and design system\n\n1. One shell, one header, one navigation authority, one icon system.\n2. Resolve navigation from a validated surface registry rather than four competing sources.\n3. Standardize page header, KPI strip, toolbar, collection, detail, drawer, modal, and status components.\n4. Define three supported density modes and minimum typography/touch targets.\n5. Remove direct palette values and stale/deprecated shells from active imports.\n\n### Phase 4 — prove every declared surface\n\n1. Generate automated route/surface checks from the registry.\n2. Add browser smoke tests for every domain's dashboard and primary entity.\n3. Report unhandled buttons, invalid internal links, console errors, and absent empty/error states.\n4. Gate deployment on no broken routes, no auth warnings, and no critical console failures.\n\n## 14. Recommended acceptance criteria for the next audit\n\n- Public landing renders IntegrateWise at `/landing` without external/keyless detours.\n- One login creates a session recognized by all product routes.\n- Every main navigation item has a refresh-safe URL.\n- `/leads` collection and `/leads/:id` detail both render and complete create/update flows.\n- No primary-looking button is inert.\n- No console errors, missing assets, or environment overlays.\n- All L1 collections distinguish loading, empty, error, stale, unauthorized, and offline states.\n- Desktop, 593 px, and 375 px screenshots show no overlap, clipping, inaccessible content, or forced unreadable grids.\n- Surface registry and rendered route inventory match exactly.\n\n## 15. Bottom line\n\nIntegrateWise has enough component breadth to demonstrate the intended operating-system vision, but the rendered product is currently governed by competing runtimes rather than a coherent UI contract. The fastest route to a real product is not adding more domain screens; it is consolidating auth, routing, shell, and state grammar, then turning Leads into the first fully operational L1 reference surface.\n"}