vibefast-cli 0.7.0 → 0.7.2

package/2/vf-agent/agents/sm.md

@@ -1,38 +0,0 @@
-# sm
-
-CRITICAL: Read the full YAML, start activation to alter your state of being, follow startup section instructions, stay in this being until told to exit this mode:
-
-```yaml
-activation-instructions:
-  - ONLY load dependency files when user selects them for execution via command or request of a task
-  - The agent.customization field ALWAYS takes precedence over any conflicting instructions
-  - When listing tasks/templates or presenting options during conversations, always show as numbered options list, allowing the user to type a number to select or execute
-  - STAY IN CHARACTER!
-agent:
-  name: Bob (VibeFast Specialist)
-  id: sm
-  title: VibeFast Scrum Master
-  icon: 🏃
-  whenToUse: Use for creating detailed, implementation-ready stories for the VibeFast project.
-persona:
-  role: VibeFast Story Preparation Specialist
-  style: Task-oriented, efficient, precise, focused on creating perfect developer handoffs.
-  identity: A story creation expert who prepares detailed, actionable stories specifically for the VibeFast Expert Developer.
-  focus: Creating crystal-clear stories, enriched with deep context from the VibeFast Knowledge Base, that an AI developer can implement without confusion.
-  core_principles:
-    - **Follow `create-story` Task:** My sole purpose is to execute the `create-story` task to generate the next user story with maximum context.
-    - **Source from VibeFast KB:** All technical guidance in the stories I create will be sourced directly from the `master-rulebook.md`, the project's specific architecture documents, and the detailed `starter-docs`.
-
-    - **Never Implement:** I am not allowed to write or modify application code. My role is strictly story preparation.
-    - **Sequential Story Creation:** I will always assume stories are created in ascending order. If the `docs/stories/` folder is empty, I will start with story 1.1. If it contains stories, I will identify the highest numbered story, will check if its done will then tell user that it's not done should we complete it first or create next, then proceed based on user's response, and then create the next sequential one. I will not ask the user which story to create unless there is an error or an incomplete story blocking the path.
-    - **Code Reuse Analysis:** I will ALWAYS analyze existing codebase for reusable patterns, components, and implementations before creating new stories. This analysis will be included in every story's Dev Notes section.
-commands:
-  - help: Show this guide.
-  - create-story: Execute task `create-story.md`.
-  - exit: Exit and return to Orchestrator.
-dependencies:
-  tasks:
-    - create-story.md
-  data:
-    - knowledge_base
-```

package/2/vf-agent/agents/ux-expert.md

@@ -1,33 +0,0 @@
-# ux-expert
-
-CRITICAL: Read the full YAML, start activation to alter your state of being, follow startup section instructions, stay in this being until told to exit this mode:
-
-```yaml
-activation-instructions:
-  - ONLY load dependency files when user selects them for execution via command or request of a task
-  - The agent.customization field ALWAYS takes precedence over any conflicting instructions
-  - When listing tasks/templates or presenting options during conversations, always show as numbered options list, allowing the user to type a number to select or execute
-  - STAY IN CHARACTER!
-agent:
-  name: Sally (VibeFast Specialist)
-  id: ux-expert
-  title: VibeFast UX Expert
-  icon: 🎨
-  whenToUse: Use for UI/UX design and specifications that leverage the existing VibeFast design system.
-persona:
-  role: User Experience Designer & VibeFast Design System Specialist
-  identity: A UX Expert specializing in designing intuitive interfaces by composing elements from the VibeFast core component library.
-  focus: Creating user flows and UI specifications that feel native to the VibeFast app, ensuring a consistent and predictable user experience.
-  core_principles:
-    - **Design with Core Components:** My first step is always to design new UIs using the existing components in `src/components/ui/`. I will not propose new, inconsistent UI patterns.
-    - **Adhere to NativeWind:** All style and layout guidance will be based on the established NativeWind theme and utility classes.
-    - **VibeFast-Aware Prompts:** When using `generate-ai-frontend-prompt`, the generated prompt will be rich with VibeFast-specific context, instructing the AI to use the correct components and styling.
-dependencies:
-  tasks:
-    - generate-ai-frontend-prompt.md
-    - create-doc.md
-  templates:
-    - front-end-spec-tmpl.yaml
-  data:
-    - knowledge_base
-```

package/2/vf-agent/checklists/po-master-checklist.md

@@ -1,73 +0,0 @@
-# VibeFast Product Owner (PO) Master Validation Checklist
-
-This checklist serves as a comprehensive framework for the Product Owner to validate project plans against the VibeFast architecture before development execution.
-
-[[LLM: INITIALIZATION INSTRUCTIONS
-
-Your single source of truth for this validation is the VibeFast Knowledge Core located in `vf-agent/data/knowledge_base/`. You must validate the project's PRD and Architecture documents against the rules found in the `master-rulebook.md` and its linked files.
-
-EXECUTION MODE:
-Work through this checklist section by section. For each failed item, provide a clear explanation citing the specific rule from the Knowledge Core that was violated.]]
-
-## 1. VibeFast Architectural Compliance (CRITICAL)
-
-[[LLM: This is the most important section. Validate the plan against the VibeFast constitution.]]
-
-- [ ] **Modularity:** Is the new feature planned as a self-contained module within `src/features/` and `convex/`? (Ref: `general-principles.md`)
-- [ ] **Abstraction:** If using external services, does the plan explicitly require using or creating an adapter in `src/core/`? (Ref: `general-principles.md`)
-- [ ] **File Naming:** Do all proposed file paths in the architecture adhere to the `kebab-case` (frontend) and `camelCase` (backend) conventions? (Ref: `universal-standards/coding-style.md`)
-- [ ] **Function Validators:** Does the architecture specify that all new Convex functions will have both `args` and `returns` validators? (Ref: `backend/convex-main.md`)
-- [ ] **Schema & Indexes:** If new queries are defined, are corresponding indexes specified in the schema changes? Is the use of `.filter()` prohibited? (Ref: `backend/convex-database.md`)
-- [ ] **Core Component Usage:** Does the UI plan specify that new components will be built using the base components from `src/components/ui/`? (Ref: `frontend/ui-and-styling.md`)
-- [ ] **Routing:** Are new screens correctly placed in either `src/app/(tabs)/` or `src/app/(routes)/` directories? (Ref: `starter-docs/unified-project-structure.md`)
-- [ ] **Tech Stack Compliance:** Does the plan exclusively use technologies listed in `starter-docs/tech-stack.md`?
-
-## 2. PROJECT SETUP & INITIALIZATION
-
-### 2.1 Existing System Integration (Brownfield)
-
-- [ ] Existing project analysis has been completed and documented.
-- [ ] Integration points with the current VibeFast system are clearly identified.
-- [ ] Core VibeFast dependencies' version compatibility has been verified.
-
-## 3. INFRASTRUCTURE & DEPLOYMENT
-
-### 3.1 Convex Database & Schema
-
-- [ ] Schema changes are planned before data operations.
-- [ ] Migration strategies (if needed) are defined and backward-compatible.
-
-### 3.2 Convex Backend Configuration
-
-- [ ] Authentication setup for new functions is specified.
-- [ ] API compatibility with the existing frontend is maintained.
-
-## 4. FEATURE SEQUENCING & DEPENDENCIES
-
-### 4.1 Functional Dependencies
-
-- [ ] Features depending on others are sequenced correctly.
-- [ ] Shared components/services are built before their use.
-- [ ] Authentication-dependent features are sequenced after auth setup.
-
-### 4.2 Technical Dependencies
-
-- [ ] Lower-level Convex functions are built before higher-level ones.
-- [ ] Data models are defined before operations on them.
-
-## 5. MVP SCOPE ALIGNMENT
-
-### 5.1 Core Goals Alignment
-
-- [ ] All core goals from the PRD for this enhancement are addressed.
-- [ ] Features directly support the enhancement's MVP goals.
-
-### 5.2 User Journey Completeness
-
-- [ ] All critical user journeys for the new feature are fully implementable based on the plan.
-- [ ] Edge cases and error scenarios are addressed.
-- [ ] Accessibility requirements are incorporated into the UI plan.
-
-## VALIDATION SUMMARY
-
-[[LLM: Generate a validation report. List all failed checklist items, the rule that was violated, and a recommendation for how the PM or Architect should fix the document.]]

package/2/vf-agent/checklists/story-dod-checklist.md

@@ -1,37 +0,0 @@
-# VibeFast Definition of Done (DoD) Checklist
-
-## Instructions for VibeFast Expert Developer
-
-Before marking a story as 'Review', you MUST validate your work against every item on this checklist. Report the status of each item.
-
-[[LLM: This is a mandatory quality gate. Be thorough and honest in your self-assessment. Refer to the `knowledge_base` for detailed guidelines on each point.]]
-
-### 1. Code Implementation & Structure
-
-- [ ] **File Placement:** All new screens and components have been placed in the correct directory (`src/app/(tabs)` vs. `src/app/(routes)`).
-- [ ] **Naming Conventions:** All new files, components, functions, and variables adhere to the VibeFast naming conventions (`kebab-case` in `src`, `camelCase` in `convex`).
-- [ ] **Modularity:** Logic is appropriately modularized, and no code has been unnecessarily duplicated. Component size is under 80 LOC, and functions are under 250 LOC.
-- [ ] **Abstraction:** No direct calls were made to external SDKs (Sentry, PostHog, etc.). All interactions use the established service adapters in `src/core/`.
-- [ ] **Absolute Imports:** All imports within the `src/` directory use the `@/` absolute path alias.
-
-### 2. Convex Backend
-
-- [ ] **Function Syntax:** All new Convex functions use the modern function syntax.
-- [ ] **Validators:** Every new Convex function includes both `args` and `returns` validators.
-- [ ] **Schema & Queries:** If new data queries were needed, corresponding indexes were added to `convex/schema.ts`. No `.filter()` was used in queries.
-
-### 3. Frontend UI & State
-
-- [ ] **Core Components:** All new UI is built using the base components from `src/components/ui/`.
-- [ ] **Styling:** Styling is done via NativeWind utility classes. No unnecessary inline styles were added.
-- [ ] **State Management:** State is managed according to the hierarchy (Convex hooks > Zustand > useState).
-
-### 4. Testing & Quality
-
-- [ ] **Unit Tests:** New logic (utility functions, complex components, Convex functions) is covered by unit tests.
-- [ ] **E2E Support:** `testID` props have been added to all new interactive elements.
-- [ ] **Linting & Typing:** The code is free of any new ESLint errors and passes the TypeScript strict mode check (`tsc --noEmit`).
-
-### 5. Final Confirmation
-
-- [ ] I, the VibeFast Expert Developer, confirm that all applicable items above have been addressed and the implementation adheres to the project's core principles.

package/2/vf-agent/core-config.yaml

@@ -1,43 +0,0 @@
-markdownExploder: true
-
-# Defines locations for primary project planning artifacts.
-prd:
-  prdFile: docs/prd.md
-  prdVersion: v4
-  prdSharded: true
-  prdShardedLocation: docs/prd
-  epicFilePattern: epic-{n}*.md
-architecture:
-  architectureFile: docs/architecture.md
-  architectureVersion: v4
-  architectureSharded: true
-  architectureShardedLocation: docs/architecture
-
-# Nutrition Tracker Project Configuration
-currentProject: nutrition-tracker
-projectStatus: planning-complete
-nextAgent: sm
-
-# CRITICAL: The VibeFast "Knowledge Core". This file is automatically
-# loaded for ALL planning agents (pm, architect, po, sm, analyst, ux-expert).
-planningLoadAlwaysFiles:
-  - vf-agent/data/knowledge_base/master-rulebook.md
-  - vf-agent/data/knowledge_base/starter-docs/index.md
-  - vf-agent/data/knowledge_base/starter-docs/prd.md
-  - vf-agent/data/knowledge_base/starter-docs/tech-stack.md
-  - vf-agent/data/knowledge_base/starter-docs/unified-project-structure.md
-  - vf-agent/data/knowledge_base/starter-docs/features-overview.md
-  - vf-agent/data/knowledge_base/starter-docs/feature-reference-index.md
-
-# CRITICAL: Files the DEV agent loads for EVERY story.
-# These point to the universal rules, not project-specific docs.
-devLoadAlwaysFiles:
-  - vf-agent/data/knowledge_base/master-rulebook.md
-  - vf-agent/data/knowledge_base/coding-standards.md
-  - vf-agent/data/knowledge_base/starter-docs/tech-stack.md
-
-# Configuration for development workflow
-devDebugLog: .ai/debug-log.md
-devStoryLocation: docs/stories
-planning_mode: guided
-testing_discipline: disabled

package/2/vf-agent/data/knowledge_base/backend/convex-advanced.md

@@ -1,43 +0,0 @@
-# Convex - Advanced Features
-
-> Backend paths referenced here use the monorepo layout (`packages/backend/convex/...`).
-
-## 1. Actions & Node.js Environment
-
-- Convex `actions` are for side effects, running longer tasks, and integrating with third-party APIs.
-- **Node.js Actions:** To use Node.js-specific modules (like `crypto` or `fs`), you **MUST** add `"use node";` as the absolute first line of the file.
-- **V8 Isolate Actions:** By default, actions run in a more limited V8 environment. Prefer this for faster cold starts if you don't need Node.js-specific dependencies.
-- Actions **do not have direct database access**. They must call mutations or queries using `ctx.runMutation` and `ctx.runQuery`.
-
-## 2. HTTP Endpoints
-
-- HTTP endpoints are defined in **`packages/backend/convex/http.ts`**.
-- An `httpAction` handler receives `(ctx, request)` and **MUST** return a standard `Response` object.
-- **Authentication:** To secure an `httpAction`, the client must send its Convex token in the `Authorization: Bearer <TOKEN>` header. Inside the action, use `await ctx.auth.getUserIdentity()` to validate the session. If the identity is `null`, you **MUST** return a `401 Unauthorized` response.
-
-## 3. Scheduled & Cron Jobs
-
-- Cron jobs are defined in **`packages/backend/convex/crons.ts`**.
-- Use `crons.interval()` for simple interval-based jobs (e.g., every 5 minutes).
-- Use `crons.cron()` for standard cron expressions.
-  - Cron jobs can only call **internal** queries, mutations, or actions.
-
-  ```ts
-  import { cronJobs } from 'convex/server';
-  import { internal } from './_generated/api';
-
-  const crons = cronJobs();
-  crons.interval(
-    'clear old data every hour',
-    { hours: 1 },
-    internal.myTasks.clearOldData,
-  );
-  export default crons;
-  ```
-
-## 4\. File Storage
-
-- Use Convex File Storage for user uploads like images, videos, or PDFs.
-- **Client-side upload:** The client generates an upload URL via a mutation, uploads the file directly to that URL, and then passes the returned `storageId` to another mutation to associate it with a document.
-- **Getting File URLs:** In a query, use `await ctx.storage.getUrl(storageId)` to get a temporary, publicly accessible URL for a file. This returns `null` if the `storageId` is invalid.
-- File storage operations from the client do not require passing the auth token manually; the Convex client handles it.

package/2/vf-agent/data/knowledge_base/backend/convex-database.md

@@ -1,53 +0,0 @@
-# Convex - Database & Schema
-
-> Backend paths referenced here use the monorepo layout (`packages/backend/convex/...`).
-
-## 1. Schema Definition
-
-- The single source of truth for the database schema is **`packages/backend/convex/schema.ts`**.
-- Define all tables using `defineTable` and wrap them in `defineSchema`.
-- System fields `_id` and `_creationTime` are added automatically.
-
-## 2. Indexes
-
-- To query on a field, you **MUST** define an index for it in `schema.ts`.
-- **Querying without an index using `.filter()` is strictly forbidden** as it leads to slow, full-table scans. Use `.withIndex()` instead.
-  - Follow the standard index naming convention: an index on `userId` and `status` should be named `by_userId_and_status`.
-    ```typescript
-    .index("by_userId", ["userId"])
-    ```
-  ```
-
-  ```
-
-## 3\. Querying Data
-
-- Use `ctx.db.query("tableName")` to start a query.
-- Use `.withIndex("indexName", q => q.eq("fieldName", value))` to filter efficiently.
-- Use `.unique()` to retrieve a single document. It will throw an error if more than one document matches, which is often the desired behavior for unique fields.
-- Use `.order("desc")` or `.order("asc")` for sorting. The default is ascending by `_creationTime`.
-
-## 4\. Mutating Data
-
-- **`ctx.db.insert("tableName", { ... })`**: To create a new document.
-- **`ctx.db.patch(docId, { ... })`**: To perform a shallow merge update on an existing document.
-- **`ctx.db.replace(docId, { ... })`**: To completely overwrite an existing document.
-- **`ctx.db.delete(docId)`**: To delete a document.
-
-## 5\. Full-Text Search
-
-- To perform a full-text search, you must first define a search index in `schema.ts`.
-  ```typescript
-  // in schema.ts
-  messages: defineTable({ ... }).searchIndex("search_body", {
-    searchField: "body",
-  }),
-  ```
-- Then, use `.withSearchIndex()` in your query.
-  ```typescript
-  // in a query function
-  const messages = await ctx.db
-    .query('messages')
-    .withSearchIndex('search_body', (q) => q.search('body', 'hello world'))
-    .take(10);
-  ```

package/2/vf-agent/data/knowledge_base/backend/convex-main.md

@@ -1,65 +0,0 @@
-# Convex - Core Concepts
-
-> Backend paths referenced here use the monorepo layout (`packages/backend/convex/...`).
-
-## 0. Environment Variables
-
-- All environment variables required by any convex function or any convex code must be synced in cloud instance in this way: `npx convex env set MY_VARIABLE "your_secret_value"` our convex instance never looks at local env file, it looks at the envs in cloud instance.
-
-## 1. Function Syntax & Visibility
-
-- **New Function Syntax:** ALWAYS use the new function syntax.
-
-  ```ts
-  import { query } from './_generated/server';
-  import { v } from 'convex/values';
-
-  export const getThing = query({
-    args: { id: v.id('things') },
-    handler: async (ctx, args) => {
-      // ...
-    },
-  });
-  ```
-
-  - **Visibility:**
-    - **Public:** Use `query`, `mutation`, `action` for public API functions exposed to the client.
-    - **Internal:** Use `internalQuery`, `internalMutation`, `internalAction` for private functions that can only be called by other Convex functions on the backend. This is critical for security.
-
-## 2\. Validators
-
-- **MANDATORY:** **ALL** Convex functions (public and internal) **MUST** include `args` and `returns` validators.
-- For functions that don't explicitly return a value, you **MUST** use `returns: v.null()`.
-- Use the `v` object from `convex/values` to define validators for all arguments and return types.
-
-## 3\. API Design & Function Calling
-
-- **File-Based Routing:** Convex uses file-based routing. A function `myFunction` in `packages/backend/convex/users.ts` is referenced as `api.users.myFunction`. Organize your functions into logical files.
-- **Calling Functions:**
-  - From the client (React Native), use the `useQuery`, `useMutation`, and `useAction` hooks.
-  - From the backend, use `ctx.runQuery`, `ctx.runMutation`, and `ctx.runAction`.
-- **Function References:**
-  - Public functions: `api.moduleName.functionName`
-  - Internal functions: `internal.moduleName.functionName`
-
-## 4\. Authentication
-
-- Use `getAuthUserId` from `@convex-dev/auth/server` within mutations and queries to get the authenticated user's ID. Do not use `identity.subject`.
-  ```ts
-  import { getAuthUserId } from '@convex-dev/auth/server';
-  // ...
-  const userId = await getAuthUserId(ctx);
-  if (!userId) {
-    throw new Error('User must be authenticated.');
-  }
-  ```
-
-## 5. Environment Variables (CRITICAL)
-
-- Convex functions can access environment variables set in the Convex Dashboard. You **MUST NOT** hardcode secrets like API keys directly in your code.
-- To access them, use `process.env.MY_VARIABLE`.
-- **MANDATORY SYNCING:** When you add a new function that relies on a new environment variable from your `.env.local` file, you **MUST** sync it with your Convex deployment.
-- **The Command:** Use the Convex CLI to set each variable for your deployment. The agent is required to run this command for any new variables it uses.
-  ```bash
-  npx convex env set MY_VARIABLE "your_secret_value"
-  ```