design(chat): remove un-wired dictation and select-mode buttons from composer to match Base44 simplicity

vibn-frontend/app/api/chat/route.ts

@@ -222,58 +222,29 @@ export async function buildSystemPrompt(
   const modeInstructions =
     chatMode === "collaborate"
       ? `
-# MODE: Architect (Collaborate)
+# MODE: Architect (Plan & Spec)
-You are an Architect and Product Strategist using Spec-Driven Development.
+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 CODE OR USE FILE SYSTEM TOOLS (e.g., fs_edit, fs_write, ship, shell_exec).**
+**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.
-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)
+## The Planning Flow (Crucial!)
-Do not guess. Ask the user clarifying questions. When the requirements are clear, use \`plan_vision_set\` to save the PRD.
+DO NOT dump a wall of text or ask 10 questions at once. Be conversational and brief.
-The PRD MUST strictly follow this Markdown template:
+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]
+## Specification Documents (File map)
-**Status**: Draft
+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
+## Execution Tasks (Database)
-User stories MUST be prioritized as user journeys ordered by importance. Each user story MUST be INDEPENDENTLY TESTABLE.
+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.
-### User Story 1 - [Brief Title] (Priority: P1)
+- Each task should be an atomic, executable step (e.g., "[US1] Create User table in schema.prisma", "[US1] Build /api/auth endpoint").
-[Describe this user journey in plain language]
+- Group tasks logically by prefixing titles with [Phase 1] or [US1].
-**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)
+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.`
-[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.
@@ -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.

vibn-frontend/components/vibn-chat/chat-panel.tsx

@@ -2179,42 +2179,6 @@ export function ChatPanel({
                   >
                     <Paperclip style={{ width: 14, height: 14 }} />
                   </button>
-                  <button
-                    type="button"
-                    style={{
-                      ...COMPOSER_ACTION_BTN_BASE,
-                      background: "transparent",
-                      color: "#a1a1aa",
-                      border: "1px solid transparent",
-                      cursor: "pointer",
-                      transition: "all 0.1s ease",
-                    }}
-                    onMouseEnter={(e) => {
-                      e.currentTarget.style.background = "#f4f4f5";
-                      e.currentTarget.style.color = "#18181b";
-                    }}
-                    onMouseLeave={(e) => {
-                      e.currentTarget.style.background = "transparent";
-                      e.currentTarget.style.color = "#a1a1aa";
-                    }}
-                    title="Voice dictation"
-                  >
-                    <svg
-                      width="14"
-                      height="14"
-                      viewBox="0 0 24 24"
-                      fill="none"
-                      stroke="currentColor"
-                      strokeWidth="2"
-                      strokeLinecap="round"
-                      strokeLinejoin="round"
-                    >
-                      <path d="M12 2a3 3 0 0 0-3 3v7a3 3 0 0 0 6 0V5a3 3 0 0 0-3-3Z"></path>
-                      <path d="M19 10v2a7 7 0 0 1-14 0v-2"></path>
-                      <line x1="12" x2="12" y1="19" y2="22"></line>
-                    </svg>
-                  </button>
-                  {selectToggle}
                 </div>
                 {(() => {
                   // While the AI is streaming or running tools, the button