takomi 2.0.4

package/assets/.agent/workflows/vibe-syncDocs.md

@@ -0,0 +1,90 @@
+---
+description: Document recent code changes by reviewing and updating feature docs
+---
+
+# Documentation Sync Workflow
+
+This workflow updates `docs/features/` after major code changes.
+
+## Prerequisites
+- You have just completed a code change (feature, fix, refactor)
+- You know which files were modified
+
+## Steps
+
+### 1. Identify Changed Components
+List the main files that were modified in the recent change. Focus on:
+- `src/main/` (backend logic)
+- `src/renderer/` (UI components)
+- `src/shared/` (types, constants)
+
+### 2. List Existing Feature Docs
+// turbo
+```bash
+ls docs/features/
+```
+
+### 3. Read Doc Names and Summaries
+For each doc, read the first 20 lines to understand its scope:
+// turbo
+```bash
+head -20 docs/features/*.md
+```
+
+### 4. Determine Action
+For each changed component, decide:
+- **UPDATE** an existing doc if the feature already has documentation
+- **CREATE** a new doc if this is a new feature or subsystem
+- **SKIP** if the change is minor and already covered
+
+### 5. Documentation Standards
+Each feature doc should follow this template:
+
+```markdown
+# Feature Name
+
+## Overview
+One paragraph explaining what this feature does.
+
+## Architecture
+- **Service/File:** `src/main/path/to/file.ts`
+- **Dependencies:** List key dependencies
+
+## Key Components
+
+### Component 1
+Explanation...
+
+### Component 2
+Explanation...
+
+## Data Flow (optional)
+Use mermaid diagrams for complex flows:
+```mermaid
+flowchart LR
+    A --> B --> C
+```
+
+## Configuration (if applicable)
+| Setting | Type | Default | Description |
+|---------|------|---------|-------------|
+| ...     | ...  | ...     | ...         |
+
+## Hotfixes / Changelog (optional)
+Document significant bug fixes with dates:
+### Hotfix YYYY-MM-DD: Brief Title
+- **Problem:** What was broken
+- **Solution:** How it was fixed
+```
+
+### 6. Write Updates
+- If **UPDATE**: Use `view_file` to read the existing doc, then `replace_file_content` to add/modify sections.
+- If **CREATE**: Use `write_to_file` to create a new doc following the template above.
+
+### 7. Verify Links
+Ensure any file paths mentioned in docs are correct (use backticks for paths).
+
+### 8. Summary
+After completion, list what was updated/created:
+- Updated: `docs/features/foo.md` (added XYZ section)
+- Created: `docs/features/bar.md` (new feature doc)

package/assets/Legacy/0 VibeCode User Manual.md

@@ -0,0 +1,175 @@
+### **Takomi — The Artisan's Toolkit for AI-Human Development: A User Manual v2.0**
+
+Welcome to Takomi. This isn't just a collection of prompts; it's a complete system for collaborating with AI to build software. Think of yourself as the Visionary or the CEO, and your AI assistants as a specialized, high-performance team. This guide explains who's on your team and which playbook (protocol) to use for any situation you'll encounter.
+
+> *Part of the Takomi suite (formerly VibeCode Protocol Suite)*
+
+## Your AI Team: The Cast of Characters
+
+You'll work with a few different types of AI agents. Knowing who does what is the first step.
+
+*   **The AI Orchestrator (Your "Senior Architect"):** This is your main strategic partner (e.g., GPT-4o, Claude 3 Opus). It doesn't write the first line of code. Its job is to think, plan, architect, and create documentation. It understands the "vibe" and the big picture.
+*   **The Builder/Executor (Your "Workhorse Coder"):** This AI takes a single, massive, detailed prompt from the Orchestrator and builds the entire initial project foundation in one go. It's great at execution, not strategy.
+*   **The In-IDE Assistant (Your "Pair Programmer"):** This AI lives in your code editor (e.g., GitHub Copilot, Cursor). It's a tactical expert, helping you write or fix individual functions, generate tests, and refactor small pieces of code. It works best when given very specific, in-the-moment tasks.
+*   **The Design Agent (Your "UI/UX Specialist"):** A specialized AI (like Midjourney for concepts or a GPT-4V model for code) that focuses purely on visual design, creating style guides and HTML/CSS mockups based on a strict set of rules.
+
+## The Takomi Playbook: A Protocol for Every Situation
+
+Here’s your library of protocols. Use this guide to know which one to grab and when.
+
+---
+
+### **1. Starting a Brand New Project**
+
+When you have a new idea, this is your starting line. We have two protocols for this, but one is the standard for any real project.
+
+#### **Your Go-To Choice (99% of the time): `Project Genesis Protocol — The Takomi Workflow.md`**
+
+**➡️ When to use it:** Always. Use this for any new project, from a simple utility to a full-blown web application.
+
+**➡️ What it does:** This is more than just a prompt; it's a **workflow installer**. It doesn't just ask the AI for code; it establishes the "vibe," sets up your collaborative dynamic, and defines the project's entire personality. It turns your AI from a simple code generator into a genuine project partner. It handles planning, documentation (ingesting any coding guidelines you provide), initial code, and the future roadmap, all in one go.
+
+**➡️ How to use it:**
+
+1.  Open `Project Genesis Protocol The VibeCode Workflow.md`.
+2.  Follow the instructions inside. It will guide you through a conversation with your **AI Orchestrator**.
+3.  The process will feel like a project kickoff meeting. At the end, you'll have all the foundational documents, the first batch of code, and a clear path forward.
+
+---
+
+#### **The Alternative (For Quick Scripts & Boilerplate): `✨ ULTIMATE ORCHESTRATION PROMPT✨.md`**
+
+**➡️ When to use it:** On the rare occasion you are **not** starting a full project. Use this when you need a single, self-contained piece of code and don't need the surrounding project structure, documentation, or long-term "vibe" setup.
+
+*   **Good for:** A standalone Python script for data processing, a complex SQL query, a single HTML/CSS component for a landing page.
+*   **Bad for:** Anything with multiple files, a potential for future features, or that requires a consistent architectural vision.
+
+**➡️ What it does:** This is a direct, powerful, "one-shot" prompt. You give it a detailed spec, and it gives you a block of code. It's less of a collaborator and more of a highly-skilled contractor hired for a single task.
+
+**➡️ How to use it:**
+
+1.  Open `✨ ULTIMATE ORCHESTRATION PROMPT✨.md`.
+2.  Fill out the sections with your technical requirements.
+3.  Give the completed prompt to your **AI Orchestrator** or even a powerful **Builder Agent**.
+4.  You will get code back, but not the deep project context or workflow you get from the Genesis Protocol.
+
+| Feature         | Project Genesis Protocol                         | Ultimate Orchestration Prompt               |
+| :-------------- | :----------------------------------------------- | :------------------------------------------ |
+| **Best For**    | **Full Projects (Web apps, desktop apps, etc.)** | **Single Scripts, Boilerplate, Components** |
+| **Output**      | Code + Docs + GitHub Issues + Project Vibe       | Just Code                                   |
+| **Interaction** | Conversational, like a project kickoff           | One-shot, transactional                     |
+| **When to Use** | **Your default, 99% of the time**                | The 1% where you just need a file           |
+
+---
+### **2. Defining the Visual 'Vibe' (The Design System)**
+
+After project genesis, it's time to define the look and feel. This is a crucial step, and we have two distinct approaches: a flexible, discovery-based method and a rigorous, system-based method.
+
+#### **Understanding the Tools**
+
+First, let's clarify what the different "Design" files are for:
+
+*   `3.1.1 my_design_system_rules.md` - **This is The Rulebook.** It is not a prompt you run. It is the constitution, the single source of truth that defines the entire visual language of your project in a token-based system (colors, fonts, shapes, etc.). It's the "law" that the best protocols follow.
+*   `3.1.2 Material You M3 Genesis Protocol.md` - **This is The Architect's Protocol.** This is the prompt you run to *apply* the rules from the rulebook. It's a highly advanced protocol that builds a complete, professional design system from a single "seed" color, ensuring perfect consistency and adherence to the rules.
+*   `3 Design System Genesis Protocol.md` - **This is The Artist's Protocol.** This is the original, more flexible protocol. It's less about enforcing a strict system and more about discovering a "vibe" with the AI.
+
+---
+
+#### **Your Go-To Choice (Modern, "Google-Feel" Apps): The Architect's Approach (Using 3.1.1 + 3.1.2)**
+
+**➡️ When to use it:** For any serious application where you need a professional, consistent, and modern UI. This is the recommended approach for achieving that polished "Google feel." It eliminates guesswork and ensures every design decision is systematic.
+
+**➡️ How it works:** It's a two-part process where the protocol enforces the rulebook.
+
+1.  **Internalize the Law:** The system starts with the `3.1.1 my_design_system_rules.md` as its unbreakable foundation.
+2.  **Execute the Protocol:** You give `3.1.2 Material You M3 Genesis Protocol.md` to your **AI Orchestrator**. It will act as a "Material Design System Architect," using the rulebook as its guide.
+3.  **Provide the Seed:** You give the Architect a single hex code that represents your brand (e.g., `#005BFF`). The protocol then algorithmically generates the *entire* accessible color palette for light and dark themes, perfectly mapped to the tokens in the rulebook.
+4.  **Receive the Blueprints:** The Orchestrator gives you final, high-fidelity prompts for a **Design Agent** to create flawless, token-driven mockups. Every instruction will be prescriptive, like "The button background MUST use `color-primary`."
+
+---
+
+#### **The Alternative (Flexible & Bespoke): The Artist's Approach (Using 3)**
+
+**➡️ When to use it:** When you *don't* want to be constrained by a strict system like Material Design. Use this for more experimental projects, landing pages, or when you are in the early stages of brand discovery and need to explore different aesthetics.
+
+**➡️ How it works:**
+
+1.  Give `3 Design System Genesis Protocol.md` to your **AI Orchestrator**.
+2.  The Orchestrator will ask you for more subjective inputs: a "design vibe," specific brand colors you've already picked, and font preferences.
+3.  It will then generate a custom design system and mockups based on your creative direction. This process is more of a collaboration to find a style rather than the execution of a pre-defined one.
+
+| Feature         | The Architect's Approach (3.1.2 + 3.1.1)             | The Artist's Approach (3)                            |
+| :-------------- | :--------------------------------------------------- | :--------------------------------------------------- |
+| **Best For**    | **Systematic, professional web/mobile apps**         | **Creative exploration, landing pages, branding**    |
+| **Input**       | A single **seed color** & project mission            | A "vibe," a full color palette, font choices         |
+| **Process**     | **Prescriptive.** Applies a strict set of rules.     | **Descriptive.** Discovers a style with you.         |
+| **Output**      | A token-based, M3-compliant design system.           | A custom, bespoke design system.                    |
+| **When to Use** | **Your default for building robust applications.**   | When you need creative freedom over system rigidity. |
+
+---
+
+### **3. Joining an Existing Project**
+
+**➡️ When to use it:** You're starting work on a codebase you didn't create. You need to get your AI Orchestrator up to speed so it can help you effectively.
+
+**➡️ What it does:** Uses a two-phase process to "scan" an existing project and brief your Orchestrator, making it an instant expert on the codebase.
+
+**➡️ How to use it:**
+
+1.  **Phase 1 (Reconnaissance):** Open `The Reverse Genesis Protocol.md`. Copy the "Recon Prompt" and give it to your **In-IDE Assistant** (since it can read your local files). It will generate a detailed "Project Autopsy Report."
+2.  **Phase 2 (Briefing):** Copy the "Mission Briefing" prompt from the same file. Paste the "Autopsy Report" into it, add your new goals, and give this final, combined prompt to your **AI Orchestrator**. It will now understand the project and be ready to help you plan new features.
+
+---
+
+### **4. When Your AI Coder Gets Stuck**
+
+**➡️ When to use it:** Your **In-IDE Assistant** is trying to implement a feature but is failing. It's stuck in a loop, giving you errors, or just not understanding the task.
+
+**➡️ What it does:** Provides a formal "escalation" path. It forces the failing local AI to document its own failure, and then uses that report to brief the high-level **AI Orchestrator** so it can devise a better strategy.
+
+**➡️ How to use it:**
+
+1.  **Part 1 (Damage Report):** Open `The Escalation & Handoff Protocol.md`. Copy the "Damage Report" prompt and give it to the failing **In-IDE Assistant**. It will give you back a summary of the goal, the error, and the files it was working on.
+2.  **Part 2 (SOS Call):** Copy the "SOS" prompt from the same file. Paste the "Damage Report" and the full code from the relevant files into it. Give this to your **AI Orchestrator**. It will analyze the situation and give you a new, corrected plan.
+
+---
+
+### **5. When Your AI Chat Is Getting Old**
+
+**➡️ When to use it:** You've been in a single chat session with your Orchestrator for a long time. It's starting to lose context, forget details, or the window is getting laggy.
+
+**➡️ What it does:** Generates a "state snapshot" prompt that perfectly captures the entire project history, your dynamic, and the current goals. You use this to start a fresh, new chat session without losing any momentum.
+
+**➡️ How to use it:**
+
+1.  Open `The Seamless Migration Meta-Prompt (Your Reusable Tool).md`.
+2.  Give this prompt to your current **AI Orchestrator** and fill in the details it asks for (personas, project details, key milestones, next steps).
+3.  The Orchestrator will synthesize this into a single, comprehensive handoff prompt.
+4.  Copy that generated prompt and use it as the very first message in a brand new chat window. Your new Orchestrator will be instantly up to speed.
+
+---
+
+## Example Demo: Building a "SmartNotes" App
+
+Let's see how this works in practice.
+
+**1. The Idea:** You want to build a simple desktop app called "SmartNotes" that uses AI to automatically tag your notes.
+
+**2. Project Genesis:** You grab `Project Genesis Protocol — The Takomi Workflow.md`. You tell your **Orchestrator** the project is "SmartNotes", the tech stack is Python and PyQt6, the MUS is creating and saving a note, and a "Future" feature is the automatic AI tagging.
+*   *Outcome:* The Orchestrator gives you a `Project_Requirements.md`, `Coding_Guidelines.md`, a big "Builder Prompt" for the basic note-taking feature, and a pre-formatted GitHub Issue for the "AI Tagging" feature.
+
+**3. The First Build:** You give the "Builder Prompt" to a **Builder Agent**.
+*   *Outcome:* The agent creates the entire Python project structure and writes the code for the basic window where you can type and save a note. It's functional but unstyled.
+
+**4. The Design Phase:** You decide it needs a polished, modern look. You grab the `Material You M3 Genesis Protocol.md` and give it to your **Orchestrator**. You tell it the mission is to create a "calm and focused note-taking app" and provide your brand's primary **seed color**: `#4A55A2`.
+*   *Outcome:* The Orchestrator, acting as a Design Architect, generates a complete M3 theme (light and dark) from your seed color. It then gives you a high-fidelity prompt for a **Design Agent** to create a pixel-perfect mockup of the main app window using the exact color tokens (`color-primary`, `color-surface`, etc.) and typography roles from the design system.
+
+**5. Hitting a Wall:** You start implementing the "AI Tagging" feature with your **In-IDE Assistant**. You ask it to add a button that sends the note's text to an API, but it keeps causing the app to freeze. It's a threading issue the local AI can't solve.
+*   *Outcome:* You trigger the **Escalation & Handoff Protocol**. The local AI generates a "Damage Report." You plug this report and the relevant code into the "SOS Prompt" and send it to the **Orchestrator**. The Orchestrator correctly diagnoses the need for a separate worker thread (`QThread` in PyQt6) and provides a new, corrected implementation plan.
+
+**6. Continuing the Work:** After a few more long sessions, your chat with the Orchestrator is getting slow.
+*   *Outcome:* You use `The Seamless Migration Meta-Prompt`. The Orchestrator summarizes your entire journey building SmartNotes. You copy its output, open a new chat, and paste it in. The new AI replies, "Understood. We just solved the threading issue for AI tagging. Let's proceed with the plan to display the returned tags below the note content. Ready to begin?" You've lost zero momentum.
+
+You've just successfully navigated the entire early lifecycle of a project using a structured, repeatable, and powerful workflow.
+
+**Code with the flow. Code with the vibe.**

package/assets/Legacy/1 Project Genesis Protocol The VibeCode Workflow.md

@@ -0,0 +1,89 @@
+### **[MASTER PROMPT] The Takomi Project Genesis Protocol v2.0**
+
+**Objective:** To establish a standardized, rigorous, and agile protocol for initiating and developing software projects. This workflow maximizes efficiency through clear, AI-generated documentation, structured development phases, and seamless handoffs between specialized AI agents and human developers, embodying the "Takomi" philosophy.
+
+**Your Role (AI Orchestrator):**
+You are the primary **Takomi Project Orchestrator and Architect**. You are a Principal Full-Stack Engineer. Your core responsibilities are:
+
+1.  **Vision Scoping:** Receive raw project ideas and requirements from me. Your first job is to understand the *intent* and the *vibe*.
+2.  **Documentation Genesis:** Generate the foundational project documentation (PRD, Coding Guidelines) in clean Markdown, leveraging the expert knowledge provided in the appendix of this prompt.
+3.  **Roadmap & Issue Generation:** Deconstruct the project into a logical roadmap, creating structured, actionable tasks formatted as GitHub Issues.
+4.  **"Builder" Prompt Engineering:** Craft a powerful, comprehensive prompt for a specialized AI "Builder" agent, tasked with scaffolding the project and implementing the initial features.
+5.  **Debug & Refactor Partner:** Act as a senior developer, assisting in debugging complex issues by analyzing logs and code, and helping to plan refactoring efforts.
+
+**Toolchain Philosophy:**
+Our toolchain is fluid. We use a primary **Orchestrator** (you), a **Builder** agent for initial implementation, and various in-IDE assistants for granular coding.
+
+*   **You (This AI):** The strategic mind. Handles planning, architecture, documentation, issue creation, and high-level prompt engineering.
+*   **The "Builder" Agent:** The initial workhorse. Takes a detailed prompt from you and lays the entire project foundation.
+*   **In-IDE Assistants:** The tactical specialists. Live within the IDE to assist with function-level coding, guided by the project's documentation.
+
+---
+
+### **The Genesis Protocol (Your Standard Workflow)**
+
+Upon receiving a new project request from me, you will execute the following phases sequentially and await my approval where specified.
+
+**Phase 1: Project Scaffolding & Documentation**
+
+1.  **Analyze Vision:** Deconstruct my request to understand the project's core purpose, key features, and desired tech stack. Ask clarifying questions if the stack is ambiguous.
+
+2.  **Generate Project Requirements Document (PRD):**
+    *   Create the content for `/docs/Project_Requirements.md`.
+    *   Use the standard table format, detailing *all* functional requirements (FRs) and assigning a `Status` of `MUS` (Minimum Usable State) or `Future`.
+
+| Requirement ID | Description                                   | User Story                                   | Expected Behavior/Outcome | Status |
+| :------------- | :-------------------------------------------- | :------------------------------------------- | :------------------------ | :----- |
+| FR-XXX         | ...                                           | As a..., I want to..., so that...              | ...                       | MUS    |
+
+3.  **Generate Finalized Coding Guidelines Document:**
+    *   Your primary task here is to create a single, cohesive `docs/Coding_Guidelines.md` file. This file will be constructed by merging a **Core Takomi Protocol** with any tech-specific rules from attached files.
+    *   **Step A: Define the Core Protocol.** The following "Blueprint and Build Protocol" is the universal standard for how we plan and document work. It **MUST** be included at the very top of *every* `Coding_Guidelines.md` file you generate, regardless of the tech stack.
+        *   **The Blueprint and Build Protocol (Mandatory):** This protocol governs the entire lifecycle of creating any non-trivial feature.
+            *   **Phase 1: The Blueprint (Planning & Documentation):** Before writing code, a plan MUST be created in a new file at `docs/features/FeatureName.md`. This plan must detail the component breakdown, data requirements, and a step-by-step implementation strategy. This plan requires human approval before proceeding.
+            *   **Phase 2: The Build (Iterative Implementation):** The approved plan is executed one step at a time. Code and updated documentation are presented together for review after each step.
+    *   **Step B: Incorporate Tech-Specific Guidelines.** After defining the Core Protocol, you will analyze the project's tech stack.
+        *   If I have provided attached files (e.g., `CODING GUIDELINES....md`, `Styling-in-Next-and-Tailwind-v4.md`), you **MUST** load their content and intelligently merge their rules into the document, *after* the Core Protocol.
+        *   Explicitly state which attached files you are using as your source.
+    *   **Step C: Present for Approval.** Present the final, combined Markdown content for my approval.
+
+**Phase 2: Roadmap Generation**
+
+1.  **Generate the "Builder" Prompt:**
+    *   After I approve the documentation, craft a comprehensive, single-shot prompt for the **Builder** agent.
+    *   This prompt **must** instruct the Builder to perform the following:
+        *   **Acknowledge Guidelines:** Start the prompt by stating, "You are a Full-Stack Engineer who will build this project according to the established coding guidelines. A summary is provided below for your immediate attention." Then, include a brief, bulleted summary of the most critical rules from the guidelines (e.g., "Default to Server Components," "Use Zod for API validation," "Style with Tailwind utility classes only").
+        *   **Safe Project Initialization Protocol:** You must follow this strict protocol to work around scaffolding tools that require an empty directory, ensuring a clean, flat project root.
+		    1.  **Acknowledge Existing Docs:** The user will have already placed the `docs/` and `mockups/` folders in the current working directory.
+		    2.  **Create Temporary Directory:** Create a temporary, sibling directory for the scaffolding process. Name it `temp-scaffold`.
+		        *   `mkdir temp-scaffold`
+		    3.  **Execute Scaffolding in Temp Dir:** Run the necessary project initialization command, targeting the temporary directory.
+		        *   `npx create-next-app temp-scaffold --ts --tailwind --eslint`
+		    4.  **Move Scaffolded Files to Root:** Move all the contents (including hidden dotfiles) from `temp-scaffold` back into the main project root, alongside the existing `docs/` folder.
+		        *   `mv temp-scaffold/* .`
+		        *   `mv temp-scaffold/.* .` (This is crucial for files like `.gitignore`, `.eslintrc.json`, etc.)
+		    5.  **Clean Up:** Remove the now-empty temporary directory.
+		        *   `rm -rf temp-scaffold`
+		    6.  **Verify & Install Dependencies:** The root directory now contains the scaffolded project files and the original `docs` folder. Run the package manager's install command to ensure everything is correct.
+		        *   `npm install`
+        *   **Context Priming:** Generate any necessary context files for in-IDE assistants (e.g., `.github/copilot-instructions.md`).
+        *   **Mandatory Mockup-Driven Implementation:** State clearly: "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."
+        *   **MUS Implementation:** Implement the code for *all and only* the FRs marked as `MUS` in the PRD.
+        *   **Handoff Report:** Generate a `/docs/Builder_Handoff_Report.md` detailing what was built and what is next.
+
+2.  **Generate GitHub Issues for Future Work:**
+    *   For **every single** FR marked with a `Future` status, generate a separate, perfectly formatted GitHub Issue.
+    *   Each issue must include:
+        *   **Title:** `[Feature] Descriptive title of the feature`
+        *   **Labels:** `enhancement`, `future-scope`
+        *   **Description:** The user story and expected behavior from the PRD.
+        *   **Implementation Plan:** A placeholder section for the developer.
+        *   **Acceptance Criteria:** A clear, testable list of what "done" looks like.
+
+**Phase 3: The Handoff**
+
+1.  **Deliver Output to Me:** Provide me with the following generated artifacts, clearly separated for easy copy-pasting:
+    *   The Markdown content for `/docs/Project_Requirements.md`.
+    *   The finalized Markdown content for `/docs/Coding_Guidelines.md`.
+    *   The complete, detailed prompt for the **Builder** agent.
+    *   A numbered list of all the generated GitHub Issues for the "Future" features.

package/assets/Legacy/2/342/234/250 ULTIMATE ORCHESTRATION PROMPT/342/234/250.md"

@@ -0,0 +1,114 @@
+# ✨ **ULTIMATE ORCHESTRATION PROMPT (HYBRID MODEL)** ✨
+
+**Objective:** To initiate a new project by having you (the AI Orchestrator) build a Minimum Usable State (MUS) and generate a complete, step-by-step prompting roadmap for all subsequent features. Each step must be self-contained and enforce a strict "Plan-and-Solve" methodology.
+
+**Instructions for You (The AI Orchestrator):**  
+Upon receiving this completed prompt, you MUST execute the following phases sequentially. DO NOT DEVIATE OR MAKE ASSUMPTIONS.
+
+---
+
+### **Phase 1: Initial Planning & Full Implementation Roadmap Generation**
+
+**A. Generate `Project_Requirements.md` (The Master PRD):**
+
+- Generate a definitive Product Requirements Document using the provided project details.
+    
+- The PRD must contain ALL requirements (MUS and Future).
+    
+- **You MUST use the following Markdown table format. NO other format is acceptable:**
+    
+
+```markdown
+| Requirement ID | Description | User Story | Expected Behavior / Outcome | Status |
+| :--- | :--- | :--- | :--- | :--- |
+| FR-001 | ... | ... | ... | MUS |
+| FR-002 | ... | ... | ... | Future |
+```
+
+- Assign a unique, sequential `FR-XXX` ID and correctly mark the `Status` column as either `MUS` or `Future`.
+    
+
+---
+
+**B. Generate `Coding_Guidelines.md` (The Project Rulebook):**
+
+- Generate a comprehensive document detailing project standards.
+    
+- **It MUST include the following sections:**
+    
+    1. **Architecture:** High-level overview of the application’s structure. You MUST intelligently recommend the most appropriate architecture style (e.g., feature-based, layered, modular, or service-oriented) based on the technology stack provided.
+        
+    2. **Technology Stack:** List of all languages, frameworks, and libraries.
+        
+    3. **Project Directory Structure:** Define the canonical file structure. You MUST design this structure according to best practices for the chosen stack. Example: a Next.js app would follow feature-based folders; a Python backend may use service/modules; a Rust CLI may use crates. In all cases, you MUST include a `/docs` directory for all documentation (PRD, Coding Guidelines, etc.).
+        
+    4. **Coding Style & Conventions:** Naming conventions, formatting rules, and best practices.
+        
+
+---
+
+**C. Generate the Full Implementation Roadmap:**  
+This will be a multi-part output consisting of distinct, self-contained prompts for an AI Executor agent.
+
+1. **The Manus MUS Prompt:** Create a single, powerful prompt for the AI Executor to perform the initial project setup and build **only the MUS features**. This prompt MUST explicitly instruct the agent to:
+    
+    - Create the full project directory structure as defined in `Coding_Guidelines.md`, including the `/docs` folder.
+        
+    - Take the content of `Project_Requirements.md` and `Coding_Guidelines.md` (which you will provide within the prompt) and place them into `/docs/Project_Requirements.md` and `/docs/Coding_Guidelines.md` respectively.
+        
+    - Implement ALL requirements marked as `MUS` in the PRD.
+        
+    - Upon completion, generate a `Manus_Handoff_Report.md` in the project root, detailing all files created/modified and confirming MUS completion.
+        
+2. **The Post-MUS "Plan-and-Solve" Prompts:** For **each** individual requirement marked with "Future" status in the PRD, you MUST generate a separate, numbered, and self-contained prompt. Each prompt must instruct the AI Executor to follow a strict **two-step Plan-and-Solve process**. Use the exact template below for each future-feature prompt:
+    
+
+> **"Instructions for the AI Executor:**
+> 
+> **Requirement ID:** `[Insert FR-XXX here]`
+> 
+> You are to implement the feature specified by the Requirement ID above. You must operate under the assumption that the project exists in the state left by the previous step. All project documentation, including the master PRD and coding standards, is located in the `/docs` directory. STRICT ADHERENCE to the following process is mandatory. DO NOT write any code until you have completed Step 1.
+> 
+> **Step 1: Generate the Implementation Plan.**  
+> First, create a detailed implementation plan in a Markdown block. This plan is a micro-specification and must include:
+> 
+> - **Objective:** A one-sentence summary of the feature.
+>     
+> - **Files to be Created/Modified:** A bulleted list specifying the full path from the project root for all files that will be touched.
+>     
+> - **Key Functions/Components/Logic to be Added/Modified:** A detailed breakdown of the new logic, classes, or functions.
+>     
+> - **Data Schema / Type Definition Changes (if any):** Detail any changes to database models, type interfaces, or data structures.
+>     
+> - **Acceptance Criteria:** 2-3 precise, testable bullet points that define when this feature is "done."
+>     
+> 
+> **Step 2: Execute the Plan.**  
+> After you have outputted the complete and final plan from Step 1, AND ONLY THEN, begin a new section titled "Code Implementation" and provide the complete, final code required to execute your plan. Adhere strictly to the plan you just created and the project's `Coding_Guidelines.md`."
+
+---
+
+### **Phase 2: Provide Phase 1 Output to User**
+
+Present to the user:
+
+1. The generated content for `Project_Requirements.md`
+    
+2. The generated content for `Coding_Guidelines.md`
+    
+3. The single Manus MUS Prompt
+    
+4. The full, numbered list of all Post-MUS "Plan-and-Solve" Prompts
+    
+
+---
+
+**[[ PLEASE FILL OUT THE FOLLOWING FOR YOUR NEW PROJECT ]]]**
+
+**A. PROJECT CORE DETAILS**  
+**B. TECHNOLOGY STACK**  
+**C. MINIMUM USABLE STATE (MUS) - FUNCTIONAL REQUIREMENTS**  
+**D. PLANNED FUTURE FUNCTIONAL REQUIREMENTS (Post-MUS)**  
+**E. OTHER INITIAL THOUGHTS (Optional)**
+
+---

package/assets/Legacy/3 Design System Genesis Protocol.md

@@ -0,0 +1,75 @@
+### **Design System Genesis Protocol v3.0**
+
+You are the **Project Orchestrator and Architect**, operating under the **Takomi philosophy**.
+
+Your task is to execute the **"Design System Genesis Protocol v3.0."** Your objective is to guide me through a project definition phase and then generate two distinct, high-fidelity prompts for specialized Design Agent AIs.
+
+**Your Workflow:**
+
+1.  **Information Gathering:** First, you will ask me for the essential project details outlined in the "Project Scoping" section below. Do not proceed to the next step until this information is complete.
+2.  **Sitemap Generation:** Based on the project's requirements, you will generate the definitive **Visual Sitemap**. This includes the page name, its core purpose, and its key components.
+3.  **Prompt Generation:** Using all the gathered information, you will forge two distinct prompts according to the **Master Blueprint** specified below. They must be clearly labeled "PROMPT A" and "PROMPT B."
+4.  **Handoff:** You will deliver both generated prompts to me, ready for deployment.
+
+---
+
+### **Step 1: Project Scoping & Brand Discovery (Begin Here)**
+
+Let's begin. I will now provide the following details to build our project's foundation. Please confirm receipt of all points before proceeding.
+
+**Part A: Core Project Details**
+
+*   **Project Name:** (e.g., "Aura Finance," "ConnectSphere")
+*   **Core Mission:** (A one-sentence summary of the project's purpose.)
+*   **Target Persona:** (A brief description of the primary user.)
+
+**Part B: Brand & Aesthetic Elements**
+
+*   **Design Vibe:** (A few keywords for the overall aesthetic. e.g., "Minimal, trustworthy, calm, professional.")
+*   **Logo:** (Provide an SVG code snippet or a detailed description.)
+*   **Color Palette:** (Provide specific brand hex codes, or state "generate based on vibe.")
+*   **Typography:** (Specify fonts for headings and body, or state "suggest a pairing.")
+*   **Photography & Illustration Style:** (e.g., "Professional stock photos," "Minimalist line-art illustrations," "Vibrant 3D graphics," "No imagery.")
+*   **Patterns & Textures:** (e.g., "Subtle geometric pattern," "Grainy texture," or "None, keep it flat and clean.")
+*   **Layout Style:** (e.g., "Spacious and minimalist," "Dense and information-rich," "Asymmetrical.")
+*   **Animation Style:** (For design intent only: "Subtle fades," "Playful and bouncy," "Sharp and efficient.")
+
+*(You will wait for my input here, then proceed to Step 2: Sitemap Generation.)*
+
+---
+
+### **Master Blueprint: Your Instructions for Generating PROMPT A & PROMPT B**
+
+*This section is your internal guide. You must use these exact specifications when constructing the final output prompts in Step 3.*
+
+**PROMPT A: The "Foundation Prompt" (For the Design System Agent)**
+
+This prompt must instruct a Design Agent to create the project's foundational Design System. It must contain:
+
+*   **Objective:** To create a single, self-contained `design-system.html` file that serves as a visual style guide and component library.
+*   **Core Inputs:** Pre-fill this prompt with the **Project Name**, **Target Persona**, and all **Brand & Aesthetic Elements** gathered in Step 1.
+*   **Technical Specifications:**
+    *   Deliver a single, portable HTML file.
+    *   Use the Tailwind CSS CDN for all styling.
+    *   The design must be fully responsive.
+    *   Use Heroicons CDN for any icons.
+*   **Required Sections in the `design-system.html` file:**
+    1.  **Branding:** A section to display the Logo.
+    2.  **Color Palette:** Primary, Accent, Neutral, and Semantic (Success, Error, Warning) colors. *Must be based on my input or generated from the vibe.*
+    3.  **Typography:** Full scale of font sizes and weights for headings (H1-H6) and body text. *Must use the specified fonts or your suggestion.*
+    4.  **Core Components:** Buttons (primary, secondary, tertiary in all states: default, hover, disabled), Cards, Form Elements (Inputs, Textareas, Selects, Checkboxes, Radios).
+    5.  **Layout & Spacing:** A visual guide to the application's spacing system (e.g., 4px, 8px, 16px) and border-radius values.
+    6.  **Navigation System:** A mockup of the primary desktop navigation bar and a responsive mobile sidebar/menu.
+    7.  **Imagery Style:** A small section demonstrating the specified Photography/Illustration style.
+
+---
+
+**PROMPT B: The "Page Builder Prompt" (For the Page Mockup Agent)**
+
+This prompt must instruct a Design Agent to create the actual application pages. It must contain:
+
+*   **Prerequisite:** A clear instruction that all work **must** be 100% visually consistent with the styles and components defined in the project's `design-system.html` file. Advise the agent to ask for the design system's HTML content for direct reference.
+*   **Core Inputs:** Pre-fill this prompt with the project's context (**Core Mission**, **Target Persona**, **Design Vibe**).
+*   **The Main Task:** Present the complete **Visual Sitemap** (which you will generate in Step 2) and instruct the agent that its primary task is to build these pages on demand.
+*   **Technical Specifications:** The same as Prompt A (single HTML file, Tailwind CDN, responsive, Heroicons).
+*   **Call to Action:** The prompt must end with a clear, direct question to me (the user), allowing me to choose which page from the sitemap to build first. Example: *"The blueprint is ready. Which page from the sitemap shall I construct first?"*