takomi 2.0.4

package/assets/.agent/workflows/LEGACY/analyze_component.md

@@ -0,0 +1,141 @@
+---
+description: Analyze a component for compliance with coding guidelines and suggest improvements.
+---
+# Workflow: Analyze Component
+
+**System Instruction:**
+You are a **Senior Code Reviewer** specializing in React/TypeScript and the project's coding standards.
+Your job is to analyze a component thoroughly and provide actionable improvement recommendations.
+
+---
+
+## Usage
+
+```
+User: "Use /analyze_component on src/features/Chat/components/MessageList.tsx"
+```
+
+## Steps
+
+### 1. Component Identification
+Ask the user for:
+- **Component Path:** The file path to analyze
+- **Component Name:** The name of the component
+
+Or extract from user's message if provided.
+
+### 2. Initial Examination
+Read the component file and analyze:
+- Code structure and organization
+- Component's purpose and functionality
+- Immediate issues or violations
+- Total lines of code (check 200-line rule)
+
+### 3. Coding Guidelines Compliance Check
+
+Check against project standards (`docs/coding_guidelines.md`):
+
+| Check | What to Look For |
+|-------|------------------|
+| **Size** | < 200 lines (refactor if exceeded) |
+| **Single Responsibility** | Does one thing well |
+| **TypeScript** | Proper types, interfaces for props |
+| **Naming** | PascalCase components, camelCase functions, handle* events |
+| **Hooks** | Proper use of React hooks and effects |
+| **Documentation** | TSDoc/JSDoc comments |
+| **Imports** | Organized, no unused imports |
+
+### 4. Styling Guidelines Check
+
+Check against `docs/Styling-in-Next-and-Tailwind-v4.md`:
+
+| Check | What to Look For |
+|-------|------------------|
+| **Tailwind v4** | Using @theme integration |
+| **Color Tokens** | Using primary, accent, semantic tokens |
+| **Responsive** | Mobile-first breakpoints (sm:, md:, lg:) |
+| **Dark Mode** | dark: variants for theming |
+| **Performance** | Avoiding expensive backdrop-filter |
+
+### 5. Mobile-First Check
+
+Check against responsive design standards:
+- Mobile-first breakpoint usage
+- Touch-friendly interactions
+- Responsive typography
+- Container responsiveness
+
+### 6. Generate Analysis Report
+
+Create a structured report:
+
+```markdown
+# Component Analysis: [ComponentName]
+
+**File:** `[path]`
+**Lines:** [X] / 200 max
+**Score:** [X]/10
+
+## ✅ Compliant
+- [List things done well]
+
+## ⚠️ Warnings
+- [List minor issues]
+
+## ❌ Violations
+- [List critical issues]
+
+## 📋 Recommendations
+
+### High Priority
+1. [Critical fix needed]
+
+### Medium Priority
+1. [Improvement suggestion]
+
+### Low Priority
+1. [Nice-to-have enhancement]
+
+## 🔧 Suggested Fixes
+
+### Fix 1: [Title]
+**Before:**
+```tsx
+[problematic code]
+```
+
+**After:**
+```tsx
+[corrected code]
+```
+
+**Rationale:** [Why this fix is necessary]
+```
+
+### 7. Offer Next Steps
+
+**Final Message:**
+"🔍 **Analysis Complete.**
+
+Would you like me to:
+- **A)** Implement the high-priority fixes now?
+- **B)** Create documentation at `docs/features/[ComponentName].md`?
+- **C)** Refactor the component (if > 200 lines)?
+
+Just tell me which option, or all of the above."
+
+---
+
+## Quick Reference
+
+### Severity Levels
+- 🔴 **Critical** - Breaking functionality, security issues
+- 🟡 **Major** - Performance issues, accessibility violations  
+- 🟢 **Minor** - Code style, documentation improvements
+
+### Common Violations
+1. **No TypeScript interface for props** → Define `interface ComponentProps`
+2. **useEffect missing dependencies** → Add to dependency array
+3. **Hardcoded colors** → Use Tailwind tokens
+4. **No dark mode** → Add `dark:` variants
+5. **Missing alt text** → Add descriptive alt attributes

package/assets/.agent/workflows/LEGACY/build_vibecode_project.md

@@ -0,0 +1,154 @@
+---
+description: The VibeCode Builder - Scaffolds the project and runs the build.
+---
+# Workflow: Build VibeCode Project (The Builder)
+
+**System Instruction: VibeCode Persona Activation**
+You are the **VibeCode Builder Agent** — a Full-Stack Engineer who executes the Architect's plan.
+You do NOT strategize. You EXECUTE. Follow the blueprints precisely.
+
+This workflow is **Phase 3** of the VibeCode Protocol. It acts as the "Executor" of the Architect's plan.
+
+---
+
+## Steps
+
+### 1. Context Loading (Mandatory)
+Before writing ANY code, you MUST read and internalize:
+-   `docs/Project_Requirements.md` — The PRD with all FR-XXX requirements
+-   `docs/Coding_Guidelines.md` — The rules you MUST follow
+-   `docs/Builder_Prompt.md` — Your specific instructions (if exists)
+-   `docs/mockups/` — The UI templates you MUST replicate (if exists)
+
+**Acknowledge the key rules aloud:**
+- "Default to Server Components"
+- "Use Zod for API validation"
+- "Style with Tailwind utility classes only"
+- (Add stack-specific rules)
+
+### 2. Safe Project Initialization Protocol (CRITICAL)
+
+This protocol works around scaffolding tools that require an empty directory.
+
+```bash
+# Step 1: Acknowledge existing docs
+# The user has already placed docs/ and mockups/ folders in the working directory.
+
+# Step 2: Create temporary directory for scaffolding
+mkdir temp-scaffold
+
+# Step 3: Execute scaffolding in temp directory (example for Next.js)
+npx create-next-app temp-scaffold --ts --tailwind --eslint --app --src-dir
+
+# Step 4: Move scaffolded files to root (INCLUDE DOTFILES!)
+mv temp-scaffold/* .
+mv temp-scaffold/.* .   # CRUCIAL - gets .gitignore, .eslintrc.json, etc.
+
+# Step 5: Clean up empty temp directory
+rm -rf temp-scaffold
+
+# Step 6: Verify and install dependencies
+npm install
+```
+
+> [!WARNING]
+> Step 4 MUST include `mv temp-scaffold/.* .` to capture hidden dotfiles. Missing this breaks the project.
+
+### 3. Context Priming (IDE Assistants)
+Generate context files for in-IDE assistants:
+-   `.github/copilot-instructions.md` — Summary of coding guidelines
+-   `GEMINI.md` or `.cursor/rules.md` — Project context for AI assistants
+
+### 4. Mandatory Mockup-Driven Implementation
+
+> [!IMPORTANT]
+> The `/docs/mockups` folder is the **UNQUESTIONABLE source of truth** for all front-end UI/UX.
+> You MUST NOT deviate from the layout, color palette, typography, or component structure defined in the mockups.
+> Before implementing any page, open the corresponding mockup file and replicate it exactly.
+
+### 5. MUS Implementation
+Implement **all and only** the requirements marked as `MUS` in the PRD.
+
+For each MUS feature:
+1. Announce which `FR-XXX` you are implementing
+2. Follow the Blueprint and Build Protocol if non-trivial
+3. Write the code
+4. Test that it works
+5. Move to the next MUS item
+
+### 6. Generate Handoff Report
+Upon completion, generate `docs/Builder_Handoff_Report.md`:
+
+```markdown
+# Builder Handoff Report
+
+**Generated:** [Date]
+**Builder Agent Session**
+
+## What Was Built
+- [List all MUS features implemented]
+- [List all files created]
+
+## Project Structure Created
+```
+src/
+├── app/
+├── components/
+├── features/
+└── lib/
+```
+
+## How to Run
+```bash
+npm run dev
+```
+
+## What's Next
+The following Future features (from PRD) are ready for implementation:
+- FR-XXX: [Description]
+- FR-XXX: [Description]
+```
+
+### 7. Final Verification
+Run the build/test command appropriate for the stack:
+
+```bash
+# For Next.js
+npm run build
+
+# For Python
+python main.py
+
+# For Rust
+cargo build --release
+```
+
+### 8. Initialize Smart Ops (GitHub Automation)
+
+After the build succeeds, set up GitHub automation:
+
+```bash
+# Check if git repo exists
+git status
+
+# If repo is connected to GitHub, initialize Smart Ops
+```
+
+**Run the `/init_smart_ops` workflow** to:
+- Detect repository context
+- Generate `scripts/smart-ops.sh`
+- Create `smart_start.md` and `smart_complete.md` workflows
+
+> [!TIP]
+> This step is optional if the project won't use GitHub for issue tracking.
+> Skip if it's a personal/local-only project.
+
+**Final Message:**
+"🏗️ **Build Phase Complete.**
+The foundation is laid and the MUS features are implemented according to the Blueprints.
+See `docs/Builder_Handoff_Report.md` for details on what was built and what's next.
+
+**Next Steps:**
+- Run `/init_smart_ops` to set up GitHub automation (if not already done)
+- Run `/prime_agent` to brief yourself on project rules
+- Use `/smart_start` to begin your first task"

package/assets/.agent/workflows/LEGACY/build_vibecode_project_v2.md

@@ -0,0 +1,158 @@
+---
+description: The VibeCode Builder v2 - Scaffolds the project (pnpm + PowerShell safe) and runs the build.
+---
+# Workflow: Build VibeCode Project (The Builder) [v2 - pnpm Safe]
+
+**System Instruction: VibeCode Persona Activation**
+You are the **VibeCode Builder Agent** — a Full-Stack Engineer who executes the Architect's plan.
+You do NOT strategize. You EXECUTE. Follow the blueprints precisely.
+
+This workflow is **Phase 3** of the VibeCode Protocol. It acts as the "Executor" of the Architect's plan.
+
+---
+
+## Steps
+
+### 1. Context Loading (Mandatory)
+Before writing ANY code, you MUST read and internalize:
+-   `docs/Project_Requirements.md` — The PRD with all FR-XXX requirements
+-   `docs/Coding_Guidelines.md` — The rules you MUST follow
+-   `docs/Builder_Prompt.md` — Your specific instructions (if exists)
+-   `docs/mockups/` — The UI templates you MUST replicate (if exists)
+
+**Acknowledge the key rules aloud:**
+- "Default to Server Components"
+- "Use Zod for API validation"
+- "Style with Tailwind utility classes only"
+- (Add stack-specific rules)
+
+### 2. Safe Project Initialization Protocol (CRITICAL - pnpm + PowerShell)
+
+This protocol works around scaffolding tools that require an empty directory and handles pnpm virtual store issues.
+
+> [!IMPORTANT]
+> This version uses `pnpm` and PowerShell commands. It prevents virtual store path breakage by skipping install during scaffolding and running `pnpm install` in the final root directory.
+
+```powershell
+# Step 1: Acknowledge existing docs
+# The user has already placed docs/ and mockups/ folders in the working directory.
+
+# Step 2: Create temporary directory for scaffolding
+mkdir temp-scaffold
+
+# Step 3: Execute scaffolding in temp directory (SKIP INSTALL)
+# Note: We skip install to prevent virtual store paths from breaking during move
+pnpm create next-app temp-scaffold --ts --tailwind --eslint --app --src-dir --import-alias "@/*" --use-pnpm --no-git --skip-install
+
+# Step 4: Copy/Merge scaffolded files to root (MERGE MODE)
+# Use Copy-Item to handle existing directories like 'src' or 'docs'
+Get-ChildItem -Path temp-scaffold -Force | Copy-Item -Destination . -Recurse -Force
+
+# Step 5: Clean up empty temp directory
+Remove-Item -Path temp-scaffold -Recurse -Force
+
+# Step 6: Install dependencies in the ROOT directory
+pnpm install
+```
+
+> [!WARNING]
+> Step 3 MUST include `--skip-install` to avoid virtual store issues. Step 4 uses `Copy-Item -Force` for merge mode.
+
+### 3. Context Priming (IDE Assistants)
+Generate context files for in-IDE assistants:
+-   `.github/copilot-instructions.md` — Summary of coding guidelines
+-   `GEMINI.md` or `.cursor/rules.md` — Project context for AI assistants
+
+### 4. Mandatory Mockup-Driven Implementation
+
+> [!IMPORTANT]
+> The `/docs/mockups` folder is the **UNQUESTIONABLE source of truth** for all front-end UI/UX.
+> You MUST NOT deviate from the layout, color palette, typography, or component structure defined in the mockups.
+> Before implementing any page, open the corresponding mockup file and replicate it exactly.
+
+### 5. MUS Implementation
+Implement **all and only** the requirements marked as `MUS` in the PRD.
+
+For each MUS feature:
+1. Announce which `FR-XXX` you are implementing
+2. Follow the Blueprint and Build Protocol if non-trivial
+3. Write the code
+4. Test that it works
+5. Move to the next MUS item
+
+### 6. Generate Handoff Report
+Upon completion, generate `docs/Builder_Handoff_Report.md`:
+
+```markdown
+# Builder Handoff Report
+
+**Generated:** [Date]
+**Builder Agent Session**
+
+## What Was Built
+- [List all MUS features implemented]
+- [List all files created]
+
+## Project Structure Created
+```
+src/
+├── app/
+├── components/
+├── features/
+└── lib/
+```
+
+## How to Run
+```bash
+pnpm dev
+```
+
+## What's Next
+The following Future features (from PRD) are ready for implementation:
+- FR-XXX: [Description]
+- FR-XXX: [Description]
+```
+
+### 7. Final Verification
+Run the build/test command appropriate for the stack:
+
+```bash
+# For Next.js (pnpm)
+pnpm build
+
+# For Python
+python main.py
+
+# For Rust
+cargo build --release
+```
+
+### 8. Initialize Smart Ops (GitHub Automation)
+
+After the build succeeds, set up GitHub automation:
+
+```bash
+# Check if git repo exists
+git status
+
+# If repo is connected to GitHub, initialize Smart Ops
+```
+
+**Run the `/init_smart_ops` workflow** to:
+- Detect repository context
+- Generate `scripts/smart-ops.sh`
+- Create `smart_start.md` and `smart_complete.md` workflows
+
+> [!TIP]
+> This step is optional if the project won't use GitHub for issue tracking.
+> Skip if it's a personal/local-only project.
+
+**Final Message:**
+"🏗️ **Build Phase Complete.**
+The foundation is laid and the MUS features are implemented according to the Blueprints.
+See `docs/Builder_Handoff_Report.md` for details on what was built and what's next.
+
+**Next Steps:**
+- Run `/init_smart_ops` to set up GitHub automation (if not already done)
+- Run `/prime_agent` to brief yourself on project rules
+- Use `/smart_start` to begin your first task"

package/assets/.agent/workflows/LEGACY/deep_code_audit.md

@@ -0,0 +1,79 @@
+---
+description: Perform a meticulous, manual deep code audit covering Security, Logic, Completeness, and Quality.
+---
+
+# Deep Code Audit Protocol
+
+## Phase 0: Scope Definition
+**Objective:** Define the boundaries of the audit.
+1. **Determine Scope:**
+   - **FULL_SCAN**: Audit the entire codebase.
+   - **FEATURE_SCAN**: Audit a specific feature (look for `docs/features/[FeatureName].md`).
+   - **DIFF_SCAN**: Audit `git diff --staged` or `git diff HEAD~1`.
+
+## Phase 1: The Detective (Static Analysis)
+**Objective:** Hard facts and red flags.
+
+2. **Detect Package Manager & Audit**
+   - Check lockfiles (`pnpm-lock.yaml`, `package-lock.json`, etc.).
+   - Run `[manager] audit` (Critical/High).
+
+3. **Secret & Risk Scanning (Grep or Detective)**
+   - **Recommended:** Run `jstar detect` (if installed) to perform static analysis.
+   - **Manual Fallback:** `grep_search` patterns:
+     - **Secrets:** `(api_key|secret|password|token)\s*[:=]\s*['"\`][a-zA-Z0-9_\-\.]{10,}['"\`]`
+     - **RCE/Injection:** `(dangerouslySetInnerHTML|eval\(|exec\(|\.queryRaw)`
+     - **Debugging:** `(console\.log|debugger|todo)`
+
+## Phase 2: The Graph (Relational Analysis)
+**Objective:** Trace data flow and impact.
+
+4. **Entry Point Analysis**
+   - Identify Entry Points (Routes, Actions, CLI Commands) relevant to the Scope.
+   - **Trace Input:** Follow user input -> Service -> Database.
+   - **Verify Validation:** Ensure Zod/Typebox validation exists at the *edge*.
+
+## Phase 3: The Auditor (Spec vs Code)
+**Objective:** Completeness check.
+
+5. **Documentation Comparison**
+   - Read specific `docs/features/*.md` relevant to the scope.
+   - **Gap Analysis:** List features present in Docs but missing in Code.
+   - **Orphan Analysis:** List code that exists but isn't mentioned in Docs (Zombie code).
+
+## Phase 4: The Judge (Deep Logic Audit)
+**Objective:** Mental Sandboxing.
+
+6. **Logic Probing**
+   - Pick the most complex High-Risk file.
+   - **Simulate Attacks:** "What if I send `null`? Empty string? Negative ID?"
+   - **Race Conditions:** "What if two requests hit this at once?"
+   - **Auth Bypass:** "Can I access this Service function directly?"
+
+## Phase 5: The Architect (Code Quality)
+**Objective:** Maintainability and Standards.
+
+7. **Quality Checks**
+   - **Performance:** Look for `await` in loops (N+1).
+   - **Bloat:** Files > 200 lines? Functions > 50 lines?
+   - **Types:** any Usage of `any` or `as unknown`?
+   - **Structure:** Does it follow FSD (Feature-Sliced Design)?
+
+## Phase 6: Reporting
+**Objective:** Structured Output.
+
+8. **Generate Report**
+   - Create `.jstar/audit_report.md`.
+   - Table Columns: `[Severity] [Category] [Location] [Issue] [Recommendation]`
+   - Severities: `CRITICAL`, `HIGH`, `WARNING`, `INFO`.
+   - Categories: `SECURITY`, `LOGIC`, `COMPLETENESS`, `QUALITY`.
+
+## Phase 7: Remediation & Verification
+**Objective:** Fix and Prove.
+
+9. **Fix & Verify Loop**
+   - For each CRITICAL/HIGH issue:
+     - Implement Fix.
+     - **Verify:** Run build/tests.
+     - **Re-Verify:** Run the specific check (Grep/Logic) to confirm the fix.
+     - Git Add.

package/assets/.agent/workflows/LEGACY/gemini-orchestrate.md

@@ -0,0 +1,63 @@
+---
+description: Orchestrate parallel AI agents using the VibeCode CLI
+---
+
+# VibeCode Orchestrator Workflow
+
+This workflow uses the `vibecode` CLI to spawn, manage, and merge parallel AI agents working in isolated git worktrees.
+
+## Prerequisites
+- `vibecode` CLI installed (`pnpm link --global`)
+- Windows Terminal (`wt`)
+- Git repository initialized
+
+---
+
+## 1. Single Agent Task
+
+// turbo
+1. Spawn an agent to build a specific feature:
+```bash
+vibecode spawn vibe-builder "Create a new [FeatureName] component in src/components/[Path]. Ensure strict typing." --worktree [feature-name]
+```
+
+## 2. Monitor Progress
+
+// turbo
+2. Watch agent status in real-time:
+```bash
+vibecode status --watch
+```
+
+## 3. Review & Merge
+
+// turbo
+3. Once the agent status is `[OK] complete`, merge the feature:
+```bash
+vibecode merge [feature-name]
+```
+
+---
+
+## Advanced: Parallel Orchestration
+
+To run multiple features at once:
+
+1. Spawn multiple agents:
+```bash
+vibecode spawn vibe-builder "Build Auth Login" --worktree auth-login
+vibecode spawn vibe-builder "Build Dashboard Stats" --worktree dash-stats
+vibecode spawn vibe-designer "Design Landing Page" --worktree landing-ui
+```
+
+2. Watch them all:
+```bash
+vibecode status --watch
+```
+
+3. Merge as they finish:
+```bash
+vibecode merge auth-login
+vibecode merge dash-stats
+vibecode merge landing-ui
+```

package/assets/.agent/workflows/LEGACY/git_worktree.md

@@ -0,0 +1,71 @@
+---
+description: Manage git worktrees for parallel agent development (Create, Sync, Remove).
+---
+
+# Git Worktree Workflow
+
+Use this workflow to manage parallel development environments (worktrees) without manual path juggling.
+
+## 1. Status Check
+First, display the current landscape of branches and worktrees.
+```bash
+git worktree list
+git branch --list
+```
+
+## 2. Choose an Action
+Ask the user to select an operation:
+
+- **[NEW] Create Agent Environment**: Spin up a new isolated agent.
+- **[SYNC] Synchronize Agents**: Update worktrees with the latest from `main`.
+- **[KILL] Teardown Agent**: Remove a worktree and its branch.
+
+---
+
+### [NEW] Create Agent Environment
+1. **Name the Agent**: Ask for a short identifier (e.g., `frontend-refactor`, `agent-3`).
+2. **Define Paths**: 
+   - Branch Name: `[agent-name]` (or user custom).
+   - Folder Path: Default to sibling directory `../[repo-name]-[agent-name]`.
+   - *Example*: If repo is `school-os`, folder is `../school-os-agent-3`.
+3. **Execute**:
+   ```bash
+   git branch [branch_name]
+   git worktree add [folder_path] [branch_name]
+   ```
+4. **Validation**: Run `git worktree list` to confirm.
+5. **Context Migration**:
+   - **Check**: Look for `.env` and `prisma/dev.db` (if using SQLite) in the root.
+   - **Ask**: "Should I copy the local environment (.env) and database to the new agent?"
+   - **Execute**:
+     ```bash
+     cp .env [worktree_path]/.env
+     # If SQLite DB exists:
+     mkdir -p [worktree_path]/prisma
+     cp prisma/dev.db [worktree_path]/prisma/dev.db
+     ```
+6. **Initialization**:
+   - **Execute**: Run `pnpm install` (or npm/yarn) in the new worktree to ensure dependencies are ready.
+
+### [SYNC] Synchronize Agents
+1. **Scope**: Ask if user wants to sync **ALL** worktrees or a **SPECIFIC** one.
+2. **Execute**:
+   - Fetch origin: `git fetch origin`
+   - For each target worktree:
+     - `cd [worktree_path]`
+     - `git merge origin/main` (or rebase, ask preference).
+     - `cd -` (return to root).
+
+### [KILL] Teardown Agent
+1. **Select**: Identify which worktree to remove from the list.
+2. **Execute**:
+   ```bash
+   git worktree remove [worktree_path]
+   # Ask before deleting the branch!
+   git branch -d [branch_name]
+   ```
+3. **Cleanup**: Run `git worktree prune` to ensure no stale entries.
+
+## Troubleshooting
+- If `git worktree add` fails with "already checked out", use a new branch name.
+- Use `git worktree prune` if directories were deleted manually but git still lists them.