Completed Phase 6 pixel-faithful UI rollout and fixes

Summary

Closed, Completed

Understand
Reviewed architecture, CLAUDE, and memory docs; mapped current progress.
Understand
Plan
Defined Phase 6 scope and planned implementation steps.
Plan
Build
Implemented Tailwind, endpoints, UI components, and backend APIs in 11 steps.
Build
Verify
Tested endpoints, UI rendering, and fixed bugs including grounding and DB migration blockers.
Verify
Edit
Reworked landing page to restore scroll-scrub animation and fixed sticky header bug.
Edit

I want you to go through the architecture.md, claude.md, and memory.md. Understand where we are standing with our current progress and the codebase. Fully map and make sure we are progressing in the correct direction. If so, let's cook phase 6.

I'll map the current state first. Let me read the architecture and memory docs, and explore the codebase in parallel.

ReadARCHITECTURE.md

Architecture and CLAUDE.md are clear. The git log shows we've completed through the relationship graph (Layer 2). I need to pin down what "phase 6" means in this repo's own numbering. Let me read the spec and explore the codebase state in parallel.

Readspec.md

Now I have the full picture. Phase 6 = the pixel-faithful UI (Today, Ask, Relationships, Search) + onboarding stepper + landing page. Phases 0–5 (spine, ingestion, retrieval, graph, hardening) are substantially in place; the app currently only has a minimal ask page and a stub home page.

Let me explore the design source-of-truth, the current frontend state, and the backing APIs in parallel.

Readpage.tsx

I now have the shape of Phase 6 clearly. Let me deeply map two things in parallel before designing: the exact mockup design (4 screens + landing), and the backend API surface that will feed the screens.

Used Agent

I now have a complete map. Here's where things stand:

Done (Phases 0–5, the backend spine): Google auth + multi-tenancy, connectors (Gmail, Calendar, Linear, Slack, Notion), Trigger.dev ingestion, the full retrieval pipeline (plan → hybrid search → graph expand → rollup → assemble → streamed synthesis), /api/answer, /api/graph, Composio connect/callback, Slack webhooks, Sentry + Langfuse. (Note: a few Phase 5 hardening items — rerank.ts, rail.ts, semantic-cache.ts — aren't in the tree yet, but those aren't Phase 6.)

Phase 6 = the UI, and it's almost entirely greenfield. Today the frontend is just a bare app/ask/page.tsx, a stub home page, a 4-line globals.css, and no app shell. Phase 6 needs: the sidebar + top-bar shell, the four pixel-faithful screens (Today, Ask, Relationships, Search), the onboarding stepper, and the landing page — plus three small backing endpoints (/api/today, /api/search, /api/connections) since those don't exist yet.

Direction is correct and on-sequence (spec §5 explicitly says do Phase 6 Today+Ask right after the spine). Before I write the plan, three decisions materially shape it:

Used AskUserQuestion

Decisions locked: full Phase 6, structured /api/today, add Tailwind. Let me have a Plan agent design the implementation with all this context, then I'll write the final plan.

Used Agent

The Plan agent produced a thorough, validated design. Let me write the final plan file.

The plan is written. Here's the summary before you approve.

Where we stand: The backend spine (Phases 0–5) is on main and correct — auth, 5 connectors, Trigger.dev ingestion, the full retrieval pipeline, /api/answer, /api/graph, Composio flows, Sentry + Langfuse. Direction is on-sequence: spec.md §5 puts Phase 6 right after the spine. (Minor note: a few Phase 5 hardening files — rerank.ts, rail.ts, semantic-cache.ts — aren't in the tree, but they're out of Phase 6 scope.)

Phase 6 = the UI, almost entirely greenfield. The plan covers, per your three decisions:

Tailwind added with the design tokens encoded, Inter via next/font, legacy Ask page kept alive during migration.
App shell ((app) route group): server-component layout feeding a client sidebar (live source dots, founder footer) + route-aware top bar with ⌘K.
Four screens rebuilt pixel-faithful over real per-tenant data with loading/empty states — including a hand-rolled deterministic SVG graph (no new dep, node-capped for real-data readability).
Structured /api/today (retrieve() + grounded generateObject, with a citation guard that drops any invented item_id), plus new /api/search and /api/connections.
Onboarding stepper (connect → poll → unlock on first items landing) and the landing page ported with CSS-only motion + reveal, deferring the fragile scroll-scrub.
An 11-step commit sequence on feature/pixel-faithful-ui with the Greptile 5/5 gate, verifiable against the canonical tenant via the DEV_USER_ID fallback.

Full detail is in the plan file.

Grepped

Used ExitPlanMode

Understood on both: I'll work in auto mode (proceed through the full 11-step sequence without stopping for per-step approval) and keep a running phase6-trade-offs.md documenting every trade-off and shortcut I make as I build. Let me re-confirm exit from plan mode so I can start editing.

Used ExitPlanMode

Plan approved. I'll isolate work in a worktree first (background-job requirement), then track the 11 steps and start building.

Used EnterWorktree

Now in an isolated worktree on worktree-feature+pixel-faithful-ui. Let me start with Step 1 (Tailwind) and read the files I'll touch early, in parallel. First let me create the trade-offs doc and read the current state of key files.

Readlayout.tsx

Readglobals.css

Readpage.tsx

Readnext.config.mjs

Readmiddleware.ts

Let me read the backend files I'll reuse for the new endpoints, so I get signatures exactly right.

Readpipeline.ts

Readtypes.ts

Readroute.ts

Let me read the remaining reuse targets so my new endpoints match exact signatures.

Readsession.ts

Readsupabase.ts

Readregistry.ts

Readtypes.ts

Readsync-state.ts

Readgateway.ts

Readlangfuse.ts

Readrollup.ts

Readroute.ts

Readtsconfig.json

I have all signatures. Starting Step 1: Tailwind + tokens, and creating the running trade-offs doc. Writing config files and the trade-offs log:

Now update globals.css and the root layout, and install the Tailwind deps.

Now the root layout with Inter + AuthProvider, the AuthProvider component, and installing deps in parallel:

Deps installed. Let me verify the build/typecheck is green before moving on.

Typecheck green. Committing step 1, then moving to the new endpoints (step 3) and routing (step 2).

Step 1 committed. Now Step 3: the three new endpoints + Zod schemas (screens depend on them). Writing the schemas first:

Now the three endpoints:

Let me check search.ts and plan.ts signatures before writing the search route.

Readsearch.ts

Readplan.ts

Now the search route:

Now the Today route (the heart of the phase) with the grounding guard:

Let me typecheck the new endpoints before moving on.

Endpoints clean. Committing, then building the app shell + routing (steps 2 & 4).

Now steps 2 & 4: routing + app shell. Let me read the App mockup to match icons and structure exactly.

ReadZrux App.dc.html

I have the complete mockup. Now building the shared icons + format utils, then the shell. Writing the icon set:

Now the format + source helpers:

Now the shell components. SourceDots (polls connections), Sidebar, and TopBar:

Now the app shell layout (server component):

Now the routing wiring: I'll build the screens. First shared UI primitives (EmptyState, Skeleton):

Now the Today screen + BriefCard:

Now the Ask screen (step 6) — the most involved. Building its subcomponents first:

Now the Ask page:

Now removing the conflicting old pages (both rebuilt under route groups):

Now the Search screen (step 7) — ResultCard with highlight, then the page:

Now the Relationships graph (step 8). First the deterministic layout algorithm:

Now the Relationships page tying it together:

Now a marketing landing (minimal working version; full port in step 10) and the onboarding page so / and the connect flow work. First let me build to catch errors early with what I have — I'll add a temporary minimal landing:

Now the onboarding stepper (step 9):

Now let me typecheck and build everything so far.

200 of 484