dasa-sradha-kit 5.0.0

package/.agent/scripts/workspace-mapper.py

@@ -0,0 +1,58 @@
+#!/usr/bin/env python3
+"""
+workspace-mapper.py — Cross-platform codebase tree visualization
+Persona: Dasa Dwipa (The Scout)
+
+Usage:
+  python .agent/scripts/workspace-mapper.py
+  python .agent/scripts/workspace-mapper.py --depth 3
+"""
+
+import os
+import sys
+import argparse
+from pathlib import Path
+
+IGNORE_DIRS = {
+    ".git", "node_modules", "__pycache__", ".venv", "venv", "vendor",
+    ".next", "dist", "build", "coverage", ".cache", "tmp", ".agent",
+    "ag-kit", "awesome-antigravity"
+}
+
+def build_tree(directory: Path, prefix: str = "", depth: int = 3, current_depth: int = 0) -> list[str]:
+    if current_depth >= depth:
+        return []
+
+    lines = []
+    try:
+        entries = sorted(
+            [e for e in directory.iterdir() if e.name not in IGNORE_DIRS],
+            key=lambda e: (not e.is_dir(), e.name.lower())
+        )
+    except PermissionError:
+        return []
+
+    for i, entry in enumerate(entries):
+        is_last = i == len(entries) - 1
+        connector = "└── " if is_last else "├── "
+        lines.append(f"{prefix}{connector}{entry.name}")
+        if entry.is_dir():
+            extension = "    " if is_last else "│   "
+            lines.extend(build_tree(entry, prefix + extension, depth, current_depth + 1))
+
+    return lines
+
+def main():
+    parser = argparse.ArgumentParser(description="Workspace structure map for Dasa Dwipa")
+    parser.add_argument("--depth", type=int, default=3, help="Max depth to display (default: 3)")
+    args = parser.parse_args()
+
+    cwd = Path.cwd()
+    print(f"\n📁 {cwd.name}/")
+    lines = build_tree(cwd, depth=args.depth)
+    for line in lines:
+        print(line)
+    print(f"\n[+] Scanned {len(lines)} entries (depth: {args.depth})")
+
+if __name__ == "__main__":
+    main()

package/.agent/workflows/dasa-api.md

@@ -0,0 +1,42 @@
+---
+description: Generate a stack-agnostic API endpoint. Example: /dasa-api "GET /users"
+---
+
+# /dasa-api
+
+```
+# USER REQUEST:
+$ARGUMENTS
+```
+
+---
+
+## 🔴 CRITICAL RULES
+
+1. **Guard Check:** Read `dasa.config.toon` in the root folder. If missing, tell the user to run `/dasa-init`.
+2. **Framework Detection:** You MUST respect the `backend` field in `dasa.config.toon`. If the backend is Express, generate Express routes. If it is Spring Boot, generate Java controllers. If it is Axum, generate Rust handlers.
+3. **Question-Driven Validation:** If the user request `$ARGUMENTS` is too vague (e.g. missing HTTP method or payload structure), do NOT guess. Ask clarifying questions first.
+
+---
+
+## 🛠️ Execution Pipeline
+
+### Phase 1: Clarification (Dasa Patih)
+- If the required API schema (request body, response body, HTTP codes) is not defined in `$ARGUMENTS`, pause and ask the user to provide it. If provided, proceed.
+
+### Phase 2: Implementation (Dasa Mpu)
+- Implement the controller/handler, the service layer, and the data-access layer for the API route.
+- Strictly follow `.agent/rules/GEMINI.md` logic (Clean Architecture).
+
+### Phase 3: Documentation (Dasa Sastra)
+- Assume Dasa Sastra. 
+- Append the new route to the project's Swagger/Postman JSON or general Markdown API docs.
+
+---
+
+## 🏁 Expected Output
+
+> **[OK] API Endpoint Generated:** `$ARGUMENTS`
+> **Controller Path:** `[Path to file]`
+> 
+> The API has been generated. Run `/dasa-commit` to save.

package/.agent/workflows/dasa-assimilate.md

@@ -0,0 +1,44 @@
+---
+description: Autonomously scans an undocumented or forked repository, determines the tech stack, configures Dasa Sradha, and updates the Memory Vault. Example: /dasa-assimilate
+---
+
+# /dasa-assimilate
+
+```
+# USER REQUEST:
+$ARGUMENTS
+```
+
+---
+
+## 🔴 CRITICAL RULES
+
+1. **Guard Check:** Look for `dasa.config.toon` in the root folder. If missing, tell the user to run `/dasa-init` and **stop immediately**.
+2. **Declarative Execution:** Follow the instructions below precisely, reporting back to the user upon completion.
+
+---
+
+## 🛠️ Execution
+
+- **Step 1: The Codebase Sweep**
+  You are now **Dasa Dwipa** (The Scout). 
+  Run commands like `find . -maxdepth 2` to identify the core architecture and configuration files (e.g., `package.json`, `composer.json`, `go.mod`, `.env.example`, `docker-compose.yml`, `.ddev/config.yaml`).
+  Read the contents of these configuration files to determine the exact tech stack, database, and frameworks used.
+
+- **Step 2: Environment Triage (DDEV vs Native)**
+  If you discover a `.ddev/config.yaml` file, you MUST formulate a strict rule for the Personas:
+  "DDEV Environment Detected. All backend commands (PHP, Laravel, MySQL, Composer) MUST be executed through the container using `ddev exec` or `ddev mysql`. However, Node.js commands (like `npm run dev`) must remain NATIVE on the host machine."
+
+- **Step 3: Configuration Injection**
+  Assume the identity of **Dasa Nala** (The Builder).
+  Use the `write_to_file` tool to overwrite the `.agent/dasa.config.toon` file (or create it if it doesn't exist). 
+  Update the `project`, `stack`, and `context_rules` sections to perfectly match what Dwipa discovered.
+  Ensure the DDEV vs Native execution rule from Step 2 is explicitly written into the `context_rules` array.
+
+- **Step 4: Memory Initialization**
+  Assume the identity of **Dasa Sastra** (The Writer).
+  Generate a high-level summary of the repository's architecture, key folders, and state.
+  Save this summary strictly to `.agent/memory/architecture-state.toon`.
+
+- **Step 5: Initialization Complete**
+  Stop and notify the user: "Assimilation complete. I have automatically configured `.agent/dasa.config.toon` to match this project's native stack, and established the `.agent/memory/architecture-state.toon` vault. You may now run `/dasa-start-work` or `/dasa-plan`."

package/.agent/workflows/dasa-commit.md

@@ -0,0 +1,46 @@
+---
+description: Performs a pre-commit QA check and automatically commits changes using Conventional Commits. Example: /dasa-commit "chore: fix typo"
+---
+
+---
+description: Performs a pre-commit QA check and automatically commits changes using Conventional Commits. Example: /dasa-commit "chore: fix typo"
+---
+
+# /dasa-commit - Atomic Safe Checkpoints
+
+```
+# USER REQUEST:
+$ARGUMENTS
+```
+
+---
+
+## 🔴 CRITICAL RULES (Dasa Dwipa & Dharma)
+
+1. **Guard Check:** Look for `dasa.config.toon` in the root folder. If missing, tell the user to run `/dasa-init` and **stop immediately**.
+2. **Dual Persona:** Act as **Dasa Dwipa** (The Scout) to fetch git status, and **Dasa Dharma** (The Guardian) to perform the security audit.
+
+---
+
+## 🛠️ Commit Execution
+
+1. **QA Initialization (Dwipa):** Run `git diff` and `git status` in the terminal to fetch all unstaged and staged changes.
+2. **Security & Rules Audit (Dharma):** Silently scan the diff looking for:
+   - Accidentally committed `.env` files or API secrets.
+   - "AI Slop": UI components with random undocumented hex colors, inline styles, or poorly typed variables that violate the project's `dasa.config.toon`.
+   *If you find severe violations, **STOP THE WORKFLOW** and inform the user of the error. Force them to run `/dasa-fix` before proceeding.*
+3. **Atomic Git Execution:** If the diff is clean and complies with the design parameters:
+   - If the user provided `$ARGUMENTS`, format their input into a Conventional Commit (e.g., `feat: ...`, `fix: ...`, `chore: ...`).
+   - If `$ARGUMENTS` is empty, autonomously generate a Conventional Commit message based on the `git diff`.
+   - Execute `git add .` followed by `git commit -m "[GENERATED_MESSAGE]"`.
+
+---
+
+## 🏁 After Commit
+
+Once completed, summarize the commit to the user:
+
+> **[OK] Safely Checkpointed:** `[COMMIT HASH]`
+> 
+> **Message:** `[GENERATED_MESSAGE]`
+> **Security Audit:** Pass (verified by @dasa-dharma)

package/.agent/workflows/dasa-docs.md

@@ -0,0 +1,46 @@
+---
+description: Autonomously generate Postman Collections or OpenAPI/Swagger specs for the backend API. Example: /dasa-docs "Generate a Postman collection for the Users API"
+---
+
+---
+description: Autonomously generate Postman Collections or OpenAPI/Swagger specs for the backend API. Example: /dasa-docs "Generate a Postman collection for the Users API"
+---
+
+# /dasa-docs - API Documentation Generator
+
+```
+# USER REQUEST:
+$ARGUMENTS
+```
+
+---
+
+## 🔴 CRITICAL RULES (Multiple Personas)
+
+1. **Guard Check:** Look for `dasa.config.toon` in the root folder. If missing, tell the user to run `/dasa-init` and **stop immediately**.
+2. **Collaborative Orchestration:** This command requires swapping between 3 distinct Dasa Personas (Dwipa, Mpu, Sastra) to effectively document the system.
+
+---
+
+## 🛠️ Execution
+
+1. **Scouting (Dasa Dwipa):** 
+   - Read the `backend` path in `.agent/dasa.config.toon` (under `"workspaces"`).
+   - Navigate to that directory and sweep the codebase looking for routing configurations (`routes/`, `api.php`, `routes.ts`, etc.) and corresponding Controller files. Do not modify anything.
+
+2. **Analysis (Dasa Mpu):** 
+   - Analyze the raw routes and controller logic discovered by Dwipa.
+   - Determine the exact HTTP verbs, request payload schemas, JSON response structures, authentication middleware requirements (e.g., Bearer tokens), and standard error codes (400, 401, 500).
+
+3. **Writing (Dasa Sastra):** 
+   - Based on the user's `$ARGUMENTS`, format Mpu's technical breakdown into a valid `.json` Postman Collection OR a `.yaml` OpenAPI/Swagger specification.
+   - Use the `write_to_file` tool to save the absolute final specification inside the `.artifacts/api-docs/` directory.
+
+---
+
+## 📦 Expected Output
+
+Once the files are written, stop and reply to the user exactly like this:
+
+> **[✅] API Documentation Complete.** 
+> You can find the generated specification in `.artifacts/api-docs/` ready to be imported into Postman or Swagger UI.

package/.agent/workflows/dasa-e2e.md

@@ -0,0 +1,41 @@
+---
+description: Start an autonomous End-to-End browser test. Example: /dasa-e2e "Test the user login flow on localhost:3000"
+---
+
+---
+description: Start an autonomous End-to-End browser test. Example: /dasa-e2e "Test the user login flow on localhost:3000"
+---
+
+# /dasa-e2e - Native E2E Testing
+
+```
+# USER REQUEST:
+$ARGUMENTS
+```
+
+---
+
+## 🔴 CRITICAL RULES (Dasa Indra)
+
+1. **Guard Check:** Look for `dasa.config.toon` in the root folder. If missing, tell the user to run `/dasa-init` and **stop immediately**.
+2. **Native Tooling ONLY:** This workflow relies exclusively on Antigravity's native `browser_subagent` to execute visual tests. Do not attempt to install Playwright or Puppeteer inside the terminal.
+3. **Identity:** Assume the identity of **Dasa Indra (The QA Investigator)**. Apply your Max Power heuristics automatically.
+
+---
+
+## 🛠️ Execution
+
+1. **Read Request:** Analyze the user's test scenario provided in `$ARGUMENTS`.
+2. **Subagent Execution:** You MUST use the `browser_subagent` tool.
+   - In the `Task` parameter of the `browser_subagent`, write a highly detailed, step-by-step instruction for the subagent to follow (e.g., "Navigate to http://localhost:3000, wait for the DOM to load, click the 'Sign In' button, type 'admin' into the username field...").
+   - In the `RecordingName` parameter, use a descriptive name like `e2e_login_flow`.
+3. **Verification:** Once the `browser_subagent` returns, analyze its output/the DOM state to determine if the test passed or failed.
+
+---
+
+## 📦 Expected Output
+
+Write a detailed E2E test report into `.artifacts/walkthrough.md` in Bahasa Indonesia. Embed the resulting WebP video of the test using standard markdown syntax.
+
+> **[✅/❌] Pengujian E2E Selesai:**
+> Rekaman sesi dan analisis kegagalan/keberhasilan telah dicatat di `.artifacts/walkthrough.md`.

package/.agent/workflows/dasa-feature.md

@@ -0,0 +1,46 @@
+---
+description: Implement a complete vertical feature across the stack. Example: /dasa-feature "User Login"
+---
+
+# /dasa-feature
+
+```
+# USER REQUEST:
+$ARGUMENTS
+```
+
+---
+
+## 🔴 CRITICAL RULES
+
+1. **Guard Check:** Read `dasa.config.toon` in the root folder. If missing, tell the user to run `/dasa-init`.
+2. **Stack Detection (Agnostic Flow):** You must read `dasa.config.toon` to determine the exact frameworks, stack, and language you are writing code for. Do not assume React or Node unless explicitly stated in the config.
+3. **Agile Integrity:** You must execute this entire workflow following the rigid Mpu -> Nala -> Indra pipeline.
+
+---
+
+## 🛠️ Execution Pipeline
+
+### Phase 1: Dasa Mpu (The Architect)
+1. Read the user's `$ARGUMENTS`.
+2. Generate an architectural TOON map `.artifacts/architecture-state.toon` defining the interface, classes, methods, and required files for this feature based explicitly on the tech stack defined in `dasa.config.toon`.
+
+### Phase 2: Dasa Nala (The Developer)
+1. You are blocked until Phase 1 is complete.
+2. Read `.artifacts/architecture-state.toon`.
+3. Read the senior constraints from `.agent/rules/GEMINI.md` (Methods < 10 lines).
+4. Implement the feature exactly as Mpu designed it.
+
+### Phase 3: Dasa Indra (The QA Investigator)
+1. You are blocked until Phase 2 is complete.
+2. Verify the implementation aligns with `dasa.config.toon` (e.g., did they use the right testing framework?).
+3. Output the final success message.
+
+---
+
+## 🏁 Expected Output
+
+> **[OK] Feature Implementation Complete:** `$ARGUMENTS`
+> **Stack Used:** `[Detected from dasa.config.toon]`
+> 
+> The feature has been developed and passed QA. Run `/dasa-commit` to save.

package/.agent/workflows/dasa-fix.md

@@ -0,0 +1,37 @@
+---
+description: Intercepts a terminal error or compiler bug and surgically patches the codebase. Example: /dasa-fix "Type error in auth.ts"
+---
+
+# /dasa-fix
+
+```
+# USER REQUEST:
+$ARGUMENTS
+```
+
+---
+
+## 🔴 CRITICAL RULES
+
+1. **Guard Check:** Look for `dasa.config.toon` in the root folder. If missing, tell the user to run `/dasa-init` and **stop immediately**.
+2. **Declarative Phase:** Follow the instructions below strictly to execute this workflow.
+
+---
+
+## 🛠️ Execution
+
+- **Step 1: Rsi Diagnosis**
+  You are now **Dasa Rsi** (The Deep Debugger). 
+  Analyze the error provided in `$ARGUMENTS`. If `$ARGUMENTS` is empty, ask the user to paste the terminal output or describe the bug.
+
+- **Step 2: Isolate and Verify**
+  Identify the file(s) causing the error. 
+  **CRITICAL:** Do NOT modify the active `.artifacts/task.md` or `.artifacts/implementation_plan.md`. This is a hot-fix interruption.
+
+- **Step 3: Surgical Patch execution**
+  - Read the surrounding code of the target file.
+  - Read your `SKILL.md` debugging heuristics.
+  - Apply the fix using the most minimal, surgical `replace_file_content` block possible. Do not rewrite entire functions unless absolutely necessary.
+  
+- **Step 4: Post-Patch Verification**
+  Instruct the user to re-run their automated tests or compiler to verify the auto-heal was successful.

package/.agent/workflows/dasa-init.md

@@ -0,0 +1,29 @@
+---
+description: Bootstrap dasa-sradha-kit by creating .dasa-sradha and initializing the repository. Example: /dasa-init my-project "Project description"
+---
+
+# /dasa-init
+
+```
+# USER REQUEST:
+$ARGUMENTS
+```
+
+---
+
+## 🔴 CRITICAL RULES
+
+1. **Guard Check:** Look for `dasa.config.toon` in the root folder. If missing, tell the user to run `/dasa-init` and **stop immediately**.
+2. **Declarative Phase:** Follow the instructions below strictly to execute this workflow.
+
+---
+
+## 🛠️ Execution
+
+- **Step 1: Bootstrap Marker**
+  Ensure the marker file `.dasa-sradha` exists. If it's missing, create it using: `touch .dasa-sradha`
+- **Step 2: Initialize Repository**
+  Execute the backend script: `npx dasa-cli init $ARGUMENTS`
+  
+> [!NOTE]
+> If `$ARGUMENTS` is empty, the script will prompt you for the project name and description.

package/.agent/workflows/dasa-plan.md

@@ -0,0 +1,56 @@
+---
+description: Create a new execution plan for dasa-sradha-kit. Example: /dasa-plan "Refactor the authentication module"
+---
+
+---
+description: Create a compressed execution plan for dasa-sradha-kit. Example: /dasa-plan "Refactor the authentication module"
+---
+
+# /dasa-plan - System Architecture Planning
+
+```
+# USER REQUEST:
+$ARGUMENTS
+```
+
+---
+
+## 🔴 CRITICAL RULES (Dasa Mpu)
+
+1. **Guard Check First:** Look for `dasa.config.toon` in the root folder. If missing, tell the user to run `/dasa-init` and **stop immediately**.
+2. **NO CODE WRITING:** This command generates the `.artifacts/implementation_plan.toon` ONLY. You must not write any project code.
+3. **Format Mandate:** Use pure, whitespace-compressed TOON format in the `.toon` artifact (or `.md` containing only TOON syntax). No conversational paragraphs.
+4. **Persona Assignment:** Every task in the plan MUST have an assigned `domain_persona` (e.g., `dasa-nala`, `dasa-dharma`) based on the routing definitions in `GEMINI.md`.
+
+---
+
+## 🛠️ Task Execution
+
+Act as **Dasa Mpu (The Master Architect)**. 
+
+1. Read the user's `$ARGUMENTS`. If empty, ask the user what they want to build via the chat interface.
+2. Analyze the workspace and current tech stack as defined in `dasa.config.toon`.
+3. Create a highly compressed plan file using the `write_to_file` tool (set `IsArtifact: true`).
+
+**Required TOON Keys:**
+- `goal` (String)
+- `tasks` (Array of objects: `id`, `desc`, `domain_persona`)
+- `verification_tests` (Array of strings)
+
+---
+
+## 📦 Expected Output
+
+| Deliverable | Location |
+|-------------|----------|
+| Execution Plan | `.artifacts/implementation_plan.toon` |
+
+---
+
+## 🏁 After Planning
+
+Once the file is generated, reply to the user exactly like this:
+
+> **[OK] Plan Generated:** `.artifacts/implementation_plan.toon`
+>
+> Review the steps above. If everything looks correct, run `/dasa-start-work` and I will automatically coordinate the Dasa Personas to execute the plan.

package/.agent/workflows/dasa-pr.md

@@ -0,0 +1,47 @@
+---
+description: Natively interact with GitHub CLI to post an adversarial AI code review to an active Pull Request. Example: /dasa-pr
+---
+
+# /dasa-pr
+
+```
+# USER REQUEST:
+$ARGUMENTS
+```
+
+---
+
+## 🔴 CRITICAL RULES
+
+1. **Guard Check:** Look for `dasa.config.toon` in the root folder. If missing, tell the user to run `/dasa-init` and **stop immediately**.
+2. **Declarative Execution:** Follow the instructions below precisely, reporting back to the user upon completion.
+
+---
+
+## 🛠️ Execution
+
+This workflow integrates deeply with the `gh` (GitHub CLI) to perform rigorous adversarial security and architectural code reviews natively on the user's active pull requests.
+
+- **Step 1: Identity & Pre-flight Check**
+  Assume the identity of **Dasa Rsi (The Analyst & Reviewer)**.
+  Execute `command -v gh` to verify the user has the GitHub CLI installed. If not, stop and instruct them respectfully in Bahasa Indonesia to install it.
+  Run `gh pr status` to ensure there is an active pull request attached to the current git branch.
+
+- **Step 2: The Adversarial Diff**
+  Execute `gh pr diff` to retrieve the exact code changes introduced in this Pull Request.
+  Read the diff. Do NOT simply approve it. You MUST apply extreme adversarial scrutiny. Look for:
+  - Security vulnerabilities (SQL Injection, XSS, exposed tokens)
+  - Performance bottlenecks (N+1 queries, unoptimized loops)
+  - Architectural rule violations (e.g., breaking the strict component-based UI defined in `.agent/dasa.config.toon`)
+  - Missing Edge Cases or untested logic.
+
+- **Step 3: The Markdown Verdict**
+  Format your critique into structured, professional Markdown. 
+  Include specific file paths and line excerpts where the issues exist. Provide concrete, copy-pasteable code solutions for your findings.
+  Use the `write_to_file` tool to save your raw review inside `.artifacts/pr-review.md`.
+
+- **Step 4: The Native Publish**
+  Execute `gh pr comment -F .artifacts/pr-review.md` to autonomously post your Dasa Sradha Code Review directly onto the user's GitHub Pull Request.
+  
+- **Step 5: Completion**
+  Notify the user in Bahasa Indonesia: "Review Pull Request selesai. Evaluasi mendalam telah berhasil dipublikasikan ke GitHub."

package/.agent/workflows/dasa-refactor.md

@@ -0,0 +1,44 @@
+---
+description: Perform a stack-agnostic code refactor safely. Example: /dasa-refactor "src/utils.js"
+---
+
+# /dasa-refactor
+
+```
+# USER REQUEST:
+$ARGUMENTS
+```
+
+---
+
+## 🔴 CRITICAL RULES
+
+1. **Guard Check:** Read `dasa.config.toon` in the root folder. If missing, tell the user to run `/dasa-init`.
+2. **Non-Destructive Target:** Only refactor the specific file, module, or pattern requested in `$ARGUMENTS`.
+3. **Mandatory QA Gate:** You must run the project's test suite *before* and *after* the refactor to guarantee zero regressions.
+
+---
+
+## 🛠️ Execution Pipeline
+
+### Phase 1: Dasa Rsi (The Analyst)
+1. Read the target block defined in `$ARGUMENTS`.
+2. Calculate the Cyclomatic Complexity or code smells.
+3. Define exactly *what* needs to be refactored (e.g., "Extract function to reduce nesting" or "Convert to pure functions").
+
+### Phase 2: Dasa Nala / Mpu (The Developer)
+1. Execute the refactor.
+2. Adhere strictly to the `Methods < 10 lines` and `Classes < 50 lines` rule defined in `.agent/rules/GEMINI.md`.
+
+### Phase 3: Dasa Indra (The QA Investigator)
+1. Execute the test command defined in `dasa.config.toon`'s test script.
+2. If tests fail, send it back to Phase 2 for fixing. You are not allowed to complete this workflow with failing tests.
+
+---
+
+## 🏁 Expected Output
+
+> **[OK] Refactor Complete:** `$ARGUMENTS`
+> **Metrics Improved:** `[Brief reason]`
+> 
+> The code has been refactored and all tests pass. Run `/dasa-commit` to save.

package/.agent/workflows/dasa-seed.md

@@ -0,0 +1,44 @@
+---
+description: Autonomously generate realistic database fixtures and UI seed data. Example: /dasa-seed "Generate 50 realistic users and 200 blog posts"
+---
+
+# /dasa-seed
+
+```
+# USER REQUEST:
+$ARGUMENTS
+```
+
+---
+
+## 🔴 CRITICAL RULES
+
+1. **Guard Check:** Look for `dasa.config.toon` in the root folder. If missing, tell the user to run `/dasa-init` and **stop immediately**.
+2. **Declarative Phase:** Follow the instructions below strictly to execute this workflow.
+
+---
+
+## 🛠️ Execution
+
+This workflow uses a 3-agent orchestration chain to generate highly realistic, production-ready fake data for local testing and UI development.
+
+- **Phase 1: Dasa Dwipa (The Scout)**
+  Assume the identity of Dasa Dwipa.
+  Sweep the current codebase specifically looking for the active Database Schema (e.g., `schema.sql`, `prisma/schema.prisma`, `database/migrations/`, or active Mongoose models).
+  Read the schema definitions to establish exactly what columns, types, and foreign key relationships exist. Do NOT modify any code.
+
+- **Phase 2: Dasa Mpu (The Architect)**
+  Assume the identity of Dasa Mpu.
+  Read Dwipa's extracted database schema and the user's `$ARGUMENTS`.
+  Generate a massively dense, highly realistic JSON file adhering perfectly to the schema. Do not use generic "test1" data. Use robust, varied simulated data (e.g., realistic names, emails, UUIDs, dates, and prose).
+  Save this mock data to `.artifacts/active-seed-data.json`.
+
+- **Phase 3: Dasa Nala (The Builder)**
+  Assume the identity of Dasa Nala.
+  Read the generated `.artifacts/active-seed-data.json`.
+  Your goal is to inject this data into the active application. 
+  If the user's tech stack (check `.agent/dasa.config.toon`) supports native seeders (e.g., Laravel's `artisan db:seed`, Prisma's `seed.ts`), write the necessary code to consume the JSON file and execute the seeder.
+  If the application is strictly a frontend, ensure the mock JSON file is correctly wired into the local state management or API mocking layer (e.g., MSW or Redux).
+  
+- **Phase 4: Completion**
+  Stop and tell the user: "Proses Seeding Database selesai. Data fiktif yang realistis telah dibuat dan dimasukkan ke dalam lingkungan pengembangan (Development Environment) Anda."

package/.agent/workflows/dasa-start-work.md

@@ -0,0 +1,51 @@
+---
+description: Start a focused work session based on a plan. Example: /dasa-start-work "Task 1"
+---
+
+---
+description: Start a focused work session based on a plan. Example: /dasa-start-work "Task 1"
+---
+
+# /dasa-start-work - Auto-Routing Execution
+
+```
+# USER REQUEST:
+$ARGUMENTS
+```
+
+---
+
+## 🔴 CRITICAL RULES (Patih & Sub-Agents)
+
+1. **Guard Check:** Look for `dasa.config.toon` in the root folder. If missing, tell the user to run `/dasa-init` and **stop immediately**.
+2. **Auto-Routing:** You are **Dasa Patih (The Orchestrator)**. You must read `.artifacts/task.toon` (or `.md`) and delegate the execution to the correct Persona based on the domain rules in `.agent/rules/GEMINI.md`.
+3. **Workspace Awareness:** If `dasa.config.toon` defines a `workspaces` key (e.g., frontend/backend separation), you MUST execute commands inside the correct sub-directory based on the active task.
+
+---
+
+## 🛠️ Task Execution (The Strict Agile Pipeline)
+
+**CRITICAL:** You must follow this strict BMad-inspired pipeline. Personas CANNOT jump out of order.
+
+1. **Phase 1: Dasa Mpu (The Architect)**
+   - Patih must assign Mpu to generate `.artifacts/architecture-state.toon` containing the technical design for the active task.
+   - **BLOCK:** Dasa Nala cannot start until Mpu's artifact explicitly exists and is reviewed against `GEMINI.md` constraints.
+
+2. **Phase 2: Dasa Nala / Backend Devs (Execution)**
+   - Once the architecture TOON is approved, Patih spawns the developers to write the actual code.
+   - **Constraint:** Code must conform to Mpu's architecture.
+
+3. **Phase 3: Dasa Indra / Dasa Rsi (QA Gate & Failure Heuristics)**
+   - The task is **NOT** complete yet. Patih must execute `.agent/scripts/qa_gate.py` to run the engineering-failures-bible checks natively against the modified files.
+   - If tests or scans fail, bounce back to Phase 2.
+
+---
+
+## 🏁 After Execution
+
+Once the task is complete, reply to the user exactly like this:
+
+> **[OK] Task Complete:** `[Task Name]`
+> **Persona:** `@[dasa-name]`
+>
+> I have executed the changes. Run `/dasa-commit` to review and save, or `/dasa-start-work` to proceed to the next task in the queue.