Feature/backend ts support andunification of auth settings on frontend

[blackmammoth]

Summary

This PR does two related jobs:

1. It cleans up the frontend auth/settings/provider flow so provider state is easier to reason about, less coupled to project state, and named more accurately.
2. It turns the backend into a first-class typed/buildable target with reliable alias resolution, stable runtime path handling after compilation, and enforced module boundaries.

Although the commits span both frontend and backend concerns, they all move the codebase in the same direction: clearer ownership, less hidden coupling, and tooling that matches how the app actually runs.

Why this was needed

On the frontend, provider authentication state and settings behavior had become spread across onboarding, settings, and agent-management UI. Some of that logic still depended on project-specific context even though provider auth status is global application state, not project state. There were also stale controller arguments and naming that no longer reflected the domain well. That made the code harder to reuse and easier to break when one surface changed another.

On the backend, the project had outgrown a frontend-first tooling setup. Alias imports, linting, runtime path assumptions, and the actual server build path were not aligned. We also had no architecture guardrail around server/modules, so module internals could be imported directly without going through a public entry point. That kind of coupling is cheap in the short term but costly as modules grow.

This PR addresses both categories by reducing implicit coupling and making the intended boundaries explicit.

Frontend changes

Decoupled provider auth state from project-specific settings flows

The provider auth status logic was moved into a dedicated custom hook. This was needed because onboarding, settings, and related UI were each carrying pieces of the same provider-status behavior. Centralizing that logic gives the app a single place to answer questions such as which providers are authenticated, how loading/error state should behave, and which UI branches should render.

This reduces duplication and makes the provider-auth behavior reusable across multiple screens without forcing those screens to know how the status is derived.

Removed project dependency from settings/onboarding logic

Settings and onboarding were carrying project-dependent behavior that did not belong in those flows. That dependency made global settings behavior harder to reuse and harder to test because screens that should only care about provider/account state were indirectly coupled to project context.

This was simplified so settings/onboarding can make decisions from the right source of truth instead of depending on project state they do not actually own.

Removed obsolete controller surface

useSettingsController no longer takes the unused onClose argument. That argument had become stale and keeping it around made the API noisier and more misleading than the actual behavior.

Removing it makes the controller contract smaller and clearer.

Renamed SessionProvider to LLMProvider

The previous name suggested session ownership, but the actual concept being modeled is the selected large-language-model provider. Renaming this to LLMProvider makes the code read closer to the product/domain language and removes a layer of translation when navigating chat, onboarding, sidebar, and provider-auth code.

This kind of rename matters because it reduces ambiguity across components, hooks, types, and store state.

Added frontend @ alias support

The frontend now explicitly supports @ alias imports through the client TypeScript/Vite configuration. This was needed to make imports more consistent and less brittle as the UI surface grew.

That also sets the stage for having symmetrical but separate alias behavior between frontend and backend instead of forcing both sides through one shared resolution model.

Tailwind ordering cleanup

A small Tailwind class order cleanup was included to keep formatting consistent with the lint/style direction of the rest of the PR.

Backend changes

Replaced raw SQL bootstrap file with schema-owned SQL

Database schema creation moved away from the standalone init.sql flow and into schema.js, with database initialization updated to consume that shared schema source. This was needed because schema definitions and initialization behavior were drifting apart.

By keeping table creation SQL in one JS-owned schema module, database setup becomes easier to evolve, easier to review, and less likely to fall out of sync between initialization and runtime usage.

Added a real backend TypeScript project and build pipeline

The backend now has a canonical TypeScript config in server/tsconfig.json, while tsconfig.server.json remains as a compatibility shim. Development runs through tsx, the server builds into dist-server, and the backend build is handled by a dedicated script that compiles and rewrites aliases.

This was needed because the backend was no longer just a set of source files that happened to run. It needed a real project boundary for the editor, typechecker, linter, and build system to agree on.

The new setup makes backend tooling explicit instead of incidental.

Fixed backend alias resolution across TypeScript and ESLint

Backend alias resolution now points to the backend-specific tsconfig instead of piggybacking on the frontend config model. This was necessary because the frontend and backend both use @, but they do not mean the same thing. The frontend maps @ to src, while the backend needs @ rooted at server.

Without separating those concerns, one side of the stack will always be “correct” only by accident.

The new configuration makes alias imports resolve consistently in the editor, in type checking, and in lint rules.

Made runtime path handling stable after compilation

Several server entry points were relying on source-layout-relative assumptions like walking ../.. from the current file. That works only while code runs directly from server. Once the backend is compiled into dist-server/server, those assumptions become fragile and can break access to top-level resources such as package.json, .env, public, dist, and default database paths.

This PR introduces shared runtime path helpers so backend code resolves the real app root intentionally instead of guessing it from local file layout. That keeps runtime behavior consistent in both source and built forms.

Enforced server module boundaries through barrel files

eslint-plugin-boundaries now treats each folder under server/modules as an explicit module boundary. Cross-module imports are only allowed through the target module’s barrel file (index.ts / index.js), while deep imports into another module’s internals are blocked.

This was needed because once modules exist, the lack of import boundaries quickly turns them into folders rather than real modules. Requiring barrel imports creates a clear public API for each module and prevents accidental coupling to private implementation files.

The configuration also now fails unknown dependency classifications so alias-resolution gaps cannot silently bypass the boundary rule.

Brought backend import hygiene in line with the frontend

Backend ESLint now enforces the same import ordering behavior as the frontend, including blank lines between groups, along with duplicate/unresolved import checks and unused import reporting.

This improves consistency across the codebase and makes backend files follow the same readability and hygiene expectations as frontend files.

How the pieces fit together

The frontend auth/settings changes and the backend tooling changes solve different immediate problems, but they follow the same design principle:

• global concerns should not depend on narrower local state
• public boundaries should be explicit
• tooling should reflect runtime reality
• naming should match the domain the code represents

On the frontend, that means provider auth status lives behind a reusable hook, settings controllers expose only the arguments they actually need, and provider naming matches the real concept.

On the backend, that means aliases resolve through the correct project config, build output is treated as a real runtime target, runtime paths are resolved deliberately, and server modules expose stable public entry points instead of encouraging deep imports.

Validation

This PR was validated through:

• frontend and backend TypeScript checks
• backend build verification through the new server build flow
• ESLint verification for frontend and backend import resolution/order
• boundaries-rule verification for cross-module backend imports

Result

After this PR:

• provider auth state is centralized and reusable
• settings/onboarding are less coupled to project state
• provider terminology is clearer and more accurate
• frontend and backend alias imports are each resolved through the correct config
• the backend can be built and run from dist-server safely
• server runtime path lookups remain stable after compilation
• backend modules must depend on each other through barrel-defined public APIs
• frontend and backend import hygiene are aligned

Summary by CodeRabbit

• New Features

  • Added backend TypeScript compilation and build separation from client builds.

• Infrastructure

  • Migrated provider authentication state management to a centralized hook.
  • Improved application root path resolution for consistent behavior across build layouts.
  • Enhanced ESLint configuration with backend-specific rules and import enforcement.
  • Updated build output structure to include compiled server artifacts.

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds TypeScript build infrastructure for the backend with path resolution utilities, refactors database schema into JavaScript constants, updates ESLint to enforce backend module boundaries, consolidates provider authentication state handling, unifies provider typing from SessionProvider to LLMProvider throughout the codebase, and configures import aliases.

Changes

Cohort / File(s)	Summary
Server Build Infrastructure package.json, .gitignore, tsconfig.json, vite.config.js	Adds server/tsconfig.json for backend TypeScript compilation, separates dev/build scripts for server and client (server:dev, build:server with tsc and tsc-alias), updates build outputs to dist-server/, adds import alias resolution via @/* paths, and extends published files.
Server Path Resolution server/utils/runtime-paths.js, server/cli.js, server/index.js, server/load-env.js, server/database/db.js, server/routes/commands.js	Introduces new utility functions (getModuleDir, findServerRoot, findAppRoot) to compute stable filesystem roots at runtime; refactors server entry points and route handlers to use these utilities instead of __dirname-relative paths, improving compatibility across source and compiled layouts. Updates database path and .env resolution to use application root.
ESLint Configuration eslint.config.js	Adds backend-specific linting for server/**/*.{js,ts} with import ordering, unused imports detection, module boundary enforcement via eslint-plugin-boundaries, and TypeScript-aware import resolution using path aliases from server/tsconfig.json.
Database Schema Refactoring server/database/schema.js, server/database/init.sql, server/database/db.js	Moves SQL table/index definitions from init.sql into schema.js as exported JavaScript constants (APP_CONFIG_TABLE_SQL, USER_NOTIFICATION_PREFERENCES_TABLE_SQL, VAPID_KEYS_TABLE_SQL, PUSH_SUBSCRIPTIONS_TABLE_SQL, SESSION_NAMES_TABLE_SQL, DATABASE_SCHEMA_SQL); refactors db.js to use these constants directly instead of reading init.sql from disk.
Provider Type Unification src/types/app.ts	Renames SessionProvider type to LLMProvider with same union members ('claude' | 'cursor' | 'codex' | 'gemini'), updates ProjectSession.__provider type reference accordingly.
Provider Authentication System src/components/provider-auth/types.ts, src/components/provider-auth/hooks/useProviderAuthStatus.ts, src/components/provider-auth/view/ProviderLoginModal.tsx	Replaces CliProvider with LLMProvider; adds ProviderAuthStatus and ProviderAuthStatusMap types; introduces useProviderAuthStatus hook centralizing auth-status state management; removes project prop from ProviderLoginModal; adds CLI_PROVIDERS list and CLI_AUTH_STATUS_ENDPOINTS mapping.
Onboarding Refactoring src/components/onboarding/view/Onboarding.tsx, src/components/onboarding/view/.../*, src/components/onboarding/view/types.ts, src/components/onboarding/view/utils.ts	Migrates from local state management to useProviderAuthStatus hook; removes cliProviders, selectedProject, and createInitialProviderStatuses exports; updates component types from CliProvider to LLMProvider; simplifies provider status refresh flow.
Settings Components src/components/settings/hooks/useSettingsController.ts, src/components/settings/types/types.ts, src/components/settings/constants/constants.ts, src/components/settings/view/Settings.tsx, src/components/settings/view/tabs/agents-settings/.../*	Delegates auth-status management to useProviderAuthStatus; consolidates per-provider auth fields into single providerAuthStatus object; replaces individual login callbacks with unified onProviderLogin callback; updates AgentProvider type alias to LLMProvider and AuthStatus to ProviderAuthStatus.
Chat & Session Hooks src/components/chat/hooks/useChatComposerState.ts, src/components/chat/hooks/useChatProviderState.ts, src/components/chat/hooks/useChatRealtimeHandlers.ts, src/components/chat/hooks/useChatSessionState.ts, src/components/chat/types/types.ts, src/components/chat/view/ChatInterface.tsx	Updates all provider type parameters and state from SessionProvider to LLMProvider; updates Provider type alias in chat types module accordingly.
Sidebar Components src/components/sidebar/hooks/useSidebarController.ts, src/components/sidebar/types/types.ts, src/components/sidebar/view/Sidebar.tsx, src/components/sidebar/view/subcomponents/.../*	Updates callback and prop types for session operations from SessionProvider to LLMProvider across all sidebar components and nested session item handling.
Chat UI Components src/components/chat/view/subcomponents/ChatMessagesPane.tsx, src/components/chat/view/subcomponents/ProviderSelectionEmptyState.tsx, src/components/llm-logo-provider/SessionProviderLogo.tsx	Updates component props and internal types to use LLMProvider instead of SessionProvider for provider selection and display.
Session Store & Config src/stores/useSessionStore.ts, src/constants/config.ts	Updates session message store provider field types from SessionProvider to LLMProvider; adds DEFAULT_PROJECT_FOR_EMPTY_SHELL constant for fallback project configuration; updates TypeScript paths configuration with @/* alias mapping to src/*.

Possibly related PRs

• feat: implement session rename with SQLite storage #413: Adds SESSION_NAMES_* SQL constants and sessionNamesDb APIs that complement the schema refactoring in this PR's database migration consolidation.
• Refactor/app content main content and chat interface #374: Modifies the same chat hooks and provider type surface (useChatComposerState, useChatProviderState, etc.), creating direct code-level overlap on provider type handling.
• feat: introduce notification system and claude notifications #450: Implements notification features using the same VAPID_KEYS_TABLE_SQL and PUSH_SUBSCRIPTIONS_TABLE_SQL schema constants added in this PR's database layer.

Suggested reviewers

• viper151

Poem

🐰 A TypeScript burrow takes shape with grace,
Provider paths now find their home and place,
Auth states unified, no more scattered few,
The backend builds strong—old schemas made new!
Aliases guide imports through the warren wide. ✨

🚥 Pre-merge checks | ✅ 1 | ❌ 2

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 29.63% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.
Title check	❓ Inconclusive	The title partially describes key changes (TypeScript backend support and auth settings unification) but contains a typo ('andunification' should be 'and unification') and is somewhat vague about which auth settings are being unified.	Correct the typo and clarify the scope: consider 'Add backend TypeScript support and unify provider auth state' or similar to better reflect that the main focus is centralizing auth state across frontend and settings/onboarding components.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feature/backend-ts-support-andunification-of-auth-settings-on-frontend

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 3

🧹 Nitpick comments (3)

src/components/provider-auth/types.ts (1)

22-27: Consider deriving the initial map from CLI_PROVIDERS to reduce duplication.

The provider list is duplicated in both CLI_PROVIDERS and createInitialProviderAuthStatusMap. If a provider is added or removed, both places need updating.

♻️ Suggested refactor to derive from CLI_PROVIDERS

-export const createInitialProviderAuthStatusMap = (loading = true): ProviderAuthStatusMap => ({
-  claude: { authenticated: false, email: null, method: null, error: null, loading },
-  cursor: { authenticated: false, email: null, method: null, error: null, loading },
-  codex: { authenticated: false, email: null, method: null, error: null, loading },
-  gemini: { authenticated: false, email: null, method: null, error: null, loading },
-});
+export const createInitialProviderAuthStatusMap = (loading = true): ProviderAuthStatusMap => (
+  Object.fromEntries(
+    CLI_PROVIDERS.map((provider) => [
+      provider,
+      { authenticated: false, email: null, method: null, error: null, loading },
+    ]),
+  ) as ProviderAuthStatusMap
+);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/components/provider-auth/types.ts` around lines 22 - 27, The
createInitialProviderAuthStatusMap duplicates the provider list instead of using
the canonical CLI_PROVIDERS; change createInitialProviderAuthStatusMap to build
the ProviderAuthStatusMap by iterating over CLI_PROVIDERS (e.g., using reduce or
Object.fromEntries) and returning the same default object shape ({
authenticated: false, email: null, method: null, error: null, loading }) for
each provider key so adding/removing providers only requires updating
CLI_PROVIDERS; reference createInitialProviderAuthStatusMap and CLI_PROVIDERS
when making the change and preserve the return type ProviderAuthStatusMap.

src/components/provider-auth/hooks/useProviderAuthStatus.ts (1)

103-108: Consider whether exposing setProviderAuthStatus is necessary.

The hook exposes setProviderAuthStatus directly, but the hook already provides checkProviderAuthStatus and refreshProviderAuthStatuses for state updates. Direct exposure of the state setter could lead to inconsistent state if callers bypass the proper update flow (e.g., setting authenticated without clearing loading).

If external state manipulation is needed, consider exposing a more controlled API like setProviderStatus (which is already defined internally but not exported).

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/components/provider-auth/hooks/useProviderAuthStatus.ts` around lines 103
- 108, The hook currently returns the raw state setter setProviderAuthStatus
which allows callers to mutate providerAuthStatus inconsistently; instead,
remove setProviderAuthStatus from the returned object and expose the controlled
updater setProviderStatus (or rename to setProviderStatus if required) so
callers must go through the internal logic that maintains
loading/authenticated/error invariants; update the returned object in
useProviderAuthStatus to include setProviderStatus (or the existing internal
function) and remove setProviderAuthStatus, and adjust any call sites to use the
new controlled API (checkProviderAuthStatus and refreshProviderAuthStatuses
remain unchanged).

src/components/sidebar/view/Sidebar.tsx (1)

237-244: Prefer guarded coercion over as LLMProvider for search payload providers.

provider is runtime string input; casting it directly can leak unsupported values into session state.

Proposed refactor

-              const resolvedProvider = (provider || 'claude') as LLMProvider;
+              const resolvedProvider: LLMProvider =
+                provider === 'claude' || provider === 'cursor' || provider === 'codex' || provider === 'gemini'
+                  ? provider
+                  : 'claude';

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/components/sidebar/view/Sidebar.tsx` around lines 237 - 244, The code
casts the runtime string provider to LLMProvider using "as" in the
onConversationResultClick handler which can leak invalid values into
sessionObj.__provider; replace the unsafe cast by validating provider against
the known provider set (e.g., an isValidProvider/type-guard or a lookup of
allowed LLMProvider values) and only assign provider to resolvedProvider if it
passes validation, otherwise fall back to the default ('claude'); update the
resolvedProvider creation and ensure sessionObj.__provider uses that validated
value (refer to onConversationResultClick, resolvedProvider, sessionObj, and
LLMProvider).

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@package.json`:
- Around line 27-33: The package.json's files whitelist is missing the runtime
artifact directory referenced by the "server" script ("node
dist-server/server/index.js"); update the package.json "files" array to include
"dist-server/" so the dist-server directory (and its server/index.js) is
packaged on publish; locate the "files" array in package.json and add the string
"dist-server/" alongside the existing entries ("server/", "shared/", "dist/",
"scripts/", "README.md").

In `@src/components/chat/hooks/useChatProviderState.ts`:
- Around line 14-16: The state initializer in useChatProviderState (the
useState<LLMProvider> call that reads localStorage.getItem('selected-provider'))
currently asserts the stored string as LLMProvider without runtime validation;
add a small validation helper (e.g., isValidProvider(value): value is
LLMProvider) that checks against the allowed provider union/list and use it in
the initializer and anywhere you read 'selected-provider' (and in setters like
setProvider) so that invalid or legacy strings fall back to 'claude' and never
populate state with an invalid provider.

In `@src/components/chat/view/ChatInterface.tsx`:
- Around line 209-212: The code casts localStorage.getItem('selected-provider')
to LLMProvider directly (providerVal) and then passes it to
sessionStore.refreshFromServer via selectedSession.__provider || providerVal,
allowing invalid runtime strings to reach the API; change this to
parse-and-validate the runtime value against the allowed LLMProvider literals
('claude','cursor','codex','gemini') before use: read the stored string, verify
it matches one of the valid provider values, otherwise fall back to a safe
default ('claude'); then pass the validated provider to refreshFromServer (use
the existing symbols providerVal, selectedSession.__provider, LLMProvider, and
sessionStore.refreshFromServer) so only validated provider values are sent to
the backend.

---

Nitpick comments:
In `@src/components/provider-auth/hooks/useProviderAuthStatus.ts`:
- Around line 103-108: The hook currently returns the raw state setter
setProviderAuthStatus which allows callers to mutate providerAuthStatus
inconsistently; instead, remove setProviderAuthStatus from the returned object
and expose the controlled updater setProviderStatus (or rename to
setProviderStatus if required) so callers must go through the internal logic
that maintains loading/authenticated/error invariants; update the returned
object in useProviderAuthStatus to include setProviderStatus (or the existing
internal function) and remove setProviderAuthStatus, and adjust any call sites
to use the new controlled API (checkProviderAuthStatus and
refreshProviderAuthStatuses remain unchanged).

In `@src/components/provider-auth/types.ts`:
- Around line 22-27: The createInitialProviderAuthStatusMap duplicates the
provider list instead of using the canonical CLI_PROVIDERS; change
createInitialProviderAuthStatusMap to build the ProviderAuthStatusMap by
iterating over CLI_PROVIDERS (e.g., using reduce or Object.fromEntries) and
returning the same default object shape ({ authenticated: false, email: null,
method: null, error: null, loading }) for each provider key so adding/removing
providers only requires updating CLI_PROVIDERS; reference
createInitialProviderAuthStatusMap and CLI_PROVIDERS when making the change and
preserve the return type ProviderAuthStatusMap.

In `@src/components/sidebar/view/Sidebar.tsx`:
- Around line 237-244: The code casts the runtime string provider to LLMProvider
using "as" in the onConversationResultClick handler which can leak invalid
values into sessionObj.__provider; replace the unsafe cast by validating
provider against the known provider set (e.g., an isValidProvider/type-guard or
a lookup of allowed LLMProvider values) and only assign provider to
resolvedProvider if it passes validation, otherwise fall back to the default
('claude'); update the resolvedProvider creation and ensure
sessionObj.__provider uses that validated value (refer to
onConversationResultClick, resolvedProvider, sessionObj, and LLMProvider).

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: ebb19162-2fa2-4190-97cb-424187bf22f5

📥 Commits

Reviewing files that changed from the base of the PR and between c3599cd and 2e86197.

⛔ Files ignored due to path filters (1)

• package-lock.json is excluded by !**/package-lock.json

📒 Files selected for processing (49)

• .gitignore
• eslint.config.js
• package.json
• scripts/build-server.mjs
• server/cli.js
• server/database/db.js
• server/database/init.sql
• server/database/schema.js
• server/index.js
• server/load-env.js
• server/routes/commands.js
• server/tsconfig.json
• server/utils/runtime-paths.js
• src/components/chat/hooks/useChatComposerState.ts
• src/components/chat/hooks/useChatProviderState.ts
• src/components/chat/hooks/useChatRealtimeHandlers.ts
• src/components/chat/hooks/useChatSessionState.ts
• src/components/chat/types/types.ts
• src/components/chat/view/ChatInterface.tsx
• src/components/chat/view/subcomponents/ChatMessagesPane.tsx
• src/components/chat/view/subcomponents/ProviderSelectionEmptyState.tsx
• src/components/llm-logo-provider/SessionProviderLogo.tsx
• src/components/onboarding/view/Onboarding.tsx
• src/components/onboarding/view/subcomponents/AgentConnectionCard.tsx
• src/components/onboarding/view/subcomponents/AgentConnectionsStep.tsx
• src/components/onboarding/view/types.ts
• src/components/onboarding/view/utils.ts
• src/components/provider-auth/hooks/useProviderAuthStatus.ts
• src/components/provider-auth/types.ts
• src/components/provider-auth/view/ProviderLoginModal.tsx
• src/components/settings/constants/constants.ts
• src/components/settings/hooks/useSettingsController.ts
• src/components/settings/types/types.ts
• src/components/settings/view/Settings.tsx
• src/components/settings/view/tabs/agents-settings/AgentsSettingsTab.tsx
• src/components/settings/view/tabs/agents-settings/types.ts
• src/components/sidebar/hooks/useSidebarController.ts
• src/components/sidebar/types/types.ts
• src/components/sidebar/view/Sidebar.tsx
• src/components/sidebar/view/subcomponents/SidebarProjectItem.tsx
• src/components/sidebar/view/subcomponents/SidebarProjectList.tsx
• src/components/sidebar/view/subcomponents/SidebarProjectSessions.tsx
• src/components/sidebar/view/subcomponents/SidebarSessionItem.tsx
• src/constants/config.ts
• src/stores/useSessionStore.ts
• src/types/app.ts
• tsconfig.json
• tsconfig.server.json
• vite.config.js

💤 Files with no reviewable changes (4)

• src/components/settings/constants/constants.ts
• src/components/onboarding/view/types.ts
• server/database/init.sql
• src/components/onboarding/view/utils.ts

[viper151]

@blackmammoth not sure if you are going to submit this PR as is but it will be very difficult to review it as it is very big.

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@package.json`:
- Around line 38-39: Update the lint-staged configuration so staged backend
files under the new server/ directory are linted before commit: adjust the
lint-staged globs (the package.json "lint" / "lint:fix" commands reference
server/) to include server/**/* (or specific extensions like
server/**/*.{js,ts,tsx}) in addition to src/**/* so pre-commit ESLint runs the
same scope as the lint and lint:fix scripts; locate the "lint-staged" entry in
package.json and mirror the new backend path there.
- Around line 27-35: The package.json exposes runtime entrypoints that point at
source files ("main": "server/index.js" and "bin.cloudcli": "server/cli.js")
while the runtime scripts and build output use the compiled artifact under
dist-server/server/index.js; update the published entrypoints to reference the
compiled output (e.g., set "main" to "dist-server/server/index.js" and
"bin.cloudcli" to "dist-server/server/cli.js") and ensure any npm scripts that
run the package (like the "server" script) are consistent with this compiled
path so installed consumers execute the built artifact rather than source.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 66d6d58b-fdc6-4efe-8f23-70179d5366ee

📥 Commits

Reviewing files that changed from the base of the PR and between f4957ff and 5964d0a.

📒 Files selected for processing (1)

• package.json