[
  {
    "id": "445fc84e-da39-4c89-a4b7-8a8715534a4a",
    "name": "micro unit test",
    "usage": "HTML,JavaScript",
    "content": "The micro unit test system is a highly efficient, **zero-dependency testing architecture**. \n### The 4 Pillars of the Micro Unit Test System\n\n1. **The URL-Triggered Injector (`?test=run`)**\nThe main HTML file checks `window.location.search` for the word `test=`. If it's missing, the app runs normally with zero performance overhead. If it is present, the app dynamically creates a `<script>` tag and injects the external `..._tests.js` file.\n2. **The `__TEST_API__` Bridge**\nTo test private internal functions (like `formatXML` or `syncDataUrl`) without polluting the global window object for regular users, the app conditionally creates a `window.__TEST_API__` object *only* when test mode is activated. The test script uses this bridge to access internal logic.\n3. **Vanilla JS Asynchronous Assertions**\nInstead of using bulky external libraries like Jest or Mocha, the test file defines its own lightweight `assert()` and `assertTrue()` functions. Because it operates directly in the browser, it uses `async/await` and DOM polling (`setTimeout` loops) to wait for visual elements (like canvas rendering) to finish before asserting.\n4. **The UI Toast \"Enforcer\"**\nInstead of just logging to the hidden developer console, the test suite hooks directly into the application's native UI (the `#status-toast`). It uses a `setInterval` \"enforcer\" to aggressively keep the final test score visible on the screen, overriding any internal app timeouts.\n\n---\n\n### How to Request This in the Future\n\nWhenever you create a new application and want me to generate this exact testing framework for it, you can copy and paste this block into your prompt:\n\n> **Add the Vanilla Micro Unit Test System.**\n> Please implement the URL-triggered testing architecture for this application:\n> 1. **The Bridge:** Inside the main app's IIFE, check if the URL contains `?test=`. If true, expose necessary internal functions to a `window.__TEST_API__` object.\n> 2. **The Injector:** Dynamically load a separate `{app_name}_tests.js` script. If the URL contains `?test=run`, automatically execute `window.__runTests()`.\n> 3. **The Test Suite (Separate File):** Generate the companion Javascript test file. Include lightweight vanilla `assert()` and `assertTrue()` functions. Write tests that validate both internal logic (via the API bridge) and DOM UI changes.\n> 4. **Visual Output:** Hook into the app's native UI (e.g., a toast notification) to display the final test pass/fail results. Use an interval enforcer to ensure the final score toast stays visible for 7 seconds without being overwritten by the app's internal timeouts.\n> \n>\n\n---\n\n\n## 📋 **Generic Micro Unit Test Suite Specification**  \n*Use this template to request the same testing infrastructure for **any** web application.*\n\n---\n\n### **Goal**  \nGenerate a self‑contained, offline micro unit test suite that validates critical functionality of a web application, automatically resets the app to its initial state after tests, and displays a prominent final result toast.\n\n---\n\n### **Core Infrastructure (Required for All Apps)**\n\n1. **Test API Exposure**  \n   - The host application must expose internal functions via a global object (e.g., `window.__TEST_API__`) when a query parameter (e.g., `?test=`) is present.  \n   - Exposed functions should include all methods necessary for testing: core business logic, data transformation, UI update functions, etc.\n\n2. **Assertion Helpers**  \n   - `assert(name, actual, expected, message?)` – strict equality.  \n   - `assertTrue(name, condition, message?)` – boolean check.  \n   - `assertStartsWith(name, str, prefix)` – string prefix validation.\n\n3. **Asynchronous Test Loading**  \n   - A generic `loadTestData(inputData, waitForCondition)` function that returns a `Promise`.  \n   - Resolves when a specified condition (e.g., UI element appears, data loaded, no error) is met.  \n   - Rejects after a configurable timeout (e.g., 6 seconds).\n\n4. **Reset to Initial State**  \n   - A `resetAppToInitialState()` function that:  \n     - Restores default input values (text fields, checkboxes, dropdowns, etc.).  \n     - Reloads the default/initial data into the UI.  \n     - Clears any error messages or transient states.  \n     - Suppresses or removes any lingering application toasts, alerts, or notifications that appear after reset.  \n   - The reset must run **after** all tests complete, regardless of pass/fail.\n\n5. **Final Toast Behaviour**  \n   - After reset, display a **centered**, **visually enlarged** toast (2× the original toast size).  \n   - Duration: **≥ 7 seconds**.  \n   - The toast shows: `🧪 Tests: X passed, Y failed. App reset.`  \n   - After it fades, restore the original toast position, size, and padding.\n\n6. **Toast/Notification Suppression Watchdog**  \n   - Since some app timeouts (e.g., “operation completed” messages) may fire 2–3 seconds after reset, a watchdog interval must scan for and remove any toast containing a specific identifiable string (e.g., a known transient message) for the first 3 seconds after reset.\n\n7. **Execution & Output**  \n   - Tests run automatically when the URL contains `?test=run` (or manually via `window.__runTests()`).  \n   - Results are logged to the console with coloured PASS/FAIL messages.  \n   - A summary is printed, and the final enlarged toast is shown.\n\n---\n\n### **Test Coverage (Adapt to Your App)**\n\nWrite tests that validate:\n\n- **Core functionality** – The primary feature the app provides (e.g., data conversion, calculation, rendering).  \n- **Edge cases** – Empty inputs, invalid data, missing required attributes, extreme values.  \n- **UI state management** – Input fields reset correctly, error messages appear when expected, disabled/enabled states.  \n- **Asynchronous behaviour** – Loading indicators, delayed operations, timeouts.  \n- **Fallback / defensive logic** – Default values when data is malformed, fallback UI when feature unavailable.  \n- **Output generation** – If the app produces files or data URLs, verify headers, signatures, or structure.  \n- **Event handling** – Drag & drop, file upload, button clicks, keyboard shortcuts.\n\n---\n\n### **Example Generic Prompt to Use**\n\n> *“Add the same micro unit test suite as described in the generic specification. Expose `window.__TEST_API__` with the necessary internal functions, implement all assertions, async load tests, reset functionality with toast suppression, and display a large centered final toast for 7 seconds. Adapt the test coverage to this app’s core features, edge cases, and UI state.”*\n\n---\n\n### **Why This Works for Any App**\n\n- **No Hardcoded Domains** – The spec talks about “core functionality,” “UI state,” “output generation” without mentioning SVG, PNG, or BMP.  \n- **Configurable** – The test author decides which functions to expose and which conditions to wait for.  \n- **Clean Reset** – Works for any form‑based or interactive app.  \n- **User‑Friendly** – The large toast and console logs provide clear pass/fail feedback without interfering with normal use.\n",
    "active": false
  },
  {
    "id": "691f5278-f739-4f05-8871-f8949008abcb",
    "name": "Dual auto theme",
    "usage": "HTML,JavaScript",
    "content": "Implement an isolated Light/Dark theme mechanism inside the `#name-app` container using CSS variables.\n1. **CSS Variables**: Define custom properties for background, borders, text-main, and inputs on `#name-app` (default light) and override them under `#name-app.theme-dark`.\n2. **Standalone Scoping**: Map body background variables under `body.theme-dark` and `body:not(.theme-dark)`. Apply smooth `transition: background-color 0.3s ease` to all themeable properties.\n3. **JS Theme Controller**: Within an IIFE, declare a configurable constant `const APP_THEME = 'auto';` (supporting `'auto'`, `'dark'`, `'light'`). If `'auto'`, bind a change listener to the system preference `window.matchMedia('(prefers-color-scheme: dark)')` and toggle `.theme-dark` on the body and app container accordingly.",
    "active": false
  },
  {
    "id": "e3e5c639-49a4-4023-9d0a-eb69aa103ebe",
    "name": "SAP Embed developer profile",
    "usage": "HTML,JavaScript",
    "content": "⚙️ Custom Instructions: SAP+Embedable Developer Profile\n\nI. Application Architecture & CSS Scoping\n  - Offline First: When an HTML+JS page is created, it must work completely offline unless explicitly stated otherwise. No external CDNs or APIs.\n  - Embeddability: The page must operate flawlessly as both a standalone document and as an embedded component within a host page.\n  - Containerization: Place the entire application inside a distinct #name-app wrapper container.\n  - CSS Scoping: Leave in the html, body CSS block only what is strictly necessary to run the page standalone (e.g., background color, base font). All layout and specific styling must be scoped strictly to the #name-app container.\n  - JavaScript Isolation: Wrap all core JavaScript logic within an Immediately Invoked Function Expression (IIFE) to prevent global scope pollution when embedded.\n\nII. Versioning Rules ( vMajor.Minor.Fix )\n  - Strict Tracking: Each page must have a visible version number (usually in the header/footer), and every single change must reflect in that version.\n  - Fix ( .0 ): The fix number is reserved exclusively for the user's manual changes. If the AI provides an updated file, it must always set the fix digit to 0 for the next version.\n  - Minor ( .X. ): Increment the minor version automatically on any updates, bug fixes, or feature additions provided by the AI.\n  - Major ( X. ): Increment the major version only when explicitly commanded by the user.\n\nIII. Code Patching Methodology\n  - No Diffs: Do not use standard unified diffs (diff -u) for file updates. They fail due to LLM line-counting limitations and chat UI whitespace stripping.\n  - Python Target-and-Replace: Generate a Python script using str.replace() to apply code updates.\n  - Raw Triple Quotes: Always use Python's raw triple-quoted strings (r\"\"\"...\"\"\") for the search and replace blocks to ensure exact string matching without escape character conflicts.\n\nIV. Micro Unit Testing Architecture\nWhen instructed to build tests, implement the Vanilla Micro Unit Test System :\n1. The Trigger: Check window.location.search for ?test=run. The test suite only loads if this is present.\n2. The Bridge: Conditionally expose a window.TEST_API object inside the IIFE to allow external test scripts to interact with internal functions.\n3. Vanilla Assertions: Use lightweight, dependency-free asynchronous assertions (assert, assertTrue) inside a separate dynamically injected {app_name}_tests.js file.\n4. UI Testing: Use native Browser Event Dispatching (MouseEvent, KeyboardEvent) followed by timers (e.g., 250ms) to trigger debounced UI functions safely, rather than calling raw internal handlers directly (which causes undefined event crashes).\n5. The UI Enforcer: Hook into the app's native UI toast notification to display final test results. Use a setInterval watchdog to aggressively keep the final score visible for at least 7 seconds, preventing the main app's internal timeouts from overwriting it.\n\nV. Data Preservation & Black Boxing\n  - Long Data URIs: To protect long, complex data:image/svg+xml strings from browser decoding errors or AI corruption, wrap the entire HTML element containing the data inside explicit comments: and .\n  - Massive Datasets: When dealing with large arrays or dictionaries (e.g., BIP-39 lists), mock them as a single-line string constant (e.g., const DATA_RAW = \"...\").\n  - AI-SKIP Markers: If the user provides a file with [DO NOT MODIFY...] or [AI-SKIP] comments wrapping a large block of text, treat that block as a black box. Do not read it, modify it, or include it in Python patch scripts.\n\nVI. File Delivery & Markdown Handling\n  - The HTML Downloader: If the user requests a formatted file (like a Markdown manual, JSON, or CSV), do not output it as plain text. Instead, generate a Standalone HTML Downloader utility.\n  - Formatting Protection: Store the raw, fully formatted content inside a hidden <textarea> within the utility to preserve all brackets, line breaks, and spacing.\n  - Blob Export: Include a styled UI with a 'Download' button that uses JavaScript to create a Blob and trigger a local file download directly to the user's machine.\n \n",
    "active": false
  },
  {
    "id": "16b506dd-b709-4c50-8e5e-7eae73090e5e",
    "name": "favicon.ico for provided code prompt",
    "usage": "SVG, HTML",
    "content": "Task: Analyze the HTML/CSS/JS application provided  to understand its visual theme and purpose. \n\nInstructions:\n1. Conceptualize & Style: Design a simple, scalable vector icon (viewBox \"0 0 100 100\") that represents the tool, utilizing the primary accent colors extracted from the provided CSS.\n2. Step 1 (Raw Output): First, output the clean, well-formatted raw <svg> block inside a standard markdown code block. \n3. Step 2 (URI Conversion): Directly below that, manually convert that specific SVG code into a fully percent-encoded (URL-encoded) data:image/svg+xml string. Ensure all spaces (%20), double quotes (%22), hashes (%23), slashes (%2F), and angle brackets (%3C, %3E) are completely encoded.\n4. Final Output Format: Conclude your response by placing the final, embeddable HTML string on its own line at the very bottom: \n<link rel=\"icon\" type=\"image/svg+xml\" href=\"data:image/svg+xml,...\">\n",
    "active": false
  }
]