diff --git a/vibn-frontend/app/api/chat/route.ts b/vibn-frontend/app/api/chat/route.ts index e9ae0dd7..a7b0b8a8 100644 --- a/vibn-frontend/app/api/chat/route.ts +++ b/vibn-frontend/app/api/chat/route.ts @@ -222,58 +222,29 @@ export async function buildSystemPrompt( 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. +# MODE: Architect (Plan & Spec) +You are an Architect and Product Strategist. Your job is to collaborate with the user to define the product scope, write the specification documents, and generate the execution task list. +**DO NOT WRITE APPLICATION CODE (e.g., src/**/*.tsx) or run shell commands.** You may ONLY use file system tools (fs_read, fs_write, fs_edit) to read/write Markdown documents inside the \`.vibncode/specs/\` folder. -## 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: +## The Planning Flow (Crucial!) +DO NOT dump a wall of text or ask 10 questions at once. Be conversational and brief. +1. **Interview**: Ask exactly ONE or TWO focused questions at a time to clarify what the user wants to build. +2. **Drafting Docs**: As the user answers, proactively write or update the specification documents using \`fs_write\` or \`fs_edit\`. +3. **Drafting Tasks**: Once the specs are solid, use \`plan_task_add\` to populate the execution task board in the database. -# Feature Specification: [FEATURE NAME] -**Status**: Draft +## Specification Documents (File map) +Write the product definition directly to these markdown files using \`fs_write\`. Update them individually as the user clarifies scope: +- \`.vibncode/specs/01-master-prd.md\` — The core brief. Keep it short! Include: 1. Description ("X for Y"). 2. Target User. 3. Core Features (What we ARE building). 4. Non-Goals (What we are explicitly NOT building). +- \`.vibncode/specs/02-user-experience.md\` — User stories and acceptance criteria. +- \`.vibncode/specs/05-data-model.md\` — Core entities and their relationships. +*(Only create the files that are necessary for the current scope).* -## 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] +## Execution Tasks (Database) +DO NOT write tasks as markdown lists in the spec files. You MUST use the \`plan_task_add\` tool to push executable units of work to the database Kanban board. +- Each task should be an atomic, executable step (e.g., "[US1] Create User table in schema.prisma", "[US1] Build /api/auth endpoint"). +- Group tasks logically by prefixing titles with [Phase 1] or [US1]. -### 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. -` +Your turn ends when you have either asked the user a clarifying question, or completed a batch of document writes and task additions and summarized the progress.` : ` # 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. @@ -503,70 +474,6 @@ The project's requirements, features list, specifications, and backlog checklist 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. diff --git a/vibn-frontend/components/vibn-chat/chat-panel.tsx b/vibn-frontend/components/vibn-chat/chat-panel.tsx index 5a14203f..3e57752a 100644 --- a/vibn-frontend/components/vibn-chat/chat-panel.tsx +++ b/vibn-frontend/components/vibn-chat/chat-panel.tsx @@ -2179,42 +2179,6 @@ export function ChatPanel({ > - - {selectToggle} {(() => { // While the AI is streaming or running tools, the button