mark/vibn-agent-runner
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
mawkone
2026-06-12 11:05:01 -07:00
parent 55646f668e
commit 9b13320253
2 changed files with 19 additions and 148 deletions
Download Patch File Download Diff File Expand all files Collapse all files

131
vibn-frontend/app/api/chat/route.ts
View File

@@ -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.

36
vibn-frontend/components/vibn-chat/chat-panel.tsx
View File

@@ -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