A v2 interface for Devlane, built on shadcn/ui — feedback wanted before I open the PR

[YSamed]

I've been working on a second interface for the Devlane web app, built with shadcn/ui. It's now complete enough that I'd like to get your feedback before opening a large PR.

Branch: [YSamed:feat/shadcn-design-system](https://github.com/YSamed/devlane/tree/feat/shadcn-design-system)

Why

The main goal is to improve the user experience by making the interface more consistent and easier to use.

The current UI has evolved organically over time, so things like spacing, borders, empty states, menus, and common interactions can look or behave differently across pages.

Rather than refactoring the existing interface page by page and risking regressions for current users, I built the new interface alongside it using shadcn/ui and a shared component system.

The existing UI remains unchanged, and the new interface is optional, so users can switch to it whenever they want.

How it works

v2 is a preference, not a separate route.

Both interfaces use the same URLs. routes/index.tsx defines each route once and selects the interface using <Variant v1={…} v2={…} />.

The selected interface is stored in localStorage under devlane-interface-version, and users can switch between versions from Settings.

This also means shared links continue to work normally. The same URL opens using the recipient's preferred interface.

The two interfaces are isolated from each other.

All v2 code lives under apps/web/src/v2/, following roughly the same structure as the existing src/ directory.

An ESLint rule prevents code outside src/v2/ and src/routes/ from importing v2 modules.

v2 styles are loaded by the v2 shell instead of the global stylesheet, so users on v1 do not download them.

The existing v1 files remain unchanged, except for a single <InterfaceSwitch /> entry in pages/SettingsPage.tsx, whose implementation lives under routes/.

What's included

The new interface currently covers around 31 pages, including workspace home, projects, work items, work item details and creation, epics, cycles, modules, views, pages, drafts, archives, intake, analytics, notifications, settings, and the full authentication flow.

It also includes around 40 shadcn/ui primitives using the new-york style, slate base colors, and Lucide icons.

Turkish translations are included alongside English using i18next.

I've also added an AGENTS.md file that documents the design direction and reference sources so future contributors have a clear foundation to work from.

API change

There is one small additive API change in apps/api/internal/handler/user.go.

When a user activity entry has no free text comment, the response now also includes verb, field, old_value, and new_value.

This allows the client to generate the activity description in the user's selected language instead of receiving a prebuilt English sentence.

The existing description field remains unchanged, so current consumers should not be affected.

There are no schema changes, new environment variables, or new instance settings.

Screenshots

What I'd like your opinion on

Before opening the full PR, I'd especially like your opinion on two points.

1. Should v2 remain optional?

   It is currently disabled by default, and users can enable it themselves from Settings.

   Do you think it makes more sense to keep it this way, or should the goal eventually be to make v2 the default interface for new users?

2. What should the long term direction for v1 be?

   If the goal is to eventually replace v1, I can focus future work on migration and feature parity.

   If both interfaces are expected to coexist long term, I can structure the work around keeping them properly isolated and synchronized where necessary.

The main thing for me is that this work fits the overall direction of the project. Before opening the large PR, I'd like to understand which direction you think makes the most sense.

I can adjust the structure and next steps based on your feedback.

[YSamed]

Quick update: I decided not to hold the code back while this thread waits for answers, so the PR is now open and out of draft — #401.

All three checks are green (API CI, UI CI, CodeRabbit). One caveat: CodeRabbit skipped the automated review because the PR has 173 files and its limit is 100, so this one needs human eyes.

The two questions above still stand, and neither of them blocks reviewing the code — v2 is opt-in and off by default either way, so the answers change what I build next rather than what is in this PR:

1. Should v2 stay opt-in, or eventually become the default for new users?
2. Is the long-term goal to replace v1, or to keep both?

@Devlaner/maintainers — whenever someone has time to take a look, I would appreciate it. Happy to restructure the PR if the size is a problem.