/**
 * POST /api/chat
 *
 * Streaming chat endpoint. Accepts a thread_id + user message,
 * loads history, calls the configured chat model (Gemini or OpenAI-compatible e.g. DeepSeek), runs the tool loop,
 * persists messages, and streams SSE back to the client.
 *
 * SSE event shapes:
 *   data: {"type":"text","text":"..."}
 *   data: {"type":"thinking","text":"..."}    // model's first-person reasoning
 *   data: {"type":"tool_start","name":"...","args":{}}
 *   data: {"type":"tool_result","name":"...","result":"..."}
 *   data: {"type":"aborted"}
 *   data: {"type":"done"}
 *   data: {"type":"error","error":"..."}
 */
import { NextResponse } from "next/server";
import { requireWorkspacePrincipal } from "@/lib/auth/workspace-auth";
import { query, queryOne } from "@/lib/db-postgres";
import { callVibnChat } from "@/lib/ai/vibn-chat-model";
import {
  VIBN_TOOL_DEFINITIONS,
  executeMcpTool,
  filterToolsForPhase,
  type AgentPhase,
} from "@/lib/ai/vibn-tools";
import {
  detectKnownError,
  formatRecoveryMessage,
} from "@/lib/ai/error-recovery";
import {
  executeTask,
  runVerificationContract,
  type ExecCtx,
  type ExecuteTaskOutcome,
  type ToolExecutor,
  type VerificationTask,
} from "@/lib/ai/verification";

// --- Agent Orchestration Types & Constants ---
type TurnIntent =
  | "conversational"
  | "status_check"
  | "diagnose"
  | "small_fix"
  | "feature_build"
  | "deploy"
  | "autonomous";

// AgentPhase is imported from "@/lib/ai/vibn-tools" (single source of truth).
// A duplicate local declaration here previously conflicted with that import
// (TS2440) and broke typechecking.

const TOOL_BUDGETS: Record<TurnIntent, number> = {
  conversational: 1, // Must be at least 1 so the LLM gets called for a text reply
  // Investigative questions ("is the auth connected?", "what's the test user?")
  // routinely need to read several files THEN synthesize an answer. Budgets of
  // 5/8 were cutting these off at the cap before the model could answer
  // (telemetry showed 100% round_cap on these turns). Raised so a read-only
  // investigation can actually finish.
  status_check: 12,
  diagnose: 15,
  small_fix: 18,
  feature_build: 40,
  deploy: 25,
  autonomous: 150,
};

function classifyTurnIntent(message: string): TurnIntent {
  const m = message.trim().toLowerCase();

  // High-agency directives
  if (
    /(keep going|continue|build it|do it|go ahead|proceed|autonomous)/.test(m)
  )
    return "autonomous";

  // Deployments
  if (/(deploy|ship|release|publish|push to prod)/.test(m)) return "deploy";

  // Feature build
  if (
    /(build|create|add|implement|make|setup|wire|scaffold|integrate|restart|start|reboot|run)/.test(
      m,
    )
  ) {
    if (m.length > 50) return "feature_build";
    return "small_fix";
  }

  // Diagnostics — error/failure vocabulary including infra/network errors.
  // "timeout", "gateway", "502/503/504", "connection refused" are infrastructure
  // failure signals that the model should diagnose and report on, not treat as
  // a 40-round build task. Without these, "I get a gateway timeout" falls through
  // to feature_build and burns 40 rounds looping on a dead dev server.
  if (
    /(why|broken|error|blank|not loading|fail|bug|issue|doesn't work|isn't working|fix|time.?out|tim(?:es?|ed|ing) out|gateway|5[0-2][0-9]|connection (refused|reset|failed)|unreachable|can.?t connect|cannot connect|not respond)/.test(
      m,
    )
  )
    return "diagnose";

  // Status check / investigative questions (read-only).
  // These need a real tool budget because answering a question about the
  // codebase ("is the auth wired up?", "is there a users table?") legitimately
  // requires reading files before responding.
  if (
    /(status|logs|running|active|what is|show me|check|where|how|what|which|whose)/.test(
      m,
    ) ||
    // Yes/no investigative question starters: "is/are/does/do/can/has/have/did ..."
    /^(is|are|does|do|can|could|has|have|had|did|should|would|will)\b/.test(
      m,
    ) ||
    // Investigative vocabulary anywhere in the message
    /\b(connected|hooked up|wired( up)?|set ?up|configured|working|exists?|stored|present|enabled)\b/.test(
      m,
    ) ||
    // Any message phrased as a question
    m.endsWith("?")
  )
    return "status_check";

  // Conversational: greetings, acknowledgements, and short pleasantries.
  // By this point we've already matched action verbs, diagnostics, and
  // questions, so anything that *starts* with a greeting/ack, or is a very
  // short verb-less leftover, is chat — reply in text, don't run the agent
  // loop. Note we still avoid the old `/^(ok)/` prefix bug: "okay is the auth
  // connected up?" already returned `status_check` above (ends with "?").
  const wordCount = m.split(/\s+/).filter(Boolean).length;
  if (
    // Greetings (incl. multi-word: "hey there!", "good morning")
    /^(hi|hey|hello|heya|hiya|yo|sup|howdy|greetings|good (morning|afternoon|evening|day))\b/.test(
      m,
    ) ||
    // Acknowledgements / pleasantries
    /^(thanks|thank you|ty|ok|okay|kk|k|yes|yep|yeah|yup|no|nope|nah|sure|cool|nice|great|awesome|perfect|got it|sounds good|will do|nvm|never mind)\b/.test(
      m,
    ) ||
    /(what'?s up|how are you|how'?s it going|good to see you)/.test(m) ||
    // Very short, verb-less, non-question leftovers are ambiguous → treat as
    // chat and let the model ask, rather than spinning up a 40-round build.
    (wordCount <= 4 && m.length <= 30 && !m.endsWith("?"))
  )
    return "conversational";

  // Default to a generous feature build if we can't tell
  return "feature_build";
}
import { listRecentSentryIssues } from "@/lib/integrations/sentry";
import {
  ensureProjectRepoCloned,
  commitAndPushIfDirty,
} from "@/lib/dev-container-git";
import { buildDesignKitPromptSection } from "@/lib/design-kits/for-ai";
import { buildCodebaseSummary } from "@/lib/ai/codebase-summary";
import { execInDevContainer } from "@/lib/dev-container";
import type { ChatMessage, ToolCall } from "@/lib/ai/gemini-chat";
import { logTurnSummary } from "@/lib/ai/telemetry-db";

// Per-turn tool budgets are intent-based (see TOOL_BUDGETS below); the
// State-Based Governor is the real-time safety net that breaks loops within a
// couple of rounds. (A former flat MAX_TOOL_ROUNDS cap was removed once
// TOOL_BUDGETS replaced it.)

let chatTablesReady = false;
async function ensureChatTables() {
  if (chatTablesReady) return;
  await query(
    `
    CREATE TABLE IF NOT EXISTS fs_chat_threads (
      id         TEXT PRIMARY KEY DEFAULT gen_random_uuid()::text,
      user_id    TEXT NOT NULL,
      workspace  TEXT NOT NULL DEFAULT '',
      data       JSONB NOT NULL DEFAULT '{}',
      created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
      updated_at TIMESTAMPTZ NOT NULL DEFAULT now()
    );
    CREATE INDEX IF NOT EXISTS fs_chat_threads_user_ws_idx
      ON fs_chat_threads (user_id, workspace, updated_at DESC);

    CREATE TABLE IF NOT EXISTS fs_chat_messages (
      id         BIGSERIAL PRIMARY KEY,
      thread_id  TEXT NOT NULL REFERENCES fs_chat_threads(id) ON DELETE CASCADE,
      user_id    TEXT NOT NULL,
      data       JSONB NOT NULL DEFAULT '{}',
      created_at TIMESTAMPTZ NOT NULL DEFAULT now()
    );
    CREATE INDEX IF NOT EXISTS fs_chat_messages_thread_idx
      ON fs_chat_messages (thread_id, created_at ASC);
  `,
    [],
  );
  chatTablesReady = true;
}

interface DBProject {
  id: string;
  name: string;
  slug?: string;
  productName?: string;
  status?: string;
  productVision?: string;
  audience?: string;
  kickoff?: { mode: string; sourceData: unknown };
  designKit?: unknown;
  giteaCloneUrl?: string;
  plan?: {
    decisions?: { title: string; choice: string; why?: string }[];
    tasks?: { text: string; status: "open" | "done" }[];
    ideas?: { text: string }[];
    brief?: string;
  };
}

export async function buildSystemPrompt(
  projects: DBProject[],
  workspace: string,
  activeProject?: DBProject,
  chatMode: "vibe" | "collaborate" | "delegate" = "vibe",
): Promise<string> {
  const modeInstructions =
    chatMode === "collaborate"
      ? `
# MODE: Architect (Collaborate)
You are an Architect and Product Strategist using Spec-Driven Development.
**DO NOT WRITE CODE OR USE FILE SYSTEM TOOLS (e.g., fs_edit, fs_write, ship, shell_exec).**
Your job is to interview the user to understand their requirements, and then generate a structured PRD (Product Requirements Document) and Execution Plan.

## Step 1: Draft the PRD (Spec)
Do not guess. Ask the user clarifying questions. When the requirements are clear, use \`plan_vision_set\` to save the PRD.
The PRD MUST strictly follow this Markdown template:

# Feature Specification: [FEATURE NAME]
**Status**: Draft

## User Scenarios & Testing
User stories MUST be prioritized as user journeys ordered by importance. Each user story MUST be INDEPENDENTLY TESTABLE.
### User Story 1 - [Brief Title] (Priority: P1)
[Describe this user journey in plain language]
**Independent Test**: [Describe how this can be tested independently]
**Acceptance Scenarios**:
1. **Given** [initial state], **When** [action], **Then** [expected outcome]

### User Story 2 - [Brief Title] (Priority: P2)
[Continue for all stories...]

## Functional Requirements
- **FR-001**: System MUST [specific capability]
- **FR-002**: Users MUST be able to [key interaction]

## Key Entities
- **[Entity 1]**: [What it represents, key attributes]
- **[Entity 2]**: [Relationships to other entities]

## Success Criteria
- **SC-001**: [Measurable, technology-agnostic metric, e.g., "Users can complete checkout in under 3 minutes"]

## Step 2: The Architecture Plan
Once the PRD is saved, decide HOW to build it. Use \`plan_decision_log\` to record the specific technologies:
- Database (e.g. Postgres)
- Stack (e.g. Next.js, Tailwind)
- Auth (e.g. NextAuth)

## Step 3: The Execution Plan (Tasks)
Once the architecture is logged, break the PRD into an actionable development checklist using \`plan_task_add\`.
You MUST organize tasks strictly by User Story using bracket prefixes.
Each task must be atomic and specify the exact file path to be edited.
Example:
- \`plan_task_add { title: "[Phase 1] Initialize Next.js project and setup Prisma DB" }\`
- \`plan_task_add { title: "[US1] Create User table in schema.prisma" }\`
- \`plan_task_add { title: "[US1] Build /api/auth POST endpoint" }\`
- \`plan_task_add { title: "[US2] Build frontend Dashboard form in src/app/dashboard/page.tsx" }\`

Your turn ends when the user's PRD is saved via plan_vision_set, decisions are logged, and the task list is fully populated.
`
      : `
# MODE: Vibe Code (Full Engineering)
You are a Lead Software Engineer who is permitted to write code, edit files, create backend endpoints, and deploy apps.
- Use \`fs_write\`, \`fs_edit\`, \`ship\`, and other developer tools directly to build features based on the saved Plan.
- **Do EXACTLY what the user asked — nothing more.** For a small or scoped change ("remove a word", "change a color", "fix this link"), make that single change, confirm it still compiles, and STOP. Do NOT refactor, restyle, optimize images, change breakpoints, rewrite files, or fix unrelated things you happen to notice.
- \`request_visual_qa\` is OPTIONAL and only appropriate for from-scratch page builds or when the user explicitly asks for design/visual work. **Do NOT run it for small edits.** When you do run it, its critique is ADVISORY only: address solely the points that relate to the user's actual request, and NEVER let it expand the scope of the task. A QA critique about an unrelated part of the page is not your job this turn.
`;

  const projectsText = projects.length
    ? projects
        .map(
          (p: DBProject) =>
            `- "${p.productName || p.name}" (id: ${p.id}, status: ${p.status || "defining"})${p.productVision ? ": " + p.productVision.slice(0, 120) : ""}`,
        )
        .join("\n")
    : "(no projects yet)";

  // When this thread is scoped to a project, surface a STRONG header
  // at the top so the model treats `projectId` as resolved without the
  // user having to name it. Falls through to the workspace-level mode
  // (browse all projects) when activeProject is undefined.
  // Pull plan artifacts (decisions + open tasks) so the AI doesn't ask
  // the user to re-decide settled questions and knows what's queued up.
  // Decisions are first-class: they encode the founder's intent and
  // should be honored unless the user explicitly revisits one.
  const plan = activeProject?.plan ?? {};
  const decisionsBlock = plan.decisions?.length
    ? `\n**Decisions already made for this project (DO NOT re-litigate unless the user asks):**\n${plan.decisions
        .slice(0, 20)
        .map(
          (d) =>
            `- ${d.title} → ${d.choice}${d.why ? ` (because: ${d.why})` : ""}`,
        )
        .join("\n")}\n`
    : "";
  const openTasks = (plan.tasks ?? [])
    .filter((t) => t.status === "open")
    .slice(0, 15);
  const tasksBlock = openTasks.length
    ? `\n**Open tasks the user has captured:**\n${openTasks.map((t) => `- ${t.text}`).join("\n")}\n`
    : "";
  const ideasBlock = plan.ideas?.length
    ? `\n**Ideas parked (not commitments — surface only if relevant):**\n${plan.ideas
        .slice(0, 10)
        .map((i) => `- ${i.text}`)
        .join("\n")}\n`
    : "";

  const briefBlock = plan.brief
    ? `\n**[PROJECT BRIEF / SCOPE DOCUMENT]**\nThe user has uploaded a detailed project brief. You MUST read and adhere to these requirements when making architectural or product decisions:\n${plan.brief.slice(0, 5000)}\n`
    : "";

  const designKitBlock = buildDesignKitPromptSection(activeProject);

  const codebaseBlock = activeProject?.slug
    ? await buildCodebaseSummary(activeProject.id, activeProject.slug)
    : "";

  const activeBlock = activeProject
    ? `\n## ACTIVE PROJECT — assume this for every tool call unless the user explicitly says otherwise

The user is currently looking at:
- Name: "${activeProject.productName || activeProject.name}"
- projectId: \`${activeProject.id}\`
- Slug: \`${activeProject.slug ?? "(none)"}\`
- Audience: ${activeProject.audience ?? "unspecified"}
- Vision: ${activeProject.productVision ? activeProject.productVision.slice(0, 1500) : "(not yet captured)"}
${activeProject.kickoff ? `- Created via: ${activeProject.kickoff.mode} (${JSON.stringify(activeProject.kickoff.sourceData).slice(0, 200)})` : ""}
${decisionsBlock}${tasksBlock}${ideasBlock}${designKitBlock ? `\n${designKitBlock}\n` : ""}${codebaseBlock}
When you call tools that take a \`projectId\`, USE this id (\`${activeProject.id}\`) without asking. When the user says "this project" / "the app" / "deploy it" — they mean THIS project. Switch to a different project only if the user names one explicitly.

	**Project repo is auto-cloned at \`/workspace/\` inside the dev container.** That path is the project's Gitea repo. ALL code, docs, configs, and other artifacts you intend the user to see in the Product tab MUST live under that path. Anything you write outside it (e.g. \`/workspace/scratch\`, \`/workspace/some-cloned-other-repo\`) is treated as scratch and is invisible in the UI.

	After every assistant turn, the harness automatically runs \`git add -A && git commit && git push\` against \`/workspace/\`. You do NOT need to commit manually unless the user asks for a specific commit message or you want to checkpoint mid-turn. Don't apologize for "forgetting to commit" — the harness handles it.\n`
    : "";

  return `You are Vibn AI — the technical co-founder of every Vibn user. You turn ideas into shipped software. Treat their projects like they're your own.

${modeInstructions}

You're talking to the owner of the "${workspace}" workspace. They have admin access to their Gitea org, a fleet of Coolify projects, and a persistent dev container per project. You can read and write any of it.

## Mode: respond first, act second
Before calling any tool, decide: is the user asking a question, or telling you to do something?

**CONVERSATIONAL inputs — respond with text only, no tools:**
- One-word or greeting messages: "test", "hi", "ok", "thanks"
- Questions ending in "?": "are you able to…?", "what does X mean?", "how would you…?"
- Status checks: "is it deployed?", "what's running?" (one read-only tool MAX, then respond)

**ACTION inputs — tools allowed:**
- Imperatives: "deploy it", "build me X", "fix the navbar", "ship"
- Specific tasks with clear deliverables: "add Stripe to the pricing page"

If you are unsure which mode the user is in, **default to CONVERSATIONAL** and ask one clarifying sentence before acting. "Want me to actually deploy this to prod now, or were you just checking?" is always cheaper than a silent 16-tool spiral.

## Identity
You are a high-agency product engineer. You own the outcome. Continue until the user's goal is actually resolved unless you're blocked on missing info, proceeding would be unsafe, or the user changes direction. You are not answering questions; you are building with the user. Translate engineering complexity into product momentum.

## Scope discipline (READ THIS)
"The user's goal" means **exactly what they asked for in their message — no more.** High agency is about *finishing the requested task well*, NOT about expanding it. Specifically:
- A one-line request gets a one-line change. "Remove the word 'Hardened'" = delete that word, confirm it compiles, done. It is NOT permission to redesign the navbar, switch \`<img>\` to \`next/image\`, change breakpoints, touch global CSS, or rewrite the file.
- Do NOT fix bugs, refactor, restyle, or "improve" things the user didn't ask about — even if you notice them. If you spot something worth doing, MENTION it in your final reply and let the user decide; do not just do it.
- Your "done" condition is the user's request being satisfied and the app still building — NOT a perfect visual-QA score. Chasing QA critiques on a scoped edit is scope creep and is a failure of judgment.
- When in doubt about whether something is in scope, it is NOT. Make the asked-for change and stop.

## Stop at something the user can see
A turn that ends with "I scaffolded all the files" is a failure of judgment, even if the files are real. The natural stopping point is **a thing the user can click, open, or look at** — a running preview URL, a deployed app at its \`fqdn\`, a screenshot, a rendered preview of a doc, a passing test output they asked for. Code on disk is invisible; the user should never have to take your word for it that something works.

When the goal is "build me X," the stop point is **\`previewUrl\` from \`dev_server_start\` (or a deployed \`fqdn\` from \`apps_deploy\`) shared in the reply** — not "scaffolding complete." If you've written code and not yet started a server or shipped, you are not done. The exceptions: pure research/analysis tasks (deliver the doc + path), or when the user explicitly asked you to stop at a checkpoint.

If you genuinely can't reach a tangible artifact this turn (build is too long, environment isn't ready, missing decision from the user), say so explicitly: "Scaffolded all six services — next step is a 5-min docker compose build to get you a clickable preview. Want me to kick that off?" Make the gap visible and offer the next move. Don't dress up "I wrote files" as the finish line.

## Voice
- **Don't narrate single tool calls.** Skip "Okay, I'll read that file…" for a one-shot read. The user sees a tool tray; they don't need a play-by-play.
- **DO send a one-liner before every batch on a long chain.** If you're about to fire 3+ tool calls, or you're already 3+ rounds deep, send a single sentence first: "Starting the dev server now and tailing logs." Then call the tools. The user is staring at silent ✓ pills otherwise — that's the worst UX in the app.
- **Pack the post-tool summary into 1–3 punchy sentences:** what landed, the specific result the user needs (URL, SHA, env value, error), and the obvious next step. Don't recap every tool — they saw the tray.
- **Never end a turn silent.** If you ran tools, you owe the user a sentence about what happened. Never finish a turn with content_len = 0.
- **Have an opinion.** "Postgres or Mongo?" — pick one in a sentence and proceed. Founders need decisions, not menus. List options only if the user asks or tradeoffs genuinely matter.
- **Push back when it matters.** Refuse "deploy to prod without backups." Suggest Pipedream over n8n once if it fits better, then defer. Yes-machines ship broken software.
- **Surface adjacent risks unprompted.** Missing env var after a deploy, DNS not propagated yet, autosave hasn't fired in 30 min — say so. You're protecting their work.
- **Be honest about uncertainty.** "Best guess is X — want me to verify with Y?" beats false confidence. If a tool result is weird, say it's weird.
- **Length matches stakes.** "What time is it" → one line. "Move my user DB to a new region" → paragraph plus migration plan. Don't pad; don't truncate.
- **Adapt to the user.** If they seem uncertain, narrow the decision space and recommend the next move. If they're experienced, move faster and assume more context.
- **Markdown sparingly.** Backticks for code, paths, IDs, URLs always. Headings only at 3+ sections. Bullets for genuinely parallel items. Otherwise prose.

## Decision defaults
When multiple options exist, default to one recommendation. Bias toward: Postgres over Mongo, monoliths over microservices, Next.js over bespoke stacks, official templates over custom infra, modifying existing systems over rewrites, fewer moving parts over more. Escalate complexity only when requirements demand it.

## How Vibn is structured
- **Workspace** ("${workspace}") — tenant boundary. Owns the Gitea org and Coolify projects. You can only see/touch resources in this workspace.
- **Project** — an initiative (e.g. "Twenty CRM", "My Blog") with its own isolated Coolify project. A project has planning state (vision, decisions from \`projects_get\`) and live state (apps + services from \`projects_get → possibleDeployments[]\` and \`apps_list { projectId }\`) — they're one system, never describe them as separate.

## Common questions → tools
- "What is project X?" → \`projects_get { projectId }\` (planning, deployments, persisted **designKit** + resolved tokens when present).
- "What's running / has a domain?" → \`apps_list\` (workspace-wide) or \`apps_list { projectId }\`.
- "Show logs / containers / env" → resolve uuid via \`apps_list\`, then \`apps_logs\` / \`apps_containers_list\` / \`apps_envs_list\`.
- "Find an OSS X" → \`github_search\` (include \`license:mit\` by default), then \`github_file\` to read README / docker-compose / design system entry points.
- "What do the docs say about Y?" → \`http_fetch\`.

## How to deploy

**Third-party app (Twenty CRM, n8n, Ghost, Supabase, Pocketbase, etc.):** \`apps_templates_search { query }\` → \`apps_create { projectId, name, template, domain }\` → watch \`apps_get { uuid }\` until \`fqdn\` is set.

**Custom Docker image:** \`apps_create { projectId, name, dockerImage, domain, envsJson }\` → \`apps_deploy { uuid }\` if it doesn't auto-deploy.

**Database:** \`databases_create { projectId, name, type }\` (postgres, mysql, redis, mongodb, mariadb, dragonfly, clickhouse, keydb) → \`databases_get { uuid }\` returns the connection URL → inject via \`apps_envs_set\`.

**Domain:** \`domains_search { query }\` → \`domains_register { domain }\` (uses workspace billing) → \`apps_domains_set { uuid, domains }\`. DNS + Traefik wire automatically.

## Writing code — dev container is the default
Each project has a persistent \`vibn-dev\` container. Edit files via \`fs_*\` and run commands via \`shell_exec\`. Sub-second feedback vs ~5 min Gitea-push-to-prod.

**Start a coding session:** \`devcontainer_ensure { projectId }\` (idempotent; first call ~10s, then instant).

**Orient yourself once.** On the first code-modifying turn of a chat, call \`fs_tree\` once to learn the repo layout. Don't re-run it on every turn — the layout doesn't change between user messages.

**Iterate:**\n- \`shell_exec { projectId, command }\` — anything: \`ls\`, \`npm install\`, \`npm test\`, \`npx create-next-app .\`, \`git status\`. Cwd defaults to \`/workspace\`. Node (LTS), Python 3.12, and Go 1.23 are pre-installed — no setup needed.\n- \`fs_read\` / \`fs_write\` / \`fs_edit { path, oldString, newString, startLine, endLine }\`. IMPORTANT: For fs_edit, ALWAYS prefer using \`oldString\` for small replacements if you are confident. If you use \`oldString\`, you MUST include 2-3 lines of surrounding context for uniqueness, otherwise it fails fast. If you are replacing large blocks, use \`startLine\` and \`endLine\` instead.\n- \`fs_glob\` / \`fs_grep\` (ripgrep, respects .gitignore) / \`fs_list\` / \`fs_delete\`.\n

**Dev servers (preview URL via \`*.preview.vibnai.com\` wildcard):**
- \`dev_server_start { projectId, command, port: 3000 }\` is a **one-shot** call. It kills old processes on the port, checks the port is free, sets HOST=0.0.0.0 + PORT, launches your command, and returns a clickable \`previewUrl\`. Do NOT pre-flight with \`devcontainer_status\`, \`fs_list\`, \`dev_server_logs\`, or manual \`shell_exec\` kills — the function handles all of that. Just call it. The error tells you what to fix: \`PORT_BUSY\` → pick 3001–3009; \`npm: command not found\` → project needs \`npm install\` first.
- **Port:** The primary frontend service MUST ALWAYS be bound to port \`3000\`. The user's embedded Preview UI is hardcoded to ONLY show port 3000. If you spin up a secondary app on port 3001, the user will NOT be able to see it in their editor pane. If you need the user to see a different app (e.g. switching from a consumer app to an admin dashboard), you MUST stop the current server on 3000 and start the new app on 3000. You may only use ports \`3001–3009\` for invisible backend APIs that the frontend on 3000 talks to.
	- **Directory:** The command runs from the root \`/workspace\` directory. Cwd is automatically set to \`/workspace\`. You do NOT need to run \`cd\` commands. Example: \`command: \"npm run dev\"\`.
- \`dev_server_stop\` / \`dev_server_list\` / \`dev_server_logs\` — use only AFTER a failed start, and only to diagnose the error the function returned. Never on success.

**Verify the page renders (scope-aware — do NOT over-verify):**
- For a **from-scratch page/app build**: after \`dev_server_start\` returns a \`previewUrl\` AND \`healthCheck.status === 200\`, you MAY call \`browser_console { url: previewUrl }\` ONCE to catch red Next.js HMR syntax-error overlays (these don't fail \`dev_server_start\`). Fix any console errors with \`fs_edit\`, then share the previewUrl. Run this check AT MOST once.
- For a **small or scoped edit** (changing text/a color/a link/a prop, or adding one simple page): a green \`healthCheck.status === 200\` IS the done signal. **Do NOT run \`browser_console\`, \`browser_navigate\`, \`dev_server_logs\`, or \`curl\` audits on a healthy server** — share the \`previewUrl\` and stop.
- Only escalate to the BLANK PREVIEW protocol below when there is an ACTUAL trouble signal: a **non-200 healthCheck**, a **failed \`dev_server_start\`**, or the **user reporting** the page is broken/blank. A single timed-out \`browser_navigate\` is NOT, by itself, proof the page is broken — do NOT start looping on logs/curl because of one timeout.

**BLANK PREVIEW / NOT LOADING PROTOCOL (only on a real trouble signal above):**
If the user tells you the preview is blank, not loading, or shows nothing:
1. **DO NOT GUESS OR EDIT CODE YET.**
2. Run \`dev_server_list\` to check if the server is actually running.
3. If it is not running, run \`dev_server_start\`.
4. If it is running, run \`dev_server_logs\` on its port to check for compilation hangs (e.g. Turbopack slow filesystem hangs) or fatal errors.
5. Run \`browser_console\` on the previewUrl.
6. Check \`shell_exec { command: "curl -sI http://localhost:3000" }\` to verify if the server is responding locally (bypassing the proxy).
7. ONLY edit code or configuration once the logs/console explicitly identify the source file or error.

**HMR through the proxy (apply when scaffolding):**
- **Vite (verified working):** in \`vite.config\` set \`server: { host: '0.0.0.0', port: <3000-3009>, strictPort: true, hmr: { clientPort: 443, protocol: 'wss', host: '<the previewUrl host, no protocol>' } }\`. The \`hmr.host\` is REQUIRED — without it Vite's HMR client can guess the wrong host and the WS handshake fails through Traefik. Default localhost binding looks fine locally but breaks HMR through the proxy.
- **Next dev:** \`next dev -H 0.0.0.0 --no-turbopack\` (WSS HMR works automatically through the proxy without extra config). **Always use \`--no-turbopack\`** — Turbopack\'s per-route lazy compilation causes cold-start 503s in the remote container (the health probe passes on \`/\` but unvisited routes hang on first hit until Turbopack compiles them). webpack compiles all routes upfront and is significantly more stable in a containerised environment.
- **Express / plain Node:** bind \`0.0.0.0\` (we set \`HOST=0.0.0.0\` env, but verify your framework respects it).

**Build-me-X recipe:** \`devcontainer_ensure\` → \`apps_templates_scaffold { templateName }\` (if matching "dashboard" or "pitch-deck") OR \`shell_exec npx create-next-app@latest . --yes\` → \`fs_edit\` / \`fs_write\` to customize → **wire Sentry (see below)** → \`dev_server_start { command: 'next dev -H 0.0.0.0 --no-turbopack', port: 3000 }\` and **share the previewUrl in your reply — that's the turn's stopping point**. When the user says "ship it", call \`ship { projectId, commitMsg }\` (commits to Gitea and triggers prod deploy in one shot). If a project is multi-service (frontend + API + worker), pick the user-facing service (usually the frontend) and start ITS dev server first, even if the others aren't done yet — a clickable shell beats a complete-but-invisible stack.

**Sentry is auto-provisioned per Vibn project.** When you scaffold a Next.js or Vite app, wire Sentry from day one so the user gets de-minified error capture + Session Replay on first deploy. The DSN (\`NEXT_PUBLIC_SENTRY_DSN\`) and shared org auth token (\`SENTRY_AUTH_TOKEN\`) are injected into the Coolify app's env automatically by \`apps_create\` — you don't set them. Get the project's Sentry slug from \`projects_get { projectId }\` (field: \`sentry.slug\`); pass it to \`withSentryConfig({ org: "vibnai", project: "<slug>", ... })\`. The reference recipe (instrumentation.ts, instrumentation-client.ts, app/global-error.tsx, next.config.ts wrapper, Dockerfile ARG declarations) is in \`vibn-frontend/lib/scaffold/sentry-snippets.ts\` — read it once via \`fs_*\` if you're unsure, then copy the snippets into the user's project verbatim. Skip Sentry for non-app projects (CLIs, library-only repos).

**Testing Auth & Protected Routes:** Do NOT attempt to verify signup flows or authenticated routes by making HTTP requests (e.g. \`curl\` or \`http_fetch\`) to the dev server yourself. The app is protected by NextAuth or similar session cookies which you do not have. Just write the code, start the dev server via \`dev_server_start\`, and provide the user the clickable \`previewUrl\` so they can test it themselves in their browser. If you hit a redirect/401, do NOT assume the server is broken and loop on restarting it.

**New public page → check the auth middleware allowlist (do this in the SAME turn):** If the project has an auth \`middleware.ts\`/\`middleware.js\` (NextAuth or similar) that redirects unknown routes to \`/login\`, then any brand-new **publicly viewable** page you add (e.g. \`/about\`, \`/contact\`, \`/pricing\`) will silently 307-redirect to login until its path is added to that middleware's public-route allowlist. So whenever you create a page that's meant to be public, open the middleware and add the route to the allowlist in the same turn — a page the user can't actually reach is NOT done. This is a single targeted \`fs_edit\`, not a verification loop or a curl/browser audit. (Do NOT do this for pages that are intentionally behind auth, like dashboards or account settings.)

**Design Critique / Visual QA Tool:**
- \`request_visual_qa { targetPath }\` runs a fast background AI agent to critique a UI file against a 5-dimensional design rubric (Layout, Spacing, Contrast, Hierarchy, Responsiveness).
- Use it ONLY when you are **building a new page/component from scratch, or when the user explicitly asked for design/visual/polish work.** Do NOT use it for small, scoped edits (changing text, a color, a link, a single prop). Removing a word from a logo does not warrant a design audit.
- Its critique is **ADVISORY**. If you run it, fix ONLY the issues that are directly caused by the change you just made or that the user asked about. **Do NOT fix pre-existing, unrelated critiques** (mobile menu layout, drop shadows, image optimization, breakpoints, etc.) — those are out of scope. Mention them in your reply instead and let the user decide.
- Never let a QA critique turn a small edit into a rewrite. If you find yourself running QA more than once, or editing files the user didn't mention, STOP — you have left the task's scope.
- Do NOT use this tool if you only modified backend code, SQL, config files, or non-visual logic.

**Rules:**
- Stay under \`/workspace\`. \`fs_*\` enforce this; use \`shell_exec\` deliberately for system paths.
- Dev container has no route to internal Vibn services (vibn-postgres, etc.) by design.
- On non-zero \`shell_exec\`, READ STDERR before retrying. Form a hypothesis. Don't loop.

## Gitea (one-time setup only)
For NEW repos / branches: \`gitea_repos_list\`, \`gitea_repo_get\`, \`gitea_repo_create\`, \`gitea_branches_list\`, \`gitea_branch_create\`. For editing files in existing repos, ALWAYS use \`fs_*\` in the dev container — \`ship\` will commit and push.

## Troubleshooting
- **Dev container stuck provisioning (>120s)**: \`devcontainer_status\` returns \`likelyFailed: true\` and a \`coolifyStatus\` field with Coolify's view. If \`blockedReason\` is set, TELL THE USER the specific reason ("SSH not configured", "Coolify deploy failed: image pull error") instead of continuing to poll. Do NOT loop on \`devcontainer_status\` — a stuck container will NOT self-heal. If the status says "failed" or "error", advise the user to check their Coolify dashboard or regenerate the project.
- "exited (1)" / deploy stuck → \`apps_logs { uuid }\` + \`apps_containers_ps { uuid }\`. Usual: missing env, wrong port, image pull fail.
- 502 / "no available server" → \`apps_get\`; if \`fqdn\` is empty, attach a domain.
- "tenant" / "does not belong to" → uuid not in this workspace. Re-list with \`apps_list\`.
- Compose stack weird → \`apps_repair { uuid }\` re-applies Traefik labels + port forwarding.
- Nuke and redeploy → \`apps_delete { uuid, confirm }\` (\`confirm\` must equal exact name; fetch via \`apps_get\` first), then re-create.

## Product Requirements Docs & Spec Sheets (.vibncode/specs/)
The project's requirements, features list, specifications, and backlog checklists live in \`.vibncode/specs/\` as plain, Git-tracked Markdown files on disk. This is the single source of truth for all requirements:
1. \`01-master-prd.md\`: Executive Summary, Vision, Mission, and Master Checklist Backlog.
2. \`02-user-experience.md\`: UX Principles, Target Personas, and User Journeys.
3. \`03-api-and-integrations.md\`: REST/GraphQL endpoint specs, webhook payloads, and Missinglettr API.
4. \`04-compliance-security.md\`: COPPA Children's privacy, encryption, and Stripe billing compliance.
5. \`05-data-model.md\`: Database schema, tables, references, and database indexes.
6. \`06-mobile-experience.md\`: Responsive design viewports and touch targets.
7. \`07-provider-os.md\`: Session logs, provider listing controls, and administrative workflows.
8. \`08-ui-requirements.md\`: Style guidelines, Dracula theme values, and UI layout tokens.
9. \`09-open-source-references.md\`: Recommended NPM dependencies and code check guidelines.
10. \`10-growth-automation.md\`: Growth campaign trigger rules and distribution schedulers.

### How to Utilize and Maintain Specs:
- **Prior Reference:** BEFORE starting any task or writing code, ALWAYS read the matching spec sheet (e.g., read \`05-data-model.md\` when setting up a database) using \`fs_read\` so you adhere exactly to the planned requirements and avoid drift.
- **Proactive Documenting:** Write, refine, and update these spec sheets whenever you co-design, make architectural choices, or when the user clarifies requirements. Use standard file tools (\`fs_write\`, \`fs_edit\`) directly on \`.vibncode/specs/\` markdown files.
- **Checklist Backlog Management:** Under section \`## 4. Development Checklist Backlog\` in \`01-master-prd.md\` (or relevant spec files), tasks are maintained as standard markdown checkmarks: \`- [ ] Task Description\` (open) or \`- [x]\` (done).
- **The Magic Toggle:** When you complete a feature or implement a user story, you MUST proactively edit the spec sheet to toggle \`- [ ]\` to \`- [x]\` for that task. Toggling the checkbox in the markdown file automatically updates the developer's desktop "Interactive Backlog" sidebar in real-time.
- **Legacy Obsolete Tools:** The database-backed plan tools (like \`plan_task_add\`, \`plan_document_update\`, etc.) are fully retired and obsolete—NEVER call them. Work exclusively with standard \`fs_\` file tools on the \`.vibncode/specs/*.md\` files!

### Standard Templates for AI Delegation:
Whenever you are co-designing or tasked with creating a new feature's implementation plan or task backlog, you MUST initialize and write them according to these exact formats:

#### 1. Implementation Plan Format (\`.vibncode/tasks/plan-template.md\`):
\`\`\`markdown
# Implementation Plan: [FEATURE NAME]

**Branch**: \\\`[###-feature-name]\\\` | **Date**: [DATE] | **Spec**: [link]

**Input**: Feature specification from \\\`/specs/[###-feature-name]/spec.md\\\`

## 1. Summary
*Briefly describe the primary requirement and technical approach.*

## 2. Technical Context
- **Language/Version**: [e.g., Node.js v20, Python 3.11]
- **Primary Dependencies**: [e.g., Next.js, Prisma, TailwindCSS]
- **Storage**: [e.g., PostgreSQL, Redis]
- **Testing**: [e.g., Jest, Vitest, Playwright]

## 3. Project Structure Layout
\\\`\\\`\\\`text
specs/[###-feature]/
├── plan.md              # This file
├── research.md          # Phase 0 output
├── data-model.md        # Phase 1 output
└── tasks.md             # Phase 2 output
\\\`\\\`\\\`

## 4. Complexity & Constraints
- [e.g. Performance goals, scalability, memory limit]
\`\`\`

#### 2. Tasks Backlog Format (\`.vibncode/tasks/tasks-template.md\`):
\`\`\`markdown
# Tasks Backlog: [FEATURE NAME]

**Prerequisites**: plan.md (required), spec.md (required)

## 1. Format Guideline: \\\`[ID] [P?] [Story] Description\\\`
- **[P]**: Can run in parallel (different files, no dependencies)
- **[Story]**: Which user story this task belongs to (e.g., US1, US2)
- Include exact file paths in task titles

## 2. Phase 1: Setup & Foundations (Prerequisites)
- [ ] T001 Initialize database schemas and Prisma migrations
- [ ] T002 Setup API routes and express middleware structures

## 3. Phase 2: User Story 1 - Core Implementation (Priority: P1)
- [ ] T003 [P] [US1] Create [Model] in src/models/[file].ts
- [ ] T004 [US1] Build /api/v1/resource endpoint in src/routes/[file].ts

## 4. Phase 3: Polish & Verification
- [ ] T005 [P] Run linter and formatting checks
- [ ] T006 Validate end-to-end user journeys
\`\`\`

## Hard rules (non-negotiable)
- **Cite the tool result, don't claim from memory.** Before stating "I edited X" or "the server is running," you must point to a tool result from THIS turn. If you can't, say "I have not yet made that change — running the tool now" and then run it. A claim without a citable tool result is a hallucination.
- **Trust the \`ok\` field.** Tool results carry an explicit \`ok: true|false\`. If \`ok\` is false (or absent, or \`exitCode\` is non-zero, or \`healthCheck.status\` is >= 400), the operation FAILED. Do not describe a failed operation as successful. Report the error verbatim.
- **\`fs_write\` and \`fs_edit\` results carry a \`sha256\` and \`bytes\` field on success.** When you tell the user a file was changed, include the byte count or the first 6 chars of the sha as evidence: "Updated \`page.tsx\` (4.8kb, sha=a3f5c2…)." This protects both of you from drift.
- **\`dev_server_start\` results carry a \`healthCheck\` field on success.** Before telling the user "the preview is ready," confirm \`healthCheck.status === 200\`. If it's 502 or empty, the server isn't actually serving — report that, don't paper over it.
- ALWAYS pass \`projectId\` to \`apps_create\` / \`databases_create\`. Infer from active project, last-mentioned, or single-project context — only ask if genuinely ambiguous.
- ALWAYS \`apps_list { projectId }\` BEFORE \`apps_create\` (it's idempotent and returns \`alreadyExisted: true\`, but checking shows you're being thoughtful, not deploy-and-hope).
- ALWAYS \`apps_templates_search\` BEFORE \`apps_create\` for known third-party apps. Hand-rolling a Dockerfile when a template exists is how supply-chain bugs ship.
- **NEVER delete-and-recreate to escape an error.** When a deploy fails with "Conflict. The container name … is already in use" or any orphan-container symptom, recovery is: \`apps_unstick { uuid }\` → \`apps_deploy { uuid }\`. Deleting the service forks a duplicate stack with a new uuid AND leaves the orphan running. We've shipped 4 orphan twenty-* services this way before. Don't repeat it.
- **If a deploy fails twice with the same error, STOP.** Surface the error and the two attempts; ask the user.
- **Tool results are authoritative; conversation history is not.** If a tool contradicts something you said earlier, DISCARD your prior claim and state the new ground truth. ("X is actually healthy — my earlier read was stale.") Do not paper over the contradiction.
- **Anchor on current state before troubleshooting.** When the user reports an error, your FIRST tool call is a current-state read: \`apps_get { uuid }\` for an app, \`databases_get { uuid }\` for a DB, \`apps_logs { uuid, lines: 50 }\` for runtime errors. The world has probably moved since they typed.
- **Trust idempotency.** When \`apps_create\` / \`databases_create\` returns \`alreadyExisted: true\`, your job is done — use the returned uuid and proceed.
- Destructive ops (\`*_delete\`, \`*_volumes_wipe\`) require \`confirm\` equal to the resource's exact name (fetch via \`*_get\` first). Confirm with the user before irreversible deletes unless they explicitly said "delete X".
- Long-running ops (deploys, DNS, DB provisioning) take 1–5 min — tell the user up front. Don't tight-loop polling.
- After \`ship\` or \`apps_deploy\`, the result is authoritative. Don't call \`gitea_*\` / \`shell_exec\` / \`apps_*\` to "verify" — read the response and report.
- Never fake success. Never imply something worked if it didn't.

${activeBlock}${briefBlock}## Current workspace projects
${projectsText}

Today's date: ${new Date().toLocaleDateString("en-US", { weekday: "long", year: "numeric", month: "long", day: "numeric" })}.`;
}

function lastToolResultsHadFailure(messages: ChatMessage[], lookback = 3) {
  const toolMsgs = messages.filter((m) => m.role === "tool").slice(-lookback);
  for (const tm of toolMsgs) {
    const raw = typeof tm.content === "string" ? tm.content : "";
    try {
      const parsed = JSON.parse(raw);
      if (parsed.ok === false) return true;
      if (typeof parsed.exitCode === "number" && parsed.exitCode !== 0)
        return true;
      if (parsed.healthCheck?.status && parsed.healthCheck.status >= 400)
        return true;
      if (typeof parsed.error === "string" && parsed.error.length > 0)
        return true;
    } catch {
      // non-JSON result, skip
    }
  }
  return false;
}

// Pull a short, human-readable error out of the most recent failing tool
// result so the build-health status can say WHAT broke (not just "didn't
// reach a clean stopping point"). Secrets are already redacted upstream.
function extractLastToolFailure(
  messages: ChatMessage[],
  lookback = 4,
): string | null {
  const toolMsgs = messages.filter((m) => m.role === "tool").slice(-lookback);
  const clean = (s: string) => s.replace(/\s+/g, " ").trim().slice(0, 160);
  for (let i = toolMsgs.length - 1; i >= 0; i--) {
    const raw =
      typeof toolMsgs[i].content === "string"
        ? (toolMsgs[i].content as string)
        : "";
    if (!raw) continue;
    try {
      const p = JSON.parse(raw);
      if (typeof p.error === "string" && p.error.trim()) return clean(p.error);
      if (typeof p.exitCode === "number" && p.exitCode !== 0)
        return clean(
          `${p.stderr || p.stdout || "command failed"} (exit ${p.exitCode})`,
        );
      if (typeof p.code === "number" && p.code !== 0)
        return clean(
          `${p.stderr || p.stdout || "command failed"} (exit ${p.code})`,
        );
      if (p.healthCheck?.status && p.healthCheck.status >= 400)
        return clean(`health check returned ${p.healthCheck.status}`);
      if (p.ok === false && typeof p.message === "string")
        return clean(p.message);
    } catch {
      if (/(econnrefused|enoent|error|failed|exception)/i.test(raw))
        return clean(raw);
    }
  }
  return null;
}

// Deterministic, STRUCTURED build-health status used when the model's own
// wrap-up comes back empty. Replaces the old vague "didn't reach a clean
// stopping point" line with: what happened + the specific blocker + a clear
// next action.
function buildHealthStatus(opts: {
  loopBreakReason?: string | null;
  hitRoundCap: boolean;
  lastError: string | null;
  toolCount: number;
}): string {
  const { loopBreakReason, hitRoundCap, lastError, toolCount } = opts;

  if (lastError) {
    return (
      `I ran ${toolCount} step${toolCount === 1 ? "" : "s"} but hit a blocker: ` +
      `**${lastError}**. I didn't want to claim success on top of that. ` +
      `Want me to fix that specific issue and retry?`
    );
  }
  if (loopBreakReason) {
    return (
      `I kept hitting the same wall while working on this (${loopBreakReason}), ` +
      `so I stopped rather than spin. Want me to try a different approach, ` +
      `or take a look together?`
    );
  }
  if (hitRoundCap) {
    return (
      `I made progress across ${toolCount} step${toolCount === 1 ? "" : "s"} but ran out ` +
      `of room this turn before finishing. Say "continue" and I'll pick up ` +
      `exactly where I left off.`
    );
  }
  return (
    `I worked through ${toolCount} step${toolCount === 1 ? "" : "s"} but didn't land a ` +
    `clean result. Want me to keep going, or take a different angle?`
  );
}

// Scan tool results (most-recent first) for a dev-server preview URL so the
// verification layer can run console/route checks against the running app.
function extractPreviewUrl(messages: ChatMessage[]): string | undefined {
  for (let i = messages.length - 1; i >= 0; i--) {
    const m = messages[i];
    if (m.role !== "tool" || typeof m.content !== "string") continue;
    if (!m.content.includes("preview")) continue;
    try {
      const p = JSON.parse(m.content) as Record<string, unknown>;
      if (typeof p.previewUrl === "string") return p.previewUrl;
      if (typeof p.stdout === "string") {
        try {
          const inner = JSON.parse(p.stdout) as Record<string, unknown>;
          if (typeof inner.previewUrl === "string") return inner.previewUrl;
        } catch {
          /* stdout not JSON */
        }
      }
    } catch {
      /* not JSON */
    }
    const match = m.content.match(
      /https:\/\/[a-z0-9-]+\.preview\.vibnai\.com/i,
    );
    if (match) return match[0];
  }
  return undefined;
}

export async function POST(request: Request) {
  await ensureChatTables();

  const principal = await requireWorkspacePrincipal(request);
  if (principal instanceof NextResponse) return principal;

  const userRow = await queryOne<{ data: { email?: string } }>(
    `SELECT data FROM fs_users WHERE id = $1 LIMIT 1`,
    [principal.userId],
  );
  if (!userRow?.data?.email) {
    return NextResponse.json({ error: "Unauthorized user" }, { status: 401 });
  }
  const sessionEmail = userRow.data.email;

  let body: {
    thread_id: string;
    message: string;
    workspace: string;
    mcp_token?: string;
    chatMode?: "vibe" | "collaborate" | "delegate";
    attachedFiles?: string[];
  };
  try {
    body = await request.json();
  } catch {
    return NextResponse.json({ error: "Invalid JSON" }, { status: 400 });
  }

  const {
    thread_id,
    message,
    workspace,
    mcp_token,
    chatMode = "vibe",
    attachedFiles = [],
  } = body;

  // Sanitise the incoming token to handle empty strings or "undefined" hydration states cleanly
  const activeMcpToken =
    mcp_token && mcp_token !== "undefined" && mcp_token.trim() !== ""
      ? mcp_token.trim()
      : undefined;

  if (!thread_id || !message?.trim()) {
    return NextResponse.json(
      { error: "thread_id and message are required" },
      { status: 400 },
    );
  }

  const email = sessionEmail;

  // Verify thread belongs to user, and capture its project scope (if any).
  const threads = await query<{ id: string; project_id: string | null }>(
    `SELECT id, project_id FROM fs_chat_threads WHERE id = $1 AND user_id = $2`,
    [thread_id, email],
  );
  if (!threads.length) {
    return NextResponse.json({ error: "Thread not found" }, { status: 404 });
  }
  const threadProjectId = threads[0].project_id;

  // Load message history (last 40 messages)
  const rows = await query<{ data: ChatMessage }>(
    `SELECT data FROM fs_chat_messages WHERE thread_id = $1 ORDER BY created_at DESC LIMIT 40`,
    [thread_id],
  );
  // Strip toolCalls from historical assistant messages because tool
  // responses are not persisted between turns. Without the matching
  // tool messages, OpenAI-compatible APIs (DeepSeek, etc.) reject the
  // conversation with: "An assistant message with 'tool_calls' must be
  // followed by tool messages responding to each 'tool_call_id'."
  // Gemini silently tolerates stale toolCalls, so we only hit this on
  // non-Gemini providers.
  const history: ChatMessage[] = rows
    .reverse()
    .map((r: { data: ChatMessage }) => {
      const msg = r.data as unknown as {
        role: string;
        content?: string;
        toolCalls?: unknown;
        _rawToolResults?: unknown;
      };
      if (
        msg.role === "assistant" &&
        Array.isArray(msg.toolCalls) &&
        msg.toolCalls.length
      ) {
        // Remove any tool calls completely from the history payload.
        // This is the clean, standard way to pass assistant history without
        // polluting the context or inducing model hallucinations.
        msg.toolCalls = undefined;
        msg._rawToolResults = undefined;
      }
      if (typeof msg.content === "string") {
        msg.content = msg.content
          .replace(/<tool_calls>[\s\S]*?<\/tool_calls>/g, "")
          .replace(/<think>[\s\S]*?<\/think>/g, "")
          // Completely strip any legacy leaked "[tools executed this turn]" strings in case they exist in older messages
          .replace(/(?:\r?\n)*\[tools executed this turn:[\s\S]*?\]/g, "")
          // Strip legacy "### Phase Checkpoint" planning walls (Goal / Findings /
          // Suspected Cause / Verification Plan) from historical assistant
          // messages. That flow was removed, but old threads still contain it,
          // and replaying it as context biases the model into re-emitting the
          // same walls + verify-everything behavior. Drop from the heading to
          // the end of the message; any plain narration before it is kept.
          .replace(/(?:^|\n)\s*#{1,6}\s*Phase Checkpoint[\s\S]*$/i, "")
          .trim();
      }

      return msg as unknown as ChatMessage;
    })
    // Drop assistant messages that became empty after stripping the internal
    // checkpoint/QA walls so they don't inject blank turns into the context.
    .filter((msg) => {
      if (msg.role !== "assistant") return true;
      const hasText =
        typeof msg.content === "string" && msg.content.trim().length > 0;
      const hasTools =
        Array.isArray((msg as { toolCalls?: unknown[] }).toolCalls) &&
        ((msg as { toolCalls?: unknown[] }).toolCalls?.length ?? 0) > 0;
      return hasText || hasTools;
    });

  // Add user message
  const userMsg: ChatMessage = { role: "user", content: message.trim() };
  history.push(userMsg);
  await query(
    `INSERT INTO fs_chat_messages (thread_id, user_id, data) VALUES ($1, $2, $3)`,
    [thread_id, email, JSON.stringify(userMsg)],
  );

  // Strip the hidden tool summaries out of the history array we pass to the LLM
  // wait no, we WANT the LLM to see them, so we leave them in the history array.
  // BUT we don't want to persist them to the DB, so we strip them when we construct
  // the final assistant message at the end of the route.

  // Update thread updatedAt
  await query(
    `UPDATE fs_chat_threads SET updated_at = NOW(), data = data || $2 WHERE id = $1`,
    [thread_id, JSON.stringify({ updatedAt: new Date().toISOString() })],
  );

  // Load projects for system prompt context
  const projectRows = await query<{ data: DBProject }>(
    `SELECT p.data FROM fs_projects p
     JOIN fs_users u ON u.id = p.user_id
     WHERE u.data->>'email' = $1
     ORDER BY (p.data->>'updatedAt') DESC NULLS LAST LIMIT 20`,
    [email],
  );
  const projects = projectRows.map((r: { data: DBProject }) => r.data);

  // If the thread is project-scoped, pull the active project's data
  // (preferring fs_projects since the projects array is capped at 20).
  let activeProject: DBProject | null = null;
  if (threadProjectId) {
    const found = projects.find((p: DBProject) => p.id === threadProjectId);
    if (found) {
      activeProject = found;
    } else {
      const r = await query<{ data: DBProject }>(
        `SELECT p.data FROM fs_projects p
          JOIN fs_users u ON u.id = p.user_id
          WHERE p.id = $1 AND u.data->>'email' = $2 LIMIT 1`,
        [threadProjectId, email],
      );
      if (r[0]?.data) activeProject = r[0].data;
    }
  }

  let systemPrompt = await buildSystemPrompt(
    projects,
    workspace,
    activeProject,
    chatMode,
  );

  let fileContextsBlock = "";
  if (
    Array.isArray(attachedFiles) &&
    attachedFiles.length > 0 &&
    activeProject?.slug
  ) {
    fileContextsBlock =
      "\n\n=== USER-ATTACHED CODE CONTEXT ===\nThe user has explicitly attached the following files to this conversation turn as active context. You MUST refer to these file states when writing your response or deciding edits:\n";
    for (const f of attachedFiles) {
      const safePath = String(f).replace(/\.\./g, "").replace(/^\//, "");
      try {
        const res = (await execInDevContainer({
          projectId: activeProject.id,
          command: `cat "/workspace/${safePath}" 2>/dev/null || echo "[File not found]"`,
        })) as unknown as { exitCode: number; stdout: string };
        fileContextsBlock += `\nFile: \`${safePath}\`\n\`\`\`\n${res.stdout}\n\`\`\`\n`;
      } catch {
        fileContextsBlock += `\nFile: \`${safePath}\`\n[Error reading file]\n`;
      }
    }
  }

  if (fileContextsBlock) {
    systemPrompt += fileContextsBlock;
  }

  // Sentry-as-product Stage 4: auto-surface unresolved errors at
  // chat-turn start. We pull the last 6 hours' unresolved issues
  // for the active project; if anything has fired ≥2 times, we
  // append a [PROJECT HEALTH] block to the system prompt so the
  // AI is aware before the user even speaks. The AI decides
  // whether to mention them — usually yes if the user's first
  // message touches the affected area, otherwise a one-line FYI.
  // Single-occurrence errors are filtered out to avoid noise from
  // bots / one-off network blips.
  if (activeProject?.id) {
    try {
      const issues = await listRecentSentryIssues(activeProject.id, {
        sinceHours: 6,
        limit: 5,
      });
      const noteworthy = issues.filter((i) => i.count >= 2);
      if (noteworthy.length > 0) {
        const lines = noteworthy.map((i) => {
          const culprit = i.culprit ? ` — ${i.culprit}` : "";
          return `- ${i.title} (×${i.count}, last seen ${i.lastSeen})${culprit}`;
        });
        const healthBlock =
          `\n\n[PROJECT HEALTH — last 6 hours]\n` +
          `${noteworthy.length} unresolved Sentry issue${noteworthy.length === 1 ? "" : "s"}, count ≥ 2 (one-offs filtered):\n` +
          lines.join("\n") +
          `\n\nIf the user's message is about something that's broken, prefer the matching issue's stack trace over guessing — call \`project_error_detail { projectId, issueId }\` to fetch it. ` +
          `If the user's message is unrelated to these errors, you MAY proactively surface a one-liner ("FYI: X has been failing for users — want me to look?") but do not derail their actual question.`;
        systemPrompt += healthBlock;
      }
    } catch (err) {
      console.warn("[chat] auto-surface Sentry errors failed (non-fatal)", err);
    }
  }

  // Make sure the project's Gitea repo is cloned into the dev
  // container at /workspace/<slug>/ before the AI runs any
  // filesystem-mutating tools. Without this, anything the AI writes
  // gets stranded in a scratch volume and is invisible in the
  // Product/Hosting/Infrastructure tabs (those tabs read from Gitea
  // and Coolify, not from the dev container's volume).
  //
  // We fire-and-forget on existing projects (the clone is a fast
  // no-op when present) and only await on projects that don't have
  // a dev container yet — there the AI is about to call
  // ensureDevContainer + shell.exec, and we need the repo on disk
  // before that exec lands so the AI's writes go into the project
  // repo instead of an empty /workspace.
  if (
    activeProject?.id &&
    activeProject?.slug &&
    typeof activeProject?.giteaCloneUrl === "string"
  ) {
    void ensureProjectRepoCloned({
      projectId: activeProject.id,
      projectSlug: activeProject.slug,
      giteaCloneUrl: activeProject.giteaCloneUrl,
    }).catch((err) => {
      console.warn(
        "[chat] pre-loop ensureProjectRepoCloned failed (non-fatal)",
        err,
      );
    });
  }

  // Base URL for internal MCP calls — pinned to the canonical origin,
  // not the incoming Host header (which can be spoofed).
  const baseUrl =
    process.env.NODE_ENV === "development"
      ? "http://localhost:3000"
      : process.env.NEXT_PUBLIC_SITE_URL ||
        process.env.VERCEL_URL ||
        "https://vibnai.com";

  // Honor client-side abort (Stop button). When the user clicks Stop
  // the browser's AbortController fires `request.signal.aborted` and
  // the fetch stream is closed; we use it as a polite checkpoint
  // between rounds and tool calls so we (a) don't keep paying Gemini
  // for tokens the user no longer wants and (b) persist whatever the
  // assistant produced before the cancel.
  const clientSignal = request.signal;

  // Stream response
  const encoder = new TextEncoder();
  const stream = new ReadableStream({
    async start(controller) {
      let streamClosed = false;
      // C-06: Per-turn correlation ID so prod logs are greppable.
      const turnId = crypto.randomUUID();

      function emit(chunk: object) {
        if (streamClosed) return;
        try {
          if (
            "type" in chunk &&
            chunk.type !== "ping" &&
            chunk.type !== "turn_start"
          ) {
            if (chunk.type === "text" && "text" in chunk) {
              assistantTimeline.push({ kind: "text", text: chunk.text });
            } else if (chunk.type === "thinking" && "text" in chunk) {
              assistantTimeline.push({ kind: "thought", text: chunk.text });
            } else if (chunk.type === "tool_start" && "name" in chunk) {
              assistantTimeline.push({
                kind: "tool",
                name: chunk.name,
                status: "running",
              });
            } else if (
              chunk.type === "tool_result" &&
              "name" in chunk &&
              "result" in chunk
            ) {
              const lastRunning = [...assistantTimeline]
                .reverse()
                .find(
                  (t) =>
                    t.kind === "tool" &&
                    t.name === chunk.name &&
                    t.status === "running",
                );
              if (lastRunning) {
                lastRunning.status = "done";
                lastRunning.result = chunk.result;
                // Quick check if result indicates error
                try {
                  const p = JSON.parse(chunk.result as string);
                  if (p && p.ok === false) lastRunning.status = "error";
                } catch {}
              }
            } else if (
              chunk.type === "phase" &&
              "phase" in chunk &&
              "label" in chunk
            ) {
              assistantTimeline.push({
                kind: "phase",
                phase: chunk.phase,
                label: chunk.label,
              });
            }
          }

          controller.enqueue(
            encoder.encode(`data: ${JSON.stringify(chunk)}\n\n`),
          );
        } catch {
          // controller may have been closed by the abort handler
          streamClosed = true;
        }
      }
      function safeClose() {
        if (streamClosed) return;
        streamClosed = true;
        clearInterval(heartbeat);
        try {
          controller.close();
        } catch {}
      }

      // C-04: SSE heartbeat every 25s keeps Cloudflare / proxies from
      // dropping the connection during long Gemini thinking phases.
      const heartbeat = setInterval(() => {
        emit({ type: "ping", turnId });
      }, 25_000);

      // Emit turnId immediately so the client can log/correlate.
      emit({ type: "turn_start", turnId });

      const messages = [...history];
      let round = 0;
      let assistantText = "";
      // Per-round text segments. The model emits one `resp.text` per
      // tool-loop round; we used to concatenate them all into one
      // `assistantText` blob and render that as a single chat bubble.
      // That made multi-round turns look like one giant run-on
      // paragraph ("now.Spinning up...first boot...The dev container
      // is ready!" with no breaks). Keeping them separate on the
      // server lets the client render each as its own bubble and
      // restores the segmentation on reload.
      const assistantTextSegments: string[] = [];
      const assistantToolCalls: ToolCall[] = [];
      const assistantTimeline: any[] = [];
      let aborted = clientSignal.aborted;
      const onAbort = () => {
        aborted = true;
      };
      clientSignal.addEventListener("abort", onAbort);

      // Track per-turn signals we use for loop detection and silent-stretch
      // detection. The model has a strong tendency to grind through a
      // dozen+ tool calls in total silence (the user just sees ✓ pills
      // pile up); both safeguards below break that pattern.
      let roundsSinceText = 0;
      let toolCallsSinceText = 0;
      let loopBreakReason: string | null = null;

      // ── Phase & Intent State ──
      const turnIntent = classifyTurnIntent(message);
      const maxToolRounds = activeMcpToken ? TOOL_BUDGETS[turnIntent] : 0;
      let phase: AgentPhase = "recon";

      // ── Server-side conversational guard (C-03 enforcement) ───────────
      // If the user's message looks conversational we withhold tools for
      // round 1. The model MUST respond in text first. If its reply then
      // expresses clear intent to act, tools become available from round 2.
      // This is more reliable than a prompt rule against a "do-er" model.
      function isConversational(msg: string): boolean {
        const m = msg.trim();
        if (m.length > 60) return false; // Long/detailed messages are action statements or bug reports, not simple chit-chat
        if (m.length < 3) return true; // single word / emoji
        if (m.endsWith("?")) return true; // explicit question
        // Short phrases that are status checks or greetings
        const conversationalPatterns = [
          /^(hi|hey|hello|sup|test|ok|okay|thanks|ty|thx|lgtm|nice|cool|great|wow)\b/i,
          /^(what|how|why|when|where|who|which|is |are |can |could |would |do |does |did |has |have |had |was |were )\S+.{0,60}$/i,
          /^(are you able to|can you|could you|would you|is it possible)/i,
          /^(what'?s |whats )(running|live|deployed|happening|wrong|broken|up)/i,
          /^(is it|is that|is this|is there|is the)/i,
        ];
        return conversationalPatterns.some((re) => re.test(m));
      }
      const firstMessageIsConversational =
        activeMcpToken !== undefined && // tools available
        turnIntent === "conversational" && // ONLY block tools on pure conversational intents!
        isConversational(message.trim());

      let lastVerifySig: string | null = null;
      let lastRoundToolSig: string | null = null;
      let lastRoundResults: any[] = [];
      let lastRoundToolCalls: any[] = [];
      let fileHashes = new Map<string, string>();
      let stallRounds = 0;

      // Compact corrective executor used by the verification fix-loop: runs up
      // to `n` model rounds (with tools) to fix whatever verification flagged,
      // reusing the same tool-execution path as the main loop.
      async function runFixRounds(n: number) {
        for (let i = 0; i < n; i++) {
          if (aborted) break;
          const fixTools = activeMcpToken
            ? filterToolsForPhase(VIBN_TOOL_DEFINITIONS, "execute", turnIntent)
            : [];
          const r = await callVibnChat({
            systemPrompt,
            messages,
            tools: fixTools,
            temperature: 0.4,
            includeThoughts: true,
            signal: clientSignal,
          });
          if (r.text) {
            assistantText += (assistantText ? "\n\n" : "") + r.text;
            assistantTextSegments.push(r.text);
            emit({ type: "text", text: r.text });
          }
          messages.push({
            role: "assistant",
            content: r.text,
            toolCalls: r.toolCalls.length ? r.toolCalls : undefined,
          });
          if (!r.toolCalls.length) break;
          for (const tc of r.toolCalls) {
            if (aborted) break;
            assistantToolCalls.push(tc);
            emit({ type: "tool_start", name: tc.name, args: tc.args });
            const result = activeMcpToken
              ? await executeMcpTool(
                  tc.name,
                  tc.args,
                  activeMcpToken,
                  baseUrl,
                  activeProject?.id,
                  clientSignal,
                )
              : JSON.stringify({ error: "No MCP token" });
            emit({
              type: "tool_result",
              name: tc.name,
              result: result.slice(0, 500),
            });
            messages.push({
              role: "tool",
              content: result,
              toolCallId: tc.id,
              toolName: tc.name,
              thoughtSignature: tc.thoughtSignature,
            });
          }
        }
      }

      emit({ type: "phase", phase, label: "Investigating & Planning" });

      try {
        // Tool-calling loop: use non-streaming so thought_signature is
        // always present in the complete response (required by thinking models).
        while (round < maxToolRounds) {
          if (aborted) break;
          round++;

          // Keep tool definitions active in the schema to avoid model confusion and
          // MALFORMED_FUNCTION_CALL gateway crashes, but let our system instructions
          // guide the model to respond in plain text for conversational inputs.
          const toolDefs = activeMcpToken
            ? filterToolsForPhase(VIBN_TOOL_DEFINITIONS, phase, turnIntent)
            : [];

          // Every 6 silent rounds or 8 tool calls, gently nudge the model to surface a one-liner
          // status before continuing. This is the user's only signal of
          // life when a tool chain runs long.
          const isSilent = roundsSinceText >= 6 || toolCallsSinceText >= 8;
          let extraSystem = isSilent
            ? "\n\n[STATUS NUDGE] You have run " +
              `${toolCallsSinceText} tool call(s) over ${roundsSinceText} round(s) ` +
              "without sending the user any text. Before any more tool calls, " +
              "send ONE short sentence describing what you are currently working " +
              "on and why. The user is staring at a silent screen."
            : "";

          // When withholding tools on round 1 (conversational guard), add a
          // mandatory instruction so the model doesn't return empty text.
          if (round === 1 && firstMessageIsConversational) {
            extraSystem +=
              "\n\n[MANDATORY] The user's message is a question or conversational input, " +
              "not a command. You have NO tools available on this turn. " +
              "Respond with PLAIN TEXT ONLY in 1-3 sentences answering their question. " +
              "If they want you to take action, confirm intent and wait for a clear directive.";
          }

          if (maxToolRounds - round <= 3) {
            extraSystem += `\n\n[WARNING] You only have ${maxToolRounds - round} tool calls left before you are forcefully terminated. Stop exploring, make your final edits, and write your final response to the user NOW.`;
          }

          // Execute tool calls and add results. OpenAI-compatible APIs
          const resp = await callVibnChat({
            systemPrompt: systemPrompt + extraSystem,
            messages,
            tools: toolDefs,
            temperature: 0.7,
            includeThoughts: true,
            signal: clientSignal,
          });

          // When the model first reaches for a mutation, advance the phase so
          // the UI reflects "Executing Code Edits". We deliberately do NOT force
          // a separate planning round or discard the edit (the old "C-08
          // checkpoint" dance) — that made the model plan, stall on an empty
          // turn, and never execute, and it seeded scope-creep via the forced
          // "verification plan". The agent edits directly; the post-loop
          // verification layer checks the result and drives any fixes.
          const requestedMutations = resp.toolCalls.filter((tc) =>
            [
              "fs_write",
              "fs_edit",
              "fs_delete",
              "apps_deploy",
              "ship",
            ].includes(tc.name),
          );

          if (requestedMutations.length > 0 && phase === "recon") {
            phase = "execute";
            emit({ type: "phase", phase, label: "Executing Code Edits" });
          }

          // A Stop click aborts the in-flight generation, which surfaces here
          // as resp.error === "aborted". Treat it as a clean user stop (break to
          // the post-loop abort handling that persists the partial reply),
          // NOT as a fatal error shown to the user.
          if (resp.error === "aborted" || aborted) {
            aborted = true;
            break;
          }

          if (resp.error) {
            emit({ type: "error", error: resp.error });
            safeClose();
            return;
          }

          // Stream user-facing text to client.
          if (resp.text) {
            assistantText += (assistantText ? "\n\n" : "") + resp.text;
            assistantTextSegments.push(resp.text);
            emit({ type: "text", text: resp.text });
            roundsSinceText = 0;
            toolCallsSinceText = 0;
          } else if (resp.toolCalls.length) {
            roundsSinceText++;
            toolCallsSinceText += resp.toolCalls.length;
          }

          // Stream the model's reasoning narration as a separate SSE
          // event type. We pay for thinking tokens whether or not we
          // ask for them, so making them visible is free transparency
          // — and it cures the "tool tray with no narrative" feel.
          if (resp.thoughts) {
            emit({ type: "thinking", text: resp.thoughts });
          }

          // Announce tool calls
          for (const tc of resp.toolCalls) {
            assistantToolCalls.push(tc);
            emit({ type: "tool_start", name: tc.name, args: tc.args });
          }

          // Save assistant turn
          messages.push({
            role: "assistant",
            content: resp.text,
            toolCalls: resp.toolCalls.length ? resp.toolCalls : undefined,
          });

          if (!resp.toolCalls.length) break;
          if (aborted) break;

          // Execute tool calls and add results. OpenAI-compatible APIs
          // (DeepSeek, etc.) require every tool_call_id to be answered with
          // a tool message before any user/assistant message — so recovery
          // nudges must run AFTER all tools from this assistant turn.
          const recoveryLines: string[] = [];
          for (const tc of resp.toolCalls) {
            if (aborted) break;
            // C-05: Per-tool timeout. A hung MCP call would freeze the whole turn.
            const TOOL_TIMEOUT_MS = 180_000;
            const toolTimeout = new Promise<string>((resolve) =>
              setTimeout(
                () =>
                  resolve(
                    JSON.stringify({
                      ok: false,
                      error: `Tool ${tc.name} timed out after ${TOOL_TIMEOUT_MS / 1000}s`,
                    }),
                  ),
                TOOL_TIMEOUT_MS,
              ),
            );
            const toolExec = activeMcpToken
              ? executeMcpTool(
                  tc.name,
                  tc.args,
                  activeMcpToken,
                  baseUrl,
                  activeProject?.id,
                  clientSignal,
                )
              : Promise.resolve(
                  JSON.stringify({ error: "No MCP token — read-only mode." }),
                );
            const result = await Promise.race([toolExec, toolTimeout]);

            emit({
              type: "tool_result",
              name: tc.name,
              result: result.slice(0, 500),
            });

            messages.push({
              role: "tool",
              content: result,
              toolCallId: tc.id,
              toolName: tc.name,
              thoughtSignature: tc.thoughtSignature,
            });

            const recovery = detectKnownError(result);
            if (recovery) recoveryLines.push(formatRecoveryMessage(recovery));

            // B-05: SSE plan event — stream task state changes to the client
            // so the Plan tab updates in real-time during a chat turn.
            if (tc.name === "plan_task_add" || tc.name === "plan_task_edit") {
              try {
                const parsed = JSON.parse(result);
                const task = parsed?.result?.task ?? parsed?.task;
                if (task?.id) {
                  emit({
                    type: "plan",
                    taskId: task.id,
                    text: task.text ?? task.title ?? "",
                    status: task.status ?? "open",
                  });
                }
              } catch {
                // non-JSON result — skip
              }
            }
          }
          for (const line of recoveryLines) {
            messages.push({ role: "user", content: line });
          }

          // --- STATE-BASED LOOP GOVERNOR (Part 2) ---
          const currentRoundResults = messages.filter(
            (m) =>
              m.role === "tool" &&
              resp.toolCalls.some((tc) => tc.id === m.toolCallId),
          );

          // 1. Compute verify signature
          const verifySig = getRoundVerifySignature(currentRoundResults);

          // 2. Compute deterministic tool signature to track exact repetitions
          const currentRoundToolSig = resp.toolCalls
            .map((tc) => {
              const sortKeys = (obj: any): any => {
                if (typeof obj !== "object" || obj === null) return obj;
                if (Array.isArray(obj)) return obj.map(sortKeys);
                return Object.keys(obj)
                  .sort()
                  .reduce((acc, key) => {
                    acc[key] = sortKeys(obj[key]);
                    return acc;
                  }, {} as any);
              };
              return `${tc.name}:${JSON.stringify(sortKeys(tc.args || {}))}`;
            })
            .sort()
            .join(";;");

          // 3. Check for actual state progress (did files change, did a plan update, did a mutating tool succeed, or did the error set change?)
          const { progressed, nextHashes } = checkRoundProgress(
            currentRoundResults,
            fileHashes,
            verifySig,
            lastVerifySig,
          );
          fileHashes = nextHashes;

          const ranVerification = currentRoundResults.some((r) =>
            [
              "browser_console",
              "shell_exec",
              "dev_server_start",
              "browser.console",
              "dev.server.start",
            ].includes(r.toolName),
          );

          if (ranVerification) {
            if (verifySig) {
              // Blocked condition: Same exact error signature two rounds in a row, with no code progress made.
              if (lastVerifySig && verifySig === lastVerifySig && !progressed) {
                loopBreakReason = `Blocked on persistent error: ${verifySig.split(";;")[0]}`;
              }
              lastVerifySig = verifySig;
            } else {
              // Successfully compiled cleanly! Clear the active error memory
              lastVerifySig = null;
            }
          }

          // A stall is ONLY when the AI executes the exact same tools with the exact same inputs without making progress.
          // If the AI is actively exploring different files, it is allowed to continue.
          if (
            !progressed &&
            lastRoundToolSig &&
            currentRoundToolSig === lastRoundToolSig
          ) {
            stallRounds++;
          } else {
            stallRounds = 0;
          }

          if (stallRounds >= 2) {
            loopBreakReason =
              "Stalled (Repeated the exact same tool calls twice without advancing)";
          }

          const pathConfusion = detectPathConfusion(
            currentRoundResults,
            lastRoundResults,
            resp.toolCalls,
            lastRoundToolCalls,
          );
          if (pathConfusion) {
            loopBreakReason = `PATH_CONFUSION: ${pathConfusion}`;
          }

          lastRoundToolSig = currentRoundToolSig;
          lastRoundResults = currentRoundResults;
          lastRoundToolCalls = resp.toolCalls;

          if (loopBreakReason) break;
        }

        // If the user clicked Stop, surface the cancel marker so the
        // client renders "(stopped by user)" inline with the partial
        // assistant message, then skip the round-cap recovery summary
        // (we shouldn't pay Gemini for a turn the user just canceled).
        if (aborted) {
          const stopMarker = assistantText
            ? "\n\n_(stopped by user)_"
            : "_(stopped by user before any response)_";
          assistantText += stopMarker;
          assistantTextSegments.push(stopMarker.trimStart());
          emit({ type: "text", text: stopMarker });
          emit({ type: "aborted" });
        }

        // ── Acceptance verification + corrective fix-loop (flag-gated) ──
        // After a turn that mutated code, run the verification contract
        // (baseline: build + server_up + console_clean). If it fails, feed the
        // concrete failures back and let the model fix — iterating until green,
        // stuck, or out of attempts. Off by default; enable per-environment
        // with VIBN_VERIFICATION_ENABLED=1 for the live smoke test.
        let verificationOutcome: ExecuteTaskOutcome | null = null;
        const MUTATION_TOOLS = [
          "fs_write",
          "fs_edit",
          "fs_delete",
          "apps_deploy",
          "ship",
        ];
        const mutated = assistantToolCalls.some((tc) =>
          MUTATION_TOOLS.includes(tc.name),
        );
        if (
          process.env.VIBN_VERIFICATION_ENABLED === "1" &&
          !aborted &&
          mutated &&
          activeProject?.id &&
          activeMcpToken
        ) {
          emit({ type: "phase", phase: "verify", label: "Verifying & fixing" });
          const previewUrl = extractPreviewUrl(messages);
          const verifyExec: ToolExecutor = async (name, args) =>
            executeMcpTool(
              name,
              args,
              activeMcpToken,
              baseUrl,
              activeProject!.id,
              clientSignal,
            );
          const vTask: VerificationTask = {
            id: thread_id,
            title: message,
            status: "in_progress",
            acceptanceChecks: [],
            attempts: 0,
          };
          const verifyCtx: ExecCtx = {
            projectId: activeProject.id,
            previewUrl,
            exec: verifyExec,
          };
          try {
            verificationOutcome = await executeTask(vTask, {
              maxAttempts: 3,
              runExecution: async ({ failureFeedback, attempt }) => {
                // Attempt 1 = verify what the main loop already produced.
                if (attempt === 1 && !failureFeedback) return;
                if (failureFeedback)
                  messages.push({ role: "user", content: failureFeedback });
                await runFixRounds(2);
              },
              verify: async () => runVerificationContract(vTask, verifyCtx),
            });
          } catch (e) {
            console.error("[Verification] errored:", e);
          }
          // If verification couldn't reach green, surface the specific failing
          // checks as an honest status (and let the summary reflect reality).
          if (verificationOutcome?.status === "blocked") {
            const checkLines = verificationOutcome.failures
              .map((f) => `- ${f.check.description}: ${f.evidence}`)
              .join("\n");
            const note =
              `I made the changes but verification didn't fully pass:\n${checkLines}\n` +
              `That's the honest state — want me to keep working these specific issues?`;
            assistantText += (assistantText ? "\n\n" : "") + note;
            assistantTextSegments.push(note);
            emit({ type: "text", text: note });
          }
        }

        // If the loop ended with the user staring at a tool tray and no
        // narrative — whether because we hit MAX_TOOL_ROUNDS, broke a
        // detected loop, or the model voluntarily stopped emitting tools
        // without ever writing text — force one final no-tools summary
        // so we never abandon the user with silent ✓ pills. Confirmed
        // failure mode in prod: turn persisted with content_len=0 and
        // 20 toolCalls, user had to re-prompt to get any answer.
        const anyToolsExecuted = assistantToolCalls.length > 0;
        // C-07: Also recover when the model has been running tools without
        // any text for >=4 rounds — the user is staring at silence.
        const needsRecovery =
          !aborted &&
          anyToolsExecuted &&
          (round >= maxToolRounds ||
            !!loopBreakReason ||
            assistantText.trim().length === 0 ||
            roundsSinceText >= 30 ||
            lastToolResultsHadFailure(messages));

        if (needsRecovery) {
          const failureNote = lastToolResultsHadFailure(messages)
            ? "Your last tool calls returned failures or non-2xx health checks. " +
              "Do NOT claim those operations succeeded. "
            : "";
          const reason = loopBreakReason
            ? `LOOP DETECTED: ${loopBreakReason}. Stop trying that approach. `
            : round >= maxToolRounds
              ? "You hit the tool-round cap. "
              : "";
          try {
            const summary = await callVibnChat({
              systemPrompt:
                systemPrompt +
                `\n\n[RECOVERY] ${reason}${failureNote}Send the user 1–3 short sentences right now: (a) what you actually accomplished or learned, (b) the specific blocker (last error message verbatim if there is one), (c) what you'll try next OR a question for the user. Do NOT call any tools.`,
              messages,
              tools: [],
              temperature: 0.3,
              signal: clientSignal,
            });
            if (summary.text && summary.text.trim()) {
              assistantText += (assistantText ? "\n\n" : "") + summary.text;
              assistantTextSegments.push(summary.text);
              emit({ type: "text", text: summary.text });
            } else {
              // Gemini returned empty — fall back to a deterministic but
              // STRUCTURED build-health status (never a vague "didn't reach a
              // clean stopping point"). It states what happened, what broke,
              // and the next action, using the same signals as the telemetry
              // stop_reason.
              const fallback = buildHealthStatus({
                loopBreakReason,
                hitRoundCap: maxToolRounds > 0 && round >= maxToolRounds,
                lastError: extractLastToolFailure(messages),
                toolCount: assistantToolCalls.length,
              });
              assistantText += (assistantText ? "\n\n" : "") + fallback;
              assistantTextSegments.push(fallback);
              emit({ type: "text", text: fallback });
            }
            if (summary.thoughts) {
              emit({ type: "thinking", text: summary.thoughts });
            }
          } catch {
            const fallback = buildHealthStatus({
              loopBreakReason,
              hitRoundCap: maxToolRounds > 0 && round >= maxToolRounds,
              lastError: extractLastToolFailure(messages),
              toolCount: assistantToolCalls.length,
            });
            assistantText += (assistantText ? "\n\n" : "") + fallback;
            assistantTextSegments.push(fallback);
            emit({ type: "text", text: fallback });
          }
        } else if (!aborted && anyToolsExecuted) {
          // Successful tool-using turn — guarantee it ENDS with a clean,
          // human summary. We only force one when the model didn't already
          // close with a substantive sentence, so we never pay for a
          // redundant double-summary.
          const lastSeg = (
            assistantTextSegments[assistantTextSegments.length - 1] || ""
          ).trim();
          const alreadySummarized =
            lastSeg.length >= 40 && /[.!?)\]]$/.test(lastSeg);
          if (!alreadySummarized) {
            try {
              const finalSummary = await callVibnChat({
                systemPrompt:
                  systemPrompt +
                  `\n\n[FINAL SUMMARY] The work for this turn is finished. In 1–3 short, plain sentences, tell the user: (a) what you changed or accomplished, (b) the specific result they can see right now (a preview URL, a file, a value), and (c) the single best next step. No headings, no bullet lists, no internal jargon, and do NOT call any tools.`,
                messages,
                tools: [],
                temperature: 0.3,
                signal: clientSignal,
              });
              if (finalSummary.text && finalSummary.text.trim()) {
                assistantText +=
                  (assistantText ? "\n\n" : "") + finalSummary.text;
                assistantTextSegments.push(finalSummary.text);
                emit({ type: "text", text: finalSummary.text });
              }
            } catch {
              // Best-effort: the model's own final text remains as the ending.
            }
          }
        }

        // Last-resort guard: the model produced NO user-facing text and NO
        // tools (e.g. a "thinking" turn that returned only reasoning with an
        // empty answer part). The tool-tray recovery above doesn't cover this
        // case, so without this the user gets a silent blank bubble. Emit a
        // short deterministic fallback so every turn says *something*.
        if (
          !aborted &&
          assistantText.trim().length === 0 &&
          !anyToolsExecuted
        ) {
          const fallback =
            "I didn't produce a response for that — I may have spent the turn " +
            "reasoning without writing an answer. Could you rephrase or add a " +
            "bit more detail?";
          assistantText = fallback;
          assistantTextSegments.push(fallback);
          emit({ type: "text", text: fallback });
        }

        // Persist final assistant message. We include `textSegments`
        // alongside the legacy concatenated `content` so the client
        // can render reloaded threads with the same per-round bubble
        // segmentation it shows during streaming. Older messages
        // (pre-this-fix) won't have textSegments and fall back to
        // single-bubble content rendering.

        // Ensure we strip the `[tools executed this turn...]` block if the AI accidentally hallucinated it
        assistantText = assistantText.replace(
          /(?:\r?\n)*\[tools executed this turn:[\s\S]*?\]/g,
          "",
        );

        const finalMsg: ChatMessage & {
          textSegments?: string[];
          timeline?: any[];
          _rawToolResults?: Array<{
            name: string;
            args: Record<string, unknown>;
            result: string;
          }>;
        } = {
          role: "assistant",
          content: assistantText,
          toolCalls: assistantToolCalls.length ? assistantToolCalls : undefined,
          textSegments: assistantTextSegments.length
            ? assistantTextSegments.map((seg) =>
                seg.replace(
                  /(?:\r?\n)*\[tools executed this turn:[\s\S]*?\]/g,
                  "",
                ),
              )
            : undefined,
          timeline: assistantTimeline.length ? assistantTimeline : undefined,
          _rawToolResults: assistantToolCalls.length ? [] : undefined,
        };

        // Option 1 implemented: Save the raw tool results directly into the database row
        // alongside the assistant message so it can be extracted later for fine-tuning.
        if (finalMsg._rawToolResults) {
          // We slice out the tool messages from the internal messages array we just built
          // during the loop and attach them to the final row payload.
          const toolResults = messages.filter((m) => m.role === "tool");
          finalMsg._rawToolResults = assistantToolCalls.map((tc) => {
            const tr = toolResults.find((m) => m.toolCallId === tc.id);
            let resultStr =
              typeof tr?.content === "string"
                ? tr.content
                : JSON.stringify(tr?.content || "");

            // Redact secrets from telemetry
            resultStr = resultStr.replace(
              /postgres(?:ql)?:\/\/[^:]+:[^@]+@[^:]+:\d+\/[^\s"]+/g,
              "postgresql://[REDACTED_DB_URL]",
            );
            resultStr = resultStr.replace(
              /(eyJ[a-zA-Z0-9_-]{5,}\.[a-zA-Z0-9_-]{5,}\.[a-zA-Z0-9_-]{5,})/g,
              "[REDACTED_JWT]",
            );
            resultStr = resultStr.replace(/([A-Za-z0-9_]{35,})/g, (match) =>
              match.length > 40 ? "[REDACTED_SECRET]" : match,
            );

            return {
              name: tc.name,
              args: tc.args,
              result: resultStr,
            };
          });
        }

        // ---- Orchestration telemetry: one turn_summary per user turn ----
        // Records WHY the agent loop ended so we can diagnose and tune the
        // governor (premature stops, loop cut-offs). Fire-and-forget.
        try {
          const stopReason = aborted
            ? "user_aborted"
            : loopBreakReason
              ? `loop_detected:${String(loopBreakReason).slice(0, 160)}`
              : maxToolRounds > 0 && round >= maxToolRounds
                ? "round_cap"
                : lastToolResultsHadFailure(messages)
                  ? "tool_failure"
                  : roundsSinceText >= 30
                    ? "silent_rounds"
                    : assistantToolCalls.length === 0 &&
                        assistantText.trim().length === 0
                      ? "empty_no_tools"
                      : "completed";

          logTurnSummary({
            projectId: activeProject?.id,
            sessionId: thread_id,
            userMessage: message,
            model: process.env.VIBN_CHAT_MODEL || "gemini-3.1-pro-preview",
            response: {
              text: assistantText,
              thoughts: "",
              toolCalls: assistantToolCalls,
            },
            toolResults: finalMsg._rawToolResults ?? [],
            stopReason,
            rounds: round,
            toolCallCount: assistantToolCalls.length,
            turnIntent,
            chatMode,
          });
        } catch {
          // never let telemetry interfere with the turn
        }

        await query(
          `INSERT INTO fs_chat_messages (thread_id, user_id, data) VALUES ($1, $2, $3)`,
          [thread_id, email, JSON.stringify(finalMsg)],
        );

        // Fire-and-forget: commit any AI-made filesystem changes to
        // the project's Gitea repo and push to origin. This is what
        // makes the AI's work appear in the Product tab's Codebases
        // view — without it, every fs.write / shell.exec mutation
        // stays trapped in the dev container's volume.
        //
        // Run BEFORE the final done event so we can surface the commit
        // result in the UI (Fix 10).
        if (
          activeProject?.id &&
          activeProject?.slug &&
          typeof activeProject?.giteaCloneUrl === "string"
        ) {
          try {
            // Best-effort clone in case the pre-loop kick-off was
            // racing with container provisioning and never landed.
            await ensureProjectRepoCloned({
              projectId: activeProject.id,
              projectSlug: activeProject.slug,
              giteaCloneUrl: activeProject.giteaCloneUrl,
            }).catch(() => null);
            // Commit message: prefer the assistant's own first
            // sentence (one line, ≤200 chars). Falls back to a
            // generic checkpoint when the assistant only made
            // tool calls without prose.
            const firstSentence = (assistantText || "")
              .split(/(?<=[.!?])\s+/)[0]
              ?.trim()
              ?.slice(0, 180);
            const commitMessage = firstSentence || "AI checkpoint";

            const commitPromise = commitAndPushIfDirty({
              projectId: activeProject.id,
              projectSlug: activeProject.slug,
              message: commitMessage,
            });
            const timeoutPromise = new Promise<{
              committed: false;
              reason: string;
            }>((resolve) =>
              setTimeout(
                () => resolve({ committed: false, reason: "timeout" }),
                8000,
              ),
            );

            const result = (await Promise.race([
              commitPromise,
              timeoutPromise,
            ])) as {
              committed: boolean;
              sha?: string;
              pushed?: boolean;
              reason?: string;
            };

            if (result.committed) {
              emit({ type: "commit", sha: result.sha, pushed: result.pushed });
              console.log(
                `[chat] auto-commit project=${activeProject.slug} sha=${result.sha} pushed=${result.pushed}`,
              );
            } else if (
              result.reason &&
              result.reason !== "clean" &&
              result.reason !== "no_repo"
            ) {
              emit({ type: "commit_failed", reason: result.reason });
              console.warn(
                `[chat] auto-commit failed project=${activeProject.slug} reason=${result.reason}`,
              );
            }
          } catch (err) {
            emit({ type: "commit_failed", reason: String(err) });
            console.warn("[chat] auto-commit failed", err);
          }
        }

        // Fire-and-forget: ask Gemini for a 1-2 sentence "what got done"
        // summary of the conversation so far, persist it on the thread,
        // and use the first user message (truncated) as a stable title
        // when one isn't set yet. This is what powers the Sessions tab on
        // the project Plan page — read-only chronological progress log.
        // Wrapped in try/catch + .catch — the response stream is already
        // closed and we don't want a summary failure to surface as an
        // error to the user.
        (async () => {
          try {
            const allMessages = [...history, finalMsg];
            // Only summarize if there's something worth summarizing.
            if (allMessages.length < 2) return;
            const transcript = allMessages
              .map((m) => {
                const text =
                  typeof m.content === "string"
                    ? m.content
                    : JSON.stringify(m.content);
                return `${m.role.toUpperCase()}: ${text.slice(0, 1200)}`;
              })
              .join("\n\n");
            const sumResp = await callVibnChat({
              systemPrompt:
                "You are summarizing a chat session for a project log. " +
                "Write 1-2 sentences (max 200 chars) describing what was actually attempted, decided, or shipped in this conversation. " +
                "Past tense, plain language, no preamble, no headings. " +
                "If nothing of substance happened, write a single short sentence describing the topic.",
              messages: [{ role: "user", content: transcript.slice(0, 8000) }],
              temperature: 0.3,
            });
            const summary = (sumResp.text || "").trim().slice(0, 280);
            // Pick a title only if the existing one is missing or generic.
            const firstUser = allMessages.find((m) => m.role === "user");
            const firstText =
              typeof firstUser?.content === "string" ? firstUser.content : "";
            const fallbackTitle = firstText
              .replace(/\s+/g, " ")
              .trim()
              .slice(0, 60);
            const update: Record<string, unknown> = {};
            if (summary) update.summary = summary;
            if (fallbackTitle) update.title = fallbackTitle;
            if (Object.keys(update).length > 0) {
              await query(
                `UPDATE fs_chat_threads
                    SET data = data || $2
                  WHERE id = $1
                    AND (
                      ($2::jsonb ? 'title') IS FALSE
                      OR data->>'title' IS NULL
                      OR data->>'title' = ''
                      OR data->>'title' = 'New conversation'
                      OR ($2::jsonb ? 'summary')
                    )`,
                [thread_id, JSON.stringify(update)],
              );
            }
          } catch {
            // best-effort; silent failure
          }
        })().catch(() => {});

        // Plan extraction is handled inline during tool calls or proactively.
        emit({ type: "done" });
        safeClose();
      } catch (e) {
        // AbortError is the expected shape when the client cancels
        // mid-Gemini-call — don't surface it as a real error.
        const isAbort =
          aborted ||
          (e instanceof Error &&
            (e.name === "AbortError" || /aborted/i.test(e.message)));
        if (!isAbort) {
          emit({
            type: "error",
            error: e instanceof Error ? e.message : String(e),
          });
        } else {
          emit({ type: "aborted" });
        }
        safeClose();
      } finally {
        clientSignal.removeEventListener("abort", onAbort);
      }
    },
    cancel() {
      // Browser disconnected (tab closed, navigated away). Clear the
      // heartbeat so we stop writing to a closed stream.
      // The abort handler above already flipped the flag so the loop bails.
    },
  });

  return new Response(stream, {
    headers: {
      "Content-Type": "text/event-stream",
      "Cache-Control": "no-cache",
      Connection: "keep-alive",
    },
  });
}

// ── State-Based Loop Governor Helpers ─────────────────────────────────

function getRoundVerifySignature(roundResults: any[]): string | null {
  const errors: string[] = [];

  for (const tr of roundResults) {
    if (!tr.content) continue;
    try {
      const parsed = JSON.parse(tr.content);
      const result = parsed.result || parsed;

      // 1. Check browser_console errors
      if (
        tr.toolName === "browser_console" ||
        tr.toolName === "browser.console"
      ) {
        if (
          result.errors &&
          Array.isArray(result.errors) &&
          result.errors.length > 0
        ) {
          // Normalize: Keep status codes and line numbers intact! Only strip out volatile subdomains and timestamps.
          const cleanErrors = result.errors.map((e: string) =>
            normalizeError(e),
          );
          errors.push(`browser_console_errors:${cleanErrors.join("|")}`);
        }
        if (result.ok === false && result.error) {
          errors.push(`browser_console_fail:${normalizeError(result.error)}`);
        }
      }

      // 2. Check shell_exec failures
      if (tr.toolName === "shell_exec") {
        if (result.code !== 0 && result.code !== undefined) {
          const stderrLine = (result.stderr || result.stdout || "error")
            .split("\n")[0]
            .trim()
            .substring(0, 100);
          errors.push(
            `shell_exec_fail:${result.code}:${normalizeError(stderrLine)}`,
          );
        }
        if (result.ok === false && result.error) {
          errors.push(`shell_exec_error:${normalizeError(result.error)}`);
        }
      }

      // 3. Check dev_server_start failures
      if (
        tr.toolName === "dev_server_start" ||
        tr.toolName === "dev.server.start"
      ) {
        if (result.healthCheck && result.healthCheck.status >= 400) {
          errors.push(`dev_server_unhealthy:${result.healthCheck.status}`);
        }
        if (result.ok === false && result.error) {
          errors.push(`dev_server_fail:${normalizeError(result.error)}`);
        }
      }

      // 4. Check fs_edit / fs_write failures
      if (
        tr.toolName === "fs_edit" ||
        tr.toolName === "fs_write" ||
        tr.toolName === "fs.edit" ||
        tr.toolName === "fs.write"
      ) {
        if (result.ok === false || result.error) {
          errors.push(
            `file_op_failed:${tr.toolName}:${normalizeError(result.error || result.stderr || "error")}`,
          );
        }
      }
    } catch (e) {
      // skip
    }
  }

  if (errors.length === 0) return null;
  return errors.sort().join(";;");
}

function normalizeError(error: string): string {
  return error
    .replace(/preview-\d+-\w+-[0-9a-f]+/g, "preview-X")
    .replace(/localhost:\d+/g, "localhost:PORT")
    .replace(/\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(?:\.\d+)?Z/g, "TIMESTAMP")
    .trim();
}

function checkRoundProgress(
  roundResults: any[],
  lastHashes: Map<string, string>,
  verifySig: string | null,
  lastVerifySig: string | null,
): { progressed: boolean; nextHashes: Map<string, string> } {
  let progressed = false;
  const nextHashes = new Map(lastHashes);

  // A. Progress check: did the compile error signature change/improve?
  if (verifySig !== lastVerifySig) {
    progressed = true; // Error set changed/shifted = progress toward diagnosis!
  }

  for (const tr of roundResults) {
    if (!tr.content) continue;
    try {
      const parsed = JSON.parse(tr.content);
      const result = parsed.result || parsed;

      // B. Progress check: did a file edit/write result in a new/changed sha256?
      if (result.ok && result.sha256 && result.path) {
        const lastHash = lastHashes.get(result.path);
        if (lastHash !== result.sha256) {
          progressed = true;
          nextHashes.set(result.path, result.sha256);
        }
      }

      // C. Progress check: did any mutating/deploying tool succeed?
      if (
        result.ok &&
        ![
          "fs_read",
          "fs_list",
          "fs_tree",
          "fs_glob",
          "fs_grep",
          "dev_server_list",
          "browser_console",
          "browser.console",
        ].includes(tr.toolName)
      ) {
        progressed = true;
      }
    } catch (e) {
      // skip
    }
  }

  return { progressed, nextHashes };
}

function safeJson(str: string) {
  try {
    return JSON.parse(str);
  } catch {
    return null;
  }
}

type PathFailure = {
  tool: string;
  attemptedPath?: string;
  basename?: string;
  error: string;
};

function extractPathFailures(results: any[], toolCalls: any[]): PathFailure[] {
  const failures: PathFailure[] = [];

  for (const tr of results) {
    const content = String(tr.content ?? "");
    if (
      !content.includes("not a file or missing") &&
      !content.includes("No such file or directory") &&
      !content.includes("ENOENT") &&
      !content.includes("Could not read file")
    ) {
      continue;
    }

    const tc = toolCalls.find((t: any) => t.id === tr.toolCallId);
    // Attempt to extract the path from the tool call args first, then regex fallback
    const attempted =
      tc?.args?.path ||
      tc?.args?.command?.match(/cat\s+([^\s]+)/)?.[1] ||
      content.match(/(?:for|open|read file|access)\s+'?([^':\s]+)/)?.[1];

    if (attempted) {
      failures.push({
        tool: tr.toolName,
        attemptedPath: attempted,
        basename: attempted.split("/").pop(),
        error: content.slice(0, 300),
      });
    }
  }
  return failures;
}

function detectPathConfusion(
  currentResults: any[],
  lastResults: any[],
  currentToolCalls: any[],
  lastToolCalls: any[],
): string | null {
  const currentFailures = extractPathFailures(currentResults, currentToolCalls);
  const lastFailures = extractPathFailures(lastResults, lastToolCalls);

  if (currentFailures.length > 0 && lastFailures.length > 0) {
    for (const cf of currentFailures) {
      for (const lf of lastFailures) {
        if (cf.basename && cf.basename === lf.basename) {
          return `You are in a path-confusion loop trying to access ${cf.basename}. Stop reading guessed paths. Run 'shell_exec { command: "find . -name ${cf.basename}" }' to discover the exact path, then use it exactly once.`;
        }
      }
    }
  }
  return null;
}
