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. **Use the CLI only for verification or ops workflows** (`npm install -g @latentkit/cli`, `latentkit login`, `latentkit whoami --json`); do not require browser login for production app code.
17. **Protect the new endpoint with the project's existing authentication and authorization.** If cookie authentication is used, preserve CSRF protection. Add an appropriate request-size limit and rate limit before production use.
18. **Log only safe diagnostics:** status, LatentKit error code, and request ID. Do not log prompts, generated content, authorization headers, cookies, or raw upstream response bodies.
19. **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. Existing app authentication/authorization, CSRF protection where applicable,
   request-size limits, and rate limiting on the new endpoint.
6. Notes on env vars and how to test locally.
7. 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) {
  let body: unknown;
  try {
    body = await request.json();
  } catch {
    return NextResponse.json({ error: 'invalid_json' }, { status: 400 });
  }

  const messages =
    typeof body === 'object' && body !== null && 'messages' in body
      ? (body as { messages?: unknown }).messages
      : null;

  if (
    !Array.isArray(messages) ||
    messages.length === 0 ||
    messages.length > 50 ||
    !messages.every((message) =>
      typeof message === 'object' &&
      message !== null &&
      'role' in message &&
      ['system', 'user', 'assistant'].includes(String(message.role)) &&
      'content' in message &&
      typeof message.content === 'string' &&
      message.content.length <= 100_000
    )
  ) {
    return NextResponse.json({ error: 'invalid_messages' }, { status: 400 });
  }

  const client = getLatentKitClient();
  try {
    const response = await client.chat.create({
      messages,
      response_profile: 'balanced',
      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. Apply the app's existing authentication, authorization, rate limiting, and Origin/CSRF controls before production. If the project uses Pages Router, follow its existing API pattern.
## Verification
- Confirm no secret appears in client bundles or committed files.
- Confirm prompts, generated content, authorization headers, and raw provider
  responses are not written to logs.
- 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.