vibe-me 1.0.0

package/templates/architecture.md

@@ -0,0 +1,42 @@
+# Architecture
+
+<!-- 
+  INSTRUCTIONS FOR AI AGENT:
+  Read .vibe/VIBE_GUIDE.md for the full specification.
+  Describe SYSTEMS, not files. Think: "Frontend", "API", "Database", "Auth" — 
+  not "src/utils.ts" or "UserController class".
+  The diagram should fit on ONE SCREEN.
+  Delete these instruction comments when done.
+-->
+
+## Systems
+
+<!-- 
+  Draw an ASCII or Mermaid diagram showing all major systems.
+  Each box is a system (Frontend, Backend, Database, AI Layer, etc.)
+  Each arrow is labeled with the protocol (HTTP, WebSocket, SQL, IPC, etc.)
+  
+  Example:
+  ┌──────────┐     HTTP     ┌──────────┐     SQL      ┌──────────┐
+  │ Frontend │ ───────────► │ Backend  │ ───────────► │ Database │
+  └──────────┘              └──────────┘              └──────────┘
+-->
+
+## How They Connect
+
+<!-- A table showing connections between systems -->
+
+| From | To | Protocol | Purpose |
+|---|---|---|---|
+| | | | |
+
+## Trust Boundaries
+
+<!-- Optional but valuable. Where does trusted data end and untrusted data begin? -->
+
+<!-- 
+  Example:
+  UNTRUSTED              GATE                    TRUSTED
+  Browser input    →   Validation           →   API handler
+  API request      →   JWT verification     →   Database query
+-->

package/templates/decisions.md

@@ -0,0 +1,33 @@
+# Decisions
+
+<!-- 
+  INSTRUCTIONS FOR AI AGENT:
+  Read .vibe/VIBE_GUIDE.md for the full specification.
+  This is the MOST IMPORTANT file. Most repos are impossible to understand 
+  because nobody recorded WHY choices were made.
+  
+  For each decision:
+  1. State the choice that was made
+  2. Explain the context and constraints
+  3. List the alternatives that were considered
+  4. State the tradeoff that was accepted
+  
+  Research sources: git log, PR descriptions, code comments (HACK/NOTE/TODO),
+  pinned dependency versions, README history.
+  
+  If you can't determine WHY from the code, ASK THE USER.
+  Every project has at least: language choice, framework choice, database choice.
+  Delete these instruction comments when done.
+-->
+
+## Why [technology/approach] instead of [alternative]?
+
+[Context and constraints that led to this choice]
+
+[Alternatives considered and why they were rejected]
+
+[Tradeoffs accepted — what's the downside of this choice?]
+
+---
+
+<!-- Copy the template above for each major decision. Aim for 3-10 decisions. -->

package/templates/entities.md

@@ -0,0 +1,24 @@
+# Entities
+
+<!-- 
+  INSTRUCTIONS FOR AI AGENT:
+  Read .vibe/VIBE_GUIDE.md for the full specification.
+  List the important NOUNS of the system — things users create, view, or care about.
+  NOT internal classes, NOT framework concepts.
+  Look at: database tables, API resources, TypeScript interfaces, UI labels.
+  Every entity MUST have all 4 fields. "What depends on it?" is the most important.
+  Delete these instruction comments when done.
+-->
+
+## [Entity Name]
+
+[One sentence: what is this thing?]
+
+- **What is it?** [Detailed explanation]
+- **Who creates it?** [What user action or system process brings it into existence]
+- **Who modifies it?** [What can change it after creation]
+- **What depends on it?** [What breaks if this entity is deleted or modified]
+
+---
+
+<!-- Copy the template above for each entity. Most projects have 5-15 entities. -->

package/templates/flows.md

@@ -0,0 +1,51 @@
+# Flows
+
+<!-- 
+  INSTRUCTIONS FOR AI AGENT:
+  Read .vibe/VIBE_GUIDE.md for the full specification.
+  Describe USER JOURNEYS — what a user DOES and SEES, not internal processing.
+  Use simple arrow notation. Every project needs at least 2 flows.
+  If this is a library with no user flows, write "N/A — library" and describe the integration pattern instead.
+  Delete these instruction comments when done.
+-->
+
+## 1. [Primary Value Flow — the main thing users come to do]
+
+<!--
+  Example:
+  User opens the app
+    ↓
+  Searches for a document
+    ↓
+  Uploads a file
+    ↓
+  AI processes it (loading spinner, ~10 seconds)
+    ↓
+  Results displayed in dashboard
+-->
+
+## 2. [Onboarding Flow — how a new user gets started]
+
+<!--
+  Example:
+  User visits landing page
+    ↓
+  Clicks "Sign Up" → enters email and password
+    ↓
+  Receives verification email → clicks link
+    ↓
+  Redirected to onboarding wizard
+    ↓
+  Completes setup → sees dashboard
+-->
+
+## 3. [Error/Recovery Flow — what happens when something goes wrong]
+
+<!--
+  Example:
+  User encounters an error
+    ↓
+  Error message displayed with action options
+    ↓
+  User retries or contacts support
+-->

package/templates/purpose.md

@@ -0,0 +1,33 @@
+# Purpose
+
+<!-- 
+  INSTRUCTIONS FOR AI AGENT:
+  Read .vibe/VIBE_GUIDE.md for the full specification.
+  Fill out each section below based on your analysis of the codebase.
+  If you can't determine something from the code, ASK THE USER.
+  Delete these instruction comments when done.
+-->
+
+## What is this?
+
+<!-- 1-3 sentences. No jargon. A non-technical person should understand. -->
+
+## Who is it for?
+
+<!-- Specific user personas. Not "developers" — what KIND of developers? -->
+
+## What problem does it solve?
+
+<!-- The pain point that existed before this project. What was the user doing before? Why was that bad? -->
+
+## What does success look like?
+
+<!-- A concrete scenario. "A user does X, then Y, then Z, and it feels like W." -->
+
+## What does it explicitly NOT do?
+
+<!-- Hard boundaries. At least 3 items. Things users might expect but will never get. -->
+
+- 
+- 
+- 

package/templates/state.json

@@ -0,0 +1,12 @@
+{
+  "version": "0.1.0",
+  "health": "active",
+  "status": "prototype",
+  "last_audit": "TIMESTAMP",
+  "languages": {},
+  "known_issues": [],
+  "dependencies": [],
+  "constraints": [],
+  "vibe_version": "1.0",
+  "vibe_updated": "TIMESTAMP"
+}