Build with AI (Vibe Coding)

# LatentKit integration prompt

You are working inside the user's existing Cursor workspace. Use agent mode carefully: inspect the repo first, propose a minimal plan, then implement only the LatentKit integration.

## Safety rules — read before editing any file

You MUST follow these rules. They protect the user's existing project from aggressive AI refactors.

1. **Do not break the existing project structure.** Extend it; do not reorganize unrelated folders.
2. **Respect the current architecture.** Match routing, DI, modules, and naming already in the repo.
3. **Scope is LatentKit integration only.** Do not rewrite unrelated features, styles, or dependencies.
4. **Inspect before you edit.** List the files you will touch and why before making changes.
5. **If something is unclear or blocked** (missing env var, unknown framework entrypoint, no server layer), explain the blocker and ask or propose the smallest fix — do not guess wildly.
6. **Do not delete or replace working code** unless it is strictly required for LatentKit.
7. **Follow framework conventions** already used in the project (App Router vs Pages Router, Laravel routes vs controllers, Django apps, etc.).
8. **Keep the implementation production-safe:** server-side secrets, typed handlers where the project already uses types, and basic error handling.
9. **Explain major changes before applying them** (new env vars, new routes, new packages).
10. **Never commit or hardcode API keys.** Use environment variables or the platform's secrets manager.
11. **Never send `model`, `provider`, `route`, or `policy`** in LatentKit request bodies — routing is configured in the LatentKit console per API key.
12. **Prefer the official SDK** when the stack is JavaScript/TypeScript or Python. Use REST/cURL only when no SDK fits.
13. **Do not run destructive commands** such as reset, clean, bulk delete, migration rollback, or broad formatter commands unless the user explicitly approves.
14. **Do not overwrite existing env files.** Add documented variable names or examples, but leave real secrets to the user.
15. **Validate inputs at the server boundary** before forwarding to LatentKit, and return safe errors to the frontend.
16. **After editing, summarize verification steps** and mention any tests or commands that could not be run.

## LatentKit model (route-based gateway)

- Base URL: `https://ai.latentkit.com`
- Auth: `Authorization: Bearer $LATENTKIT_API_KEY` (server-side only)
- Content-Type: `application/json`
- App code sends task payloads (`messages`, `input`, `prompt`, etc.). The API key's assigned route picks provider/model at runtime.
- Optional body field: `response_profile` → `fast` | `balanced` | `deep`
- Log `X-LK-Request-ID` on errors when available. Parse JSON `error` + `message` fields.
- Streaming: SSE with `stream: true`; handle terminal `event: error`.

## Target stack
- Framework: **Next.js**
- Language: **typescript**
- Profile: **Next.js (App Router)**

## Your task
Integrate LatentKit into this **existing** Next.js (App Router) project.

Deliverables:
1. A short plan listing files to add or change (no unrelated refactors).
2. Server-side LatentKit client setup using `LATENTKIT_API_KEY`.
3. One working chat endpoint the frontend can call.
4. Request validation, basic error handling, and request-id logging.
5. Notes on env vars and how to test locally.
6. If the repo already has a similar pattern (services, routes, API handlers), follow it.

Before editing:
- Inspect the repo structure, package manager, framework routing style, and existing API/client patterns.
- If there is no server-side execution layer for this stack, stop and explain the smallest safe backend/serverless option before adding one.
- If installing packages is required, use the package manager already present in the repo and explain the dependency first.

## Install / dependencies
```bash
npm install @latentkit/sdk
```

## Client setup (server-side)
```ts
// lib/latentkit.ts — server-only module
import 'server-only';
import { LatentKit } from '@latentkit/sdk';

export function getLatentKitClient() {
  const apiKey = process.env.LATENTKIT_API_KEY;
  if (!apiKey) throw new Error('LATENTKIT_API_KEY is not set');
  return new LatentKit({ apiKey });
}
```

## Example handler
```ts
// app/api/chat/route.ts
import { NextResponse } from 'next/server';
import { LatentKitApiError } from '@latentkit/sdk';
import { getLatentKitClient } from '@/lib/latentkit';

export async function POST(request: Request) {
  const body = await request.json();
  if (!Array.isArray(body.messages)) {
    return NextResponse.json({ error: 'invalid_messages' }, { status: 400 });
  }

  const client = getLatentKitClient();
  try {
    const response = await client.chat.create({
      messages: body.messages,
      response_profile: 'balanced',
      max_tokens: body.max_tokens ?? 500,
    });
    return NextResponse.json({ content: response.content });
  } catch (error) {
    if (error instanceof LatentKitApiError) {
      console.error('LatentKit request failed', { status: error.status, code: error.code, request_id: error.request_id });
      return NextResponse.json({ error: error.code ?? 'latentkit_error' }, { status: 502 });
    }
    throw error;
  }
}
```

## Suggested file layout
```text
lib/latentkit.ts          # server-only client factory
app/api/chat/route.ts     # POST handler; frontend calls /api/chat
.env.local                # LATENTKIT_API_KEY=lk_... (never commit)
```

## Stack notes
Keep LATENTKIT_API_KEY out of NEXT_PUBLIC_* vars. Call your /api/chat route from client components. If the project uses Pages Router instead of App Router, create pages/api/chat.ts with the same server-only rules.
## Verification
- Confirm no secret appears in client bundles or committed files.
- Send a test message and log `X-LK-Request-ID` on failure.
- Do not add `model` or `provider` fields to LatentKit requests.
- Confirm the route works from the LatentKit console first if app requests fail.

## When finished
Summarize what changed, which env vars are required, and how to run a test request.