feat: initialize Next.js app in /web directory

[vargas-jr]

Summary

Initial Next.js setup extracted from velly-prototype, organized as a monorepo.

Structure

/
├── web/               # Next.js application
│   ├── src/
│   │   ├── app/       # App router pages & API routes
│   │   ├── components/
│   │   └── lib/       # DB, auth, GCP utilities
│   ├── public/
│   └── package.json
├── editor-templates/  # Agent editor templates
└── .github/           # CI workflows

Changes from velly-prototype

• ✅ Replaced Convex with Drizzle ORM + PostgreSQL
• ✅ Removed Vercel deployment (deployment TBD)
• ✅ Updated branding to Vellum Assistant
• ✅ Simplified auth (placeholder for now)
• ✅ Reorganized into monorepo structure with /web directory

Tech Stack

• Next.js 16 (App Router)
• Tailwind CSS v4
• Drizzle ORM + PostgreSQL
• TypeScript

Getting Started

cd web
npm install
npm run dev

---

[devin-ai-integration]

Devin Review found 6 potential issues.

View 7 additional findings in Devin Review.

[devin-ai-integration]

🔴 Duplicate getDb() function definitions return different types, breaking all raw SQL callers

The db.ts file defines getDb() twice: once at line 22 returning the raw postgres SQL client, and again at line 37 returning the Drizzle ORM instance. The second definition shadows the first.

Root Cause and Impact

The first getDb() (line 22-24) returns the raw sql postgres client that supports template tag queries like sql\SELECT * FROM agents`. The second getDb()(line 37-39) returns the Drizzledb` instance, which has a completely different API.

Every API route in the codebase calls getDb() and uses it with template tag syntax, e.g.:

const sql = getDb();
const result = await sql`SELECT * FROM agents WHERE id = ${id}`;

If the second definition takes precedence (as it would in JS), the Drizzle instance does NOT support template tag queries, causing all these API routes to fail at runtime. This affects web/src/app/api/agents/route.ts:75, web/src/app/api/agents/[id]/route.ts:11, and virtually every other API route.

Impact: All API endpoints that use getDb() with raw SQL template tags will crash at runtime.

Suggested change

	// Legacy compatibility - getDb returns the drizzle instance
	export function getDb() {
	return db;
	}
	// Legacy compatibility - getDb returns the raw SQL client
	// (duplicate removed - see line 22)

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🔴 SSE parser uses indexOf on iterated array, causing wrong data line lookup for duplicate event types

The SSE parsing logic in handleCreateAgent uses lines.indexOf(line) to find the index of the current event line, then looks up the next line as the data line. indexOf returns the index of the first occurrence, not the current one.

Detailed Explanation

At web/src/app/agents/page.tsx:85, the code does:

const dataLineIndex = lines.indexOf(line) + 1;
const dataLine = lines[dataLineIndex];

When the SSE stream contains multiple events of the same type (e.g., multiple event: progress lines), lines.indexOf(line) always returns the index of the first event: progress line in the lines array, not the current one being iterated. This means subsequent progress events will read the data from the first progress event's data line instead of their own.

For example, if lines contains:

["event: progress", "data: {step:naming}", "", "event: progress", "data: {step:upload}", ""]

When iterating over the second event: progress (index 3), indexOf returns 0, so dataLineIndex = 1, reading {step:naming} instead of {step:upload}.

Impact: Progress messages during agent creation may show stale/incorrect status, and the "complete" event could be missed if a prior event line has the same text.

Suggested change

	for (const line of lines) {
	if (line.startsWith("event: ")) {
	const eventType = line.slice(7);
	const dataLineIndex = lines.indexOf(line) + 1;
	const dataLine = lines[dataLineIndex];
	if (dataLine?.startsWith("data: ")) {
	const data = JSON.parse(dataLine.slice(6));
	if (eventType === "progress") {
	setProgressMessage(data.message);
	} else if (eventType === "complete") {
	router.push(`/agents/${data.agent.id}`);
	return;
	} else if (eventType === "error") {
	throw new Error(data.message);
	}
	}
	}
	let currentEventType: string | null = null;
	for (const line of lines) {
	if (line.startsWith("event: ")) {
	currentEventType = line.slice(7);
	} else if (line.startsWith("data: ") && currentEventType) {
	const data = JSON.parse(line.slice(6));
	if (currentEventType === "progress") {
	setProgressMessage(data.message);
	} else if (currentEventType === "complete") {
	router.push(`/agents/${data.agent.id}`);
	return;
	} else if (currentEventType === "error") {
	throw new Error(data.message);
	}
	currentEventType = null;
	} else if (line === "") {
	currentEventType = null;
	}
	}

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🔴 createChatMessage called with snake_case keys but Drizzle schema expects camelCase

The createChatMessage function uses Drizzle ORM's insert().values() which expects keys matching the schema's camelCase property names, but callers pass snake_case keys.

Root Cause and Impact

The Drizzle schema at web/src/lib/schema.ts:19 defines agentId (camelCase) mapped to column agent_id, and gcsMessageId mapped to gcs_message_id. The NewChatMessage type inferred from this schema expects camelCase keys.

However, at web/src/app/api/agents/[id]/messages/route.ts:69-75 and route.ts:188-194, the callers pass:

await createChatMessage({
  agent_id: agentId,      // should be agentId
  role: "assistant",
  content: outboxMsg.content,
  status: "delivered",
  gcs_message_id: outboxMsg.id,  // should be gcsMessageId
});

Drizzle will not recognize agent_id or gcs_message_id as valid column references. The agent_id column is NOT NULL, so the insert will either fail with a database constraint violation (missing required agent_id) or silently insert NULL values.

Impact: All message creation (both user messages and synced assistant outbox messages) will fail, breaking the chat functionality entirely.

Suggested change

	await createChatMessage({
	agent_id: agentId,
	role: "assistant",
	content: outboxMsg.content,
	status: "delivered",
	gcs_message_id: outboxMsg.id,
	});
	await createChatMessage({
	agentId: agentId,
	role: "assistant",
	content: outboxMsg.content,
	status: "delivered",
	gcsMessageId: outboxMsg.id,
	});

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🔴 Second createChatMessage call also uses snake_case keys

Same issue as BUG-0003 but for the user message creation path at line 188-194.

Root Cause

At web/src/app/api/agents/[id]/messages/route.ts:188-194:

const dbMessage = await createChatMessage({
  agent_id: agentId,       // should be agentId
  role: "user",
  content,
  status: "sent",
  gcs_message_id: agentData.messageId,  // should be gcsMessageId
});

This will fail for the same reason as BUG-0003 - Drizzle expects camelCase property names.

Impact: Sending messages to agents will fail.

Suggested change

	const dbMessage = await createChatMessage({
	agent_id: agentId,
	role: "user",
	content,
	status: "sent",
	gcs_message_id: agentData.messageId,
	});
	const dbMessage = await createChatMessage({
	agentId: agentId,
	role: "user",
	content,
	status: "sent",
	gcsMessageId: agentData.messageId,
	});

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🔴 .env obfuscation bypass for files like .env.local, .env.production

The env file detection logic fails to catch common env file variants that also contain secrets.

Root Cause

At web/src/app/api/agents/[id]/cat/route.ts:60:

if (filename === ".env" || filename.endsWith(".env")) {

This only matches files named exactly .env or files ending with .env. It does NOT match common variants like .env.local, .env.production, .env.development, etc., because those end with .local, .production, etc.

A user browsing the file system can read the full unobfuscated contents of .env.local or .env.production files, which typically contain the same sensitive secrets as .env.

Impact: Secret values in .env.* variant files are exposed in plaintext through the file viewer API.

Suggested change

	if (filename === ".env" || filename.endsWith(".env")) {
	if (filename === ".env" || filename.startsWith(".env.") || filename.endsWith(".env")) {

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🔴 FocusView SSE parser discards eventType due to continue statement, never processes events

The SSE parser in FocusView.tsx reads the event type but immediately continues, so the event type is never used to determine how to handle the data.

Root Cause

At web/src/components/AssistantInitialization/FocusView.tsx:68-71:

if (line.startsWith('event: ')) {
  const eventType = line.slice(7);
  continue;  // <-- skips to next iteration
}

The eventType variable is declared inside the if block and immediately discarded by continue. The subsequent if (line.startsWith('data: ')) block processes data lines but has no access to the event type. This means the parser cannot distinguish between progress, complete, and error events.

The code partially works because it checks data.step and data.agent properties to infer the event type, but it never detects error events properly. If the server sends an error event, the data line will be processed but the error message check at line 105 (data.message.includes('error')) only logs it - it doesn't set the error state or stop processing.

Impact: Error events from the agent creation SSE stream are silently ignored. The user sees a perpetual loading state instead of an error message.

Prompt for agents

In web/src/components/AssistantInitialization/FocusView.tsx, the SSE parser at lines 67-111 needs to be restructured to properly track the event type across lines. Currently, the event type is read at line 69 but immediately discarded by the continue statement at line 70. The fix should:

1. Declare a variable outside the for loop (e.g., let currentEventType: string | null = null) to track the current event type.
2. When an event: line is encountered, store the event type in that variable (don't continue).
3. When a data: line is encountered, check currentEventType to determine how to handle it.
4. For 'error' events, call setError(data.message) to show the error UI.
5. For 'complete' events, extract the agent ID.
6. Reset currentEventType after processing a data line or on empty lines.

---

Was this helpful? React with 👍 or 👎 to provide feedback.