diff --git a/documentation/docs/design-2-code/Guides/design-conversion-basics.md b/documentation/docs/design-2-code/Guides/design-conversion-basics.md
deleted file mode 100644
index 9badd0ca..00000000
--- a/documentation/docs/design-2-code/Guides/design-conversion-basics.md
+++ /dev/null
@@ -1,83 +0,0 @@
----
-sidebar_position: 1
-sidebar_label: Design Conversion Basics
-title: "Design Conversion Basics"
-description: "Explore a pragmatic approach to transforming designs into functional websites with our guide on design-to-code conversion. Learn essential principles, tools, and best practices for a seamless transition from visual concepts to responsive, accessible web applications. Perfect for developers and designers seeking a straightforward, effective strategy for turning creative visions into technical realities."
-
-keywords:
-  [
-    bitloops design conversion,
-    figma-to-react guide,
-    frontend design conversion,
-    responsive UI development,
-    UI-to-code automation,
-    design conversion basics,
-    professional frontend tools,
-    design optimization for coding,
-    efficient UI coding process,
-    Design-2-Code,
-    Responsive code generation,
-    Adaptive design implementation,
-    Code integration guide,
-  ]
----
-
-Design-to-code conversion is the process of transforming visual designs into functional websites or applications. It bridges the gap between creativity and technology, enabling developers to turn a designer’s vision into interactive, user-friendly digital products. Mastering this process is essential for building high-quality, responsive, and scalable user interfaces.  
-
-This guide outlines the key principles, tools, and steps for effective design conversion, helping you create well-structured, maintainable codebases.  
-
-### Introduction  
-
-Design-to-code conversion requires a blend of technical expertise and close collaboration between designers and developers. Successful projects depend on clear communication, shared goals, and an understanding of the project’s audience and requirements.  
-
-### Understanding the synergy between design and development  
-
-- **Collaboration is key:** Effective communication ensures alignment on objectives, reducing the risk of inconsistencies.  
-- **Shared understanding:** Both teams should have clarity on project goals, user needs, and functionality to achieve the best results.  
-
-### Principles of effective design conversion  
-
-1. **Clarity in designs:** Ensure designs include detailed guidelines for typography, spacing, colors, and component states to minimize ambiguity.  
-2. **Responsive design:** Designs should adapt seamlessly to different screen sizes and orientations to provide a consistent user experience.  
-3. **Accessibility standards:** Follow accessibility guidelines (e.g., WCAG) to ensure inclusivity and usability for all users.  
-
-### Tools and technologies  
-
-- **Languages:** Proficiency in HTML, CSS, and JavaScript is foundational for frontend development.  
-- **Frameworks:** Use frameworks like React, Angular, or Vue to streamline development and enhance scalability.  
-- **Design tools:** Familiarity with tools like Figma, Sketch, or Adobe XD enables effective collaboration with designers.  
-- **IDEs:** Leverage Integrated Development Environments (e.g., VS Code) for efficient coding and debugging.  
-
-### The design-to-code conversion process  
-
-1. **Understand the design:** Analyze the design thoroughly, identifying components, styles, and interactions.  
-2. **Break it into components:** Divide the design into smaller, reusable components or sections.  
-3. **Write semantic HTML:** Structure content with clean, accessible HTML for better maintainability.  
-4. **Style with CSS:** Apply styles to match the design’s typography, colors, and layout.  
-5. **Add interactivity:** Use JavaScript to implement dynamic elements, animations, or user interactions.  
-6. **Test and validate:**  
-   - **Responsiveness:** Verify layouts on multiple devices and screen sizes.  
-   - **Functionality:** Test interactive elements like buttons, forms, and links.  
-   - **Performance:** Optimize for fast load times and smooth operation.  
-
-### Optimizing performance  
-
-- **Minify code:** Reduce the size of HTML, CSS, and JavaScript files to improve load times.  
-- **Compress images:** Optimize image assets for the web to balance quality and performance.  
-- **Analyze metrics:** Use tools like Lighthouse or WebPageTest to measure and improve performance.  
-
-### Maintenance and updates  
-
-- **Version control:** Use Git to manage changes and collaborate effectively with your team.  
-- **Regular updates:** Keep your codebase aligned with evolving standards and frameworks.  
-- **Comprehensive documentation:** Document your processes and codebase for easier handovers and future updates.  
-
-### Conclusion  
-
-Design-to-code conversion is a critical aspect of frontend development that combines creativity, technical skills, and collaboration. By following these principles and leveraging the right tools, you can create high-quality, responsive, and maintainable digital products.  
-
----
-
-### How Bitloops Helps  
-
-Bitloops simplifies the design-to-code conversion process by automating repetitive tasks, generating clean code, and ensuring responsiveness and consistency. It accelerates your workflow, allowing you to focus on building sophisticated, user-friendly interfaces.  
\ No newline at end of file
diff --git a/documentation/docs/design-2-code/Guides/frontend-best-practices.md b/documentation/docs/design-2-code/Guides/frontend-best-practices.md
deleted file mode 100644
index 22183bdd..00000000
--- a/documentation/docs/design-2-code/Guides/frontend-best-practices.md
+++ /dev/null
@@ -1,100 +0,0 @@
----
-sidebar_position: 3
-sidebar_label: Frontend Best Practices
-title: "Frontend Best Practices"
-description: "Maximize your productivity and efficiency with Bitloops by exploring 'Best Practices'. This comprehensive guide offers tips and tricks for optimizing your design-to-code conversion process. From preparing well-structured design files to fine-tuning the settings within Bitloops, learn how to leverage the platform's full potential. Stay updated with the latest features, engage with the community, and ensure your development practices align with industry standards."
-
-keywords:
-  [
-    Bitloops, 
-    Design-2-Code,
-    Design file preparation,
-    AI design interpretation,
-    Code conversion process,
-    Responsive code generation,
-    Adaptive design implementation,
-    Code integration guide,
-    Bitloops user interface,
-    Design element mapping,
-    Component selection in Bitloops,
-    Code output optimization,
-    Project integration tips,
-    Code review best practices,
-    Bitloops software updates,
-    Performance tuning Bitloops,
-    Community engagement Bitloops,
-    Bitloops support resources,
-    Developer collaboration tools,
-    Quality assurance coding,
-    Bitloops troubleshooting guide,
-    Scalable code solutions,
-    Design consistency checks,
-    User experience enhancement,
-    Efficient workflow Bitloops,
-    Code maintainability standards,
-    Bitloops training materials,
-  ]
----
-
-Transforming visual designs into functional websites or applications is a critical step in web development. To ensure efficiency, consistency, and high-quality outcomes, it’s essential to follow established best practices. This guide outlines strategies to optimize the design-to-code process and create scalable, maintainable frontend codebases.  
-
-### Collaboration Between Designers and Developers  
-- **Effective communication:** Use tools like Slack, Jira, or Trello to coordinate workflows, track progress, and align goals.  
-- **Regular feedback:** Schedule consistent feedback sessions to address issues early and ensure mutual understanding of design and functionality requirements.  
-
-### Understanding and Preparing the Design  
-- **Thorough review:** Examine designs carefully to identify component structures, styles, and interactive elements.  
-- **Logical organization:** Ensure all assets are properly named, grouped logically, and complete to minimize development delays.  
-
-### Responsive and Adaptive Design  
-Responsive design is essential for delivering consistent experiences across devices:  
-- **Fluid grids:** Use percentage-based widths to create layouts that adapt to various screen sizes.  
-- **Flexible images:** Ensure images scale correctly within their containers without distortion.  
-- **Media queries:** Apply CSS media queries to tailor styles for specific device breakpoints.  
-
-### Accessibility and Inclusivity  
-Building accessible applications ensures usability for all, including users with disabilities:  
-- **Semantic HTML:** Use HTML5 elements like `<header>`, `<footer>`, and `<article>` for clear structure.  
-- **Keyboard navigation:** Ensure all interactive elements can be accessed via keyboard.  
-- **ARIA roles:** Add attributes like `aria-label` to improve support for assistive technologies.  
-
-### Code Quality and Standards  
-Maintain a clean and consistent codebase by adhering to these principles:  
-- **Consistent naming conventions:** Follow established standards like BEM for CSS or Airbnb’s JavaScript guide.  
-- **Documentation:** Add comments to explain complex logic and maintain clear documentation for future developers.  
-- **Code reviews:** Conduct regular reviews to ensure adherence to standards and catch potential issues early.  
-
-### Component-Based Architecture  
-Breaking your UI into reusable components enhances scalability and efficiency:  
-- **Small, focused components:** Each component should handle one specific responsibility.  
-- **Reusable structures:** Design components for use across multiple features or pages.  
-- **Organized structure:** Group components by feature or functionality for better navigation and maintainability.  
-
-### CSS Preprocessing and Frameworks  
-- **Preprocessors:** Use tools like SASS or LESS for advanced styling capabilities and improved maintainability.  
-- **Frameworks:** Leverage frameworks like TailwindCSS or Bootstrap for rapid prototyping and consistent design implementation.  
-
-### Performance Optimization  
-Optimized performance is critical for user satisfaction:  
-- **Optimize assets:** Compress images and minify CSS, JavaScript, and HTML files.  
-- **Lazy loading:** Load images and components only when they are needed.  
-- **Performance monitoring:** Use tools like Google PageSpeed Insights or Lighthouse to identify and fix bottlenecks.  
-
-### Version Control and Documentation  
-- **Version control:** Use Git to track changes, collaborate effectively, and maintain a reliable code history.  
-- **Comprehensive documentation:** Document your codebase and workflows to simplify onboarding and future development.  
-
-### Testing and Quality Assurance  
-Thorough testing ensures reliability and consistency:  
-- **Cross-browser testing:** Verify compatibility across major browsers.  
-- **Responsiveness testing:** Test layouts and components on various devices and screen sizes.  
-- **Automated testing:** Use tools like Jest, Cypress, or Playwright to streamline testing and reduce manual effort.  
-
-### Conclusion  
-By adhering to these best practices, you can build frontend codebases that are scalable, maintainable, and performant. These principles ensure a smooth transition from design to code, reduce errors, and enhance collaboration between designers and developers.  
-
----
-
-### How Bitloops Helps  
-
-Bitloops supports these best practices by automating repetitive tasks, generating clean code, and integrating seamlessly with modern development workflows. By leveraging Bitloops, you can focus on creating exceptional user experiences while maintaining high standards for your codebase.  
diff --git a/documentation/docs/design-2-code/Guides/frontend-testing.md b/documentation/docs/design-2-code/Guides/frontend-testing.md
deleted file mode 100644
index f22ba16f..00000000
--- a/documentation/docs/design-2-code/Guides/frontend-testing.md
+++ /dev/null
@@ -1,98 +0,0 @@
----
-sidebar_position: 4
-sidebar_label: Frontend Testing
-title: "Frontend Testing"
-description: "Learn how Bitloops Frontend Copilot automates frontend testing with built-in property and responsiveness tests to ensure high-quality components."
-keywords:
-  [
-    frontend testing guide,
-    component testing best practices,
-    responsive UI tests,
-    property testing automation,
-    UI testing overview,
-    design-to-code testing,
-    automated UI validation,
-    frontend development tests,
-    Bitloops testing features,
-    Storybook tests,
-  ]
----
-
-Frontend testing is crucial to ensure that components behave as expected, look consistent, and adapt seamlessly across devices. By validating functionality and visual fidelity early in the development process, testing helps prevent bugs, maintain quality, and streamline workflows.  
-
-This guide explores the purpose of frontend testing, the types of tests commonly performed, and best practices for integrating testing into your development process.  
-
-### What Is Frontend Testing?  
-
-Frontend testing involves verifying that components:  
-- **Maintain visual fidelity:** Ensure elements appear as designed.  
-- **Respond to interactions:** Test user actions like clicks, hovers, and input changes.  
-- **Adapt to different devices:** Validate responsiveness across various screen sizes.  
-
-Testing is an essential part of frontend development, helping to catch bugs early, reduce manual QA efforts, and ensure a polished user experience.  
-
-### Types of Frontend Tests  
-
-To ensure comprehensive coverage, frontend testing typically involves the following types:  
-
-#### 1. Property tests  
-Property tests validate that components match design specifications and function as intended:  
-
-- **Typography:** Ensure correct font size, type, weight, and color.  
-- **Dimensions:** Validate width, height, margins, and padding for precise layout.  
-- **Alignment:** Confirm proper positioning of elements within the layout.  
-- **Visibility:** Check that no elements are hidden, clipped, or overlapping.  
-
-*Example:* A property test might flag an issue where a button's font size doesn’t match the design specs.  
-
-#### 2. Responsiveness tests  
-Responsiveness tests ensure that components adjust correctly to different devices and screen sizes:  
-
-- **Layout adaptability:** Validate that elements rearrange and resize appropriately for different breakpoints.  
-- **Content scaling:** Prevent issues like clipping, stretching, or overflow.  
-- **Device previews:** Simulate how components appear on devices like mobile phones, tablets, and desktops.  
-
-*Example:* A responsiveness test might highlight that an image overflows its container on smaller screens.  
-
-#### 3. Interaction tests  
-Interaction tests simulate user actions to verify that components behave as expected:  
-
-- **Button clicks:** Ensure proper functionality when buttons are clicked.  
-- **Form submissions:** Validate input handling and submission logic.  
-- **Hover states:** Confirm visual changes on hover or focus.  
-
-### How to Run Frontend Tests  
-
-Most frontend testing workflows involve a combination of automated and manual testing:  
-
-1. **Set up a testing framework:** Use tools like Jest, React Testing Library, or Cypress to automate tests.  
-2. **Run tests locally:** Execute tests during development to catch errors early.  
-3. **Integrate with CI/CD pipelines:** Automate testing during deployment to maintain quality across updates.  
-
-### Interpreting Test Results  
-
-#### ✅ Passing tests  
-- A passing test indicates that the component meets all required criteria and is ready for deployment.  
-
-#### ❌ Failed tests  
-- Failed tests reveal discrepancies in design or functionality. Address issues by:  
-  1. Reviewing the failed properties or states.  
-  2. Updating the component code to fix the discrepancies.  
-  3. Re-running the tests to ensure the issues are resolved.  
-
-### Best Practices for Frontend Testing  
-
-- **Automate where possible:** Use testing tools to reduce manual effort and ensure consistent coverage.  
-- **Write reusable test cases:** Create modular test cases that can be applied across multiple components.  
-- **Test early and often:** Incorporate testing into your development workflow to catch issues early.  
-- **Document edge cases:** Identify and document uncommon scenarios to ensure comprehensive coverage.  
-
-### Summary  
-
-Frontend testing is an indispensable step in building reliable and high-quality user interfaces. By implementing property, responsiveness, and interaction tests, developers can ensure their components meet design specifications, behave consistently, and adapt seamlessly across devices.  
-
----
-
-### How Bitloops Helps  
-
-Bitloops simplifies testing by automating property and responsiveness checks for all generated components. This ensures that your components meet high standards of quality while reducing the need for manual QA efforts.   
diff --git a/documentation/docs/design-2-code/Guides/working-with-design-systems.md b/documentation/docs/design-2-code/Guides/working-with-design-systems.md
deleted file mode 100644
index ebadfb38..00000000
--- a/documentation/docs/design-2-code/Guides/working-with-design-systems.md
+++ /dev/null
@@ -1,88 +0,0 @@
----
-sidebar_position: 6
-sidebar_label: Design Systems
-title: "Design Systems"
-description: "Learn how to create, sync, and manage design tokens from Figma to ensure consistent UI components with Bitloops Frontend Copilot."
-keywords:
-  [
-    design system guide,
-    working with design systems,
-    Figma design tokens,
-    UI design consistency,
-    design system best practices,
-    frontend design management,
-    component style management,
-    design-to-code systems,
-    Bitloops design system integration,
-    scalable UI development,
-  ]
----
-
-A **design system** is a foundational tool in frontend development that ensures consistency and efficiency across a project by standardizing UI elements, styles, and components. It serves as a single source of truth for both designers and developers, enabling the creation of scalable and maintainable user interfaces.  
-
-This guide covers how to create, manage, and utilize a design system effectively to enhance your development workflow.
-
-### What Is a Design System?  
-
-A design system is a collection of reusable components, guidelines, and resources that define the visual and functional aspects of a project:  
-
-- **Visual styles:** Define colors, typography, icons, shadows, and effects.  
-- **Spacing and layout:** Establish consistent margins, paddings, and grid systems.  
-- **Reusable components:** Provide standardized UI elements like buttons, inputs, and cards.  
-
-By unifying these elements, a design system ensures design consistency while improving development efficiency and collaboration.
-
-### Creating a Design System  
-
-Follow these steps to build a robust design system:  
-
-#### 1. Define reusable styles  
-- **Colors:** Create primary, secondary, background, and text color styles.  
-- **Typography:** Define consistent text styles for headings, body text, captions, and more.  
-- **Effects:** Add reusable styles for shadows, borders, and blurs to maintain uniformity.  
-
-#### 2. Build reusable components  
-- **Interactive elements:** Design buttons with states like hover, active, and disabled.  
-- **Complex layouts:** Use auto-layout tools to create responsive cards, forms, or containers.  
-- **Icons and assets:** Organize icons in a dedicated library for easy reference.  
-
-#### 3. Organize the system  
-- **Logical structure:** Group related styles and components into folders (e.g., Colors, Typography, Components).  
-- **Naming conventions:** Use clear, consistent names (e.g., `Button/Primary`, `Color/Background/Light`).  
-
-
-### Managing Design Tokens  
-
-Design tokens represent the core building blocks of your design system, such as colors, typography, and spacing values. Managing these tokens effectively ensures scalability and consistency.  
-
-#### Best practices for design tokens:  
-- **Centralize tokens:** Store tokens in a shared file or library to enable cross-project consistency.  
-- **Abstract styles into variables:** Use tokens like `primaryColor` or `spacingMd` in your codebase for maintainability.  
-- **Version control:** Keep track of changes to your design system using tools like Git or Figma’s version history.  
-
-### Integrating Design Systems in Development  
-
-A design system is only effective if it integrates seamlessly into your development process.  
-
-#### Tips for effective integration:  
-1. **Use design tools:** Leverage Figma, Adobe XD, or Sketch to create and manage your design system.  
-2. **Bridge design and code:** Implement tokens in your codebase using tools like Style Dictionary or CSS variables.  
-3. **Promote collaboration:** Ensure designers and developers have access to shared resources and align on naming conventions and guidelines.  
-
-### Ensuring Consistency Across Projects  
-
-Consistency is the hallmark of a successful design system. Here’s how to achieve it:  
-
-- **Shared libraries:** Use shared design libraries in tools like Figma to sync updates across projects.  
-- **Documentation:** Maintain detailed documentation outlining how and when to use each component or token.  
-- **Regular updates:** Periodically review and refine the design system to accommodate evolving project requirements.  
-
-### Summary  
-
-A well-structured design system is critical for delivering consistent, scalable, and maintainable user interfaces. By defining reusable styles and components and integrating them seamlessly into your development process, you can create products that are visually cohesive and easy to manage.
-
----
-
-### How Bitloops Helps  
-
-Bitloops simplifies design system integration by automatically building a design system in the code base. This is done by reading design tokens from Figma or identifying repeated styles across the designs and automatically generating global stlyes to then apply them to generated components. This ensures your code adheres to your design standards while reducing manual effort and errors.  
diff --git a/documentation/docs/design-2-code/Guides/working-with-storybook.md b/documentation/docs/design-2-code/Guides/working-with-storybook.md
deleted file mode 100644
index c9f77ca5..00000000
--- a/documentation/docs/design-2-code/Guides/working-with-storybook.md
+++ /dev/null
@@ -1,83 +0,0 @@
----
-idebar_position: 5
-sidebar_label: Storybook
-title: "Storybook"
-description: "Learn how Bitloops Frontend Copilot uses Storybook to preview, test, and document frontend components for seamless development and collaboration."
-keywords:
-  [
-    storybook guide,
-    working with storybook,
-    UI component testing,
-    UI component previews,
-    Storybook documentation,
-    Storybook component management,
-    design-to-code storybook,
-    frontend component testing,
-    Bitloops Storybook integration,
-    UI testing with Storybook,
-  ]
----
-
-Storybook is a powerful tool for frontend developers to build, preview, test, and document UI components in isolation. By providing a dedicated environment, it simplifies the development process, making it easier to ensure consistency, responsiveness, and reusability across your components.  
-
-This guide covers how to use Storybook effectively for frontend development, including navigating its interface, testing components, and sharing your work with team members.
-
-### What Is Storybook?  
-
-Storybook is a widely used tool in modern frontend development that allows developers to:  
-- **Build components in isolation:** Work on components without being tied to the full application.  
-- **Preview components:** See live renderings of UI elements in various states and configurations.  
-- **Test UI interactions:** Experiment with props, simulate user actions, and validate responsiveness.  
-- **Document components:** Automatically generate detailed documentation for your component library.  
-
-By isolating components, Storybook helps streamline development, minimize bugs, and improve collaboration between developers, designers, and stakeholders.
-
-### Navigating Storybook  
-
-Storybook’s user-friendly interface makes it easy to manage and interact with components:  
-
-1. **Component tree:** The sidebar organizes your components by feature, category, or folder structure. Use it to navigate through your component library.  
-2. **Preview pane:** View a live rendering of the selected component, showcasing how it looks and behaves.  
-3. **Props panel:** Modify props in real-time to test various configurations and states.  
-4. **Add-ons panel:** Access additional tools like viewport resizing, action simulation, and documentation.  
-
-
-### Testing Components  
-
-Storybook provides an interactive environment for testing UI components.  
-
-#### Key testing features:  
-- **Props testing:** Adjust props directly in the interface to see immediate visual and functional changes.  
-- **Responsive testing:** Use the viewport add-on to preview components on different screen sizes, such as mobile, tablet, and desktop.  
-- **State simulation:** Simulate states like hover, active, or disabled to ensure proper behavior.  
-- **Accessibility testing:** Leverage add-ons like Storybook Accessibility to validate compliance with WCAG standards.  
-
-
-### Sharing Storybook with Your Team  
-
-Storybook enhances collaboration by making your component library accessible to all team members:  
-
-#### How to share Storybook:  
-- **Deploy online:** Host Storybook on platforms like Vercel, Netlify, or GitHub Pages for easy access.  
-- **Static exports:** Generate a static version of Storybook to share privately or offline.  
-- **Team reviews:** Use Storybook as a reference for design discussions, code reviews, or QA sessions.  
-
-By sharing Storybook, teams can align on UI consistency and functionality, reducing misunderstandings and improving workflows.
-
-### Customizing and Extending Storybook  
-
-Storybook’s modular architecture allows developers to tailor it to their specific needs:  
-
-- **Add custom stories:** Write stories for unique use cases, edge cases, or advanced configurations.  
-- **Integrate add-ons:** Use official plugins like **Knobs**, **Actions**, **Viewport**, or **Docs** to extend functionality.  
-- **Enhance workflows:** Combine Storybook with tools like Chromatic for visual regression testing or integrate it into CI/CD pipelines for automated testing.  
-
-### Summary  
-
-Storybook is an invaluable tool for frontend developers, offering a dedicated environment for building, testing, and documenting components. It fosters better collaboration, reduces errors, and ensures a consistent user interface across your application.
-
----
-
-### How Bitloops Helps  
-
-Bitloops integrates seamlessly with Storybook by automatically generating stories for all components it creates. This includes live previews, interactive testing capabilities, and built-in documentation, making it easier to manage and refine your component library.  
diff --git a/documentation/docs/design-2-code/Troubleshooting-and-Support/common-challenges.md b/documentation/docs/design-2-code/Troubleshooting-and-Support/common-challenges.md
deleted file mode 100644
index 1b3c4d1a..00000000
--- a/documentation/docs/design-2-code/Troubleshooting-and-Support/common-challenges.md
+++ /dev/null
@@ -1,81 +0,0 @@
----
-sidebar_position: 1
-sidebar_label: Common Challenges
-title: "Conquering Common Challenges"
-description: "Overcome common design-to-code conversion challenges with Bitloops. Learn about supported features, fallback solutions, and how to report issues for personalized assistance."
-
-keywords:
-  [
-    Bitloops, 
-    Design-2-Code,
-    Bitloops common challenges,
-    design-to-code troubleshooting,
-    error resolution guide,
-    design conversion issues,
-    bug reporting Bitloops,
-    technical assistance guide,
-    support resources Bitloops,
-    issue diagnosis tips,
-    customer service Bitloops,
-    problem-solving strategies,
-    reporting platform issues,
-    troubleshooting design files,
-    code generation fixes,
-    support contact options,
-    issue reporting rewards,
-  ]
-
----
-
-Bitloops is designed to streamline your design-to-code workflow, but even the best tools encounter occasional hiccups. 
-
-We want you to succeed, so this guide covers common challenges, fallback solutions, and tips for efficient troubleshooting. In this section, we address the most common issues faced by our users. Whether it's a hiccup during installation, trouble importing design files, or the code not performing as expected, we've got you covered.  
-
-If your issue persists or isn’t listed here, we **highly recommend emailing us** at [support@bitloops.com](mailto:support@bitloops.com) with a video of the issue—and as a token of our appreciation, **we’ll send you an Amazon voucher!** 🎁 Or alternatively, join our [Discord server](https://discord.com/invite/vj8EdZx8gK). 
-
----
-
-### **What to Expect**  
-
-While Bitloops handles most design-to-code scenarios effortlessly, certain limitations can occur due to:  
-
-- **Unsupported Elements:** Some complex Figma elements may not yet be fully supported.  
-- **Fallback Issues:** Bitloops uses several proprietary algorithms and custom AI models, however, we haven't been able to test all scnearios. Our fallback logic kicks in when somehthing unexpected is detected, but it might not always produce the expected results.  
-
----
-
-### **Troubleshooting Guide**  
-
-#### **1. Component not generated**  
-**Cause:**  
-- Fall back option did not work 
-- An unsupported Figma feature was used (e.g., overly complex SVGs).  
-
-**Solution:**  
-- Delete the component and try again
-- Try building a smaller component first
-
-#### **2. Unresponsive Tests or Errors in Storybook**  
-**Cause:**  
-- Code-generation process interrupted.  
-- CSS / Responsiveness decisions where not the best for the circumastance 
-
-**Solution:**  
-- Try deleting and re-creating the component again
-- Manually edit the code to your preference and email us your needs 
-
----
-
-### **We’re Here to Help!**  
-
-If you encounter persistent issues:  
-
-📧 **Send Us an Email:** Describe your issue in detail and attach a short video showing what went wrong. Email us at **[support@bitloops.com](mailto:support@bitloops.com)**.  
-
-💬 **Join Our Discord:** Chat with our team and community on [Discord](https://discord.com/invite/vj8EdZx8gK).  
-
-🎁 **Amazon Voucher Reward:** As a thank-you for helping us improve, we’ll send you an Amazon voucher when you report a verified bug with a video demonstration.  
-
----
-
-By following these troubleshooting steps, you can quickly resolve most common challenges. Let us know how we can make your experience even better! 🚀  
\ No newline at end of file
diff --git a/documentation/docs/design-2-code/Troubleshooting-and-Support/contact-support.md b/documentation/docs/design-2-code/Troubleshooting-and-Support/contact-support.md
deleted file mode 100644
index 9ea213a9..00000000
--- a/documentation/docs/design-2-code/Troubleshooting-and-Support/contact-support.md
+++ /dev/null
@@ -1,86 +0,0 @@
----
-sidebar_position: 3
-sidebar_label: Contact Support
-title: "Bitloops Support"
-description: "Need a helping hand? 'Your Direct Line to Bitloops Support' connects you with our dedicated team, ready to assist you with any inquiries or challenges you might face. Whether you need guidance through a complex scenario, assistance with advanced features, or help troubleshooting an issue, our support team is here for you. Learn how to reach out via email, chat, or phone, ensuring you receive timely and effective assistance."
-
-keywords:
-  [
-    Bitloops, 
-    Design-2-Code,
-    Common issues resolution,
-    Bug reporting guide,
-    Contact support options,
-    Troubleshooting tips,
-    Technical assistance Bitloops,
-    Installation troubleshooting,
-    Design conversion errors,
-    User support resources,
-    Error diagnosis Bitloops,
-    Feedback submission process,
-    Code output discrepancies,
-    Support team contact,
-    Problem-solving strategies,
-    Documentation clarification,
-    Software update issues,
-    User guidance services,
-    Platform optimization tips,
-    Community support Bitloops,
-    Reporting system glitches,
-    Performance troubleshooting,
-    Responsive customer service,
-    User experience improvement,
-    Technical query resolution,
-    Issue tracking Bitloops,
-    Efficient problem reporting,
-  ]
----
-
-We understand that sometimes you need direct assistance to navigate through more complex situations. That's why our Bitloops support team is just a message or call away. 
-
-In this section, you'll find all the necessary contact information to reach our support team via email, chat, or phone. We're committed to providing timely, comprehensive support to ensure your experience with Bitloops is as smooth and productive as possible. Whether you have a question, need help with a specific feature, or require technical assistance, don't hesitate to reach out. Our team is here to ensure your success with Bitloops.
-
-## Getting Help
-
-The Bitloops team is eager to provide all the support we can to all our users. Therefore, we have created many options from which you can obtain help when converting designs into code.
-
-&nbsp; 
-&nbsp; 
-
-### 🗺 Community
-
-We have a [Discord](https://discord.gg/vj8EdZx8gK) server for live discussion with the Bitloops team as well as the broader community of frontend engineers, designers and developers using Bitloops. Feel free to join our server, introduce yourself, give us some feedback, share your output and build UIs faster!
-
-___
-
-&nbsp; 
-
-### 📯 Demonstrations
-
-The Bitloops team wants to help as much as possible, so we also provide you with the ability to book a [One-to-One Discussion](https://calendly.com/bitloops/30min?month=2022-11) with someone from the Bitloops team who will be able to provide you with a live and informal 30-minute video session. 
-
-In this session we can help you understand Bitloops Language better, or even help you solve a particular problem you may be facing. You will be speaking directly with a Bitloops Software Engineer! 
-
-&nbsp; 
-&nbsp; 
-___
-
-&nbsp; 
-
-### 📚 Documentation
-
-Well, if you're reading this, then you found the [Bitloops Documentation](https://bitloops.com/docs/design-2-code/category/getting-started). 
-
-We know there should be more documentation, but bear with us, the team is still small. We would love any feedback or help on this. 
-
-&nbsp; 
-&nbsp; 
-___
-
-&nbsp; 
-
-### 📧 Email
-
-Sometimes the easiest is a simple email. Feel free to email us at [support@bitloops.com](mailto:support@bitloops.com) and one of the founders will respond!
-
-
diff --git a/documentation/docs/design-2-code/Troubleshooting-and-Support/reporting-bugs.md b/documentation/docs/design-2-code/Troubleshooting-and-Support/reporting-bugs.md
deleted file mode 100644
index 8ce0905c..00000000
--- a/documentation/docs/design-2-code/Troubleshooting-and-Support/reporting-bugs.md
+++ /dev/null
@@ -1,58 +0,0 @@
----
-sidebar_position: 2
-sidebar_label: Bugs (earn credits!)
-title: "Report a bug -> Earn credits"
-description: "Join the Bitloops bug-hunting quest! Your keen eye for spotting glitches not only refines our tool but also earns you rewards. Learn how to craft effective bug reports and in return, receive free credits as a token of our appreciation. Together, we'll build a more robust and efficient Bitloops experience."
-
-keywords:
-  [
-    Bitloops, 
-    Design-2-Code,
-    Common issues resolution,
-    Bug reporting guide,
-    Contact support options,
-    Troubleshooting tips,
-    Technical assistance Bitloops,
-    Installation troubleshooting,
-    Design conversion errors,
-    User support resources,
-    Error diagnosis Bitloops,
-    Feedback submission process,
-    Code output discrepancies,
-    Support team contact,
-    Problem-solving strategies,
-    Documentation clarification,
-    Software update issues,
-    User guidance services,
-    Platform optimization tips,
-    Community support Bitloops,
-    Reporting system glitches,
-    Performance troubleshooting,
-    Responsive customer service,
-    User experience improvement,
-    Technical query resolution,
-    Issue tracking Bitloops,
-    Efficient problem reporting,
-  ]
----
-
-At Bitloops, we are committed to providing a seamless and efficient design-to-code conversion experience. However, we understand that despite our rigorous testing, bugs can slip through the cracks. 
-
-This is where you, our valued user, play a crucial role. Not only do you help us in enhancing the quality of Bitloops, but you also get rewarded for your contributions. Here's how you can participate in our 'Spot, Report, Reward' program and earn free credits.
-
-## 1. Identifying Bugs
-Begin by using Bitloops as you normally would and keep an eye out for any unexpected behavior, glitches, or inconsistencies. Whether it's a minor interface issue or a major functionality flaw, your keen observations are invaluable.
-
-## 2. Generating a Bug Report
-If you encounter a bug, prepare to document it. Start by noting what you were doing when the bug occurred, the specific steps that led to the issue, and the expected vs. actual results. If possible, capture screenshots or record a short video. This visual evidence can significantly aid our development team in understanding and addressing the issue promptly.
-
-## 3. Submitting Your Report
-Visit the 'Report a Bug' section on our website and fill out the bug report form. Provide a detailed description of the issue, including the steps to reproduce it, and attach any screenshots or videos you've captured. Be sure to include your contact information so we can reach out if we need more details or to update you on the status of the bug fix.
-
-## 4. Earning Your Credits
-Once your bug report is submitted, our team will review the details and verify the issue. After validation, we'll credit your Bitloops account as a token of our appreciation. These credits can be used for future subscriptions, additional features, or conversion credits within Bitloops.
-
-By participating in the 'Spot, Report, Reward' program, you're not just improving your own experience with Bitloops; you're also contributing to a community of developers and designers who rely on our tool for their projects. Your insights and proactive reporting are instrumental in shaping an even more robust and reliable Bitloops. 
-
-So, let's team up to squash those bugs and keep enhancing the seamless bridge between design and code!
-
diff --git a/documentation/docs/design-2-code/getting-started/faqs.md b/documentation/docs/design-2-code/getting-started/faqs.md
deleted file mode 100644
index 7cf27c11..00000000
--- a/documentation/docs/design-2-code/getting-started/faqs.md
+++ /dev/null
@@ -1,140 +0,0 @@
----
-sidebar_position: 3
-sidebar_label: FAQs
-title: "Frequently Asked Questions"
-description: "List of frequently asked questions"
-keywords:
-  [
-    bitloops terminology,
-    figma-2-react terms,
-    bitloops faqs,
-    responsive UI generation,
-    automated frontend testing,
-    component testing definitions,
-    design-to-code concepts,
-    UI/UX development terms,
-    bitloops definitions,
-  ]
----
-
-Whether you’re new to Bitloops or looking to maximize its potential, this FAQ section has you covered. We’ve compiled answers to the most common questions developers ask, from understanding core concepts like components and property tests to exploring advanced features like responsiveness and team collaboration. Dive in to learn how Bitloops simplifies frontend development, saves you time, and empowers you to deliver high-quality code with confidence.
-
----
-
-### **1. What is a component in Bitloops?**  
-A **Component** in Bitloops is a coded UI element generated from a Figma design frame. Components can be as simple as buttons, icons, or text fields, or as complex as entire webpage sections or reusable design patterns.  
-
-Each component is:  
-- **Reusable:** Easily used across multiple parts of your project.  
-- **Testable:** Comes with built-in property and responsiveness tests.  
-- **Customizable:** Modify or extend components to suit your project’s needs.  
-
-By turning your Figma designs into reusable and high-quality code components, Bitloops streamlines your development process and ensures scalability.
-
----
-
-### **2. What are property tests, and why are they important?**  
-**Property Tests** are automated checks that validate the core design properties of a component. They ensure the code matches your Figma design exactly, reducing the need for manual QA.  
-
-These tests verify properties such as:  
-- **Font Details:** Size, type, weight, and color.  
-- **Element Dimensions:** Width, height, margins, and padding.  
-- **Positioning:** Alignment, layout constraints, and spacing rules.  
-
-**Why are they important?**  
-- They prevent inconsistencies between your designs and the final code.  
-- They save time on manual validation, letting you focus on higher-value tasks.  
-
----
-
-### **3. What happens if my component fails a test?**  
-When a component fails a test, Bitloops provides detailed feedback highlighting the issue. Here’s how it helps:  
-
-1. **Test Results:** You’ll see specific test results that pinpoint mismatched properties, such as incorrect dimensions, colors, or fonts.  
-2. **Actionable Feedback:** The feedback provided allows users to adjust the generated code.  
-3. **Iterative Testing:** Once adjustments are made, simply save the file and the tests are rerun to confirm all issues have been resolved.  
-
-This ensures that every component meets your project’s quality standards before deployment.
-
----
-
-### **4. Do I have to define buttons and other elements manually?**  
-Currently, specific UI elements such as **Text Fields**, and **Images** are automatically identified whilst **Buttons** require manual definition in Bitloops. This ensures accuracy in assigning properties like functionality and dynamic content.  
-
-**Exciting Update:** Automatic detection of common UI elements like buttons is a **feature coming soon!** This will further streamline your workflow and reduce setup time.
-
----
-
-### **5. How does Bitloops handle responsiveness?**  
-Responsiveness is critical to delivering a seamless user experience across devices. Bitloops has built a process using its own algorithms and AI to analyze and build a codebase that supports responsiveness for each specific component. Moreover, it automatically runs **Responsiveness Tests** to ensure components adapt to various screen sizes, including mobile, tablet, and desktop.  
-
-These tests validate:  
-- **Element Resizing:** Components and containers resize appropriately without losing design fidelity.  
-- **Alignment and Spacing:** Adjustments are made to maintain proper positioning and spacing across breakpoints.  
-- **Breakpoints Compatibility:** Designs are checked against standard screen resolutions for common devices.  
-
-**How it works:**  
-- Bitloops analyzes your design’s constraints and layout rules.  
-- It identifies areas requiring adjustments for smaller or larger screens.  
-- Feedback is provided to help you fine-tune your design or code.  
-
-By automating responsiveness, Bitloops ensures a consistent and high-quality experience for end-users on any device.
-
----
-
-### **6. Can I use Bitloops with non-Figma designs?**  
-Currently, Bitloops is optimized for Figma designs. However, support for additional design tools like Adobe XD or Sketch is part of our **future roadmap**. Stay tuned for updates as we expand compatibility!
-
----
-
-### **7. What programming languages and frameworks does Bitloops support?**  
-Bitloops generates **React** code and specifically for **Nextjs**. Support for additional frameworks and programming languages like Vue, Angular, Svelte, or plain HTML/CSS is being planned as part of our future expansion.  
-
----
-
-### **8. How do I customize the generated code?**  
-Bitloops allows you to export fully customizable code. Once generated, you can:  
-- Edit the code in your preferred IDE (e.g., **VS Code**).  
-- Modify styles, props, and logic to meet project-specific requirements.  
-- Integrate it with backend services or extend functionality as needed.  
-
----
-
-### **9. Can I use Bitloops for dynamic components or interactive elements?**  
-Yes, Bitloops can generate dynamic components, but you’ll need to define interactions and dynamic behaviors (like onClick events or API calls) manually in the code. Advanced support for common interactions is on the roadmap.
-
----
-
-### **10. How does Bitloops help with collaboration?**  
-Bitloops bridges the gap between designers and developers by:  
-- Ensuring that design-to-code mappings are consistent and transparent.  
-- Providing detailed test results for resolving discrepancies quickly.  
-- Allowing seamless sharing and updates between team members.  
-
----
-
-### **11. What happens to my existing codebase?**  
-Currently, Bitloops operates in parallel to your existing codebase. In the near future we will allow users to integrate existing codebases into Bitloops including: 
-- Importing existing components into your Bitloops project structure.  
-- Using those components in the creation of new Components, Sections or Pages
-
----
-
-### **12. Is Bitloops suitable for enterprise projects?**  
-Absolutely! Bitloops is designed to handle projects of all sizes, including enterprise-level applications. Its ability to generate clean, scalable, and maintainable code ensures a consistent and professional-grade output for large teams and complex systems.
-
----
-
-### **13. What security measures does Bitloops use to protect my designs?**  
-Your design files are securely handled using industry-standard encryption protocols. Bitloops ensures:  
-- Data is stored and processed securely.  
-- Files are accessible only by authorized users.  
-- Compliance with GDPR and other relevant data protection regulations.
-
----
-
-### **14. Does Bitloops offer team collaboration features?**  
-Not yet, but its coming! Bitloops will support team accounts where multiple users can:  
-- Work on shared projects.  
-- Review test results and make adjustments collaboratively.  
-- Manage permissions and access levels for better team coordination.
diff --git a/documentation/docs/design-2-code/getting-started/quick-start-guide.md b/documentation/docs/design-2-code/getting-started/quick-start-guide.md
deleted file mode 100644
index 0d1422f5..00000000
--- a/documentation/docs/design-2-code/getting-started/quick-start-guide.md
+++ /dev/null
@@ -1,95 +0,0 @@
----
-sidebar_position: 2
-sidebar_label: Quick Start
-title: "Quick Start Guide"
-description: "Learn how to set up Bitloops Frontend Copilot and quickly convert your Figma designs into responsive, production-ready components with built-in tests and documentation."
-keywords:
-  [
-    bitloops quick start,
-    figma-to-code workflow,
-    professional code generation,
-    automated UI coding,
-    responsive frontend tools,
-    frontend developer onboarding,
-    efficient coding processes,
-    storybook integration,
-    component testing automation,
-    adaptive design conversion,
-  ]
----
-
-Bitloops has been built by developers for developers, so integration with the developer workflow is a priority. 
-
-In fact, Bitloops is currently a VS Code extension, so everything it generates and all the assets it exports are created in your working folder. Follow these simple steps to create your first component, complete with Storybook documentation and custom tests:
-
-
-### **1. Create Your Account**  
-Sign up for a free Bitloops account through the VS Code extension. Find it by searching Bitloops in VS Code exentions marketplace or through this [link](https://marketplace.visualstudio.com/items?itemName=Bitloops.bitloops). You're then able to create an account using Google or Github. This will give you access to all the tools and features needed to start converting designs into code.  
-
-![Creating Bitloops Account](../../../static/img/create_account.png)
-
----
-
-### **2. Create your first Bitloops Project**  
-Once logged in, give your Bitloops Project a name. Currently we only support Typescript, Next.js and Tailwind but will introduce more languages, frameworks and UI libraries in the future.  
-
-![Create your Bitloops Project](../../../static/img/start_project.png)
-
----
-
-### **3. Import Your Figma File**  
-After you've created your project, simply import your figma design by pasting the Figma URL in the import function on Bitloops. You will need to import every single Figma Page you would like to convert. Your design will appear under the Designs tab of your Bitloops account.   
-
-![Import a Figma File](../../../static/img/DocsFigmaImport.gif)
-
----
-
-### **4. Add a Design to Your Project**  
-Click on the + button next to your imported design to view all the frames of your design. You are now able to add specific frames to your Bitloops Project.  
-- Frames are individual sections or components you want to convert into code. 
-- Some designs have many frames that are not relevant to the project, so Bitloops will only consider frames that are added to the Project 
-
-![Add Design to Project](../../../static/img/Adddesignstoproject.gif)
-
----
-
-### **5. Select the Frame and Create a Component**  
-Now that the selected frames have been added to your Bitloops Project, you're able to view the frame tree (just like in Figma). All you need to do now is right-click the frame you want to convert into a component (note: this can be a parent frame or any child frame within that tree) and select **"Create Component."**  
-
-Bitloops will now:  
-- Generate production-ready code.  
-- Create a Storybook story and documentation.  
-- Build custom tests for responsiveness and design validation for that component  
-
-![Create Component](../../../static/img/CreateComponent.gif)
-
----
-
-### **6. View Your Output**  
-Once the component is ready, you can:  
-- Review the generated code directly in the Bitloops dashboard or export it to your IDE.  
-- Explore the Storybook documentation and test results included with the output.  
-
-![Code Generated](../../../static/img/CodeGenerated.gif)
-
----
-
-## **Additional Features to Enhance Your Workflow**
-
-Once you’ve mastered the basics, Bitloops offers a range of additional features to keep your projects organized and efficient:  
-
-- **Seamlessly Import New Designs**  
-  Bring in additional Figma files to expand your project as requirements evolve.  
-
-- **Add More Frames and Designs**  
-  Add new frames or designs into your project to accommodate updates or changes.  
-
-- **Efficient Component Management**  
-  Keep your project clean and up-to-date by removing outdated components and generating new ones when needed.  
-
-- **Organize and Manage Frames**  
-  Flexibly add or delete frames and designs to refine your workflow and maintain project focus.  
-
-- **Streamline File Management**  
-  Easily remove unused design files from your account to free up space and maintain a clutter-free workspace.  
-
diff --git a/documentation/docs/design-2-code/getting-started/terminology.md b/documentation/docs/design-2-code/getting-started/terminology.md
deleted file mode 100644
index e83a9476..00000000
--- a/documentation/docs/design-2-code/getting-started/terminology.md
+++ /dev/null
@@ -1,101 +0,0 @@
----
-sidebar_position: 3
-sidebar_label: Terminology
-title: "Terminology"
-description: "Learn key terms used in Bitloops Frontend Copilot, from components and designs to containers and elements."
-keywords:
-  [
-    bitloops terminology,
-    figma-2-react terms,
-    frontend development glossary,
-    responsive UI generation,
-    automated frontend testing,
-    component testing definitions,
-    design-to-code concepts,
-    UI/UX development terms,
-    bitloops definitions,
-  ]
----
-
-Here are the key terms used throughout Bitloops Frontend Copilot. Understanding these will help you make the most of the platform.
-
----
-
-### **Core Terms**
-
-#### **1. Component**  
-A **coded UI element** generated from a Figma design frame. Components are reusable, testable, and follow best practices in web development. They can represent anything from small UI elements (like buttons) to full-page sections (like a header or footer).
-
-#### **2. Design**  
-A **frame from a Figma file** that serves as the source of truth for generating components. A design can be:  
-- A full webpage or screen layout.  
-- A UI section like a navbar, footer, or sidebar.  
-- A smaller frame, such as a button, card, or form field.
-
-#### **3. Figma File**  
-The **Figma project file** containing all design frames. Bitloops pulls frames from this file to create components and run tests.
-
-#### **4. Element**  
-A **single design element** within a design or component. Examples include:  
-- Text fields (labels, headings, paragraphs)  
-- Buttons  
-- Icons  
-- Images  
-
-Elements are the building blocks of components and can be combined into more complex layouts.
-
-#### **5. Container**  
-A **layout structure** used to group elements or other containers. Containers allow for more complex UI structures by managing:  
-- **Element Grouping:** Organizing multiple elements or nested containers.  
-- **Layout Behavior:** Controlling element alignment, spacing, and stacking.
-
----
-
-### **Testing Concepts**
-
-#### **6. Storybook Story**  
-An **interactive visual test case** generated from a component. Storybook stories allow developers to:  
-- Preview how components look and behave in isolation.  
-- Adjust component properties interactively.  
-- Document the intended appearance and functionality of components.  
-
-Storybook serves as both a testing tool and a UI component library.
-
-#### **7. Property Tests**  
-Automated **design verification tests** that compare components against design specifications from Figma. They check for:  
-- **Font properties:** Correct font size, type, and color  
-- **Element size and location:** Width, height, margins, paddings, and alignment  
-- **Design Constraints:** Minimum and maximum dimensions, aspect ratios, etc.  
-
-Property tests ensure that components match their Figma designs pixel-perfectly.
-
-#### **8. Responsiveness Tests**  
-Automated **adaptive behavior tests** that validate how components respond to different screen sizes. These tests check for:  
-- Proper resizing of elements and containers  
-- Correct alignment and spacing when the viewport changes  
-- Support for common breakpoints like mobile, tablet, and desktop views  
-
-This ensures a consistent user experience across devices.
-
-
-### **Specific Elements and Components**  
-
-#### **9. Button Component**  
-A **clickable UI element** designed to trigger actions such as form submissions, navigation, or interactions.  
-- **Auto-Detection (Coming Soon):** Bitloops will soon detect buttons automatically based on design frame properties.  
-- **Manual Definition (Current):** Until auto-detection is supported, buttons must be manually defined in the system.
-
-#### **10. Text Element**  
-A **content element** containing only text. Common examples include:  
-- **Headings:** H1, H2, etc.  
-- **Paragraphs:** Standard body text  
-- **Labels:** Descriptive text for form fields or buttons  
-
-Text elements follow specific properties like font size, color, alignment, and weight.
-
-#### **11. Image Element**  
-An **element containing visual content**, such as photos, icons, or logos. Supported file types typically include:  
-- **Raster Images:** JPG, PNG  
-- **Vector Images:** SVG  
-
-Images are styled with properties like width, height, aspect ratio, and alignment.
diff --git a/documentation/docs/design-2-code/overview/how-it-works.md b/documentation/docs/design-2-code/overview/how-it-works.md
deleted file mode 100644
index 1b1ab944..00000000
--- a/documentation/docs/design-2-code/overview/how-it-works.md
+++ /dev/null
@@ -1,85 +0,0 @@
----
-sidebar_position: 3
-sidebar_label: How it Works
-title: "How it Works"
-description: "A step-by-step guide to how Bitloops transforms your designs into responsive, production-ready code."
-keywords:
-  [
-    bitloops workflow,
-    design conversion process,
-    responsive code generation,
-    automated frontend development,
-    professional coding workflow,
-    Figma to React pipeline,
-    design-to-code automation,
-    UI development tools,
-    efficient design-to-code,
-    Bitloops step-by-step,
-  ]
----
-
-Bitloops simplifies frontend development by **automating the design-to-code process**, generating professional-grade frontend code, and handling design assets with minimal manual input. Here's a step-by-step overview of how it works:  
-
-### **1. Import Your Figma File**  
-
-Start by **importing your Figma file** into Bitloops. This file serves as the source of truth for your design system, containing all frames, components, and assets.  
-
-#### **What Bitloops Imports:**  
-- **Frames and Design Elements:** UI components, screens, and pages.  
-- **Visual Assets:** Icons, logos, and images.  
-- **Fonts and Colors:** Ensuring consistent design fidelity.  
-
-### **2. Add a Design Frame to Your Project**  
-
-Once your Figma file is imported, **add individual design frames** to your Bitloops project. A design frame can be anything from a simple button to an entire webpage layout.  
-
-#### **Why This Step Matters:**  
-- **Selective Import:** Focus only on relevant parts of your design.  
-- **Organized Workflow:** Add and manage frames one at a time for easier component generation.  
-
-### **3. Convert Design Frames into Components**  
-
-After adding a design frame, **select a specific frame** and let Bitloops work its magic. Bitloops **analyzes the frame**, generates code, and extracts assets—all while ensuring **design fidelity** and **responsive behavior**.
-
-#### **What Bitloops Generates:**  
-- **Production-Ready Code:** React or Next.js components following industry best practices.  
-- **Storybook Story:** An interactive preview of your component.  
-- **Property Tests:** Tests for font sizes, colors, dimensions, and layout accuracy.  
-- **Responsiveness Tests:** Validations ensuring the component works on all devices.  
-- **Assets Export:** Automatic export of icons, images, and fonts into the appropriate folders.  
-- **Prop Definitions:** Automatically generated prop names and default values based on design context.  
-- **Component Naming:** Meaningful component names reflecting their purpose in the project.
-
-### **4. Customize and Export the Code**  
-
-Once code generation is complete, you can **review, refine, and export** the generated code directly into your project.  
-
-#### **Customization Options:**  
-- **Code Editing:** Adjust components, props, and styles as needed.  
-- **Project Integration:** Export components into your codebase for immediate use.  
-- **Team Collaboration:** Maintain consistent code standards for your entire team.  
-
----
-
-## **Upcoming Features (Coming Soon 🚀)**  
-
-Bitloops is constantly evolving. Here’s a sneak peek at some upcoming features designed to take your design-to-code experience even further:  
-
-#### **1. Automatic Nested Component Generation**  
-- Detect nested components within a frame.  
-- Automatically create child components, define props, and link instances.  
-
-#### **2. Defining Instances of Existing Components**  
-- Select parts of a frame that reference already-defined components.  
-- **Reuse instead of re-creating**—reducing duplicated work and improving project scalability.  
-
-#### **3. Import Existing Code Components**  
-- Import pre-existing components into Bitloops and **integrate them seamlessly** into your projects.  
-
-#### **4. Full Page Conversion & Automatic Component Breakdown**  
-- Select an **entire page frame** in Figma and let Bitloops identify and break it into components.  
-- **Component Identification:** Automatically detect buttons, forms, cards, and more.  
-- **Bottom-Up Approach:** Build components from the smallest elements up to entire pages.  
-- **User Confirmation Workflow:** Review and approve detected components before generation.  
-
-
diff --git a/documentation/docs/design-2-code/overview/introduction-to-bitloops.md b/documentation/docs/design-2-code/overview/introduction-to-bitloops.md
deleted file mode 100644
index a2c37bdd..00000000
--- a/documentation/docs/design-2-code/overview/introduction-to-bitloops.md
+++ /dev/null
@@ -1,103 +0,0 @@
----
-sidebar_position: 1
-sidebar_label: Introduction to Bitloops
-title: "Introduction to Bitloops"
-description: "Learn what Bitloops Frontend Copilot is and how it can revolutionize your frontend development process by automating repetitive tasks and generating high-quality code."
-keywords:
-  [
-    bitloops introduction,
-    design-to-code automation,
-    responsive UI generation,
-    Figma to React process,
-    professional frontend tools,
-    automated code generation,
-    developer productivity tools,
-    high-quality code output,
-    frontend workflow optimization,
-  ]
----
-
-Bitloops is an AI Agent and Copilot that automates the generation of professional-grade frontend code. With Bitloops developers can turn their designs into **responsive, production-ready code** in minutes, with the added benefit of automatically generating storybook stories and custom tests for each UI component, freeing up developer time to focus on high-value tasks.  
-
-
-### Why Bitloops?  
-
-Frontend development is a cornerstone of modern application development, yet it remains mired in time-consuming, manual processes. The truth is, most businesses still require scalable and custom software to serve their customers and users. However, whilst design tools have improved significantly, the ability to convert these into high-quality production-grade code remains a manual process.  
-
-### The Developer’s Journey: Challenges in Frontend Development
-
-1. **Extracting and Translating Design Systems into Code**
-   - Manually converting design tokens (e.g., colors, typography, spacing) into **global CSS** or **TailwindCSS configuration files**.
-   - Ensuring consistency and scalability in design token usage across projects.
-
-2. **Asset Management and Optimization**
-   - Exporting images, icons, and vectors in web-optimized formats.
-   - Merging and grouping vector elements into cohesive assets (e.g., logos) to maintain fidelity.
-   - Handling custom fonts, including weights and styles, while ensuring cross-browser compatibility.
-
-3. **Component Analysis and Build-Out**
-   - Breaking down designs into reusable components and variants.
-   - Mapping out **props** and dynamic instances to maximize code reusability.
-   - Keeping track of updates in design iterations and ensuring synchronization with code.
-
-4. **Responsive Design Implementation**
-   - Ensuring layouts adapt seamlessly across various screen sizes and resolutions.
-   - Writing custom CSS or adjusting TailwindCSS classes to handle edge cases.
-
-5. **Streamlining Collaboration**
-   - Bridging the gap between design and development, which often leads to mismatches in implementation and unnecessary back-and-forth.
-
-6. **Efficiency Overhead**
-   - Reviewing and refactoring code to align with best practices and maintainability.
-   - Documenting design-to-code mappings to ensure future extensibility.
-
-These challenges often lead to inefficiencies, increased costs, and compromised delivery timelines, especially as projects scale.
-
-
-### How Bitloops Frontend Copilot Revolutionizes Development
-
-Bitloops eliminates these bottlenecks by serving as an **AI-powered copilot** for frontend engineers, automating the repetitive and error-prone aspects of frontend development. Here’s how it transforms your workflow:
-
-1. **Asset Automation**
-   - Exports all design assets—images, icons, and fonts—with optimal settings in a single step.
-   - Automatically merges vector graphics for complex assets, ensuring scalability and performance.
-
-2. **Automated Component and Variant Generation**
-   - Analyzes the design holistically, identifying atomic components and their variants.
-   - Generates reusable, scalable code with detailed props mapping and clean structure.
-
-3. **Intelligent Design System Integration** (under development)
-   - Automatically converts design tokens into **global stylesheets** or **Tailwind configurations**, ensuring consistency across the application.
-
-4. **Built-In Responsiveness**
-   - Validates design responsiveness with **automated testing** across multiple devices and resolutions.
-   - Highlights and resolves inconsistencies, saving hours of manual debugging.
-
-5. **End-to-End Workflow Integration**
-   - Integrates seamlessly with tools like **Figma, VS Code, GitHub**, and CI/CD pipelines (under development), enabling developers to work efficiently in their existing ecosystems.
-
-6. **Developer Empowerment Through Automation**
-   - Reduces time spent on repetitive tasks, freeing developers to focus on complex problem-solving and innovation.
-   - Delivers clean, production-ready code that adheres to best practices, reducing refactoring needs and technical debt.
-
-7. **Context-Aware Intelligence**
-   - Unlike competitors, Bitloops doesn’t just translate designs element by element. It understands the intent behind the design and makes intelligent decisions to create a maintainable and logical codebase.
-
-
-
-### The Bitloops Advantage: What Sets Us Apart
-
-- **Precision and Scalability:** Bitloops replicates the decision-making of senior developers, delivering high-quality code that scales effortlessly.
-- **Cost and Time Efficiency:** Reduce costs by up to 90% and deliver in minutes what used to take days.
-- **Future-Ready Integration:** Stay ahead with support for emerging technologies, backend automation, and cross-platform compatibility.
-
-
-### The Impact
-
-With Bitloops, developers can:
-- Deliver high-quality frontends faster and more consistently.
-- Minimize costs and technical debt.
-- Improve collaboration between design and development teams.
-
-**Bitloops isn’t just a tool - it’s the next-generation development platform that empowers developers to focus on creating exceptional user experiences, while we handle the heavy lifting.**
-
diff --git a/documentation/docs/design-2-code/overview/key-features.md b/documentation/docs/design-2-code/overview/key-features.md
deleted file mode 100644
index 74641417..00000000
--- a/documentation/docs/design-2-code/overview/key-features.md
+++ /dev/null
@@ -1,50 +0,0 @@
----
-sidebar_position: 2
-sidebar_label: Bitloops' Key Features
-title: "Bitloops' Key Features"
-description: "Explore the key Bitloops features that make it an essential tool for professional frontend developers."
-keywords:
-  [
-    bitloops features,
-    professional coding tools,
-    responsive design automation,
-    reusable components,
-    design validation tests,
-    design-to-code AI,
-    Figma integration,
-    production-ready code,
-    automated code generation,
-    developer productivity,
-    high-quality code,
-  ]
----
-
-Bitloops is purpose-built to streamline the developer workflow and elevate code quality. Here’s how it sets a new standard for efficiency, precision, and scalability:  
-
-### **1. Intelligent design-to-code conversion**  
-- Transform Figma designs into **clean, responsive, and reusable components**.  
-- Automatically extract assets, including images, icons, and logos, optimized for seamless integration.  
-- Support for nested components and design variants ensures consistency and scalability.  
-
-### **2. Automated testing and validation**  
-- Validate responsiveness across devices and screen sizes with **automated checks**.  
-- Maintain design fidelity using proprietary tests that align code output with original specifications.  
-- Save hours of manual QA by letting Bitloops build the storybook automatically.  
-
-### **3. Fully customizable code output**  
-- Adapt generated code to match your team’s **coding standards** and preferences.  
-- Outputs are fully editable, allowing you to tweak, refactor, or extend code as needed.  
-- Flexible enough to fit seamlessly into any project workflow, from startups to enterprises.  
-
-### **4. Seamless integrations**  
-- Easy integration with **Figma** for importing designs.  
-- Upcoming support for tools like **AdobeXD**, **Sketch**, and IDEs like **VS Code** ensures your workflow remains future-proof.  
-- Request designs to be converted and Bitloops **automatically builds a design system (in code)**. It then identifies components and their respective instances, building flexible and reusable code
-- Immediate access to the **component storybook** and the code for manual editing 
-
-### **5. Designed for professionals, built for scalability**  
-- Focus on **maintainable, production-grade code** that adheres to industry best practices.  
-- Automates repetitive tasks, freeing you to focus on building innovative and high-impact features.  
-- Scales to meet the demands of startups, small businesses, and large enterprises alike.  
-
-Bitloops isn’t just a tool — it’s your partner in building exceptional user interfaces. From automating tedious tasks to ensuring top-notch code quality, Bitloops transforms how frontend development gets done.
diff --git a/documentation/docs/design-2-code/overview/what-is-a-frontend-copilot.md b/documentation/docs/design-2-code/overview/what-is-a-frontend-copilot.md
deleted file mode 100644
index 34fb144d..00000000
--- a/documentation/docs/design-2-code/overview/what-is-a-frontend-copilot.md
+++ /dev/null
@@ -1,62 +0,0 @@
----
-sidebar_position: 1
-sidebar_label: What is a Frontend Copilot?
-title: "What is a Frontend Copilot?"
-description: "An introduction to Bitloops Frontend Copilot, the AI-powered tool for professional frontend developers that transforms designs into responsive, production-ready code."
-keywords:
-  [
-    bitloops frontend copilot,
-    professional frontend development,
-    AI-powered design conversion,
-    responsive code generation,
-    Figma to React,
-    design-to-production automation,
-    adaptive components,
-    developer tools overview,
-    high-quality code generation,
-  ]
----
-
-A **frontend copilot** is an AI-powered tool designed to enhance the productivity of frontend developers by automating routine tasks, ensuring consistency, and enabling the creation of high-quality, scalable user interfaces.  
-
-Frontend development often requires a balance between creative problem-solving and repetitive implementation work, such as converting designs into functional code or ensuring responsiveness. A copilot bridges this gap by accelerating workflows while maintaining precision and design fidelity.
-
-### How Does a Frontend Copilot Add Value?
-
-A frontend copilot transforms the way developers work by addressing key pain points in the development process:
-
-1. **Streamlining repetitive tasks**  
-   Frontend development involves many time-consuming steps that a copilot can automate, such as:  
-   - Extracting assets and design tokens from files like Figma.  
-   - Generating responsive layouts and reusable components.  
-   - Ensuring consistency across design systems.  
-
-   Automating these tasks frees developers to focus on building complex features and refining user experiences.
-
-2. **Delivering clean, scalable code**  
-   Quality code is the foundation of any successful application. A copilot generates:  
-   - Modular and reusable components that simplify future updates.  
-   - Scalable structures that grow with the project without technical debt.  
-   - Flexible integrations with popular frameworks and libraries like React or Redux.
-
-3. **Ensuring design fidelity and responsiveness**  
-   A copilot validates that the generated code matches the original design while adapting seamlessly to different devices and resolutions. By automating testing and adjustments, it ensures a consistent user experience across platforms.
-
-
-### Why Use a Frontend Copilot?
-
-Modern frontend development is challenging due to the need for speed, quality, and scalability. A copilot addresses these challenges by:  
-
-- **Reducing time to production:** Automating repetitive steps accelerates delivery timelines.  
-- **Minimizing errors:** Automated checks ensure adherence to design and coding standards, reducing QA overhead.  
-- **Improving developer productivity:** Developers can focus on solving complex problems rather than routine implementation tasks.  
-
-
-### The Future of Frontend Development
-
-Frontend copilots represent a shift in how applications are built. By combining AI with smart automation, these tools empower developers to:  
-- Deliver projects faster without sacrificing quality.  
-- Focus on innovation and creativity rather than repetitive coding.  
-- Reduce costs by streamlining workflows and minimizing manual effort.
-
-As the industry evolves, a frontend copilot is becoming an essential tool for teams looking to stay competitive, improve collaboration, and achieve higher standards of development excellence.
diff --git a/documentation/docs/design-2-code/seo-metadata-recommendations.md b/documentation/docs/design-2-code/seo-metadata-recommendations.md
new file mode 100644
index 00000000..51684264
--- /dev/null
+++ b/documentation/docs/design-2-code/seo-metadata-recommendations.md
@@ -0,0 +1,1124 @@
+# SEO Metadata Recommendations: Titles, Descriptions, Keywords & FAQs
+
+**Purpose:** Comprehensive SEO improvements for all 20 documents across Best Practices and UI Systems Performance series.
+
+---
+
+### 3. component-api-design.md
+
+**Current Title:** "Component API Design"
+
+**Suggested Title:** "React Component API Design: Props as Contracts, Variants, and Stable Interfaces"
+
+**Current Description:** "Props are contracts. Learn how to design component APIs that are semantic, stable, and evolvable—without boolean explosion or breaking changes."
+
+**Suggested Description:** "Design React component APIs that don't break. Learn semantic props vs. mechanical props, variant patterns, boolean explosion prevention, and stable interface evolution."
+
+**Current Keywords:**
+```
+component api, props design, react props, component interface, typescript props, component contracts, api stability
+```
+
+**Suggested Keywords:**
+```
+react component api design,
+props best practices react,
+component interface design,
+boolean prop explosion,
+react component variants,
+typescript component props,
+stable component api,
+semantic vs mechanical props
+```
+
+*
+
+---
+
+### 4. data-contracts.md
+
+**Current Title:** "Data Contracts and Content Boundaries"
+
+**Suggested Title:** "Frontend Data Contracts: API Boundaries, Mapping Layers, and Schema Ownership"
+
+**Current Description:** "Where does data responsibility live? Learn how to design boundaries between CMS, backend, and frontend—with clear contracts, mapping layers, and validation strategies."
+
+**Suggested Description:** "Who owns the data shape—API, CMS, or component? Learn mapping layers, validation boundaries, and contracts that prevent backend changes from breaking your UI."
+
+**Current Keywords:**
+```
+data contracts, content boundaries, api contracts, cms integration, data mapping, frontend data, schema validation
+```
+
+**Suggested Keywords:**
+```
+frontend data contracts,
+api response mapping react,
+cms frontend integration,
+typescript api validation,
+zod schema validation,
+backend frontend contract,
+data transformation layer,
+api schema ownership
+```
+
+**Suggested FAQs:**
+
+1. **Should components consume API responses directly?**
+   No. Add a mapping layer that transforms API responses into the shape components expect. This isolates components from backend changes: when the API returns `price_cents`, map it to `formattedPrice: "$29.99"` before it reaches components. See [Component API Design](./component-api-design.md) for how component props should be designed around this mapped data.
+
+2. **Where should data validation happen—frontend or backend?**
+   Both, for different reasons. Backend validates for security and data integrity (never trust client input—see [Security Boundaries](../ui-systems-performance/security-boundaries.md)). Frontend validates for UX (immediate feedback) and to fail fast on unexpected response shapes. Use tools like Zod for runtime validation at API boundaries.
+
+3. **How do I handle API schema changes without breaking the UI?**
+   The mapping layer absorbs changes. When the API renames `user_name` to `username`, update the mapper once—not every component that displays names. See [Codebase Conventions](./codebase-conventions.md) for organizing mapping layers alongside features.
+
+4. **What's the difference between a data contract and a TypeScript type?**
+   TypeScript types are compile-time checks—they verify your code is internally consistent. Data contracts are runtime agreements about what shape data actually arrives in. Use both: types for development, runtime validation for production. For related type patterns, see [Component API Design](./component-api-design.md).
+
+5. **Who owns the contract—frontend or backend?**
+   Ideally, contracts are shared artifacts (OpenAPI specs, GraphQL schemas) that both sides agree to. In practice, the backend usually defines the API and frontend adapts. See [Network Protocols](../ui-systems-performance/network-protocols.md) for HTTP contract patterns.
+
+6. **How do I handle optional or missing fields from the API?**
+   Define defaults in the mapping layer, not scattered across components. If `user.avatarUrl` might be null, the mapper provides a default: `avatarUrl: user.avatarUrl ?? DEFAULT_AVATAR`. Components can assume the shape is complete. See [Component API Design](./component-api-design.md) for handling optional props.
+
+7. **What's the right granularity for data contracts?**
+   Match contracts to domain concepts, not API endpoints. A "Product" contract includes everything components need to render a product, regardless of whether it comes from one endpoint or three. For caching these aggregated shapes, see [Caching Strategies](../ui-systems-performance/caching-strategies.md).
+
+8. **How do I version data contracts?**
+   When contracts must change, support both versions temporarily: the mapping layer accepts v1 or v2 from the API and normalizes to the component's expected shape. Deprecate old versions with deadlines. For similar versioning patterns with component APIs, see [Component API Design](./component-api-design.md).
+
+9. **Should I use GraphQL to avoid mapping layers?**
+   GraphQL reduces the need for mapping by letting frontend request exact shapes. But you still need validation and transformation. For caching GraphQL responses, see [Caching Strategies](../ui-systems-performance/caching-strategies.md). GraphQL is better DX, not a replacement for data boundaries.
+
+10. **How do I test data contracts?**
+    Test the mapping layer with fixtures: given this API response, verify the output shape. Test that validation rejects malformed responses. See [Testing and Storybook](./testing-and-storybook.md) for how story fixtures should reflect these mapped data shapes.
+
+---
+
+### 5. design-system-consumption.md
+
+**Current Title:** "Design System Consumption"
+
+**Suggested Title:** "Using Design Systems Correctly: Tokens, Constraints, and Preventing Drift"
+
+**Current Description:** "Design systems provide tokens and constraints. Learn the rules for consuming them: what's allowed, what's forbidden, and how limitation enables scale."
+
+**Suggested Description:** "Design systems fail when developers bypass them. Learn token-only styling, the forbidden list, escape hatch friction, and how to prevent design drift at scale."
+
+**Current Keywords:**
+```
+design systems, design tokens, tailwind tokens, css variables, theming, design constraints, style consistency
+```
+
+**Suggested Keywords:**
+```
+design system consumption rules,
+design tokens best practices,
+preventing design system drift,
+tailwind design system,
+css custom properties tokens,
+design system constraints,
+token only styling,
+design system governance
+```
+
+**Suggested FAQs:**
+
+1. **When is it okay to use arbitrary values instead of design tokens?**
+   Almost never in production code. Acceptable exceptions: one-off decorative elements (marketing hero positioning), third-party integration constraints (external widget dimensions), or rapid prototyping before tokens exist. Always document why. If you need a value frequently, request a token. See [Responsive Behavior](./responsive-behavior.md) for when fluid values are appropriate.
+
+2. **How do I prevent developers from bypassing the design system?**
+   Multiple layers: (1) constrain component APIs—don't expose `className` (see [Component API Design](./component-api-design.md)), (2) add linting rules for arbitrary Tailwind values, (3) make escape hatches explicit (`__unsafeClassName`), (4) review PRs for token compliance, (5) audit quarterly for drift. See [Codebase Conventions](./codebase-conventions.md) for enforcement patterns.
+
+3. **What's the difference between extending and bypassing a design system?**
+   Extending adds new tokens, components, or variants through the system's governance process—it's intentional, documented, and reviewed. Bypassing hardcodes values outside the system—it's hidden, undocumented, and erodes consistency. See [Component Creation Workflows](./component-creation-workflows.md) for when to create new components vs. extend existing ones.
+
+4. **Should I use `!important` to override design system styles?**
+   No. If you need `!important`, you're fighting the system instead of using it. Either the system needs a new variant (see [Component API Design](./component-api-design.md)), or you're using the wrong component. File an issue requesting what you need rather than forcing overrides.
+
+5. **How do I handle cases where design tokens don't exist for my use case?**
+   Follow the fallback hierarchy: (1) verify the token doesn't exist, (2) use the nearest existing token, (3) request a new token if the need is recurring, (4) document the exception if you must use an arbitrary value temporarily. See [Codebase Conventions](./codebase-conventions.md) for documenting exceptions.
+
+6. **What's token-only styling and why does it matter?**
+   Token-only styling means using design system values (colors, spacing, typography) exclusively—never hardcoded hex values or pixel measurements. Tokens adapt to themes (dark mode) and can be audited. See [Responsive Behavior](./responsive-behavior.md) for how tokens work with responsive design.
+
+7. **How do themes interact with design system consumption?**
+   Themes redefine token values, not component structure. If you use `bg-primary`, the theme defines what "primary" means in each context. Semantic tokens (`bg-background`, `text-muted`) are theme-safe. For accessibility considerations in theming, see [Accessibility](./accessibility.md).
+
+8. **How do I create recurring patterns without violating the design system?**
+   Create wrapper components that compose system primitives correctly. If you often use `Button` + `Tooltip` + specific icon sizing, create an `IconButton` wrapper. See [Component Creation Workflows](./component-creation-workflows.md) for when to extract wrapper components.
+
+9. **What are the costs of design system drift?**
+   Drift compounds: inconsistent appearance, inconsistent behavior, theme failures, and accessibility gaps (see [Accessibility](./accessibility.md)). Custom components often miss accessibility features that system components provide. See [Testing and Storybook](./testing-and-storybook.md) for catching drift through visual regression testing.
+
+10. **How do I audit a codebase for design system compliance?**
+    Search for: arbitrary values in Tailwind (`text-[`, `bg-[`), `!important` usages, inline `style` props, components that duplicate system functionality. See [Codebase Conventions](./codebase-conventions.md) for establishing linting and review processes that catch drift early.
+
+---
+
+### 6. responsive-behavior.md
+
+**Current Title:** "Responsive Behavior"
+
+**Suggested Title:** "Responsive Design Systems: Fluid Typography, Breakpoint Strategy, and Adaptive Images"
+
+**Current Description:** "Responsiveness isn't about breakpoints—it's about strategy. Learn fluid vs. stepped approaches, and how to unify typography, spacing, and images into a coherent responsive system."
+
+**Suggested Description:** "Stop adding breakpoints at random. Learn fluid vs. stepped responsive strategies, clamp() typography, srcset images, and when breakpoints actually matter."
+
+**Current Keywords:**
+```
+responsive design, breakpoints, fluid design, responsive typography, responsive images, tailwind responsive, mobile-first
+```
+
+**Suggested Keywords:**
+```
+responsive design strategy,
+fluid typography clamp,
+tailwind breakpoints best practices,
+mobile first css,
+responsive images srcset sizes,
+css container queries,
+responsive spacing system,
+breakpoint strategy frontend
+```
+
+**Suggested FAQs:**
+
+1. **How many breakpoints do I actually need?**
+   Most layouts need 1-2 meaningful breakpoints, not 5. Add breakpoints only when layout structure genuinely changes (single column to multi-column, navigation collapse). Don't add breakpoints for minor spacing tweaks. See [Component Creation Workflows](./component-creation-workflows.md) for keeping component complexity manageable.
+
+2. **When should I use fluid typography with clamp()?**
+   Use `clamp()` for headings and display text where smooth scaling improves visual rhythm across viewports. Keep body text and UI elements (buttons, labels) at fixed sizes for consistent readability and touch targets—especially important for [Accessibility](./accessibility.md).
+
+3. **What's the difference between fluid and stepped responsive design?**
+   Fluid: values scale continuously with viewport (using vw units, clamp()). Stepped: values jump at specific breakpoints. Most production systems are hybrid—fluid typography within ranges, stepped layout changes at major breakpoints. See [Design System Consumption](./design-system-consumption.md) for token-based approaches.
+
+4. **Should I use mobile-first or desktop-first CSS?**
+   Mobile-first for most projects—it forces content prioritization and aligns with Tailwind's default modifiers (`sm:`, `md:`, `lg:` add styles as viewport grows). Desktop-first only if 70%+ of your audience uses desktop. For layout shift concerns, see [Performance Optimization](../ui-systems-performance/performance-optimization.md).
+
+5. **How do I handle responsive images correctly?**
+   Use `srcset` and `sizes` for resolution switching (same image, different file sizes for different viewports). Use `<picture>` for art direction. Always include `width` and `height` attributes to prevent layout shift (CLS). See [Performance Optimization](../ui-systems-performance/performance-optimization.md) for image performance patterns.
+
+6. **When do breakpoints actually matter vs. being unnecessary?**
+   Breakpoints matter when: layout fundamentally restructures (sidebar becomes bottom nav), content reorganizes (tabs become accordion), or interaction patterns change (hover becomes tap). For accessibility of these pattern changes, see [Accessibility](./accessibility.md).
+
+7. **How do I test responsive behavior effectively?**
+   Test at edge viewports (320px, 375px, 768px, 1024px, 1440px) and between breakpoints (767px and 769px often reveal bugs). For visual regression testing across viewports, see [Testing and Storybook](./testing-and-storybook.md). For production monitoring, see [Observability](../ui-systems-performance/observability.md).
+
+8. **Should spacing be fluid or use fixed tokens?**
+   Fixed tokens for component-internal spacing (padding, gaps)—these need consistent rhythm and touch targets. Viewport-relative or stepped spacing for section-level spacing. See [Design System Consumption](./design-system-consumption.md) for token-only styling patterns.
+
+9. **How do container queries change responsive design?**
+   Container queries let components respond to their container's size, not the viewport. This enables truly reusable components—a Card can adapt based on whether it's in a sidebar or main content. See [Component Creation Workflows](./component-creation-workflows.md) for component reusability patterns.
+
+10. **What's the "breakpoint trap" and how do I avoid it?**
+    The trap: adding `sm:`, `md:`, `lg:`, `xl:` variants to every property because breakpoints exist. Avoid it by: using fluid values where appropriate, questioning whether each breakpoint variant is necessary. See [Codebase Conventions](./codebase-conventions.md) for establishing responsive design conventions.
+
+---
+
+### 7. accessibility.md
+
+**Current Title:** "Accessibility"
+
+**Suggested Title:** "Accessible React Components: Semantic HTML, ARIA Patterns, and Keyboard Navigation"
+
+**Current Description:** "Accessible components aren't an afterthought—they're a byproduct of good structure. Learn semantic HTML, ARIA patterns, keyboard navigation, and focus management."
+
+**Suggested Description:** "Accessibility isn't a checklist—it's architecture. Learn semantic HTML defaults, ARIA patterns, keyboard navigation, and focus management for React components."
+
+**Current Keywords:**
+```
+accessibility, a11y, aria, semantic html, keyboard navigation, focus management, screen readers
+```
+
+**Suggested Keywords:**
+```
+react accessibility best practices,
+semantic html components,
+aria attributes react,
+keyboard navigation react,
+focus management react,
+accessible component library,
+screen reader testing,
+wcag react components
+```
+
+**Suggested FAQs:**
+
+1. **When should I use ARIA attributes vs. semantic HTML?**
+   Semantic HTML first—always. A `<button>` is automatically focusable, keyboard-activatable, and announced correctly. Use ARIA only when native elements don't exist (custom tabs, comboboxes, live regions). See [Component API Design](./component-api-design.md) for how props should expose semantic options, not implementation details.
+
+2. **What's the difference between `aria-label`, `aria-labelledby`, and `aria-describedby`?**
+   `aria-label`: provides accessible name as a string directly. `aria-labelledby`: references another element's ID for the accessible name. `aria-describedby`: provides supplementary description (like help text). Use `aria-labelledby` when the label is visible; `aria-label` for icon-only buttons.
+
+3. **How do I make icon-only buttons accessible?**
+   Three options: (1) visually hidden text with `sr-only` class, (2) `aria-label` on the button, (3) tooltip that also serves as accessible name. Always hide decorative icons with `aria-hidden="true"`. See [Design System Consumption](./design-system-consumption.md) for how system components should handle this by default.
+
+4. **Should I remove focus outlines for better design?**
+   Never remove focus indicators entirely—they're essential for keyboard users. Use `:focus-visible` to show outlines only for keyboard navigation. See [Design System Consumption](./design-system-consumption.md) for how focus styles should be defined in design tokens.
+
+5. **How do I implement keyboard navigation for custom components?**
+   Follow established patterns: Arrow keys for navigation within groups (menus, tabs), Enter/Space for activation, Escape to close overlays, Tab to move between interactive elements. See [Testing and Storybook](./testing-and-storybook.md) for testing keyboard interactions in stories.
+
+6. **What's focus trapping and when do I need it?**
+   Focus trapping keeps keyboard focus inside a container (typically modals/dialogs). When a modal opens, Tab should cycle within the modal, not escape to the page behind. For state management of modal visibility, see [State Management at Scale](../ui-systems-performance/state-management-at-scale.md).
+
+7. **How do I handle focus management during navigation?**
+   When opening: move focus into the new surface (first focusable element or the container itself). When closing: return focus to the trigger element. For SPA navigation patterns, see [Performance Optimization](../ui-systems-performance/performance-optimization.md) for how navigation affects perceived performance.
+
+8. **What accessibility issues only appear at scale?**
+   Common at-scale issues: inconsistent heading hierarchy, duplicate IDs breaking label associations, inconsistent keyboard patterns between similar components. See [Codebase Conventions](./codebase-conventions.md) for conventions that prevent these at-scale issues.
+
+9. **How do I test accessibility during development?**
+   Layers: (1) browser DevTools accessibility panel, (2) axe-core extension, (3) keyboard-only navigation testing, (4) screen reader testing. See [Testing and Storybook](./testing-and-storybook.md) for integrating a11y testing into Storybook. For production monitoring, see [Observability](../ui-systems-performance/observability.md).
+
+10. **What's the 80/20 rule for accessibility?**
+    Approximately 80% of accessibility comes from using semantic HTML correctly—buttons, links, headings, lists, landmarks. The remaining 20% requires ARIA and JavaScript for complex interactions. See [Component Creation Workflows](./component-creation-workflows.md) for choosing the right elements from the start.
+
+---
+
+### 8. codebase-conventions.md
+
+**Current Title:** "Codebase Conventions"
+
+**Suggested Title:** "Frontend Codebase Conventions: File Structure, Naming, and Patterns That Scale"
+
+**Current Description:** "Conventions aren't preferences—they're constraints that prevent failure modes. Learn file structure, naming patterns, and composition rules that scale."
+
+**Suggested Description:** "Conventions prevent failure modes, not just enforce style. Learn file structure, naming patterns, barrel exports, and composition rules that scale across teams."
+
+**Current Keywords:**
+```
+codebase conventions, file structure, naming conventions, code organization, frontend architecture, component organization, project structure
+```
+
+**Suggested Keywords:**
+```
+react project structure,
+frontend file organization,
+component naming conventions,
+barrel exports typescript,
+feature folder structure,
+react codebase architecture,
+monorepo component organization,
+frontend code conventions
+```
+
+**Suggested FAQs:**
+
+1. **Should I organize by feature or by type (components/, hooks/, utils/)?**
+   Feature-first for product code—each feature contains its components, hooks, and utilities together. Type-first only for truly shared code. See [Component Creation Workflows](./component-creation-workflows.md) for when components should be local vs. shared.
+
+2. **What naming convention should I use for component files?**
+   PascalCase for component files and exports: `UserProfile.tsx` exports `function UserProfile`. Match filename to export exactly. Use `index.ts` only for re-exports, not as the component file itself. For prop naming, see [Component API Design](./component-api-design.md).
+
+3. **Are barrel files (index.ts re-exports) good or bad?**
+   It depends. Good for public APIs (design system packages where you control the interface). Often harmful for application code—they defeat tree-shaking, create circular dependency risks. For performance implications, see [Performance Optimization](../ui-systems-performance/performance-optimization.md).
+
+4. **How do I know if a convention matters or is just preference?**
+   Conventions matter if violating them causes: bugs, confusion for new developers, maintenance burden, or failure modes. "Colocate tests with source files" prevents orphaned tests—see [Testing and Storybook](./testing-and-storybook.md) for test organization patterns.
+
+5. **What's the component folder pattern and when should I use it?**
+   Each component gets a folder: `ComponentName/ComponentName.tsx`, `ComponentName.test.tsx`, `ComponentName.stories.tsx`, `index.ts`. Use it when components have related files. See [Testing and Storybook](./testing-and-storybook.md) for colocating stories.
+
+6. **How do I prevent naming conflicts across features?**
+   Use specific, namespaced names: `ProductCard`, `UserCard` instead of just `Card` in different features. If both features need a generic Card, it belongs in shared components. See [Design System Consumption](./design-system-consumption.md) for design system component naming.
+
+7. **Where should TypeScript types live?**
+   Colocate types with the code that uses them when possible. Shared types belong in a central `types/` folder. See [Data Contracts](./data-contracts.md) for organizing data types and [Component API Design](./component-api-design.md) for prop types.
+
+8. **What file structure patterns prevent circular dependencies?**
+   Layered architecture: higher layers import from lower, never the reverse. Features don't import from each other—shared code lives in a common layer. See [Data Contracts](./data-contracts.md) for keeping mapping layers independent.
+
+9. **How do I enforce conventions across a team?**
+   Multiple layers: (1) ESLint/Prettier for automated enforcement, (2) documented conventions in the repository, (3) code review checklist, (4) file structure linting. See [Design System Consumption](./design-system-consumption.md) for linting design token usage.
+
+10. **What happens when conventions conflict with rapid development?**
+    Conventions save time in the long run but can slow initial development. For rapid prototyping: relax conventions temporarily but schedule cleanup. See [Testing and Storybook](./testing-and-storybook.md) for how stories can capture intended patterns even during rapid development.
+
+---
+
+### 9. testing-and-storybook.md
+
+**Current Title:** "Testing and Storybook Contracts"
+
+**Suggested Title:** "Storybook as a Contract Layer: Fixtures, Visual Testing, and Executable Specifications"
+
+**Current Description:** "Stories aren't just visual documentation—they're executable contracts. Learn how to use Storybook as a verification layer with deterministic fixtures and clear data boundaries."
+
+**Suggested Description:** "Stories aren't documentation—they're contracts. Learn deterministic fixtures, visual regression testing, and how Storybook becomes your component verification layer."
+
+**Current Keywords:**
+```
+storybook, component testing, visual testing, fixtures, test contracts, frontend testing, react storybook
+```
+
+**Suggested Keywords:**
+```
+storybook testing best practices,
+visual regression testing storybook,
+storybook fixtures patterns,
+component story format csf,
+chromatic visual testing,
+storybook interaction testing,
+deterministic test data,
+storybook as documentation
+```
+
+**Suggested FAQs:**
+
+1. **What's the difference between stories and unit tests?**
+   Stories verify visual output and behavior for specific prop combinations—they're executable specifications of "what this looks like." Unit tests verify logic and edge cases programmatically. For component logic that needs unit testing, see how [Data Contracts](./data-contracts.md) recommends testing mapping layers.
+
+2. **Should I use random data (faker) in Storybook fixtures?**
+   No for production stories. Random data breaks visual regression tests, makes debugging harder, and prevents reproducibility. Use deterministic fixtures with factory functions. See [Data Contracts](./data-contracts.md) for how fixtures should mirror real data shapes.
+
+3. **How do I create deterministic fixtures for stories?**
+   Create factory functions: `const mockUser = (overrides = {}) => ({ id: 'user-1', name: 'Jane Smith', avatar: '/fixtures/avatar.png', ...overrides })`. See [Codebase Conventions](./codebase-conventions.md) for organizing fixtures alongside components.
+
+4. **How many stories should each component have?**
+   Cover: (1) default/primary state, (2) all visual variants (see [Component API Design](./component-api-design.md)), (3) key interactive states (loading, error, empty), (4) edge cases (long text, missing optional data). Focus on states users actually encounter.
+
+5. **How do I test user interactions in Storybook?**
+   Use the `play` function with `@storybook/testing-library`. Test keyboard interactions for [Accessibility](./accessibility.md). Write interactions that click, type, and assert—these run automatically and catch behavior regressions.
+
+6. **When should I use Chromatic vs. local Storybook testing?**
+   Local Storybook for development iteration—see changes immediately. Chromatic (or Percy) for CI visual regression testing. For production monitoring beyond CI, see [Observability](../ui-systems-performance/observability.md).
+
+7. **What's the relationship between stories and data contracts?**
+   Story fixtures should reflect real data shapes—the post-mapping shape that components actually receive. See [Data Contracts](./data-contracts.md) for mapping layer patterns. Stories test the component contract, not the API contract.
+
+8. **How do I organize stories for complex components?**
+   Group by category: Primary use cases first, then states (loading, error, disabled), then sizes/variants, then edge cases. See [Codebase Conventions](./codebase-conventions.md) for file organization patterns.
+
+9. **Should stories be documentation or tests?**
+   Both. Stories document supported states and verify those states remain stable. The shift from "documentation mindset" to "contract mindset" is key. See [Component API Design](./component-api-design.md) for how stories demonstrate the component's API contract.
+
+10. **How do I prevent stories from becoming stale?**
+    Keep stories close to components (see [Codebase Conventions](./codebase-conventions.md) for colocation patterns). Use TypeScript for story args so prop changes surface in stories. See [Accessibility](./accessibility.md) for accessibility checks that should run on every story.
+
+---
+
+## UI Systems Performance Series (11 Documents)
+
+---
+
+### 1. introduction.md
+
+**Current Title:** "System Design & Architecture: An Introduction"
+
+**Suggested Title:** "Frontend Systems Design: Distributed Systems Thinking for Web Applications"
+
+**Current Description:** "A 10-part series that reframes frontend development through a systems design lens, covering state management, caching, performance, security, and more."
+
+**Suggested Description:** "Frontend apps are distributed systems. This 10-part series covers state replication, caching, async patterns, security, and performance from a systems design perspective."
+
+**Current Keywords:**
+```
+frontend systems design, distributed systems, frontend architecture, systems thinking, web development, system design
+```
+
+**Suggested Keywords:**
+```
+frontend systems design,
+distributed systems frontend,
+frontend architecture patterns,
+web application architecture,
+systems thinking javascript,
+frontend system design interview,
+browser as distributed system,
+frontend engineering principles
+```
+
+**Suggested FAQs:**
+
+1. **Why should frontend developers learn systems design?**
+   The browser is a distributed system—it replicates server data, handles network partitions (offline mode), and resolves conflicts when state diverges. See [State Management at Scale](./state-management-at-scale.md) for replication patterns and [Consistency and Failure Handling](./consistency-and-failure-handling.md) for offline-first architecture.
+
+2. **How is frontend systems design different from backend?**
+   Same problems, different constraints. Backend optimizes for throughput and correctness. Frontend must optimize for correctness under perception and latency—see [Human Perception](./human-perception.md) for why a 500ms block feels broken even when metrics are "acceptable."
+
+3. **Is this series for junior or senior developers?**
+   Both benefit differently. Juniors get mental models for concepts they're already using ([State Management](./state-management-at-scale.md), [Caching](./caching-strategies.md), [Async Operations](./asynchronous-operations.md)). Seniors get a structured framework for trade-offs they've learned through experience.
+
+4. **Do I need to read the series in order?**
+   The series builds progressively, with [Human Perception](./human-perception.md) as the capstone. But each document stands alone. Start with your current pain point: async bugs → [Asynchronous Operations](./asynchronous-operations.md), performance → [Performance Optimization](./performance-optimization.md).
+
+5. **What's the "perception gap" mentioned in the introduction?**
+   The gap between technical metrics (LCP 2.5s, API 200ms) and user experience ("this feels sluggish"). See [Human Perception](./human-perception.md) for perception budgets and [Observability](./observability.md) for measuring what users actually experience.
+
+6. **How do these concepts apply to my specific framework (React, Vue, Svelte)?**
+   The systems concepts—state replication, caching, failure handling—are framework-agnostic. For framework-specific component patterns, see the [Best Practices series](../best-practices/introduction.md) which covers React examples that apply to any component model.
+
+7. **Is this relevant for simple websites or only complex web apps?**
+   Even simple sites face these issues: caching decisions (see [Caching Strategies](./caching-strategies.md)), loading states (see [Human Perception](./human-perception.md)), error handling (see [Consistency and Failure Handling](./consistency-and-failure-handling.md)). The principles apply universally.
+
+8. **How does this relate to backend system design interviews?**
+   Frontend system design is increasingly part of technical interviews. Understanding replication (see [State Management](./state-management-at-scale.md)), caching (see [Caching Strategies](./caching-strategies.md)), and failure handling prepares you for these discussions with frontend-specific depth.
+
+9. **What tools or libraries implement these concepts?**
+   TanStack Query implements caching and revalidation patterns (see [Caching Strategies](./caching-strategies.md)). Zustand/Redux implement state management (see [State Management at Scale](./state-management-at-scale.md)). Understanding the underlying concepts helps you use these tools correctly.
+
+10. **How does Bitloops relate to these systems concepts?**
+    Bitloops generates code that applies these concepts by default: proper loading states (see [Human Perception](./human-perception.md)), data contracts (see [Data Contracts](../best-practices/data-contracts.md)), accessible components (see [Accessibility](../best-practices/accessibility.md)).
+
+---
+
+### 2. state-management-at-scale.md
+
+**Current Title:** "State Management at Scale"
+
+**Suggested Title:** "State Management as Replication: Sources of Truth, Sync, and Conflict Resolution"
+
+**Current Description:** "Understanding state management as replication design - keeping client replicas synchronized with server sources of truth."
+
+**Suggested Description:** "State management isn't Redux vs. Zustand—it's replication design. Learn sources of truth, client-server sync, cross-tab coordination, and conflict resolution patterns."
+
+**Current Keywords:**
+```
+state management, redux, zustand, react state, global state, state synchronization, frontend state
+```
+
+**Suggested Keywords:**
+```
+react state management patterns,
+frontend state architecture,
+client server state sync,
+zustand vs redux vs tanstack query,
+cross tab state synchronization,
+state replication frontend,
+optimistic state updates,
+source of truth frontend
+```
+
+**Suggested FAQs:**
+
+1. **What are the four sources of truth in frontend applications?**
+   (1) Server: authoritative data (user profile, products). (2) URL: navigation state, shareable app state. (3) Local Storage/IndexedDB: persisted client state. (4) Memory: transient UI state. For caching server state, see [Caching Strategies](./caching-strategies.md). For offline persistence, see [Consistency and Failure Handling](./consistency-and-failure-handling.md).
+
+2. **What's the difference between server state and client state?**
+   Server state needs synchronization (user data, products, orders)—see [Caching Strategies](./caching-strategies.md). Client state is UI-only (modal visibility, accordion expansion). For how this affects component design, see [Component API Design](../best-practices/component-api-design.md).
+
+3. **When should I use Redux vs. Zustand vs. TanStack Query?**
+   TanStack Query (or SWR) for server state—see [Caching Strategies](./caching-strategies.md) for caching patterns. Zustand or Redux for complex client state. useState/useReducer for local component state. Most apps need all three patterns, not one "winner."
+
+4. **How do I keep state synchronized across browser tabs?**
+   Use BroadcastChannel API (modern) or localStorage events (legacy) for cross-tab communication. Critical for: auth state (see [Security Boundaries](./security-boundaries.md)), cart/selection state, real-time data. Don't sync everything—only state users expect to be consistent.
+
+5. **What is "state tearing" and how do I prevent it?**
+   State tearing occurs when a React render uses inconsistent state because an external store updated mid-render. `useSyncExternalStore` (React 18+) solves this. For related async state issues, see [Asynchronous Operations](./asynchronous-operations.md).
+
+6. **What's the difference between optimistic updates and server state caching?**
+   Caching stores server responses for later reuse (see [Caching Strategies](./caching-strategies.md)). Optimistic updates show expected results before confirmation (see [Consistency and Failure Handling](./consistency-and-failure-handling.md) for when to use optimistic vs. pessimistic patterns).
+
+7. **How do I handle conflicts when local and server state diverge?**
+   Strategies: last-write-wins, server-authoritative, merge, or user-mediated conflict UI. See [Consistency and Failure Handling](./consistency-and-failure-handling.md) for reconciliation strategies and [Human Perception](./human-perception.md) for communicating conflicts to users.
+
+8. **When should state live in the URL vs. in memory?**
+   URL state for: navigation, shareable application state (search filters, pagination). Memory for: transient UI state. For performance implications of URL state, see [Performance Optimization](./performance-optimization.md).
+
+9. **How do I debug state management issues?**
+   Use dev tools: Redux DevTools, React DevTools, TanStack Query DevTools. Log state transitions. For production debugging, see [Observability](./observability.md) for correlation IDs and distributed tracing.
+
+10. **What causes "stale closure" bugs in state management?**
+    Closures capture state values at creation time. Related: race conditions in async operations—see [Asynchronous Operations](./asynchronous-operations.md) for commit guards and request cancellation patterns that prevent stale data issues.
+
+---
+
+### 3. caching-strategies.md
+
+**Current Title:** "Caching Strategies"
+
+**Suggested Title:** "Frontend Caching: Browser Cache Stack, Invalidation Strategies, and Security Boundaries"
+
+**Current Description:** "Cache lifecycle design - understanding when stale data is acceptable, invalidation strategies, and cache layers in frontend applications."
+
+**Suggested Description:** "Every cache is a bet. Learn the browser cache stack (memory, HTTP, Service Worker, CDN), stale-while-revalidate, cache invalidation, and security implications."
+
+**Current Keywords:**
+```
+caching, cache invalidation, http cache, service worker cache, frontend caching, stale while revalidate, cache strategies
+```
+
+**Suggested Keywords:**
+```
+frontend caching strategy,
+browser cache explained,
+stale while revalidate pattern,
+service worker cache api,
+http cache headers frontend,
+cache invalidation strategies,
+tanstack query cache,
+indexeddb caching patterns
+```
+
+**Suggested FAQs:**
+
+1. **What are the layers of the browser cache stack?**
+   From fastest to slowest: (1) Memory/application cache. (2) HTTP cache. (3) Service Worker cache. (4) CDN/edge cache (see [Distributed Systems](./distributed-systems.md)). (5) Origin server. Each layer trades freshness for speed. For HTTP headers, see [Network Protocols](./network-protocols.md).
+
+2. **What's the difference between no-cache and no-store?**
+   `no-cache`: browser can store but must revalidate. `no-store`: browser must not store at all. Use `no-store` for sensitive data—see [Security Boundaries](./security-boundaries.md) for token storage patterns. For header syntax, see [Network Protocols](./network-protocols.md).
+
+3. **When should I use stale-while-revalidate?**
+   When showing slightly stale data is acceptable while fetching fresh data in background. For user-facing implications, see [Human Perception](./human-perception.md) for how staleness affects perceived performance. Bad for: inventory counts, prices at checkout.
+
+4. **How do I invalidate cached data when it changes?**
+   Strategies: (1) Time-based (TTL). (2) Event-based via WebSocket/SSE—see [Network Protocols](./network-protocols.md). (3) Version-based URLs—see [Distributed Systems](./distributed-systems.md) for CDN invalidation. Choose based on freshness requirements.
+
+5. **Should I cache API responses in JavaScript or rely on HTTP cache?**
+   Both—they're complementary. HTTP cache handles the network layer (see [Network Protocols](./network-protocols.md)). JavaScript cache (TanStack Query, SWR) handles application layer. For state management integration, see [State Management at Scale](./state-management-at-scale.md).
+
+6. **What are the security risks of caching?**
+   Major risks: caching authenticated responses, sensitive data persisting after logout, cross-user data leakage. See [Security Boundaries](./security-boundaries.md) for token storage and [Distributed Systems](./distributed-systems.md) for CDN security considerations.
+
+7. **How does cache invalidation work with immutable assets?**
+   Immutable assets (JS, CSS with content hashes) can be cached forever (`max-age=31536000, immutable`). When content changes, the filename changes. For bundle optimization, see [Performance Optimization](./performance-optimization.md).
+
+8. **What's cache key fragmentation and why does it matter?**
+   Cache keys determine what's cached separately. Too many key factors fragment the cache—low hit rates, high storage. See [Distributed Systems](./distributed-systems.md) for CDN cache key design.
+
+9. **How do I cache for offline support?**
+   Service Worker + Cache API for static assets and API responses. IndexedDB for structured data. See [Consistency and Failure Handling](./consistency-and-failure-handling.md) for offline-first architecture patterns.
+
+10. **What's the cost model for caching decisions?**
+    Every cache is a bet: cost of serving stale data vs. cost of fetching fresh data. For how staleness affects user experience, see [Human Perception](./human-perception.md). For measuring cache effectiveness, see [Observability](./observability.md).
+
+---
+
+### 4. asynchronous-operations.md
+
+**Current Title:** "Asynchronous Operations"
+
+**Suggested Title:** "Async Operations in React: Race Conditions, Cancellation, and Commit Guards"
+
+**Current Description:** "Handling race conditions, operation scopes, and commit guards to prevent async bugs in frontend applications."
+
+**Suggested Description:** "Async bugs are state bugs—stale results overwriting fresh data. Learn operation scopes, commit guards, request cancellation, and deduplication patterns."
+
+**Current Keywords:**
+```
+async operations, race conditions, abort controller, async state, promises, concurrent requests, async patterns
+```
+
+**Suggested Keywords:**
+```
+react race condition fix,
+abort controller react,
+async state management,
+request deduplication pattern,
+stale closure react,
+cancel fetch request,
+async operation lifecycle,
+concurrent request handling
+```
+
+**Suggested FAQs:**
+
+1. **What causes race conditions in React components?**
+   Race conditions occur when async operations complete in different order than they started. User types "abc", then "ab"—if the "abc" search returns after "ab", you display wrong results. Related: [State Management at Scale](./state-management-at-scale.md) for state consistency patterns.
+
+2. **How do I cancel fetch requests when a component unmounts?**
+   Use AbortController: create a controller, pass its signal to fetch, call controller.abort() in useEffect cleanup. For fetch patterns and timeouts, see [Network Protocols](./network-protocols.md).
+
+3. **What's a commit guard and when do I need one?**
+   A commit guard verifies that an async result is still relevant before applying it to state. Compare request timestamps, version numbers, or request IDs. Related: [Consistency and Failure Handling](./consistency-and-failure-handling.md) for version-based conflict resolution.
+
+4. **How do I deduplicate identical API requests?**
+   Store pending promises by request key. If a request with the same key is already in flight, return the existing promise. TanStack Query and SWR do this automatically—see [Caching Strategies](./caching-strategies.md) for application-level caching patterns.
+
+5. **What's the difference between cancellation and ignoring stale results?**
+   Cancellation (AbortController) stops the network request—saves bandwidth, frees connections. Ignoring just discards results client-side. For network cost considerations, see [Performance Optimization](./performance-optimization.md).
+
+6. **How do I handle dependent async operations (A must complete before B)?**
+   Use async/await for sequential operations. For complex dependency chains, consider state machines (XState). For perceived performance during multi-step operations, see [Human Perception](./human-perception.md).
+
+7. **What are operation scopes and why do they matter?**
+   Operation scope is the context in which an async result is valid. A search result is scoped to the query that produced it. When scope changes, results from old scope should be discarded. Related: [State Management at Scale](./state-management-at-scale.md) for sources of truth.
+
+8. **How do I implement retry with exponential backoff?**
+   On failure, wait before retrying: delay = baseDelay * 2^attempt + random jitter. Only retry transient failures (5xx, network errors)—see [Network Protocols](./network-protocols.md) for which HTTP errors are retryable.
+
+9. **What's the difference between throttling and debouncing?**
+   Throttle: execute at most once per interval (rate limiting). Debounce: execute only after activity stops for an interval. For how this affects perceived responsiveness, see [Human Perception](./human-perception.md).
+
+10. **How do I debug async state corruption?**
+    Add logging with timestamps and operation IDs. For production debugging, see [Observability](./observability.md) for correlation IDs and distributed tracing that connects frontend operations to backend requests.
+
+---
+
+### 5. performance-optimization.md
+
+**Current Title:** "Performance Optimization"
+
+**Suggested Title:** "Frontend Performance: Core Web Vitals, Critical Path, and Resource Optimization"
+
+**Current Description:** "Resource allocation under constraints - shipping less, scheduling better, and rendering less for optimal frontend performance."
+
+**Suggested Description:** "Performance is a constraint, not a feature. Learn the critical rendering path, Core Web Vitals optimization, bundle splitting, and rendering performance patterns."
+
+**Current Keywords:**
+```
+performance, core web vitals, lcp, inp, cls, bundle size, rendering performance, frontend optimization
+```
+
+**Suggested Keywords:**
+```
+frontend performance optimization,
+core web vitals optimization,
+react performance best practices,
+javascript bundle size reduction,
+largest contentful paint improve,
+interaction to next paint fix,
+cumulative layout shift prevent,
+critical rendering path
+```
+
+**Suggested FAQs:**
+
+1. **What are Core Web Vitals and what scores should I target?**
+   LCP (Largest Contentful Paint): < 2.5s measures loading. INP (Interaction to Next Paint): < 200ms measures interactivity. CLS (Cumulative Layout Shift): < 0.1 measures visual stability. For monitoring these in production, see [Observability](./observability.md). For how metrics relate to user experience, see [Human Perception](./human-perception.md).
+
+2. **What's the critical rendering path and why does it matter?**
+   The sequence of steps before the first pixel: HTML parsing → DOM, CSS parsing → CSSOM, JavaScript execution, render tree → layout → paint. For CDN delivery optimization, see [Distributed Systems](./distributed-systems.md). For network layer details, see [Network Protocols](./network-protocols.md).
+
+3. **How do I reduce my JavaScript bundle size?**
+   Strategies: code splitting with dynamic imports, tree shaking, analyze with webpack-bundle-analyzer. For how bundle size affects loading experience, see [Human Perception](./human-perception.md). For caching strategies for static assets, see [Caching Strategies](./caching-strategies.md).
+
+4. **What causes layout shift (CLS) and how do I fix it?**
+   Causes: images without dimensions, fonts that swap and resize, dynamically injected content. For responsive image patterns, see [Responsive Behavior](../best-practices/responsive-behavior.md). Layout stability directly affects perceived performance—see [Human Perception](./human-perception.md).
+
+5. **What's the difference between lab and field performance metrics?**
+   Lab metrics: controlled synthetic tests (Lighthouse). Field metrics: real users on real devices (RUM). See [Observability](./observability.md) for RUM implementation. They often differ significantly—optimize for field, gate on lab.
+
+6. **Should I use React.memo and useMemo everywhere?**
+   No. Memoization has overhead. Use when: component re-renders frequently with same props, computation is genuinely expensive, you've profiled and confirmed the benefit. For state management patterns that reduce unnecessary renders, see [State Management at Scale](./state-management-at-scale.md).
+
+7. **How do I optimize images for performance?**
+   Use modern formats (WebP, AVIF). Serve appropriate sizes with srcset/sizes—see [Responsive Behavior](../best-practices/responsive-behavior.md). Lazy load below-fold images. Use `fetchpriority="high"` for LCP images. Consider blur placeholders for perceived performance—see [Human Perception](./human-perception.md).
+
+8. **What's the performance pipeline model?**
+   Five stages: Delivery (see [Network Protocols](./network-protocols.md)), Boot, Render, Interact, Update. Every optimization maps to a stage. Ship less (delivery), schedule better (boot), render less (render/update). For CDN optimization of delivery, see [Distributed Systems](./distributed-systems.md).
+
+9. **How do I set performance budgets?**
+   Derive from constraints: target device, target network, target UX (LCP < 2.5s). Convert to byte budgets. Enforce in CI. For monitoring budget adherence in production, see [Observability](./observability.md). For perception thresholds, see [Human Perception](./human-perception.md).
+
+10. **What's the most common performance mistake in React apps?**
+    Over-fetching and under-caching. See [Caching Strategies](./caching-strategies.md) for proper caching patterns. See [Asynchronous Operations](./asynchronous-operations.md) for request deduplication. Profile before optimizing render performance.
+
+---
+
+### 6. distributed-systems.md
+
+**Current Title:** "Distributed Systems (CDNs & Edge)"
+
+**Suggested Title:** "Edge Computing for Frontend: CDN Architecture, Cache Keys, and Execution Location"
+
+**Current Description:** "Understanding edge computing, CDN architecture, and where code should execute for optimal latency and user experience."
+
+**Suggested Description:** "Where should code execute—client, edge, or origin? Learn CDN cache architecture, cache key design, edge computing patterns, and latency optimization."
+
+**Current Keywords:**
+```
+cdn, edge computing, distributed systems, cache invalidation, edge functions, latency optimization, content delivery
+```
+
+**Suggested Keywords:**
+```
+cdn caching frontend,
+edge computing patterns,
+vercel edge functions,
+cloudflare workers frontend,
+cdn cache key design,
+origin shield cdn,
+edge vs serverless,
+global latency optimization
+```
+
+**Suggested FAQs:**
+
+1. **What's the execution spectrum: client vs. edge vs. origin?**
+   Client (browser): zero network latency, full browser APIs. Edge (CDN PoP): 10-50ms latency, limited runtime. Origin (your server): 50-300ms+ latency, full capabilities. For network layer details, see [Network Protocols](./network-protocols.md). For client-side state, see [State Management at Scale](./state-management-at-scale.md).
+
+2. **What's the difference between edge functions and serverless functions?**
+   Edge functions run at CDN nodes globally (low latency, constrained runtime). Serverless functions run in specific cloud regions (more compute, higher latency). For caching patterns at each layer, see [Caching Strategies](./caching-strategies.md).
+
+3. **How do I design cache keys for personalized content?**
+   Include only factors that vary the response: country, language, A/B variant—not user ID. See [Caching Strategies](./caching-strategies.md) for cache key fragmentation. For security implications, see [Security Boundaries](./security-boundaries.md).
+
+4. **What is origin shield and when should I use it?**
+   Origin shield is a designated CDN PoP that consolidates requests to your origin. Protects origin from thundering herd. Related: [Caching Strategies](./caching-strategies.md) for browser-level caching that further reduces origin load.
+
+5. **How do I invalidate CDN cache when content changes?**
+   Options: TTL expiration, purge API, surrogate keys, versioned URLs (most reliable). For browser cache invalidation, see [Caching Strategies](./caching-strategies.md). For HTTP headers that control caching, see [Network Protocols](./network-protocols.md).
+
+6. **When should content be cached at CDN vs. fetched fresh?**
+   CDN cache: static assets, public content with acceptable staleness. Fetch fresh: user-specific data, prices at checkout. For consistency requirements, see [Consistency and Failure Handling](./consistency-and-failure-handling.md). For user perception of staleness, see [Human Perception](./human-perception.md).
+
+7. **What are the security risks of CDN caching?**
+   Risks: cross-user data leakage, cache poisoning, sensitive data persisting. See [Security Boundaries](./security-boundaries.md) for token storage patterns. Use `Cache-Control: private` for user-specific data—see [Network Protocols](./network-protocols.md) for header syntax.
+
+8. **How do I debug CDN caching issues?**
+   Check response headers: cache status (HIT/MISS/BYPASS), Age, X-Cache headers. For production monitoring and debugging, see [Observability](./observability.md). Test from multiple locations.
+
+9. **What's stale-while-revalidate at the CDN level?**
+   `Cache-Control: max-age=60, stale-while-revalidate=600`: serve cached response immediately, revalidate in background. See [Caching Strategies](./caching-strategies.md) for application-level stale-while-revalidate. For how staleness affects user experience, see [Human Perception](./human-perception.md).
+
+10. **How do I balance latency vs. consistency in distributed systems?**
+    Define per-resource. See [Consistency and Failure Handling](./consistency-and-failure-handling.md) for consistency models. For performance implications, see [Performance Optimization](./performance-optimization.md). For user perception of latency, see [Human Perception](./human-perception.md).
+
+---
+
+### 7. network-protocols.md
+
+**Current Title:** "Network Protocols"
+
+**Suggested Title:** "HTTP for Frontend Developers: Methods, Caching Headers, CORS, and Failure Handling"
+
+**Current Description:** "HTTP as a contract - understanding methods, status codes, caching headers, CORS, and designing robust API requests."
+
+**Suggested Description:** "HTTP isn't just transport—it's a contract. Learn method semantics, status codes, Cache-Control headers, CORS preflight, and retry patterns for frontend applications."
+
+**Current Keywords:**
+```
+http, network protocols, cors, rest api, fetch, request design
+```
+
+**Suggested Keywords:**
+```
+http methods frontend,
+cors explained simply,
+fetch api best practices,
+cache control headers guide,
+http status codes frontend,
+retry with exponential backoff,
+preflight request cors,
+http 2 http 3 frontend
+```
+
+**Suggested FAQs:**
+
+1. **Why do HTTP method semantics matter for frontend?**
+   Methods have meaning beyond "send request." GET is cacheable (see [Caching Strategies](./caching-strategies.md)); POST isn't. PUT is idempotent—see [Consistency and Failure Handling](./consistency-and-failure-handling.md) for idempotency keys. Using wrong methods breaks caching and retry safety.
+
+2. **When does CORS preflight happen?**
+   Preflight (OPTIONS request) happens for "non-simple" requests: custom headers (Authorization), Content-Type other than form-urlencoded. For security implications of CORS, see [Security Boundaries](./security-boundaries.md).
+
+3. **Why can't I read certain response headers in JavaScript?**
+   CORS restricts which headers JavaScript can access. For custom headers, the server must include them in `Access-Control-Expose-Headers`. For security context, see [Security Boundaries](./security-boundaries.md). For caching headers, see [Caching Strategies](./caching-strategies.md).
+
+4. **How should I implement retry logic for failed requests?**
+   Rules: retry only transient failures (5xx, network errors), use exponential backoff with jitter, set maximum retries. See [Asynchronous Operations](./asynchronous-operations.md) for request cancellation. See [Consistency and Failure Handling](./consistency-and-failure-handling.md) for idempotency keys to make retries safe.
+
+5. **What's the difference between HTTP/2 and HTTP/3?**
+   HTTP/2 multiplexes requests over single TCP connection. HTTP/3 uses QUIC (UDP-based), each stream independent. HTTP/3 performs better on lossy mobile networks. For CDN considerations, see [Distributed Systems](./distributed-systems.md).
+
+6. **How do I use Cache-Control headers effectively?**
+   Common patterns: `max-age=31536000, immutable` for versioned static assets. `no-store` for sensitive data (see [Security Boundaries](./security-boundaries.md)). See [Caching Strategies](./caching-strategies.md) for application-level caching.
+
+7. **What's the difference between timeout, abort, and error in fetch?**
+   Timeout: you set via AbortController. Abort: you call manually. Error: network failure. fetch doesn't have built-in timeout—see [Asynchronous Operations](./asynchronous-operations.md) for AbortController patterns.
+
+8. **How do connection costs affect frontend performance?**
+   New connection cost: DNS (20-120ms) + TCP handshake + TLS = 300-700ms. See [Performance Optimization](./performance-optimization.md) for the critical rendering path. See [Distributed Systems](./distributed-systems.md) for CDN edge locations that reduce latency.
+
+9. **When should I use WebSocket vs. Server-Sent Events vs. polling?**
+   WebSocket: bidirectional, real-time (chat). SSE: server→client only (notifications). For state synchronization over these protocols, see [State Management at Scale](./state-management-at-scale.md). For cache invalidation via events, see [Caching Strategies](./caching-strategies.md).
+
+10. **How do I debug network issues in production?**
+    Instrument with: request/response logging, timing data, correlation IDs. See [Observability](./observability.md) for distributed tracing. Use Server-Timing header to expose backend timing. Monitor error rates by endpoint.
+
+---
+
+### 8. security-boundaries.md
+
+**Current Title:** "Security Boundaries"
+
+**Suggested Title:** "Frontend Security Architecture: XSS, CSRF, CSP, and Token Storage Patterns"
+
+**Current Description:** "Blast radius design for frontend security - XSS, CSRF, CSP, token storage, and minimizing attack impact."
+
+**Suggested Description:** "Security isn't prevention—it's blast radius design. Learn XSS mitigation, CSRF protection, Content Security Policy, and where to store JWT tokens in SPAs."
+
+**Current Keywords:**
+```
+security, xss, csrf, csp, authentication, token storage
+```
+
+**Suggested Keywords:**
+```
+frontend security best practices,
+xss prevention react,
+csrf protection spa,
+content security policy guide,
+jwt token storage spa,
+httponly cookie vs localstorage,
+same origin policy explained,
+oauth pkce spa
+```
+
+**Suggested FAQs:**
+
+1. **What's "blast radius design" for security?**
+   Security isn't just preventing attacks—it's minimizing damage when attacks succeed. Design layers of defense where each limits blast radius. For related failure handling patterns, see [Consistency and Failure Handling](./consistency-and-failure-handling.md).
+
+2. **Where should I store JWT tokens in a React SPA?**
+   Recommended pattern: short-lived access tokens in memory, refresh tokens in HTTPOnly cookies with SameSite=Strict. For state management of auth state, see [State Management at Scale](./state-management-at-scale.md) for cross-tab synchronization of logout.
+
+3. **What's the difference between XSS and CSRF?**
+   XSS: attacker injects code that runs in your site's context. CSRF: attacker tricks browser into making authenticated requests. For validating user input, see [Data Contracts](../best-practices/data-contracts.md) for validation boundaries.
+
+4. **Does HTTPOnly prevent XSS attacks?**
+   No. HTTPOnly prevents cookie theft but XSS can still make authenticated requests. HTTPOnly limits blast radius; it doesn't prevent XSS. For caching implications of authentication, see [Caching Strategies](./caching-strategies.md).
+
+5. **How do I implement Content Security Policy (CSP)?**
+   Start with report-only mode to find violations. Remove inline scripts. Tighten progressively. For bundle optimization that reduces script sources, see [Performance Optimization](./performance-optimization.md).
+
+6. **What's the SameSite cookie attribute?**
+   SameSite controls when cookies are sent cross-site. `Strict`: never sent cross-site. `Lax`: sent on top-level navigation. Use `Strict` for auth cookies. For related CORS patterns, see [Network Protocols](./network-protocols.md).
+
+7. **How do I protect against third-party script risks?**
+   Third-party scripts run with your origin's privileges. Mitigations: Subresource Integrity (SRI), sandboxed iframes, strict CSP. For bundle size implications of third-party scripts, see [Performance Optimization](./performance-optimization.md).
+
+8. **What's the principle of least privilege for frontend?**
+   Give each part of the system minimum necessary access: short-lived tokens, scoped API permissions, restricted CSP. For how this applies to component design, see [Component API Design](../best-practices/component-api-design.md) for limiting prop exposure.
+
+9. **How do I handle logout securely?**
+   Clear all auth state: memory tokens, HTTPOnly cookies (server-side), localStorage. Broadcast logout to other tabs—see [State Management at Scale](./state-management-at-scale.md) for cross-tab communication. Server should invalidate refresh tokens.
+
+10. **What security headers should every frontend set?**
+    Essential headers: `Strict-Transport-Security`, `Content-Security-Policy`, `X-Frame-Options`, `X-Content-Type-Options: nosniff`. For caching headers, see [Network Protocols](./network-protocols.md). For CDN header configuration, see [Distributed Systems](./distributed-systems.md).
+
+---
+
+### 9. consistency-and-failure-handling.md
+
+**Current Title:** "Consistency Models & Failure Handling"
+
+**Suggested Title:** "Frontend Consistency: Optimistic UI, Offline-First Patterns, and Intent Preservation"
+
+**Current Description:** "Optimistic UI, intent preservation, offline-first patterns, and reconciliation strategies for resilient frontend applications."
+
+**Suggested Description:** "Networks fail. Users go offline. Learn optimistic UI, intent preservation with idempotency keys, offline queues, and reconciliation strategies for resilient frontends."
+
+**Current Keywords:**
+```
+consistency, failure handling, optimistic ui, offline first, error recovery
+```
+
+**Suggested Keywords:**
+```
+optimistic ui react,
+offline first web app,
+idempotency key frontend,
+intent preservation pattern,
+frontend error handling,
+conflict resolution frontend,
+eventual consistency ui,
+retry queue javascript
+```
+
+**Suggested FAQs:**
+
+1. **When should I use optimistic UI vs. wait for the server?**
+   Optimistic for reversible, low-stakes actions: likes, toggles, adding to cart. Pessimistic for irreversible, high-stakes actions: payment, delete. See [Human Perception](./human-perception.md) for how optimism affects perceived responsiveness.
+
+2. **What's an idempotency key and why do I need one?**
+   A unique ID sent with mutations so the server can deduplicate retries. Without it: network fails → client retries → action happens twice. For retry patterns, see [Asynchronous Operations](./asynchronous-operations.md). For HTTP method semantics, see [Network Protocols](./network-protocols.md).
+
+3. **How do I preserve user intent when the network fails?**
+   Intent preservation pattern: persist intent locally (IndexedDB) before network attempt, apply optimistic UI, retry with backoff. See [Caching Strategies](./caching-strategies.md) for offline caching patterns. See [Human Perception](./human-perception.md)—intent preservation is "non-negotiable."
+
+4. **What's the difference between eventual and strong consistency?**
+   Strong consistency: every read reflects the most recent write. Eventual consistency: reads may be temporarily stale but converge. For caching implications, see [Caching Strategies](./caching-strategies.md). For user perception of consistency, see [Human Perception](./human-perception.md).
+
+5. **How do I handle version conflicts when multiple users edit the same data?**
+   Strategies: last-write-wins, server-authoritative, field-level merge, user-mediated. For state management patterns, see [State Management at Scale](./state-management-at-scale.md). For communicating conflicts to users, see [Human Perception](./human-perception.md).
+
+6. **What causes "time travel" bugs where UI shows older data?**
+   Race conditions where older responses arrive after newer ones. Fix: version-gating. See [Asynchronous Operations](./asynchronous-operations.md) for commit guards. See [State Management at Scale](./state-management-at-scale.md) for state consistency patterns.
+
+7. **How do I implement offline-first architecture?**
+   Layers: local persistence (IndexedDB), intent queue with idempotency keys, sync engine, conflict resolution. See [Caching Strategies](./caching-strategies.md) for Service Worker patterns. See [State Management at Scale](./state-management-at-scale.md) for sources of truth.
+
+8. **How do I communicate failure states to users?**
+   Match communication to failure type: transient → silent retry, recoverable → inline notification, persistent → change UI affordance. See [Human Perception](./human-perception.md) for the six user-facing states every app should handle.
+
+9. **What's the "projection" mental model for state?**
+   State = projection of commands under unreliable delivery. This unifies optimistic UI, offline queues, retries, reconciliation. Related: [State Management at Scale](./state-management-at-scale.md) for replication design.
+
+10. **How do I test failure handling in the frontend?**
+    Simulate failures: network throttling, mock API errors, disable network. For production monitoring of failure rates, see [Observability](./observability.md). For testing component states, see [Testing and Storybook](../best-practices/testing-and-storybook.md) for error state stories.
+
+---
+
+### 10. observability.md
+
+**Current Title:** "Observability"
+
+**Suggested Title:** "Frontend Observability: RUM, Error Tracking, Distributed Tracing, and SLOs"
+
+**Current Description:** "Telemetry pipelines, Real User Monitoring, distributed tracing, and alerting strategies for frontend applications."
+
+**Suggested Description:** "You can't improve what you can't measure. Learn telemetry pipelines, Real User Monitoring, Core Web Vitals tracking, distributed tracing, and burn-rate alerting."
+
+**Current Keywords:**
+```
+observability, monitoring, rum, telemetry, alerting, distributed tracing
+```
+
+**Suggested Keywords:**
+```
+frontend observability guide,
+real user monitoring rum,
+frontend error tracking,
+distributed tracing frontend,
+core web vitals monitoring,
+sentry frontend setup,
+frontend slo sli,
+burn rate alerting
+```
+
+**Suggested FAQs:**
+
+1. **What's the difference between Real User Monitoring (RUM) and synthetic monitoring?**
+   RUM measures actual users on real devices—shows what users experience. Synthetic runs controlled tests (Lighthouse)—provides CI baselines. For performance metrics to track, see [Performance Optimization](./performance-optimization.md). For how metrics relate to experience, see [Human Perception](./human-perception.md).
+
+2. **What frontend SLIs (Service Level Indicators) should I track?**
+   Core SLIs: crash-free sessions (≥99.5%), error rate (<0.5%), LCP p75 (<2.5s), INP p75 (<200ms), CLS p75 (<0.1). For Core Web Vitals optimization, see [Performance Optimization](./performance-optimization.md). For perception-based targets, see [Human Perception](./human-perception.md).
+
+3. **How do I implement distributed tracing in the frontend?**
+   Generate trace IDs client-side, propagate via `traceparent` header. For HTTP header patterns, see [Network Protocols](./network-protocols.md). For async operation tracing, see [Asynchronous Operations](./asynchronous-operations.md).
+
+4. **What's burn-rate alerting and why is it better than threshold alerts?**
+   Burn rate measures how fast you're consuming error budget. Catches both spikes and slow leaks. For failure handling that affects error rates, see [Consistency and Failure Handling](./consistency-and-failure-handling.md).
+
+5. **What should I NOT log in frontend telemetry?**
+   Never log: passwords, tokens, cookies, full URLs with query strings, free-form user input. See [Security Boundaries](./security-boundaries.md) for sensitive data handling. Use allowlists (only log approved fields), not denylists.
+
+6. **How do I build a telemetry pipeline that doesn't impact performance?**
+   Buffer events in memory. Use sendBeacon for delivery. Use requestIdleCallback for non-critical telemetry. For performance budget implications, see [Performance Optimization](./performance-optimization.md).
+
+7. **How do I correlate frontend errors with backend issues?**
+   Propagate correlation IDs: generate client-side, send in request headers. See [Network Protocols](./network-protocols.md) for header patterns. See [Asynchronous Operations](./asynchronous-operations.md) for tracking operation lifecycles.
+
+8. **What's the investigation ladder for frontend incidents?**
+   Step through: confirm user impact, identify regression start, narrow scope (browsers, devices), correlate to backend (trace IDs), reproduce, fix. For testing failure states, see [Testing and Storybook](../best-practices/testing-and-storybook.md).
+
+9. **How do I avoid alert fatigue?**
+   Use burn-rate alerts instead of threshold alerts. Every alert should have a runbook. Alert on user-impacting symptoms—see [Human Perception](./human-perception.md) for what impacts user experience.
+
+10. **What observability tools should a frontend team use?**
+    Error tracking: Sentry, Bugsnag. RUM: web-vitals library. Synthetic: Lighthouse CI. Tracing: OpenTelemetry. For performance metrics to instrument, see [Performance Optimization](./performance-optimization.md). For caching metrics, see [Caching Strategies](./caching-strategies.md).
+
+---
+
+### 11. human-perception.md
+
+**Current Title:** "Human Perception"
+
+**Suggested Title:** "Perceived Performance: Loading States, Optimistic UI, and Perception Budgets"
+
+**Current Description:** "The capstone - understanding how technical metrics translate to perceived performance and user experience."
+
+**Suggested Description:** "A 2-second load can feel faster than 3 seconds. Learn perception budgets, phase-based delivery, skeleton screens, and the psychology of waiting in UI design."
+
+**Current Keywords:**
+```
+human perception, user experience, perceived performance, ux, loading states
+```
+
+**Suggested Keywords:**
+```
+perceived performance optimization,
+loading state ux patterns,
+skeleton screen best practices,
+optimistic ui patterns,
+perception budgets frontend,
+phase based page load,
+ux response time thresholds,
+psychological waiting time
+```
+
+**Suggested FAQs:**
+
+1. **Why does a 3-second load sometimes feel faster than 2 seconds?**
+   Perception depends on feedback, progress, and control—not just duration. A 3-second load with instant input acknowledgment, skeleton, and progressive content feels faster than 2 seconds of blank screen. For technical performance metrics, see [Performance Optimization](./performance-optimization.md).
+
+2. **What are perception budgets?**
+   Time allocations for interaction phases: <100ms for input acknowledgment, <300ms for meaningful response, <1s for critical content. For Core Web Vitals targets that align with these budgets, see [Performance Optimization](./performance-optimization.md). For monitoring these, see [Observability](./observability.md).
+
+3. **When should I use a skeleton screen vs. a spinner?**
+   Skeleton when layout is predictable and content-heavy. Spinner when layout varies or load is short (<200ms). For testing loading states in Storybook, see [Testing and Storybook](../best-practices/testing-and-storybook.md). For preventing layout shift, see [Performance Optimization](./performance-optimization.md).
+
+4. **Should I show a loading indicator immediately?**
+   No. Delay indicators by ~150ms. If the operation completes quickly, users never see the indicator. For async operation patterns that support this, see [Asynchronous Operations](./asynchronous-operations.md).
+
+5. **What's phase-based delivery?**
+   Loading in stages with specific budgets: acknowledge input (<100ms), stabilize layout (<300ms), deliver critical content (<1s). For network optimization that supports this, see [Performance Optimization](./performance-optimization.md). For CDN delivery, see [Distributed Systems](./distributed-systems.md).
+
+6. **How do I choose between optimistic and pessimistic UI?**
+   Match optimism to stakes. Low stakes + reversible → fully optimistic. High stakes + irreversible → pessimistic, wait for confirmation. For detailed patterns, see [Consistency and Failure Handling](./consistency-and-failure-handling.md).
+
+7. **What's intent preservation and why is it "non-negotiable"?**
+   User input is durable before network. The user's work must never be lost due to network issues. Persist intents locally before attempting delivery. See [Consistency and Failure Handling](./consistency-and-failure-handling.md) for idempotency keys. See [Caching Strategies](./caching-strategies.md) for offline persistence.
+
+8. **How do I debug "feels slow" when metrics look fine?**
+   Check perception phases: Is input acknowledged within 100ms? Is there visible feedback within 300ms? See [Observability](./observability.md) for RUM that captures real user experience. Check CLS—see [Performance Optimization](./performance-optimization.md).
+
+9. **What are the universal user-facing states every app should handle?**
+   Six states: Idle, Working, Pending, Succeeded, Failed, Degraded. See [Testing and Storybook](../best-practices/testing-and-storybook.md) for creating stories that cover these states. See [Consistency and Failure Handling](./consistency-and-failure-handling.md) for failure state patterns.
+
+10. **How does Human Perception connect to the rest of the systems series?**
+    Human Perception is the capstone. Every previous document's decisions affect perception: [State Management](./state-management-at-scale.md) (does data feel fresh?), [Caching](./caching-strategies.md) (does content feel instant?), [Async Operations](./asynchronous-operations.md) (does UI feel responsive?), [Performance](./performance-optimization.md) (do metrics reflect experience?), [Failure Handling](./consistency-and-failure-handling.md) (does the system feel reliable?).
+
+---
+
+## Implementation Notes
+
+### How to Apply These Changes
+
+1. **Titles:** Update the `title:` field in each document's frontmatter
+2. **Descriptions:** Update the `description:` field (keep under 160 characters)
+3. **Keywords:** Replace the `keywords:` array in frontmatter
+4. **FAQs:** Add a `## Frequently Asked Questions` section before the Summary section in each document
+
+### FAQ Formatting for Structured Data
+
+Format FAQs as H3 questions for potential structured data extraction:
+
+```markdown
+## Frequently Asked Questions
+
+### When should I use optimistic UI vs. wait for the server?
+
+Optimistic for reversible, low-stakes actions (like, toggle, add to cart). Pessimistic for irreversible, high-stakes actions (payment, delete account). If rollback would confuse or harm the user, wait.
+
+### What's an idempotency key and why do I need one?
+
+A unique ID sent with mutations so the server can deduplicate retries...
+```
+
+### Keyword Format in Frontmatter
+
+Use multi-line array format for readability:
+
+```yaml
+keywords:
+  [
+    primary keyword phrase,
+    secondary keyword phrase,
+    long tail keyword one,
+    long tail keyword two,
+    tool or framework name,
+    problem statement keyword,
+    solution keyword,
+    comparison keyword,
+  ]
+```
+
+---
+
+*End of SEO metadata recommendations.*
diff --git a/documentation/docs/frontend-copilot/Guides/adding-layout-containers.md b/documentation/docs/frontend-copilot/Guides/adding-layout-containers.md
new file mode 100644
index 00000000..4f92454b
--- /dev/null
+++ b/documentation/docs/frontend-copilot/Guides/adding-layout-containers.md
@@ -0,0 +1,129 @@
+---
+sidebar_position: 4
+sidebar_label: Adding Layout Containers
+title: "Adding Layout Containers"
+description: "Step-by-step guide to adding Layout Containers (wrapper divs) so Bitloops can generate cleaner, more intentional layout code."
+keywords:
+  [
+    layout containers,
+    divs,
+    grouping elements,
+    flex layout,
+    structure,
+  ]
+---
+
+# Adding Layout Containers
+
+This guide shows you how to add **Layout Containers** in Bitloops—intentional wrapper `div`s that define layout structure (flex/grid, spacing, alignment). We assume you’re signed in, inside a project, and you’re working from an imported design (or an existing component).
+
+Layout containers are where Bitloops becomes a true copilot: it can infer a lot from design, but **layout can be implemented in multiple valid ways**. Containers let you and Bitloops agree on the hierarchy that will produce clean, maintainable code.
+
+## Video walkthrough
+
+<!-- TODO: Replace with YouTube link -->
+- YouTube: https://www.youtube.com/watch?v=YOUR_VIDEO_ID
+
+:::tip
+Watch once end-to-end, then follow the steps below.
+:::
+
+## When to use this
+
+- The generated structure feels too flat (missing wrappers you’d write by hand)
+- Spacing/alignment is hard to express without a parent wrapper (`gap`, `items-*`, `justify-*`)
+- A snapshot doesn’t match well because grouping/hierarchy is unclear
+- You’re preparing a selection so “Create Component” produces a cleaner layout
+- You’re attaching snapshots (instances/variants) and want consistent structure across them
+
+## Before you start
+
+- You’re signed in to Bitloops
+- You have a project open
+- You can see the relevant UI in **Design View** or via a component’s **Snapshot View**
+- You have a clear intent (row vs column, what should move together, what should wrap together)
+
+## How it works
+
+A Layout Container is a structural decision:
+
+- Bitloops groups the selected elements under a new container in the tree
+- In code, that container becomes a wrapper element (typically a `<div>`)
+- You can then configure it with layout rules (flex/grid, alignment, gap, padding, responsive behavior)
+
+You can nest containers—exactly like you would when structuring JSX by hand.
+
+## Steps
+
+### 1) Open the right place to add containers
+
+You can add containers in either place:
+
+- **Design View** (best when you want to fix structure before creating a component), or
+- **Snapshot View** (best when you’re refining an existing component to match a snapshot)
+
+✅ **Checkpoint:** You can see the elements you want to group, and you can select them on canvas or in the tree.
+
+<!-- TODO: Add screenshot: “Design View vs Snapshot View (where to do it)” -->
+
+### 2) Select the elements to group
+
+Select multiple elements that should behave as a unit—for example:
+- image + text block + button inside a card
+- a row of tags
+- a header title + subtitle group
+
+Tip: group by **behavior**, not just proximity (what should resize/move together).
+
+✅ **Checkpoint:** All intended elements are selected and highlighted.
+
+<!-- TODO: Add screenshot: “Multi-select highlighted” -->
+
+### 3) Create the Layout Container
+
+With elements selected:
+
+- Press `Cmd + G` (Mac) / `Ctrl + G` (Windows/Linux), or
+- Right-click → **Add Layout Container**
+
+Bitloops will wrap the selected elements into a container and apply a sensible default layout you can refine.
+
+✅ **Checkpoint:** A new container appears in the tree and the selected elements are now children of it.
+
+<!-- TODO: Add screenshot: “Container added in tree” -->
+
+### 4) Configure layout intent (direction, spacing, alignment)
+
+Select the new container and set the layout intent in the properties panel:
+
+- **Direction:** row vs column
+- **Spacing:** `gap-*`
+- **Alignment:** `items-*`, `justify-*`
+- **Sizing & padding:** width/height constraints, `p-*`, `m-*`
+- **Responsive adjustments:** breakpoint-specific behavior (as needed)
+
+✅ **Checkpoint:** The grouping reads correctly in the tree and the layout looks closer to the design.
+
+<!-- TODO: Add screenshot: “Container properties panel + updated layout” -->
+
+### 5) Nest containers for real layouts
+
+If the UI needs more structure, repeat the process:
+
+1. Create an inner container first (tightest grouping)
+2. Then group that container with adjacent elements
+3. Build outward until the layout hierarchy matches your mental model
+
+✅ **Checkpoint:** The hierarchy is understandable at a glance (not overly deep, but not flat).
+
+<!-- TODO: Add screenshot: “Nested containers” -->
+
+## Notes
+
+- If a snapshot doesn’t match, missing hierarchy is often the culprit—containers are usually the cleanest fix.
+- Don’t over-nest. Prefer fewer, meaningful wrappers.
+- Containers are especially useful before attaching lots of snapshots: consistent structure reduces later refactors.
+
+---
+
+*Next up: attach snapshots (instances + variants) and use them to pressure-test your layout across real examples.*
diff --git a/documentation/docs/frontend-copilot/Guides/attaching-snapshots.md b/documentation/docs/frontend-copilot/Guides/attaching-snapshots.md
new file mode 100644
index 00000000..2c9c27a7
--- /dev/null
+++ b/documentation/docs/frontend-copilot/Guides/attaching-snapshots.md
@@ -0,0 +1,126 @@
+---
+sidebar_position: 3
+sidebar_label: Attaching Snapshots
+title: "Attaching Snapshots"
+description: "Step-by-step guide to attaching snapshots to a component to infer props, variants, and responsive behavior."
+keywords:
+  [
+    attaching snapshots,
+    snapshots,
+    component instances,
+    variants,
+    responsive design,
+  ]
+---
+
+# Attaching Snapshots
+
+This guide shows you how to attach additional snapshots to an existing component. We assume you’re signed in, inside a project, and you already created a component.
+
+Snapshots are design-based examples of a component. They can represent:
+- **Instances** (same component, different data/content), and/or
+- **Variants** (meaningful state/style/layout differences, including viewport-specific versions)
+
+Attaching snapshots is how you teach Bitloops what changes and what stays consistent—so it can infer a cleaner component API.
+
+## Video walkthrough
+
+<!-- TODO: Replace with YouTube link -->
+- YouTube: https://www.youtube.com/watch?v=YOUR_VIDEO_ID
+
+:::tip
+Watch once end-to-end, then follow the steps below.
+:::
+
+## When to use this
+
+- You have multiple occurrences of the same UI (e.g., several cards on a page) and want Bitloops to infer **props**
+- You have state differences (e.g., selected/expanded/error) and want Bitloops to infer **variants/conditionals**
+- You have desktop + mobile designs and want Bitloops to infer **responsive behavior**
+- You created a component early and want to improve it using more examples
+
+## Before you start
+
+- You’re signed in to Bitloops
+- You have a project open
+- A component already exists under the **Components** tab
+- The frame(s) containing the new example(s) are available in **Design View**
+
+## How it works
+
+Attaching a snapshot doesn’t overwrite your component—it **adds another example** under that component.
+
+- Each attached snapshot appears under the component
+- A component can have **many snapshots**
+- Bitloops uses snapshot differences to infer:
+  - props (what changes across instances)
+  - variants (what changes across states)
+  - conditional rendering (what appears/disappears)
+  - responsive rules (when viewport snapshots exist)
+
+## Steps
+
+### 1) Open the frame that contains the example
+
+1. Open **Design View**
+2. Select the frame where the example lives (another instance, another state, or another viewport)
+
+✅ **Checkpoint:** You can see the target UI on the canvas and in the design tree.
+
+<!-- TODO: Add screenshot: “Design View with target frame selected” -->
+
+### 2) Select the snapshot elements
+
+Select the exact group of elements that represents the component in this example.
+
+This might be:
+- one of several repeated instances (e.g., BlogCard #3), or
+- a variant/state (e.g., selected), or
+- a viewport-specific version (e.g., mobile)
+
+✅ **Checkpoint:** The selection is highlighted and matches the component boundary you intend.
+
+<!-- TODO: Add screenshot: “Elements selected for snapshot” -->
+
+### 3) Attach the snapshot to an existing component
+
+Right-click the selection → **Attach Snapshot to [Component-name]**  
+(or choose the component from the attach list if shown)
+
+*(Shortcut: if the component is selected, `Ctrl/Cmd + A` attaches the snapshot.)*
+
+✅ **Checkpoint:** The snapshot is now listed under that component.
+
+<!-- TODO: Add screenshot: “Context menu attach + snapshot appears under component” -->
+
+### 4) Review in Snapshot View + Component View
+
+Open the component from the **Components** tab to enter the compare loop:
+
+- **Snapshot View** shows the newly attached design example
+- **Component View** shows the live render from your `.tsx`
+
+✅ **Checkpoint:** You can switch between snapshots and compare design vs output.
+
+<!-- TODO: Add screenshot: “Snapshot list + Snapshot View + Component View visible” -->
+
+### 5) Iterate if something is off
+
+If the new snapshot doesn’t match the current implementation, you have two common fixes:
+
+- Adjust code in the `.tsx` file (save to refresh preview)
+- Add/adjust **Layout Containers** if the hierarchy/grouping is the real issue
+
+✅ **Checkpoint:** The component renders correctly for this snapshot example.
+
+<!-- TODO: Add screenshot: “Before/after fix with matching preview” -->
+
+## Notes
+
+- **Instances vs variants:** multiple “same component” examples are still valuable snapshots—even if nothing is “variant-like.” They help Bitloops infer props and optional fields.
+- **Viewport snapshots:** attaching mobile/desktop examples gives Bitloops more signal for responsive output.
+- You can attach snapshots at any time—even after editing the component code.
+
+---
+
+*Next up: open the component and use the snapshots to drive props, variants, and responsiveness—one example at a time.*
\ No newline at end of file
diff --git a/documentation/docs/frontend-copilot/Guides/component-testing.md b/documentation/docs/frontend-copilot/Guides/component-testing.md
new file mode 100644
index 00000000..62ed7f69
--- /dev/null
+++ b/documentation/docs/frontend-copilot/Guides/component-testing.md
@@ -0,0 +1,120 @@
+---
+sidebar_position: 5
+sidebar_label: Component Testing
+title: "Component Testing"
+description: "Step-by-step guide to validating components in Bitloops by comparing Snapshot View (design) against Component View (live output)."
+keywords:
+  [
+    component testing,
+    snapshot comparison,
+    visual testing,
+    design to code validation,
+    component preview,
+  ]
+---
+
+# Component Testing
+
+This guide shows you how Bitloops helps you validate a component against its attached snapshots—so you can catch layout/structure issues early and fix them while you’re still in the implementation loop.
+
+Bitloops testing here is not “unit tests” in the traditional sense. It’s **design-to-output validation**: Snapshot View is the reference, Component View is the live result, and Bitloops surfaces where they don’t match.
+
+## Video walkthrough
+
+<!-- TODO: Replace with YouTube link -->
+- YouTube: https://www.youtube.com/watch?v=YOUR_VIDEO_ID
+
+:::tip
+Attach at least 2–3 snapshots (instances or variants) before testing—differences are where the signal comes from.
+:::
+
+## When to use this
+
+- After attaching snapshots to a component (instances, variants, viewport-specific examples)
+- After editing layout containers or refactoring component structure
+- Before reusing a component across multiple screens/pages
+- When a component “looks right” for one snapshot but breaks for another
+
+## Before you start
+
+- You’re signed in to Bitloops
+- You have a project open
+- You have a component created under **Components**
+- That component has at least one snapshot attached (ideally multiple)
+
+## How it works
+
+Bitloops compares each snapshot’s **design slice** to the component’s **rendered output** and flags potential mismatches, such as:
+
+- spacing/alignment issues
+- incorrect hierarchy/grouping
+- missing/extra elements
+- conditional elements behaving inconsistently across snapshots
+- responsive differences (when viewport snapshots exist)
+
+These results are surfaced per snapshot so you can fix issues incrementally without guessing.
+
+## Steps
+
+### 1) Open the component from the Components tab
+
+1. Open the **Components** tab
+2. Double-click the component you want to validate
+
+✅ **Checkpoint:** Snapshot View + Component View are visible (and your `.tsx` file is open).
+
+<!-- TODO: Add screenshot: “Components tab → component opened → panels visible” -->
+
+### 2) Check the snapshot indicators
+
+In the **Components** tab (and/or while browsing snapshots), Bitloops surfaces indicators per snapshot when it detects mismatches.
+
+✅ **Checkpoint:** You can see which snapshots are “clean” and which ones are flagged.
+
+<!-- TODO: Add screenshot: “Snapshot list with pass/fail/issue indicator” -->
+
+### 3) Inspect a flagged snapshot
+
+1. Select a flagged snapshot
+2. Compare **Snapshot View** (design reference) against **Component View** (live output)
+
+Use this pass to identify what kind of mismatch it is:
+- missing wrapper / grouping issue
+- spacing/alignment
+- conditional element appearing incorrectly
+- viewport-specific layout differences
+
+✅ **Checkpoint:** You can point to the mismatch visually (what’s different, and where).
+
+<!-- TODO: Add screenshot: “Same snapshot vs live preview mismatch example” -->
+
+### 4) Fix the mismatch
+
+Most fixes fall into one of these paths:
+
+- **Layout/structure fix:** add or adjust **Layout Containers** to make hierarchy intent explicit
+- **Implementation fix:** edit the `.tsx` file (and save) to correct structure, props, or conditional rendering
+
+✅ **Checkpoint:** After saving or updating containers, Component View matches Snapshot View more closely for that snapshot.
+
+<!-- TODO: Add screenshot: “Before/after: mismatch resolved” -->
+
+### 5) Re-check across all snapshots
+
+Once a fix is applied, cycle through the other snapshots attached to the same component. Often:
+- a structural fix improves multiple snapshots at once, or
+- a conditional fix resolves a specific variant only
+
+✅ **Checkpoint:** The component renders consistently across the snapshot set (instances + variants).
+
+<!-- TODO: Add screenshot: “Multiple snapshots all passing / clean state” -->
+
+## Notes
+
+- Snapshot validation is most useful when you attach **real examples** (multiple instances + at least one meaningful state difference).
+- If a single snapshot is “wrong,” the issue is often missing hierarchy—try Layout Containers before rewriting logic.
+- Bitloops may also add stable data attributes to support mapping and testing workflows. In general, treat them as tool-owned metadata.
+
+---
+
+*Next up: if the component passes across snapshots, start nesting it into a parent component and reuse it across screens with confidence.*
diff --git a/documentation/docs/frontend-copilot/Guides/creating-components.md b/documentation/docs/frontend-copilot/Guides/creating-components.md
new file mode 100644
index 00000000..a83ad70d
--- /dev/null
+++ b/documentation/docs/frontend-copilot/Guides/creating-components.md
@@ -0,0 +1,109 @@
+---
+sidebar_position: 2
+sidebar_label: Creating Components
+title: "Creating Components"
+description: "Step-by-step guide to creating components from your designs in Bitloops."
+keywords:
+  [
+    creating components,
+    component creation,
+    design to component,
+    how to create,
+  ]
+---
+
+# Creating Components
+
+This guide shows you how to turn a selection in **Design View** into a real React component in your project. We assume you’re signed in, inside a project, and you have at least one design frame added to that project.
+
+You decide what becomes a component and when—Bitloops won’t force a structure. It helps you extract the right boundaries, generate code, and set you up for iteration with snapshots.
+
+## Video walkthrough
+
+<!-- TODO: Replace with YouTube link -->
+- YouTube: https://www.youtube.com/watch?v=YOUR_VIDEO_ID
+
+:::tip
+Watch once end-to-end, then follow the steps below.
+:::
+
+## When to use this
+
+- You want to extract a reusable UI block (card, header, navbar, section, etc.)
+- You want Bitloops to generate the initial structure, props, and assets
+- You’re ready to start the Snapshot View ↔ Component View ↔ Code loop
+
+## Before you start
+
+- You’re signed in to Bitloops
+- You have a project open (folder opened + project created)
+- You have at least one frame available in **Design View** (added to the project)
+
+## How it works
+
+Creating a component is the moment Bitloops turns design structure into code:
+
+- You select elements (or a whole frame)
+- You create a component (Bitloops generates the `.tsx` and registers it under **Components**)
+- Bitloops creates an initial snapshot and/or suggests additional snapshots
+- From there, you iterate by attaching more snapshots and refining the code
+
+## Steps
+
+### 1) Open the frame in Design View
+
+1. Open **Design View**
+2. Select the frame you want to work with
+
+✅ **Checkpoint:** You can see the frame on the canvas and the design tree on the left.
+
+<!-- TODO: Add screenshot: “Design View with frame selected” -->
+
+### 2) Select the element(s) to componentize
+
+Select elements directly on the canvas (click, or drag-select like in Figma), or select an entire frame when available. To select multiple items, hold **Ctrl** (Windows/Linux) or **Cmd** (Mac) while clicking.
+
+✅ **Checkpoint:** Your target selection is highlighted.
+
+<!-- TODO: Add screenshot: “Selected nodes highlighted on canvas + in tree” -->
+
+### 3) Create the component
+
+With elements selected:
+
+**Right-click → Create Component** *(Shortcut: Ctrl/Cmd + C in the Bitloops canvas)*
+
+Give the component a developer-friendly name (e.g., `ProductCard`, `HeroSection`, `PricingTable`).
+
+✅ **Checkpoint:** The component appears under **Components** and renders for the first time in **Component View** (live preview).
+
+<!-- TODO: Add screenshot: “Create Component dialog + Components tab showing new component” -->
+
+### 4) Open the generated code
+
+Double-click the component under **Components**.
+
+Bitloops opens:
+- the component’s `.tsx` file in your editor
+- Snapshot View + Component View for comparison (when available)
+
+✅ **Checkpoint:** You can see the component code file open, with Snapshot View and Component View visible for the component.
+
+<!-- TODO: Add screenshot: “3-panel workflow with code + snapshot + preview” -->
+
+### 5) Save and see live updates
+
+Make a small change in the `.tsx` file and save (`Ctrl/Cmd + S`).
+
+✅ **Checkpoint:** **Component View** updates immediately.
+
+<!-- TODO: Add screenshot: “Code change + updated Component View” -->
+
+## Notes
+
+- If the selection produces awkward layout, add **Layout Containers** to make grouping/layout intent explicit before (or after) creating the component.
+- Components are composable: you can create smaller components first and build parent components on top.
+
+---
+
+*Next up: attach a couple of snapshots so Bitloops can infer props, variants, and conditionals.*
diff --git a/documentation/docs/frontend-copilot/Guides/editing-components.md b/documentation/docs/frontend-copilot/Guides/editing-components.md
new file mode 100644
index 00000000..014be54c
--- /dev/null
+++ b/documentation/docs/frontend-copilot/Guides/editing-components.md
@@ -0,0 +1,125 @@
+---
+sidebar_position: 6
+sidebar_label: Editing Components
+title: "Editing Components"
+description: "Step-by-step guide to editing generated components in your codebase and validating changes instantly in Bitloops."
+keywords:
+  [
+    editing components,
+    code editing,
+    live preview,
+    snapshot validation,
+  ]
+---
+
+# Editing Components
+
+This guide shows you how to edit a Bitloops-generated component like any normal React component: open the file, change the code, save.
+
+Bitloops stays in sync while you work by keeping the **compare loop** tight:
+**Snapshot View (design) ↔ Component View (live output) ↔ Code (your editor)**
+
+There’s no special syntax and no hidden layer—you own the code.
+
+## Video walkthrough
+
+<!-- TODO: Replace with YouTube link -->
+- YouTube: https://www.youtube.com/watch?v=YOUR_VIDEO_ID
+
+:::tip
+Make small edits first (spacing, wrappers, simple props), then pressure-test across snapshots before doing larger refactors.
+:::
+
+## When to use this
+
+- You want to tweak Tailwind classes, spacing, typography, or layout
+- A snapshot is flagged as “off” and you want to fix the mismatch
+- You’re adding conditional rendering or cleaning up props
+- You’re preparing a component for reuse (nesting into a parent component)
+
+## Before you start
+
+- You’re signed in to Bitloops
+- You have a project open
+- You have a component under the **Components** tab
+- That component has at least one snapshot (ideally multiple) so you can validate changes
+
+## How it works
+
+When you open a component from the **Components** tab, Bitloops gives you the full editing loop:
+
+- **Code file** (`.tsx`) opens in your editor
+- **Component View** renders the component from your code
+- **Snapshot View** shows the design reference for the selected snapshot
+- On save (`Ctrl/Cmd + S`), Bitloops refreshes the preview and re-evaluates snapshot alignment
+
+Edits don’t require a rebuild or manual refresh—the live preview updates immediately.
+
+## Steps
+
+### 1) Open the component from the Components tab
+
+1. Open the **Components** tab
+2. Double-click the component you want to edit
+
+✅ **Checkpoint:** The component’s `.tsx` file opens, and you can see Snapshot View + Component View for comparison.
+
+<!-- TODO: Add screenshot: “Components tab → component opened → code + snapshot + preview visible” -->
+
+### 2) Make a targeted change
+
+Common edits include:
+
+- Adjust Tailwind classes (`gap-*`, `p-*`, `text-*`, `items-*`, `justify-*`)
+- Introduce or remove a wrapper `div` (often paired with Layout Containers)
+- Refine props (rename, make optional, set defaults)
+- Add conditional rendering for optional elements
+- Replace repeated markup with nested component usage
+
+✅ **Checkpoint:** The code compiles and the component still renders in Component View.
+
+<!-- TODO: Add screenshot: “Code change highlighted” -->
+
+### 3) Save and validate instantly
+
+Save the file (`Ctrl/Cmd + S`).
+
+✅ **Checkpoint:** Component View updates immediately—no reload required.
+
+<!-- TODO: Add screenshot: “Before/after preview update on save” -->
+
+### 4) Pressure-test across snapshots
+
+Switch between snapshots attached to the component:
+
+- Instances (same structure, different content)
+- Variants (state/style/layout differences)
+- Viewport snapshots (mobile/desktop examples)
+
+✅ **Checkpoint:** The component holds up across snapshots (or you can clearly see which snapshot is now off).
+
+<!-- TODO: Add screenshot: “Switching snapshots + consistent rendering” -->
+
+### 5) Fix structural issues with Layout Containers (when needed)
+
+If one snapshot is off due to hierarchy/grouping, the cleanest fix is often structural:
+
+- Add or adjust **Layout Containers** to make layout intent explicit
+- Then refine Tailwind classes for spacing/alignment
+
+✅ **Checkpoint:** The hierarchy is clearer and the snapshot matches more reliably.
+
+<!-- TODO: Add screenshot: “Layout container adjustment + improved match” -->
+
+## Notes
+
+- Bitloops won’t overwrite your edits unless you explicitly regenerate/replace a component.
+- If a change “fixes” one snapshot but breaks another, that’s usually a signal you need:
+  - a prop boundary (instance differences), or
+  - a conditional branch/variant handling (state differences), or
+  - an explicit wrapper (layout container / hierarchy intent).
+- Treat tool-owned metadata (like generated mapping attributes) as read-only unless a doc explicitly says otherwise.
+
+---
+
+*Next up: once the component holds up across snapshots, nest it into a parent component and reuse it with confidence.*
\ No newline at end of file
diff --git a/documentation/docs/frontend-copilot/Guides/importing-designs.md b/documentation/docs/frontend-copilot/Guides/importing-designs.md
new file mode 100644
index 00000000..99164d3e
--- /dev/null
+++ b/documentation/docs/frontend-copilot/Guides/importing-designs.md
@@ -0,0 +1,94 @@
+---
+sidebar_position: 1
+sidebar_label: Importing Designs
+title: "Importing Designs"
+description: "Step-by-step guide to importing Figma designs into Bitloops."
+keywords:
+  [
+    importing designs,
+    figma import,
+    design files,
+    how to import,
+  ]
+---
+
+# Importing Designs
+
+This guide shows you how to import a Figma design into your Bitloops **account library** and then add specific frames to your **current project**. We assume you’re already signed in and inside a project.
+
+Bitloops won’t auto-generate components on import—you decide which frames to work on and when to start componentizing.
+
+## Video walkthrough
+
+<!-- TODO: Replace with YouTube link -->
+- YouTube: https://www.youtube.com/watch?v=YOUR_VIDEO_ID
+
+:::tip
+Watch once end-to-end, then follow the steps below.
+:::
+
+## When to use this
+
+- You’re starting a new project and want to bring designs into Bitloops
+- You’ve received new screens and want to add more frames to an existing project
+- You want the full set of frames available so reuse, snapshots, and the design system are inferred more accurately
+
+## Before you start
+
+- You’re signed in to Bitloops
+- You have a project open (folder opened + project created)
+- You have access to the Figma file/page you’re importing
+
+## How it works
+
+Bitloops separates **importing** from **adding frames to a project**:
+
+- Importing a Figma URL adds frames to **My Design Files** (account-level library)
+- You then select which frames to **Add to Project**
+- Only frames added to your project show up in Design View for component creation
+
+## Steps
+
+### 1) Open “My Design Files”
+
+In the Bitloops sidebar, go to the Designs area and click the **+** button to open **My Design Files**.
+
+✅ **Checkpoint:** You can see your design library (previously imported designs, if any).
+
+<!-- TODO: Add screenshot: “+ button / My Design Files panel” -->
+
+### 2) Import a Figma page URL
+
+Inside **My Design Files**, click **Import**, then paste your **Figma page URL**.
+
+Bitloops will import **all frames contained in that page** and add them to your account library.
+
+✅ **Checkpoint:** The imported design file appears in **My Design Files**, and its frames are visible.
+
+<!-- TODO: Add screenshot: “Paste URL → Import → frames grid” -->
+
+### 3) Add frames to your project
+
+Select the frames you want to work with, then click **Add to Project**.
+
+✅ **Checkpoint:** The selected frames are now available in your project’s **Design View**.
+
+<!-- TODO: Add screenshot: “Select frame(s) → Add to Project → success state” -->
+
+### 4) Open Design View
+
+Click **Take me to Design View** (or open Design View from the sidebar), then select one of the frames you added.
+
+✅ **Checkpoint:** You can see the frame on the canvas and its element tree.
+
+<!-- TODO: Add screenshot: “Design View with imported frame visible” -->
+
+## Notes
+
+- Imported designs do **not** auto-sync with Figma (yet). If the design changes, import a second version or start a new project and re-run the flow.
+- You can import once into your library and reuse the same design frames across multiple projects.
+
+---
+
+*Next up: add a frame to your project and start extracting components.*
+
diff --git a/documentation/docs/frontend-copilot/Guides/nested-components.md b/documentation/docs/frontend-copilot/Guides/nested-components.md
new file mode 100644
index 00000000..a2cbaf70
--- /dev/null
+++ b/documentation/docs/frontend-copilot/Guides/nested-components.md
@@ -0,0 +1,127 @@
+---
+sidebar_position: 7
+sidebar_label: Nested Components
+title: "Nested Components"
+description: "Step-by-step guide to composing child components inside parent components for cleaner structure and reuse."
+keywords:
+  [
+    nested components,
+    component composition,
+    reusable components,
+    parent child components,
+  ]
+---
+
+# Nested Components
+
+This guide shows you how to build larger components by composing smaller ones (nesting), and how Bitloops keeps the structure clean when components appear inside other components. We assume you’re signed in, inside a project, and you already have at least one component created.
+
+Nesting is how you scale from “one card” to “a whole section” without copy-pasting markup.
+
+## Video walkthrough
+
+<!-- TODO: Replace with YouTube link -->
+- YouTube: https://www.youtube.com/watch?v=YOUR_VIDEO_ID
+
+:::tip
+Nesting works best when you already have a stable child component with a couple of snapshots (instances/variants). That gives Bitloops a clearer prop boundary.
+:::
+
+## When to use this
+
+- You want to build a section/page out of smaller components (compose upward)
+- You created a big component and want to extract a reusable part (refactor downward)
+- You have repeated UI blocks across screens and want one “child” used in many parents
+- You want cleaner props and less duplicated layout logic
+
+## Before you start
+
+- You’re signed in to Bitloops
+- You have a project open
+- You have a design frame available in **Design View**
+- You have (or plan to create) at least one child component (e.g., `Button`, `Card`, `Badge`)
+
+## How it works
+
+In Bitloops, nesting is reflected in both the **design tree** and the **generated code**:
+
+- When a component is created, it appears under the **Components** tab
+- When that component is used inside another selection, Bitloops treats it as a component **instance**
+- Parent components will reference the child component (imports + JSX usage)
+- Snapshot differences help Bitloops pass the right data/props through the hierarchy
+
+You can approach nesting two ways:
+- **Bottom-up:** make smaller components first, then build parents
+- **Top-down:** make a large component first, then extract smaller parts
+
+## Steps
+
+### 1) Create (or identify) the child component
+
+Pick a UI element that repeats and should be reusable—e.g. `Button`, `Avatar`, `Badge`, `BlogCard`.
+
+If it doesn’t exist yet:
+1. In **Design View**, select the child UI
+2. **Create Component**
+
+✅ **Checkpoint:** The child component appears under **Components**.
+
+<!-- TODO: Add screenshot: “Child component created + listed under Components” -->
+
+### 2) Open the parent frame/section in Design View
+
+Navigate to the frame or section where you want the parent component (the one that will *contain* the child).
+
+✅ **Checkpoint:** You can see the larger layout/section that includes (or will include) the child UI.
+
+<!-- TODO: Add screenshot: “Parent frame visible in Design View” -->
+
+### 3) Select the parent boundary (including child instances)
+
+Select the elements that make up the parent section. If the design already contains the child UI in multiple places (e.g., multiple cards or buttons), include those in your selection.
+
+✅ **Checkpoint:** Your selection matches the intended parent boundary (a section, header block, page area, etc.).
+
+<!-- TODO: Add screenshot: “Parent selection highlighted” -->
+
+### 4) Create the parent component
+
+Right-click → **Create Component** *(Shortcut: Ctrl/Cmd + C in the Bitloops canvas)*  
+Name it (e.g., `HeroSection`, `BlogGrid`, `PricingSection`).
+
+✅ **Checkpoint:** The new parent component appears under **Components** and renders in Component View.
+
+<!-- TODO: Add screenshot: “Parent component created and visible in Components tab” -->
+
+### 5) Verify nesting in the code
+
+Open the parent component from **Components** and inspect the generated `.tsx`.
+
+You should see:
+- the child component imported (when applicable)
+- the child component rendered as a JSX instance inside the parent
+
+✅ **Checkpoint:** The parent component uses the child component rather than duplicating its markup.
+
+<!-- TODO: Add screenshot: “Parent code showing child import + JSX usage” -->
+
+### 6) Pressure-test with snapshots
+
+If the parent component has multiple snapshots (instances/variants), switch between them and confirm:
+- child instances still render correctly
+- prop/data differences flow through cleanly
+- layout remains consistent
+
+✅ **Checkpoint:** The parent holds up across snapshots without copy-pasted fixes.
+
+<!-- TODO: Add screenshot: “Parent snapshots switching with stable render” -->
+
+## Notes
+
+- If the parent layout becomes messy, add **Layout Containers** to express hierarchy intent (wrappers you’d write by hand).
+- If nesting causes one snapshot to break, it usually means you need clearer prop boundaries (instance data) or a conditional (variant/state).
+- Nested components are iterative: it’s normal to create a parent, then go back and tighten the child API using more snapshots.
+
+---
+
+*Next up: attach a couple of snapshots to the parent component so its layout and prop boundaries are tested against real examples—not just the “happy path.”*
diff --git a/documentation/docs/frontend-copilot/best-practices/accessibility.md b/documentation/docs/frontend-copilot/best-practices/accessibility.md
new file mode 100644
index 00000000..18f0b866
--- /dev/null
+++ b/documentation/docs/frontend-copilot/best-practices/accessibility.md
@@ -0,0 +1,667 @@
+---
+sidebar_position: 7
+sidebar_label: Accessibility
+title: "Accessible React Components: Semantic HTML, ARIA Patterns, and Keyboard Navigation"
+description: "Accessibility isn't a checklist—it's architecture. Learn semantic HTML defaults, ARIA patterns, keyboard navigation, and focus management for React components."
+keywords:
+  [
+    react accessibility best practices,
+    semantic html components,
+    aria attributes react,
+    keyboard navigation react,
+    focus management react,
+    accessible component library,
+    screen reader testing,
+    wcag react components,
+  ]
+---
+
+# Designing for accessibility by default
+
+Accessibility isn't a checklist to satisfy at the end of a project. It's a byproduct of good structure—components built with semantic HTML, clear interaction patterns, and thoughtful state management are often accessible by default. Components built with divs and click handlers require extensive retrofitting.
+
+This document covers accessibility as architecture: the structural decisions that produce accessible components, and the patterns that close remaining gaps.
+
+## Accessibility as Architecture
+
+The difference between accessible and inaccessible components is usually structural, not cosmetic.
+
+### Two approaches to a button
+
+**The div approach:**
+
+```tsx
+const Button = ({ children, onClick }) => (
+  <div
+    className="bg-blue-500 text-white px-4 py-2 rounded cursor-pointer"
+    onClick={onClick}
+  >
+    {children}
+  </div>
+);
+```
+
+This "button" is:
+- Not focusable via keyboard
+- Not announced as a button by screen readers
+- Not activatable with Enter or Space
+- Not included in the tab order
+
+**The button approach:**
+
+```tsx
+const Button = ({ children, onClick }) => (
+  <button
+    className="bg-blue-500 text-white px-4 py-2 rounded"
+    onClick={onClick}
+  >
+    {children}
+  </button>
+);
+```
+
+This button is:
+- Focusable by default
+- Announced as "button" by screen readers
+- Activatable with Enter or Space
+- In the natural tab order
+
+The second version required no extra work—just the right element. Accessibility was architectural, not added.
+
+### The 80% rule
+
+Approximately 80% of accessibility comes from using semantic HTML correctly. The remaining 20% requires ARIA attributes and JavaScript for complex interactions.
+
+If you're adding ARIA to every component, you're likely using the wrong elements.
+
+## Semantic HTML
+
+Semantic elements carry meaning and behavior that browsers and assistive technologies understand.
+
+### Elements and their semantics
+
+| Element | Semantic meaning | Built-in behavior |
+|---------|------------------|-------------------|
+| `<button>` | Interactive control | Focus, keyboard activation |
+| `<a href>` | Navigation link | Focus, keyboard activation, context menu |
+| `<input>` | Data entry | Focus, keyboard input, form integration |
+| `<h1>`-`<h6>` | Heading hierarchy | Document outline, navigation |
+| `<nav>` | Navigation region | Landmark for screen readers |
+| `<main>` | Main content | Landmark, skip-link target |
+| `<article>` | Self-contained content | Syndication, outline |
+| `<aside>` | Tangential content | Landmark |
+| `<form>` | Data collection | Submission, validation |
+
+### Common semantic mistakes
+
+**Links vs. buttons:**
+
+```tsx
+// Wrong: link with no href (not a link)
+<a onClick={handleClick}>Click me</a>
+
+// Wrong: link that doesn't navigate
+<a href="#" onClick={handleClick}>Click me</a>
+
+// Right: button for actions
+<button onClick={handleClick}>Click me</button>
+
+// Right: link for navigation
+<a href="/page">Go to page</a>
+```
+
+The rule: buttons do things, links go places.
+
+**Heading hierarchy:**
+
+```tsx
+// Wrong: skipping levels
+<h1>Page Title</h1>
+<h4>Section Title</h4>  // Skipped h2, h3
+
+// Right: sequential hierarchy
+<h1>Page Title</h1>
+<h2>Section Title</h2>
+<h3>Subsection</h3>
+```
+
+Screen reader users navigate by headings. Skipped levels break this navigation.
+
+**Lists for lists:**
+
+```tsx
+// Wrong: divs for a list of items
+<div>
+  <div>Item 1</div>
+  <div>Item 2</div>
+  <div>Item 3</div>
+</div>
+
+// Right: actual list
+<ul>
+  <li>Item 1</li>
+  <li>Item 2</li>
+  <li>Item 3</li>
+</ul>
+```
+
+Screen readers announce "list, 3 items" for the second version, providing context.
+
+## ARIA: Completing the Picture
+
+ARIA (Accessible Rich Internet Applications) fills gaps when semantic HTML isn't enough. Use it to:
+
+- Describe relationships between elements
+- Communicate dynamic state changes
+- Make custom components accessible
+
+### The first rule of ARIA
+
+> No ARIA is better than bad ARIA.
+
+ARIA can make things worse. A `<div role="button">` that doesn't handle keyboard events is worse than a plain `<div>`—it promises button behavior and fails to deliver.
+
+### Common ARIA patterns
+
+**Labels for form elements:**
+
+```tsx
+// Explicit label association
+<label htmlFor="email">Email address</label>
+<input id="email" type="email" />
+
+// aria-label for icon-only buttons
+<button aria-label="Close dialog">
+  <XIcon />
+</button>
+
+// aria-labelledby for complex labels
+<h2 id="section-title">User Settings</h2>
+<section aria-labelledby="section-title">
+  {/* Content */}
+</section>
+```
+
+**Describing relationships:**
+
+```tsx
+// Error messages
+<input
+  id="email"
+  type="email"
+  aria-describedby="email-error"
+  aria-invalid={hasError}
+/>
+<span id="email-error" role="alert">
+  Please enter a valid email address
+</span>
+
+// Related content
+<button aria-controls="menu" aria-expanded={isOpen}>
+  Menu
+</button>
+<nav id="menu" hidden={!isOpen}>
+  {/* Menu items */}
+</nav>
+```
+
+**Live regions for dynamic updates:**
+
+```tsx
+// Polite announcements (wait for pause in speech)
+<div aria-live="polite" aria-atomic="true">
+  {statusMessage}
+</div>
+
+// Assertive announcements (interrupt immediately)
+<div role="alert">
+  {errorMessage}
+</div>
+```
+
+### When to use roles
+
+Roles override native semantics. Use them for custom components:
+
+```tsx
+// Custom toggle switch
+<button
+  role="switch"
+  aria-checked={isOn}
+  onClick={toggle}
+>
+  <span className={isOn ? 'on' : 'off'} />
+</button>
+
+// Custom tab interface
+<div role="tablist">
+  <button role="tab" aria-selected={index === 0}>Tab 1</button>
+  <button role="tab" aria-selected={index === 1}>Tab 2</button>
+</div>
+<div role="tabpanel">
+  {/* Tab content */}
+</div>
+```
+
+## Icon-Only Controls
+
+Controls with only icons (no visible text) are accessibility hazards. Users who can't see the icon have no idea what it does.
+
+### The problem
+
+```tsx
+// Inaccessible: no indication what this button does
+<button>
+  <TrashIcon />
+</button>
+```
+
+Screen readers announce: "button" (with no context).
+
+### Solutions
+
+**1. Visually hidden text:**
+
+```tsx
+<button>
+  <TrashIcon aria-hidden="true" />
+  <span className="sr-only">Delete item</span>
+</button>
+```
+
+Screen readers announce: "Delete item, button."
+
+**2. aria-label:**
+
+```tsx
+<button aria-label="Delete item">
+  <TrashIcon aria-hidden="true" />
+</button>
+```
+
+Same result, shorter markup.
+
+**3. Tooltip (visible on hover/focus):**
+
+```tsx
+<Tooltip content="Delete item">
+  <button aria-label="Delete item">
+    <TrashIcon aria-hidden="true" />
+  </button>
+</Tooltip>
+```
+
+Helps sighted users too.
+
+### Icon accessibility patterns
+
+```tsx
+// Decorative icons: hide from screen readers
+<button>
+  <CheckIcon aria-hidden="true" />
+  Save
+</button>
+
+// Informative icons: provide alt text
+<span role="img" aria-label="Warning">⚠️</span>
+<span className="text-yellow-500">
+  <WarningIcon aria-hidden="true" /> {/* Icon hidden, text visible */}
+  Warning: This action cannot be undone
+</span>
+```
+
+## Keyboard Navigation
+
+All interactive elements must be operable with a keyboard. This isn't just for screen reader users—power users, users with motor impairments, and anyone with a broken mouse depend on keyboard access.
+
+### Focus order
+
+Focus should follow a logical order, typically matching visual reading order:
+
+```tsx
+// Natural flow: focus moves top-to-bottom, left-to-right
+<header>
+  <nav>
+    <a href="/">Home</a>        {/* 1 */}
+    <a href="/about">About</a>  {/* 2 */}
+  </nav>
+</header>
+<main>
+  <input type="text" />         {/* 3 */}
+  <button>Submit</button>       {/* 4 */}
+</main>
+```
+
+**Avoid tabindex > 0.** It overrides natural order and creates confusion:
+
+```tsx
+// Don't: arbitrary tab order
+<button tabIndex={2}>Second</button>
+<button tabIndex={1}>First</button>
+
+// Do: natural document order
+<button>First</button>
+<button>Second</button>
+```
+
+### Keyboard interaction patterns
+
+Standard patterns users expect:
+
+| Element | Key | Action |
+|---------|-----|--------|
+| Button | Enter, Space | Activate |
+| Link | Enter | Navigate |
+| Checkbox | Space | Toggle |
+| Menu | Arrow keys | Navigate items |
+| Dialog | Escape | Close |
+| Tabs | Arrow keys | Switch tabs |
+
+Implement these patterns for custom components:
+
+```tsx
+// Custom menu keyboard navigation
+const Menu = ({ items }) => {
+  const [focusIndex, setFocusIndex] = useState(0);
+
+  const handleKeyDown = (e) => {
+    switch (e.key) {
+      case 'ArrowDown':
+        e.preventDefault();
+        setFocusIndex(i => Math.min(i + 1, items.length - 1));
+        break;
+      case 'ArrowUp':
+        e.preventDefault();
+        setFocusIndex(i => Math.max(i - 1, 0));
+        break;
+      case 'Home':
+        e.preventDefault();
+        setFocusIndex(0);
+        break;
+      case 'End':
+        e.preventDefault();
+        setFocusIndex(items.length - 1);
+        break;
+    }
+  };
+
+  return (
+    <ul role="menu" onKeyDown={handleKeyDown}>
+      {items.map((item, i) => (
+        <li
+          key={item.id}
+          role="menuitem"
+          tabIndex={i === focusIndex ? 0 : -1}
+          ref={i === focusIndex ? focusedRef : null}
+        >
+          {item.label}
+        </li>
+      ))}
+    </ul>
+  );
+};
+```
+
+### Skip links
+
+Allow keyboard users to skip repetitive navigation:
+
+```tsx
+// First element in the page
+<a href="#main-content" className="sr-only focus:not-sr-only">
+  Skip to main content
+</a>
+
+{/* ... header and nav ... */}
+
+<main id="main-content">
+  {/* Main content */}
+</main>
+```
+
+The link is hidden until focused, then appears and allows jumping to content.
+
+## Focus Management
+
+Interactive components must manage focus appropriately, especially when UI changes dynamically.
+
+### Focus on open
+
+When opening dialogs, menus, or panels, move focus inside:
+
+```tsx
+const Dialog = ({ isOpen, onClose, children }) => {
+  const closeButtonRef = useRef(null);
+
+  useEffect(() => {
+    if (isOpen) {
+      closeButtonRef.current?.focus();
+    }
+  }, [isOpen]);
+
+  if (!isOpen) return null;
+
+  return (
+    <div role="dialog" aria-modal="true">
+      <button ref={closeButtonRef} onClick={onClose}>
+        Close
+      </button>
+      {children}
+    </div>
+  );
+};
+```
+
+### Focus on close
+
+When closing, return focus to the triggering element:
+
+```tsx
+const DialogTrigger = () => {
+  const [isOpen, setIsOpen] = useState(false);
+  const triggerRef = useRef(null);
+
+  const handleClose = () => {
+    setIsOpen(false);
+    triggerRef.current?.focus();  // Return focus
+  };
+
+  return (
+    <>
+      <button ref={triggerRef} onClick={() => setIsOpen(true)}>
+        Open Dialog
+      </button>
+      <Dialog isOpen={isOpen} onClose={handleClose}>
+        {/* Dialog content */}
+      </Dialog>
+    </>
+  );
+};
+```
+
+### Focus trapping
+
+Modal dialogs should trap focus—Tab should cycle within the dialog, not escape to the page behind:
+
+```tsx
+// Using a library like @react-aria/focus
+import { FocusScope } from '@react-aria/focus';
+
+const Dialog = ({ isOpen, children }) => {
+  if (!isOpen) return null;
+
+  return (
+    <FocusScope contain restoreFocus autoFocus>
+      <div role="dialog" aria-modal="true">
+        {children}
+      </div>
+    </FocusScope>
+  );
+};
+```
+
+### Focus visible
+
+Focus indicators must be visible. Never remove them entirely:
+
+```tsx
+// Bad: removes all focus indicators
+* { outline: none; }
+
+// Good: custom focus style
+button:focus-visible {
+  outline: 2px solid blue;
+  outline-offset: 2px;
+}
+```
+
+Use `:focus-visible` to show focus only for keyboard navigation, not mouse clicks.
+
+## Common Patterns
+
+### Accessible forms
+
+```tsx
+<form>
+  {/* Labels associated with inputs */}
+  <label htmlFor="name">Full name</label>
+  <input id="name" type="text" required />
+
+  {/* Error messages linked to inputs */}
+  <label htmlFor="email">Email</label>
+  <input
+    id="email"
+    type="email"
+    aria-describedby="email-error"
+    aria-invalid={emailError ? 'true' : undefined}
+  />
+  {emailError && (
+    <span id="email-error" className="text-red-500">
+      {emailError}
+    </span>
+  )}
+
+  {/* Button type prevents accidental submission */}
+  <button type="submit">Submit</button>
+</form>
+```
+
+### Accessible modals
+
+```tsx
+<div
+  role="dialog"
+  aria-modal="true"
+  aria-labelledby="dialog-title"
+  aria-describedby="dialog-description"
+>
+  <h2 id="dialog-title">Confirm deletion</h2>
+  <p id="dialog-description">
+    This action cannot be undone.
+  </p>
+  <button>Cancel</button>
+  <button>Delete</button>
+</div>
+```
+
+### Accessible tabs
+
+```tsx
+<div>
+  <div role="tablist" aria-label="Product information">
+    {tabs.map((tab, i) => (
+      <button
+        key={tab.id}
+        role="tab"
+        aria-selected={selectedIndex === i}
+        aria-controls={`panel-${tab.id}`}
+        id={`tab-${tab.id}`}
+        tabIndex={selectedIndex === i ? 0 : -1}
+      >
+        {tab.label}
+      </button>
+    ))}
+  </div>
+
+  {tabs.map((tab, i) => (
+    <div
+      key={tab.id}
+      role="tabpanel"
+      id={`panel-${tab.id}`}
+      aria-labelledby={`tab-${tab.id}`}
+      hidden={selectedIndex !== i}
+    >
+      {tab.content}
+    </div>
+  ))}
+</div>
+```
+
+## How this connects to Bitloops
+
+Accessibility is most effective when it's built into the component from the start — retrofitting semantic HTML, ARIA attributes, and keyboard navigation after the fact is expensive and error-prone. [Bitloops](https://bitloops.com) generates components with accessibility built in: buttons are `<button>` elements (not styled `<div>`s), images include `alt` attributes, form inputs are associated with labels, and interactive patterns use appropriate ARIA roles. This doesn't replace accessibility expertise, but it ensures the structural foundation is correct from the first render, making it easier to layer on the focus management and keyboard patterns described in this document.
+
+---
+
+## Summary
+
+Accessibility is structural. The principles:
+
+| Principle | Application |
+|---|---|
+| Semantic HTML first | Default to native elements (`button`, `a href`, `input`, headings, lists, landmarks). You get focus, keyboard behavior, and correct announcements “for free,” and you avoid fragile `div`-based interactivity that needs retrofitting. |
+| ARIA completes the picture | Use ARIA to express relationships and dynamic state *only when semantics aren’t enough* (e.g., `aria-expanded` + `aria-controls`, `aria-describedby`, `role="dialog"` + `aria-modal`). Prefer “no ARIA” over incorrect ARIA. |
+| Label everything | Ensure every control has an accessible name: visible `<label>`, `aria-label` for icon-only controls, or `aria-labelledby` for composite labels. Treat icon-only buttons as a required labeling case. |
+| Keyboard works everywhere | All interactive UI must be reachable and operable with keyboard: natural tab order, no `tabIndex>0`, expected key patterns (Enter/Space for buttons, arrows for menus/tabs, Escape to close dialogs). Custom widgets must implement the standard interaction model. |
+| Manage focus intentionally | On open: move focus into the surface (dialog/menu). On close: restore focus to the trigger. For modals: trap focus (Tab stays inside) and ensure background isn’t interactable. Use a proven focus-scope utility when possible. |
+| Focus indicators are mandatory | Never remove focus styles globally. Use `:focus-visible` to provide clear, consistent outlines for keyboard navigation without adding noise for mouse users. Make “focus visible” a design-system default. |
+
+The best accessibility work is invisible—it's built into component architecture from the start. Retrofitting accessibility is possible, but it's always more expensive than building it in.
+
+---
+
+## Further reading
+
+- [ARIA Authoring Practices Guide (APG) — W3C](https://www.w3.org/WAI/ARIA/apg/) — The authoritative reference for implementing accessible widgets (tabs, dialogs, menus, etc.) with correct keyboard interaction patterns and ARIA roles.
+- [WebAIM — Introduction to Web Accessibility](https://webaim.org/intro/) — Practical, standards-aligned accessibility guidance with testing tools (WAVE) and real-world examples; a reliable starting point for developers new to accessibility.
+- [React Aria — Adobe](https://react-spectrum.adobe.com/react-aria/) — A library of unstyled, accessible React hooks that implement the WAI-ARIA patterns; study the source to understand how focus management, keyboard navigation, and ARIA attributes work together.
+- [The A11y Project — Checklist](https://www.a11yproject.com/checklist/) — A practical, WCAG-based checklist for auditing web accessibility; useful as a design review companion to the principles in this document.
+- [Inclusive Components — Heydon Pickering](https://inclusive-components.design/) — Pattern-by-pattern guide to building accessible UI components (toggles, cards, data tables, notifications) with detailed explanations of the accessibility decisions behind each.
+
+---
+
+## Frequently Asked Questions (FAQs)
+
+1. **When should I use ARIA attributes vs. semantic HTML?**
+   Semantic HTML first—always. A `<button>` is automatically focusable, keyboard-activatable, and announced correctly. Use ARIA only when native elements don't exist (custom tabs, comboboxes, live regions). See [Component API Design](./component-api-design.md) for how props should expose semantic options, not implementation details.
+
+2. **What's the difference between `aria-label`, `aria-labelledby`, and `aria-describedby`?**
+   `aria-label`: provides accessible name as a string directly. `aria-labelledby`: references another element's ID for the accessible name. `aria-describedby`: provides supplementary description (like help text). Use `aria-labelledby` when the label is visible; `aria-label` for icon-only buttons.
+
+3. **How do I make icon-only buttons accessible?**
+   Three options: (1) visually hidden text with `sr-only` class, (2) `aria-label` on the button, (3) tooltip that also serves as accessible name. Always hide decorative icons with `aria-hidden="true"`. See [Design System Consumption](./design-system-consumption.md) for how system components should handle this by default.
+
+4. **Should I remove focus outlines for better design?**
+   Never remove focus indicators entirely—they're essential for keyboard users. Use `:focus-visible` to show outlines only for keyboard navigation. See [Design System Consumption](./design-system-consumption.md) for how focus styles should be defined in design tokens.
+
+5. **How do I implement keyboard navigation for custom components?**
+   Follow established patterns: Arrow keys for navigation within groups (menus, tabs), Enter/Space for activation, Escape to close overlays, Tab to move between interactive elements. See [Testing and Storybook](./testing-and-storybook.md) for testing keyboard interactions in stories.
+
+6. **What's focus trapping and when do I need it?**
+   Focus trapping keeps keyboard focus inside a container (typically modals/dialogs). When a modal opens, Tab should cycle within the modal, not escape to the page behind. For state management of modal visibility, see [State Management at Scale](../ui-systems-performance/state-management-at-scale.md).
+
+7. **How do I handle focus management during navigation?**
+   When opening: move focus into the new surface (first focusable element or the container itself). When closing: return focus to the trigger element. For SPA navigation patterns, see [Performance Optimization](../ui-systems-performance/performance-optimization.md) for how navigation affects perceived performance.
+
+8. **What accessibility issues only appear at scale?**
+   Common at-scale issues: inconsistent heading hierarchy, duplicate IDs breaking label associations, inconsistent keyboard patterns between similar components. See [Codebase Conventions](./codebase-conventions.md) for conventions that prevent these at-scale issues.
+
+9. **How do I test accessibility during development?**
+   Layers: (1) browser DevTools accessibility panel, (2) axe-core extension, (3) keyboard-only navigation testing, (4) screen reader testing. See [Testing and Storybook](./testing-and-storybook.md) for integrating a11y testing into Storybook. For production monitoring, see [Observability](../ui-systems-performance/observability.md).
+
+10. **What's the 80/20 rule for accessibility?**
+    Approximately 80% of accessibility comes from using semantic HTML correctly—buttons, links, headings, lists, landmarks. The remaining 20% requires ARIA and JavaScript for complex interactions. See [Component Creation Workflows](./component-creation-workflows.md) for choosing the right elements from the start.
+
+---
+
+*Build accessible frontends from the start. Start building with [Bitloops](https://bitloops.com).*
\ No newline at end of file
diff --git a/documentation/docs/frontend-copilot/best-practices/codebase-conventions.md b/documentation/docs/frontend-copilot/best-practices/codebase-conventions.md
new file mode 100644
index 00000000..99fdfdf8
--- /dev/null
+++ b/documentation/docs/frontend-copilot/best-practices/codebase-conventions.md
@@ -0,0 +1,625 @@
+---
+sidebar_position: 8
+sidebar_label: Codebase Conventions
+title: "Frontend Codebase Conventions: File Structure, Naming, and Patterns That Scale"
+description: "Conventions prevent failure modes, not just enforce style. Learn file structure, naming patterns, barrel exports, and composition rules that scale across teams."
+keywords:
+  [
+    react project structure,
+    frontend file organization,
+    component naming conventions,
+    barrel exports typescript,
+    feature folder structure,
+    react codebase architecture,
+    monorepo component organization,
+    frontend code conventions,
+  ]
+---
+
+# Conventions that scale a codebase
+
+Conventions often seem arbitrary. "Why kebab-case for files but PascalCase for components? Why this folder structure?" The answer isn't preference—it's failure mode prevention. Each convention exists because its absence causes specific problems at scale.
+
+This document covers conventions as constraints: the organizational patterns that prevent confusion, collisions, and maintenance burden.
+
+## Conventions as Constraints
+
+Every convention trades freedom for consistency. That trade is worth it when:
+
+- **The decision recurs** — You name files hundreds of times
+- **Inconsistency compounds** — Different patterns multiply cognitive load
+- **The convention prevents failure** — A specific problem is avoided
+
+### The cost of inconsistency
+
+Without conventions:
+
+```
+src/
+  components/
+    UserProfile.tsx
+    userCard.jsx
+    product-list.tsx
+    OrderHistory/
+      index.js
+      order-history.module.css
+    CheckoutForm.tsx
+    checkout_form.styles.ts
+```
+
+Every file requires a mental lookup. Every import requires checking the actual casing. Every new file starts a debate.
+
+With conventions:
+
+```
+src/
+  components/
+    CheckoutForm/
+      CheckoutForm.tsx
+      CheckoutForm.test.tsx
+      CheckoutForm.styles.ts
+    OrderHistory/
+      OrderHistory.tsx
+      OrderHistory.test.tsx
+    ProductList/
+      ProductList.tsx
+    UserCard/
+      UserCard.tsx
+    UserProfile/
+      UserProfile.tsx
+```
+
+Predictable. Navigable. No decisions required for each new file.
+
+## File Organization
+
+### The component folder pattern
+
+Each component gets a folder:
+
+```
+ComponentName/
+  ComponentName.tsx       # Main component
+  ComponentName.test.tsx  # Tests
+  ComponentName.stories.tsx  # Storybook stories
+  ComponentName.styles.ts # Styles (if extracted)
+  index.ts                # Public exports
+```
+
+**Why folders, not flat files?**
+
+- Related files stay together
+- Imports stay clean (`import { Button } from '@/components/Button'`)
+- Easy to move/delete as a unit
+- Tests and stories don't clutter component directories
+
+### The index.ts pattern
+
+The index file controls what's public:
+
+```tsx
+// ComponentName/index.ts
+export { ComponentName } from './ComponentName';
+export type { ComponentNameProps } from './ComponentName';
+
+// Internal helpers stay private
+// SubComponent.tsx is not exported
+```
+
+**Why index files?**
+
+- Clean imports without file extensions
+- Controlled public API
+- Ability to refactor internals without changing imports
+
+### Feature-based organization
+
+For larger codebases, organize by feature:
+
+```
+src/
+  features/
+    auth/
+      components/
+        LoginForm/
+        SignupForm/
+      hooks/
+        useAuth.ts
+      api/
+        auth.ts
+      types.ts
+      index.ts
+    checkout/
+      components/
+      hooks/
+      api/
+      types.ts
+      index.ts
+  components/          # Shared/generic components
+    Button/
+    Modal/
+    Input/
+  hooks/               # Shared hooks
+  utils/               # Shared utilities
+```
+
+**Why feature-based?**
+
+- Related code is colocated
+- Features can be extracted or deleted as units
+- Reduces cross-feature imports
+- Scales better than type-based organization (`components/`, `hooks/`, `utils/`)
+
+### Type-based vs. feature-based
+
+| Approach | Works best for | Failure mode |
+|----------|----------------|--------------|
+| Type-based | Small projects, component libraries | Chasing across folders for related code |
+| Feature-based | Applications, larger teams | Feature boundaries can become unclear |
+| Hybrid | Most real projects | Requires judgment on what's shared vs. feature-specific |
+
+## Naming Conventions
+
+### File naming
+
+| File type | Convention | Example |
+|-----------|------------|---------|
+| Component | PascalCase | `UserProfile.tsx` |
+| Hook | camelCase, `use` prefix | `useAuth.ts` |
+| Utility | camelCase | `formatDate.ts` |
+| Type file | PascalCase or camelCase | `types.ts`, `User.types.ts` |
+| Constant | camelCase or SCREAMING_SNAKE | `config.ts`, `constants.ts` |
+| Test | Same as source + `.test` | `Button.test.tsx` |
+| Story | Same as source + `.stories` | `Button.stories.tsx` |
+
+### Component naming
+
+```tsx
+// PascalCase for components
+const UserProfile = () => { ... };
+const CheckoutForm = () => { ... };
+
+// Descriptive, noun-based names
+const Button = () => { ... };        // What it is
+const ProductCard = () => { ... };   // What it represents
+const OrderSummary = () => { ... };  // What it shows
+```
+
+**Avoid:**
+- Verbs for components (`GetUser`, `FetchData`)
+- Generic names without context (`Item`, `Container`, `Wrapper`)
+- Abbreviations (`UsrProf`, `ProdCrd`)
+
+### Prop naming
+
+```tsx
+interface ButtonProps {
+  // Actions: on + Event
+  onClick: () => void;
+  onHover: () => void;
+  onFocus: () => void;
+
+  // States: is/has + State (for booleans)
+  isDisabled: boolean;
+  isLoading: boolean;
+  hasError: boolean;
+
+  // Or just the adjective for simpler cases
+  disabled: boolean;  // Standard HTML attribute
+  checked: boolean;
+
+  // Values: descriptive nouns
+  label: string;
+  icon: ReactNode;
+  variant: 'primary' | 'secondary';
+}
+```
+
+### Hook naming
+
+```tsx
+// use + Domain + Action/State
+const useAuth = () => { ... };
+const useUserProfile = () => { ... };
+const useFetchProducts = () => { ... };
+const useLocalStorage = () => { ... };
+
+// Return patterns
+const { user, isLoading, error } = useAuth();
+const [value, setValue] = useLocalStorage('key');
+```
+
+### Variable naming
+
+```tsx
+// Booleans: is/has/should/can
+const isLoading = true;
+const hasPermission = false;
+const shouldFetch = true;
+const canEdit = user.role === 'admin';
+
+// Arrays: plural nouns
+const users = [];
+const products = [];
+const selectedIds = [];
+
+// Event handlers: handle + Event
+const handleClick = () => { ... };
+const handleSubmit = () => { ... };
+const handleUserSelect = () => { ... };
+```
+
+## Composition Patterns
+
+### Component composition
+
+Prefer composition over configuration:
+
+```tsx
+// Over-configured: one component does everything
+<Card
+  title="Product"
+  image={img}
+  description={desc}
+  actions={[{ label: 'Buy', onClick: handleBuy }]}
+  footer={<Price value={99} />}
+  showRibbon
+  ribbonText="Sale"
+/>
+
+// Composed: small pieces, flexible arrangement
+<Card>
+  <Card.Ribbon>Sale</Card.Ribbon>
+  <Card.Image src={img} alt="Product" />
+  <Card.Body>
+    <Card.Title>Product</Card.Title>
+    <Card.Description>{desc}</Card.Description>
+  </Card.Body>
+  <Card.Footer>
+    <Price value={99} />
+    <Button onClick={handleBuy}>Buy</Button>
+  </Card.Footer>
+</Card>
+```
+
+**Why composition?**
+
+- Flexibility: arrange pieces as needed
+- Discoverability: subcomponents are visible
+- No boolean explosion from optional features
+
+### The compound component pattern
+
+```tsx
+// Define subcomponents
+const CardImage = ({ src, alt }) => (
+  <img src={src} alt={alt} className="card-image" />
+);
+
+const CardTitle = ({ children }) => (
+  <h3 className="card-title">{children}</h3>
+);
+
+// Attach to main component
+export const Card = ({ children }) => (
+  <div className="card">{children}</div>
+);
+
+Card.Image = CardImage;
+Card.Title = CardTitle;
+Card.Body = CardBody;
+Card.Footer = CardFooter;
+```
+
+### The render prop pattern
+
+When children need data from parent:
+
+```tsx
+<DataFetcher url="/api/users">
+  {({ data, isLoading, error }) => (
+    isLoading ? <Spinner /> :
+    error ? <Error message={error} /> :
+    <UserList users={data} />
+  )}
+</DataFetcher>
+```
+
+### The slot pattern
+
+Named slots for specific content areas:
+
+```tsx
+interface DialogProps {
+  header: ReactNode;
+  body: ReactNode;
+  footer?: ReactNode;
+}
+
+const Dialog = ({ header, body, footer }: DialogProps) => (
+  <div className="dialog">
+    <header className="dialog-header">{header}</header>
+    <main className="dialog-body">{body}</main>
+    {footer && (
+      <footer className="dialog-footer">{footer}</footer>
+    )}
+  </div>
+);
+
+// Usage
+<Dialog
+  header={<h2>Confirm Action</h2>}
+  body={<p>Are you sure?</p>}
+  footer={
+    <>
+      <Button variant="ghost">Cancel</Button>
+      <Button variant="primary">Confirm</Button>
+    </>
+  }
+/>
+```
+
+## UI Primitives
+
+### Using design system primitives
+
+Design systems often provide primitive components. Use them consistently:
+
+```tsx
+// Don't: mix primitives with raw elements
+<div className="flex gap-4">          {/* Raw div */}
+  <Stack gap={4}>                     {/* System primitive */}
+    <Text variant="heading">Title</Text>
+    <p className="text-gray-500">Subtitle</p>  {/* Raw p */}
+  </Stack>
+</div>
+
+// Do: use primitives consistently
+<Stack gap={4}>
+  <Text variant="heading">Title</Text>
+  <Text variant="muted">Subtitle</Text>
+</Stack>
+```
+
+### When to use primitives
+
+| Use primitive when... | Use raw element when... |
+|----------------------|-------------------------|
+| Semantic meaning is UI-related (layout, text styling) | Semantic meaning is content-related (article, nav, form) |
+| Design system provides the primitive | No relevant primitive exists |
+| Consistency with design system matters | One-off styling is acceptable |
+
+### Primitive layering
+
+```
+Application components
+        ↓
+Feature components
+        ↓
+Shared components
+        ↓
+Design system components
+        ↓
+UI primitives (Stack, Text, Box)
+        ↓
+HTML elements
+```
+
+Higher layers compose lower layers. Don't skip layers arbitrarily.
+
+## Failure Modes and Prevention
+
+### Failure: Can't find the component
+
+**Convention:** Component name = file name = folder name
+
+```
+// Finding UserProfile
+components/UserProfile/UserProfile.tsx
+```
+
+No guessing. Name is the path.
+
+### Failure: Import breaks after refactor
+
+**Convention:** Export from index.ts, import from folder
+
+```tsx
+// Importing
+import { Button } from '@/components/Button';
+
+// Internally, Button/Button.tsx can be renamed to Button/index.tsx
+// or split into multiple files—import path doesn't change
+```
+
+### Failure: Test files scattered everywhere
+
+**Convention:** Tests live next to source
+
+```
+Button/
+  Button.tsx
+  Button.test.tsx   # Right here
+```
+
+Not in a separate `__tests__` folder. When you work on Button, you see Button.test.
+
+### Failure: Can't tell what's public API
+
+**Convention:** index.ts exports public API only
+
+```tsx
+// Button/index.ts
+export { Button } from './Button';
+export type { ButtonProps } from './Button';
+
+// Internal helper not exported
+// ButtonIcon.tsx exists but isn't exported
+```
+
+If it's not in index.ts, it's not public.
+
+### Failure: Naming conflicts
+
+**Convention:** Unique, descriptive names
+
+```tsx
+// Bad: generic names that collide
+import { Card } from '@/features/products/Card';
+import { Card } from '@/features/users/Card';  // Collision!
+
+// Good: namespaced or specific names
+import { ProductCard } from '@/features/products/ProductCard';
+import { UserCard } from '@/features/users/UserCard';
+```
+
+### Failure: Can't understand prop expectations
+
+**Convention:** TypeScript types for all props
+
+```tsx
+interface ButtonProps {
+  variant: 'primary' | 'secondary' | 'ghost';
+  size: 'sm' | 'md' | 'lg';
+  disabled?: boolean;
+  onClick?: () => void;
+  children: ReactNode;
+}
+```
+
+Types are documentation that can't go stale.
+
+## Enforcing Conventions
+
+### Automated enforcement
+
+Use tooling to enforce conventions:
+
+```json
+// ESLint
+{
+  "rules": {
+    "react/jsx-pascal-case": "error",
+    "@typescript-eslint/naming-convention": [
+      "error",
+      { "selector": "variable", "format": ["camelCase", "UPPER_CASE"] },
+      { "selector": "function", "format": ["camelCase", "PascalCase"] }
+    ]
+  }
+}
+
+// Prettier (formatting consistency)
+{
+  "singleQuote": true,
+  "trailingComma": "es5",
+  "tabWidth": 2
+}
+```
+
+### File structure linting
+
+```json
+// eslint-plugin-project-structure or similar
+{
+  "rules": {
+    "project-structure/file-structure": [
+      "error",
+      {
+        "modules": {
+          "components": {
+            "includes": ["*.tsx"],
+            "children": ["index.ts", "*.test.tsx", "*.stories.tsx"]
+          }
+        }
+      }
+    ]
+  }
+}
+```
+
+### Documentation
+
+Document conventions in the repository:
+
+```
+docs/
+  conventions.md      # This document
+  architecture.md     # How the codebase is organized
+  contributing.md     # How to add new code
+```
+
+## How this connects to Bitloops
+
+Conventions only work when every contributor follows them — and new code is where conventions most often break. [Bitloops](https://bitloops.com) generates components that follow your project's conventions from the start: PascalCase component names, colocated file structures (component + test + story in one folder), `index.ts` barrel exports, and feature-based organization. By producing code that already matches your naming, folder, and composition patterns, Bitloops reduces the gap between "how we agreed to write code" and "how code actually gets written," especially when onboarding new contributors or working under time pressure.
+
+---
+
+## Summary
+
+Conventions prevent failure modes. The principles:
+
+| Convention / pattern | Why it exists | What to do in practice | Failure modes it prevents |
+|---|---|---|---|
+| Component folder per component | Keeps related artifacts colocated and makes components movable as a single unit. | Use `ComponentName/` with `ComponentName.tsx`, `ComponentName.test.tsx`, `ComponentName.stories.tsx`, optional `ComponentName.styles.ts`, plus `index.ts`. | Scattered tests/stories, hard-to-delete components, “where is the story/test?” searches, refactors that miss related files. |
+| Name alignment (component = folder = file) | Makes navigation deterministic: the name becomes the path. | Ensure `UserProfile` lives at `components/UserProfile/UserProfile.tsx` (or feature equivalent). Avoid mismatched casing or synonyms. | “Can’t find the component”, duplicate implementations, inconsistent imports, collisions from near-identical names. |
+| `index.ts` as the public API boundary | Separates what’s public from what’s internal and stabilizes import paths over time. | Export only supported surface from `ComponentName/index.ts` (component + props types). Import from the folder: `@/components/Button`. | Import breakage on internal refactors, accidental coupling to private modules, unclear “what’s supported.” |
+| Feature-based organization (with shared layers) | Keeps related logic together and reduces cross-folder chasing as the app grows. | Prefer `src/features/<feature>/{components,hooks,api,types,index.ts}`; reserve `src/components` for genuinely shared UI. | Tangled dependency graph, “type-based” scavenger hunts, unclear ownership, features that are hard to delete/extract. |
+| Predictable file naming by intent | Makes file role obvious at a glance and enables tooling/globbing patterns. | Components: `PascalCase.tsx`; hooks: `useX.ts`; utilities: `camelCase.ts`; tests: `.test.tsx`; stories: `.stories.tsx`. | Confusing imports, inconsistent casing bugs, broken test/story discovery, debates on every new file. |
+| Prop naming conventions | Makes component usage guessable and consistent across the codebase. | Events: `onClick/onChange`; boolean state: `disabled/checked` (HTML) or `isLoading/hasError`; values: noun-based (`variant`, `size`, `label`). | Cognitive load, mismatched prop names between components, misuse and bugs that come from ambiguous props. |
+| Hook and state naming conventions | Encodes semantics directly in names so dataflow is readable without mental decoding. | Hooks: `useDomainState/useFetchX`; booleans: `is/has/should/can`; arrays: plural nouns; handlers: `handleX`. | Misread logic, unclear intent, inconsistent patterns across teams, harder code reviews. |
+| Composition over configuration | Prevents “mega-components” with boolean explosion and brittle conditional branches. | Prefer subcomponents/children composition (`<Card><Card.Header/>…</Card>`) over dozens of props. Add wrappers for recurring compositions. | Inflexible components, hard-to-test variants, undocumented combinations, API bloat and breaking changes. |
+| Compound components (when structure is stable) | Provides a clear, discoverable API for assembling consistent layouts. | Use `Card.Image`, `Card.Body`, `Card.Footer` when the internal structure is a known pattern and consumers benefit from guided composition. | Consumers re-implement layouts inconsistently, ad-hoc DOM structures, styling hacks to force layouts. |
+| Slots / render props (when customization needs data) | Enables controlled flexibility without exposing internals or adding many props. | Use named slots (`header/body/footer`) for structure; use render props when children need parent-provided data (`{(state) => …}`). | Leaky abstraction, consumers depending on internal markup, too many special-case props. |
+| Consistent use of design system primitives | Centralizes spacing/typography/layout decisions and reduces drift. | Use primitives like `Stack/Text/Box` for UI scaffolding; use raw HTML for content semantics (`article/nav/form`). | Mixed styling paradigms, inconsistent spacing/type, duplicated layout utilities, harder theming and audits. |
+| Tests live beside source | Keeps verification close to implementation and improves maintainability. | Place `Button.test.tsx` in `Button/` and align test naming to the component file. | Orphaned tests, tests forgotten during refactors, slower onboarding, missed coverage for changed components. |
+| Convention enforcement via tooling | Keeps conventions stable over time without relying on memory or code review heroics. | Use ESLint/Prettier for naming/formatting; add structure linting rules for folder/file expectations; document conventions in `docs/`. | Convention drift, recurring PR debates, inconsistent folders, “it depends who wrote it” codebase feel. |
+
+The goal isn't to follow rules for their own sake. It's to make the codebase predictable enough that developers can focus on the actual problem instead of navigating inconsistency.
+
+---
+
+## Further reading
+
+- [Bulletproof React — Alan Alickovic](https://github.com/alan2207/bulletproof-react) — An opinionated, production-grade React project structure covering file organization, feature-based folders, naming conventions, and testing placement; a concrete reference implementation of many patterns in this document.
+- [Feature-Sliced Design](https://feature-sliced.design/) — An architectural methodology for organizing frontend projects by features and layers, with clear rules for dependencies and public APIs; directly supports the feature-based organization pattern described here.
+- [Scaling React Server-Side Rendering — Shaundai Person (Netlify)](https://www.patterns.dev/react/compound-pattern/) — Covers the compound component pattern and other composition patterns for React, showing how structural conventions enable scalable component APIs.
+- [ESLint — Configuring Rules](https://eslint.org/docs/latest/use/configure/rules) — Official reference for automating code conventions with ESLint; essential for enforcing naming, structure, and import conventions described in this document.
+- [Prettier — Why Prettier?](https://prettier.io/docs/en/why-prettier) — Explains the philosophy behind opinionated formatting and how automated formatting eliminates style debates, freeing teams to focus on conventions that actually affect architecture.
+
+---
+
+## Frequently Asked Questions (FAQs)
+
+1. **Should I organize by feature or by type (components/, hooks/, utils/)?**
+   Feature-first for product code—each feature contains its components, hooks, and utilities together. Type-first only for truly shared code. See [Component Creation Workflows](./component-creation-workflows.md) for when components should be local vs. shared.
+
+2. **What naming convention should I use for component files?**
+   PascalCase for component files and exports: `UserProfile.tsx` exports `function UserProfile`. Match filename to export exactly. Use `index.ts` only for re-exports, not as the component file itself. For prop naming, see [Component API Design](./component-api-design.md).
+
+3. **Are barrel files (index.ts re-exports) good or bad?**
+   It depends. Good for public APIs (design system packages where you control the interface). Often harmful for application code—they defeat tree-shaking, create circular dependency risks. For performance implications, see [Performance Optimization](../ui-systems-performance/performance-optimization.md).
+
+4. **How do I know if a convention matters or is just preference?**
+   Conventions matter if violating them causes: bugs, confusion for new developers, maintenance burden, or failure modes. "Colocate tests with source files" prevents orphaned tests—see [Testing and Storybook](./testing-and-storybook.md) for test organization patterns.
+
+5. **What's the component folder pattern and when should I use it?**
+   Each component gets a folder: `ComponentName/ComponentName.tsx`, `ComponentName.test.tsx`, `ComponentName.stories.tsx`, `index.ts`. Use it when components have related files. See [Testing and Storybook](./testing-and-storybook.md) for colocating stories.
+
+6. **How do I prevent naming conflicts across features?**
+   Use specific, namespaced names: `ProductCard`, `UserCard` instead of just `Card` in different features. If both features need a generic Card, it belongs in shared components. See [Design System Consumption](./design-system-consumption.md) for design system component naming.
+
+7. **Where should TypeScript types live?**
+   Colocate types with the code that uses them when possible. Shared types belong in a central `types/` folder. See [Data Contracts](./data-contracts.md) for organizing data types and [Component API Design](./component-api-design.md) for prop types.
+
+8. **What file structure patterns prevent circular dependencies?**
+   Layered architecture: higher layers import from lower, never the reverse. Features don't import from each other—shared code lives in a common layer. See [Data Contracts](./data-contracts.md) for keeping mapping layers independent.
+
+9. **How do I enforce conventions across a team?**
+   Multiple layers: (1) ESLint/Prettier for automated enforcement, (2) documented conventions in the repository, (3) code review checklist, (4) file structure linting. See [Design System Consumption](./design-system-consumption.md) for linting design token usage.
+
+10. **What happens when conventions conflict with rapid development?**
+    Conventions save time in the long run but can slow initial development. For rapid prototyping: relax conventions temporarily but schedule cleanup. See [Testing and Storybook](./testing-and-storybook.md) for how stories can capture intended patterns even during rapid development.
+
+---
+
+*Build codebases that are predictable to navigate. Start building with [Bitloops](https://bitloops.com).*
\ No newline at end of file
diff --git a/documentation/docs/frontend-copilot/best-practices/component-api-design.md b/documentation/docs/frontend-copilot/best-practices/component-api-design.md
new file mode 100644
index 00000000..aa84f480
--- /dev/null
+++ b/documentation/docs/frontend-copilot/best-practices/component-api-design.md
@@ -0,0 +1,531 @@
+---
+sidebar_position: 3
+sidebar_label: Component API Design
+title: "Component API Design: Props as Contracts, Variants, and Stable Interfaces"
+description: "Design component APIs that don't break. Learn semantic props vs. mechanical props, variant patterns, boolean explosion prevention, and stable interface evolution."
+keywords:
+  [
+    react component api design,
+    props best practices react,
+    component interface design,
+    boolean prop explosion,
+    react component variants,
+    typescript component props,
+    stable component api,
+    semantic vs mechanical props
+  ]
+---
+
+# Designing contracts that scale
+
+The props you expose are a contract. Every consumer of your component depends on that contract. A well-designed API makes components easy to use correctly and hard to use incorrectly. A poorly designed API creates confusion, bugs, and breaking changes.
+
+This document covers the principles of component API design: how to choose props that express intent, avoid common pitfalls, and evolve APIs without breaking consumers.
+
+## Props as Contracts
+
+When you define a component's props, you're making promises:
+
+- **"I accept these inputs"** — The prop types define what consumers can pass.
+- **"I produce this output"** — The rendered result depends on those inputs predictably.
+- **"I won't break you"** — Future versions will honor the contract or communicate changes explicitly.
+
+### The contract mindset
+
+Think of your component as a service with an API:
+
+```tsx
+// This is a contract
+interface ButtonProps {
+  label: string;
+  variant?: 'primary' | 'secondary' | 'ghost';
+  disabled?: boolean;
+  onClick?: () => void;
+}
+```
+
+Consumers write code against this contract:
+
+```tsx
+<Button label="Submit" variant="primary" onClick={handleSubmit} />
+```
+
+If you later change `variant` to `type`, or rename `label` to `text`, you've broken the contract. Every consumer must update their code.
+
+**The rule:** Design props as if changing them later will cost you money. Because in development time, it will.
+
+## Semantic vs. Mechanical Props
+
+The most important distinction in prop design is between *semantic* and *mechanical* props.
+
+### Mechanical props
+
+Mechanical props describe *how* something looks or works:
+
+```tsx
+interface ButtonProps {
+  backgroundColor: string;
+  textColor: string;
+  borderRadius: number;
+  fontSize: number;
+  paddingX: number;
+  paddingY: number;
+}
+```
+
+**Problems with mechanical props:**
+
+- Consumers need to understand implementation details
+- No constraints—any combination is allowed, including ugly ones
+- Changes to design require updating every usage
+- Inconsistency across the codebase
+
+### Semantic props
+
+Semantic props describe *what* something is or *why* it's used:
+
+```tsx
+interface ButtonProps {
+  variant: 'primary' | 'secondary' | 'ghost';
+  size: 'sm' | 'md' | 'lg';
+  intent?: 'default' | 'danger' | 'success';
+}
+```
+
+**Benefits of semantic props:**
+
+- Consumers express intent, not implementation
+- Constrained options prevent misuse
+- Design changes update all usages automatically
+- Consistency by default
+
+### The translation layer
+
+Semantic props get translated to mechanical output inside the component:
+
+```tsx
+const Button = ({ variant, size, intent = 'default' }) => {
+  const variantStyles = {
+    primary: 'bg-blue-600 text-white',
+    secondary: 'bg-gray-200 text-gray-800',
+    ghost: 'bg-transparent text-gray-600'
+  };
+
+  const sizeStyles = {
+    sm: 'px-3 py-1.5 text-sm',
+    md: 'px-4 py-2 text-base',
+    lg: 'px-6 py-3 text-lg'
+  };
+
+  return (
+    <button className={`${variantStyles[variant]} ${sizeStyles[size]}`}>
+      {/* ... */}
+    </button>
+  );
+};
+```
+
+The component owns the translation. Consumers never need to know that `primary` means `bg-blue-600`.
+
+### When mechanical props are acceptable
+
+Sometimes mechanical props are the right choice:
+
+- **Genuinely variable values**: A chart component needs `width` and `height` because these aren't semantic categories.
+- **Escape hatches**: A `className` prop lets consumers customize when semantic options don't cover their case.
+- **Low-level primitives**: A `Box` component might expose spacing props because it *is* a mechanical abstraction.
+
+The key is being intentional. Don't mix mechanical and semantic props arbitrarily.
+
+## Boolean Explosion
+
+One of the most common API design mistakes is "boolean explosion"—using multiple boolean props where a single discriminated prop would be clearer.
+
+### The problem
+
+```tsx
+interface ButtonProps {
+  isLoading?: boolean;
+  isDisabled?: boolean;
+  isError?: boolean;
+  isSuccess?: boolean;
+}
+```
+
+This creates 2^4 = 16 possible states, most of which are invalid:
+
+- `isLoading && isError` — Loading and error at the same time?
+- `isDisabled && isSuccess` — Disabled but successful?
+- `isLoading && isDisabled && isError && isSuccess` — All four at once?
+
+Consumers must figure out which combinations are valid. The component must handle—or explicitly reject—invalid combinations.
+
+### The solution: discriminated unions
+
+Replace boolean flags with a single status prop:
+
+```tsx
+interface ButtonProps {
+  status?: 'idle' | 'loading' | 'success' | 'error';
+  disabled?: boolean;
+}
+```
+
+Now there are exactly 4 status states (plus disabled as an orthogonal concern). Invalid combinations are impossible to express.
+
+### Recognizing boolean explosion
+
+Watch for these patterns:
+
+```tsx
+// Red flag: related booleans
+isOpen, isClosed
+isLoading, isLoaded, isError
+isExpanded, isCollapsed
+isPending, isSuccess, isFailure
+
+// Better: single discriminated prop
+state: 'open' | 'closed'
+status: 'loading' | 'loaded' | 'error'
+expanded: boolean  // Only two states? Boolean is fine
+result: 'pending' | 'success' | 'failure'
+```
+
+**The heuristic:** If you have 2+ booleans that represent mutually exclusive states, combine them into one prop.
+
+### When booleans are fine
+
+Booleans work well for truly independent, binary options:
+
+```tsx
+interface DialogProps {
+  open: boolean;           // Dialog is open or not
+  closeOnEscape?: boolean; // Orthogonal behavior
+  closeOnOverlayClick?: boolean; // Orthogonal behavior
+}
+```
+
+These three booleans aren't mutually exclusive—they can combine freely, and all combinations are valid.
+
+## Stable vs. Extensible APIs
+
+API design involves tension between stability (don't change things) and extensibility (allow future growth). The goal is to design APIs that can evolve without breaking.
+
+### Stable props
+
+Some props should rarely change:
+
+- **Core identity props**: `id`, `name`, `label`
+- **Core behavior props**: `onClick`, `onChange`, `onSubmit`
+- **Core semantic props**: `variant`, `size`, `type`
+
+These form the stable core of your contract. Changing them is a breaking change.
+
+### Extensible patterns
+
+Design for extension without modification:
+
+**1. Object props for grouped options:**
+
+```tsx
+// Inflexible: flat props
+<DatePicker
+  minDate={min}
+  maxDate={max}
+  excludeDates={excluded}
+  includeDates={included}
+/>
+
+// Extensible: object prop
+<DatePicker
+  dateConstraints={{
+    min: min,
+    max: max,
+    exclude: excluded,
+    include: included
+  }}
+/>
+```
+
+Adding new date constraints doesn't change the prop signature.
+
+**2. Render props and slots for customization:**
+
+```tsx
+// Inflexible: boolean flags
+<Card showHeader showFooter showDivider />
+
+// Extensible: slot props
+<Card
+  header={<CardHeader title="My Card" />}
+  footer={<CardFooter actions={actions} />}
+/>
+```
+
+New slots can be added without breaking existing usages.
+
+**3. Spreading for escape hatches:**
+
+```tsx
+interface ButtonProps extends React.ButtonHTMLAttributes<HTMLButtonElement> {
+  variant: 'primary' | 'secondary';
+}
+
+const Button = ({ variant, ...rest }: ButtonProps) => (
+  <button className={variantStyles[variant]} {...rest} />
+);
+```
+
+Consumers can pass any valid button attribute without you explicitly supporting each one.
+
+### The extension checklist
+
+Before adding a new prop, ask:
+
+- [ ] Could this be a value in an existing prop? (`variant: 'new-variant'`)
+- [ ] Could this be a property in an existing object prop?
+- [ ] Is this prop orthogonal to existing props, or does it create invalid combinations?
+- [ ] Can I add this without changing any existing behavior?
+
+## Backwards Compatibility
+
+Maintaining backwards compatibility is essential for shared components. Breaking changes cascade through codebases, creating upgrade friction and bugs.
+
+### Non-breaking changes
+
+These changes are safe:
+
+- **Adding optional props** with sensible defaults
+- **Adding new values** to union types
+- **Widening types** (accepting more inputs)
+- **Adding new callbacks** (optional)
+
+```tsx
+// Before
+interface ButtonProps {
+  variant: 'primary' | 'secondary';
+}
+
+// After: non-breaking additions
+interface ButtonProps {
+  variant: 'primary' | 'secondary' | 'ghost';  // New value
+  size?: 'sm' | 'md' | 'lg';  // New optional prop
+}
+```
+
+### Breaking changes
+
+These changes break consumers:
+
+- **Removing props**
+- **Renaming props**
+- **Changing prop types** (narrowing)
+- **Removing values** from union types
+- **Changing default behavior**
+
+### Managing breaking changes
+
+When breaking changes are necessary:
+
+**1. Deprecation warnings:**
+
+```tsx
+interface ButtonProps {
+  /** @deprecated Use `variant` instead */
+  type?: 'primary' | 'secondary';
+  variant?: 'primary' | 'secondary';
+}
+
+const Button = ({ type, variant, ...props }) => {
+  if (type !== undefined) {
+    console.warn('Button: `type` is deprecated, use `variant` instead');
+  }
+
+  const effectiveVariant = variant ?? type ?? 'primary';
+  // ...
+};
+```
+
+**2. Codemods for large-scale updates:**
+
+For widely-used components, provide automated migration tools.
+
+**3. Semantic versioning:**
+
+Major versions signal breaking changes. Consumers can upgrade on their schedule.
+
+### The compatibility mindset
+
+Every prop you add is a promise. Before adding props:
+
+- Will this prop name still make sense in two years?
+- Is the type broad enough to accommodate likely extensions?
+- Can I document the behavior precisely?
+
+Fewer, well-designed props beat many hastily-added ones.
+
+## Prop Naming Conventions
+
+Consistent naming makes APIs predictable. Consumers can guess prop names before reading documentation.
+
+### Event handlers: `on` + `Event`
+
+```tsx
+// Consistent
+onClick, onChange, onSubmit, onFocus, onBlur
+
+// Inconsistent
+handleClick  // Suggests internal handler
+clickHandler // Noun instead of event name
+click        // Missing "on" prefix
+```
+
+### Boolean props: positive assertions
+
+```tsx
+// Good: positive assertions
+disabled, hidden, required, checked
+
+// Avoid: negations (confusing double-negatives)
+notDisabled, isNotHidden
+```
+
+### Render props and slots: noun or adjective
+
+```tsx
+// Clear: nouns for slot content
+header, footer, icon, prefix, suffix
+
+// Clear: functions for render props
+renderItem, renderHeader, children
+```
+
+### Size and variant props: descriptive values
+
+```tsx
+// Good: self-documenting values
+size: 'sm' | 'md' | 'lg' | 'xl'
+variant: 'primary' | 'secondary' | 'ghost'
+
+// Avoid: numeric or abstract values
+size: 1 | 2 | 3 | 4
+variant: 'type-a' | 'type-b'
+```
+
+## Designing for TypeScript
+
+TypeScript makes APIs self-documenting and catches errors at compile time. Leverage it fully.
+
+### Discriminated unions for state
+
+```tsx
+type AsyncState<T> =
+  | { status: 'idle' }
+  | { status: 'loading' }
+  | { status: 'success'; data: T }
+  | { status: 'error'; error: Error };
+
+interface DataDisplayProps<T> {
+  state: AsyncState<T>;
+  renderData: (data: T) => ReactNode;
+}
+```
+
+TypeScript enforces that `data` is only accessed when `status === 'success'`.
+
+### Generic components
+
+```tsx
+interface SelectProps<T> {
+  options: T[];
+  value: T;
+  onChange: (value: T) => void;
+  getLabel: (option: T) => string;
+}
+
+function Select<T>({ options, value, onChange, getLabel }: SelectProps<T>) {
+  // Type-safe for any T
+}
+```
+
+### Strict prop relationships
+
+```tsx
+// If loading, data and error are unavailable
+type DataViewProps =
+  | { loading: true }
+  | { loading: false; data: Data; error?: never }
+  | { loading: false; data?: never; error: Error };
+```
+
+Invalid combinations become type errors.
+
+## How this connects to Bitloops
+
+Designing stable, semantic component APIs is one of the highest-leverage activities in frontend development — and one of the easiest to get wrong under deadline pressure. [Bitloops](https://bitloops.com) generates components with prop interfaces derived from the design itself: variants map to semantic props, repeated patterns produce typed enums, and slot-based composition is favored over prop sprawl. The result is a starting API that follows the principles in this document — contracts over knobs, intent over mechanics — so teams spend less time retrofitting props and more time building features.
+
+---
+
+## Summary
+
+Component API design is contract design. The principles:
+
+| Principle | Application |
+|---|---|
+| Props are contracts | Treat every prop as a long-lived promise to every consumer. Prefer stability over cleverness: once a prop ships, changing its name/type/default behavior has a real migration cost. Design “as if changes cost money”: pick durable names, document guarantees, and keep behavior predictable. |
+| Prefer semantic over mechanical props | Expose *intent* (e.g. `variant`, `size`, `intent`) rather than implementation knobs (e.g. `paddingX`, `backgroundColor`). Keep the translation layer inside the component so design updates propagate automatically. Allow mechanical inputs only when the value is genuinely continuous (e.g. chart dimensions) or when providing an explicit escape hatch (`className`). |
+| Avoid boolean explosion | If multiple booleans describe mutually exclusive states, collapse them into one discriminated prop (e.g. `status: 'idle' | 'loading' | 'success' | 'error'`). Keep booleans for truly orthogonal, independent toggles (e.g. `closeOnEscape`, `closeOnOverlayClick`). The goal is to prevent invalid combinations and reduce consumer guesswork. |
+| Design for extension without prop churn | Prefer patterns that allow growth without adding many new top-level props: group related options into object props, use slots (e.g. `header`, `footer`, `icon`) or render props where customization is expected, and spread native attributes when appropriate (e.g. `...buttonProps`). Add new union values rather than new booleans when expanding variants. |
+| Maintain backwards compatibility | Make safe changes by adding optional props with defaults, widening types, or adding new union values. Avoid breaking changes (rename/remove/narrow/change defaults). If breaking is unavoidable, provide a deprecation path: support old + new temporarily, warn in dev, and ship codemods when components are widely used. |
+| Name props predictably | Use consistent conventions so consumers can guess APIs: event handlers as `onX`, booleans as positive assertions (`disabled`, `required`), and slots as nouns (`header`, `suffix`). Prefer descriptive enum values (`'sm' | 'md' | 'lg'`, `'primary' | 'secondary' | 'ghost'`) over numeric/opaque labels. |
+| Use TypeScript to enforce valid states | Encode constraints in types so invalid combinations are unrepresentable: discriminated unions for async state, generics for reusable inputs, and strict unions for mutually exclusive props. Use TS to shift errors left (compile time) and reduce runtime branching and documentation burden. |
+
+A well-designed API is invisible—consumers use it correctly without thinking. A poorly designed API creates constant friction. Invest time upfront; it compounds.
+
+---
+
+## Further reading
+
+- [React TypeScript Cheatsheet — Props](https://react-typescript-cheatsheet.netlify.app/docs/basic/getting-started/basic_type_example/) — Community-maintained reference for typing React props with TypeScript, including discriminated unions, generics, and event handlers.
+- [Radix Primitives — API Design](https://www.radix-ui.com/primitives) — Study how Radix designs unstyled, composable component APIs with slots, polymorphism, and accessibility built in; a benchmark for prop and composition design.
+- [Effective TypeScript — Dan Vanderkam](https://effectivetypescript.com/) — Practical patterns for making TypeScript types encode your domain constraints, directly applicable to designing component props that prevent invalid states.
+- [API Design Matters — Michi Henning (ACM Queue)](https://queue.acm.org/detail.cfm?id=1255422) — Although focused on general API design, the principles of minimal surface area, consistency, and hard-to-misuse interfaces apply directly to component prop design.
+- [Designing the Perfect Slider — Smashing Magazine](https://www.smashingmagazine.com/2017/07/designing-perfect-slider/) — A deep dive into designing a single component's API well, covering the trade-offs between flexibility and simplicity that every component author faces.
+
+---
+
+## Frequently Asked Questions (FAQs)
+
+1. **What's the difference between semantic and mechanical props?**
+   Semantic props describe intent: `variant="primary"`, `size="large"`, `status="error"`. Mechanical props describe implementation: `backgroundColor="blue"`, `padding={16}`, `borderWidth={2}`. Prefer semantic props—they remain stable when visual implementation changes. See [Design System Consumption](./design-system-consumption.md) for token-based styling that reinforces semantic props.
+
+2. **How do I avoid boolean prop explosion?**
+   Replace multiple related booleans with a single variant prop. Instead of `<Button isLarge isPrimary isOutlined />` (8 possible combinations), use `<Button variant="primary" size="lg" style="outlined" />`. If you have 3+ related booleans, you have a variant system in disguise. See [Component Creation Workflows](./component-creation-workflows.md) for when to split components.
+
+3. **When should I use `children` vs. named slots like `header`, `footer`, `icon`?**
+   Use `children` for simple, single content areas where order doesn't matter. Use named slots when: (1) the component has multiple distinct regions, (2) you need to enforce structure, (3) content needs specific styling or behavior. Named slots make the API explicit and self-documenting.
+
+4. **How do I evolve a component API without breaking consumers?**
+   Rules for non-breaking changes: (1) add new optional props, never change required ones, (2) deprecate with console warnings before removing, (3) use TypeScript to catch breaks at compile time, (4) version your design system if breaking changes are necessary. See [Data Contracts](./data-contracts.md) for similar contract evolution patterns.
+
+5. **Should I expose `className` or `style` props on design system components?**
+   Avoid exposing escape hatches like `className` unless absolutely necessary—they invite design system drift. If you must, consider naming it `__unsafeClassName` to signal it's discouraged. See [Design System Consumption](./design-system-consumption.md) for preventing drift patterns.
+
+6. **How do I design props for compound components (Card.Header, Card.Body)?**
+   Keep compound component props minimal—they're for structure, not configuration. The parent component can accept shared configuration and pass it via context. Each sub-component should be self-contained. See [Component Creation Workflows](./component-creation-workflows.md) for boundary decisions.
+
+7. **What's the right level of flexibility in component APIs?**
+   Flexibility should match expected variation. A Button needs variants (primary, secondary) because that's how buttons are used. It doesn't need a `customHoverColor` prop because that's design drift. See [Design System Consumption](./design-system-consumption.md) for the balance between flexibility and constraint.
+
+8. **How do I handle required vs. optional props?**
+   Make props required when the component can't render meaningfully without them (a Button needs children or an icon). Make props optional when there's a sensible default. For accessibility requirements on props, see [Accessibility](./accessibility.md).
+
+9. **Should I use TypeScript discriminated unions for component props?**
+   Yes, for mutually exclusive configurations. Instead of `<Component showImage imageUrl={url} />` where `imageUrl` is ignored without `showImage`, use a union: `{ type: 'with-image'; imageUrl: string } | { type: 'no-image' }`. For TypeScript in data contracts, see [Data Contracts](./data-contracts.md).
+
+10. **How do I document component APIs effectively?**
+    Document: (1) what each prop does, (2) valid values and their meaning, (3) default values, (4) which combinations are valid, (5) example usage. See [Testing and Storybook](./testing-and-storybook.md)—stories serve as executable documentation where each story demonstrates valid usage.
+
+---
+
+*Design component APIs that your team uses correctly without thinking. Start building with [Bitloops](https://bitloops.com).*
\ No newline at end of file
diff --git a/documentation/docs/frontend-copilot/best-practices/component-creation-workflows.md b/documentation/docs/frontend-copilot/best-practices/component-creation-workflows.md
new file mode 100644
index 00000000..b1b014df
--- /dev/null
+++ b/documentation/docs/frontend-copilot/best-practices/component-creation-workflows.md
@@ -0,0 +1,405 @@
+---
+sidebar_position: 2
+sidebar_label: Component Creation Workflows
+title: "When to Create React Components: Extraction Signals, Boundaries, and Abstraction Timing"
+description: "When should a component exist? How do you decide its boundaries? Learn the signals that indicate component boundaries, determine component structure and prevent premature abstraction."
+keywords:
+  [
+    when to create react component,
+    component extraction patterns,
+    react component boundaries,
+    premature abstraction react,
+    reusable vs one-off components,
+    container presentational pattern,
+    component refactoring signals,
+    react code organization
+  ]
+---
+
+# The Lifecycle of a Component
+
+Every component starts as a decision. Not a file, not a function—a decision that *this piece of UI deserves its own identity*. Getting that decision right determines whether your codebase scales gracefully or accumulates friction.
+
+This document covers the lifecycle of that decision: when to create components, how to draw their boundaries, and when extraction serves the codebase versus when it creates unnecessary indirection.
+
+## The Component Decision Moment
+
+Components don't need to exist from the start. In fact, starting with too many components is a common source of friction. The question isn't "what could be a component?" but "what *needs* to be a component right now?"
+
+**A component should exist when:**
+
+1. **It appears more than once** — The clearest signal. If you're copying JSX, extract it.
+2. **It has a distinct data boundary** — It fetches its own data, manages its own state, or receives a cohesive set of props that represent a single concept.
+3. **It has a distinct interaction boundary** — It handles user interactions that don't need to propagate upward.
+4. **It's cognitively heavy** — Even if it appears once, if understanding it requires scrolling or mental bookmarks, it deserves extraction.
+5. **It needs independent testing** — If you want to test a piece of UI in isolation, it needs to be isolatable.
+
+**A component should NOT exist when:**
+
+- You're extracting "just in case" it might be reused
+- The extraction would require passing many props that were previously local variables
+- The logic is tightly coupled to its parent and has no independent meaning
+
+### The premature abstraction trap
+
+Extracting too early creates components that:
+
+- Have awkward APIs because they were designed before the use cases were clear
+- Pass props through multiple layers (prop drilling)
+- Need frequent modification because the abstraction was wrong
+
+**The rule:** Extract when you see the pattern, not when you imagine it.
+
+```tsx
+// Too early: extracting on first use
+// You don't know what variations exist yet
+const UserBadge = ({ name, avatar, role }) => (
+  <div className="flex items-center gap-2">
+    <img src={avatar} alt={name} className="w-8 h-8 rounded-full" />
+    <span>{name}</span>
+    <span className="text-xs text-gray-500">{role}</span>
+  </div>
+);
+
+// Better: wait until you see the second usage
+// Then you know what varies and what's constant
+```
+
+## Boundary Heuristics
+
+Once you've decided a component should exist, where do you draw its edges? Three heuristics help:
+
+### 1. Data cohesion
+
+A component's boundary should align with data boundaries. If a piece of UI displays data from a single source, it's a candidate for one component. If it combines data from multiple sources, consider whether those sources are conceptually unified or separate.
+
+```tsx
+// Good boundary: single data concept (a product)
+const ProductCard = ({ product }) => (
+  <div>
+    <h3>{product.name}</h3>
+    <p>{product.price}</p>
+    <img src={product.image} alt={product.name} />
+  </div>
+);
+
+// Questionable boundary: mixing concepts
+const ProductWithReviews = ({ product, reviews, relatedProducts }) => (
+  // This component is doing too much
+  // Consider: ProductCard + ReviewList + RelatedProducts
+);
+```
+
+### 2. Interaction isolation
+
+Components that handle user interaction should own the full interaction cycle. If a click handler needs to coordinate with a parent, ask whether the component boundary is in the right place.
+
+```tsx
+// Good: component owns its interaction
+const LikeButton = ({ postId, initialCount }) => {
+  const [count, setCount] = useState(initialCount);
+  const [liked, setLiked] = useState(false);
+
+  const handleClick = async () => {
+    setLiked(!liked);
+    setCount(c => liked ? c - 1 : c + 1);
+    await api.toggleLike(postId);
+  };
+
+  return <button onClick={handleClick}>♥ {count}</button>;
+};
+
+// Awkward: component can't function without parent coordination
+const LikeButton = ({ liked, count, onLike }) => (
+  // Why isn't this just a <button> in the parent?
+  <button onClick={onLike}>♥ {count}</button>
+);
+```
+
+### 3. Layout responsibility
+
+A component should either control layout *or* be a layout participant, rarely both. Components that try to position themselves *and* arrange their children often become rigid.
+
+```tsx
+// Good: card doesn't know where it lives
+const ProductCard = ({ product }) => (
+  <div className="rounded-lg shadow p-4">
+    {/* Card internals */}
+  </div>
+);
+
+// Good: grid controls layout
+const ProductGrid = ({ products }) => (
+  <div className="grid grid-cols-3 gap-4">
+    {products.map(p => <ProductCard key={p.id} product={p} />)}
+  </div>
+);
+
+// Awkward: card tries to control its own grid position
+const ProductCard = ({ product, gridColumn }) => (
+  <div className={`rounded-lg shadow p-4 col-span-${gridColumn}`}>
+    {/* Now the card knows about the grid */}
+  </div>
+);
+```
+
+## Reusable vs. Local: The Extraction Decision
+
+Not every component needs to be reusable. In fact, most components should start as local—specific to their context—and graduate to reusable only when reuse materializes.
+
+### The locality spectrum
+
+```
+Local                                              Reusable
+  │                                                    │
+  ▼                                                    ▼
+Feature-specific ──► Section-specific ──► Page-agnostic ──► Design system
+```
+
+**Local components** live near their usage:
+- `features/checkout/components/CheckoutSummary.tsx`
+- Tightly coupled to feature logic
+- Can make assumptions about context
+
+**Reusable components** live in shared locations:
+- `components/ui/Button.tsx`
+- Context-agnostic
+- Stable APIs
+
+### When to graduate a component
+
+Move a component toward reusability when:
+
+1. **Three or more usages exist** — The "rule of three" helps avoid premature abstraction.
+2. **Usages are in different features** — Same-feature reuse often doesn't need extraction; the feature might change as a unit.
+3. **The API is stable** — If you're still changing props frequently, the component isn't ready.
+4. **The variations are known** — You can define the prop interface because you've seen the actual variations.
+
+### The extraction checklist
+
+Before extracting to a shared location:
+
+- [ ] Are there 3+ usages?
+- [ ] Are usages in different features/pages?
+- [ ] Has the API been stable for several iterations?
+- [ ] Can you write the prop types without guessing?
+- [ ] Does extraction reduce total code, or just move it?
+
+If you answered "no" to any of these, keep it local.
+
+## Container vs. Presentational as Workflow
+
+The container/presentational split is often taught as an architecture pattern. More usefully, it's a *workflow* pattern—a way to think about component creation order.
+
+### The pattern
+
+**Presentational components:**
+- Receive data via props
+- Don't fetch or manage global state
+- Focus on rendering
+
+**Container components:**
+- Fetch data or connect to state
+- Handle business logic
+- Delegate rendering to presentational children
+
+### As a workflow decision
+
+When creating a new component:
+
+1. **Start presentational** — Build the UI first, with hardcoded or mock data. This lets you iterate on visuals without worrying about data.
+
+2. **Add a container when needed** — Once the presentation is solid, wrap it with data-fetching logic if required.
+
+3. **Keep them separate or merge them** — If the container logic is trivial, merging is fine. If it's complex, separation helps testing.
+
+```tsx
+// Step 1: Build the presentation
+const UserProfile = ({ user }) => (
+  <div>
+    <img src={user.avatar} alt={user.name} />
+    <h1>{user.name}</h1>
+    <p>{user.bio}</p>
+  </div>
+);
+
+// Step 2: Add a container when data requirements are known
+const UserProfileContainer = ({ userId }) => {
+  const { data: user, isLoading } = useUser(userId);
+
+  if (isLoading) return <UserProfileSkeleton />;
+  return <UserProfile user={user} />;
+};
+
+// Alternative: merge if logic is trivial
+const UserProfile = ({ userId }) => {
+  const { data: user, isLoading } = useUser(userId);
+
+  if (isLoading) return <Skeleton />;
+
+  return (
+    <div>
+      <img src={user.avatar} alt={user.name} />
+      <h1>{user.name}</h1>
+      <p>{user.bio}</p>
+    </div>
+  );
+};
+```
+
+The decision isn't about purity—it's about what makes iteration faster and testing easier.
+
+## The Component Lifecycle
+
+Components aren't static. They evolve through predictable phases:
+
+### 1. Birth (inline)
+
+A piece of UI starts inline in its parent. This is fine. Don't extract prematurely.
+
+```tsx
+const Page = () => (
+  <main>
+    <div className="flex items-center gap-2">
+      <img src={user.avatar} className="w-8 h-8 rounded-full" />
+      <span>{user.name}</span>
+    </div>
+    {/* ... rest of page */}
+  </main>
+);
+```
+
+### 2. Growth (local extraction)
+
+When the inline code becomes unwieldy or appears twice, extract it locally.
+
+```tsx
+// Same file or feature folder
+const UserBadge = ({ user }) => (
+  <div className="flex items-center gap-2">
+    <img src={user.avatar} className="w-8 h-8 rounded-full" />
+    <span>{user.name}</span>
+  </div>
+);
+
+const Page = () => (
+  <main>
+    <UserBadge user={user} />
+    {/* ... rest of page */}
+  </main>
+);
+```
+
+### 3. Maturation (shared extraction)
+
+When the component is used across features and its API is stable, promote it to a shared location.
+
+```tsx
+// components/ui/UserBadge.tsx
+export const UserBadge = ({ user, size = 'md' }) => {
+  const sizeClasses = {
+    sm: 'w-6 h-6',
+    md: 'w-8 h-8',
+    lg: 'w-12 h-12'
+  };
+
+  return (
+    <div className="flex items-center gap-2">
+      <img
+        src={user.avatar}
+        className={`${sizeClasses[size]} rounded-full`}
+      />
+      <span>{user.name}</span>
+    </div>
+  );
+};
+```
+
+### 4. Deprecation
+
+Components sometimes outlive their usefulness. When a component:
+
+- Is used in only one place after refactoring
+- Has been replaced by a better abstraction
+- No longer fits the design system
+
+...it should be inlined or deleted, not left as cruft.
+
+## Practical Workflow
+
+When building a new feature:
+
+1. **Start with one component** — The feature root. Don't pre-plan the component tree.
+2. **Extract when it hurts** — When a section becomes unwieldy, extract it. Not before.
+3. **Keep extractions local** — New components live in the feature folder. They're not shared yet.
+4. **Watch for patterns** — When the same shape appears three times, it's time to formalize.
+5. **Promote gradually** — Move to shared locations only when cross-feature usage emerges.
+6. **Delete aggressively** — Unused components are worse than duplicated code. At least duplicated code is visible.
+
+## How this connects to Bitloops
+
+Deciding when to extract a component, where to draw its boundary, and when to promote it from local to shared — these are judgment calls that slow teams down, especially when working from design files. [Bitloops](https://bitloops.com) accelerates this workflow by analyzing your designs and generating components with boundaries already aligned to visual and data structure. Instead of starting from a blank file and extracting later, you start with well-scoped components that follow the local-first, promote-gradually lifecycle described above. The extraction decisions are still yours, but the starting point is much closer to the right answer.
+
+---
+
+## Summary
+
+Component creation is a workflow, not an architecture diagram. The key principles:
+
+| Principle | Application |
+|---|---|
+| Extract when you see the pattern | Don’t extract on first use. Keep UI inline until you observe real repetition in structure or behavior. Once duplication appears, extract to reduce cognitive load. Use the “rule of three” (3+ real usages) before promoting a component to shared UI. |
+| Align boundaries with data | Define component boundaries around a single data concept (e.g. `product`, `user`, `orderSummary`). If a component depends on multiple unrelated data sources, split it into smaller components and compose them at a higher level. |
+| Start local, graduate_toggle to shared | New components should live close to their feature initially. Promote them to shared locations only when they are reused across features and their API has stabilized. Local components can assume context; shared components should remain context-agnostic. |
+| Container/presentational is workflow | Treat container vs. presentational as a build order, not a rigid rule. Start by building the presentational component with mock or fixture data. Introduce a container when data-fetching, state, or orchestration becomes non-trivial. |
+| Components have lifecycles | Components evolve over time: inline → locally extracted → shared. They should also be inlined or deleted when reuse disappears or abstractions no longer hold. Removing obsolete components is part of healthy system maintenance. |
+
+The goal isn't the fewest components or the most reusable components. It's components that make the codebase easier to understand and change.
+
+---
+
+## Further reading
+
+- [Atomic Design — Brad Frost](https://atomicdesign.bradfrost.com/) — The original methodology for decomposing UIs into atoms, molecules, organisms, templates, and pages; provides a shared vocabulary for deciding component granularity.
+- [Thinking in React — React Docs](https://react.dev/learn/thinking-in-react) — Official walkthrough of how to break a UI into a component hierarchy, decide where state lives, and build top-down; the definitive starting point for React component design.
+- [Presentational and Container Components — Dan Abramov](https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0) — The original article that popularized separating data-fetching containers from presentational components (with Dan's own retrospective on when the pattern still applies).
+- [The Wrong Abstraction — Sandi Metz](https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction) — Explains why premature extraction is worse than duplication; directly supports the "extract when it hurts" workflow described in this document.
+- [Refactoring UI](https://www.refactoringui.com/) — Practical design-driven guidance on building UI components that look right from the start, reducing the need for constant extraction and restyling.
+
+---
+
+## Frequently Asked Questions (FAQs)
+
+1. **How do I know when to extract a component vs. keep code inline?**
+   Extract when you see: (1) the same UI appearing in 2+ places, (2) a piece of UI that has a clear, describable purpose, (3) a section exceeding ~200 lines that's hard to understand at a glance, or (4) something you want to test in isolation (see [Testing and Storybook](./testing-and-storybook.md)). Keep code inline when extraction would just move complexity without adding clarity.
+
+2. **What's the difference between premature and delayed abstraction?**
+   Premature abstraction creates flexible, configurable components before you understand the actual variations. You end up with wrong abstractions that need constant modification. Delayed abstraction copies code until patterns emerge naturally. Both fail—premature creates wrong interfaces (see [Component API Design](./component-api-design.md)), delayed creates inconsistency.
+
+3. **Should every UI element be a component?**
+   No. A `<div className="flex gap-4">` doesn't need to be a `<FlexRow>` component. Components earn their existence through reuse, encapsulation, or naming value. A button is a component because it has behavior, variants, and accessibility requirements (see [Accessibility](./accessibility.md)). A flex container is just styling.
+
+4. **When should a component become "shared" vs. stay local to a feature?**
+   Keep components local (in the feature folder) until a second, unrelated feature needs them. Promote to shared only when: (1) 3+ usages exist, (2) usages span different features, (3) the API is stable. See [Codebase Conventions](./codebase-conventions.md) for file organization patterns.
+
+5. **What are the signals that I've drawn component boundaries wrong?**
+   Signals of wrong boundaries: (1) passing many props through layers (prop drilling), (2) frequent changes to the component when unrelated features change, (3) needing to expose internal implementation details, (4) the component name doesn't describe what it does. See [Component API Design](./component-api-design.md) for proper boundary design.
+
+6. **Is the container/presentational pattern still relevant?**
+   Yes, but as a workflow, not an architecture rule. Start by building the presentational component with mock data (focus on visuals). Add a container when data-fetching logic becomes non-trivial. See [Data Contracts](./data-contracts.md) for how to separate data concerns from presentation.
+
+7. **How do I decide between one configurable component vs. multiple specific components?**
+   Use the "boolean explosion" test: if you'd need 3+ boolean props to configure variations, you probably want multiple specific components (or a variant prop). `<Card>`, `<Card.Compact>`, `<Card.Featured>` is often clearer than `<Card isCompact isFeatured showImage />`. See [Component API Design](./component-api-design.md) for variant patterns.
+
+8. **What's the lifecycle of a component—when should components be deleted?**
+   Components should be deleted when: (1) they're used in only one place after refactoring, (2) they've been replaced by a better abstraction, (3) they no longer fit the design system. See [Design System Consumption](./design-system-consumption.md) for when components should align with design system primitives.
+
+9. **How do I handle components that seem to need access to their parent's state?**
+   This often indicates the boundary is in the wrong place. Options: (1) lift state up and pass it down as props, (2) use context for truly global state, (3) reconsider whether the component should own the interaction. For complex state patterns, see [State Management at Scale](../ui-systems-performance/state-management-at-scale.md).
+
+10. **Should components control their own layout (margin, positioning)?**
+    No. Components should control their internal layout but not their external position. The parent decides where the component goes (margin, grid placement). This makes components reusable across different layout contexts. See [Responsive Behavior](./responsive-behavior.md) for layout adaptation patterns.
+
+---
+
+*Build components that evolve with your codebase. Start building with [Bitloops](https://bitloops.com).*
diff --git a/documentation/docs/frontend-copilot/best-practices/data-contracts.md b/documentation/docs/frontend-copilot/best-practices/data-contracts.md
new file mode 100644
index 00000000..29503d6a
--- /dev/null
+++ b/documentation/docs/frontend-copilot/best-practices/data-contracts.md
@@ -0,0 +1,533 @@
+---
+sidebar_position: 4
+sidebar_label: Data Contracts
+title: "Frontend Data Contracts: API Boundaries, Mapping Layers, and Schema Ownership"
+description: "Who owns the data shape—API, CMS, or component? Learn mapping layers, validation boundaries, and contracts that prevent backend changes from breaking your UI."
+keywords:
+  [
+    frontend data contracts,
+    api response mapping react,
+    cms frontend integration,
+    typescript api validation,
+    zod schema validation,
+    backend frontend contract,
+    data transformation layer,
+    api schema ownership,
+  ]
+---
+
+# Where data shape is decided
+
+Components consume data. But who decides the shape of that data? The CMS? The backend API? The frontend? When this question goes unanswered, you get fragile components that break when data changes, duplicated transformation logic, and arguments about where "the data should be fixed."
+
+This document covers data ownership, the contracts between systems, and how to design boundaries that make change manageable.
+
+## The Data Ownership Question
+
+Every piece of data displayed in your UI has an origin. Understanding who owns the shape of that data—and where transformations happen—prevents architectural confusion.
+
+### Three sources, three owners
+
+**1. CMS-owned data**
+
+Content managed by editors in a CMS (Contentful, Sanity, Strapi, etc.). The CMS schema defines the shape.
+
+- Blog posts, product descriptions, marketing copy
+- Images with metadata
+- Structured content blocks
+
+**2. Backend-owned data**
+
+Data from your application's API. The backend team defines the shape.
+
+- User accounts, orders, transactions
+- Real-time data, computed values
+- Aggregated or processed data
+
+**3. Frontend-owned data**
+
+State that exists only in the browser. The frontend defines the shape.
+
+- UI state (modals open, tabs selected)
+- Form input before submission
+- Derived or computed display values
+
+### The ownership principle
+
+**The source of truth owns the schema. Consumers adapt.**
+
+If the CMS defines a `BlogPost` with `title`, `body`, and `publishedAt`, your frontend doesn't get to demand a `formattedDate` field. The CMS owns the shape. Your frontend transforms `publishedAt` into a display format.
+
+This sounds obvious, but violations are common:
+
+- Backends that format data "for the frontend" (mixing concerns)
+- Frontends that assume CMS fields will be renamed (wishful thinking)
+- Components that accept raw API shapes and pray they don't change
+
+## Contracts Between Systems
+
+A data contract is an explicit agreement about shape. It can be:
+
+- A TypeScript type shared between systems
+- An API specification (OpenAPI, GraphQL schema)
+- A CMS schema definition
+- Documentation that both sides commit to
+
+### Why explicit contracts matter
+
+Without contracts:
+
+```tsx
+// Frontend assumes this shape
+const UserCard = ({ user }) => (
+  <div>
+    <img src={user.avatar} alt={user.name} />
+    <h3>{user.name}</h3>
+    <p>{user.email}</p>
+  </div>
+);
+
+// Backend changes shape without notice
+// user.avatar → user.profileImage
+// user.name → user.fullName
+// Frontend breaks in production
+```
+
+With contracts:
+
+```tsx
+// Shared contract (or generated from API spec)
+interface User {
+  id: string;
+  fullName: string;
+  email: string;
+  profileImage: string | null;
+}
+
+// Frontend uses the contract
+const UserCard = ({ user }: { user: User }) => (
+  <div>
+    <img src={user.profileImage ?? '/default-avatar.png'} alt={user.fullName} />
+    <h3>{user.fullName}</h3>
+    <p>{user.email}</p>
+  </div>
+);
+
+// Backend changes break at compile time, not production
+```
+
+### Contract boundaries
+
+Define contracts at system boundaries:
+
+```
+┌─────────────┐     contract     ┌─────────────┐
+│     CMS     │ ───────────────► │   Frontend  │
+└─────────────┘                  └─────────────┘
+       │                               ▲
+       │ CMS types                     │ API types
+       ▼                               │
+┌─────────────┐     contract     ┌─────────────┐
+│   Backend   │ ───────────────► │   Frontend  │
+└─────────────┘                  └─────────────┘
+```
+
+Each arrow is a contract. Each contract has an owner (the source) and consumers (the destinations).
+
+## The Mapping Layer
+
+Raw API data rarely matches what components need. A mapping layer transforms source shapes into component-friendly shapes.
+
+### Why mapping matters
+
+**Raw API shape:**
+
+```tsx
+interface APIProduct {
+  product_id: string;
+  product_name: string;
+  price_cents: number;
+  currency_code: string;
+  main_image_url: string;
+  is_available: boolean;
+  stock_quantity: number;
+}
+```
+
+**Component-friendly shape:**
+
+```tsx
+interface Product {
+  id: string;
+  name: string;
+  formattedPrice: string;  // "$19.99"
+  imageUrl: string;
+  availability: 'in-stock' | 'low-stock' | 'out-of-stock';
+}
+```
+
+The component doesn't need to know about `price_cents` vs `currency_code`, or calculate stock thresholds. The mapping layer handles that once.
+
+### Where mapping lives
+
+**Option 1: API layer (recommended for apps)**
+
+```tsx
+// api/products.ts
+import { APIProduct } from './types';
+import { Product } from '@/types';
+
+export async function getProduct(id: string): Promise<Product> {
+  const response = await fetch(`/api/products/${id}`);
+  const raw: APIProduct = await response.json();
+  return mapProduct(raw);
+}
+
+function mapProduct(raw: APIProduct): Product {
+  return {
+    id: raw.product_id,
+    name: raw.product_name,
+    formattedPrice: formatPrice(raw.price_cents, raw.currency_code),
+    imageUrl: raw.main_image_url,
+    availability: getAvailability(raw.stock_quantity),
+  };
+}
+```
+
+Components never see `APIProduct`. They work with `Product`.
+
+**Option 2: Data fetching hooks**
+
+```tsx
+// hooks/useProduct.ts
+export function useProduct(id: string) {
+  return useQuery(['product', id], async () => {
+    const raw = await fetchProduct(id);
+    return mapProduct(raw);
+  });
+}
+```
+
+**Option 3: Dedicated mapping module**
+
+```tsx
+// mappers/product.ts
+export function mapProduct(raw: APIProduct): Product { ... }
+export function mapProducts(raw: APIProduct[]): Product[] {
+  return raw.map(mapProduct);
+}
+```
+
+### The mapping principle
+
+**Transform once, at the boundary. Use the transformed shape everywhere.**
+
+Don't let raw API shapes leak into components. Don't transform in multiple places.
+
+## CMS Content Modeling
+
+CMS data has unique characteristics: it's often edited by non-developers, may be partially filled, and changes frequently. Defensive modeling is essential.
+
+### Structured vs. freeform content
+
+**Structured content** has a defined schema:
+
+```tsx
+interface BlogPost {
+  title: string;        // Required
+  slug: string;         // Required
+  body: RichText;       // Required
+  author: Author;       // Required reference
+  publishedAt: string;  // Required date
+  tags: string[];       // Optional array
+}
+```
+
+**Freeform content** is loosely defined:
+
+```tsx
+interface PageSection {
+  type: string;
+  content: Record<string, unknown>;
+}
+```
+
+### When to use each
+
+| Use structured when... | Use freeform when... |
+|------------------------|----------------------|
+| Shape is predictable | Content editors need flexibility |
+| Validation is important | Schema evolves rapidly |
+| Type safety matters | You're building a page builder |
+| Content is authored by developers | Content is authored by marketers |
+
+### Defensive CMS consumption
+
+CMS data is often partially filled or unexpectedly shaped. Defend against it:
+
+```tsx
+// Dangerous: assumes all fields exist
+const BlogCard = ({ post }) => (
+  <div>
+    <img src={post.coverImage.url} alt={post.coverImage.alt} />
+    <h3>{post.title}</h3>
+    <p>{post.excerpt}</p>
+    <span>{post.author.name}</span>
+  </div>
+);
+
+// Defensive: handles missing data
+const BlogCard = ({ post }: { post: CMSBlogPost }) => {
+  const coverImage = post.coverImage ?? { url: '/placeholder.jpg', alt: '' };
+  const authorName = post.author?.name ?? 'Unknown Author';
+
+  return (
+    <div>
+      <img src={coverImage.url} alt={coverImage.alt} />
+      <h3>{post.title}</h3>
+      {post.excerpt && <p>{post.excerpt}</p>}
+      <span>{authorName}</span>
+    </div>
+  );
+};
+```
+
+### CMS types: partial by default
+
+Model CMS types to reflect reality:
+
+```tsx
+// Reflects actual CMS behavior
+interface CMSBlogPost {
+  title: string;           // Required fields are actually required
+  slug: string;
+  body: RichText;
+  coverImage?: {           // Optional: editors might not add it
+    url: string;
+    alt?: string;          // Alt text often forgotten
+  };
+  author?: {               // Reference might be broken
+    name: string;
+    avatar?: string;
+  };
+  publishedAt?: string;    // Draft posts won't have this
+  tags?: string[];         // Optional array
+}
+```
+
+## Validation Strategies
+
+Data should be validated at boundaries. But which boundaries, and how?
+
+### Build-time vs. runtime validation
+
+**Build-time validation (TypeScript):**
+
+- Catches shape mismatches during development
+- Zero runtime cost
+- Only works for statically known shapes
+
+**Runtime validation (Zod, io-ts, yup):**
+
+- Catches actual data errors
+- Works with dynamic data
+- Has runtime cost
+- Provides detailed error messages
+
+### When to validate at runtime
+
+Runtime validation is worth the cost when:
+
+1. **Data comes from untrusted sources** — User input, external APIs, webhooks
+2. **Data shape is critical** — Payment data, authentication, form submissions
+3. **Debugging matters** — Clear validation errors beat "cannot read property of undefined"
+4. **CMS data is unpredictable** — Editors make mistakes
+
+```tsx
+// Runtime validation for CMS data
+import { z } from 'zod';
+
+const BlogPostSchema = z.object({
+  title: z.string().min(1),
+  slug: z.string().min(1),
+  body: z.string(),
+  coverImage: z.object({
+    url: z.string().url(),
+    alt: z.string().optional(),
+  }).optional(),
+  publishedAt: z.string().datetime().optional(),
+});
+
+type BlogPost = z.infer<typeof BlogPostSchema>;
+
+async function getBlogPost(slug: string): Promise<BlogPost | null> {
+  const raw = await cmsClient.getPost(slug);
+
+  const result = BlogPostSchema.safeParse(raw);
+  if (!result.success) {
+    console.error('Invalid blog post data:', result.error);
+    return null;
+  }
+
+  return result.data;
+}
+```
+
+### Where validation lives
+
+```
+┌──────────────┐
+│   External   │
+│   Source     │
+└──────┬───────┘
+       │ raw data
+       ▼
+┌──────────────┐
+│  Validation  │  ← Validate at the boundary
+│    Layer     │
+└──────┬───────┘
+       │ validated & typed data
+       ▼
+┌──────────────┐
+│  Application │  ← Trust the data from here on
+│    Code      │
+└──────────────┘
+```
+
+Validate once at entry. Trust within the boundary.
+
+## Component Data Expectations
+
+Components should declare exactly what data they expect—no more, no less.
+
+### Props as explicit contracts
+
+```tsx
+// Clear data contract
+interface ProductCardProps {
+  product: {
+    id: string;
+    name: string;
+    price: string;  // Already formatted
+    imageUrl: string;
+    inStock: boolean;
+  };
+}
+
+const ProductCard = ({ product }: ProductCardProps) => (
+  // Component can trust these fields exist and are typed correctly
+);
+```
+
+### Rejecting bad data
+
+Components should fail clearly when data is wrong:
+
+```tsx
+const ProductCard = ({ product }: ProductCardProps) => {
+  // Development-time assertion
+  if (process.env.NODE_ENV === 'development') {
+    if (!product.id || !product.name) {
+      console.error('ProductCard: missing required product fields', product);
+    }
+  }
+
+  return (
+    // ...
+  );
+};
+```
+
+### The "transform then consume" pattern
+
+Don't let components do data transformation:
+
+```tsx
+// Bad: component does transformation
+const ProductCard = ({ apiProduct }) => {
+  const formattedPrice = `$${(apiProduct.price_cents / 100).toFixed(2)}`;
+  const imageUrl = apiProduct.images?.[0]?.url ?? '/placeholder.jpg';
+  // ...
+};
+
+// Good: component receives transformed data
+const ProductCard = ({ product }) => {
+  // product.formattedPrice and product.imageUrl already exist
+  // ...
+};
+```
+
+Why? Because:
+- Transformation logic is duplicated if multiple components need the same data
+- Components become coupled to API shape
+- Testing requires mocking complex API shapes instead of simple display shapes
+
+## How this connects to Bitloops
+
+One of the most common sources of frontend fragility is components that are tightly coupled to raw API or CMS shapes. [Bitloops](https://bitloops.com) helps enforce clean data boundaries by generating components that expect already-transformed, display-ready props — not raw backend payloads. When turning designs into code, Bitloops produces typed component interfaces that match what the UI actually needs, making it natural to introduce a mapping layer between the data source and the component. The "transform then consume" pattern becomes the default workflow, not an afterthought.
+
+---
+
+## Summary
+
+Data contracts define boundaries. The principles:
+
+| Principle | Application |
+|---|---|
+| Source owns the schema | Treat the origin as authoritative: CMS fields follow the CMS schema, API responses follow the backend contract, and client-only state follows frontend rules. Don’t “negotiate” shapes in components—adapt at the boundary. |
+| Contracts are explicit | Define the contract where systems meet (CMS → frontend, API → frontend). Use generated types (OpenAPI/GraphQL), shared TypeScript models, or documented schemas so shape changes fail at build time, not in production. |
+| Transform at boundaries | Introduce a mapping layer (API module, data hooks, or dedicated mappers) that converts raw shapes into component-friendly models (e.g., `price_cents` → `formattedPrice`). Components should never see raw `APIProduct` or raw CMS records. |
+| CMS data is partial by default | Model CMS fields with real-world optionality (missing images, empty alt text, broken references, drafts without dates). Provide sensible fallbacks and conditional rendering so editorial mistakes don’t become UI crashes. |
+| Validate external data | Validate at ingress when inputs are untrusted or unpredictable (CMS payloads, external APIs, user input). Use runtime schemas (e.g., Zod) at the boundary so everything inside the app can assume data is well-formed. |
+| Components declare expectations | Keep component props tight and explicit: accept only what the UI needs (already formatted, already derived). If a component needs `formattedPrice`, make it a prop—don’t compute it inside the component. |
+| Prevent raw-shape leakage | Enforce “transform then consume” as a rule: no ad-hoc formatting in views, no `apiProduct.*` access in UI components, no duplicated transformations across multiple components. This reduces breakage and makes testing fixtures simpler. |
+
+Clear data boundaries prevent the ripple effects of change. When the API changes, you update one mapping function—not fifty components.
+
+---
+
+## Further reading
+
+- [Zod Documentation](https://zod.dev/) — The TypeScript-first schema validation library referenced throughout this document; covers parsing, inference, transforms, and error handling for runtime data contracts.
+- [OpenAPI Specification](https://spec.openapis.org/oas/latest.html) — The standard for defining HTTP API contracts; combined with code generators (e.g., `openapi-typescript`), it automates the typed boundary between backend and frontend.
+- [GraphQL Code Generator](https://the-guild.dev/graphql/codegen) — Generates TypeScript types and hooks directly from your GraphQL schema, eliminating manual type definitions and ensuring frontend code stays in sync with the API contract.
+- [Data Fetching Patterns in Single-Page Applications — Juntao Qiu (martinfowler.com)](https://martinfowler.com/articles/data-fetch-spa.html) — Explores how to structure data-fetching and transformation layers in SPAs, including the "transform then consume" pattern central to this document.
+- [Parse, Don't Validate — Alexis King](https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/) — The foundational article on why parsing data at the boundary (turning unstructured input into typed values) is safer than scattering validation checks throughout your code.
+
+---
+
+## Frequently Asked Questions (FAQs)
+
+1. **Should components consume API responses directly?**
+   No. Add a mapping layer that transforms API responses into the shape components expect. This isolates components from backend changes: when the API returns `price_cents`, map it to `formattedPrice: "$29.99"` before it reaches components. See [Component API Design](./component-api-design.md) for how component props should be designed around this mapped data.
+
+2. **Where should data validation happen—frontend or backend?**
+   Both, for different reasons. Backend validates for security and data integrity (never trust client input—see [Security Boundaries](../ui-systems-performance/security-boundaries.md)). Frontend validates for UX (immediate feedback) and to fail fast on unexpected response shapes. Use tools like Zod for runtime validation at API boundaries.
+
+3. **How do I handle API schema changes without breaking the UI?**
+   The mapping layer absorbs changes. When the API renames `user_name` to `username`, update the mapper once—not every component that displays names. See [Codebase Conventions](./codebase-conventions.md) for organizing mapping layers alongside features.
+
+4. **What's the difference between a data contract and a TypeScript type?**
+   TypeScript types are compile-time checks—they verify your code is internally consistent. Data contracts are runtime agreements about what shape data actually arrives in. Use both: types for development, runtime validation for production. For related type patterns, see [Component API Design](./component-api-design.md).
+
+5. **Who owns the contract—frontend or backend?**
+   Ideally, contracts are shared artifacts (OpenAPI specs, GraphQL schemas) that both sides agree to. In practice, the backend usually defines the API and frontend adapts. See [Network Protocols](../ui-systems-performance/network-protocols.md) for HTTP contract patterns.
+
+6. **How do I handle optional or missing fields from the API?**
+   Define defaults in the mapping layer, not scattered across components. If `user.avatarUrl` might be null, the mapper provides a default: `avatarUrl: user.avatarUrl ?? DEFAULT_AVATAR`. Components can assume the shape is complete. See [Component API Design](./component-api-design.md) for handling optional props.
+
+7. **What's the right granularity for data contracts?**
+   Match contracts to domain concepts, not API endpoints. A "Product" contract includes everything components need to render a product, regardless of whether it comes from one endpoint or three. For caching these aggregated shapes, see [Caching Strategies](../ui-systems-performance/caching-strategies.md).
+
+8. **How do I version data contracts?**
+   When contracts must change, support both versions temporarily: the mapping layer accepts v1 or v2 from the API and normalizes to the component's expected shape. Deprecate old versions with deadlines. For similar versioning patterns with component APIs, see [Component API Design](./component-api-design.md).
+
+9. **Should I use GraphQL to avoid mapping layers?**
+   GraphQL reduces the need for mapping by letting frontend request exact shapes. But you still need validation and transformation. For caching GraphQL responses, see [Caching Strategies](../ui-systems-performance/caching-strategies.md). GraphQL is better DX, not a replacement for data boundaries.
+
+10. **How do I test data contracts?**
+    Test the mapping layer with fixtures: given this API response, verify the output shape. Test that validation rejects malformed responses. See [Testing and Storybook](./testing-and-storybook.md) for how story fixtures should reflect these mapped data shapes.
+
+---
+
+*Build frontends with clear data boundaries. Start building with [Bitloops](https://bitloops.com).*
\ No newline at end of file
diff --git a/documentation/docs/frontend-copilot/best-practices/design-system-consumption.md b/documentation/docs/frontend-copilot/best-practices/design-system-consumption.md
new file mode 100644
index 00000000..87b81024
--- /dev/null
+++ b/documentation/docs/frontend-copilot/best-practices/design-system-consumption.md
@@ -0,0 +1,488 @@
+---
+sidebar_position: 5
+sidebar_label: Design System Consumption
+title: "Using Design Systems Correctly: Tokens, Constraints, and Preventing Drift"
+description: "Design systems fail when developers bypass them. Learn token-only styling, the forbidden list, escape hatch friction, and how to prevent design drift at scale."
+keywords:
+  [
+    design system consumption rules,
+    design tokens best practices,
+    preventing design system drift,
+    tailwind design system,
+    css custom properties tokens,
+    design system constraints,
+    token only styling,
+    design system governance,
+  ]
+---
+
+# Design system usage and constraints
+
+Design systems aren't just component libraries. They're constraint systems—carefully curated sets of tokens, patterns, and rules that enable consistency at scale. But the value of a design system depends entirely on how it's consumed. One developer bypassing tokens "just this once" can undermine months of design work.
+
+This document covers the consumption side: the rules for using design systems correctly, what consumers are allowed to do, and how constraints enable rather than limit.
+
+## The Consumption Contract
+
+When you consume a design system, you're agreeing to a contract:
+
+- **Use the system's building blocks** — Tokens, components, and patterns as provided
+- **Stay within documented boundaries** — Customization only where explicitly allowed
+- **Report gaps rather than bypass** — Missing capabilities are system issues, not workaround opportunities
+
+### Why constraints matter
+
+Without consumption discipline:
+
+```tsx
+// Developer A uses the system
+<Button variant="primary" size="md">Submit</Button>
+
+// Developer B "just needs a different blue"
+<button className="bg-[#1a73e8] hover:bg-[#1557b0] px-4 py-2 text-white rounded">
+  Submit
+</button>
+
+// Developer C "needs slightly more padding"
+<Button variant="primary" size="md" className="!px-6">Submit</Button>
+```
+
+Result: Three buttons that look similar but behave differently. Brand inconsistency. Maintenance burden. Accessibility gaps.
+
+With consumption discipline:
+
+```tsx
+// Everyone uses the same primitive
+<Button variant="primary" size="md">Submit</Button>
+<Button variant="primary" size="lg">Submit</Button>  // When more padding is needed
+```
+
+The design system owns the definition of "primary button." Changes update everywhere. Consistency is automatic.
+
+## Token-Only Styling
+
+The foundational rule of design system consumption is **token-only styling**. Never use arbitrary values when tokens exist.
+
+### What tokens provide
+
+Tokens are named, semantic values:
+
+```css
+/* Spacing tokens */
+--spacing-1: 0.25rem;   /* 4px */
+--spacing-2: 0.5rem;    /* 8px */
+--spacing-4: 1rem;      /* 16px */
+--spacing-8: 2rem;      /* 32px */
+
+/* Color tokens */
+--color-primary: #2563eb;
+--color-primary-hover: #1d4ed8;
+--color-text: #1f2937;
+--color-text-muted: #6b7280;
+
+/* Typography tokens */
+--font-size-sm: 0.875rem;
+--font-size-base: 1rem;
+--font-size-lg: 1.125rem;
+```
+
+In Tailwind, these map to utility classes:
+
+```tsx
+// Token-based (correct)
+<div className="p-4 text-gray-700 text-base">
+
+// Arbitrary values (avoid)
+<div className="p-[18px] text-[#374151] text-[15px]">
+```
+
+### The arbitrary value problem
+
+Arbitrary values bypass the system:
+
+```tsx
+// Looks right now, breaks later
+<div className="bg-[#2563eb]">  // Primary blue, hardcoded
+
+// When brand colors change, this doesn't update
+// When dark mode is added, this doesn't adapt
+// When the design system is audited, this is invisible
+```
+
+Token-based styling:
+
+```tsx
+// Uses the token
+<div className="bg-primary">  // References --color-primary
+
+// Brand changes update everywhere
+// Dark mode can redefine --color-primary
+// Auditing tools can track token usage
+```
+
+### When arbitrary values are acceptable
+
+Sometimes tokens don't exist for your use case:
+
+1. **One-off illustrations or decorative elements** — A marketing hero image might need specific positioning
+2. **Third-party integration constraints** — External widgets might require specific dimensions
+3. **Rapid prototyping** — Before tokens are defined, you might spike with arbitrary values
+
+Even then, document why:
+
+```tsx
+// Arbitrary value: aligning with third-party chart library requirement
+<div className="h-[320px]">
+  <ThirdPartyChart />
+</div>
+```
+
+## Fallback Patterns
+
+Tokens won't cover every case. When they don't, you need a fallback strategy.
+
+### The fallback hierarchy
+
+1. **Check if a token exists** — Maybe `spacing-5` exists and you missed it
+2. **Use the nearest token** — If you need 18px and tokens are 16px and 20px, choose one
+3. **Request a new token** — If the use case is legitimate and recurring, the system should add it
+4. **Document the exception** — If you must use an arbitrary value, explain why
+
+### Requesting tokens vs. bypassing
+
+**Bypassing (don't do this):**
+
+```tsx
+// "I need 18px padding, tokens only go 16/20, I'll just..."
+<div className="p-[18px]">
+```
+
+**Requesting (do this):**
+
+```tsx
+// Use nearest token for now
+<div className="p-4">  // 16px, close enough
+
+// Open an issue: "Need spacing-4.5 (18px) for card padding"
+// Design team evaluates and either:
+// - Adds the token if it's a valid need
+// - Explains why 16px or 20px should be used
+```
+
+The conversation matters. Bypasses are invisible. Requests create shared understanding.
+
+## Theme Constraints
+
+Design systems often support theming—light/dark mode, brand variants, or white-labeling. Consuming themes correctly requires understanding what's customizable.
+
+### What themes control
+
+Themes typically redefine tokens, not structure:
+
+```css
+/* Light theme */
+:root {
+  --color-background: #ffffff;
+  --color-text: #1f2937;
+  --color-primary: #2563eb;
+}
+
+/* Dark theme */
+.dark {
+  --color-background: #111827;
+  --color-text: #f9fafb;
+  --color-primary: #3b82f6;
+}
+```
+
+Components using tokens adapt automatically:
+
+```tsx
+// This component works in any theme
+<div className="bg-background text-foreground">
+  <Button variant="primary">Click me</Button>
+</div>
+```
+
+### Theme-safe patterns
+
+**Do:**
+- Use semantic color tokens (`bg-primary`, `text-muted`)
+- Let the theme define what "primary" means
+- Test components in all supported themes
+
+**Don't:**
+- Hardcode colors (`bg-[#ffffff]`)
+- Mix theme tokens with arbitrary colors
+- Assume light mode is the default
+
+### Consumer customization boundaries
+
+Themes define what consumers can change:
+
+| Layer | Who Controls | Examples |
+|-------|--------------|----------|
+| Tokens | Design system | Colors, spacing, typography |
+| Component structure | Design system | Button has icon slot, label, loading state |
+| Component variants | Design system | `variant="primary"`, `size="lg"` |
+| Props | Consumer | Labels, callbacks, content |
+| Composition | Consumer | Which components, in what order |
+
+Consumers control props and composition. Everything else belongs to the system.
+
+## The Forbidden List
+
+Every design system has implicit rules about what consumers shouldn't do. Make them explicit.
+
+### Common violations
+
+**1. Overriding styles with `!important` or specificity hacks**
+
+```tsx
+// Violation: forcing different padding
+<Button className="!p-8">Submit</Button>
+
+// Violation: overriding with inline styles
+<Button style={{ padding: '2rem' }}>Submit</Button>
+```
+
+Why it's forbidden: Breaks consistency, creates maintenance burden, overrides tested behavior.
+
+**2. Accessing internal implementation**
+
+```tsx
+// Violation: styling internal elements
+<Button className="[&>svg]:w-8 [&>svg]:h-8">Submit</Button>
+
+// Violation: depending on DOM structure
+document.querySelector('.button-internal-icon').style.fill = 'red';
+```
+
+Why it's forbidden: Internal structure can change without notice.
+
+**3. Mixing design system components with custom styling**
+
+```tsx
+// Violation: half-system, half-custom
+<div className="flex gap-4">
+  <Button variant="primary">System button</Button>
+  <button className="bg-blue-500 px-4 py-2 rounded">Custom button</button>
+</div>
+```
+
+Why it's forbidden: Inconsistent appearance and behavior.
+
+**4. Reimplementing system components**
+
+```tsx
+// Violation: "Button was too limiting"
+const MyButton = ({ children }) => (
+  <button className="bg-primary text-white px-4 py-2 rounded">
+    {children}
+  </button>
+);
+```
+
+Why it's forbidden: Misses accessibility, states, and future updates.
+
+### Making violations visible
+
+Violations should be detectable:
+
+- **Linting rules** flag arbitrary values or `!important`
+- **Code review checklists** include design system compliance
+- **Visual regression tests** catch unintended styling
+- **Token usage reports** identify hardcoded values
+
+## Preventing Design Drift
+
+Design drift happens gradually. One exception becomes two, becomes twenty, becomes "we don't really have a design system anymore."
+
+### Drift prevention strategies
+
+**1. Clear documentation**
+
+Document what's allowed:
+
+```md
+## Button Usage
+
+### Allowed
+- All documented variants: primary, secondary, ghost
+- All documented sizes: sm, md, lg
+- All documented props: disabled, loading, icon
+
+### Not Allowed
+- Custom colors via className
+- Inline style overrides
+- Direct DOM manipulation
+```
+
+**2. Constrained APIs**
+
+Components should make misuse difficult:
+
+```tsx
+// Constrained: only accepts known variants
+type ButtonVariant = 'primary' | 'secondary' | 'ghost';
+
+interface ButtonProps {
+  variant: ButtonVariant;
+  // No className prop exposed
+}
+
+// vs. permissive: accepts anything
+interface ButtonProps {
+  variant?: string;
+  className?: string;  // Escape hatch invites abuse
+}
+```
+
+**3. Escape hatches with friction**
+
+If escape hatches are necessary, add friction:
+
+```tsx
+// Requires explicit acknowledgment
+<Button
+  variant="primary"
+  __unsafeClassName="p-8"  // Clearly marked as unsafe
+>
+  Submit
+</Button>
+```
+
+**4. Regular audits**
+
+Periodically audit the codebase:
+
+- Search for arbitrary values in Tailwind classes
+- Count `!important` usages
+- Compare component usage to documentation
+- Review exceptions and whether they should become tokens
+
+## Consumption Patterns
+
+### Pattern 1: Composition over customization
+
+Instead of customizing components, compose them:
+
+```tsx
+// Don't: customize beyond the API
+<Card className="!p-8 !rounded-xl">
+  <CardContent>...</CardContent>
+</Card>
+
+// Do: compose primitives
+<div className="p-8 rounded-xl bg-surface shadow">
+  <Card>
+    <CardContent>...</CardContent>
+  </Card>
+</div>
+```
+
+### Pattern 2: Slots for flexibility
+
+Use component slots instead of style overrides:
+
+```tsx
+// Don't: try to style the icon
+<Button className="[&>svg]:w-8">
+  <Icon /> Submit
+</Button>
+
+// Do: use the icon prop/slot
+<Button icon={<Icon size="lg" />}>Submit</Button>
+```
+
+### Pattern 3: Wrapper components for recurring patterns
+
+When you need consistent customization, create a wrapper:
+
+```tsx
+// Recurring pattern: icon buttons with tooltips
+const IconButton = ({ icon, tooltip, ...props }) => (
+  <Tooltip content={tooltip}>
+    <Button variant="ghost" size="sm" {...props}>
+      {icon}
+    </Button>
+  </Tooltip>
+);
+
+// Usage: consistent pattern
+<IconButton icon={<TrashIcon />} tooltip="Delete" onClick={handleDelete} />
+```
+
+The wrapper uses the system correctly. Consumers use the wrapper.
+
+## How this connects to Bitloops
+
+Design system drift happens when developers bypass tokens and components under time pressure — hardcoding colors, overriding spacing, adding `!important` to make something fit. [Bitloops](https://bitloops.com) reduces this pressure by generating code that already uses your design system's tokens and components. When converting designs, it maps colors to token variables, spacing to scale values, and typography to system primitives, so the output is system-compliant from the start. The discipline described in this document becomes easier to maintain when the starting code already follows the rules.
+
+---
+
+## Summary
+
+Design system consumption is about discipline. The principles:
+
+| Principle | Application |
+|---|---|
+| Treat consumption as a contract | Use design-system tokens and components as the default. Stay within documented variants/slots. When something is missing, raise a request instead of bypassing with custom CSS. |
+| Token-only styling | Prefer token-backed utilities/classes (e.g., `bg-primary`, `text-foreground`, `p-4`) so brand updates, dark mode, and audits “just work.” Avoid hardcoded hex values and arbitrary spacing/font sizes that silently fork the system. |
+| Minimize escape hatches | Don’t override system components with `!important`, inline styles, or deep selectors that target internal DOM. If an escape hatch must exist, make it explicit and rare (e.g., `__unsafeClassName`) and require justification. |
+| Use the fallback hierarchy | If a token doesn’t fit: (1) confirm it doesn’t exist, (2) choose the nearest token, (3) request a new token/variant if the need is recurring, (4) document a temporary exception only when unavoidable (e.g., third-party constraints). |
+| Keep theming “token-first” | Themes should redefine tokens, not component structure. Use semantic tokens (`bg-background`, `text-muted`, `border-subtle`) so components adapt automatically across light/dark/brand variants without per-consumer tweaks. |
+| Compose over customize | When you need a different layout, compose primitives around system components rather than restyling them. Use spacing/layout primitives and wrappers instead of changing the internals of a `Button`, `Card`, etc. |
+| Prefer slots over styling internals | If you need flexibility, use supported slots/props (`icon`, `header`, `footer`) rather than styling internal children via selectors (`[&>svg]...`) or relying on DOM structure. Slots preserve upgrade safety. |
+| Create wrappers for recurring patterns | When the same “customization” repeats (e.g., `Button` + `Tooltip` + icon sizing), create a thin wrapper component that encodes the pattern using approved variants/tokens. Consumers use the wrapper, not ad-hoc overrides. |
+| Make drift detectable | Add guardrails: lint rules for arbitrary values/`!important`, code review checks for token usage, visual regression tests for component states, and periodic audits that surface exceptions before they become the norm. |
+
+A design system's value isn't in its components—it's in consistent consumption. One team following the rules creates coherent UI. One exception creates precedent for more.
+
+---
+
+## Further reading
+
+- [Design Tokens W3C Community Group](https://design-tokens.github.io/community-group/format/) — The emerging standard for defining design tokens in a platform-agnostic format; explains why tokens are the foundation of consistent consumption across tools and codebases.
+- [Atomic Design — Brad Frost](https://atomicdesign.bradfrost.com/) — The methodology behind layered design systems; explains how atoms, molecules, and organisms compose into consistent UIs, and why consumption discipline matters at every layer.
+- [Tailwind CSS Documentation — Theme Configuration](https://tailwindcss.com/docs/theme) — Practical reference for configuring design tokens (colors, spacing, typography) in Tailwind, directly relevant to enforcing token-only styling in utility-first codebases.
+- [The Component Gallery](https://component.gallery/) — A catalog of real-world design system components across organizations; useful for benchmarking your consumption patterns and seeing how others handle variants, slots, and composition.
+- [Maintaining Design Systems — Brad Frost](https://bradfrost.com/blog/post/maintaining-design-systems/) — Addresses the operational side—governance, contribution models, and how to prevent drift over time; complements this document's focus on consumption discipline.
+
+---
+
+## Frequently Asked Questions (FAQs)
+
+1. **When is it okay to use arbitrary values instead of design tokens?**
+   Almost never in production code. Acceptable exceptions: one-off decorative elements (marketing hero positioning), third-party integration constraints (external widget dimensions), or rapid prototyping before tokens exist. Always document why. If you need a value frequently, request a token. See [Responsive Behavior](./responsive-behavior.md) for when fluid values are appropriate.
+
+2. **How do I prevent developers from bypassing the design system?**
+   Multiple layers: (1) constrain component APIs—don't expose `className` (see [Component API Design](./component-api-design.md)), (2) add linting rules for arbitrary Tailwind values, (3) make escape hatches explicit (`__unsafeClassName`), (4) review PRs for token compliance, (5) audit quarterly for drift. See [Codebase Conventions](./codebase-conventions.md) for enforcement patterns.
+
+3. **What's the difference between extending and bypassing a design system?**
+   Extending adds new tokens, components, or variants through the system's governance process—it's intentional, documented, and reviewed. Bypassing hardcodes values outside the system—it's hidden, undocumented, and erodes consistency. See [Component Creation Workflows](./component-creation-workflows.md) for when to create new components vs. extend existing ones.
+
+4. **Should I use `!important` to override design system styles?**
+   No. If you need `!important`, you're fighting the system instead of using it. Either the system needs a new variant (see [Component API Design](./component-api-design.md)), or you're using the wrong component. File an issue requesting what you need rather than forcing overrides.
+
+5. **How do I handle cases where design tokens don't exist for my use case?**
+   Follow the fallback hierarchy: (1) verify the token doesn't exist, (2) use the nearest existing token, (3) request a new token if the need is recurring, (4) document the exception if you must use an arbitrary value temporarily. See [Codebase Conventions](./codebase-conventions.md) for documenting exceptions.
+
+6. **What's token-only styling and why does it matter?**
+   Token-only styling means using design system values (colors, spacing, typography) exclusively—never hardcoded hex values or pixel measurements. Tokens adapt to themes (dark mode) and can be audited. See [Responsive Behavior](./responsive-behavior.md) for how tokens work with responsive design.
+
+7. **How do themes interact with design system consumption?**
+   Themes redefine token values, not component structure. If you use `bg-primary`, the theme defines what "primary" means in each context. Semantic tokens (`bg-background`, `text-muted`) are theme-safe. For accessibility considerations in theming, see [Accessibility](./accessibility.md).
+
+8. **How do I create recurring patterns without violating the design system?**
+   Create wrapper components that compose system primitives correctly. If you often use `Button` + `Tooltip` + specific icon sizing, create an `IconButton` wrapper. See [Component Creation Workflows](./component-creation-workflows.md) for when to extract wrapper components.
+
+9. **What are the costs of design system drift?**
+   Drift compounds: inconsistent appearance, inconsistent behavior, theme failures, and accessibility gaps (see [Accessibility](./accessibility.md)). Custom components often miss accessibility features that system components provide. See [Testing and Storybook](./testing-and-storybook.md) for catching drift through visual regression testing.
+
+10. **How do I audit a codebase for design system compliance?**
+    Search for: arbitrary values in Tailwind (`text-[`, `bg-[`), `!important` usages, inline `style` props, components that duplicate system functionality. See [Codebase Conventions](./codebase-conventions.md) for establishing linting and review processes that catch drift early.
+
+---
+
+*Consume design systems consistently. Start building with [Bitloops](https://bitloops.com).*
\ No newline at end of file
diff --git a/documentation/docs/frontend-copilot/best-practices/introduction.md b/documentation/docs/frontend-copilot/best-practices/introduction.md
new file mode 100644
index 00000000..c7206e63
--- /dev/null
+++ b/documentation/docs/frontend-copilot/best-practices/introduction.md
@@ -0,0 +1,144 @@
+---
+sidebar_position: 1
+sidebar_label: Introduction
+title: "Frontend Component Best Practices: Production Patterns for React & Design Systems"
+description: "8-part guide to production-quality React components: API design, accessibility, testing contracts, and the patterns that scale across teams. Start here."
+keywords:
+  [
+    frontend best practices guide,
+    react component patterns,
+    component library best practices,
+    design system implementation,
+    production react components,
+    frontend architecture patterns,
+    component api design principles,
+    scalable frontend code
+  ]
+---
+
+# Production patterns for component systems
+
+Building components is straightforward. Building components that scale, compose, and survive contact with real data is not. This series covers the patterns and practices that separate prototype-quality code from production-quality systems.
+
+## Why Patterns Matter
+
+Every codebase accumulates decisions. Some decisions compound—they make future work easier. Others accrete—they make future work harder. The difference often isn't visible in a single component. It emerges across dozens of components, months of iteration, and teams of contributors.
+
+**The core insight:**
+
+> Good patterns aren't about individual components. They're about what happens when you have 200 components, 5 contributors, and 2 years of accumulated changes.
+
+A component with a messy API works fine in isolation. A codebase with 50 messy APIs becomes unmaintainable. A component without accessibility works for most users. A product without accessibility excludes millions. The practices in this series address scale—of components, contributors, and users.
+
+## What This Series Covers
+
+This 8-part series covers component-level decisions that compound into system-level quality. Each document tackles a dimension of component development:
+
+### Component Foundation
+
+**1. Component Creation Workflows**
+When should a component exist? How do you decide its boundaries? When does something become reusable versus staying local? This document covers the lifecycle decisions that determine component structure.
+
+**2. Component API Design**
+The props you expose are a contract. Semantic versus mechanical props. Stable versus extensible APIs. Boolean explosion versus structured alternatives. This document covers the public surface area that consumers depend on.
+
+### Data Layer
+
+**3. Data Contracts and Content Boundaries**
+Components consume data, but who owns the shape? CMS schemas, typed versus freeform content, mapping layers, and validation. This document covers where data responsibility lives—and where it doesn't.
+
+**4. Design System Consumption**
+Design systems provide tokens, constraints, and patterns. But what are consumers allowed to do? What's forbidden? This document covers consumption discipline: the rules that enable scale without drift.
+
+### Adaptation Layer
+
+**5. Responsive Behavior**
+Responsiveness isn't about breakpoints—it's about strategy. Fluid versus stepped approaches. Typography, spacing, and images as a unified system. This document covers intentional adaptation, not ad-hoc fixes.
+
+**6. Accessibility**
+Accessible components aren't an afterthought—they're a byproduct of good structure. Semantic HTML, ARIA patterns, keyboard interaction, and focus management. This document covers accessibility as architecture.
+
+### Organization Layer
+
+**7. Codebase Conventions**
+File structure, naming patterns, composition rules. Conventions aren't preferences—they're constraints that prevent failure modes. This document ties everyday decisions to the problems they solve.
+
+**8. Testing and Storybook Contracts**
+Stories aren't just visual documentation—they're executable contracts. Deterministic fixtures, data mapping, and the separation between visual states and data variability. This document covers Storybook as a verification layer.
+
+## Who This Series Is For
+
+Frontend developers building component libraries, design system consumers, or product UIs at scale. You'll learn:
+
+- Decision frameworks for component boundaries and APIs
+- Patterns that prevent common failure modes
+- Conventions that scale across teams and time
+- Testing strategies that catch regressions early
+
+## Relationship to UI Systems & Performance
+
+This series complements the [UI Systems & Performance](../ui-systems-performance/introduction.md) series:
+
+| System Design & Architecture | Best Practices & Patterns |
+|------------------------------|---------------------------|
+| How systems work | How to build things well |
+| Infrastructure, protocols, failure modes | Components, APIs, conventions |
+| Understanding the "why" | Knowing the "what to do" |
+
+UI System Design explains *why* race conditions happen in async operations. Best Practices shows *how* to structure component APIs and tests to prevent them. Theory informs practice; practice validates theory.
+
+## How this connects to Bitloops
+
+The patterns in this series aren’t “nice to have” guidelines — they’re the practical constraints that make UI work scalable: stable component boundaries, predictable APIs, clear data contracts, disciplined design system usage, and testable states. [Bitloops](https://bitloops.com) is built to make those constraints easier to apply consistently. By turning designs into structured components (with tokens, primitives, and repeatable patterns), and by encouraging contract-like Storybook states instead of one-off demos, it helps teams keep implementation quality high as the codebase grows. Use the documents below as the decision framework; use Bitloops as the workflow that makes the framework repeatable across contributors and time.
+
+
+## Frequently Asked Questions (FAQs)
+
+1. **What's the difference between component patterns and design patterns?**
+   Component patterns address React-specific concerns like prop design, composition, and state boundaries. Design patterns are language-agnostic solutions to recurring problems (Observer, Factory, etc.). This series covers component patterns specifically—how to structure React components for production use. See [Component API Design](./component-api-design.md) for detailed prop patterns.
+
+2. **Should I read this series in order?**
+   Not necessarily. Start with [Component Creation Workflows](./component-creation-workflows.md) if you're building new components from scratch. Jump to [Component API Design](./component-api-design.md) if you're refactoring existing component interfaces. For testing strategy, see [Testing and Storybook](./testing-and-storybook.md).
+
+3. **Do these patterns apply to Vue, Svelte, or other frameworks?**
+   The underlying principles—prop contracts, data boundaries, accessibility structure, testing as verification—transfer to any component-based framework. The code examples use React syntax, but the mental models apply universally. See [Data Contracts](./data-contracts.md) for framework-agnostic boundary design.
+
+4. **How do Best Practices relate to the UI Systems Performance series?**
+   Best Practices covers *how to build things well* (components, APIs, conventions). [UI Systems Performance](../ui-systems-performance/introduction.md) covers *how systems work* (state replication, caching, failure modes). For state management patterns, see [State Management at Scale](../ui-systems-performance/state-management-at-scale.md). For caching, see [Caching Strategies](../ui-systems-performance/caching-strategies.md).
+
+5. **Are these patterns for design system authors or consumers?**
+   Both. Design system authors need these patterns to build stable, well-documented components. Consumers need them to use design systems correctly, extend them appropriately, and avoid drift. See [Design System Consumption](./design-system-consumption.md) for consumer-specific guidance.
+
+6. **How do I know if my codebase needs these patterns?**
+   Signs you need them: inconsistent component APIs across the codebase, difficulty onboarding new developers, frequent breaking changes, accessibility retrofitting, tests that break on visual changes. See [Codebase Conventions](./codebase-conventions.md) for structure patterns that prevent these issues.
+
+7. **What's the relationship between these patterns and team size?**
+   Patterns matter more as teams grow. A solo developer can hold conventions in their head. A team of 5+ needs explicit patterns to maintain consistency. See [Codebase Conventions](./codebase-conventions.md) for patterns that scale with team size.
+
+8. **Can I adopt these patterns incrementally?**
+   Yes. Start with the area causing the most pain. Accessibility problems? Start with [Accessibility](./accessibility.md). Inconsistent APIs? Start with [Component API Design](./component-api-design.md). Testing gaps? See [Testing and Storybook](./testing-and-storybook.md). Each document stands alone.
+
+9. **How do these patterns interact with AI code generation tools?**
+   AI tools benefit from clear patterns—they can generate more consistent code when patterns are explicit. Bitloops specifically encodes these patterns into its generation pipeline, producing components that follow best practices by default. See [Design System Consumption](./design-system-consumption.md) for token-based generation patterns.
+
+10. **What's the cost of NOT following these patterns?**
+    Technical debt accumulates: inconsistent APIs create cognitive load (see [Component API Design](./component-api-design.md)), poor accessibility excludes users (see [Accessibility](./accessibility.md)), missing tests allow regressions (see [Testing and Storybook](./testing-and-storybook.md)), and design drift erodes brand consistency (see [Design System Consumption](./design-system-consumption.md)).
+
+---
+
+## Document index
+
+| # | Document | Core questions this document answers |
+|---|---------|--------------------------------------|
+| 1 | **Component creation workflows** | When does something *deserve* to be a component? What signals distinguish a reusable component from a one-off layout? How do premature abstraction and delayed abstraction fail differently over time? How do design, data, and usage frequency influence component boundaries? |
+| 2 | **Component API design** | What should a component expose—and what should it hide? How do props encode intent versus mechanics? How do APIs evolve without breaking consumers? When do booleans, variants, slots, or composition patterns become liabilities? How do you design APIs that remain stable under new requirements? |
+| 3 | **Data contracts and content boundaries** | Who owns the shape of data a component consumes—the CMS, the API, or the component itself? Where should validation, defaults, and mapping live? How do you prevent components from becoming tightly coupled to volatile backend schemas? What breaks when content responsibility is unclear? |
+| 4 | **Design system consumption** | What are consumers allowed to customize—and what must remain constrained? How do tokens, primitives, and patterns prevent visual drift? When should teams extend the system versus compose within it? How do you avoid “design system erosion” as the codebase grows? |
+| 5 | **Responsive behavior** | How should components adapt across viewport sizes and contexts without fragmenting logic? When is responsiveness a layout concern versus a component concern? How do fluid and stepped strategies trade off predictability and flexibility? How do you prevent breakpoint-driven complexity from leaking everywhere? |
+| 6 | **Accessibility** | How does component structure enable or block accessibility by default? Which accessibility guarantees should be baked into components versus handled by consumers? How do keyboard interaction, focus management, and semantics scale across a component library? What accessibility failures only appear at scale? |
+| 7 | **Codebase conventions** | Which conventions meaningfully prevent failure modes versus merely enforce style? How do file structure, naming, and composition rules reduce cognitive load across teams? How do conventions encode architectural intent? What happens when conventions are missing or inconsistently applied? |
+| 8 | **Testing and Storybook contracts** | What does it mean for a component to be “verified”? How do stories act as executable contracts instead of visual demos? How do you separate visual states from data variability? How do deterministic fixtures prevent regressions during refactors and design changes? |
+
+---
+
+*Ready to dive in? Start with [Component Creation Workflows](./component-creation-workflows.md).*
\ No newline at end of file
diff --git a/documentation/docs/frontend-copilot/best-practices/responsive-behavior.md b/documentation/docs/frontend-copilot/best-practices/responsive-behavior.md
new file mode 100644
index 00000000..373d293e
--- /dev/null
+++ b/documentation/docs/frontend-copilot/best-practices/responsive-behavior.md
@@ -0,0 +1,476 @@
+---
+sidebar_position: 6
+sidebar_label: Responsive Behavior
+title: "Responsive Design Systems: Fluid Typography, Breakpoint Strategy, and Adaptive Images"
+description: "Stop adding breakpoints at random. Learn fluid vs. stepped responsive strategies, clamp() typography, srcset images, and when breakpoints actually matter."
+keywords:
+  [
+    responsive design strategy,
+    fluid typography clamp,
+    tailwind breakpoints best practices,
+    mobile first css,
+    responsive images srcset sizes,
+    css container queries,
+    responsive spacing system,
+    breakpoint strategy frontend,
+  ]
+---
+
+# Responsive Design as a System
+
+Responsiveness is often treated as an afterthought—"make it work on mobile"—but this leads to fragile layouts held together by media queries. Genuine responsive design is a strategy: a coherent approach to how your UI adapts across screen sizes, input methods, and contexts.
+
+This document covers responsive design as strategy: when to use fluid versus stepped approaches, how to treat breakpoints as tools rather than goals, and how to unify typography, spacing, and images into a coherent adaptive system.
+
+## Responsiveness as Strategy
+
+Before writing a single media query, answer these questions:
+
+1. **What are your actual viewports?** — Not theoretical ones. Check analytics. Where do users actually view this?
+2. **What changes between sizes?** — Layout, content visibility, interaction patterns, or all three?
+3. **Is adaptation continuous or discrete?** — Should things scale smoothly, or shift at specific points?
+
+### The strategy spectrum
+
+```
+Fluid                                                    Stepped
+  │                                                          │
+  ▼                                                          ▼
+Typography scales smoothly          Typography jumps at breakpoints
+Spacing uses viewport units         Spacing uses fixed tokens per breakpoint
+Images resize continuously          Images swap sources at breakpoints
+Layout flows naturally              Layout restructures at breakpoints
+```
+
+Most systems are hybrid: fluid within ranges, stepped between them.
+
+### Mobile-first vs. desktop-first
+
+**Mobile-first** (recommended for most projects):
+
+- Start with the smallest viewport
+- Add complexity with `min-width` media queries
+- Forces you to prioritize content
+- Tailwind default: `sm:`, `md:`, `lg:` add styles upward
+
+```tsx
+// Mobile-first: base is mobile, add for larger
+<div className="flex flex-col md:flex-row">
+  <div className="w-full md:w-1/3">Sidebar</div>
+  <div className="w-full md:w-2/3">Content</div>
+</div>
+```
+
+**Desktop-first** (rare, specific use cases):
+
+- Start with the largest viewport
+- Remove complexity with `max-width` media queries
+- Can lead to "hide things on mobile" anti-pattern
+
+Choose based on your audience. If 70% of traffic is mobile, mobile-first is obvious. If building an enterprise dashboard used on desktop, desktop-first might make sense.
+
+## Breakpoints as Tools
+
+Breakpoints are often treated as mandatory stops: "we need a mobile layout, tablet layout, and desktop layout." This creates artificial constraints and busywork.
+
+### The breakpoint trap
+
+```tsx
+// Busywork: different padding at every breakpoint
+<div className="p-2 sm:p-3 md:p-4 lg:p-5 xl:p-6">
+
+// Often unnecessary: one or two breakpoints suffice
+<div className="p-3 md:p-5">
+```
+
+Adding breakpoints because they exist, not because layout requires them, creates maintenance burden and visual noise.
+
+### When breakpoints matter
+
+Breakpoints are meaningful when:
+
+1. **Layout fundamentally changes** — Single column to multi-column
+2. **Content reorganizes** — Navigation collapses, sidebar becomes bottom sheet
+3. **Interaction shifts** — Hover states become taps, tooltips become modals
+
+```tsx
+// Meaningful: layout restructure
+<div className="grid grid-cols-1 lg:grid-cols-12">
+  <aside className="lg:col-span-3">
+    {/* Mobile: full width, stacked
+        Desktop: sidebar */}
+  </aside>
+  <main className="lg:col-span-9">
+    {/* Content */}
+  </main>
+</div>
+```
+
+### When to skip breakpoints
+
+Many properties don't need breakpoint variation:
+
+- **Fluid typography** scales without breakpoints
+- **Percentage widths** adapt automatically
+- **Gap/spacing** often works at one size
+- **Max-width containers** prevent over-wide content
+
+```tsx
+// No breakpoints needed: naturally responsive
+<article className="max-w-prose mx-auto px-4">
+  <h1 className="text-2xl font-bold">Title</h1>
+  <p className="mt-4 text-base">Content...</p>
+</article>
+```
+
+The `max-width: prose` (~65 characters) ensures readability at any viewport. Horizontal padding provides breathing room. No breakpoints required.
+
+## Fluid Typography
+
+Typography can scale fluidly using viewport-relative units or CSS `clamp()`.
+
+### The clamp approach
+
+```css
+/* Font size scales between 1rem (16px) and 1.5rem (24px)
+   based on viewport width */
+.heading {
+  font-size: clamp(1rem, 0.5rem + 2vw, 1.5rem);
+}
+```
+
+In Tailwind, use arbitrary values or custom utilities:
+
+```tsx
+<h1 className="text-[clamp(1.5rem,1rem+2vw,2.5rem)]">
+  Responsive Heading
+</h1>
+```
+
+### Fluid typography scale
+
+Define a fluid scale that maintains visual hierarchy:
+
+```css
+:root {
+  --text-sm: clamp(0.875rem, 0.8rem + 0.25vw, 1rem);
+  --text-base: clamp(1rem, 0.9rem + 0.5vw, 1.125rem);
+  --text-lg: clamp(1.125rem, 1rem + 0.75vw, 1.5rem);
+  --text-xl: clamp(1.5rem, 1.25rem + 1vw, 2rem);
+  --text-2xl: clamp(2rem, 1.5rem + 1.5vw, 3rem);
+}
+```
+
+### When to step typography
+
+Fluid typography isn't always appropriate:
+
+- **Body text** often works best at fixed sizes (too small is unreadable, too large wastes space)
+- **UI elements** (buttons, labels) need consistent sizing for touch targets
+- **Dense interfaces** may need stepped sizes for clarity
+
+```tsx
+// Fluid: headings and display text
+<h1 className="text-[clamp(2rem,1.5rem+2vw,4rem)]">Hero Title</h1>
+
+// Stepped: body and UI
+<p className="text-base md:text-lg">Body text</p>
+<button className="text-sm px-3 py-2">Button</button>
+```
+
+## Spacing Systems
+
+Spacing—margins, padding, gaps—can be fluid, stepped, or both.
+
+### Fixed spacing tokens
+
+Most design systems use fixed spacing tokens:
+
+```tsx
+// Tailwind spacing scale
+<div className="p-4">       // 16px
+<div className="gap-6">     // 24px
+<div className="mt-8">      // 32px
+```
+
+These work well because:
+- Spacing is about rhythm, not viewport size
+- Touch targets need minimum sizes
+- Proportions should be consistent
+
+### Viewport-relative spacing
+
+For larger spaces (sections, hero areas), viewport units can help:
+
+```tsx
+// Section padding scales with viewport
+<section className="py-16 md:py-24 lg:py-32">
+
+// Or use viewport units
+<section className="py-[5vh] md:py-[8vh]">
+```
+
+### The spacing hierarchy
+
+Different spacing for different purposes:
+
+| Purpose | Approach | Example |
+|---------|----------|---------|
+| Component internal | Fixed tokens | `p-4`, `gap-2` |
+| Component external | Fixed or stepped | `mt-8 md:mt-12` |
+| Section spacing | Viewport-relative or stepped | `py-16 lg:py-24` |
+| Full-bleed elements | Viewport-relative | `min-h-[50vh]` |
+
+## Image Adaptation
+
+Images are often the largest assets and most variable content. Responsive image strategy matters.
+
+### Resolution switching
+
+Same image, different sizes for different viewports:
+
+```tsx
+<img
+  src="/hero.jpg"
+  srcSet="
+    /hero-400.jpg 400w,
+    /hero-800.jpg 800w,
+    /hero-1200.jpg 1200w,
+    /hero-1600.jpg 1600w
+  "
+  sizes="
+    (max-width: 640px) 100vw,
+    (max-width: 1024px) 80vw,
+    1200px
+  "
+  alt="Hero image"
+/>
+```
+
+The browser picks the right size based on viewport and pixel density.
+
+### Art direction
+
+Different crops or compositions for different viewports:
+
+```tsx
+<picture>
+  {/* Mobile: vertical crop, focus on subject */}
+  <source media="(max-width: 640px)" srcSet="/hero-mobile.jpg" />
+
+  {/* Tablet: square crop */}
+  <source media="(max-width: 1024px)" srcSet="/hero-tablet.jpg" />
+
+  {/* Desktop: full landscape */}
+  <img src="/hero-desktop.jpg" alt="Hero image" />
+</picture>
+```
+
+Use art direction when:
+- Composition must change (landscape to portrait)
+- Important details would be lost at small sizes
+- Different contexts need different framing
+
+### Lazy loading and placeholders
+
+```tsx
+<img
+  src="/product.jpg"
+  loading="lazy"           // Browser-native lazy loading
+  decoding="async"         // Non-blocking decode
+  className="bg-gray-100"  // Placeholder background
+  alt="Product"
+/>
+```
+
+For above-the-fold images, skip lazy loading:
+
+```tsx
+<img
+  src="/hero.jpg"
+  fetchPriority="high"     // Prioritize loading
+  alt="Hero"
+/>
+```
+
+## Layout Strategies
+
+### Fluid containers with max-width
+
+```tsx
+// Content stays readable at any size
+<div className="max-w-7xl mx-auto px-4 sm:px-6 lg:px-8">
+  {/* Content */}
+</div>
+```
+
+The container:
+- Centers content
+- Caps maximum width
+- Adds responsive padding
+
+### Grid with implicit responsiveness
+
+```tsx
+// Columns wrap naturally
+<div className="grid grid-cols-[repeat(auto-fill,minmax(300px,1fr))] gap-6">
+  {items.map(item => <Card key={item.id} {...item} />)}
+</div>
+```
+
+No breakpoints needed. Items fill available space, wrapping when they'd shrink below 300px.
+
+### Flexbox with wrapping
+
+```tsx
+// Items wrap when space runs out
+<div className="flex flex-wrap gap-4">
+  <div className="flex-1 min-w-[200px]">Item 1</div>
+  <div className="flex-1 min-w-[200px]">Item 2</div>
+  <div className="flex-1 min-w-[200px]">Item 3</div>
+</div>
+```
+
+### Explicit layout shifts
+
+When layout fundamentally changes:
+
+```tsx
+// Mobile: stacked, Desktop: sidebar layout
+<div className="flex flex-col lg:flex-row">
+  <aside className="lg:w-64 lg:flex-shrink-0">
+    <nav className="lg:sticky lg:top-4">
+      {/* Navigation */}
+    </nav>
+  </aside>
+  <main className="flex-1 min-w-0">
+    {/* Content */}
+  </main>
+</div>
+```
+
+## The Unified Mental Model
+
+Think of responsiveness as a system, not a set of ad-hoc fixes.
+
+### The three layers
+
+**1. Content layer (what)**
+- What content exists
+- What's essential vs. optional
+- Content priority
+
+**2. Structure layer (how)**
+- Layout patterns
+- Component composition
+- Navigation patterns
+
+**3. Presentation layer (style)**
+- Typography
+- Spacing
+- Colors, images
+
+### How layers adapt
+
+| Viewport | Content | Structure | Presentation |
+|----------|---------|-----------|--------------|
+| Mobile | Essential only | Single column, stacked | Larger touch targets, denser type |
+| Tablet | Most content | Mixed layouts | Balanced proportions |
+| Desktop | All content | Multi-column, sidebars | More whitespace, smaller touch targets |
+
+### Designing responsively
+
+When designing a responsive component:
+
+1. **Define content** — What must be shown? What's optional?
+2. **Define breakpoints** — Where does structure actually need to change?
+3. **Define scaling** — What scales fluid? What steps?
+4. **Test edges** — 320px, 768px, 1024px, 1440px, 2560px
+
+### Testing strategy
+
+```tsx
+// Critical viewports to test
+const viewports = [
+  320,   // Small phones
+  375,   // iPhone standard
+  414,   // iPhone Max
+  768,   // iPad portrait
+  1024,  // iPad landscape / small laptop
+  1280,  // Laptop
+  1440,  // Desktop
+  1920,  // Full HD
+];
+```
+
+Test at edges, not just at breakpoints. The space between 767px and 769px often reveals problems.
+
+## How this connects to Bitloops
+
+Responsive behavior is where design-to-code translation most often breaks down — designers think in fluid layouts and adaptive content, while developers implement fixed breakpoints and ad-hoc media queries. [Bitloops](https://bitloops.com) bridges this gap by interpreting responsive design intent and generating code that uses fluid strategies (like `clamp()` for typography), mobile-first breakpoints, and proper image adaptation (`srcset`/`sizes`). Instead of manually translating artboards into media queries, you get responsive components that follow the strategic approach described in this document.
+
+---
+
+## Summary
+
+Responsive design is strategy, not afterthought. The principles:
+
+| Principle | Application |
+|---|---|
+| Choose a strategy | Decide up front whether the UI is **fluid**, **stepped**, or **hybrid** (fluid within ranges, stepped at true structural shifts). Document what scales continuously (type, spacing, images) vs. what changes discretely (layout, nav patterns). |
+| Mobile-first (usually) | Start from the smallest viewport and **add complexity with min-width** (Tailwind `sm: md: lg:`). Use this to force content prioritization and avoid “hide on mobile” layouts. Use desktop-first only when usage is overwhelmingly desktop (e.g., internal dashboards). |
+| Breakpoints as tools | Add breakpoints only when **structure or interaction** changes (1→2 columns, nav collapse, sidebar behavior, tooltip→modal). Avoid “padding at every breakpoint” busywork; keep breakpoint usage sparse and purposeful. |
+| Fluid typography for headings | Use `clamp()` for display text and headings to preserve hierarchy across widths. Keep **body/UI text stepped** where readability and touch targets matter, and reserve fluid scaling for large type where it improves rhythm and density. |
+| Fixed spacing for components | Keep component padding/gaps on **token scales** (`p-4`, `gap-6`) for consistent rhythm and predictable touch targets. Step spacing only when density genuinely needs to change (e.g., `mt-8 md:mt-12`). Use viewport-relative spacing for **sections**, not buttons. |
+| Image strategy matters | Use **resolution switching** (`srcset`/`sizes`) to reduce bytes on small screens and support high-DPI. Use **art direction** (`picture`) when composition must change (crop/focus). Avoid lazy-loading above-the-fold; prefer `fetchPriority="high"` for hero images. |
+| Test edges, not breakpoints | Validate at **edge viewports** (320/375/414/768/1024/1280/1440/1920+) and between breakpoints to catch “in-between” layout failures. Include input-mode checks (touch vs. hover) where interaction changes. |
+
+A coherent responsive strategy makes maintenance easier and user experience better. Ad-hoc media queries create technical debt.
+
+---
+
+## Further reading
+
+- [Every Layout — Heydon Pickering & Andy Bell](https://every-layout.dev/) — A set of CSS layout primitives (Stack, Sidebar, Switcher, etc.) that handle responsive behavior intrinsically, without media queries; the gold standard for fluid layout thinking.
+- [Utopia — Fluid Type & Space Calculator](https://utopia.fyi/) — Interactive tool for generating `clamp()`-based fluid typography and spacing scales; directly implements the fluid typography approach described in this document.
+- [Responsive Web Design — MDN Web Docs](https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layout/Responsive_Design) — Comprehensive MDN guide covering media queries, fluid grids, responsive images, and viewport units; a reliable reference for all responsive CSS fundamentals.
+- [A Complete Guide to CSS Container Queries — Ahmad Shadeed](https://ishadeed.com/article/css-container-queries/) — Explains container queries as the next evolution of responsive design, enabling component-level responsiveness instead of viewport-level breakpoints.
+- [Responsive Images — web.dev](https://web.dev/learn/design/responsive-images/) — Google's guide to `srcset`, `sizes`, and the `<picture>` element; covers resolution switching and art direction with practical examples and performance considerations.
+
+---
+
+## Frequently Asked Questions (FAQs)
+
+1. **How many breakpoints do I actually need?**
+   Most layouts need 1-2 meaningful breakpoints, not 5. Add breakpoints only when layout structure genuinely changes (single column to multi-column, navigation collapse). Don't add breakpoints for minor spacing tweaks. See [Component Creation Workflows](./component-creation-workflows.md) for keeping component complexity manageable.
+
+2. **When should I use fluid typography with clamp()?**
+   Use `clamp()` for headings and display text where smooth scaling improves visual rhythm across viewports. Keep body text and UI elements (buttons, labels) at fixed sizes for consistent readability and touch targets—especially important for [Accessibility](./accessibility.md).
+
+3. **What's the difference between fluid and stepped responsive design?**
+   Fluid: values scale continuously with viewport (using vw units, clamp()). Stepped: values jump at specific breakpoints. Most production systems are hybrid—fluid typography within ranges, stepped layout changes at major breakpoints. See [Design System Consumption](./design-system-consumption.md) for token-based approaches.
+
+4. **Should I use mobile-first or desktop-first CSS?**
+   Mobile-first for most projects—it forces content prioritization and aligns with Tailwind's default modifiers (`sm:`, `md:`, `lg:` add styles as viewport grows). Desktop-first only if 70%+ of your audience uses desktop. For layout shift concerns, see [Performance Optimization](../ui-systems-performance/performance-optimization.md).
+
+5. **How do I handle responsive images correctly?**
+   Use `srcset` and `sizes` for resolution switching (same image, different file sizes for different viewports). Use `<picture>` for art direction. Always include `width` and `height` attributes to prevent layout shift (CLS). See [Performance Optimization](../ui-systems-performance/performance-optimization.md) for image performance patterns.
+
+6. **When do breakpoints actually matter vs. being unnecessary?**
+   Breakpoints matter when: layout fundamentally restructures (sidebar becomes bottom nav), content reorganizes (tabs become accordion), or interaction patterns change (hover becomes tap). For accessibility of these pattern changes, see [Accessibility](./accessibility.md).
+
+7. **How do I test responsive behavior effectively?**
+   Test at edge viewports (320px, 375px, 768px, 1024px, 1440px) and between breakpoints (767px and 769px often reveal bugs). For visual regression testing across viewports, see [Testing and Storybook](./testing-and-storybook.md). For production monitoring, see [Observability](../ui-systems-performance/observability.md).
+
+8. **Should spacing be fluid or use fixed tokens?**
+   Fixed tokens for component-internal spacing (padding, gaps)—these need consistent rhythm and touch targets. Viewport-relative or stepped spacing for section-level spacing. See [Design System Consumption](./design-system-consumption.md) for token-only styling patterns.
+
+9. **How do container queries change responsive design?**
+   Container queries let components respond to their container's size, not the viewport. This enables truly reusable components—a Card can adapt based on whether it's in a sidebar or main content. See [Component Creation Workflows](./component-creation-workflows.md) for component reusability patterns.
+
+10. **What's the "breakpoint trap" and how do I avoid it?**
+    The trap: adding `sm:`, `md:`, `lg:`, `xl:` variants to every property because breakpoints exist. Avoid it by: using fluid values where appropriate, questioning whether each breakpoint variant is necessary. See [Codebase Conventions](./codebase-conventions.md) for establishing responsive design conventions.
+
+---
+
+*Build responsive UIs that adapt fluidly. Start building with [Bitloops](https://bitloops.com).*
diff --git a/documentation/docs/frontend-copilot/best-practices/testing-and-storybook.md b/documentation/docs/frontend-copilot/best-practices/testing-and-storybook.md
new file mode 100644
index 00000000..3f299af0
--- /dev/null
+++ b/documentation/docs/frontend-copilot/best-practices/testing-and-storybook.md
@@ -0,0 +1,617 @@
+---
+sidebar_position: 9
+sidebar_label: Testing and Storybook
+title: "Storybook as a Contract Layer: Fixtures, Visual Testing, and Executable Specifications"
+description: "Stories aren't documentation—they're contracts. Learn deterministic fixtures, visual regression testing, and how Storybook becomes your component verification layer."
+keywords:
+  [
+    storybook testing best practices,
+    visual regression testing storybook,
+    storybook fixtures patterns,
+    component story format csf,
+    chromatic visual testing,
+    storybook interaction testing,
+    deterministic test data,
+    storybook as documentation,
+  ]
+---
+
+# Storybook as a testing and contract layer
+
+Storybook is often introduced as "visual documentation" or "a playground for components." These descriptions undersell its value. Storybook is a contract layer—a way to specify, demonstrate, and verify component behavior through executable examples.
+
+This document covers Storybook as a verification tool: how stories serve as contracts, the discipline of deterministic fixtures, and the separation between visual states and data variability.
+
+## Stories as Contracts
+
+A story is a statement: "Given these props, the component looks and behaves like this."
+
+```tsx
+// Button.stories.tsx
+export const Primary: Story = {
+  args: {
+    variant: 'primary',
+    children: 'Click me',
+  },
+};
+```
+
+This story is a contract:
+- When `variant="primary"` and `children="Click me"`, the component renders as shown
+- Future changes that break this appearance are regressions
+- Consumers can rely on this behavior
+
+### From documentation to contract
+
+**Documentation mindset:**
+"Here's what the button looks like with different variants."
+
+**Contract mindset:**
+"These are the guaranteed states. If a change breaks these stories, it's a breaking change that requires review."
+
+The shift matters. Documentation is informational. Contracts are enforceable.
+
+### What stories guarantee
+
+Each story is a snapshot of expected behavior:
+
+```tsx
+export const Loading: Story = {
+  args: {
+    variant: 'primary',
+    isLoading: true,
+    children: 'Submit',
+  },
+};
+```
+
+This story guarantees:
+- A loading state exists
+- It's triggered by `isLoading: true`
+- The visual treatment is as rendered
+- The text remains visible (or not—the story shows which)
+
+### Stories as acceptance criteria
+
+For feature work, stories can serve as acceptance criteria:
+
+```tsx
+// Feature: User can see product in different states
+
+export const InStock: Story = {
+  args: {
+    product: mockProduct({ inStock: true }),
+  },
+};
+
+export const OutOfStock: Story = {
+  args: {
+    product: mockProduct({ inStock: false }),
+  },
+};
+
+export const OnSale: Story = {
+  args: {
+    product: mockProduct({ salePrice: 19.99 }),
+  },
+};
+```
+
+When these stories render correctly, the feature is complete.
+
+## The Fixture Discipline
+
+Stories require data. That data needs to be deterministic—the same inputs produce the same outputs every time.
+
+### The problem with random data
+
+```tsx
+// Brittle: different every run
+export const UserCard: Story = {
+  args: {
+    user: {
+      name: faker.name.fullName(),        // "John Doe" sometimes
+      avatar: faker.image.avatar(),        // Different image each time
+      joinedAt: faker.date.past(),         // Different date
+    },
+  },
+};
+```
+
+Problems:
+- Visual regression tests fail randomly
+- Screenshots differ between runs
+- Debugging is harder—"which data caused this?"
+
+### Deterministic fixtures
+
+```tsx
+// Stable: same every run
+const mockUser = (overrides = {}) => ({
+  id: 'user-1',
+  name: 'Jane Smith',
+  avatar: '/fixtures/avatar.png',
+  email: 'jane@example.com',
+  joinedAt: '2023-01-15T00:00:00Z',
+  ...overrides,
+});
+
+export const UserCard: Story = {
+  args: {
+    user: mockUser(),
+  },
+};
+
+export const UserCardLongName: Story = {
+  args: {
+    user: mockUser({ name: 'Alexandria Bartholomew Constantine III' }),
+  },
+};
+```
+
+Benefits:
+- Reproducible results
+- Visual regression tests work
+- Easy to create variants with overrides
+
+### Fixture factories
+
+Create factory functions for complex data:
+
+```tsx
+// fixtures/product.ts
+export const mockProduct = (overrides = {}): Product => ({
+  id: 'prod-1',
+  name: 'Example Product',
+  description: 'A great product for testing.',
+  price: 29.99,
+  currency: 'USD',
+  image: '/fixtures/product.png',
+  inStock: true,
+  rating: 4.5,
+  reviewCount: 128,
+  ...overrides,
+});
+
+// Usage in stories
+export const Default: Story = {
+  args: { product: mockProduct() },
+};
+
+export const Expensive: Story = {
+  args: { product: mockProduct({ price: 999.99 }) },
+};
+
+export const OutOfStock: Story = {
+  args: { product: mockProduct({ inStock: false }) },
+};
+
+export const NoReviews: Story = {
+  args: { product: mockProduct({ rating: 0, reviewCount: 0 }) },
+};
+```
+
+### Fixture organization
+
+```
+src/
+  fixtures/
+    users.ts        # User factories
+    products.ts     # Product factories
+    orders.ts       # Order factories
+    index.ts        # Re-exports all fixtures
+  components/
+    ProductCard/
+      ProductCard.tsx
+      ProductCard.stories.tsx  # Uses fixtures/products
+```
+
+Centralized fixtures ensure consistency across stories and tests.
+
+## Visual States vs. Data Variability
+
+A component has visual states (loading, error, empty) and data variations (different content). Stories should cover both, but separately.
+
+### Visual states
+
+States that change the component's structure or behavior:
+
+```tsx
+// Loading state: different structure
+export const Loading: Story = {
+  args: {
+    isLoading: true,
+  },
+};
+
+// Error state: different structure
+export const Error: Story = {
+  args: {
+    error: new Error('Failed to load'),
+  },
+};
+
+// Empty state: different structure
+export const Empty: Story = {
+  args: {
+    items: [],
+  },
+};
+
+// Default state: normal structure
+export const Default: Story = {
+  args: {
+    items: mockItems(3),
+  },
+};
+```
+
+### Data variability
+
+Different content within the same visual structure:
+
+```tsx
+// Short content
+export const ShortTitle: Story = {
+  args: {
+    title: 'Hi',
+  },
+};
+
+// Long content (tests truncation, wrapping)
+export const LongTitle: Story = {
+  args: {
+    title: 'This is an extremely long title that might wrap or truncate depending on container width',
+  },
+};
+
+// Edge case content
+export const SpecialCharacters: Story = {
+  args: {
+    title: 'Héllo & <World> "Quotes"',
+  },
+};
+```
+
+### The coverage matrix
+
+| State \ Content | Short | Normal | Long | Edge Case |
+|-----------------|-------|--------|------|-----------|
+| Default         | ✓     | ✓      | ✓    | ✓         |
+| Loading         | —     | ✓      | —    | —         |
+| Error           | —     | ✓      | —    | —         |
+| Empty           | —     | n/a    | —    | —         |
+
+You don't need every combination. Cover:
+- All visual states with normal content
+- Default state with content variations
+
+## Story Organization
+
+### File structure
+
+```tsx
+// Button.stories.tsx
+import type { Meta, StoryObj } from '@storybook/react';
+import { Button } from './Button';
+
+const meta: Meta<typeof Button> = {
+  title: 'Components/Button',
+  component: Button,
+  tags: ['autodocs'],
+};
+
+export default meta;
+type Story = StoryObj<typeof Button>;
+
+// Primary stories (most common uses)
+export const Primary: Story = { ... };
+export const Secondary: Story = { ... };
+export const Ghost: Story = { ... };
+
+// States
+export const Disabled: Story = { ... };
+export const Loading: Story = { ... };
+
+// Sizes
+export const Small: Story = { ... };
+export const Large: Story = { ... };
+
+// Edge cases
+export const LongLabel: Story = { ... };
+export const IconOnly: Story = { ... };
+```
+
+### Naming conventions
+
+- **Primary/Default first** — The most common case
+- **Descriptive names** — What makes this story different
+- **Grouped by category** — States, sizes, variants, edge cases
+
+### Documentation in stories
+
+Use story-level documentation:
+
+```tsx
+export const Loading: Story = {
+  args: {
+    isLoading: true,
+    children: 'Submit',
+  },
+  parameters: {
+    docs: {
+      description: {
+        story: 'Button shows a spinner and disables interaction while loading.',
+      },
+    },
+  },
+};
+```
+
+## Storybook as Verification
+
+### Visual regression testing
+
+Tools like Chromatic or Percy compare story screenshots:
+
+```tsx
+// This story is a visual contract
+export const Primary: Story = {
+  args: { variant: 'primary', children: 'Click me' },
+};
+
+// Chromatic captures a screenshot
+// Future changes that alter pixels trigger review
+```
+
+### Interaction testing
+
+Test user interactions within stories:
+
+```tsx
+import { within, userEvent } from '@storybook/testing-library';
+import { expect } from '@storybook/jest';
+
+export const ClickInteraction: Story = {
+  args: {
+    onClick: fn(),  // Mock function
+    children: 'Click me',
+  },
+  play: async ({ args, canvasElement }) => {
+    const canvas = within(canvasElement);
+    const button = canvas.getByRole('button');
+
+    await userEvent.click(button);
+
+    expect(args.onClick).toHaveBeenCalledTimes(1);
+  },
+};
+```
+
+### Accessibility testing
+
+Integrate accessibility checks:
+
+```tsx
+export const AccessibleButton: Story = {
+  args: {
+    children: 'Submit',
+  },
+  parameters: {
+    a11y: {
+      // Accessibility rules for this story
+      config: {
+        rules: [{ id: 'button-name', enabled: true }],
+      },
+    },
+  },
+};
+```
+
+Storybook's a11y addon runs automated checks against every story.
+
+## Connection to Data Contracts
+
+Stories and data contracts (from [Data Contracts](./data-contracts.md)) work together.
+
+### Component props match data contracts
+
+```tsx
+// Data contract (from API)
+interface Product {
+  id: string;
+  name: string;
+  formattedPrice: string;
+  imageUrl: string;
+  availability: 'in-stock' | 'low-stock' | 'out-of-stock';
+}
+
+// Component props match the contract
+interface ProductCardProps {
+  product: Product;
+}
+
+// Stories use fixtures that match the contract
+export const InStock: Story = {
+  args: {
+    product: mockProduct({ availability: 'in-stock' }),
+  },
+};
+```
+
+### Fixtures reflect real data shapes
+
+```tsx
+// Fixture matches what the API actually returns
+const mockProduct = (overrides = {}): Product => ({
+  id: 'prod-1',
+  name: 'Test Product',
+  formattedPrice: '$29.99',  // Already formatted, like real data
+  imageUrl: '/fixtures/product.png',
+  availability: 'in-stock',
+  ...overrides,
+});
+```
+
+### Stories test mapping assumptions
+
+If your mapping layer transforms API data, stories should use the transformed shape:
+
+```tsx
+// API returns price_cents, mapping layer produces formattedPrice
+// Stories use formattedPrice because that's what the component receives
+export const ExpensiveProduct: Story = {
+  args: {
+    product: mockProduct({ formattedPrice: '$1,299.99' }),
+  },
+};
+```
+
+## Common Patterns
+
+### Args composition
+
+Compose complex props:
+
+```tsx
+const baseArgs = {
+  variant: 'primary' as const,
+  size: 'md' as const,
+};
+
+export const Primary: Story = {
+  args: { ...baseArgs, children: 'Click me' },
+};
+
+export const PrimaryDisabled: Story = {
+  args: { ...baseArgs, children: 'Click me', disabled: true },
+};
+```
+
+### Decorators for context
+
+Wrap stories with necessary context:
+
+```tsx
+const meta: Meta<typeof ThemeToggle> = {
+  component: ThemeToggle,
+  decorators: [
+    (Story) => (
+      <ThemeProvider>
+        <Story />
+      </ThemeProvider>
+    ),
+  ],
+};
+```
+
+### Controls for exploration
+
+Let consumers adjust props:
+
+```tsx
+const meta: Meta<typeof Button> = {
+  component: Button,
+  argTypes: {
+    variant: {
+      control: 'select',
+      options: ['primary', 'secondary', 'ghost'],
+    },
+    size: {
+      control: 'radio',
+      options: ['sm', 'md', 'lg'],
+    },
+  },
+};
+```
+
+### Story composition
+
+Compose stories for complex scenarios:
+
+```tsx
+// Individual component stories
+export const ProductCardStory = { ... };
+export const AddToCartButtonStory = { ... };
+
+// Composed scenario
+export const ProductPage: Story = {
+  render: () => (
+    <div className="grid grid-cols-2 gap-8">
+      <ProductCard {...ProductCardStory.args} />
+      <div>
+        <AddToCartButton {...AddToCartButtonStory.args} />
+      </div>
+    </div>
+  ),
+};
+```
+
+## How this connects to Bitloops
+
+Writing stories for every component state is one of the most valuable — and most skipped — practices in frontend development. Teams know they should do it but often don't, because the overhead of creating deterministic fixtures and covering every visual state feels too high. [Bitloops](https://bitloops.com) generates Storybook stories alongside components, with fixtures that reflect real data shapes and stories that cover the key visual states (default, loading, error, empty, edge cases). This turns story coverage from a discipline problem into a workflow default — every component starts with executable contracts, and the team's job shifts from writing stories from scratch to reviewing and extending them.
+
+---
+
+## Summary
+
+Storybook is a contract layer. The principles:
+
+| Principle | Application |
+|---------|-------------|
+| Stories are contracts | Each story defines a guaranteed component state: given specific props, the component must render and behave consistently. Breaking a story is a regression, not a visual tweak. |
+| Deterministic fixtures | Stories use stable, repeatable fixture data so visual output, tests, and debugging are reliable across runs, environments, and contributors. |
+| Separate states from data | Visual states (loading, error, empty) are modeled independently from content variations (short, long, edge-case data) to ensure clear and complete coverage. |
+| Organize for discovery | Stories are structured by primary use cases, states, sizes, and edge cases so consumers can quickly understand supported behavior. |
+| Verify, don’t just document | Stories power visual regression testing, interaction testing, and accessibility checks, turning Storybook into an enforcement layer. |
+| Align with data contracts | Story fixtures reflect real, post-mapping data shapes so components are tested against the same contracts they receive in production. |
+
+Stories aren't screenshots for a design handoff. They're executable specifications that verify your components behave as promised. When stories pass, you know the contract holds.
+
+---
+
+## Further reading
+
+- [Storybook Documentation — Writing Stories](https://storybook.js.org/docs/writing-stories) — The official guide to authoring stories with Component Story Format (CSF), args, decorators, and play functions; the starting point for everything in this document.
+- [Component-Driven Development — chromatic.com](https://www.componentdriven.org/) — Explains the methodology of building UIs bottom-up from isolated components, with Storybook as the development environment; provides the "why" behind using stories as contracts.
+- [Chromatic — Visual Testing Handbook](https://storybook.js.org/tutorials/visual-testing-handbook/) — A free tutorial on visual regression testing with Storybook and Chromatic, covering snapshot workflows, baselines, and review processes for catching unintended visual changes.
+- [Testing Library — Guiding Principles](https://testing-library.com/docs/guiding-principles) — The philosophy behind testing UI components the way users interact with them (roles, labels, text), which directly complements Storybook's interaction testing via `play` functions.
+- [Storybook Accessibility Addon](https://storybook.js.org/addons/@storybook/addon-a11y) — Documentation for integrating automated accessibility checks (powered by axe-core) into every story, turning Storybook into an accessibility enforcement layer.
+
+---
+
+## Frequently Asked Questions (FAQs)
+
+1. **What's the difference between stories and unit tests?**
+   Stories verify visual output and behavior for specific prop combinations—they're executable specifications of "what this looks like." Unit tests verify logic and edge cases programmatically. For component logic that needs unit testing, see how [Data Contracts](./data-contracts.md) recommends testing mapping layers.
+
+2. **Should I use random data (faker) in Storybook fixtures?**
+   No for production stories. Random data breaks visual regression tests, makes debugging harder, and prevents reproducibility. Use deterministic fixtures with factory functions. See [Data Contracts](./data-contracts.md) for how fixtures should mirror real data shapes.
+
+3. **How do I create deterministic fixtures for stories?**
+   Create factory functions: `const mockUser = (overrides = {}) => ({ id: 'user-1', name: 'Jane Smith', avatar: '/fixtures/avatar.png', ...overrides })`. See [Codebase Conventions](./codebase-conventions.md) for organizing fixtures alongside components.
+
+4. **How many stories should each component have?**
+   Cover: (1) default/primary state, (2) all visual variants (see [Component API Design](./component-api-design.md)), (3) key interactive states (loading, error, empty), (4) edge cases (long text, missing optional data). Focus on states users actually encounter.
+
+5. **How do I test user interactions in Storybook?**
+   Use the `play` function with `@storybook/testing-library`. Test keyboard interactions for [Accessibility](./accessibility.md). Write interactions that click, type, and assert—these run automatically and catch behavior regressions.
+
+6. **When should I use Chromatic vs. local Storybook testing?**
+   Local Storybook for development iteration—see changes immediately. Chromatic (or Percy) for CI visual regression testing. For production monitoring beyond CI, see [Observability](../ui-systems-performance/observability.md).
+
+7. **What's the relationship between stories and data contracts?**
+   Story fixtures should reflect real data shapes—the post-mapping shape that components actually receive. See [Data Contracts](./data-contracts.md) for mapping layer patterns. Stories test the component contract, not the API contract.
+
+8. **How do I organize stories for complex components?**
+   Group by category: Primary use cases first, then states (loading, error, disabled), then sizes/variants, then edge cases. See [Codebase Conventions](./codebase-conventions.md) for file organization patterns.
+
+9. **Should stories be documentation or tests?**
+   Both. Stories document supported states and verify those states remain stable. The shift from "documentation mindset" to "contract mindset" is key. See [Component API Design](./component-api-design.md) for how stories demonstrate the component's API contract.
+
+10. **How do I prevent stories from becoming stale?**
+    Keep stories close to components (see [Codebase Conventions](./codebase-conventions.md) for colocation patterns). Use TypeScript for story args so prop changes surface in stories. See [Accessibility](./accessibility.md) for accessibility checks that should run on every story.
+
+---
+
+*Turn your stories into executable specifications. Start building with [Bitloops](https://bitloops.com).*
diff --git a/documentation/docs/frontend-copilot/community-support/contact-us.md b/documentation/docs/frontend-copilot/community-support/contact-us.md
new file mode 100644
index 00000000..0c4c0033
--- /dev/null
+++ b/documentation/docs/frontend-copilot/community-support/contact-us.md
@@ -0,0 +1,80 @@
+---
+sidebar_position: 3
+sidebar_label: Contact Us
+title: "Contact Us"
+description: "Get in touch with the Bitloops team for support, questions, or feedback."
+keywords:
+  [
+    contact,
+    support,
+    help,
+    email,
+    demo,
+  ]
+---
+
+# Contact Us
+
+Whether you have a question, need help with a specific feature, or require technical assistance, don't hesitate to reach out. Our team is here to ensure your success with Bitloops.
+
+---
+
+## 🗺 Community (Discord)
+
+**Best for:** Quick questions, community discussions, real-time help
+
+We have a [Discord](https://discord.gg/vj8EdZx8gK) server for live discussion with the Bitloops team as well as the broader community of frontend engineers, designers, and developers using Bitloops.
+
+Feel free to join our server to:
+- Introduce yourself
+- Give us feedback
+- Share your output
+- Build UIs faster together!
+
+[**Join Discord →**](https://discord.gg/vj8EdZx8gK)
+
+---
+
+## 📯 One-to-One Demonstrations
+
+**Best for:** Personalized help, complex scenarios, team onboarding
+
+The Bitloops team wants to help as much as possible, so we provide you with the ability to book a **One-to-One Discussion** with someone from our team.
+
+**What you'll get:**
+- A live, informal 30-minute video session
+- Direct access to a Bitloops Software Engineer
+- Help understanding Bitloops better
+- Assistance solving specific problems you're facing
+
+[**Book a Demo →**](https://calendly.com/bitloops/30min)
+
+---
+
+## 📧 Email
+
+**Best for:** Detailed issues, formal inquiries, partnership discussions
+
+Sometimes the easiest approach is a simple email. Feel free to email us at:
+
+📮 **[support@bitloops.com](mailto:support@bitloops.com)**
+
+One of the founders will respond!
+
+**Response time:** Typically within 1 business day
+
+---
+
+## Related Resources
+
+- [Discord](./discord.md) — Join our Discord community
+- [Submit a Bug](./submit-bug.md) — Report issues and earn credits
+- [The Essential Guide](../getting-started-new/essential-guide.md) — Complete beginner walkthrough
+- [Video Tutorials](../tutorials/learn-by-watching.md) — Watch Bitloops in action
+- [FAQs](../faq-troubleshooting/faqs.md) — Common questions answered
+- [Common Challenges](../faq-troubleshooting/common-challenges.md) — Troubleshooting guide
+- [Tips & Tricks](../faq-troubleshooting/tips-and-tricks.md) — Pro tips for better workflow
+
+---
+
+*We're here to help you succeed with [Bitloops](https://bitloops.com).*
diff --git a/documentation/docs/frontend-copilot/community-support/discord.md b/documentation/docs/frontend-copilot/community-support/discord.md
new file mode 100644
index 00000000..2e1f6786
--- /dev/null
+++ b/documentation/docs/frontend-copilot/community-support/discord.md
@@ -0,0 +1,61 @@
+---
+sidebar_position: 1
+sidebar_label: Join our Discord
+title: "Join our Discord Community"
+description: "Connect with the Bitloops community on Discord for support, feedback, and discussions."
+keywords:
+  [
+    discord,
+    community,
+    support,
+    chat,
+    help,
+  ]
+---
+
+# Join Our Discord Community
+
+Our community lives on [Discord](https://discord.gg/vj8EdZx8gK) — it's the fastest way to connect with the Bitloops team and other developers.
+
+## What You'll Find
+
+| Channel | Purpose |
+|---------|---------|
+| **#general** | General discussions about Bitloops and frontend development |
+| **#help** | Get help with issues and questions |
+| **#feedback** | Share your thoughts and feature requests |
+| **#showcase** | Show off what you've built with Bitloops |
+| **#announcements** | Stay updated on new features and releases |
+
+## Why Join?
+
+- **Get Help Fast:** Ask questions and get answers from the Bitloops team and community members. We're active and ready to help!
+- **Share Feedback:** Your input shapes the future of Bitloops. Share feature requests, report issues, and help us build a better tool.
+- **See What Others Are Building:** Get inspired by what other developers are creating with Bitloops. Share your own projects and get feedback.
+- **Early Access:** Discord members often get early access to new features and the opportunity to provide feedback before public releases.
+- **Direct Access to the Team:** The Bitloops team is active on Discord. Get direct answers from the people building the product.
+
+---
+
+## Community Guidelines
+
+To keep our community helpful and welcoming:
+
+- **Be respectful** — Treat everyone with kindness
+- **Stay on topic** — Use appropriate channels for your messages
+- **Search first** — Check if your question has been answered before
+- **Share knowledge** — Help others when you can
+- **No spam** — Keep promotions relevant and minimal
+
+---
+
+## Related Resources
+
+- [The Essential Guide](../getting-started-new/essential-guide.md) — Complete beginner walkthrough
+- [FAQs](../faq-troubleshooting/faqs.md) — Common questions answered
+- [Common Challenges](../faq-troubleshooting/common-challenges.md) — Troubleshooting guide
+- [Submit a Bug](./submit-bug.md) — Report issues and earn credits
+
+---
+
+*Connect with the [Bitloops](https://bitloops.com) community and build faster together.*
diff --git a/documentation/docs/frontend-copilot/community-support/submit-bug.md b/documentation/docs/frontend-copilot/community-support/submit-bug.md
new file mode 100644
index 00000000..07d15cac
--- /dev/null
+++ b/documentation/docs/frontend-copilot/community-support/submit-bug.md
@@ -0,0 +1,120 @@
+---
+sidebar_position: 2
+sidebar_label: Submit a Bug or Request
+title: "Submit a Bug or Request"
+description: "Report bugs and earn credits through our Spot, Report, Reward program."
+keywords:
+  [
+    bug report,
+    feature request,
+    feedback,
+    issues,
+    rewards,
+  ]
+---
+
+# Submit a bug or request
+
+We are committed to providing a seamless and efficient design-to-code conversion experience. However, we understand that despite our rigorous testing, bugs can slip through the cracks.
+
+This is where you can play a crucial role. Not only do you help us enhance the quality of Bitloops, but you also get rewarded for your contributions.
+
+## 🎁 Spot, report, reward program
+
+Here's how you can participate and earn free credits:
+
+### 1. Identifying Bugs
+
+Begin by using Bitloops as you normally would and keep an eye out for:
+
+- Unexpected behavior
+- Glitches or visual issues
+- Inconsistencies in output
+- Performance problems
+
+Whether it's a minor interface issue or a major functionality flaw, your keen observations are invaluable.
+
+### 2. Generating a Bug Report
+
+If you encounter a bug, prepare to document it:
+
+| Include | Why It Helps |
+|---------|--------------|
+| **What you were doing** | Provides context |
+| **Steps to reproduce** | Helps us recreate the issue |
+| **Expected vs. actual results** | Clarifies the problem |
+| **Screenshots or video** | Visual evidence speeds up diagnosis |
+
+:::tip Pro Tip
+A short video recording is the most helpful way to demonstrate an issue. Tools like Loom or screen recording make this easy.
+:::
+
+### 3. Submitting Your Report
+
+**Option 1: Email**
+Send your report to [support@bitloops.com](mailto:support@bitloops.com) with:
+- Detailed description
+- Steps to reproduce
+- Screenshots or video attachment
+- Your contact information
+
+**Option 2: Discord**
+Post in our [Discord #help channel](https://discord.gg/vj8EdZx8gK) for community visibility and faster response.
+
+### 4. Earning Your Credits
+
+Once your bug report is submitted, our team will:
+
+1. Review the details
+2. Verify the issue
+3. Credit your Bitloops account
+
+These credits can be used for:
+
+- Future subscriptions
+- Additional features
+- Conversion credits within Bitloops
+
+---
+
+## Feature Requests
+
+Have an idea for improving Bitloops? We'd love to hear it!
+
+**How to submit:**
+
+1. Join our [Discord](https://discord.gg/vj8EdZx8gK)
+2. Post in the #feedback channel
+3. Describe your idea and how it would help your workflow
+
+We review all feature requests and prioritize based on community feedback.
+
+---
+
+## What Happens Next?
+
+| Stage | Timeline |
+|-------|----------|
+| **Acknowledgment** | Within 24 hours |
+| **Initial Review** | Within 48 hours |
+| **Status Update** | Within 1 week |
+| **Resolution** | Varies by complexity |
+
+---
+
+## Thank You!
+
+By participating in the 'Spot, Report, Reward' program, you're not just improving your own experience with Bitloops; you're also contributing to a community of developers and designers who rely on our tool for their projects.
+
+---
+
+## Related Resources
+
+- [Common Challenges](../faq-troubleshooting/common-challenges.md) — Common issues and solutions
+- [FAQs](../faq-troubleshooting/faqs.md) — Frequently asked questions
+- [The Essential Guide](../getting-started-new/essential-guide.md) — Complete walkthrough
+- [Tips & Tricks](../faq-troubleshooting/tips-and-tricks.md) — Pro tips for better workflow
+
+---
+
+*Help us improve [Bitloops](https://bitloops.com) — your feedback shapes the product.*
diff --git a/documentation/docs/frontend-copilot/core-concepts/canvases.md b/documentation/docs/frontend-copilot/core-concepts/canvases.md
new file mode 100644
index 00000000..2880e36f
--- /dev/null
+++ b/documentation/docs/frontend-copilot/core-concepts/canvases.md
@@ -0,0 +1,166 @@
+---
+sidebar_position: 6
+sidebar_label: Canvases
+title: "Canvases"
+description: "Learn about the four canvases in Bitloops - Design View, Snapshot View, Component Preview, and File Import."
+keywords:
+  [
+    canvases,
+    design view,
+    snapshot view,
+    component preview,
+    file import,
+    workspaces,
+  ]
+---
+
+# Canvases
+
+**Canvases are a core Bitloops product feature.** They’re the purpose-built workspaces that makes Bitloop usable as a *frontend copilot* rather than “just a generator.”
+
+Instead of cramming design inspection, state comparison, and code preview into one cluttered view, Bitloops splits the workflow into four canvases—each optimized for a specific job. That structure helps you:
+
+- understand what you’re looking at (design vs snapshot vs code)
+- know what action is appropriate in each step
+- quickly spot differences between the design reference and the rendered component
+
+:::tip
+Canvases aren’t different “modes.” They’re different **lenses** over the same workflow—each one designed to reduce cognitive load and make the design-to-code loop faster and more reliable.
+:::
+
+---
+
+## Design View
+
+The **Design View** is where you explore the imported design in a development-friendly way.
+
+It’s a read-only representation of the imported design that’s optimized for implementation—so the tree you see may be cleaner than Figma’s (design noise is filtered out), but it still preserves the structure and details that matter for building the UI.
+
+### What you do here
+
+- Explore the design structure and hierarchy
+- Inspect spacing/alignment (hold `ALT`, like Figma)
+- Select single or multiple nodes
+- Create layout containers (manual grouping for intent)
+- Create components from selected elements
+- Attach snapshots to components
+
+### What you don’t do here
+
+- Edit the design itself
+
+Design View is the “where do I start?” canvas: you decide component boundaries and prepare the structure that will become code.
+
+---
+
+## Snapshot View
+
+The **Snapshot View** isolates a component-sized slice of the design—captured as a snapshot.
+
+It’s the design reference you compare against when implementing or refining a component.
+
+### What a snapshot shows
+
+- The exact design slice for a component example
+- Concrete content (text/images) for that example
+- A specific case that may represent:
+  - an **instance** (same structure, different data), or
+  - a **variant** (different state/style/layout)
+
+### When to use Snapshot View
+
+- Implementing a component state/example
+- Comparing design intent vs implementation output
+- Spotting what changes across snapshots (props, variants, conditionals)
+- Checking spacing and alignment quickly
+
+Snapshot View exists so you can stay in your editor and still have a precise source of truth.
+
+---
+
+## Component Preview
+
+The **Component Preview** renders the real component output—directly from your `.tsx` file.
+
+Every time you save, the preview updates immediately. This is the implementation side of the comparison loop.
+
+### What Component Preview is for
+
+- Validating implementation against the Snapshot View
+- Checking layout/spacing/structure
+- Verifying conditionals and snapshot-driven differences
+- Evaluating responsiveness (especially when you attach viewport-specific snapshots)
+
+Component Preview is where “does it actually work in code?” gets answered instantly.
+
+---
+
+## File Import Canvas
+
+The **File Import Canvas** is where you manage designs:
+
+- import design files into your account library
+- add frames from those files into a specific project
+
+### What it does
+
+- Import a Figma source into **My Design Files** (account-level library)
+- Show available pages/frames from that source
+- Let you choose what frames to add to the current project
+
+### Important notes
+
+- Imported designs do **not** auto-sync with Figma (yet)
+- Imports never edit your original Figma files
+- Treat imports as a static capture of the design at that moment
+
+---
+
+## Navigating between canvases
+
+Bitloops makes canvas navigation intentional—because each canvas is tied to a specific kind of work.
+
+### Via icons
+
+Three icons at the top of the sidebar provide quick access:
+
+| Icon | Opens |
+|------|-------|
+| Design View icon | Design View |
+| Snapshot View icon | Snapshot View |
+| Component View icon | Component Preview |
+
+### Via sidebar selection
+
+| Selection | Result |
+|-----------|--------|
+| Select a **Design** | Opens Design View |
+| Select a **Snapshot** | Opens Snapshot View |
+| Select a **Component** | Opens Snapshot View + Component Preview + the component `.tsx` file |
+
+---
+
+## The “compare loop” (why canvases matter)
+
+The core Bitloops workflow is a tight comparison loop:
+
+- **Snapshot View** shows what the design example looks like
+- **Component Preview** shows what your code renders
+- **Your editor** is where you make changes
+
+That separation is the whole point of canvases: they make differences obvious and iteration fast.
+
+Snapshot View (design reference) ↔ Component Preview (live code output) ↔ Code Editor
+
+If something is off—spacing, hierarchy, conditional rendering—canvases make it easy to identify where the mismatch is coming from and fix it without leaving your IDE.
+
+## Related pages
+
+- [Designs](./designs.md) - The source of truth
+- [Snapshots](./snapshots.md) — Design-based component examples (instances and variants)
+- [Components & Reusability](./components-and-reusability.md) — Component architecture patterns
+- [Layout Containers](./layout-containers.md) — Manual structure control
+
+---
+
+*Try Bitloops at [bitloops.com](https://bitloops.com) — the canvases make the “design ↔ code” gap finally feel manageable.*
diff --git a/documentation/docs/frontend-copilot/core-concepts/code-generation-and-testing.md b/documentation/docs/frontend-copilot/core-concepts/code-generation-and-testing.md
new file mode 100644
index 00000000..eecda9ca
--- /dev/null
+++ b/documentation/docs/frontend-copilot/core-concepts/code-generation-and-testing.md
@@ -0,0 +1,106 @@
+---
+sidebar_position: 9
+sidebar_label: Code Generation & Testing
+title: "Code Generation & Testing"
+description: "Learn how Bitloops generates React code from designs, validates output against snapshots, and helps you correct mismatches."
+keywords:
+  [
+    code generation,
+    design to code,
+    testing,
+    visual regression,
+    snapshots,
+    component preview,
+  ]
+---
+
+# Code Generation & Testing
+
+Bitloops doesn’t just generate code—it helps you **validate** that the generated component matches the design intent, and it surfaces mismatches so you can iterate quickly.
+
+The core loop is:
+
+**Design / Snapshot → Generate component → Compare → Fix (you + Bitloops)**
+
+## How code generation works (high level)
+
+When you create a component from a selection, Bitloops:
+
+1. **Analyzes the design selection**
+   - hierarchy and nesting
+   - layout relationships (rows/columns/groups)
+   - element types (text, image, container, UI elements)
+   - styling signals (spacing, typography, sizing)
+
+2. **Builds an internal representation**
+   - consistent structure for the component
+   - prop boundaries inferred from snapshots/instances
+   - variant/state signals inferred from snapshot differences
+   - layout rules and container decisions
+
+3. **Generates code into your project**
+   - React component code (`.tsx`)
+   - Tailwind CSS classes for styling and responsiveness
+   - supporting files (when applicable) for props/snapshots/stories
+
+## Snapshot-driven validation (design vs code)
+
+Snapshots aren’t just references—they’re also what Bitloops uses to validate correctness.
+
+When a snapshot is attached to a component, Bitloops can compare:
+
+- **Snapshot View** (design slice)
+- **Component View** (live render from code)
+
+This lets Bitloops detect issues such as:
+- spacing/alignment mismatches
+- incorrect grouping/hierarchy
+- missing/extra elements
+- incorrect handling of optional content or state
+- responsive inconsistencies (when viewport snapshots exist)
+
+The goal is pixel-accurate output when possible—but more importantly: **fast feedback when something is off.**
+
+## Where you see issues (Components tab)
+
+Bitloops surfaces validation signals in the **Components** tab:
+
+- a component can have multiple snapshots
+- each snapshot can be “passing” or “off”
+- when something doesn’t render correctly for a snapshot, Bitloops can flag it there
+
+This is especially useful when:
+- you add new snapshots later (instances or variants)
+- one snapshot matches, but another breaks due to structure or conditional logic
+- you refactor the component and want confidence you didn’t regress a state
+
+## Correcting mismatches (the copilot workflow)
+
+When Bitloops identifies a mismatch between snapshot and output, you have two paths:
+
+1. **Fix it manually** in the `.tsx` file (often fastest for small changes)
+2. **Ask Bitloops to correct** the implementation when the issue is structural or repetitive  
+   (e.g., grouping/layout containers, missing wrappers, variant-driven differences)
+
+This is where the “copilot” approach matters:
+- Bitloops does the heavy lifting of detection and suggestion
+- you decide the final structure and implementation
+
+## A note on data attributes (brief)
+
+Bitloops may include stable data attributes in generated output to support internal mapping and testing workflows. In general, treat them as tool-owned metadata and avoid editing them unless the docs explicitly tell you to.
+
+## Key takeaway
+
+**Bitloops combines generation with validation.** Snapshots are the design truth, Component View is the runtime truth, and Bitloops helps you close the gap—surfacing issues per snapshot and supporting rapid correction.
+
+## Related pages
+
+- [Snapshots](./snapshots.md) — Design-based component examples (instances and variants)
+- [Components & Reusability](./components-and-reusability.md) — Design-based component examples (instances and variants)
+- [Canvases](./canvases.md) — Where you explore and compare designs and code
+- [Guide: Component Testing](../Guides/component-testing.md) - Comparing Designs to Implementation
+
+---
+
+*Try Bitloops at [bitloops.com](https://bitloops.com) — generate the component, then let the snapshot call your bluff.*
\ No newline at end of file
diff --git a/documentation/docs/frontend-copilot/core-concepts/components-and-reusability.md b/documentation/docs/frontend-copilot/core-concepts/components-and-reusability.md
new file mode 100644
index 00000000..ea8aa923
--- /dev/null
+++ b/documentation/docs/frontend-copilot/core-concepts/components-and-reusability.md
@@ -0,0 +1,121 @@
+---
+sidebar_position: 2
+sidebar_label: Components & Reusability
+title: "Components & Reusability"
+description: "Learn how Components work in Bitloops and how they enable reusability across your codebase."
+keywords:
+  [
+    components,
+    reusability,
+    react components,
+    UI components,
+    code reuse,
+  ]
+---
+
+# Components & Reusability
+
+A **Component** in Bitloops is a reusable piece of UI that originates from your imported designs and becomes a real, production-ready React component in your codebase.
+
+Bitloops treats components as the main unit of work: you extract them from the design, attach snapshots to expand coverage, and then build upward by composing components into larger components and pages.
+
+## What makes a component in Bitloops
+
+When you create a component in Bitloops, you’re defining more than a visual block—you’re defining a **unit of reusable structure + data**.
+
+Bitloops will:
+
+1. Analyze the selected design elements
+2. Generate an initial code representation (`.tsx`)
+3. Create and/or suggest snapshots that represent how the component appears in real usage
+
+Once created, the component appears in the **Components** tab—this is where you manage the component and everything attached to it.
+
+## Snapshots are not only “variants”
+
+Snapshots are design-based examples of a component—and they’re useful even when nothing is “variant-like” is happening.
+
+Snapshots commonly represent two things:
+
+- **Instances (same structure, different data)**  
+  Example: a page shows 6 blog cards. Same component structure, but different title, image, tag, or description. Each card can be a snapshot. These snapshots help Bitloops infer **props** and a clean data model (what should be passed in vs hardcoded).
+
+- **Variants (same component, different state)**  
+  Example: `default`, `active`, `disabled`, `expanded`, `error`, etc. These snapshots help Bitloops model **variants** and, where needed, **conditional rendering**.
+
+In both cases, snapshots clarify what changes vs what stays consistent—so the component becomes reusable without becoming fragile.
+
+:::info
+Variant handling is currently under active development and not yet fully supported.
+:::
+
+## How snapshots attach to components (and why it matters)
+
+Components and snapshots are linked explicitly in Bitloops:
+
+- When a component is created, it’s added to the **Components** tab
+- Each time you attach a snapshot, it is added **under that specific component**
+- A single component can have **many snapshots**
+- Each snapshot contributes signal that Bitloops uses to improve:
+  - prop boundaries
+  - variants/state handling
+  - conditional rendering
+  - asset handling (static vs dynamic)
+  - structural consistency
+
+This is what allows Bitloops to turn “one design selection” into “a component you can use across the product.”
+
+## Validation and snapshot-level errors
+
+Bitloops uses snapshots as a reference for correctness.
+
+If a component renders a snapshot correctly compared to the snapshot design, you should see a clean state. If a snapshot doesn’t match (e.g., spacing is off, text is misaligned, a conditional element is missing), Bitloops can surface that as a snapshot-level issue in the **Components** tab.
+
+This makes it easier to iterate safely as you add more snapshots and expand coverage.
+
+## Nested components and composition
+
+Bitloops supports real composition:
+
+- A component can be used **inside another component**
+- When Bitloops generates or updates a parent component, it can replace repeated UI with **an instance of an existing component**
+- Snapshots help Bitloops pass the right data into nested components (e.g., the right props for each instance)
+
+This allows you to build the UI the way you would manually: start with primitives, then compose upward into sections and pages.
+
+## Design system components vs custom components
+
+Bitloops can distinguish between:
+- **UI elements / design system components** (buttons, checkboxes, accordions, inputs, etc.)
+- **Custom components** (product-specific cards, sections, layout patterns)
+
+As Bitloops evolves, this distinction becomes more important—because the tooling and best practices differ between:
+- foundational UI primitives (often backed by libraries like Radix/Base UI),
+- reusable product components,
+- and higher-level “page sections” or layout modules.
+
+## Seeing components in the design tree
+
+Once a component is created, Bitloops can reflect that decision back into the design representation:
+
+- Containers/elements that belong to a component can be replaced by a **component instance** in the design tree
+- This makes it obvious what is “already componentized” vs what is still raw design structure
+- It also helps guide the next extraction steps (what to componentize next, and where reuse already exists)
+
+## Key takeaway
+
+Components are your reusable units. Snapshots are your real examples. Reusability emerges when one component is proven across many snapshots—instances and variants alike.
+
+## Related concepts
+
+- [Variants](./variants.md) — Managing state-based differences
+- [Layout Containers](./layout-containers.md) — Manual structure control
+- [Creating Components](../Guides/creating-components.md) — Step-by-step component creation
+- [Attaching Snapshots](../Guides/attaching-snapshots.md) — Adding examples to improve props/variants
+- [Nested Components](../Guides/nested-components.md) — Building complex hierarchies
+- [Editing Components](../Guides/editing-components.md) — Modifying generated code
+- [The Essential Guide](../getting-started-new/essential-guide.md) — Create your first component
+
+---
+
+*Try Bitloops at [bitloops.com](https://bitloops.com) — extract components, attach snapshots, and build up to full pages fast.*
diff --git a/documentation/docs/frontend-copilot/core-concepts/design-system.md b/documentation/docs/frontend-copilot/core-concepts/design-system.md
new file mode 100644
index 00000000..1e72e3cf
--- /dev/null
+++ b/documentation/docs/frontend-copilot/core-concepts/design-system.md
@@ -0,0 +1,103 @@
+---
+sidebar_position: 5
+sidebar_label: Design System
+title: "Design System"
+description: "Learn how Bitloops builds a project-level design system from your imported designs to generate consistent, scalable UI code."
+keywords:
+  [
+    design system,
+    design tokens,
+    semantic tokens,
+    UI consistency,
+    component library,
+    scalable design,
+  ]
+---
+
+# Design System
+
+In Bitloops, the **Design System** is the shared set of styles, tokens, and UI patterns that keeps your generated code consistent across a project.
+
+The important difference vs traditional docs: **Bitloops builds the design system from the designs you add to a project.** The more representative your project’s design frames are, the stronger and more consistent the inferred system becomes.
+
+## Bitloops builds the design system from project designs
+
+Bitloops doesn’t assume you already have a perfect design system in Figma.
+
+Instead, it looks at the **frames you’ve added to the project** and learns the patterns that matter for implementation:
+
+- recurring typography styles
+- spacing rhythm and layout rules
+- color usage
+- repeated UI primitives (buttons, inputs, badges, etc.)
+- common variants and state patterns
+- consistent component boundaries across screens
+
+This project-level system becomes the baseline for generating components that “belong together” instead of looking like a pile of one-off exports.
+
+## Why adding more frames early matters
+
+Because the design system is inferred from your project’s design set, completeness matters:
+
+- Fewer frames → weaker signals → more one-off decisions
+- More relevant frames → stronger signals → better reuse, more consistent output, fewer refactors later
+
+If you add new frames later, you may discover better tokens or patterns that should have been used earlier—meaning you’ll want to revisit existing components.
+
+## Design tokens vs semantic tokens (both matter)
+
+A design system isn’t just raw values. Bitloops benefits from two layers:
+
+### Design tokens (raw values)
+These are the concrete values used in the UI:
+- colors (hex/RGB)
+- font sizes/weights/line-heights
+- spacing values
+- radii, borders, shadows
+
+Bitloops uses these to standardize output and reduce “random” styling.
+
+### Semantic tokens (meaningful intent)
+Semantic tokens describe *why* a value exists:
+- `text.primary`, `text.muted`
+- `surface.default`, `surface.elevated`
+- `border.subtle`, `border.strong`
+- `accent.brand`, `accent.danger`
+
+Bitloops treats semantic tokens as the long-term stabilizers of a codebase: when the brand color changes, you change the token mapping—not every component.
+
+## How the design system influences generation
+
+Once Bitloops has enough signal from your designs, it can generate code that is more consistent by default:
+
+- applying repeatable typography and spacing patterns
+- mapping values into Tailwind usage and configuration
+- recognizing and reusing design-system primitives instead of regenerating them
+- expressing state/variant patterns in a consistent way across components
+
+## What’s next (design system refactoring)
+
+Today, Bitloops builds the design system based on the designs you add to a project.
+
+In the future, the goal is to support **design system refactoring** as your project evolves:
+- add new designs → detect improved tokens/patterns
+- reconcile conflicts and inconsistencies
+- propose changes that reduce duplication across the codebase
+- help migrate existing components to the updated system
+
+This is especially important for teams whose UI evolves quickly: the design system shouldn’t be a one-time setup—it should be continuously improvable.
+
+## Key takeaway
+
+**In Bitloops, the design system isn’t a separate artifact—you grow it by adding real designs to your project.** The better your project’s design coverage, the better Bitloops can generate consistent, scalable UI code.
+
+## Related pages
+
+- [Designs](./designs.md) - the source of truth
+- [Components & Reusability](./components-and-reusability.md) — How Bitloops handles component creation
+- [Tailwind CSS](./tailwind-css.md) — Why Bitloops uses Tailwind
+- [Variants](./variants.md) — Managing state-based differences
+
+---
+
+*Try Bitloops at [bitloops.com](https://bitloops.com) — feed it real screens, and watch consistency emerge.*
diff --git a/documentation/docs/frontend-copilot/core-concepts/designs.md b/documentation/docs/frontend-copilot/core-concepts/designs.md
new file mode 100644
index 00000000..41c9b2ae
--- /dev/null
+++ b/documentation/docs/frontend-copilot/core-concepts/designs.md
@@ -0,0 +1,114 @@
+---
+sidebar_position: 1
+sidebar_label: Designs
+title: "Designs"
+description: "Understand how Designs work in Bitloops - the visual source of truth imported from Figma."
+keywords:
+  [
+    designs,
+    figma import,
+    design files,
+    source of truth,
+    visual design,
+  ]
+---
+
+# Designs
+
+A **Design** in Bitloops is the visual source of truth you import from Figma—the interface your team is implementing. Designs are the foundation for component creation, snapshots, prop inference, and design-to-implemented-code comparison.
+
+Bitloops treats designs as **high-fidelity, development-ready representation** sources of truth, translating figma files into artifacts ready for real engineering workflows.
+
+## Important: Bitloops does not import Figma “as-is”
+
+Bitloops does **not** mirror every Figma node one-to-one.
+
+Design tools contain a lot of information that’s useful for designers (layer organization, grouping habits, annotation layers, helper frames, naming noise, etc.) but doesn’t materially affect how the UI should be implemented in code.
+
+So when Bitloops imports a design, it:
+
+- **Keeps what impacts the UI** (structure, layout, text, assets, styles)
+- **Filters out superfluous design metadata**
+- Produces a **cleaner tree** that is easier to reason about as an engineer
+
+✅ This means the element tree you see in Bitloops may not match the exact tree you see in Figma—and that’s intentional.
+
+## How import works
+
+### 1) Import happens at the account library level
+
+Designs are imported into your **account library** first.
+
+- Imported designs live under **My Design Files**
+- They can be reused across multiple projects
+- This keeps design imports shareable and avoids re-importing the same file repeatedly
+
+### 2) Importing a Figma URL brings in the frames from that source
+
+When you import a Figma page through its URL into Bitloops, Bitloops imports the frames available from that source (e.g., the frames within that Figma page. it does not import all pages of that figma project).
+
+If you want your project to include designs spread across multiple Figma pages/files, you should import each relevant URL so those frames become available in your library.
+
+### 3) Projects use a subset of frames
+
+After importing into your library, you choose which frames to add to a specific Bitloops project:
+
+- In **My Design Files**, select the relevant figma page
+- Then, select the frame(s) you want to add to your project
+- Click **Add to Project** (note: multi frame selection in this canvas is not yet available)
+- Those frames are added to the project and become the working set you’ll turn into components and snapshots
+
+In other words:
+
+- **Library** = everything you’ve imported
+- **Project** = the frames you’ve chosen to implement right now
+
+:::note
+As we're in closed Alpha, you're unable to import your own designs without being whitelisted. [Join the waitlist](https://airtable.com/appuDrjEAoOhJTIls/shrSM0ZEsJBanusfa) as we do whitelist users regularly.
+:::
+
+## Why you should add all relevant frames early
+
+Bitloops uses the frames you add to a project to make better, more consistent decisions—especially around reuse and design-system inference.
+
+Adding more relevant frames early helps Bitloops:
+
+- Recognize repeated UI patterns and propose better component boundaries
+- Infer more accurate prop APIs from multiple real instances
+- Detect variants and state differences across screens
+- Build stronger design-system signals (tokens, typography, spacing patterns)
+
+If you only add a small subset of frames and later add more, you may end up revisiting earlier components to improve boundaries, tokens, and reuse. In general: **the more complete your project’s design set is up front, the less refactor work you’ll do later** just like if you were doing everything manually.
+
+## Designs as the source of truth (and validation)
+
+Designs are not just used to generate components—they’re also the reference Bitloops uses for comparison and validation.
+
+Bitloops aims for **pixel-accurate output**, and uses your imported design as the baseline to:
+
+- Compare design slices (snapshots) against rendered components
+- Highlight mismatches or structural issues
+- Detect cases where the *design itself* may be inconsistent or ambiguous
+
+This creates a tighter feedback loop between design intent and implementation.
+
+## Key points
+
+- Designs in Bitloops are **high-fidelity snapshots** of Figma at import time
+- Bitloops imports a **development-ready representation**, not a 1:1 Figma layer mirror
+- Designs are stored at the **account library** level, then frames are added to projects
+- Adding more relevant frames early improves reuse, tokens, and reduces refactor later
+- The design remains the **source of truth** for both generation and comparison
+
+## Related concepts
+
+- [Importing Designs](../Guides/importing-designs.md) — Step-by-step import process
+- [Snapshots](./snapshots.md) — Design-based component examples (instances and variants)
+- [Canvases](./canvases.md) — Where you explore and compare designs and code
+- [Design System](./design-system.md) — Tokens and patterns inferred from designs
+- [The Essential Guide](../getting-started-new/essential-guide.md) — Complete walkthrough
+- [How Bitloops Works](../introduction/how-bitloops-works.md) — The design-to-code transformation process
+
+---
+
+*Try Bitloops at [bitloops.com](https://bitloops.com) - turn designs into code, then let the design keep you honest.*
diff --git a/documentation/docs/frontend-copilot/core-concepts/layout-containers.md b/documentation/docs/frontend-copilot/core-concepts/layout-containers.md
new file mode 100644
index 00000000..95fabe84
--- /dev/null
+++ b/documentation/docs/frontend-copilot/core-concepts/layout-containers.md
@@ -0,0 +1,174 @@
+---
+sidebar_position: 7
+sidebar_label: Layout Containers
+title: "Layout Containers"
+description: "Understand Layout Containers in Bitloops - developer-controlled wrappers (divs) that shape hierarchy and layout in generated code."
+keywords:
+  [
+    layout containers,
+    divs,
+    grouping,
+    structure,
+    flex,
+    grid,
+  ]
+---
+
+# Layout Containers
+
+A **Layout Container** in Bitloops is essentially a **wrapper `div`** that you add intentionally to shape layout and hierarchy.
+
+Design tools often “group” layers for organization. Layout Containers go further: they represent a real structural decision that affects both:
+- the design tree you work with, and
+- the code Bitloops generates.
+
+They’re one of the most direct ways you (the developer) can communicate layout intent to Bitloops.
+
+## Why Layout Containers exist
+
+Real-world designs don’t always encode layout intent cleanly. Layers may be visually aligned, but not grouped in a way that translates to maintainable code.
+
+A Layout Container helps when you need to answer questions like:
+- “Is this a row or a column?”
+- “Which elements should move together on resize?”
+- “What should be spaced with a `gap` vs positioned independently?”
+- “What is the correct wrapper for this section?”
+
+There isn’t one universally correct answer—layout can be implemented in multiple valid ways. Layout Containers are where **you and Bitloops collaborate** to choose the best structure for your codebase.
+
+## What Layout Containers do
+
+### 1) They change the design hierarchy you work with
+
+When you create a Layout Container, Bitloops updates the design tree to reflect the new grouping. Elements that were previously siblings become children of a shared container.
+
+This makes the structure:
+- clearer to reason about
+- easier to componentize
+- easier to reuse and nest
+
+### 2) They change the generated code (on purpose)
+
+Each Layout Container becomes a wrapper element in code (typically a `<div>`). That wrapper is where layout rules live:
+
+- flex/grid direction
+- alignment and spacing (`gap-*`)
+- padding/margins and sizing constraints
+- responsive adjustments
+
+This is not decorative—it’s a direct mapping from “how this should be grouped” to “how this should be implemented.”
+
+## When you should add a layout container
+
+Use Layout Containers when:
+
+- the generated structure feels too flat or ambiguous
+- a group of elements should behave as a unit (move together, align together, wrap together)
+- spacing is easier to express with a `gap` on a wrapper
+- you want to enforce a specific row/column structure before generating a component
+- a snapshot/instance is hard to match because the layout hierarchy is missing a wrapper
+
+A good rule of thumb: **if you’d write a wrapper `div` manually, add a Layout Container.**
+
+## How layout containers appear in code
+
+A Layout Container usually introduces a wrapper with layout classes.
+
+```tsx
+// Without a Layout Container (flat structure)
+<>
+  <Image />
+  <Title />
+  <Description />
+  <Button />
+</>
+
+// With a Layout Container (explicit layout intent)
+<div className="flex flex-col gap-4">
+  <Image />
+  <Title />
+  <Description />
+  <Button />
+</div>
+```
+
+## Creating a layout container
+
+### Keyboard shortcut
+
+1. Select multiple elements (canvas or tree)
+2. Press `Cmd + G` (Mac) or `Ctrl + G` (Windows/Linux)
+
+### Context menu
+
+1. Select multiple elements
+2. Right-click → **Add Layout Container**
+
+---
+
+## Customizing a layout container
+
+After creating a Layout Container, you can adjust the wrapper to match intent:
+
+- **Layout:** `flex-row` / `flex-col` / grid patterns  
+- **Alignment:** `justify-*`, `items-*`  
+- **Spacing:** `gap-*`  
+- **Sizing:** width/height constraints  
+- **Padding/Margins:** `p-*`, `m-*`  
+- **Responsive behavior:** breakpoint-specific adjustments  
+
+This is often where the “copilot” workflow is most visible:
+
+- Bitloops proposes structure
+- You add/adjust containers to express intent
+- The generated code becomes dramatically cleaner and easier to maintain
+
+---
+
+## Nesting layout containers (real-world layout)
+
+Complex UIs often require nested wrappers.
+
+You can build nested containers progressively:
+
+1. Group the innermost related elements
+2. Add a container
+3. Select that container + adjacent elements
+4. Group again
+
+This mirrors how you’d build layout wrappers by hand in React.
+
+---
+
+## Best practices
+
+- **Group by behavior, not just proximity**  
+  If items should move together on resize, they belong together.
+
+- **Prefer fewer, meaningful wrappers**  
+  Avoid deep nesting unless it buys you clarity or layout correctness.
+
+- **Add containers early when a design is messy**  
+  It improves component boundaries and snapshot matching.
+
+- **Use containers to make snapshots match**  
+  If a snapshot doesn’t align well, missing hierarchy is often the cause.
+
+---
+
+## Key takeaway
+
+Layout Containers are intentional wrapper `div`s. They let you and Bitloops agree on layout structure before (and during) code generation—so your output is easier to reuse, easier to reason about, and easier to keep consistent across snapshots and viewports.
+
+---
+
+## Related pages
+
+- [Canvases](./canvases.md) — Where you explore and compare designs and code
+- [Components & Reusability](./components-and-reusability.md) — Component architecture patterns
+- [Tailwind CSS](./tailwind-css.md) — Why Bitloops uses Tailwind
+- [Guide: Adding Layout Containers](../Guides/adding-layout-containers.md) - Manual layout restructuring
+
+---
+
+*Try Bitloops at [bitloops.com](https://bitloops.com) — when layout gets tricky, containers make the intent explicit.*
\ No newline at end of file
diff --git a/documentation/docs/frontend-copilot/core-concepts/snapshots.md b/documentation/docs/frontend-copilot/core-concepts/snapshots.md
new file mode 100644
index 00000000..f3cd7160
--- /dev/null
+++ b/documentation/docs/frontend-copilot/core-concepts/snapshots.md
@@ -0,0 +1,124 @@
+---
+sidebar_position: 3
+sidebar_label: Snapshots
+title: "Snapshots"
+description: "Understand Snapshots in Bitloops - design-based examples that power props, variants, and reusable component code."
+keywords:
+  [
+    snapshots,
+    component states,
+    storybook stories,
+    design states,
+    variants,
+    instances,
+  ]
+---
+
+# Snapshots
+
+A **Snapshot** in Bitloops is a **design-based example** of a component—captured from your imported design and used as a reference while you build.
+
+Snapshots do two jobs at once:
+
+1. They show the *exact* design slice you’re implementing (for comparison and validation).
+2. They provide concrete examples that help Bitloops infer a reusable component API (props, state-driven differences, and conditional rendering).
+
+## Snapshots vs instances (the mental model)
+
+It helps to separate two related ideas:
+
+- **Snapshot** → an example attached to a component during construction.  
+  It’s “this component, as seen in this design, with this content/state.”
+
+- **Instance** → a usage of a component inside another component or page.  
+  When you build parent components, Bitloops uses the component **as an instance** and passes the right props.
+
+In practice:
+
+- You attach **snapshots** to *define* a component.
+- You create **instances** when you *use* that component elsewhere.
+
+You can think of snapshots as the “source examples” that later become real instances in your UI. A snapshot may also include viewport context (e.g. mobile/tablet/desktop), so Bitloops can learn responsive intent.
+
+## What a snapshot represents
+
+Snapshots usually vary along one or more of these axes:
+
+### 1) Instances (same component, different content)
+
+Example: a page shows 6 blog cards. The component structure is the same, but each card has different text, images, tags, or metadata.
+
+Those are still valuable snapshots because they help Bitloops infer:
+- **Props** (what should be passed in vs hardcoded)
+- **Optional fields** (what appears only sometimes)
+- **Data shape** (what the component expects)
+
+### 2) Variants (same component, different state)
+
+Example: `default`, `active`, `disabled`, `expanded`, `error`, etc.
+
+These snapshots help Bitloops infer:
+- **Variant/state handling**
+- **Conditional rendering**
+- **Behavior-related differences** expressed in design (what changes visually across states)
+
+### 3) Viewports (same component, different breakpoint context)
+
+Example: the same component at mobile vs desktop, where layout, density, or element visibility changes due to responsive rules.
+These snapshots help Bitloops infer: 
+
+- **Responsive layout changes**
+- **Conditional visibility and density**
+- **Breakpoint-driven styling and behavior**
+
+:::note
+Viewport snapshots are not a separate category from instances or variants—you can have “the same content” at multiple viewports, or “the same variant” across viewports. Viewport is the context in which the snapshot is captured.
+:::
+
+## Why snapshots exist
+
+Snapshots act as **ground truth** for design-to-code accuracy.
+
+When you open a snapshot, Bitloops isolates the relevant slice of the design so you can compare it directly against the live component output—without bouncing between tools.
+
+That makes snapshots useful for:
+- building faster (less ambiguity)
+- iterating safely (changes are testable against real examples)
+- catching mismatches early (structure, spacing, missing elements)
+
+## What a snapshot contains
+
+A snapshot includes:
+
+- A specific set of design elements (the slice)
+- Concrete content (text, images, labels, etc.)
+- Context for how the component is expected to render (instance data, state and/or viewport/breakpoint context)
+
+## How snapshots shape your component code
+
+A single Bitloops component is backed by **one `.tsx` file**, and snapshots provide the evidence that shapes it.
+
+As you attach more snapshots, Bitloops can refine:
+- component structure (what is consistent across examples)
+- prop boundaries (what changes across examples)
+- variants/state handling (what changes across states)
+- conditional rendering (what appears/disappears)
+- asset handling (what should be static vs dynamic)
+
+More snapshots = better coverage = a component that is reusable in more real scenarios.
+
+## Key takeaway
+
+**Snapshots are the examples that define a component. Instances are how that component gets used elsewhere.**  
+Attach snapshots to teach Bitloops what changes and what stays consistent—then reuse the resulting component as instances across your UI.
+
+## Related pages
+
+- [Components & Reusability](./components-and-reusability.md) — Component architecture patterns
+- [Variants](./variants.md) — Managing state-based differences
+- [Canvases](./canvases.md) — Where you explore and compare designs and code
+- [Guide: Attaching Snapshots](../Guides/attaching-snapshots.md) — Adding examples to improve props/variants
+
+---
+
+*Give [Bitloops](https://bitloops.com) a try — snapshots in, reusable components out.*
diff --git a/documentation/docs/frontend-copilot/core-concepts/tailwind-css.md b/documentation/docs/frontend-copilot/core-concepts/tailwind-css.md
new file mode 100644
index 00000000..aa7abec3
--- /dev/null
+++ b/documentation/docs/frontend-copilot/core-concepts/tailwind-css.md
@@ -0,0 +1,118 @@
+---
+sidebar_position: 8
+sidebar_label: Tailwind CSS
+title: "Tailwind CSS - Why We Chose It"
+description: "Learn why Bitloops generates Tailwind CSS today, how it maps design intent to code, and what to expect next."
+keywords:
+  [
+    tailwind css,
+    styling,
+    utility-first css,
+    design to code,
+    css framework,
+  ]
+---
+
+# Tailwind CSS (Why We Chose It)
+
+Bitloops generates production-ready React components—and the styling layer needs to be **fast, consistent, scalable, and predictable**. Today, Bitloops outputs **Tailwind CSS** because it gives us the cleanest, most deterministic mapping from design decisions to code.
+
+We plan to support additional styling approaches in the future, but Tailwind is the best current foundation for reliable design-to-code output.
+
+## Why Tailwind works well for Bitloops
+
+### 1) Deterministic design → code mapping
+
+Tailwind’s utility classes map directly to the kinds of decisions designers make:
+
+- spacing and layout
+- typography
+- color
+- alignment
+- sizing
+
+That lets Bitloops translate design intent into code with high fidelity—without “CSS guessing,” fragile overrides, or global leakage.
+
+### 2) Minimal styling boilerplate
+
+Tailwind keeps styling colocated with structure:
+
+- no separate CSS files required
+- no naming conventions to invent
+- fewer cascade surprises
+- less dead or duplicate styling
+
+For generated code, that’s a big deal: the output is easier to read, review, and modify.
+
+### 3) Consistency at scale
+
+Tailwind supports the patterns Bitloops needs for real apps:
+
+- token-driven theming via configuration
+- responsive breakpoints
+- state/variant styling patterns
+- composition-friendly conventions
+
+This aligns well with Bitloops’ goal: generate components that feel like they belong to the same system, not one-off exports.
+
+## How Bitloops uses Tailwind
+
+### Mapping design values to Tailwind classes
+
+Here are examples of the kinds of mappings Bitloops produces:
+
+| Design intent | Tailwind example |
+|-------------|------------------|
+| Font size ~16px | `text-base` |
+| Padding ~8px | `p-2` |
+| Gap ~16px | `gap-4` |
+| Flex column layout | `flex flex-col` |
+
+> Exact classes depend on your Tailwind config and the detected design-system patterns in your project.
+
+### Responsive output (when you provide viewport snapshots)
+
+If you attach viewport-specific snapshots (e.g., mobile + desktop), Bitloops can infer responsive rules and emit breakpoint-based classes:
+
+```tsx
+<div className="flex flex-col md:flex-row md:gap-6">
+  {/* content */}
+</div>
+```
+
+## Variant/state styling
+
+When snapshots represent meaningful state differences (variants), Bitloops can express those differences as conditional classes:
+
+```tsx
+<div className={isActive ? "bg-neutral-900 text-white" : "bg-white text-neutral-900"}>
+  {/* content */}
+</div>
+```
+
+## Looking forward
+
+Tailwind is the primary styling engine today. As Bitloops expands output formats, we plan to support additional styling approaches (and broader framework ecosystems).
+
+For now, Tailwind gives us the strongest combination of:
+
+- predictable generation
+- readable output
+- scalable consistency across a real codebase
+
+## If you want to brush up on Tailwind
+
+- Tailwind docs: https://tailwindcss.com/docs
+- Responsive design: https://tailwindcss.com/docs/responsive-design
+- Hover/focus/other states: https://tailwindcss.com/docs/hover-focus-and-other-states
+
+## Related pages
+
+- [Design System](./design-system.md) — Tokens and patterns inferred from designs
+- [Layout Containers](./layout-containers.md) — Manual structure control
+- [Variants](./variants.md) — Managing state-based differences
+- [Code Output Overview](../getting-started-new/code-output-overview.md) - Example of code generated by Bitloops
+
+---
+
+*Try Bitloops at bitloops.com — Tailwind makes “design intent” show up in code like it actually meant to.*
\ No newline at end of file
diff --git a/documentation/docs/frontend-copilot/core-concepts/variants.md b/documentation/docs/frontend-copilot/core-concepts/variants.md
new file mode 100644
index 00000000..c13f32ea
--- /dev/null
+++ b/documentation/docs/frontend-copilot/core-concepts/variants.md
@@ -0,0 +1,96 @@
+---
+sidebar_position: 4
+sidebar_label: Variants
+title: "Variants"
+description: "Learn about Variants in Bitloops - meaningful state, style, or viewport differences captured through snapshots and expressed in one reusable component."
+keywords:
+  [
+    variants,
+    component states,
+    visual states,
+    behavioral states,
+    design variants,
+    viewport variants,
+  ]
+---
+
+# Variants
+
+**Variants** are meaningful differences in how the *same component* renders—based on state, styling, content configuration, or viewport.
+
+In Bitloops, variants are discovered through **snapshots**. You attach snapshots to a component, and Bitloops uses the differences between them to infer what should be:
+- a prop,
+- a conditional branch,
+- a styling change,
+- or a responsive rule.
+
+## Variants vs instances
+
+It’s useful to separate two ideas:
+
+- **Instances**: the component is the same, but the data changes (e.g., 6 blog cards with different titles/images).  
+  This typically becomes **props**.
+
+- **Variants**: the component changes in a meaningful way (e.g., different state, styling, layout, or behavior).  
+  This typically becomes **variant/state logic** or conditional rendering inside the component.
+
+Both are captured as snapshots—but they lead to different outcomes in the final component API.
+
+## What a variant represents
+
+A variant usually shows up as one (or more) of the following:
+
+- **State differences** (e.g., selected vs unselected, expanded vs collapsed)
+- **Style differences** (e.g., emphasis, color, “with star” vs “without star”)
+- **Structural differences** (e.g., “with badge” vs “no badge”, optional sections)
+- **Viewport differences** (e.g., mobile vs desktop layouts for the same component)
+
+## Viewport variants (responsive snapshots)
+
+Variants can also be viewport-driven.
+
+If you have a mobile design for the same component, you can attach that as a snapshot. Bitloops will then try to infer the best way to make the component render correctly at that viewport—often by introducing responsive Tailwind classes and/or media-query-driven behavior.
+
+The goal is not to duplicate components for each breakpoint, but to support multiple viewports inside **one reusable component**.
+
+## How variants show up in code
+
+Variants are expressed inside **one component file** (`.tsx`) rather than duplicating components.
+
+As snapshots are attached, Bitloops can infer:
+
+- **Props** (what changes between snapshots)
+- **Variant keys** (the “mode” or “state” being represented)
+- **Conditional rendering** (what appears/disappears in certain states)
+- **Conditional styling** (class changes based on props/state)
+- **Responsive rules** (when viewport snapshots are provided)
+
+This keeps the result:
+- maintainable (one component)
+- reusable (prop/variant driven)
+- consistent with design intent (snapshots as reference)
+
+## Examples of variants (what you’ll actually see)
+
+- **Interaction/state**: default, selected, expanded, error
+- **Style**: with icon vs without icon, with star vs without star, emphasis levels
+- **Structure**: with badge vs no badge, with description vs no description
+- **Viewport**: desktop layout vs mobile layout for the same component
+
+## Current status
+
+:::info
+Full “first-class variants” (explicit variant tooling and richer automatic detection) is evolving.  
+Today, you can still achieve variant behavior by attaching multiple snapshots to the same component—Bitloops uses the differences to guide props, conditions, and responsiveness.
+:::
+
+## Related pages
+
+- [Snapshots](./snapshots.md) — Design-based component examples (instances and variants)
+- [Components & Reusability](./components-and-reusability.md) — Component architecture patterns
+- [Tailwind CSS](./tailwind-css.md) — Why Bitloops uses Tailwind
+- [Guide: Attaching Snapshots](../Guides/attaching-snapshots.md) - How to attach a snapshot to a component
+
+---
+
+*Try Bitloops at [bitloops.com](https://bitloops.com) — attach a few snapshots, and watch one component learn new states.*
diff --git a/documentation/docs/frontend-copilot/documentation-review-feedback.md b/documentation/docs/frontend-copilot/documentation-review-feedback.md
new file mode 100644
index 00000000..da8b767b
--- /dev/null
+++ b/documentation/docs/frontend-copilot/documentation-review-feedback.md
@@ -0,0 +1,459 @@
+# Documentation Review: Best Practices & UI Systems Performance
+
+**Review Date:** January 2026
+**Scope:** All documents in `best-practices/` (9 files) and `ui-systems-performance/` (11 files)
+**Objective:** Identify improvements to appeal to frontend engineers seeking tools for high-quality frontends, and optimize for SEO
+
+---
+
+## Executive Summary
+
+Both documentation series are strong technically. The writing is opinionated, well-structured, and genuinely useful for frontend engineers. The UI Systems Performance series is particularly distinctive — there is very little content like it on the web, which represents a significant SEO opportunity. However, several structural, SEO, and positioning improvements would increase discoverability, engagement, and conversion.
+
+The three highest-impact areas for improvement are:
+
+1. **SEO metadata needs to be more competitive** — titles, descriptions, and keywords are currently too generic to compete for search traffic
+2. **The two series lack structural consistency with each other** — the UI Systems Performance series has a strong, repeatable template; Best Practices does not
+3. **Bitloops positioning is uneven** — Best Practices has dedicated "How this connects to Bitloops" sections; UI Systems Performance does not (it only has bottom-of-page CTAs)
+
+---
+
+## 1. SEO Improvements
+
+### 1.1 Title Tags Are Too Generic
+
+Current titles read like chapter headings, not searchable content. Frontend engineers don't search for "Accessibility" — they search for "React accessibility best practices" or "how to make React components accessible."
+
+**Current examples:**
+- `"Accessibility"` — competes with millions of results
+- `"Network Protocols"` — too broad, doesn't signal frontend relevance
+- `"Responsive Behavior"` — generic, could be about anything
+
+**Recommended pattern:** `[Specific Topic] for Frontend Developers | Bitloops`
+
+**Suggested title rewrites:**
+
+| Document | Current Title | Suggested Title |
+|----------|--------------|-----------------|
+| accessibility.md | "Accessibility" | "Accessible React Components: Semantic HTML, ARIA, and Keyboard Patterns" |
+| responsive-behavior.md | "Responsive Behavior" | "Responsive Design Systems: Fluid Typography, Breakpoint Strategy, and Image Adaptation" |
+| network-protocols.md | "Network Protocols" | "HTTP for Frontend Developers: Methods, Caching Headers, CORS, and Failure Handling" |
+| security-boundaries.md | "Security Boundaries" | "Frontend Security Architecture: XSS, CSRF, CSP, and Token Storage" |
+| observability.md | "Observability" | "Frontend Observability: RUM, Error Tracking, Distributed Tracing, and SLOs" |
+| human-perception.md | "Human Perception" | "Perceived Performance: Loading States, Optimistic UI, and Perception Budgets" |
+| state-management-at-scale.md | "State Management at Scale" | "State Management as Replication Design: Sources of Truth, Sync, and Conflict Resolution" |
+| caching-strategies.md | "Caching Strategies" | "Frontend Caching: Browser Cache Stack, Invalidation, and Security Boundaries" |
+| testing-and-storybook.md | "Testing and Storybook Contracts" | "Storybook as a Contract Layer: Fixtures, Visual Testing, and Executable Specifications" |
+| component-api-design.md | "Component API Design" | "React Component API Design: Props as Contracts, Variants, and Stable Interfaces" |
+
+### 1.2 Meta Descriptions Need CTAs and Specificity
+
+Descriptions should be 150-160 characters, include a primary keyword, and end with a reason to click.
+
+**Current (weak):**
+> "HTTP as a contract - understanding methods, status codes, caching headers, CORS, and designing robust API requests."
+
+**Suggested:**
+> "HTTP methods, status codes, caching headers, and CORS explained for frontend developers. Learn to design reliable, cacheable API interactions."
+
+**Current (weak):**
+> "The capstone - understanding how technical metrics translate to perceived performance and user experience."
+
+**Suggested:**
+> "Why a 3-second load can feel faster than 2 seconds. Perception budgets, phase-based delivery, optimistic UI, and the psychology of wait time."
+
+Apply this pattern across all documents: lead with specifics, include the target keyword, hint at the value.
+
+### 1.3 Keywords Are Too Short-Tail
+
+Current keyword lists use single terms (`security`, `accessibility`, `caching`) that are impossible to rank for. Frontend engineers search with intent-rich queries.
+
+**Recommended approach:** Replace generic terms with long-tail, intent-driven phrases.
+
+| Current Keyword | Suggested Long-Tail Alternatives |
+|----------------|----------------------------------|
+| `security` | `frontend security best practices`, `spa security architecture`, `xss prevention react` |
+| `accessibility` | `react accessibility patterns`, `semantic html components`, `keyboard navigation react` |
+| `caching` | `frontend caching strategy`, `browser cache invalidation`, `stale-while-revalidate pattern` |
+| `http` | `http methods frontend`, `fetch api error handling`, `cors explained` |
+| `storybook` | `storybook testing contracts`, `visual regression testing storybook`, `storybook fixture factories` |
+| `responsive design` | `responsive design system`, `fluid typography clamp`, `mobile-first tailwind` |
+
+### 1.4 Missing FAQ / Structured Data Opportunities
+
+Google increasingly surfaces FAQ-style content in featured snippets. Neither series has any question-and-answer formatted sections that could be pulled into search results.
+
+**Recommendation:** Add a short FAQ section (3-5 questions) to the highest-traffic-potential documents. Candidates:
+
+- **accessibility.md** — "When should I use ARIA vs semantic HTML?", "What's the difference between aria-label and aria-labelledby?"
+- **network-protocols.md** — "What's the difference between no-cache and no-store?", "When does CORS preflight happen?"
+- **security-boundaries.md** — "Where should I store JWT tokens in a React SPA?", "What's the difference between XSS and CSRF?"
+- **responsive-behavior.md** — "When should I use clamp() for typography?", "How many breakpoints do I need?"
+
+These questions should be H3 headings under a `## Frequently Asked Questions` section before the Summary, formatted so structured data parsers can extract them.
+
+### 1.5 Internal Cross-Linking Is Weak Between Series
+
+The UI Systems Performance documents cross-reference each other extensively (e.g., "See *Caching Strategies*"), but rarely link to Best Practices, and vice versa. This is a missed opportunity for:
+- SEO link equity distribution
+- User journey extension (longer session time)
+- Demonstrating the breadth of the documentation
+
+**Specific recommendations:**
+- **accessibility.md** should link to **human-perception.md** (perception of trustworthiness)
+- **testing-and-storybook.md** should link to **observability.md** (visual regression as observability)
+- **component-api-design.md** should link to **state-management-at-scale.md** (props as state contracts)
+- **data-contracts.md** should link to **caching-strategies.md** (cache invalidation depends on data contracts)
+- **responsive-behavior.md** should link to **performance-optimization.md** (responsive images and performance)
+- **design-system-consumption.md** should link to **distributed-systems.md** (CDN delivery of design system assets)
+
+The cross-references in UI Systems Performance (e.g., italic references like *See Caching Strategies*) should be converted to actual Docusaurus links where they aren't already.
+
+### 1.6 URL Structure
+
+The current URL structure (`/design-2-code/best-practices/accessibility`) is clean and good. However, the parent path `design-2-code` is product-oriented rather than topic-oriented. Frontend engineers searching for accessibility or caching patterns won't associate their query with "design-2-code."
+
+**Consider:** Whether `frontend-engineering` or `frontend-guides` as a parent path would perform better for organic search. This is a trade-off between brand positioning and discoverability. If the primary goal is SEO-driven traffic, a topic-oriented path wins. If the primary goal is product-associated content, the current path is fine.
+
+---
+
+## 2. Content Quality and Appeal
+
+### 2.1 Best Practices Needs a Consistent Template
+
+The UI Systems Performance series follows a strong, repeatable structure:
+- Introduction with "What makes frontend unique"
+- Core content sections
+- Trade-offs
+- Patterns
+- Anti-patterns
+- Real-world scenarios
+- Design review checklist
+- Red flags
+- Key takeaways
+- How this connects to Bitloops (inconsistent — see Section 3)
+- Further reading
+
+The Best Practices series does not have a consistent template. Each document has different sections in different orders:
+- Some have "Common Patterns" sections, some don't
+- None have "Red flags" sections
+- None have "Anti-patterns" as a dedicated section (though some mention anti-patterns inline)
+- None have "Design review checklist" sections
+- None have "Real-world scenarios" sections
+- The Summary tables exist in all but have different column headers
+
+**Recommendation:** Adopt a lighter version of the UI Systems template for Best Practices. At minimum, add to each Best Practices document:
+
+1. **Anti-patterns section** — Frontend engineers love "what NOT to do" content. It validates their frustrations and signals expert knowledge.
+2. **Red flags section** — Short, quotable one-liners that engineers can reference in code reviews. These are highly shareable and link-worthy.
+3. **Design review checklist** — Actionable checklists are the most bookmarked content on engineering blogs. These create return visits.
+
+### 2.2 Missing "Quick Reference" or TL;DR
+
+Both series are long. Individual documents range from 400 to 800+ lines. Engineers often scan documentation rather than reading linearly.
+
+**Recommendation:** Add a "Quick reference" or "At a glance" box at the top of each document (after the H1 and intro paragraph) with 3-5 bullet points summarizing the key takeaways. This:
+- Helps skimmers decide whether to read deeply
+- Provides immediate value for return visitors
+- Creates an easily sharable summary
+- Improves time-on-page (users who get immediate value are more likely to scroll)
+
+### 2.3 Code Examples Are Framework-Agnostic (Mostly Good, But Could Be Better)
+
+The code examples use React and vanilla JS, which is the right default. However, some documents miss opportunities to reference widely-used ecosystem tools that engineers are actively searching for:
+
+| Document | Missing Reference Opportunity |
+|----------|-------------------------------|
+| state-management-at-scale.md | TanStack Query, Zustand, Jotai — these are what engineers actually search for |
+| caching-strategies.md | SWR, TanStack Query `staleTime`/`gcTime` — practical cache config |
+| asynchronous-operations.md | React Suspense, `use()` hook, server components — modern patterns |
+| testing-and-storybook.md | Chromatic, Playwright component testing — tools engineers evaluate |
+| accessibility.md | Radix UI, React Aria, shadcn/ui — accessible component libraries |
+| observability.md | Sentry, Datadog RUM, PostHog — tools engineers actually use |
+
+This doesn't mean the documents should become tool-specific. But mentioning these tools in context (e.g., "Libraries like TanStack Query implement this stale-while-revalidate pattern out of the box") signals relevance and captures search traffic for tool-related queries.
+
+### 2.4 Real-World Scenarios Could Be Stronger in Best Practices
+
+The UI Systems Performance series has excellent "Real-world scenario" sections (e.g., "dashboard with mixed update patterns," "collaborative document editor," "e-commerce cart and checkout"). These ground abstract concepts in concrete situations.
+
+Best Practices has no equivalent. Adding 1-2 real-world scenarios per document would significantly increase practical value:
+
+- **component-creation-workflows.md** — "Scenario: Refactoring a product listing page from monolithic to component-based"
+- **component-api-design.md** — "Scenario: Designing a DataTable component API that serves 5 different views"
+- **data-contracts.md** — "Scenario: CMS schema change that breaks 12 components"
+- **accessibility.md** — "Scenario: Retrofitting accessibility into an existing modal system"
+- **testing-and-storybook.md** — "Scenario: Using stories to catch a regression before production"
+
+### 2.5 Tone Is Occasionally Too Academic
+
+Some passages read more like textbook content than practitioner guidance. Frontend engineers respond to direct, opinionated content that acknowledges real-world constraints.
+
+**Examples of overly academic phrasing:**
+- "This document covers accessibility as architecture: the structural decisions that produce accessible components" — could be "Here's how to build components that are accessible by default, without retrofitting"
+- "This document covers responsive design as strategy" — could be "Most responsive design is ad-hoc breakpoint tweaking. Here's how to think about it as a system."
+- "This document covers the consumption side: the rules for using design systems correctly" — could be "Design systems break when developers bypass them. Here's how to prevent that."
+
+The UI Systems Performance series does this better — the opening lines are punchy and opinionated ("The browser is hostile territory," "You can't improve what you can't measure"). Best Practices should match this energy.
+
+### 2.6 Document Length Considerations
+
+Several documents exceed 600 lines:
+
+| Document | Line Count | Assessment |
+|----------|-----------|------------|
+| asynchronous-operations.md | ~831 | Could split "operation scopes" into standalone |
+| caching-strategies.md | ~662 | Acceptable — topic demands depth |
+| network-protocols.md | ~767 | Could split "streaming and real-time" into standalone |
+| performance-optimization.md | ~700 | Acceptable — comprehensive |
+| consistency-and-failure-handling.md | ~643 | Acceptable |
+| security-boundaries.md | ~755 | Could split "authentication flows" into standalone |
+
+Long documents aren't inherently bad for SEO (they can rank well for multiple queries), but they reduce completion rate. If analytics show high bounce rates on these pages, consider splitting the longest ones into focused sub-pages with a parent hub page.
+
+---
+
+## 3. Bitloops Positioning
+
+### 3.1 UI Systems Performance Series Lacks "How This Connects to Bitloops" Sections
+
+The Best Practices series has a dedicated "How this connects to Bitloops" section before the Summary in every document. The UI Systems Performance series does not — it only has a one-line CTA at the very bottom of each page (after Further Reading).
+
+This inconsistency means:
+- Users who read only UI Systems Performance get minimal Bitloops context
+- The connection between systems design knowledge and a design-to-code tool is unclear
+- The CTA at the bottom is too disconnected from the content to feel natural
+
+**Recommendation:** Add "How this connects to Bitloops" sections to all 10 UI Systems Performance documents (excluding the introduction, which already has an "About this series" mention). The positioning challenge is different here — the UI Systems Performance content is about understanding systems, not about component-level generation. The sections should explain how Bitloops-generated code embodies the systems thinking described in each document.
+
+**Example angles:**
+
+| Document | Connection to Bitloops |
+|----------|----------------------|
+| state-management-at-scale.md | Bitloops generates components with clear data flow — props for server state, hooks for local state — so the source-of-truth hierarchy is encoded in the component structure |
+| caching-strategies.md | Bitloops produces components that separate data fetching from presentation, making it straightforward to add caching layers without refactoring component internals |
+| performance-optimization.md | Bitloops generates code that follows performance best practices by default — code-split-ready components, proper image handling, minimal bundle impact |
+| security-boundaries.md | Bitloops outputs semantic HTML and proper form patterns that align with security best practices — no `dangerouslySetInnerHTML`, proper input handling |
+| human-perception.md | Bitloops generates loading states, skeleton screens, and phased delivery patterns so perceived performance is designed in from the start |
+
+### 3.2 Best Practices Bitloops Sections Are Somewhat Generic
+
+The current Bitloops sections in Best Practices follow a pattern:
+1. Acknowledge the difficulty of the practice
+2. State that Bitloops generates code that follows the practice
+3. Link to bitloops.com
+
+This works but could be more specific. Engineers are skeptical of "our tool does everything right" claims. More specific claims build more credibility.
+
+**Current (generic):**
+> "Bitloops generates components with accessibility built in: buttons are `<button>` elements (not styled `<div>`s), images include `alt` attributes, form inputs are associated with labels..."
+
+**More specific and credible:**
+> "When Bitloops converts a design with a clickable element, it generates a `<button>` — not a `<div>` with an `onClick`. When a design includes an image, the output includes a placeholder `alt` attribute that flags for review. Form fields are generated with associated `<label>` elements and `htmlFor` bindings. These aren't post-processing fixes — they're structural defaults in the generation pipeline."
+
+The difference is specificity about *how* the tool works, not just *what* it produces. Engineers trust mechanism descriptions more than outcome claims.
+
+### 3.3 The Introduction CTAs Have Different Tones
+
+- Best Practices intro: "Use the documents below as the decision framework; use Bitloops as the workflow that makes the framework repeatable."
+- UI Systems intro: "While many tools (including most AI-assisted ones) focus on accelerating code output, very few attempt to encode these system-level concerns..."
+
+The UI Systems intro is more measured and credible. The Best Practices intro is more direct. Both approaches work, but the contrast is noticeable if a user reads both. Consider aligning the tone.
+
+### 3.4 Bottom CTAs Are Inconsistent
+
+The one-liner CTAs at the bottom of each document vary in quality:
+
+**Strong:**
+- "Never lose a user's work — build offline-ready, failure-resilient frontends with Bitloops."
+- "The best performance optimization is the one your users feel."
+
+**Weak / Generic:**
+- "Build accessible frontends from the start. Start building with Bitloops."
+- "Consume design systems consistently. Start building with Bitloops."
+- "Build responsive UIs that adapt fluidly. Start building with Bitloops."
+
+The weak ones follow a "[Repeat document topic]. Start building with Bitloops." formula that feels templated. The strong ones connect Bitloops to a specific value proposition.
+
+**Recommendation:** Rewrite the generic CTAs to connect the document's core insight to Bitloops's value:
+- accessibility.md: "Accessibility starts with structure, not audits. Generate accessible components from your designs with Bitloops."
+- design-system-consumption.md: "The fastest way to stay on-system is to start on-system. Generate token-compliant code from designs with Bitloops."
+- responsive-behavior.md: "Translate design intent into fluid, adaptive code without manual breakpoint wrangling. Start building with Bitloops."
+
+---
+
+## 4. Structural Issues
+
+### 4.1 Typo in component-creation-workflows.md
+
+The Summary table at approximately line 352 contains `"graduate_toggle"` — this appears to be a corruption of the intended text. It should likely read "Start local, graduate to shared" or similar.
+
+### 4.2 Cross-References in UI Systems Performance Use Italics Instead of Links
+
+The UI Systems Performance documents reference each other frequently using italic text (e.g., "*See Caching Strategies*" or "*Security Boundaries* covers..."). Many of these are not hyperlinked. In a Docusaurus site, these should be actual `[link text](./file.md)` references.
+
+**Count of likely unlinked cross-references:**
+- state-management-at-scale.md: ~4 italic cross-references
+- caching-strategies.md: ~5
+- asynchronous-operations.md: ~6
+- performance-optimization.md: ~5
+- distributed-systems.md: ~4
+- network-protocols.md: ~6
+- security-boundaries.md: ~5
+- consistency-and-failure-handling.md: ~7
+- observability.md: ~6
+- human-perception.md: ~9 (references all previous documents)
+
+That is roughly 57 cross-references that should be hyperlinks. This is both an SEO issue (internal linking) and a UX issue (users can't navigate to referenced content).
+
+### 4.3 Summary Tables Have Inconsistent Column Headers
+
+Best Practices Summary tables use `| Principle | Application |` columns. This is consistent across the series. Good.
+
+UI Systems Performance uses `Key takeaways` as bullet points, not tables. This is also consistent within the series. Good.
+
+However, the two formats are quite different, which is fine since they're separate series. No action needed unless you want visual consistency across both.
+
+### 4.4 Further Reading Sections
+
+Best Practices and UI Systems Performance both have Further Reading sections. These are well-done, with 4-6 references each that include descriptions. Two observations:
+
+1. **All references are external.** None link to other documents in the two series. Adding 1-2 internal cross-links (e.g., "For the systems design perspective on this topic, see State Management at Scale") would strengthen the internal linking structure.
+
+2. **Some links may break over time.** Consider adding archived/stable versions of URLs where possible, or using the `title` attribute for context if a link dies. (This is a minor concern.)
+
+---
+
+## 5. Content Gaps
+
+### 5.1 Missing Topics That Frontend Engineers Search For
+
+Based on common search patterns for frontend engineering content, the following topics are not covered and represent expansion opportunities:
+
+**High Priority (directly related to existing content):**
+
+| Topic | Why It Matters | Which Series |
+|-------|---------------|-------------|
+| Forms and validation patterns | One of the most-searched frontend topics; connects to data contracts, accessibility, and component API design | Best Practices |
+| Error boundaries and error handling UI | Currently scattered across multiple documents; deserves consolidated treatment | Best Practices |
+| Server components and streaming SSR | Modern React architecture that changes many assumptions in the existing docs | UI Systems Performance |
+
+**Medium Priority (extends content positioning):**
+
+| Topic | Why It Matters | Which Series |
+|-------|---------------|-------------|
+| Internationalization (i18n) | Significant concern for production apps; affects component APIs and data contracts | Best Practices |
+| Animation and transitions | Briefly covered in human-perception.md but deserves dedicated treatment as a Best Practice | Best Practices |
+| Build and bundle optimization | Engineers search for this constantly; connects to performance-optimization.md | UI Systems Performance |
+| API design patterns (REST, GraphQL, tRPC) | Would extend network-protocols.md with practical frontend-specific patterns | UI Systems Performance |
+
+### 5.2 Missing "Getting Started" Content
+
+Neither series has a "what should I read first?" guide based on the reader's situation. A routing page that says:
+
+- "Building a component library? Start with Component Creation Workflows, then Component API Design"
+- "Debugging performance issues? Start with Performance Optimization, then Human Perception"
+- "Setting up a new project? Start with Codebase Conventions, then Design System Consumption"
+
+This would improve user journeys and reduce bounce rates from readers who land on the wrong document for their needs.
+
+---
+
+## 6. Engagement and Conversion Opportunities
+
+### 6.1 No Interactive Elements
+
+The documentation is entirely static text and code blocks. Consider adding:
+
+- **Comparison tables that help engineers choose** — e.g., "Token storage decision matrix" in security-boundaries.md is close but could be more interactive
+- **Code playgrounds** — Embedding StackBlitz or CodeSandbox examples for key patterns
+- **Downloadable checklists** — The "Design review checklist" sections could be offered as downloadable PDFs (email capture opportunity)
+
+### 6.2 No Social Proof or Community Signals
+
+The documentation doesn't reference:
+- How many developers use Bitloops
+- Any testimonials or case studies
+- GitHub stars or community size
+- Companies using the approach
+
+Even one line like "Used by teams building design systems at [logos]" on the introduction pages would increase credibility.
+
+### 6.3 No Newsletter or Follow-Up Mechanism
+
+There's no way for a reader who finds this content valuable to subscribe for updates. Consider:
+- An email capture for "Get notified when we publish new engineering guides"
+- A link to a Discord or community for discussing these patterns
+- RSS feed for the documentation section
+
+---
+
+## 7. Priority Recommendations
+
+### Immediate (Low Effort, High Impact)
+
+1. **Fix the typo** in component-creation-workflows.md Summary table ("graduate_toggle")
+2. **Convert italic cross-references to actual links** in UI Systems Performance (57+ instances)
+3. **Rewrite the 3-4 weakest bottom CTAs** to be specific rather than templated
+4. **Add long-tail keywords** to all frontmatter keyword arrays
+
+### Short-Term (Medium Effort, High Impact)
+
+5. **Rewrite title tags** for all 20 documents to be searchable and specific
+6. **Improve meta descriptions** to include specifics and implicit CTAs
+7. **Add "How this connects to Bitloops" sections** to all 10 UI Systems Performance documents
+8. **Add internal cross-links** between the two series (5-10 per document)
+
+### Medium-Term (Higher Effort, High Impact)
+
+9. **Add anti-patterns, red flags, and checklists** to all Best Practices documents
+10. **Add FAQ sections** to the 4-5 highest-traffic-potential documents
+11. **Add real-world scenario sections** to all Best Practices documents
+12. **Add "At a glance" summary boxes** to the top of each document
+13. **Mention popular ecosystem tools** where relevant (TanStack Query, Sentry, Radix, etc.)
+
+### Long-Term (Higher Effort, Strategic)
+
+14. **Create new documents** for forms/validation, error handling UI, and server components
+15. **Create a "Getting Started" routing guide** based on reader situation
+16. **Add interactive elements** (code playgrounds, downloadable checklists)
+17. **Split the longest documents** if analytics show high bounce rates
+18. **Consider a topic-oriented URL path** if SEO traffic is the primary goal
+
+---
+
+## Appendix: Document-by-Document Notes
+
+### Best Practices Series
+
+| Document | Strengths | Improvements |
+|----------|-----------|-------------|
+| introduction.md | Clear series framing, good document index table | Could benefit from reader routing ("start here if you're...") |
+| component-creation-workflows.md | Strong decision framework for when to extract components | Typo in Summary table; needs anti-patterns and red flags sections |
+| component-api-design.md | Excellent treatment of props as contracts; boolean explosion section is highly shareable | Could reference React 19 patterns; needs real-world scenario |
+| data-contracts.md | Unique angle on ownership boundaries; mapping layer concept well explained | Could mention Zod, tRPC, or GraphQL codegen as concrete tools |
+| design-system-consumption.md | "Forbidden list" section is excellent; escape hatches with friction is a great pattern | Bitloops section could be more specific about token mapping |
+| responsive-behavior.md | Fluid vs. stepped framework is clear and practical | Could reference container queries (CSS `@container`); thin on practical examples |
+| accessibility.md | Structure-first approach is the right framing; keyboard navigation examples are strong | Missing screen reader testing guidance; no mention of automated testing tools (axe, Lighthouse a11y) |
+| codebase-conventions.md | Connecting conventions to failure modes is compelling | Could benefit from examples of conventions gone wrong |
+| testing-and-storybook.md | "Stories as contracts" framing is distinctive and search-worthy | Could mention Chromatic, Playwright, and Testing Library more concretely |
+
+### UI Systems Performance Series
+
+| Document | Strengths | Improvements |
+|----------|-----------|-------------|
+| introduction.md | "Backend optimizes for correctness, frontend for correctness under perception" is a killer thesis | Bitloops mention is too cautious — could be more confident |
+| state-management-at-scale.md | "State as replication" reframing is genuinely novel | Could mention TanStack Query, Zustand patterns; missing Bitloops section |
+| caching-strategies.md | Browser cache stack visualization is excellent; security implications of caching is rare content | Very long; IndexedDB section could be expanded; missing Bitloops section |
+| asynchronous-operations.md | Commit guard pattern is unique and valuable; cancellation handling is thorough | Longest document — could split operation scopes; missing Bitloops section |
+| performance-optimization.md | Core Web Vitals treatment is practical, not just definitional | Could reference React Server Components impact on performance; missing Bitloops section |
+| distributed-systems.md | Edge computing decision framework is excellent | Could mention Vercel, Cloudflare Workers, Deno Deploy as concrete platforms; missing Bitloops section |
+| network-protocols.md | HTTP semantics table is highly referenceable; circuit breaker implementation is practical | WebSocket section could be expanded; missing Bitloops section |
+| security-boundaries.md | "Blast radius design" framing is distinctive; token storage comparison is one of the best I've seen | Could mention OWASP headers scanner; missing Bitloops section |
+| consistency-and-failure-handling.md | Intent preservation pattern is the standout; failure taxonomy table is excellent | Real-world scenarios are strong but could link to specific code patterns; missing Bitloops section |
+| observability.md | Control system framing is novel; burn-rate alerting is practical and rare in frontend content | Could mention Sentry, Datadog RUM by name; missing Bitloops section |
+| human-perception.md | Perception budgets concept is the best content in either series; phase-based delivery model is unique | Could be more prescriptive about specific framework implementations; missing Bitloops section |
+
+---
+
+*End of review.*
diff --git a/documentation/docs/frontend-copilot/faq-troubleshooting/code-licensing.md b/documentation/docs/frontend-copilot/faq-troubleshooting/code-licensing.md
new file mode 100644
index 00000000..5caaed7b
--- /dev/null
+++ b/documentation/docs/frontend-copilot/faq-troubleshooting/code-licensing.md
@@ -0,0 +1,102 @@
+---
+sidebar_position: 3
+sidebar_label: Code Licensing
+title: "Code Licensing & Ownership"
+description: "Understand your rights to the code generated by Bitloops."
+keywords:
+  [
+    code licensing,
+    code ownership,
+    generated code,
+    intellectual property,
+    licensing,
+  ]
+---
+
+# Code Licensing & Ownership
+
+One of the most important questions when using any code generation tool is: **"Who owns the code?"**
+
+With Bitloops, the answer is simple: **You do.**
+
+## Full Ownership
+
+All code generated by Bitloops is **100% yours**. You have complete ownership and can:
+
+- Use it in personal projects
+- Use it in commercial projects
+- Modify it however you want
+- Redistribute it as part of your applications
+- Keep it private or make it open source
+
+## No Lock-In
+
+Bitloops generates **standard React + Tailwind CSS code**. There are:
+
+- No proprietary dependencies
+- No required runtime libraries
+- No mandatory Bitloops imports
+- No license restrictions on usage
+
+The code works independently of Bitloops once generated. You can stop using Bitloops at any time and continue working with your generated code.
+
+## What This Means for You
+
+### For Individual Developers
+- Use generated code in freelance projects
+- Build your portfolio with Bitloops-generated components
+- Learn from the code patterns and best practices
+
+### For Teams & Companies
+- Use in production applications
+- Include in proprietary software
+- No attribution required
+- No royalty payments
+
+### For Open Source Projects
+- Generated code can be included in open source projects
+- Compatible with any open source license
+- No special considerations needed
+
+## Your Designs
+
+Similarly, Bitloops **never claims ownership** of your designs:
+
+- Your Figma files remain yours
+- Imported designs are only read, never modified
+- We don't store or redistribute your designs
+- You can delete imported designs at any time
+
+## Data Privacy
+
+For information about how we handle your data, please see our:
+
+- [Privacy Policy](https://bitloops.com/privacy)
+- [Terms of Service](https://bitloops.com/terms)
+
+## Summary
+
+| Aspect | Status |
+|--------|--------|
+| Code ownership | **You own 100%** |
+| Commercial use | **Allowed** |
+| Modification rights | **Unlimited** |
+| Attribution required | **No** |
+| Lock-in | **None** |
+| Proprietary dependencies | **None** |
+
+**The code Bitloops generates is yours to use however you see fit.**
+
+---
+
+## Related Resources
+
+- [What is Bitloops?](../introduction/what-is-bitloops.md) — Product overview
+- [The Essential Guide](../getting-started-new/essential-guide.md) — Complete walkthrough
+- [Code Output Overview](../getting-started-new/code-output-overview.md) — Generated code structure
+- [Why Bitloops?](../introduction/why-bitloops.md) — Benefits of using Bitloops
+- [Who Should Use Bitloops?](../introduction/who-should-use-bitloops.md) — Is Bitloops right for you?
+
+---
+
+*Own your code with [Bitloops](https://bitloops.com) — no lock-in, no restrictions.*
diff --git a/documentation/docs/frontend-copilot/faq-troubleshooting/common-challenges.md b/documentation/docs/frontend-copilot/faq-troubleshooting/common-challenges.md
new file mode 100644
index 00000000..8e0b19e3
--- /dev/null
+++ b/documentation/docs/frontend-copilot/faq-troubleshooting/common-challenges.md
@@ -0,0 +1,202 @@
+---
+sidebar_position: 2
+sidebar_label: Common Challenges
+title: "Common Challenges"
+description: "Solutions to common issues you might encounter when using Bitloops."
+keywords:
+  [
+    troubleshooting,
+    common issues,
+    problems,
+    solutions,
+    help,
+  ]
+---
+
+# Common Challenges
+
+Bitloops is designed to streamline your design-to-code workflow, but even the best tools encounter occasional challenges. This guide covers common issues and their solutions.
+
+:::tip Need More Help?
+If your issue persists or isn't listed here, we **highly recommend** reaching out:
+- Email us at [support@bitloops.com](mailto:support@bitloops.com) with a video of the issue
+- Join our [Discord server](https://discord.com/invite/vj8EdZx8gK)
+
+**We'll send you an Amazon voucher as thanks for helping us improve!**
+:::
+
+---
+
+## Import Issues
+
+### Design won't import from Figma
+
+**Possible causes:**
+- The Figma file link is incorrect or inaccessible
+- Your Figma account doesn't have access to the file
+- Network connectivity issues
+
+**Solutions:**
+1. Verify the Figma link is correct and the file is accessible
+2. Make sure you're logged into Figma with the correct account
+3. Re-authenticate your Figma connection in Bitloops
+4. Check your internet connection
+
+### Some frames are missing after import
+
+**Possible causes:**
+- Very complex or deeply nested frames
+- Frames with unsupported features
+
+**Solutions:**
+1. Try importing specific frames instead of the entire file
+2. Simplify complex nested structures in Figma
+3. Contact support if the issue persists
+
+---
+
+## Component Generation Issues
+
+### Component not generated
+
+**Possible causes:**
+- Fallback option did not work
+- An unsupported Figma feature was used (e.g., overly complex SVGs)
+- Selection includes incompatible elements
+
+**Solutions:**
+1. Delete the component and try again
+2. Try building a smaller component first
+3. Select consecutive elements that form a harmonious component
+
+### Elements not appearing in generated code
+
+**Possible causes:**
+- Elements may be hidden or have zero dimensions in Figma
+- Complex layer structures
+
+**Solutions:**
+1. Check that all elements are visible in Figma
+2. Verify elements have proper dimensions
+3. Use the layer tree to ensure all elements are selected
+
+---
+
+## Layout Issues
+
+### Layout doesn't match the design
+
+**Possible causes:**
+- Missing layout containers
+- Incorrect flex/grid settings
+
+**Solutions:**
+1. Add layout containers to group related elements
+2. Adjust flex direction and alignment settings
+3. Check spacing and gap values
+
+### Elements overlapping incorrectly
+
+**Possible causes:**
+- Absolute positioning in the original design
+- Missing structural grouping
+
+**Solutions:**
+1. Create layout containers to establish proper structure
+2. Review the design hierarchy in Figma
+3. Use the sidebar tree to verify element ordering
+
+---
+
+## Testing & Preview Issues
+
+### Unresponsive tests or errors in Storybook
+
+**Possible causes:**
+- Code-generation process was interrupted
+- CSS/Responsiveness decisions were not optimal for the circumstance
+
+**Solutions:**
+1. Try deleting and re-creating the component
+2. Manually edit the code to your preference
+3. Email us your specific needs for assistance
+
+### Component preview not updating
+
+**Possible causes:**
+- File not saved
+- Syntax error in the code
+
+**Solutions:**
+1. Save the file (`Ctrl+S` / `Cmd+S`)
+2. Check for syntax errors in your IDE
+3. Verify the component file path is correct
+
+---
+
+## Images & Assets
+
+### Images not exporting correctly
+
+**Possible causes:**
+- Image format not supported
+- Very large image files
+- Complex vector graphics
+
+**Solutions:**
+1. Ensure images are in supported formats (PNG, JPG, SVG)
+2. Optimize large images before importing
+3. For complex vectors, try flattening them in Figma
+
+### Icons appearing as broken images
+
+**Possible causes:**
+- SVG complexity
+- Missing vector data
+
+**Solutions:**
+1. Simplify complex SVGs in Figma
+2. Outline strokes in Figma before importing
+3. Use the "Flatten" option in Figma for complex icons
+
+---
+
+## Performance Issues
+
+### Bitloops running slowly
+
+**Possible causes:**
+- Very large Figma files
+- Many components in the project
+- System resources
+
+**Solutions:**
+1. Import only the frames you need
+2. Close unnecessary applications
+3. Break large designs into smaller imports
+
+---
+
+## We're Here to Help!
+
+If you encounter persistent issues:
+
+📧 **Email:** [support@bitloops.com](mailto:support@bitloops.com) — Include a video showing the issue
+
+💬 **Discord:** [Join our community](https://discord.com/invite/vj8EdZx8gK)
+
+---
+
+## Related Resources
+
+- [FAQs](./faqs.md) — Common questions answered
+- [Tips & Tricks](./tips-and-tricks.md) — Pro tips to avoid issues
+- [Submit a Bug](../community-support/submit-bug.md) — Report issues and get credits
+- [Importing Designs](../Guides/importing-designs.md) — Fix import issues
+- [Creating Components](../Guides/creating-components.md) — Fix component generation issues
+- [Adding Layout Containers](../Guides/adding-layout-containers.md) — Fix layout issues
+- [Editing Components](../Guides/editing-components.md) — Fix code issues
+
+---
+
+*Need more help? Contact us at [bitloops.com](https://bitloops.com).*
diff --git a/documentation/docs/frontend-copilot/faq-troubleshooting/faqs.md b/documentation/docs/frontend-copilot/faq-troubleshooting/faqs.md
new file mode 100644
index 00000000..fc0e2a2c
--- /dev/null
+++ b/documentation/docs/frontend-copilot/faq-troubleshooting/faqs.md
@@ -0,0 +1,138 @@
+---
+sidebar_position: 1
+sidebar_label: FAQs
+title: "Frequently Asked Questions"
+description: "Answers to the most common questions about Bitloops Frontend Copilot."
+keywords:
+  [
+    faqs,
+    frequently asked questions,
+    bitloops questions,
+    common questions,
+  ]
+---
+
+# Frequently Asked Questions
+
+Answers to the most common questions about Bitloops.
+
+---
+
+## General
+
+### What is Bitloops?
+
+Bitloops is an AI-powered frontend copilot that transforms Figma designs into production-ready React code. It generates clean, reusable components with Tailwind CSS styling, complete with test IDs and optional Storybook integration.
+
+### Is Bitloops free to use?
+
+Bitloops offers both free and paid tiers. Check our [pricing page](https://bitloops.com/pricing) for the latest information on plans and features.
+
+### What frameworks does Bitloops support?
+
+Currently, Bitloops generates **React (JSX)** components with **Tailwind CSS**. Support for additional frameworks (Vue, Angular, Svelte) is on our roadmap.
+
+### Do I need to know React to use Bitloops?
+
+While Bitloops generates React code, you can still benefit from the tool even if you're learning React. The generated code follows best practices and is well-structured, making it a good learning resource.
+
+---
+
+## Design & Import
+
+### What design tools does Bitloops support?
+
+Currently, Bitloops supports **Figma**. Support for Adobe XD, Sketch, and other design tools is planned for future releases.
+
+### Does Bitloops modify my original Figma files?
+
+No, Bitloops only reads your Figma files. It never modifies or overwrites your original designs.
+
+### Do I need a perfectly structured Figma file?
+
+No! Bitloops is designed to work with real-world, messy designs. While well-structured files may produce cleaner output, Bitloops can handle imperfect inputs.
+
+### How do I update my design after making changes in Figma?
+
+Bitloops does not auto-sync with Figma. To get updated designs, delete the imported file from Bitloops and re-import it.
+
+---
+
+## Components & Code
+
+### What happens to my code when I edit it?
+
+Your edits are preserved. Bitloops won't overwrite your changes unless you explicitly choose to regenerate a component.
+
+### Can I customize the generated code?
+
+Absolutely! The generated code is fully yours to modify. You can rename components, restructure files, add logic, and integrate with your existing codebase.
+
+### What are snapshots?
+
+Snapshots are design-based representations of component states. They're like Storybook stories, automatically generated from your Figma designs. See [Core Concepts: Snapshots](../core-concepts/snapshots.md) for details.
+
+### Can I create nested components?
+
+Yes! You can compose smaller components into larger ones. Bitloops automatically handles imports and references. See [Guides: Nested Components](../Guides/nested-components.md).
+
+---
+
+## Technical
+
+### What are data IDs and why shouldn't I change them?
+
+Data IDs are stable identifiers that Bitloops assigns to every element. They're used for:
+- Linking designs to code
+- Testing (Cypress selectors)
+- Snapshot reconciliation
+
+Modifying them breaks Bitloops' internal tracking. See [Core Concepts: Code Generation & Testing](../core-concepts/code-generation-and-testing.md).
+
+### Does Bitloops work offline?
+
+Bitloops requires an internet connection to import designs and generate code. However, once code is generated, you can work with it offline.
+
+### Can I use Bitloops with my existing project?
+
+Yes! Bitloops generates components directly into your project folder. The generated code integrates seamlessly with existing React + Tailwind projects.
+
+---
+
+## Support
+
+### How do I report a bug?
+
+See our [Submit a Bug or Request](../community-support/submit-bug.md) page. We offer credits for verified bug reports!
+
+### Where can I get help?
+
+- Join our [Discord community](https://discord.gg/vj8EdZx8gK)
+- Email us at [support@bitloops.com](mailto:support@bitloops.com)
+- Check our [documentation](../introduction/what-is-bitloops.md)
+
+---
+
+## Still Have Questions?
+
+If your question isn't answered here, reach out to us:
+
+- [Discord Community](https://discord.gg/vj8EdZx8gK)
+- [Contact Support](../community-support/contact-us.md)
+
+---
+
+## Related Resources
+
+- [The Essential Guide](../getting-started-new/essential-guide.md) — Complete beginner walkthrough
+- [Quick Start](../getting-started-new/quick-start.md) — Fast reference guide
+- [What is Bitloops?](../introduction/what-is-bitloops.md) — Product overview
+- [Common Challenges](./common-challenges.md) — Solutions to common issues
+- [Tips & Tricks](./tips-and-tricks.md) — Pro tips for better workflow
+- [Code Licensing](./code-licensing.md) — Understand your code ownership
+- [Video Tutorials](../tutorials/learn-by-watching.md) — Watch Bitloops in action
+- [Core Concepts](../core-concepts/snapshots.md) — Deep dive into key concepts
+
+---
+
+*Get started with [Bitloops](https://bitloops.com) — your AI-powered frontend copilot.*
diff --git a/documentation/docs/frontend-copilot/faq-troubleshooting/tips-and-tricks.md b/documentation/docs/frontend-copilot/faq-troubleshooting/tips-and-tricks.md
new file mode 100644
index 00000000..2b603b1e
--- /dev/null
+++ b/documentation/docs/frontend-copilot/faq-troubleshooting/tips-and-tricks.md
@@ -0,0 +1,180 @@
+---
+sidebar_position: 4
+sidebar_label: Tips & Tricks
+title: "Tips & Tricks"
+description: "Pro tips to get the most out of Bitloops and speed up your workflow."
+keywords:
+  [
+    tips,
+    tricks,
+    best practices,
+    workflow optimization,
+    productivity,
+  ]
+---
+
+# Tips & Tricks
+
+Get the most out of Bitloops with these productivity tips and best practices.
+
+---
+
+## Keyboard Shortcuts
+
+### Quick Component Creation
+Use `Cmd+C` / `Ctrl+C` to quickly create a component. Just select the elements you want and press the shortcut — Bitloops will prompt you to name the component and generate everything instantly.
+
+### Quick Snapshot Attachment
+Use `Cmd+A` / `Ctrl+A` to attach a snapshot to a component. Make sure the correct base component is visible in Component Preview before using this shortcut.
+
+### Recursive Grouping
+Use `Cmd+G` / `Ctrl+G` repeatedly to build layout hierarchy quickly. Start with the innermost elements, group them, then group those groups — this mimics how you'd build nested layout containers with divs in code.
+
+---
+
+## Selection Tips
+
+### Use the Sidebar Tree for Precision
+Figma designs can be tricky to click on, especially with overlapping layers. The sidebar tree in Snapshot View gives you pixel-perfect control over what's selected and grouped.
+
+### Multi-Select on Canvas
+Hold `Ctrl` (Windows) or `Cmd` (Mac) while clicking to select multiple elements. You can also click and drag to create a selection box.
+
+### Inspect Spacing
+Hold `ALT` while hovering over elements to see spacing information, just like in Figma.
+
+---
+
+## Component Strategy
+
+### Start with Atomic Components
+Creating small components like `Button`, `Badge`, or `Avatar` first allows you to reuse them across multiple sections. Then nest them into larger `Card`, `Hero`, or `Section` components for better structure and code reuse.
+
+### Attach Multiple Snapshots Early
+Even if you're not sure about variants yet, attaching multiple versions (e.g., mobile and desktop) upfront helps Bitloops generate more robust and responsive components from the start.
+
+### Build Bottom-Up for Design Systems
+If you're building a design system, start with the smallest atoms and work your way up:
+
+```
+Icons → Buttons → Form Fields → Cards → Sections → Pages
+```
+
+---
+
+## Code Editing Tips
+
+### Edit Freely — Bitloops Stays in Sync
+Don't be afraid to make manual changes. Just save your edits, and Bitloops will re-analyze the code, update previews, and re-run snapshot tests automatically.
+
+### Fix One, Fix Many
+When fixing layout issues, often correcting one problem in the base component resolves similar issues across all attached snapshots.
+
+### Use the Three-Panel View
+Keep Snapshot View, Component View, and your code editor visible simultaneously for the most efficient workflow.
+
+---
+
+## Naming Conventions
+
+### Name Components Meaningfully
+Component names don't affect Bitloops' behavior, but naming things clearly (e.g., `FeatureCard` instead of `Card1`) will make your component tree and file structure much easier to manage as your project scales.
+
+### Use Descriptive Prop Names
+When Bitloops infers props from your snapshots, meaningful names help future maintainability.
+
+---
+
+## Design Import Tips
+
+### Import Once, Use Everywhere
+You can import a Figma file once and add frames to multiple projects. No need to re-import for each project.
+
+### Re-Import for Updates
+Bitloops doesn't auto-sync with Figma. If your design changes, simply delete the imported file and re-import to get the latest version.
+
+### Import Selectively
+You don't need to import entire files. Import only the frames you need to keep your project focused and organized.
+
+---
+
+## Workflow Optimization
+
+### Create Component First, Then Attach All Snapshots
+The recommended workflow is:
+1. Create the component from the primary design
+2. Attach all relevant snapshots (variants, viewports, states)
+3. Fix any errors that exist
+4. Only then create nested components
+
+### Use Layout Containers Proactively
+Adding layout containers before generating code often produces better results than trying to fix layout issues afterward.
+
+### Keep Related Elements Grouped
+In Figma, keeping related elements logically grouped makes Bitloops' job easier and produces cleaner code.
+
+---
+
+## Common Patterns
+
+### Card Components
+```
+Layout Container (flex-col)
+  └── Image
+  └── Content Container (flex-col)
+      └── Title
+      └── Description
+      └── CTA Button
+```
+
+### Navigation Components
+```
+Layout Container (flex-row, justify-between)
+  └── Logo
+  └── Nav Links Container (flex-row, gap-4)
+  └── CTA Button
+```
+
+### Hero Sections
+```
+Layout Container (flex-col, items-center)
+  └── Headline
+  └── Subheadline
+  └── CTA Container (flex-row, gap-4)
+      └── Primary Button
+      └── Secondary Button
+```
+
+---
+
+## Pro Tips Summary
+
+| Tip | Benefit |
+|-----|---------|
+| Start atomic, compose up | Better reusability |
+| Attach snapshots early | Better variant handling |
+| Use keyboard shortcuts | Faster workflow |
+| Name meaningfully | Better maintainability |
+| Fix one, fix many | Efficient debugging |
+| Use layout containers | Cleaner code output |
+
+---
+
+## Need More Help?
+
+### Getting Started
+
+- [The Essential Guide](../getting-started-new/essential-guide.md) — Complete beginner walkthrough
+- [Quick Start](../getting-started-new/quick-start.md) — Fast reference guide
+- [Video Tutorials](../tutorials/learn-by-watching.md) — Watch Bitloops in action
+- [Importing Designs](../Guides/importing-designs.md) — Import workflow
+- [Creating Components](../Guides/creating-components.md) — Component creation
+- [Attaching Snapshots](../Guides/attaching-snapshots.md) — Managing states
+- [Adding Layout Containers](../Guides/adding-layout-containers.md) — Structuring elements
+- [Nested Components](../Guides/nested-components.md) — Complex hierarchies
+- [Discord](https://discord.gg/vj8EdZx8gK) — Get help from the community
+- [FAQs](./faqs.md) — Common questions answered
+
+---
+
+*Master your workflow with [Bitloops](https://bitloops.com).*
diff --git a/documentation/docs/frontend-copilot/getting-started-new/code-output-overview.md b/documentation/docs/frontend-copilot/getting-started-new/code-output-overview.md
new file mode 100644
index 00000000..bc6cc74f
--- /dev/null
+++ b/documentation/docs/frontend-copilot/getting-started-new/code-output-overview.md
@@ -0,0 +1,182 @@
+---
+sidebar_position: 3
+sidebar_label: Code Output Overview
+title: "Code Output Overview"
+description: "Understand how Bitloops generates code, the file structure, and coding conventions used in the output."
+keywords:
+  [
+    code generation,
+    output structure,
+    file structure,
+    react components,
+    tailwind css,
+    code conventions,
+  ]
+---
+
+# Code Output Overview
+
+This page explains the philosophy behind how code is generated by Bitloops, the structure and conventions used, and your options for customization.
+
+## Code Generation Philosophy
+
+Bitloops generates code with a few guiding principles:
+
+1. **Readability first** — The code should be easy to understand for any React developer
+2. **Editability** — You should be able to modify any part without breaking the whole system
+3. **Production-ready** — The output follows industry best practices and is ready for deployment
+4. **No lock-in** — The generated code is standard React + Tailwind; you own it completely
+
+## Output Structure
+
+When you create components in Bitloops, they are generated directly into your project folder with a clean, organized structure:
+
+```
+/components
+  /Button
+    index.tsx        # Main component file
+    styles.ts        # Extracted styles (if applicable)
+    test.spec.ts     # Test file with data-id selectors
+  /Card
+    index.tsx
+    props.ts         # Props type definitions
+    Snapshot.json    # Snapshot metadata
+  /ProductSection
+    index.tsx
+    /nested
+      FeatureItem.tsx
+/pages
+  Home.tsx
+/assets
+  /images
+  /icons
+```
+
+## File Conventions
+
+### Component Files (`.tsx`)
+
+- **Named exports** for better tree-shaking
+- **Props interfaces** defined at the top
+- **Tailwind classes** for styling
+- **Data attributes** for testing (`data-testid`)
+
+Example output:
+
+```tsx
+import React from 'react';
+
+interface ButtonProps {
+  label: string;
+  variant?: 'primary' | 'secondary';
+  onClick?: () => void;
+}
+
+export const Button: React.FC<ButtonProps> = ({
+  label,
+  variant = 'primary',
+  onClick
+}) => {
+  return (
+    <button
+      data-testid="button-component"
+      className={`px-4 py-2 rounded-lg font-medium ${
+        variant === 'primary'
+          ? 'bg-blue-600 text-white hover:bg-blue-700'
+          : 'bg-gray-200 text-gray-800 hover:bg-gray-300'
+      }`}
+      onClick={onClick}
+    >
+      {label}
+    </button>
+  );
+};
+```
+
+### Styling Approach
+
+Bitloops uses **Tailwind CSS** for all styling because:
+
+- Perfect mapping from design tokens to code
+- No separate CSS files to manage
+- Consistent, predictable output
+- Easy to modify and extend
+- Industry-standard adoption
+
+See [Core Concepts: Tailwind CSS](../core-concepts/tailwind-css.md) for more details on why we chose Tailwind.
+
+### Data Attributes
+
+Every element generated by Bitloops includes stable data attributes (data IDs). These serve multiple purposes:
+
+- **Testing** — Reliable selectors for Cypress, Playwright, or other testing tools
+- **Tracking** — Internal mapping between design and code
+- **Reconciliation** — Helps Bitloops understand your component when regenerating
+
+:::warning Important
+Do not modify or remove data IDs. They are essential for Bitloops' internal logic and testing infrastructure.
+:::
+
+## Customization Options
+
+Once code is generated, you have full control:
+
+### What You Can Modify
+
+- Rename components, props, and files
+- Restructure the folder organization
+- Add custom logic and state management
+- Integrate with your existing codebase
+- Add additional styling or override Tailwind classes
+
+### What You Should Preserve
+
+- **Data attributes** (`data-testid`, etc.) — Required for testing and Bitloops tracking
+- **Import structure** — If using nested components, maintain the import paths
+
+### Re-generation
+
+Bitloops won't overwrite your manual changes unless you explicitly choose to regenerate a component. This means:
+
+- Your edits are safe
+- You can continue attaching snapshots after editing
+- You can selectively regenerate specific components while keeping others
+
+## Integration with Your Stack
+
+The generated code is designed to work seamlessly with:
+
+- **Next.js** — The primary target framework
+- **React** — Standard JSX patterns
+- **Tailwind CSS** — Utility-first styling
+- **Storybook** — Optional story generation
+- **Cypress/Playwright** — Test-ready with data attributes
+- **TypeScript** — Full type safety
+
+## Next Steps
+
+### Understand Code Generation
+
+- [Code Generation & Data IDs](../core-concepts/code-generation-and-testing.md) — Deep dive into how code is generated
+- [Tailwind CSS](../core-concepts/tailwind-css.md) — Why Bitloops uses Tailwind
+- [Design Systems](../core-concepts/design-system.md) — Working with design tokens
+
+### Editing & Customization
+
+- [Editing Components](../Guides/editing-components.md) — How to modify generated code
+- [Nested Components](../Guides/nested-components.md) — Building complex component hierarchies
+- [Layout Containers](../core-concepts/layout-containers.md) — Understanding structural grouping
+
+### Related Resources
+
+- [The Essential Guide](./essential-guide.md) — Complete getting started walkthrough
+- [Quick Start](./quick-start.md) — Condensed reference guide
+- [Components & Reusability](../core-concepts/components-and-reusability.md) — Component architecture patterns
+
+### Advanced Reading
+
+- [Frontend Systems Design](../ui-systems-performance/introduction.md) — Technical deep-dives on frontend architecture
+
+---
+
+*Generate production-ready code with [Bitloops](https://bitloops.com) — transform designs into clean React components.*
diff --git a/documentation/docs/frontend-copilot/getting-started-new/essential-guide.md b/documentation/docs/frontend-copilot/getting-started-new/essential-guide.md
new file mode 100644
index 00000000..69490df4
--- /dev/null
+++ b/documentation/docs/frontend-copilot/getting-started-new/essential-guide.md
@@ -0,0 +1,246 @@
+---
+sidebar_position: 2
+sidebar_label: The Essential Guide
+title: "Getting Started - The Essential Guide"
+description: "Complete walkthrough of Bitloops: install the extension, open your first project, create a component, and understand snapshots."
+keywords:
+  [
+    bitloops tutorial,
+    getting started,
+    figma import,
+    create component,
+    snapshots,
+    VS Code extension,
+    first component,
+  ]
+---
+
+# Guide to working with Bitloops
+
+This guide walks you through your first Bitloops win: **open a project → create a component → generate code → attach snapshots**.
+
+You’ll learn the basics by doing, not reading.
+
+## Welcome & Overview
+
+Bitloops is your [AI-powered frontend copilot](https://bitloops.com)—built to turn messy designs into **clean, reusable, production-ready React + Tailwind CSS code**. No magic tricks. No throwaway prototypes. Just real components you can ship.
+
+Bitloops runs inside [**Visual Studio Code**](https://visualstudio.microsoft.com/) and **VS Code-based editors** (including popular forks like [**Cursor**](https://cursor.com/docs), [**Windsurf**](https://windsurf.com/) and [**Antigravity**](https://antigravity.google/)).
+
+### Start here: Watch a demo video
+
+Below is a short walkthrough of the exact flow you're about to follow (new video being developed).
+
+<!-- TODO: Add Embedded Demo Video Here -->
+
+:::tip
+Keep the video open as you go—it's much easier to follow along.
+:::
+
+---
+
+## Install & set up Bitloops
+
+Before we jump into generating components, let’s get Bitloops installed and signed in. You only need to do this once.
+
+### 1) Install the Bitloops extension
+
+Search for **"Bitloops"** in the **VS Code Marketplace** within VS Code and click Install or click on this link: [Bitloops VS Code Marketplace](https://marketplace.visualstudio.com/items?itemName=Bitloops.bitloops)
+
+✅ **Checkpoint:** You can see the Bitloops icon/panel in your editor sidebar.
+
+### 2) Sign In / Create Your Account
+
+Open the Bitloops panel and sign in using GitHub or Google.
+
+✅ **Checkpoint:** You’re signed in and can access Bitloops features from the sidebar. It now asks you to open a folder (if you're not in one), or to create a project. 
+
+### 3) Prerequisites
+
+Bitloops works out of the box. Recommended:
+
+- **VS Code (or a VS Code-based editor)**
+- **A Figma account** (only needed if/when you import your own designs - we provide you a Demo Design in your first project)
+
+---
+
+## Account Library vs Project
+
+Bitloops separates **design storage** from **your codebase**:
+
+- **Account library:** Design files live under **My Design Files** and can be reused across projects.
+- **Project:** Generated components, assets, and code live in **the folder you opened in your editor** (your repository).
+
+This keeps your code local and reviewable, while letting you reuse design imports across projects.
+
+---
+
+## Start a project (1st project comes with a Demo Design)
+
+### Name and create a project
+
+Open a folder in your editor (empty or existing):
+
+**Top Menu → File → Open Folder…**
+
+Now click on the Bitloops extension icon, give your project a name and click create. That folder becomes your current Bitloops project.
+
+✅ **Checkpoint:** Bitloops treats the open folder as the active project (project actions become available). You should see 2 sections on the left: Components and Designs as well as 3 canvasas: Designs View, Snapshot View and Component Preview
+
+### Your Demo Design is already ready
+
+To help you get your first win quickly, Bitloops starts you with a **pre-loaded demo design** already imported **and added to your first project**.
+
+That means you can immediately move on to creating a component — no Figma setup required or design import. 
+
+✅ **Checkpoint:** You can see a design/frame available in your project’s Design View.
+
+### Want to use your own designs?
+
+Bitloops works with any design, however, we are in closed Alpha. Do sign-up to our [waiting list](https://airtable.com/appuDrjEAoOhJTIls/shrSM0ZEsJBanusfa) if you want to gain early acces by providing some additional information. 
+
+---
+
+## Understanding the canvases
+
+Bitloops includes four canvases, each aligned with a different stage of work:
+
+| Canvas | Purpose |
+|--------|---------|
+| **Design View** | Inspect design structure and select elements to turn into components |
+| **Snapshot View** | Compare a component’s design slice (a specific state) |
+| **Component View** | Live preview rendered from your code |
+| **File Import Canvas** | Manage (import) design files in your account/ add designs to projects |
+
+You don’t need to memorize these right now—just know where you are:
+
+- **Design View** is where you create components and can see the design "data" (spacings, distances, etc. by selecting an element and pressing option or alt)
+- **Snapshot View** is where you see only that specific snapshot to compare against the implemented component where you're able to manually add layout containers 
+- **Component Preview** is where you view the rendered component
+
+For the full breakdown, see:  
+- [Core Concepts: Canvases](../core-concepts/canvases.md)
+
+---
+
+## Your first component
+
+Now that you have a design ready in your project, it’s time to create your first Bitloops component.
+
+### Step 1 — Open the design view
+
+Open the Design View (if its not automatically open) and select the design you want to work with.
+
+✅ **Checkpoint:** You can see:
+- the design preview on the right
+- the design element tree (open) on the left in the sidebar
+
+### Step 2 — Select the element(s)
+
+Select elements directly on the canvas (click, or drag-select like in Figma), or select an entire frame when available. To select multiple items, hold Ctrl (Windows/Linux) or Cmd (Mac) while clicking.
+
+✅ **Checkpoint:** Your target element(s) are highlighted/selected.
+
+### Step 3 — Create the component
+
+With elements selected:
+
+**Right-click → Create Component** (shortcu: Ctrl/CMD + C in the Bitloops canvas) and then give your component a name. 
+
+Bitloops will:
+
+- create a new component in your project
+- generate the initial `.tsx` file
+- create an associated snapshot representing the design slice for that component
+
+✅ **Checkpoint:** You can see the new component listed under **Components**, and it renders for the first time in **Component Preiew** (live preview).
+
+### Step 4 — View your component code
+
+Double-click the component under **Components**.
+
+Bitloops opens the **component's `.tsx` file** in the editor
+
+✅ **Checkpoint:** You can see Snapshot View + Component View and the component code file is open.
+
+:::tip
+Select an element in the snapshot view and press **ALT** to inspect spacing between elements.
+:::
+
+---
+
+## Snapshots (the only part you need right now)
+
+A snapshot is a **design-based example** of your component—captured from the imported design and used as a reference while you build.
+
+Snapshots can represent two common situations:
+
+- **Different instances (same component, different content)**  
+  Example: a page has 6 blog cards. The component is the same, but each card has different titles, images, or labels. Those are **multiple snapshots of the same component**. They help Bitloops understand what should become **props** (e.g., `title`, `image`, `tag`) while keeping the structure consistent.
+
+- **Variants (same component, different state)**  
+  Example: `default`, `hover`, `active`, `disabled`, or other state-driven designs. These snapshots help Bitloops model **variants** and, where needed, **conditional rendering**.
+
+### Why snapshots matter
+
+Snapshots help Bitloops infer:
+- **Props** — what changes across different instances (content, assets, optional fields)
+- **Variants** — different visual/state configurations of the same component
+- **Conditional rendering** — what appears or disappears across snapshots (e.g., “tag” exists only sometimes)
+
+### Attaching a snapshot
+
+Bitloops may suggest snapshots automatically. You can accept/reject them.
+
+To attach one manually:
+1. Select the design elements you want as a snapshot
+2. Right-click → **Attach Snapshot to [Component-name]** (Shortcut: if the component is selected, you can use Ctrl / CMD + A)
+
+✅ **Checkpoint:** The component now has an additional snapshot captured from the design.
+
+---
+
+## Editing the code
+
+- Edit the `.tsx` file normally
+- Press `Ctrl + S`
+- Bitloops updates the **Component View** immediately
+- Snapshot View stays fixed as your reference
+
+✅ **Checkpoint:** You can change code, save, and see the preview update instantly.
+
+---
+
+## Design syncing (not yet)
+
+Bitloops does **not** auto-sync changes from Figma after a design is imported.
+
+If your design changes, the simplest approach today is to:
+- import a second version of the design, **or**
+- start a new project and re-run the extraction flow
+
+---
+
+## What’s Next?
+
+### Go Deeper (When You’re Ready)
+
+- [Core Concepts: Canvases](../core-concepts/canvases.md)
+- [Core Concepts: Snapshots](../core-concepts/snapshots.md)
+
+### Continue Building
+
+- [Guide: Creating Components](../Guides/creating-components.md)
+- [Guide: Attaching Snapshots](../Guides/attaching-snapshots.md)
+- [Guide: Adding Layout Containers](../Guides/adding-layout-containers.md)
+- [Guide: Nested Components](../Guides/nested-components.md)
+
+### Get Help
+
+- [FAQs](../faq-troubleshooting/faqs.md)
+- [Common Challenges](../faq-troubleshooting/common-challenges.md)
+- [Join our Discord](../community-support/discord.md)
+
+---
+
+*Try [Bitloops](https://bitloops.com) to see the full workflow in action—design to editable React components in minutes.*
\ No newline at end of file
diff --git a/documentation/docs/frontend-copilot/getting-started-new/quick-start.md b/documentation/docs/frontend-copilot/getting-started-new/quick-start.md
new file mode 100644
index 00000000..200e0448
--- /dev/null
+++ b/documentation/docs/frontend-copilot/getting-started-new/quick-start.md
@@ -0,0 +1,91 @@
+---
+sidebar_position: 1
+sidebar_label: Quick Start
+title: "Quick Start"
+description: "The fastest way to get your first Bitloops component generated and editable."
+keywords:
+  [
+    bitloops quick start,
+    fast tutorial,
+    quick reference,
+    getting started fast,
+    cheat sheet,
+  ]
+---
+
+# Quick Start
+
+Fast path for experienced users. Goal: **create a component → open the preview + code → iterate.**
+
+:::info
+Want the full walkthrough? See [Getting Started - The Essential Guide](./essential-guide.md).
+:::
+
+## 1) Install & sign in
+
+- Install Bitloops from the [**VS Code Marketplace**](https://marketplace.visualstudio.com/items?itemName=Bitloops.bitloops)
+- Open the **Bitloops** panel (sidebar icon)
+- Sign in with GitHub or Google
+
+Bitloops runs in **VS Code** and **VS Code-based editors** (including forks like **Cursor**).
+
+## 2) Create a project
+
+- **File → Open Folder…**
+- Open Bitloops → give your project a name → **Create**
+
+✅ **Checkpoint:** Project actions are enabled.
+
+## 3) Use the demo design (fastest)
+
+Your first project includes a **pre-loaded demo design** already added to the project.
+
+- Open **Design View**
+- Select the demo design/frame
+
+✅ **Checkpoint:** You can see the design preview and the design tree.
+
+## 4) Create a component
+
+- Select elements (click, or drag-select like in Figma)
+- **Right-click → Create Component** *(Shortcut: Ctrl/Cmd + C in the Bitloops canvas)*
+- Name the component
+
+✅ **Checkpoint:** The component appears under **Components** and renders in **Component View** (live preview).
+
+## 5) Attach snapshots (recommended)
+
+Snapshots can be:
+
+- **Instances** (same component, different content) → helps infer **props**
+- **Variants** (same component, different state) → helps infer **variants** and **conditional rendering**
+- Accept suggested snapshots, **or**
+- Select elements → **Right-click → Attach Snapshot to [Component-name]**
+  *(Shortcut: if the component is selected, Ctrl/Cmd + A)*
+
+✅ **Checkpoint:** The component has an additional snapshot captured from the design.
+
+## 6) Edit code (the loop)
+
+- Double-click the component under **Components** to open its `.tsx` file
+- Edit code → `Ctrl/Cmd + S` → **Component View** updates instantly
+- Snapshot View stays fixed as your reference
+
+---
+
+## Account library vs project designs
+
+- **Account library:** all figma pages imported will be stored in your account library and live under **My Design Files.** These are reusable across projects and you only need to import them once. 
+- **Project Designs:** are designs you actually add fron your account library to a specific project. A project will generate design system tokens and extract the assets (text and images) from designs added to a project. All generated components/assets/code live in **the folder you opened** (your repo)
+
+## Using your own Figma designs (closed alpha)
+
+Bitloops works with any design, but Figma import access may require enablement while we’re in closed alpha. [Join the waitlist](https://airtable.com/appuDrjEAoOhJTIls/shrSM0ZEsJBanusfa) to get full access. 
+
+## Design syncing (not yet)
+
+Designs don’t auto-sync after import. If a design changes, the simplest approach today is to import a second version or start a new project and re-run the flow.
+
+---
+
+*Try Bitloops at [bitloops.com](https://bitloops.com) and ship your first component before your coffee gets cold.*
\ No newline at end of file
diff --git a/documentation/docs/frontend-copilot/introduction/how-bitloops-works.md b/documentation/docs/frontend-copilot/introduction/how-bitloops-works.md
new file mode 100644
index 00000000..a3aa00ca
--- /dev/null
+++ b/documentation/docs/frontend-copilot/introduction/how-bitloops-works.md
@@ -0,0 +1,167 @@
+---
+sidebar_position: 4
+sidebar_label: How Bitloops Works
+title: "How Bitloops Works"
+description: "A technical overview of how Bitloops transforms your Figma designs into structured, reusable React code."
+keywords:
+  [
+    bitloops workflow,
+    design to code process,
+    figma import,
+    code generation,
+    AI code generation,
+    react components,
+    tailwind css,
+  ]
+---
+
+# How Bitloops Works
+
+Bitloops turns Figma designs into structured, reusable React code using a hybrid approach: **deterministic analysis for structure** and **targeted AI for ambiguity**. Instead of exporting raw layers, Bitloops helps you build a maintainable UI by extracting components, inferring props, and supporting an iteration loop you can steer.
+
+The result is **editable code in your project**, plus snapshots/stories you can use for review and testing.
+
+## From Figma to components (and to full pages)
+
+Here’s the typical flow inside Bitloops today:
+
+1. **Import a Figma file**
+   - Import a Figma page by copying the URL
+   - Add pages, frames, or designs from the file into your Bitloops project
+
+2. **Select a frame or group of elements**
+   - You decide what becomes a component (Bitloops doesn’t force boundaries)
+   - Elements can be selected directly from the design canvas or the design tree
+
+3. **Create a component**
+   - Bitloops generates the initial React + Tailwind implementation and sets up the component’s structure
+   - When creating the first component in a project, Bitloops initializes a design system and extracts assets (text and images) for consistent management
+
+4. **Infer structure, props, and assets**
+   - Bitloops identifies reusable patterns, structural hierarchy, and prop candidates, enriching components where appropriate
+   - It also detects ICU-ready text, semantic HTML elements, and determines how assets should be handled (e.g. static vs dynamic)
+
+5. **Attach snapshots to expand behavior**
+   - Bitloops detects related instances or states of the same UI and allows you to attach snapshots to build variants and prop-driven behavior
+   - Developers can also manually associate snapshots from designs with existing components
+
+6. **Build upward**
+   - Create parent components, nest components, and assemble larger sections or full pages
+   - Child props are evaluated and container components are generated when orchestration or data mapping is required
+
+7. **Iterate fast**
+   - Bitloops compares the generated output with the design and highlights mismatches
+   - Users (or Bitloops) can adjust structure, including layout containers, and iterate until the output matches the design
+
+:::tip
+A good mental model is to work bottom-up: **create components → attach snapshots → build larger components**. Start with small, reusable child components, enrich them with snapshots for states and variants, then compose them into sections, pages, and finally routes.
+:::
+
+## What Bitloops generates
+
+Bitloops focuses on output you can actually ship and maintain:
+
+- **React components** with clean structure and readable JSX
+- **Tailwind CSS** classes with responsive corrections where possible
+- **Props and variants** inferred from snapshots and repeated instances
+- **Assets handling**
+  - Classifies images as **static vs dynamic**
+  - Generates correct imports and APIs (and can treat some assets as CMS-driven when appropriate)
+- **Stories / snapshot-style test scaffolding**
+  - Generates stories/snapshots so you can validate states and regressions early
+- **Better HTML semantics**
+  - Identifies where additional HTML tags (e.g., `button`, `a`, `input`) make sense for real UI behavior
+
+## How Bitloops understands designs
+
+Bitloops is designed to work with real-world Figma files—not just perfectly structured design systems.
+
+It does not assume that designs are clean, consistent, or built “the right way”. Whether a file uses auto-layout extensively, mixes styles, hard-codes values, or has little structure at all, Bitloops focuses on understanding intent, not enforcing rules. 
+
+Bitloops can work with:
+
+- Reusable components as well as one-off UI
+- Repeated patterns, even when they are not defined as Figma components
+- Deeply nested or inconsistent hierarchies
+- Variants and state-based designs, inferred or attached through snapshots
+- Layout intent (flex/grid-like groupings), even when auto-layout is not used consistently
+- Text styles, tokens, and hard-coded typography
+- Icons, images, vectors, and other visual assets
+- Responsive intent, where it can be inferred—and where developers explicitly guide it
+
+## The role of snapshots and repeated instances
+
+A key part of Bitloops’ workflow is identifying when the “same UI” appears multiple times.
+
+- If a component appears in multiple places, Bitloops can detect those **other instances** (referred to as snapshots until they're actually referenced in a parent as an instance)
+- You can **attach snapshots** from those instances to the same component
+- Differences across snapshots help Bitloops infer:
+  - prop boundaries
+  - variants/states
+  - conditional rendering
+  - what should remain structurally consistent
+
+This is how you go from “a component” to “a reusable component you can trust.”
+
+## Where AI is used—and where it isn’t
+
+Bitloops applies AI selectively, where it improves accuracy and reduces developer time:
+
+**AI/Hybrid inference is used for:**
+
+- Ambiguous layout intent and grouping suggestions
+- Component boundary hints across repeated patterns
+- Prop candidates inferred from snapshot differences
+- Asset classification (static vs dynamic) and API suggestions
+- Mapping design intent to practical HTML semantics
+
+**Bitloops avoids over-relying on AI for:**
+
+- Small manual tweaks that are faster for a developer to do directly
+- Unreviewable “one-shot” decisions that would lock you into a structure
+
+The goal is a predictable workflow: **you steer the decisions, Bitloops accelerates the heavy lifting.**
+
+## Interactivity via UI primitives (Base UI / Radix UI)
+
+When Bitloops identifies interactive UI elements (e.g., buttons, menus, toggles, dialogs), it can generate implementations that leverage established UI primitives such as **Base UI** or **Radix UI**, so interactivity is built on reliable foundations rather than ad-hoc behavior.
+
+:::note
+Exact components and generated patterns may vary depending on your design and project setup.
+:::
+
+## Layout containers (when designs need help)
+
+Sometimes the design structure doesn’t communicate grouping clearly (common in real files) and AI doesn't capture the intent accurately. Bitloops lets you add **layout containers** manually so the tool understands how elements should be grouped and laid out.
+
+Use layout containers when:
+
+- a selection generates awkward nesting
+- items that should be in a row/column aren’t grouped cleanly
+- you want to enforce a specific structure before/after generating a component
+
+This is a core part of the “copilot” approach: you provide intent when the design doesn’t.
+
+## Built for speed *and* iteration
+
+Bitloops is designed to help you go from design to implementation quickly—often from component extraction to meaningful UI output in minutes—while still supporting the reality that UI takes iteration.
+
+You can:
+
+- create components from any selection
+- attach more snapshots over time to expand coverage
+- build parent components and pages progressively
+- refine responsiveness and structure as you go (including with layout containers)
+
+## Dive deeper
+
+- [Core Concepts: Components & Reusability](../core-concepts/components-and-reusability.md) — How reuse works in Bitloops
+- [Core Concepts: Snapshots](../core-concepts/snapshots.md) — How snapshots define states and props
+- [Core Concepts: Layout Containers](../core-concepts/layout-containers.md) — Manual structure control
+- [Getting Started Guide](../getting-started-new/essential-guide.md) — Install and create your first component
+- [Guide: Importing Designs](../Guides/importing-designs.md) — Step-by-step import process
+- [Code Output Overview](../getting-started-new/code-output-overview.md) — Understand the generated code structure
+
+---
+
+*Try Bitloops to see how a frontend copilot accelerates UI work—without taking control away from you.*
\ No newline at end of file
diff --git a/documentation/docs/frontend-copilot/introduction/what-is-a-frontend-copilot.md b/documentation/docs/frontend-copilot/introduction/what-is-a-frontend-copilot.md
new file mode 100644
index 00000000..ccaaf536
--- /dev/null
+++ b/documentation/docs/frontend-copilot/introduction/what-is-a-frontend-copilot.md
@@ -0,0 +1,90 @@
+---
+sidebar_position: 3
+sidebar_label: What is a Frontend Copilot?
+title: "What is a Frontend Copilot?"
+description: "Understand what a frontend copilot does and how Bitloops acts as your AI-powered assistant for building UI faster."
+keywords:
+  [
+    frontend copilot,
+    AI copilot,
+    developer assistant,
+    UI automation,
+    code generation,
+    design to code,
+    productivity tools,
+  ]
+---
+
+# What is a Frontend Copilot?
+
+A **frontend copilot** is an AI-assisted tool that helps developers build UI faster by automating repetitive, low-leverage work—like layout scaffolding, component structure, and prop wiring—while keeping developers in full control of the codebase. [Bitloops](https://bitloops.com) is an example of a frontend copilot built specifically for design-to-code workflows.
+
+Think of it as a productivity layer that sits between **design and implementation**. It doesn’t replace your IDE, your framework, or your architectural decisions—it accelerates the path to writing scalable frontend code.
+
+## What a frontend copilot does
+
+A frontend copilot typically helps with:
+
+- Turning design intent into **structure** (layout scaffolding, containers, nesting)
+- Suggesting **component boundaries and reuse** based on repeated patterns
+- Inferring **props and variants** from differences across states (e.g., snapshots)
+- Producing a clean starting point that’s easy to **review, refactor, and extend**
+
+## What a frontend copilot does not do
+
+A frontend copilot is *not* responsible for:
+
+- Choosing your app architecture, state model, or data layer
+- Writing product/business logic on your behalf
+- Guaranteeing a perfect, final UI without review and iteration
+
+## Bitloops as your frontend copilot
+
+Bitloops is a frontend copilot designed for design-to-code workflows:
+
+- It interprets design files and identifies reusable components, variants, and layouts  
+  *(e.g., repeated cards across screens become a shared component; differences across states become prop candidates).*
+- It creates clean, prop-driven React components using Tailwind CSS
+- It outputs code directly into your project structure
+- It’s editable by default—you can change anything it generates
+
+## Frontend copilot ≠ full automation
+
+There are many valid ways to build UI. A copilot won’t get everything right on the first pass—and that’s the point.
+
+Bitloops is designed for fast iteration: **generate → compare → refine**. The output is structured for clarity and modification so you can adjust decisions quickly and keep moving.
+
+## A frontend copilot is not these tools
+
+A frontend copilot is often confused with other approaches:
+
+- **Page builder** — drag-and-drop tools designed for non-dev workflows.  
+  Great for assembly, but typically limits code ownership and flexibility.
+
+- **Prompt-only code generator** — “describe a UI” → get a snippet.  
+  Fast for one-offs, but structure and reusability are inconsistent across a real codebase.
+
+- **Static design-to-code exporter** — element-to-code mapping from a single frame.  
+  Often produces brittle markup, hardcoded styles, and poor component boundaries.
+
+- **Autonomous agent** — tries to “do everything” end-to-end.  
+  Can be powerful, but often reduces predictability and makes review/control harder.
+
+## Copilot, not autopilot
+
+- You remain in the driver’s seat
+- You decide how to structure and extend the code
+- You can delete or override anything without being trapped in a tool-specific runtime
+
+**A frontend copilot should help you build faster—without giving up the craftsmanship of frontend engineering.**
+
+## Related resources
+
+- [What is Bitloops?](./what-is-bitloops.md) — Complete overview of Bitloops
+- [Components & Reusability](../core-concepts/components-and-reusability.md) — How Bitloops handles component creation
+- [Getting Started](../getting-started-new/essential-guide.md) — Begin using Bitloops today
+- [Code Output example](../getting-started-new/code-output-overview.md) — See the type of code a frontend copilot can produce
+
+---
+
+*Try [Bitloops](https://bitloops.com) to see what a frontend copilot looks like in a real design-to-code workflow.*
\ No newline at end of file
diff --git a/documentation/docs/frontend-copilot/introduction/what-is-bitloops.md b/documentation/docs/frontend-copilot/introduction/what-is-bitloops.md
new file mode 100644
index 00000000..1dcb8423
--- /dev/null
+++ b/documentation/docs/frontend-copilot/introduction/what-is-bitloops.md
@@ -0,0 +1,80 @@
+---
+sidebar_position: 1
+sidebar_label: What is Bitloops?
+title: "What is Bitloops?"
+description: "Learn what Bitloops Frontend Copilot is - an AI-powered tool that transforms Figma designs into clean, reusable, production-ready React code."
+keywords:
+  [
+    bitloops,
+    frontend copilot,
+    design to code,
+    figma to react,
+    AI code generation,
+    production-ready code,
+    react components,
+    tailwind css,
+  ]
+---
+
+# What is Bitloops?
+
+Bitloops is a frontend copilot that converts Figma designs into clean, reusable, production-ready code. It helps you automate repetitive tasks like component creation, layout scaffolding, asset extraction, and styling — while keeping you fully in control of the output.
+
+Bitloops is built for professional developers who want to move faster without compromising quality. The goal isn't to replace developers, but to support them by offloading time-consuming UI work that follows patterns and best practices.
+
+## What Bitloops does
+
+- **Imports Figma designs** - entire pages or selected frames
+- **Identifies layout structure**, reusable components, and variants
+- **Generates React + Tailwind CSS code**, optimized for readability and reuse
+- **Organizes code** with prop-driven components and flexible folder structure
+- **Automatically generates Storybook stubs** for isolated component rendering
+- **Generates responsive layouts** not just static desktop scaffolding
+- **Extracts UI copy into mock JSON** for text elements and supports i18n workflows
+- **Classifies images as static vs dynamic** generating correct imports and prop-driven APIs
+
+## How Bitloops is different
+
+Unlike tools that do direct element-to-code mapping, Bitloops interprets designs the way a senior engineer would. It looks for patterns, context, and hierarchy — then builds scalable UI code from that model. If a button appears in four places, Bitloops suggests a single component. If a layout uses repeating patterns, it structures them accordingly.
+
+Bitloops doesn't require your design file to follow rigid conventions. It works with real-world, messy designs and still aims to generate high-quality code. And Bitloops doesn’t just generate code — it generates checks (tests and comparisons) to validate that the output matches the design intent.
+
+## Transparent, not magic
+
+There are many ways to build a UI — and Bitloops won't get it right every time. That's expected. The key is that the code it gives you is easy to understand and modify. You can rename props, restructure layout, or delete parts entirely and continue working.
+
+Bitloops is built on the idea that AI should handle what's slow or tedious — and get out of your way when human judgment is faster or easier. For example, changing a couple of Tailwind classes is quick. But extracting a design pattern into a component API—props, states, and variants that scale across screens—takes real effort. Bitloops focuses on the latter.
+
+## What it's not
+
+- **Not a low-code builder** — you work with real code
+- **Not a black box** — you can review, edit, and fully own your code
+- **Not a generic design-to-code tool that “takes a best guess”** - get engineer-grade components you can trust and iterate
+
+## Next steps
+
+Ready to get started? Here's where to go next:
+
+- [How Bitloops Works](./how-bitloops-works.md) — Technical overview of the conversion process
+- [Getting Started Guide](../getting-started-new/essential-guide.md) — Install and create your first component
+- [Core Concepts: Components](../core-concepts/components-and-reusability.md) — Learn about component creation and reusability
+
+---
+
+*Try [Bitloops](https://bitloops.com) on a real design and inspect the generated code yourself!*
+
+
+
+
+
+### Getting Started
+
+- [The Essential Guide](../getting-started-new/essential-guide.md) — Complete beginner walkthrough
+- [What is Bitloops?](../introduction/what-is-bitloops.md) — Product overview
+- [Quick Start](../getting-started-new/quick-start.md) — Fast reference guide
+
+### Core Concepts
+
+- [Components & Reusability](../core-concepts/components-and-reusability.md) — Building scalable UI
+- [Code Generation & Testing](../core-concepts/code-generation-and-testing.md) — Generated code structure
+- [Tailwind CSS](../core-concepts/tailwind-css.md) — Styling approach
\ No newline at end of file
diff --git a/documentation/docs/frontend-copilot/introduction/who-should-use-bitloops.md b/documentation/docs/frontend-copilot/introduction/who-should-use-bitloops.md
new file mode 100644
index 00000000..db9b926f
--- /dev/null
+++ b/documentation/docs/frontend-copilot/introduction/who-should-use-bitloops.md
@@ -0,0 +1,98 @@
+---
+sidebar_position: 5
+sidebar_label: Who Should Use Bitloops?
+title: "Who Should Use Bitloops?"
+description: "Find out if Bitloops is the right tool for you - ideal users, common use cases, and when it's not the right fit."
+keywords:
+  [
+    bitloops users,
+    frontend developers,
+    react developers,
+    design system builders,
+    startups,
+    freelancers,
+    agencies,
+  ]
+---
+
+# Who should use Bitloops?
+
+Bitloops is built for **developers** doing **frontend work** and teams who want to **ship professional-grade UI** faster—without giving up control of their code. It’s not a no-code website builder, and it’s not a “magic button.” It’s a copilot for engineers who can review output, make implementation decisions, and iterate.
+
+## Ideal users
+
+### Frontend / Fullstack Developers
+
+- Building UIs in **React** (Bitloops currently outputs React + Tailwind CSS)
+- Want to reduce boilerplate: layout scaffolding, component setup, variants, and repetitive UI structure
+- Prefer clean, editable code over black-box output
+
+### Tech Startups (3–10 devs)
+
+- Shipping fast with evolving designs and frequent UI changes
+- Need maintainable components early to avoid “rewrite it later”
+- Want to compress the design-to-implementation cycle without sacrificing ownership
+
+### Freelancers & Agencies
+
+- Delivering multiple projects under tight timelines
+- Need consistent, maintainable component structure across screens and clients
+- Want a fast first pass that still feels like real engineering output
+
+### Design System Builders
+
+- Translating Figma patterns into reusable component libraries
+- Need repeatable component boundaries, variants, and prop-driven APIs
+- Want a tighter pipeline between design intent and implementation
+
+## Works best when
+
+Bitloops shines when the bottleneck is **UI structure and repetition**, not “inventing” product logic.
+
+Use Bitloops when:
+
+- Your designs include repeated patterns across screens (cards, headers, lists, forms, tables)
+- You want to extract reusable components and build upward into larger sections and pages
+- You care about maintainability: clear component boundaries, props, and variants
+- Your team wants a fast baseline and an iteration loop (generate → compare → refine)
+- Your Figma files are real-world and imperfect, and you want a tool that can still help—especially when you can steer it
+
+## Common use cases
+
+- Kickstarting a new project or feature from fresh designs
+- Translating multi-screen designs into a reusable component library
+- Rebuilding UI after design updates by extracting and extending components
+- Refactoring messy UI into cleaner structure through better boundaries and reuse
+- Working in a typical Git-based workflow (VS Code + PR review), where generated code is reviewed and refined like any other change
+
+## When Bitloops isn't the right fit
+
+Bitloops is **not** for:
+
+- **Non-developers** who don’t want to work with code
+- Projects that **do not start from (figma) design inputs** (e.g. UI built entirely ad-hoc or directly in code without a design reference)
+- **Backend-focused developers** trying to “generate a website” without frontend implementation knowledge
+- Teams seeking a **drag-and-drop page builder** rather than a code-first workflow
+- Projects that aren’t a match for the current output stack (react/next.js + tailwind)
+
+:::note
+**Current output:** React with Tailwind CSS (Next.js–ready).
+Support for additional frameworks and languages is planned, but today Bitloops is focused on teams shipping React component code.
+:::
+
+## Designed for frontend ownership
+
+Bitloops won’t get everything perfect on the first pass—no tool can. What matters is that the code is **yours**: readable, editable, and designed to be iterated on by a frontend engineer.
+
+Whether you’re solo or on a growing team, Bitloops helps you scale UI delivery while keeping quality and maintainability high.
+
+## Get started
+
+- [Getting Started Guide](../getting-started-new/essential-guide.md) — Your first steps with Bitloops
+- [Create Components](../Guides/creating-components.md) — Create your first component
+- [Design Systems](../core-concepts/design-system.md) — How Bitloops works with design systems
+- [FAQs](../faq-troubleshooting/faqs.md) — Common questions answered
+
+---
+
+*Try [Bitloops](https://bitloops.com) to see how a frontend copilot fits into a real React workflow.*
\ No newline at end of file
diff --git a/documentation/docs/frontend-copilot/introduction/why-bitloops.md b/documentation/docs/frontend-copilot/introduction/why-bitloops.md
new file mode 100644
index 00000000..e46fb84e
--- /dev/null
+++ b/documentation/docs/frontend-copilot/introduction/why-bitloops.md
@@ -0,0 +1,84 @@
+---
+sidebar_position: 2
+sidebar_label: Why Bitloops?
+title: "Why Bitloops?"
+description: "Discover why Bitloops exists and how it solves the repetitive, manual tasks that slow down frontend development."
+keywords:
+  [
+    bitloops benefits,
+    frontend automation,
+    design to code,
+    developer productivity,
+    reduce boilerplate,
+    frontend efficiency,
+    code generation benefits,
+  ]
+---
+
+# Why Bitloops?
+
+Frontend engineering is full of repetitive, manual tasks — especially at the point where design meets implementation. Bitloops exists to automate the work that slows developers down, while preserving full control and flexibility over the codebase.
+
+The real cost isn’t generating JSX — it’s arriving at a component model you’ll still understand three months later. Teams lose time rebuilding structure, renegotiating boundaries, and refactoring UI code that started as “just ship it” — while also doing the grind work of writing layout scaffolding, extracting assets, and repeatedly structuring components from scratch. Bitloops is built to give you a maintainable starting point: reusable components, clear prop boundaries, and an iteration loop that holds up over time.
+
+That’s why Bitloops focuses on structure and reusability first—so you spend your time on the parts that actually require engineering judgment.
+
+## The problem with frontend work today
+
+- **Too much boilerplate:** Even small pages require lots of setup — containers, spacing, variants, tests, props.
+- **Manual & repetitive:** Developers often recreate the same layout structures, cards, buttons, and wrappers.
+- **Designs aren't consistent:** Most real-world Figma files are messy, unannotated, or loosely structured.
+- **Existing tools fall short:** Most design-to-code solutions either produce unmaintainable code or force you into their platform.
+
+These problems don't just waste time — they introduce bugs, technical debt, and friction across product, design, and engineering teams.
+
+## How Bitloops helps
+
+Bitloops gives developers a head start by converting designs into clean, reusable components — ready to be used, edited, and extended.
+
+- **Saves hours on initial UI scaffolding** — generates the baseline layout, structure, and component skeletons so you start from a maintainable foundation, not boilerplate
+- **Auto-detects layout and structure** - finds repetition across screens to propose shared components, and infers prop boundaries from snapshot differences
+- **Outputs real code** — readable React + Tailwind you can edit, refactor, and commit directly into your codebase (no proprietary runtime)
+- **Works with imperfect designs** — handles real-world Figma files that are messy, inconsistent, or loosely structured; you steer when needed
+
+## Where AI fits in (and where it doesn't)
+
+AI is powerful — but it has real limits. Tasks that are trivial for humans (like shifting an image or aligning a label) can be very hard and costly for AI to handle reliably. On the other hand, tasks like layout scaffolding, variant setup, or prop modeling — while simple in concept — are time-consuming for humans, and ideal for automation.
+
+Bitloops uses AI and algorithms to accelerate the right parts of development — not to replace your decisions.
+
+## Built for developer control
+
+We know there's no single "right" way to build a UI — and we don't assume Bitloops will always get it perfect. What matters is that the generated code is something you can trust, tweak, and extend.
+
+- You can rename props, split components, add custom logic
+- You stay in your stack — no lock-in, no visual builder: outputs plain React components in your repo with no proprietary runtime - you can delete Bitloops and keep the code
+- You choose component boundaries
+- Accept/reject suggestions
+- Regenerate selectively
+- Edit output directly without fighting the tool
+
+Bitloops supports developer workflows from the ground up without getting in the way or eating up AI tokens. 
+
+## When to use Bitloops
+
+Bitloops is a strong fit when you need to turn design into maintainable UI quickly — without sacrificing structure.
+
+Use it when:
+
+- You’re starting a new feature and want a clean component baseline fast
+- You’re converting multiple screens and need consistent component boundaries and reuse
+- You want to accelerate scaffolding while keeping the code easy to review and refactor
+- You’re building (or migrating to) a design system and want repeatable patterns from real designs
+
+**Bitloops doesn’t replace frontend engineering — it compresses the boring parts so you can spend more time on architecture, behavior, and product logic.**
+
+## Learn more
+
+- [How Bitloops Works](./how-bitloops-works.md) — Technical deep-dive into the conversion process
+- [Who Should Use Bitloops?](./who-should-use-bitloops.md) — Find out if Bitloops is right for you
+- [Getting Started](../getting-started-new/essential-guide.md) — Begin your first project
+
+---
+
+*Visit [bitloops.com](https://bitloops.com) to start building faster today.*
diff --git a/documentation/docs/frontend-copilot/seo-metadata-recommendations.md b/documentation/docs/frontend-copilot/seo-metadata-recommendations.md
new file mode 100644
index 00000000..25044eb3
--- /dev/null
+++ b/documentation/docs/frontend-copilot/seo-metadata-recommendations.md
@@ -0,0 +1,1280 @@
+# SEO Metadata Recommendations: Titles, Descriptions, Keywords & FAQs
+
+**Purpose:** Comprehensive SEO improvements for all 20 documents across Best Practices and UI Systems Performance series.
+
+---
+
+## Best Practices Series (9 Documents)
+
+---
+
+### 1. introduction.md
+
+**Current Title:** "Best Practices & Patterns: An Introduction"
+
+**Suggested Title:** "Frontend Component Best Practices: Production Patterns for React & Design Systems"
+
+**Current Description:** "An 8-part series on component-level best practices: API design, data contracts, accessibility, testing, and the patterns that produce production-quality frontends."
+
+**Suggested Description:** "8-part guide to production-quality React components: API design, accessibility, testing contracts, and the patterns that scale across teams. Start here."
+
+**Current Keywords:**
+```
+frontend best practices, component patterns, react patterns, component api design, frontend architecture, design systems, accessibility, storybook testing
+```
+
+**Suggested Keywords:**
+```
+frontend best practices guide,
+react component patterns,
+component library best practices,
+design system implementation,
+production react components,
+frontend architecture patterns,
+component api design principles,
+scalable frontend code
+```
+
+**Suggested FAQs:**
+
+1. **What's the difference between component patterns and design patterns?**
+   Component patterns address React-specific concerns like prop design, composition, and state boundaries. Design patterns are language-agnostic solutions to recurring problems (Observer, Factory, etc.). This series covers component patterns specifically—how to structure React components for production use. See [Component API Design](./best-practices/component-api-design.md) for detailed prop patterns.
+
+2. **Should I read this series in order?**
+   Not necessarily. Start with [Component Creation Workflows](./best-practices/component-creation-workflows.md) if you're building new components from scratch. Jump to [Component API Design](./best-practices/component-api-design.md) if you're refactoring existing component interfaces. For testing strategy, see [Testing and Storybook](./best-practices/testing-and-storybook.md).
+
+3. **Do these patterns apply to Vue, Svelte, or other frameworks?**
+   The underlying principles—prop contracts, data boundaries, accessibility structure, testing as verification—transfer to any component-based framework. The code examples use React syntax, but the mental models apply universally. See [Data Contracts](./best-practices/data-contracts.md) for framework-agnostic boundary design.
+
+4. **How do Best Practices relate to the UI Systems Performance series?**
+   Best Practices covers *how to build things well* (components, APIs, conventions). [UI Systems Performance](./ui-systems-performance/introduction.md) covers *how systems work* (state replication, caching, failure modes). For state management patterns, see [State Management at Scale](./ui-systems-performance/state-management-at-scale.md). For caching, see [Caching Strategies](./ui-systems-performance/caching-strategies.md).
+
+5. **Are these patterns for design system authors or consumers?**
+   Both. Design system authors need these patterns to build stable, well-documented components. Consumers need them to use design systems correctly, extend them appropriately, and avoid drift. See [Design System Consumption](./best-practices/design-system-consumption.md) for consumer-specific guidance.
+
+6. **How do I know if my codebase needs these patterns?**
+   Signs you need them: inconsistent component APIs across the codebase, difficulty onboarding new developers, frequent breaking changes, accessibility retrofitting, tests that break on visual changes. See [Codebase Conventions](./best-practices/codebase-conventions.md) for structure patterns that prevent these issues.
+
+7. **What's the relationship between these patterns and team size?**
+   Patterns matter more as teams grow. A solo developer can hold conventions in their head. A team of 5+ needs explicit patterns to maintain consistency. See [Codebase Conventions](./best-practices/codebase-conventions.md) for patterns that scale with team size.
+
+8. **Can I adopt these patterns incrementally?**
+   Yes. Start with the area causing the most pain. Accessibility problems? Start with [Accessibility](./best-practices/accessibility.md). Inconsistent APIs? Start with [Component API Design](./best-practices/component-api-design.md). Testing gaps? See [Testing and Storybook](./best-practices/testing-and-storybook.md). Each document stands alone.
+
+9. **How do these patterns interact with AI code generation tools?**
+   AI tools benefit from clear patterns—they can generate more consistent code when patterns are explicit. Bitloops specifically encodes these patterns into its generation pipeline, producing components that follow best practices by default. See [Design System Consumption](./best-practices/design-system-consumption.md) for token-based generation patterns.
+
+10. **What's the cost of NOT following these patterns?**
+    Technical debt accumulates: inconsistent APIs create cognitive load (see [Component API Design](./best-practices/component-api-design.md)), poor accessibility excludes users (see [Accessibility](./best-practices/accessibility.md)), missing tests allow regressions (see [Testing and Storybook](./best-practices/testing-and-storybook.md)), and design drift erodes brand consistency (see [Design System Consumption](./best-practices/design-system-consumption.md)).
+
+---
+
+### 2. component-creation-workflows.md
+
+**Current Title:** "Component Creation Workflows"
+
+**Suggested Title:** "When to Create React Components: Extraction Signals, Boundaries, and Abstraction Timing"
+
+**Current Description:** "When should a component exist? How do you decide its boundaries? Learn the lifecycle decisions that determine component structure and prevent premature abstraction."
+
+**Suggested Description:** "When should you extract a React component? Learn the signals that indicate component boundaries, how to avoid premature abstraction, and when to keep code inline."
+
+**Current Keywords:**
+```
+component creation, component boundaries, reusable components, component extraction, container components, presentational components, react patterns
+```
+
+**Suggested Keywords:**
+```
+when to create react component,
+component extraction patterns,
+react component boundaries,
+premature abstraction react,
+reusable vs one-off components,
+container presentational pattern,
+component refactoring signals,
+react code organization
+```
+
+**Suggested FAQs:**
+
+1. **How do I know when to extract a component vs. keep code inline?**
+   Extract when you see: (1) the same UI appearing in 2+ places, (2) a piece of UI that has a clear, describable purpose, (3) a section exceeding ~200 lines that's hard to understand at a glance, or (4) something you want to test in isolation (see [Testing and Storybook](./best-practices/testing-and-storybook.md)). Keep code inline when extraction would just move complexity without adding clarity.
+
+2. **What's the difference between premature and delayed abstraction?**
+   Premature abstraction creates flexible, configurable components before you understand the actual variations. You end up with wrong abstractions that need constant modification. Delayed abstraction copies code until patterns emerge naturally. Both fail—premature creates wrong interfaces (see [Component API Design](./best-practices/component-api-design.md)), delayed creates inconsistency.
+
+3. **Should every UI element be a component?**
+   No. A `<div className="flex gap-4">` doesn't need to be a `<FlexRow>` component. Components earn their existence through reuse, encapsulation, or naming value. A button is a component because it has behavior, variants, and accessibility requirements (see [Accessibility](./best-practices/accessibility.md)). A flex container is just styling.
+
+4. **When should a component become "shared" vs. stay local to a feature?**
+   Keep components local (in the feature folder) until a second, unrelated feature needs them. Promote to shared only when: (1) 3+ usages exist, (2) usages span different features, (3) the API is stable. See [Codebase Conventions](./best-practices/codebase-conventions.md) for file organization patterns.
+
+5. **What are the signals that I've drawn component boundaries wrong?**
+   Signals of wrong boundaries: (1) passing many props through layers (prop drilling), (2) frequent changes to the component when unrelated features change, (3) needing to expose internal implementation details, (4) the component name doesn't describe what it does. See [Component API Design](./best-practices/component-api-design.md) for proper boundary design.
+
+6. **Is the container/presentational pattern still relevant?**
+   Yes, but as a workflow, not an architecture rule. Start by building the presentational component with mock data (focus on visuals). Add a container when data-fetching logic becomes non-trivial. See [Data Contracts](./best-practices/data-contracts.md) for how to separate data concerns from presentation.
+
+7. **How do I decide between one configurable component vs. multiple specific components?**
+   Use the "boolean explosion" test: if you'd need 3+ boolean props to configure variations, you probably want multiple specific components (or a variant prop). `<Card>`, `<Card.Compact>`, `<Card.Featured>` is often clearer than `<Card isCompact isFeatured showImage />`. See [Component API Design](./best-practices/component-api-design.md) for variant patterns.
+
+8. **What's the lifecycle of a component—when should components be deleted?**
+   Components should be deleted when: (1) they're used in only one place after refactoring, (2) they've been replaced by a better abstraction, (3) they no longer fit the design system. See [Design System Consumption](./best-practices/design-system-consumption.md) for when components should align with design system primitives.
+
+9. **How do I handle components that seem to need access to their parent's state?**
+   This often indicates the boundary is in the wrong place. Options: (1) lift state up and pass it down as props, (2) use context for truly global state, (3) reconsider whether the component should own the interaction. For complex state patterns, see [State Management at Scale](./ui-systems-performance/state-management-at-scale.md).
+
+10. **Should components control their own layout (margin, positioning)?**
+    No. Components should control their internal layout but not their external position. The parent decides where the component goes (margin, grid placement). This makes components reusable across different layout contexts. See [Responsive Behavior](./best-practices/responsive-behavior.md) for layout adaptation patterns.
+
+---
+
+### 3. component-api-design.md
+
+**Current Title:** "Component API Design"
+
+**Suggested Title:** "React Component API Design: Props as Contracts, Variants, and Stable Interfaces"
+
+**Current Description:** "Props are contracts. Learn how to design component APIs that are semantic, stable, and evolvable—without boolean explosion or breaking changes."
+
+**Suggested Description:** "Design React component APIs that don't break. Learn semantic props vs. mechanical props, variant patterns, boolean explosion prevention, and stable interface evolution."
+
+**Current Keywords:**
+```
+component api, props design, react props, component interface, typescript props, component contracts, api stability
+```
+
+**Suggested Keywords:**
+```
+react component api design,
+props best practices react,
+component interface design,
+boolean prop explosion,
+react component variants,
+typescript component props,
+stable component api,
+semantic vs mechanical props
+```
+
+**Suggested FAQs:**
+
+1. **What's the difference between semantic and mechanical props?**
+   Semantic props describe intent: `variant="primary"`, `size="large"`, `status="error"`. Mechanical props describe implementation: `backgroundColor="blue"`, `padding={16}`, `borderWidth={2}`. Prefer semantic props—they remain stable when visual implementation changes. See [Design System Consumption](./best-practices/design-system-consumption.md) for token-based styling that reinforces semantic props.
+
+2. **How do I avoid boolean prop explosion?**
+   Replace multiple related booleans with a single variant prop. Instead of `<Button isLarge isPrimary isOutlined />` (8 possible combinations), use `<Button variant="primary" size="lg" style="outlined" />`. If you have 3+ related booleans, you have a variant system in disguise. See [Component Creation Workflows](./best-practices/component-creation-workflows.md) for when to split components.
+
+3. **When should I use `children` vs. named slots like `header`, `footer`, `icon`?**
+   Use `children` for simple, single content areas where order doesn't matter. Use named slots when: (1) the component has multiple distinct regions, (2) you need to enforce structure, (3) content needs specific styling or behavior. Named slots make the API explicit and self-documenting.
+
+4. **How do I evolve a component API without breaking consumers?**
+   Rules for non-breaking changes: (1) add new optional props, never change required ones, (2) deprecate with console warnings before removing, (3) use TypeScript to catch breaks at compile time, (4) version your design system if breaking changes are necessary. See [Data Contracts](./best-practices/data-contracts.md) for similar contract evolution patterns.
+
+5. **Should I expose `className` or `style` props on design system components?**
+   Avoid exposing escape hatches like `className` unless absolutely necessary—they invite design system drift. If you must, consider naming it `__unsafeClassName` to signal it's discouraged. See [Design System Consumption](./best-practices/design-system-consumption.md) for preventing drift patterns.
+
+6. **How do I design props for compound components (Card.Header, Card.Body)?**
+   Keep compound component props minimal—they're for structure, not configuration. The parent component can accept shared configuration and pass it via context. Each sub-component should be self-contained. See [Component Creation Workflows](./best-practices/component-creation-workflows.md) for boundary decisions.
+
+7. **What's the right level of flexibility in component APIs?**
+   Flexibility should match expected variation. A Button needs variants (primary, secondary) because that's how buttons are used. It doesn't need a `customHoverColor` prop because that's design drift. See [Design System Consumption](./best-practices/design-system-consumption.md) for the balance between flexibility and constraint.
+
+8. **How do I handle required vs. optional props?**
+   Make props required when the component can't render meaningfully without them (a Button needs children or an icon). Make props optional when there's a sensible default. For accessibility requirements on props, see [Accessibility](./best-practices/accessibility.md).
+
+9. **Should I use TypeScript discriminated unions for component props?**
+   Yes, for mutually exclusive configurations. Instead of `<Component showImage imageUrl={url} />` where `imageUrl` is ignored without `showImage`, use a union: `{ type: 'with-image'; imageUrl: string } | { type: 'no-image' }`. For TypeScript in data contracts, see [Data Contracts](./best-practices/data-contracts.md).
+
+10. **How do I document component APIs effectively?**
+    Document: (1) what each prop does, (2) valid values and their meaning, (3) default values, (4) which combinations are valid, (5) example usage. See [Testing and Storybook](./best-practices/testing-and-storybook.md)—stories serve as executable documentation where each story demonstrates valid usage.
+
+---
+
+### 4. data-contracts.md
+
+**Current Title:** "Data Contracts and Content Boundaries"
+
+**Suggested Title:** "Frontend Data Contracts: API Boundaries, Mapping Layers, and Schema Ownership"
+
+**Current Description:** "Where does data responsibility live? Learn how to design boundaries between CMS, backend, and frontend—with clear contracts, mapping layers, and validation strategies."
+
+**Suggested Description:** "Who owns the data shape—API, CMS, or component? Learn mapping layers, validation boundaries, and contracts that prevent backend changes from breaking your UI."
+
+**Current Keywords:**
+```
+data contracts, content boundaries, api contracts, cms integration, data mapping, frontend data, schema validation
+```
+
+**Suggested Keywords:**
+```
+frontend data contracts,
+api response mapping react,
+cms frontend integration,
+typescript api validation,
+zod schema validation,
+backend frontend contract,
+data transformation layer,
+api schema ownership
+```
+
+**Suggested FAQs:**
+
+1. **Should components consume API responses directly?**
+   No. Add a mapping layer that transforms API responses into the shape components expect. This isolates components from backend changes: when the API returns `price_cents`, map it to `formattedPrice: "$29.99"` before it reaches components. See [Component API Design](./best-practices/component-api-design.md) for how component props should be designed around this mapped data.
+
+2. **Where should data validation happen—frontend or backend?**
+   Both, for different reasons. Backend validates for security and data integrity (never trust client input—see [Security Boundaries](./ui-systems-performance/security-boundaries.md)). Frontend validates for UX (immediate feedback) and to fail fast on unexpected response shapes. Use tools like Zod for runtime validation at API boundaries.
+
+3. **How do I handle API schema changes without breaking the UI?**
+   The mapping layer absorbs changes. When the API renames `user_name` to `username`, update the mapper once—not every component that displays names. See [Codebase Conventions](./best-practices/codebase-conventions.md) for organizing mapping layers alongside features.
+
+4. **What's the difference between a data contract and a TypeScript type?**
+   TypeScript types are compile-time checks—they verify your code is internally consistent. Data contracts are runtime agreements about what shape data actually arrives in. Use both: types for development, runtime validation for production. For related type patterns, see [Component API Design](./best-practices/component-api-design.md).
+
+5. **Who owns the contract—frontend or backend?**
+   Ideally, contracts are shared artifacts (OpenAPI specs, GraphQL schemas) that both sides agree to. In practice, the backend usually defines the API and frontend adapts. See [Network Protocols](./ui-systems-performance/network-protocols.md) for HTTP contract patterns.
+
+6. **How do I handle optional or missing fields from the API?**
+   Define defaults in the mapping layer, not scattered across components. If `user.avatarUrl` might be null, the mapper provides a default: `avatarUrl: user.avatarUrl ?? DEFAULT_AVATAR`. Components can assume the shape is complete. See [Component API Design](./best-practices/component-api-design.md) for handling optional props.
+
+7. **What's the right granularity for data contracts?**
+   Match contracts to domain concepts, not API endpoints. A "Product" contract includes everything components need to render a product, regardless of whether it comes from one endpoint or three. For caching these aggregated shapes, see [Caching Strategies](./ui-systems-performance/caching-strategies.md).
+
+8. **How do I version data contracts?**
+   When contracts must change, support both versions temporarily: the mapping layer accepts v1 or v2 from the API and normalizes to the component's expected shape. Deprecate old versions with deadlines. For similar versioning patterns with component APIs, see [Component API Design](./best-practices/component-api-design.md).
+
+9. **Should I use GraphQL to avoid mapping layers?**
+   GraphQL reduces the need for mapping by letting frontend request exact shapes. But you still need validation and transformation. For caching GraphQL responses, see [Caching Strategies](./ui-systems-performance/caching-strategies.md). GraphQL is better DX, not a replacement for data boundaries.
+
+10. **How do I test data contracts?**
+    Test the mapping layer with fixtures: given this API response, verify the output shape. Test that validation rejects malformed responses. See [Testing and Storybook](./best-practices/testing-and-storybook.md) for how story fixtures should reflect these mapped data shapes.
+
+---
+
+### 5. design-system-consumption.md
+
+**Current Title:** "Design System Consumption"
+
+**Suggested Title:** "Using Design Systems Correctly: Tokens, Constraints, and Preventing Drift"
+
+**Current Description:** "Design systems provide tokens and constraints. Learn the rules for consuming them: what's allowed, what's forbidden, and how limitation enables scale."
+
+**Suggested Description:** "Design systems fail when developers bypass them. Learn token-only styling, the forbidden list, escape hatch friction, and how to prevent design drift at scale."
+
+**Current Keywords:**
+```
+design systems, design tokens, tailwind tokens, css variables, theming, design constraints, style consistency
+```
+
+**Suggested Keywords:**
+```
+design system consumption rules,
+design tokens best practices,
+preventing design system drift,
+tailwind design system,
+css custom properties tokens,
+design system constraints,
+token only styling,
+design system governance
+```
+
+**Suggested FAQs:**
+
+1. **When is it okay to use arbitrary values instead of design tokens?**
+   Almost never in production code. Acceptable exceptions: one-off decorative elements (marketing hero positioning), third-party integration constraints (external widget dimensions), or rapid prototyping before tokens exist. Always document why. If you need a value frequently, request a token. See [Responsive Behavior](./best-practices/responsive-behavior.md) for when fluid values are appropriate.
+
+2. **How do I prevent developers from bypassing the design system?**
+   Multiple layers: (1) constrain component APIs—don't expose `className` (see [Component API Design](./best-practices/component-api-design.md)), (2) add linting rules for arbitrary Tailwind values, (3) make escape hatches explicit (`__unsafeClassName`), (4) review PRs for token compliance, (5) audit quarterly for drift. See [Codebase Conventions](./best-practices/codebase-conventions.md) for enforcement patterns.
+
+3. **What's the difference between extending and bypassing a design system?**
+   Extending adds new tokens, components, or variants through the system's governance process—it's intentional, documented, and reviewed. Bypassing hardcodes values outside the system—it's hidden, undocumented, and erodes consistency. See [Component Creation Workflows](./best-practices/component-creation-workflows.md) for when to create new components vs. extend existing ones.
+
+4. **Should I use `!important` to override design system styles?**
+   No. If you need `!important`, you're fighting the system instead of using it. Either the system needs a new variant (see [Component API Design](./best-practices/component-api-design.md)), or you're using the wrong component. File an issue requesting what you need rather than forcing overrides.
+
+5. **How do I handle cases where design tokens don't exist for my use case?**
+   Follow the fallback hierarchy: (1) verify the token doesn't exist, (2) use the nearest existing token, (3) request a new token if the need is recurring, (4) document the exception if you must use an arbitrary value temporarily. See [Codebase Conventions](./best-practices/codebase-conventions.md) for documenting exceptions.
+
+6. **What's token-only styling and why does it matter?**
+   Token-only styling means using design system values (colors, spacing, typography) exclusively—never hardcoded hex values or pixel measurements. Tokens adapt to themes (dark mode) and can be audited. See [Responsive Behavior](./best-practices/responsive-behavior.md) for how tokens work with responsive design.
+
+7. **How do themes interact with design system consumption?**
+   Themes redefine token values, not component structure. If you use `bg-primary`, the theme defines what "primary" means in each context. Semantic tokens (`bg-background`, `text-muted`) are theme-safe. For accessibility considerations in theming, see [Accessibility](./best-practices/accessibility.md).
+
+8. **How do I create recurring patterns without violating the design system?**
+   Create wrapper components that compose system primitives correctly. If you often use `Button` + `Tooltip` + specific icon sizing, create an `IconButton` wrapper. See [Component Creation Workflows](./best-practices/component-creation-workflows.md) for when to extract wrapper components.
+
+9. **What are the costs of design system drift?**
+   Drift compounds: inconsistent appearance, inconsistent behavior, theme failures, and accessibility gaps (see [Accessibility](./best-practices/accessibility.md)). Custom components often miss accessibility features that system components provide. See [Testing and Storybook](./best-practices/testing-and-storybook.md) for catching drift through visual regression testing.
+
+10. **How do I audit a codebase for design system compliance?**
+    Search for: arbitrary values in Tailwind (`text-[`, `bg-[`), `!important` usages, inline `style` props, components that duplicate system functionality. See [Codebase Conventions](./best-practices/codebase-conventions.md) for establishing linting and review processes that catch drift early.
+
+---
+
+### 6. responsive-behavior.md
+
+**Current Title:** "Responsive Behavior"
+
+**Suggested Title:** "Responsive Design Systems: Fluid Typography, Breakpoint Strategy, and Adaptive Images"
+
+**Current Description:** "Responsiveness isn't about breakpoints—it's about strategy. Learn fluid vs. stepped approaches, and how to unify typography, spacing, and images into a coherent responsive system."
+
+**Suggested Description:** "Stop adding breakpoints at random. Learn fluid vs. stepped responsive strategies, clamp() typography, srcset images, and when breakpoints actually matter."
+
+**Current Keywords:**
+```
+responsive design, breakpoints, fluid design, responsive typography, responsive images, tailwind responsive, mobile-first
+```
+
+**Suggested Keywords:**
+```
+responsive design strategy,
+fluid typography clamp,
+tailwind breakpoints best practices,
+mobile first css,
+responsive images srcset sizes,
+css container queries,
+responsive spacing system,
+breakpoint strategy frontend
+```
+
+**Suggested FAQs:**
+
+1. **How many breakpoints do I actually need?**
+   Most layouts need 1-2 meaningful breakpoints, not 5. Add breakpoints only when layout structure genuinely changes (single column to multi-column, navigation collapse). Don't add breakpoints for minor spacing tweaks. See [Component Creation Workflows](./best-practices/component-creation-workflows.md) for keeping component complexity manageable.
+
+2. **When should I use fluid typography with clamp()?**
+   Use `clamp()` for headings and display text where smooth scaling improves visual rhythm across viewports. Keep body text and UI elements (buttons, labels) at fixed sizes for consistent readability and touch targets—especially important for [Accessibility](./best-practices/accessibility.md).
+
+3. **What's the difference between fluid and stepped responsive design?**
+   Fluid: values scale continuously with viewport (using vw units, clamp()). Stepped: values jump at specific breakpoints. Most production systems are hybrid—fluid typography within ranges, stepped layout changes at major breakpoints. See [Design System Consumption](./best-practices/design-system-consumption.md) for token-based approaches.
+
+4. **Should I use mobile-first or desktop-first CSS?**
+   Mobile-first for most projects—it forces content prioritization and aligns with Tailwind's default modifiers (`sm:`, `md:`, `lg:` add styles as viewport grows). Desktop-first only if 70%+ of your audience uses desktop. For layout shift concerns, see [Performance Optimization](./ui-systems-performance/performance-optimization.md).
+
+5. **How do I handle responsive images correctly?**
+   Use `srcset` and `sizes` for resolution switching (same image, different file sizes for different viewports). Use `<picture>` for art direction. Always include `width` and `height` attributes to prevent layout shift (CLS). See [Performance Optimization](./ui-systems-performance/performance-optimization.md) for image performance patterns.
+
+6. **When do breakpoints actually matter vs. being unnecessary?**
+   Breakpoints matter when: layout fundamentally restructures (sidebar becomes bottom nav), content reorganizes (tabs become accordion), or interaction patterns change (hover becomes tap). For accessibility of these pattern changes, see [Accessibility](./best-practices/accessibility.md).
+
+7. **How do I test responsive behavior effectively?**
+   Test at edge viewports (320px, 375px, 768px, 1024px, 1440px) and between breakpoints (767px and 769px often reveal bugs). For visual regression testing across viewports, see [Testing and Storybook](./best-practices/testing-and-storybook.md). For production monitoring, see [Observability](./ui-systems-performance/observability.md).
+
+8. **Should spacing be fluid or use fixed tokens?**
+   Fixed tokens for component-internal spacing (padding, gaps)—these need consistent rhythm and touch targets. Viewport-relative or stepped spacing for section-level spacing. See [Design System Consumption](./best-practices/design-system-consumption.md) for token-only styling patterns.
+
+9. **How do container queries change responsive design?**
+   Container queries let components respond to their container's size, not the viewport. This enables truly reusable components—a Card can adapt based on whether it's in a sidebar or main content. See [Component Creation Workflows](./best-practices/component-creation-workflows.md) for component reusability patterns.
+
+10. **What's the "breakpoint trap" and how do I avoid it?**
+    The trap: adding `sm:`, `md:`, `lg:`, `xl:` variants to every property because breakpoints exist. Avoid it by: using fluid values where appropriate, questioning whether each breakpoint variant is necessary. See [Codebase Conventions](./best-practices/codebase-conventions.md) for establishing responsive design conventions.
+
+---
+
+### 7. accessibility.md
+
+**Current Title:** "Accessibility"
+
+**Suggested Title:** "Accessible React Components: Semantic HTML, ARIA Patterns, and Keyboard Navigation"
+
+**Current Description:** "Accessible components aren't an afterthought—they're a byproduct of good structure. Learn semantic HTML, ARIA patterns, keyboard navigation, and focus management."
+
+**Suggested Description:** "Accessibility isn't a checklist—it's architecture. Learn semantic HTML defaults, ARIA patterns, keyboard navigation, and focus management for React components."
+
+**Current Keywords:**
+```
+accessibility, a11y, aria, semantic html, keyboard navigation, focus management, screen readers
+```
+
+**Suggested Keywords:**
+```
+react accessibility best practices,
+semantic html components,
+aria attributes react,
+keyboard navigation react,
+focus management react,
+accessible component library,
+screen reader testing,
+wcag react components
+```
+
+**Suggested FAQs:**
+
+1. **When should I use ARIA attributes vs. semantic HTML?**
+   Semantic HTML first—always. A `<button>` is automatically focusable, keyboard-activatable, and announced correctly. Use ARIA only when native elements don't exist (custom tabs, comboboxes, live regions). See [Component API Design](./best-practices/component-api-design.md) for how props should expose semantic options, not implementation details.
+
+2. **What's the difference between `aria-label`, `aria-labelledby`, and `aria-describedby`?**
+   `aria-label`: provides accessible name as a string directly. `aria-labelledby`: references another element's ID for the accessible name. `aria-describedby`: provides supplementary description (like help text). Use `aria-labelledby` when the label is visible; `aria-label` for icon-only buttons.
+
+3. **How do I make icon-only buttons accessible?**
+   Three options: (1) visually hidden text with `sr-only` class, (2) `aria-label` on the button, (3) tooltip that also serves as accessible name. Always hide decorative icons with `aria-hidden="true"`. See [Design System Consumption](./best-practices/design-system-consumption.md) for how system components should handle this by default.
+
+4. **Should I remove focus outlines for better design?**
+   Never remove focus indicators entirely—they're essential for keyboard users. Use `:focus-visible` to show outlines only for keyboard navigation. See [Design System Consumption](./best-practices/design-system-consumption.md) for how focus styles should be defined in design tokens.
+
+5. **How do I implement keyboard navigation for custom components?**
+   Follow established patterns: Arrow keys for navigation within groups (menus, tabs), Enter/Space for activation, Escape to close overlays, Tab to move between interactive elements. See [Testing and Storybook](./best-practices/testing-and-storybook.md) for testing keyboard interactions in stories.
+
+6. **What's focus trapping and when do I need it?**
+   Focus trapping keeps keyboard focus inside a container (typically modals/dialogs). When a modal opens, Tab should cycle within the modal, not escape to the page behind. For state management of modal visibility, see [State Management at Scale](./ui-systems-performance/state-management-at-scale.md).
+
+7. **How do I handle focus management during navigation?**
+   When opening: move focus into the new surface (first focusable element or the container itself). When closing: return focus to the trigger element. For SPA navigation patterns, see [Performance Optimization](./ui-systems-performance/performance-optimization.md) for how navigation affects perceived performance.
+
+8. **What accessibility issues only appear at scale?**
+   Common at-scale issues: inconsistent heading hierarchy, duplicate IDs breaking label associations, inconsistent keyboard patterns between similar components. See [Codebase Conventions](./best-practices/codebase-conventions.md) for conventions that prevent these at-scale issues.
+
+9. **How do I test accessibility during development?**
+   Layers: (1) browser DevTools accessibility panel, (2) axe-core extension, (3) keyboard-only navigation testing, (4) screen reader testing. See [Testing and Storybook](./best-practices/testing-and-storybook.md) for integrating a11y testing into Storybook. For production monitoring, see [Observability](./ui-systems-performance/observability.md).
+
+10. **What's the 80/20 rule for accessibility?**
+    Approximately 80% of accessibility comes from using semantic HTML correctly—buttons, links, headings, lists, landmarks. The remaining 20% requires ARIA and JavaScript for complex interactions. See [Component Creation Workflows](./best-practices/component-creation-workflows.md) for choosing the right elements from the start.
+
+---
+
+### 8. codebase-conventions.md
+
+**Current Title:** "Codebase Conventions"
+
+**Suggested Title:** "Frontend Codebase Conventions: File Structure, Naming, and Patterns That Scale"
+
+**Current Description:** "Conventions aren't preferences—they're constraints that prevent failure modes. Learn file structure, naming patterns, and composition rules that scale."
+
+**Suggested Description:** "Conventions prevent failure modes, not just enforce style. Learn file structure, naming patterns, barrel exports, and composition rules that scale across teams."
+
+**Current Keywords:**
+```
+codebase conventions, file structure, naming conventions, code organization, frontend architecture, component organization, project structure
+```
+
+**Suggested Keywords:**
+```
+react project structure,
+frontend file organization,
+component naming conventions,
+barrel exports typescript,
+feature folder structure,
+react codebase architecture,
+monorepo component organization,
+frontend code conventions
+```
+
+**Suggested FAQs:**
+
+1. **Should I organize by feature or by type (components/, hooks/, utils/)?**
+   Feature-first for product code—each feature contains its components, hooks, and utilities together. Type-first only for truly shared code. See [Component Creation Workflows](./best-practices/component-creation-workflows.md) for when components should be local vs. shared.
+
+2. **What naming convention should I use for component files?**
+   PascalCase for component files and exports: `UserProfile.tsx` exports `function UserProfile`. Match filename to export exactly. Use `index.ts` only for re-exports, not as the component file itself. For prop naming, see [Component API Design](./best-practices/component-api-design.md).
+
+3. **Are barrel files (index.ts re-exports) good or bad?**
+   It depends. Good for public APIs (design system packages where you control the interface). Often harmful for application code—they defeat tree-shaking, create circular dependency risks. For performance implications, see [Performance Optimization](./ui-systems-performance/performance-optimization.md).
+
+4. **How do I know if a convention matters or is just preference?**
+   Conventions matter if violating them causes: bugs, confusion for new developers, maintenance burden, or failure modes. "Colocate tests with source files" prevents orphaned tests—see [Testing and Storybook](./best-practices/testing-and-storybook.md) for test organization patterns.
+
+5. **What's the component folder pattern and when should I use it?**
+   Each component gets a folder: `ComponentName/ComponentName.tsx`, `ComponentName.test.tsx`, `ComponentName.stories.tsx`, `index.ts`. Use it when components have related files. See [Testing and Storybook](./best-practices/testing-and-storybook.md) for colocating stories.
+
+6. **How do I prevent naming conflicts across features?**
+   Use specific, namespaced names: `ProductCard`, `UserCard` instead of just `Card` in different features. If both features need a generic Card, it belongs in shared components. See [Design System Consumption](./best-practices/design-system-consumption.md) for design system component naming.
+
+7. **Where should TypeScript types live?**
+   Colocate types with the code that uses them when possible. Shared types belong in a central `types/` folder. See [Data Contracts](./best-practices/data-contracts.md) for organizing data types and [Component API Design](./best-practices/component-api-design.md) for prop types.
+
+8. **What file structure patterns prevent circular dependencies?**
+   Layered architecture: higher layers import from lower, never the reverse. Features don't import from each other—shared code lives in a common layer. See [Data Contracts](./best-practices/data-contracts.md) for keeping mapping layers independent.
+
+9. **How do I enforce conventions across a team?**
+   Multiple layers: (1) ESLint/Prettier for automated enforcement, (2) documented conventions in the repository, (3) code review checklist, (4) file structure linting. See [Design System Consumption](./best-practices/design-system-consumption.md) for linting design token usage.
+
+10. **What happens when conventions conflict with rapid development?**
+    Conventions save time in the long run but can slow initial development. For rapid prototyping: relax conventions temporarily but schedule cleanup. See [Testing and Storybook](./best-practices/testing-and-storybook.md) for how stories can capture intended patterns even during rapid development.
+
+---
+
+### 9. testing-and-storybook.md
+
+**Current Title:** "Testing and Storybook Contracts"
+
+**Suggested Title:** "Storybook as a Contract Layer: Fixtures, Visual Testing, and Executable Specifications"
+
+**Current Description:** "Stories aren't just visual documentation—they're executable contracts. Learn how to use Storybook as a verification layer with deterministic fixtures and clear data boundaries."
+
+**Suggested Description:** "Stories aren't documentation—they're contracts. Learn deterministic fixtures, visual regression testing, and how Storybook becomes your component verification layer."
+
+**Current Keywords:**
+```
+storybook, component testing, visual testing, fixtures, test contracts, frontend testing, react storybook
+```
+
+**Suggested Keywords:**
+```
+storybook testing best practices,
+visual regression testing storybook,
+storybook fixtures patterns,
+component story format csf,
+chromatic visual testing,
+storybook interaction testing,
+deterministic test data,
+storybook as documentation
+```
+
+**Suggested FAQs:**
+
+1. **What's the difference between stories and unit tests?**
+   Stories verify visual output and behavior for specific prop combinations—they're executable specifications of "what this looks like." Unit tests verify logic and edge cases programmatically. For component logic that needs unit testing, see how [Data Contracts](./best-practices/data-contracts.md) recommends testing mapping layers.
+
+2. **Should I use random data (faker) in Storybook fixtures?**
+   No for production stories. Random data breaks visual regression tests, makes debugging harder, and prevents reproducibility. Use deterministic fixtures with factory functions. See [Data Contracts](./best-practices/data-contracts.md) for how fixtures should mirror real data shapes.
+
+3. **How do I create deterministic fixtures for stories?**
+   Create factory functions: `const mockUser = (overrides = {}) => ({ id: 'user-1', name: 'Jane Smith', avatar: '/fixtures/avatar.png', ...overrides })`. See [Codebase Conventions](./best-practices/codebase-conventions.md) for organizing fixtures alongside components.
+
+4. **How many stories should each component have?**
+   Cover: (1) default/primary state, (2) all visual variants (see [Component API Design](./best-practices/component-api-design.md)), (3) key interactive states (loading, error, empty), (4) edge cases (long text, missing optional data). Focus on states users actually encounter.
+
+5. **How do I test user interactions in Storybook?**
+   Use the `play` function with `@storybook/testing-library`. Test keyboard interactions for [Accessibility](./best-practices/accessibility.md). Write interactions that click, type, and assert—these run automatically and catch behavior regressions.
+
+6. **When should I use Chromatic vs. local Storybook testing?**
+   Local Storybook for development iteration—see changes immediately. Chromatic (or Percy) for CI visual regression testing. For production monitoring beyond CI, see [Observability](./ui-systems-performance/observability.md).
+
+7. **What's the relationship between stories and data contracts?**
+   Story fixtures should reflect real data shapes—the post-mapping shape that components actually receive. See [Data Contracts](./best-practices/data-contracts.md) for mapping layer patterns. Stories test the component contract, not the API contract.
+
+8. **How do I organize stories for complex components?**
+   Group by category: Primary use cases first, then states (loading, error, disabled), then sizes/variants, then edge cases. See [Codebase Conventions](./best-practices/codebase-conventions.md) for file organization patterns.
+
+9. **Should stories be documentation or tests?**
+   Both. Stories document supported states and verify those states remain stable. The shift from "documentation mindset" to "contract mindset" is key. See [Component API Design](./best-practices/component-api-design.md) for how stories demonstrate the component's API contract.
+
+10. **How do I prevent stories from becoming stale?**
+    Keep stories close to components (see [Codebase Conventions](./best-practices/codebase-conventions.md) for colocation patterns). Use TypeScript for story args so prop changes surface in stories. See [Accessibility](./best-practices/accessibility.md) for accessibility checks that should run on every story.
+
+---
+
+## UI Systems Performance Series (11 Documents)
+
+---
+
+### 1. introduction.md
+
+**Current Title:** "System Design & Architecture: An Introduction"
+
+**Suggested Title:** "Frontend Systems Design: Distributed Systems Thinking for Web Applications"
+
+**Current Description:** "A 10-part series that reframes frontend development through a systems design lens, covering state management, caching, performance, security, and more."
+
+**Suggested Description:** "Frontend apps are distributed systems. This 10-part series covers state replication, caching, async patterns, security, and performance from a systems design perspective."
+
+**Current Keywords:**
+```
+frontend systems design, distributed systems, frontend architecture, systems thinking, web development, system design
+```
+
+**Suggested Keywords:**
+```
+frontend systems design,
+distributed systems frontend,
+frontend architecture patterns,
+web application architecture,
+systems thinking javascript,
+frontend system design interview,
+browser as distributed system,
+frontend engineering principles
+```
+
+**Suggested FAQs:**
+
+1. **Why should frontend developers learn systems design?**
+   The browser is a distributed system—it replicates server data, handles network partitions (offline mode), and resolves conflicts when state diverges. See [State Management at Scale](./ui-systems-performance/state-management-at-scale.md) for replication patterns and [Consistency and Failure Handling](./ui-systems-performance/consistency-and-failure-handling.md) for offline-first architecture.
+
+2. **How is frontend systems design different from backend?**
+   Same problems, different constraints. Backend optimizes for throughput and correctness. Frontend must optimize for correctness under perception and latency—see [Human Perception](./ui-systems-performance/human-perception.md) for why a 500ms block feels broken even when metrics are "acceptable."
+
+3. **Is this series for junior or senior developers?**
+   Both benefit differently. Juniors get mental models for concepts they're already using ([State Management](./ui-systems-performance/state-management-at-scale.md), [Caching](./ui-systems-performance/caching-strategies.md), [Async Operations](./ui-systems-performance/asynchronous-operations.md)). Seniors get a structured framework for trade-offs they've learned through experience.
+
+4. **Do I need to read the series in order?**
+   The series builds progressively, with [Human Perception](./ui-systems-performance/human-perception.md) as the capstone. But each document stands alone. Start with your current pain point: async bugs → [Asynchronous Operations](./ui-systems-performance/asynchronous-operations.md), performance → [Performance Optimization](./ui-systems-performance/performance-optimization.md).
+
+5. **What's the "perception gap" mentioned in the introduction?**
+   The gap between technical metrics (LCP 2.5s, API 200ms) and user experience ("this feels sluggish"). See [Human Perception](./ui-systems-performance/human-perception.md) for perception budgets and [Observability](./ui-systems-performance/observability.md) for measuring what users actually experience.
+
+6. **How do these concepts apply to my specific framework (React, Vue, Svelte)?**
+   The systems concepts—state replication, caching, failure handling—are framework-agnostic. For framework-specific component patterns, see the [Best Practices series](./best-practices/introduction.md) which covers React examples that apply to any component model.
+
+7. **Is this relevant for simple websites or only complex web apps?**
+   Even simple sites face these issues: caching decisions (see [Caching Strategies](./ui-systems-performance/caching-strategies.md)), loading states (see [Human Perception](./ui-systems-performance/human-perception.md)), error handling (see [Consistency and Failure Handling](./ui-systems-performance/consistency-and-failure-handling.md)). The principles apply universally.
+
+8. **How does this relate to backend system design interviews?**
+   Frontend system design is increasingly part of technical interviews. Understanding replication (see [State Management](./ui-systems-performance/state-management-at-scale.md)), caching (see [Caching Strategies](./ui-systems-performance/caching-strategies.md)), and failure handling prepares you for these discussions with frontend-specific depth.
+
+9. **What tools or libraries implement these concepts?**
+   TanStack Query implements caching and revalidation patterns (see [Caching Strategies](./ui-systems-performance/caching-strategies.md)). Zustand/Redux implement state management (see [State Management at Scale](./ui-systems-performance/state-management-at-scale.md)). Understanding the underlying concepts helps you use these tools correctly.
+
+10. **How does Bitloops relate to these systems concepts?**
+    Bitloops generates code that applies these concepts by default: proper loading states (see [Human Perception](./ui-systems-performance/human-perception.md)), data contracts (see [Data Contracts](./best-practices/data-contracts.md)), accessible components (see [Accessibility](./best-practices/accessibility.md)).
+
+---
+
+### 2. state-management-at-scale.md
+
+**Current Title:** "State Management at Scale"
+
+**Suggested Title:** "State Management as Replication: Sources of Truth, Sync, and Conflict Resolution"
+
+**Current Description:** "Understanding state management as replication design - keeping client replicas synchronized with server sources of truth."
+
+**Suggested Description:** "State management isn't Redux vs. Zustand—it's replication design. Learn sources of truth, client-server sync, cross-tab coordination, and conflict resolution patterns."
+
+**Current Keywords:**
+```
+state management, redux, zustand, react state, global state, state synchronization, frontend state
+```
+
+**Suggested Keywords:**
+```
+react state management patterns,
+frontend state architecture,
+client server state sync,
+zustand vs redux vs tanstack query,
+cross tab state synchronization,
+state replication frontend,
+optimistic state updates,
+source of truth frontend
+```
+
+**Suggested FAQs:**
+
+1. **What are the four sources of truth in frontend applications?**
+   (1) Server: authoritative data (user profile, products). (2) URL: navigation state, shareable app state. (3) Local Storage/IndexedDB: persisted client state. (4) Memory: transient UI state. For caching server state, see [Caching Strategies](./ui-systems-performance/caching-strategies.md). For offline persistence, see [Consistency and Failure Handling](./ui-systems-performance/consistency-and-failure-handling.md).
+
+2. **What's the difference between server state and client state?**
+   Server state needs synchronization (user data, products, orders)—see [Caching Strategies](./ui-systems-performance/caching-strategies.md). Client state is UI-only (modal visibility, accordion expansion). For how this affects component design, see [Component API Design](./best-practices/component-api-design.md).
+
+3. **When should I use Redux vs. Zustand vs. TanStack Query?**
+   TanStack Query (or SWR) for server state—see [Caching Strategies](./ui-systems-performance/caching-strategies.md) for caching patterns. Zustand or Redux for complex client state. useState/useReducer for local component state. Most apps need all three patterns, not one "winner."
+
+4. **How do I keep state synchronized across browser tabs?**
+   Use BroadcastChannel API (modern) or localStorage events (legacy) for cross-tab communication. Critical for: auth state (see [Security Boundaries](./ui-systems-performance/security-boundaries.md)), cart/selection state, real-time data. Don't sync everything—only state users expect to be consistent.
+
+5. **What is "state tearing" and how do I prevent it?**
+   State tearing occurs when a React render uses inconsistent state because an external store updated mid-render. `useSyncExternalStore` (React 18+) solves this. For related async state issues, see [Asynchronous Operations](./ui-systems-performance/asynchronous-operations.md).
+
+6. **What's the difference between optimistic updates and server state caching?**
+   Caching stores server responses for later reuse (see [Caching Strategies](./ui-systems-performance/caching-strategies.md)). Optimistic updates show expected results before confirmation (see [Consistency and Failure Handling](./ui-systems-performance/consistency-and-failure-handling.md) for when to use optimistic vs. pessimistic patterns).
+
+7. **How do I handle conflicts when local and server state diverge?**
+   Strategies: last-write-wins, server-authoritative, merge, or user-mediated conflict UI. See [Consistency and Failure Handling](./ui-systems-performance/consistency-and-failure-handling.md) for reconciliation strategies and [Human Perception](./ui-systems-performance/human-perception.md) for communicating conflicts to users.
+
+8. **When should state live in the URL vs. in memory?**
+   URL state for: navigation, shareable application state (search filters, pagination). Memory for: transient UI state. For performance implications of URL state, see [Performance Optimization](./ui-systems-performance/performance-optimization.md).
+
+9. **How do I debug state management issues?**
+   Use dev tools: Redux DevTools, React DevTools, TanStack Query DevTools. Log state transitions. For production debugging, see [Observability](./ui-systems-performance/observability.md) for correlation IDs and distributed tracing.
+
+10. **What causes "stale closure" bugs in state management?**
+    Closures capture state values at creation time. Related: race conditions in async operations—see [Asynchronous Operations](./ui-systems-performance/asynchronous-operations.md) for commit guards and request cancellation patterns that prevent stale data issues.
+
+---
+
+### 3. caching-strategies.md
+
+**Current Title:** "Caching Strategies"
+
+**Suggested Title:** "Frontend Caching: Browser Cache Stack, Invalidation Strategies, and Security Boundaries"
+
+**Current Description:** "Cache lifecycle design - understanding when stale data is acceptable, invalidation strategies, and cache layers in frontend applications."
+
+**Suggested Description:** "Every cache is a bet. Learn the browser cache stack (memory, HTTP, Service Worker, CDN), stale-while-revalidate, cache invalidation, and security implications."
+
+**Current Keywords:**
+```
+caching, cache invalidation, http cache, service worker cache, frontend caching, stale while revalidate, cache strategies
+```
+
+**Suggested Keywords:**
+```
+frontend caching strategy,
+browser cache explained,
+stale while revalidate pattern,
+service worker cache api,
+http cache headers frontend,
+cache invalidation strategies,
+tanstack query cache,
+indexeddb caching patterns
+```
+
+**Suggested FAQs:**
+
+1. **What are the layers of the browser cache stack?**
+   From fastest to slowest: (1) Memory/application cache. (2) HTTP cache. (3) Service Worker cache. (4) CDN/edge cache (see [Distributed Systems](./ui-systems-performance/distributed-systems.md)). (5) Origin server. Each layer trades freshness for speed. For HTTP headers, see [Network Protocols](./ui-systems-performance/network-protocols.md).
+
+2. **What's the difference between no-cache and no-store?**
+   `no-cache`: browser can store but must revalidate. `no-store`: browser must not store at all. Use `no-store` for sensitive data—see [Security Boundaries](./ui-systems-performance/security-boundaries.md) for token storage patterns. For header syntax, see [Network Protocols](./ui-systems-performance/network-protocols.md).
+
+3. **When should I use stale-while-revalidate?**
+   When showing slightly stale data is acceptable while fetching fresh data in background. For user-facing implications, see [Human Perception](./ui-systems-performance/human-perception.md) for how staleness affects perceived performance. Bad for: inventory counts, prices at checkout.
+
+4. **How do I invalidate cached data when it changes?**
+   Strategies: (1) Time-based (TTL). (2) Event-based via WebSocket/SSE—see [Network Protocols](./ui-systems-performance/network-protocols.md). (3) Version-based URLs—see [Distributed Systems](./ui-systems-performance/distributed-systems.md) for CDN invalidation. Choose based on freshness requirements.
+
+5. **Should I cache API responses in JavaScript or rely on HTTP cache?**
+   Both—they're complementary. HTTP cache handles the network layer (see [Network Protocols](./ui-systems-performance/network-protocols.md)). JavaScript cache (TanStack Query, SWR) handles application layer. For state management integration, see [State Management at Scale](./ui-systems-performance/state-management-at-scale.md).
+
+6. **What are the security risks of caching?**
+   Major risks: caching authenticated responses, sensitive data persisting after logout, cross-user data leakage. See [Security Boundaries](./ui-systems-performance/security-boundaries.md) for token storage and [Distributed Systems](./ui-systems-performance/distributed-systems.md) for CDN security considerations.
+
+7. **How does cache invalidation work with immutable assets?**
+   Immutable assets (JS, CSS with content hashes) can be cached forever (`max-age=31536000, immutable`). When content changes, the filename changes. For bundle optimization, see [Performance Optimization](./ui-systems-performance/performance-optimization.md).
+
+8. **What's cache key fragmentation and why does it matter?**
+   Cache keys determine what's cached separately. Too many key factors fragment the cache—low hit rates, high storage. See [Distributed Systems](./ui-systems-performance/distributed-systems.md) for CDN cache key design.
+
+9. **How do I cache for offline support?**
+   Service Worker + Cache API for static assets and API responses. IndexedDB for structured data. See [Consistency and Failure Handling](./ui-systems-performance/consistency-and-failure-handling.md) for offline-first architecture patterns.
+
+10. **What's the cost model for caching decisions?**
+    Every cache is a bet: cost of serving stale data vs. cost of fetching fresh data. For how staleness affects user experience, see [Human Perception](./ui-systems-performance/human-perception.md). For measuring cache effectiveness, see [Observability](./ui-systems-performance/observability.md).
+
+---
+
+### 4. asynchronous-operations.md
+
+**Current Title:** "Asynchronous Operations"
+
+**Suggested Title:** "Async Operations in React: Race Conditions, Cancellation, and Commit Guards"
+
+**Current Description:** "Handling race conditions, operation scopes, and commit guards to prevent async bugs in frontend applications."
+
+**Suggested Description:** "Async bugs are state bugs—stale results overwriting fresh data. Learn operation scopes, commit guards, request cancellation, and deduplication patterns."
+
+**Current Keywords:**
+```
+async operations, race conditions, abort controller, async state, promises, concurrent requests, async patterns
+```
+
+**Suggested Keywords:**
+```
+react race condition fix,
+abort controller react,
+async state management,
+request deduplication pattern,
+stale closure react,
+cancel fetch request,
+async operation lifecycle,
+concurrent request handling
+```
+
+**Suggested FAQs:**
+
+1. **What causes race conditions in React components?**
+   Race conditions occur when async operations complete in different order than they started. User types "abc", then "ab"—if the "abc" search returns after "ab", you display wrong results. Related: [State Management at Scale](./ui-systems-performance/state-management-at-scale.md) for state consistency patterns.
+
+2. **How do I cancel fetch requests when a component unmounts?**
+   Use AbortController: create a controller, pass its signal to fetch, call controller.abort() in useEffect cleanup. For fetch patterns and timeouts, see [Network Protocols](./ui-systems-performance/network-protocols.md).
+
+3. **What's a commit guard and when do I need one?**
+   A commit guard verifies that an async result is still relevant before applying it to state. Compare request timestamps, version numbers, or request IDs. Related: [Consistency and Failure Handling](./ui-systems-performance/consistency-and-failure-handling.md) for version-based conflict resolution.
+
+4. **How do I deduplicate identical API requests?**
+   Store pending promises by request key. If a request with the same key is already in flight, return the existing promise. TanStack Query and SWR do this automatically—see [Caching Strategies](./ui-systems-performance/caching-strategies.md) for application-level caching patterns.
+
+5. **What's the difference between cancellation and ignoring stale results?**
+   Cancellation (AbortController) stops the network request—saves bandwidth, frees connections. Ignoring just discards results client-side. For network cost considerations, see [Performance Optimization](./ui-systems-performance/performance-optimization.md).
+
+6. **How do I handle dependent async operations (A must complete before B)?**
+   Use async/await for sequential operations. For complex dependency chains, consider state machines (XState). For perceived performance during multi-step operations, see [Human Perception](./ui-systems-performance/human-perception.md).
+
+7. **What are operation scopes and why do they matter?**
+   Operation scope is the context in which an async result is valid. A search result is scoped to the query that produced it. When scope changes, results from old scope should be discarded. Related: [State Management at Scale](./ui-systems-performance/state-management-at-scale.md) for sources of truth.
+
+8. **How do I implement retry with exponential backoff?**
+   On failure, wait before retrying: delay = baseDelay * 2^attempt + random jitter. Only retry transient failures (5xx, network errors)—see [Network Protocols](./ui-systems-performance/network-protocols.md) for which HTTP errors are retryable.
+
+9. **What's the difference between throttling and debouncing?**
+   Throttle: execute at most once per interval (rate limiting). Debounce: execute only after activity stops for an interval. For how this affects perceived responsiveness, see [Human Perception](./ui-systems-performance/human-perception.md).
+
+10. **How do I debug async state corruption?**
+    Add logging with timestamps and operation IDs. For production debugging, see [Observability](./ui-systems-performance/observability.md) for correlation IDs and distributed tracing that connects frontend operations to backend requests.
+
+---
+
+### 5. performance-optimization.md
+
+**Current Title:** "Performance Optimization"
+
+**Suggested Title:** "Frontend Performance: Core Web Vitals, Critical Path, and Resource Optimization"
+
+**Current Description:** "Resource allocation under constraints - shipping less, scheduling better, and rendering less for optimal frontend performance."
+
+**Suggested Description:** "Performance is a constraint, not a feature. Learn the critical rendering path, Core Web Vitals optimization, bundle splitting, and rendering performance patterns."
+
+**Current Keywords:**
+```
+performance, core web vitals, lcp, inp, cls, bundle size, rendering performance, frontend optimization
+```
+
+**Suggested Keywords:**
+```
+frontend performance optimization,
+core web vitals optimization,
+react performance best practices,
+javascript bundle size reduction,
+largest contentful paint improve,
+interaction to next paint fix,
+cumulative layout shift prevent,
+critical rendering path
+```
+
+**Suggested FAQs:**
+
+1. **What are Core Web Vitals and what scores should I target?**
+   LCP (Largest Contentful Paint): < 2.5s measures loading. INP (Interaction to Next Paint): < 200ms measures interactivity. CLS (Cumulative Layout Shift): < 0.1 measures visual stability. For monitoring these in production, see [Observability](./ui-systems-performance/observability.md). For how metrics relate to user experience, see [Human Perception](./ui-systems-performance/human-perception.md).
+
+2. **What's the critical rendering path and why does it matter?**
+   The sequence of steps before the first pixel: HTML parsing → DOM, CSS parsing → CSSOM, JavaScript execution, render tree → layout → paint. For CDN delivery optimization, see [Distributed Systems](./ui-systems-performance/distributed-systems.md). For network layer details, see [Network Protocols](./ui-systems-performance/network-protocols.md).
+
+3. **How do I reduce my JavaScript bundle size?**
+   Strategies: code splitting with dynamic imports, tree shaking, analyze with webpack-bundle-analyzer. For how bundle size affects loading experience, see [Human Perception](./ui-systems-performance/human-perception.md). For caching strategies for static assets, see [Caching Strategies](./ui-systems-performance/caching-strategies.md).
+
+4. **What causes layout shift (CLS) and how do I fix it?**
+   Causes: images without dimensions, fonts that swap and resize, dynamically injected content. For responsive image patterns, see [Responsive Behavior](./best-practices/responsive-behavior.md). Layout stability directly affects perceived performance—see [Human Perception](./ui-systems-performance/human-perception.md).
+
+5. **What's the difference between lab and field performance metrics?**
+   Lab metrics: controlled synthetic tests (Lighthouse). Field metrics: real users on real devices (RUM). See [Observability](./ui-systems-performance/observability.md) for RUM implementation. They often differ significantly—optimize for field, gate on lab.
+
+6. **Should I use React.memo and useMemo everywhere?**
+   No. Memoization has overhead. Use when: component re-renders frequently with same props, computation is genuinely expensive, you've profiled and confirmed the benefit. For state management patterns that reduce unnecessary renders, see [State Management at Scale](./ui-systems-performance/state-management-at-scale.md).
+
+7. **How do I optimize images for performance?**
+   Use modern formats (WebP, AVIF). Serve appropriate sizes with srcset/sizes—see [Responsive Behavior](./best-practices/responsive-behavior.md). Lazy load below-fold images. Use `fetchpriority="high"` for LCP images. Consider blur placeholders for perceived performance—see [Human Perception](./ui-systems-performance/human-perception.md).
+
+8. **What's the performance pipeline model?**
+   Five stages: Delivery (see [Network Protocols](./ui-systems-performance/network-protocols.md)), Boot, Render, Interact, Update. Every optimization maps to a stage. Ship less (delivery), schedule better (boot), render less (render/update). For CDN optimization of delivery, see [Distributed Systems](./ui-systems-performance/distributed-systems.md).
+
+9. **How do I set performance budgets?**
+   Derive from constraints: target device, target network, target UX (LCP < 2.5s). Convert to byte budgets. Enforce in CI. For monitoring budget adherence in production, see [Observability](./ui-systems-performance/observability.md). For perception thresholds, see [Human Perception](./ui-systems-performance/human-perception.md).
+
+10. **What's the most common performance mistake in React apps?**
+    Over-fetching and under-caching. See [Caching Strategies](./ui-systems-performance/caching-strategies.md) for proper caching patterns. See [Asynchronous Operations](./ui-systems-performance/asynchronous-operations.md) for request deduplication. Profile before optimizing render performance.
+
+---
+
+### 6. distributed-systems.md
+
+**Current Title:** "Distributed Systems (CDNs & Edge)"
+
+**Suggested Title:** "Edge Computing for Frontend: CDN Architecture, Cache Keys, and Execution Location"
+
+**Current Description:** "Understanding edge computing, CDN architecture, and where code should execute for optimal latency and user experience."
+
+**Suggested Description:** "Where should code execute—client, edge, or origin? Learn CDN cache architecture, cache key design, edge computing patterns, and latency optimization."
+
+**Current Keywords:**
+```
+cdn, edge computing, distributed systems, cache invalidation, edge functions, latency optimization, content delivery
+```
+
+**Suggested Keywords:**
+```
+cdn caching frontend,
+edge computing patterns,
+vercel edge functions,
+cloudflare workers frontend,
+cdn cache key design,
+origin shield cdn,
+edge vs serverless,
+global latency optimization
+```
+
+**Suggested FAQs:**
+
+1. **What's the execution spectrum: client vs. edge vs. origin?**
+   Client (browser): zero network latency, full browser APIs. Edge (CDN PoP): 10-50ms latency, limited runtime. Origin (your server): 50-300ms+ latency, full capabilities. For network layer details, see [Network Protocols](./ui-systems-performance/network-protocols.md). For client-side state, see [State Management at Scale](./ui-systems-performance/state-management-at-scale.md).
+
+2. **What's the difference between edge functions and serverless functions?**
+   Edge functions run at CDN nodes globally (low latency, constrained runtime). Serverless functions run in specific cloud regions (more compute, higher latency). For caching patterns at each layer, see [Caching Strategies](./ui-systems-performance/caching-strategies.md).
+
+3. **How do I design cache keys for personalized content?**
+   Include only factors that vary the response: country, language, A/B variant—not user ID. See [Caching Strategies](./ui-systems-performance/caching-strategies.md) for cache key fragmentation. For security implications, see [Security Boundaries](./ui-systems-performance/security-boundaries.md).
+
+4. **What is origin shield and when should I use it?**
+   Origin shield is a designated CDN PoP that consolidates requests to your origin. Protects origin from thundering herd. Related: [Caching Strategies](./ui-systems-performance/caching-strategies.md) for browser-level caching that further reduces origin load.
+
+5. **How do I invalidate CDN cache when content changes?**
+   Options: TTL expiration, purge API, surrogate keys, versioned URLs (most reliable). For browser cache invalidation, see [Caching Strategies](./ui-systems-performance/caching-strategies.md). For HTTP headers that control caching, see [Network Protocols](./ui-systems-performance/network-protocols.md).
+
+6. **When should content be cached at CDN vs. fetched fresh?**
+   CDN cache: static assets, public content with acceptable staleness. Fetch fresh: user-specific data, prices at checkout. For consistency requirements, see [Consistency and Failure Handling](./ui-systems-performance/consistency-and-failure-handling.md). For user perception of staleness, see [Human Perception](./ui-systems-performance/human-perception.md).
+
+7. **What are the security risks of CDN caching?**
+   Risks: cross-user data leakage, cache poisoning, sensitive data persisting. See [Security Boundaries](./ui-systems-performance/security-boundaries.md) for token storage patterns. Use `Cache-Control: private` for user-specific data—see [Network Protocols](./ui-systems-performance/network-protocols.md) for header syntax.
+
+8. **How do I debug CDN caching issues?**
+   Check response headers: cache status (HIT/MISS/BYPASS), Age, X-Cache headers. For production monitoring and debugging, see [Observability](./ui-systems-performance/observability.md). Test from multiple locations.
+
+9. **What's stale-while-revalidate at the CDN level?**
+   `Cache-Control: max-age=60, stale-while-revalidate=600`: serve cached response immediately, revalidate in background. See [Caching Strategies](./ui-systems-performance/caching-strategies.md) for application-level stale-while-revalidate. For how staleness affects user experience, see [Human Perception](./ui-systems-performance/human-perception.md).
+
+10. **How do I balance latency vs. consistency in distributed systems?**
+    Define per-resource. See [Consistency and Failure Handling](./ui-systems-performance/consistency-and-failure-handling.md) for consistency models. For performance implications, see [Performance Optimization](./ui-systems-performance/performance-optimization.md). For user perception of latency, see [Human Perception](./ui-systems-performance/human-perception.md).
+
+---
+
+### 7. network-protocols.md
+
+**Current Title:** "Network Protocols"
+
+**Suggested Title:** "HTTP for Frontend Developers: Methods, Caching Headers, CORS, and Failure Handling"
+
+**Current Description:** "HTTP as a contract - understanding methods, status codes, caching headers, CORS, and designing robust API requests."
+
+**Suggested Description:** "HTTP isn't just transport—it's a contract. Learn method semantics, status codes, Cache-Control headers, CORS preflight, and retry patterns for frontend applications."
+
+**Current Keywords:**
+```
+http, network protocols, cors, rest api, fetch, request design
+```
+
+**Suggested Keywords:**
+```
+http methods frontend,
+cors explained simply,
+fetch api best practices,
+cache control headers guide,
+http status codes frontend,
+retry with exponential backoff,
+preflight request cors,
+http 2 http 3 frontend
+```
+
+**Suggested FAQs:**
+
+1. **Why do HTTP method semantics matter for frontend?**
+   Methods have meaning beyond "send request." GET is cacheable (see [Caching Strategies](./ui-systems-performance/caching-strategies.md)); POST isn't. PUT is idempotent—see [Consistency and Failure Handling](./ui-systems-performance/consistency-and-failure-handling.md) for idempotency keys. Using wrong methods breaks caching and retry safety.
+
+2. **When does CORS preflight happen?**
+   Preflight (OPTIONS request) happens for "non-simple" requests: custom headers (Authorization), Content-Type other than form-urlencoded. For security implications of CORS, see [Security Boundaries](./ui-systems-performance/security-boundaries.md).
+
+3. **Why can't I read certain response headers in JavaScript?**
+   CORS restricts which headers JavaScript can access. For custom headers, the server must include them in `Access-Control-Expose-Headers`. For security context, see [Security Boundaries](./ui-systems-performance/security-boundaries.md). For caching headers, see [Caching Strategies](./ui-systems-performance/caching-strategies.md).
+
+4. **How should I implement retry logic for failed requests?**
+   Rules: retry only transient failures (5xx, network errors), use exponential backoff with jitter, set maximum retries. See [Asynchronous Operations](./ui-systems-performance/asynchronous-operations.md) for request cancellation. See [Consistency and Failure Handling](./ui-systems-performance/consistency-and-failure-handling.md) for idempotency keys to make retries safe.
+
+5. **What's the difference between HTTP/2 and HTTP/3?**
+   HTTP/2 multiplexes requests over single TCP connection. HTTP/3 uses QUIC (UDP-based), each stream independent. HTTP/3 performs better on lossy mobile networks. For CDN considerations, see [Distributed Systems](./ui-systems-performance/distributed-systems.md).
+
+6. **How do I use Cache-Control headers effectively?**
+   Common patterns: `max-age=31536000, immutable` for versioned static assets. `no-store` for sensitive data (see [Security Boundaries](./ui-systems-performance/security-boundaries.md)). See [Caching Strategies](./ui-systems-performance/caching-strategies.md) for application-level caching.
+
+7. **What's the difference between timeout, abort, and error in fetch?**
+   Timeout: you set via AbortController. Abort: you call manually. Error: network failure. fetch doesn't have built-in timeout—see [Asynchronous Operations](./ui-systems-performance/asynchronous-operations.md) for AbortController patterns.
+
+8. **How do connection costs affect frontend performance?**
+   New connection cost: DNS (20-120ms) + TCP handshake + TLS = 300-700ms. See [Performance Optimization](./ui-systems-performance/performance-optimization.md) for the critical rendering path. See [Distributed Systems](./ui-systems-performance/distributed-systems.md) for CDN edge locations that reduce latency.
+
+9. **When should I use WebSocket vs. Server-Sent Events vs. polling?**
+   WebSocket: bidirectional, real-time (chat). SSE: server→client only (notifications). For state synchronization over these protocols, see [State Management at Scale](./ui-systems-performance/state-management-at-scale.md). For cache invalidation via events, see [Caching Strategies](./ui-systems-performance/caching-strategies.md).
+
+10. **How do I debug network issues in production?**
+    Instrument with: request/response logging, timing data, correlation IDs. See [Observability](./ui-systems-performance/observability.md) for distributed tracing. Use Server-Timing header to expose backend timing. Monitor error rates by endpoint.
+
+---
+
+### 8. security-boundaries.md
+
+**Current Title:** "Security Boundaries"
+
+**Suggested Title:** "Frontend Security Architecture: XSS, CSRF, CSP, and Token Storage Patterns"
+
+**Current Description:** "Blast radius design for frontend security - XSS, CSRF, CSP, token storage, and minimizing attack impact."
+
+**Suggested Description:** "Security isn't prevention—it's blast radius design. Learn XSS mitigation, CSRF protection, Content Security Policy, and where to store JWT tokens in SPAs."
+
+**Current Keywords:**
+```
+security, xss, csrf, csp, authentication, token storage
+```
+
+**Suggested Keywords:**
+```
+frontend security best practices,
+xss prevention react,
+csrf protection spa,
+content security policy guide,
+jwt token storage spa,
+httponly cookie vs localstorage,
+same origin policy explained,
+oauth pkce spa
+```
+
+**Suggested FAQs:**
+
+1. **What's "blast radius design" for security?**
+   Security isn't just preventing attacks—it's minimizing damage when attacks succeed. Design layers of defense where each limits blast radius. For related failure handling patterns, see [Consistency and Failure Handling](./ui-systems-performance/consistency-and-failure-handling.md).
+
+2. **Where should I store JWT tokens in a React SPA?**
+   Recommended pattern: short-lived access tokens in memory, refresh tokens in HTTPOnly cookies with SameSite=Strict. For state management of auth state, see [State Management at Scale](./ui-systems-performance/state-management-at-scale.md) for cross-tab synchronization of logout.
+
+3. **What's the difference between XSS and CSRF?**
+   XSS: attacker injects code that runs in your site's context. CSRF: attacker tricks browser into making authenticated requests. For validating user input, see [Data Contracts](./best-practices/data-contracts.md) for validation boundaries.
+
+4. **Does HTTPOnly prevent XSS attacks?**
+   No. HTTPOnly prevents cookie theft but XSS can still make authenticated requests. HTTPOnly limits blast radius; it doesn't prevent XSS. For caching implications of authentication, see [Caching Strategies](./ui-systems-performance/caching-strategies.md).
+
+5. **How do I implement Content Security Policy (CSP)?**
+   Start with report-only mode to find violations. Remove inline scripts. Tighten progressively. For bundle optimization that reduces script sources, see [Performance Optimization](./ui-systems-performance/performance-optimization.md).
+
+6. **What's the SameSite cookie attribute?**
+   SameSite controls when cookies are sent cross-site. `Strict`: never sent cross-site. `Lax`: sent on top-level navigation. Use `Strict` for auth cookies. For related CORS patterns, see [Network Protocols](./ui-systems-performance/network-protocols.md).
+
+7. **How do I protect against third-party script risks?**
+   Third-party scripts run with your origin's privileges. Mitigations: Subresource Integrity (SRI), sandboxed iframes, strict CSP. For bundle size implications of third-party scripts, see [Performance Optimization](./ui-systems-performance/performance-optimization.md).
+
+8. **What's the principle of least privilege for frontend?**
+   Give each part of the system minimum necessary access: short-lived tokens, scoped API permissions, restricted CSP. For how this applies to component design, see [Component API Design](./best-practices/component-api-design.md) for limiting prop exposure.
+
+9. **How do I handle logout securely?**
+   Clear all auth state: memory tokens, HTTPOnly cookies (server-side), localStorage. Broadcast logout to other tabs—see [State Management at Scale](./ui-systems-performance/state-management-at-scale.md) for cross-tab communication. Server should invalidate refresh tokens.
+
+10. **What security headers should every frontend set?**
+    Essential headers: `Strict-Transport-Security`, `Content-Security-Policy`, `X-Frame-Options`, `X-Content-Type-Options: nosniff`. For caching headers, see [Network Protocols](./ui-systems-performance/network-protocols.md). For CDN header configuration, see [Distributed Systems](./ui-systems-performance/distributed-systems.md).
+
+---
+
+### 9. consistency-and-failure-handling.md
+
+**Current Title:** "Consistency Models & Failure Handling"
+
+**Suggested Title:** "Frontend Consistency: Optimistic UI, Offline-First Patterns, and Intent Preservation"
+
+**Current Description:** "Optimistic UI, intent preservation, offline-first patterns, and reconciliation strategies for resilient frontend applications."
+
+**Suggested Description:** "Networks fail. Users go offline. Learn optimistic UI, intent preservation with idempotency keys, offline queues, and reconciliation strategies for resilient frontends."
+
+**Current Keywords:**
+```
+consistency, failure handling, optimistic ui, offline first, error recovery
+```
+
+**Suggested Keywords:**
+```
+optimistic ui react,
+offline first web app,
+idempotency key frontend,
+intent preservation pattern,
+frontend error handling,
+conflict resolution frontend,
+eventual consistency ui,
+retry queue javascript
+```
+
+**Suggested FAQs:**
+
+1. **When should I use optimistic UI vs. wait for the server?**
+   Optimistic for reversible, low-stakes actions: likes, toggles, adding to cart. Pessimistic for irreversible, high-stakes actions: payment, delete. See [Human Perception](./ui-systems-performance/human-perception.md) for how optimism affects perceived responsiveness.
+
+2. **What's an idempotency key and why do I need one?**
+   A unique ID sent with mutations so the server can deduplicate retries. Without it: network fails → client retries → action happens twice. For retry patterns, see [Asynchronous Operations](./ui-systems-performance/asynchronous-operations.md). For HTTP method semantics, see [Network Protocols](./ui-systems-performance/network-protocols.md).
+
+3. **How do I preserve user intent when the network fails?**
+   Intent preservation pattern: persist intent locally (IndexedDB) before network attempt, apply optimistic UI, retry with backoff. See [Caching Strategies](./ui-systems-performance/caching-strategies.md) for offline caching patterns. See [Human Perception](./ui-systems-performance/human-perception.md)—intent preservation is "non-negotiable."
+
+4. **What's the difference between eventual and strong consistency?**
+   Strong consistency: every read reflects the most recent write. Eventual consistency: reads may be temporarily stale but converge. For caching implications, see [Caching Strategies](./ui-systems-performance/caching-strategies.md). For user perception of consistency, see [Human Perception](./ui-systems-performance/human-perception.md).
+
+5. **How do I handle version conflicts when multiple users edit the same data?**
+   Strategies: last-write-wins, server-authoritative, field-level merge, user-mediated. For state management patterns, see [State Management at Scale](./ui-systems-performance/state-management-at-scale.md). For communicating conflicts to users, see [Human Perception](./ui-systems-performance/human-perception.md).
+
+6. **What causes "time travel" bugs where UI shows older data?**
+   Race conditions where older responses arrive after newer ones. Fix: version-gating. See [Asynchronous Operations](./ui-systems-performance/asynchronous-operations.md) for commit guards. See [State Management at Scale](./ui-systems-performance/state-management-at-scale.md) for state consistency patterns.
+
+7. **How do I implement offline-first architecture?**
+   Layers: local persistence (IndexedDB), intent queue with idempotency keys, sync engine, conflict resolution. See [Caching Strategies](./ui-systems-performance/caching-strategies.md) for Service Worker patterns. See [State Management at Scale](./ui-systems-performance/state-management-at-scale.md) for sources of truth.
+
+8. **How do I communicate failure states to users?**
+   Match communication to failure type: transient → silent retry, recoverable → inline notification, persistent → change UI affordance. See [Human Perception](./ui-systems-performance/human-perception.md) for the six user-facing states every app should handle.
+
+9. **What's the "projection" mental model for state?**
+   State = projection of commands under unreliable delivery. This unifies optimistic UI, offline queues, retries, reconciliation. Related: [State Management at Scale](./ui-systems-performance/state-management-at-scale.md) for replication design.
+
+10. **How do I test failure handling in the frontend?**
+    Simulate failures: network throttling, mock API errors, disable network. For production monitoring of failure rates, see [Observability](./ui-systems-performance/observability.md). For testing component states, see [Testing and Storybook](./best-practices/testing-and-storybook.md) for error state stories.
+
+---
+
+### 10. observability.md
+
+**Current Title:** "Observability"
+
+**Suggested Title:** "Frontend Observability: RUM, Error Tracking, Distributed Tracing, and SLOs"
+
+**Current Description:** "Telemetry pipelines, Real User Monitoring, distributed tracing, and alerting strategies for frontend applications."
+
+**Suggested Description:** "You can't improve what you can't measure. Learn telemetry pipelines, Real User Monitoring, Core Web Vitals tracking, distributed tracing, and burn-rate alerting."
+
+**Current Keywords:**
+```
+observability, monitoring, rum, telemetry, alerting, distributed tracing
+```
+
+**Suggested Keywords:**
+```
+frontend observability guide,
+real user monitoring rum,
+frontend error tracking,
+distributed tracing frontend,
+core web vitals monitoring,
+sentry frontend setup,
+frontend slo sli,
+burn rate alerting
+```
+
+**Suggested FAQs:**
+
+1. **What's the difference between Real User Monitoring (RUM) and synthetic monitoring?**
+   RUM measures actual users on real devices—shows what users experience. Synthetic runs controlled tests (Lighthouse)—provides CI baselines. For performance metrics to track, see [Performance Optimization](./ui-systems-performance/performance-optimization.md). For how metrics relate to experience, see [Human Perception](./ui-systems-performance/human-perception.md).
+
+2. **What frontend SLIs (Service Level Indicators) should I track?**
+   Core SLIs: crash-free sessions (≥99.5%), error rate (&lt;0.5%), LCP p75 (&lt;2.5s), INP p75 (&lt;200ms), CLS p75 (&lt;0.1). For Core Web Vitals optimization, see [Performance Optimization](./ui-systems-performance/performance-optimization.md). For perception-based targets, see [Human Perception](./ui-systems-performance/human-perception.md).
+
+3. **How do I implement distributed tracing in the frontend?**
+   Generate trace IDs client-side, propagate via `traceparent` header. For HTTP header patterns, see [Network Protocols](./ui-systems-performance/network-protocols.md). For async operation tracing, see [Asynchronous Operations](./ui-systems-performance/asynchronous-operations.md).
+
+4. **What's burn-rate alerting and why is it better than threshold alerts?**
+   Burn rate measures how fast you're consuming error budget. Catches both spikes and slow leaks. For failure handling that affects error rates, see [Consistency and Failure Handling](./ui-systems-performance/consistency-and-failure-handling.md).
+
+5. **What should I NOT log in frontend telemetry?**
+   Never log: passwords, tokens, cookies, full URLs with query strings, free-form user input. See [Security Boundaries](./ui-systems-performance/security-boundaries.md) for sensitive data handling. Use allowlists (only log approved fields), not denylists.
+
+6. **How do I build a telemetry pipeline that doesn't impact performance?**
+   Buffer events in memory. Use sendBeacon for delivery. Use requestIdleCallback for non-critical telemetry. For performance budget implications, see [Performance Optimization](./ui-systems-performance/performance-optimization.md).
+
+7. **How do I correlate frontend errors with backend issues?**
+   Propagate correlation IDs: generate client-side, send in request headers. See [Network Protocols](./ui-systems-performance/network-protocols.md) for header patterns. See [Asynchronous Operations](./ui-systems-performance/asynchronous-operations.md) for tracking operation lifecycles.
+
+8. **What's the investigation ladder for frontend incidents?**
+   Step through: confirm user impact, identify regression start, narrow scope (browsers, devices), correlate to backend (trace IDs), reproduce, fix. For testing failure states, see [Testing and Storybook](./best-practices/testing-and-storybook.md).
+
+9. **How do I avoid alert fatigue?**
+   Use burn-rate alerts instead of threshold alerts. Every alert should have a runbook. Alert on user-impacting symptoms—see [Human Perception](./ui-systems-performance/human-perception.md) for what impacts user experience.
+
+10. **What observability tools should a frontend team use?**
+    Error tracking: Sentry, Bugsnag. RUM: web-vitals library. Synthetic: Lighthouse CI. Tracing: OpenTelemetry. For performance metrics to instrument, see [Performance Optimization](./ui-systems-performance/performance-optimization.md). For caching metrics, see [Caching Strategies](./ui-systems-performance/caching-strategies.md).
+
+---
+
+### 11. human-perception.md
+
+**Current Title:** "Human Perception"
+
+**Suggested Title:** "Perceived Performance: Loading States, Optimistic UI, and Perception Budgets"
+
+**Current Description:** "The capstone - understanding how technical metrics translate to perceived performance and user experience."
+
+**Suggested Description:** "A 2-second load can feel faster than 3 seconds. Learn perception budgets, phase-based delivery, skeleton screens, and the psychology of waiting in UI design."
+
+**Current Keywords:**
+```
+human perception, user experience, perceived performance, ux, loading states
+```
+
+**Suggested Keywords:**
+```
+perceived performance optimization,
+loading state ux patterns,
+skeleton screen best practices,
+optimistic ui patterns,
+perception budgets frontend,
+phase based page load,
+ux response time thresholds,
+psychological waiting time
+```
+
+**Suggested FAQs:**
+
+1. **Why does a 3-second load sometimes feel faster than 2 seconds?**
+   Perception depends on feedback, progress, and control—not just duration. A 3-second load with instant input acknowledgment, skeleton, and progressive content feels faster than 2 seconds of blank screen. For technical performance metrics, see [Performance Optimization](./ui-systems-performance/performance-optimization.md).
+
+2. **What are perception budgets?**
+   Time allocations for interaction phases: &lt;100ms for input acknowledgment, &lt;300ms for meaningful response, &lt;1s for critical content. For Core Web Vitals targets that align with these budgets, see [Performance Optimization](./ui-systems-performance/performance-optimization.md). For monitoring these, see [Observability](./ui-systems-performance/observability.md).
+
+3. **When should I use a skeleton screen vs. a spinner?**
+   Skeleton when layout is predictable and content-heavy. Spinner when layout varies or load is short (&lt;200ms). For testing loading states in Storybook, see [Testing and Storybook](./best-practices/testing-and-storybook.md). For preventing layout shift, see [Performance Optimization](./ui-systems-performance/performance-optimization.md).
+
+4. **Should I show a loading indicator immediately?**
+   No. Delay indicators by ~150ms. If the operation completes quickly, users never see the indicator. For async operation patterns that support this, see [Asynchronous Operations](./ui-systems-performance/asynchronous-operations.md).
+
+5. **What's phase-based delivery?**
+   Loading in stages with specific budgets: acknowledge input (&lt;100ms), stabilize layout (&lt;300ms), deliver critical content (&lt;1s). For network optimization that supports this, see [Performance Optimization](./ui-systems-performance/performance-optimization.md). For CDN delivery, see [Distributed Systems](./ui-systems-performance/distributed-systems.md).
+
+6. **How do I choose between optimistic and pessimistic UI?**
+   Match optimism to stakes. Low stakes + reversible → fully optimistic. High stakes + irreversible → pessimistic, wait for confirmation. For detailed patterns, see [Consistency and Failure Handling](./ui-systems-performance/consistency-and-failure-handling.md).
+
+7. **What's intent preservation and why is it "non-negotiable"?**
+   User input is durable before network. The user's work must never be lost due to network issues. Persist intents locally before attempting delivery. See [Consistency and Failure Handling](./ui-systems-performance/consistency-and-failure-handling.md) for idempotency keys. See [Caching Strategies](./ui-systems-performance/caching-strategies.md) for offline persistence.
+
+8. **How do I debug "feels slow" when metrics look fine?**
+   Check perception phases: Is input acknowledged within 100ms? Is there visible feedback within 300ms? See [Observability](./ui-systems-performance/observability.md) for RUM that captures real user experience. Check CLS—see [Performance Optimization](./ui-systems-performance/performance-optimization.md).
+
+9. **What are the universal user-facing states every app should handle?**
+   Six states: Idle, Working, Pending, Succeeded, Failed, Degraded. See [Testing and Storybook](./best-practices/testing-and-storybook.md) for creating stories that cover these states. See [Consistency and Failure Handling](./ui-systems-performance/consistency-and-failure-handling.md) for failure state patterns.
+
+10. **How does Human Perception connect to the rest of the systems series?**
+    Human Perception is the capstone. Every previous document's decisions affect perception: [State Management](./ui-systems-performance/state-management-at-scale.md) (does data feel fresh?), [Caching](./ui-systems-performance/caching-strategies.md) (does content feel instant?), [Async Operations](./ui-systems-performance/asynchronous-operations.md) (does UI feel responsive?), [Performance](./ui-systems-performance/performance-optimization.md) (do metrics reflect experience?), [Failure Handling](./ui-systems-performance/consistency-and-failure-handling.md) (does the system feel reliable?).
+
+---
+
+## Implementation Notes
+
+### How to Apply These Changes
+
+1. **Titles:** Update the `title:` field in each document's frontmatter
+2. **Descriptions:** Update the `description:` field (keep under 160 characters)
+3. **Keywords:** Replace the `keywords:` array in frontmatter
+4. **FAQs:** Add a `## Frequently Asked Questions` section before the Summary section in each document
+
+### FAQ Formatting for Structured Data
+
+Format FAQs as H3 questions for potential structured data extraction:
+
+```markdown
+## Frequently Asked Questions
+
+### When should I use optimistic UI vs. wait for the server?
+
+Optimistic for reversible, low-stakes actions (like, toggle, add to cart). Pessimistic for irreversible, high-stakes actions (payment, delete account). If rollback would confuse or harm the user, wait.
+
+### What's an idempotency key and why do I need one?
+
+A unique ID sent with mutations so the server can deduplicate retries...
+```
+
+### Keyword Format in Frontmatter
+
+Use multi-line array format for readability:
+
+```yaml
+keywords:
+  [
+    primary keyword phrase,
+    secondary keyword phrase,
+    long tail keyword one,
+    long tail keyword two,
+    tool or framework name,
+    problem statement keyword,
+    solution keyword,
+    comparison keyword,
+  ]
+```
+
+---
+
+*End of SEO metadata recommendations.*
diff --git a/documentation/docs/frontend-copilot/tutorials/learn-by-watching.md b/documentation/docs/frontend-copilot/tutorials/learn-by-watching.md
new file mode 100644
index 00000000..7c26875a
--- /dev/null
+++ b/documentation/docs/frontend-copilot/tutorials/learn-by-watching.md
@@ -0,0 +1,57 @@
+---
+sidebar_position: 1
+sidebar_label: Learn by Watching
+title: "Learn by Watching"
+description: "Long-form video walkthroughs that teach you Bitloops by building real UI components and pages."
+keywords:
+  [
+    bitloops tutorials,
+    video tutorials,
+    learn bitloops,
+    design to code walkthrough,
+    figma to react,
+  ]
+---
+
+# Learn by Watching
+
+## Tutorial: Create your first component (end-to-end)
+
+This is the fastest way to understand the Bitloops workflow in one sitting: **Import design → Add Designs to Project → Select ELements in Design View → Create Component → Attach Snapshots → Iterate → Build Parent Components**.
+
+### **Video**
+
+<iframe
+  width="560"
+  height="315"
+  src="https://www.youtube.com/watch?v=4HJFAI5r4ME"
+  title="YouTube video player"
+  frameborder="0"
+  allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
+  allowfullscreen>
+</iframe>
+
+### **What you’ll learn**
+
+- How to import figma pages and add designs to projects
+- How to selection elements in **Design View**
+- How to create a component and where it shows up in the **Components** tab
+- How snapshots represent both **instances** (same component, different data) and **variants** (state differences)
+- How to iterate using **Snapshot View ↔ Component View ↔ Code File**
+- When to add **Layout Containers** to make layout intent explicit
+
+### **Quick outline**
+1. Open a project (demo design)
+2. Select a frame or element group
+3. **Create Component**
+4. Attach snapshots
+5. Edit the `.tsx` file and validate in Component View
+6. Optional: add a Layout Container to fix grouping/layout
+
+---
+
+## Upcoming videos
+
+- **Building a production Button**
+- **Responsive components with viewport snapshots**
+- **Design-system consistency in real projects**
diff --git a/documentation/docs/frontend-copilot/ui-systems-performance/asynchronous-operations.md b/documentation/docs/frontend-copilot/ui-systems-performance/asynchronous-operations.md
new file mode 100644
index 00000000..e59cb2e7
--- /dev/null
+++ b/documentation/docs/frontend-copilot/ui-systems-performance/asynchronous-operations.md
@@ -0,0 +1,867 @@
+---
+sidebar_position: 4
+sidebar_label: Asynchronous Operations
+title: "Async Operations in React: Race Conditions, Cancellation, and Commit Guards"
+description: "Async bugs are state bugs—stale results overwriting fresh data. Learn operation scopes, commit guards, request cancellation, and deduplication patterns."
+keywords:
+  [
+    react race condition fix,
+    abort controller react,
+    async state management,
+    request deduplication pattern,
+    stale closure react,
+    cancel fetch request,
+    async operation lifecycle,
+    concurrent request handling,
+  ]
+---
+
+# Async without chaos
+
+JavaScript is single-threaded, but your application is not. Every fetch, every timer, every user interaction creates concurrent operations that can complete in any order. The question isn't whether you'll have race conditions—it's whether you'll handle them or let them corrupt your UI.
+
+Here's the insight that reframes how you think about async bugs: **async bugs are state bugs**. When async operations corrupt your UI, they do so by committing stale results to state. The fix isn't just "add AbortController"—it's ensuring that every async result commits only when it's still valid. This connects directly to *State Management at Scale*—ownership and consistency guarantees matter here too.
+
+## The browser's concurrency model
+
+Backend engineers design for concurrent access using locks, transactions, queues, and idempotency keys. Frontend faces the same problems with different primitives.
+
+**Concurrency vs. parallelism:** Parallelism means multiple things happening at the exact same time—multiple threads or cores. JavaScript has this only through Web Workers, which have restricted communication. Concurrency means multiple things in progress, interleaved on one thread. This is how async/await, Promises, and event handlers work. While waiting for a fetch, other code runs. Operations can complete in any order.
+
+The distinction matters. You don't need operating system synchronization primitives (semaphores, mutexes). But you do need to handle interleaving and ordering. And you can build coordination constructs—single-flight, queues, latest-wins gates—they just aren't built into the language.
+
+## What makes frontend unique
+
+**Single thread, multiple timelines.** One thread runs your code, but many async operations are in progress simultaneously, completing whenever the network or timer decides.
+
+**The user is the chaos monkey.** Users click rapidly, navigate mid-request, open multiple tabs, lose network connection, and regain it at unpredictable times.
+
+**Component lifecycles complicate everything.** Components mount, unmount, and re-render while requests are in flight. A response might arrive for a component that no longer exists.
+
+**User intent changes.** By the time a response arrives, the user may have moved on. They typed a new search query. They navigated to a different page. Their intent changed, but your response didn't know.
+
+## Ordering boundaries
+
+The event loop details (microtask vs. macrotask) are less important than understanding these ordering boundaries:
+
+| Boundary | What It Means | Design Implication |
+|----------|---------------|-------------------|
+| User events | User actions arrive in order but async consequences don't | User clicks A then B; A's response may arrive after B's |
+| Navigation transitions | Route change invalidates current intent | Pending requests become stale when route changes |
+| Component lifetimes | Mount/unmount define validity scope | Results for unmounted components should not commit |
+| Request/response identity | Each request has identity; response must match | Response for request A must not be committed if request B is now current |
+
+Focus on these boundaries, not microtask trivia.
+
+## Operation scopes: the core model
+
+This is the conceptual glue that ties all async patterns together.
+
+**Definition:** An operation scope is a boundary that owns async operations and determines their validity.
+
+A scope owns: abort controllers, request identifiers, retry state, and commit permissions. When a scope ends, it cancels children, drops queued work, and ignores late arrivals. Only results from an active scope should commit to state.
+
+**Common scopes:**
+
+| Scope Type | Lifecycle | Examples |
+|------------|-----------|----------|
+| Component | Mount → Unmount | Data fetching in a component |
+| Route | Navigation start → Navigation away | Page-level data loading |
+| User intent | Action start → New action | Search query, form submission |
+| Workflow step | Step start → Step complete/cancel | Multi-step wizard |
+
+**Implementation:**
+
+```javascript
+function createOperationScope() {
+  const controller = new AbortController()
+  let isActive = true
+
+  return {
+    signal: controller.signal,
+    isActive: () => isActive,
+
+    commit: (fn) => {
+      if (isActive) fn()
+    },
+
+    dispose: () => {
+      isActive = false
+      controller.abort()
+    }
+  }
+}
+
+// Usage in component
+useEffect(() => {
+  const scope = createOperationScope()
+
+  fetchData({ signal: scope.signal })
+    .then(data => scope.commit(() => setData(data)))
+    .catch(err => {
+      if (err.name !== 'AbortError') {
+        scope.commit(() => setError(err))
+      }
+    })
+
+  return () => scope.dispose()
+}, [])
+```
+
+## Commit points
+
+The moment you mutate UI state or cache is the **commit point**. Most UI corruption comes from committing stale results.
+
+**The commit rule:** Only commit if (scope is active) AND (result matches current intent) AND (version still valid).
+
+**Three types of invalid commits:**
+
+1. **Stale scope:** Component unmounted, route changed, user navigated away
+2. **Stale intent:** User changed input; this result is for old input
+3. **Stale version:** Data was updated elsewhere; this version is outdated
+
+```javascript
+async function fetchWithCommitGuard(key, fetcher, commit) {
+  const requestId = generateId()
+  currentRequestId.current = requestId
+
+  const data = await fetcher()
+
+  // Commit only if this is still the current request
+  if (requestId === currentRequestId.current) {
+    commit(data)
+  }
+  // Otherwise: silently drop (not an error, just stale)
+}
+```
+
+## Cancellation semantics
+
+AbortController doesn't magically stop everything. Understand what cancellation actually means:
+
+**Abort Delivery (Latest-Wins Gate):** Ignore results from superseded requests. The request may still complete server-side. Use for search-as-you-type, autocomplete. Implementation: Request ID comparison, drop if stale.
+
+**Abort Execution (Cooperative Cancellation):** Actually cancel the in-flight operation. `AbortController.abort()` stops fetch, but the server may still process. Use for user cancels, navigation, unmount. Requires passing the signal through the async chain.
+
+**Abort Commit (Scope Invalidation):** Let the operation complete, but don't commit the result. Use for component lifecycle, route changes. Implementation: `scope.isActive()` check before commit.
+
+**What AbortController actually does:**
+- Cancels the fetch (client-side network abort)
+- Does NOT cancel server processing (request may still execute)
+- Does NOT automatically prevent stale commits (you must check)
+- Does NOT work on arbitrary Promises (only cooperatively cancellable operations)
+
+```javascript
+function SearchComponent() {
+  const scopeRef = useRef(createOperationScope())
+  const latestQueryRef = useRef('')
+
+  async function search(query) {
+    // 1. Abort execution: Cancel previous request
+    scopeRef.current.dispose()
+    scopeRef.current = createOperationScope()
+
+    // Track current intent
+    latestQueryRef.current = query
+
+    try {
+      const results = await fetchSearch(query, {
+        signal: scopeRef.current.signal
+      })
+
+      // 2. Abort delivery: Check if this query is still current
+      if (query !== latestQueryRef.current) return
+
+      // 3. Abort commit: Check if scope is still active
+      scopeRef.current.commit(() => setResults(results))
+
+    } catch (err) {
+      if (err.name !== 'AbortError') {
+        scopeRef.current.commit(() => setError(err))
+      }
+    }
+  }
+
+  useEffect(() => () => scopeRef.current.dispose(), [])
+}
+```
+
+## Three deduplication patterns
+
+These are distinct patterns, not interchangeable.
+
+### Single-flight (share in-flight promise)
+
+Multiple callers request the same data simultaneously. Return the same Promise to all callers—one network request, multiple consumers. *Caching Strategies* uses this pattern to prevent cache stampedes.
+
+```javascript
+const inFlight = new Map()
+
+function singleFlight(key, fetcher) {
+  if (inFlight.has(key)) {
+    return inFlight.get(key)
+  }
+
+  const promise = fetcher().finally(() => inFlight.delete(key))
+  inFlight.set(key, promise)
+  return promise
+}
+```
+
+### Latest-wins (discard stale results)
+
+Rapid requests where only the latest matters. Track request ID, ignore old responses. Many requests fire, only the latest commits.
+
+```javascript
+function latestWins() {
+  let currentId = 0
+
+  return async function fetch(fetcher) {
+    const thisId = ++currentId
+    const result = await fetcher()
+
+    if (thisId === currentId) {
+      return result
+    }
+    return null // Stale, discard
+  }
+}
+```
+
+### Queue/serialize (ordered execution)
+
+Mutations that must execute in order. Queue operations, process sequentially. Guaranteed ordering, no concurrent execution.
+
+```javascript
+class SerialQueue {
+  #queue = []
+  #processing = false
+
+  async add(operation) {
+    return new Promise((resolve, reject) => {
+      this.#queue.push({ operation, resolve, reject })
+      this.#process()
+    })
+  }
+
+  async #process() {
+    if (this.#processing) return
+    this.#processing = true
+
+    while (this.#queue.length > 0) {
+      const { operation, resolve, reject } = this.#queue.shift()
+      try {
+        resolve(await operation())
+      } catch (e) {
+        reject(e)
+      }
+    }
+
+    this.#processing = false
+  }
+}
+```
+
+**When to use each:**
+
+| Pattern | Use When | Example |
+|---------|----------|---------|
+| Single-flight | Same data, multiple consumers | Multiple components fetch user profile |
+| Latest-wins | Superseding requests | Search autocomplete |
+| Queue/serialize | Order matters | Offline mutation sync |
+
+## Timeouts and deadlines
+
+Timeouts are first-class concerns, not afterthoughts.
+
+**AbortSignal.timeout()** (modern browsers):
+
+```javascript
+const response = await fetch('/api/slow', {
+  signal: AbortSignal.timeout(5000)
+})
+```
+
+**Manual timeout with Promise.race:**
+
+```javascript
+function withTimeout(promise, ms) {
+  const timeout = new Promise((_, reject) => {
+    setTimeout(() => reject(new Error('Timeout')), ms)
+  })
+  return Promise.race([promise, timeout])
+}
+```
+
+**User-level deadlines (UX timeouts):** Show fallback if data doesn't arrive quickly enough.
+
+```javascript
+function useFetchWithDeadline(fetcher, deadline = 2000) {
+  const [state, setState] = useState({ loading: true, data: null, timedOut: false })
+
+  useEffect(() => {
+    const timer = setTimeout(() => {
+      setState(s => s.loading ? { ...s, timedOut: true } : s)
+    }, deadline)
+
+    fetcher()
+      .then(data => setState({ loading: false, data, timedOut: false }))
+      .catch(() => setState({ loading: false, data: null, timedOut: false }))
+
+    return () => clearTimeout(timer)
+  }, [])
+
+  return state
+}
+
+// Show skeleton for 2s, then fallback UI
+const { data, timedOut } = useFetchWithDeadline(fetchDashboard, 2000)
+if (timedOut && !data) return <FallbackDashboard />
+```
+
+**Server vs. client timeout mismatch:** The client times out after 5 seconds. The server might still be processing. The client shows an error, but the server completed the work. Solution: Idempotency keys, status checks on reconnect.
+
+## Delivery semantics
+
+Borrowed from backend message systems—applies directly to UI updates:
+
+| Semantic | Frontend Meaning | Implementation |
+|----------|------------------|----------------|
+| At-most-once commit | UI state updated 0 or 1 times per operation | Scope guards, latest-wins |
+| At-least-once request | Request retried until acknowledged | Retry with backoff |
+| Exactly-once effect | Business action happens exactly once | Requires idempotency key + server support |
+
+**What frontend can guarantee:**
+- At-most-once commit: Yes, through scope guards
+- At-least-once request: Yes, through retries
+
+**What frontend cannot guarantee alone:**
+- Exactly-once effect: Requires server to deduplicate via idempotency key (see *Consistency Models & Failure Handling* for the intent preservation pattern)
+
+```javascript
+const idempotencyKey = `${userId}-${action}-${crypto.randomUUID()}`
+
+await fetch('/api/payment', {
+  headers: { 'Idempotency-Key': idempotencyKey },
+  body: JSON.stringify(paymentData)
+})
+```
+
+The server checks: "Have I processed this key before?" If yes, return cached response. If no, process and store response with key.
+
+## Retries
+
+**When to retry:** Network failures, server errors (5xx), rate limiting (429 with backoff). See *Network Protocols* for the circuit breaker pattern that prevents hammering failing services.
+
+**When not to retry:** Client errors (4xx except 429), business logic failures, non-idempotent operations without idempotency key.
+
+**Exponential backoff with jitter** prevents thundering herd:
+
+```javascript
+async function fetchWithRetry(url, options = {}) {
+  const { maxAttempts = 3, baseDelay = 1000 } = options
+
+  for (let attempt = 0; attempt < maxAttempts; attempt++) {
+    try {
+      return await fetch(url)
+    } catch (error) {
+      if (attempt === maxAttempts - 1) throw error
+
+      const delay = baseDelay * Math.pow(2, attempt)
+      const jitter = Math.random() * delay * 0.1
+      await sleep(delay + jitter)
+    }
+  }
+}
+```
+
+### Retry UX patterns
+
+**Progressive disclosure:** Don't show retry immediately—try silently first.
+
+```javascript
+const SILENT_RETRY_LIMIT = 2
+const USER_VISIBLE_RETRY_LIMIT = 3
+
+async function fetchWithProgressiveRetry(fetcher, onRetryVisible) {
+  for (let attempt = 0; attempt < SILENT_RETRY_LIMIT + USER_VISIBLE_RETRY_LIMIT; attempt++) {
+    try {
+      return await fetcher()
+    } catch (error) {
+      if (attempt >= SILENT_RETRY_LIMIT) {
+        onRetryVisible(attempt - SILENT_RETRY_LIMIT + 1)
+      }
+      await backoff(attempt)
+    }
+  }
+  throw new Error('All retries exhausted')
+}
+```
+
+**Retry budgets:** Cap total retry time, not just attempts.
+
+```javascript
+function retryWithBudget(fetcher, { maxTime = 30000, maxAttempts = 5 }) {
+  const startTime = Date.now()
+  let attempt = 0
+
+  async function tryOnce() {
+    if (Date.now() - startTime > maxTime || attempt >= maxAttempts) {
+      throw new Error('Retry budget exhausted')
+    }
+
+    try {
+      return await fetcher()
+    } catch {
+      attempt++
+      await backoff(attempt)
+      return tryOnce()
+    }
+  }
+
+  return tryOnce()
+}
+```
+
+**User intent cancels retries:** If the user changes input, stop retrying the old request.
+
+## Backpressure and streaming
+
+Modern frontends handle streams, not just request-response. *Performance Optimization* covers the producer/consumer model and how to maintain 60fps under high-frequency updates.
+
+**Backpressure** occurs when the producer is faster than the consumer: WebSocket messages arriving faster than UI can render, SSE events flooding state, real-time data feeds overwhelming the update cycle.
+
+**Throttle consumption:**
+
+```javascript
+const throttledHandler = throttle((messages) => {
+  const latest = messages[messages.length - 1]
+  updateUI(latest)
+}, 100)
+
+socket.onmessage = (event) => {
+  messageBuffer.push(JSON.parse(event.data))
+  throttledHandler(messageBuffer)
+}
+```
+
+**Buffer and batch:**
+
+```javascript
+const buffer = []
+const flush = debounce(() => {
+  const batch = buffer.splice(0, buffer.length)
+  processBatch(batch)
+}, 200)
+
+socket.onmessage = (event) => {
+  buffer.push(JSON.parse(event.data))
+  flush()
+}
+```
+
+**Streaming responses:**
+
+```javascript
+async function streamingFetch(url, onChunk) {
+  const response = await fetch(url)
+  const reader = response.body.getReader()
+  const decoder = new TextDecoder()
+
+  while (true) {
+    const { done, value } = await reader.read()
+    if (done) break
+
+    const chunk = decoder.decode(value)
+    onChunk(chunk)
+  }
+}
+```
+
+## The trade-offs
+
+### Eager vs. lazy loading
+
+**Eager loading** fetches data before it's needed. Instant when the user needs it, but wasted bandwidth if never used. **Lazy loading** fetches when needed. No wasted requests, but the user waits.
+
+Decision factors: How likely will this data be needed? How expensive is the request? How quickly does data go stale? What's the UX impact of waiting?
+
+### Parallel vs. sequential
+
+*Performance Optimization* covers how parallel vs. waterfall loading affects the performance pipeline. The decision here has direct impact on LCP and TTI.
+
+**Parallel execution:**
+
+```javascript
+const [users, posts, comments] = await Promise.all([
+  fetchUsers(),
+  fetchPosts(),
+  fetchComments()
+])
+```
+
+Faster total time, but all-or-nothing error handling.
+
+**Sequential execution:**
+
+```javascript
+const user = await fetchUser()
+const posts = await fetchPosts(user.id)
+```
+
+Can use previous results, per-step error handling. Total time equals sum of all requests.
+
+**Decision:** "Does B depend on A?" → Yes = sequential.
+
+**Partial success pattern:**
+
+```javascript
+const results = await Promise.allSettled([
+  fetchUsers(),
+  fetchPosts(),
+  fetchComments()
+])
+
+results.forEach((result, i) => {
+  if (result.status === 'fulfilled') {
+    commit(result.value)
+  } else {
+    handlePartialFailure(i, result.reason)
+  }
+})
+```
+
+## Patterns
+
+### Scoped async operations
+
+Every async operation belongs to a scope that determines its validity.
+
+```javascript
+function useAsyncOperation() {
+  const scopeRef = useRef()
+
+  useEffect(() => {
+    scopeRef.current = createOperationScope()
+    return () => scopeRef.current.dispose()
+  }, [])
+
+  return useCallback(async (asyncFn) => {
+    const scope = scopeRef.current
+    if (!scope.isActive()) return null
+
+    try {
+      const result = await asyncFn({ signal: scope.signal })
+      if (scope.isActive()) {
+        return result
+      }
+      return null
+    } catch (error) {
+      if (error.name === 'AbortError') return null
+      throw error
+    }
+  }, [])
+}
+```
+
+### Debounce with cleanup
+
+```javascript
+function useDebouncedCallback(callback, delay) {
+  const timeoutRef = useRef()
+  const callbackRef = useRef(callback)
+
+  useEffect(() => {
+    callbackRef.current = callback
+  }, [callback])
+
+  useEffect(() => {
+    return () => clearTimeout(timeoutRef.current)
+  }, [])
+
+  return useCallback((...args) => {
+    clearTimeout(timeoutRef.current)
+    timeoutRef.current = setTimeout(() => {
+      callbackRef.current(...args)
+    }, delay)
+  }, [delay])
+}
+```
+
+### Optimistic concurrency control
+
+Allow concurrent edits, detect conflicts at save time.
+
+```javascript
+async function saveDocument(doc) {
+  try {
+    return await api.save({
+      id: doc.id,
+      content: doc.content,
+      expectedVersion: doc.version
+    })
+  } catch (e) {
+    if (e.code === 'VERSION_CONFLICT') {
+      const latest = await api.fetch(doc.id)
+      return handleConflict(doc, latest)
+    }
+    throw e
+  }
+}
+```
+
+## Anti-patterns
+
+### Fire and forget
+
+Starting async operations without handling completion, errors, or cancellation.
+
+```javascript
+// BAD
+useEffect(() => {
+  fetch('/api/data').then(r => r.json()).then(setData)
+}, [])
+```
+
+Errors are silently swallowed. No loading indication. Memory leak if component unmounts. No retry mechanism.
+
+### Stale closure commits
+
+Committing results using stale closure values.
+
+```javascript
+// BAD
+useEffect(() => {
+  fetchResults(query).then(results => {
+    console.log(`Results for: ${query}`) // May be stale
+    setResults(results)
+  })
+}, [query])
+```
+
+Don't reference changing values in callbacks. Use request identity instead.
+
+### Async in loop without control
+
+```javascript
+// BAD: 1000 simultaneous requests
+for (const id of ids) {
+  fetch(`/api/item/${id}`).then(process)
+}
+```
+
+Browser limits concurrent connections. Server may rate-limit or crash. No way to cancel. Memory pressure from pending promises.
+
+**Fix: Controlled concurrency:**
+
+```javascript
+async function processWithConcurrency(items, fn, concurrency = 5) {
+  const results = []
+  const executing = new Set()
+
+  for (const item of items) {
+    const promise = fn(item).then(result => {
+      executing.delete(promise)
+      return result
+    })
+    executing.add(promise)
+    results.push(promise)
+
+    if (executing.size >= concurrency) {
+      await Promise.race(executing)
+    }
+  }
+
+  return Promise.all(results)
+}
+```
+
+## Real-world scenario: search-as-you-type
+
+**The situation:** User types in a search box. Results update as they type. Fast typers generate many requests. Responses arrive out of order.
+
+**Solution using operation scopes:**
+
+```javascript
+function useSearch() {
+  const [results, setResults] = useState([])
+  const [loading, setLoading] = useState(false)
+  const scopeRef = useRef(createOperationScope())
+
+  const search = useDebouncedCallback(async (query) => {
+    if (!query) {
+      setResults([])
+      return
+    }
+
+    scopeRef.current.dispose()
+    scopeRef.current = createOperationScope()
+    const scope = scopeRef.current
+
+    setLoading(true)
+    try {
+      const data = await fetchSearch(query, { signal: scope.signal })
+      scope.commit(() => {
+        setResults(data.results)
+        setLoading(false)
+      })
+    } catch (e) {
+      if (e.name !== 'AbortError') {
+        scope.commit(() => {
+          setResults([])
+          setLoading(false)
+        })
+      }
+    }
+  }, 250)
+
+  useEffect(() => () => scopeRef.current.dispose(), [])
+
+  return { search, results, loading }
+}
+```
+
+## Real-world scenario: multi-step form
+
+**The situation:** A 4-step wizard form. Each step validates with the server before proceeding. Final submit creates a record.
+
+**State machine:**
+
+```
+STEP_1 → [validate] → STEP_1_VALIDATING → [success] → STEP_2
+                                        → [failure] → STEP_1 (errors)
+STEP_4 → [submit] → SUBMITTING → [success] → COMPLETE
+```
+
+**Key patterns:**
+- Per-step validation scope (cancel on back navigation)
+- Submit with idempotency key (prevent duplicate creation)
+- Optimistic step advance with rollback on failure
+
+## Real-world scenario: real-time collaboration
+
+**The situation:** Multiple users editing the same document. Changes sync in real-time. Offline editing must work.
+
+Collaborative editing isn't just fetch/response—it's concurrent operations across replicas. Each user's client is a replica that must apply local changes immediately, queue operations for sync, receive remote operations, and merge without conflicts.
+
+**Operation flow:**
+
+```
+User types "hello"
+  → Create operation: INSERT("hello", position: 0)
+  → Apply locally (instant)
+  → Queue for sync
+  → Send when connected
+  → Server broadcasts
+  → Other clients receive, transform, apply
+```
+
+This bridges to *Consistency Models & Failure Handling*. The solutions—Operational Transform and CRDTs—are specialized techniques for handling concurrent async operations across distributed replicas. That document covers reconciliation strategies in depth.
+
+## Design review checklist
+
+**Operation Scopes:**
+- Does every async operation have a defined scope?
+- Do scopes cancel children on disposal?
+- Are commit guards checking scope validity?
+
+**Commit Points:**
+- Is scope active?
+- Does result match current intent?
+- Is version still valid?
+
+**Cancellation:**
+- What type of cancellation is needed? (delivery, execution, commit)
+- Is AbortController passed through the async chain?
+- Are scope guards preventing stale commits?
+
+**Deduplication:**
+- Which pattern applies? (single-flight, latest-wins, queue)
+- Are concurrent requests for same data deduplicated?
+- Are mutations serialized when order matters?
+
+**Retries & Idempotency:**
+- Which failures trigger retry?
+- Is there a retry budget?
+- Are mutations idempotent or keyed?
+- Does user intent cancel retries?
+
+**Timeouts:**
+- Is there a client-side timeout?
+- Is there a user-level deadline?
+- How is server processing after client timeout handled?
+
+## Red flags
+
+- "Sometimes wrong data shows up" — Stale commit, missing scope guard
+- "Memory keeps growing" — Not cleaning up scopes
+- "Works on fast network" — Not tested with latency
+- "Duplicate entries" — Non-idempotent without protection
+
+## Key takeaways
+
+- **Async bugs are state bugs.** Corruption happens when stale results commit. Guard commits with scopes.
+- **Operation scopes are the architecture.** Every async operation belongs to a scope. Scopes cancel children; only scoped results commit.
+- **Cancellation has three meanings.** Abort delivery (ignore), abort execution (stop request), abort commit (scope check). Know which you need.
+- **Deduplication is three patterns.** Single-flight (share), latest-wins (discard old), queue (serialize). They're not interchangeable.
+- **Exactly-once requires backend.** Frontend can guarantee at-most-once commit and at-least-once request, but exactly-once effect needs idempotency keys.
+- **Timeouts are UX.** Client timeouts protect users from waiting forever.
+
+For every async result, ask: "Is the scope still active? Is this the current intent? Should I commit?"
+
+---
+
+## Connections to other documents
+
+- **← State Management:** Async operations update state. Race conditions corrupt state. Scopes prevent invalid commits.
+- **← Caching:** Single-flight is cache deduplication. SWR is async pattern + cache.
+- **→ Performance:** Parallel vs. waterfall affects load time. Timeouts affect perceived performance.
+- **→ Network Protocols:** Timeouts, connection limits, streaming.
+- **→ Consistency & Failure:** Retries, offline handling, OT/CRDTs for collaborative editing.
+
+## Further reading
+
+- [Notes on Structured Concurrency — Nathaniel J. Smith](https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/) — The foundational article on structured concurrency; the operation scope pattern in this document is a frontend adaptation of these ideas.
+- [Concurrency Is Not Parallelism — Rob Pike (video)](https://www.youtube.com/watch?v=oV9rvDllKEg) — A clear explanation of why concurrent design matters even on a single thread, directly applicable to JavaScript's event loop model.
+- [Designing Data-Intensive Applications — Martin Kleppmann](https://dataintensive.net/) — Chapter 8 covers distributed timing, ordering, and the impossibility results that explain why async coordination is fundamentally hard.
+- [AbortController — MDN Web Docs](https://developer.mozilla.org/en-US/docs/Web/API/AbortController) — The browser's built-in cancellation primitive; essential API reference for implementing the cancellation patterns in this document.
+- [p-limit](https://github.com/sindresorhus/p-limit) / [p-queue](https://github.com/sindresorhus/p-queue) — Battle-tested utilities for limiting concurrency and serializing async operations in JavaScript.
+- [Idempotency Keys — Stripe API Docs](https://stripe.com/docs/api/idempotent_requests) — Stripe's production implementation of idempotency keys, the industry reference for making retries safe.
+
+---
+
+## Frequently Asked Questions (FAQs)
+
+1. **What causes race conditions in React components?**
+   Race conditions occur when async operations complete in different order than they started. User types "abc", then "ab"—if the "abc" search returns after "ab", you display wrong results. Related: [State Management at Scale](./state-management-at-scale.md) for state consistency patterns.
+
+2. **How do I cancel fetch requests when a component unmounts?**
+   Use AbortController: create a controller, pass its signal to fetch, call controller.abort() in useEffect cleanup. For fetch patterns and timeouts, see [Network Protocols](./network-protocols.md).
+
+3. **What's a commit guard and when do I need one?**
+   A commit guard verifies that an async result is still relevant before applying it to state. Compare request timestamps, version numbers, or request IDs. Related: [Consistency and Failure Handling](./consistency-and-failure-handling.md) for version-based conflict resolution.
+
+4. **How do I deduplicate identical API requests?**
+   Store pending promises by request key. If a request with the same key is already in flight, return the existing promise. TanStack Query and SWR do this automatically—see [Caching Strategies](./caching-strategies.md) for application-level caching patterns.
+
+5. **What's the difference between cancellation and ignoring stale results?**
+   Cancellation (AbortController) stops the network request—saves bandwidth, frees connections. Ignoring just discards results client-side. For network cost considerations, see [Performance Optimization](./performance-optimization.md).
+
+6. **How do I handle dependent async operations (A must complete before B)?**
+   Use async/await for sequential operations. For complex dependency chains, consider state machines (XState). For perceived performance during multi-step operations, see [Human Perception](./human-perception.md).
+
+7. **What are operation scopes and why do they matter?**
+   Operation scope is the context in which an async result is valid. A search result is scoped to the query that produced it. When scope changes, results from old scope should be discarded. Related: [State Management at Scale](./state-management-at-scale.md) for sources of truth.
+
+8. **How do I implement retry with exponential backoff?**
+   On failure, wait before retrying: delay = baseDelay * 2^attempt + random jitter. Only retry transient failures (5xx, network errors)—see [Network Protocols](./network-protocols.md) for which HTTP errors are retryable.
+
+9. **What's the difference between throttling and debouncing?**
+   Throttle: execute at most once per interval (rate limiting). Debounce: execute only after activity stops for an interval. For how this affects perceived responsiveness, see [Human Perception](./human-perception.md).
+
+10. **How do I debug async state corruption?**
+    Add logging with timestamps and operation IDs. For production debugging, see [Observability](./observability.md) for correlation IDs and distributed tracing that connects frontend operations to backend requests.
+
+---
+
+*Handle every race condition, cancellation, and retry gracefully — build resilient frontends with [Bitloops](https://bitloops.com).*
diff --git a/documentation/docs/frontend-copilot/ui-systems-performance/caching-strategies.md b/documentation/docs/frontend-copilot/ui-systems-performance/caching-strategies.md
new file mode 100644
index 00000000..3bca0114
--- /dev/null
+++ b/documentation/docs/frontend-copilot/ui-systems-performance/caching-strategies.md
@@ -0,0 +1,698 @@
+---
+sidebar_position: 3
+sidebar_label: Caching Strategies
+title: "Frontend Caching: Browser Cache Stack, Invalidation Strategies, and Security Boundaries"
+description: "Every cache is a bet. Learn the browser cache stack (memory, HTTP, Service Worker, CDN), stale-while-revalidate, cache invalidation, and security implications."
+keywords:
+  [
+    frontend caching strategy,
+    browser cache explained,
+    stale while revalidate pattern,
+    service worker cache api,
+    http cache headers frontend,
+    cache invalidation strategies,
+    tanstack query cache,
+    indexeddb caching patterns,
+  ]
+---
+
+# Caching as a system
+
+Every cache is a bet: you're betting that the cost of serving stale data is lower than the cost of fetching fresh data. The art of caching is knowing when that bet pays off—and when it bankrupts user trust.
+
+Caching isn't just about storing data for later. It's **lifecycle design**. You're deciding how data ages, when it dies, how it's reborn, and what guarantees you make about its freshness. This connects directly to state management: cache is the persistence layer for replicated state. If you haven't read about [state ownership and replication](./state-management-at-scale.md), start there.
+
+## The browser's cache stack
+
+Backend engineers obsess over Redis hit rates and Memcached eviction policies. Frontend engineers face the same problems across more layers, with less coordination between them.
+
+The browser doesn't have one cache—it has several:
+
+| Layer | What it stores | Who controls it | Lifetime |
+|-------|---------------|-----------------|----------|
+| In-Memory (JS heap) | Parsed data, computed values | Your application code | Page session |
+| localStorage | Strings (serialized JSON) | Your application code | Persistent |
+| IndexedDB | Structured records, blobs | Your application code | Persistent |
+| Service Worker Cache | Request/Response pairs | Your Service Worker code | Until explicitly cleared |
+| HTTP Cache | Full HTTP responses | Response headers | Browser-managed |
+| CDN Cache | Full HTTP responses | Response headers + CDN config | Server/CDN-managed |
+
+These layers don't coordinate automatically. Invalidating your React Query cache doesn't touch the HTTP cache. Purging the CDN doesn't clear what's in the browser. You're managing a distributed system where the nodes can't talk to each other.
+
+
+## Response caches vs. data stores
+
+Before going deeper, understand a critical distinction: some caches store **responses**, others store **data**. They behave differently.
+
+- **Response caches** (HTTP cache, CDN, Service Worker CacheStorage) store complete HTTP responses, keyed by URL. You influence them through headers. When you call `fetch()`, the browser might return a cached response without hitting the network. You control this indirectly—via `Cache-Control` headers, not imperative code.
+- **Data stores** (React Query cache, Apollo cache, IndexedDB, localStorage) store parsed, structured data. You key it however you want. You control it directly through your application code. When you call `queryClient.invalidateQueries()`, you're talking to your application's cache, not the browser's HTTP cache.
+
+Here's why this matters: a "cache miss" in React Query might still be an HTTP cache hit. Your application requests fresh data, but `fetch()` returns a stale cached response from the browser. You've invalidated the wrong layer.
+
+## The request lifecycle
+
+Understanding how a request flows through cache layers prevents debugging nightmares.
+
+```
+Application calls fetch()
+         ↓
+Service Worker intercepts (if registered)
+    → SW can respond from CacheStorage
+    → Or call fetch() itself (passing through)
+         ↓
+Browser HTTP Cache
+    → Checks Cache-Control, ETag, Expires
+    → May return cached response instantly
+         ↓
+Network Request → CDN
+    → CDN checks its cache (see *Distributed Systems* for CDN architecture)
+    → Returns cached response or forwards to origin
+         ↓
+Origin Server
+    → Generates fresh response
+```
+
+A critical detail: **Service Worker intercepts before HTTP cache**. If your Service Worker calls `fetch()`, that request still goes through the browser's HTTP cache. To bypass it, you'd need `cache: 'no-store'` in the fetch options.
+
+This layering creates power and complexity. You can serve from CacheStorage while the HTTP cache has a different version. You can have stale data at four different layers simultaneously, each with different ages.
+
+## Read policies
+
+Every cache access involves a decision: use the cache, hit the network, or both? These policies formalize that decision.
+
+- **Network-Only:** Always fetch from the network. Never use cache. Use this for data that must be current—real-time stock prices, security-sensitive content, personalized responses that must reflect the latest permissions.
+- **Network-First:** Try the network. If it fails, fall back to cache. Fresher data when available, but resilient to network issues. Use for frequently-changing data where offline access matters. See *Consistency Models & Failure Handling* for graceful degradation patterns when the network fails.
+- **Stale-While-Revalidate (SWR):** Return cached data immediately. Fetch fresh data in the background. Update cache for next time. The user sees potentially stale data instantly, then fresh data on their next interaction.
+- **Cache-First:** Check cache first. Only hit the network on cache miss. Fastest for cached content, but risky if the cache isn't properly invalidated. Use for static assets or data that rarely changes.
+- **Cache-Only:** Never hit the network. Only works if data was pre-cached. Use for offline mode after initial sync, or for app shell assets.
+
+### When SWR is right—and when it's not
+
+SWR is the right default for most data. It provides instant UI while ensuring eventual freshness. But it's not appropriate for everything.
+
+**Use SWR when:**
+- Bounded staleness is acceptable (users can tolerate seconds or minutes of old data)
+- You show data age ("Updated 2 minutes ago") so users know what they're seeing
+- The data doesn't have correctness invariants
+- Showing stale data briefly causes no harm
+
+**Avoid SWR when:**
+- **Audit-sensitive contexts:** "Why does the dashboard show yesterday's numbers?" destroys trust
+- **Financial data:** Account balances, prices, transaction status must be current
+- **Permissions and access control:** Users must not see content they no longer have access to
+- **Legal compliance:** Displayed information has contractual weight
+
+When you do use SWR for sensitive data, pair it with staleness indicators:
+
+```javascript
+<Dashboard data={data} />
+{isStale && <span>Last updated: {formatRelative(dataUpdatedAt)}</span>}
+{isFetching && <RefreshIndicator />}
+```
+
+The `stale-if-error` pattern is a resilience variant: serve stale data only during outages, not all the time. Show an error indicator alongside the data so users know something is wrong.
+
+## Write policies
+
+How do writes flow through the cache stack? Three main approaches:
+
+**Write-Through:** Write to cache and origin simultaneously. The cache is always consistent with the origin when the write succeeds. But writes are slow—you wait for the origin.
+
+**Write-Behind (Write-Back):** Write to cache immediately, sync to origin asynchronously. Writes feel instant. But if sync fails, data is lost. This requires conflict resolution when the origin has changed in the meantime. *Consistency Models & Failure Handling* covers the intent preservation pattern that makes write-behind reliable.
+
+**Write-Around:** Write directly to origin, bypass cache. Invalidate or ignore the cache on write. Simpler, but the next read might miss the cache and hit the network.
+
+| Policy | Speed | Consistency | Data Loss Risk | Use Case |
+|--------|-------|-------------|----------------|----------|
+| Write-Through | Slow | Strong | Low | Critical data, payments |
+| Write-Behind | Fast | Eventual | Medium | Offline-first, drafts |
+| Write-Around | Medium | Varies | Low | Simple CRUD |
+
+## Invalidation: the hard part
+
+Adding a cache is easy. Knowing when to clear it is the real design challenge.
+
+Phil Karlton famously said there are only two hard things in computer science: cache invalidation and naming things. He wasn't joking. Incorrect invalidation causes stale data bugs that are intermittent, hard to reproduce, and erode user trust.
+
+### Time-based (TTL)
+
+Data expires after a fixed duration. Simple to implement, but blunt. If TTL is too long, users see stale data. If too short, you lose the cache benefit.
+
+Tuning depends on data change frequency and staleness tolerance. A product description might have a 1-hour TTL. A notification count might have 30 seconds. A user's avatar might cache for days.
+
+### Event-based (active invalidation)
+
+Invalidate when you know data changed. After a mutation, invalidate the related queries. More precise than TTL, but requires modeling dependencies explicitly.
+
+The risk: miss an invalidation, and the cache is permanently stale until TTL expires or the user refreshes. This is why explicit dependency maps are essential.
+
+### Version-based (ETags)
+
+The cache includes a version identifier. On each request, check if the version changed. If not, return the cached data. If so, fetch fresh.
+
+Conditional requests (`If-None-Match` with an ETag) are efficient: the server returns 304 Not Modified with no body if the data hasn't changed. You validate freshness without transferring the payload again.
+
+### Manual/on-demand
+
+Pull-to-refresh. Logout invalidation. The user or app explicitly triggers a cache clear. This is the escape hatch when automatic strategies fail.
+
+## Modeling invalidation dependencies
+
+Event-based invalidation only works if you can name which cache keys depend on which mutations. This requires explicit modeling.
+
+**Dependency maps:** Define relationships upfront.
+
+```javascript
+const INVALIDATION_MAP = {
+  createPost: (post) => [
+    ['posts', 'list'],
+    ['user', post.authorId, 'posts'],
+    ['feed'],
+  ],
+  updatePost: (postId) => [
+    ['post', postId],
+    ['posts', 'list'],
+  ],
+  deletePost: (postId, authorId) => [
+    ['post', postId],
+    ['posts', 'list'],
+    ['user', authorId, 'posts'],
+  ],
+}
+
+async function mutate(type, fn, ...args) {
+  const result = await fn(...args)
+  const keys = INVALIDATION_MAP[type]?.(...args) ?? []
+  keys.forEach(key => queryClient.invalidateQueries({ queryKey: key }))
+  return result
+}
+```
+
+**Entity tagging:** Tag queries with the entities they contain.
+
+```javascript
+const { data } = useQuery({
+  queryKey: ['product', productId],
+  queryFn: () => fetchProduct(productId),
+  meta: { tags: [`product:${productId}`, 'products'] }
+})
+
+// On mutation, invalidate by tag
+async function updateProduct(productId, data) {
+  await api.updateProduct(productId, data)
+  queryClient.invalidateQueries({
+    predicate: (query) =>
+      query.meta?.tags?.includes(`product:${productId}`)
+  })
+}
+```
+
+Document these relationships explicitly. Undocumented invalidation logic is a bug waiting to happen.
+
+## Cache keys: the schema you don't think about
+
+A cache key is the identifier for stored data. It must be unique for unique data, and identical for requests that should share cache.
+
+**Key patterns:**
+
+```javascript
+// Simple resource
+['user', userId]
+
+// Resource with parameters
+['users', { page: 1, filter: 'active', sort: 'name' }]
+
+// Dependent resource
+['posts', postId, 'comments']
+
+// User-scoped (response varies by user)
+['recommendations', currentUserId]
+```
+
+**Normalization prevents fragmentation.** The requests `/users?page=1&sort=name` and `/users?sort=name&page=1` should share a cache entry. If your keys include raw query strings, you get fragmentation—the same data stored under multiple keys.
+
+```javascript
+function normalizeParams(params) {
+  const sorted = Object.keys(params).sort()
+  return sorted.reduce((acc, key) => {
+    if (params[key] !== undefined && params[key] !== DEFAULT_VALUES[key]) {
+      acc[key] = params[key]
+    }
+    return acc
+  }, {})
+}
+```
+
+**Include all factors that affect the response.** If the API returns different data based on the Authorization header, include the user ID in your cache key. Otherwise, you risk serving User A's cached data to User B.
+
+## Concurrency: preventing thundering herds
+
+Without coordination, caching systems create their own problems.
+
+**Cache stampede:** A cache entry expires. 100 concurrent requests hit the origin simultaneously. The origin is overwhelmed. In frontend terms: 10 components mount, all requesting the same data, and 10 network requests fire.
+
+**Tab storm:** User switches back to an app after it's been backgrounded. Every component refetches on focus. The server sees a burst of requests.
+
+### Request deduplication
+
+Multiple requests for the same key in flight should result in one network call. React Query, SWR, and Apollo do this automatically. This is the "single-flight" pattern—see *Asynchronous Operations* for how it differs from latest-wins and queue patterns. If building manually:
+
+```javascript
+const inFlight = new Map()
+
+async function dedupedFetch(key, fetcher) {
+  const keyStr = JSON.stringify(key)
+  if (inFlight.has(keyStr)) {
+    return inFlight.get(keyStr)
+  }
+  const promise = fetcher()
+  inFlight.set(keyStr, promise)
+  promise.finally(() => inFlight.delete(keyStr))
+  return promise
+}
+```
+
+### SWR with locking
+
+Only one revalidation should be in flight at a time. If a revalidation is already running, don't start another.
+
+```javascript
+const revalidating = new Set()
+
+async function swr(key, fetcher, cache) {
+  const keyStr = JSON.stringify(key)
+  const cached = cache.get(keyStr)
+
+  if (cached) {
+    if (!revalidating.has(keyStr)) {
+      revalidating.add(keyStr)
+      fetcher()
+        .then(fresh => cache.set(keyStr, fresh))
+        .finally(() => revalidating.delete(keyStr))
+    }
+    return cached
+  }
+
+  return fetcher().then(data => {
+    cache.set(keyStr, data)
+    return data
+  })
+}
+```
+
+### Jitter
+
+When multiple clients might refetch at the same time (e.g., on a polling interval), add randomness to prevent synchronized requests:
+
+```javascript
+function scheduleRefetch(baseInterval) {
+  const jitter = Math.random() * baseInterval * 0.2
+  return baseInterval + jitter
+}
+```
+
+## Security: when caching goes wrong
+
+Caching bugs aren't just UX problems—they can be security incidents. *Security Boundaries* covers the broader context of trust boundaries and blast radius design.
+
+### Shared vs. private caches
+
+**Shared caches** (CDN, proxy caches) serve responses to multiple users. They must never cache user-specific content. Control this with `Cache-Control: private` or `Cache-Control: public`.
+
+**Private caches** (browser HTTP cache) serve responses to a single user. They can cache user-specific content safely.
+
+**The rule:** If the response contains user-specific data, it must include `Cache-Control: private` or `Cache-Control: no-store`. Missing this means the CDN might serve User A's response to User B.
+
+```http
+# User-specific response
+GET /api/me
+Cache-Control: private, max-age=60
+
+# Shared content
+GET /api/products/123
+Cache-Control: public, max-age=3600
+```
+
+### The Vary header
+
+`Vary` tells caches that the response depends on specific request headers. Without proper `Vary`, shared caches might key responses incorrectly.
+
+```http
+# Response varies by auth
+GET /api/dashboard
+Vary: Authorization
+Cache-Control: private, max-age=60
+
+# Response varies by language
+GET /api/content
+Vary: Accept-Language
+Cache-Control: public, max-age=3600
+```
+
+If you don't `Vary` on Authorization but your API returns user-specific data, a shared cache might serve cached responses to the wrong users.
+
+### Authorization and cookies
+
+Cookies and Authorization headers are implicit cache key inputs. A response that varies by auth but doesn't declare it is a security bug.
+
+**Dangerous:**
+```http
+GET /api/recommendations
+Cache-Control: max-age=300
+# No private, no Vary
+# CDN might cache User A's recommendations and serve to User B
+```
+
+**Safe:**
+```http
+GET /api/recommendations
+Cache-Control: private, max-age=300
+Vary: Authorization
+```
+
+In application code, include user context in cache keys when needed:
+
+```javascript
+const { data } = useQuery({
+  queryKey: ['recommendations', currentUserId],
+  queryFn: fetchRecommendations,
+})
+```
+
+## Observability: knowing what's cached
+
+"We're not sure if this is cached" should be a solved problem. *Observability* covers the broader telemetry pipeline and debugging workflows.
+
+### Identifying cache layers
+
+**Browser DevTools (Network panel):**
+- "from disk cache" or "from memory cache" indicates an HTTP cache hit
+- "from ServiceWorker" means the SW served from CacheStorage
+- "(ServiceWorker)" in the initiator column means the SW intercepted the request
+- The Size column shows actual transfer vs. cached
+
+**Response headers to check:**
+```http
+# CDN cache status (varies by provider)
+X-Cache: HIT
+CF-Cache-Status: HIT
+Age: 120
+
+# Server timing for debugging
+Server-Timing: cdn;desc="HIT", origin;dur=0
+```
+
+**Application cache state:**
+```javascript
+const { data, isStale, isFetching, dataUpdatedAt } = useQuery(...)
+
+console.log({
+  isFromCache: !isFetching && !!data,
+  isStale,
+  cacheAge: Date.now() - dataUpdatedAt,
+})
+```
+
+### Debugging checklist
+
+**When data seems stale:**
+1. Check DevTools Network—is the response from cache?
+2. Check response `Cache-Control` headers
+3. Check if Service Worker is intercepting
+4. Check application cache (React Query DevTools)
+5. Check CDN cache status headers
+
+**When cache isn't working:**
+1. Check if `Cache-Control` allows caching
+2. Check for `Vary` header mismatches
+3. Check if cache key is fragmenting (different params)
+4. Check if mutations are properly invalidating
+
+## The trade-offs
+
+### Freshness vs. performance
+
+This is the fundamental tension. Fresh data requires network requests—slower and bandwidth-intensive. Cached data is fast but potentially stale.
+
+**Decision factors:**
+1. How often does this data change?
+2. What's the cost of staleness?
+3. Can the user tell?
+
+For product descriptions that change weekly, cache aggressively. For stock prices that change every second, barely cache at all. For notification counts, cache briefly and show indicators when stale.
+
+### Memory vs. persistent vs. HTTP
+
+**Memory caching:** Instant access, no I/O. But lost on refresh, consumes heap, limited to 50-500MB practically.
+
+**Persistent storage (IndexedDB):** Survives refresh, available offline, large capacity. But async access, storage limits, and API complexity.
+
+**HTTP caching:** Survives refresh, shared across tabs, managed by browser. But still requires network roundtrip for validation.
+
+Choose based on access patterns. High-frequency access within a session: memory. Must survive refresh or work offline: persistent. Static assets shared across users: HTTP/CDN.
+
+### Complexity vs. correctness
+
+**Simple caching (TTL only):** Easy to implement, predictable. But either data is stale or you're refetching unnecessarily.
+
+**Smart caching (invalidation + SWR + normalization):** Fresh when needed, efficient. But complex logic, more potential bugs, harder to debug.
+
+Every cache layer adds complexity. Every invalidation rule adds complexity. Sometimes "just refetch" is the right answer—simpler and correct. The question is whether users will notice the latency—see *Human Perception* for when the perception budget allows network round-trips.
+
+## Patterns
+
+### Optimistic cache updates with rollback
+
+Update the cache immediately on mutation, before the server confirms. Snapshot current state for rollback.
+
+```javascript
+async function likePost(postId) {
+  const previous = queryClient.getQueryData(['post', postId])
+
+  queryClient.setQueryData(['post', postId], old => ({
+    ...old,
+    likeCount: old.likeCount + 1,
+    liked: true
+  }))
+
+  try {
+    const result = await api.likePost(postId)
+    queryClient.setQueryData(['post', postId], result)
+  } catch (error) {
+    queryClient.setQueryData(['post', postId], previous)
+    throw error
+  }
+}
+```
+
+### Cache warming
+
+Pre-populate the cache before users need the data. Prefetch on hover, on likely navigation paths, or based on behavioral prediction.
+
+```javascript
+function ProductLink({ productId, children }) {
+  const prefetch = () => {
+    queryClient.prefetchQuery({
+      queryKey: ['product', productId],
+      queryFn: () => fetchProduct(productId),
+      staleTime: 60_000,
+    })
+  }
+
+  return (
+    <Link
+      to={`/product/${productId}`}
+      onMouseEnter={prefetch}
+      onFocus={prefetch}
+    >
+      {children}
+    </Link>
+  )
+}
+```
+
+Don't prefetch aggressively. Respect data caps. Only prefetch cache-appropriate data.
+
+## Anti-patterns
+
+### Caching without invalidation strategy
+
+Adding caching without planning invalidation leads to permanently stale data. The symptom: "Have you tried clearing your cache?" becomes a support response.
+
+Before adding cache, document: What triggers invalidation? What's the maximum acceptable staleness? How will you know if invalidation is broken?
+
+### Ignoring HTTP cache when using application cache
+
+You implement React Query but ignore what HTTP headers the API returns. Your app invalidates the query, but `fetch()` returns a stale HTTP-cached response.
+
+```javascript
+// App thinks it's refetching
+queryClient.invalidateQueries(['user'])
+// But response has Cache-Control: max-age=3600
+// Browser returns stale HTTP cache hit
+```
+
+Coordinate with backend on cache headers. Use `cache: 'no-cache'` in fetch to force revalidation when needed.
+
+### User-specific data in shared caches
+
+Missing `Cache-Control: private` or `Vary: Authorization` means user A's data might be served to user B. This is intermittent (only when the cache is warm), hard to reproduce, and a privacy violation.
+
+## Real-world scenario: e-commerce product catalog
+
+**The situation:** Product listing and detail pages are CDN-cached. Prices and inventory change frequently. Product descriptions change rarely.
+
+**The correctness invariant:** Displayed price must match checkout price. Users must not be charged more than what was shown.
+
+**Strategy shaped by the invariant:**
+
+Product info (name, description, images): CDN cache, 1-hour TTL. Staleness is cosmetic.
+
+Price and inventory: Either no CDN cache (fetch fresh on each view), or cache with short TTL plus client-side verification before checkout.
+
+```javascript
+async function initiateCheckout(cart) {
+  const currentPrices = await api.getPrices(cart.items.map(i => i.productId))
+
+  const priceChanges = cart.items.filter(item =>
+    item.displayedPrice !== currentPrices[item.productId]
+  )
+
+  if (priceChanges.length > 0) {
+    return showPriceChangeModal(priceChanges)
+  }
+
+  return proceedToPayment(cart)
+}
+```
+
+The trade-off: complexity at checkout enables aggressive caching elsewhere. The correctness invariant is enforced at the point of commitment, not at every display.
+
+## Real-world scenario: offline-first notes
+
+**The situation:** Users create and edit notes. The app must work offline. Notes sync across devices.
+
+**Cache layer mapping:**
+
+| Layer | Contents | Purpose |
+|-------|----------|---------|
+| Memory | Currently open note | Instant access while editing |
+| IndexedDB | All user's notes | Primary storage, survives refresh, offline access |
+| Service Worker | App shell, assets | Enables offline launch |
+| Server | Sync target | Cross-device source of truth |
+
+**Write path:**
+
+```javascript
+async function saveNote(note) {
+  memoryCache.set(note.id, { ...note, status: 'local' })
+
+  await db.notes.put({
+    ...note,
+    pendingSync: true,
+    localUpdatedAt: Date.now()
+  })
+
+  if (navigator.onLine) {
+    syncQueue.add(note.id)
+  }
+}
+```
+
+IndexedDB is the primary store. The server is the sync target. Conflicts are resolved on sync—either last-write-wins or surfaced to the user. See *Consistency Models & Failure Handling* for reconciliation strategies and conflict detection using version vectors.
+
+## Design review checklist
+
+**Cache Placement:**
+- Which cache layers are you using?
+- For each data type, which layer is appropriate?
+- Are layers coordinated?
+
+**Invalidation:**
+- Is invalidation strategy documented for each cached entity?
+- What's the maximum time a user might see stale data?
+- Are mutation → invalidation dependencies explicit?
+
+**Cache Keys:**
+- Are keys unique for unique data?
+- Are keys normalized (param order, defaults removed)?
+- Do keys include all factors that affect the response?
+
+**Security:**
+- Is user-specific data marked `Cache-Control: private`?
+- Are `Vary` headers correct for headers that affect response?
+- Is there a correctness invariant for critical data?
+
+**Concurrency:**
+- Is request deduplication in place?
+- Are focus/refetch storms handled?
+
+**Observability:**
+- Can you determine which cache layer served a response?
+- Is cache hit/miss ratio tracked?
+
+## Red flags
+
+- "We cache everything for 24 hours" — One-size-fits-all TTL ignores data diversity
+- "Just add a cache-buster param" — Symptom of broken invalidation
+- "Users need to hard refresh" — Cache not invalidating properly
+- "It works locally but not in production" — CDN cache not considered
+- "We're not sure if this is cached" — Missing observability
+
+## Key takeaways
+
+- **Caching is lifecycle design.** You're designing how data ages, when it expires, and what guarantees you make about freshness.
+- **Response caches and data stores are different.** HTTP cache stores responses by URL. React Query stores data by keys you define. They don't coordinate automatically.
+- **Invalidation is the hard part.** Adding a cache is easy. Knowing when to clear it requires explicit dependency modeling.
+- **SWR is the right default—with guardrails.** Stale-while-revalidate works for most data. Financial and audit-sensitive data needs stricter freshness.
+- **Security is a caching concern.** Wrong headers can leak data across users.
+- **Observability is not optional.** If you can't tell what's cached, you can't debug caching problems.
+
+Before caching anything, ask: "What's the correctness invariant for this data, and how will I know when the cache is wrong?"
+
+---
+
+## Further reading
+
+- [HTTP Caching — MDN Web Docs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching) — The authoritative reference for `Cache-Control`, `ETag`, `Vary`, and conditional requests; understand these before designing any cache layer.
+- [High Performance Browser Networking — Ilya Grigorik](https://hpbn.co/) — Freely available online; deep-dive into the browser's cache hierarchy, HTTP/2 optimizations, and network-level caching behavior.
+- [Workbox Documentation](https://developer.chrome.com/docs/workbox/) — Google's toolkit for Service Worker caching, making it straightforward to implement cache-first, network-first, and stale-while-revalidate strategies.
+- [TanStack Query Documentation](https://tanstack.com/query/latest) — Application-level cache with built-in SWR, background refetching, request deduplication, and fine-grained invalidation patterns.
+
+---
+
+## Frequently Asked Questions (FAQs)
+
+1. **What are the layers of the browser cache stack?**
+   From fastest to slowest: (1) Memory/application cache. (2) HTTP cache. (3) Service Worker cache. (4) CDN/edge cache (see [Distributed Systems](./distributed-systems.md)). (5) Origin server. Each layer trades freshness for speed. For HTTP headers, see [Network Protocols](./network-protocols.md).
+
+2. **What's the difference between no-cache and no-store?**
+   `no-cache`: browser can store but must revalidate. `no-store`: browser must not store at all. Use `no-store` for sensitive data—see [Security Boundaries](./security-boundaries.md) for token storage patterns. For header syntax, see [Network Protocols](./network-protocols.md).
+
+3. **When should I use stale-while-revalidate?**
+   When showing slightly stale data is acceptable while fetching fresh data in background. For user-facing implications, see [Human Perception](./human-perception.md) for how staleness affects perceived performance. Bad for: inventory counts, prices at checkout.
+
+4. **How do I invalidate cached data when it changes?**
+   Strategies: (1) Time-based (TTL). (2) Event-based via WebSocket/SSE—see [Network Protocols](./network-protocols.md). (3) Version-based URLs—see [Distributed Systems](./distributed-systems.md) for CDN invalidation. Choose based on freshness requirements.
+
+5. **Should I cache API responses in JavaScript or rely on HTTP cache?**
+   Both—they're complementary. HTTP cache handles the network layer (see [Network Protocols](./network-protocols.md)). JavaScript cache (TanStack Query, SWR) handles application layer. For state management integration, see [State Management at Scale](./state-management-at-scale.md).
+
+6. **What are the security risks of caching?**
+   Major risks: caching authenticated responses, sensitive data persisting after logout, cross-user data leakage. See [Security Boundaries](./security-boundaries.md) for token storage and [Distributed Systems](./distributed-systems.md) for CDN security considerations.
+
+7. **How does cache invalidation work with immutable assets?**
+   Immutable assets (JS, CSS with content hashes) can be cached forever (`max-age=31536000, immutable`). When content changes, the filename changes. For bundle optimization, see [Performance Optimization](./performance-optimization.md).
+
+8. **What's cache key fragmentation and why does it matter?**
+   Cache keys determine what's cached separately. Too many key factors fragment the cache—low hit rates, high storage. See [Distributed Systems](./distributed-systems.md) for CDN cache key design.
+
+9. **How do I cache for offline support?**
+   Service Worker + Cache API for static assets and API responses. IndexedDB for structured data. See [Consistency and Failure Handling](./consistency-and-failure-handling.md) for offline-first architecture patterns.
+
+10. **What's the cost model for caching decisions?**
+    Every cache is a bet: cost of serving stale data vs. cost of fetching fresh data. For how staleness affects user experience, see [Human Perception](./human-perception.md). For measuring cache effectiveness, see [Observability](./observability.md).
+
+---
+
+*Serve content instantly and keep it fresh with smart caching — build faster frontends with [Bitloops](https://bitloops.com).*
diff --git a/documentation/docs/frontend-copilot/ui-systems-performance/consistency-and-failure-handling.md b/documentation/docs/frontend-copilot/ui-systems-performance/consistency-and-failure-handling.md
new file mode 100644
index 00000000..0cafd644
--- /dev/null
+++ b/documentation/docs/frontend-copilot/ui-systems-performance/consistency-and-failure-handling.md
@@ -0,0 +1,679 @@
+---
+sidebar_position: 9
+sidebar_label: Consistency & Failure Handling
+title: "Frontend Consistency: Optimistic UI, Offline-First Patterns, and Intent Preservation"
+description: "Networks fail. Users go offline. Learn optimistic UI, intent preservation with idempotency keys, offline queues, and reconciliation strategies for resilient frontends."
+keywords:
+  [
+    optimistic ui react,
+    offline first web app,
+    idempotency key frontend,
+    intent preservation pattern,
+    frontend error handling,
+    conflict resolution frontend,
+    eventual consistency ui,
+    retry queue javascript,
+  ]
+---
+
+# Consistency models for the browser
+
+Every distributed system must choose between availability and consistency. Frontend applications are distributed systems where one node—the user's browser—has unreliable connectivity to all other nodes. This isn't an edge case to handle; it's the default operating condition.
+
+## Core mental model
+
+**State = projection of commands under unreliable delivery.**
+
+This builds directly on *State Management at Scale*—the browser as a distributed system, with the client as a replica of server state. This single idea unifies:
+- Optimistic UI (apply command locally, project expected result)
+- Offline queues (store commands, replay when connected)
+- Retries (same command, multiple delivery attempts)
+- Deduplication (same command should produce same result)
+- Reconciliation (merge projected state with confirmed state)
+
+Every pattern in this document is a variation on this theme.
+
+## What makes frontend unique
+
+- **The user is watching.** Failures must be communicated, not just logged.
+- **Rollback is visible.** Undoing an optimistic update feels worse than waiting.
+- **Partial success is common.** Some data loads, some doesn't.
+- **Intent preservation matters.** The user's action should "stick" even under failure.
+
+## Failure model cheat sheet
+
+Before diving into patterns, establish a unified vocabulary.
+
+| Category | Examples | Default UX | Retryable? |
+|----------|----------|------------|------------|
+| **Transport failures** | Timeout, DNS failure, offline | "Connection issue" + retry | Yes, with backoff |
+| **Server failures** | 500, 502, 503, 504 | "Something went wrong" + auto-retry | Yes, with backoff |
+| **Application rejections** | 400, 403, 404, 422 | Specific error + guidance | No (fix request first) |
+| **Auth failures** | 401, token expired | Silent refresh → retry | Yes, after token refresh |
+| **Rate limiting** | 429 | Backoff per Retry-After | Yes, after delay |
+| **Concurrency anomalies** | Out-of-order responses, races | Version-gating | N/A (prevention) |
+| **Consistency conflicts** | Version mismatch, concurrent writes | Merge or server-wins | Depends on strategy |
+
+**Key distinctions:**
+- **Transient vs. Permanent:** Network hiccup (retry likely succeeds) vs. validation error (retry won't help)
+- **Silent vs. Visible recovery:** User doesn't need to know vs. user needs to act
+
+## Opinionated defaults
+
+Rather than just cataloging options, here are recommended defaults:
+
+### Default read consistency: read-your-writes + monotonic reads
+- User always sees their own changes immediately
+- User never sees data go "backwards" (no time travel)
+- Implementation: Version-gating on all reads
+
+### Default write strategy: optimistic for reversible, pessimistic for irreversible
+- **Optimistic:** Toggle, like, add to cart, draft save
+- **Pessimistic:** Payment, delete account, publish, external consequences
+- **Rule:** If rollback would confuse or harm the user, wait for confirmation
+
+### Default failure UX: show stale with age + targeted retry
+- Show cached/stale data with staleness indicator
+- Failed sections show inline retry, not modal
+- Never show blank screen if you have any data
+
+## Consistency models
+
+*Distributed Systems* covers these models as they apply to CDN caching. Here we focus on client-side state.
+
+### Strong consistency
+Every read reflects the most recent write. Wait for server confirmation before showing any change.
+
+**When to use:** Financial transactions, inventory counts, anything where showing wrong data is worse than waiting.
+
+**Cost:** Perceived latency, blocked UI.
+
+### Eventual consistency
+Updates propagate asynchronously; reads may return stale data temporarily. This is the default reality—server and client drift apart.
+
+**When to use:** Most content, social features, non-critical data.
+
+**Cost:** Must handle stale reads gracefully.
+
+### Causal consistency
+Operations that are causally related appear in order; concurrent operations may appear in any order. If operation B depends on A's result, everyone sees A before B.
+
+**Frontend friendly subset:** Read-your-writes + monotonic reads (no time travel).
+
+**When to use:** Collaborative editing, comment threads, messaging.
+
+## Version-based monotonicity
+
+**Timestamps are unreliable. Versions are reliable.**
+
+### Why timestamps fail
+- Client clocks drift (sometimes by minutes)
+- Server clocks can disagree
+- Network latency makes "wall clock time" meaningless
+
+### Version-based approach
+
+**Server-issued versions:**
+
+```javascript
+{
+  id: "123",
+  data: { ... },
+  version: 47,  // or ETag, or revision ID
+  updatedAt: "2024-01-15T..."  // informational, not for ordering
+}
+```
+
+**Client tracks versions:**
+
+```javascript
+const versions = new Map()
+
+function updateIfNewer(resourceId, newData, newVersion) {
+  const currentVersion = versions.get(resourceId) ?? 0
+
+  if (newVersion > currentVersion) {
+    versions.set(resourceId, newVersion)
+    setState(resourceId, newData)
+    return true
+  }
+
+  // Reject stale update
+  console.log(`Ignoring stale response: v${newVersion} < v${currentVersion}`)
+  return false
+}
+```
+
+### "No time travel" example
+
+The problem: Infinite scroll where page 2 response arrives before page 1, or a refetch overwrites newer cache with older response.
+
+```javascript
+// BAD: Just replace state with whatever arrives
+async function loadPage(pageNum) {
+  const data = await fetch(`/items?page=${pageNum}`)
+  setPageData(pageNum, data)  // Might overwrite newer data!
+}
+
+// GOOD: Version-gated updates
+const feedVersion = { current: 0 }
+
+async function loadPage(pageNum) {
+  const { items, version } = await fetch(`/items?page=${pageNum}`)
+
+  if (version >= feedVersion.current) {
+    feedVersion.current = version
+    setPageData(pageNum, items)
+  }
+  // Else: stale response, ignore
+}
+```
+
+## Optimistic UI
+
+Update the UI immediately as if the operation succeeded. Send the request in the background. Reconcile when the server responds. *Human Perception* provides the optimism risk rubric—matching optimism level to stakes.
+
+### Why optimism matters
+- Network latency is 100-500ms minimum; users notice delays > 100ms (see *Human Perception* for perception budgets)
+- Waiting for confirmation makes apps feel sluggish
+- Most operations succeed; optimizing for the happy path improves UX
+
+### Anatomy of an optimistic update
+
+```
+1. User action (click, submit)
+2. Immediately update local state (optimistic)
+3. Send mutation to server
+4. On success: confirm optimistic state, merge server changes
+5. On failure: rollback optimistic state, notify user
+```
+
+### What can go wrong
+- Server rejects the operation (validation, permissions, conflicts)
+- Server returns different data than expected (concurrent modifications)
+- Network fails entirely (no response)
+- Request succeeds but response is lost
+
+**Key insight:** Optimism is a bet. Bet on success for fast UX, but always design the rollback experience.
+
+## Intent preservation pattern
+
+This is the concrete architecture that makes "user's action should stick" real.
+
+### Command log / intent queue
+
+```javascript
+const intent = {
+  id: crypto.randomUUID(),        // Idempotency key
+  type: 'ADD_TO_CART',
+  payload: { productId: '123', quantity: 2 },
+  createdAt: Date.now(),
+  status: 'pending',              // pending | confirmed | failed
+  attempts: 0
+}
+
+const intentLog = new PersistentStore('intents')  // IndexedDB
+
+async function captureIntent(type, payload) {
+  const intent = {
+    id: crypto.randomUUID(),
+    type,
+    payload,
+    createdAt: Date.now(),
+    status: 'pending',
+    attempts: 0
+  }
+
+  // 1. Persist intent (survives refresh/crash)
+  await intentLog.add(intent)
+
+  // 2. Apply optimistic state (projection)
+  applyOptimistic(intent)
+
+  // 3. Attempt delivery
+  deliverIntent(intent)
+
+  return intent.id
+}
+```
+
+### State as projection
+
+```javascript
+function computeCurrentState(serverState, pendingIntents) {
+  let state = serverState
+
+  for (const intent of pendingIntents) {
+    state = applyIntent(state, intent)  // Project pending changes
+  }
+
+  return state
+}
+```
+
+### Intent delivery with idempotency
+
+```javascript
+async function deliverIntent(intent) {
+  try {
+    const result = await fetch('/api/command', {
+      method: 'POST',
+      headers: {
+        'Idempotency-Key': intent.id  // Server deduplicates
+      },
+      body: JSON.stringify(intent)
+    })
+
+    if (result.ok) {
+      await intentLog.update(intent.id, { status: 'confirmed' })
+    } else if (result.status === 409) {
+      await handleConflict(intent, result)
+    } else {
+      await intentLog.update(intent.id, { status: 'failed' })
+      notifyUser(intent, result)
+    }
+  } catch (error) {
+    intent.attempts++
+    scheduleRetry(intent)
+  }
+}
+```
+
+### Why idempotency keys matter
+- Network can fail after server processes but before client receives response
+- Retry sends same intent again
+- Server recognizes key, returns original result (doesn't double-process)
+- Without this: duplicate orders, double charges, repeated actions
+
+*Asynchronous Operations* covers delivery semantics—the frontend can guarantee at-most-once commit, but exactly-once effect requires server-side deduplication.
+
+### Recovery on app restart
+
+```javascript
+async function recoverPendingIntents() {
+  const pending = await intentLog.getByStatus('pending')
+
+  for (const intent of pending) {
+    applyOptimistic(intent)  // Restore optimistic state
+    deliverIntent(intent)     // Retry delivery
+  }
+}
+```
+
+## Offline-first architecture
+
+Assume the network is unavailable by default. Design for local-first operation, sync when possible. *Caching Strategies* covers the cache layers (IndexedDB, Service Worker, HTTP cache) that make offline-first possible.
+
+### Offline capability spectrum
+
+| Tier | What User Can Do | Reconnect Guarantee | Conflict Frequency |
+|------|------------------|---------------------|-------------------|
+| Read-only offline | View cached content | Automatic refresh | None |
+| Queued mutations | Make changes (queued) | At-least-once delivery | Rare |
+| Full offline-first | Full functionality | Exactly-once via idempotency | Common |
+
+### Key components
+1. **Local persistence:** IndexedDB, localStorage
+2. **Intent queue:** Pending commands with idempotency keys
+3. **Sync engine:** Detect connectivity, process queue
+4. **Conflict resolution:** Strategy for when local and server diverge
+
+### Service Worker's role (with caveats)
+
+**Good for:** Caching static assets, serving from cache when offline.
+
+**Background Sync limitations:**
+- Not universally supported
+- Can be delayed by browser
+- **Recommendation:** Treat as enhancement, not backbone
+
+**More reliable approach:**
+
+```javascript
+window.addEventListener('load', async () => {
+  await recoverPendingIntents()
+})
+
+window.addEventListener('online', async () => {
+  await processIntentQueue()
+})
+
+// Periodic check (backup)
+setInterval(async () => {
+  if (navigator.onLine) {
+    await processIntentQueue()
+  }
+}, 30000)
+```
+
+## Partial failures & data shape resilience
+
+### Types of partial failure
+1. **Render partial:** Main content loads, sidebar fails
+2. **Data partial:** List loads, one item's details fail
+3. **Mutation partial:** Parent succeeds, child fails
+4. **Shape partial:** Response missing expected fields
+
+### Data shape resilience
+
+```javascript
+// BAD: Assumes shape is always correct
+function renderUser(user) {
+  return `${user.profile.name} - ${user.profile.email}`
+}
+
+// GOOD: Defensive with fallbacks
+function renderUser(user) {
+  const name = user?.profile?.name ?? 'Unknown'
+  const email = user?.profile?.email ?? 'No email'
+  return `${name} - ${email}`
+}
+```
+
+### Schema validation at boundaries
+
+```javascript
+function parseUserResponse(data) {
+  if (!data?.id) {
+    throw new DataShapeError('Missing required field: id')
+  }
+
+  return {
+    id: data.id,
+    name: data.name ?? 'Unknown',
+    email: data.email,
+    avatarUrl: data.avatarUrl ?? DEFAULT_AVATAR
+  }
+}
+```
+
+### Graceful degradation policy
+
+| Aspect | Options | Example |
+|--------|---------|---------|
+| Stale tolerance | X minutes/hours | "Show data up to 24h old" |
+| Staleness indicator | Badge, timestamp | "Updated 2 hours ago" |
+| Retry behavior | Auto, manual, none | "Retry after 3 auto-retries" |
+| Mutation during degraded | Allowed, disabled | "Disable Buy while degraded" |
+| Fallback content | Skeleton, last known | "Show last known value" |
+
+## Reconciliation strategies
+
+### Conflict detection (versioning is key)
+
+```javascript
+async function updateResource(id, changes) {
+  const current = getResource(id)
+
+  const response = await fetch(`/api/resources/${id}`, {
+    method: 'PATCH',
+    headers: { 'If-Match': current.version },
+    body: JSON.stringify(changes)
+  })
+
+  if (response.status === 412) {  // Precondition Failed
+    return { conflict: true, serverState: await response.json() }
+  }
+
+  return { conflict: false, data: await response.json() }
+}
+```
+
+### Conflict resolution strategies
+
+- **Last-Write-Wins (LWW):** Most recent wins (using versions, not timestamps). Use when data loss is acceptable.
+- **Server-Authoritative:** Server always wins. Client changes are suggestions. Use when data integrity is critical.
+- **Merge Strategies:** Field-level merge (different fields → merge both), set union (both added items → include both), operational transformation (concurrent text edits).
+- **User-Mediated:** Present conflict to user. Use sparingly when automatic merge is impossible.
+
+## Multi-step operations (saga pattern)
+
+For operations spanning multiple steps where partial completion is problematic.
+
+### Frontend vs. backend responsibilities
+
+| Aspect | Frontend Owns | Backend Owns |
+|--------|----------------|--------------|
+| UI state machine | Progress, step visualization | N/A |
+| Retry semantics | When to retry, user cancel | Idempotency, deduplication |
+| User feedback | Error messages, UX | N/A |
+| Atomic boundaries | N/A | Transaction, rollback |
+| Compensating transactions | Display rollback, notify | Actual rollback (refund) |
+
+### Frontend saga implementation
+
+```javascript
+const checkoutStates = {
+  idle: { on: { START: 'validating' } },
+  validating: { on: { SUCCESS: 'reserving', FAILURE: 'error' } },
+  reserving: { on: { SUCCESS: 'charging', FAILURE: 'error' } },
+  charging: { on: { SUCCESS: 'confirming', FAILURE: 'compensating' } },
+  confirming: { on: { SUCCESS: 'complete', FAILURE: 'compensating' } },
+  compensating: { on: { DONE: 'error' } },
+  complete: {},
+  error: { on: { RETRY: 'validating' } }
+}
+```
+
+Frontend shows progress and handles user experience; backend handles atomicity and actual compensations.
+
+## Retry strategies
+
+*Network Protocols* covers the circuit breaker pattern for preventing cascading failures. Here we focus on client-side retry semantics.
+
+### Which failures are retryable
+- Network errors: YES
+- 5xx server errors: USUALLY YES
+- 4xx client errors: USUALLY NO
+- 401 Unauthorized: MAYBE (after token refresh—see *Security Boundaries*)
+- 409 Conflict: MAYBE (after state refresh)
+- 429 Rate limit: YES (after delay)
+
+### Exponential backoff with jitter
+
+```javascript
+async function retryWithBackoff(operation, maxAttempts = 3) {
+  for (let attempt = 0; attempt < maxAttempts; attempt++) {
+    try {
+      return await operation()
+    } catch (error) {
+      if (!isRetryable(error) || attempt === maxAttempts - 1) {
+        throw error
+      }
+
+      const baseDelay = 1000
+      const exponential = Math.pow(2, attempt)
+      const jitter = Math.random() * baseDelay
+      await sleep(baseDelay * exponential + jitter)
+    }
+  }
+}
+```
+
+## Failure UX principles
+
+These principles connect resilience architecture to user perception. *Human Perception* is the capstone that ties all these decisions together—every choice here affects how the system feels.
+
+**1. Honesty over false confidence.** Don't hide failures that affect user actions. Users trust honest uncertainty more than false certainty.
+
+**2. Rollback feels worse than waiting.** For important actions: pessimistic with good feedback > optimistic with rollback.
+
+**3. Context-appropriate feedback.**
+- Silent retry: Background refreshes, non-critical mutations
+- Inline status: Pending state, retrying indicator
+- Toast: Recoverable errors, stale warnings
+- Blocking modal: Irreversible failures
+
+**4. Progressive disclosure of failure.** First "Something went wrong" + retry. If retry fails, more detail. If persistent, guidance and alternatives.
+
+**5. Preserve user work.** Never lose user input to a failure. Queue mutations, persist drafts. On recovery, restore context.
+
+## The trade-offs
+
+### Optimism vs. correctness
+
+**Decision factors:**
+- Consequence of showing wrong data temporarily
+- Frequency of server rejection
+- Reversibility of the action
+- User expectation
+
+**Default:** Optimistic for reversible, pessimistic for irreversible.
+
+### Offline capability vs. complexity
+
+**Decision factors:**
+- User context (mobile, travel, unreliable networks)
+- Data sensitivity
+- Development resources
+
+**Default:** Start with read-only offline + queued mutations. Full offline-first only if user context demands it.
+
+### User feedback vs. silent recovery
+
+| Recovery possible | User action needed | Approach |
+|-------------------|-------------------|----------|
+| Yes | No | Silent retry |
+| Yes | Yes | Inform + suggest action |
+| No | No | Log, maybe inform later |
+| No | Yes | Clear error + guidance |
+
+## Patterns
+
+### Version-gated updates
+
+```javascript
+function updateIfNewer(resourceId, data, version) {
+  if (version > currentVersions.get(resourceId)) {
+    currentVersions.set(resourceId, version)
+    setState(resourceId, data)
+  }
+}
+```
+
+### Intent queue with persistence
+See Intent Preservation Pattern section.
+
+### Error boundaries with degradation policies
+Isolate failures to prevent cascade. Each boundary decides: show error, show fallback, or hide.
+
+## Anti-patterns
+
+### Optimism without rollback capability
+Showing changes you can't undo leads to inconsistent state. Always capture previous state.
+
+### Retry without backoff
+Hammering a failing server makes things worse. Use exponential backoff with jitter.
+
+### Timestamps for ordering
+Clock drift makes "most recent" ambiguous. Use server-issued versions.
+
+### Conflict resolution as afterthought
+"We'll handle conflicts later" → they happen in production. Design conflict strategy upfront.
+
+## Real-world scenario: collaborative document editor
+
+- **Consistency:** Causal consistency with OT or CRDTs for concurrent edits.
+- **Failure handling:** Network disconnect → continue editing locally, queue operations. Reconnect → send queued operations, receive and transform missed operations.
+- **Key insight:** The user should never feel like they're waiting for the network to type.
+
+## Real-world scenario: e-commerce cart and checkout
+
+- **Consistency:** Cart is eventually consistent, optimistic. Checkout is strongly consistent, pessimistic, saga pattern.
+- **Failure handling:** Payment fails → clear error, don't lose cart. Price changed → show old vs. new, require confirmation.
+- **Key insight:** Optimism in browsing, pessimism in buying.
+
+## Real-world scenario: offline-first field service app
+
+- **Consistency:** Full offline-first with intent queue. Conflict resolution: field trumps office (technician was there).
+- **Failure handling:** Extended offline → app works indefinitely. Storage full → prioritize recent work, warn user.
+- **Key insight:** The app must be fully functional without network; connectivity is a bonus.
+
+## Design review checklist
+
+**Data Consistency:**
+- What consistency model does each data type need?
+- Are updates version-gated to prevent time travel?
+
+**Intent Preservation:**
+- Are user intents persisted before network delivery?
+- Do mutations use idempotency keys?
+- Can pending intents survive app restart?
+
+**Optimistic Updates:**
+- Which mutations use optimistic updates?
+- Can you always rollback?
+- Is optimism level matched to consequence severity?
+
+**Failure Handling:**
+- Are failures categorized by type and retryability?
+- Do components have explicit degradation policies?
+- Is data shape validated at boundaries?
+
+**Conflict Resolution:**
+- What's the conflict strategy for each data type?
+- How do you detect conflicts?
+
+## Red flags
+
+- "We'll handle conflicts later" — They happen in production
+- "We use timestamps to order updates" — Clock drift
+- "The spinner shows until the server responds" — No optimism for reversible actions
+- "Works online" — Not tested offline
+
+## Key takeaways
+
+- **State = projection of commands under unreliable delivery.** This mental model unifies optimistic UI, offline queues, retries, and reconciliation.
+- **Version-based monotonicity is your backbone.** Prefer server-issued versions over timestamps.
+- **Intent preservation is architecture.** Persist user intents with idempotency keys. Delivery is retry-safe.
+- **Optimism is a bet—size it appropriately.** Optimistic for reversible, pessimistic for irreversible.
+- **Partial failure is the norm.** Design for independent loading, component-level resilience.
+- **Categorize failures early.** Transport vs. application vs. concurrency vs. conflicts. Each has different handling.
+
+---
+
+## Further reading
+
+- [Eventually Consistent — Werner Vogels](https://www.allthingsdistributed.com/2008/12/eventually_consistent.html) — Amazon's CTO explains the consistency models behind large-scale distributed systems; provides the theoretical foundation for the patterns in this document.
+- [CRDT.tech](https://crdt.tech/) — A curated collection of CRDT research papers, libraries, and implementations; the starting point for understanding conflict-free replicated data types for collaborative and offline-first applications.
+- [Idempotency Keys — Stripe API Docs](https://stripe.com/docs/api/idempotent_requests) — Stripe's production implementation of idempotency keys; the industry reference for making retries safe and preventing duplicate operations.
+- [Saga Pattern — Microservices.io](https://microservices.io/patterns/data/saga.html) — Chris Richardson's pattern catalog explains how sagas coordinate multi-step operations with compensating transactions for failure recovery.
+- [XState Documentation](https://stately.ai/docs/xstate) — The leading state machine library for JavaScript; ideal for implementing the finite state machines that manage complex failure handling and multi-step workflows.
+
+---
+
+## Frequently Asked Questions (FAQs)
+
+1. **When should I use optimistic UI vs. wait for the server?**
+   Optimistic for reversible, low-stakes actions: likes, toggles, adding to cart. Pessimistic for irreversible, high-stakes actions: payment, delete. See [Human Perception](./human-perception.md) for how optimism affects perceived responsiveness.
+
+2. **What's an idempotency key and why do I need one?**
+   A unique ID sent with mutations so the server can deduplicate retries. Without it: network fails → client retries → action happens twice. For retry patterns, see [Asynchronous Operations](./asynchronous-operations.md). For HTTP method semantics, see [Network Protocols](./network-protocols.md).
+
+3. **How do I preserve user intent when the network fails?**
+   Intent preservation pattern: persist intent locally (IndexedDB) before network attempt, apply optimistic UI, retry with backoff. See [Caching Strategies](./caching-strategies.md) for offline caching patterns. See [Human Perception](./human-perception.md)—intent preservation is "non-negotiable."
+
+4. **What's the difference between eventual and strong consistency?**
+   Strong consistency: every read reflects the most recent write. Eventual consistency: reads may be temporarily stale but converge. For caching implications, see [Caching Strategies](./caching-strategies.md). For user perception of consistency, see [Human Perception](./human-perception.md).
+
+5. **How do I handle version conflicts when multiple users edit the same data?**
+   Strategies: last-write-wins, server-authoritative, field-level merge, user-mediated. For state management patterns, see [State Management at Scale](./state-management-at-scale.md). For communicating conflicts to users, see [Human Perception](./human-perception.md).
+
+6. **What causes "time travel" bugs where UI shows older data?**
+   Race conditions where older responses arrive after newer ones. Fix: version-gating. See [Asynchronous Operations](./asynchronous-operations.md) for commit guards. See [State Management at Scale](./state-management-at-scale.md) for state consistency patterns.
+
+7. **How do I implement offline-first architecture?**
+   Layers: local persistence (IndexedDB), intent queue with idempotency keys, sync engine, conflict resolution. See [Caching Strategies](./caching-strategies.md) for Service Worker patterns. See [State Management at Scale](./state-management-at-scale.md) for sources of truth.
+
+8. **How do I communicate failure states to users?**
+   Match communication to failure type: transient → silent retry, recoverable → inline notification, persistent → change UI affordance. See [Human Perception](./human-perception.md) for the six user-facing states every app should handle.
+
+9. **What's the "projection" mental model for state?**
+   State = projection of commands under unreliable delivery. This unifies optimistic UI, offline queues, retries, reconciliation. Related: [State Management at Scale](./state-management-at-scale.md) for replication design.
+
+10. **How do I test failure handling in the frontend?**
+    Simulate failures: network throttling, mock API errors, disable network. For production monitoring of failure rates, see [Observability](./observability.md). For testing component states, see [Testing and Storybook](../best-practices/testing-and-storybook.md) for error state stories.
+
+---
+
+*Never lose a user's work — build offline-ready, failure-resilient frontends with [Bitloops](https://bitloops.com).*
diff --git a/documentation/docs/frontend-copilot/ui-systems-performance/distributed-systems.md b/documentation/docs/frontend-copilot/ui-systems-performance/distributed-systems.md
new file mode 100644
index 00000000..e5243643
--- /dev/null
+++ b/documentation/docs/frontend-copilot/ui-systems-performance/distributed-systems.md
@@ -0,0 +1,625 @@
+---
+sidebar_position: 6
+sidebar_label: Distributed Systems
+title: "Edge Computing for Frontend: CDN Architecture, Cache Keys, and Execution Location"
+description: "Where should code execute—client, edge, or origin? Learn CDN cache architecture, cache key design, edge computing patterns, and latency optimization."
+keywords:
+  [
+    cdn caching frontend,
+    edge computing patterns,
+    vercel edge functions,
+    cloudflare workers frontend,
+    cdn cache key design,
+    origin shield cdn,
+    edge vs serverless,
+    global latency optimization,
+  ]
+---
+
+# Edge and CDN systems
+
+Every millisecond of latency costs conversion. Physics dictates that data traveling from Virginia to Tokyo takes ~150ms minimum—speed of light through fiber. You can't beat physics, but you can move your code and data closer to users. That's what distributed frontend systems are about.
+
+**Core framing: Edge is a policy layer.** It's less "run code near users" and more "enforce routing, caching, and safety policies close to users." This is more precise than generic edge hype.
+
+## The browser as part of a distributed system
+
+Classic distributed systems deal with data replication, consistency, and partition tolerance. Frontend distribution is the same: code, assets, and data replicated across geographic regions. The browser is just one node in a distributed system spanning client → edge → origin.
+
+SSR, SSG, ISR, edge functions—these are distributed systems patterns with new names. "Read replicas near users" is what CDNs do for static assets. "Write to primary, read from replica" is edge caching with origin fallback.
+
+## What makes frontend unique
+
+**Assets are naturally cacheable.** JS, CSS, and images rarely change—perfect for CDN distribution.
+
+**Personalization breaks caching.** User-specific content can't use shared caches naively.
+
+**The client is the final execution environment.** Edge can pre-process, but the browser renders.
+
+**Propagation time is visible.** Backend replication lag is internal. Frontend users see stale content.
+
+## The execution spectrum
+
+### Client (browser)
+
+Executes on user's device. Full access to DOM and browser APIs. Network latency is zero—it's already there. But CPU, memory, and I/O latency still apply; main thread contention is often the bottleneck. Personalization is unlimited. Cost is free (user's resources). Limitations: device capability, requires JS.
+
+### Edge (CDN PoP)
+
+Executes at CDN point of presence near user. Limited runtime (Cloudflare Workers, Vercel Edge, etc.). Latency: 10-50ms typically. Personalization via cookies, headers, geo data. Cost is per-request billing—can add up with fragmented cache keys. State is expensive and constrained at edge; design as if state is costly.
+
+### Origin (your server)
+
+Executes at your data center or cloud region. Full server capabilities. Latency: 50-300ms+ depending on user location. Unlimited personalization with database access. Limitations: distance from users, scaling challenges.
+
+**The spectrum:**
+
+```
+                Client          Edge            Origin
+                ─────────────────────────────────────────>
+Network         Zero            Low             High
+latency
+
+Data/State      Local only      Constrained     Full
+access                          (KV, cache)     (DB, files)
+
+Statefulness    Full            Limited/        Full
+                                Expensive
+```
+
+## Consistency models by resource type
+
+Instead of abstract CAP theorem discussions, define consistency per resource. *Consistency Models & Failure Handling* covers these models in depth—here we focus on their application to CDN caching:
+
+| Resource Type | Consistency Model | Invariant | Implementation |
+|---------------|-------------------|-----------|----------------|
+| Static assets | Strong (via immutability) | Content matches hash | Immutable URLs, cache forever |
+| HTML shell | Bounded staleness | Fresh within N minutes | TTL + SWR |
+| Catalog data | Eventually consistent | Acceptable lag | Short TTL, SWR at edge |
+| Price/inventory | Must be authoritative | Checkout price = displayed price | No cache or verify at commit |
+| User-specific | Private, fresh | Never show another user's data | `Cache-Control: private` |
+
+**The invariant question for each resource:**
+- What must never be wrong? (Price at checkout, permissions)
+- What can be stale? (Product descriptions, images)
+- What must be labeled as stale? (Dashboards showing "Last updated: 2 min ago")
+
+## CDN fundamentals
+
+A **Content Delivery Network** is a geographically distributed set of servers caching and serving content. A **PoP (Point of Presence)** is an individual CDN location. The **Origin** is your actual server where content originates.
+
+**How CDN caching works:**
+1. User requests resource
+2. Request routed to nearest PoP (via DNS/anycast)
+3. PoP checks cache:
+   - Cache HIT: Return cached response (fast)
+   - Cache MISS: Fetch from origin, cache response, return
+
+**Cache Key** uniquely identifies a cached response. Default is URL path + query string. Can include headers (Accept, Accept-Language), cookies, geo. Key principle: every factor in the key fragments the cache and increases cost.
+
+## Routing vs. caching order
+
+Where you execute edge logic affects hit rate and correctness.
+
+**Pattern 1: Edge function BEFORE cache lookup**
+
+```
+Request → Edge Function → (modifies cache key) → Cache Lookup → Origin
+```
+
+Use for: A/B test assignment, geo-routing, auth checks. Effect: Edge runs on every request; can affect cache key.
+
+**Pattern 2: Edge function AFTER cache hit (transform only)**
+
+```
+Request → Cache Lookup → (if hit) → Edge Function (transform) → Response
+```
+
+Use for: Response modification, header injection. Effect: Only runs on cached responses; preserves cache hit rate.
+
+**Pattern 3: Edge function on cache miss only**
+
+```
+Request → Cache Lookup → (if miss) → Edge Function → Origin → Cache → Response
+```
+
+Use for: Origin request modification. Effect: Only on misses; cached responses untouched.
+
+**Choose based on:**
+- Need to run on every request? → Before cache
+- Just transforming responses? → After cache
+- Only affecting origin requests? → On miss only
+
+## Cache key design
+
+Cache keys determine what's cached separately vs. shared. Too broad: wrong content served to users. Too narrow: every request is cache miss, costs explode.
+
+**Cache key fragmentation and cost:**
+
+```
+URL alone:               1 cache entry      → Low cost
+URL + Accept-Encoding:   3 entries          → Acceptable
+URL + Language:          10 entries         → Watch it
+URL + Country:           200+ entries       → Expensive, low hit rate
+URL + Cookie:            ∞ entries          → No caching, high origin load
+```
+
+Per-request billing at edge plus low hit rate from fragmented keys equals budget surprise.
+
+## Personalization: variant cardinality
+
+The cardinality rule: personalization strategy must bound the number of variants. Unbounded variants equals no effective caching.
+
+**Cardinality spectrum:**
+
+| Strategy | Variants | Hit Rate | Example |
+|----------|----------|----------|---------|
+| Same for all | 1 | ~95% | Static marketing page |
+| By country | ~200 | ~90% | Localized content |
+| By segment | 5-20 | ~80% | New/returning/premium |
+| By user | ∞ | ~0% | Dashboard data |
+
+**Flash of generic content:** Client-side personalization shows generic first, then fetches personalized. User sees generic content briefly. Mitigate with skeleton UI, below-fold personalization, or edge personalization.
+
+## Security & isolation at the edge
+
+Where CDN/edge systems fail in production is often security. *Security Boundaries* covers the broader threat model—here we focus on CDN-specific concerns.
+
+### Shared vs. private caching
+
+*Caching Strategies* covers the full cache stack and security implications. Here's the CDN-specific guidance:
+
+**Shared caches (CDN):** `Cache-Control: public`—OK to cache for multiple users. Must never contain user-specific data. Must never leak between users.
+
+**Private caches (browser):** `Cache-Control: private`—Cache only in user's browser. Safe for user-specific data.
+
+**Rule:** If the response contains any user-specific data, it must be `Cache-Control: private` or `no-store`.
+
+### The Vary header and cross-user safety
+
+```http
+Vary: Authorization
+Cache-Control: public, max-age=60
+```
+
+Without Vary, CDN might cache User A's response and serve it to User B.
+
+**Safe Vary values:**
+- `Accept-Encoding` (gzip, br)—Low cardinality, safe
+- `Accept-Language` (if supporting few languages)—Bounded, OK
+- `Authorization` or `Cookie`—Unbounded, effectively uncacheable at CDN
+
+### Token handling at edge
+
+**Don't log secrets:**
+
+```javascript
+// BAD
+console.log(`Processing request with token: ${token}`)
+
+// GOOD
+console.log(`Processing request for user: ${userId}`)
+```
+
+**Don't include tokens in cache keys:**
+
+```javascript
+// BAD
+const cacheKey = `${url}::${token}`
+
+// GOOD
+const cacheKey = `${url}::user=${userId}`
+```
+
+### Cache poisoning prevention
+
+Cache poisoning happens when an attacker tricks the cache into storing a malicious response. An attacker sends a request with malicious headers, the origin generates a response influenced by that input, the response is cached without the influencing factor in the key, and legitimate users get the poisoned cached response.
+
+**Prevention:**
+- Validate and sanitize inputs that influence response
+- Include influencing factors in cache key (or don't cache)
+- Use proper Vary headers
+- Don't reflect untrusted input in cacheable responses
+
+### Multi-tenant isolation
+
+For SaaS serving multiple tenants from one CDN:
+
+| Isolation Method | Implementation | Trade-off |
+|------------------|----------------|-----------|
+| Subdomain per tenant | `tenant1.app.com` | Strong isolation, DNS management |
+| Path prefix | `/tenant1/*` | Simpler, requires careful routing |
+| Header-based | `X-Tenant-ID` in cache key | Flexible, must validate |
+
+**Requirement:** Tenant A must never see Tenant B's cached data.
+
+## Origin protection patterns
+
+CDN isn't just for speed—it protects your origin.
+
+### Tiered caching / shield PoP
+
+The problem: N PoPs × cache miss = N origin requests for same content.
+
+**Shield pattern:**
+
+```
+User → Regional PoP → Shield PoP → Origin
+                         ↑
+                    One cache miss
+                    hits origin once
+```
+
+Regional PoPs check their cache, then forward miss to shield. Shield PoP is the only one that talks to origin. Origin sees shield PoP count, not regional PoP count.
+
+### Request coalescing
+
+The problem: 1000 requests arrive at PoP simultaneously for uncached resource = 1000 origin requests.
+
+**Coalescing pattern:**
+
+```
+1000 requests → PoP sees miss → Sends ONE request to origin
+                             → Holds other 999 requests
+                             → Origin responds
+                             → PoP responds to all 1000
+```
+
+Most CDNs do this automatically, but verify your configuration.
+
+### Circuit breaker: stale-if-error
+
+```http
+Cache-Control: max-age=60, stale-if-error=86400
+```
+
+If origin returns error, serve stale cache up to 24 hours. Users see slightly old content instead of error page. Buys time to fix origin. *Network Protocols* covers the circuit breaker pattern in detail—the same principle applies here at the CDN layer.
+
+```javascript
+async function fetchWithFallback(request, cache) {
+  try {
+    const response = await fetch(origin)
+    if (response.ok) {
+      await cache.put(request, response.clone())
+      return response
+    }
+    const stale = await cache.match(request)
+    if (stale) {
+      const headers = new Headers(stale.headers)
+      headers.set('X-Served-Stale', 'true')
+      return new Response(stale.body, { headers })
+    }
+    return response
+  } catch (e) {
+    const stale = await cache.match(request)
+    if (stale) return stale
+    throw e
+  }
+}
+```
+
+### Rate limiting at edge
+
+Move rate limiting to edge to protect origin:
+
+```javascript
+async function rateLimitedHandler(request, env) {
+  const ip = request.headers.get('CF-Connecting-IP')
+  const key = `ratelimit:${ip}`
+
+  const count = await env.KV.get(key) || 0
+  if (count > 100) {
+    return new Response('Rate limited', { status: 429 })
+  }
+
+  await env.KV.put(key, count + 1, { expirationTtl: 60 })
+  return fetch(request)
+}
+```
+
+## Observability & debugging
+
+"How do I prove what happened?" is essential for distributed systems. *Observability* covers the full telemetry pipeline—here we focus on CDN-specific concerns.
+
+### Cache status headers
+
+Every CDN provides cache status information:
+
+| CDN | Header | Values |
+|-----|--------|--------|
+| Cloudflare | `CF-Cache-Status` | HIT, MISS, EXPIRED, BYPASS, DYNAMIC |
+| Fastly | `X-Cache` | HIT, MISS, PASS |
+| Akamai | `X-Cache` | TCP_HIT, TCP_MISS |
+| Vercel | `X-Vercel-Cache` | HIT, MISS, STALE |
+
+Also check:
+- `Age`: Seconds since cached (0 = fresh from origin)
+- `X-Cache-Hits`: Number of times served from cache
+- Region/PoP identifiers: `CF-Ray`, `X-Served-By`
+
+### Trace correlation across layers
+
+Propagate request IDs. See *Observability* for W3C Trace Context and full distributed tracing implementation:
+
+```javascript
+export default async function handler(request) {
+  const requestId = request.headers.get('X-Request-ID')
+    || crypto.randomUUID()
+
+  const modifiedRequest = new Request(request)
+  modifiedRequest.headers.set('X-Request-ID', requestId)
+
+  const response = await fetch(modifiedRequest)
+
+  const modifiedResponse = new Response(response.body, response)
+  modifiedResponse.headers.set('X-Request-ID', requestId)
+
+  return modifiedResponse
+}
+```
+
+### Debugging geo-specific issues
+
+**How to reproduce "Tokyo sees X, London sees Y":**
+
+1. Force PoP via headers (if CDN supports)
+2. Use CDN's debug tools (Cloudflare Trace, Fastly Fiddle)
+3. Purge, then request from multiple locations
+4. Compare Age headers across regions
+5. Look for version mismatches in responses
+
+## Rollout safety patterns
+
+Propagation delay means deploys are distributed operations.
+
+### Immutable assets + versioned APIs
+
+**The safest pattern:**
+
+```
+Deploy sequence:
+1. Deploy new assets with new hashes: /app.abc123.js
+2. Deploy new API with backwards compatibility
+3. Deploy new HTML referencing new assets
+4. Old assets still served until HTML propagates
+5. After propagation: Remove old API support (optional)
+```
+
+No purge needed. No propagation race conditions.
+
+### Canary by region
+
+For edge functions with state or complexity:
+
+```javascript
+const canaryRegions = ['SFO', 'LAX']
+const isCanary = canaryRegions.includes(request.cf?.colo)
+
+if (isCanary) {
+  return newImplementation(request)
+} else {
+  return currentImplementation(request)
+}
+```
+
+Monitor canary metrics before expanding.
+
+## The trade-offs
+
+### Latency vs. consistency
+
+| Data Type | Latency Priority | Consistency Need | Strategy |
+|-----------|-----------------|------------------|----------|
+| Static assets | High | Via immutability | Long TTL, immutable URLs |
+| Product catalog | Medium | Bounded staleness | Short TTL + SWR |
+| Inventory/price | Low | Authoritative at commit | No cache or verify fresh |
+| User-specific | N/A | Private | Don't cache at CDN |
+
+### Cache hit rate vs. personalization
+
+```
+← Higher hit rate                              More personalized →
+
+Same for       Same per      Same per      Same per      Unique per
+everyone    →  country   →   segment   →   session   →   request
+(95%+ hit)     (90% hit)     (80% hit)     (10% hit)     (0% hit)
+```
+
+**Bound your cardinality.** If variants are unbounded, don't cache.
+
+### Edge logic vs. origin complexity
+
+**Put at edge:**
+- Authentication/authorization checks
+- A/B test assignment (bounded variants)
+- Geo-routing decisions
+- Header manipulation
+- Rate limiting
+
+**Keep at origin:**
+- Database queries
+- Complex business logic
+- Heavy computation
+- Unbounded personalization
+
+## Patterns
+
+### Immutable assets with content hash
+
+```
+// Build output
+app.3a7b9c.js
+styles.8f2e1d.css
+
+// HTTP headers
+Cache-Control: public, max-age=31536000, immutable
+```
+
+Content changes = new hash = new URL = no purge needed. Maximum cache hit rate. *Network Protocols* covers the full set of HTTP caching headers and how they interact.
+
+### Stale-while-revalidate at CDN
+
+```http
+Cache-Control: public, max-age=60, stale-while-revalidate=600
+```
+
+Users always get fast response. Content refreshes in background. Origin protected from thundering herd.
+
+### Surrogate keys for targeted purging
+
+```http
+Surrogate-Key: product-123 category-electronics homepage-featured
+```
+
+Update product → purge one tag → all URLs invalidated. More precise than purge-all. Faster than purging each URL.
+
+## Anti-patterns
+
+### Caching responses with Set-Cookie
+
+Session hijacking if cached response with `Set-Cookie` served to another user. Never cache responses with `Set-Cookie`. Use `Cache-Control: private` for personalized responses.
+
+### Vary on high-cardinality headers
+
+```http
+// DON'T
+Vary: Cookie           // ∞ variants
+Vary: User-Agent       // 1000s of variants
+Vary: Authorization    // ∞ variants
+```
+
+Vary only on bounded values. For user-specific content, use `Cache-Control: private`.
+
+## Real-world scenario: global e-commerce
+
+**Invariants defined:**
+- Checkout price must equal displayed price (verify fresh at checkout)
+- User cart must never show another user's items
+- Product images can be 1 hour stale
+
+**Architecture:**
+- Static assets: Immutable, cached forever
+- Product pages: SSG + SWR (1 hour)
+- Price/inventory: Edge fetch with 30s cache or client-side fresh fetch
+- Cart: `Cache-Control: private`, no CDN
+
+## Real-world scenario: news site with breaking news
+
+**Invariants defined:**
+- Breaking news must appear within 60 seconds
+- Article edits should propagate within 5 minutes
+- Traffic spikes must not kill origin
+
+**Architecture:**
+- Home page: TTL 60s, SWR 600s, surrogate key `homepage`
+- Articles: TTL 1 hour, surrogate key `article-{id}`
+- Breaking news: Purge `homepage` tag
+- Origin protection: Shield PoP, stale-if-error
+
+## Real-world scenario: multi-tenant SaaS
+
+**Invariants defined:**
+- Tenant A must never see Tenant B's data
+- Auth failures must be fast (don't hit origin)
+- Dashboard data is user-specific, not cacheable at CDN
+
+**Architecture:**
+- Tenant isolation: Subdomain per tenant in cache key
+- Auth at edge: JWT validation, reject invalid before origin
+- App shell: Cached (no user data)
+- Dashboard data: Client-side fetch, `Cache-Control: private`
+
+## Design review checklist
+
+**Execution Placement:**
+- What logic runs on client vs. edge vs. origin?
+- Does edge logic run before or after cache lookup?
+- Is edge logic within runtime constraints?
+
+**Consistency & Invariants:**
+- For each resource type, what's the consistency model?
+- What invariants must never be violated?
+- Is price/permission data verified fresh when it matters?
+
+**Security & Isolation:**
+- Is user-specific data marked `Cache-Control: private`?
+- Are Vary headers correct?
+- Is multi-tenant isolation enforced in cache keys?
+- Are tokens excluded from cache keys and logs?
+
+**Origin Protection:**
+- Is tiered caching / shield configured?
+- Is stale-if-error configured for outages?
+- Is rate limiting at edge?
+
+**Observability:**
+- Can you identify which PoP served a request?
+- Is request ID propagated edge → origin?
+- Can you reproduce geo-specific issues?
+
+## Red flags
+
+- "We cache based on cookie" — No effective caching
+- "Purge all on every deploy" — Missing targeted invalidation
+- "Users sometimes see old content" — Propagation delay not handled
+- "Origin keeps crashing on traffic spikes" — CDN not protecting origin
+- "Works in US but slow in Asia" — Not using CDN effectively
+
+## Key takeaways
+
+- **Edge is a policy layer.** Enforce routing, caching, and safety policies close to users. Not just "run code faster."
+- **Consistency models by resource type.** Define invariants: what must be correct, what can be stale, what must be labeled as stale.
+- **Security is where edge systems fail.** Cache poisoning, cross-user leakage, token exposure. Treat security as first-class.
+- **Origin protection is required.** Tiered caching, request coalescing, stale-if-error. CDN is your shield.
+- **Observability enables debugging.** Cache status headers, request IDs, PoP identification. "Tokyo sees X, London sees Y" must be reproducible.
+- **Cache key fragmentation has cost.** Unbounded personalization means no caching plus high bills.
+
+Every distribution decision should answer: What can be stale? What must be correct? What's the blast radius if this goes wrong?
+
+---
+
+## Further reading
+
+- [Designing Data-Intensive Applications — Martin Kleppmann](https://dataintensive.net/) — Chapter 5 covers data replication, consistency, and partition handling; the concepts map directly to CDN and edge caching behavior.
+- [Cloudflare Learning Center — What Is a CDN?](https://www.cloudflare.com/learning/cdn/what-is-a-cdn/) — A clear, approachable introduction to CDN architecture, caching, and edge networking concepts from one of the largest CDN providers.
+- [Cloudflare Workers Documentation](https://developers.cloudflare.com/workers/) — The leading edge runtime; covers KV storage, Durable Objects, and patterns for building stateful edge applications.
+- [Vercel Edge Functions Documentation](https://vercel.com/docs/functions/edge-functions) — Edge computing integrated with Next.js; practical guide to running server-side logic at the edge with framework-level support.
+- [Fastly Compute Documentation](https://www.fastly.com/products/edge-compute) — High-performance edge compute platform; useful for understanding how different providers approach edge execution constraints and trade-offs.
+
+---
+
+## Frequently Asked Questions (FAQs)
+
+1. **What's the execution spectrum: client vs. edge vs. origin?**
+   Client (browser): zero network latency, full browser APIs. Edge (CDN PoP): 10-50ms latency, limited runtime. Origin (your server): 50-300ms+ latency, full capabilities. For network layer details, see [Network Protocols](./network-protocols.md). For client-side state, see [State Management at Scale](./state-management-at-scale.md).
+
+2. **What's the difference between edge functions and serverless functions?**
+   Edge functions run at CDN nodes globally (low latency, constrained runtime). Serverless functions run in specific cloud regions (more compute, higher latency). For caching patterns at each layer, see [Caching Strategies](./caching-strategies.md).
+
+3. **How do I design cache keys for personalized content?**
+   Include only factors that vary the response: country, language, A/B variant—not user ID. See [Caching Strategies](./caching-strategies.md) for cache key fragmentation. For security implications, see [Security Boundaries](./security-boundaries.md).
+
+4. **What is origin shield and when should I use it?**
+   Origin shield is a designated CDN PoP that consolidates requests to your origin. Protects origin from thundering herd. Related: [Caching Strategies](./caching-strategies.md) for browser-level caching that further reduces origin load.
+
+5. **How do I invalidate CDN cache when content changes?**
+   Options: TTL expiration, purge API, surrogate keys, versioned URLs (most reliable). For browser cache invalidation, see [Caching Strategies](./caching-strategies.md). For HTTP headers that control caching, see [Network Protocols](./network-protocols.md).
+
+6. **When should content be cached at CDN vs. fetched fresh?**
+   CDN cache: static assets, public content with acceptable staleness. Fetch fresh: user-specific data, prices at checkout. For consistency requirements, see [Consistency and Failure Handling](./consistency-and-failure-handling.md). For user perception of staleness, see [Human Perception](./human-perception.md).
+
+7. **What are the security risks of CDN caching?**
+   Risks: cross-user data leakage, cache poisoning, sensitive data persisting. See [Security Boundaries](./security-boundaries.md) for token storage patterns. Use `Cache-Control: private` for user-specific data—see [Network Protocols](./network-protocols.md) for header syntax.
+
+8. **How do I debug CDN caching issues?**
+   Check response headers: cache status (HIT/MISS/BYPASS), Age, X-Cache headers. For production monitoring and debugging, see [Observability](./observability.md). Test from multiple locations.
+
+9. **What's stale-while-revalidate at the CDN level?**
+   `Cache-Control: max-age=60, stale-while-revalidate=600`: serve cached response immediately, revalidate in background. See [Caching Strategies](./caching-strategies.md) for application-level stale-while-revalidate. For how staleness affects user experience, see [Human Perception](./human-perception.md).
+
+10. **How do I balance latency vs. consistency in distributed systems?**
+    Define per-resource. See [Consistency and Failure Handling](./consistency-and-failure-handling.md) for consistency models. For performance implications, see [Performance Optimization](./performance-optimization.md). For user perception of latency, see [Human Perception](./human-perception.md).
+
+---
+
+*Move your code closer to your users and deliver globally with [Bitloops](https://bitloops.com) — your AI-powered frontend copilot.*
diff --git a/documentation/docs/frontend-copilot/ui-systems-performance/human-perception.md b/documentation/docs/frontend-copilot/ui-systems-performance/human-perception.md
new file mode 100644
index 00000000..7b17363a
--- /dev/null
+++ b/documentation/docs/frontend-copilot/ui-systems-performance/human-perception.md
@@ -0,0 +1,583 @@
+---
+sidebar_position: 11
+sidebar_label: Human Perception
+title: "Perceived Performance: Loading States, Optimistic UI, and Perception Budgets"
+description: "A 2-second load can feel faster than 3 seconds. Learn perception budgets, phase-based delivery, skeleton screens, and the psychology of waiting in UI design."
+keywords:
+  [
+    perceived performance optimization,
+    loading state ux patterns,
+    skeleton screen best practices,
+    optimistic ui patterns,
+    perception budgets frontend,
+    phase based page load,
+    ux response time thresholds,
+    psychological waiting time,
+  ]
+---
+
+# Perceived performance and human time
+
+A page that loads in 2 seconds but feels slow is slower than a page that loads in 3 seconds but feels fast. This isn't a UX trick—it's the core truth that separates frontend systems design from all other systems design. Every technical decision in this series ultimately serves one goal: how the system feels to the human using it.
+
+## Why this document is the capstone
+
+Every previous document's decisions affect perception:
+
+| Document | Perception Question |
+|----------|-------------------|
+| State Management | Does the data feel fresh? |
+| Caching | Does content feel instantly available? |
+| Async Operations | Does the UI feel responsive? |
+| Performance | Do metrics reflect perceived experience? |
+| Distributed Systems | Does edge delivery make things feel close? |
+| Network Protocols | Do requests complete without the user noticing? |
+| Security | Does the system feel trustworthy? |
+| Consistency | Does the data behave predictably? |
+| Observability | Can you detect when perception degrades? |
+
+**The perception gap:**
+- Technical metrics: LCP 2.5s, INP 150ms, API 200ms
+- User perception: "This feels sluggish"
+- The gap is where frontend systems design lives
+
+## The psychology of time perception
+
+| Duration | User Experience | Design Implication |
+|----------|----------------|-------------------|
+| 0-100ms | Instantaneous | Feedback must appear |
+| 100-300ms | Noticeable delay | Acknowledge input, show working |
+| 300-1000ms | "System is working" | Progress indication required |
+| 1000ms+ | Attention lost | Show meaningful progress |
+| 10000ms+ | Task abandoned | Avoid or explain timeline |
+
+**What affects perception (not just speed):**
+1. **Feedback:** Knowing something is happening
+2. **Progress:** Seeing advancement toward completion
+3. **Control:** Feeling in command
+4. **Predictability:** Knowing what to expect
+
+Perception is malleable. Same 2-second wait can feel faster or slower. Design decisions shape perception independent of actual speed.
+
+## Perception budgets
+
+Allocate milliseconds like you allocate memory. This is what makes perception design systems design, not vibes. *Performance Optimization* covers the technical metrics—here we translate them into human experience.
+
+### Interaction budget
+
+| Phase | Budget | What Must Happen |
+|-------|--------|------------------|
+| Input acknowledgment | < 100ms | Visual change (pressed state) |
+| Meaningful response | < 300ms | Result visible OR progress |
+| Completion | < 1000ms | Final state OR ETA |
+
+**Example: Button click**
+```
+0ms:    Click detected
+50ms:   Button shows pressed state (within budget)
+100ms:  Optimistic result appears (within budget)
+800ms:  Server confirms (user satisfied)
+```
+
+### Navigation budget
+
+| Phase | Budget | What Must Happen |
+|-------|--------|------------------|
+| Route change | < 100ms | URL updates, page transitions |
+| Destination shell | < 200ms | Skeleton visible |
+| Critical content | < 1000ms | Primary purpose visible |
+| Complete | < 3000ms | Above-fold loaded |
+
+### Completion budget
+
+| Phase | Budget | What Must Happen |
+|-------|--------|------------------|
+| Commit signal | < 100ms | User knows action captured |
+| Local confirmation | < 300ms | "Saved" / "Pending" visible |
+| Server confirmation | Best effort | Can exceed if local exists |
+
+**Key insight:** Server confirmation can take seconds if you've already acknowledged intent locally.
+
+## Phase-based delivery model
+
+The architectural pattern that stops "full-page spinner" designs.
+
+### The four phases
+
+**Phase 1: Acknowledge (0-100ms)**
+User action triggers immediate visual response. No content required—just "I heard you."
+
+**Phase 2: Stabilize (100-300ms)**
+Layout locked (no future CLS). Placeholders reserve space.
+
+**Phase 3: Deliver Critical Value (300-1000ms)**
+Primary purpose of the screen visible. User can begin consuming/acting.
+
+**Phase 4: Enhance (1000ms+)**
+Secondary content, personalization, below-fold content.
+
+**Why phases matter:**
+- Skip Phase 1 → "Feels unresponsive"
+- Skip Phase 2 → "Layout jumps, feels broken"
+- Slow Phase 3 → "Feels slow"
+- Slow Phase 4 → Acceptable (user already engaged)
+
+## Progress indication strategies
+
+| Type | Shows | Best For | Risks |
+|------|-------|----------|-------|
+| Spinner | "Something happening" | Short waits (< 3s) | Feels endless |
+| Progress bar | Percentage, ETA | Measurable progress | Stuck bar worse than spinner |
+| Skeleton | Shape of content | Predictable layouts | Wrong shape disappoints |
+| Content preview | Partial real content | Any content > none | Jump on full load |
+
+### The 150ms rule
+
+Don't show a loader immediately. If operation completes quickly, the loader flash is worse than nothing.
+
+```javascript
+function useDeferredLoading(isLoading, delay = 150) {
+  const [showLoader, setShowLoader] = useState(false)
+
+  useEffect(() => {
+    if (isLoading) {
+      const timer = setTimeout(() => setShowLoader(true), delay)
+      return () => clearTimeout(timer)
+    } else {
+      setShowLoader(false)
+    }
+  }, [isLoading, delay])
+
+  return showLoader
+}
+```
+
+### When not to use skeletons
+
+| Situation | Why Skeleton Fails | Alternative |
+|-----------|-------------------|-------------|
+| Content shape unpredictable | Wrong skeleton feels broken | Spinner |
+| Data loads very fast | Skeleton flashes | Nothing |
+| Content might not exist | Skeleton → empty = disappointment | "Loading" text |
+
+## Optimistic UI and the risk rubric
+
+Update UI immediately as if action succeeded. Reconcile with server in background. *Consistency Models & Failure Handling* covers the implementation patterns—intent preservation, idempotency keys, and rollback mechanisms. Here we focus on when to be optimistic.
+
+**But: Optimistic ≠ Lying**
+
+Optimistic designs should be explicitly labeled as pending when it matters.
+
+### Optimism risk classification
+
+| Stakes | Reversibility | Strategy | Pending State | Example |
+|--------|---------------|----------|---------------|---------|
+| Low | Reversible | Fully optimistic | None needed | Like, follow |
+| Medium | Visible consequence | Optimistic with pending | Subtle indicator | Cart add, comment |
+| High | Irreversible | Pessimistic | Wait for server | Payment, delete |
+
+**Low stakes:**
+```javascript
+function handleLike() {
+  setLiked(true)
+  setCount(c => c + 1)
+  api.like(postId).catch(() => {
+    setLiked(false)
+    setCount(c => c - 1)
+  })
+}
+```
+
+**Medium stakes:**
+```javascript
+function handleSubmit(text) {
+  const tempId = uuid()
+  addComment({
+    id: tempId,
+    text,
+    status: 'pending',  // Explicitly marked
+    author: currentUser
+  })
+
+  api.postComment(text)
+    .then(response => updateComment(tempId, { ...response, status: 'confirmed' }))
+    .catch(() => updateComment(tempId, { status: 'failed' }))
+}
+```
+
+**High stakes:**
+```javascript
+async function handlePayment() {
+  setProcessing(true)
+  showModal("Processing payment...")
+
+  const result = await api.processPayment(order)
+
+  if (result.success) {
+    showConfirmation(result.receipt)
+  } else {
+    showError(result.error)
+  }
+}
+```
+
+## Intent preservation (the hard invariant)
+
+**User input is durable before network.**
+
+This is non-negotiable. The user's work should never be lost due to network issues. *Consistency Models & Failure Handling* provides the full implementation pattern—command logs, idempotency keys, and recovery on restart.
+
+### The four guarantees
+
+**1. Drafts saved locally before submit**
+```javascript
+const [draft, setDraft] = usePersistentState(`draft-${formId}`)
+
+function handleChange(e) {
+  setDraft(e.target.value)  // Immediately persisted
+}
+```
+
+**2. Submissions queued if offline**
+```javascript
+async function handleSubmit(data) {
+  if (navigator.onLine) {
+    await api.submit(data)
+  } else {
+    await queue.add({ type: 'submit', data })
+    showNotification('Saved offline. Will sync when connected.')
+  }
+}
+```
+
+**3. UI distinguishes local vs. synced**
+```javascript
+function SyncStatus({ state }) {
+  switch (state) {
+    case 'local': return <span>Saved locally</span>
+    case 'syncing': return <span>Syncing...</span>
+    case 'synced': return <span>All changes synced</span>
+    case 'error': return <span>Sync failed. <Retry /></span>
+  }
+}
+```
+
+**4. Resume after refresh/crash**
+```javascript
+function recoverPendingWork() {
+  const pending = localStorage.getItem('pending-work')
+  if (pending) {
+    showRecoveryPrompt(JSON.parse(pending))
+  }
+}
+```
+
+## Universal user-facing states
+
+Define states that must be consistently expressed across the product.
+
+| State | User Meaning | Visual Treatment |
+|-------|--------------|------------------|
+| Idle | Ready for input | Normal appearance |
+| Working | Loading/processing | Spinner, skeleton |
+| Pending | Submitted, not confirmed | Subtle indicator |
+| Succeeded | Confirmed | Checkmark, "Saved" |
+| Failed | Needs attention | Error, retry option |
+| Degraded | Partial functionality | Banner, explanation |
+
+**The consistency rule:** The UI must never collapse these into "loading vs. not loading."
+
+Common violations:
+- Spinner that means both "loading" and "saving"
+- No distinction between "pending" and "succeeded"
+- Hiding failed state (silent failure)
+
+This is why users say "it's buggy." Inconsistent state expression creates confusion.
+
+## Error communication with trust math
+
+Error communication must respect frequency and habituation. *Consistency Models & Failure Handling* covers the failure taxonomy—here we focus on how to present failures to users.
+
+### The frequency rule
+
+| Error Frequency | Strategy |
+|-----------------|----------|
+| Rare (< 1%) | Interrupting patterns (modal, toast) |
+| Occasional (1-5%) | Inline, contextual feedback |
+| Common (> 5%) | Change the UI affordance |
+
+### Habituation rules
+
+1. **If system can recover automatically, don't interrupt.** Silent retry + subtle status.
+
+2. **If user must decide, interrupt once.** Clear CTA, don't ask twice.
+
+3. **Never show the same error repeatedly.** Deduplicate, use cooldowns, aggregate: "3 items failed" not 3 toasts.
+
+4. **Escalate, don't repeat.** First: toast. Persistent: inline status. Ongoing: banner.
+
+## Motion and perceived continuity
+
+Motion can mask latency—or create jank. *Performance Optimization* covers animation performance from a technical perspective—compositor-only properties, main thread contention. Here we focus on when motion helps perception.
+
+### When motion helps
+
+| Scenario | How It Helps |
+|----------|--------------|
+| Navigation transitions | Maintains spatial continuity |
+| Shared element animations | Connects old and new state |
+| Skeleton shimmer | Shows activity |
+| Micro-interactions | Provides instant feedback |
+
+### When motion hurts
+
+| Scenario | How It Hurts |
+|----------|--------------|
+| Long animations (> 300ms) | Feels slow |
+| Main thread competition | Causes jank |
+| Layout-triggering animations | Forces reflow |
+| Uninterruptible animations | Blocks user intent |
+
+### Motion performance rules
+
+```css
+/* GOOD: Compositor-only */
+.element {
+  transition: transform 200ms ease-out, opacity 200ms ease-out;
+}
+
+/* BAD: Layout-triggering */
+.element {
+  transition: width 200ms, height 200ms;  /* Forces reflow */
+}
+```
+
+**Guidelines:**
+- Keep animations < 200-300ms
+- Make animations cancelable
+- Animate opacity/transform only
+- Test on low-end devices
+
+## Perception debugging
+
+How to diagnose "feels slow" when metrics look fine. *Observability* covers the telemetry pipeline—here we focus on perception-specific instrumentation.
+
+| Symptom | Check For | Solution |
+|---------|-----------|----------|
+| "Feels unresponsive" | Feedback delayed (> 100ms) | Add immediate acknowledgment |
+| "Takes forever" | Progress unclear | Use phases or determinate progress |
+| "Feels broken" | Layout unstable (CLS) | Reserve space, use skeletons |
+| "Can't do anything" | UI blocked | Allow parallel interaction |
+| "Surprises me" | Jarring rollback | Add pending state |
+| "Unreliable" | Inconsistent states | Audit state → UI mapping |
+
+### Instrumenting perception
+
+```javascript
+function trackPerceptionEvent(type, duration) {
+  analytics.track('perception', {
+    type,
+    duration,
+    page: currentPage,
+    connection: navigator.connection?.effectiveType
+  })
+}
+
+trackPerceptionEvent('input_acknowledgment', timeToFirstVisualChange)
+trackPerceptionEvent('navigation_shell', timeToSkeletonVisible)
+```
+
+## The trade-offs
+
+### Honesty vs. perceived speed
+
+**Decision factors:**
+- How often does the operation fail? (< 1% → optimistic OK)
+- How bad is temporary wrong state?
+- How jarring is rollback?
+- What's user expectation?
+
+### Skeleton screens vs. spinners
+
+| Factor | Skeleton | Spinner |
+|--------|----------|---------|
+| Layout known | Use skeleton | Either |
+| Loads fast (< 200ms) | Skip loader | Skip loader |
+| Unpredictable shape | Spinner | Spinner |
+| Content-heavy | Skeleton | Not ideal |
+
+### Feedback frequency vs. noise
+
+- User-initiated → Immediate feedback
+- Background operation → Silent unless abnormal
+- Long operation → Progress indication
+- Transient issue → Silent recovery
+
+## Patterns
+
+### Phase-based page load
+```javascript
+showSkeleton()          // Phase 1: Acknowledge
+reserveLayoutSpace()    // Phase 2: Stabilize
+loadCriticalContent()   // Phase 3: Deliver
+loadSecondaryContent()  // Phase 4: Enhance
+```
+
+### Deferred loading indicator
+```javascript
+const showLoader = useDeferredLoading(isLoading, 150)
+```
+
+### Pending state with durability
+```javascript
+function Comment({ comment }) {
+  const isPending = comment.status === 'pending'
+  const isFailed = comment.status === 'failed'
+
+  return (
+    <div className={isPending ? 'pending' : ''}>
+      {comment.text}
+      {isPending && <span>Posting...</span>}
+      {isFailed && <button onClick={retry}>Retry</button>}
+    </div>
+  )
+}
+```
+
+## Anti-patterns
+
+### Full-page loading states
+Replace entire page with spinner. Fix: Preserve layout, use skeletons, load incrementally.
+
+### Silent failures
+Action fails but UI doesn't reflect it. Fix: Always confirm success or communicate failure.
+
+### Blocking UI during async
+User can't do anything while waiting. Fix: Allow interaction with other parts.
+
+### No pending vs. confirmed distinction
+User doesn't know if action completed. Fix: Explicit state indicators.
+
+## Perceived performance playbook
+
+A reusable artifact for design reviews.
+
+### Interaction playbook
+
+| Checkpoint | Budget | Must Happen |
+|------------|--------|-------------|
+| Input acknowledgment | < 100ms | Pressed state, focus |
+| Meaningful response | < 300ms | Result OR progress |
+| Completion | < 1s | Final state OR ETA |
+
+### Navigation playbook
+
+| Checkpoint | Budget | Must Happen |
+|------------|--------|-------------|
+| Route change | < 100ms | URL updates |
+| Destination shell | < 200ms | Skeleton visible |
+| Critical content | < 1s | Primary purpose visible |
+| Complete | < 3s | Above-fold loaded |
+
+### Mutation playbook
+
+| Checkpoint | Requirement |
+|------------|-------------|
+| Intent capture | Saved locally before network |
+| Pending state | Visible distinction from confirmed |
+| Failure handling | Retry option, data preserved |
+| Confirmation | Explicit success indicator |
+
+### Error playbook
+
+| Type | Response |
+|------|----------|
+| Transient, auto-recoverable | Silent retry |
+| Recoverable, user decision | Inline notification |
+| Persistent | Change UI affordance |
+| Blocking | Modal with explanation |
+
+## Design review checklist
+
+**Perception Budgets:**
+- Does input acknowledgment happen within 100ms?
+- Does meaningful response appear within 300ms?
+- Does navigation show shell within 200ms?
+
+**Phase-Based Delivery:**
+- Is layout stabilized before content (no CLS)?
+- Is critical content prioritized?
+
+**Optimism Risk:**
+- Is optimism level matched to stakes?
+- Are pending states visually distinct?
+
+**Intent Preservation:**
+- Is input persisted before network?
+- Can submissions queue offline?
+- Is "saved locally" vs. "synced" clear?
+
+**State Consistency:**
+- Are all six states consistently represented?
+
+## Key takeaways
+
+- **Perception is the only reality.** Technical metrics are proxies. The user's experience is what matters.
+- **Perception budgets are resource allocation.** 100ms for acknowledgment, 300ms for meaningful response, 1s for critical content.
+- **Phase-based delivery beats full-page loading.** Acknowledge → Stabilize → Deliver → Enhance.
+- **Optimism risk must match stakes.** Low = fully optimistic. High = pessimistic. Medium = pending states.
+- **Intent preservation is non-negotiable.** User input is durable before network. Never lose work.
+- **State expression must be consistent.** Six states, consistently rendered, is what makes a system feel reliable.
+
+## The frontend systems design thesis
+
+> Backend systems optimize for correctness. Frontend systems must optimize for correctness under perception, latency, and failure.
+
+This document is the lens through which all previous documents are evaluated. Every decision—*State Management at Scale*, *Caching Strategies*, *Asynchronous Operations*, *Performance Optimization*, *Distributed Systems*, *Network Protocols*, *Security Boundaries*, *Consistency Models & Failure Handling*, *Observability*—ultimately serves one goal: how the system feels to the human using it.
+
+---
+
+## Further reading
+
+- [Response Times: The 3 Important Limits — Nielsen Norman Group](https://www.nngroup.com/articles/response-times-3-important-limits/) — Jakob Nielsen's foundational article on the 100ms, 1s, and 10s thresholds that define how users perceive system responsiveness.
+- [Designing for Performance — Lara Hogan](https://designingforperformance.com/) — Freely available online; bridges performance engineering and design, showing how visual design choices directly impact perceived speed.
+- [Website Response Times — Nielsen Norman Group](https://www.nngroup.com/articles/website-response-times/) — Research-backed guidance on how response time affects user behavior, with data on when users abandon tasks and how to design for delay.
+- [The Psychology of Waiting Lines — David Maister](https://davidmaister.com/articles/the-psychology-of-waiting-lines/) — The seminal article explaining why occupied time feels shorter than unoccupied time, and how design can reduce perceived wait duration.
+
+---
+
+## Frequently Asked Questions (FAQs)
+
+1. **Why does a 3-second load sometimes feel faster than 2 seconds?**
+   Perception depends on feedback, progress, and control—not just duration. A 3-second load with instant input acknowledgment, skeleton, and progressive content feels faster than 2 seconds of blank screen. For technical performance metrics, see [Performance Optimization](./performance-optimization.md).
+
+2. **What are perception budgets?**
+   Time allocations for interaction phases: &lt;100ms for input acknowledgment, &lt;300ms for meaningful response, &lt;1s for critical content. For Core Web Vitals targets that align with these budgets, see [Performance Optimization](./performance-optimization.md). For monitoring these, see [Observability](./observability.md).
+
+3. **When should I use a skeleton screen vs. a spinner?**
+   Skeleton when layout is predictable and content-heavy. Spinner when layout varies or load is short (&lt;200ms). For testing loading states in Storybook, see [Testing and Storybook](../best-practices/testing-and-storybook.md). For preventing layout shift, see [Performance Optimization](./performance-optimization.md).
+
+4. **Should I show a loading indicator immediately?**
+   No. Delay indicators by ~150ms. If the operation completes quickly, users never see the indicator. For async operation patterns that support this, see [Asynchronous Operations](./asynchronous-operations.md).
+
+5. **What's phase-based delivery?**
+   Loading in stages with specific budgets: acknowledge input (&lt;100ms), stabilize layout (&lt;300ms), deliver critical content (&lt;1s). For network optimization that supports this, see [Performance Optimization](./performance-optimization.md). For CDN delivery, see [Distributed Systems](./distributed-systems.md).
+
+6. **How do I choose between optimistic and pessimistic UI?**
+   Match optimism to stakes. Low stakes + reversible → fully optimistic. High stakes + irreversible → pessimistic, wait for confirmation. For detailed patterns, see [Consistency and Failure Handling](./consistency-and-failure-handling.md).
+
+7. **What's intent preservation and why is it "non-negotiable"?**
+   User input is durable before network. The user's work must never be lost due to network issues. Persist intents locally before attempting delivery. See [Consistency and Failure Handling](./consistency-and-failure-handling.md) for idempotency keys. See [Caching Strategies](./caching-strategies.md) for offline persistence.
+
+8. **How do I debug "feels slow" when metrics look fine?**
+   Check perception phases: Is input acknowledged within 100ms? Is there visible feedback within 300ms? See [Observability](./observability.md) for RUM that captures real user experience. Check CLS—see [Performance Optimization](./performance-optimization.md).
+
+9. **What are the universal user-facing states every app should handle?**
+   Six states: Idle, Working, Pending, Succeeded, Failed, Degraded. See [Testing and Storybook](../best-practices/testing-and-storybook.md) for creating stories that cover these states. See [Consistency and Failure Handling](./consistency-and-failure-handling.md) for failure state patterns.
+
+10. **How does Human Perception connect to the rest of the systems series?**
+    Human Perception is the capstone. Every previous document's decisions affect perception: [State Management](./state-management-at-scale.md) (does data feel fresh?), [Caching](./caching-strategies.md) (does content feel instant?), [Async Operations](./asynchronous-operations.md) (does UI feel responsive?), [Performance](./performance-optimization.md) (do metrics reflect experience?), [Failure Handling](./consistency-and-failure-handling.md) (does the system feel reliable?).
+
+---
+
+*The best performance optimization is the one your users feel. Build frontends that feel instant with [Bitloops](https://bitloops.com).*
diff --git a/documentation/docs/frontend-copilot/ui-systems-performance/introduction.md b/documentation/docs/frontend-copilot/ui-systems-performance/introduction.md
new file mode 100644
index 00000000..ba416032
--- /dev/null
+++ b/documentation/docs/frontend-copilot/ui-systems-performance/introduction.md
@@ -0,0 +1,145 @@
+---
+sidebar_position: 1
+sidebar_label: Introduction
+title: "Frontend Systems Design: Distributed Systems Thinking for Web Applications"
+description: "Frontend apps are distributed systems. This 10-part series covers state replication, caching, async patterns, security, and performance from a systems design perspective."
+keywords:
+  [
+    frontend systems design,
+    distributed systems frontend,
+    frontend architecture patterns,
+    web application architecture,
+    systems thinking javascript,
+    frontend system design interview,
+    browser as distributed system,
+    frontend engineering principles,
+  ]
+---
+
+# UI Systems: An Introduction
+
+Frontend development has evolved. What was once about making pixels look right is now about building distributed systems that run on devices you don't control, over networks you can't trust, for users who expect instant responses.
+
+## Why system design Matters for Frontend
+
+The browser is a distributed system. Your application maintains replicas of server data, coordinates across tabs, handles network partitions (offline mode), and resolves conflicts when things diverge. These are the same problems backend engineers solve with databases and message queues—you're just solving them in JavaScript.
+
+**The core insight:**
+
+> Backend systems optimize for correctness. Frontend systems must optimize for correctness under perception, latency, and failure.
+
+A backend can take 500ms to process a request. A frontend that blocks for 500ms feels broken. This constraint changes everything: how you manage state, when you cache, how you handle failures, and what you show users while waiting.
+
+## What This Series Covers
+
+This 10-part series reframes frontend development through a systems design lens. Each document tackles a dimension of the problem:
+
+### Foundation Layer
+
+**1. State Management at Scale**
+State management isn't Redux vs. Zustand—it's replication design. You're constantly replicating server data to the client, keeping replicas fresh, and resolving conflicts when they diverge.
+
+**2. Caching Strategies**
+Every cache is a bet that serving stale data costs less than fetching fresh data. This document covers cache layers, invalidation strategies, and the security implications of getting it wrong.
+
+**3. Asynchronous Operations**
+Async bugs are state bugs. When operations corrupt your UI, they do so by committing stale results. Learn operation scopes, commit guards, and the patterns that prevent race conditions.
+
+### Infrastructure Layer
+
+**4. Performance Optimization**
+Performance isn't a feature to add later—it's a constraint to design within. Covers the performance pipeline from network delivery through rendering to user interaction.
+
+**5. Distributed Systems (CDNs & Edge)**
+Where code executes matters. Client, edge, or origin? Each has trade-offs for latency, consistency, and cost. Covers CDN architecture, cache keys, and edge computing patterns.
+
+**6. Network Protocols**
+HTTP semantics are contracts. Understanding methods, status codes, caching headers, and CORS isn't optional—it's foundational. Covers everything from request design to failure handling.
+
+### Resilience Layer
+
+**7. Security Boundaries**
+The client is hostile territory. Every piece of data from the browser is untrusted. Covers XSS, CSRF, CSP, token storage, and the principle of blast radius minimization.
+
+**8. Consistency Models & Failure Handling**
+The network will fail. Users will go offline. Operations will conflict. This document covers optimistic UI, intent preservation, offline-first patterns, and reconciliation strategies.
+
+**9. Observability**
+You can't improve what you can't measure. Covers telemetry pipelines, Real User Monitoring, distributed tracing, and the alerting strategies that catch problems before users report them.
+
+### Synthesis
+
+**10. Human Perception**
+The capstone. Technical metrics are proxies—what matters is how the system *feels*. A page that loads in 2 seconds but feels slow is slower than a page that loads in 3 seconds but feels fast. Every decision in the previous 9 documents serves this goal.
+
+## Who This Series Is For
+
+This series is for frontend developers who want to think beyond components and start reasoning about their applications as systems. Whether you are early in your frontend journey or have years of experience, the goal is the same: to build an intuition for how state, networks, performance, and user perception interact in real applications.
+
+You will find different value depending on where you are:
+
+- If you are earlier in your career, this series introduces the mental models behind concepts you may already be using—state management, caching, async code—without yet having names for the problems they solve.
+- If you are more experienced, it provides a structured way to reason about trade-offs, failure modes, and architectural decisions that often emerge only after systems have grown complex.
+
+This series is intentionally introductory. It does not attempt to be exhaustive, nor does it prescribe a single “correct” way to build frontend systems. Instead, it lays a foundation for deeper learning and sharper judgment—helping you recognize system-level problems earlier and reason about them more clearly.
+
+## About this series
+
+The ideas explored in this series are informed by practical experience building and reviewing production frontend systems. Over time, the same system-level concerns—state replication, async behavior, caching, failure handling, and user perception—tend to reappear, regardless of framework or stack.
+
+While many tools (including most AI-assisted ones) focus on accelerating code output, very few attempt to encode these system-level concerns directly into the way UI is built. A small number of tools aim to surface them earlier in the workflow, particularly in design-to-code contexts. [Bitloops](https://bitloops.com) is one such example, but the principles discussed here apply independently of any specific tool.
+
+---
+
+## Document Index
+
+| # | Document | Core question (why it matters) |
+|---:|---|---|
+| 1 | [State Management at Scale](./state-management-at-scale.md) | How do you define a source of truth when data is replicated across the server, client cache, UI state, and multiple tabs—and what rules keep it consistent? |
+| 2 | [Caching Strategies](./caching-strategies.md) | When is it safe to serve stale data, where should you cache it (memory, persistent storage, CDN), and how do you invalidate without breaking correctness or security? |
+| 3 | [Asynchronous Operations](./asynchronous-operations.md) | How do you prevent race conditions where older requests “win,” stale results overwrite newer intent, and UI state becomes corrupted under latency or retries? |
+| 4 | [Performance Optimization](./performance-optimization.md) | What is actually on the critical path from navigation to interaction, and how do you design within performance constraints rather than “optimizing later”? |
+| 5 | [Distributed Systems (CDNs & edge)](./distributed-systems.md) | Where should code and data execute (client, edge, origin), and how do you balance latency, consistency, personalization, and cost across that execution model? |
+| 6 | [Network Protocols](./network-protocols.md) | How do HTTP semantics (methods, status codes, caching headers, retries, CORS) shape system behavior—and what happens when you treat them as implementation details? |
+| 7 | [Security Boundaries](./security-boundaries.md) | What must the client never be trusted with, how do you minimize blast radius when something goes wrong, and what are the common web attack paths that exploit frontend assumptions? |
+| 8 | [Consistency & Failure Handling](./consistency-and-failure-handling.md) | What should the UI do when the network is slow, offline, or conflicting—how do you preserve user intent, reconcile outcomes, and avoid “lying UI”? |
+| 9 | [Observability](./observability.md) | How do you know the system is healthy in the real world—what should you measure, how do you trace failures across layers, and how do you catch regressions before users report them? |
+| 10 | [Human Perception](./human-perception.md) | What does “fast” feel like to a user, and how do you design loading, feedback, and interaction so the system remains trustworthy under delay and failure? |
+
+---
+
+## Frequently Asked Questions (FAQs)
+
+1. **Why should frontend developers learn systems design?**
+   The browser is a distributed system—it replicates server data, handles network partitions (offline mode), and resolves conflicts when state diverges. See [State Management at Scale](./state-management-at-scale.md) for replication patterns and [Consistency and Failure Handling](./consistency-and-failure-handling.md) for offline-first architecture.
+
+2. **How is frontend systems design different from backend?**
+   Same problems, different constraints. Backend optimizes for throughput and correctness. Frontend must optimize for correctness under perception and latency—see [Human Perception](./human-perception.md) for why a 500ms block feels broken even when metrics are "acceptable."
+
+3. **Is this series for junior or senior developers?**
+   Both benefit differently. Juniors get mental models for concepts they're already using ([State Management](./state-management-at-scale.md), [Caching](./caching-strategies.md), [Async Operations](./asynchronous-operations.md)). Seniors get a structured framework for trade-offs they've learned through experience.
+
+4. **Do I need to read the series in order?**
+   The series builds progressively, with [Human Perception](./human-perception.md) as the capstone. But each document stands alone. Start with your current pain point: async bugs → [Asynchronous Operations](./asynchronous-operations.md), performance → [Performance Optimization](./performance-optimization.md).
+
+5. **What's the "perception gap" mentioned in the introduction?**
+   The gap between technical metrics (LCP 2.5s, API 200ms) and user experience ("this feels sluggish"). See [Human Perception](./human-perception.md) for perception budgets and [Observability](./observability.md) for measuring what users actually experience.
+
+6. **How do these concepts apply to my specific framework (React, Vue, Svelte)?**
+   The systems concepts—state replication, caching, failure handling—are framework-agnostic. For framework-specific component patterns, see the [Best Practices series](../best-practices/introduction.md) which covers React examples that apply to any component model.
+
+7. **Is this relevant for simple websites or only complex web apps?**
+   Even simple sites face these issues: caching decisions (see [Caching Strategies](./caching-strategies.md)), loading states (see [Human Perception](./human-perception.md)), error handling (see [Consistency and Failure Handling](./consistency-and-failure-handling.md)). The principles apply universally.
+
+8. **How does this relate to backend system design interviews?**
+   Frontend system design is increasingly part of technical interviews. Understanding replication (see [State Management](./state-management-at-scale.md)), caching (see [Caching Strategies](./caching-strategies.md)), and failure handling prepares you for these discussions with frontend-specific depth.
+
+9. **What tools or libraries implement these concepts?**
+   TanStack Query implements caching and revalidation patterns (see [Caching Strategies](./caching-strategies.md)). Zustand/Redux implement state management (see [State Management at Scale](./state-management-at-scale.md)). Understanding the underlying concepts helps you use these tools correctly.
+
+10. **How does Bitloops relate to these systems concepts?**
+    Bitloops generates code that applies these concepts by default: proper loading states (see [Human Perception](./human-perception.md)), data contracts (see [Data Contracts](../best-practices/data-contracts.md)), accessible components (see [Accessibility](../best-practices/accessibility.md)).
+
+---
+
+*Designing frontends that scale starts with thinking in systems. Start building with [Bitloops](https://bitloops.com) — your AI-powered frontend copilot.*
diff --git a/documentation/docs/frontend-copilot/ui-systems-performance/network-protocols.md b/documentation/docs/frontend-copilot/ui-systems-performance/network-protocols.md
new file mode 100644
index 00000000..c3ebc386
--- /dev/null
+++ b/documentation/docs/frontend-copilot/ui-systems-performance/network-protocols.md
@@ -0,0 +1,802 @@
+---
+sidebar_position: 7
+sidebar_label: Network Protocols
+title: "HTTP for Frontend Developers: Methods, Caching Headers, CORS, and Failure Handling"
+description: "HTTP isn't just transport—it's a contract. Learn method semantics, status codes, Cache-Control headers, CORS preflight, and retry patterns for frontend applications."
+keywords:
+  [
+    http methods frontend,
+    cors explained simply,
+    fetch api best practices,
+    cache control headers guide,
+    http status codes frontend,
+    retry with exponential backoff,
+    preflight request cors,
+    http 2 http 3 frontend,
+  ]
+---
+
+# HTTP contracts and failures
+
+The network is the most unreliable part of your system, yet every feature depends on it. But here's what most frontend developers miss: **HTTP is not just transport—it's a contract**. Every header, method, and status code carries semantic meaning that caches, proxies, browsers, and servers use to make decisions. Understanding these contracts is the difference between an app that survives the real world and one that dies on the first slow connection.
+
+## Protocols define behavior, not just move bytes
+
+Backend engineers obsess over protocols: TCP tuning, connection pooling, keep-alives, retries. Frontend often treats the network as magic: call `fetch()`, get data (eventually). Every HTTP decision affects performance, reliability, and cacheability. The browser is a protocol enforcement point—it makes decisions based on headers you send.
+
+Protocol as contract means:
+- Method choice determines cacheability and retry safety
+- Status codes tell clients (and intermediaries) how to behave
+- Headers are instructions to all parties in the chain
+- Breaking these contracts breaks caching, security, and reliability
+
+## What makes frontend unique
+
+- **The network is maximally hostile.** Mobile, WiFi, 3G, flaky coffee shop connections.
+- **Users see failures directly.** Backend errors go to logs. Frontend errors create angry users.
+- **Limited control over transport.** Can't tune TCP, limited HTTP/2 prioritization control.
+- **Browser is the client.** Browser implements HTTP; you configure it via headers and fetch options.
+- **Cross-origin is default.** Most API calls cross origin, triggering CORS.
+
+## HTTP semantics as contract
+
+HTTP methods have meaning beyond "send request." Caches, proxies, CDNs, and browsers behave differently based on method. Misusing methods breaks caching, causes bugs, and creates security issues.
+
+### Methods and their semantics
+
+**GET — Retrieve resource**
+- Safe: No side effects on server
+- Idempotent: Multiple identical requests produce same result
+- Cacheable: By default (this is why caches can store it)
+- Body: Technically allowed but semantically meaningless—avoid
+- Use for: Reading data, page loads, search queries
+
+**POST — Create resource or trigger action**
+- NOT safe: Has side effects
+- NOT idempotent: Each request may create new resource
+- NOT cacheable: By default
+- Use for: Creating records, form submissions, anything with side effects
+- Warning: Never use for reads—breaks caching, back button, prefetch
+
+**PUT — Replace resource entirely**
+- NOT safe: Has side effects
+- Idempotent: Multiple identical requests produce same final state (key difference from POST)
+- Use for: Full resource replacement, upload entire document
+
+**PATCH — Partial update**
+- NOT safe: Has side effects
+- NOT necessarily idempotent: Depends on patch format
+- Use for: Partial updates when sending full resource is wasteful
+- Warning: Increment operations (`{"count": "+1"}`) are NOT idempotent
+
+**DELETE — Remove resource**
+- NOT safe: Has side effects
+- Idempotent: Deleting already-deleted resource returns success
+- Use for: Removing records
+
+| Method | Safe | Idempotent | Cacheable | Body Semantics | Typical Use |
+|--------|------|------------|-----------|----------------|-------------|
+| GET | Yes | Yes | Yes (see *Caching Strategies*) | Ignored | Read data |
+| POST | No | No | No* | Request body | Create, actions |
+| PUT | No | Yes | No | Complete resource | Full replace |
+| PATCH | No | Maybe | No | Partial changes | Partial update |
+| DELETE | No | Yes | No | Optional | Remove |
+
+*POST responses can be cached with explicit Cache-Control, but requests cannot be deduplicated
+
+## Status codes as communication
+
+Status codes tell clients (and intermediaries) what happened and what to do next.
+
+**2xx — Success**
+- `200 OK`: Standard success, response has body
+- `201 Created`: Resource created (POST success), should include Location header
+- `204 No Content`: Success, no body (common for DELETE, PUT)
+
+**3xx — Redirection**
+- `301 Moved Permanently`: Resource URL changed forever (cacheable)
+- `302 Found` / `307 Temporary Redirect`: Temporary redirect (307 preserves method)
+- `304 Not Modified`: Conditional request valid, use cached version
+
+**4xx — Client Error (don't retry with same request)**
+- `400 Bad Request`: Malformed request syntax
+- `401 Unauthorized`: Authentication required or failed
+- `403 Forbidden`: Authenticated but not permitted
+- `404 Not Found`: Resource doesn't exist
+- `409 Conflict`: State conflict (optimistic concurrency failure)
+- `422 Unprocessable Entity`: Syntactically valid but semantically wrong
+- `429 Too Many Requests`: Rate limited—check Retry-After header
+
+**5xx — Server Error (potentially retryable)**
+- `500 Internal Server Error`: Generic server failure
+- `502 Bad Gateway`: Upstream server failed
+- `503 Service Unavailable`: Server overloaded—check Retry-After header
+- `504 Gateway Timeout`: Upstream server timeout
+
+**Client-side handling:**
+
+```javascript
+async function fetchWithErrorHandling(url) {
+  const response = await fetch(url)
+
+  if (response.ok) {
+    return response.json()
+  }
+
+  switch (response.status) {
+    case 401:
+      throw new AuthError('Authentication required')
+    case 403:
+      throw new ForbiddenError('Access denied')
+    case 400:
+    case 404:
+    case 422:
+      throw new ClientError(response.status, await response.json())
+    case 429:
+      const retryAfter = response.headers.get('Retry-After')
+      throw new RateLimitError(retryAfter)
+    case 500:
+    case 502:
+    case 503:
+    case 504:
+      throw new ServerError(response.status, true)
+    default:
+      throw new HttpError(response.status)
+  }
+}
+```
+
+## CORS and cross-origin semantics
+
+Browsers enforce same-origin policy by default. Most modern apps call APIs on different origins. CORS is the browser's mechanism for controlled cross-origin access. **CORS is enforced by the browser, not the server**—the server just declares what's allowed. *Security Boundaries* covers the same-origin policy and broader security implications.
+
+### Simple requests vs. preflighted requests
+
+**Simple Request (no preflight)** requires all of:
+- Method: GET, HEAD, or POST
+- Headers: Only safe headers (Accept, Accept-Language, Content-Language)
+- Content-Type: Only text/plain, multipart/form-data, or application/x-www-form-urlencoded
+
+**Preflighted Request** when any criteria above is NOT met:
+- Non-simple methods (PUT, DELETE, PATCH)
+- Custom headers (Authorization, X-Custom-Header)
+- Content-Type: application/json (most API calls)
+
+### The preflight flow
+
+```
+1. Browser sends OPTIONS request (preflight)
+   → Origin: https://app.example.com
+   → Access-Control-Request-Method: POST
+   → Access-Control-Request-Headers: Content-Type, Authorization
+
+2. Server responds with permissions
+   ← Access-Control-Allow-Origin: https://app.example.com
+   ← Access-Control-Allow-Methods: GET, POST, PUT, DELETE
+   ← Access-Control-Allow-Headers: Content-Type, Authorization
+   ← Access-Control-Max-Age: 86400
+
+3. If allowed, browser sends actual request
+4. If denied, browser blocks request (never sent to server)
+```
+
+### Key CORS headers
+
+**Request headers (sent by browser):**
+- `Origin`: Where the request comes from
+- `Access-Control-Request-Method`: What method will be used
+- `Access-Control-Request-Headers`: What custom headers will be sent
+
+**Response headers (set by server):**
+- `Access-Control-Allow-Origin`: Which origins can access
+- `Access-Control-Allow-Methods`: Which methods are permitted
+- `Access-Control-Allow-Headers`: Which request headers are permitted
+- `Access-Control-Allow-Credentials`: Whether cookies/auth can be sent
+- `Access-Control-Max-Age`: How long to cache preflight response
+- `Access-Control-Expose-Headers`: Which response headers JS can read
+
+### Common CORS mistakes
+
+**Using `*` with credentials:**
+```http
+# INVALID - browser will reject
+Access-Control-Allow-Origin: *
+Access-Control-Allow-Credentials: true
+```
+Must specify exact origin when credentials are allowed.
+
+**Forgetting exposed headers:**
+```javascript
+// Can't read custom headers without Access-Control-Expose-Headers
+const customId = response.headers.get('X-Request-Id')  // null!
+```
+
+**Missing preflight cache:** Without `Access-Control-Max-Age`, every request triggers preflight.
+
+## Credentials and session semantics
+
+The `credentials` option controls whether cookies and auth headers are sent. *Security Boundaries* covers token storage trade-offs (HTTPOnly cookies vs. localStorage vs. memory) and CSRF protection:
+
+```javascript
+// Omit: Never send cookies (default for cross-origin)
+fetch(url, { credentials: 'omit' })
+
+// Same-origin: Send cookies only to same origin (default)
+fetch(url, { credentials: 'same-origin' })
+
+// Include: Always send cookies (needed for cross-origin auth)
+fetch(url, { credentials: 'include' })
+```
+
+Cross-origin requests don't include cookies by default. Even with `credentials: 'include'`, server must allow with `Access-Control-Allow-Credentials: true` and respond with specific origin (not `*`).
+
+| Aspect | Cookies | Authorization Header |
+|--------|---------|---------------------|
+| Sent automatically | Yes (if credentials included) | No (must add manually) |
+| HttpOnly possible | Yes (secure) | No (visible to JS) |
+| CSRF risk | High (sent automatically) | Low (must be added) |
+| Preflight trigger | No | Yes |
+
+## HTTP headers for caching
+
+**Cache-Control** is a directive, not a guarantee. It tells caches what they're allowed to do. *Caching Strategies* covers the full cache stack and how HTTP headers interact with application-level caching. *Distributed Systems* covers CDN behavior.
+
+```http
+# Cache publicly (CDN + browser) for 1 hour
+Cache-Control: public, max-age=3600
+
+# Cache only in browser for 10 minutes
+Cache-Control: private, max-age=600
+
+# Don't store anywhere (sensitive data)
+Cache-Control: no-store
+
+# Can cache but must revalidate before each use
+Cache-Control: no-cache
+
+# Serve stale while revalidating in background
+Cache-Control: max-age=60, stale-while-revalidate=600
+
+# Never changes (use ONLY with fingerprinted URLs)
+Cache-Control: public, max-age=31536000, immutable
+```
+
+**Important distinction:**
+- `no-cache`: Cache can store but must revalidate before serving
+- `no-store`: Cache must not store at all (use for sensitive data)
+
+### Conditional requests
+
+**ETag — Content fingerprint:**
+```http
+# Server response includes fingerprint
+ETag: "abc123"
+
+# Client includes in subsequent request
+If-None-Match: "abc123"
+
+# Server responds
+304 Not Modified  (if same)
+200 OK + new body (if different)
+```
+
+**Last-Modified — Time-based validation:**
+```http
+# Server response
+Last-Modified: Wed, 21 Oct 2023 07:28:00 GMT
+
+# Client request
+If-Modified-Since: Wed, 21 Oct 2023 07:28:00 GMT
+```
+
+ETag is more precise (content-based). Last-Modified has 1-second resolution. Use both for maximum compatibility.
+
+**Vary — Cache key modification:**
+```http
+# Different response per encoding
+Vary: Accept-Encoding
+
+# DON'T: Vary on Cookie (every user gets separate cache)
+```
+
+## Connection establishment costs
+
+Every new connection has overhead before data transfers. Understanding costs explains why keep-alive and multiplexing matter.
+
+- **DNS Resolution:** 20-120ms to resolve hostname to IP address. Cached by OS and browser.
+- **TCP Handshake:** 1 RTT (50-100ms good networks, 200-400ms mobile). SYN → SYN-ACK → ACK.
+- **TLS Handshake:** 1-2 RTT for certificate exchange and key negotiation. TLS 1.3 reduces to 1 RTT.
+- **Total new connection cost:** 300-700ms before first byte.
+- **Optimization strategies:**
+
+```html
+<!-- Establish connection early -->
+<link rel="preconnect" href="https://api.example.com">
+
+<!-- Just do DNS lookup -->
+<link rel="dns-prefetch" href="https://cdn.example.com">
+```
+
+## HTTP/2 and HTTP/3
+
+**HTTP/1.1 limitations:**
+- One request/response at a time per connection (HTTP-level head-of-line blocking)
+- Browsers open 6 connections per domain as workaround
+- Headers repeated every request
+
+### HTTP/2 features
+
+- **Multiplexing:** Multiple requests/responses on single connection. Solves HTTP-level head-of-line blocking.
+- **But TCP HOL blocking remains:** HTTP/2 runs over TCP. Lost packet blocks ALL streams until retransmitted. On lossy mobile networks, can be worse than HTTP/1.1.
+- **Header compression (HPACK):** Headers compressed and deduplicated across requests. First request sends full headers, subsequent send diffs.
+- **Server Push (largely deprecated):** Browsers disabled it, HTTP/3 dropped it. Better alternatives: `<link rel="preload">`, Early Hints (103).
+
+### HTTP/3 (QUIC)
+
+- **UDP-based, solves TCP HOL:** Each stream independent at transport layer. Lost packet only blocks affected stream.
+- **Faster connection establishment:** 0-RTT for repeat connections, 1-RTT for new connections (vs. 2-3 RTT for TCP+TLS).
+- **Better mobile performance:** Connection migration survives IP changes. More resilient to packet loss.
+- **Frontend implications:** Mostly transparent. Check if your CDN supports HTTP/3. Benefits most apparent on lossy mobile networks.
+
+## Compression
+
+Text compresses extremely well (70-90% reduction). Less data means faster transfer, especially on slow networks.
+
+- **gzip:** Universal support, ~70% compression for text, fast.
+- **Brotli:** Better compression than gzip (~15-20% smaller), slower to compress at high levels, modern browser support.
+
+```http
+# Request: Client advertises support
+Accept-Encoding: gzip, deflate, br
+
+# Response: Server indicates what's used
+Content-Encoding: br
+```
+
+**When to compress:**
+- Text formats: HTML, CSS, JS, JSON, SVG — Always
+- Images: JPEG, PNG, WebP — Already compressed, skip
+- Small files (< 1KB): Overhead may exceed benefit
+
+## Streaming and real-time
+
+*Asynchronous Operations* covers backpressure handling when streams produce faster than you can consume. Here we focus on the protocol-level patterns.
+
+**Traditional Request/Response:** Client sends request, server sends complete response. Simple, cacheable, stateless. Use for most data fetching.
+
+**Server-Sent Events (SSE):**
+```javascript
+const eventSource = new EventSource('/events')
+eventSource.onmessage = (event) => console.log(event.data)
+eventSource.onerror = (e) => console.log('SSE error/reconnecting')
+```
+- Unidirectional: Server → Client only
+- Automatic reconnection with Last-Event-ID
+- HTTP-based (works through proxies)
+- Use for: Notifications, live feeds, real-time updates
+
+**WebSocket:**
+```javascript
+const ws = new WebSocket('wss://example.com/socket')
+ws.onopen = () => ws.send(JSON.stringify({ type: 'subscribe' }))
+ws.onmessage = (event) => console.log(JSON.parse(event.data))
+ws.onclose = (event) => {
+  if (!event.wasClean) scheduleReconnect()
+}
+```
+- Bidirectional: Full duplex communication
+- Binary or text supported
+- Manual reconnection logic needed
+- Use for: Chat, collaborative editing, gaming
+
+**Long Polling (fallback):**
+```javascript
+async function longPoll(signal) {
+  while (!signal.aborted) {
+    const controller = new AbortController()
+    const timeoutId = setTimeout(() => controller.abort(), 30000)
+
+    try {
+      const response = await fetch('/poll', { signal: controller.signal })
+      clearTimeout(timeoutId)
+      if (response.ok) handleUpdate(await response.json())
+    } catch (error) {
+      if (error.name !== 'AbortError') await sleep(1000)
+    }
+  }
+}
+```
+
+| Pattern | Direction | Reconnect | Binary | Proxy-Friendly | Best For |
+|---------|-----------|-----------|--------|----------------|----------|
+| Polling | Request-driven | N/A | Yes | Yes | Infrequent updates |
+| Long Polling | Simulated push | Manual | Yes | Usually | Fallback option |
+| SSE | Server → Client | Auto | No | Yes | Notifications, feeds |
+| WebSocket | Bidirectional | Manual | Yes | Maybe | Chat, collaboration |
+
+## Failure behavior
+
+*Consistency Models & Failure Handling* covers failure handling from a state perspective—how to preserve user intent and handle partial failures. Here we focus on the network layer.
+
+**Failure taxonomy by retryability:**
+- **Transient (retry):** 503, 504, network hiccup, timeout
+- **Permanent (don't retry):** 400, 401, 403, 404, 422
+- **Ambiguous (retry with idempotency):** 500, 502, connection reset mid-request
+
+**Important:** `fetch` does not have a native timeout option. Use AbortController.
+
+```javascript
+async function fetchWithTimeout(url, options = {}, timeout = 5000) {
+  const controller = new AbortController()
+  const timeoutId = setTimeout(() => controller.abort(), timeout)
+
+  try {
+    const response = await fetch(url, {
+      ...options,
+      signal: controller.signal
+    })
+    clearTimeout(timeoutId)
+    return response
+  } catch (error) {
+    clearTimeout(timeoutId)
+    if (error.name === 'AbortError') {
+      throw new TimeoutError(`Request timed out after ${timeout}ms`)
+    }
+    throw error
+  }
+}
+```
+
+**Timeout guidelines:**
+- Fast operations (cache hit likely): 2-5 seconds
+- Normal operations: 5-10 seconds
+- Slow operations (reports, exports): 30-60 seconds
+- **Always set a timeout** — browser may wait 2+ minutes by default
+
+## Observability headers
+
+*Observability* covers the full telemetry pipeline—here we focus on the protocol-level headers that enable distributed tracing.
+
+**Request correlation:**
+```http
+# Request includes correlation ID
+X-Request-Id: abc-123-def-456
+
+# Response echoes it
+X-Request-Id: abc-123-def-456
+```
+
+Trace requests through CDN → load balancer → server. Correlate client-side errors with server logs.
+
+**Server Timing API:**
+```http
+Server-Timing: db;dur=53, cache;desc="Cache Read";dur=23.2
+```
+
+```javascript
+const entry = performance.getEntriesByType('resource')[0]
+entry.serverTiming.forEach(t => console.log(`${t.name}: ${t.duration}ms`))
+```
+
+## The trade-offs
+
+### Request batching vs. granular caching
+
+**Batched requests:**
+```javascript
+const data = await fetch('/api/products?ids=1,2,3,4,5')
+```
+Fewer requests, less overhead, but all-or-nothing caching.
+
+**Granular requests:**
+```javascript
+const products = await Promise.all([
+  fetch('/api/products/1'),
+  fetch('/api/products/2'),
+])
+```
+Individual caching, parallel with HTTP/2, but more overhead.
+
+| Factor | Favor Batching | Favor Granular |
+|--------|---------------|----------------|
+| Protocol | HTTP/1.1 | HTTP/2+ |
+| Cache TTL | Items have same TTL | Items change at different rates |
+| Access pattern | Always need all together | Often need subset |
+| Error handling | All-or-nothing OK | Need individual error handling |
+
+### Polling vs. push
+
+**Cost analysis:**
+```
+Polling every 5s, 10K users:
+  = 10,000 × 12 requests/min × 60 min = 7.2M requests/hour
+
+WebSocket, 10K users:
+  = 10,000 persistent connections
+  = Minimal requests, but memory per connection
+```
+
+## Patterns
+
+### Circuit breaker
+
+Stop calling failing services, fail fast instead of waiting.
+
+**States:**
+1. **Closed:** Normal operation, requests go through
+2. **Open:** Service known to be down, fail immediately
+3. **Half-Open:** Test if service recovered with single request
+
+```javascript
+class CircuitBreaker {
+  constructor(options = {}) {
+    this.failureThreshold = options.failureThreshold || 5
+    this.resetTimeout = options.resetTimeout || 30000
+    this.state = 'CLOSED'
+    this.failures = 0
+    this.lastFailureTime = null
+  }
+
+  async call(fn) {
+    if (this.state === 'OPEN') {
+      if (Date.now() - this.lastFailureTime > this.resetTimeout) {
+        this.state = 'HALF_OPEN'
+      } else {
+        throw new CircuitOpenError('Service unavailable')
+      }
+    }
+
+    try {
+      const result = await fn()
+      this.onSuccess()
+      return result
+    } catch (error) {
+      this.onFailure()
+      throw error
+    }
+  }
+
+  onSuccess() {
+    this.failures = 0
+    this.state = 'CLOSED'
+  }
+
+  onFailure() {
+    this.failures++
+    this.lastFailureTime = Date.now()
+    if (this.failures >= this.failureThreshold) {
+      this.state = 'OPEN'
+    }
+  }
+}
+```
+
+### Retry with exponential backoff and jitter
+
+```javascript
+async function fetchWithRetry(url, options = {}, maxRetries = 3) {
+  for (let attempt = 0; attempt < maxRetries; attempt++) {
+    try {
+      const response = await fetchWithTimeout(url, options)
+
+      // Don't retry client errors
+      if (response.status >= 400 && response.status < 500) {
+        return response
+      }
+
+      if (response.ok) return response
+
+    } catch (error) {
+      if (attempt === maxRetries - 1) throw error
+    }
+
+    // Exponential backoff with jitter
+    const baseDelay = Math.pow(2, attempt) * 1000
+    const jitter = Math.random() * 1000
+    await sleep(baseDelay + jitter)
+  }
+}
+```
+
+Jitter prevents "thundering herd" where all clients retry at same time.
+
+### Request deduplication
+
+```javascript
+const pendingRequests = new Map()
+
+async function deduplicatedFetch(url, options = {}) {
+  const key = `${options.method || 'GET'}:${url}`
+
+  if (pendingRequests.has(key)) {
+    return pendingRequests.get(key)
+  }
+
+  const promise = fetch(url, options)
+    .finally(() => pendingRequests.delete(key))
+
+  pendingRequests.set(key, promise)
+  return promise
+}
+```
+
+## Anti-patterns
+
+### Ignoring HTTP caching
+
+```javascript
+// Duplicating HTTP cache in app code
+const cache = new Map()
+
+async function fetchData(url) {
+  if (cache.has(url)) return cache.get(url)
+  const data = await fetch(url).then(r => r.json())
+  cache.set(url, data)
+  return data
+}
+```
+
+Missing 304 Not Modified optimization. Server can't control your cache. Configure proper cache headers, let HTTP work.
+
+### POST for everything
+
+```javascript
+// "It works"
+await fetch('/api/user/123', { method: 'POST' })
+await fetch('/api/search', { method: 'POST', body: query })
+```
+
+GETs are cacheable, POSTs are not. Browsers won't prefetch POST. Back button re-triggers POST. CDNs won't cache POST responses.
+
+### Unbounded retries
+
+```javascript
+// DANGEROUS: Never stops
+async function fetchForever(url) {
+  while (true) {
+    try { return await fetch(url) } catch (e) { await sleep(1000) }
+  }
+}
+```
+
+Hammers failing server, user waits forever, battery drain, memory leak.
+
+## Real-world scenario: dashboard with mixed update patterns
+
+**The situation:** Dashboard with 8 widgets. Some data updates every minute (metrics). Some rarely changes (user profile). Some needs real-time (alerts).
+
+**Layer 1: HTTP caching for stable data**
+```http
+# User profile - changes rarely
+Cache-Control: private, max-age=300, stale-while-revalidate=600
+
+# Static configuration
+Cache-Control: public, max-age=3600
+```
+
+**Layer 2: Parallel fetch for varied TTL**
+```javascript
+const [user, metrics, config] = await Promise.all([
+  fetch('/api/user'),
+  fetch('/api/metrics'),
+  fetch('/api/config'),
+])
+```
+
+**Layer 3: SSE for real-time**
+```javascript
+const alerts = new EventSource('/api/alerts/stream')
+alerts.onmessage = (e) => updateAlertWidget(JSON.parse(e.data))
+```
+
+## Real-world scenario: cross-origin API with authentication
+
+**Server configuration:**
+```http
+Access-Control-Allow-Origin: https://app.example.com
+Access-Control-Allow-Credentials: true
+Access-Control-Allow-Headers: Content-Type, X-CSRF-Token
+Access-Control-Allow-Methods: GET, POST, PUT, DELETE
+Access-Control-Max-Age: 86400
+```
+
+**Client configuration:**
+```javascript
+async function apiRequest(path, options = {}) {
+  return fetch(`https://api.example.com${path}`, {
+    ...options,
+    credentials: 'include',
+    headers: {
+      ...options.headers,
+      'X-CSRF-Token': getCsrfToken(),
+    }
+  })
+}
+```
+
+## Design review checklist
+
+**HTTP Usage:**
+- Are HTTP methods used semantically?
+- Are appropriate status codes returned?
+- Are cache headers configured correctly?
+- Is CORS configured correctly for cross-origin calls?
+
+**Failure Handling:**
+- What happens when requests fail?
+- Are retries implemented with exponential backoff and jitter?
+- Is there a timeout on all requests?
+- Are non-idempotent operations protected with idempotency keys?
+
+**Performance:**
+- Are requests parallelized where possible?
+- Is the API chatty?
+- Is compression enabled?
+- Are connections prewarmed with preconnect hints?
+
+## Red flags
+
+- "We POST everything" — Caching broken
+- "Retries are disabled because duplicates" — Need idempotency keys
+- "It works locally" — Not tested on slow networks
+- "We poll every second" — Use SSE or WebSocket
+- "The timeout is 5 minutes" — User has left
+
+## Key takeaways
+
+- **HTTP is a contract, not just transport.** Methods, status codes, and headers carry semantic meaning that caches, proxies, and browsers rely on.
+- **CORS is browser enforcement of server declarations.** Understand preflight, credentials, and what triggers non-simple requests.
+- **The network will fail.** Design for timeout, retry, and graceful degradation. Use AbortController for timeouts.
+- **HTTP caching is powerful.** Learn Cache-Control, ETags, and conditional requests. Don't reinvent caching in JavaScript.
+- **HTTP/2 and HTTP/3 change assumptions.** Many small requests are fine. HTTP/3 eliminates TCP HOL blocking.
+
+Protocols define what happens at each layer—use them correctly and you get caching, retry-safety, and observability for free. Fight them and you'll reimplement everything yourself, badly.
+
+---
+
+## Further reading
+
+- [HTTP/2 — RFC 9113](https://datatracker.ietf.org/doc/html/rfc9113) — The current HTTP/2 specification (obsoletes RFC 7540); understanding multiplexing, header compression, and stream prioritization is essential for modern frontend networking.
+- [QUIC — RFC 9000](https://datatracker.ietf.org/doc/html/rfc9000) — The HTTP/3 transport protocol specification; explains how QUIC solves TCP's head-of-line blocking and improves mobile performance.
+- [High Performance Browser Networking — Ilya Grigorik](https://hpbn.co/) — Freely available; the definitive reference on browser networking, covering TCP, TLS, HTTP/2, and the full request lifecycle.
+- [Fetch API — MDN Web Docs](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) — Complete reference for the Fetch API including request/response objects, headers, AbortController integration, and streaming.
+- [CORS — MDN Web Docs](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) — The definitive guide to Cross-Origin Resource Sharing; covers preflight, credentials, and the headers that control cross-origin access.
+- [Chrome DevTools Network Panel](https://developer.chrome.com/docs/devtools/network/) — Learn to inspect requests, analyze waterfall timings, throttle connections, and debug CORS issues with Chrome's built-in network tools.
+
+---
+
+## Frequently Asked Questions (FAQs)
+
+1. **Why do HTTP method semantics matter for frontend?**
+   Methods have meaning beyond "send request." GET is cacheable (see [Caching Strategies](./caching-strategies.md)); POST isn't. PUT is idempotent—see [Consistency and Failure Handling](./consistency-and-failure-handling.md) for idempotency keys. Using wrong methods breaks caching and retry safety.
+
+2. **When does CORS preflight happen?**
+   Preflight (OPTIONS request) happens for "non-simple" requests: custom headers (Authorization), Content-Type other than form-urlencoded. For security implications of CORS, see [Security Boundaries](./security-boundaries.md).
+
+3. **Why can't I read certain response headers in JavaScript?**
+   CORS restricts which headers JavaScript can access. For custom headers, the server must include them in `Access-Control-Expose-Headers`. For security context, see [Security Boundaries](./security-boundaries.md). For caching headers, see [Caching Strategies](./caching-strategies.md).
+
+4. **How should I implement retry logic for failed requests?**
+   Rules: retry only transient failures (5xx, network errors), use exponential backoff with jitter, set maximum retries. See [Asynchronous Operations](./asynchronous-operations.md) for request cancellation. See [Consistency and Failure Handling](./consistency-and-failure-handling.md) for idempotency keys to make retries safe.
+
+5. **What's the difference between HTTP/2 and HTTP/3?**
+   HTTP/2 multiplexes requests over single TCP connection. HTTP/3 uses QUIC (UDP-based), each stream independent. HTTP/3 performs better on lossy mobile networks. For CDN considerations, see [Distributed Systems](./distributed-systems.md).
+
+6. **How do I use Cache-Control headers effectively?**
+   Common patterns: `max-age=31536000, immutable` for versioned static assets. `no-store` for sensitive data (see [Security Boundaries](./security-boundaries.md)). See [Caching Strategies](./caching-strategies.md) for application-level caching.
+
+7. **What's the difference between timeout, abort, and error in fetch?**
+   Timeout: you set via AbortController. Abort: you call manually. Error: network failure. fetch doesn't have built-in timeout—see [Asynchronous Operations](./asynchronous-operations.md) for AbortController patterns.
+
+8. **How do connection costs affect frontend performance?**
+   New connection cost: DNS (20-120ms) + TCP handshake + TLS = 300-700ms. See [Performance Optimization](./performance-optimization.md) for the critical rendering path. See [Distributed Systems](./distributed-systems.md) for CDN edge locations that reduce latency.
+
+9. **When should I use WebSocket vs. Server-Sent Events vs. polling?**
+   WebSocket: bidirectional, real-time (chat). SSE: server→client only (notifications). For state synchronization over these protocols, see [State Management at Scale](./state-management-at-scale.md). For cache invalidation via events, see [Caching Strategies](./caching-strategies.md).
+
+10. **How do I debug network issues in production?**
+    Instrument with: request/response logging, timing data, correlation IDs. See [Observability](./observability.md) for distributed tracing. Use Server-Timing header to expose backend timing. Monitor error rates by endpoint.
+
+---
+
+*Make every request count — design reliable, cacheable API interactions with [Bitloops](https://bitloops.com).*
diff --git a/documentation/docs/frontend-copilot/ui-systems-performance/observability.md b/documentation/docs/frontend-copilot/ui-systems-performance/observability.md
new file mode 100644
index 00000000..36dd10c7
--- /dev/null
+++ b/documentation/docs/frontend-copilot/ui-systems-performance/observability.md
@@ -0,0 +1,641 @@
+---
+sidebar_position: 10
+sidebar_label: Observability
+title: "Frontend Observability: RUM, Error Tracking, Distributed Tracing, and SLOs"
+description: "You can't improve what you can't measure. Learn telemetry pipelines, Real User Monitoring, Core Web Vitals tracking, distributed tracing, and burn-rate alerting."
+keywords:
+  [
+    frontend observability guide,
+    real user monitoring rum,
+    frontend error tracking,
+    distributed tracing frontend,
+    core web vitals monitoring,
+    sentry frontend setup,
+    frontend slo sli,
+    burn rate alerting,
+  ]
+---
+
+# Frontend observability as a control loop
+
+You can't improve what you can't measure, and you can't fix what you can't see. But observability is more than measurement—it's a **control system**. Sensors (telemetry) detect state, a controller (alerting + budgets) decides what to do, and actuators (rollbacks, feature flags) take action. If any part is missing, the system fails—either outages go unnoticed, or alert fatigue makes the whole system useless.
+
+## The control system framing
+
+```
+┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
+│    SENSORS      │ →  │   CONTROLLER    │ →  │   ACTUATORS     │
+│   (Telemetry)   │    │(Alerting+Budgets)│    │   (Actions)     │
+│                 │    │                 │    │                 │
+│ - RUM metrics   │    │ - SLO thresholds│    │ - Rollbacks     │
+│ - Error tracking│    │ - Burn rates    │    │ - Feature flags │
+│ - Traces        │    │ - Alert rules   │    │ - Cache purge   │
+└─────────────────┘    └─────────────────┘    └─────────────────┘
+```
+
+Without actuators, you just know you're on fire. Without sensors, you don't know you're on fire. Without a controller, you either ignore fires or run around extinguishing campfires.
+
+## What makes frontend unique
+
+- **Execution happens on devices you don't control.** Environment diversity: browsers, devices, networks, screen sizes.
+- **Privacy constraints.** What data can you collect?
+- **Scale.** Millions of clients generating telemetry.
+- **The user is the final arbiter.** Perception matters as much as metrics—see *Human Perception* for why a page that loads in 2 seconds can feel slower than one that loads in 3 seconds.
+- **Correlation challenge.** Connecting frontend events to backend systems.
+
+## The three pillars of observability
+
+- **Metrics:** Aggregated numerical measurements over time. Low cardinality, pre-aggregated, cheap to store. Use for dashboards, alerting, trends.
+- **Logs:** Discrete events with context. High cardinality, detailed, expensive to store. Use for debugging specific issues, audit trails.
+- **Traces:** Connected spans showing request flow. Sampled, high context. Use for understanding latency breakdown, debugging distributed issues.
+- **How they work together:**
+  1. Metrics alert you to a problem (error rate spike)
+  2. Logs help you identify affected users/flows
+  3. Traces show you exactly where time is spent
+
+## Telemetry pipeline architecture
+
+Before measuring anything, you need a system that won't break, drown you in data, or violate privacy.
+
+### Delivery mechanism
+
+```javascript
+function sendTelemetry(events) {
+  const payload = JSON.stringify(events)
+  const blob = new Blob([payload], { type: 'application/json' })
+
+  // sendBeacon survives page unload
+  if (navigator.sendBeacon('/telemetry', blob)) {
+    return true
+  }
+
+  // Fallback: fetch with keepalive
+  fetch('/telemetry', {
+    method: 'POST',
+    body: payload,
+    keepalive: true
+  })
+}
+```
+
+**Why sendBeacon:** Doesn't block unload. Browser handles retry. Low priority, won't compete with user requests.
+
+### Batching and buffering
+
+```javascript
+class TelemetryBuffer {
+  constructor(options = {}) {
+    this.buffer = []
+    this.maxSize = options.maxSize || 100
+    this.flushInterval = options.flushInterval || 5000
+
+    setInterval(() => this.flush(), this.flushInterval)
+
+    document.addEventListener('visibilitychange', () => {
+      if (document.visibilityState === 'hidden') {
+        this.flush()
+      }
+    })
+
+    window.addEventListener('pagehide', () => this.flush())
+  }
+
+  add(event) {
+    if (this.buffer.length >= this.maxSize) {
+      if (event.priority === 'low') return
+      const lowIndex = this.buffer.findIndex(e => e.priority === 'low')
+      if (lowIndex >= 0) this.buffer.splice(lowIndex, 1)
+    }
+
+    this.buffer.push({ ...event, timestamp: Date.now() })
+  }
+
+  flush() {
+    if (this.buffer.length === 0) return
+    const events = this.buffer.splice(0, this.buffer.length)
+    sendTelemetry(events)
+  }
+}
+```
+
+### Offline behavior
+
+*Consistency Models & Failure Handling* covers intent queues for user actions—the same pattern applies to telemetry.
+
+```javascript
+const offlineQueue = new PersistentQueue('telemetry')
+
+async function queueEvent(event) {
+  if (navigator.onLine) {
+    telemetryBuffer.add(event)
+  } else {
+    await offlineQueue.add(event)
+  }
+}
+
+window.addEventListener('online', async () => {
+  const queued = await offlineQueue.drain()
+  queued.forEach(event => telemetryBuffer.add(event))
+})
+```
+
+### Avoiding jank
+
+```javascript
+function reportMetricWhenIdle(metric) {
+  if ('requestIdleCallback' in window) {
+    requestIdleCallback(() => telemetryBuffer.add(metric), { timeout: 2000 })
+  } else {
+    setTimeout(() => telemetryBuffer.add(metric), 0)
+  }
+}
+```
+
+## Frontend SLIs (what to measure)
+
+### Reliability SLIs
+
+| SLI | What It Measures | How to Capture |
+|-----|------------------|----------------|
+| Crash-free sessions % | Sessions without fatal error | Session start/end + errors |
+| Error rate per route | Errors / page views | Error count / pageviews |
+| Blank screen rate | Pages that never render | LCP = 0 or timeout |
+| API success rate | Non-error responses | `response.ok` tracking |
+
+### Performance SLIs
+
+*Performance Optimization* covers these metrics in depth—what affects them and how to optimize. Here we focus on measuring them in production.
+
+| SLI | What It Measures | Good Target | Metric Type |
+|-----|------------------|-------------|-------------|
+| LCP p75 | Largest content paint | < 2.5s | Field |
+| INP p75 | Interaction responsiveness | < 200ms | Field |
+| CLS p75 | Visual stability | < 0.1 | Field |
+| TTFB p75 | Server responsiveness | < 800ms | Field |
+
+**Lab metrics (Lighthouse, controlled tests):**
+
+| Metric | Notes |
+|--------|-------|
+| TBT (Total Blocking Time) | Lab only |
+| TTI (Time to Interactive) | Deprecated, use INP |
+| Speed Index | Lab only |
+
+**Use lab metrics for CI gates. Use field metrics for production SLOs.**
+
+### Network SLIs
+
+| SLI | What It Measures |
+|-----|------------------|
+| API failure rate | % of calls returning error |
+| API timeout rate | % of calls timing out |
+| Retry rate | % needing retry |
+| CDN cache hit/miss | Cache effectiveness |
+
+## Frontend SLOs with defaults
+
+| SLI | Default SLO | Window | Alert Threshold |
+|-----|-------------|--------|-----------------|
+| Crash-free sessions | ≥ 99.5% | 7-day | < 99% |
+| Error rate | < 0.5% | 1-hour | > 1% |
+| LCP p75 | < 2.5s | 24-hour | > 3.5s |
+| INP p75 | < 200ms | 24-hour | > 350ms |
+| CLS p75 | < 0.1 | 24-hour | > 0.2 |
+| API success rate | ≥ 99.5% | 1-hour | < 99% |
+
+These are starting points. Adjust based on user expectations and baseline measurements.
+
+## Real User Monitoring (RUM)
+
+RUM captures actual user experience from real devices on real networks.
+
+### Core Web Vitals
+
+**LCP (Largest Contentful Paint):** Time until largest content element renders. Good: < 2.5s.
+
+**INP (Interaction to Next Paint):** Responsiveness to user interactions. Good: < 200ms. Replaced FID.
+
+**CLS (Cumulative Layout Shift):** Visual stability. Good: < 0.1.
+
+### Custom metrics
+
+```javascript
+performance.mark('search-started')
+const results = await searchAPI(query)
+performance.mark('search-complete')
+performance.measure('search-duration', 'search-started', 'search-complete')
+
+const measure = performance.getEntriesByName('search-duration')[0]
+reportMetricWhenIdle({ name: 'search_latency', value: measure.duration })
+```
+
+### Resource timing for CDN monitoring
+
+```javascript
+const observer = new PerformanceObserver((list) => {
+  for (const entry of list.getEntries()) {
+    if (entry.entryType === 'resource') {
+      const cacheStatus = entry.responseStatus === 0 ? 'failed' :
+                         (entry.transferSize === 0 ? 'cache_hit' : 'cache_miss')
+
+      reportMetricWhenIdle({
+        name: 'resource_load',
+        url: sanitizeUrl(entry.name),
+        duration: entry.duration,
+        cacheStatus
+      })
+    }
+  }
+})
+
+observer.observe({ entryTypes: ['resource'] })
+```
+
+## Client-side error tracking
+
+### Error types to capture
+1. JavaScript errors: Uncaught exceptions, promise rejections
+2. Network errors: Failed requests, timeouts
+3. Resource errors: Failed image/script loads
+4. Framework errors: React error boundaries
+
+### Global error handling
+
+```javascript
+window.addEventListener('error', (event) => {
+  reportError({
+    type: 'uncaught',
+    message: event.message,
+    filename: sanitizeUrl(event.filename),
+    lineno: event.lineno,
+    stack: event.error?.stack,
+    context: gatherContext()
+  })
+})
+
+window.addEventListener('unhandledrejection', (event) => {
+  reportError({
+    type: 'unhandled_rejection',
+    message: event.reason?.message || String(event.reason),
+    stack: event.reason?.stack,
+    context: gatherContext()
+  })
+})
+
+// Resource loading errors
+window.addEventListener('error', (event) => {
+  if (event.target !== window) {
+    reportError({
+      type: 'resource_error',
+      element: event.target.tagName,
+      url: sanitizeUrl(event.target.src || event.target.href)
+    })
+  }
+}, true)
+```
+
+## Privacy hard rules
+
+This is not optional. These are engineering requirements. *Security Boundaries* covers the broader threat model—here we focus on what telemetry should never capture.
+
+### Never capture
+
+| Data Type | Why |
+|-----------|-----|
+| Passwords, auth headers, tokens | Obviously sensitive |
+| Cookie contents | May contain session tokens |
+| localStorage contents | May contain tokens, PII |
+| Full URLs with query strings | Often contain tokens, emails |
+| Free-form text field values | May contain anything |
+
+### Always do
+
+**1. Strip query strings from URLs:**
+
+```javascript
+function sanitizeUrl(url) {
+  try {
+    const parsed = new URL(url)
+    return `${parsed.origin}${parsed.pathname}`
+  } catch {
+    return '[invalid-url]'
+  }
+}
+```
+
+**2. Use allowlist for captured fields (not denylist):**
+
+```javascript
+const ALLOWED_FIELDS = ['route', 'duration', 'errorCode', 'browser', 'deviceType']
+
+function sanitizeEvent(event) {
+  return Object.fromEntries(
+    Object.entries(event).filter(([key]) => ALLOWED_FIELDS.includes(key))
+  )
+}
+```
+
+**3. Anonymize identifiers:**
+
+```javascript
+function anonymizeUserId(userId) {
+  const salt = getCurrentWeeklySalt()
+  return hash(`${userId}:${salt}`)
+}
+```
+
+**4. Respect consent:**
+
+```javascript
+function shouldCollect() {
+  if (navigator.doNotTrack === '1') return false
+  if (!hasUserConsent()) return false
+  return true
+}
+```
+
+## Distributed tracing for frontend
+
+*Network Protocols* covers the protocol-level headers (X-Request-Id, Server-Timing). *Distributed Systems* covers trace propagation through CDN/edge. Here we focus on the client-side implementation.
+
+### The correlation problem
+User reports "The page is slow." Backend sees thousands of requests. Without correlation: guessing and log diving.
+
+### W3C trace context
+
+```
+traceparent: 00-<trace-id>-<span-id>-<flags>
+```
+
+### Correct ID generation
+
+```javascript
+function generateTraceId() {
+  // 16 random bytes = 32 hex chars
+  const bytes = crypto.getRandomValues(new Uint8Array(16))
+  return Array.from(bytes, b => b.toString(16).padStart(2, '0')).join('')
+}
+
+function generateSpanId() {
+  // 8 random bytes = 16 hex chars
+  const bytes = crypto.getRandomValues(new Uint8Array(8))
+  return Array.from(bytes, b => b.toString(16).padStart(2, '0')).join('')
+}
+```
+
+### Propagation boundaries
+
+| Boundary | Challenge | Solution |
+|----------|-----------|----------|
+| CDN/Edge | May not forward headers | Configure to preserve `traceparent` |
+| Service Worker | Intercepts requests | Preserve headers in fetch handler |
+| Third-party APIs | Won't accept headers | Log span locally |
+
+### Frontend span vocabulary
+
+| Span Type | When to Create |
+|-----------|----------------|
+| `navigation` | Route change |
+| `interaction` | User click/input |
+| `http.client` | API request |
+| `render` | Component render |
+| `longtask` | Main thread blocking |
+
+## Burn-rate alerting
+
+Error budgets alone are not enough. You need burn-rate alerts.
+
+### The problem with budget-exhaustion alerts
+- "Budget exhausted" fires after 30 days of slow burn
+- 2% budget burned in 1 hour = incident, but 30-day budget looks fine
+- You need to catch spikes AND slow leaks
+
+### Multi-window alerting
+
+| Window | Burn Rate | What It Catches | Action |
+|--------|-----------|-----------------|--------|
+| 5 min | > 14x | Spike, sudden incident | Page immediately |
+| 1 hour | > 6x | Significant incident | Page |
+| 6 hour | > 1.5x | Slow leak | Alert, investigate |
+| 24 hour | > 1x | Sustained degradation | Review |
+
+**Why both windows matter:** Short window alone is too noisy. Long window alone is too slow. Both confirms spike is sustained.
+
+## Debugging workflow (investigation ladder)
+
+### Step 1: confirm user impact
+Which routes affected? What % of users? When did it start?
+
+**Tools:** Error dashboard, RUM metrics, alert history
+
+### Step 2: identify regression start
+What deployed? Feature flag changes? Third-party updates?
+
+**Tools:** Deployment history, feature flag logs
+
+### Step 3: narrow scope
+All browsers or specific? Mobile vs. desktop? Specific geography?
+
+**Tools:** Error segmentation, RUM segmentation
+
+### Step 4: correlate to backend
+Get trace ID. Look up in backend tracing. Any upstream issues?
+
+**Tools:** Distributed tracing
+
+### Step 5: reproduce
+Locally? In staging? Session replay?
+
+**Tools:** Session replay, browser dev tools
+
+### Step 6: fix + verify + postmortem
+Deploy fix. Verify metrics return to baseline. Run postmortem.
+
+**Document this ladder.** New team members should follow it.
+
+## The trade-offs
+
+### Observability overhead vs. insight
+
+**Rule of thumb:** Instrument heavily in development, sample intelligently in production. Use feature flags to adjust sampling without redeploying.
+
+### Privacy vs. debugging capability
+
+**Default:** Minimal capture with allowlist. Turn up detail only for specific debugging with appropriate controls.
+
+### Alert coverage vs. alert fatigue
+
+**Alert hygiene:**
+- Review and prune alerts quarterly
+- Every alert should have runbook
+- Track alert → action rate
+- Use burn-rate alerts, not threshold alerts
+
+## Patterns
+
+### Structured logging
+
+```javascript
+log({
+  level: 'error',
+  message: 'Failed to load user',
+  userId: anonymize(userId),
+  errorCode: error.code,
+  duration: duration,
+  traceId: traceId
+})
+```
+
+### Error boundary instrumentation
+
+```javascript
+class InstrumentedErrorBoundary extends React.Component {
+  componentDidCatch(error, errorInfo) {
+    reportError({
+      error: error,
+      componentStack: errorInfo.componentStack,
+      route: getCurrentRoute(),
+      context: this.props.name
+    })
+  }
+}
+```
+
+### Correlation ID propagation
+
+```javascript
+function withCorrelation(fetchFn) {
+  return async function(url, options = {}) {
+    const correlationId = getOrCreateCorrelationId()
+    return fetchFn(url, {
+      ...options,
+      headers: {
+        ...options.headers,
+        'X-Correlation-ID': correlationId,
+        'traceparent': generateTraceparent()
+      }
+    })
+  }
+}
+```
+
+## Anti-patterns
+
+### Alerting on causes instead of symptoms
+Alert on "CPU high" instead of "users affected." Fix: Alert on user-facing symptoms.
+
+### No runbooks
+Alert fires, no one knows what to do. Fix: Every alert has documented response.
+
+### Threshold alerts instead of burn-rate
+Too sensitive or too slow. Fix: Multi-window burn-rate alerts.
+
+### Logging URLs with query strings
+Leaking tokens, PII. Fix: Strip query strings before logging.
+
+## Real-world scenario: performance regression detection
+
+**Implementation:**
+1. Lighthouse CI runs on every PR (lab metrics—see *Performance Optimization*)
+2. RUM tracks field metrics by page type
+3. Canary deployment compares metrics (see *Distributed Systems* for canary by region)
+4. Burn-rate alert catches regressions
+
+Lab metrics catch regressions in CI; RUM catches what synthetic tests miss.
+
+## Real-world scenario: debugging user-reported issue
+
+**Apply the investigation ladder:**
+1. Get anonymized user ID from support
+2. Search errors by user ID in time window
+3. Examine breadcrumbs
+4. Check scope
+5. Find root cause
+6. Fix + add guardrail metric
+
+## Design review checklist
+
+**Telemetry Pipeline:**
+- Is telemetry batched and buffered?
+- Does it use sendBeacon?
+- Is there backpressure?
+- Does offline mode queue events?
+
+**SLIs and SLOs:**
+- Are canonical SLIs defined?
+- Are SLO targets documented?
+- Are lab vs. field metrics distinguished?
+
+**Privacy:**
+- Are query strings stripped?
+- Is field capture allowlisted?
+- Are identifiers anonymized?
+
+**Alerting:**
+- Do alerts use burn-rate?
+- Are multi-window alerts configured?
+- Does every alert have a runbook?
+
+## Red flags
+
+- "We alert on 500 errors" — Should alert on user impact
+- "We capture everything for debugging" — Privacy violation
+- "We'll add observability later" — Flying blind
+- "Lighthouse is green" — Lab doesn't equal field
+
+## Key takeaways
+
+- **Observability is a control system.** Sensors + Controller + Actuators. All three required.
+- **Build the telemetry pipeline first.** Batching, sendBeacon, backpressure, offline—then decide what to measure.
+- **Define canonical SLIs.** Crash-free sessions, error rate, Core Web Vitals, API success rate.
+- **Alert on burn rate, not thresholds.** Multi-window alerts catch spikes and slow leaks.
+- **Privacy is engineering, not policy.** Strip query strings, allowlist fields, anonymize IDs.
+- **Document the investigation ladder.** Repeatable process from alert to resolution.
+
+---
+
+## Further reading
+
+- [Site Reliability Engineering — Google](https://sre.google/sre-book/table-of-contents/) — The foundational SRE book, freely available online; covers SLIs, SLOs, error budgets, and the monitoring philosophy that inspired this document's approach.
+- [Observability Engineering — Charity Majors, Liz Fong-Jones, George Miranda](https://www.oreilly.com/library/view/observability-engineering/9781492076438/) — Goes beyond traditional monitoring to explain how observability enables debugging novel failures you've never seen before in distributed systems.
+- [Web Vitals — web.dev](https://web.dev/articles/vitals) — Google's definitive guide to Core Web Vitals; explains what each metric measures, why it matters, and how to instrument it in the field.
+- [W3C Trace Context Specification](https://www.w3.org/TR/trace-context/) — The standard for propagating trace context across services; essential for implementing the distributed tracing patterns discussed in this document.
+- [OpenTelemetry JavaScript SDK](https://opentelemetry.io/docs/languages/js/) — The vendor-neutral instrumentation standard; provides auto-instrumentation for fetch, document load, and user interactions out of the box.
+
+---
+
+## Frequently Asked Questions (FAQs)
+
+1. **What's the difference between Real User Monitoring (RUM) and synthetic monitoring?**
+   RUM measures actual users on real devices—shows what users experience. Synthetic runs controlled tests (Lighthouse)—provides CI baselines. For performance metrics to track, see [Performance Optimization](./performance-optimization.md). For how metrics relate to experience, see [Human Perception](./human-perception.md).
+
+2. **What frontend SLIs (Service Level Indicators) should I track?**
+   Core SLIs: crash-free sessions (≥99.5%), error rate (&lt;0.5%), LCP p75 (&lt;2.5s), INP p75 (&lt;200ms), CLS p75 (&lt;0.1). For Core Web Vitals optimization, see [Performance Optimization](./performance-optimization.md). For perception-based targets, see [Human Perception](./human-perception.md).
+
+3. **How do I implement distributed tracing in the frontend?**
+   Generate trace IDs client-side, propagate via `traceparent` header. For HTTP header patterns, see [Network Protocols](./network-protocols.md). For async operation tracing, see [Asynchronous Operations](./asynchronous-operations.md).
+
+4. **What's burn-rate alerting and why is it better than threshold alerts?**
+   Burn rate measures how fast you're consuming error budget. Catches both spikes and slow leaks. For failure handling that affects error rates, see [Consistency and Failure Handling](./consistency-and-failure-handling.md).
+
+5. **What should I NOT log in frontend telemetry?**
+   Never log: passwords, tokens, cookies, full URLs with query strings, free-form user input. See [Security Boundaries](./security-boundaries.md) for sensitive data handling. Use allowlists (only log approved fields), not denylists.
+
+6. **How do I build a telemetry pipeline that doesn't impact performance?**
+   Buffer events in memory. Use sendBeacon for delivery. Use requestIdleCallback for non-critical telemetry. For performance budget implications, see [Performance Optimization](./performance-optimization.md).
+
+7. **How do I correlate frontend errors with backend issues?**
+   Propagate correlation IDs: generate client-side, send in request headers. See [Network Protocols](./network-protocols.md) for header patterns. See [Asynchronous Operations](./asynchronous-operations.md) for tracking operation lifecycles.
+
+8. **What's the investigation ladder for frontend incidents?**
+   Step through: confirm user impact, identify regression start, narrow scope (browsers, devices), correlate to backend (trace IDs), reproduce, fix. For testing failure states, see [Testing and Storybook](../best-practices/testing-and-storybook.md).
+
+9. **How do I avoid alert fatigue?**
+   Use burn-rate alerts instead of threshold alerts. Every alert should have a runbook. Alert on user-impacting symptoms—see [Human Perception](./human-perception.md) for what impacts user experience.
+
+10. **What observability tools should a frontend team use?**
+    Error tracking: Sentry, Bugsnag. RUM: web-vitals library. Synthetic: Lighthouse CI. Tracing: OpenTelemetry. For performance metrics to instrument, see [Performance Optimization](./performance-optimization.md). For caching metrics, see [Caching Strategies](./caching-strategies.md).
+
+---
+
+*See what your users see — build observable, measurable frontends with [Bitloops](https://bitloops.com).*
diff --git a/documentation/docs/frontend-copilot/ui-systems-performance/performance-optimization.md b/documentation/docs/frontend-copilot/ui-systems-performance/performance-optimization.md
new file mode 100644
index 00000000..0ebde445
--- /dev/null
+++ b/documentation/docs/frontend-copilot/ui-systems-performance/performance-optimization.md
@@ -0,0 +1,736 @@
+---
+sidebar_position: 5
+sidebar_label: Performance Optimization
+title: "Frontend Performance: Core Web Vitals, Critical Path, and Resource Optimization"
+description: "Performance is a constraint, not a feature. Learn the critical rendering path, Core Web Vitals optimization, bundle splitting, and rendering performance patterns."
+keywords:
+  [
+    frontend performance optimization,
+    core web vitals optimization,
+    react performance best practices,
+    javascript bundle size reduction,
+    largest contentful paint improve,
+    interaction to next paint fix,
+    cumulative layout shift prevent,
+    critical rendering path,
+  ]
+---
+
+# Performance as a system
+
+Performance isn't about making things fast. It's about resource allocation under constraints. You have a fixed budget of time, bandwidth, CPU, and memory. Every choice about what to load, when to execute, and how to render is a trade-off within those budgets.
+
+**The mantra: Ship less, schedule better, render less.**
+
+Ship less means reducing bytes over the wire. Schedule better means prioritizing main thread work. Render less means minimizing DOM and paint cost. Every performance technique maps to one of these three principles.
+
+## The performance pipeline
+
+This is the unifying model. Every performance concept fits into one of these stages:
+
+| Stage | What Happens | Key Metrics | Optimizations |
+|-------|--------------|-------------|---------------|
+| **Delivery** | Network transfer of bytes | TTFB, transfer size | Compression, CDN (see *Distributed Systems*), bundle size |
+| **Boot** | Parse and execute JS/CSS | TBT, TTI | Code splitting, defer/async |
+| **Render** | DOM construction, layout, paint | LCP, FCP, CLS | Critical path, image dimensions |
+| **Interact** | Event handling, state updates | INP | Handler design, state batching |
+| **Update** | Ongoing re-renders, data streams | Frame rate, memory | Backpressure, virtualization |
+
+Every optimization in this document maps to a pipeline stage.
+
+## Why this is systems design
+
+Backend performance focuses on throughput, latency percentiles, resource utilization, and capacity planning. Frontend has identical concerns with different constraints: a single thread, unreliable network, and unknown device capability.
+
+The browser is a runtime environment with finite resources. You must manage them. Performance is not optimization—it's architecture. Bad architecture cannot be optimized into good performance.
+
+## What makes frontend unique
+
+**Users perceive performance.** Backend latency is a metric. Frontend latency is felt frustration.
+
+**The device is unknown.** Server specs are known. Client devices range from flagship phones to 5-year-old budget Android phones.
+
+**The network is hostile.** Backend services communicate over fast internal networks. Frontend fights 3G, packet loss, and high latency.
+
+**Single main thread.** Most meaningful work—UI rendering, JS execution, event handling—competes for one thread.
+
+## The critical rendering path
+
+The critical rendering path is the sequence of steps the browser completes before rendering the first pixel.
+
+**Steps:**
+1. HTML parsing → DOM construction
+2. CSS parsing → CSSOM construction
+3. JavaScript execution (if blocking)
+4. Render tree construction (DOM + CSSOM)
+5. Layout (calculate positions and sizes)
+6. Paint (fill in pixels)
+7. Composite (layer management, GPU)
+
+**What blocks rendering:**
+- **Render-blocking CSS:** Browser won't paint until CSSOM is ready
+- **Parser-blocking JS:** `<script>` without `async`/`defer` stops HTML parsing
+- **Large DOM:** More nodes means more work at every step
+
+**Critical path optimization (Stage: Boot + Render):**
+- Inline critical CSS (above-the-fold styles)
+- Defer non-critical CSS
+- Use `async` or `defer` on scripts
+- Minimize DOM depth and node count
+
+## Core Web Vitals: lab vs. field
+
+A critical distinction: lab metrics (Lighthouse, DevTools) and field metrics (RUM, CrUX) often differ significantly.
+
+| Aspect | Lab Metrics | Field Metrics |
+|--------|-------------|---------------|
+| Source | Synthetic test, controlled conditions | Real users, real devices, real networks |
+| Tools | Lighthouse, WebPageTest, DevTools | CrUX, RUM (web-vitals.js) |
+| Use for | Development, regression detection | Understanding actual user experience |
+| Limitations | Doesn't reflect diversity | Requires traffic, privacy considerations |
+
+**The rule:** Always pair lab with field. Lighthouse 100 means nothing if P75 field metrics are poor. *Observability* covers how to instrument field metrics with RUM and set up SLOs for production monitoring.
+
+## Core Web Vitals: what you can control
+
+### LCP (Largest Contentful Paint) — stage: delivery + render
+
+LCP measures time until the largest visible element renders. Target: Good < 2.5s, Poor > 4s.
+
+**Primary levers:**
+
+| Lever | Impact | Implementation |
+|-------|--------|----------------|
+| Server response (TTFB) | High | CDN, edge caching, server optimization |
+| Resource priority | High | `fetchpriority="high"` on LCP image, preload |
+| Image strategy | High | Responsive images, modern formats, compression |
+| Render-blocking resources | Medium | Inline critical CSS, defer non-critical |
+| Client-side rendering | Medium | SSR/SSG for initial content |
+
+### INP (Interaction to Next Paint) — stage: interact
+
+INP measures latency from user interaction to visual feedback. Target: Good < 200ms, Poor > 500ms.
+
+**Primary levers:**
+
+| Lever | Impact | Implementation |
+|-------|--------|----------------|
+| Long tasks | High | Break into chunks, yield to main thread |
+| Event handler design | High | Minimal sync work, defer non-urgent updates |
+| State update batching | Medium | Batch multiple setState calls |
+| Rendering cost | Medium | Virtualization, memoization |
+| Synchronous storage | Medium | Avoid sync localStorage in handlers |
+
+### CLS (Cumulative Layout Shift) — stage: render
+
+CLS measures unexpected movement of visible content. Target: Good < 0.1, Poor > 0.25.
+
+**Primary levers:**
+
+| Lever | Impact | Implementation |
+|-------|--------|----------------|
+| Intrinsic sizing | High | Always specify width/height or aspect-ratio |
+| Reserved space | High | Skeleton placeholders with exact dimensions |
+| Font strategy | Medium | font-display: swap with size-adjust, preload fonts |
+| Async content containment | Medium | Fixed-size containers for dynamic content |
+| Ads/embeds | High | Reserve exact space, never let ads push content |
+
+## Interactivity architecture
+
+INP is an architecture problem, not a quick fix. Poor INP comes from how you structure event handling and state updates. This connects directly to *State Management at Scale*—how you organize state updates affects main thread contention.
+
+**The anatomy of an interaction:**
+
+```
+User clicks → Event dispatched → Handler runs → State updates → Re-render → Paint → INP measured
+```
+
+### Architecture principles for good INP
+
+**1. Isolate expensive work:**
+
+```javascript
+// BAD: Expensive computation blocks interaction
+function handleClick() {
+  const result = expensiveComputation(data)
+  setState(result)
+}
+
+// GOOD: Defer expensive work
+function handleClick() {
+  setState({ loading: true })
+  requestIdleCallback(() => {
+    const result = expensiveComputation(data)
+    setState({ loading: false, result })
+  })
+}
+```
+
+**2. Avoid cascading state updates:**
+
+```javascript
+// BAD: Multiple renders triggered
+function handleSubmit() {
+  setLoading(true)
+  setErrors(null)
+  setData(newData)
+}
+
+// GOOD: Batch updates
+function handleSubmit() {
+  dispatch({ type: 'SUBMIT', data: newData })
+}
+```
+
+**3. Separate urgent vs. non-urgent updates:**
+
+```javascript
+function handleSearch(query) {
+  setInputValue(query)              // URGENT: Update input immediately
+  scheduleBackground(() => {
+    setSearchResults(search(query)) // NON-URGENT: Can be deferred
+  })
+}
+```
+
+**4. Avoid synchronous storage in handlers:**
+
+```javascript
+// BAD: Sync storage blocks main thread
+function handleSelect(item) {
+  localStorage.setItem('selected', JSON.stringify(item))
+  setSelected(item)
+}
+
+// GOOD: Async storage
+function handleSelect(item) {
+  setSelected(item)
+  queueMicrotask(() => {
+    localStorage.setItem('selected', JSON.stringify(item))
+  })
+}
+```
+
+## Scheduling and prioritization
+
+The browser provides several scheduling primitives:
+
+**requestAnimationFrame:** For visual updates synced to display refresh.
+
+```javascript
+// GOOD: Only visual updates in rAF
+requestAnimationFrame(() => {
+  updateVisuals()
+})
+
+// BAD: Heavy work blocks paint
+requestAnimationFrame(() => {
+  expensiveComputation()
+  updateVisuals()
+})
+```
+
+**requestIdleCallback:** For non-urgent background work.
+
+```javascript
+// Always set timeout—can starve indefinitely on busy pages
+requestIdleCallback(() => sendAnalytics(), { timeout: 2000 })
+```
+
+**setTimeout(fn, 0):** For yielding to main thread.
+
+```javascript
+function yieldToMain() {
+  return new Promise(resolve => setTimeout(resolve, 0))
+}
+
+async function processChunked(items) {
+  for (const chunk of chunks(items, 100)) {
+    processChunk(chunk)
+    await yieldToMain()
+  }
+}
+```
+
+## Backpressure: the producer/consumer model
+
+Backpressure occurs when input arrives faster than it can be processed. *Asynchronous Operations* covers the throttle, debounce, and buffer patterns for managing this at the async layer.
+
+**The model:**
+
+```
+Producer (data source) → [Buffer/Strategy] → Consumer (UI updates)
+```
+
+If producer rate exceeds consumer rate, either the buffer grows unbounded (memory leak) or you apply a backpressure strategy.
+
+**Frontend backpressure scenarios:**
+
+| Producer | Consumer | Rate Mismatch |
+|----------|----------|---------------|
+| WebSocket messages | UI state updates | 100 msg/sec vs 60fps |
+| Scroll events | Layout calculations | 120 events/sec vs 16ms budget |
+| Keystroke events | Search API calls | 10 chars/sec vs 500ms API |
+
+### Backpressure strategies
+
+**Drop (latest-wins):**
+
+```javascript
+let latest = null
+socket.onmessage = (e) => { latest = e.data }
+
+function renderLoop() {
+  if (latest) {
+    render(latest)
+    latest = null
+  }
+  requestAnimationFrame(renderLoop)
+}
+```
+
+**Coalesce (batch):**
+
+```javascript
+const buffer = []
+socket.onmessage = (e) => buffer.push(e.data)
+
+setInterval(() => {
+  if (buffer.length > 0) {
+    const batch = buffer.splice(0, buffer.length)
+    processBatch(batch)
+  }
+}, 1000)
+```
+
+**Sample:**
+
+```javascript
+let count = 0
+socket.onmessage = (e) => {
+  if (++count % 10 === 0) {
+    process(e.data)
+  }
+}
+```
+
+**Buffer with bounds:**
+
+```javascript
+const MAX_BUFFER = 100
+const buffer = []
+
+socket.onmessage = (e) => {
+  buffer.push(e.data)
+  if (buffer.length > MAX_BUFFER) {
+    buffer.shift()
+    showLagIndicator()
+  }
+}
+```
+
+### Real-time chart example
+
+```javascript
+function useRealtimeData(socket) {
+  const [data, setData] = useState([])
+  const bufferRef = useRef([])
+
+  useEffect(() => {
+    socket.on('data', (point) => {
+      bufferRef.current.push(point)
+    })
+
+    const interval = setInterval(() => {
+      if (bufferRef.current.length > 0) {
+        const newPoints = bufferRef.current.slice(-100)
+        bufferRef.current = []
+        setData(prev => [...prev.slice(-900), ...newPoints])
+      }
+    }, 1000)
+
+    return () => clearInterval(interval)
+  }, [socket])
+
+  return data
+}
+```
+
+## Resource budgets
+
+Budgets are not universal—they're derived from your target constraints.
+
+**The derivation method:**
+1. Define target device (mid-range Android phone from 2022)
+2. Define target network (4G, 10 Mbps, 50ms RTT)
+3. Define UX goal (LCP < 2.5s, TTI < 5s)
+4. Work backwards to byte/timing budgets
+
+**Example derivation:**
+
+```
+Target: LCP < 2.5s on 4G (10 Mbps = 1.25 MB/s)
+
+Budget calculation:
+- TTFB: ~300ms (typical CDN)
+- Available for download: 2.5s - 300ms = 2.2s
+- Theoretical max: 2.2s × 1.25 MB/s = 2.75 MB
+
+Practical budget: ~500-800 KB for critical path resources
+
+Breakdown:
+- HTML: 50 KB
+- Critical CSS: 20 KB
+- Critical JS: 100 KB
+- LCP image: 150 KB
+- Fonts: 50 KB
+- Total critical: ~370 KB (leaves headroom)
+```
+
+## Performance governance
+
+Performance is a policy, not a one-time optimization.
+
+**Governance components:**
+
+**Per-route budgets:**
+
+```javascript
+{
+  "budgets": [
+    { "route": "/", "js": "80KB", "lcp": "2s" },
+    { "route": "/dashboard", "js": "150KB", "lcp": "3s" },
+    { "route": "/checkout", "js": "60KB", "lcp": "2s" }
+  ]
+}
+```
+
+**Third-party budgets:**
+
+```javascript
+{
+  "thirdParty": {
+    "analytics": { "budget": "30KB", "owner": "marketing" },
+    "chatWidget": { "budget": "50KB", "owner": "support" },
+    "total": "100KB"
+  }
+}
+```
+
+**Review gates:**
+- PR checklist: "Does this add > 10KB JS? Get perf review."
+- CI failure thresholds
+- Lighthouse CI on every PR
+
+**Third-party governance patterns:**
+- **Sandboxing:** Load in iframe to isolate main thread impact
+- **Facades:** Load on interaction, not page load
+- **Consent gating:** Load only after user consents
+- **Monitoring:** Track third-party share of TBT, LCP impact
+
+## Modern rendering strategies
+
+Performance is heavily shaped by rendering architecture. *Distributed Systems* covers the execution spectrum—what runs on client vs. edge vs. origin—which directly affects these choices.
+
+### The spectrum
+
+| Strategy | How It Works | Trade-offs |
+|----------|--------------|------------|
+| **CSR** | Browser downloads JS, JS renders | Fast server, slow first paint |
+| **SSR** | Server renders HTML, client hydrates | Fast first paint, server cost |
+| **SSG** | Build-time rendered, CDN served | Fastest delivery, stale until rebuild |
+| **ISR** | Static + background regeneration | Good balance, complexity |
+
+### Streaming HTML
+
+Traditional SSR blocks on full render before sending bytes. Streaming sends HTML chunks as they're ready.
+
+```
+Traditional: [Server renders everything] ────────> [Send complete HTML]
+
+Streaming:   [Render header] > [Send] > [Render main] > [Send] > [Send footer]
+```
+
+Browser can start parsing while server continues rendering.
+
+### Partial hydration / islands
+
+Full hydration runs all JS before page is interactive. Partial hydration hydrates only interactive components.
+
+```
+Traditional: ALL content ──> ALL hydrated with JS
+
+Islands:     Static content ──> Stays HTML (no JS)
+             Interactive nav ──> Hydrated (JS)
+             Static article ──> Stays HTML (no JS)
+```
+
+Less JS shipped, less JS executed, faster TTI.
+
+## The trade-offs
+
+### Initial load vs. runtime performance
+
+**Decision framework:**
+
+- Content site (blog, news): Prioritize initial load
+- App (dashboard, tool): Balance initial + runtime
+- High return visitors: Invest in caching, accept slower first load
+- Mostly new users: Optimize first impression
+
+**What must be fast (invariants):**
+1. First meaningful view (user sees content)
+2. First interaction (user can do something)
+3. Core workflows (critical user journeys)
+
+Everything else can be deferred.
+
+### Bundle size vs. caching granularity
+
+**The sweet spot:**
+
+```
+vendor.js      - Third-party deps (changes rarely)
+framework.js   - React/Vue/etc. (changes with upgrades)
+common.js      - Shared app code (changes occasionally)
+[route].js     - Route-specific code (changes with features)
+```
+
+## Patterns
+
+### Code splitting by route
+
+Each route loads only the code it needs. (Stage: Delivery + Boot)
+
+```javascript
+const Dashboard = lazy(() => import('./pages/Dashboard'))
+const Settings = lazy(() => import('./pages/Settings'))
+```
+
+### Image optimization pipeline
+
+Serve appropriately sized, formatted, and loaded images. (Stage: Delivery + Render)
+
+```html
+<img
+  srcset="image-400.jpg 400w, image-800.jpg 800w"
+  sizes="(max-width: 600px) 400px, 800px"
+  src="image-800.jpg"
+  width="800" height="600"
+  loading="lazy"
+  fetchpriority="high"
+  alt="..."
+/>
+```
+
+### Virtualization for long lists
+
+Only render visible items. (Stage: Render + Update)
+
+**When to use:**
+- Lists with 100+ items
+- Complex item components
+
+**When not to use:**
+- Fewer than 100 simple items
+- Need full-page search/find
+
+### Resource hints
+
+Tell the browser about resources you'll need.
+
+```html
+<!-- Establish early connection -->
+<link rel="preconnect" href="https://api.example.com" />
+
+<!-- Fetch for future navigation -->
+<link rel="prefetch" href="/next-page.js" />
+
+<!-- Critical resource for current page -->
+<link rel="preload" href="/hero.jpg" as="image" />
+```
+
+## Anti-patterns
+
+### Premature optimization
+
+Optimizing before measuring, optimizing the wrong thing.
+
+**The fix:**
+1. Measure first (Lighthouse, DevTools, RUM)
+2. Identify actual bottleneck
+3. Optimize the bottleneck
+4. Measure again
+
+**Priority order:**
+1. Network (largest impact): Images, bundles, requests
+2. Render blocking: CSS, JS loading strategy
+3. Main thread: Long tasks, layout thrashing
+4. Memory: Leaks, large objects
+
+### "Lighthouse 100"
+
+Chasing perfect lab scores while ignoring field data.
+
+Lab conditions don't equal real user conditions. Lighthouse runs on a powerful machine with a fast network.
+
+**The fix:**
+1. Always pair lab with field
+2. Watch percentile distributions (P75)
+3. Segment by device/network
+4. Set alerts on field regressions
+
+```javascript
+import { onLCP, onINP, onCLS } from 'web-vitals'
+
+onLCP((metric) => sendToAnalytics('LCP', metric.value))
+onINP((metric) => sendToAnalytics('INP', metric.value))
+onCLS((metric) => sendToAnalytics('CLS', metric.value))
+```
+
+See *Observability* for building a complete telemetry pipeline around these metrics, including batching, privacy, and alerting.
+
+### Layout thrashing
+
+Interleaving DOM reads and writes forces repeated layout calculations. (Stage: Render)
+
+```javascript
+// BAD: Forces layout on every iteration
+elements.forEach(el => {
+  const height = el.offsetHeight
+  el.style.height = height + 10 + 'px'
+})
+
+// GOOD: Batch reads, then batch writes
+const heights = elements.map(el => el.offsetHeight)
+elements.forEach((el, i) => {
+  el.style.height = heights[i] + 10 + 'px'
+})
+```
+
+## Real-world scenario: e-commerce product listing
+
+**Performance invariants:**
+- LCP < 2.5s (first 4 product images visible)
+- INP < 200ms (filter interactions feel instant)
+- CLS < 0.1 (no layout shift when images load)
+
+**Pipeline-stage optimizations:**
+
+| Stage | Optimization |
+|-------|--------------|
+| Delivery | WebP/AVIF images, CDN, code-split filters |
+| Boot | SSR product grid, defer review JS |
+| Render | Image dimensions, skeleton placeholders |
+| Interact | Debounced filters, virtualized if > 100 |
+| Update | Paginate vs. infinite scroll |
+
+## Real-world scenario: dashboard with real-time data
+
+**Performance invariants:**
+- TTI < 5s (charts usable)
+- INP < 200ms (widget interactions)
+- Stable 60fps during data updates
+
+**Backpressure strategy:**
+- WebSocket messages → buffer → 1fps chart updates
+- Latest-wins for real-time numbers
+- Bounded buffer with lag indicator
+
+## Real-world scenario: content-heavy media site
+
+**Performance invariants:**
+- LCP < 2.5s (hero image)
+- CLS < 0.1 (no ad-induced shifts)
+- Third-party budget < 100KB
+
+**Third-party governance:**
+- Ads: Reserved space, async load
+- Analytics: Load after LCP
+- Social widgets: Facade pattern (load on click)
+
+## Design review checklist
+
+**Pipeline Coverage:**
+- Delivery: Are bytes minimized? CDN? Compression?
+- Boot: Is JS code-split? Critical CSS inlined?
+- Render: Are dimensions specified? Fonts optimized?
+- Interact: Are handlers lightweight? State batched?
+- Update: Is backpressure handled? Lists virtualized?
+
+**Metrics:**
+- Are lab metrics tracked (Lighthouse CI)?
+- Are field metrics instrumented (RUM)?
+- Are P75 values monitored, not just averages?
+
+**Governance:**
+- Are budgets defined and enforced?
+- Is third-party load governed?
+- Are budget owners assigned?
+
+## Red flags
+
+- "It's fast on my machine" — Not tested on target devices
+- "Lighthouse is 100" — Lab doesn't equal field
+- "We'll optimize later" — Performance is architecture
+- Bundle creeping — No budget enforcement
+
+## Key takeaways
+
+- **Performance is a pipeline.** Delivery → Boot → Render → Interact → Update. Every optimization maps to a stage.
+- **Ship less, schedule better, render less.** The core triad for frontend performance.
+- **Lab doesn't equal field.** Lighthouse scores are development tools. Real user metrics are truth.
+- **Budgets are derived, not arbitrary.** Start with target device + network + UX goal, work backwards to bytes.
+- **Performance is governance.** Budgets, ownership, review gates, and CI enforcement prevent regression.
+- **Interactivity is architecture.** INP problems come from handler design and state management, not just missing debounce.
+
+Performance is not a feature to add later—it's a constraint to design within from the start. But remember: *Human Perception* matters as much as metrics—a system that feels fast is fast, even if the numbers say otherwise.
+
+---
+
+## Further reading
+
+- [Designing for Performance — Lara Hogan](https://designingforperformance.com/) — Freely available online; bridges performance engineering and organizational culture, covering how to build a performance-first mindset across teams.
+- [Web Vitals — web.dev](https://web.dev/articles/vitals) — Google's definitive guide to Core Web Vitals metrics, what each one measures, and actionable guidance for improving LCP, INP, and CLS.
+- [High Performance Browser Networking — Ilya Grigorik](https://hpbn.co/) — Freely available; the most comprehensive reference on browser networking, from TCP/TLS to HTTP/2 and resource loading optimization.
+- [Chrome DevTools Performance Panel](https://developer.chrome.com/docs/devtools/performance/) — Learn to profile rendering, identify long tasks, and debug main thread contention with Chrome's built-in performance tools.
+- [WebPageTest](https://www.webpagetest.org/) — The industry-standard tool for waterfall analysis, filmstrip comparisons, and synthetic performance testing across real browsers and locations.
+- [web-vitals — GitHub](https://github.com/GoogleChrome/web-vitals) — Google's lightweight library for measuring Core Web Vitals in the field; the starting point for any Real User Monitoring implementation.
+
+---
+
+## Frequently Asked Questions (FAQs)
+
+1. **What are Core Web Vitals and what scores should I target?**
+   LCP (Largest Contentful Paint): < 2.5s measures loading. INP (Interaction to Next Paint): < 200ms measures interactivity. CLS (Cumulative Layout Shift): < 0.1 measures visual stability. For monitoring these in production, see [Observability](./observability.md). For how metrics relate to user experience, see [Human Perception](./human-perception.md).
+
+2. **What's the critical rendering path and why does it matter?**
+   The sequence of steps before the first pixel: HTML parsing → DOM, CSS parsing → CSSOM, JavaScript execution, render tree → layout → paint. For CDN delivery optimization, see [Distributed Systems](./distributed-systems.md). For network layer details, see [Network Protocols](./network-protocols.md).
+
+3. **How do I reduce my JavaScript bundle size?**
+   Strategies: code splitting with dynamic imports, tree shaking, analyze with webpack-bundle-analyzer. For how bundle size affects loading experience, see [Human Perception](./human-perception.md). For caching strategies for static assets, see [Caching Strategies](./caching-strategies.md).
+
+4. **What causes layout shift (CLS) and how do I fix it?**
+   Causes: images without dimensions, fonts that swap and resize, dynamically injected content. For responsive image patterns, see [Responsive Behavior](../best-practices/responsive-behavior.md). Layout stability directly affects perceived performance—see [Human Perception](./human-perception.md).
+
+5. **What's the difference between lab and field performance metrics?**
+   Lab metrics: controlled synthetic tests (Lighthouse). Field metrics: real users on real devices (RUM). See [Observability](./observability.md) for RUM implementation. They often differ significantly—optimize for field, gate on lab.
+
+6. **Should I use React.memo and useMemo everywhere?**
+   No. Memoization has overhead. Use when: component re-renders frequently with same props, computation is genuinely expensive, you've profiled and confirmed the benefit. For state management patterns that reduce unnecessary renders, see [State Management at Scale](./state-management-at-scale.md).
+
+7. **How do I optimize images for performance?**
+   Use modern formats (WebP, AVIF). Serve appropriate sizes with srcset/sizes—see [Responsive Behavior](../best-practices/responsive-behavior.md). Lazy load below-fold images. Use `fetchpriority="high"` for LCP images. Consider blur placeholders for perceived performance—see [Human Perception](./human-perception.md).
+
+8. **What's the performance pipeline model?**
+   Five stages: Delivery (see [Network Protocols](./network-protocols.md)), Boot, Render, Interact, Update. Every optimization maps to a stage. Ship less (delivery), schedule better (boot), render less (render/update). For CDN optimization of delivery, see [Distributed Systems](./distributed-systems.md).
+
+9. **How do I set performance budgets?**
+   Derive from constraints: target device, target network, target UX (LCP < 2.5s). Convert to byte budgets. Enforce in CI. For monitoring budget adherence in production, see [Observability](./observability.md). For perception thresholds, see [Human Perception](./human-perception.md).
+
+10. **What's the most common performance mistake in React apps?**
+    Over-fetching and under-caching. See [Caching Strategies](./caching-strategies.md) for proper caching patterns. See [Asynchronous Operations](./asynchronous-operations.md) for request deduplication. Profile before optimizing render performance.
+
+---
+
+*Hit every Core Web Vital target and deliver sub-second experiences with [Bitloops](https://bitloops.com) — your AI-powered frontend copilot.*
diff --git a/documentation/docs/frontend-copilot/ui-systems-performance/security-boundaries.md b/documentation/docs/frontend-copilot/ui-systems-performance/security-boundaries.md
new file mode 100644
index 00000000..e1a827aa
--- /dev/null
+++ b/documentation/docs/frontend-copilot/ui-systems-performance/security-boundaries.md
@@ -0,0 +1,790 @@
+---
+sidebar_position: 8
+sidebar_label: Security Boundaries
+title: "Frontend Security Architecture: XSS, CSRF, CSP, and Token Storage Patterns"
+description: "Security isn't prevention—it's blast radius design. Learn XSS mitigation, CSRF protection, Content Security Policy, and where to store JWT tokens in SPAs."
+keywords:
+  [
+    frontend security best practices,
+    xss prevention react,
+    csrf protection spa,
+    content security policy guide,
+    jwt token storage spa,
+    httponly cookie vs localstorage,
+    same origin policy explained,
+    oauth pkce spa,
+  ]
+---
+
+# Security beyond prevention
+
+The browser is hostile territory. Every line of JavaScript is visible, modifiable, and untrustworthy. But here's the insight that separates security architecture from security theater: **Security isn't about preventing attacks—it's about designing systems where successful attacks cause minimum damage.**
+
+This is blast radius design.
+
+## Security is blast radius design
+
+For each security mechanism, we ask three questions:
+1. What does it prevent?
+2. What does it NOT prevent?
+3. When it fails, what limits the damage?
+
+This framing turns security from a checklist into architecture.
+
+## What makes frontend unique
+
+- **Client is fully compromised by design.** Users can see and modify everything.
+- **Attacks come through your own code.** XSS means attacker's code runs as your code.
+- **Same-origin policy is your primary defense.** Browser-enforced isolation between origins.
+- **Users are the attack surface.** Phishing and social engineering target the human.
+- **Third-party code runs with your privileges.** Every script you include can do anything you can.
+
+## Threat model & assets
+
+Before designing security, define what you protect and from whom.
+
+### Assets to protect
+
+- **User accounts:** Credentials, sessions, identity
+- **User data:** PII, preferences, content
+- **Financial operations:** Payments, balances, transfers
+- **Tenant isolation:** In SaaS, preventing cross-tenant access
+- **Reputation:** Trust that your app is safe
+
+### Attacker capabilities
+
+- **XSS:** Attacker runs code in your origin
+- **CSRF:** Attacker triggers authenticated requests from their site
+- **Stolen device/session:** Attacker has valid credentials
+- **Malicious browser extension:** Can read/modify page content
+- **Compromised third-party:** Script you include becomes malicious
+
+### What HTTPS provides vs. doesn't
+
+| HTTPS Provides | HTTPS Does NOT Provide |
+|----------------|------------------------|
+| Transport encryption | Client-side code integrity |
+| Server authentication | Protection from XSS |
+| Message integrity | Protection from CSRF |
+| Protection against MITM | Protection from malicious extensions |
+
+HTTPS provides strong transport security. What's untrusted is: all client-provided data, the client environment (extensions, DevTools), and third-party scripts running in your context.
+
+## Trust boundaries
+
+A trust boundary is where you transition from trusted to untrusted (or vice versa). This connects to *State Management at Scale*—the client holds replicas of server data, but the server is always authoritative.
+
+**The fundamental rule:**
+```
+NEVER trust data from the client (even if your JS sent it)
+NEVER put secrets in client-side code
+ALWAYS validate and authorize on the server
+The client is for UX, not security enforcement
+```
+
+**Common trust boundary violations:**
+
+```javascript
+// BAD: Client-side authorization check
+if (user.role === 'admin') {
+  showAdminPanel()  // Attacker changes user.role in DevTools
+}
+
+// BAD: Secret in client code
+const API_KEY = 'sk_live_abc123'  // Visible in bundle
+
+// BAD: Trusting client-provided IDs
+await fetch(`/api/users/${userId}/delete`)  // userId from URL param
+```
+
+## Same-origin policy
+
+**Origin = scheme + host + port**
+
+```
+https://example.com:443/path
+└─┬─┘  └────┬─────┘└┬┘
+scheme    host    port
+```
+
+| URL A | URL B | Same Origin? |
+|-------|-------|--------------|
+| `https://example.com/a` | `https://example.com/b` | Yes |
+| `https://example.com` | `http://example.com` | No (scheme) |
+| `https://example.com` | `https://api.example.com` | No (host) |
+| `https://example.com` | `https://example.com:8080` | No (port) |
+
+**What same-origin policy prevents:**
+- Script from origin A reading data from origin B
+- Script from origin A accessing storage of origin B
+- Script from origin A making certain requests to origin B (without CORS)
+
+**What it doesn't prevent:**
+- Including resources from other origins (`<img>`, `<script>`, `<link>`)
+- Submitting forms to other origins
+- Embedding other origins in iframes (unless blocked by headers)
+
+## XSS (cross-site scripting)
+
+Attacker injects malicious script that runs in context of your origin.
+
+### Types of XSS
+
+- **Stored XSS:** Malicious script saved in database, served to other users.
+- **Reflected XSS:** Malicious script in URL, reflected in response.
+- **DOM-based XSS:** Malicious data processed unsafely by client-side JS.
+
+```javascript
+// URL: https://example.com#<img src=x onerror=alert('xss')>
+document.getElementById('output').innerHTML = location.hash.slice(1)
+```
+
+### XSS prevention
+
+**1. Output encoding (context-aware):**
+
+```javascript
+// BAD: Raw insertion
+element.innerHTML = userInput
+
+// GOOD: Text content (no HTML parsing)
+element.textContent = userInput
+
+// GOOD: Framework auto-escaping
+return <div>{userInput}</div>  // React escapes by default
+```
+
+**Context matters:**
+- HTML body: Escape `<`, `>`, `&`, `"`, `'`
+- HTML attributes: Escape quotes, never put in event handlers
+- JavaScript: Escape for JS string context
+- URLs: Encode for URL context, validate scheme
+
+**2. Content Security Policy (CSP):** See dedicated section below.
+
+**3. HTTPOnly cookies:**
+
+```http
+Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Strict
+```
+
+### Critical: XSS + HttpOnly
+
+**HttpOnly prevents cookie theft, but XSS can still perform actions as the user.**
+
+If an attacker achieves XSS, they can:
+- Read any non-HttpOnly data (localStorage, sessionStorage, DOM)
+- Make authenticated requests (cookies are still sent!)
+- Modify the page, capture keystrokes, redirect user
+- Call any API endpoint the user can access
+
+HttpOnly limits blast radius (attacker can't exfiltrate session for later use), but doesn't stop in-session attacks. This is why CSP + output encoding are essential.
+
+## CSRF (cross-site request forgery)
+
+Attacker tricks user's browser into making authenticated request to your site.
+
+```html
+<!-- Attacker's site -->
+<form action="https://bank.com/transfer" method="POST" id="exploit">
+  <input type="hidden" name="to" value="attacker" />
+  <input type="hidden" name="amount" value="1000" />
+</form>
+<script>document.getElementById('exploit').submit()</script>
+```
+
+Browser automatically includes cookies. Request looks legitimate.
+
+### CSRF prevention
+
+**1. SameSite cookies (primary defense):**
+
+```http
+Set-Cookie: session=abc123; SameSite=Strict
+# Cookie not sent on ANY cross-site request
+
+Set-Cookie: session=abc123; SameSite=Lax
+# Cookie sent on top-level GET navigation, but not POST/subresources
+```
+
+**2. CSRF tokens (additional layer):**
+
+Server generates unique token per session. Token must be in request body or custom header. Attacker can't know the token (same-origin policy).
+
+**3. Check Origin/Referer headers:**
+
+```javascript
+if (request.headers.origin !== 'https://yoursite.com') {
+  return 403
+}
+```
+
+| | XSS | CSRF |
+|---|-----|------|
+| Attack | Inject code into YOUR page | Trick request FROM attacker's page |
+| Runs where | In your origin | In attacker's origin |
+| What's exploited | Output encoding failure | Automatic cookie inclusion |
+| Prevention | CSP, encoding | SameSite, CSRF tokens |
+
+## Clickjacking & framing protections
+
+Attacker embeds your page in an invisible iframe, tricks user into clicking.
+
+**Prevention:**
+
+**frame-ancestors CSP directive (modern):**
+
+```http
+Content-Security-Policy: frame-ancestors 'none';        # No framing
+Content-Security-Policy: frame-ancestors 'self';        # Only same origin
+```
+
+**X-Frame-Options (legacy):**
+
+```http
+X-Frame-Options: DENY
+X-Frame-Options: SAMEORIGIN
+```
+
+Default to `frame-ancestors 'none'` unless you have a specific reason.
+
+## Security headers
+
+Beyond CSP, several HTTP headers harden security. *Network Protocols* covers HTTP semantics in depth—here we focus on security-specific headers.
+
+**HSTS (HTTP Strict Transport Security):**
+
+```http
+Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
+```
+
+Forces HTTPS. Prevents protocol downgrade attacks.
+
+**Referrer-Policy:**
+
+```http
+Referrer-Policy: strict-origin-when-cross-origin
+```
+
+Prevents leaking sensitive URL paths to third parties.
+
+**Permissions-Policy:**
+
+```http
+Permissions-Policy: geolocation=(), microphone=(), camera=(), payment=(self)
+```
+
+Restricts which browser features can be used. Blocks feature access by embedded iframes.
+
+**Complete security headers example:**
+
+```http
+Strict-Transport-Security: max-age=31536000; includeSubDomains
+Content-Security-Policy: default-src 'self'; script-src 'self'; frame-ancestors 'none'
+X-Frame-Options: DENY
+X-Content-Type-Options: nosniff
+Referrer-Policy: strict-origin-when-cross-origin
+Permissions-Policy: geolocation=(), microphone=(), camera=()
+```
+
+## Content Security Policy (CSP)
+
+CSP is your primary XSS mitigation. Treat it as essential, not optional.
+
+### CSP as a progression
+
+**Stage 1: Report-only mode (observe)**
+
+```http
+Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-violations
+```
+
+**Stage 2: Remove inline dependencies**
+- Move inline `<script>` to external files
+- Move inline `onclick` handlers to addEventListener
+- Eliminate eval() usage
+
+**Stage 3: Basic enforcement**
+
+```http
+Content-Security-Policy:
+  default-src 'self';
+  script-src 'self' https://trusted-cdn.com;
+  style-src 'self' 'unsafe-inline';
+  img-src 'self' https: data:;
+  connect-src 'self' https://api.example.com;
+  frame-ancestors 'none';
+```
+
+**Stage 4: Nonce-based (eliminate 'unsafe-inline' for scripts)**
+
+```http
+Content-Security-Policy: script-src 'nonce-{random}' 'strict-dynamic'
+```
+
+```html
+<script nonce="{random}">
+  // This is allowed
+</script>
+<script>
+  // This is BLOCKED (no nonce)
+</script>
+```
+
+Server generates random nonce per request. Only scripts with matching nonce execute. `strict-dynamic` allows nonced scripts to load other scripts.
+
+**Important:** `'unsafe-inline'` is a transitional compromise, not acceptable long-term for scripts.
+
+## Token storage
+
+Where do you store authentication tokens? This decision affects both security and failure handling—see *Consistency Models & Failure Handling* for how auth failures fit into the failure taxonomy.
+
+**Option 1: HTTPOnly Cookie**
+
+```http
+Set-Cookie: auth_token=xxx; HttpOnly; Secure; SameSite=Strict; Path=/
+```
+
+- Blast radius on XSS: Low (can't exfiltrate token), but attacker can still make requests
+- CSRF risk: Mitigated by SameSite
+
+**Option 2: localStorage/sessionStorage**
+
+```javascript
+localStorage.setItem('auth_token', token)
+```
+
+- Blast radius on XSS: High (attacker can steal and reuse token externally)
+- CSRF risk: None (must explicitly add to requests)
+
+**Option 3: Memory only**
+
+```javascript
+let authToken = null  // Closure or module scope
+```
+
+- Blast radius on XSS: Medium (harder to find, but still accessible)
+- Persistence: Lost on refresh
+
+**Recommended pattern:**
+
+```
+Access token: Short-lived (15min), in memory
+Refresh token: HTTPOnly cookie with SameSite=Strict
+On page load: Silent refresh to get new access token
+```
+
+This minimizes blast radius on both XSS (access token is short-lived, refresh token is HttpOnly) and CSRF (access token is in Authorization header, not automatic).
+
+## Third-party & supply chain risk
+
+This is one of the largest modern frontend security risks. *Distributed Systems* covers CDN security; *Performance Optimization* covers third-party budgets and governance.
+
+Every third-party script you include:
+- Runs with your origin's full privileges
+- Can read all DOM content, localStorage, non-HttpOnly cookies
+- Can make requests as your user
+- Can be compromised at any time
+
+### Subresource integrity (SRI)
+
+```html
+<script
+  src="https://cdn.example.com/library.js"
+  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
+  crossorigin="anonymous"
+></script>
+```
+
+Browser computes hash of downloaded script. Blocks execution if hash doesn't match.
+
+**Limitation:** Doesn't work for dynamic tag managers that load varying content.
+
+### Third-party isolation patterns
+
+**Sandboxed iframes for untrusted widgets:**
+
+```html
+<iframe
+  src="https://third-party.com/widget"
+  sandbox="allow-scripts allow-same-origin"
+  loading="lazy"
+></iframe>
+```
+
+**Strict CSP:**
+
+```http
+Content-Security-Policy:
+  script-src 'self' https://trusted-cdn.com;
+  connect-src 'self' https://api.example.com;
+```
+
+**Facades for analytics:**
+
+```javascript
+// Proxy through your own endpoint
+fetch('/api/analytics', { body: eventData })
+// Server forwards to third-party, controls what's sent
+```
+
+### Dependency hygiene
+
+- Use lockfiles (package-lock.json)
+- Run `npm audit` in CI
+- Pin versions for critical dependencies
+- Audit what dependencies bundle
+
+## Authentication flows
+
+**Session-based:**
+
+```
+1. User submits credentials
+2. Server validates, creates session in database
+3. Server sends session ID in HTTPOnly cookie
+4. Browser includes cookie on subsequent requests
+5. Server looks up session, identifies user
+```
+
+Pros: Simple, server controls sessions, easy revocation.
+Cons: Requires server-side session storage.
+
+**Token-based (JWT):**
+
+```
+1. User submits credentials
+2. Server validates, creates signed JWT
+3. Server sends JWT to client
+4. Client stores JWT, sends in Authorization header
+5. Server validates JWT signature, extracts user info
+```
+
+Pros: Stateless, scales well.
+Cons: Can't revoke easily, token contains data.
+
+**OAuth 2.0 with PKCE (for SPAs):**
+
+```
+1. App generates code_verifier and code_challenge
+2. App redirects user to auth server with code_challenge
+3. User logs in, consents
+4. Auth server redirects back with authorization code
+5. App exchanges code + code_verifier for tokens
+```
+
+PKCE prevents authorization code interception. Use this for SPAs, not implicit flow.
+
+## Auth lifecycle & revocation
+
+*State Management at Scale* covers cross-tab coordination—logout is a critical case where tabs must synchronize immediately.
+
+**Logout across tabs:**
+
+```javascript
+const authChannel = new BroadcastChannel('auth')
+
+function logout() {
+  clearSession()
+  authChannel.postMessage({ type: 'logout' })
+}
+
+authChannel.onmessage = (event) => {
+  if (event.data.type === 'logout') {
+    clearSession()
+    redirectToLogin()
+  }
+}
+```
+
+**Refresh token rotation + reuse detection:**
+
+Server issues NEW refresh token with each use. Old refresh token becomes invalid. If old token is reused, likely theft—invalidate ALL tokens for user.
+
+**Handling 401 storms:**
+
+```javascript
+let refreshPromise = null
+
+async function getValidToken() {
+  if (refreshPromise) {
+    return refreshPromise  // Reuse in-flight refresh
+  }
+
+  refreshPromise = refreshAccessToken()
+    .finally(() => { refreshPromise = null })
+
+  return refreshPromise
+}
+```
+
+## The trade-offs
+
+### Security vs. UX (friction)
+
+This connects to *Human Perception*—security friction is perceived latency. The goal is appropriate friction, not minimum friction.
+
+| Action Sensitivity | Friction Level | Examples |
+|-------------------|----------------|----------|
+| Low | Minimal | View public content |
+| Medium | Single auth | View personal data |
+| High | MFA / Re-auth | Change password, transfer money |
+| Critical | MFA + Approval | Delete account, change email |
+
+**Step-up authentication:**
+
+```javascript
+async function sensitiveAction() {
+  const lastAuth = await getLastAuthTime()
+  const fiveMinutesAgo = Date.now() - 5 * 60 * 1000
+
+  if (lastAuth < fiveMinutesAgo) {
+    await promptReAuth()
+  }
+
+  await performAction()
+}
+```
+
+### Token lifetime vs. refresh complexity
+
+**Short-lived tokens (15 minutes):**
+- Blast radius: Limited (stolen token expires quickly)
+- Complexity: Need refresh logic
+
+**Long-lived tokens (days/weeks):**
+- Blast radius: Large (stolen token useful longer)
+- Complexity: Simpler
+
+**Recommended:** Short access tokens + long-lived refresh tokens in HTTPOnly cookies. Rotate refresh tokens on use.
+
+### Strict CSP vs. flexibility
+
+**Strict CSP:** Blocks most XSS but may break third-party integrations. Requires refactoring inline scripts.
+
+**Permissive CSP (`'unsafe-inline' 'unsafe-eval'`):** Everything works but provides almost no protection.
+
+**Progressive approach:** Start report-only, fix violations, tighten gradually.
+
+## Patterns
+
+### Defense in depth
+
+```
+Layer 1: HTTPS (transport security)
+Layer 2: CORS (origin restriction)
+Layer 3: Authentication (identity verification)
+Layer 4: Authorization (permission check)
+Layer 5: Input validation (data integrity)
+Layer 6: Rate limiting (abuse prevention)
+Layer 7: Audit logging (detection)
+```
+
+Each layer independently limits damage when others fail.
+
+### Capability-based links
+
+```javascript
+// Authorization embedded in unguessable URL
+function generateShareLink(documentId) {
+  const token = crypto.randomBytes(32).toString('hex')
+  await store.set(`share:${token}`, { documentId, expiresAt: ... })
+  return `https://example.com/shared/${token}`
+}
+```
+
+Use for: Password reset, email verification, file sharing.
+
+## Anti-patterns
+
+### Client-side authorization
+
+```javascript
+// BAD: Role check in JavaScript
+if (user.role === 'admin') {
+  showAdminPanel()
+}
+```
+
+User modifies `user.role` in DevTools. Always authorize server-side.
+
+### Storing secrets in frontend
+
+```javascript
+// BAD: Visible in bundle
+const STRIPE_SECRET_KEY = 'sk_live_xxx'
+```
+
+Only publishable keys belong in client code.
+
+### Trusting client-provided identity
+
+```javascript
+// BAD: Multi-tenant with client-provided tenant
+const tenantId = req.headers['x-tenant-id']  // Attacker changes header!
+return db.documents.findMany({ where: { tenantId } })
+```
+
+**The fix:** Derive tenant from authenticated principal:
+
+```javascript
+const tenantId = req.user.currentTenantId  // From validated session/JWT
+return db.documents.findMany({ where: { tenantId } })
+```
+
+## Real-world scenario: SPA with API backend
+
+**Authentication flow:**
+1. Redirect to auth server with PKCE
+2. User authenticates
+3. Redirect back with authorization code
+4. SPA exchanges code for tokens
+5. Access token stored in memory
+6. Refresh token set as HTTPOnly cookie
+
+**CORS:**
+
+```http
+Access-Control-Allow-Origin: https://app.example.com
+Access-Control-Allow-Credentials: true
+Access-Control-Allow-Headers: Authorization, Content-Type
+```
+
+**CSP:**
+
+```http
+Content-Security-Policy:
+  default-src 'self';
+  script-src 'self' 'nonce-{random}';
+  connect-src 'self' https://api.example.com;
+  frame-ancestors 'none';
+```
+
+## Real-world scenario: multi-tenant SaaS
+
+**Security invariants:**
+1. No cross-tenant reads or writes
+2. No unauthorized state changes
+3. Sensitive actions require step-up authentication
+4. No secrets in client
+
+**Implementation:**
+
+```javascript
+app.use((req, res, next) => {
+  // Extract tenant from JWT claims, NOT client header
+  const tenantId = req.user.tenantId
+
+  // Optional: Allow user to select from allowed tenants
+  const requestedTenant = req.headers['x-tenant-id']
+  if (requestedTenant && req.user.allowedTenants.includes(requestedTenant)) {
+    req.tenantId = requestedTenant
+  } else {
+    req.tenantId = tenantId
+  }
+
+  next()
+})
+
+// All queries scoped to tenant
+async function getDocuments(req) {
+  return db.documents.findMany({
+    where: { tenantId: req.tenantId }  // ALWAYS included
+  })
+}
+```
+
+Client-provided tenant ID is an untrusted selector, not authority. Server validates user has access.
+
+## Design review checklist
+
+**Trust Boundaries:**
+- What does the client control vs. server control?
+- Where are authorization decisions made? (Must be server)
+- What happens if client code is fully compromised?
+
+**Authentication:**
+- How are credentials transmitted and stored?
+- What's the session/token lifetime?
+- How does logout/revocation work across devices?
+
+**Authorization:**
+- Is every API endpoint protected?
+- Are permissions checked server-side?
+- How is tenant isolation enforced?
+
+**XSS/Injection:**
+- Is output encoding applied correctly?
+- Is CSP configured beyond 'unsafe-inline'?
+- Are third-party scripts inventoried?
+
+**Headers:**
+- HSTS configured?
+- frame-ancestors set?
+- Referrer-Policy configured?
+
+## Red flags
+
+- "Admin panel is hidden so it's secure" — Security by obscurity
+- "We check permissions in the React component" — Client-side authorization
+- "The API key is fine, it's minified" — Secrets in bundle
+- "We use JWT so sessions are stateless" — Can't revoke, where's refresh token?
+- "Tenant comes from the request header" — Derive from auth instead
+
+## Key takeaways
+
+- **Security is blast radius design.** Each mechanism limits damage when others fail.
+- **Never trust the client.** Every security decision must be enforced server-side.
+- **XSS is the frontend's worst enemy.** Even with HttpOnly cookies, XSS can make requests as the user. CSP + output encoding are essential.
+- **Third-party scripts are privileged code.** Every script runs with your origin's full access.
+- **Token storage is a trade-off.** HttpOnly cookies prevent theft but need CSRF protection. Memory-based tokens need careful refresh logic.
+
+The client is not a security boundary—it's an attack surface. Design assuming it's compromised, and limit the damage it can cause.
+
+---
+
+## Further reading
+
+- [OWASP Top 10](https://owasp.org/www-project-top-ten/) — The industry-standard ranking of web application security risks; use this as your baseline checklist for the most common and critical vulnerabilities.
+- [The Tangled Web — Michal Zalewski](https://lcamtuf.coredump.cx/tangled/) — The definitive book on browser security internals; deep-dives into same-origin policy, XSS, and the subtle ways browsers handle trust boundaries.
+- [Web Security — MDN Web Docs](https://developer.mozilla.org/en-US/docs/Web/Security) — Mozilla's comprehensive guide to web security fundamentals including CSP, HTTPS, secure contexts, and common attack vectors.
+- [CSP Evaluator — Google](https://csp-evaluator.withgoogle.com/) — Paste your Content Security Policy and get instant feedback on weaknesses and bypasses; essential for iterating toward a strict, effective CSP.
+- [JWT Best Practices — RFC 8725](https://datatracker.ietf.org/doc/html/rfc8725) — The IETF's official recommendations for securely using JSON Web Tokens; covers algorithm selection, claim validation, and common implementation pitfalls.
+
+---
+
+## Frequently Asked Questions (FAQs)
+
+1. **What's "blast radius design" for security?**
+   Security isn't just preventing attacks—it's minimizing damage when attacks succeed. Design layers of defense where each limits blast radius. For related failure handling patterns, see [Consistency and Failure Handling](./consistency-and-failure-handling.md).
+
+2. **Where should I store JWT tokens in a React SPA?**
+   Recommended pattern: short-lived access tokens in memory, refresh tokens in HTTPOnly cookies with SameSite=Strict. For state management of auth state, see [State Management at Scale](./state-management-at-scale.md) for cross-tab synchronization of logout.
+
+3. **What's the difference between XSS and CSRF?**
+   XSS: attacker injects code that runs in your site's context. CSRF: attacker tricks browser into making authenticated requests. For validating user input, see [Data Contracts](../best-practices/data-contracts.md) for validation boundaries.
+
+4. **Does HTTPOnly prevent XSS attacks?**
+   No. HTTPOnly prevents cookie theft but XSS can still make authenticated requests. HTTPOnly limits blast radius; it doesn't prevent XSS. For caching implications of authentication, see [Caching Strategies](./caching-strategies.md).
+
+5. **How do I implement Content Security Policy (CSP)?**
+   Start with report-only mode to find violations. Remove inline scripts. Tighten progressively. For bundle optimization that reduces script sources, see [Performance Optimization](./performance-optimization.md).
+
+6. **What's the SameSite cookie attribute?**
+   SameSite controls when cookies are sent cross-site. `Strict`: never sent cross-site. `Lax`: sent on top-level navigation. Use `Strict` for auth cookies. For related CORS patterns, see [Network Protocols](./network-protocols.md).
+
+7. **How do I protect against third-party script risks?**
+   Third-party scripts run with your origin's privileges. Mitigations: Subresource Integrity (SRI), sandboxed iframes, strict CSP. For bundle size implications of third-party scripts, see [Performance Optimization](./performance-optimization.md).
+
+8. **What's the principle of least privilege for frontend?**
+   Give each part of the system minimum necessary access: short-lived tokens, scoped API permissions, restricted CSP. For how this applies to component design, see [Component API Design](../best-practices/component-api-design.md) for limiting prop exposure.
+
+9. **How do I handle logout securely?**
+   Clear all auth state: memory tokens, HTTPOnly cookies (server-side), localStorage. Broadcast logout to other tabs—see [State Management at Scale](./state-management-at-scale.md) for cross-tab communication. Server should invalidate refresh tokens.
+
+10. **What security headers should every frontend set?**
+    Essential headers: `Strict-Transport-Security`, `Content-Security-Policy`, `X-Frame-Options`, `X-Content-Type-Options: nosniff`. For caching headers, see [Network Protocols](./network-protocols.md). For CDN header configuration, see [Distributed Systems](./distributed-systems.md).
+
+---
+
+*Build frontends where security is architecture, not afterthought — start with [Bitloops](https://bitloops.com).*
diff --git a/documentation/docs/frontend-copilot/ui-systems-performance/state-management-at-scale.md b/documentation/docs/frontend-copilot/ui-systems-performance/state-management-at-scale.md
new file mode 100644
index 00000000..a9baa5d9
--- /dev/null
+++ b/documentation/docs/frontend-copilot/ui-systems-performance/state-management-at-scale.md
@@ -0,0 +1,514 @@
+---
+sidebar_position: 2
+sidebar_label: State Management at Scale
+title: "State Management as Replication: Sources of Truth, Sync, and Conflict Resolution"
+description: "State management isn't Redux vs. Zustand—it's replication design. Learn sources of truth, client-server sync, cross-tab coordination, and conflict resolution patterns."
+keywords:
+  [
+    react state management patterns,
+    frontend state architecture,
+    client server state sync,
+    zustand vs redux vs tanstack query,
+    cross tab state synchronization,
+    state replication frontend,
+    optimistic state updates,
+    source of truth frontend,
+  ]
+---
+
+# State as a System
+
+State management isn't about Redux vs. Zustand vs. Context. It's about answering a more fundamental question: **What is the source of truth, and how do I keep everything synchronized with it?**
+
+Here's the insight that changes how you think about this problem: frontend state management is replication design. You're constantly replicating server data to the client, keeping replicas fresh, and resolving conflicts when they diverge. This is the same problem that database engineers have been solving for decades—you're just solving it in the browser.
+
+## The browser as a distributed system
+
+Backend engineers think about databases, replication, and consistency guarantees. Frontend engineers face identical problems across different substrates: server responses, client memory, URL parameters, localStorage, IndexedDB, and service workers. The browser is a distributed system with multiple "nodes" that can hold conflicting versions of data.
+
+Consider the concrete mapping:
+
+| Distributed Systems Concept | Browser Equivalent |
+|----------------------------|-------------------|
+| Nodes | Tabs, iframes, Web Workers, Service Workers |
+| Communication channels | BroadcastChannel, postMessage, storage events |
+| Network partition | Offline, slow connection, failed requests |
+| Coordination service | None built-in (you must design your own) |
+| Persistence layer | localStorage, IndexedDB, Cache API |
+
+The CAP theorem applies directly. Partition tolerance isn't optional—the network *will* fail. Requests time out. Users go offline. Given that partitions happen, you must choose between availability and consistency:
+
+- **Show stale cached data immediately** (available, not perfectly consistent)
+- **Block UI until fresh data arrives** (consistent, not available during fetch)
+- **Queue mutations offline for later sync** (available, eventually consistent)—see *Consistency Models & Failure Handling* for the intent preservation pattern that makes this work
+
+Every refresh, every tab, every network hiccup is a potential consistency problem.
+
+---
+
+## What makes frontend different
+
+Three factors distinguish frontend state management from backend replication:
+
+1. **Perception matters.** Users see the state directly. Inconsistency isn't just a log entry—it's a broken UI. When a user's cart shows 3 items in one tab and 4 in another, they notice.
+2. **No default conflict resolver.** The browser provides coordination primitives (BroadcastChannel, storage events, Service Workers), but no automatic consistency or consensus. You must design conflict resolution yourself.
+3. **The user is an actor.** Unlike batch processing or queue-based backends, users generate mutations constantly—typing, clicking, dragging. Every user action is a potential write that must be coordinated.
+
+## The four sources of truth
+
+Every frontend application deals with four categories of state. Understanding what each one *is* determines how you should manage it.
+
+### 1) Server state (authoritative)
+
+This is the canonical data that lives on the backend. User profiles, product catalogs, order history—data that must persist and be shared across sessions and devices.
+
+Server state is authoritative, but by the time it arrives at the client, it's already stale. The moment you receive a response, someone else might be modifying that data on the server. This is the fundamental tension of client-server architecture.
+
+### 2) Client state (authoritative for UI)
+
+UI-specific data that doesn't exist on the server: modal open/closed, form in-progress values, drag position, undo stacks. This state is ephemeral—it doesn't need to survive a page refresh.
+
+Client state is authoritative for its domain. There's no need to sync a tooltip's visibility to the server. The mistake is mixing client state with server state management tools, which adds complexity without benefit.
+
+### 3) URL state (shared and shareable)
+
+State that should be bookmarkable and shareable: search filters, pagination, selected tabs, view modes. URL state must be serializable and survives refresh. It affects the browser's back button.
+
+The URL is an underutilized state manager. For state that users might want to share or return to, the URL is the right owner.
+
+### 4) Cache state (non-authoritative)
+
+Previously-fetched server data held locally. React Query cache, Apollo cache, service worker cache—these are **replicas** of server state, not competing sources of truth.
+
+This distinction matters. Cache is a performance optimization. It can be stale. It can be invalidated. Treating cache as authoritative leads to bugs where stale data overwrites fresh data, or where cache updates don't trigger re-fetches when they should.
+
+---
+
+## Ownership: the most important concept
+
+Every piece of data needs exactly one owner—the source that can modify the data and is responsible for its correctness. Readers can have copies (replicas), but replicas must not diverge from the owner indefinitely.
+
+The most common state management mistake is multiple components each fetching and storing the same data independently. This creates uncoordinated replicas that inevitably diverge.
+
+- **Server-owned data:** The client reads a replica, sends mutations, and waits for confirmation (or optimistically updates the replica while the mutation is in flight).
+- **Client-owned data:** The client is the source of truth. The server may persist it as a backup, but the client version is canonical.
+- **URL-owned data:** The URL is the source of truth. Components read from it and write to it through navigation.
+- **Hybrid ownership:** The server owns the canonical version, but the client owns speculative or in-flight mutations until confirmed.
+
+---
+
+## Consistency guarantees that matter
+
+Distributed systems literature has precise vocabulary for consistency. These guarantees translate directly to UI behavior—and to UI bugs when violated.
+
+### a) Read-your-writes
+
+After you write, you immediately see your write. Violation: "I submitted a comment but it's not showing up." This is the minimum expectation users have. If they perform an action, they expect to see the result.
+
+**Implementation:** Optimistic updates (see *Consistency Models & Failure Handling* for patterns), or immediate cache updates after mutation confirmation.
+
+### b) Monotonic reads
+
+You never see older data after seeing newer data. Violation: "The count was 5, now it's 3, now it's 5 again." This makes users distrust the interface.
+
+**Implementation:** Track version numbers. Reject responses with older versions than what you've already displayed.
+
+### c) Bounded staleness
+
+Data is at most X seconds or X versions old. Violation: "This shows yesterday's prices." Users need to know they can trust what they see.
+
+**Implementation:** Stale-while-revalidate with max-age. Show "last updated" timestamps. Trigger re-fetch when data exceeds staleness threshold.
+
+### d) Causal consistency
+
+If A caused B, you see A before B. Violation: "I see the reply but not the parent comment." This creates confusing, incoherent interfaces.
+
+**Implementation:** Include parent references. Order by logical timestamps, not wall-clock time.
+
+### e) Eventual convergence
+
+All replicas eventually agree. Violation: "My two tabs show different cart contents." This is particularly noticeable in multi-tab scenarios.
+
+**Implementation:** Cross-tab synchronization. Background revalidation. Shared cache with invalidation broadcasts.
+
+---
+
+## Race conditions: the #1 bug source
+
+Race conditions cause the most subtle and hard-to-reproduce frontend bugs. The "UI briefly shows wrong data" class of issues almost always traces back to responses arriving out of order, stale closures, or missing cancellation.
+
+**Asynchronous Operations** covers these patterns in depth—operation scopes, commit guards, and the latest-wins pattern that prevents stale results from corrupting state.
+
+### Stale response overwrites fresh data
+
+User types "react" then "redux". The "react" request takes 500ms; "redux" takes 100ms. Without guards, "redux" results arrive first, then "react" results overwrite them—showing results for the wrong query.
+
+### Stale closure captures old state
+
+A closure captures `count = 5`. User clicks, count becomes 6. The async callback runs with the stale value of 5. State goes backward.
+
+### Duplicate requests on rapid interaction
+
+User clicks "Submit" twice quickly. Two identical mutations are sent. Data is duplicated or corrupted.
+
+---
+
+## Preventing race conditions
+
+**Request cancellation** aborts in-flight requests when inputs change:
+
+```javascript
+const controller = useRef(null)
+
+async function search(query) {
+  controller.current?.abort()
+  controller.current = new AbortController()
+
+  try {
+    const results = await fetch(`/search?q=${query}`, {
+      signal: controller.current.signal
+    })
+    setResults(await results.json())
+  } catch (e) {
+    if (e.name !== 'AbortError') throw e
+  }
+}
+```
+
+**Sequence numbers** ensure only the latest response updates state:
+
+```javascript
+const requestIdRef = useRef(0)
+
+async function fetchData() {
+  const thisRequestId = ++requestIdRef.current
+  const data = await api.fetch()
+
+  if (thisRequestId === requestIdRef.current) {
+    setState(data)
+  }
+}
+```
+
+**Idempotency keys** make mutations safe to retry (see *Consistency Models & Failure Handling* for the full intent preservation pattern):
+
+```javascript
+const idempotencyKey = `${userId}-${action}-${timestamp}`
+await api.submit({ data, idempotencyKey })
+// Server deduplicates by key
+```
+
+**Request deduplication** prevents duplicate in-flight requests:
+
+```javascript
+const inFlight = new Map()
+
+function dedupedFetch(key, fetcher) {
+  if (inFlight.has(key)) return inFlight.get(key)
+  const promise = fetcher()
+  inFlight.set(key, promise)
+  promise.finally(() => inFlight.delete(key))
+  return promise
+}
+```
+---
+
+## Conflict resolution strategies
+
+Conflicts happen when user edits while disconnected and reconnects, two tabs modify the same data, an optimistic update conflicts with the server response, or two requests race and responses arrive out of order.
+
+1. **Last-write-wins** is simple but silently loses data. Use only when data loss is acceptable.
+2. **Server-always-wins** discards local changes on conflict. Safe but frustrating for users who lose work.
+3. **Merge strategies** combine changes rather than choosing one. Field-level merge works when different fields change. Set union works when both sides add items. This requires semantic understanding of your data.
+4. **User-decides** presents the conflict and lets the user resolve it. Use sparingly—only when automatic resolution is impossible. Good for document version conflicts; bad for routine operations.
+5. **Version vectors and ETags** detect conflicts so you can choose how to resolve them. The server rejects stale writes, forcing the client to fetch current state before retrying.
+
+---
+
+## The trade-offs
+
+### Single store vs. distributed state
+
+A single store (Redux-style) gives you one place to look, time-travel debugging, and predictable updates. But it adds boilerplate, forces everything through one bottleneck, and doesn't naturally handle async server state. The failure mode is global re-renders on unrelated changes and over-coupling between features.
+
+Distributed state (co-located with components) means state lives near where it's used. It's easier to reason about locally and better for code-splitting. But it's harder to share across components and creates potential for uncoordinated duplicates. The failure mode is the same data fetched and stored in multiple places with no synchronization.
+
+**Decision framework:** How often do distant parts of the UI need to read or write the same data? If frequently, centralize that specific state. If rarely, keep state local. You don't have to choose one approach for everything.
+
+### Normalized vs. denormalized
+
+Normalized storage keeps entities by ID and references by ID. A user entity exists in one place; posts reference `authorId`. Updates propagate automatically because there's only one copy. But selectors become complex, denormalization happens on every read, and hydrating from API responses takes more work.
+
+Denormalized storage keeps data as received from the API. A post contains the full author object nested inside. Reads are simple and match the API shape. But the same entity exists in multiple places, and updates must find all copies. Miss one, and the UI becomes inconsistent.
+
+**Decision framework:** How often is the same entity displayed in multiple places simultaneously? If a user's avatar appears in the header, comment list, and profile sidebar, normalize. If pages are standalone with no entity overlap, denormalize for simplicity.
+
+### Server-authoritative vs. optimistic
+
+Server-authoritative means the client sends a mutation, waits for the response, then updates the UI. The UI is always correct, and the mental model is simple. But it feels slow, and the UI is blocked during the request.
+
+Optimistic updates mean the client updates the UI immediately, sends the mutation, then reconciles the response. This feels instant and creates great UX for most operations. But you must handle rollback on failure, and you might briefly show incorrect data.
+
+**Decision framework:** Consider three factors. How often does the operation fail? If less than 1%, optimistic is safe. How bad is temporarily wrong state? A wrong like count is fine; a wrong account balance is not. How jarring is rollback? Removing a toast is invisible; removing a submitted comment is not. *Human Perception* provides an optimism risk rubric that formalizes this: low stakes (fully optimistic), medium stakes (optimistic with pending indicator), high stakes (pessimistic).
+
+---
+
+## Patterns
+
+### Server state separation
+
+Treat server state fundamentally differently from client state. Use dedicated tools for server state (React Query, SWR, Apollo). These handle caching, deduplication, background refetching, stale detection, and garbage collection.
+
+Server state has a different lifecycle than client state:
+
+```
+idle → loading → error | success(fresh) → stale → revalidating → success(fresh)
+```
+
+Client state has a simpler lifecycle:
+
+```
+initial → set → read → reset
+```
+
+Mixing them creates confusion about ownership, staleness, and when to refetch.
+
+### URL as state manager
+
+Use the URL for state that should be shareable or survive refresh. Filters, search queries, pagination, selected items, view modes, sort orders—these belong in the URL.
+
+What doesn't belong in the URL: sensitive data (tokens, PII), large data (base64 blobs), high-frequency state (cursor position, scroll offset), or ephemeral UI state (tooltip visibility).
+
+Debounce URL updates. Don't update on every keystroke in a search input. Canonicalize URL parameters to prevent duplicate history entries.
+
+### Optimistic update with rollback
+
+Save current state as a rollback point. Apply the optimistic update immediately. Send the mutation. On success, confirm (and maybe update with the server response if it differs). On failure, rollback to saved state and show an error.
+
+```javascript
+async function toggleLike(postId) {
+  const previousState = queryClient.getQueryData(['post', postId])
+
+  queryClient.setQueryData(['post', postId], old => ({
+    ...old,
+    liked: !old.liked,
+    likeCount: old.liked ? old.likeCount - 1 : old.likeCount + 1
+  }))
+
+  try {
+    const result = await api.toggleLike(postId)
+    queryClient.setQueryData(['post', postId], result)
+  } catch (error) {
+    queryClient.setQueryData(['post', postId], previousState)
+    showError('Failed to update. Please try again.')
+  }
+}
+```
+
+### Cross-tab coordination
+
+Use browser primitives to keep tabs synchronized. The `storage` event fires in other tabs when localStorage changes. BroadcastChannel provides explicit messaging between same-origin tabs. See *Security Boundaries* for why logout must propagate across tabs immediately.
+
+Critical for logout: when a user logs out in one tab, all tabs must handle it immediately. Stale tabs with cached auth can make requests that fail or expose data they shouldn't.
+
+```javascript
+// Trigger logout in other tabs
+function logout() {
+  clearAuthToken()
+  localStorage.setItem('logout-event', Date.now().toString())
+  localStorage.removeItem('logout-event')
+}
+
+// Listen in other tabs
+window.addEventListener('storage', (event) => {
+  if (event.key === 'logout-event') {
+    clearLocalState()
+    router.push('/login')
+  }
+})
+```
+
+## Anti-patterns
+
+### Prop drilling as state management
+
+Passing state through many component layers instead of lifting or using context creates tight coupling, makes refactoring painful, and causes unnecessary re-renders. Components in the middle don't care about the data they're passing.
+
+Use context for truly global state (theme, auth, locale). Use composition—passing components instead of data. Co-locate state closer to where it's used. Use server state tools that provide cache access anywhere.
+
+### Duplicating server state
+
+Fetching the same data in multiple components and storing it separately means the same data exists in multiple uncoordinated replicas. Updates in one place don't propagate. Wasted network requests. Inconsistent UI.
+
+Use server state management with a shared cache. Multiple components requesting the same data should result in one request and one cached response that all components read.
+
+### Global state for everything
+
+Putting all state in a global store "just in case" creates unnecessary coupling between features, makes components harder to test, and causes performance issues from unnecessary re-renders.
+
+Start local. Elevate only when needed. Most state should be component-local (`useState`) or feature-local (context at the feature boundary). Only truly shared data needs global treatment.
+
+## Real-world scenario: multi-tab session with logout
+
+Consider an application open in three tabs. The user logs out in Tab 1. Tabs 2 and 3 must handle this immediately.
+
+Session invalidation is a cross-tab consistency problem. Stale tabs with cached auth can make requests that fail with 401 errors—or worse, succeed with data they shouldn't see if the user switched accounts.
+
+```javascript
+function AuthProvider({ children }) {
+  const [user, setUser] = useState(null)
+
+  useEffect(() => {
+    const handleStorage = (event) => {
+      if (event.key === 'logout-event') {
+        setUser(null)
+        queryClient.clear()
+        router.push('/login')
+      }
+    }
+
+    window.addEventListener('storage', handleStorage)
+    return () => window.removeEventListener('storage', handleStorage)
+  }, [])
+
+  const logout = async () => {
+    await api.logout()
+    setUser(null)
+    queryClient.clear()
+    localStorage.setItem('logout-event', Date.now().toString())
+    localStorage.removeItem('logout-event')
+    router.push('/login')
+  }
+
+  return (
+    <AuthContext.Provider value={{ user, logout }}>
+      {children}
+    </AuthContext.Provider>
+  )
+}
+```
+
+Also handle: tab becomes visible, check if session is still valid. On 401 response, trigger logout in all tabs. On token refresh, update the token in all tabs.
+
+## Design review checklist
+
+**Source of Truth**
+- For each piece of data, can you name exactly one authoritative owner?
+- Is cache explicitly treated as a replica, not as an authority?
+- Is server state separated from client state?
+
+**Consistency Guarantees**
+- Do users see their own writes immediately?
+- Can data "go backwards," showing older values after newer ones?
+- How stale can each data type be before UX suffers?
+
+**Race Conditions**
+- Are in-flight requests cancelled when inputs change?
+- Is there protection against stale responses overwriting fresh data?
+- Are mutations idempotent (safe to retry)?
+
+**Multi-Tab Behavior**
+- Does state need to sync across tabs? Which state?
+- What happens if the user logs out in one tab?
+- Can two tabs make conflicting edits? How is this resolved?
+
+## Red flags
+
+- "I don't know where this data comes from" — Ownership is unclear
+- "We fetch the same data in three places" — Missing shared cache
+- "The UI flashes wrong data briefly" — Race condition
+- "Changes don't show up until refresh" — Cache not invalidating
+- "It works until you open two tabs" — No cross-tab sync
+- "The old results appear after the new ones" — Missing request cancellation
+
+## Key takeaways
+
+- **State management is replication design.** You're replicating server data to the client, keeping replicas fresh, and resolving divergence when they conflict.
+- **Ownership is everything.** Every piece of data needs exactly one authoritative source. Cache is a replica, not an authority.
+- **Consistency guarantees matter.** Read-your-writes, monotonic reads, and bounded staleness are UI requirements, not abstract theory.
+- **Race conditions are the #1 bug source.** Request cancellation, sequence guards, and deduplication are essential, not optional.
+- **Server state is not client state.** They have different lifecycles, different tools, and different mental models.
+- **The URL is an underused state manager.** For shareable, bookmarkable state, the URL is the right owner.
+
+Before writing state management code, ask: "Who owns this data, how will I keep replicas fresh, and what happens when they conflict?"
+
+---
+
+## Further reading
+
+- [Local-First Software — Ink & Switch](https://www.inkandswitch.com/local-first/) — The seminal paper on offline-first, CRDT-based applications; rethinks data ownership and sync without a central server as gatekeeper.
+- [Consistency Models — Jepsen](https://jepsen.io/consistency) — A rigorous, visual map of consistency guarantees and their relationships, giving you precise vocabulary for the state trade-offs in this document.
+- [CAP Theorem — Wikipedia](https://en.wikipedia.org/wiki/CAP_theorem) — The foundational impossibility result explaining why you must choose between consistency and availability during network partitions.
+- [TanStack Query Documentation](https://tanstack.com/query/latest) — The most widely-used server state library for React, with built-in caching, deduplication, background refetching, and stale detection patterns.
+
+---
+
+## Frequently Asked Questions (FAQs)
+
+1. **What are the four sources of truth in frontend applications?**
+   (1) Server: authoritative data (user profile, products). (2) URL: navigation state, shareable app state. (3) Local Storage/IndexedDB: persisted client state. (4) Memory: transient UI state. For caching server state, see [Caching Strategies](./caching-strategies.md). For offline persistence, see [Consistency and Failure Handling](./consistency-and-failure-handling.md).
+
+2. **What's the difference between server state and client state?**
+   Server state needs synchronization (user data, products, orders)—see [Caching Strategies](./caching-strategies.md). Client state is UI-only (modal visibility, accordion expansion). For how this affects component design, see [Component API Design](../best-practices/component-api-design.md).
+
+3. **When should I use Redux vs. Zustand vs. TanStack Query?**
+   TanStack Query (or SWR) for server state—see [Caching Strategies](./caching-strategies.md) for caching patterns. Zustand or Redux for complex client state. useState/useReducer for local component state. Most apps need all three patterns, not one "winner."
+
+4. **How do I keep state synchronized across browser tabs?**
+   Use BroadcastChannel API (modern) or localStorage events (legacy) for cross-tab communication. Critical for: auth state (see [Security Boundaries](./security-boundaries.md)), cart/selection state, real-time data. Don't sync everything—only state users expect to be consistent.
+
+5. **What is "state tearing" and how do I prevent it?**
+   State tearing occurs when a React render uses inconsistent state because an external store updated mid-render. `useSyncExternalStore` (React 18+) solves this. For related async state issues, see [Asynchronous Operations](./asynchronous-operations.md).
+
+6. **What's the difference between optimistic updates and server state caching?**
+   Caching stores server responses for later reuse (see [Caching Strategies](./caching-strategies.md)). Optimistic updates show expected results before confirmation (see [Consistency and Failure Handling](./consistency-and-failure-handling.md) for when to use optimistic vs. pessimistic patterns).
+
+7. **How do I handle conflicts when local and server state diverge?**
+   Strategies: last-write-wins, server-authoritative, merge, or user-mediated conflict UI. See [Consistency and Failure Handling](./consistency-and-failure-handling.md) for reconciliation strategies and [Human Perception](./human-perception.md) for communicating conflicts to users.
+
+8. **When should state live in the URL vs. in memory?**
+   URL state for: navigation, shareable application state (search filters, pagination). Memory for: transient UI state. For performance implications of URL state, see [Performance Optimization](./performance-optimization.md).
+
+9. **How do I debug state management issues?**
+   Use dev tools: Redux DevTools, React DevTools, TanStack Query DevTools. Log state transitions. For production debugging, see [Observability](./observability.md) for correlation IDs and distributed tracing.
+
+10. **What causes "stale closure" bugs in state management?**
+    Closures capture state values at creation time. Related: race conditions in async operations—see [Asynchronous Operations](./asynchronous-operations.md) for commit guards and request cancellation patterns that prevent stale data issues.
+
+---
+
+## Frequently Asked Questions (FAQs)
+
+1. **What are the four sources of truth in frontend applications?**
+   (1) Server: authoritative data (user profile, products). (2) URL: navigation state, shareable app state. (3) Local Storage/IndexedDB: persisted client state. (4) Memory: transient UI state. For caching server state, see [Caching Strategies](./caching-strategies.md). For offline persistence, see [Consistency and Failure Handling](./consistency-and-failure-handling.md).
+
+2. **What's the difference between server state and client state?**
+   Server state needs synchronization (user data, products, orders)—see [Caching Strategies](./caching-strategies.md). Client state is UI-only (modal visibility, accordion expansion). For how this affects component design, see [Component API Design](../best-practices/component-api-design.md).
+
+3. **When should I use Redux vs. Zustand vs. TanStack Query?**
+   TanStack Query (or SWR) for server state—see [Caching Strategies](./caching-strategies.md) for caching patterns. Zustand or Redux for complex client state. useState/useReducer for local component state. Most apps need all three patterns, not one "winner."
+
+4. **How do I keep state synchronized across browser tabs?**
+   Use BroadcastChannel API (modern) or localStorage events (legacy) for cross-tab communication. Critical for: auth state (see [Security Boundaries](./security-boundaries.md)), cart/selection state, real-time data. Don't sync everything—only state users expect to be consistent.
+
+5. **What is "state tearing" and how do I prevent it?**
+   State tearing occurs when a React render uses inconsistent state because an external store updated mid-render. `useSyncExternalStore` (React 18+) solves this. For related async state issues, see [Asynchronous Operations](./asynchronous-operations.md).
+
+6. **What's the difference between optimistic updates and server state caching?**
+   Caching stores server responses for later reuse (see [Caching Strategies](./caching-strategies.md)). Optimistic updates show expected results before confirmation (see [Consistency and Failure Handling](./consistency-and-failure-handling.md) for when to use optimistic vs. pessimistic patterns).
+
+7. **How do I handle conflicts when local and server state diverge?**
+   Strategies: last-write-wins, server-authoritative, merge, or user-mediated conflict UI. See [Consistency and Failure Handling](./consistency-and-failure-handling.md) for reconciliation strategies and [Human Perception](./human-perception.md) for communicating conflicts to users.
+
+8. **When should state live in the URL vs. in memory?**
+   URL state for: navigation, shareable application state (search filters, pagination). Memory for: transient UI state. For performance implications of URL state, see [Performance Optimization](./performance-optimization.md).
+
+9. **How do I debug state management issues?**
+   Use dev tools: Redux DevTools, React DevTools, TanStack Query DevTools. Log state transitions. For production debugging, see [Observability](./observability.md) for correlation IDs and distributed tracing.
+
+10. **What causes "stale closure" bugs in state management?**
+    Closures capture state values at creation time. Related: race conditions in async operations—see [Asynchronous Operations](./asynchronous-operations.md) for commit guards and request cancellation patterns that prevent stale data issues.
+
+---
+
+*Tame state complexity and keep your data consistent across every tab and component with [Bitloops](https://bitloops.com) — your AI-powered frontend copilot.*
diff --git a/documentation/docusaurus.config.js b/documentation/docusaurus.config.js
index 656e47b5..221bed21 100644
--- a/documentation/docusaurus.config.js
+++ b/documentation/docusaurus.config.js
@@ -38,23 +38,19 @@ const config = {
       {
         id: 'bitloops-language',
         path: 'docs/bitloops-language',
-        routeBasePath: 'bitloops-language', // Adjusted
+        routeBasePath: 'bitloops-language',
         sidebarPath: require.resolve('./sidebarsBitloops.js'),
-        // editUrl: 'https://github.com/bitloops/bitloops-language/edit/main/documentation',
       },
     ],
     [
       '@docusaurus/plugin-content-docs',
       {
-        id: 'design-2-code',
-        path: 'docs/design-2-code',
-        routeBasePath: 'design-2-code', // Adjusted
-        sidebarPath: require.resolve('./sidebarsDesign2Code.js'),
-        // disableVersioning: true, // optional, based on your preference
-        // You might want to add an edit URL for design-2-code as well
+        id: 'frontend-copilot',
+        path: 'docs/frontend-copilot',
+        routeBasePath: 'frontend-copilot',
+        sidebarPath: require.resolve('./sidebarsFrontendCopilot.js'),
       },
     ],
-    // ... other plugins you might have
   ],
   themeConfig: {
     navbar: {
diff --git a/documentation/sidebarsDesign2Code.js b/documentation/sidebarsDesign2Code.js
deleted file mode 100644
index bd420997..00000000
--- a/documentation/sidebarsDesign2Code.js
+++ /dev/null
@@ -1,59 +0,0 @@
-module.exports = {
-  design2CodeSidebar: [
-    {
-      type: 'category',
-      label: 'Overview',
-      link: {
-        type: 'generated-index',
-        description: 'Discover how Bitloops, an AI Agent and Frontend Copilot, empowers frontend developers to create high-quality, responsive code effortlessly. Explore what it is, its standout features, and how it can integrate seamlessly into your workflow.',
-      },
-      items: [
-        'overview/introduction-to-bitloops',
-        'overview/what-is-a-frontend-copilot',
-        'overview/key-features',
-        'overview/how-it-works',
-      ],
-    },
-    {
-      type: 'category',
-      label: 'Getting Started',
-      link: {
-        type: 'generated-index',
-        description: 'Get started with Bitloops in minutes and convert your first design into well-structured, responsive and professional code in the next 10 mins!',
-      },
-      items: [
-        'getting-started/quick-start-guide',
-        'getting-started/terminology',
-        'getting-started/faqs',
-      ],
-    },
-    {
-      type: 'category',
-      label: 'Guides',
-      link: {
-        type: 'generated-index',
-        description: "Learn the essentials with 'Design Conversion Basics,' ensuring a smooth transition from design to code. Delve into 'Working with the Output' for expert tips on integrating and optimizing Bitloops-generated code. Embrace 'Best Practices' to elevate your projects, enhancing efficiency and quality.",
-      },
-      items: [
-        'Guides/frontend-best-practices',
-        'Guides/frontend-testing',
-        'Guides/working-with-design-systems',
-        'Guides/working-with-storybook',
-        'Guides/design-conversion-basics',
-      ],
-    },
-    {
-      type: 'category',
-      label: 'Troubleshooting & Support',
-      link: {
-        type: 'generated-index',
-        description: "Guidance on overcoming challenges with Bitloops. Discover resources, including troubleshooting common issues, detailed steps for reporting bugs, and direct access to our dedicated support team. This section is your essential toolkit for ensuring a smooth and uninterrupted experience with Bitloops, enabling you to resolve any obstacles swiftly and continue your seamless design-to-code journey.",
-      },
-      items: [
-        'Troubleshooting-and-Support/common-challenges',
-        'Troubleshooting-and-Support/contact-support',
-        'Troubleshooting-and-Support/reporting-bugs',
-      ],
-    },
-  ],
-};
\ No newline at end of file
diff --git a/documentation/sidebarsFrontendCopilot.js b/documentation/sidebarsFrontendCopilot.js
new file mode 100644
index 00000000..681798d4
--- /dev/null
+++ b/documentation/sidebarsFrontendCopilot.js
@@ -0,0 +1,146 @@
+module.exports = {
+  frontendCopilotSidebar: [
+    {
+      type: 'category',
+      label: 'Introduction',
+      link: {
+        type: 'generated-index',
+        description: 'Discover Bitloops, the AI-powered Frontend Copilot that transforms Figma designs into production-ready React code.',
+      },
+      items: [
+        'introduction/what-is-bitloops',
+        'introduction/why-bitloops',
+        'introduction/what-is-a-frontend-copilot',
+        'introduction/how-bitloops-works',
+        'introduction/who-should-use-bitloops',
+      ],
+    },
+    {
+      type: 'category',
+      label: 'Getting Started',
+      link: {
+        type: 'generated-index',
+        description: 'Three ways to start: follow the Essential Guide end-to-end, use Quick Start as a fast checklist, and reference Code Output Overview to understand what Bitloops generates in your repo.',
+      },
+      items: [
+        'getting-started-new/essential-guide',
+        'getting-started-new/quick-start',
+        'getting-started-new/code-output-overview',
+      ],
+    },
+    {
+      type: 'category',
+      label: 'Core Concepts',
+      link: {
+        type: 'generated-index',
+        description: 'Understand the fundamental concepts that power Bitloops: designs, components, snapshots, variants, and more.',
+      },
+      items: [
+        'core-concepts/designs',
+        'core-concepts/components-and-reusability',
+        'core-concepts/snapshots',
+        'core-concepts/variants',
+        'core-concepts/design-system',
+        'core-concepts/canvases',
+        'core-concepts/layout-containers',
+        'core-concepts/tailwind-css',
+        'core-concepts/code-generation-and-testing',
+      ],
+    },
+    {
+      type: 'category',
+      label: 'Tutorials',
+      link: {
+        type: 'generated-index',
+        description: 'Long-form walkthroughs that teach you Bitloops by building real UI—component boundaries, snapshots, responsiveness, and all the stuff that actually ships.',
+      },
+      items: [
+        'tutorials/learn-by-watching',
+      ],
+    },
+    {
+      type: 'category',
+      label: 'Guides',
+      link: {
+        type: 'generated-index',
+        description: 'Step-by-step guides for common Bitloops workflows: importing designs, creating components, attaching snapshots, and more.',
+      },
+      items: [
+        'Guides/importing-designs',
+        'Guides/creating-components',
+        'Guides/attaching-snapshots',
+        'Guides/adding-layout-containers',
+        'Guides/component-testing',
+        'Guides/editing-components',
+        'Guides/nested-components',
+      ],
+    },
+    {
+      type: 'category',
+      label: 'FAQ & Troubleshooting',
+      link: {
+        type: 'generated-index',
+        description: 'Find answers to common questions, solutions to challenges, and tips to optimize your Bitloops workflow.',
+      },
+      items: [
+        'faq-troubleshooting/faqs',
+        'faq-troubleshooting/common-challenges',
+        'faq-troubleshooting/code-licensing',
+        'faq-troubleshooting/tips-and-tricks',
+      ],
+    },
+    {
+      type: 'category',
+      label: 'Community & Support',
+      link: {
+        type: 'generated-index',
+        description: 'Connect with the Bitloops community, get support, and contribute to making Bitloops better.',
+      },
+      items: [
+        'community-support/discord',
+        'community-support/submit-bug',
+        'community-support/contact-us',
+      ],
+    },
+    {
+      type: 'category',
+      label: 'Best Practices & Patterns',
+      link: {
+        type: 'generated-index',
+        description: 'Component-level best practices: API design, data contracts, accessibility, testing, and the patterns that produce production-quality frontends.',
+      },
+      items: [
+        'best-practices/introduction',
+        'best-practices/component-creation-workflows',
+        'best-practices/component-api-design',
+        'best-practices/data-contracts',
+        'best-practices/design-system-consumption',
+        'best-practices/responsive-behavior',
+        'best-practices/accessibility',
+        'best-practices/codebase-conventions',
+        'best-practices/testing-and-storybook',
+      ],
+    },
+    {
+      type: 'category',
+      label: 'UI Systems & Performance',
+      link: {
+        type: 'generated-index',
+        description: 'Deep-dive technical resources on frontend systems design, distributed systems thinking, and architecture patterns.',
+      },
+      items: [
+        'ui-systems-performance/introduction',
+        'ui-systems-performance/state-management-at-scale',
+        'ui-systems-performance/caching-strategies',
+        'ui-systems-performance/asynchronous-operations',
+        'ui-systems-performance/performance-optimization',
+        'ui-systems-performance/distributed-systems',
+        'ui-systems-performance/network-protocols',
+        'ui-systems-performance/security-boundaries',
+        'ui-systems-performance/consistency-and-failure-handling',
+        'ui-systems-performance/observability',
+        'ui-systems-performance/human-perception',
+      ],
+    },
+  ],
+};
diff --git a/documentation/src/components/HomepageFeatures/index.tsx b/documentation/src/components/HomepageFeatures/index.tsx
index f0b0c0ed..fea42753 100644
--- a/documentation/src/components/HomepageFeatures/index.tsx
+++ b/documentation/src/components/HomepageFeatures/index.tsx
@@ -17,10 +17,10 @@ const SectionList: SectionItem[] = [
     },
     },
   {
-    Svg: require('@site/static/img/Bitloops-Logo.svg').default, // Update the path to your actual SVG
+    Svg: require('@site/static/img/Bitloops-Logo.svg').default,
     button: {
-      title: 'Design 2 Code',
-      link: '/docs/design-2-code/overview/introduction-to-bitloops', // Update the link to the starting page of your design-2-code docs
+      title: 'Frontend Copilot',
+      link: '/docs/frontend-copilot/introduction/what-is-bitloops',
     },
   },
 ];
diff --git a/documentation/yarn.lock b/documentation/yarn.lock
index 4bea6905..2d92ba8d 100644
--- a/documentation/yarn.lock
+++ b/documentation/yarn.lock
@@ -2,399 +2,434 @@
 # yarn lockfile v1
 
 
-"@algolia/autocomplete-core@1.17.7":
-  version "1.17.7"
-  resolved "https://registry.npmjs.org/@algolia/autocomplete-core/-/autocomplete-core-1.17.7.tgz"
-  integrity sha512-BjiPOW6ks90UKl7TwMv7oNQMnzU+t/wk9mgIDi6b1tXpUek7MW0lbNOUHpvam9pe3lVCf4xPFT+lK7s+e+fs7Q==
-  dependencies:
-    "@algolia/autocomplete-plugin-algolia-insights" "1.17.7"
-    "@algolia/autocomplete-shared" "1.17.7"
-
-"@algolia/autocomplete-plugin-algolia-insights@1.17.7":
-  version "1.17.7"
-  resolved "https://registry.npmjs.org/@algolia/autocomplete-plugin-algolia-insights/-/autocomplete-plugin-algolia-insights-1.17.7.tgz"
-  integrity sha512-Jca5Ude6yUOuyzjnz57og7Et3aXjbwCSDf/8onLHSQgw1qW3ALl9mrMWaXb5FmPVkV3EtkD2F/+NkT6VHyPu9A==
-  dependencies:
-    "@algolia/autocomplete-shared" "1.17.7"
-
-"@algolia/autocomplete-preset-algolia@1.17.7":
-  version "1.17.7"
-  resolved "https://registry.npmjs.org/@algolia/autocomplete-preset-algolia/-/autocomplete-preset-algolia-1.17.7.tgz"
-  integrity sha512-ggOQ950+nwbWROq2MOCIL71RE0DdQZsceqrg32UqnhDz8FlO9rL8ONHNsI2R1MH0tkgVIDKI/D0sMiUchsFdWA==
-  dependencies:
-    "@algolia/autocomplete-shared" "1.17.7"
-
-"@algolia/autocomplete-shared@1.17.7":
-  version "1.17.7"
-  resolved "https://registry.npmjs.org/@algolia/autocomplete-shared/-/autocomplete-shared-1.17.7.tgz"
-  integrity sha512-o/1Vurr42U/qskRSuhBH+VKxMvkkUVTLU6WZQr+L5lGZZLYWyhdzWjW0iGXY7EkwRTjBqvN2EsR81yCTGV/kmg==
-
-"@algolia/client-abtesting@5.19.0":
-  version "5.19.0"
-  resolved "https://registry.npmjs.org/@algolia/client-abtesting/-/client-abtesting-5.19.0.tgz"
-  integrity sha512-dMHwy2+nBL0SnIsC1iHvkBao64h4z+roGelOz11cxrDBrAdASxLxmfVMop8gmodQ2yZSacX0Rzevtxa+9SqxCw==
-  dependencies:
-    "@algolia/client-common" "5.19.0"
-    "@algolia/requester-browser-xhr" "5.19.0"
-    "@algolia/requester-fetch" "5.19.0"
-    "@algolia/requester-node-http" "5.19.0"
-
-"@algolia/client-analytics@5.19.0":
-  version "5.19.0"
-  resolved "https://registry.npmjs.org/@algolia/client-analytics/-/client-analytics-5.19.0.tgz"
-  integrity sha512-CDW4RwnCHzU10upPJqS6N6YwDpDHno7w6/qXT9KPbPbt8szIIzCHrva4O9KIfx1OhdsHzfGSI5hMAiOOYl4DEQ==
-  dependencies:
-    "@algolia/client-common" "5.19.0"
-    "@algolia/requester-browser-xhr" "5.19.0"
-    "@algolia/requester-fetch" "5.19.0"
-    "@algolia/requester-node-http" "5.19.0"
-
-"@algolia/client-common@5.19.0":
-  version "5.19.0"
-  resolved "https://registry.npmjs.org/@algolia/client-common/-/client-common-5.19.0.tgz"
-  integrity sha512-2ERRbICHXvtj5kfFpY5r8qu9pJII/NAHsdgUXnUitQFwPdPL7wXiupcvZJC7DSntOnE8AE0lM7oDsPhrJfj5nQ==
-
-"@algolia/client-insights@5.19.0":
-  version "5.19.0"
-  resolved "https://registry.npmjs.org/@algolia/client-insights/-/client-insights-5.19.0.tgz"
-  integrity sha512-xPOiGjo6I9mfjdJO7Y+p035aWePcbsItizIp+qVyfkfZiGgD+TbNxM12g7QhFAHIkx/mlYaocxPY/TmwPzTe+A==
-  dependencies:
-    "@algolia/client-common" "5.19.0"
-    "@algolia/requester-browser-xhr" "5.19.0"
-    "@algolia/requester-fetch" "5.19.0"
-    "@algolia/requester-node-http" "5.19.0"
-
-"@algolia/client-personalization@5.19.0":
-  version "5.19.0"
-  resolved "https://registry.npmjs.org/@algolia/client-personalization/-/client-personalization-5.19.0.tgz"
-  integrity sha512-B9eoce/fk8NLboGje+pMr72pw+PV7c5Z01On477heTZ7jkxoZ4X92dobeGuEQop61cJ93Gaevd1of4mBr4hu2A==
-  dependencies:
-    "@algolia/client-common" "5.19.0"
-    "@algolia/requester-browser-xhr" "5.19.0"
-    "@algolia/requester-fetch" "5.19.0"
-    "@algolia/requester-node-http" "5.19.0"
-
-"@algolia/client-query-suggestions@5.19.0":
-  version "5.19.0"
-  resolved "https://registry.npmjs.org/@algolia/client-query-suggestions/-/client-query-suggestions-5.19.0.tgz"
-  integrity sha512-6fcP8d4S8XRDtVogrDvmSM6g5g6DndLc0pEm1GCKe9/ZkAzCmM3ZmW1wFYYPxdjMeifWy1vVEDMJK7sbE4W7MA==
-  dependencies:
-    "@algolia/client-common" "5.19.0"
-    "@algolia/requester-browser-xhr" "5.19.0"
-    "@algolia/requester-fetch" "5.19.0"
-    "@algolia/requester-node-http" "5.19.0"
-
-"@algolia/client-search@>= 4.9.1 < 6", "@algolia/client-search@5.19.0":
-  version "5.19.0"
-  resolved "https://registry.npmjs.org/@algolia/client-search/-/client-search-5.19.0.tgz"
-  integrity sha512-Ctg3xXD/1VtcwmkulR5+cKGOMj4r0wC49Y/KZdGQcqpydKn+e86F6l3tb3utLJQVq4lpEJud6kdRykFgcNsp8Q==
-  dependencies:
-    "@algolia/client-common" "5.19.0"
-    "@algolia/requester-browser-xhr" "5.19.0"
-    "@algolia/requester-fetch" "5.19.0"
-    "@algolia/requester-node-http" "5.19.0"
+"@ai-sdk/gateway@2.0.27":
+  version "2.0.27"
+  resolved "https://registry.npmjs.org/@ai-sdk/gateway/-/gateway-2.0.27.tgz"
+  integrity sha512-8hbezMsGa0crSt7/DKjkYL1UbbJJW/UFxTfhmf5qcIeYeeWG4dTNmm+DWbUdIsTaWvp59KC4eeC9gYXBbTHd7w==
+  dependencies:
+    "@ai-sdk/provider" "2.0.1"
+    "@ai-sdk/provider-utils" "3.0.20"
+    "@vercel/oidc" "3.1.0"
+
+"@ai-sdk/provider-utils@3.0.20":
+  version "3.0.20"
+  resolved "https://registry.npmjs.org/@ai-sdk/provider-utils/-/provider-utils-3.0.20.tgz"
+  integrity sha512-iXHVe0apM2zUEzauqJwqmpC37A5rihrStAih5Ks+JE32iTe4LZ58y17UGBjpQQTCRw9YxMeo2UFLxLpBluyvLQ==
+  dependencies:
+    "@ai-sdk/provider" "2.0.1"
+    "@standard-schema/spec" "^1.0.0"
+    eventsource-parser "^3.0.6"
+
+"@ai-sdk/provider@2.0.1":
+  version "2.0.1"
+  resolved "https://registry.npmjs.org/@ai-sdk/provider/-/provider-2.0.1.tgz"
+  integrity sha512-KCUwswvsC5VsW2PWFqF8eJgSCu5Ysj7m1TxiHTVA6g7k360bk0RNQENT8KTMAYEs+8fWPD3Uu4dEmzGHc+jGng==
+  dependencies:
+    json-schema "^0.4.0"
+
+"@ai-sdk/react@^2.0.30":
+  version "2.0.123"
+  resolved "https://registry.npmjs.org/@ai-sdk/react/-/react-2.0.123.tgz"
+  integrity sha512-exaEvHAsDdR0wgzF3l0BmC9U1nPLnkPK2CCnX3BP4RDj/PySZvPXjry3AOz1Ayb8KSPZgWklVRzxsQxrOYQJxA==
+  dependencies:
+    "@ai-sdk/provider-utils" "3.0.20"
+    ai "5.0.121"
+    swr "^2.2.5"
+    throttleit "2.1.0"
+
+"@algolia/abtesting@1.12.3":
+  version "1.12.3"
+  resolved "https://registry.npmjs.org/@algolia/abtesting/-/abtesting-1.12.3.tgz"
+  integrity sha512-0SpSdnME0RCS6UHSs9XD3ox4bMcCg1JTmjAJ3AU6rcTlX54CZOAEPc2as8uSghX6wfKGT0HWes4TeUpjJMg6FQ==
+  dependencies:
+    "@algolia/client-common" "5.46.3"
+    "@algolia/requester-browser-xhr" "5.46.3"
+    "@algolia/requester-fetch" "5.46.3"
+    "@algolia/requester-node-http" "5.46.3"
+
+"@algolia/autocomplete-core@1.19.2":
+  version "1.19.2"
+  resolved "https://registry.npmjs.org/@algolia/autocomplete-core/-/autocomplete-core-1.19.2.tgz"
+  integrity sha512-mKv7RyuAzXvwmq+0XRK8HqZXt9iZ5Kkm2huLjgn5JoCPtDy+oh9yxUMfDDaVCw0oyzZ1isdJBc7l9nuCyyR7Nw==
+  dependencies:
+    "@algolia/autocomplete-plugin-algolia-insights" "1.19.2"
+    "@algolia/autocomplete-shared" "1.19.2"
+
+"@algolia/autocomplete-plugin-algolia-insights@1.19.2":
+  version "1.19.2"
+  resolved "https://registry.npmjs.org/@algolia/autocomplete-plugin-algolia-insights/-/autocomplete-plugin-algolia-insights-1.19.2.tgz"
+  integrity sha512-TjxbcC/r4vwmnZaPwrHtkXNeqvlpdyR+oR9Wi2XyfORkiGkLTVhX2j+O9SaCCINbKoDfc+c2PB8NjfOnz7+oKg==
+  dependencies:
+    "@algolia/autocomplete-shared" "1.19.2"
+
+"@algolia/autocomplete-shared@1.19.2":
+  version "1.19.2"
+  resolved "https://registry.npmjs.org/@algolia/autocomplete-shared/-/autocomplete-shared-1.19.2.tgz"
+  integrity sha512-jEazxZTVD2nLrC+wYlVHQgpBoBB5KPStrJxLzsIFl6Kqd1AlG9sIAGl39V5tECLpIQzB3Qa2T6ZPJ1ChkwMK/w==
+
+"@algolia/client-abtesting@5.46.3":
+  version "5.46.3"
+  resolved "https://registry.npmjs.org/@algolia/client-abtesting/-/client-abtesting-5.46.3.tgz"
+  integrity sha512-i2C8sBcl3EKXuCd5nlGohW+pZ9pY3P3JKJ2OYqsbCPg6wURiR32hNDiDvDq7/dqJ7KWWwC2snxJhokZzGlckgQ==
+  dependencies:
+    "@algolia/client-common" "5.46.3"
+    "@algolia/requester-browser-xhr" "5.46.3"
+    "@algolia/requester-fetch" "5.46.3"
+    "@algolia/requester-node-http" "5.46.3"
+
+"@algolia/client-analytics@5.46.3":
+  version "5.46.3"
+  resolved "https://registry.npmjs.org/@algolia/client-analytics/-/client-analytics-5.46.3.tgz"
+  integrity sha512-uFmD7m3LOym1SAURHeiqupHT9jui+9HK0lAiIvm077gXEscOM5KKXM4rg/ICzQ3UDHLZEA0Lb5TglWsXnieE6w==
+  dependencies:
+    "@algolia/client-common" "5.46.3"
+    "@algolia/requester-browser-xhr" "5.46.3"
+    "@algolia/requester-fetch" "5.46.3"
+    "@algolia/requester-node-http" "5.46.3"
+
+"@algolia/client-common@5.46.3":
+  version "5.46.3"
+  resolved "https://registry.npmjs.org/@algolia/client-common/-/client-common-5.46.3.tgz"
+  integrity sha512-SN+yK840nXa+2+mF72hrDfGd8+B7eBjF8TK/8KoRMdjlAkO/P3o3vtpjKRKI/Sk4L8kYYkB/avW8l+cwR+O1Ew==
+
+"@algolia/client-insights@5.46.3":
+  version "5.46.3"
+  resolved "https://registry.npmjs.org/@algolia/client-insights/-/client-insights-5.46.3.tgz"
+  integrity sha512-5ic1liG0VucNPi6gKCWh5bEUGWQfyEmVeXiNKS+rOSppg7B7nKH0PEEJOFXBbHmgK5aPfNNZINiKcyUoH4XsFA==
+  dependencies:
+    "@algolia/client-common" "5.46.3"
+    "@algolia/requester-browser-xhr" "5.46.3"
+    "@algolia/requester-fetch" "5.46.3"
+    "@algolia/requester-node-http" "5.46.3"
+
+"@algolia/client-personalization@5.46.3":
+  version "5.46.3"
+  resolved "https://registry.npmjs.org/@algolia/client-personalization/-/client-personalization-5.46.3.tgz"
+  integrity sha512-f4HNitgTip8tntKgluYBTc1LWSOkbNCdxZvRA3rRBZnEAYSvLe7jpE+AxRep6RY+prSWwMtyeCFhA/F1Um+TuQ==
+  dependencies:
+    "@algolia/client-common" "5.46.3"
+    "@algolia/requester-browser-xhr" "5.46.3"
+    "@algolia/requester-fetch" "5.46.3"
+    "@algolia/requester-node-http" "5.46.3"
+
+"@algolia/client-query-suggestions@5.46.3":
+  version "5.46.3"
+  resolved "https://registry.npmjs.org/@algolia/client-query-suggestions/-/client-query-suggestions-5.46.3.tgz"
+  integrity sha512-/AaVqah2aYyJj7Cazu5QRkgcV3HF3lkBJo5TRkgqQ26xR4iHNRbLF2YsWJfJpJEFghlTF2HOCh7IgzaUCnM+8A==
+  dependencies:
+    "@algolia/client-common" "5.46.3"
+    "@algolia/requester-browser-xhr" "5.46.3"
+    "@algolia/requester-fetch" "5.46.3"
+    "@algolia/requester-node-http" "5.46.3"
+
+"@algolia/client-search@>= 4.9.1 < 6", "@algolia/client-search@5.46.3":
+  version "5.46.3"
+  resolved "https://registry.npmjs.org/@algolia/client-search/-/client-search-5.46.3.tgz"
+  integrity sha512-hfpCIukPuwkrlwsYfJEWdU5R5bduBHEq2uuPcqmgPgNq5MSjmiNIzRuzxGZZgiBKcre6gZT00DR7G1AFn//wiQ==
+  dependencies:
+    "@algolia/client-common" "5.46.3"
+    "@algolia/requester-browser-xhr" "5.46.3"
+    "@algolia/requester-fetch" "5.46.3"
+    "@algolia/requester-node-http" "5.46.3"
 
 "@algolia/events@^4.0.1":
   version "4.0.1"
   resolved "https://registry.npmjs.org/@algolia/events/-/events-4.0.1.tgz"
   integrity sha512-FQzvOCgoFXAbf5Y6mYozw2aj5KCJoA3m4heImceldzPSMbdyS4atVjJzXKMsfX3wnZTFYwkkt8/z8UesLHlSBQ==
 
-"@algolia/ingestion@1.19.0":
-  version "1.19.0"
-  resolved "https://registry.npmjs.org/@algolia/ingestion/-/ingestion-1.19.0.tgz"
-  integrity sha512-LO7w1MDV+ZLESwfPmXkp+KLeYeFrYEgtbCZG6buWjddhYraPQ9MuQWLhLLiaMlKxZ/sZvFTcZYuyI6Jx4WBhcg==
+"@algolia/ingestion@1.46.3":
+  version "1.46.3"
+  resolved "https://registry.npmjs.org/@algolia/ingestion/-/ingestion-1.46.3.tgz"
+  integrity sha512-ChVzNkCzAVxKozTnTgPWCG69WQLjzW7X6OqD91zUh8U38ZhPEX/t3qGhXs+M9ZNaHcJ7xToMB3jywNwONhpLGA==
   dependencies:
-    "@algolia/client-common" "5.19.0"
-    "@algolia/requester-browser-xhr" "5.19.0"
-    "@algolia/requester-fetch" "5.19.0"
-    "@algolia/requester-node-http" "5.19.0"
+    "@algolia/client-common" "5.46.3"
+    "@algolia/requester-browser-xhr" "5.46.3"
+    "@algolia/requester-fetch" "5.46.3"
+    "@algolia/requester-node-http" "5.46.3"
 
-"@algolia/monitoring@1.19.0":
-  version "1.19.0"
-  resolved "https://registry.npmjs.org/@algolia/monitoring/-/monitoring-1.19.0.tgz"
-  integrity sha512-Mg4uoS0aIKeTpu6iv6O0Hj81s8UHagi5TLm9k2mLIib4vmMtX7WgIAHAcFIaqIZp5D6s5EVy1BaDOoZ7buuJHA==
+"@algolia/monitoring@1.46.3":
+  version "1.46.3"
+  resolved "https://registry.npmjs.org/@algolia/monitoring/-/monitoring-1.46.3.tgz"
+  integrity sha512-MZa+Z5iPmVMxVAQ0aq4HpGsja5utSLEMcOuY01X8D46vvMrSPkP8DnlDFtu1PgJ0RwyIGqqx7v+ClFo6iRJ6bA==
   dependencies:
-    "@algolia/client-common" "5.19.0"
-    "@algolia/requester-browser-xhr" "5.19.0"
-    "@algolia/requester-fetch" "5.19.0"
-    "@algolia/requester-node-http" "5.19.0"
+    "@algolia/client-common" "5.46.3"
+    "@algolia/requester-browser-xhr" "5.46.3"
+    "@algolia/requester-fetch" "5.46.3"
+    "@algolia/requester-node-http" "5.46.3"
 
-"@algolia/recommend@5.19.0":
-  version "5.19.0"
-  resolved "https://registry.npmjs.org/@algolia/recommend/-/recommend-5.19.0.tgz"
-  integrity sha512-PbgrMTbUPlmwfJsxjFhal4XqZO2kpBNRjemLVTkUiti4w/+kzcYO4Hg5zaBgVqPwvFDNQ8JS4SS3TBBem88u+g==
+"@algolia/recommend@5.46.3":
+  version "5.46.3"
+  resolved "https://registry.npmjs.org/@algolia/recommend/-/recommend-5.46.3.tgz"
+  integrity sha512-cr3atJRJBKgAKZl/Oxo4sig6Se0+ukbyIOOluPV5H+ZAXVcxuMoXQgwQ1M5UHPnCnEsZ4uBXhBmilRgUQpUegw==
   dependencies:
-    "@algolia/client-common" "5.19.0"
-    "@algolia/requester-browser-xhr" "5.19.0"
-    "@algolia/requester-fetch" "5.19.0"
-    "@algolia/requester-node-http" "5.19.0"
+    "@algolia/client-common" "5.46.3"
+    "@algolia/requester-browser-xhr" "5.46.3"
+    "@algolia/requester-fetch" "5.46.3"
+    "@algolia/requester-node-http" "5.46.3"
 
-"@algolia/requester-browser-xhr@5.19.0":
-  version "5.19.0"
-  resolved "https://registry.npmjs.org/@algolia/requester-browser-xhr/-/requester-browser-xhr-5.19.0.tgz"
-  integrity sha512-GfnhnQBT23mW/VMNs7m1qyEyZzhZz093aY2x8p0era96MMyNv8+FxGek5pjVX0b57tmSCZPf4EqNCpkGcGsmbw==
+"@algolia/requester-browser-xhr@5.46.3":
+  version "5.46.3"
+  resolved "https://registry.npmjs.org/@algolia/requester-browser-xhr/-/requester-browser-xhr-5.46.3.tgz"
+  integrity sha512-/Ku9GImJf2SKoRM2S3e03MjCVaWJCP5olih4k54DRhNDdmxBkd3nsWuUXvDElY3Ucw/arBYGs5SYz79SoS5APw==
   dependencies:
-    "@algolia/client-common" "5.19.0"
+    "@algolia/client-common" "5.46.3"
 
-"@algolia/requester-fetch@5.19.0":
-  version "5.19.0"
-  resolved "https://registry.npmjs.org/@algolia/requester-fetch/-/requester-fetch-5.19.0.tgz"
-  integrity sha512-oyTt8ZJ4T4fYvW5avAnuEc6Laedcme9fAFryMD9ndUTIUe/P0kn3BuGcCLFjN3FDmdrETHSFkgPPf1hGy3sLCw==
+"@algolia/requester-fetch@5.46.3":
+  version "5.46.3"
+  resolved "https://registry.npmjs.org/@algolia/requester-fetch/-/requester-fetch-5.46.3.tgz"
+  integrity sha512-Uw+SPy/zpfwbH1AxQaeOWvWVzPEcO0XbtLbbSz0HPcEIiBGWyfa9LUCxD5UferbDjrSQNVimmzl3FaWi4u8Ykw==
   dependencies:
-    "@algolia/client-common" "5.19.0"
+    "@algolia/client-common" "5.46.3"
 
-"@algolia/requester-node-http@5.19.0":
-  version "5.19.0"
-  resolved "https://registry.npmjs.org/@algolia/requester-node-http/-/requester-node-http-5.19.0.tgz"
-  integrity sha512-p6t8ue0XZNjcRiqNkb5QAM0qQRAKsCiebZ6n9JjWA+p8fWf8BvnhO55y2fO28g3GW0Imj7PrAuyBuxq8aDVQwQ==
+"@algolia/requester-node-http@5.46.3":
+  version "5.46.3"
+  resolved "https://registry.npmjs.org/@algolia/requester-node-http/-/requester-node-http-5.46.3.tgz"
+  integrity sha512-4No9iTjr1GZ0JWsFbQJj9aZBnmKyY1sTxOoEud9+SGe3U6iAulF0A0lI4cWi/F/Gcfg8V3jkaddcqSQKDnE45w==
   dependencies:
-    "@algolia/client-common" "5.19.0"
-
-"@ampproject/remapping@^2.2.0":
-  version "2.3.0"
-  resolved "https://registry.npmjs.org/@ampproject/remapping/-/remapping-2.3.0.tgz"
-  integrity sha512-30iZtAPgz+LTIYoeivqYo853f02jBYSd5uGnGpkFV0M3xOt9aN73erkgYAmZU43x4VfqcnLxW9Kpg3R5LC4YYw==
-  dependencies:
-    "@jridgewell/gen-mapping" "^0.3.5"
-    "@jridgewell/trace-mapping" "^0.3.24"
+    "@algolia/client-common" "5.46.3"
 
-"@babel/code-frame@^7.0.0", "@babel/code-frame@^7.16.0", "@babel/code-frame@^7.25.9", "@babel/code-frame@^7.26.0", "@babel/code-frame@^7.26.2", "@babel/code-frame@^7.8.3":
-  version "7.26.2"
-  resolved "https://registry.npmjs.org/@babel/code-frame/-/code-frame-7.26.2.tgz"
-  integrity sha512-RJlIHRueQgwWitWgF8OdFYGZX328Ax5BCemNGlqHfplnRT9ESi8JkFlvaVYbS+UubVY6dpv87Fs2u5M29iNFVQ==
+"@babel/code-frame@^7.0.0", "@babel/code-frame@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/code-frame/-/code-frame-7.28.6.tgz"
+  integrity sha512-JYgintcMjRiCvS8mMECzaEn+m3PfoQiyqukOMCCVQtoJGYJw8j/8LBJEiqkHLkfwCcs74E3pbAUFNg7d9VNJ+Q==
   dependencies:
-    "@babel/helper-validator-identifier" "^7.25.9"
+    "@babel/helper-validator-identifier" "^7.28.5"
     js-tokens "^4.0.0"
-    picocolors "^1.0.0"
+    picocolors "^1.1.1"
 
-"@babel/compat-data@^7.22.6", "@babel/compat-data@^7.26.0", "@babel/compat-data@^7.26.5":
-  version "7.26.5"
-  resolved "https://registry.npmjs.org/@babel/compat-data/-/compat-data-7.26.5.tgz"
-  integrity sha512-XvcZi1KWf88RVbF9wn8MN6tYFloU5qX8KjuF3E1PVBmJ9eypXfs4GRiJwLuTZL0iSnJUKn1BFPa5BPZZJyFzPg==
+"@babel/compat-data@^7.27.7", "@babel/compat-data@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/compat-data/-/compat-data-7.28.6.tgz"
+  integrity sha512-2lfu57JtzctfIrcGMz992hyLlByuzgIk58+hhGCxjKZ3rWI82NnVLjXcaTqkI2NvlcvOskZaiZ5kjUALo3Lpxg==
 
 "@babel/core@^7.0.0", "@babel/core@^7.0.0-0", "@babel/core@^7.0.0-0 || ^8.0.0-0 <8.0.0", "@babel/core@^7.12.0", "@babel/core@^7.13.0", "@babel/core@^7.21.3", "@babel/core@^7.25.9", "@babel/core@^7.4.0 || ^8.0.0-0 <8.0.0":
-  version "7.26.0"
-  resolved "https://registry.npmjs.org/@babel/core/-/core-7.26.0.tgz"
-  integrity sha512-i1SLeK+DzNnQ3LL/CswPCa/E5u4lh1k6IAEphON8F+cXt0t9euTshDru0q7/IqMa1PMPz5RnHuHscF8/ZJsStg==
-  dependencies:
-    "@ampproject/remapping" "^2.2.0"
-    "@babel/code-frame" "^7.26.0"
-    "@babel/generator" "^7.26.0"
-    "@babel/helper-compilation-targets" "^7.25.9"
-    "@babel/helper-module-transforms" "^7.26.0"
-    "@babel/helpers" "^7.26.0"
-    "@babel/parser" "^7.26.0"
-    "@babel/template" "^7.25.9"
-    "@babel/traverse" "^7.25.9"
-    "@babel/types" "^7.26.0"
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/core/-/core-7.28.6.tgz"
+  integrity sha512-H3mcG6ZDLTlYfaSNi0iOKkigqMFvkTKlGUYlD8GW7nNOYRrevuA46iTypPyv+06V3fEmvvazfntkBU34L0azAw==
+  dependencies:
+    "@babel/code-frame" "^7.28.6"
+    "@babel/generator" "^7.28.6"
+    "@babel/helper-compilation-targets" "^7.28.6"
+    "@babel/helper-module-transforms" "^7.28.6"
+    "@babel/helpers" "^7.28.6"
+    "@babel/parser" "^7.28.6"
+    "@babel/template" "^7.28.6"
+    "@babel/traverse" "^7.28.6"
+    "@babel/types" "^7.28.6"
+    "@jridgewell/remapping" "^2.3.5"
     convert-source-map "^2.0.0"
     debug "^4.1.0"
     gensync "^1.0.0-beta.2"
     json5 "^2.2.3"
     semver "^6.3.1"
 
-"@babel/generator@^7.25.9", "@babel/generator@^7.26.0", "@babel/generator@^7.26.5":
-  version "7.26.5"
-  resolved "https://registry.npmjs.org/@babel/generator/-/generator-7.26.5.tgz"
-  integrity sha512-2caSP6fN9I7HOe6nqhtft7V4g7/V/gfDsC3Ag4W7kEzzvRGKqiv0pu0HogPiZ3KaVSoNDhUws6IJjDjpfmYIXw==
+"@babel/generator@^7.25.9", "@babel/generator@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/generator/-/generator-7.28.6.tgz"
+  integrity sha512-lOoVRwADj8hjf7al89tvQ2a1lf53Z+7tiXMgpZJL3maQPDxh0DgLMN62B2MKUOFcoodBHLMbDM6WAbKgNy5Suw==
   dependencies:
-    "@babel/parser" "^7.26.5"
-    "@babel/types" "^7.26.5"
-    "@jridgewell/gen-mapping" "^0.3.5"
-    "@jridgewell/trace-mapping" "^0.3.25"
+    "@babel/parser" "^7.28.6"
+    "@babel/types" "^7.28.6"
+    "@jridgewell/gen-mapping" "^0.3.12"
+    "@jridgewell/trace-mapping" "^0.3.28"
     jsesc "^3.0.2"
 
-"@babel/helper-annotate-as-pure@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/helper-annotate-as-pure/-/helper-annotate-as-pure-7.25.9.tgz"
-  integrity sha512-gv7320KBUFJz1RnylIg5WWYPRXKZ884AGkYpgpWW02TH66Dl+HaC1t1CKd0z3R4b6hdYEcmrNZHUmfCP+1u3/g==
+"@babel/helper-annotate-as-pure@^7.27.1", "@babel/helper-annotate-as-pure@^7.27.3":
+  version "7.27.3"
+  resolved "https://registry.npmjs.org/@babel/helper-annotate-as-pure/-/helper-annotate-as-pure-7.27.3.tgz"
+  integrity sha512-fXSwMQqitTGeHLBC08Eq5yXz2m37E4pJX1qAU1+2cNedz/ifv/bVXft90VeSav5nFO61EcNgwr0aJxbyPaWBPg==
   dependencies:
-    "@babel/types" "^7.25.9"
+    "@babel/types" "^7.27.3"
 
-"@babel/helper-compilation-targets@^7.22.6", "@babel/helper-compilation-targets@^7.25.9":
-  version "7.26.5"
-  resolved "https://registry.npmjs.org/@babel/helper-compilation-targets/-/helper-compilation-targets-7.26.5.tgz"
-  integrity sha512-IXuyn5EkouFJscIDuFF5EsiSolseme1s0CZB+QxVugqJLYmKdxI1VfIBOst0SUu4rnk2Z7kqTwmoO1lp3HIfnA==
+"@babel/helper-compilation-targets@^7.27.1", "@babel/helper-compilation-targets@^7.27.2", "@babel/helper-compilation-targets@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/helper-compilation-targets/-/helper-compilation-targets-7.28.6.tgz"
+  integrity sha512-JYtls3hqi15fcx5GaSNL7SCTJ2MNmjrkHXg4FSpOA/grxK8KwyZ5bubHsCq8FXCkua6xhuaaBit+3b7+VZRfcA==
   dependencies:
-    "@babel/compat-data" "^7.26.5"
-    "@babel/helper-validator-option" "^7.25.9"
+    "@babel/compat-data" "^7.28.6"
+    "@babel/helper-validator-option" "^7.27.1"
     browserslist "^4.24.0"
     lru-cache "^5.1.1"
     semver "^6.3.1"
 
-"@babel/helper-create-class-features-plugin@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/helper-create-class-features-plugin/-/helper-create-class-features-plugin-7.25.9.tgz"
-  integrity sha512-UTZQMvt0d/rSz6KI+qdu7GQze5TIajwTS++GUozlw8VBJDEOAqSXwm1WvmYEZwqdqSGQshRocPDqrt4HBZB3fQ==
-  dependencies:
-    "@babel/helper-annotate-as-pure" "^7.25.9"
-    "@babel/helper-member-expression-to-functions" "^7.25.9"
-    "@babel/helper-optimise-call-expression" "^7.25.9"
-    "@babel/helper-replace-supers" "^7.25.9"
-    "@babel/helper-skip-transparent-expression-wrappers" "^7.25.9"
-    "@babel/traverse" "^7.25.9"
+"@babel/helper-create-class-features-plugin@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/helper-create-class-features-plugin/-/helper-create-class-features-plugin-7.28.6.tgz"
+  integrity sha512-dTOdvsjnG3xNT9Y0AUg1wAl38y+4Rl4sf9caSQZOXdNqVn+H+HbbJ4IyyHaIqNR6SW9oJpA/RuRjsjCw2IdIow==
+  dependencies:
+    "@babel/helper-annotate-as-pure" "^7.27.3"
+    "@babel/helper-member-expression-to-functions" "^7.28.5"
+    "@babel/helper-optimise-call-expression" "^7.27.1"
+    "@babel/helper-replace-supers" "^7.28.6"
+    "@babel/helper-skip-transparent-expression-wrappers" "^7.27.1"
+    "@babel/traverse" "^7.28.6"
     semver "^6.3.1"
 
-"@babel/helper-create-regexp-features-plugin@^7.18.6", "@babel/helper-create-regexp-features-plugin@^7.25.9":
-  version "7.26.3"
-  resolved "https://registry.npmjs.org/@babel/helper-create-regexp-features-plugin/-/helper-create-regexp-features-plugin-7.26.3.tgz"
-  integrity sha512-G7ZRb40uUgdKOQqPLjfD12ZmGA54PzqDFUv2BKImnC9QIfGhIHKvVML0oN8IUiDq4iRqpq74ABpvOaerfWdong==
+"@babel/helper-create-regexp-features-plugin@^7.18.6", "@babel/helper-create-regexp-features-plugin@^7.27.1", "@babel/helper-create-regexp-features-plugin@^7.28.5":
+  version "7.28.5"
+  resolved "https://registry.npmjs.org/@babel/helper-create-regexp-features-plugin/-/helper-create-regexp-features-plugin-7.28.5.tgz"
+  integrity sha512-N1EhvLtHzOvj7QQOUCCS3NrPJP8c5W6ZXCHDn7Yialuy1iu4r5EmIYkXlKNqT99Ciw+W0mDqWoR6HWMZlFP3hw==
   dependencies:
-    "@babel/helper-annotate-as-pure" "^7.25.9"
-    regexpu-core "^6.2.0"
+    "@babel/helper-annotate-as-pure" "^7.27.3"
+    regexpu-core "^6.3.1"
     semver "^6.3.1"
 
-"@babel/helper-define-polyfill-provider@^0.6.2", "@babel/helper-define-polyfill-provider@^0.6.3":
-  version "0.6.3"
-  resolved "https://registry.npmjs.org/@babel/helper-define-polyfill-provider/-/helper-define-polyfill-provider-0.6.3.tgz"
-  integrity sha512-HK7Bi+Hj6H+VTHA3ZvBis7V/6hu9QuTrnMXNybfUf2iiuU/N97I8VjB+KbhFF8Rld/Lx5MzoCwPCpPjfK+n8Cg==
+"@babel/helper-define-polyfill-provider@^0.6.5":
+  version "0.6.5"
+  resolved "https://registry.npmjs.org/@babel/helper-define-polyfill-provider/-/helper-define-polyfill-provider-0.6.5.tgz"
+  integrity sha512-uJnGFcPsWQK8fvjgGP5LZUZZsYGIoPeRjSF5PGwrelYgq7Q15/Ft9NGFp1zglwgIv//W0uG4BevRuSJRyylZPg==
   dependencies:
-    "@babel/helper-compilation-targets" "^7.22.6"
-    "@babel/helper-plugin-utils" "^7.22.5"
-    debug "^4.1.1"
+    "@babel/helper-compilation-targets" "^7.27.2"
+    "@babel/helper-plugin-utils" "^7.27.1"
+    debug "^4.4.1"
     lodash.debounce "^4.0.8"
-    resolve "^1.14.2"
-
-"@babel/helper-member-expression-to-functions@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/helper-member-expression-to-functions/-/helper-member-expression-to-functions-7.25.9.tgz"
-  integrity sha512-wbfdZ9w5vk0C0oyHqAJbc62+vet5prjj01jjJ8sKn3j9h3MQQlflEdXYvuqRWjHnM12coDEqiC1IRCi0U/EKwQ==
-  dependencies:
-    "@babel/traverse" "^7.25.9"
-    "@babel/types" "^7.25.9"
-
-"@babel/helper-module-imports@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/helper-module-imports/-/helper-module-imports-7.25.9.tgz"
-  integrity sha512-tnUA4RsrmflIM6W6RFTLFSXITtl0wKjgpnLgXyowocVPrbYrLUXSBXDgTs8BlbmIzIdlBySRQjINYs2BAkiLtw==
-  dependencies:
-    "@babel/traverse" "^7.25.9"
-    "@babel/types" "^7.25.9"
-
-"@babel/helper-module-transforms@^7.25.9", "@babel/helper-module-transforms@^7.26.0":
-  version "7.26.0"
-  resolved "https://registry.npmjs.org/@babel/helper-module-transforms/-/helper-module-transforms-7.26.0.tgz"
-  integrity sha512-xO+xu6B5K2czEnQye6BHA7DolFFmS3LB7stHZFaOLb1pAwO1HWLS8fXA+eh0A2yIvltPVmx3eNNDBJA2SLHXFw==
-  dependencies:
-    "@babel/helper-module-imports" "^7.25.9"
-    "@babel/helper-validator-identifier" "^7.25.9"
-    "@babel/traverse" "^7.25.9"
-
-"@babel/helper-optimise-call-expression@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/helper-optimise-call-expression/-/helper-optimise-call-expression-7.25.9.tgz"
-  integrity sha512-FIpuNaz5ow8VyrYcnXQTDRGvV6tTjkNtCK/RYNDXGSLlUD6cBuQTSw43CShGxjvfBTfcUA/r6UhUCbtYqkhcuQ==
-  dependencies:
-    "@babel/types" "^7.25.9"
-
-"@babel/helper-plugin-utils@^7.0.0", "@babel/helper-plugin-utils@^7.18.6", "@babel/helper-plugin-utils@^7.22.5", "@babel/helper-plugin-utils@^7.25.9", "@babel/helper-plugin-utils@^7.26.5", "@babel/helper-plugin-utils@^7.8.0":
-  version "7.26.5"
-  resolved "https://registry.npmjs.org/@babel/helper-plugin-utils/-/helper-plugin-utils-7.26.5.tgz"
-  integrity sha512-RS+jZcRdZdRFzMyr+wcsaqOmld1/EqTghfaBGQQd/WnRdzdlvSZ//kF7U8VQTxf1ynZ4cjUcYgjVGx13ewNPMg==
-
-"@babel/helper-remap-async-to-generator@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/helper-remap-async-to-generator/-/helper-remap-async-to-generator-7.25.9.tgz"
-  integrity sha512-IZtukuUeBbhgOcaW2s06OXTzVNJR0ybm4W5xC1opWFFJMZbwRj5LCk+ByYH7WdZPZTt8KnFwA8pvjN2yqcPlgw==
-  dependencies:
-    "@babel/helper-annotate-as-pure" "^7.25.9"
-    "@babel/helper-wrap-function" "^7.25.9"
-    "@babel/traverse" "^7.25.9"
-
-"@babel/helper-replace-supers@^7.25.9":
-  version "7.26.5"
-  resolved "https://registry.npmjs.org/@babel/helper-replace-supers/-/helper-replace-supers-7.26.5.tgz"
-  integrity sha512-bJ6iIVdYX1YooY2X7w1q6VITt+LnUILtNk7zT78ykuwStx8BauCzxvFqFaHjOpW1bVnSUM1PN1f0p5P21wHxvg==
-  dependencies:
-    "@babel/helper-member-expression-to-functions" "^7.25.9"
-    "@babel/helper-optimise-call-expression" "^7.25.9"
-    "@babel/traverse" "^7.26.5"
-
-"@babel/helper-skip-transparent-expression-wrappers@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/helper-skip-transparent-expression-wrappers/-/helper-skip-transparent-expression-wrappers-7.25.9.tgz"
-  integrity sha512-K4Du3BFa3gvyhzgPcntrkDgZzQaq6uozzcpGbOO1OEJaI+EJdqWIMTLgFgQf6lrfiDFo5FU+BxKepI9RmZqahA==
-  dependencies:
-    "@babel/traverse" "^7.25.9"
-    "@babel/types" "^7.25.9"
-
-"@babel/helper-string-parser@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/helper-string-parser/-/helper-string-parser-7.25.9.tgz"
-  integrity sha512-4A/SCr/2KLd5jrtOMFzaKjVtAei3+2r/NChoBNoZ3EyP/+GlhoaEGoWOZUmFmoITP7zOJyHIMm+DYRd8o3PvHA==
+    resolve "^1.22.10"
+
+"@babel/helper-globals@^7.28.0":
+  version "7.28.0"
+  resolved "https://registry.npmjs.org/@babel/helper-globals/-/helper-globals-7.28.0.tgz"
+  integrity sha512-+W6cISkXFa1jXsDEdYA8HeevQT/FULhxzR99pxphltZcVaugps53THCeiWA8SguxxpSp3gKPiuYfSWopkLQ4hw==
+
+"@babel/helper-member-expression-to-functions@^7.28.5":
+  version "7.28.5"
+  resolved "https://registry.npmjs.org/@babel/helper-member-expression-to-functions/-/helper-member-expression-to-functions-7.28.5.tgz"
+  integrity sha512-cwM7SBRZcPCLgl8a7cY0soT1SptSzAlMH39vwiRpOQkJlh53r5hdHwLSCZpQdVLT39sZt+CRpNwYG4Y2v77atg==
+  dependencies:
+    "@babel/traverse" "^7.28.5"
+    "@babel/types" "^7.28.5"
+
+"@babel/helper-module-imports@^7.27.1", "@babel/helper-module-imports@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/helper-module-imports/-/helper-module-imports-7.28.6.tgz"
+  integrity sha512-l5XkZK7r7wa9LucGw9LwZyyCUscb4x37JWTPz7swwFE/0FMQAGpiWUZn8u9DzkSBWEcK25jmvubfpw2dnAMdbw==
+  dependencies:
+    "@babel/traverse" "^7.28.6"
+    "@babel/types" "^7.28.6"
+
+"@babel/helper-module-transforms@^7.27.1", "@babel/helper-module-transforms@^7.28.3", "@babel/helper-module-transforms@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/helper-module-transforms/-/helper-module-transforms-7.28.6.tgz"
+  integrity sha512-67oXFAYr2cDLDVGLXTEABjdBJZ6drElUSI7WKp70NrpyISso3plG9SAGEF6y7zbha/wOzUByWWTJvEDVNIUGcA==
+  dependencies:
+    "@babel/helper-module-imports" "^7.28.6"
+    "@babel/helper-validator-identifier" "^7.28.5"
+    "@babel/traverse" "^7.28.6"
+
+"@babel/helper-optimise-call-expression@^7.27.1":
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/helper-optimise-call-expression/-/helper-optimise-call-expression-7.27.1.tgz"
+  integrity sha512-URMGH08NzYFhubNSGJrpUEphGKQwMQYBySzat5cAByY1/YgIRkULnIy3tAMeszlL/so2HbeilYloUmSpd7GdVw==
+  dependencies:
+    "@babel/types" "^7.27.1"
+
+"@babel/helper-plugin-utils@^7.0.0", "@babel/helper-plugin-utils@^7.18.6", "@babel/helper-plugin-utils@^7.27.1", "@babel/helper-plugin-utils@^7.28.6", "@babel/helper-plugin-utils@^7.8.0":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/helper-plugin-utils/-/helper-plugin-utils-7.28.6.tgz"
+  integrity sha512-S9gzZ/bz83GRysI7gAD4wPT/AI3uCnY+9xn+Mx/KPs2JwHJIz1W8PZkg2cqyt3RNOBM8ejcXhV6y8Og7ly/Dug==
+
+"@babel/helper-remap-async-to-generator@^7.27.1":
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/helper-remap-async-to-generator/-/helper-remap-async-to-generator-7.27.1.tgz"
+  integrity sha512-7fiA521aVw8lSPeI4ZOD3vRFkoqkJcS+z4hFo82bFSH/2tNd6eJ5qCVMS5OzDmZh/kaHQeBaeyxK6wljcPtveA==
+  dependencies:
+    "@babel/helper-annotate-as-pure" "^7.27.1"
+    "@babel/helper-wrap-function" "^7.27.1"
+    "@babel/traverse" "^7.27.1"
+
+"@babel/helper-replace-supers@^7.27.1", "@babel/helper-replace-supers@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/helper-replace-supers/-/helper-replace-supers-7.28.6.tgz"
+  integrity sha512-mq8e+laIk94/yFec3DxSjCRD2Z0TAjhVbEJY3UQrlwVo15Lmt7C2wAUbK4bjnTs4APkwsYLTahXRraQXhb1WCg==
+  dependencies:
+    "@babel/helper-member-expression-to-functions" "^7.28.5"
+    "@babel/helper-optimise-call-expression" "^7.27.1"
+    "@babel/traverse" "^7.28.6"
+
+"@babel/helper-skip-transparent-expression-wrappers@^7.27.1":
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/helper-skip-transparent-expression-wrappers/-/helper-skip-transparent-expression-wrappers-7.27.1.tgz"
+  integrity sha512-Tub4ZKEXqbPjXgWLl2+3JpQAYBJ8+ikpQ2Ocj/q/r0LwE3UhENh7EUabyHjz2kCEsrRY83ew2DQdHluuiDQFzg==
+  dependencies:
+    "@babel/traverse" "^7.27.1"
+    "@babel/types" "^7.27.1"
+
+"@babel/helper-string-parser@^7.27.1":
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/helper-string-parser/-/helper-string-parser-7.27.1.tgz"
+  integrity sha512-qMlSxKbpRlAridDExk92nSobyDdpPijUq2DW6oDnUqd0iOGxmQjyqhMIihI9+zv4LPyZdRje2cavWPbCbWm3eA==
+
+"@babel/helper-validator-identifier@^7.28.5":
+  version "7.28.5"
+  resolved "https://registry.npmjs.org/@babel/helper-validator-identifier/-/helper-validator-identifier-7.28.5.tgz"
+  integrity sha512-qSs4ifwzKJSV39ucNjsvc6WVHs6b7S03sOh2OcHF9UHfVPqWWALUsNUVzhSBiItjRZoLHx7nIarVjqKVusUZ1Q==
+
+"@babel/helper-validator-option@^7.27.1":
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/helper-validator-option/-/helper-validator-option-7.27.1.tgz"
+  integrity sha512-YvjJow9FxbhFFKDSuFnVCe2WxXk1zWc22fFePVNEaWJEu8IrZVlda6N0uHwzZrUM1il7NC9Mlp4MaJYbYd9JSg==
+
+"@babel/helper-wrap-function@^7.27.1":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/helper-wrap-function/-/helper-wrap-function-7.28.6.tgz"
+  integrity sha512-z+PwLziMNBeSQJonizz2AGnndLsP2DeGHIxDAn+wdHOGuo4Fo1x1HBPPXeE9TAOPHNNWQKCSlA2VZyYyyibDnQ==
+  dependencies:
+    "@babel/template" "^7.28.6"
+    "@babel/traverse" "^7.28.6"
+    "@babel/types" "^7.28.6"
+
+"@babel/helpers@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/helpers/-/helpers-7.28.6.tgz"
+  integrity sha512-xOBvwq86HHdB7WUDTfKfT/Vuxh7gElQ+Sfti2Cy6yIWNW05P8iUslOVcZ4/sKbE+/jQaukQAdz/gf3724kYdqw==
+  dependencies:
+    "@babel/template" "^7.28.6"
+    "@babel/types" "^7.28.6"
 
-"@babel/helper-validator-identifier@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/helper-validator-identifier/-/helper-validator-identifier-7.25.9.tgz"
-  integrity sha512-Ed61U6XJc3CVRfkERJWDz4dJwKe7iLmmJsbOGu9wSloNSFttHV0I8g6UAgb7qnK5ly5bGLPd4oXZlxCdANBOWQ==
-
-"@babel/helper-validator-option@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/helper-validator-option/-/helper-validator-option-7.25.9.tgz"
-  integrity sha512-e/zv1co8pp55dNdEcCynfj9X7nyUKUXoUEwfXqaZt0omVOmDe9oOTdKStH4GmAw6zxMFs50ZayuMfHDKlO7Tfw==
-
-"@babel/helper-wrap-function@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/helper-wrap-function/-/helper-wrap-function-7.25.9.tgz"
-  integrity sha512-ETzz9UTjQSTmw39GboatdymDq4XIQbR8ySgVrylRhPOFpsd+JrKHIuF0de7GCWmem+T4uC5z7EZguod7Wj4A4g==
-  dependencies:
-    "@babel/template" "^7.25.9"
-    "@babel/traverse" "^7.25.9"
-    "@babel/types" "^7.25.9"
-
-"@babel/helpers@^7.26.0":
-  version "7.26.0"
-  resolved "https://registry.npmjs.org/@babel/helpers/-/helpers-7.26.0.tgz"
-  integrity sha512-tbhNuIxNcVb21pInl3ZSjksLCvgdZy9KwJ8brv993QtIVKJBBkYXz4q4ZbAv31GdnC+R90np23L5FbEBlthAEw==
-  dependencies:
-    "@babel/template" "^7.25.9"
-    "@babel/types" "^7.26.0"
-
-"@babel/parser@^7.25.9", "@babel/parser@^7.26.0", "@babel/parser@^7.26.5":
-  version "7.26.5"
-  resolved "https://registry.npmjs.org/@babel/parser/-/parser-7.26.5.tgz"
-  integrity sha512-SRJ4jYmXRqV1/Xc+TIVG84WjHBXKlxO9sHQnA2Pf12QQEAp1LOh6kDzNHXcUnbH1QI0FDoPPVOt+vyUDucxpaw==
-  dependencies:
-    "@babel/types" "^7.26.5"
-
-"@babel/plugin-bugfix-firefox-class-in-computed-class-key@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-bugfix-firefox-class-in-computed-class-key/-/plugin-bugfix-firefox-class-in-computed-class-key-7.25.9.tgz"
-  integrity sha512-ZkRyVkThtxQ/J6nv3JFYv1RYY+JT5BvU0y3k5bWrmuG4woXypRa4PXmm9RhOwodRkYFWqC0C0cqcJ4OqR7kW+g==
-  dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
-    "@babel/traverse" "^7.25.9"
-
-"@babel/plugin-bugfix-safari-class-field-initializer-scope@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-bugfix-safari-class-field-initializer-scope/-/plugin-bugfix-safari-class-field-initializer-scope-7.25.9.tgz"
-  integrity sha512-MrGRLZxLD/Zjj0gdU15dfs+HH/OXvnw/U4jJD8vpcP2CJQapPEv1IWwjc/qMg7ItBlPwSv1hRBbb7LeuANdcnw==
+"@babel/parser@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/parser/-/parser-7.28.6.tgz"
+  integrity sha512-TeR9zWR18BvbfPmGbLampPMW+uW1NZnJlRuuHso8i87QZNq2JRF9i6RgxRqtEq+wQGsS19NNTWr2duhnE49mfQ==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
-
-"@babel/plugin-bugfix-safari-id-destructuring-collision-in-function-expression@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-bugfix-safari-id-destructuring-collision-in-function-expression/-/plugin-bugfix-safari-id-destructuring-collision-in-function-expression-7.25.9.tgz"
-  integrity sha512-2qUwwfAFpJLZqxd02YW9btUCZHl+RFvdDkNfZwaIJrvB8Tesjsk8pEQkTvGwZXLqXUx/2oyY3ySRhm6HOXuCug==
+    "@babel/types" "^7.28.6"
+
+"@babel/plugin-bugfix-firefox-class-in-computed-class-key@^7.28.5":
+  version "7.28.5"
+  resolved "https://registry.npmjs.org/@babel/plugin-bugfix-firefox-class-in-computed-class-key/-/plugin-bugfix-firefox-class-in-computed-class-key-7.28.5.tgz"
+  integrity sha512-87GDMS3tsmMSi/3bWOte1UblL+YUTFMV8SZPZ2eSEL17s74Cw/l63rR6NmGVKMYW2GYi85nE+/d6Hw5N0bEk2Q==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
-
-"@babel/plugin-bugfix-v8-spread-parameters-in-optional-chaining@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-bugfix-v8-spread-parameters-in-optional-chaining/-/plugin-bugfix-v8-spread-parameters-in-optional-chaining-7.25.9.tgz"
-  integrity sha512-6xWgLZTJXwilVjlnV7ospI3xi+sl8lN8rXXbBD6vYn3UYDlGsag8wrZkKcSI8G6KgqKP7vNFaDgeDnfAABq61g==
+    "@babel/helper-plugin-utils" "^7.27.1"
+    "@babel/traverse" "^7.28.5"
+
+"@babel/plugin-bugfix-safari-class-field-initializer-scope@^7.27.1":
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/plugin-bugfix-safari-class-field-initializer-scope/-/plugin-bugfix-safari-class-field-initializer-scope-7.27.1.tgz"
+  integrity sha512-qNeq3bCKnGgLkEXUuFry6dPlGfCdQNZbn7yUAPCInwAJHMU7THJfrBSozkcWq5sNM6RcF3S8XyQL2A52KNR9IA==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
-    "@babel/helper-skip-transparent-expression-wrappers" "^7.25.9"
-    "@babel/plugin-transform-optional-chaining" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.27.1"
+
+"@babel/plugin-bugfix-safari-id-destructuring-collision-in-function-expression@^7.27.1":
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/plugin-bugfix-safari-id-destructuring-collision-in-function-expression/-/plugin-bugfix-safari-id-destructuring-collision-in-function-expression-7.27.1.tgz"
+  integrity sha512-g4L7OYun04N1WyqMNjldFwlfPCLVkgB54A/YCXICZYBsvJJE3kByKv9c9+R/nAfmIfjl2rKYLNyMHboYbZaWaA==
+  dependencies:
+    "@babel/helper-plugin-utils" "^7.27.1"
 
-"@babel/plugin-bugfix-v8-static-class-fields-redefine-readonly@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-bugfix-v8-static-class-fields-redefine-readonly/-/plugin-bugfix-v8-static-class-fields-redefine-readonly-7.25.9.tgz"
-  integrity sha512-aLnMXYPnzwwqhYSCyXfKkIkYgJ8zv9RK+roo9DkTXz38ynIhd9XCbN08s3MGvqL2MYGVUGdRQLL/JqBIeJhJBg==
+"@babel/plugin-bugfix-v8-spread-parameters-in-optional-chaining@^7.27.1":
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/plugin-bugfix-v8-spread-parameters-in-optional-chaining/-/plugin-bugfix-v8-spread-parameters-in-optional-chaining-7.27.1.tgz"
+  integrity sha512-oO02gcONcD5O1iTLi/6frMJBIwWEHceWGSGqrpCmEL8nogiS6J9PBlE48CaK20/Jx1LuRml9aDftLgdjXT8+Cw==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
-    "@babel/traverse" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.27.1"
+    "@babel/helper-skip-transparent-expression-wrappers" "^7.27.1"
+    "@babel/plugin-transform-optional-chaining" "^7.27.1"
+
+"@babel/plugin-bugfix-v8-static-class-fields-redefine-readonly@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-bugfix-v8-static-class-fields-redefine-readonly/-/plugin-bugfix-v8-static-class-fields-redefine-readonly-7.28.6.tgz"
+  integrity sha512-a0aBScVTlNaiUe35UtfxAN7A/tehvvG4/ByO6+46VPKTRSlfnAFsgKy0FUh+qAkQrDTmhDkT+IBOKlOoMUxQ0g==
+  dependencies:
+    "@babel/helper-plugin-utils" "^7.28.6"
+    "@babel/traverse" "^7.28.6"
 
 "@babel/plugin-proposal-private-property-in-object@7.21.0-placeholder-for-preset-env.2":
   version "7.21.0-placeholder-for-preset-env.2"
@@ -408,33 +443,33 @@
   dependencies:
     "@babel/helper-plugin-utils" "^7.8.0"
 
-"@babel/plugin-syntax-import-assertions@^7.26.0":
-  version "7.26.0"
-  resolved "https://registry.npmjs.org/@babel/plugin-syntax-import-assertions/-/plugin-syntax-import-assertions-7.26.0.tgz"
-  integrity sha512-QCWT5Hh830hK5EQa7XzuqIkQU9tT/whqbDz7kuaZMHFl1inRRg7JnuAEOQ0Ur0QUl0NufCk1msK2BeY79Aj/eg==
+"@babel/plugin-syntax-import-assertions@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-syntax-import-assertions/-/plugin-syntax-import-assertions-7.28.6.tgz"
+  integrity sha512-pSJUpFHdx9z5nqTSirOCMtYVP2wFgoWhP0p3g8ONK/4IHhLIBd0B9NYqAvIUAhq+OkhO4VM1tENCt0cjlsNShw==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.28.6"
 
-"@babel/plugin-syntax-import-attributes@^7.26.0":
-  version "7.26.0"
-  resolved "https://registry.npmjs.org/@babel/plugin-syntax-import-attributes/-/plugin-syntax-import-attributes-7.26.0.tgz"
-  integrity sha512-e2dttdsJ1ZTpi3B9UYGLw41hifAubg19AtCu/2I/F1QNVclOBr1dYpTdmdyZ84Xiz43BS/tCUkMAZNLv12Pi+A==
+"@babel/plugin-syntax-import-attributes@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-syntax-import-attributes/-/plugin-syntax-import-attributes-7.28.6.tgz"
+  integrity sha512-jiLC0ma9XkQT3TKJ9uYvlakm66Pamywo+qwL+oL8HJOvc6TWdZXVfhqJr8CCzbSGUAbDOzlGHJC1U+vRfLQDvw==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.28.6"
 
-"@babel/plugin-syntax-jsx@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-syntax-jsx/-/plugin-syntax-jsx-7.25.9.tgz"
-  integrity sha512-ld6oezHQMZsZfp6pWtbjaNDF2tiiCYYDqQszHt5VV437lewP9aSi2Of99CK0D0XB21k7FLgnLcmQKyKzynfeAA==
+"@babel/plugin-syntax-jsx@^7.27.1", "@babel/plugin-syntax-jsx@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-syntax-jsx/-/plugin-syntax-jsx-7.28.6.tgz"
+  integrity sha512-wgEmr06G6sIpqr8YDwA2dSRTE3bJ+V0IfpzfSY3Lfgd7YWOaAdlykvJi13ZKBt8cZHfgH1IXN+CL656W3uUa4w==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.28.6"
 
-"@babel/plugin-syntax-typescript@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-syntax-typescript/-/plugin-syntax-typescript-7.25.9.tgz"
-  integrity sha512-hjMgRy5hb8uJJjUcdWunWVcoi9bGpJp8p5Ol1229PoN6aytsLwNMgmdftO23wnCLMfVmTwZDWMPNq/D1SY60JQ==
+"@babel/plugin-syntax-typescript@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-syntax-typescript/-/plugin-syntax-typescript-7.28.6.tgz"
+  integrity sha512-+nDNmQye7nlnuuHDboPbGm00Vqg3oO8niRRL27/4LYHUsHYh0zJ1xWOz0uRwNFmM1Avzk8wZbc6rdiYhomzv/A==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.28.6"
 
 "@babel/plugin-syntax-unicode-sets-regex@^7.18.6":
   version "7.18.6"
@@ -444,529 +479,540 @@
     "@babel/helper-create-regexp-features-plugin" "^7.18.6"
     "@babel/helper-plugin-utils" "^7.18.6"
 
-"@babel/plugin-transform-arrow-functions@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-arrow-functions/-/plugin-transform-arrow-functions-7.25.9.tgz"
-  integrity sha512-6jmooXYIwn9ca5/RylZADJ+EnSxVUS5sjeJ9UPk6RWRzXCmOJCy6dqItPJFpw2cuCangPK4OYr5uhGKcmrm5Qg==
+"@babel/plugin-transform-arrow-functions@^7.27.1":
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-arrow-functions/-/plugin-transform-arrow-functions-7.27.1.tgz"
+  integrity sha512-8Z4TGic6xW70FKThA5HYEKKyBpOOsucTOD1DjU3fZxDg+K3zBJcXMFnt/4yQiZnf5+MiOMSXQ9PaEK/Ilh1DeA==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.27.1"
 
-"@babel/plugin-transform-async-generator-functions@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-async-generator-functions/-/plugin-transform-async-generator-functions-7.25.9.tgz"
-  integrity sha512-RXV6QAzTBbhDMO9fWwOmwwTuYaiPbggWQ9INdZqAYeSHyG7FzQ+nOZaUUjNwKv9pV3aE4WFqFm1Hnbci5tBCAw==
+"@babel/plugin-transform-async-generator-functions@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-async-generator-functions/-/plugin-transform-async-generator-functions-7.28.6.tgz"
+  integrity sha512-9knsChgsMzBV5Yh3kkhrZNxH3oCYAfMBkNNaVN4cP2RVlFPe8wYdwwcnOsAbkdDoV9UjFtOXWrWB52M8W4jNeA==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
-    "@babel/helper-remap-async-to-generator" "^7.25.9"
-    "@babel/traverse" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.28.6"
+    "@babel/helper-remap-async-to-generator" "^7.27.1"
+    "@babel/traverse" "^7.28.6"
 
-"@babel/plugin-transform-async-to-generator@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-async-to-generator/-/plugin-transform-async-to-generator-7.25.9.tgz"
-  integrity sha512-NT7Ejn7Z/LjUH0Gv5KsBCxh7BH3fbLTV0ptHvpeMvrt3cPThHfJfst9Wrb7S8EvJ7vRTFI7z+VAvFVEQn/m5zQ==
+"@babel/plugin-transform-async-to-generator@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-async-to-generator/-/plugin-transform-async-to-generator-7.28.6.tgz"
+  integrity sha512-ilTRcmbuXjsMmcZ3HASTe4caH5Tpo93PkTxF9oG2VZsSWsahydmcEHhix9Ik122RcTnZnUzPbmux4wh1swfv7g==
   dependencies:
-    "@babel/helper-module-imports" "^7.25.9"
-    "@babel/helper-plugin-utils" "^7.25.9"
-    "@babel/helper-remap-async-to-generator" "^7.25.9"
+    "@babel/helper-module-imports" "^7.28.6"
+    "@babel/helper-plugin-utils" "^7.28.6"
+    "@babel/helper-remap-async-to-generator" "^7.27.1"
 
-"@babel/plugin-transform-block-scoped-functions@^7.25.9":
-  version "7.26.5"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-block-scoped-functions/-/plugin-transform-block-scoped-functions-7.26.5.tgz"
-  integrity sha512-chuTSY+hq09+/f5lMj8ZSYgCFpppV2CbYrhNFJ1BFoXpiWPnnAb7R0MqrafCpN8E1+YRrtM1MXZHJdIx8B6rMQ==
+"@babel/plugin-transform-block-scoped-functions@^7.27.1":
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-block-scoped-functions/-/plugin-transform-block-scoped-functions-7.27.1.tgz"
+  integrity sha512-cnqkuOtZLapWYZUYM5rVIdv1nXYuFVIltZ6ZJ7nIj585QsjKM5dhL2Fu/lICXZ1OyIAFc7Qy+bvDAtTXqGrlhg==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.26.5"
+    "@babel/helper-plugin-utils" "^7.27.1"
 
-"@babel/plugin-transform-block-scoping@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-block-scoping/-/plugin-transform-block-scoping-7.25.9.tgz"
-  integrity sha512-1F05O7AYjymAtqbsFETboN1NvBdcnzMerO+zlMyJBEz6WkMdejvGWw9p05iTSjC85RLlBseHHQpYaM4gzJkBGg==
+"@babel/plugin-transform-block-scoping@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-block-scoping/-/plugin-transform-block-scoping-7.28.6.tgz"
+  integrity sha512-tt/7wOtBmwHPNMPu7ax4pdPz6shjFrmHDghvNC+FG9Qvj7D6mJcoRQIF5dy4njmxR941l6rgtvfSB2zX3VlUIw==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.28.6"
 
-"@babel/plugin-transform-class-properties@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-class-properties/-/plugin-transform-class-properties-7.25.9.tgz"
-  integrity sha512-bbMAII8GRSkcd0h0b4X+36GksxuheLFjP65ul9w6C3KgAamI3JqErNgSrosX6ZPj+Mpim5VvEbawXxJCyEUV3Q==
+"@babel/plugin-transform-class-properties@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-class-properties/-/plugin-transform-class-properties-7.28.6.tgz"
+  integrity sha512-dY2wS3I2G7D697VHndN91TJr8/AAfXQNt5ynCTI/MpxMsSzHp+52uNivYT5wCPax3whc47DR8Ba7cmlQMg24bw==
   dependencies:
-    "@babel/helper-create-class-features-plugin" "^7.25.9"
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-create-class-features-plugin" "^7.28.6"
+    "@babel/helper-plugin-utils" "^7.28.6"
 
-"@babel/plugin-transform-class-static-block@^7.26.0":
-  version "7.26.0"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-class-static-block/-/plugin-transform-class-static-block-7.26.0.tgz"
-  integrity sha512-6J2APTs7BDDm+UMqP1useWqhcRAXo0WIoVj26N7kPFB6S73Lgvyka4KTZYIxtgYXiN5HTyRObA72N2iu628iTQ==
+"@babel/plugin-transform-class-static-block@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-class-static-block/-/plugin-transform-class-static-block-7.28.6.tgz"
+  integrity sha512-rfQ++ghVwTWTqQ7w8qyDxL1XGihjBss4CmTgGRCTAC9RIbhVpyp4fOeZtta0Lbf+dTNIVJer6ych2ibHwkZqsQ==
   dependencies:
-    "@babel/helper-create-class-features-plugin" "^7.25.9"
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-create-class-features-plugin" "^7.28.6"
+    "@babel/helper-plugin-utils" "^7.28.6"
 
-"@babel/plugin-transform-classes@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-classes/-/plugin-transform-classes-7.25.9.tgz"
-  integrity sha512-mD8APIXmseE7oZvZgGABDyM34GUmK45Um2TXiBUt7PnuAxrgoSVf123qUzPxEr/+/BHrRn5NMZCdE2m/1F8DGg==
+"@babel/plugin-transform-classes@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-classes/-/plugin-transform-classes-7.28.6.tgz"
+  integrity sha512-EF5KONAqC5zAqT783iMGuM2ZtmEBy+mJMOKl2BCvPZ2lVrwvXnB6o+OBWCS+CoeCCpVRF2sA2RBKUxvT8tQT5Q==
   dependencies:
-    "@babel/helper-annotate-as-pure" "^7.25.9"
-    "@babel/helper-compilation-targets" "^7.25.9"
-    "@babel/helper-plugin-utils" "^7.25.9"
-    "@babel/helper-replace-supers" "^7.25.9"
-    "@babel/traverse" "^7.25.9"
-    globals "^11.1.0"
+    "@babel/helper-annotate-as-pure" "^7.27.3"
+    "@babel/helper-compilation-targets" "^7.28.6"
+    "@babel/helper-globals" "^7.28.0"
+    "@babel/helper-plugin-utils" "^7.28.6"
+    "@babel/helper-replace-supers" "^7.28.6"
+    "@babel/traverse" "^7.28.6"
 
-"@babel/plugin-transform-computed-properties@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-computed-properties/-/plugin-transform-computed-properties-7.25.9.tgz"
-  integrity sha512-HnBegGqXZR12xbcTHlJ9HGxw1OniltT26J5YpfruGqtUHlz/xKf/G2ak9e+t0rVqrjXa9WOhvYPz1ERfMj23AA==
+"@babel/plugin-transform-computed-properties@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-computed-properties/-/plugin-transform-computed-properties-7.28.6.tgz"
+  integrity sha512-bcc3k0ijhHbc2lEfpFHgx7eYw9KNXqOerKWfzbxEHUGKnS3sz9C4CNL9OiFN1297bDNfUiSO7DaLzbvHQQQ1BQ==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
-    "@babel/template" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.28.6"
+    "@babel/template" "^7.28.6"
 
-"@babel/plugin-transform-destructuring@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-destructuring/-/plugin-transform-destructuring-7.25.9.tgz"
-  integrity sha512-WkCGb/3ZxXepmMiX101nnGiU+1CAdut8oHyEOHxkKuS1qKpU2SMXE2uSvfz8PBuLd49V6LEsbtyPhWC7fnkgvQ==
+"@babel/plugin-transform-destructuring@^7.28.5":
+  version "7.28.5"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-destructuring/-/plugin-transform-destructuring-7.28.5.tgz"
+  integrity sha512-Kl9Bc6D0zTUcFUvkNuQh4eGXPKKNDOJQXVyyM4ZAQPMveniJdxi8XMJwLo+xSoW3MIq81bD33lcUe9kZpl0MCw==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.27.1"
+    "@babel/traverse" "^7.28.5"
 
-"@babel/plugin-transform-dotall-regex@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-dotall-regex/-/plugin-transform-dotall-regex-7.25.9.tgz"
-  integrity sha512-t7ZQ7g5trIgSRYhI9pIJtRl64KHotutUJsh4Eze5l7olJv+mRSg4/MmbZ0tv1eeqRbdvo/+trvJD/Oc5DmW2cA==
+"@babel/plugin-transform-dotall-regex@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-dotall-regex/-/plugin-transform-dotall-regex-7.28.6.tgz"
+  integrity sha512-SljjowuNKB7q5Oayv4FoPzeB74g3QgLt8IVJw9ADvWy3QnUb/01aw8I4AVv8wYnPvQz2GDDZ/g3GhcNyDBI4Bg==
   dependencies:
-    "@babel/helper-create-regexp-features-plugin" "^7.25.9"
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-create-regexp-features-plugin" "^7.28.5"
+    "@babel/helper-plugin-utils" "^7.28.6"
 
-"@babel/plugin-transform-duplicate-keys@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-duplicate-keys/-/plugin-transform-duplicate-keys-7.25.9.tgz"
-  integrity sha512-LZxhJ6dvBb/f3x8xwWIuyiAHy56nrRG3PeYTpBkkzkYRRQ6tJLu68lEF5VIqMUZiAV7a8+Tb78nEoMCMcqjXBw==
+"@babel/plugin-transform-duplicate-keys@^7.27.1":
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-duplicate-keys/-/plugin-transform-duplicate-keys-7.27.1.tgz"
+  integrity sha512-MTyJk98sHvSs+cvZ4nOauwTTG1JeonDjSGvGGUNHreGQns+Mpt6WX/dVzWBHgg+dYZhkC4X+zTDfkTU+Vy9y7Q==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.27.1"
 
-"@babel/plugin-transform-duplicate-named-capturing-groups-regex@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-duplicate-named-capturing-groups-regex/-/plugin-transform-duplicate-named-capturing-groups-regex-7.25.9.tgz"
-  integrity sha512-0UfuJS0EsXbRvKnwcLjFtJy/Sxc5J5jhLHnFhy7u4zih97Hz6tJkLU+O+FMMrNZrosUPxDi6sYxJ/EA8jDiAog==
+"@babel/plugin-transform-duplicate-named-capturing-groups-regex@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-duplicate-named-capturing-groups-regex/-/plugin-transform-duplicate-named-capturing-groups-regex-7.28.6.tgz"
+  integrity sha512-5suVoXjC14lUN6ZL9OLKIHCNVWCrqGqlmEp/ixdXjvgnEl/kauLvvMO/Xw9NyMc95Joj1AeLVPVMvibBgSoFlA==
   dependencies:
-    "@babel/helper-create-regexp-features-plugin" "^7.25.9"
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-create-regexp-features-plugin" "^7.28.5"
+    "@babel/helper-plugin-utils" "^7.28.6"
 
-"@babel/plugin-transform-dynamic-import@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-dynamic-import/-/plugin-transform-dynamic-import-7.25.9.tgz"
-  integrity sha512-GCggjexbmSLaFhqsojeugBpeaRIgWNTcgKVq/0qIteFEqY2A+b9QidYadrWlnbWQUrW5fn+mCvf3tr7OeBFTyg==
+"@babel/plugin-transform-dynamic-import@^7.27.1":
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-dynamic-import/-/plugin-transform-dynamic-import-7.27.1.tgz"
+  integrity sha512-MHzkWQcEmjzzVW9j2q8LGjwGWpG2mjwaaB0BNQwst3FIjqsg8Ct/mIZlvSPJvfi9y2AC8mi/ktxbFVL9pZ1I4A==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.27.1"
 
-"@babel/plugin-transform-exponentiation-operator@^7.25.9":
-  version "7.26.3"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-exponentiation-operator/-/plugin-transform-exponentiation-operator-7.26.3.tgz"
-  integrity sha512-7CAHcQ58z2chuXPWblnn1K6rLDnDWieghSOEmqQsrBenH0P9InCUtOJYD89pvngljmZlJcz3fcmgYsXFNGa1ZQ==
+"@babel/plugin-transform-explicit-resource-management@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-explicit-resource-management/-/plugin-transform-explicit-resource-management-7.28.6.tgz"
+  integrity sha512-Iao5Konzx2b6g7EPqTy40UZbcdXE126tTxVFr/nAIj+WItNxjKSYTEw3RC+A2/ZetmdJsgueL1KhaMCQHkLPIg==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.28.6"
+    "@babel/plugin-transform-destructuring" "^7.28.5"
 
-"@babel/plugin-transform-export-namespace-from@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-export-namespace-from/-/plugin-transform-export-namespace-from-7.25.9.tgz"
-  integrity sha512-2NsEz+CxzJIVOPx2o9UsW1rXLqtChtLoVnwYHHiB04wS5sgn7mrV45fWMBX0Kk+ub9uXytVYfNP2HjbVbCB3Ww==
+"@babel/plugin-transform-exponentiation-operator@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-exponentiation-operator/-/plugin-transform-exponentiation-operator-7.28.6.tgz"
+  integrity sha512-WitabqiGjV/vJ0aPOLSFfNY1u9U3R7W36B03r5I2KoNix+a3sOhJ3pKFB3R5It9/UiK78NiO0KE9P21cMhlPkw==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.28.6"
 
-"@babel/plugin-transform-for-of@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-for-of/-/plugin-transform-for-of-7.25.9.tgz"
-  integrity sha512-LqHxduHoaGELJl2uhImHwRQudhCM50pT46rIBNvtT/Oql3nqiS3wOwP+5ten7NpYSXrrVLgtZU3DZmPtWZo16A==
+"@babel/plugin-transform-export-namespace-from@^7.27.1":
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-export-namespace-from/-/plugin-transform-export-namespace-from-7.27.1.tgz"
+  integrity sha512-tQvHWSZ3/jH2xuq/vZDy0jNn+ZdXJeM8gHvX4lnJmsc3+50yPlWdZXIc5ay+umX+2/tJIqHqiEqcJvxlmIvRvQ==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
-    "@babel/helper-skip-transparent-expression-wrappers" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.27.1"
 
-"@babel/plugin-transform-function-name@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-function-name/-/plugin-transform-function-name-7.25.9.tgz"
-  integrity sha512-8lP+Yxjv14Vc5MuWBpJsoUCd3hD6V9DgBon2FVYL4jJgbnVQ9fTgYmonchzZJOVNgzEgbxp4OwAf6xz6M/14XA==
+"@babel/plugin-transform-for-of@^7.27.1":
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-for-of/-/plugin-transform-for-of-7.27.1.tgz"
+  integrity sha512-BfbWFFEJFQzLCQ5N8VocnCtA8J1CLkNTe2Ms2wocj75dd6VpiqS5Z5quTYcUoo4Yq+DN0rtikODccuv7RU81sw==
   dependencies:
-    "@babel/helper-compilation-targets" "^7.25.9"
-    "@babel/helper-plugin-utils" "^7.25.9"
-    "@babel/traverse" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.27.1"
+    "@babel/helper-skip-transparent-expression-wrappers" "^7.27.1"
 
-"@babel/plugin-transform-json-strings@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-json-strings/-/plugin-transform-json-strings-7.25.9.tgz"
-  integrity sha512-xoTMk0WXceiiIvsaquQQUaLLXSW1KJ159KP87VilruQm0LNNGxWzahxSS6T6i4Zg3ezp4vA4zuwiNUR53qmQAw==
+"@babel/plugin-transform-function-name@^7.27.1":
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-function-name/-/plugin-transform-function-name-7.27.1.tgz"
+  integrity sha512-1bQeydJF9Nr1eBCMMbC+hdwmRlsv5XYOMu03YSWFwNs0HsAmtSxxF1fyuYPqemVldVyFmlCU7w8UE14LupUSZQ==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-compilation-targets" "^7.27.1"
+    "@babel/helper-plugin-utils" "^7.27.1"
+    "@babel/traverse" "^7.27.1"
 
-"@babel/plugin-transform-literals@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-literals/-/plugin-transform-literals-7.25.9.tgz"
-  integrity sha512-9N7+2lFziW8W9pBl2TzaNht3+pgMIRP74zizeCSrtnSKVdUl8mAjjOP2OOVQAfZ881P2cNjDj1uAMEdeD50nuQ==
+"@babel/plugin-transform-json-strings@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-json-strings/-/plugin-transform-json-strings-7.28.6.tgz"
+  integrity sha512-Nr+hEN+0geQkzhbdgQVPoqr47lZbm+5fCUmO70722xJZd0Mvb59+33QLImGj6F+DkK3xgDi1YVysP8whD6FQAw==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.28.6"
 
-"@babel/plugin-transform-logical-assignment-operators@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-logical-assignment-operators/-/plugin-transform-logical-assignment-operators-7.25.9.tgz"
-  integrity sha512-wI4wRAzGko551Y8eVf6iOY9EouIDTtPb0ByZx+ktDGHwv6bHFimrgJM/2T021txPZ2s4c7bqvHbd+vXG6K948Q==
+"@babel/plugin-transform-literals@^7.27.1":
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-literals/-/plugin-transform-literals-7.27.1.tgz"
+  integrity sha512-0HCFSepIpLTkLcsi86GG3mTUzxV5jpmbv97hTETW3yzrAij8aqlD36toB1D0daVFJM8NK6GvKO0gslVQmm+zZA==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.27.1"
 
-"@babel/plugin-transform-member-expression-literals@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-member-expression-literals/-/plugin-transform-member-expression-literals-7.25.9.tgz"
-  integrity sha512-PYazBVfofCQkkMzh2P6IdIUaCEWni3iYEerAsRWuVd8+jlM1S9S9cz1dF9hIzyoZ8IA3+OwVYIp9v9e+GbgZhA==
+"@babel/plugin-transform-logical-assignment-operators@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-logical-assignment-operators/-/plugin-transform-logical-assignment-operators-7.28.6.tgz"
+  integrity sha512-+anKKair6gpi8VsM/95kmomGNMD0eLz1NQ8+Pfw5sAwWH9fGYXT50E55ZpV0pHUHWf6IUTWPM+f/7AAff+wr9A==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.28.6"
 
-"@babel/plugin-transform-modules-amd@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-modules-amd/-/plugin-transform-modules-amd-7.25.9.tgz"
-  integrity sha512-g5T11tnI36jVClQlMlt4qKDLlWnG5pP9CSM4GhdRciTNMRgkfpo5cR6b4rGIOYPgRRuFAvwjPQ/Yk+ql4dyhbw==
+"@babel/plugin-transform-member-expression-literals@^7.27.1":
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-member-expression-literals/-/plugin-transform-member-expression-literals-7.27.1.tgz"
+  integrity sha512-hqoBX4dcZ1I33jCSWcXrP+1Ku7kdqXf1oeah7ooKOIiAdKQ+uqftgCFNOSzA5AMS2XIHEYeGFg4cKRCdpxzVOQ==
   dependencies:
-    "@babel/helper-module-transforms" "^7.25.9"
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.27.1"
 
-"@babel/plugin-transform-modules-commonjs@^7.25.9":
-  version "7.26.3"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-modules-commonjs/-/plugin-transform-modules-commonjs-7.26.3.tgz"
-  integrity sha512-MgR55l4q9KddUDITEzEFYn5ZsGDXMSsU9E+kh7fjRXTIC3RHqfCo8RPRbyReYJh44HQ/yomFkqbOFohXvDCiIQ==
+"@babel/plugin-transform-modules-amd@^7.27.1":
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-modules-amd/-/plugin-transform-modules-amd-7.27.1.tgz"
+  integrity sha512-iCsytMg/N9/oFq6n+gFTvUYDZQOMK5kEdeYxmxt91fcJGycfxVP9CnrxoliM0oumFERba2i8ZtwRUCMhvP1LnA==
   dependencies:
-    "@babel/helper-module-transforms" "^7.26.0"
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-module-transforms" "^7.27.1"
+    "@babel/helper-plugin-utils" "^7.27.1"
 
-"@babel/plugin-transform-modules-systemjs@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-modules-systemjs/-/plugin-transform-modules-systemjs-7.25.9.tgz"
-  integrity sha512-hyss7iIlH/zLHaehT+xwiymtPOpsiwIIRlCAOwBB04ta5Tt+lNItADdlXw3jAWZ96VJ2jlhl/c+PNIQPKNfvcA==
+"@babel/plugin-transform-modules-commonjs@^7.27.1", "@babel/plugin-transform-modules-commonjs@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-modules-commonjs/-/plugin-transform-modules-commonjs-7.28.6.tgz"
+  integrity sha512-jppVbf8IV9iWWwWTQIxJMAJCWBuuKx71475wHwYytrRGQ2CWiDvYlADQno3tcYpS/T2UUWFQp3nVtYfK/YBQrA==
   dependencies:
-    "@babel/helper-module-transforms" "^7.25.9"
-    "@babel/helper-plugin-utils" "^7.25.9"
-    "@babel/helper-validator-identifier" "^7.25.9"
-    "@babel/traverse" "^7.25.9"
+    "@babel/helper-module-transforms" "^7.28.6"
+    "@babel/helper-plugin-utils" "^7.28.6"
+
+"@babel/plugin-transform-modules-systemjs@^7.28.5":
+  version "7.28.5"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-modules-systemjs/-/plugin-transform-modules-systemjs-7.28.5.tgz"
+  integrity sha512-vn5Jma98LCOeBy/KpeQhXcV2WZgaRUtjwQmjoBuLNlOmkg0fB5pdvYVeWRYI69wWKwK2cD1QbMiUQnoujWvrew==
+  dependencies:
+    "@babel/helper-module-transforms" "^7.28.3"
+    "@babel/helper-plugin-utils" "^7.27.1"
+    "@babel/helper-validator-identifier" "^7.28.5"
+    "@babel/traverse" "^7.28.5"
 
-"@babel/plugin-transform-modules-umd@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-modules-umd/-/plugin-transform-modules-umd-7.25.9.tgz"
-  integrity sha512-bS9MVObUgE7ww36HEfwe6g9WakQ0KF07mQF74uuXdkoziUPfKyu/nIm663kz//e5O1nPInPFx36z7WJmJ4yNEw==
+"@babel/plugin-transform-modules-umd@^7.27.1":
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-modules-umd/-/plugin-transform-modules-umd-7.27.1.tgz"
+  integrity sha512-iQBE/xC5BV1OxJbp6WG7jq9IWiD+xxlZhLrdwpPkTX3ydmXdvoCpyfJN7acaIBZaOqTfr76pgzqBJflNbeRK+w==
   dependencies:
-    "@babel/helper-module-transforms" "^7.25.9"
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-module-transforms" "^7.27.1"
+    "@babel/helper-plugin-utils" "^7.27.1"
 
-"@babel/plugin-transform-named-capturing-groups-regex@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-named-capturing-groups-regex/-/plugin-transform-named-capturing-groups-regex-7.25.9.tgz"
-  integrity sha512-oqB6WHdKTGl3q/ItQhpLSnWWOpjUJLsOCLVyeFgeTktkBSCiurvPOsyt93gibI9CmuKvTUEtWmG5VhZD+5T/KA==
+"@babel/plugin-transform-named-capturing-groups-regex@^7.27.1":
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-named-capturing-groups-regex/-/plugin-transform-named-capturing-groups-regex-7.27.1.tgz"
+  integrity sha512-SstR5JYy8ddZvD6MhV0tM/j16Qds4mIpJTOd1Yu9J9pJjH93bxHECF7pgtc28XvkzTD6Pxcm/0Z73Hvk7kb3Ng==
   dependencies:
-    "@babel/helper-create-regexp-features-plugin" "^7.25.9"
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-create-regexp-features-plugin" "^7.27.1"
+    "@babel/helper-plugin-utils" "^7.27.1"
 
-"@babel/plugin-transform-new-target@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-new-target/-/plugin-transform-new-target-7.25.9.tgz"
-  integrity sha512-U/3p8X1yCSoKyUj2eOBIx3FOn6pElFOKvAAGf8HTtItuPyB+ZeOqfn+mvTtg9ZlOAjsPdK3ayQEjqHjU/yLeVQ==
+"@babel/plugin-transform-new-target@^7.27.1":
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-new-target/-/plugin-transform-new-target-7.27.1.tgz"
+  integrity sha512-f6PiYeqXQ05lYq3TIfIDu/MtliKUbNwkGApPUvyo6+tc7uaR4cPjPe7DFPr15Uyycg2lZU6btZ575CuQoYh7MQ==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.27.1"
 
-"@babel/plugin-transform-nullish-coalescing-operator@^7.25.9":
-  version "7.26.6"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-nullish-coalescing-operator/-/plugin-transform-nullish-coalescing-operator-7.26.6.tgz"
-  integrity sha512-CKW8Vu+uUZneQCPtXmSBUC6NCAUdya26hWCElAWh5mVSlSRsmiCPUUDKb3Z0szng1hiAJa098Hkhg9o4SE35Qw==
+"@babel/plugin-transform-nullish-coalescing-operator@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-nullish-coalescing-operator/-/plugin-transform-nullish-coalescing-operator-7.28.6.tgz"
+  integrity sha512-3wKbRgmzYbw24mDJXT7N+ADXw8BC/imU9yo9c9X9NKaLF1fW+e5H1U5QjMUBe4Qo4Ox/o++IyUkl1sVCLgevKg==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.26.5"
+    "@babel/helper-plugin-utils" "^7.28.6"
 
-"@babel/plugin-transform-numeric-separator@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-numeric-separator/-/plugin-transform-numeric-separator-7.25.9.tgz"
-  integrity sha512-TlprrJ1GBZ3r6s96Yq8gEQv82s8/5HnCVHtEJScUj90thHQbwe+E5MLhi2bbNHBEJuzrvltXSru+BUxHDoog7Q==
+"@babel/plugin-transform-numeric-separator@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-numeric-separator/-/plugin-transform-numeric-separator-7.28.6.tgz"
+  integrity sha512-SJR8hPynj8outz+SlStQSwvziMN4+Bq99it4tMIf5/Caq+3iOc0JtKyse8puvyXkk3eFRIA5ID/XfunGgO5i6w==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.28.6"
 
-"@babel/plugin-transform-object-rest-spread@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-object-rest-spread/-/plugin-transform-object-rest-spread-7.25.9.tgz"
-  integrity sha512-fSaXafEE9CVHPweLYw4J0emp1t8zYTXyzN3UuG+lylqkvYd7RMrsOQ8TYx5RF231be0vqtFC6jnx3UmpJmKBYg==
+"@babel/plugin-transform-object-rest-spread@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-object-rest-spread/-/plugin-transform-object-rest-spread-7.28.6.tgz"
+  integrity sha512-5rh+JR4JBC4pGkXLAcYdLHZjXudVxWMXbB6u6+E9lRL5TrGVbHt1TjxGbZ8CkmYw9zjkB7jutzOROArsqtncEA==
   dependencies:
-    "@babel/helper-compilation-targets" "^7.25.9"
-    "@babel/helper-plugin-utils" "^7.25.9"
-    "@babel/plugin-transform-parameters" "^7.25.9"
+    "@babel/helper-compilation-targets" "^7.28.6"
+    "@babel/helper-plugin-utils" "^7.28.6"
+    "@babel/plugin-transform-destructuring" "^7.28.5"
+    "@babel/plugin-transform-parameters" "^7.27.7"
+    "@babel/traverse" "^7.28.6"
 
-"@babel/plugin-transform-object-super@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-object-super/-/plugin-transform-object-super-7.25.9.tgz"
-  integrity sha512-Kj/Gh+Rw2RNLbCK1VAWj2U48yxxqL2x0k10nPtSdRa0O2xnHXalD0s+o1A6a0W43gJ00ANo38jxkQreckOzv5A==
+"@babel/plugin-transform-object-super@^7.27.1":
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-object-super/-/plugin-transform-object-super-7.27.1.tgz"
+  integrity sha512-SFy8S9plRPbIcxlJ8A6mT/CxFdJx/c04JEctz4jf8YZaVS2px34j7NXRrlGlHkN/M2gnpL37ZpGRGVFLd3l8Ng==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
-    "@babel/helper-replace-supers" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.27.1"
+    "@babel/helper-replace-supers" "^7.27.1"
 
-"@babel/plugin-transform-optional-catch-binding@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-optional-catch-binding/-/plugin-transform-optional-catch-binding-7.25.9.tgz"
-  integrity sha512-qM/6m6hQZzDcZF3onzIhZeDHDO43bkNNlOX0i8n3lR6zLbu0GN2d8qfM/IERJZYauhAHSLHy39NF0Ctdvcid7g==
+"@babel/plugin-transform-optional-catch-binding@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-optional-catch-binding/-/plugin-transform-optional-catch-binding-7.28.6.tgz"
+  integrity sha512-R8ja/Pyrv0OGAvAXQhSTmWyPJPml+0TMqXlO5w+AsMEiwb2fg3WkOvob7UxFSL3OIttFSGSRFKQsOhJ/X6HQdQ==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.28.6"
 
-"@babel/plugin-transform-optional-chaining@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-optional-chaining/-/plugin-transform-optional-chaining-7.25.9.tgz"
-  integrity sha512-6AvV0FsLULbpnXeBjrY4dmWF8F7gf8QnvTEoO/wX/5xm/xE1Xo8oPuD3MPS+KS9f9XBEAWN7X1aWr4z9HdOr7A==
+"@babel/plugin-transform-optional-chaining@^7.27.1", "@babel/plugin-transform-optional-chaining@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-optional-chaining/-/plugin-transform-optional-chaining-7.28.6.tgz"
+  integrity sha512-A4zobikRGJTsX9uqVFdafzGkqD30t26ck2LmOzAuLL8b2x6k3TIqRiT2xVvA9fNmFeTX484VpsdgmKNA0bS23w==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
-    "@babel/helper-skip-transparent-expression-wrappers" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.28.6"
+    "@babel/helper-skip-transparent-expression-wrappers" "^7.27.1"
 
-"@babel/plugin-transform-parameters@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-parameters/-/plugin-transform-parameters-7.25.9.tgz"
-  integrity sha512-wzz6MKwpnshBAiRmn4jR8LYz/g8Ksg0o80XmwZDlordjwEk9SxBzTWC7F5ef1jhbrbOW2DJ5J6ayRukrJmnr0g==
+"@babel/plugin-transform-parameters@^7.27.7":
+  version "7.27.7"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-parameters/-/plugin-transform-parameters-7.27.7.tgz"
+  integrity sha512-qBkYTYCb76RRxUM6CcZA5KRu8K4SM8ajzVeUgVdMVO9NN9uI/GaVmBg/WKJJGnNokV9SY8FxNOVWGXzqzUidBg==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.27.1"
 
-"@babel/plugin-transform-private-methods@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-private-methods/-/plugin-transform-private-methods-7.25.9.tgz"
-  integrity sha512-D/JUozNpQLAPUVusvqMxyvjzllRaF8/nSrP1s2YGQT/W4LHK4xxsMcHjhOGTS01mp9Hda8nswb+FblLdJornQw==
+"@babel/plugin-transform-private-methods@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-private-methods/-/plugin-transform-private-methods-7.28.6.tgz"
+  integrity sha512-piiuapX9CRv7+0st8lmuUlRSmX6mBcVeNQ1b4AYzJxfCMuBfB0vBXDiGSmm03pKJw1v6cZ8KSeM+oUnM6yAExg==
   dependencies:
-    "@babel/helper-create-class-features-plugin" "^7.25.9"
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-create-class-features-plugin" "^7.28.6"
+    "@babel/helper-plugin-utils" "^7.28.6"
 
-"@babel/plugin-transform-private-property-in-object@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-private-property-in-object/-/plugin-transform-private-property-in-object-7.25.9.tgz"
-  integrity sha512-Evf3kcMqzXA3xfYJmZ9Pg1OvKdtqsDMSWBDzZOPLvHiTt36E75jLDQo5w1gtRU95Q4E5PDttrTf25Fw8d/uWLw==
+"@babel/plugin-transform-private-property-in-object@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-private-property-in-object/-/plugin-transform-private-property-in-object-7.28.6.tgz"
+  integrity sha512-b97jvNSOb5+ehyQmBpmhOCiUC5oVK4PMnpRvO7+ymFBoqYjeDHIU9jnrNUuwHOiL9RpGDoKBpSViarV+BU+eVA==
   dependencies:
-    "@babel/helper-annotate-as-pure" "^7.25.9"
-    "@babel/helper-create-class-features-plugin" "^7.25.9"
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-annotate-as-pure" "^7.27.3"
+    "@babel/helper-create-class-features-plugin" "^7.28.6"
+    "@babel/helper-plugin-utils" "^7.28.6"
 
-"@babel/plugin-transform-property-literals@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-property-literals/-/plugin-transform-property-literals-7.25.9.tgz"
-  integrity sha512-IvIUeV5KrS/VPavfSM/Iu+RE6llrHrYIKY1yfCzyO/lMXHQ+p7uGhonmGVisv6tSBSVgWzMBohTcvkC9vQcQFA==
+"@babel/plugin-transform-property-literals@^7.27.1":
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-property-literals/-/plugin-transform-property-literals-7.27.1.tgz"
+  integrity sha512-oThy3BCuCha8kDZ8ZkgOg2exvPYUlprMukKQXI1r1pJ47NCvxfkEy8vK+r/hT9nF0Aa4H1WUPZZjHTFtAhGfmQ==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.27.1"
 
 "@babel/plugin-transform-react-constant-elements@^7.21.3":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-react-constant-elements/-/plugin-transform-react-constant-elements-7.25.9.tgz"
-  integrity sha512-Ncw2JFsJVuvfRsa2lSHiC55kETQVLSnsYGQ1JDDwkUeWGTL/8Tom8aLTnlqgoeuopWrbbGndrc9AlLYrIosrow==
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-react-constant-elements/-/plugin-transform-react-constant-elements-7.27.1.tgz"
+  integrity sha512-edoidOjl/ZxvYo4lSBOQGDSyToYVkTAwyVoa2tkuYTSmjrB1+uAedoL5iROVLXkxH+vRgA7uP4tMg2pUJpZ3Ug==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.27.1"
 
-"@babel/plugin-transform-react-display-name@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-react-display-name/-/plugin-transform-react-display-name-7.25.9.tgz"
-  integrity sha512-KJfMlYIUxQB1CJfO3e0+h0ZHWOTLCPP115Awhaz8U0Zpq36Gl/cXlpoyMRnUWlhNUBAzldnCiAZNvCDj7CrKxQ==
+"@babel/plugin-transform-react-display-name@^7.28.0":
+  version "7.28.0"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-react-display-name/-/plugin-transform-react-display-name-7.28.0.tgz"
+  integrity sha512-D6Eujc2zMxKjfa4Zxl4GHMsmhKKZ9VpcqIchJLvwTxad9zWIYulwYItBovpDOoNLISpcZSXoDJ5gaGbQUDqViA==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.27.1"
 
-"@babel/plugin-transform-react-jsx-development@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-react-jsx-development/-/plugin-transform-react-jsx-development-7.25.9.tgz"
-  integrity sha512-9mj6rm7XVYs4mdLIpbZnHOYdpW42uoiBCTVowg7sP1thUOiANgMb4UtpRivR0pp5iL+ocvUv7X4mZgFRpJEzGw==
+"@babel/plugin-transform-react-jsx-development@^7.27.1":
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-react-jsx-development/-/plugin-transform-react-jsx-development-7.27.1.tgz"
+  integrity sha512-ykDdF5yI4f1WrAolLqeF3hmYU12j9ntLQl/AOG1HAS21jxyg1Q0/J/tpREuYLfatGdGmXp/3yS0ZA76kOlVq9Q==
   dependencies:
-    "@babel/plugin-transform-react-jsx" "^7.25.9"
+    "@babel/plugin-transform-react-jsx" "^7.27.1"
 
-"@babel/plugin-transform-react-jsx@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-react-jsx/-/plugin-transform-react-jsx-7.25.9.tgz"
-  integrity sha512-s5XwpQYCqGerXl+Pu6VDL3x0j2d82eiV77UJ8a2mDHAW7j9SWRqQ2y1fNo1Z74CdcYipl5Z41zvjj4Nfzq36rw==
+"@babel/plugin-transform-react-jsx@^7.27.1":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-react-jsx/-/plugin-transform-react-jsx-7.28.6.tgz"
+  integrity sha512-61bxqhiRfAACulXSLd/GxqmAedUSrRZIu/cbaT18T1CetkTmtDN15it7i80ru4DVqRK1WMxQhXs+Lf9kajm5Ow==
   dependencies:
-    "@babel/helper-annotate-as-pure" "^7.25.9"
-    "@babel/helper-module-imports" "^7.25.9"
-    "@babel/helper-plugin-utils" "^7.25.9"
-    "@babel/plugin-syntax-jsx" "^7.25.9"
-    "@babel/types" "^7.25.9"
+    "@babel/helper-annotate-as-pure" "^7.27.3"
+    "@babel/helper-module-imports" "^7.28.6"
+    "@babel/helper-plugin-utils" "^7.28.6"
+    "@babel/plugin-syntax-jsx" "^7.28.6"
+    "@babel/types" "^7.28.6"
 
-"@babel/plugin-transform-react-pure-annotations@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-react-pure-annotations/-/plugin-transform-react-pure-annotations-7.25.9.tgz"
-  integrity sha512-KQ/Takk3T8Qzj5TppkS1be588lkbTp5uj7w6a0LeQaTMSckU/wK0oJ/pih+T690tkgI5jfmg2TqDJvd41Sj1Cg==
+"@babel/plugin-transform-react-pure-annotations@^7.27.1":
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-react-pure-annotations/-/plugin-transform-react-pure-annotations-7.27.1.tgz"
+  integrity sha512-JfuinvDOsD9FVMTHpzA/pBLisxpv1aSf+OIV8lgH3MuWrks19R27e6a6DipIg4aX1Zm9Wpb04p8wljfKrVSnPA==
   dependencies:
-    "@babel/helper-annotate-as-pure" "^7.25.9"
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-annotate-as-pure" "^7.27.1"
+    "@babel/helper-plugin-utils" "^7.27.1"
 
-"@babel/plugin-transform-regenerator@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-regenerator/-/plugin-transform-regenerator-7.25.9.tgz"
-  integrity sha512-vwDcDNsgMPDGP0nMqzahDWE5/MLcX8sv96+wfX7as7LoF/kr97Bo/7fI00lXY4wUXYfVmwIIyG80fGZ1uvt2qg==
+"@babel/plugin-transform-regenerator@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-regenerator/-/plugin-transform-regenerator-7.28.6.tgz"
+  integrity sha512-eZhoEZHYQLL5uc1gS5e9/oTknS0sSSAtd5TkKMUp3J+S/CaUjagc0kOUPsEbDmMeva0nC3WWl4SxVY6+OBuxfw==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
-    regenerator-transform "^0.15.2"
+    "@babel/helper-plugin-utils" "^7.28.6"
 
-"@babel/plugin-transform-regexp-modifiers@^7.26.0":
-  version "7.26.0"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-regexp-modifiers/-/plugin-transform-regexp-modifiers-7.26.0.tgz"
-  integrity sha512-vN6saax7lrA2yA/Pak3sCxuD6F5InBjn9IcrIKQPjpsLvuHYLVroTxjdlVRHjjBWxKOqIwpTXDkOssYT4BFdRw==
+"@babel/plugin-transform-regexp-modifiers@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-regexp-modifiers/-/plugin-transform-regexp-modifiers-7.28.6.tgz"
+  integrity sha512-QGWAepm9qxpaIs7UM9FvUSnCGlb8Ua1RhyM4/veAxLwt3gMat/LSGrZixyuj4I6+Kn9iwvqCyPTtbdxanYoWYg==
   dependencies:
-    "@babel/helper-create-regexp-features-plugin" "^7.25.9"
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-create-regexp-features-plugin" "^7.28.5"
+    "@babel/helper-plugin-utils" "^7.28.6"
 
-"@babel/plugin-transform-reserved-words@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-reserved-words/-/plugin-transform-reserved-words-7.25.9.tgz"
-  integrity sha512-7DL7DKYjn5Su++4RXu8puKZm2XBPHyjWLUidaPEkCUBbE7IPcsrkRHggAOOKydH1dASWdcUBxrkOGNxUv5P3Jg==
+"@babel/plugin-transform-reserved-words@^7.27.1":
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-reserved-words/-/plugin-transform-reserved-words-7.27.1.tgz"
+  integrity sha512-V2ABPHIJX4kC7HegLkYoDpfg9PVmuWy/i6vUM5eGK22bx4YVFD3M5F0QQnWQoDs6AGsUWTVOopBiMFQgHaSkVw==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.27.1"
 
 "@babel/plugin-transform-runtime@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-runtime/-/plugin-transform-runtime-7.25.9.tgz"
-  integrity sha512-nZp7GlEl+yULJrClz0SwHPqir3lc0zsPrDHQUcxGspSL7AKrexNSEfTbfqnDNJUO13bgKyfuOLMF8Xqtu8j3YQ==
-  dependencies:
-    "@babel/helper-module-imports" "^7.25.9"
-    "@babel/helper-plugin-utils" "^7.25.9"
-    babel-plugin-polyfill-corejs2 "^0.4.10"
-    babel-plugin-polyfill-corejs3 "^0.10.6"
-    babel-plugin-polyfill-regenerator "^0.6.1"
+  version "7.28.5"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-runtime/-/plugin-transform-runtime-7.28.5.tgz"
+  integrity sha512-20NUVgOrinudkIBzQ2bNxP08YpKprUkRTiRSd2/Z5GOdPImJGkoN4Z7IQe1T5AdyKI1i5L6RBmluqdSzvaq9/w==
+  dependencies:
+    "@babel/helper-module-imports" "^7.27.1"
+    "@babel/helper-plugin-utils" "^7.27.1"
+    babel-plugin-polyfill-corejs2 "^0.4.14"
+    babel-plugin-polyfill-corejs3 "^0.13.0"
+    babel-plugin-polyfill-regenerator "^0.6.5"
     semver "^6.3.1"
 
-"@babel/plugin-transform-shorthand-properties@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-shorthand-properties/-/plugin-transform-shorthand-properties-7.25.9.tgz"
-  integrity sha512-MUv6t0FhO5qHnS/W8XCbHmiRWOphNufpE1IVxhK5kuN3Td9FT1x4rx4K42s3RYdMXCXpfWkGSbCSd0Z64xA7Ng==
+"@babel/plugin-transform-shorthand-properties@^7.27.1":
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-shorthand-properties/-/plugin-transform-shorthand-properties-7.27.1.tgz"
+  integrity sha512-N/wH1vcn4oYawbJ13Y/FxcQrWk63jhfNa7jef0ih7PHSIHX2LB7GWE1rkPrOnka9kwMxb6hMl19p7lidA+EHmQ==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.27.1"
 
-"@babel/plugin-transform-spread@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-spread/-/plugin-transform-spread-7.25.9.tgz"
-  integrity sha512-oNknIB0TbURU5pqJFVbOOFspVlrpVwo2H1+HUIsVDvp5VauGGDP1ZEvO8Nn5xyMEs3dakajOxlmkNW7kNgSm6A==
+"@babel/plugin-transform-spread@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-spread/-/plugin-transform-spread-7.28.6.tgz"
+  integrity sha512-9U4QObUC0FtJl05AsUcodau/RWDytrU6uKgkxu09mLR9HLDAtUMoPuuskm5huQsoktmsYpI+bGmq+iapDcriKA==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
-    "@babel/helper-skip-transparent-expression-wrappers" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.28.6"
+    "@babel/helper-skip-transparent-expression-wrappers" "^7.27.1"
 
-"@babel/plugin-transform-sticky-regex@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-sticky-regex/-/plugin-transform-sticky-regex-7.25.9.tgz"
-  integrity sha512-WqBUSgeVwucYDP9U/xNRQam7xV8W5Zf+6Eo7T2SRVUFlhRiMNFdFz58u0KZmCVVqs2i7SHgpRnAhzRNmKfi2uA==
+"@babel/plugin-transform-sticky-regex@^7.27.1":
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-sticky-regex/-/plugin-transform-sticky-regex-7.27.1.tgz"
+  integrity sha512-lhInBO5bi/Kowe2/aLdBAawijx+q1pQzicSgnkB6dUPc1+RC8QmJHKf2OjvU+NZWitguJHEaEmbV6VWEouT58g==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.27.1"
 
-"@babel/plugin-transform-template-literals@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-template-literals/-/plugin-transform-template-literals-7.25.9.tgz"
-  integrity sha512-o97AE4syN71M/lxrCtQByzphAdlYluKPDBzDVzMmfCobUjjhAryZV0AIpRPrxN0eAkxXO6ZLEScmt+PNhj2OTw==
+"@babel/plugin-transform-template-literals@^7.27.1":
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-template-literals/-/plugin-transform-template-literals-7.27.1.tgz"
+  integrity sha512-fBJKiV7F2DxZUkg5EtHKXQdbsbURW3DZKQUWphDum0uRP6eHGGa/He9mc0mypL680pb+e/lDIthRohlv8NCHkg==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.27.1"
 
-"@babel/plugin-transform-typeof-symbol@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-typeof-symbol/-/plugin-transform-typeof-symbol-7.25.9.tgz"
-  integrity sha512-v61XqUMiueJROUv66BVIOi0Fv/CUuZuZMl5NkRoCVxLAnMexZ0A3kMe7vvZ0nulxMuMp0Mk6S5hNh48yki08ZA==
+"@babel/plugin-transform-typeof-symbol@^7.27.1":
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-typeof-symbol/-/plugin-transform-typeof-symbol-7.27.1.tgz"
+  integrity sha512-RiSILC+nRJM7FY5srIyc4/fGIwUhyDuuBSdWn4y6yT6gm652DpCHZjIipgn6B7MQ1ITOUnAKWixEUjQRIBIcLw==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.27.1"
 
-"@babel/plugin-transform-typescript@^7.25.9":
-  version "7.26.5"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-typescript/-/plugin-transform-typescript-7.26.5.tgz"
-  integrity sha512-GJhPO0y8SD5EYVCy2Zr+9dSZcEgaSmq5BLR0Oc25TOEhC+ba49vUAGZFjy8v79z9E1mdldq4x9d1xgh4L1d5dQ==
+"@babel/plugin-transform-typescript@^7.28.5":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-typescript/-/plugin-transform-typescript-7.28.6.tgz"
+  integrity sha512-0YWL2RFxOqEm9Efk5PvreamxPME8OyY0wM5wh5lHjF+VtVhdneCWGzZeSqzOfiobVqQaNCd2z0tQvnI9DaPWPw==
   dependencies:
-    "@babel/helper-annotate-as-pure" "^7.25.9"
-    "@babel/helper-create-class-features-plugin" "^7.25.9"
-    "@babel/helper-plugin-utils" "^7.26.5"
-    "@babel/helper-skip-transparent-expression-wrappers" "^7.25.9"
-    "@babel/plugin-syntax-typescript" "^7.25.9"
+    "@babel/helper-annotate-as-pure" "^7.27.3"
+    "@babel/helper-create-class-features-plugin" "^7.28.6"
+    "@babel/helper-plugin-utils" "^7.28.6"
+    "@babel/helper-skip-transparent-expression-wrappers" "^7.27.1"
+    "@babel/plugin-syntax-typescript" "^7.28.6"
 
-"@babel/plugin-transform-unicode-escapes@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-unicode-escapes/-/plugin-transform-unicode-escapes-7.25.9.tgz"
-  integrity sha512-s5EDrE6bW97LtxOcGj1Khcx5AaXwiMmi4toFWRDP9/y0Woo6pXC+iyPu/KuhKtfSrNFd7jJB+/fkOtZy6aIC6Q==
+"@babel/plugin-transform-unicode-escapes@^7.27.1":
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-unicode-escapes/-/plugin-transform-unicode-escapes-7.27.1.tgz"
+  integrity sha512-Ysg4v6AmF26k9vpfFuTZg8HRfVWzsh1kVfowA23y9j/Gu6dOuahdUVhkLqpObp3JIv27MLSii6noRnuKN8H0Mg==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.27.1"
 
-"@babel/plugin-transform-unicode-property-regex@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-unicode-property-regex/-/plugin-transform-unicode-property-regex-7.25.9.tgz"
-  integrity sha512-Jt2d8Ga+QwRluxRQ307Vlxa6dMrYEMZCgGxoPR8V52rxPyldHu3hdlHspxaqYmE7oID5+kB+UKUB/eWS+DkkWg==
+"@babel/plugin-transform-unicode-property-regex@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-unicode-property-regex/-/plugin-transform-unicode-property-regex-7.28.6.tgz"
+  integrity sha512-4Wlbdl/sIZjzi/8St0evF0gEZrgOswVO6aOzqxh1kDZOl9WmLrHq2HtGhnOJZmHZYKP8WZ1MDLCt5DAWwRo57A==
   dependencies:
-    "@babel/helper-create-regexp-features-plugin" "^7.25.9"
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-create-regexp-features-plugin" "^7.28.5"
+    "@babel/helper-plugin-utils" "^7.28.6"
 
-"@babel/plugin-transform-unicode-regex@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-unicode-regex/-/plugin-transform-unicode-regex-7.25.9.tgz"
-  integrity sha512-yoxstj7Rg9dlNn9UQxzk4fcNivwv4nUYz7fYXBaKxvw/lnmPuOm/ikoELygbYq68Bls3D/D+NBPHiLwZdZZ4HA==
+"@babel/plugin-transform-unicode-regex@^7.27.1":
+  version "7.27.1"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-unicode-regex/-/plugin-transform-unicode-regex-7.27.1.tgz"
+  integrity sha512-xvINq24TRojDuyt6JGtHmkVkrfVV3FPT16uytxImLeBZqW3/H52yN+kM1MGuyPkIQxrzKwPHs5U/MP3qKyzkGw==
   dependencies:
-    "@babel/helper-create-regexp-features-plugin" "^7.25.9"
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-create-regexp-features-plugin" "^7.27.1"
+    "@babel/helper-plugin-utils" "^7.27.1"
 
-"@babel/plugin-transform-unicode-sets-regex@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/plugin-transform-unicode-sets-regex/-/plugin-transform-unicode-sets-regex-7.25.9.tgz"
-  integrity sha512-8BYqO3GeVNHtx69fdPshN3fnzUNLrWdHhk/icSwigksJGczKSizZ+Z6SBCxTs723Fr5VSNorTIK7a+R2tISvwQ==
+"@babel/plugin-transform-unicode-sets-regex@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/plugin-transform-unicode-sets-regex/-/plugin-transform-unicode-sets-regex-7.28.6.tgz"
+  integrity sha512-/wHc/paTUmsDYN7SZkpWxogTOBNnlx7nBQYfy6JJlCT7G3mVhltk3e++N7zV0XfgGsrqBxd4rJQt9H16I21Y1Q==
   dependencies:
-    "@babel/helper-create-regexp-features-plugin" "^7.25.9"
-    "@babel/helper-plugin-utils" "^7.25.9"
+    "@babel/helper-create-regexp-features-plugin" "^7.28.5"
+    "@babel/helper-plugin-utils" "^7.28.6"
 
 "@babel/preset-env@^7.20.2", "@babel/preset-env@^7.25.9":
-  version "7.26.0"
-  resolved "https://registry.npmjs.org/@babel/preset-env/-/preset-env-7.26.0.tgz"
-  integrity sha512-H84Fxq0CQJNdPFT2DrfnylZ3cf5K43rGfWK4LJGPpjKHiZlk0/RzwEus3PDDZZg+/Er7lCA03MVacueUuXdzfw==
-  dependencies:
-    "@babel/compat-data" "^7.26.0"
-    "@babel/helper-compilation-targets" "^7.25.9"
-    "@babel/helper-plugin-utils" "^7.25.9"
-    "@babel/helper-validator-option" "^7.25.9"
-    "@babel/plugin-bugfix-firefox-class-in-computed-class-key" "^7.25.9"
-    "@babel/plugin-bugfix-safari-class-field-initializer-scope" "^7.25.9"
-    "@babel/plugin-bugfix-safari-id-destructuring-collision-in-function-expression" "^7.25.9"
-    "@babel/plugin-bugfix-v8-spread-parameters-in-optional-chaining" "^7.25.9"
-    "@babel/plugin-bugfix-v8-static-class-fields-redefine-readonly" "^7.25.9"
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/preset-env/-/preset-env-7.28.6.tgz"
+  integrity sha512-GaTI4nXDrs7l0qaJ6Rg06dtOXTBCG6TMDB44zbqofCIC4PqC7SEvmFFtpxzCDw9W5aJ7RKVshgXTLvLdBFV/qw==
+  dependencies:
+    "@babel/compat-data" "^7.28.6"
+    "@babel/helper-compilation-targets" "^7.28.6"
+    "@babel/helper-plugin-utils" "^7.28.6"
+    "@babel/helper-validator-option" "^7.27.1"
+    "@babel/plugin-bugfix-firefox-class-in-computed-class-key" "^7.28.5"
+    "@babel/plugin-bugfix-safari-class-field-initializer-scope" "^7.27.1"
+    "@babel/plugin-bugfix-safari-id-destructuring-collision-in-function-expression" "^7.27.1"
+    "@babel/plugin-bugfix-v8-spread-parameters-in-optional-chaining" "^7.27.1"
+    "@babel/plugin-bugfix-v8-static-class-fields-redefine-readonly" "^7.28.6"
     "@babel/plugin-proposal-private-property-in-object" "7.21.0-placeholder-for-preset-env.2"
-    "@babel/plugin-syntax-import-assertions" "^7.26.0"
-    "@babel/plugin-syntax-import-attributes" "^7.26.0"
+    "@babel/plugin-syntax-import-assertions" "^7.28.6"
+    "@babel/plugin-syntax-import-attributes" "^7.28.6"
     "@babel/plugin-syntax-unicode-sets-regex" "^7.18.6"
-    "@babel/plugin-transform-arrow-functions" "^7.25.9"
-    "@babel/plugin-transform-async-generator-functions" "^7.25.9"
-    "@babel/plugin-transform-async-to-generator" "^7.25.9"
-    "@babel/plugin-transform-block-scoped-functions" "^7.25.9"
-    "@babel/plugin-transform-block-scoping" "^7.25.9"
-    "@babel/plugin-transform-class-properties" "^7.25.9"
-    "@babel/plugin-transform-class-static-block" "^7.26.0"
-    "@babel/plugin-transform-classes" "^7.25.9"
-    "@babel/plugin-transform-computed-properties" "^7.25.9"
-    "@babel/plugin-transform-destructuring" "^7.25.9"
-    "@babel/plugin-transform-dotall-regex" "^7.25.9"
-    "@babel/plugin-transform-duplicate-keys" "^7.25.9"
-    "@babel/plugin-transform-duplicate-named-capturing-groups-regex" "^7.25.9"
-    "@babel/plugin-transform-dynamic-import" "^7.25.9"
-    "@babel/plugin-transform-exponentiation-operator" "^7.25.9"
-    "@babel/plugin-transform-export-namespace-from" "^7.25.9"
-    "@babel/plugin-transform-for-of" "^7.25.9"
-    "@babel/plugin-transform-function-name" "^7.25.9"
-    "@babel/plugin-transform-json-strings" "^7.25.9"
-    "@babel/plugin-transform-literals" "^7.25.9"
-    "@babel/plugin-transform-logical-assignment-operators" "^7.25.9"
-    "@babel/plugin-transform-member-expression-literals" "^7.25.9"
-    "@babel/plugin-transform-modules-amd" "^7.25.9"
-    "@babel/plugin-transform-modules-commonjs" "^7.25.9"
-    "@babel/plugin-transform-modules-systemjs" "^7.25.9"
-    "@babel/plugin-transform-modules-umd" "^7.25.9"
-    "@babel/plugin-transform-named-capturing-groups-regex" "^7.25.9"
-    "@babel/plugin-transform-new-target" "^7.25.9"
-    "@babel/plugin-transform-nullish-coalescing-operator" "^7.25.9"
-    "@babel/plugin-transform-numeric-separator" "^7.25.9"
-    "@babel/plugin-transform-object-rest-spread" "^7.25.9"
-    "@babel/plugin-transform-object-super" "^7.25.9"
-    "@babel/plugin-transform-optional-catch-binding" "^7.25.9"
-    "@babel/plugin-transform-optional-chaining" "^7.25.9"
-    "@babel/plugin-transform-parameters" "^7.25.9"
-    "@babel/plugin-transform-private-methods" "^7.25.9"
-    "@babel/plugin-transform-private-property-in-object" "^7.25.9"
-    "@babel/plugin-transform-property-literals" "^7.25.9"
-    "@babel/plugin-transform-regenerator" "^7.25.9"
-    "@babel/plugin-transform-regexp-modifiers" "^7.26.0"
-    "@babel/plugin-transform-reserved-words" "^7.25.9"
-    "@babel/plugin-transform-shorthand-properties" "^7.25.9"
-    "@babel/plugin-transform-spread" "^7.25.9"
-    "@babel/plugin-transform-sticky-regex" "^7.25.9"
-    "@babel/plugin-transform-template-literals" "^7.25.9"
-    "@babel/plugin-transform-typeof-symbol" "^7.25.9"
-    "@babel/plugin-transform-unicode-escapes" "^7.25.9"
-    "@babel/plugin-transform-unicode-property-regex" "^7.25.9"
-    "@babel/plugin-transform-unicode-regex" "^7.25.9"
-    "@babel/plugin-transform-unicode-sets-regex" "^7.25.9"
+    "@babel/plugin-transform-arrow-functions" "^7.27.1"
+    "@babel/plugin-transform-async-generator-functions" "^7.28.6"
+    "@babel/plugin-transform-async-to-generator" "^7.28.6"
+    "@babel/plugin-transform-block-scoped-functions" "^7.27.1"
+    "@babel/plugin-transform-block-scoping" "^7.28.6"
+    "@babel/plugin-transform-class-properties" "^7.28.6"
+    "@babel/plugin-transform-class-static-block" "^7.28.6"
+    "@babel/plugin-transform-classes" "^7.28.6"
+    "@babel/plugin-transform-computed-properties" "^7.28.6"
+    "@babel/plugin-transform-destructuring" "^7.28.5"
+    "@babel/plugin-transform-dotall-regex" "^7.28.6"
+    "@babel/plugin-transform-duplicate-keys" "^7.27.1"
+    "@babel/plugin-transform-duplicate-named-capturing-groups-regex" "^7.28.6"
+    "@babel/plugin-transform-dynamic-import" "^7.27.1"
+    "@babel/plugin-transform-explicit-resource-management" "^7.28.6"
+    "@babel/plugin-transform-exponentiation-operator" "^7.28.6"
+    "@babel/plugin-transform-export-namespace-from" "^7.27.1"
+    "@babel/plugin-transform-for-of" "^7.27.1"
+    "@babel/plugin-transform-function-name" "^7.27.1"
+    "@babel/plugin-transform-json-strings" "^7.28.6"
+    "@babel/plugin-transform-literals" "^7.27.1"
+    "@babel/plugin-transform-logical-assignment-operators" "^7.28.6"
+    "@babel/plugin-transform-member-expression-literals" "^7.27.1"
+    "@babel/plugin-transform-modules-amd" "^7.27.1"
+    "@babel/plugin-transform-modules-commonjs" "^7.28.6"
+    "@babel/plugin-transform-modules-systemjs" "^7.28.5"
+    "@babel/plugin-transform-modules-umd" "^7.27.1"
+    "@babel/plugin-transform-named-capturing-groups-regex" "^7.27.1"
+    "@babel/plugin-transform-new-target" "^7.27.1"
+    "@babel/plugin-transform-nullish-coalescing-operator" "^7.28.6"
+    "@babel/plugin-transform-numeric-separator" "^7.28.6"
+    "@babel/plugin-transform-object-rest-spread" "^7.28.6"
+    "@babel/plugin-transform-object-super" "^7.27.1"
+    "@babel/plugin-transform-optional-catch-binding" "^7.28.6"
+    "@babel/plugin-transform-optional-chaining" "^7.28.6"
+    "@babel/plugin-transform-parameters" "^7.27.7"
+    "@babel/plugin-transform-private-methods" "^7.28.6"
+    "@babel/plugin-transform-private-property-in-object" "^7.28.6"
+    "@babel/plugin-transform-property-literals" "^7.27.1"
+    "@babel/plugin-transform-regenerator" "^7.28.6"
+    "@babel/plugin-transform-regexp-modifiers" "^7.28.6"
+    "@babel/plugin-transform-reserved-words" "^7.27.1"
+    "@babel/plugin-transform-shorthand-properties" "^7.27.1"
+    "@babel/plugin-transform-spread" "^7.28.6"
+    "@babel/plugin-transform-sticky-regex" "^7.27.1"
+    "@babel/plugin-transform-template-literals" "^7.27.1"
+    "@babel/plugin-transform-typeof-symbol" "^7.27.1"
+    "@babel/plugin-transform-unicode-escapes" "^7.27.1"
+    "@babel/plugin-transform-unicode-property-regex" "^7.28.6"
+    "@babel/plugin-transform-unicode-regex" "^7.27.1"
+    "@babel/plugin-transform-unicode-sets-regex" "^7.28.6"
     "@babel/preset-modules" "0.1.6-no-external-plugins"
-    babel-plugin-polyfill-corejs2 "^0.4.10"
-    babel-plugin-polyfill-corejs3 "^0.10.6"
-    babel-plugin-polyfill-regenerator "^0.6.1"
-    core-js-compat "^3.38.1"
+    babel-plugin-polyfill-corejs2 "^0.4.14"
+    babel-plugin-polyfill-corejs3 "^0.13.0"
+    babel-plugin-polyfill-regenerator "^0.6.5"
+    core-js-compat "^3.43.0"
     semver "^6.3.1"
 
 "@babel/preset-modules@0.1.6-no-external-plugins":
@@ -979,164 +1025,205 @@
     esutils "^2.0.2"
 
 "@babel/preset-react@^7.18.6", "@babel/preset-react@^7.25.9":
-  version "7.26.3"
-  resolved "https://registry.npmjs.org/@babel/preset-react/-/preset-react-7.26.3.tgz"
-  integrity sha512-Nl03d6T9ky516DGK2YMxrTqvnpUW63TnJMOMonj+Zae0JiPC5BC9xPMSL6L8fiSpA5vP88qfygavVQvnLp+6Cw==
+  version "7.28.5"
+  resolved "https://registry.npmjs.org/@babel/preset-react/-/preset-react-7.28.5.tgz"
+  integrity sha512-Z3J8vhRq7CeLjdC58jLv4lnZ5RKFUJWqH5emvxmv9Hv3BD1T9R/Im713R4MTKwvFaV74ejZ3sM01LyEKk4ugNQ==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
-    "@babel/helper-validator-option" "^7.25.9"
-    "@babel/plugin-transform-react-display-name" "^7.25.9"
-    "@babel/plugin-transform-react-jsx" "^7.25.9"
-    "@babel/plugin-transform-react-jsx-development" "^7.25.9"
-    "@babel/plugin-transform-react-pure-annotations" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.27.1"
+    "@babel/helper-validator-option" "^7.27.1"
+    "@babel/plugin-transform-react-display-name" "^7.28.0"
+    "@babel/plugin-transform-react-jsx" "^7.27.1"
+    "@babel/plugin-transform-react-jsx-development" "^7.27.1"
+    "@babel/plugin-transform-react-pure-annotations" "^7.27.1"
 
 "@babel/preset-typescript@^7.21.0", "@babel/preset-typescript@^7.25.9":
-  version "7.26.0"
-  resolved "https://registry.npmjs.org/@babel/preset-typescript/-/preset-typescript-7.26.0.tgz"
-  integrity sha512-NMk1IGZ5I/oHhoXEElcm+xUnL/szL6xflkFZmoEU9xj1qSJXpiS7rsspYo92B4DRCDvZn2erT5LdsCeXAKNCkg==
+  version "7.28.5"
+  resolved "https://registry.npmjs.org/@babel/preset-typescript/-/preset-typescript-7.28.5.tgz"
+  integrity sha512-+bQy5WOI2V6LJZpPVxY+yp66XdZ2yifu0Mc1aP5CQKgjn4QM5IN2i5fAZ4xKop47pr8rpVhiAeu+nDQa12C8+g==
   dependencies:
-    "@babel/helper-plugin-utils" "^7.25.9"
-    "@babel/helper-validator-option" "^7.25.9"
-    "@babel/plugin-syntax-jsx" "^7.25.9"
-    "@babel/plugin-transform-modules-commonjs" "^7.25.9"
-    "@babel/plugin-transform-typescript" "^7.25.9"
+    "@babel/helper-plugin-utils" "^7.27.1"
+    "@babel/helper-validator-option" "^7.27.1"
+    "@babel/plugin-syntax-jsx" "^7.27.1"
+    "@babel/plugin-transform-modules-commonjs" "^7.27.1"
+    "@babel/plugin-transform-typescript" "^7.28.5"
 
 "@babel/runtime-corejs3@^7.25.9":
-  version "7.26.0"
-  resolved "https://registry.npmjs.org/@babel/runtime-corejs3/-/runtime-corejs3-7.26.0.tgz"
-  integrity sha512-YXHu5lN8kJCb1LOb9PgV6pvak43X2h4HvRApcN5SdWeaItQOzfn1hgP6jasD6KWQyJDBxrVmA9o9OivlnNJK/w==
-  dependencies:
-    core-js-pure "^3.30.2"
-    regenerator-runtime "^0.14.0"
-
-"@babel/runtime@^7.1.2", "@babel/runtime@^7.10.3", "@babel/runtime@^7.12.13", "@babel/runtime@^7.12.5", "@babel/runtime@^7.25.9", "@babel/runtime@^7.8.4":
-  version "7.26.0"
-  resolved "https://registry.npmjs.org/@babel/runtime/-/runtime-7.26.0.tgz"
-  integrity sha512-FDSOghenHTiToteC/QRlv2q3DhPZ/oOXTBoirfWNx1Cx3TMVcGWQtMMmQcSvb/JjpNeGzx8Pq/b4fKEJuWm1sw==
-  dependencies:
-    regenerator-runtime "^0.14.0"
-
-"@babel/template@^7.25.9":
-  version "7.25.9"
-  resolved "https://registry.npmjs.org/@babel/template/-/template-7.25.9.tgz"
-  integrity sha512-9DGttpmPvIxBb/2uwpVo3dqJ+O6RooAFOS+lB+xDqoE2PVCE8nfoHMdZLpfCQRLwvohzXISPZcgxt80xLfsuwg==
-  dependencies:
-    "@babel/code-frame" "^7.25.9"
-    "@babel/parser" "^7.25.9"
-    "@babel/types" "^7.25.9"
-
-"@babel/traverse@^7.25.9", "@babel/traverse@^7.26.5":
-  version "7.26.5"
-  resolved "https://registry.npmjs.org/@babel/traverse/-/traverse-7.26.5.tgz"
-  integrity sha512-rkOSPOw+AXbgtwUga3U4u8RpoK9FEFWBNAlTpcnkLFjL5CT+oyHNuUUC/xx6XefEJ16r38r8Bc/lfp6rYuHeJQ==
-  dependencies:
-    "@babel/code-frame" "^7.26.2"
-    "@babel/generator" "^7.26.5"
-    "@babel/parser" "^7.26.5"
-    "@babel/template" "^7.25.9"
-    "@babel/types" "^7.26.5"
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/runtime-corejs3/-/runtime-corejs3-7.28.6.tgz"
+  integrity sha512-kz2fAQ5UzjV7X7D3ySxmj3vRq89dTpqOZWv76Z6pNPztkwb/0Yj1Mtx1xFrYj6mbIHysxtBot8J4o0JLCblcFw==
+  dependencies:
+    core-js-pure "^3.43.0"
+
+"@babel/runtime@^7.1.2", "@babel/runtime@^7.10.3", "@babel/runtime@^7.12.13", "@babel/runtime@^7.12.5", "@babel/runtime@^7.25.9":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/runtime/-/runtime-7.28.6.tgz"
+  integrity sha512-05WQkdpL9COIMz4LjTxGpPNCdlpyimKppYNoJ5Di5EUObifl8t4tuLuUBBZEpoLYOmfvIWrsp9fCl0HoPRVTdA==
+
+"@babel/template@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/template/-/template-7.28.6.tgz"
+  integrity sha512-YA6Ma2KsCdGb+WC6UpBVFJGXL58MDA6oyONbjyF/+5sBgxY/dwkhLogbMT2GXXyU84/IhRw/2D1Os1B/giz+BQ==
+  dependencies:
+    "@babel/code-frame" "^7.28.6"
+    "@babel/parser" "^7.28.6"
+    "@babel/types" "^7.28.6"
+
+"@babel/traverse@^7.25.9", "@babel/traverse@^7.27.1", "@babel/traverse@^7.28.5", "@babel/traverse@^7.28.6":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/traverse/-/traverse-7.28.6.tgz"
+  integrity sha512-fgWX62k02qtjqdSNTAGxmKYY/7FSL9WAS1o2Hu5+I5m9T0yxZzr4cnrfXQ/MX0rIifthCSs6FKTlzYbJcPtMNg==
+  dependencies:
+    "@babel/code-frame" "^7.28.6"
+    "@babel/generator" "^7.28.6"
+    "@babel/helper-globals" "^7.28.0"
+    "@babel/parser" "^7.28.6"
+    "@babel/template" "^7.28.6"
+    "@babel/types" "^7.28.6"
     debug "^4.3.1"
-    globals "^11.1.0"
 
-"@babel/types@^7.21.3", "@babel/types@^7.25.9", "@babel/types@^7.26.0", "@babel/types@^7.26.5", "@babel/types@^7.4.4":
-  version "7.26.5"
-  resolved "https://registry.npmjs.org/@babel/types/-/types-7.26.5.tgz"
-  integrity sha512-L6mZmwFDK6Cjh1nRCLXpa6no13ZIioJDz7mdkzHv399pThrTa/k0nUlNaenOeh2kWu/iaOQYElEpKPUswUa9Vg==
+"@babel/types@^7.21.3", "@babel/types@^7.27.1", "@babel/types@^7.27.3", "@babel/types@^7.28.5", "@babel/types@^7.28.6", "@babel/types@^7.4.4":
+  version "7.28.6"
+  resolved "https://registry.npmjs.org/@babel/types/-/types-7.28.6.tgz"
+  integrity sha512-0ZrskXVEHSWIqZM/sQZ4EV3jZJXRkio/WCxaqKZP1g//CEWEPSfeZFcms4XeKBCHU0ZKnIkdJeU/kF+eRp5lBg==
   dependencies:
-    "@babel/helper-string-parser" "^7.25.9"
-    "@babel/helper-validator-identifier" "^7.25.9"
+    "@babel/helper-string-parser" "^7.27.1"
+    "@babel/helper-validator-identifier" "^7.28.5"
 
 "@colors/colors@1.5.0":
   version "1.5.0"
   resolved "https://registry.npmjs.org/@colors/colors/-/colors-1.5.0.tgz"
   integrity sha512-ooWCrlZP11i8GImSjTHYHLkvFDP48nS4+204nGb1RiX/WXYHmJA2III9/e2DWVabCESdW7hBAEzHRqUn9OUVvQ==
 
-"@csstools/cascade-layer-name-parser@^2.0.4":
-  version "2.0.4"
-  resolved "https://registry.npmjs.org/@csstools/cascade-layer-name-parser/-/cascade-layer-name-parser-2.0.4.tgz"
-  integrity sha512-7DFHlPuIxviKYZrOiwVU/PiHLm3lLUR23OMuEEtfEOQTOp9hzQ2JjdY6X5H18RVuUPJqSCI+qNnD5iOLMVE0bA==
+"@csstools/cascade-layer-name-parser@^2.0.5":
+  version "2.0.5"
+  resolved "https://registry.npmjs.org/@csstools/cascade-layer-name-parser/-/cascade-layer-name-parser-2.0.5.tgz"
+  integrity sha512-p1ko5eHgV+MgXFVa4STPKpvPxr6ReS8oS2jzTukjR74i5zJNyWO1ZM1m8YKBXnzDKWfBN1ztLYlHxbVemDD88A==
 
-"@csstools/color-helpers@^5.0.1":
-  version "5.0.1"
-  resolved "https://registry.npmjs.org/@csstools/color-helpers/-/color-helpers-5.0.1.tgz"
-  integrity sha512-MKtmkA0BX87PKaO1NFRTFH+UnkgnmySQOvNxJubsadusqPEC2aJ9MOQiMceZJJ6oitUl/i0L6u0M1IrmAOmgBA==
+"@csstools/color-helpers@^5.1.0":
+  version "5.1.0"
+  resolved "https://registry.npmjs.org/@csstools/color-helpers/-/color-helpers-5.1.0.tgz"
+  integrity sha512-S11EXWJyy0Mz5SYvRmY8nJYTFFd1LCNV+7cXyAgQtOOuzb4EsgfqDufL+9esx72/eLhsRdGZwaldu/h+E4t4BA==
 
-"@csstools/css-calc@^2.1.1":
-  version "2.1.1"
-  resolved "https://registry.npmjs.org/@csstools/css-calc/-/css-calc-2.1.1.tgz"
-  integrity sha512-rL7kaUnTkL9K+Cvo2pnCieqNpTKgQzy5f+N+5Iuko9HAoasP+xgprVh7KN/MaJVvVL1l0EzQq2MoqBHKSrDrag==
+"@csstools/css-calc@^2.1.4":
+  version "2.1.4"
+  resolved "https://registry.npmjs.org/@csstools/css-calc/-/css-calc-2.1.4.tgz"
+  integrity sha512-3N8oaj+0juUw/1H3YwmDDJXCgTB1gKU6Hc/bB502u9zR0q2vd786XJH9QfrKIEgFlZmhZiq6epXl4rHqhzsIgQ==
 
-"@csstools/css-color-parser@^3.0.7":
-  version "3.0.7"
-  resolved "https://registry.npmjs.org/@csstools/css-color-parser/-/css-color-parser-3.0.7.tgz"
-  integrity sha512-nkMp2mTICw32uE5NN+EsJ4f5N+IGFeCFu4bGpiKgb2Pq/7J/MpyLBeQ5ry4KKtRFZaYs6sTmcMYrSRIyj5DFKA==
+"@csstools/css-color-parser@^3.1.0":
+  version "3.1.0"
+  resolved "https://registry.npmjs.org/@csstools/css-color-parser/-/css-color-parser-3.1.0.tgz"
+  integrity sha512-nbtKwh3a6xNVIp/VRuXV64yTKnb1IjTAEEh3irzS+HkKjAOYLTGNb9pmVNntZ8iVBHcWDA2Dof0QtPgFI1BaTA==
   dependencies:
-    "@csstools/color-helpers" "^5.0.1"
-    "@csstools/css-calc" "^2.1.1"
+    "@csstools/color-helpers" "^5.1.0"
+    "@csstools/css-calc" "^2.1.4"
+
+"@csstools/css-parser-algorithms@^3.0.5":
+  version "3.0.5"
+  resolved "https://registry.npmjs.org/@csstools/css-parser-algorithms/-/css-parser-algorithms-3.0.5.tgz"
+  integrity sha512-DaDeUkXZKjdGhgYaHNJTV9pV7Y9B3b644jCLs9Upc3VeNGg6LWARAT6O+Q+/COo+2gg/bM5rhpMAtf70WqfBdQ==
 
-"@csstools/css-parser-algorithms@^3.0.4":
+"@csstools/css-tokenizer@^3.0.4":
   version "3.0.4"
-  resolved "https://registry.npmjs.org/@csstools/css-parser-algorithms/-/css-parser-algorithms-3.0.4.tgz"
-  integrity sha512-Up7rBoV77rv29d3uKHUIVubz1BTcgyUK72IvCQAbfbMv584xHcGKCKbWh7i8hPrRJ7qU4Y8IO3IY9m+iTB7P3A==
+  resolved "https://registry.npmjs.org/@csstools/css-tokenizer/-/css-tokenizer-3.0.4.tgz"
+  integrity sha512-Vd/9EVDiu6PPJt9yAh6roZP6El1xHrdvIVGjyBsHR0RYwNHgL7FJPyIIW4fANJNG6FtyZfvlRPpFI4ZM/lubvw==
 
-"@csstools/css-tokenizer@^3.0.3":
-  version "3.0.3"
-  resolved "https://registry.npmjs.org/@csstools/css-tokenizer/-/css-tokenizer-3.0.3.tgz"
-  integrity sha512-UJnjoFsmxfKUdNYdWgOB0mWUypuLvAfQPH1+pyvRJs6euowbFkFC6P13w1l8mJyi3vxYMxc9kld5jZEGRQs6bw==
+"@csstools/media-query-list-parser@^4.0.3":
+  version "4.0.3"
+  resolved "https://registry.npmjs.org/@csstools/media-query-list-parser/-/media-query-list-parser-4.0.3.tgz"
+  integrity sha512-HAYH7d3TLRHDOUQK4mZKf9k9Ph/m8Akstg66ywKR4SFAigjs3yBiUeZtFxywiTm5moZMAp/5W/ZuFnNXXYLuuQ==
 
-"@csstools/media-query-list-parser@^4.0.2":
-  version "4.0.2"
-  resolved "https://registry.npmjs.org/@csstools/media-query-list-parser/-/media-query-list-parser-4.0.2.tgz"
-  integrity sha512-EUos465uvVvMJehckATTlNqGj4UJWkTmdWuDMjqvSUkjGpmOyFZBVwb4knxCm/k2GMTXY+c/5RkdndzFYWeX5A==
+"@csstools/postcss-alpha-function@^1.0.1":
+  version "1.0.1"
+  resolved "https://registry.npmjs.org/@csstools/postcss-alpha-function/-/postcss-alpha-function-1.0.1.tgz"
+  integrity sha512-isfLLwksH3yHkFXfCI2Gcaqg7wGGHZZwunoJzEZk0yKYIokgre6hYVFibKL3SYAoR1kBXova8LB+JoO5vZzi9w==
+  dependencies:
+    "@csstools/css-color-parser" "^3.1.0"
+    "@csstools/css-parser-algorithms" "^3.0.5"
+    "@csstools/css-tokenizer" "^3.0.4"
+    "@csstools/postcss-progressive-custom-properties" "^4.2.1"
+    "@csstools/utilities" "^2.0.0"
 
-"@csstools/postcss-cascade-layers@^5.0.1":
-  version "5.0.1"
-  resolved "https://registry.npmjs.org/@csstools/postcss-cascade-layers/-/postcss-cascade-layers-5.0.1.tgz"
-  integrity sha512-XOfhI7GShVcKiKwmPAnWSqd2tBR0uxt+runAxttbSp/LY2U16yAVPmAf7e9q4JJ0d+xMNmpwNDLBXnmRCl3HMQ==
+"@csstools/postcss-cascade-layers@^5.0.2":
+  version "5.0.2"
+  resolved "https://registry.npmjs.org/@csstools/postcss-cascade-layers/-/postcss-cascade-layers-5.0.2.tgz"
+  integrity sha512-nWBE08nhO8uWl6kSAeCx4im7QfVko3zLrtgWZY4/bP87zrSPpSyN/3W3TDqz1jJuH+kbKOHXg5rJnK+ZVYcFFg==
   dependencies:
     "@csstools/selector-specificity" "^5.0.0"
     postcss-selector-parser "^7.0.0"
 
-"@csstools/postcss-color-function@^4.0.7":
-  version "4.0.7"
-  resolved "https://registry.npmjs.org/@csstools/postcss-color-function/-/postcss-color-function-4.0.7.tgz"
-  integrity sha512-aDHYmhNIHR6iLw4ElWhf+tRqqaXwKnMl0YsQ/X105Zc4dQwe6yJpMrTN6BwOoESrkDjOYMOfORviSSLeDTJkdQ==
+"@csstools/postcss-color-function-display-p3-linear@^1.0.1":
+  version "1.0.1"
+  resolved "https://registry.npmjs.org/@csstools/postcss-color-function-display-p3-linear/-/postcss-color-function-display-p3-linear-1.0.1.tgz"
+  integrity sha512-E5qusdzhlmO1TztYzDIi8XPdPoYOjoTY6HBYBCYSj+Gn4gQRBlvjgPQXzfzuPQqt8EhkC/SzPKObg4Mbn8/xMg==
   dependencies:
-    "@csstools/css-color-parser" "^3.0.7"
-    "@csstools/css-parser-algorithms" "^3.0.4"
-    "@csstools/css-tokenizer" "^3.0.3"
-    "@csstools/postcss-progressive-custom-properties" "^4.0.0"
+    "@csstools/css-color-parser" "^3.1.0"
+    "@csstools/css-parser-algorithms" "^3.0.5"
+    "@csstools/css-tokenizer" "^3.0.4"
+    "@csstools/postcss-progressive-custom-properties" "^4.2.1"
     "@csstools/utilities" "^2.0.0"
 
-"@csstools/postcss-color-mix-function@^3.0.7":
-  version "3.0.7"
-  resolved "https://registry.npmjs.org/@csstools/postcss-color-mix-function/-/postcss-color-mix-function-3.0.7.tgz"
-  integrity sha512-e68Nev4CxZYCLcrfWhHH4u/N1YocOfTmw67/kVX5Rb7rnguqqLyxPjhHWjSBX8o4bmyuukmNf3wrUSU3//kT7g==
+"@csstools/postcss-color-function@^4.0.12":
+  version "4.0.12"
+  resolved "https://registry.npmjs.org/@csstools/postcss-color-function/-/postcss-color-function-4.0.12.tgz"
+  integrity sha512-yx3cljQKRaSBc2hfh8rMZFZzChaFgwmO2JfFgFr1vMcF3C/uyy5I4RFIBOIWGq1D+XbKCG789CGkG6zzkLpagA==
   dependencies:
-    "@csstools/css-color-parser" "^3.0.7"
-    "@csstools/css-parser-algorithms" "^3.0.4"
-    "@csstools/css-tokenizer" "^3.0.3"
-    "@csstools/postcss-progressive-custom-properties" "^4.0.0"
+    "@csstools/css-color-parser" "^3.1.0"
+    "@csstools/css-parser-algorithms" "^3.0.5"
+    "@csstools/css-tokenizer" "^3.0.4"
+    "@csstools/postcss-progressive-custom-properties" "^4.2.1"
     "@csstools/utilities" "^2.0.0"
 
-"@csstools/postcss-content-alt-text@^2.0.4":
-  version "2.0.4"
-  resolved "https://registry.npmjs.org/@csstools/postcss-content-alt-text/-/postcss-content-alt-text-2.0.4.tgz"
-  integrity sha512-YItlZUOuZJCBlRaCf8Aucc1lgN41qYGALMly0qQllrxYJhiyzlI6RxOTMUvtWk+KhS8GphMDsDhKQ7KTPfEMSw==
+"@csstools/postcss-color-mix-function@^3.0.12":
+  version "3.0.12"
+  resolved "https://registry.npmjs.org/@csstools/postcss-color-mix-function/-/postcss-color-mix-function-3.0.12.tgz"
+  integrity sha512-4STERZfCP5Jcs13P1U5pTvI9SkgLgfMUMhdXW8IlJWkzOOOqhZIjcNhWtNJZes2nkBDsIKJ0CJtFtuaZ00moag==
   dependencies:
-    "@csstools/css-parser-algorithms" "^3.0.4"
-    "@csstools/css-tokenizer" "^3.0.3"
-    "@csstools/postcss-progressive-custom-properties" "^4.0.0"
+    "@csstools/css-color-parser" "^3.1.0"
+    "@csstools/css-parser-algorithms" "^3.0.5"
+    "@csstools/css-tokenizer" "^3.0.4"
+    "@csstools/postcss-progressive-custom-properties" "^4.2.1"
     "@csstools/utilities" "^2.0.0"
 
-"@csstools/postcss-exponential-functions@^2.0.6":
-  version "2.0.6"
-  resolved "https://registry.npmjs.org/@csstools/postcss-exponential-functions/-/postcss-exponential-functions-2.0.6.tgz"
-  integrity sha512-IgJA5DQsQLu/upA3HcdvC6xEMR051ufebBTIXZ5E9/9iiaA7juXWz1ceYj814lnDYP/7eWjZnw0grRJlX4eI6g==
+"@csstools/postcss-color-mix-variadic-function-arguments@^1.0.2":
+  version "1.0.2"
+  resolved "https://registry.npmjs.org/@csstools/postcss-color-mix-variadic-function-arguments/-/postcss-color-mix-variadic-function-arguments-1.0.2.tgz"
+  integrity sha512-rM67Gp9lRAkTo+X31DUqMEq+iK+EFqsidfecmhrteErxJZb6tUoJBVQca1Vn1GpDql1s1rD1pKcuYzMsg7Z1KQ==
+  dependencies:
+    "@csstools/css-color-parser" "^3.1.0"
+    "@csstools/css-parser-algorithms" "^3.0.5"
+    "@csstools/css-tokenizer" "^3.0.4"
+    "@csstools/postcss-progressive-custom-properties" "^4.2.1"
+    "@csstools/utilities" "^2.0.0"
+
+"@csstools/postcss-content-alt-text@^2.0.8":
+  version "2.0.8"
+  resolved "https://registry.npmjs.org/@csstools/postcss-content-alt-text/-/postcss-content-alt-text-2.0.8.tgz"
+  integrity sha512-9SfEW9QCxEpTlNMnpSqFaHyzsiRpZ5J5+KqCu1u5/eEJAWsMhzT40qf0FIbeeglEvrGRMdDzAxMIz3wqoGSb+Q==
+  dependencies:
+    "@csstools/css-parser-algorithms" "^3.0.5"
+    "@csstools/css-tokenizer" "^3.0.4"
+    "@csstools/postcss-progressive-custom-properties" "^4.2.1"
+    "@csstools/utilities" "^2.0.0"
+
+"@csstools/postcss-contrast-color-function@^2.0.12":
+  version "2.0.12"
+  resolved "https://registry.npmjs.org/@csstools/postcss-contrast-color-function/-/postcss-contrast-color-function-2.0.12.tgz"
+  integrity sha512-YbwWckjK3qwKjeYz/CijgcS7WDUCtKTd8ShLztm3/i5dhh4NaqzsbYnhm4bjrpFpnLZ31jVcbK8YL77z3GBPzA==
   dependencies:
-    "@csstools/css-calc" "^2.1.1"
-    "@csstools/css-parser-algorithms" "^3.0.4"
-    "@csstools/css-tokenizer" "^3.0.3"
+    "@csstools/css-color-parser" "^3.1.0"
+    "@csstools/css-parser-algorithms" "^3.0.5"
+    "@csstools/css-tokenizer" "^3.0.4"
+    "@csstools/postcss-progressive-custom-properties" "^4.2.1"
+    "@csstools/utilities" "^2.0.0"
+
+"@csstools/postcss-exponential-functions@^2.0.9":
+  version "2.0.9"
+  resolved "https://registry.npmjs.org/@csstools/postcss-exponential-functions/-/postcss-exponential-functions-2.0.9.tgz"
+  integrity sha512-abg2W/PI3HXwS/CZshSa79kNWNZHdJPMBXeZNyPQFbbj8sKO3jXxOt/wF7juJVjyDTc6JrvaUZYFcSBZBhaxjw==
+  dependencies:
+    "@csstools/css-calc" "^2.1.4"
+    "@csstools/css-parser-algorithms" "^3.0.5"
+    "@csstools/css-tokenizer" "^3.0.4"
 
 "@csstools/postcss-font-format-keywords@^4.0.0":
   version "4.0.0"
@@ -1146,67 +1233,67 @@
     "@csstools/utilities" "^2.0.0"
     postcss-value-parser "^4.2.0"
 
-"@csstools/postcss-gamut-mapping@^2.0.7":
-  version "2.0.7"
-  resolved "https://registry.npmjs.org/@csstools/postcss-gamut-mapping/-/postcss-gamut-mapping-2.0.7.tgz"
-  integrity sha512-gzFEZPoOkY0HqGdyeBXR3JP218Owr683u7KOZazTK7tQZBE8s2yhg06W1tshOqk7R7SWvw9gkw2TQogKpIW8Xw==
-  dependencies:
-    "@csstools/css-color-parser" "^3.0.7"
-    "@csstools/css-parser-algorithms" "^3.0.4"
-    "@csstools/css-tokenizer" "^3.0.3"
-
-"@csstools/postcss-gradients-interpolation-method@^5.0.7":
-  version "5.0.7"
-  resolved "https://registry.npmjs.org/@csstools/postcss-gradients-interpolation-method/-/postcss-gradients-interpolation-method-5.0.7.tgz"
-  integrity sha512-WgEyBeg6glUeTdS2XT7qeTFBthTJuXlS9GFro/DVomj7W7WMTamAwpoP4oQCq/0Ki2gvfRYFi/uZtmRE14/DFA==
-  dependencies:
-    "@csstools/css-color-parser" "^3.0.7"
-    "@csstools/css-parser-algorithms" "^3.0.4"
-    "@csstools/css-tokenizer" "^3.0.3"
-    "@csstools/postcss-progressive-custom-properties" "^4.0.0"
+"@csstools/postcss-gamut-mapping@^2.0.11":
+  version "2.0.11"
+  resolved "https://registry.npmjs.org/@csstools/postcss-gamut-mapping/-/postcss-gamut-mapping-2.0.11.tgz"
+  integrity sha512-fCpCUgZNE2piVJKC76zFsgVW1apF6dpYsqGyH8SIeCcM4pTEsRTWTLCaJIMKFEundsCKwY1rwfhtrio04RJ4Dw==
+  dependencies:
+    "@csstools/css-color-parser" "^3.1.0"
+    "@csstools/css-parser-algorithms" "^3.0.5"
+    "@csstools/css-tokenizer" "^3.0.4"
+
+"@csstools/postcss-gradients-interpolation-method@^5.0.12":
+  version "5.0.12"
+  resolved "https://registry.npmjs.org/@csstools/postcss-gradients-interpolation-method/-/postcss-gradients-interpolation-method-5.0.12.tgz"
+  integrity sha512-jugzjwkUY0wtNrZlFeyXzimUL3hN4xMvoPnIXxoZqxDvjZRiSh+itgHcVUWzJ2VwD/VAMEgCLvtaJHX+4Vj3Ow==
+  dependencies:
+    "@csstools/css-color-parser" "^3.1.0"
+    "@csstools/css-parser-algorithms" "^3.0.5"
+    "@csstools/css-tokenizer" "^3.0.4"
+    "@csstools/postcss-progressive-custom-properties" "^4.2.1"
     "@csstools/utilities" "^2.0.0"
 
-"@csstools/postcss-hwb-function@^4.0.7":
-  version "4.0.7"
-  resolved "https://registry.npmjs.org/@csstools/postcss-hwb-function/-/postcss-hwb-function-4.0.7.tgz"
-  integrity sha512-LKYqjO+wGwDCfNIEllessCBWfR4MS/sS1WXO+j00KKyOjm7jDW2L6jzUmqASEiv/kkJO39GcoIOvTTfB3yeBUA==
+"@csstools/postcss-hwb-function@^4.0.12":
+  version "4.0.12"
+  resolved "https://registry.npmjs.org/@csstools/postcss-hwb-function/-/postcss-hwb-function-4.0.12.tgz"
+  integrity sha512-mL/+88Z53KrE4JdePYFJAQWFrcADEqsLprExCM04GDNgHIztwFzj0Mbhd/yxMBngq0NIlz58VVxjt5abNs1VhA==
   dependencies:
-    "@csstools/css-color-parser" "^3.0.7"
-    "@csstools/css-parser-algorithms" "^3.0.4"
-    "@csstools/css-tokenizer" "^3.0.3"
-    "@csstools/postcss-progressive-custom-properties" "^4.0.0"
+    "@csstools/css-color-parser" "^3.1.0"
+    "@csstools/css-parser-algorithms" "^3.0.5"
+    "@csstools/css-tokenizer" "^3.0.4"
+    "@csstools/postcss-progressive-custom-properties" "^4.2.1"
     "@csstools/utilities" "^2.0.0"
 
-"@csstools/postcss-ic-unit@^4.0.0":
-  version "4.0.0"
-  resolved "https://registry.npmjs.org/@csstools/postcss-ic-unit/-/postcss-ic-unit-4.0.0.tgz"
-  integrity sha512-9QT5TDGgx7wD3EEMN3BSUG6ckb6Eh5gSPT5kZoVtUuAonfPmLDJyPhqR4ntPpMYhUKAMVKAg3I/AgzqHMSeLhA==
+"@csstools/postcss-ic-unit@^4.0.4":
+  version "4.0.4"
+  resolved "https://registry.npmjs.org/@csstools/postcss-ic-unit/-/postcss-ic-unit-4.0.4.tgz"
+  integrity sha512-yQ4VmossuOAql65sCPppVO1yfb7hDscf4GseF0VCA/DTDaBc0Wtf8MTqVPfjGYlT5+2buokG0Gp7y0atYZpwjg==
   dependencies:
-    "@csstools/postcss-progressive-custom-properties" "^4.0.0"
+    "@csstools/postcss-progressive-custom-properties" "^4.2.1"
     "@csstools/utilities" "^2.0.0"
     postcss-value-parser "^4.2.0"
 
-"@csstools/postcss-initial@^2.0.0":
-  version "2.0.0"
-  resolved "https://registry.npmjs.org/@csstools/postcss-initial/-/postcss-initial-2.0.0.tgz"
-  integrity sha512-dv2lNUKR+JV+OOhZm9paWzYBXOCi+rJPqJ2cJuhh9xd8USVrd0cBEPczla81HNOyThMQWeCcdln3gZkQV2kYxA==
+"@csstools/postcss-initial@^2.0.1":
+  version "2.0.1"
+  resolved "https://registry.npmjs.org/@csstools/postcss-initial/-/postcss-initial-2.0.1.tgz"
+  integrity sha512-L1wLVMSAZ4wovznquK0xmC7QSctzO4D0Is590bxpGqhqjboLXYA16dWZpfwImkdOgACdQ9PqXsuRroW6qPlEsg==
 
-"@csstools/postcss-is-pseudo-class@^5.0.1":
-  version "5.0.1"
-  resolved "https://registry.npmjs.org/@csstools/postcss-is-pseudo-class/-/postcss-is-pseudo-class-5.0.1.tgz"
-  integrity sha512-JLp3POui4S1auhDR0n8wHd/zTOWmMsmK3nQd3hhL6FhWPaox5W7j1se6zXOG/aP07wV2ww0lxbKYGwbBszOtfQ==
+"@csstools/postcss-is-pseudo-class@^5.0.3":
+  version "5.0.3"
+  resolved "https://registry.npmjs.org/@csstools/postcss-is-pseudo-class/-/postcss-is-pseudo-class-5.0.3.tgz"
+  integrity sha512-jS/TY4SpG4gszAtIg7Qnf3AS2pjcUM5SzxpApOrlndMeGhIbaTzWBzzP/IApXoNWEW7OhcjkRT48jnAUIFXhAQ==
   dependencies:
     "@csstools/selector-specificity" "^5.0.0"
     postcss-selector-parser "^7.0.0"
 
-"@csstools/postcss-light-dark-function@^2.0.7":
-  version "2.0.7"
-  resolved "https://registry.npmjs.org/@csstools/postcss-light-dark-function/-/postcss-light-dark-function-2.0.7.tgz"
-  integrity sha512-ZZ0rwlanYKOHekyIPaU+sVm3BEHCe+Ha0/px+bmHe62n0Uc1lL34vbwrLYn6ote8PHlsqzKeTQdIejQCJ05tfw==
+"@csstools/postcss-light-dark-function@^2.0.11":
+  version "2.0.11"
+  resolved "https://registry.npmjs.org/@csstools/postcss-light-dark-function/-/postcss-light-dark-function-2.0.11.tgz"
+  integrity sha512-fNJcKXJdPM3Lyrbmgw2OBbaioU7yuKZtiXClf4sGdQttitijYlZMD5K7HrC/eF83VRWRrYq6OZ0Lx92leV2LFA==
   dependencies:
-    "@csstools/css-parser-algorithms" "^3.0.4"
-    "@csstools/css-tokenizer" "^3.0.3"
-    "@csstools/postcss-progressive-custom-properties" "^4.0.0"
+    "@csstools/css-parser-algorithms" "^3.0.5"
+    "@csstools/css-tokenizer" "^3.0.4"
+    "@csstools/postcss-progressive-custom-properties" "^4.2.1"
     "@csstools/utilities" "^2.0.0"
 
 "@csstools/postcss-logical-float-and-clear@^3.0.0":
@@ -1231,32 +1318,32 @@
   dependencies:
     postcss-value-parser "^4.2.0"
 
-"@csstools/postcss-logical-viewport-units@^3.0.3":
-  version "3.0.3"
-  resolved "https://registry.npmjs.org/@csstools/postcss-logical-viewport-units/-/postcss-logical-viewport-units-3.0.3.tgz"
-  integrity sha512-OC1IlG/yoGJdi0Y+7duz/kU/beCwO+Gua01sD6GtOtLi7ByQUpcIqs7UE/xuRPay4cHgOMatWdnDdsIDjnWpPw==
+"@csstools/postcss-logical-viewport-units@^3.0.4":
+  version "3.0.4"
+  resolved "https://registry.npmjs.org/@csstools/postcss-logical-viewport-units/-/postcss-logical-viewport-units-3.0.4.tgz"
+  integrity sha512-q+eHV1haXA4w9xBwZLKjVKAWn3W2CMqmpNpZUk5kRprvSiBEGMgrNH3/sJZ8UA3JgyHaOt3jwT9uFa4wLX4EqQ==
   dependencies:
-    "@csstools/css-tokenizer" "^3.0.3"
+    "@csstools/css-tokenizer" "^3.0.4"
     "@csstools/utilities" "^2.0.0"
 
-"@csstools/postcss-media-minmax@^2.0.6":
-  version "2.0.6"
-  resolved "https://registry.npmjs.org/@csstools/postcss-media-minmax/-/postcss-media-minmax-2.0.6.tgz"
-  integrity sha512-J1+4Fr2W3pLZsfxkFazK+9kr96LhEYqoeBszLmFjb6AjYs+g9oDAw3J5oQignLKk3rC9XHW+ebPTZ9FaW5u5pg==
+"@csstools/postcss-media-minmax@^2.0.9":
+  version "2.0.9"
+  resolved "https://registry.npmjs.org/@csstools/postcss-media-minmax/-/postcss-media-minmax-2.0.9.tgz"
+  integrity sha512-af9Qw3uS3JhYLnCbqtZ9crTvvkR+0Se+bBqSr7ykAnl9yKhk6895z9rf+2F4dClIDJWxgn0iZZ1PSdkhrbs2ig==
   dependencies:
-    "@csstools/css-calc" "^2.1.1"
-    "@csstools/css-parser-algorithms" "^3.0.4"
-    "@csstools/css-tokenizer" "^3.0.3"
-    "@csstools/media-query-list-parser" "^4.0.2"
+    "@csstools/css-calc" "^2.1.4"
+    "@csstools/css-parser-algorithms" "^3.0.5"
+    "@csstools/css-tokenizer" "^3.0.4"
+    "@csstools/media-query-list-parser" "^4.0.3"
 
-"@csstools/postcss-media-queries-aspect-ratio-number-values@^3.0.4":
-  version "3.0.4"
-  resolved "https://registry.npmjs.org/@csstools/postcss-media-queries-aspect-ratio-number-values/-/postcss-media-queries-aspect-ratio-number-values-3.0.4.tgz"
-  integrity sha512-AnGjVslHMm5xw9keusQYvjVWvuS7KWK+OJagaG0+m9QnIjZsrysD2kJP/tr/UJIyYtMCtu8OkUd+Rajb4DqtIQ==
+"@csstools/postcss-media-queries-aspect-ratio-number-values@^3.0.5":
+  version "3.0.5"
+  resolved "https://registry.npmjs.org/@csstools/postcss-media-queries-aspect-ratio-number-values/-/postcss-media-queries-aspect-ratio-number-values-3.0.5.tgz"
+  integrity sha512-zhAe31xaaXOY2Px8IYfoVTB3wglbJUVigGphFLj6exb7cjZRH9A6adyE22XfFK3P2PzwRk0VDeTJmaxpluyrDg==
   dependencies:
-    "@csstools/css-parser-algorithms" "^3.0.4"
-    "@csstools/css-tokenizer" "^3.0.3"
-    "@csstools/media-query-list-parser" "^4.0.2"
+    "@csstools/css-parser-algorithms" "^3.0.5"
+    "@csstools/css-tokenizer" "^3.0.4"
+    "@csstools/media-query-list-parser" "^4.0.3"
 
 "@csstools/postcss-nested-calc@^4.0.0":
   version "4.0.0"
@@ -1266,49 +1353,62 @@
     "@csstools/utilities" "^2.0.0"
     postcss-value-parser "^4.2.0"
 
-"@csstools/postcss-normalize-display-values@^4.0.0":
-  version "4.0.0"
-  resolved "https://registry.npmjs.org/@csstools/postcss-normalize-display-values/-/postcss-normalize-display-values-4.0.0.tgz"
-  integrity sha512-HlEoG0IDRoHXzXnkV4in47dzsxdsjdz6+j7MLjaACABX2NfvjFS6XVAnpaDyGesz9gK2SC7MbNwdCHusObKJ9Q==
+"@csstools/postcss-normalize-display-values@^4.0.1":
+  version "4.0.1"
+  resolved "https://registry.npmjs.org/@csstools/postcss-normalize-display-values/-/postcss-normalize-display-values-4.0.1.tgz"
+  integrity sha512-TQUGBuRvxdc7TgNSTevYqrL8oItxiwPDixk20qCB5me/W8uF7BPbhRrAvFuhEoywQp/woRsUZ6SJ+sU5idZAIA==
   dependencies:
     postcss-value-parser "^4.2.0"
 
-"@csstools/postcss-oklab-function@^4.0.7":
-  version "4.0.7"
-  resolved "https://registry.npmjs.org/@csstools/postcss-oklab-function/-/postcss-oklab-function-4.0.7.tgz"
-  integrity sha512-I6WFQIbEKG2IO3vhaMGZDkucbCaUSXMxvHNzDdnfsTCF5tc0UlV3Oe2AhamatQoKFjBi75dSEMrgWq3+RegsOQ==
+"@csstools/postcss-oklab-function@^4.0.12":
+  version "4.0.12"
+  resolved "https://registry.npmjs.org/@csstools/postcss-oklab-function/-/postcss-oklab-function-4.0.12.tgz"
+  integrity sha512-HhlSmnE1NKBhXsTnNGjxvhryKtO7tJd1w42DKOGFD6jSHtYOrsJTQDKPMwvOfrzUAk8t7GcpIfRyM7ssqHpFjg==
   dependencies:
-    "@csstools/css-color-parser" "^3.0.7"
-    "@csstools/css-parser-algorithms" "^3.0.4"
-    "@csstools/css-tokenizer" "^3.0.3"
-    "@csstools/postcss-progressive-custom-properties" "^4.0.0"
+    "@csstools/css-color-parser" "^3.1.0"
+    "@csstools/css-parser-algorithms" "^3.0.5"
+    "@csstools/css-tokenizer" "^3.0.4"
+    "@csstools/postcss-progressive-custom-properties" "^4.2.1"
     "@csstools/utilities" "^2.0.0"
 
-"@csstools/postcss-progressive-custom-properties@^4.0.0":
-  version "4.0.0"
-  resolved "https://registry.npmjs.org/@csstools/postcss-progressive-custom-properties/-/postcss-progressive-custom-properties-4.0.0.tgz"
-  integrity sha512-XQPtROaQjomnvLUSy/bALTR5VCtTVUFwYs1SblvYgLSeTo2a/bMNwUwo2piXw5rTv/FEYiy5yPSXBqg9OKUx7Q==
+"@csstools/postcss-position-area-property@^1.0.0":
+  version "1.0.0"
+  resolved "https://registry.npmjs.org/@csstools/postcss-position-area-property/-/postcss-position-area-property-1.0.0.tgz"
+  integrity sha512-fUP6KR8qV2NuUZV3Cw8itx0Ep90aRjAZxAEzC3vrl6yjFv+pFsQbR18UuQctEKmA72K9O27CoYiKEgXxkqjg8Q==
+
+"@csstools/postcss-progressive-custom-properties@^4.2.1":
+  version "4.2.1"
+  resolved "https://registry.npmjs.org/@csstools/postcss-progressive-custom-properties/-/postcss-progressive-custom-properties-4.2.1.tgz"
+  integrity sha512-uPiiXf7IEKtUQXsxu6uWtOlRMXd2QWWy5fhxHDnPdXKCQckPP3E34ZgDoZ62r2iT+UOgWsSbM4NvHE5m3mAEdw==
   dependencies:
     postcss-value-parser "^4.2.0"
 
-"@csstools/postcss-random-function@^1.0.2":
-  version "1.0.2"
-  resolved "https://registry.npmjs.org/@csstools/postcss-random-function/-/postcss-random-function-1.0.2.tgz"
-  integrity sha512-vBCT6JvgdEkvRc91NFoNrLjgGtkLWt47GKT6E2UDn3nd8ZkMBiziQ1Md1OiKoSsgzxsSnGKG3RVdhlbdZEkHjA==
+"@csstools/postcss-property-rule-prelude-list@^1.0.0":
+  version "1.0.0"
+  resolved "https://registry.npmjs.org/@csstools/postcss-property-rule-prelude-list/-/postcss-property-rule-prelude-list-1.0.0.tgz"
+  integrity sha512-IxuQjUXq19fobgmSSvUDO7fVwijDJaZMvWQugxfEUxmjBeDCVaDuMpsZ31MsTm5xbnhA+ElDi0+rQ7sQQGisFA==
   dependencies:
-    "@csstools/css-calc" "^2.1.1"
-    "@csstools/css-parser-algorithms" "^3.0.4"
-    "@csstools/css-tokenizer" "^3.0.3"
+    "@csstools/css-parser-algorithms" "^3.0.5"
+    "@csstools/css-tokenizer" "^3.0.4"
 
-"@csstools/postcss-relative-color-syntax@^3.0.7":
-  version "3.0.7"
-  resolved "https://registry.npmjs.org/@csstools/postcss-relative-color-syntax/-/postcss-relative-color-syntax-3.0.7.tgz"
-  integrity sha512-apbT31vsJVd18MabfPOnE977xgct5B1I+Jpf+Munw3n6kKb1MMuUmGGH+PT9Hm/fFs6fe61Q/EWnkrb4bNoNQw==
-  dependencies:
-    "@csstools/css-color-parser" "^3.0.7"
-    "@csstools/css-parser-algorithms" "^3.0.4"
-    "@csstools/css-tokenizer" "^3.0.3"
-    "@csstools/postcss-progressive-custom-properties" "^4.0.0"
+"@csstools/postcss-random-function@^2.0.1":
+  version "2.0.1"
+  resolved "https://registry.npmjs.org/@csstools/postcss-random-function/-/postcss-random-function-2.0.1.tgz"
+  integrity sha512-q+FQaNiRBhnoSNo+GzqGOIBKoHQ43lYz0ICrV+UudfWnEF6ksS6DsBIJSISKQT2Bvu3g4k6r7t0zYrk5pDlo8w==
+  dependencies:
+    "@csstools/css-calc" "^2.1.4"
+    "@csstools/css-parser-algorithms" "^3.0.5"
+    "@csstools/css-tokenizer" "^3.0.4"
+
+"@csstools/postcss-relative-color-syntax@^3.0.12":
+  version "3.0.12"
+  resolved "https://registry.npmjs.org/@csstools/postcss-relative-color-syntax/-/postcss-relative-color-syntax-3.0.12.tgz"
+  integrity sha512-0RLIeONxu/mtxRtf3o41Lq2ghLimw0w9ByLWnnEVuy89exmEEq8bynveBxNW3nyHqLAFEeNtVEmC1QK9MZ8Huw==
+  dependencies:
+    "@csstools/css-color-parser" "^3.1.0"
+    "@csstools/css-parser-algorithms" "^3.0.5"
+    "@csstools/css-tokenizer" "^3.0.4"
+    "@csstools/postcss-progressive-custom-properties" "^4.2.1"
     "@csstools/utilities" "^2.0.0"
 
 "@csstools/postcss-scope-pseudo-class@^4.0.1":
@@ -1318,50 +1418,65 @@
   dependencies:
     postcss-selector-parser "^7.0.0"
 
-"@csstools/postcss-sign-functions@^1.1.1":
-  version "1.1.1"
-  resolved "https://registry.npmjs.org/@csstools/postcss-sign-functions/-/postcss-sign-functions-1.1.1.tgz"
-  integrity sha512-MslYkZCeMQDxetNkfmmQYgKCy4c+w9pPDfgOBCJOo/RI1RveEUdZQYtOfrC6cIZB7sD7/PHr2VGOcMXlZawrnA==
+"@csstools/postcss-sign-functions@^1.1.4":
+  version "1.1.4"
+  resolved "https://registry.npmjs.org/@csstools/postcss-sign-functions/-/postcss-sign-functions-1.1.4.tgz"
+  integrity sha512-P97h1XqRPcfcJndFdG95Gv/6ZzxUBBISem0IDqPZ7WMvc/wlO+yU0c5D/OCpZ5TJoTt63Ok3knGk64N+o6L2Pg==
   dependencies:
-    "@csstools/css-calc" "^2.1.1"
-    "@csstools/css-parser-algorithms" "^3.0.4"
-    "@csstools/css-tokenizer" "^3.0.3"
+    "@csstools/css-calc" "^2.1.4"
+    "@csstools/css-parser-algorithms" "^3.0.5"
+    "@csstools/css-tokenizer" "^3.0.4"
 
-"@csstools/postcss-stepped-value-functions@^4.0.6":
-  version "4.0.6"
-  resolved "https://registry.npmjs.org/@csstools/postcss-stepped-value-functions/-/postcss-stepped-value-functions-4.0.6.tgz"
-  integrity sha512-/dwlO9w8vfKgiADxpxUbZOWlL5zKoRIsCymYoh1IPuBsXODKanKnfuZRr32DEqT0//3Av1VjfNZU9yhxtEfIeA==
+"@csstools/postcss-stepped-value-functions@^4.0.9":
+  version "4.0.9"
+  resolved "https://registry.npmjs.org/@csstools/postcss-stepped-value-functions/-/postcss-stepped-value-functions-4.0.9.tgz"
+  integrity sha512-h9btycWrsex4dNLeQfyU3y3w40LMQooJWFMm/SK9lrKguHDcFl4VMkncKKoXi2z5rM9YGWbUQABI8BT2UydIcA==
   dependencies:
-    "@csstools/css-calc" "^2.1.1"
-    "@csstools/css-parser-algorithms" "^3.0.4"
-    "@csstools/css-tokenizer" "^3.0.3"
+    "@csstools/css-calc" "^2.1.4"
+    "@csstools/css-parser-algorithms" "^3.0.5"
+    "@csstools/css-tokenizer" "^3.0.4"
 
-"@csstools/postcss-text-decoration-shorthand@^4.0.1":
-  version "4.0.1"
-  resolved "https://registry.npmjs.org/@csstools/postcss-text-decoration-shorthand/-/postcss-text-decoration-shorthand-4.0.1.tgz"
-  integrity sha512-xPZIikbx6jyzWvhms27uugIc0I4ykH4keRvoa3rxX5K7lEhkbd54rjj/dv60qOCTisoS+3bmwJTeyV1VNBrXaw==
+"@csstools/postcss-syntax-descriptor-syntax-production@^1.0.1":
+  version "1.0.1"
+  resolved "https://registry.npmjs.org/@csstools/postcss-syntax-descriptor-syntax-production/-/postcss-syntax-descriptor-syntax-production-1.0.1.tgz"
+  integrity sha512-GneqQWefjM//f4hJ/Kbox0C6f2T7+pi4/fqTqOFGTL3EjnvOReTqO1qUQ30CaUjkwjYq9qZ41hzarrAxCc4gow==
+  dependencies:
+    "@csstools/css-tokenizer" "^3.0.4"
+
+"@csstools/postcss-system-ui-font-family@^1.0.0":
+  version "1.0.0"
+  resolved "https://registry.npmjs.org/@csstools/postcss-system-ui-font-family/-/postcss-system-ui-font-family-1.0.0.tgz"
+  integrity sha512-s3xdBvfWYfoPSBsikDXbuorcMG1nN1M6GdU0qBsGfcmNR0A/qhloQZpTxjA3Xsyrk1VJvwb2pOfiOT3at/DuIQ==
+  dependencies:
+    "@csstools/css-parser-algorithms" "^3.0.5"
+    "@csstools/css-tokenizer" "^3.0.4"
+
+"@csstools/postcss-text-decoration-shorthand@^4.0.3":
+  version "4.0.3"
+  resolved "https://registry.npmjs.org/@csstools/postcss-text-decoration-shorthand/-/postcss-text-decoration-shorthand-4.0.3.tgz"
+  integrity sha512-KSkGgZfx0kQjRIYnpsD7X2Om9BUXX/Kii77VBifQW9Ih929hK0KNjVngHDH0bFB9GmfWcR9vJYJJRvw/NQjkrA==
   dependencies:
-    "@csstools/color-helpers" "^5.0.1"
+    "@csstools/color-helpers" "^5.1.0"
     postcss-value-parser "^4.2.0"
 
-"@csstools/postcss-trigonometric-functions@^4.0.6":
-  version "4.0.6"
-  resolved "https://registry.npmjs.org/@csstools/postcss-trigonometric-functions/-/postcss-trigonometric-functions-4.0.6.tgz"
-  integrity sha512-c4Y1D2Why/PeccaSouXnTt6WcNHJkoJRidV2VW9s5gJ97cNxnLgQ4Qj8qOqkIR9VmTQKJyNcbF4hy79ZQnWD7A==
+"@csstools/postcss-trigonometric-functions@^4.0.9":
+  version "4.0.9"
+  resolved "https://registry.npmjs.org/@csstools/postcss-trigonometric-functions/-/postcss-trigonometric-functions-4.0.9.tgz"
+  integrity sha512-Hnh5zJUdpNrJqK9v1/E3BbrQhaDTj5YiX7P61TOvUhoDHnUmsNNxcDAgkQ32RrcWx9GVUvfUNPcUkn8R3vIX6A==
   dependencies:
-    "@csstools/css-calc" "^2.1.1"
-    "@csstools/css-parser-algorithms" "^3.0.4"
-    "@csstools/css-tokenizer" "^3.0.3"
+    "@csstools/css-calc" "^2.1.4"
+    "@csstools/css-parser-algorithms" "^3.0.5"
+    "@csstools/css-tokenizer" "^3.0.4"
 
 "@csstools/postcss-unset-value@^4.0.0":
   version "4.0.0"
   resolved "https://registry.npmjs.org/@csstools/postcss-unset-value/-/postcss-unset-value-4.0.0.tgz"
   integrity sha512-cBz3tOCI5Fw6NIFEwU3RiwK6mn3nKegjpJuzCndoGq3BZPkUjnsq7uQmIeMNeMbMk7YD2MfKcgCpZwX5jyXqCA==
 
-"@csstools/selector-resolve-nested@^3.0.0":
-  version "3.0.0"
-  resolved "https://registry.npmjs.org/@csstools/selector-resolve-nested/-/selector-resolve-nested-3.0.0.tgz"
-  integrity sha512-ZoK24Yku6VJU1gS79a5PFmC8yn3wIapiKmPgun0hZgEI5AOqgH2kiPRsPz1qkGv4HL+wuDLH83yQyk6inMYrJQ==
+"@csstools/selector-resolve-nested@^3.1.0":
+  version "3.1.0"
+  resolved "https://registry.npmjs.org/@csstools/selector-resolve-nested/-/selector-resolve-nested-3.1.0.tgz"
+  integrity sha512-mf1LEW0tJLKfWyvn5KdDrhpxHyuxpbNwTIwOYLIvsTffeyOf85j5oIzfG0yosxDgx/sswlqBnESYUcQH0vgZ0g==
 
 "@csstools/selector-specificity@^5.0.0":
   version "5.0.0"
@@ -1378,25 +1493,34 @@
   resolved "https://registry.npmjs.org/@discoveryjs/json-ext/-/json-ext-0.5.7.tgz"
   integrity sha512-dBVuXR082gk3jsFp7Rd/JI4kytwGHecnCoTtXFb7DB6CNHp4rg5k1bhg0nWdLGLnOV71lmDzGQaLMy8iPLY0pw==
 
-"@docsearch/css@3.8.2":
-  version "3.8.2"
-  resolved "https://registry.npmjs.org/@docsearch/css/-/css-3.8.2.tgz"
-  integrity sha512-y05ayQFyUmCXze79+56v/4HpycYF3uFqB78pLPrSV5ZKAlDuIAAJNhaRi8tTdRNXh05yxX/TyNnzD6LwSM89vQ==
+"@docsearch/core@4.4.0":
+  version "4.4.0"
+  resolved "https://registry.npmjs.org/@docsearch/core/-/core-4.4.0.tgz"
+  integrity sha512-kiwNo5KEndOnrf5Kq/e5+D9NBMCFgNsDoRpKQJ9o/xnSlheh6b8AXppMuuUVVdAUIhIfQFk/07VLjjk/fYyKmw==
 
-"@docsearch/react@^3.8.1":
-  version "3.8.2"
-  resolved "https://registry.npmjs.org/@docsearch/react/-/react-3.8.2.tgz"
-  integrity sha512-xCRrJQlTt8N9GU0DG4ptwHRkfnSnD/YpdeaXe02iKfqs97TkZJv60yE+1eq/tjPcVnTW8dP5qLP7itifFVV5eg==
-  dependencies:
-    "@algolia/autocomplete-core" "1.17.7"
-    "@algolia/autocomplete-preset-algolia" "1.17.7"
-    "@docsearch/css" "3.8.2"
-    algoliasearch "^5.14.2"
+"@docsearch/css@4.4.0":
+  version "4.4.0"
+  resolved "https://registry.npmjs.org/@docsearch/css/-/css-4.4.0.tgz"
+  integrity sha512-e9vPgtih6fkawakmYo0Y6V4BKBmDV7Ykudn7ADWXUs5b6pmtBRwDbpSG/WiaUG63G28OkJDEnsMvgIAnZgGwYw==
 
-"@docusaurus/babel@3.7.0":
-  version "3.7.0"
-  resolved "https://registry.npmjs.org/@docusaurus/babel/-/babel-3.7.0.tgz"
-  integrity sha512-0H5uoJLm14S/oKV3Keihxvh8RV+vrid+6Gv+2qhuzbqHanawga8tYnsdpjEyt36ucJjqlby2/Md2ObWjA02UXQ==
+"@docsearch/react@^3.9.0 || ^4.1.0":
+  version "4.4.0"
+  resolved "https://registry.npmjs.org/@docsearch/react/-/react-4.4.0.tgz"
+  integrity sha512-z12zeg1mV7WD4Ag4pKSuGukETJLaucVFwszDXL/qLaEgRqxEaVacO9SR1qqnCXvZztlvz2rt7cMqryi/7sKfjA==
+  dependencies:
+    "@ai-sdk/react" "^2.0.30"
+    "@algolia/autocomplete-core" "1.19.2"
+    "@docsearch/core" "4.4.0"
+    "@docsearch/css" "4.4.0"
+    ai "^5.0.30"
+    algoliasearch "^5.28.0"
+    marked "^16.3.0"
+    zod "^4.1.8"
+
+"@docusaurus/babel@3.9.2":
+  version "3.9.2"
+  resolved "https://registry.npmjs.org/@docusaurus/babel/-/babel-3.9.2.tgz"
+  integrity sha512-GEANdi/SgER+L7Japs25YiGil/AUDnFFHaCGPBbundxoWtCkA2lmy7/tFmgED4y1htAy6Oi4wkJEQdGssnw9MA==
   dependencies:
     "@babel/core" "^7.25.9"
     "@babel/generator" "^7.25.9"
@@ -1408,55 +1532,54 @@
     "@babel/runtime" "^7.25.9"
     "@babel/runtime-corejs3" "^7.25.9"
     "@babel/traverse" "^7.25.9"
-    "@docusaurus/logger" "3.7.0"
-    "@docusaurus/utils" "3.7.0"
+    "@docusaurus/logger" "3.9.2"
+    "@docusaurus/utils" "3.9.2"
     babel-plugin-dynamic-import-node "^2.3.3"
     fs-extra "^11.1.1"
     tslib "^2.6.0"
 
-"@docusaurus/bundler@3.7.0":
-  version "3.7.0"
-  resolved "https://registry.npmjs.org/@docusaurus/bundler/-/bundler-3.7.0.tgz"
-  integrity sha512-CUUT9VlSGukrCU5ctZucykvgCISivct+cby28wJwCC/fkQFgAHRp/GKv2tx38ZmXb7nacrKzFTcp++f9txUYGg==
+"@docusaurus/bundler@3.9.2":
+  version "3.9.2"
+  resolved "https://registry.npmjs.org/@docusaurus/bundler/-/bundler-3.9.2.tgz"
+  integrity sha512-ZOVi6GYgTcsZcUzjblpzk3wH1Fya2VNpd5jtHoCCFcJlMQ1EYXZetfAnRHLcyiFeBABaI1ltTYbOBtH/gahGVA==
   dependencies:
     "@babel/core" "^7.25.9"
-    "@docusaurus/babel" "3.7.0"
-    "@docusaurus/cssnano-preset" "3.7.0"
-    "@docusaurus/logger" "3.7.0"
-    "@docusaurus/types" "3.7.0"
-    "@docusaurus/utils" "3.7.0"
+    "@docusaurus/babel" "3.9.2"
+    "@docusaurus/cssnano-preset" "3.9.2"
+    "@docusaurus/logger" "3.9.2"
+    "@docusaurus/types" "3.9.2"
+    "@docusaurus/utils" "3.9.2"
     babel-loader "^9.2.1"
-    clean-css "^5.3.2"
+    clean-css "^5.3.3"
     copy-webpack-plugin "^11.0.0"
-    css-loader "^6.8.1"
+    css-loader "^6.11.0"
     css-minimizer-webpack-plugin "^5.0.1"
     cssnano "^6.1.2"
     file-loader "^6.2.0"
     html-minifier-terser "^7.2.0"
-    mini-css-extract-plugin "^2.9.1"
+    mini-css-extract-plugin "^2.9.2"
     null-loader "^4.0.1"
-    postcss "^8.4.26"
-    postcss-loader "^7.3.3"
-    postcss-preset-env "^10.1.0"
-    react-dev-utils "^12.0.1"
+    postcss "^8.5.4"
+    postcss-loader "^7.3.4"
+    postcss-preset-env "^10.2.1"
     terser-webpack-plugin "^5.3.9"
     tslib "^2.6.0"
     url-loader "^4.1.1"
     webpack "^5.95.0"
     webpackbar "^6.0.1"
 
-"@docusaurus/core@^3.1.1", "@docusaurus/core@3.7.0":
-  version "3.7.0"
-  resolved "https://registry.npmjs.org/@docusaurus/core/-/core-3.7.0.tgz"
-  integrity sha512-b0fUmaL+JbzDIQaamzpAFpTviiaU4cX3Qz8cuo14+HGBCwa0evEK0UYCBFY3n4cLzL8Op1BueeroUD2LYAIHbQ==
-  dependencies:
-    "@docusaurus/babel" "3.7.0"
-    "@docusaurus/bundler" "3.7.0"
-    "@docusaurus/logger" "3.7.0"
-    "@docusaurus/mdx-loader" "3.7.0"
-    "@docusaurus/utils" "3.7.0"
-    "@docusaurus/utils-common" "3.7.0"
-    "@docusaurus/utils-validation" "3.7.0"
+"@docusaurus/core@^3.1.1", "@docusaurus/core@3.9.2":
+  version "3.9.2"
+  resolved "https://registry.npmjs.org/@docusaurus/core/-/core-3.9.2.tgz"
+  integrity sha512-HbjwKeC+pHUFBfLMNzuSjqFE/58+rLVKmOU3lxQrpsxLBOGosYco/Q0GduBb0/jEMRiyEqjNT/01rRdOMWq5pw==
+  dependencies:
+    "@docusaurus/babel" "3.9.2"
+    "@docusaurus/bundler" "3.9.2"
+    "@docusaurus/logger" "3.9.2"
+    "@docusaurus/mdx-loader" "3.9.2"
+    "@docusaurus/utils" "3.9.2"
+    "@docusaurus/utils-common" "3.9.2"
+    "@docusaurus/utils-validation" "3.9.2"
     boxen "^6.2.1"
     chalk "^4.1.2"
     chokidar "^3.5.3"
@@ -1464,19 +1587,19 @@
     combine-promises "^1.1.0"
     commander "^5.1.0"
     core-js "^3.31.1"
-    del "^6.1.1"
     detect-port "^1.5.1"
     escape-html "^1.0.3"
     eta "^2.2.0"
     eval "^0.1.8"
+    execa "5.1.1"
     fs-extra "^11.1.1"
     html-tags "^3.3.1"
     html-webpack-plugin "^5.6.0"
     leven "^3.1.0"
     lodash "^4.17.21"
+    open "^8.4.0"
     p-map "^4.0.0"
     prompts "^2.4.2"
-    react-dev-utils "^12.0.1"
     react-helmet-async "npm:@slorber/react-helmet-async@1.3.0"
     react-loadable "npm:@docusaurus/react-loadable@6.0.0"
     react-loadable-ssr-addon-v5-slorber "^1.0.1"
@@ -1485,47 +1608,47 @@
     react-router-dom "^5.3.4"
     semver "^7.5.4"
     serve-handler "^6.1.6"
-    shelljs "^0.8.5"
+    tinypool "^1.0.2"
     tslib "^2.6.0"
     update-notifier "^6.0.2"
     webpack "^5.95.0"
     webpack-bundle-analyzer "^4.10.2"
-    webpack-dev-server "^4.15.2"
+    webpack-dev-server "^5.2.2"
     webpack-merge "^6.0.1"
 
-"@docusaurus/cssnano-preset@3.7.0":
-  version "3.7.0"
-  resolved "https://registry.npmjs.org/@docusaurus/cssnano-preset/-/cssnano-preset-3.7.0.tgz"
-  integrity sha512-X9GYgruZBSOozg4w4dzv9uOz8oK/EpPVQXkp0MM6Tsgp/nRIU9hJzJ0Pxg1aRa3xCeEQTOimZHcocQFlLwYajQ==
+"@docusaurus/cssnano-preset@3.9.2":
+  version "3.9.2"
+  resolved "https://registry.npmjs.org/@docusaurus/cssnano-preset/-/cssnano-preset-3.9.2.tgz"
+  integrity sha512-8gBKup94aGttRduABsj7bpPFTX7kbwu+xh3K9NMCF5K4bWBqTFYW+REKHF6iBVDHRJ4grZdIPbvkiHd/XNKRMQ==
   dependencies:
     cssnano-preset-advanced "^6.1.2"
-    postcss "^8.4.38"
+    postcss "^8.5.4"
     postcss-sort-media-queries "^5.2.0"
     tslib "^2.6.0"
 
-"@docusaurus/logger@3.7.0":
-  version "3.7.0"
-  resolved "https://registry.npmjs.org/@docusaurus/logger/-/logger-3.7.0.tgz"
-  integrity sha512-z7g62X7bYxCYmeNNuO9jmzxLQG95q9QxINCwpboVcNff3SJiHJbGrarxxOVMVmAh1MsrSfxWkVGv4P41ktnFsA==
+"@docusaurus/logger@3.9.2":
+  version "3.9.2"
+  resolved "https://registry.npmjs.org/@docusaurus/logger/-/logger-3.9.2.tgz"
+  integrity sha512-/SVCc57ByARzGSU60c50rMyQlBuMIJCjcsJlkphxY6B0GV4UH3tcA1994N8fFfbJ9kX3jIBe/xg3XP5qBtGDbA==
   dependencies:
     chalk "^4.1.2"
     tslib "^2.6.0"
 
-"@docusaurus/mdx-loader@3.7.0":
-  version "3.7.0"
-  resolved "https://registry.npmjs.org/@docusaurus/mdx-loader/-/mdx-loader-3.7.0.tgz"
-  integrity sha512-OFBG6oMjZzc78/U3WNPSHs2W9ZJ723ewAcvVJaqS0VgyeUfmzUV8f1sv+iUHA0DtwiR5T5FjOxj6nzEE8LY6VA==
+"@docusaurus/mdx-loader@3.9.2":
+  version "3.9.2"
+  resolved "https://registry.npmjs.org/@docusaurus/mdx-loader/-/mdx-loader-3.9.2.tgz"
+  integrity sha512-wiYoGwF9gdd6rev62xDU8AAM8JuLI/hlwOtCzMmYcspEkzecKrP8J8X+KpYnTlACBUUtXNJpSoCwFWJhLRevzQ==
   dependencies:
-    "@docusaurus/logger" "3.7.0"
-    "@docusaurus/utils" "3.7.0"
-    "@docusaurus/utils-validation" "3.7.0"
+    "@docusaurus/logger" "3.9.2"
+    "@docusaurus/utils" "3.9.2"
+    "@docusaurus/utils-validation" "3.9.2"
     "@mdx-js/mdx" "^3.0.0"
     "@slorber/remark-comment" "^1.0.0"
     escape-html "^1.0.3"
     estree-util-value-to-estree "^3.0.1"
     file-loader "^6.2.0"
     fs-extra "^11.1.1"
-    image-size "^1.0.2"
+    image-size "^2.0.2"
     mdast-util-mdx "^3.0.0"
     mdast-util-to-string "^4.0.0"
     rehype-raw "^7.0.0"
@@ -1541,197 +1664,209 @@
     vfile "^6.0.1"
     webpack "^5.88.1"
 
-"@docusaurus/module-type-aliases@^3.1.1", "@docusaurus/module-type-aliases@3.7.0":
-  version "3.7.0"
-  resolved "https://registry.npmjs.org/@docusaurus/module-type-aliases/-/module-type-aliases-3.7.0.tgz"
-  integrity sha512-g7WdPqDNaqA60CmBrr0cORTrsOit77hbsTj7xE2l71YhBn79sxdm7WMK7wfhcaafkbpIh7jv5ef5TOpf1Xv9Lg==
+"@docusaurus/module-type-aliases@^3.1.1", "@docusaurus/module-type-aliases@3.9.2":
+  version "3.9.2"
+  resolved "https://registry.npmjs.org/@docusaurus/module-type-aliases/-/module-type-aliases-3.9.2.tgz"
+  integrity sha512-8qVe2QA9hVLzvnxP46ysuofJUIc/yYQ82tvA/rBTrnpXtCjNSFLxEZfd5U8cYZuJIVlkPxamsIgwd5tGZXfvew==
   dependencies:
-    "@docusaurus/types" "3.7.0"
+    "@docusaurus/types" "3.9.2"
     "@types/history" "^4.7.11"
     "@types/react" "*"
     "@types/react-router-config" "*"
     "@types/react-router-dom" "*"
-    react-helmet-async "npm:@slorber/react-helmet-async@*"
+    react-helmet-async "npm:@slorber/react-helmet-async@1.3.0"
     react-loadable "npm:@docusaurus/react-loadable@6.0.0"
 
-"@docusaurus/plugin-content-blog@3.7.0":
-  version "3.7.0"
-  resolved "https://registry.npmjs.org/@docusaurus/plugin-content-blog/-/plugin-content-blog-3.7.0.tgz"
-  integrity sha512-EFLgEz6tGHYWdPU0rK8tSscZwx+AsyuBW/r+tNig2kbccHYGUJmZtYN38GjAa3Fda4NU+6wqUO5kTXQSRBQD3g==
-  dependencies:
-    "@docusaurus/core" "3.7.0"
-    "@docusaurus/logger" "3.7.0"
-    "@docusaurus/mdx-loader" "3.7.0"
-    "@docusaurus/theme-common" "3.7.0"
-    "@docusaurus/types" "3.7.0"
-    "@docusaurus/utils" "3.7.0"
-    "@docusaurus/utils-common" "3.7.0"
-    "@docusaurus/utils-validation" "3.7.0"
+"@docusaurus/plugin-content-blog@3.9.2":
+  version "3.9.2"
+  resolved "https://registry.npmjs.org/@docusaurus/plugin-content-blog/-/plugin-content-blog-3.9.2.tgz"
+  integrity sha512-3I2HXy3L1QcjLJLGAoTvoBnpOwa6DPUa3Q0dMK19UTY9mhPkKQg/DYhAGTiBUKcTR0f08iw7kLPqOhIgdV3eVQ==
+  dependencies:
+    "@docusaurus/core" "3.9.2"
+    "@docusaurus/logger" "3.9.2"
+    "@docusaurus/mdx-loader" "3.9.2"
+    "@docusaurus/theme-common" "3.9.2"
+    "@docusaurus/types" "3.9.2"
+    "@docusaurus/utils" "3.9.2"
+    "@docusaurus/utils-common" "3.9.2"
+    "@docusaurus/utils-validation" "3.9.2"
     cheerio "1.0.0-rc.12"
     feed "^4.2.2"
     fs-extra "^11.1.1"
     lodash "^4.17.21"
-    reading-time "^1.5.0"
+    schema-dts "^1.1.2"
     srcset "^4.0.0"
     tslib "^2.6.0"
     unist-util-visit "^5.0.0"
     utility-types "^3.10.0"
     webpack "^5.88.1"
 
-"@docusaurus/plugin-content-docs@*", "@docusaurus/plugin-content-docs@3.7.0":
-  version "3.7.0"
-  resolved "https://registry.npmjs.org/@docusaurus/plugin-content-docs/-/plugin-content-docs-3.7.0.tgz"
-  integrity sha512-GXg5V7kC9FZE4FkUZA8oo/NrlRb06UwuICzI6tcbzj0+TVgjq/mpUXXzSgKzMS82YByi4dY2Q808njcBCyy6tQ==
-  dependencies:
-    "@docusaurus/core" "3.7.0"
-    "@docusaurus/logger" "3.7.0"
-    "@docusaurus/mdx-loader" "3.7.0"
-    "@docusaurus/module-type-aliases" "3.7.0"
-    "@docusaurus/theme-common" "3.7.0"
-    "@docusaurus/types" "3.7.0"
-    "@docusaurus/utils" "3.7.0"
-    "@docusaurus/utils-common" "3.7.0"
-    "@docusaurus/utils-validation" "3.7.0"
+"@docusaurus/plugin-content-docs@*", "@docusaurus/plugin-content-docs@3.9.2":
+  version "3.9.2"
+  resolved "https://registry.npmjs.org/@docusaurus/plugin-content-docs/-/plugin-content-docs-3.9.2.tgz"
+  integrity sha512-C5wZsGuKTY8jEYsqdxhhFOe1ZDjH0uIYJ9T/jebHwkyxqnr4wW0jTkB72OMqNjsoQRcb0JN3PcSeTwFlVgzCZg==
+  dependencies:
+    "@docusaurus/core" "3.9.2"
+    "@docusaurus/logger" "3.9.2"
+    "@docusaurus/mdx-loader" "3.9.2"
+    "@docusaurus/module-type-aliases" "3.9.2"
+    "@docusaurus/theme-common" "3.9.2"
+    "@docusaurus/types" "3.9.2"
+    "@docusaurus/utils" "3.9.2"
+    "@docusaurus/utils-common" "3.9.2"
+    "@docusaurus/utils-validation" "3.9.2"
     "@types/react-router-config" "^5.0.7"
     combine-promises "^1.1.0"
     fs-extra "^11.1.1"
     js-yaml "^4.1.0"
     lodash "^4.17.21"
+    schema-dts "^1.1.2"
     tslib "^2.6.0"
     utility-types "^3.10.0"
     webpack "^5.88.1"
 
-"@docusaurus/plugin-content-pages@3.7.0":
-  version "3.7.0"
-  resolved "https://registry.npmjs.org/@docusaurus/plugin-content-pages/-/plugin-content-pages-3.7.0.tgz"
-  integrity sha512-YJSU3tjIJf032/Aeao8SZjFOrXJbz/FACMveSMjLyMH4itQyZ2XgUIzt4y+1ISvvk5zrW4DABVT2awTCqBkx0Q==
+"@docusaurus/plugin-content-pages@3.9.2":
+  version "3.9.2"
+  resolved "https://registry.npmjs.org/@docusaurus/plugin-content-pages/-/plugin-content-pages-3.9.2.tgz"
+  integrity sha512-s4849w/p4noXUrGpPUF0BPqIAfdAe76BLaRGAGKZ1gTDNiGxGcpsLcwJ9OTi1/V8A+AzvsmI9pkjie2zjIQZKA==
   dependencies:
-    "@docusaurus/core" "3.7.0"
-    "@docusaurus/mdx-loader" "3.7.0"
-    "@docusaurus/types" "3.7.0"
-    "@docusaurus/utils" "3.7.0"
-    "@docusaurus/utils-validation" "3.7.0"
+    "@docusaurus/core" "3.9.2"
+    "@docusaurus/mdx-loader" "3.9.2"
+    "@docusaurus/types" "3.9.2"
+    "@docusaurus/utils" "3.9.2"
+    "@docusaurus/utils-validation" "3.9.2"
     fs-extra "^11.1.1"
     tslib "^2.6.0"
     webpack "^5.88.1"
 
-"@docusaurus/plugin-debug@3.7.0":
-  version "3.7.0"
-  resolved "https://registry.npmjs.org/@docusaurus/plugin-debug/-/plugin-debug-3.7.0.tgz"
-  integrity sha512-Qgg+IjG/z4svtbCNyTocjIwvNTNEwgRjSXXSJkKVG0oWoH0eX/HAPiu+TS1HBwRPQV+tTYPWLrUypYFepfujZA==
+"@docusaurus/plugin-css-cascade-layers@3.9.2":
+  version "3.9.2"
+  resolved "https://registry.npmjs.org/@docusaurus/plugin-css-cascade-layers/-/plugin-css-cascade-layers-3.9.2.tgz"
+  integrity sha512-w1s3+Ss+eOQbscGM4cfIFBlVg/QKxyYgj26k5AnakuHkKxH6004ZtuLe5awMBotIYF2bbGDoDhpgQ4r/kcj4rQ==
   dependencies:
-    "@docusaurus/core" "3.7.0"
-    "@docusaurus/types" "3.7.0"
-    "@docusaurus/utils" "3.7.0"
+    "@docusaurus/core" "3.9.2"
+    "@docusaurus/types" "3.9.2"
+    "@docusaurus/utils" "3.9.2"
+    "@docusaurus/utils-validation" "3.9.2"
+    tslib "^2.6.0"
+
+"@docusaurus/plugin-debug@3.9.2":
+  version "3.9.2"
+  resolved "https://registry.npmjs.org/@docusaurus/plugin-debug/-/plugin-debug-3.9.2.tgz"
+  integrity sha512-j7a5hWuAFxyQAkilZwhsQ/b3T7FfHZ+0dub6j/GxKNFJp2h9qk/P1Bp7vrGASnvA9KNQBBL1ZXTe7jlh4VdPdA==
+  dependencies:
+    "@docusaurus/core" "3.9.2"
+    "@docusaurus/types" "3.9.2"
+    "@docusaurus/utils" "3.9.2"
     fs-extra "^11.1.1"
-    react-json-view-lite "^1.2.0"
+    react-json-view-lite "^2.3.0"
     tslib "^2.6.0"
 
-"@docusaurus/plugin-google-analytics@3.7.0":
-  version "3.7.0"
-  resolved "https://registry.npmjs.org/@docusaurus/plugin-google-analytics/-/plugin-google-analytics-3.7.0.tgz"
-  integrity sha512-otIqiRV/jka6Snjf+AqB360XCeSv7lQC+DKYW+EUZf6XbuE8utz5PeUQ8VuOcD8Bk5zvT1MC4JKcd5zPfDuMWA==
+"@docusaurus/plugin-google-analytics@3.9.2":
+  version "3.9.2"
+  resolved "https://registry.npmjs.org/@docusaurus/plugin-google-analytics/-/plugin-google-analytics-3.9.2.tgz"
+  integrity sha512-mAwwQJ1Us9jL/lVjXtErXto4p4/iaLlweC54yDUK1a97WfkC6Z2k5/769JsFgwOwOP+n5mUQGACXOEQ0XDuVUw==
   dependencies:
-    "@docusaurus/core" "3.7.0"
-    "@docusaurus/types" "3.7.0"
-    "@docusaurus/utils-validation" "3.7.0"
+    "@docusaurus/core" "3.9.2"
+    "@docusaurus/types" "3.9.2"
+    "@docusaurus/utils-validation" "3.9.2"
     tslib "^2.6.0"
 
-"@docusaurus/plugin-google-gtag@3.7.0":
-  version "3.7.0"
-  resolved "https://registry.npmjs.org/@docusaurus/plugin-google-gtag/-/plugin-google-gtag-3.7.0.tgz"
-  integrity sha512-M3vrMct1tY65ModbyeDaMoA+fNJTSPe5qmchhAbtqhDD/iALri0g9LrEpIOwNaoLmm6lO88sfBUADQrSRSGSWA==
+"@docusaurus/plugin-google-gtag@3.9.2":
+  version "3.9.2"
+  resolved "https://registry.npmjs.org/@docusaurus/plugin-google-gtag/-/plugin-google-gtag-3.9.2.tgz"
+  integrity sha512-YJ4lDCphabBtw19ooSlc1MnxtYGpjFV9rEdzjLsUnBCeis2djUyCozZaFhCg6NGEwOn7HDDyMh0yzcdRpnuIvA==
   dependencies:
-    "@docusaurus/core" "3.7.0"
-    "@docusaurus/types" "3.7.0"
-    "@docusaurus/utils-validation" "3.7.0"
+    "@docusaurus/core" "3.9.2"
+    "@docusaurus/types" "3.9.2"
+    "@docusaurus/utils-validation" "3.9.2"
     "@types/gtag.js" "^0.0.12"
     tslib "^2.6.0"
 
-"@docusaurus/plugin-google-tag-manager@3.7.0":
-  version "3.7.0"
-  resolved "https://registry.npmjs.org/@docusaurus/plugin-google-tag-manager/-/plugin-google-tag-manager-3.7.0.tgz"
-  integrity sha512-X8U78nb8eiMiPNg3jb9zDIVuuo/rE1LjGDGu+5m5CX4UBZzjMy+klOY2fNya6x8ACyE/L3K2erO1ErheP55W/w==
+"@docusaurus/plugin-google-tag-manager@3.9.2":
+  version "3.9.2"
+  resolved "https://registry.npmjs.org/@docusaurus/plugin-google-tag-manager/-/plugin-google-tag-manager-3.9.2.tgz"
+  integrity sha512-LJtIrkZN/tuHD8NqDAW1Tnw0ekOwRTfobWPsdO15YxcicBo2ykKF0/D6n0vVBfd3srwr9Z6rzrIWYrMzBGrvNw==
   dependencies:
-    "@docusaurus/core" "3.7.0"
-    "@docusaurus/types" "3.7.0"
-    "@docusaurus/utils-validation" "3.7.0"
+    "@docusaurus/core" "3.9.2"
+    "@docusaurus/types" "3.9.2"
+    "@docusaurus/utils-validation" "3.9.2"
     tslib "^2.6.0"
 
-"@docusaurus/plugin-sitemap@3.7.0":
-  version "3.7.0"
-  resolved "https://registry.npmjs.org/@docusaurus/plugin-sitemap/-/plugin-sitemap-3.7.0.tgz"
-  integrity sha512-bTRT9YLZ/8I/wYWKMQke18+PF9MV8Qub34Sku6aw/vlZ/U+kuEuRpQ8bTcNOjaTSfYsWkK4tTwDMHK2p5S86cA==
-  dependencies:
-    "@docusaurus/core" "3.7.0"
-    "@docusaurus/logger" "3.7.0"
-    "@docusaurus/types" "3.7.0"
-    "@docusaurus/utils" "3.7.0"
-    "@docusaurus/utils-common" "3.7.0"
-    "@docusaurus/utils-validation" "3.7.0"
+"@docusaurus/plugin-sitemap@3.9.2":
+  version "3.9.2"
+  resolved "https://registry.npmjs.org/@docusaurus/plugin-sitemap/-/plugin-sitemap-3.9.2.tgz"
+  integrity sha512-WLh7ymgDXjG8oPoM/T4/zUP7KcSuFYRZAUTl8vR6VzYkfc18GBM4xLhcT+AKOwun6kBivYKUJf+vlqYJkm+RHw==
+  dependencies:
+    "@docusaurus/core" "3.9.2"
+    "@docusaurus/logger" "3.9.2"
+    "@docusaurus/types" "3.9.2"
+    "@docusaurus/utils" "3.9.2"
+    "@docusaurus/utils-common" "3.9.2"
+    "@docusaurus/utils-validation" "3.9.2"
     fs-extra "^11.1.1"
     sitemap "^7.1.1"
     tslib "^2.6.0"
 
-"@docusaurus/plugin-svgr@3.7.0":
-  version "3.7.0"
-  resolved "https://registry.npmjs.org/@docusaurus/plugin-svgr/-/plugin-svgr-3.7.0.tgz"
-  integrity sha512-HByXIZTbc4GV5VAUkZ2DXtXv1Qdlnpk3IpuImwSnEzCDBkUMYcec5282hPjn6skZqB25M1TYCmWS91UbhBGxQg==
+"@docusaurus/plugin-svgr@3.9.2":
+  version "3.9.2"
+  resolved "https://registry.npmjs.org/@docusaurus/plugin-svgr/-/plugin-svgr-3.9.2.tgz"
+  integrity sha512-n+1DE+5b3Lnf27TgVU5jM1d4x5tUh2oW5LTsBxJX4PsAPV0JGcmI6p3yLYtEY0LRVEIJh+8RsdQmRE66wSV8mw==
   dependencies:
-    "@docusaurus/core" "3.7.0"
-    "@docusaurus/types" "3.7.0"
-    "@docusaurus/utils" "3.7.0"
-    "@docusaurus/utils-validation" "3.7.0"
+    "@docusaurus/core" "3.9.2"
+    "@docusaurus/types" "3.9.2"
+    "@docusaurus/utils" "3.9.2"
+    "@docusaurus/utils-validation" "3.9.2"
     "@svgr/core" "8.1.0"
     "@svgr/webpack" "^8.1.0"
     tslib "^2.6.0"
     webpack "^5.88.1"
 
 "@docusaurus/preset-classic@^3.1.1":
-  version "3.7.0"
-  resolved "https://registry.npmjs.org/@docusaurus/preset-classic/-/preset-classic-3.7.0.tgz"
-  integrity sha512-nPHj8AxDLAaQXs+O6+BwILFuhiWbjfQWrdw2tifOClQoNfuXDjfjogee6zfx6NGHWqshR23LrcN115DmkHC91Q==
-  dependencies:
-    "@docusaurus/core" "3.7.0"
-    "@docusaurus/plugin-content-blog" "3.7.0"
-    "@docusaurus/plugin-content-docs" "3.7.0"
-    "@docusaurus/plugin-content-pages" "3.7.0"
-    "@docusaurus/plugin-debug" "3.7.0"
-    "@docusaurus/plugin-google-analytics" "3.7.0"
-    "@docusaurus/plugin-google-gtag" "3.7.0"
-    "@docusaurus/plugin-google-tag-manager" "3.7.0"
-    "@docusaurus/plugin-sitemap" "3.7.0"
-    "@docusaurus/plugin-svgr" "3.7.0"
-    "@docusaurus/theme-classic" "3.7.0"
-    "@docusaurus/theme-common" "3.7.0"
-    "@docusaurus/theme-search-algolia" "3.7.0"
-    "@docusaurus/types" "3.7.0"
-
-"@docusaurus/theme-classic@3.7.0":
-  version "3.7.0"
-  resolved "https://registry.npmjs.org/@docusaurus/theme-classic/-/theme-classic-3.7.0.tgz"
-  integrity sha512-MnLxG39WcvLCl4eUzHr0gNcpHQfWoGqzADCly54aqCofQX6UozOS9Th4RK3ARbM9m7zIRv3qbhggI53dQtx/hQ==
-  dependencies:
-    "@docusaurus/core" "3.7.0"
-    "@docusaurus/logger" "3.7.0"
-    "@docusaurus/mdx-loader" "3.7.0"
-    "@docusaurus/module-type-aliases" "3.7.0"
-    "@docusaurus/plugin-content-blog" "3.7.0"
-    "@docusaurus/plugin-content-docs" "3.7.0"
-    "@docusaurus/plugin-content-pages" "3.7.0"
-    "@docusaurus/theme-common" "3.7.0"
-    "@docusaurus/theme-translations" "3.7.0"
-    "@docusaurus/types" "3.7.0"
-    "@docusaurus/utils" "3.7.0"
-    "@docusaurus/utils-common" "3.7.0"
-    "@docusaurus/utils-validation" "3.7.0"
+  version "3.9.2"
+  resolved "https://registry.npmjs.org/@docusaurus/preset-classic/-/preset-classic-3.9.2.tgz"
+  integrity sha512-IgyYO2Gvaigi21LuDIe+nvmN/dfGXAiMcV/murFqcpjnZc7jxFAxW+9LEjdPt61uZLxG4ByW/oUmX/DDK9t/8w==
+  dependencies:
+    "@docusaurus/core" "3.9.2"
+    "@docusaurus/plugin-content-blog" "3.9.2"
+    "@docusaurus/plugin-content-docs" "3.9.2"
+    "@docusaurus/plugin-content-pages" "3.9.2"
+    "@docusaurus/plugin-css-cascade-layers" "3.9.2"
+    "@docusaurus/plugin-debug" "3.9.2"
+    "@docusaurus/plugin-google-analytics" "3.9.2"
+    "@docusaurus/plugin-google-gtag" "3.9.2"
+    "@docusaurus/plugin-google-tag-manager" "3.9.2"
+    "@docusaurus/plugin-sitemap" "3.9.2"
+    "@docusaurus/plugin-svgr" "3.9.2"
+    "@docusaurus/theme-classic" "3.9.2"
+    "@docusaurus/theme-common" "3.9.2"
+    "@docusaurus/theme-search-algolia" "3.9.2"
+    "@docusaurus/types" "3.9.2"
+
+"@docusaurus/theme-classic@3.9.2":
+  version "3.9.2"
+  resolved "https://registry.npmjs.org/@docusaurus/theme-classic/-/theme-classic-3.9.2.tgz"
+  integrity sha512-IGUsArG5hhekXd7RDb11v94ycpJpFdJPkLnt10fFQWOVxAtq5/D7hT6lzc2fhyQKaaCE62qVajOMKL7OiAFAIA==
+  dependencies:
+    "@docusaurus/core" "3.9.2"
+    "@docusaurus/logger" "3.9.2"
+    "@docusaurus/mdx-loader" "3.9.2"
+    "@docusaurus/module-type-aliases" "3.9.2"
+    "@docusaurus/plugin-content-blog" "3.9.2"
+    "@docusaurus/plugin-content-docs" "3.9.2"
+    "@docusaurus/plugin-content-pages" "3.9.2"
+    "@docusaurus/theme-common" "3.9.2"
+    "@docusaurus/theme-translations" "3.9.2"
+    "@docusaurus/types" "3.9.2"
+    "@docusaurus/utils" "3.9.2"
+    "@docusaurus/utils-common" "3.9.2"
+    "@docusaurus/utils-validation" "3.9.2"
     "@mdx-js/react" "^3.0.0"
     clsx "^2.0.0"
-    copy-text-to-clipboard "^3.2.0"
     infima "0.2.0-alpha.45"
     lodash "^4.17.21"
     nprogress "^0.2.0"
-    postcss "^8.4.26"
+    postcss "^8.5.4"
     prism-react-renderer "^2.3.0"
     prismjs "^1.29.0"
     react-router-dom "^5.3.4"
@@ -1739,15 +1874,15 @@
     tslib "^2.6.0"
     utility-types "^3.10.0"
 
-"@docusaurus/theme-common@3.7.0":
-  version "3.7.0"
-  resolved "https://registry.npmjs.org/@docusaurus/theme-common/-/theme-common-3.7.0.tgz"
-  integrity sha512-8eJ5X0y+gWDsURZnBfH0WabdNm8XMCXHv8ENy/3Z/oQKwaB/EHt5lP9VsTDTf36lKEp0V6DjzjFyFIB+CetL0A==
+"@docusaurus/theme-common@3.9.2":
+  version "3.9.2"
+  resolved "https://registry.npmjs.org/@docusaurus/theme-common/-/theme-common-3.9.2.tgz"
+  integrity sha512-6c4DAbR6n6nPbnZhY2V3tzpnKnGL+6aOsLvFL26VRqhlczli9eWG0VDUNoCQEPnGwDMhPS42UhSAnz5pThm5Ag==
   dependencies:
-    "@docusaurus/mdx-loader" "3.7.0"
-    "@docusaurus/module-type-aliases" "3.7.0"
-    "@docusaurus/utils" "3.7.0"
-    "@docusaurus/utils-common" "3.7.0"
+    "@docusaurus/mdx-loader" "3.9.2"
+    "@docusaurus/module-type-aliases" "3.9.2"
+    "@docusaurus/utils" "3.9.2"
+    "@docusaurus/utils-common" "3.9.2"
     "@types/history" "^4.7.11"
     "@types/react" "*"
     "@types/react-router-config" "*"
@@ -1757,21 +1892,21 @@
     tslib "^2.6.0"
     utility-types "^3.10.0"
 
-"@docusaurus/theme-search-algolia@3.7.0":
-  version "3.7.0"
-  resolved "https://registry.npmjs.org/@docusaurus/theme-search-algolia/-/theme-search-algolia-3.7.0.tgz"
-  integrity sha512-Al/j5OdzwRU1m3falm+sYy9AaB93S1XF1Lgk9Yc6amp80dNxJVplQdQTR4cYdzkGtuQqbzUA8+kaoYYO0RbK6g==
-  dependencies:
-    "@docsearch/react" "^3.8.1"
-    "@docusaurus/core" "3.7.0"
-    "@docusaurus/logger" "3.7.0"
-    "@docusaurus/plugin-content-docs" "3.7.0"
-    "@docusaurus/theme-common" "3.7.0"
-    "@docusaurus/theme-translations" "3.7.0"
-    "@docusaurus/utils" "3.7.0"
-    "@docusaurus/utils-validation" "3.7.0"
-    algoliasearch "^5.17.1"
-    algoliasearch-helper "^3.22.6"
+"@docusaurus/theme-search-algolia@3.9.2":
+  version "3.9.2"
+  resolved "https://registry.npmjs.org/@docusaurus/theme-search-algolia/-/theme-search-algolia-3.9.2.tgz"
+  integrity sha512-GBDSFNwjnh5/LdkxCKQHkgO2pIMX1447BxYUBG2wBiajS21uj64a+gH/qlbQjDLxmGrbrllBrtJkUHxIsiwRnw==
+  dependencies:
+    "@docsearch/react" "^3.9.0 || ^4.1.0"
+    "@docusaurus/core" "3.9.2"
+    "@docusaurus/logger" "3.9.2"
+    "@docusaurus/plugin-content-docs" "3.9.2"
+    "@docusaurus/theme-common" "3.9.2"
+    "@docusaurus/theme-translations" "3.9.2"
+    "@docusaurus/utils" "3.9.2"
+    "@docusaurus/utils-validation" "3.9.2"
+    algoliasearch "^5.37.0"
+    algoliasearch-helper "^3.26.0"
     clsx "^2.0.0"
     eta "^2.2.0"
     fs-extra "^11.1.1"
@@ -1779,21 +1914,22 @@
     tslib "^2.6.0"
     utility-types "^3.10.0"
 
-"@docusaurus/theme-translations@3.7.0":
-  version "3.7.0"
-  resolved "https://registry.npmjs.org/@docusaurus/theme-translations/-/theme-translations-3.7.0.tgz"
-  integrity sha512-Ewq3bEraWDmienM6eaNK7fx+/lHMtGDHQyd1O+4+3EsDxxUmrzPkV7Ct3nBWTuE0MsoZr3yNwQVKjllzCMuU3g==
+"@docusaurus/theme-translations@3.9.2":
+  version "3.9.2"
+  resolved "https://registry.npmjs.org/@docusaurus/theme-translations/-/theme-translations-3.9.2.tgz"
+  integrity sha512-vIryvpP18ON9T9rjgMRFLr2xJVDpw1rtagEGf8Ccce4CkTrvM/fRB8N2nyWYOW5u3DdjkwKw5fBa+3tbn9P4PA==
   dependencies:
     fs-extra "^11.1.1"
     tslib "^2.6.0"
 
-"@docusaurus/types@3.7.0":
-  version "3.7.0"
-  resolved "https://registry.npmjs.org/@docusaurus/types/-/types-3.7.0.tgz"
-  integrity sha512-kOmZg5RRqJfH31m+6ZpnwVbkqMJrPOG5t0IOl4i/+3ruXyNfWzZ0lVtVrD0u4ONc/0NOsS9sWYaxxWNkH1LdLQ==
+"@docusaurus/types@3.9.2":
+  version "3.9.2"
+  resolved "https://registry.npmjs.org/@docusaurus/types/-/types-3.9.2.tgz"
+  integrity sha512-Ux1JUNswg+EfUEmajJjyhIohKceitY/yzjRUpu04WXgvVz+fbhVC0p+R0JhvEu4ytw8zIAys2hrdpQPBHRIa8Q==
   dependencies:
     "@mdx-js/mdx" "^3.0.0"
     "@types/history" "^4.7.11"
+    "@types/mdast" "^4.0.2"
     "@types/react" "*"
     commander "^5.1.0"
     joi "^17.9.2"
@@ -1802,37 +1938,38 @@
     webpack "^5.95.0"
     webpack-merge "^5.9.0"
 
-"@docusaurus/utils-common@3.7.0":
-  version "3.7.0"
-  resolved "https://registry.npmjs.org/@docusaurus/utils-common/-/utils-common-3.7.0.tgz"
-  integrity sha512-IZeyIfCfXy0Mevj6bWNg7DG7B8G+S6o6JVpddikZtWyxJguiQ7JYr0SIZ0qWd8pGNuMyVwriWmbWqMnK7Y5PwA==
+"@docusaurus/utils-common@3.9.2":
+  version "3.9.2"
+  resolved "https://registry.npmjs.org/@docusaurus/utils-common/-/utils-common-3.9.2.tgz"
+  integrity sha512-I53UC1QctruA6SWLvbjbhCpAw7+X7PePoe5pYcwTOEXD/PxeP8LnECAhTHHwWCblyUX5bMi4QLRkxvyZ+IT8Aw==
   dependencies:
-    "@docusaurus/types" "3.7.0"
+    "@docusaurus/types" "3.9.2"
     tslib "^2.6.0"
 
-"@docusaurus/utils-validation@3.7.0":
-  version "3.7.0"
-  resolved "https://registry.npmjs.org/@docusaurus/utils-validation/-/utils-validation-3.7.0.tgz"
-  integrity sha512-w8eiKk8mRdN+bNfeZqC4nyFoxNyI1/VExMKAzD9tqpJfLLbsa46Wfn5wcKH761g9WkKh36RtFV49iL9lh1DYBA==
+"@docusaurus/utils-validation@3.9.2":
+  version "3.9.2"
+  resolved "https://registry.npmjs.org/@docusaurus/utils-validation/-/utils-validation-3.9.2.tgz"
+  integrity sha512-l7yk3X5VnNmATbwijJkexdhulNsQaNDwoagiwujXoxFbWLcxHQqNQ+c/IAlzrfMMOfa/8xSBZ7KEKDesE/2J7A==
   dependencies:
-    "@docusaurus/logger" "3.7.0"
-    "@docusaurus/utils" "3.7.0"
-    "@docusaurus/utils-common" "3.7.0"
+    "@docusaurus/logger" "3.9.2"
+    "@docusaurus/utils" "3.9.2"
+    "@docusaurus/utils-common" "3.9.2"
     fs-extra "^11.2.0"
     joi "^17.9.2"
     js-yaml "^4.1.0"
     lodash "^4.17.21"
     tslib "^2.6.0"
 
-"@docusaurus/utils@3.7.0":
-  version "3.7.0"
-  resolved "https://registry.npmjs.org/@docusaurus/utils/-/utils-3.7.0.tgz"
-  integrity sha512-e7zcB6TPnVzyUaHMJyLSArKa2AG3h9+4CfvKXKKWNx6hRs+p0a+u7HHTJBgo6KW2m+vqDnuIHK4X+bhmoghAFA==
+"@docusaurus/utils@3.9.2":
+  version "3.9.2"
+  resolved "https://registry.npmjs.org/@docusaurus/utils/-/utils-3.9.2.tgz"
+  integrity sha512-lBSBiRruFurFKXr5Hbsl2thmGweAPmddhF3jb99U4EMDA5L+e5Y1rAkOS07Nvrup7HUMBDrCV45meaxZnt28nQ==
   dependencies:
-    "@docusaurus/logger" "3.7.0"
-    "@docusaurus/types" "3.7.0"
-    "@docusaurus/utils-common" "3.7.0"
+    "@docusaurus/logger" "3.9.2"
+    "@docusaurus/types" "3.9.2"
+    "@docusaurus/utils-common" "3.9.2"
     escape-string-regexp "^4.0.0"
+    execa "5.1.1"
     file-loader "^6.2.0"
     fs-extra "^11.1.1"
     github-slugger "^1.5.0"
@@ -1842,9 +1979,9 @@
     js-yaml "^4.1.0"
     lodash "^4.17.21"
     micromatch "^4.0.5"
+    p-queue "^6.6.2"
     prompts "^2.4.2"
     resolve-pathname "^3.0.0"
-    shelljs "^0.8.5"
     tslib "^2.6.0"
     url-loader "^4.1.1"
     utility-types "^3.10.0"
@@ -1881,13 +2018,20 @@
     "@types/yargs" "^17.0.8"
     chalk "^4.0.0"
 
-"@jridgewell/gen-mapping@^0.3.5":
-  version "0.3.8"
-  resolved "https://registry.npmjs.org/@jridgewell/gen-mapping/-/gen-mapping-0.3.8.tgz"
-  integrity sha512-imAbBGkb+ebQyxKgzv5Hu2nmROxoDOXHh80evxdoXNOrvAnVx7zimzc1Oo5h9RlfV4vPXaE2iM5pOFbvOCClWA==
+"@jridgewell/gen-mapping@^0.3.12", "@jridgewell/gen-mapping@^0.3.5":
+  version "0.3.13"
+  resolved "https://registry.npmjs.org/@jridgewell/gen-mapping/-/gen-mapping-0.3.13.tgz"
+  integrity sha512-2kkt/7niJ6MgEPxF0bYdQ6etZaA+fQvDcLKckhy1yIQOzaoKjBBjSj63/aLVjYE3qhRt5dvM+uUyfCg6UKCBbA==
   dependencies:
-    "@jridgewell/set-array" "^1.2.1"
-    "@jridgewell/sourcemap-codec" "^1.4.10"
+    "@jridgewell/sourcemap-codec" "^1.5.0"
+    "@jridgewell/trace-mapping" "^0.3.24"
+
+"@jridgewell/remapping@^2.3.5":
+  version "2.3.5"
+  resolved "https://registry.npmjs.org/@jridgewell/remapping/-/remapping-2.3.5.tgz"
+  integrity sha512-LI9u/+laYG4Ds1TDKSJW2YPrIlcVYOwi2fUC6xB43lueCjgxV4lffOCZCtYFiH6TNOX+tQKXx97T4IKHbhyHEQ==
+  dependencies:
+    "@jridgewell/gen-mapping" "^0.3.5"
     "@jridgewell/trace-mapping" "^0.3.24"
 
 "@jridgewell/resolve-uri@^3.1.0":
@@ -1895,11 +2039,6 @@
   resolved "https://registry.npmjs.org/@jridgewell/resolve-uri/-/resolve-uri-3.1.2.tgz"
   integrity sha512-bRISgCIjP20/tbWSPWMEi54QVPRZExkuD9lJL+UIxUKtwVJA8wW1Trb1jMs1RFXo1CBTNZ/5hpC9QvmKWdopKw==
 
-"@jridgewell/set-array@^1.2.1":
-  version "1.2.1"
-  resolved "https://registry.npmjs.org/@jridgewell/set-array/-/set-array-1.2.1.tgz"
-  integrity sha512-R8gLRTZeyp03ymzP/6Lil/28tGeGEzhx1q2k703KGWRAI1VdvPIXdG70VJc2pAMw3NA6JKL5hhFu1sJX0Mnn/A==
-
 "@jridgewell/source-map@^0.3.3":
   version "0.3.6"
   resolved "https://registry.npmjs.org/@jridgewell/source-map/-/source-map-0.3.6.tgz"
@@ -1908,19 +2047,64 @@
     "@jridgewell/gen-mapping" "^0.3.5"
     "@jridgewell/trace-mapping" "^0.3.25"
 
-"@jridgewell/sourcemap-codec@^1.4.10", "@jridgewell/sourcemap-codec@^1.4.14":
+"@jridgewell/sourcemap-codec@^1.4.14", "@jridgewell/sourcemap-codec@^1.5.0":
   version "1.5.0"
   resolved "https://registry.npmjs.org/@jridgewell/sourcemap-codec/-/sourcemap-codec-1.5.0.tgz"
   integrity sha512-gv3ZRaISU3fjPAgNsriBRqGWQL6quFx04YMPW/zD8XMLsU32mhCCbfbO6KZFLjvYpCZ8zyDEgqsgf+PwPaM7GQ==
 
-"@jridgewell/trace-mapping@^0.3.18", "@jridgewell/trace-mapping@^0.3.24", "@jridgewell/trace-mapping@^0.3.25":
-  version "0.3.25"
-  resolved "https://registry.npmjs.org/@jridgewell/trace-mapping/-/trace-mapping-0.3.25.tgz"
-  integrity sha512-vNk6aEwybGtawWmy/PzwnGDOjCkLWSD2wqvjGGAgOAwCGWySYXfYoxt00IJkTF+8Lb57DwOb3Aa0o9CApepiYQ==
+"@jridgewell/trace-mapping@^0.3.18", "@jridgewell/trace-mapping@^0.3.24", "@jridgewell/trace-mapping@^0.3.25", "@jridgewell/trace-mapping@^0.3.28":
+  version "0.3.31"
+  resolved "https://registry.npmjs.org/@jridgewell/trace-mapping/-/trace-mapping-0.3.31.tgz"
+  integrity sha512-zzNR+SdQSDJzc8joaeP8QQoCQr8NuYx2dIIytl1QeBEZHJ9uW6hebsrYgbz8hJwUQao3TWCMtmfV8Nu1twOLAw==
   dependencies:
     "@jridgewell/resolve-uri" "^3.1.0"
     "@jridgewell/sourcemap-codec" "^1.4.14"
 
+"@jsonjoy.com/base64@^1.1.2":
+  version "1.1.2"
+  resolved "https://registry.npmjs.org/@jsonjoy.com/base64/-/base64-1.1.2.tgz"
+  integrity sha512-q6XAnWQDIMA3+FTiOYajoYqySkO+JSat0ytXGSuRdq9uXE7o92gzuQwQM14xaCRlBLGq3v5miDGC4vkVTn54xA==
+
+"@jsonjoy.com/buffers@^1.0.0", "@jsonjoy.com/buffers@^1.2.0":
+  version "1.2.1"
+  resolved "https://registry.npmjs.org/@jsonjoy.com/buffers/-/buffers-1.2.1.tgz"
+  integrity sha512-12cdlDwX4RUM3QxmUbVJWqZ/mrK6dFQH4Zxq6+r1YXKXYBNgZXndx2qbCJwh3+WWkCSn67IjnlG3XYTvmvYtgA==
+
+"@jsonjoy.com/codegen@^1.0.0":
+  version "1.0.0"
+  resolved "https://registry.npmjs.org/@jsonjoy.com/codegen/-/codegen-1.0.0.tgz"
+  integrity sha512-E8Oy+08cmCf0EK/NMxpaJZmOxPqM+6iSe2S4nlSBrPZOORoDJILxtbSUEDKQyTamm/BVAhIGllOBNU79/dwf0g==
+
+"@jsonjoy.com/json-pack@^1.11.0":
+  version "1.21.0"
+  resolved "https://registry.npmjs.org/@jsonjoy.com/json-pack/-/json-pack-1.21.0.tgz"
+  integrity sha512-+AKG+R2cfZMShzrF2uQw34v3zbeDYUqnQ+jg7ORic3BGtfw9p/+N6RJbq/kkV8JmYZaINknaEQ2m0/f693ZPpg==
+  dependencies:
+    "@jsonjoy.com/base64" "^1.1.2"
+    "@jsonjoy.com/buffers" "^1.2.0"
+    "@jsonjoy.com/codegen" "^1.0.0"
+    "@jsonjoy.com/json-pointer" "^1.0.2"
+    "@jsonjoy.com/util" "^1.9.0"
+    hyperdyperid "^1.2.0"
+    thingies "^2.5.0"
+    tree-dump "^1.1.0"
+
+"@jsonjoy.com/json-pointer@^1.0.2":
+  version "1.0.2"
+  resolved "https://registry.npmjs.org/@jsonjoy.com/json-pointer/-/json-pointer-1.0.2.tgz"
+  integrity sha512-Fsn6wM2zlDzY1U+v4Nc8bo3bVqgfNTGcn6dMgs6FjrEnt4ZCe60o6ByKRjOGlI2gow0aE/Q41QOigdTqkyK5fg==
+  dependencies:
+    "@jsonjoy.com/codegen" "^1.0.0"
+    "@jsonjoy.com/util" "^1.9.0"
+
+"@jsonjoy.com/util@^1.9.0":
+  version "1.9.0"
+  resolved "https://registry.npmjs.org/@jsonjoy.com/util/-/util-1.9.0.tgz"
+  integrity sha512-pLuQo+VPRnN8hfPqUTLTHk126wuYdXVxE6aDmjSeV4NCAgyxWbiOIeNJVtID3h1Vzpoi9m4jXezf73I6LgabgQ==
+  dependencies:
+    "@jsonjoy.com/buffers" "^1.0.0"
+    "@jsonjoy.com/codegen" "^1.0.0"
+
 "@leichtgewicht/ip-codec@^2.0.1":
   version "2.0.5"
   resolved "https://registry.npmjs.org/@leichtgewicht/ip-codec/-/ip-codec-2.0.5.tgz"
@@ -1963,6 +2147,11 @@
   dependencies:
     "@types/mdx" "^2.0.0"
 
+"@noble/hashes@1.4.0":
+  version "1.4.0"
+  resolved "https://registry.npmjs.org/@noble/hashes/-/hashes-1.4.0.tgz"
+  integrity sha512-V1JJ1WTRUqHHrOSh597hURcMqVKVGL/ea3kv0gSnEdsEZ0/+VyPghM1lMNGc00z7CIQorSvbKpuJkxvuHbvdbg==
+
 "@nodelib/fs.scandir@2.1.5":
   version "2.1.5"
   resolved "https://registry.npmjs.org/@nodelib/fs.scandir/-/fs.scandir-2.1.5.tgz"
@@ -1984,6 +2173,134 @@
     "@nodelib/fs.scandir" "2.1.5"
     fastq "^1.6.0"
 
+"@opentelemetry/api@1.9.0":
+  version "1.9.0"
+  resolved "https://registry.npmjs.org/@opentelemetry/api/-/api-1.9.0.tgz"
+  integrity sha512-3giAOQvZiH5F9bMlMiv8+GSPMeqg0dbaeo58/0SlA9sxSqZhnUtxzX9/2FzyhS9sWQf5S0GJE0AKBrFqjpeYcg==
+
+"@peculiar/asn1-cms@^2.6.0":
+  version "2.6.0"
+  resolved "https://registry.npmjs.org/@peculiar/asn1-cms/-/asn1-cms-2.6.0.tgz"
+  integrity sha512-2uZqP+ggSncESeUF/9Su8rWqGclEfEiz1SyU02WX5fUONFfkjzS2Z/F1Li0ofSmf4JqYXIOdCAZqIXAIBAT1OA==
+  dependencies:
+    "@peculiar/asn1-schema" "^2.6.0"
+    "@peculiar/asn1-x509" "^2.6.0"
+    "@peculiar/asn1-x509-attr" "^2.6.0"
+    asn1js "^3.0.6"
+    tslib "^2.8.1"
+
+"@peculiar/asn1-csr@^2.6.0":
+  version "2.6.0"
+  resolved "https://registry.npmjs.org/@peculiar/asn1-csr/-/asn1-csr-2.6.0.tgz"
+  integrity sha512-BeWIu5VpTIhfRysfEp73SGbwjjoLL/JWXhJ/9mo4vXnz3tRGm+NGm3KNcRzQ9VMVqwYS2RHlolz21svzRXIHPQ==
+  dependencies:
+    "@peculiar/asn1-schema" "^2.6.0"
+    "@peculiar/asn1-x509" "^2.6.0"
+    asn1js "^3.0.6"
+    tslib "^2.8.1"
+
+"@peculiar/asn1-ecc@^2.6.0":
+  version "2.6.0"
+  resolved "https://registry.npmjs.org/@peculiar/asn1-ecc/-/asn1-ecc-2.6.0.tgz"
+  integrity sha512-FF3LMGq6SfAOwUG2sKpPXblibn6XnEIKa+SryvUl5Pik+WR9rmRA3OCiwz8R3lVXnYnyRkSZsSLdml8H3UiOcw==
+  dependencies:
+    "@peculiar/asn1-schema" "^2.6.0"
+    "@peculiar/asn1-x509" "^2.6.0"
+    asn1js "^3.0.6"
+    tslib "^2.8.1"
+
+"@peculiar/asn1-pfx@^2.6.0":
+  version "2.6.0"
+  resolved "https://registry.npmjs.org/@peculiar/asn1-pfx/-/asn1-pfx-2.6.0.tgz"
+  integrity sha512-rtUvtf+tyKGgokHHmZzeUojRZJYPxoD/jaN1+VAB4kKR7tXrnDCA/RAWXAIhMJJC+7W27IIRGe9djvxKgsldCQ==
+  dependencies:
+    "@peculiar/asn1-cms" "^2.6.0"
+    "@peculiar/asn1-pkcs8" "^2.6.0"
+    "@peculiar/asn1-rsa" "^2.6.0"
+    "@peculiar/asn1-schema" "^2.6.0"
+    asn1js "^3.0.6"
+    tslib "^2.8.1"
+
+"@peculiar/asn1-pkcs8@^2.6.0":
+  version "2.6.0"
+  resolved "https://registry.npmjs.org/@peculiar/asn1-pkcs8/-/asn1-pkcs8-2.6.0.tgz"
+  integrity sha512-KyQ4D8G/NrS7Fw3XCJrngxmjwO/3htnA0lL9gDICvEQ+GJ+EPFqldcJQTwPIdvx98Tua+WjkdKHSC0/Km7T+lA==
+  dependencies:
+    "@peculiar/asn1-schema" "^2.6.0"
+    "@peculiar/asn1-x509" "^2.6.0"
+    asn1js "^3.0.6"
+    tslib "^2.8.1"
+
+"@peculiar/asn1-pkcs9@^2.6.0":
+  version "2.6.0"
+  resolved "https://registry.npmjs.org/@peculiar/asn1-pkcs9/-/asn1-pkcs9-2.6.0.tgz"
+  integrity sha512-b78OQ6OciW0aqZxdzliXGYHASeCvvw5caqidbpQRYW2mBtXIX2WhofNXTEe7NyxTb0P6J62kAAWLwn0HuMF1Fw==
+  dependencies:
+    "@peculiar/asn1-cms" "^2.6.0"
+    "@peculiar/asn1-pfx" "^2.6.0"
+    "@peculiar/asn1-pkcs8" "^2.6.0"
+    "@peculiar/asn1-schema" "^2.6.0"
+    "@peculiar/asn1-x509" "^2.6.0"
+    "@peculiar/asn1-x509-attr" "^2.6.0"
+    asn1js "^3.0.6"
+    tslib "^2.8.1"
+
+"@peculiar/asn1-rsa@^2.6.0":
+  version "2.6.0"
+  resolved "https://registry.npmjs.org/@peculiar/asn1-rsa/-/asn1-rsa-2.6.0.tgz"
+  integrity sha512-Nu4C19tsrTsCp9fDrH+sdcOKoVfdfoQQ7S3VqjJU6vedR7tY3RLkQ5oguOIB3zFW33USDUuYZnPEQYySlgha4w==
+  dependencies:
+    "@peculiar/asn1-schema" "^2.6.0"
+    "@peculiar/asn1-x509" "^2.6.0"
+    asn1js "^3.0.6"
+    tslib "^2.8.1"
+
+"@peculiar/asn1-schema@^2.6.0":
+  version "2.6.0"
+  resolved "https://registry.npmjs.org/@peculiar/asn1-schema/-/asn1-schema-2.6.0.tgz"
+  integrity sha512-xNLYLBFTBKkCzEZIw842BxytQQATQv+lDTCEMZ8C196iJcJJMBUZxrhSTxLaohMyKK8QlzRNTRkUmanucnDSqg==
+  dependencies:
+    asn1js "^3.0.6"
+    pvtsutils "^1.3.6"
+    tslib "^2.8.1"
+
+"@peculiar/asn1-x509-attr@^2.6.0":
+  version "2.6.0"
+  resolved "https://registry.npmjs.org/@peculiar/asn1-x509-attr/-/asn1-x509-attr-2.6.0.tgz"
+  integrity sha512-MuIAXFX3/dc8gmoZBkwJWxUWOSvG4MMDntXhrOZpJVMkYX+MYc/rUAU2uJOved9iJEoiUx7//3D8oG83a78UJA==
+  dependencies:
+    "@peculiar/asn1-schema" "^2.6.0"
+    "@peculiar/asn1-x509" "^2.6.0"
+    asn1js "^3.0.6"
+    tslib "^2.8.1"
+
+"@peculiar/asn1-x509@^2.6.0":
+  version "2.6.0"
+  resolved "https://registry.npmjs.org/@peculiar/asn1-x509/-/asn1-x509-2.6.0.tgz"
+  integrity sha512-uzYbPEpoQiBoTq0/+jZtpM6Gq6zADBx+JNFP3yqRgziWBxQ/Dt/HcuvRfm9zJTPdRcBqPNdaRHTVwpyiq6iNMA==
+  dependencies:
+    "@peculiar/asn1-schema" "^2.6.0"
+    asn1js "^3.0.6"
+    pvtsutils "^1.3.6"
+    tslib "^2.8.1"
+
+"@peculiar/x509@^1.14.2":
+  version "1.14.3"
+  resolved "https://registry.npmjs.org/@peculiar/x509/-/x509-1.14.3.tgz"
+  integrity sha512-C2Xj8FZ0uHWeCXXqX5B4/gVFQmtSkiuOolzAgutjTfseNOHT3pUjljDZsTSxXFGgio54bCzVFqmEOUrIVk8RDA==
+  dependencies:
+    "@peculiar/asn1-cms" "^2.6.0"
+    "@peculiar/asn1-csr" "^2.6.0"
+    "@peculiar/asn1-ecc" "^2.6.0"
+    "@peculiar/asn1-pkcs9" "^2.6.0"
+    "@peculiar/asn1-rsa" "^2.6.0"
+    "@peculiar/asn1-schema" "^2.6.0"
+    "@peculiar/asn1-x509" "^2.6.0"
+    pvtsutils "^1.3.6"
+    reflect-metadata "^0.2.2"
+    tslib "^2.8.1"
+    tsyringe "^4.10.0"
+
 "@pnpm/config.env-replace@^1.1.0":
   version "1.1.0"
   resolved "https://registry.npmjs.org/@pnpm/config.env-replace/-/config.env-replace-1.1.0.tgz"
@@ -2051,6 +2368,11 @@
     micromark-util-character "^1.1.0"
     micromark-util-symbol "^1.0.1"
 
+"@standard-schema/spec@^1.0.0":
+  version "1.1.0"
+  resolved "https://registry.npmjs.org/@standard-schema/spec/-/spec-1.1.0.tgz"
+  integrity sha512-l2aFy5jALhniG5HgqrD6jXLi/rUWrKvqN/qJx6yoJsgKhblVd+iqqU4RCXavm/jPityDo5TCvKMnpjKnOriy0w==
+
 "@svgr/babel-plugin-add-jsx-attribute@8.0.0":
   version "8.0.0"
   resolved "https://registry.npmjs.org/@svgr/babel-plugin-add-jsx-attribute/-/babel-plugin-add-jsx-attribute-8.0.0.tgz"
@@ -2182,21 +2504,21 @@
     "@types/estree" "*"
 
 "@types/body-parser@*":
-  version "1.19.5"
-  resolved "https://registry.npmjs.org/@types/body-parser/-/body-parser-1.19.5.tgz"
-  integrity sha512-fB3Zu92ucau0iQ0JMCFQE7b/dv8Ot07NI3KaZIkIUNXq82k4eBAqUaneXfleGY9JWskeS9y+u0nXMyspcuQrCg==
+  version "1.19.6"
+  resolved "https://registry.npmjs.org/@types/body-parser/-/body-parser-1.19.6.tgz"
+  integrity sha512-HLFeCYgz89uk22N5Qg3dvGvsv46B8GLvKKo1zKG4NybA8U2DiEO3w9lqGg29t/tfLRJpJ6iQxnVw4OnB7MoM9g==
   dependencies:
     "@types/connect" "*"
     "@types/node" "*"
 
-"@types/bonjour@^3.5.9":
+"@types/bonjour@^3.5.13":
   version "3.5.13"
   resolved "https://registry.npmjs.org/@types/bonjour/-/bonjour-3.5.13.tgz"
   integrity sha512-z9fJ5Im06zvUL548KvYNecEVlA7cVDkGUi6kZusb04mpyEFKCIZJvloCcmpmLaIahDpOQGHaHmG6imtPMmPXGQ==
   dependencies:
     "@types/node" "*"
 
-"@types/connect-history-api-fallback@^1.3.5":
+"@types/connect-history-api-fallback@^1.5.4":
   version "1.5.4"
   resolved "https://registry.npmjs.org/@types/connect-history-api-fallback/-/connect-history-api-fallback-1.5.4.tgz"
   integrity sha512-n6Cr2xS1h4uAulPRdlw6Jl6s1oG8KrVilPN2yUITEs+K48EzMJJ3W1xy8K5eWuFvjp3R74AOIGSmp2UfBJ8HFw==
@@ -2246,45 +2568,25 @@
   resolved "https://registry.npmjs.org/@types/estree/-/estree-1.0.6.tgz"
   integrity sha512-AYnb1nQyY49te+VRAVgmzfcgjYS91mY5P0TKUDCLEM+gNnA+3T6rWITXRLYCpahpqSQbN5cE+gHpnPyXjHWxcw==
 
-"@types/express-serve-static-core@*", "@types/express-serve-static-core@^5.0.0":
-  version "5.0.5"
-  resolved "https://registry.npmjs.org/@types/express-serve-static-core/-/express-serve-static-core-5.0.5.tgz"
-  integrity sha512-GLZPrd9ckqEBFMcVM/qRFAP0Hg3qiVEojgEFsx/N/zKXsBzbGF6z5FBDpZ0+Xhp1xr+qRZYjfGr1cWHB9oFHSA==
-  dependencies:
-    "@types/node" "*"
-    "@types/qs" "*"
-    "@types/range-parser" "*"
-    "@types/send" "*"
-
-"@types/express-serve-static-core@^4.17.33":
-  version "4.19.6"
-  resolved "https://registry.npmjs.org/@types/express-serve-static-core/-/express-serve-static-core-4.19.6.tgz"
-  integrity sha512-N4LZ2xG7DatVqhCZzOGb1Yi5lMbXSZcmdLDe9EzSndPV2HpWYWzRbaerl2n27irrm94EPpprqa8KpskPT085+A==
+"@types/express-serve-static-core@*", "@types/express-serve-static-core@^4.17.21", "@types/express-serve-static-core@^4.17.33":
+  version "4.19.8"
+  resolved "https://registry.npmjs.org/@types/express-serve-static-core/-/express-serve-static-core-4.19.8.tgz"
+  integrity sha512-02S5fmqeoKzVZCHPZid4b8JH2eM5HzQLZWN2FohQEy/0eXTq8VXZfSN6Pcr3F6N9R/vNrj7cpgbhjie6m/1tCA==
   dependencies:
     "@types/node" "*"
     "@types/qs" "*"
     "@types/range-parser" "*"
     "@types/send" "*"
 
-"@types/express@*":
-  version "5.0.0"
-  resolved "https://registry.npmjs.org/@types/express/-/express-5.0.0.tgz"
-  integrity sha512-DvZriSMehGHL1ZNLzi6MidnsDhUZM/x2pRdDIKdwbUNqqwHxMlRdkxtn6/EPKyqKpHqTl/4nRZsRNLpZxZRpPQ==
-  dependencies:
-    "@types/body-parser" "*"
-    "@types/express-serve-static-core" "^5.0.0"
-    "@types/qs" "*"
-    "@types/serve-static" "*"
-
-"@types/express@^4.17.13":
-  version "4.17.21"
-  resolved "https://registry.npmjs.org/@types/express/-/express-4.17.21.tgz"
-  integrity sha512-ejlPM315qwLpaQlQDTjPdsUFSc6ZsP4AN6AlWnogPjQ7CVi7PYF3YVz+CY3jE2pwYf7E/7HlDAN0rV2GxTG0HQ==
+"@types/express@*", "@types/express@^4.17.13", "@types/express@^4.17.25":
+  version "4.17.25"
+  resolved "https://registry.npmjs.org/@types/express/-/express-4.17.25.tgz"
+  integrity sha512-dVd04UKsfpINUnK0yBoYHDF3xu7xVH4BuDotC/xGuycx4CgbP48X/KF/586bcObxT0HENHXEU8Nqtu6NR+eKhw==
   dependencies:
     "@types/body-parser" "*"
     "@types/express-serve-static-core" "^4.17.33"
     "@types/qs" "*"
-    "@types/serve-static" "*"
+    "@types/serve-static" "^1"
 
 "@types/gtag.js@^0.0.12":
   version "0.0.12"
@@ -2314,14 +2616,14 @@
   integrity sha512-1m0bIFVc7eJWyve9S0RnuRgcQqF/Xd5QsUZAZeQFr1Q3/p9JWoQQEqmVy+DPTNpGXwhgIetAoYF8JSc33q29QA==
 
 "@types/http-errors@*":
-  version "2.0.4"
-  resolved "https://registry.npmjs.org/@types/http-errors/-/http-errors-2.0.4.tgz"
-  integrity sha512-D0CFMMtydbJAegzOyHjtiKPLlvnm3iTZyZRSZoLq2mRhDdmLfIWOCYPfQJ4cu2erKghU++QvjcUjp/5h7hESpA==
+  version "2.0.5"
+  resolved "https://registry.npmjs.org/@types/http-errors/-/http-errors-2.0.5.tgz"
+  integrity sha512-r8Tayk8HJnX0FztbZN7oVqGccWgw98T/0neJphO91KkmOzug1KkofZURD4UaD5uH8AqcFLfdPErnBod0u71/qg==
 
 "@types/http-proxy@^1.17.8":
-  version "1.17.15"
-  resolved "https://registry.npmjs.org/@types/http-proxy/-/http-proxy-1.17.15.tgz"
-  integrity sha512-25g5atgiVNTIv0LBDTg1H74Hvayx0ajtJPLLcYE3whFv75J0pWNtOBzaXJQgDTmrX1bx5U9YC2w/n65BN1HwRQ==
+  version "1.17.17"
+  resolved "https://registry.npmjs.org/@types/http-proxy/-/http-proxy-1.17.17.tgz"
+  integrity sha512-ED6LB+Z1AVylNTu7hdzuBqOgMnvG/ld6wGCG8wFnAzKX5uyW2K3WD52v0gnLCTK/VLpXtKckgWuyScYK6cSPaw==
   dependencies:
     "@types/node" "*"
 
@@ -2344,7 +2646,7 @@
   dependencies:
     "@types/istanbul-lib-report" "*"
 
-"@types/json-schema@*", "@types/json-schema@^7.0.4", "@types/json-schema@^7.0.5", "@types/json-schema@^7.0.8", "@types/json-schema@^7.0.9":
+"@types/json-schema@*", "@types/json-schema@^7.0.8", "@types/json-schema@^7.0.9":
   version "7.0.15"
   resolved "https://registry.npmjs.org/@types/json-schema/-/json-schema-7.0.15.tgz"
   integrity sha512-5+fP8P8MFNC+AyZCDxrB2pkZFPGzqQWUzpSeuuVLvm8VMcorNYavBqoFcxK8bQz4Qsbn4oUEEem4wDLfcysGHA==
@@ -2371,13 +2673,6 @@
   resolved "https://registry.npmjs.org/@types/ms/-/ms-2.1.0.tgz"
   integrity sha512-GsCCIZDE/p3i96vtEqx+7dBUGXrc7zeSK3wwPHIaRThS+9OhWIXRqzs4d6k1SVU8g91DrNRWxWUGhp5KXQb2VA==
 
-"@types/node-forge@^1.3.0":
-  version "1.3.11"
-  resolved "https://registry.npmjs.org/@types/node-forge/-/node-forge-1.3.11.tgz"
-  integrity sha512-FQx220y22OKNTqaByeBGqHWYz4cl94tpcxeFdvBo3wjG6XPBuZ0BNgNZRV5J5TFmmcsJ4IzsLkmGRiQbnYsBEQ==
-  dependencies:
-    "@types/node" "*"
-
 "@types/node@*":
   version "22.10.7"
   resolved "https://registry.npmjs.org/@types/node/-/node-22.10.7.tgz"
@@ -2390,11 +2685,6 @@
   resolved "https://registry.npmjs.org/@types/node/-/node-17.0.45.tgz"
   integrity sha512-w+tIMs3rq2afQdsPJlODhoUEKzFP1ayaoyl1CcnwtIlsVe7K7bA1NGm4s3PraqTLlXnbIN84zuBlxBWo1u9BLw==
 
-"@types/parse-json@^4.0.0":
-  version "4.0.2"
-  resolved "https://registry.npmjs.org/@types/parse-json/-/parse-json-4.0.2.tgz"
-  integrity sha512-dISoDXWWQwUquiKsyZ4Ng+HX2KsPL7LyHKHQwgGFEA3IaKac4Obd+h2a/a6waisAoepJlBcx9paWqjA8/HVjCw==
-
 "@types/prismjs@^1.26.0":
   version "1.26.5"
   resolved "https://registry.npmjs.org/@types/prismjs/-/prismjs-1.26.5.tgz"
@@ -2406,9 +2696,9 @@
   integrity sha512-gNMvNH49DJ7OJYv+KAKn0Xp45p8PLl6zo2YnvDIbTd4J6MER2BmWN49TG7n9LvkyihINxeKW8+3bfS2yDC9dzQ==
 
 "@types/qs@*":
-  version "6.9.18"
-  resolved "https://registry.npmjs.org/@types/qs/-/qs-6.9.18.tgz"
-  integrity sha512-kK7dgTYDyGqS+e2Q4aK9X3D7q234CIZ1Bv0q/7Z5IwRDoADNU81xXJK/YVyLbLTZCoIwUoDoffFeF+p/eIklAA==
+  version "6.14.0"
+  resolved "https://registry.npmjs.org/@types/qs/-/qs-6.14.0.tgz"
+  integrity sha512-eOunJqu0K1923aExK6y8p6fsihYEn/BYuQ4g0CxAAgFc4b/ZLN4CrsRZ55srTdqoiLzU2B2evC+apEIxprEzkQ==
 
 "@types/range-parser@*":
   version "1.2.7"
@@ -2441,7 +2731,7 @@
     "@types/history" "^4.7.11"
     "@types/react" "*"
 
-"@types/react@*", "@types/react@>= 16.8.0 < 19.0.0", "@types/react@>=16":
+"@types/react@*", "@types/react@>= 16.8.0 < 20.0.0", "@types/react@>=16":
   version "18.3.18"
   resolved "https://registry.npmjs.org/@types/react/-/react-18.3.18.tgz"
   integrity sha512-t4yC+vtgnkYjNSKlFx1jkAhH8LgTo2N/7Qvi83kdEaUtMDiwpbLAktKDaAMlRcJ5eSxZkH74eEGt1ky31d7kfQ==
@@ -2449,10 +2739,10 @@
     "@types/prop-types" "*"
     csstype "^3.0.2"
 
-"@types/retry@0.12.0":
-  version "0.12.0"
-  resolved "https://registry.npmjs.org/@types/retry/-/retry-0.12.0.tgz"
-  integrity sha512-wWKOClTTiizcZhXnPY4wikVAwmdYHp8q6DmC+EJUzAMsycb7HB32Kh9RN4+0gExjmPmZSAQjgURXIGATPegAvA==
+"@types/retry@0.12.2":
+  version "0.12.2"
+  resolved "https://registry.npmjs.org/@types/retry/-/retry-0.12.2.tgz"
+  integrity sha512-XISRgDJ2Tc5q4TRqvgJtzsRkFYNJzZrhTdtMoGVBttwzzQJkPnS3WWTFc7kuDRoPtPakl+T+OfdEUjYJj7Jbow==
 
 "@types/sax@^1.2.1":
   version "1.2.7"
@@ -2462,30 +2752,37 @@
     "@types/node" "*"
 
 "@types/send@*":
-  version "0.17.4"
-  resolved "https://registry.npmjs.org/@types/send/-/send-0.17.4.tgz"
-  integrity sha512-x2EM6TJOybec7c52BX0ZspPodMsQUd5L6PRwOunVyVUhXiBSKf3AezDL8Dgvgt5o0UfKNfuA0eMLr2wLT4AiBA==
+  version "1.2.1"
+  resolved "https://registry.npmjs.org/@types/send/-/send-1.2.1.tgz"
+  integrity sha512-arsCikDvlU99zl1g69TcAB3mzZPpxgw0UQnaHeC1Nwb015xp8bknZv5rIfri9xTOcMuaVgvabfIRA7PSZVuZIQ==
+  dependencies:
+    "@types/node" "*"
+
+"@types/send@<1":
+  version "0.17.6"
+  resolved "https://registry.npmjs.org/@types/send/-/send-0.17.6.tgz"
+  integrity sha512-Uqt8rPBE8SY0RK8JB1EzVOIZ32uqy8HwdxCnoCOsYrvnswqmFZ/k+9Ikidlk/ImhsdvBsloHbAlewb2IEBV/Og==
   dependencies:
     "@types/mime" "^1"
     "@types/node" "*"
 
-"@types/serve-index@^1.9.1":
+"@types/serve-index@^1.9.4":
   version "1.9.4"
   resolved "https://registry.npmjs.org/@types/serve-index/-/serve-index-1.9.4.tgz"
   integrity sha512-qLpGZ/c2fhSs5gnYsQxtDEq3Oy8SXPClIXkW5ghvAvsNuVSA8k+gCONcUCS/UjLEYvYps+e8uBtfgXgvhwfNug==
   dependencies:
     "@types/express" "*"
 
-"@types/serve-static@*", "@types/serve-static@^1.13.10":
-  version "1.15.7"
-  resolved "https://registry.npmjs.org/@types/serve-static/-/serve-static-1.15.7.tgz"
-  integrity sha512-W8Ym+h8nhuRwaKPaDw34QUkwsGi6Rc4yYqvKFo5rm2FUEhCFbzVWrxXUxuKK8TASjWsysJY0nsmNCGhCOIsrOw==
+"@types/serve-static@^1", "@types/serve-static@^1.15.5":
+  version "1.15.10"
+  resolved "https://registry.npmjs.org/@types/serve-static/-/serve-static-1.15.10.tgz"
+  integrity sha512-tRs1dB+g8Itk72rlSI2ZrW6vZg0YrLI81iQSTkMmOqnqCaNr/8Ek4VwWcN5vZgCYWbg/JJSGBlUaYGAOP73qBw==
   dependencies:
     "@types/http-errors" "*"
     "@types/node" "*"
-    "@types/send" "*"
+    "@types/send" "<1"
 
-"@types/sockjs@^0.3.33":
+"@types/sockjs@^0.3.36":
   version "0.3.36"
   resolved "https://registry.npmjs.org/@types/sockjs/-/sockjs-0.3.36.tgz"
   integrity sha512-MK9V6NzAS1+Ud7JV9lJLFqW85VbC9dq3LmwZCuBe4wBDgKC0Kj/jd8Xl+nSviU+Qc3+m7umHHyHg//2KSa0a0Q==
@@ -2502,10 +2799,10 @@
   resolved "https://registry.npmjs.org/@types/unist/-/unist-2.0.11.tgz"
   integrity sha512-CmBKiL6NNo/OqgmMn95Fk9Whlp2mtvIv+KNpQKN2F4SjvrEesubTRWGYSg+BnWZOnlCaSTU1sMpsBOzgbYhnsA==
 
-"@types/ws@^8.5.5":
-  version "8.5.13"
-  resolved "https://registry.npmjs.org/@types/ws/-/ws-8.5.13.tgz"
-  integrity sha512-osM/gWBTPKgHV8XkTunnegTRIsvF6owmf5w+JtAfOw472dptdm0dlGv4xCt6GwQRcC2XVOvvRE/0bAoQcL2QkA==
+"@types/ws@^8.5.10":
+  version "8.18.1"
+  resolved "https://registry.npmjs.org/@types/ws/-/ws-8.18.1.tgz"
+  integrity sha512-ThVF6DCVhA8kUGy+aazFQ4kXQ7E1Ty7A3ypFOe0IcJV8O/M511G99AW24irKrW56Wt44yG9+ij8FaqoBGkuBXg==
   dependencies:
     "@types/node" "*"
 
@@ -2515,9 +2812,9 @@
   integrity sha512-I4q9QU9MQv4oEOz4tAHJtNz1cwuLxn2F3xcc2iV5WdqLPpUnj30aUuxt1mAxYTG+oe8CZMV/+6rU4S4gRDzqtQ==
 
 "@types/yargs@^17.0.8":
-  version "17.0.33"
-  resolved "https://registry.npmjs.org/@types/yargs/-/yargs-17.0.33.tgz"
-  integrity sha512-WpxBCKWPLr4xSsHgz511rFJAM+wS28w2zEO1QDNY5zM/S8ok70NNfztH0xwhqKyaK0OHCbN98LDAZuy1ctxDkA==
+  version "17.0.35"
+  resolved "https://registry.npmjs.org/@types/yargs/-/yargs-17.0.35.tgz"
+  integrity sha512-qUHkeCyQFxMXg79wQfTtfndEC+N9ZZg76HJftDJp+qH2tV7Gj4OJi7l+PiWwJ+pWtW8GwSmqsDj/oymhrTWXjg==
   dependencies:
     "@types/yargs-parser" "*"
 
@@ -2526,6 +2823,11 @@
   resolved "https://registry.npmjs.org/@ungap/structured-clone/-/structured-clone-1.2.1.tgz"
   integrity sha512-fEzPV3hSkSMltkw152tJKNARhOupqbH96MZWyRjNaYZOMIzbrTeQDG+MTc6Mr2pgzFQzFxAfmhGDNP5QK++2ZA==
 
+"@vercel/oidc@3.1.0":
+  version "3.1.0"
+  resolved "https://registry.npmjs.org/@vercel/oidc/-/oidc-3.1.0.tgz"
+  integrity sha512-Fw28YZpRnA3cAHHDlkt7xQHiJ0fcL+NRcIqsocZQUSmbzeIKRpwttJjik5ZGanXP+vlA4SbTg+AbA3bP363l+w==
+
 "@webassemblyjs/ast@^1.14.1", "@webassemblyjs/ast@1.14.1":
   version "1.14.1"
   resolved "https://registry.npmjs.org/@webassemblyjs/ast/-/ast-1.14.1.tgz"
@@ -2682,7 +2984,7 @@ acorn-walk@^8.0.0:
   resolved "https://registry.npmjs.org/acorn/-/acorn-8.14.0.tgz"
   integrity sha512-cl669nCJTZBsL97OF4kUQm5g5hC2uihk0NxY3WENAC0TYdILVkAyHymAntgxGkl7K+t0cXIrH5siy5S4XkFycA==
 
-address@^1.0.1, address@^1.1.2:
+address@^1.0.1:
   version "1.2.2"
   resolved "https://registry.npmjs.org/address/-/address-1.2.2.tgz"
   integrity sha512-4B/qKCfeE/ODUaAUpSwfzazo5x29WD4r3vXiWsB7I2mSDAihwEqKO+g8GELZUQSSAo5e1XTYh3ZVfLyxBc12nA==
@@ -2695,6 +2997,16 @@ aggregate-error@^3.0.0:
     clean-stack "^2.0.0"
     indent-string "^4.0.0"
 
+ai@^5.0.30, ai@5.0.121:
+  version "5.0.121"
+  resolved "https://registry.npmjs.org/ai/-/ai-5.0.121.tgz"
+  integrity sha512-3iYPdARKGLryC/7OA9RgBUaym1gynvWS7UPy8NwoRNCKP52lshldtHB5xcEfVviw7liWH2zJlW9yEzsDglcIEQ==
+  dependencies:
+    "@ai-sdk/gateway" "2.0.27"
+    "@ai-sdk/provider" "2.0.1"
+    "@ai-sdk/provider-utils" "3.0.20"
+    "@opentelemetry/api" "1.9.0"
+
 ajv-formats@^2.1.1:
   version "2.1.1"
   resolved "https://registry.npmjs.org/ajv-formats/-/ajv-formats-2.1.1.tgz"
@@ -2702,7 +3014,7 @@ ajv-formats@^2.1.1:
   dependencies:
     ajv "^8.0.0"
 
-ajv-keywords@^3.4.1, ajv-keywords@^3.5.2:
+ajv-keywords@^3.5.2:
   version "3.5.2"
   resolved "https://registry.npmjs.org/ajv-keywords/-/ajv-keywords-3.5.2.tgz"
   integrity sha512-5p6WTN0DdTGVQk6VjcEju19IgaHudalcfabD7yhDGeA6bcQnmL+CpveLJq/3hvfwd1aof6L386Ougkx6RfyMIQ==
@@ -2714,7 +3026,7 @@ ajv-keywords@^5.1.0:
   dependencies:
     fast-deep-equal "^3.1.3"
 
-ajv@^6.12.2, ajv@^6.12.5, ajv@^6.9.1:
+ajv@^6.12.5, ajv@^6.9.1:
   version "6.12.6"
   resolved "https://registry.npmjs.org/ajv/-/ajv-6.12.6.tgz"
   integrity sha512-j3fVLgvTo527anyYyJOGTYJbG+vnnQYvE0m5mmkc1TK+nxAppkCLMIL0aZ4dblVCNoGShhm+kzE4ZUykBoMg4g==
@@ -2734,31 +3046,32 @@ ajv@^8.0.0, ajv@^8.8.2, ajv@^8.9.0:
     json-schema-traverse "^1.0.0"
     require-from-string "^2.0.2"
 
-algoliasearch-helper@^3.22.6:
-  version "3.23.0"
-  resolved "https://registry.npmjs.org/algoliasearch-helper/-/algoliasearch-helper-3.23.0.tgz"
-  integrity sha512-8CK4Gb/ju4OesAYcS+mjBpNiVA7ILWpg7D2vhBZohh0YkG8QT1KZ9LG+8+EntQBUGoKtPy06OFhiwP4f5zzAQg==
+algoliasearch-helper@^3.26.0:
+  version "3.27.0"
+  resolved "https://registry.npmjs.org/algoliasearch-helper/-/algoliasearch-helper-3.27.0.tgz"
+  integrity sha512-eNYchRerbsvk2doHOMfdS1/B6Tm70oGtu8mzQlrNzbCeQ8p1MjCW8t/BL6iZ5PD+cL5NNMgTMyMnmiXZ1sgmNw==
   dependencies:
     "@algolia/events" "^4.0.1"
 
-algoliasearch@^5.14.2, algoliasearch@^5.17.1, "algoliasearch@>= 3.1 < 6", "algoliasearch@>= 4.9.1 < 6":
-  version "5.19.0"
-  resolved "https://registry.npmjs.org/algoliasearch/-/algoliasearch-5.19.0.tgz"
-  integrity sha512-zrLtGhC63z3sVLDDKGW+SlCRN9eJHFTgdEmoAOpsVh6wgGL1GgTTDou7tpCBjevzgIvi3AIyDAQO3Xjbg5eqZg==
-  dependencies:
-    "@algolia/client-abtesting" "5.19.0"
-    "@algolia/client-analytics" "5.19.0"
-    "@algolia/client-common" "5.19.0"
-    "@algolia/client-insights" "5.19.0"
-    "@algolia/client-personalization" "5.19.0"
-    "@algolia/client-query-suggestions" "5.19.0"
-    "@algolia/client-search" "5.19.0"
-    "@algolia/ingestion" "1.19.0"
-    "@algolia/monitoring" "1.19.0"
-    "@algolia/recommend" "5.19.0"
-    "@algolia/requester-browser-xhr" "5.19.0"
-    "@algolia/requester-fetch" "5.19.0"
-    "@algolia/requester-node-http" "5.19.0"
+algoliasearch@^5.28.0, algoliasearch@^5.37.0, "algoliasearch@>= 3.1 < 6", "algoliasearch@>= 4.9.1 < 6":
+  version "5.46.3"
+  resolved "https://registry.npmjs.org/algoliasearch/-/algoliasearch-5.46.3.tgz"
+  integrity sha512-n/NdPglzmkcNYZfIT3Fo8pnDR/lKiK1kZ1Yaa315UoLyHymADhWw15+bzN5gBxrCA8KyeNu0JJD6mLtTov43lQ==
+  dependencies:
+    "@algolia/abtesting" "1.12.3"
+    "@algolia/client-abtesting" "5.46.3"
+    "@algolia/client-analytics" "5.46.3"
+    "@algolia/client-common" "5.46.3"
+    "@algolia/client-insights" "5.46.3"
+    "@algolia/client-personalization" "5.46.3"
+    "@algolia/client-query-suggestions" "5.46.3"
+    "@algolia/client-search" "5.46.3"
+    "@algolia/ingestion" "1.46.3"
+    "@algolia/monitoring" "1.46.3"
+    "@algolia/recommend" "5.46.3"
+    "@algolia/requester-browser-xhr" "5.46.3"
+    "@algolia/requester-fetch" "5.46.3"
+    "@algolia/requester-node-http" "5.46.3"
 
 ansi-align@^3.0.1:
   version "3.0.1"
@@ -2836,26 +3149,29 @@ array-union@^2.1.0:
   resolved "https://registry.npmjs.org/array-union/-/array-union-2.1.0.tgz"
   integrity sha512-HGyxoOTYUyCM6stUe6EJgnd4EoewAI7zMdfqO+kGjnlZmBDz/cR5pf8r/cR4Wq60sL/p0IkcjUEEPwS3GFrIyw==
 
+asn1js@^3.0.6:
+  version "3.0.7"
+  resolved "https://registry.npmjs.org/asn1js/-/asn1js-3.0.7.tgz"
+  integrity sha512-uLvq6KJu04qoQM6gvBfKFjlh6Gl0vOKQuR5cJMDHQkmwfMOQeN3F3SHCv9SNYSL+CRoHvOGFfllDlVz03GQjvQ==
+  dependencies:
+    pvtsutils "^1.3.6"
+    pvutils "^1.1.3"
+    tslib "^2.8.1"
+
 astring@^1.8.0:
   version "1.9.0"
   resolved "https://registry.npmjs.org/astring/-/astring-1.9.0.tgz"
   integrity sha512-LElXdjswlqjWrPpJFg1Fx4wpkOCxj1TDHlSV4PlaRxHGWko024xICaa97ZkMfs6DRKlCguiAI+rbXv5GWwXIkg==
 
-at-least-node@^1.0.0:
-  version "1.0.0"
-  resolved "https://registry.npmjs.org/at-least-node/-/at-least-node-1.0.0.tgz"
-  integrity sha512-+q/t7Ekv1EDY2l6Gda6LLiX14rU9TV20Wa3ofeQmwPFZbOMo9DXrLbOjFaaclkXKWidIaopwAObQDqwWtGUjqg==
-
-autoprefixer@^10.4.19:
-  version "10.4.20"
-  resolved "https://registry.npmjs.org/autoprefixer/-/autoprefixer-10.4.20.tgz"
-  integrity sha512-XY25y5xSv/wEoqzDyXXME4AFfkZI0P23z6Fs3YgymDnKJkCGOnkL0iTxCa85UTqaSgfcqyf3UA6+c7wUvx/16g==
-  dependencies:
-    browserslist "^4.23.3"
-    caniuse-lite "^1.0.30001646"
-    fraction.js "^4.3.7"
-    normalize-range "^0.1.2"
-    picocolors "^1.0.1"
+autoprefixer@^10.4.19, autoprefixer@^10.4.23:
+  version "10.4.23"
+  resolved "https://registry.npmjs.org/autoprefixer/-/autoprefixer-10.4.23.tgz"
+  integrity sha512-YYTXSFulfwytnjAPlw8QHncHJmlvFKtczb8InXaAx9Q0LbfDnfEYDE55omerIJKihhmU61Ft+cAOSzQVaBUmeA==
+  dependencies:
+    browserslist "^4.28.1"
+    caniuse-lite "^1.0.30001760"
+    fraction.js "^5.3.4"
+    picocolors "^1.1.1"
     postcss-value-parser "^4.2.0"
 
 babel-loader@^9.2.1:
@@ -2873,29 +3189,29 @@ babel-plugin-dynamic-import-node@^2.3.3:
   dependencies:
     object.assign "^4.1.0"
 
-babel-plugin-polyfill-corejs2@^0.4.10:
-  version "0.4.12"
-  resolved "https://registry.npmjs.org/babel-plugin-polyfill-corejs2/-/babel-plugin-polyfill-corejs2-0.4.12.tgz"
-  integrity sha512-CPWT6BwvhrTO2d8QVorhTCQw9Y43zOu7G9HigcfxvepOU6b8o3tcWad6oVgZIsZCTt42FFv97aA7ZJsbM4+8og==
+babel-plugin-polyfill-corejs2@^0.4.14:
+  version "0.4.14"
+  resolved "https://registry.npmjs.org/babel-plugin-polyfill-corejs2/-/babel-plugin-polyfill-corejs2-0.4.14.tgz"
+  integrity sha512-Co2Y9wX854ts6U8gAAPXfn0GmAyctHuK8n0Yhfjd6t30g7yvKjspvvOo9yG+z52PZRgFErt7Ka2pYnXCjLKEpg==
   dependencies:
-    "@babel/compat-data" "^7.22.6"
-    "@babel/helper-define-polyfill-provider" "^0.6.3"
+    "@babel/compat-data" "^7.27.7"
+    "@babel/helper-define-polyfill-provider" "^0.6.5"
     semver "^6.3.1"
 
-babel-plugin-polyfill-corejs3@^0.10.6:
-  version "0.10.6"
-  resolved "https://registry.npmjs.org/babel-plugin-polyfill-corejs3/-/babel-plugin-polyfill-corejs3-0.10.6.tgz"
-  integrity sha512-b37+KR2i/khY5sKmWNVQAnitvquQbNdWy6lJdsr0kmquCKEEUgMKK4SboVM3HtfnZilfjr4MMQ7vY58FVWDtIA==
+babel-plugin-polyfill-corejs3@^0.13.0:
+  version "0.13.0"
+  resolved "https://registry.npmjs.org/babel-plugin-polyfill-corejs3/-/babel-plugin-polyfill-corejs3-0.13.0.tgz"
+  integrity sha512-U+GNwMdSFgzVmfhNm8GJUX88AadB3uo9KpJqS3FaqNIPKgySuvMb+bHPsOmmuWyIcuqZj/pzt1RUIUZns4y2+A==
   dependencies:
-    "@babel/helper-define-polyfill-provider" "^0.6.2"
-    core-js-compat "^3.38.0"
+    "@babel/helper-define-polyfill-provider" "^0.6.5"
+    core-js-compat "^3.43.0"
 
-babel-plugin-polyfill-regenerator@^0.6.1:
-  version "0.6.3"
-  resolved "https://registry.npmjs.org/babel-plugin-polyfill-regenerator/-/babel-plugin-polyfill-regenerator-0.6.3.tgz"
-  integrity sha512-LiWSbl4CRSIa5x/JAU6jZiG9eit9w6mz+yVMFwDE83LAWvt0AfGBoZ7HS/mkhrKuh2ZlzfVZYKoLjXdqw6Yt7Q==
+babel-plugin-polyfill-regenerator@^0.6.5:
+  version "0.6.5"
+  resolved "https://registry.npmjs.org/babel-plugin-polyfill-regenerator/-/babel-plugin-polyfill-regenerator-0.6.5.tgz"
+  integrity sha512-ISqQ2frbiNU9vIJkzg7dlPpznPZ4jOiUQ1uSmB0fEHeowtN3COYRsXr/xexn64NpU13P06jc/L5TgiJXOgrbEg==
   dependencies:
-    "@babel/helper-define-polyfill-provider" "^0.6.3"
+    "@babel/helper-define-polyfill-provider" "^0.6.5"
 
 bail@^2.0.0:
   version "2.0.2"
@@ -2907,6 +3223,11 @@ balanced-match@^1.0.0:
   resolved "https://registry.npmjs.org/balanced-match/-/balanced-match-1.0.2.tgz"
   integrity sha512-3oSeUO0TMV67hN1AmbXsK4yaqU7tjiHlbxRDZOpH0KW9+CeX4bRAaX0Anxt0tx2MrpRpWwQaPwIlISEJhYU5Pw==
 
+baseline-browser-mapping@^2.9.0:
+  version "2.9.14"
+  resolved "https://registry.npmjs.org/baseline-browser-mapping/-/baseline-browser-mapping-2.9.14.tgz"
+  integrity sha512-B0xUquLkiGLgHhpPBqvl7GWegWBUNuujQ6kXd/r1U38ElPT6Ok8KZ8e+FpUGEc2ZoRQUzq/aUnaKFc/svWUGSg==
+
 batch@0.6.1:
   version "0.6.1"
   resolved "https://registry.npmjs.org/batch/-/batch-0.6.1.tgz"
@@ -2922,25 +3243,25 @@ binary-extensions@^2.0.0:
   resolved "https://registry.npmjs.org/binary-extensions/-/binary-extensions-2.3.0.tgz"
   integrity sha512-Ceh+7ox5qe7LJuLHoY0feh3pHuUDHAcRUeyL2VYghZwfpkNIy/+8Ocg0a3UuSoYzavmylwuLWQOf3hl0jjMMIw==
 
-body-parser@1.20.3:
-  version "1.20.3"
-  resolved "https://registry.npmjs.org/body-parser/-/body-parser-1.20.3.tgz"
-  integrity sha512-7rAxByjUMqQ3/bHJy7D6OGXvx/MMc4IqBn/X0fcM1QUcAItpZrBEYhWGem+tzXH90c+G01ypMcYJBO9Y30203g==
+body-parser@~1.20.3:
+  version "1.20.4"
+  resolved "https://registry.npmjs.org/body-parser/-/body-parser-1.20.4.tgz"
+  integrity sha512-ZTgYYLMOXY9qKU/57FAo8F+HA2dGX7bqGc71txDRC1rS4frdFI5R7NhluHxH6M0YItAP0sHB4uqAOcYKxO6uGA==
   dependencies:
-    bytes "3.1.2"
+    bytes "~3.1.2"
     content-type "~1.0.5"
     debug "2.6.9"
     depd "2.0.0"
-    destroy "1.2.0"
-    http-errors "2.0.0"
-    iconv-lite "0.4.24"
-    on-finished "2.4.1"
-    qs "6.13.0"
-    raw-body "2.5.2"
+    destroy "~1.2.0"
+    http-errors "~2.0.1"
+    iconv-lite "~0.4.24"
+    on-finished "~2.4.1"
+    qs "~6.14.0"
+    raw-body "~2.5.3"
     type-is "~1.6.18"
-    unpipe "1.0.0"
+    unpipe "~1.0.0"
 
-bonjour-service@^1.0.11:
+bonjour-service@^1.2.1:
   version "1.3.0"
   resolved "https://registry.npmjs.org/bonjour-service/-/bonjour-service-1.3.0.tgz"
   integrity sha512-3YuAUiSkWykd+2Azjgyxei8OWf8thdn8AITIog2M4UICzoqfjlqr64WIjEXZllf/W6vK1goqleSR6brGomxQqA==
@@ -2982,9 +3303,9 @@ boxen@^7.0.0:
     wrap-ansi "^8.1.0"
 
 brace-expansion@^1.1.7:
-  version "1.1.11"
-  resolved "https://registry.npmjs.org/brace-expansion/-/brace-expansion-1.1.11.tgz"
-  integrity sha512-iCuPHDFgrHX7H2vEI/5xpz07zSHB00TpugqhmYtVmMO6518mCuRMoOYFldEBl0g187ufozdaHgWKcYFb61qGiA==
+  version "1.1.12"
+  resolved "https://registry.npmjs.org/brace-expansion/-/brace-expansion-1.1.12.tgz"
+  integrity sha512-9T9UjW3r0UW5c1Q7GTwllptXwhvYmEzFhzMfZ9H7FQWt+uZePjZPjBP/W1ZEyZ1twGWom5/56TF4lPcqjnDHcg==
   dependencies:
     balanced-match "^1.0.0"
     concat-map "0.0.1"
@@ -2996,30 +3317,43 @@ braces@^3.0.3, braces@~3.0.2:
   dependencies:
     fill-range "^7.1.1"
 
-browserslist@^4.0.0, browserslist@^4.18.1, browserslist@^4.21.5, browserslist@^4.23.0, browserslist@^4.23.1, browserslist@^4.23.3, browserslist@^4.24.0, browserslist@^4.24.3, "browserslist@>= 4.21.0":
-  version "4.24.4"
-  resolved "https://registry.npmjs.org/browserslist/-/browserslist-4.24.4.tgz"
-  integrity sha512-KDi1Ny1gSePi1vm0q4oxSF8b4DR44GF4BbmS2YdhPLOEqd8pDviZOGH/GsmRwoWJ2+5Lr085X7naowMwKHDG1A==
+browserslist@^4.0.0, browserslist@^4.21.5, browserslist@^4.23.0, browserslist@^4.24.0, browserslist@^4.28.0, browserslist@^4.28.1, "browserslist@>= 4.21.0":
+  version "4.28.1"
+  resolved "https://registry.npmjs.org/browserslist/-/browserslist-4.28.1.tgz"
+  integrity sha512-ZC5Bd0LgJXgwGqUknZY/vkUQ04r8NXnJZ3yYi4vDmSiZmC/pdSN0NbNRPxZpbtO4uAfDUAFffO8IZoM3Gj8IkA==
   dependencies:
-    caniuse-lite "^1.0.30001688"
-    electron-to-chromium "^1.5.73"
-    node-releases "^2.0.19"
-    update-browserslist-db "^1.1.1"
+    baseline-browser-mapping "^2.9.0"
+    caniuse-lite "^1.0.30001759"
+    electron-to-chromium "^1.5.263"
+    node-releases "^2.0.27"
+    update-browserslist-db "^1.2.0"
 
 buffer-from@^1.0.0:
   version "1.1.2"
   resolved "https://registry.npmjs.org/buffer-from/-/buffer-from-1.1.2.tgz"
   integrity sha512-E+XQCRwSbaaiChtv6k6Dwgc+bx+Bs6vuKJHHl5kox/BaKbhiXzqQOwK4cO22yElGp2OCmjwVhT3HmxgyPGnJfQ==
 
+bundle-name@^4.1.0:
+  version "4.1.0"
+  resolved "https://registry.npmjs.org/bundle-name/-/bundle-name-4.1.0.tgz"
+  integrity sha512-tjwM5exMg6BGRI+kNmTntNsvdZS1X8BFYS6tnJ2hdH0kVxM6/eVZ2xy+FqStSWvYmtfFMDLIxurorHwDKfDz5Q==
+  dependencies:
+    run-applescript "^7.0.0"
+
+bytes@~3.1.2, bytes@3.1.2:
+  version "3.1.2"
+  resolved "https://registry.npmjs.org/bytes/-/bytes-3.1.2.tgz"
+  integrity sha512-/Nf7TyzTx6S3yRJObOAV7956r8cr2+Oj8AC5dt8wSP3BQAoeX58NoHyCU8P8zGkNXStjTSi6fzO6F0pBdcYbEg==
+
 bytes@3.0.0:
   version "3.0.0"
   resolved "https://registry.npmjs.org/bytes/-/bytes-3.0.0.tgz"
   integrity sha512-pMhOfFDPiv9t5jjIXkHosWmkSyQbvsgEVNkz0ERHbuLh2T/7j4Mqqpz523Fe8MVY89KC6Sh/QfS2sM+SjgFDcw==
 
-bytes@3.1.2:
-  version "3.1.2"
-  resolved "https://registry.npmjs.org/bytes/-/bytes-3.1.2.tgz"
-  integrity sha512-/Nf7TyzTx6S3yRJObOAV7956r8cr2+Oj8AC5dt8wSP3BQAoeX58NoHyCU8P8zGkNXStjTSi6fzO6F0pBdcYbEg==
+bytestreamjs@^2.0.1:
+  version "2.0.1"
+  resolved "https://registry.npmjs.org/bytestreamjs/-/bytestreamjs-2.0.1.tgz"
+  integrity sha512-U1Z/ob71V/bXfVABvNr/Kumf5VyeQRBEm6Txb0PQ6S7V5GpBM3w4Cbqz/xPDicR5tN0uvDifng8C+5qECeGwyQ==
 
 cacheable-lookup@^7.0.0:
   version "7.0.0"
@@ -3039,10 +3373,10 @@ cacheable-request@^10.2.8:
     normalize-url "^8.0.0"
     responselike "^3.0.0"
 
-call-bind-apply-helpers@^1.0.0, call-bind-apply-helpers@^1.0.1:
-  version "1.0.1"
-  resolved "https://registry.npmjs.org/call-bind-apply-helpers/-/call-bind-apply-helpers-1.0.1.tgz"
-  integrity sha512-BhYE+WDaywFg2TBWYNXAE+8B1ATnThNBqXHP5nQu0jWJdVvY2hvkpyB3qOmtmDePiS5/BDQ8wASEWGMWRG148g==
+call-bind-apply-helpers@^1.0.0, call-bind-apply-helpers@^1.0.1, call-bind-apply-helpers@^1.0.2:
+  version "1.0.2"
+  resolved "https://registry.npmjs.org/call-bind-apply-helpers/-/call-bind-apply-helpers-1.0.2.tgz"
+  integrity sha512-Sp1ablJ0ivDkSzjcaJdxEunN5/XvksFJ2sMBFfq6x0ryhQV/2b/KwFe21cMpmHtPOSij8K99/wSfoEuTObmuMQ==
   dependencies:
     es-errors "^1.3.0"
     function-bind "^1.1.2"
@@ -3058,12 +3392,12 @@ call-bind@^1.0.8:
     set-function-length "^1.2.2"
 
 call-bound@^1.0.2, call-bound@^1.0.3:
-  version "1.0.3"
-  resolved "https://registry.npmjs.org/call-bound/-/call-bound-1.0.3.tgz"
-  integrity sha512-YTd+6wGlNlPxSuri7Y6X8tY2dmm12UMH66RpKMhiX6rsk5wXXnYgbUcOt8kiS31/AjfoTOvCsE+w8nZQLQnzHA==
+  version "1.0.4"
+  resolved "https://registry.npmjs.org/call-bound/-/call-bound-1.0.4.tgz"
+  integrity sha512-+ys997U96po4Kx/ABpBCqhA9EuxJaQWDQg7295H4hBphv3IZg0boBKuwYpt4YXp6MZ5AmZQnU/tyMTlRpaSejg==
   dependencies:
-    call-bind-apply-helpers "^1.0.1"
-    get-intrinsic "^1.2.6"
+    call-bind-apply-helpers "^1.0.2"
+    get-intrinsic "^1.3.0"
 
 callsites@^3.0.0:
   version "3.1.0"
@@ -3098,17 +3432,17 @@ caniuse-api@^3.0.0:
     lodash.memoize "^4.1.2"
     lodash.uniq "^4.5.0"
 
-caniuse-lite@^1.0.0, caniuse-lite@^1.0.30001646, caniuse-lite@^1.0.30001688:
-  version "1.0.30001692"
-  resolved "https://registry.npmjs.org/caniuse-lite/-/caniuse-lite-1.0.30001692.tgz"
-  integrity sha512-A95VKan0kdtrsnMubMKxEKUKImOPSuCpYgxSQBo036P5YYgVIcOYJEgt/txJWqObiRQeISNCfef9nvlQ0vbV7A==
+caniuse-lite@^1.0.0, caniuse-lite@^1.0.30001759, caniuse-lite@^1.0.30001760:
+  version "1.0.30001764"
+  resolved "https://registry.npmjs.org/caniuse-lite/-/caniuse-lite-1.0.30001764.tgz"
+  integrity sha512-9JGuzl2M+vPL+pz70gtMF9sHdMFbY9FJaQBi186cHKH3pSzDvzoUJUPV6fqiKIMyXbud9ZLg4F3Yza1vJ1+93g==
 
 ccount@^2.0.0:
   version "2.0.1"
   resolved "https://registry.npmjs.org/ccount/-/ccount-2.0.1.tgz"
   integrity sha512-eyrF0jiFpY+3drT6383f1qhkbGsLSifNAjA61IUjZjmLCWjItY6LB9ft9YhoDgwfmclB2zhu51Lc7+95b8NRAg==
 
-chalk@^4.0.0, chalk@^4.1.0, chalk@^4.1.2:
+chalk@^4.0.0, chalk@^4.1.2:
   version "4.1.2"
   resolved "https://registry.npmjs.org/chalk/-/chalk-4.1.2.tgz"
   integrity sha512-oKnbhFyRIXpUuez8iBMmyEa4nbj4IOQyuhc/wy9kY7/WVPcwIO9VA668Pu8RkO7+0G76SLROeyw9CpQ061i4mA==
@@ -3171,7 +3505,7 @@ cheerio@1.0.0-rc.12:
     parse5 "^7.0.0"
     parse5-htmlparser2-tree-adapter "^7.0.0"
 
-chokidar@^3.4.2, chokidar@^3.5.3:
+chokidar@^3.5.3, chokidar@^3.6.0:
   version "3.6.0"
   resolved "https://registry.npmjs.org/chokidar/-/chokidar-3.6.0.tgz"
   integrity sha512-7VT13fmjotKpGipCW9JEQAusEPE+Ei8nl6/g4FBAmIm0GOOLMua9NDDo/DWp0ZAxCr3cPq5ZpBqmPAQgDda2Pw==
@@ -3196,7 +3530,7 @@ ci-info@^3.2.0:
   resolved "https://registry.npmjs.org/ci-info/-/ci-info-3.9.0.tgz"
   integrity sha512-NIxF55hv4nSqQswkAeiOi1r83xy8JldOFDTWiug55KBu9Jnblncd2U6ViHmYgHf01TPZS77NJBhBMKdWj9HQMQ==
 
-clean-css@^5.2.2, clean-css@^5.3.2, clean-css@~5.3.2:
+clean-css@^5.2.2, clean-css@^5.3.3, clean-css@~5.3.2:
   version "5.3.3"
   resolved "https://registry.npmjs.org/clean-css/-/clean-css-5.3.3.tgz"
   integrity sha512-D5J+kHaVb/wKSFcyyV75uCn8fiY4sV38XJoe4CUyGQ+mOU/fMVYUdH1hJC+CJQ5uY3EnW27SbJYS4X8BiLrAFg==
@@ -3315,16 +3649,16 @@ compressible@~2.0.18:
   dependencies:
     mime-db ">= 1.43.0 < 2"
 
-compression@^1.7.4:
-  version "1.7.5"
-  resolved "https://registry.npmjs.org/compression/-/compression-1.7.5.tgz"
-  integrity sha512-bQJ0YRck5ak3LgtnpKkiabX5pNF7tMUh1BSy2ZBOTh0Dim0BUu6aPPwByIns6/A5Prh8PufSPerMDUklpzes2Q==
+compression@^1.8.1:
+  version "1.8.1"
+  resolved "https://registry.npmjs.org/compression/-/compression-1.8.1.tgz"
+  integrity sha512-9mAqGPHLakhCLeNyxPkK4xVo746zQ/czLH1Ky+vkitMnWfWZps8r0qXuwhwizagCRttsL4lfG4pIOvaWLpAP0w==
   dependencies:
     bytes "3.1.2"
     compressible "~2.0.18"
     debug "2.6.9"
     negotiator "~0.6.4"
-    on-headers "~1.0.2"
+    on-headers "~1.1.0"
     safe-buffer "5.2.1"
     vary "~1.1.2"
 
@@ -3358,22 +3692,22 @@ connect-history-api-fallback@^2.0.0:
   integrity sha512-U73+6lQFmfiNPrYbXqr6kZ1i1wiRqXnp2nhMsINseWXO8lDau0LGEffJ8kQi4EjLZympVgRdvqjAgiZ1tgzDDA==
 
 consola@^3.2.3:
-  version "3.4.0"
-  resolved "https://registry.npmjs.org/consola/-/consola-3.4.0.tgz"
-  integrity sha512-EiPU8G6dQG0GFHNR8ljnZFki/8a+cQwEQ+7wpxdChl02Q8HXlwEZWD5lqAF8vC2sEC3Tehr8hy7vErz88LHyUA==
+  version "3.4.2"
+  resolved "https://registry.npmjs.org/consola/-/consola-3.4.2.tgz"
+  integrity sha512-5IKcdX0nnYavi6G7TtOhwkYzyjfJlatbjMjuLSfE2kYT5pMDOilZ4OvMhi637CcDICTmz3wARPoyhqyX1Y+XvA==
 
-content-disposition@0.5.2:
-  version "0.5.2"
-  resolved "https://registry.npmjs.org/content-disposition/-/content-disposition-0.5.2.tgz"
-  integrity sha512-kRGRZw3bLlFISDBgwTSA1TMBFN6J6GWDeubmDE3AF+3+yXL8hTWv8r5rkLbqYXY4RjPk/EzHnClI3zQf1cFmHA==
-
-content-disposition@0.5.4:
+content-disposition@~0.5.4:
   version "0.5.4"
   resolved "https://registry.npmjs.org/content-disposition/-/content-disposition-0.5.4.tgz"
   integrity sha512-FveZTNuGw04cxlAiWbzi6zTAL/lhehaWbTtgluJh4/E95DqMwTmha3KZN1aAWA8cFIhHzMZUvLevkw5Rqk+tSQ==
   dependencies:
     safe-buffer "5.2.1"
 
+content-disposition@0.5.2:
+  version "0.5.2"
+  resolved "https://registry.npmjs.org/content-disposition/-/content-disposition-0.5.2.tgz"
+  integrity sha512-kRGRZw3bLlFISDBgwTSA1TMBFN6J6GWDeubmDE3AF+3+yXL8hTWv8r5rkLbqYXY4RjPk/EzHnClI3zQf1cFmHA==
+
 content-type@~1.0.4, content-type@~1.0.5:
   version "1.0.5"
   resolved "https://registry.npmjs.org/content-type/-/content-type-1.0.5.tgz"
@@ -3384,20 +3718,15 @@ convert-source-map@^2.0.0:
   resolved "https://registry.npmjs.org/convert-source-map/-/convert-source-map-2.0.0.tgz"
   integrity sha512-Kvp459HrV2FEJ1CAsi1Ku+MY3kasH19TFykTz2xWmMeq6bk2NU3XXvfJ+Q61m0xktWwt+1HSYf3JZsTms3aRJg==
 
-cookie-signature@1.0.6:
-  version "1.0.6"
-  resolved "https://registry.npmjs.org/cookie-signature/-/cookie-signature-1.0.6.tgz"
-  integrity sha512-QADzlaHc8icV8I7vbaJXJwod9HWYp8uCqf1xa4OfNu1T7JVxQIrUgOWtHdNDtPiywmFbiS12VjotIXLrKM3orQ==
-
-cookie@0.7.1:
-  version "0.7.1"
-  resolved "https://registry.npmjs.org/cookie/-/cookie-0.7.1.tgz"
-  integrity sha512-6DnInpx7SJ2AK3+CTUE/ZM0vWTUboZCegxhC2xiIydHR9jNuTAASBrfEpHhiGOZw/nX51bHt6YQl8jsGo4y/0w==
+cookie-signature@~1.0.6:
+  version "1.0.7"
+  resolved "https://registry.npmjs.org/cookie-signature/-/cookie-signature-1.0.7.tgz"
+  integrity sha512-NXdYc3dLr47pBkpUCHtKSwIOQXLVn8dZEuywboCOJY/osA0wFSLlSawr3KN8qXJEyX66FcONTH8EIlVuK0yyFA==
 
-copy-text-to-clipboard@^3.2.0:
-  version "3.2.0"
-  resolved "https://registry.npmjs.org/copy-text-to-clipboard/-/copy-text-to-clipboard-3.2.0.tgz"
-  integrity sha512-RnJFp1XR/LOBDckxTib5Qjr/PMfkatD0MUCQgdpqS8MdKiNUzBjAQBEN6oUy+jW7LI93BBG3DtMB2KOOKpGs2Q==
+cookie@~0.7.1:
+  version "0.7.2"
+  resolved "https://registry.npmjs.org/cookie/-/cookie-0.7.2.tgz"
+  integrity sha512-yki5XnKuf750l50uGTllt6kKILY4nQ1eNIQatoXEByZ5dWgnKqbnqmTrBE5B4N7lrMJKQ2ytWMiTO2o0v6Ew/w==
 
 copy-webpack-plugin@^11.0.0:
   version "11.0.0"
@@ -3411,17 +3740,17 @@ copy-webpack-plugin@^11.0.0:
     schema-utils "^4.0.0"
     serialize-javascript "^6.0.0"
 
-core-js-compat@^3.38.0, core-js-compat@^3.38.1:
-  version "3.40.0"
-  resolved "https://registry.npmjs.org/core-js-compat/-/core-js-compat-3.40.0.tgz"
-  integrity sha512-0XEDpr5y5mijvw8Lbc6E5AkjrHfp7eEoPlu36SWeAbcL8fn1G1ANe8DBlo2XoNN89oVpxWwOjYIPVzR4ZvsKCQ==
+core-js-compat@^3.43.0:
+  version "3.47.0"
+  resolved "https://registry.npmjs.org/core-js-compat/-/core-js-compat-3.47.0.tgz"
+  integrity sha512-IGfuznZ/n7Kp9+nypamBhvwdwLsW6KC8IOaURw2doAK5e98AG3acVLdh0woOnEqCfUtS+Vu882JE4k/DAm3ItQ==
   dependencies:
-    browserslist "^4.24.3"
+    browserslist "^4.28.0"
 
-core-js-pure@^3.30.2:
-  version "3.40.0"
-  resolved "https://registry.npmjs.org/core-js-pure/-/core-js-pure-3.40.0.tgz"
-  integrity sha512-AtDzVIgRrmRKQai62yuSIN5vNiQjcJakJb4fbhVw3ehxx7Lohphvw9SGNWKhLFqSxC4ilD0g/L1huAYFQU3Q6A==
+core-js-pure@^3.43.0:
+  version "3.47.0"
+  resolved "https://registry.npmjs.org/core-js-pure/-/core-js-pure-3.47.0.tgz"
+  integrity sha512-BcxeDbzUrRnXGYIVAGFtcGQVNpFcUhVjr6W7F8XktvQW2iJP9e66GP6xdKotCRFlrxBvNIBrhwKteRXqMV86Nw==
 
 core-js@^3.31.1:
   version "3.40.0"
@@ -3433,17 +3762,6 @@ core-util-is@~1.0.0:
   resolved "https://registry.npmjs.org/core-util-is/-/core-util-is-1.0.3.tgz"
   integrity sha512-ZQBvi1DcpJ4GDqanjucZ2Hj3wEO5pZDS89BWbkcrvdxksJorwUDDZamX9ldFkp9aw2lmBDLgkObEA4DWNJ9FYQ==
 
-cosmiconfig@^6.0.0:
-  version "6.0.0"
-  resolved "https://registry.npmjs.org/cosmiconfig/-/cosmiconfig-6.0.0.tgz"
-  integrity sha512-xb3ZL6+L8b9JLLCx3ZdoZy4+2ECphCMo2PwqgP1tlfVq6M6YReyzBJtvWWtbDSpNr9hn96pkCiZqUcFEc+54Qg==
-  dependencies:
-    "@types/parse-json" "^4.0.0"
-    import-fresh "^3.1.0"
-    parse-json "^5.0.0"
-    path-type "^4.0.0"
-    yaml "^1.7.2"
-
 cosmiconfig@^8.1.3, cosmiconfig@^8.3.5:
   version "8.3.6"
   resolved "https://registry.npmjs.org/cosmiconfig/-/cosmiconfig-8.3.6.tgz"
@@ -3478,20 +3796,20 @@ css-blank-pseudo@^7.0.1:
     postcss-selector-parser "^7.0.0"
 
 css-declaration-sorter@^7.2.0:
-  version "7.2.0"
-  resolved "https://registry.npmjs.org/css-declaration-sorter/-/css-declaration-sorter-7.2.0.tgz"
-  integrity sha512-h70rUM+3PNFuaBDTLe8wF/cdWu+dOZmb7pJt8Z2sedYbAcQVQV/tEchueg3GWxwqS0cxtbxmaHEdkNACqcvsow==
+  version "7.3.1"
+  resolved "https://registry.npmjs.org/css-declaration-sorter/-/css-declaration-sorter-7.3.1.tgz"
+  integrity sha512-gz6x+KkgNCjxq3Var03pRYLhyNfwhkKF1g/yoLgDNtFvVu0/fOLV9C8fFEZRjACp/XQLumjAYo7JVjzH3wLbxA==
 
-css-has-pseudo@^7.0.2:
-  version "7.0.2"
-  resolved "https://registry.npmjs.org/css-has-pseudo/-/css-has-pseudo-7.0.2.tgz"
-  integrity sha512-nzol/h+E0bId46Kn2dQH5VElaknX2Sr0hFuB/1EomdC7j+OISt2ZzK7EHX9DZDY53WbIVAR7FYKSO2XnSf07MQ==
+css-has-pseudo@^7.0.3:
+  version "7.0.3"
+  resolved "https://registry.npmjs.org/css-has-pseudo/-/css-has-pseudo-7.0.3.tgz"
+  integrity sha512-oG+vKuGyqe/xvEMoxAQrhi7uY16deJR3i7wwhBerVrGQKSqUC5GiOVxTpM9F9B9hw0J+eKeOWLH7E9gZ1Dr5rA==
   dependencies:
     "@csstools/selector-specificity" "^5.0.0"
     postcss-selector-parser "^7.0.0"
     postcss-value-parser "^4.2.0"
 
-css-loader@^6.8.1:
+css-loader@^6.11.0:
   version "6.11.0"
   resolved "https://registry.npmjs.org/css-loader/-/css-loader-6.11.0.tgz"
   integrity sha512-CTJ+AEQJjq5NzLga5pE39qdiSV56F8ywCIsqNIRF0r7BDgWsN25aazToqAFg7ZrtA/U016xudB3ffgweORxX7g==
@@ -3534,9 +3852,9 @@ css-select@^4.1.3:
     nth-check "^2.0.1"
 
 css-select@^5.1.0:
-  version "5.1.0"
-  resolved "https://registry.npmjs.org/css-select/-/css-select-5.1.0.tgz"
-  integrity sha512-nwoRF1rvRRnnCqqY7updORDsuqKzqYJ28+oSMaJMMgOauh3fvwHqMS7EZpIPqK8GL+g9mKxF1vP/ZjSeNjEVHg==
+  version "5.2.2"
+  resolved "https://registry.npmjs.org/css-select/-/css-select-5.2.2.tgz"
+  integrity sha512-TizTzUddG/xYLA3NXodFM0fSbNizXjOKhqiQQwvhlspadZokn1KDy0NZFS0wuEubIYAV5/c1/lAr0TaaFXEXzw==
   dependencies:
     boolbase "^1.0.0"
     css-what "^6.1.0"
@@ -3565,10 +3883,10 @@ css-what@^6.0.1, css-what@^6.1.0:
   resolved "https://registry.npmjs.org/css-what/-/css-what-6.1.0.tgz"
   integrity sha512-HTUrgRJ7r4dsZKU6GjmpfRK1O76h97Z8MfS1G0FozR+oF2kG6Vfe8JE6zwrkbxigziPHinCJ+gCPjA9EaBDtRw==
 
-cssdb@^8.2.3:
-  version "8.2.3"
-  resolved "https://registry.npmjs.org/cssdb/-/cssdb-8.2.3.tgz"
-  integrity sha512-9BDG5XmJrJQQnJ51VFxXCAtpZ5ebDlAREmO8sxMOVU0aSxN/gocbctjIG5LMh3WBUq+xTlb/jw2LoljBEqraTA==
+cssdb@^8.6.0:
+  version "8.7.0"
+  resolved "https://registry.npmjs.org/cssdb/-/cssdb-8.7.0.tgz"
+  integrity sha512-UxiWVpV953ENHqAKjKRPZHNDfRo3uOymvO5Ef7MFCWlenaohkYj7PTO7WCBdjZm8z/aDZd6rXyUIlwZ0AjyFSg==
 
 cssesc@^3.0.0:
   version "3.0.0"
@@ -3654,48 +3972,20 @@ debounce@^1.2.1:
   resolved "https://registry.npmjs.org/debounce/-/debounce-1.2.1.tgz"
   integrity sha512-XRRe6Glud4rd/ZGQfiV1ruXSfbvfJedlV9Y6zOlP+2K04vBYiJEte6stfFkCP03aMnY5tsipamumUjL14fofug==
 
-debug@^2.6.0, debug@2.6.9:
+debug@^4.0.0, debug@^4.1.0, debug@^4.3.1, debug@^4.4.1, debug@4:
+  version "4.4.3"
+  resolved "https://registry.npmjs.org/debug/-/debug-4.4.3.tgz"
+  integrity sha512-RGwwWnwQvkVfavKVt22FGLw+xYSdzARwm0ru6DhTVA3umU5hZc28V3kO4stgYryrTlLpuvgI9GiijltAjNbcqA==
+  dependencies:
+    ms "^2.1.3"
+
+debug@2.6.9:
   version "2.6.9"
   resolved "https://registry.npmjs.org/debug/-/debug-2.6.9.tgz"
   integrity sha512-bC7ElrdJaJnPbAP+1EotYvqZsb3ecl5wi6Bfi6BJTUcNowp6cvspg0jXznRTKDjm/E7AdgFBVeAPVMNcKGsHMA==
   dependencies:
     ms "2.0.0"
 
-debug@^4.0.0:
-  version "4.4.0"
-  resolved "https://registry.npmjs.org/debug/-/debug-4.4.0.tgz"
-  integrity sha512-6WTZ/IxCY/T6BALoZHaE4ctp9xm+Z5kY/pzYaCHRFeyVhojxlrm+46y68HA6hr0TcwEssoxNiDEUJQjfPZ/RYA==
-  dependencies:
-    ms "^2.1.3"
-
-debug@^4.1.0:
-  version "4.4.0"
-  resolved "https://registry.npmjs.org/debug/-/debug-4.4.0.tgz"
-  integrity sha512-6WTZ/IxCY/T6BALoZHaE4ctp9xm+Z5kY/pzYaCHRFeyVhojxlrm+46y68HA6hr0TcwEssoxNiDEUJQjfPZ/RYA==
-  dependencies:
-    ms "^2.1.3"
-
-debug@^4.1.1:
-  version "4.4.0"
-  resolved "https://registry.npmjs.org/debug/-/debug-4.4.0.tgz"
-  integrity sha512-6WTZ/IxCY/T6BALoZHaE4ctp9xm+Z5kY/pzYaCHRFeyVhojxlrm+46y68HA6hr0TcwEssoxNiDEUJQjfPZ/RYA==
-  dependencies:
-    ms "^2.1.3"
-
-debug@^4.3.1:
-  version "4.4.0"
-  resolved "https://registry.npmjs.org/debug/-/debug-4.4.0.tgz"
-  integrity sha512-6WTZ/IxCY/T6BALoZHaE4ctp9xm+Z5kY/pzYaCHRFeyVhojxlrm+46y68HA6hr0TcwEssoxNiDEUJQjfPZ/RYA==
-  dependencies:
-    ms "^2.1.3"
-
-debug@4:
-  version "4.4.0"
-  resolved "https://registry.npmjs.org/debug/-/debug-4.4.0.tgz"
-  integrity sha512-6WTZ/IxCY/T6BALoZHaE4ctp9xm+Z5kY/pzYaCHRFeyVhojxlrm+46y68HA6hr0TcwEssoxNiDEUJQjfPZ/RYA==
-  dependencies:
-    ms "^2.1.3"
-
 decode-named-character-reference@^1.0.0:
   version "1.0.2"
   resolved "https://registry.npmjs.org/decode-named-character-reference/-/decode-named-character-reference-1.0.2.tgz"
@@ -3715,17 +4005,23 @@ deep-extend@^0.6.0:
   resolved "https://registry.npmjs.org/deep-extend/-/deep-extend-0.6.0.tgz"
   integrity sha512-LOHxIOaPYdHlJRtCQfDIVZtfw/ufM8+rVj649RIHzcm/vGwQRXFt6OPqIFWsm2XEMrNIEtWR64sY1LEKD2vAOA==
 
-deepmerge@^4.2.2, deepmerge@^4.3.1:
+deepmerge@^4.3.1:
   version "4.3.1"
   resolved "https://registry.npmjs.org/deepmerge/-/deepmerge-4.3.1.tgz"
   integrity sha512-3sUqbMEc77XqpdNO7FRyRog+eW3ph+GYCbj+rK+uYyRMuwsVy0rMiVtPn+QJlKFvWP/1PYpapqYn0Me2knFn+A==
 
-default-gateway@^6.0.3:
-  version "6.0.3"
-  resolved "https://registry.npmjs.org/default-gateway/-/default-gateway-6.0.3.tgz"
-  integrity sha512-fwSOJsbbNzZ/CUFpqFBqYfYNLj1NbMPm8MMCIzHjC83iSJRBEGmDUxU+WP661BaBQImeC2yHwXtz+P/O9o+XEg==
+default-browser-id@^5.0.0:
+  version "5.0.1"
+  resolved "https://registry.npmjs.org/default-browser-id/-/default-browser-id-5.0.1.tgz"
+  integrity sha512-x1VCxdX4t+8wVfd1so/9w+vQ4vx7lKd2Qp5tDRutErwmR85OgmfX7RlLRMWafRMY7hbEiXIbudNrjOAPa/hL8Q==
+
+default-browser@^5.2.1:
+  version "5.4.0"
+  resolved "https://registry.npmjs.org/default-browser/-/default-browser-5.4.0.tgz"
+  integrity sha512-XDuvSq38Hr1MdN47EDvYtx3U0MTqpCEn+F6ft8z2vYDzMrvQhVp0ui9oQdqW3MvK3vqUETglt1tVGgjLuJ5izg==
   dependencies:
-    execa "^5.0.0"
+    bundle-name "^4.1.0"
+    default-browser-id "^5.0.0"
 
 defer-to-connect@^2.0.1:
   version "2.0.1"
@@ -3746,6 +4042,11 @@ define-lazy-prop@^2.0.0:
   resolved "https://registry.npmjs.org/define-lazy-prop/-/define-lazy-prop-2.0.0.tgz"
   integrity sha512-Ds09qNh8yw3khSjiJjiUInaGX9xlqZDY7JVryGxdxV7NPeuqQfplOpQ66yJFZut3jLa5zOwkXw1g9EI2uKh4Og==
 
+define-lazy-prop@^3.0.0:
+  version "3.0.0"
+  resolved "https://registry.npmjs.org/define-lazy-prop/-/define-lazy-prop-3.0.0.tgz"
+  integrity sha512-N+MeXYoqr3pOgn8xfyRPREN7gHakLYjhsHhWGT3fWAiL4IkAt0iDw14QiiEm2bE30c5XX5q0FtAA3CK5f9/BUg==
+
 define-properties@^1.2.1:
   version "1.2.1"
   resolved "https://registry.npmjs.org/define-properties/-/define-properties-1.2.1.tgz"
@@ -3755,36 +4056,22 @@ define-properties@^1.2.1:
     has-property-descriptors "^1.0.0"
     object-keys "^1.1.1"
 
-del@^6.1.1:
-  version "6.1.1"
-  resolved "https://registry.npmjs.org/del/-/del-6.1.1.tgz"
-  integrity sha512-ua8BhapfP0JUJKC/zV9yHHDW/rDoDxP4Zhn3AkA6/xT6gY7jYXJiaeyBZznYVujhZZET+UgcbZiQ7sN3WqcImg==
-  dependencies:
-    globby "^11.0.1"
-    graceful-fs "^4.2.4"
-    is-glob "^4.0.1"
-    is-path-cwd "^2.2.0"
-    is-path-inside "^3.0.2"
-    p-map "^4.0.0"
-    rimraf "^3.0.2"
-    slash "^3.0.0"
-
 depd@~1.1.2:
   version "1.1.2"
   resolved "https://registry.npmjs.org/depd/-/depd-1.1.2.tgz"
   integrity sha512-7emPTl6Dpo6JRXOXjLRxck+FlLRX5847cLKEn00PLAgc3g2hTZZgr+e4c2v6QpSmLeFP3n5yUo7ft6avBK/5jQ==
 
-depd@2.0.0:
+depd@~2.0.0, depd@2.0.0:
   version "2.0.0"
   resolved "https://registry.npmjs.org/depd/-/depd-2.0.0.tgz"
   integrity sha512-g7nH6P6dyDioJogAAGprGpCtVImJhpPk/roCzdb3fIh61/s/nPsfR6onyMwkCAR/OlC3yBC0lESvUoQEAssIrw==
 
-dequal@^2.0.0:
+dequal@^2.0.0, dequal@^2.0.3:
   version "2.0.3"
   resolved "https://registry.npmjs.org/dequal/-/dequal-2.0.3.tgz"
   integrity sha512-0je+qPKHEMohvfRTCEo3CrPG6cAzAYgmzKyxRiYSSDkS6eGJdyVJm7WaYA5ECaAD9wLB2T4EEeymA5aFVcYXCA==
 
-destroy@1.2.0:
+destroy@~1.2.0, destroy@1.2.0:
   version "1.2.0"
   resolved "https://registry.npmjs.org/destroy/-/destroy-1.2.0.tgz"
   integrity sha512-2sJGJTaXIIaR1w4iJSNoN0hnMY7Gpc/n8D4qSCJw8QqFWXf7cuAgnEHxBpweaVcPevC2l3KpjYCx3NypQQgaJg==
@@ -3794,14 +4081,6 @@ detect-node@^2.0.4:
   resolved "https://registry.npmjs.org/detect-node/-/detect-node-2.1.0.tgz"
   integrity sha512-T0NIuQpnTvFDATNuHN5roPwSBG83rFsuO+MXXH9/3N1eFbn4wcPjttvjMLEPWJ0RGUYgQE7cGgS3tNxbqCGM7g==
 
-detect-port-alt@^1.1.6:
-  version "1.1.6"
-  resolved "https://registry.npmjs.org/detect-port-alt/-/detect-port-alt-1.1.6.tgz"
-  integrity sha512-5tQykt+LqfJFBEYaDITx7S7cR7mJ/zQmLXZ2qt5w04ainYZw6tBf9dBunMjVeVOdYVRUzUOE4HkY5J7+uttb5Q==
-  dependencies:
-    address "^1.0.1"
-    debug "^2.6.0"
-
 detect-port@^1.5.1:
   version "1.6.1"
   resolved "https://registry.npmjs.org/detect-port/-/detect-port-1.6.1.tgz"
@@ -3932,10 +4211,10 @@ ee-first@1.1.1:
   resolved "https://registry.npmjs.org/ee-first/-/ee-first-1.1.1.tgz"
   integrity sha512-WMwm9LhRUo+WUaRN+vRuETqG89IgZphVSNkdFgeb6sS/E4OrDIN7t48CAewSHXc6C8lefD8KKfr5vY61brQlow==
 
-electron-to-chromium@^1.5.73:
-  version "1.5.83"
-  resolved "https://registry.npmjs.org/electron-to-chromium/-/electron-to-chromium-1.5.83.tgz"
-  integrity sha512-LcUDPqSt+V0QmI47XLzZrz5OqILSMGsPFkDYus22rIbgorSvBYEFqq854ltTmUdHkY92FSdAAvsh4jWEULMdfQ==
+electron-to-chromium@^1.5.263:
+  version "1.5.267"
+  resolved "https://registry.npmjs.org/electron-to-chromium/-/electron-to-chromium-1.5.267.tgz"
+  integrity sha512-0Drusm6MVRXSOJpGbaSVgcQsuB4hEkMpHXaVstcPmhu5LIedxs1xNK/nIxmQIU/RPC0+1/o0AVZfBTkTNJOdUw==
 
 emoji-regex@^8.0.0:
   version "8.0.0"
@@ -3962,11 +4241,6 @@ emoticon@^4.0.1:
   resolved "https://registry.npmjs.org/emoticon/-/emoticon-4.1.0.tgz"
   integrity sha512-VWZfnxqwNcc51hIy/sbOdEem6D+cVtpPzEEtVAFdaas30+1dgkyaOQ4sQ6Bp0tOMqWO1v+HQfYaoodOkdhK6SQ==
 
-encodeurl@~1.0.2:
-  version "1.0.2"
-  resolved "https://registry.npmjs.org/encodeurl/-/encodeurl-1.0.2.tgz"
-  integrity sha512-TPJXq8JqFaVYm2CWmPvnP2Iyo4ZSM7/QKcSmuMLDObfpH5fi7RUGmd/rTDf+rut/saiDiQEeVTNgAmJEdAOx0w==
-
 encodeurl@~2.0.0:
   version "2.0.0"
   resolved "https://registry.npmjs.org/encodeurl/-/encodeurl-2.0.0.tgz"
@@ -3985,15 +4259,20 @@ entities@^2.0.0:
   resolved "https://registry.npmjs.org/entities/-/entities-2.2.0.tgz"
   integrity sha512-p92if5Nz619I0w+akJrLZH0MX0Pb5DX39XOwQTtXSdQQOaYH03S1uIQp4mhOZtAXrxq4ViO67YTiLBo2638o9A==
 
-entities@^4.2.0, entities@^4.4.0, entities@^4.5.0:
+entities@^4.2.0, entities@^4.4.0:
   version "4.5.0"
   resolved "https://registry.npmjs.org/entities/-/entities-4.5.0.tgz"
   integrity sha512-V0hjH4dGPh9Ao5p0MoRY6BVqtwCjhz6vI5LT8AJ55H+4g9/4vbHx1I54fS0XuclLhDHArPQCiMjDxjaL8fPxhw==
 
+entities@^6.0.0:
+  version "6.0.1"
+  resolved "https://registry.npmjs.org/entities/-/entities-6.0.1.tgz"
+  integrity sha512-aN97NXWF6AWBTahfVOIrB/NShkzi5H7F9r1s9mD3cDj4Ko5f2qhhVoYMibXF7GlLveb/D2ioWay8lxI97Ven3g==
+
 error-ex@^1.3.1:
-  version "1.3.2"
-  resolved "https://registry.npmjs.org/error-ex/-/error-ex-1.3.2.tgz"
-  integrity sha512-7dFHNmqeFSEt2ZBsCriorKnn3Z2pj+fd9kmI6QoWw4//DL+icEBfc0U7qJCisqrTsKTjw4fNFy2pW9OqStD84g==
+  version "1.3.4"
+  resolved "https://registry.npmjs.org/error-ex/-/error-ex-1.3.4.tgz"
+  integrity sha512-sqQamAnR14VgCr1A618A3sGrygcpK+HEbenA/HiEAkkUwcZIIB/tgWqHFxWgOyDh4nB4JCRimh79dR5Ywc9MDQ==
   dependencies:
     is-arrayish "^0.2.1"
 
@@ -4012,7 +4291,7 @@ es-module-lexer@^1.2.1:
   resolved "https://registry.npmjs.org/es-module-lexer/-/es-module-lexer-1.6.0.tgz"
   integrity sha512-qqnD1yMU6tk/jnaMosogGySTZP8YtUgAffA9nMN+E/rjxcfRQ6IEk7IiozUjgxKoFHBGjTLnrHB/YC45r/59EQ==
 
-es-object-atoms@^1.0.0:
+es-object-atoms@^1.0.0, es-object-atoms@^1.1.1:
   version "1.1.1"
   resolved "https://registry.npmjs.org/es-object-atoms/-/es-object-atoms-1.1.1.tgz"
   integrity sha512-FGgH2h8zKNim9ljj7dankFPcICIK9Cp5bm+c2gQSYePhpaG5+esrLODihIorn+Pe6FGJzWhXQotPv73jTaldXA==
@@ -4139,9 +4418,9 @@ estree-util-to-js@^2.0.0:
     source-map "^0.7.0"
 
 estree-util-value-to-estree@^3.0.1:
-  version "3.2.1"
-  resolved "https://registry.npmjs.org/estree-util-value-to-estree/-/estree-util-value-to-estree-3.2.1.tgz"
-  integrity sha512-Vt2UOjyPbNQQgT5eJh+K5aATti0OjCIAGc9SgMdOFYbohuifsWclR74l0iZTJwePMgWYdX1hlVS+dedH9XV8kw==
+  version "3.5.0"
+  resolved "https://registry.npmjs.org/estree-util-value-to-estree/-/estree-util-value-to-estree-3.5.0.tgz"
+  integrity sha512-aMV56R27Gv3QmfmF1MY12GWkGzzeAezAX+UplqHVASfjc9wNzI/X6hC0S9oxq61WT4aQesLGslWP9tKk6ghRZQ==
   dependencies:
     "@types/estree" "^1.0.0"
 
@@ -4183,7 +4462,7 @@ eval@^0.1.8:
     "@types/node" "*"
     require-like ">= 0.1.1"
 
-eventemitter3@^4.0.0:
+eventemitter3@^4.0.0, eventemitter3@^4.0.4:
   version "4.0.7"
   resolved "https://registry.npmjs.org/eventemitter3/-/eventemitter3-4.0.7.tgz"
   integrity sha512-8guHBZCwKnFhYdHr2ysuRWErTwhoN2X8XELRlrRwpmfeY2jjuUN4taQMsULKUVo1K4DvZl+0pgfyoysHxvmvEw==
@@ -4193,7 +4472,12 @@ events@^3.2.0:
   resolved "https://registry.npmjs.org/events/-/events-3.3.0.tgz"
   integrity sha512-mQw+2fkQbALzQ7V0MY0IqdnXNOeTtP4r0lN9z7AAawCXgqea7bDii20AYrIBrFd/Hx0M2Ocz6S111CaFkUcb0Q==
 
-execa@^5.0.0:
+eventsource-parser@^3.0.6:
+  version "3.0.6"
+  resolved "https://registry.npmjs.org/eventsource-parser/-/eventsource-parser-3.0.6.tgz"
+  integrity sha512-Vo1ab+QXPzZ4tCa8SwIHJFaSzy4R6SHf7BY79rFBDf0idraZWAkYrDjDj8uWaSm3S2TK+hJ7/t1CEmZ7jXw+pg==
+
+execa@5.1.1:
   version "5.1.1"
   resolved "https://registry.npmjs.org/execa/-/execa-5.1.1.tgz"
   integrity sha512-8uSpZZocAZRBAPIEINJj3Lo9HyGitllczc27Eh5YYojjMFMn8yHMDMaUHE2Jqfq05D/wucwI4JGURyXt1vchyg==
@@ -4208,39 +4492,39 @@ execa@^5.0.0:
     signal-exit "^3.0.3"
     strip-final-newline "^2.0.0"
 
-express@^4.17.3:
-  version "4.21.2"
-  resolved "https://registry.npmjs.org/express/-/express-4.21.2.tgz"
-  integrity sha512-28HqgMZAmih1Czt9ny7qr6ek2qddF4FclbMzwhCREB6OFfH+rXAnuNCwo1/wFvrtbgsQDb4kSbX9de9lFbrXnA==
+express@^4.22.1:
+  version "4.22.1"
+  resolved "https://registry.npmjs.org/express/-/express-4.22.1.tgz"
+  integrity sha512-F2X8g9P1X7uCPZMA3MVf9wcTqlyNp7IhH5qPCI0izhaOIYXaW9L535tGA3qmjRzpH+bZczqq7hVKxTR4NWnu+g==
   dependencies:
     accepts "~1.3.8"
     array-flatten "1.1.1"
-    body-parser "1.20.3"
-    content-disposition "0.5.4"
+    body-parser "~1.20.3"
+    content-disposition "~0.5.4"
     content-type "~1.0.4"
-    cookie "0.7.1"
-    cookie-signature "1.0.6"
+    cookie "~0.7.1"
+    cookie-signature "~1.0.6"
     debug "2.6.9"
     depd "2.0.0"
     encodeurl "~2.0.0"
     escape-html "~1.0.3"
     etag "~1.8.1"
-    finalhandler "1.3.1"
-    fresh "0.5.2"
-    http-errors "2.0.0"
+    finalhandler "~1.3.1"
+    fresh "~0.5.2"
+    http-errors "~2.0.0"
     merge-descriptors "1.0.3"
     methods "~1.1.2"
-    on-finished "2.4.1"
+    on-finished "~2.4.1"
     parseurl "~1.3.3"
-    path-to-regexp "0.1.12"
+    path-to-regexp "~0.1.12"
     proxy-addr "~2.0.7"
-    qs "6.13.0"
+    qs "~6.14.0"
     range-parser "~1.2.1"
     safe-buffer "5.2.1"
-    send "0.19.0"
-    serve-static "1.16.2"
+    send "~0.19.0"
+    serve-static "~1.16.2"
     setprototypeof "1.2.0"
-    statuses "2.0.1"
+    statuses "~2.0.1"
     type-is "~1.6.18"
     utils-merge "1.0.1"
     vary "~1.1.2"
@@ -4284,9 +4568,9 @@ fast-uri@^3.0.1:
   integrity sha512-5JnBCWpFlMo0a3ciDy/JckMzzv1U9coZrIhedq+HXxxUfDTAiS0LA8OKVao4G9BxmCVck/jtA5r3KAtRWEyD8Q==
 
 fastq@^1.6.0:
-  version "1.18.0"
-  resolved "https://registry.npmjs.org/fastq/-/fastq-1.18.0.tgz"
-  integrity sha512-QKHXPW0hD8g4UET03SdOdunzSouc9N4AuHdsX8XNcTsuz+yYFILVNIX4l9yHABMhiEI9Db0JTTIpu0wB+Y1QQw==
+  version "1.20.1"
+  resolved "https://registry.npmjs.org/fastq/-/fastq-1.20.1.tgz"
+  integrity sha512-GGToxJ/w1x32s/D2EKND7kTil4n8OVk/9mycTc4VDza13lOvpUZTGX3mFSCtV9ksdGBVzvsyAVLM6mHFThxXxw==
   dependencies:
     reusify "^1.0.4"
 
@@ -4326,11 +4610,6 @@ file-loader@*, file-loader@^6.2.0:
     loader-utils "^2.0.0"
     schema-utils "^3.0.0"
 
-filesize@^8.0.6:
-  version "8.0.7"
-  resolved "https://registry.npmjs.org/filesize/-/filesize-8.0.7.tgz"
-  integrity sha512-pjmC+bkIF8XI7fWaH8KxHcZL3DPybs1roSKP4rKDvy20tAWwIObE4+JIseG2byfGKhud5ZnM4YSGKBz7Sh0ndQ==
-
 fill-range@^7.1.1:
   version "7.1.1"
   resolved "https://registry.npmjs.org/fill-range/-/fill-range-7.1.1.tgz"
@@ -4338,17 +4617,17 @@ fill-range@^7.1.1:
   dependencies:
     to-regex-range "^5.0.1"
 
-finalhandler@1.3.1:
-  version "1.3.1"
-  resolved "https://registry.npmjs.org/finalhandler/-/finalhandler-1.3.1.tgz"
-  integrity sha512-6BN9trH7bp3qvnrRyzsBz+g3lZxTNZTbVO2EV1CS0WIcDbawYVdYvGflME/9QP0h0pYlCDBCTjYa9nZzMDpyxQ==
+finalhandler@~1.3.1:
+  version "1.3.2"
+  resolved "https://registry.npmjs.org/finalhandler/-/finalhandler-1.3.2.tgz"
+  integrity sha512-aA4RyPcd3badbdABGDuTXCMTtOneUCAYH/gxoYRTZlIJdF0YPWuGqiAsIrhNnnqdXGswYk6dGujem4w80UJFhg==
   dependencies:
     debug "2.6.9"
     encodeurl "~2.0.0"
     escape-html "~1.0.3"
-    on-finished "2.4.1"
+    on-finished "~2.4.1"
     parseurl "~1.3.3"
-    statuses "2.0.1"
+    statuses "~2.0.2"
     unpipe "~1.0.0"
 
 find-cache-dir@^4.0.0:
@@ -4359,21 +4638,6 @@ find-cache-dir@^4.0.0:
     common-path-prefix "^3.0.0"
     pkg-dir "^7.0.0"
 
-find-up@^3.0.0:
-  version "3.0.0"
-  resolved "https://registry.npmjs.org/find-up/-/find-up-3.0.0.tgz"
-  integrity sha512-1yD6RmLI1XBfxugvORwlck6f75tYL+iR0jqwsOrOxMZyGYqUuDhJ0l4AXdO1iX/FTs9cBAMEk1gWSEx1kSbylg==
-  dependencies:
-    locate-path "^3.0.0"
-
-find-up@^5.0.0:
-  version "5.0.0"
-  resolved "https://registry.npmjs.org/find-up/-/find-up-5.0.0.tgz"
-  integrity sha512-78/PXT1wlLLDgTzDs7sjq9hzz0vXD+zn+7wypEe4fXQxCmdmqfGsEPQxmiCSQI3ajFV91bVSsvNtrJRiW6nGng==
-  dependencies:
-    locate-path "^6.0.0"
-    path-exists "^4.0.0"
-
 find-up@^6.3.0:
   version "6.3.0"
   resolved "https://registry.npmjs.org/find-up/-/find-up-6.3.0.tgz"
@@ -4388,28 +4652,9 @@ flat@^5.0.2:
   integrity sha512-b6suED+5/3rTpUBdG1gupIl8MPFCAMA0QXwmljLhvCUKcUvdE4gWky9zpuGCcXHOsz4J9wPGNWq6OKpmIzz3hQ==
 
 follow-redirects@^1.0.0:
-  version "1.15.9"
-  resolved "https://registry.npmjs.org/follow-redirects/-/follow-redirects-1.15.9.tgz"
-  integrity sha512-gew4GsXizNgdoRyqmyfMHyAmXsZDk6mHkSxZFCzW9gwlbtOW44CDtYavM+y+72qD/Vq2l550kMF52DT8fOLJqQ==
-
-fork-ts-checker-webpack-plugin@^6.5.0:
-  version "6.5.3"
-  resolved "https://registry.npmjs.org/fork-ts-checker-webpack-plugin/-/fork-ts-checker-webpack-plugin-6.5.3.tgz"
-  integrity sha512-SbH/l9ikmMWycd5puHJKTkZJKddF4iRLyW3DeZ08HTI7NGyLS38MXd/KGgeWumQO7YNQbW2u/NtPT2YowbPaGQ==
-  dependencies:
-    "@babel/code-frame" "^7.8.3"
-    "@types/json-schema" "^7.0.5"
-    chalk "^4.1.0"
-    chokidar "^3.4.2"
-    cosmiconfig "^6.0.0"
-    deepmerge "^4.2.2"
-    fs-extra "^9.0.0"
-    glob "^7.1.6"
-    memfs "^3.1.2"
-    minimatch "^3.0.4"
-    schema-utils "2.7.0"
-    semver "^7.3.2"
-    tapable "^1.0.0"
+  version "1.15.11"
+  resolved "https://registry.npmjs.org/follow-redirects/-/follow-redirects-1.15.11.tgz"
+  integrity sha512-deG2P0JfjrTxl50XGCDyfI97ZGVCxIpfKYmfyrQ54n5FO/0gfIES8C/Psl6kWVDolizcaaxZJnTS0QSMxvnsBQ==
 
 form-data-encoder@^2.1.2:
   version "2.1.4"
@@ -4426,45 +4671,25 @@ forwarded@0.2.0:
   resolved "https://registry.npmjs.org/forwarded/-/forwarded-0.2.0.tgz"
   integrity sha512-buRG0fpBtRHSTCOASe6hD258tEubFoRLb4ZNA6NxMVHNw2gOcwHo9wyablzMzOA5z9xA9L1KNjk/Nt6MT9aYow==
 
-fraction.js@^4.3.7:
-  version "4.3.7"
-  resolved "https://registry.npmjs.org/fraction.js/-/fraction.js-4.3.7.tgz"
-  integrity sha512-ZsDfxO51wGAXREY55a7la9LScWpwv9RxIrYABrlvOFBlH/ShPnrtsXeuUIfXKKOVicNxQ+o8JTbJvjS4M89yew==
+fraction.js@^5.3.4:
+  version "5.3.4"
+  resolved "https://registry.npmjs.org/fraction.js/-/fraction.js-5.3.4.tgz"
+  integrity sha512-1X1NTtiJphryn/uLQz3whtY6jK3fTqoE3ohKs0tT+Ujr1W59oopxmoEh7Lu5p6vBaPbgoM0bzveAW4Qi5RyWDQ==
 
-fresh@0.5.2:
+fresh@~0.5.2:
   version "0.5.2"
   resolved "https://registry.npmjs.org/fresh/-/fresh-0.5.2.tgz"
   integrity sha512-zJ2mQYM18rEFOudeV4GShTGIQ7RbzA7ozbU9I/XBpm7kqgMywgmylMwXHxZJmkVoYkna9d2pVXVXPdYTP9ej8Q==
 
 fs-extra@^11.1.1, fs-extra@^11.2.0:
-  version "11.3.0"
-  resolved "https://registry.npmjs.org/fs-extra/-/fs-extra-11.3.0.tgz"
-  integrity sha512-Z4XaCL6dUDHfP/jT25jJKMmtxvuwbkrD1vNSMFlo9lNLY2c5FHYSQgHPRZUjAB26TpDEoW9HCOgplrdbaPV/ew==
+  version "11.3.3"
+  resolved "https://registry.npmjs.org/fs-extra/-/fs-extra-11.3.3.tgz"
+  integrity sha512-VWSRii4t0AFm6ixFFmLLx1t7wS1gh+ckoa84aOeapGum0h+EZd1EhEumSB+ZdDLnEPuucsVB9oB7cxJHap6Afg==
   dependencies:
     graceful-fs "^4.2.0"
     jsonfile "^6.0.1"
     universalify "^2.0.0"
 
-fs-extra@^9.0.0:
-  version "9.1.0"
-  resolved "https://registry.npmjs.org/fs-extra/-/fs-extra-9.1.0.tgz"
-  integrity sha512-hcg3ZmepS30/7BSFqRvoo3DOMQu7IjqxO5nCDt+zM9XWjb33Wg7ziNT+Qvqbuc3+gWpzO02JubVyk2G4Zvo1OQ==
-  dependencies:
-    at-least-node "^1.0.0"
-    graceful-fs "^4.2.0"
-    jsonfile "^6.0.1"
-    universalify "^2.0.0"
-
-fs-monkey@^1.0.4:
-  version "1.0.6"
-  resolved "https://registry.npmjs.org/fs-monkey/-/fs-monkey-1.0.6.tgz"
-  integrity sha512-b1FMfwetIKymC0eioW7mTywihSQE4oLzQn1dB6rZB5fx/3NpNEdAWeCSMB+60/AeT0TCXsxzAlcYVEFCTAksWg==
-
-fs.realpath@^1.0.0:
-  version "1.0.0"
-  resolved "https://registry.npmjs.org/fs.realpath/-/fs.realpath-1.0.0.tgz"
-  integrity sha512-OO0pH2lK6a0hZnAdau5ItzHPI6pUlvI7jMVnxUQRtw4owF2wk8lOSabtGDCTP4Ggrg2MbGnWO9X8K1t4+fGMDw==
-
 fsevents@~2.3.2:
   version "2.3.3"
   resolved "https://registry.npmjs.org/fsevents/-/fsevents-2.3.3.tgz"
@@ -4480,17 +4705,17 @@ gensync@^1.0.0-beta.2:
   resolved "https://registry.npmjs.org/gensync/-/gensync-1.0.0-beta.2.tgz"
   integrity sha512-3hN7NaskYvMDLQY55gnW3NQ+mesEAepTqlg+VEbj7zzqEMBVNhzcGYYeqFo/TlYz6eQiFcp1HcsCZO+nGgS8zg==
 
-get-intrinsic@^1.2.4, get-intrinsic@^1.2.5, get-intrinsic@^1.2.6:
-  version "1.2.7"
-  resolved "https://registry.npmjs.org/get-intrinsic/-/get-intrinsic-1.2.7.tgz"
-  integrity sha512-VW6Pxhsrk0KAOqs3WEd0klDiF/+V7gQOpAvY1jVU/LHmaD/kQO4523aiJuikX/QAKYiW6x8Jh+RJej1almdtCA==
+get-intrinsic@^1.2.4, get-intrinsic@^1.2.5, get-intrinsic@^1.3.0:
+  version "1.3.0"
+  resolved "https://registry.npmjs.org/get-intrinsic/-/get-intrinsic-1.3.0.tgz"
+  integrity sha512-9fSjSaos/fRIVIp+xSJlE6lfwhES7LNtKaCBIamHsjr2na1BiABJPo0mOjjz8GJDURarmCPGqaiVg5mfjb98CQ==
   dependencies:
-    call-bind-apply-helpers "^1.0.1"
+    call-bind-apply-helpers "^1.0.2"
     es-define-property "^1.0.1"
     es-errors "^1.3.0"
-    es-object-atoms "^1.0.0"
+    es-object-atoms "^1.1.1"
     function-bind "^1.1.2"
-    get-proto "^1.0.0"
+    get-proto "^1.0.1"
     gopd "^1.2.0"
     has-symbols "^1.1.0"
     hasown "^2.0.2"
@@ -4501,7 +4726,7 @@ get-own-enumerable-property-symbols@^3.0.0:
   resolved "https://registry.npmjs.org/get-own-enumerable-property-symbols/-/get-own-enumerable-property-symbols-3.0.2.tgz"
   integrity sha512-I0UBV/XOz1XkIJHEUDMZAbzCThU/H8DxmSfmdGcKPnVhu2VfFqr34jr9777IyaTYvxjedWhqVIilEDsCdP5G6g==
 
-get-proto@^1.0.0:
+get-proto@^1.0.1:
   version "1.0.1"
   resolved "https://registry.npmjs.org/get-proto/-/get-proto-1.0.1.tgz"
   integrity sha512-sTSfBjoXBp89JvIKIefqw7U2CCebsc74kiY6awiGogKtoSGbgjYE/G/+l9sF3MWFPNc9IcoOC4ODfKHfxFmp0g==
@@ -4533,23 +4758,16 @@ glob-parent@^6.0.1:
   dependencies:
     is-glob "^4.0.3"
 
+glob-to-regex.js@^1.0.1:
+  version "1.2.0"
+  resolved "https://registry.npmjs.org/glob-to-regex.js/-/glob-to-regex.js-1.2.0.tgz"
+  integrity sha512-QMwlOQKU/IzqMUOAZWubUOT8Qft+Y0KQWnX9nK3ch0CJg0tTp4TvGZsTfudYKv2NzoQSyPcnA6TYeIQ3jGichQ==
+
 glob-to-regexp@^0.4.1:
   version "0.4.1"
   resolved "https://registry.npmjs.org/glob-to-regexp/-/glob-to-regexp-0.4.1.tgz"
   integrity sha512-lkX1HJXwyMcprw/5YUZc2s7DrpAiHB21/V+E1rHUrVNokkvB6bqMzT0VfV6/86ZNabt1k14YOIaT7nDvOX3Iiw==
 
-glob@^7.0.0, glob@^7.1.3, glob@^7.1.6:
-  version "7.2.3"
-  resolved "https://registry.npmjs.org/glob/-/glob-7.2.3.tgz"
-  integrity sha512-nFR0zLpU2YCaRxwoCJvL6UvCH2JFyFVIvwTLsIf21AuHlMskA1hhTdk+LlYJtOlYt9v6dvszD2BGRqBL+iQK9Q==
-  dependencies:
-    fs.realpath "^1.0.0"
-    inflight "^1.0.4"
-    inherits "2"
-    minimatch "^3.1.1"
-    once "^1.3.0"
-    path-is-absolute "^1.0.0"
-
 global-dirs@^3.0.0:
   version "3.0.1"
   resolved "https://registry.npmjs.org/global-dirs/-/global-dirs-3.0.1.tgz"
@@ -4557,28 +4775,7 @@ global-dirs@^3.0.0:
   dependencies:
     ini "2.0.0"
 
-global-modules@^2.0.0:
-  version "2.0.0"
-  resolved "https://registry.npmjs.org/global-modules/-/global-modules-2.0.0.tgz"
-  integrity sha512-NGbfmJBp9x8IxyJSd1P+otYK8vonoJactOogrVfFRIAEY1ukil8RSKDz2Yo7wh1oihl51l/r6W4epkeKJHqL8A==
-  dependencies:
-    global-prefix "^3.0.0"
-
-global-prefix@^3.0.0:
-  version "3.0.0"
-  resolved "https://registry.npmjs.org/global-prefix/-/global-prefix-3.0.0.tgz"
-  integrity sha512-awConJSVCHVGND6x3tmMaKcQvwXLhjdkmomy2W+Goaui8YPgYgXJZewhg3fWC+DlfqqQuWg8AwqjGTD2nAPVWg==
-  dependencies:
-    ini "^1.3.5"
-    kind-of "^6.0.2"
-    which "^1.3.1"
-
-globals@^11.1.0:
-  version "11.12.0"
-  resolved "https://registry.npmjs.org/globals/-/globals-11.12.0.tgz"
-  integrity sha512-WOBp/EEGUiIsJSp7wcv/y6MO+lV9UoncWqxuFfm8eBwzWNgyfBd6Gz+IeKQ9jCmyhoH99g15M3T+QaVHFjizVA==
-
-globby@^11.0.1, globby@^11.0.4, globby@^11.1.0:
+globby@^11.1.0:
   version "11.1.0"
   resolved "https://registry.npmjs.org/globby/-/globby-11.1.0.tgz"
   integrity sha512-jhIXaOzy1sb8IyocaruWSn1TjmnBVs8Ayhcy83rmxNJ8q2uWKCAj3CnJY+KpGSXCueAPc0i05kVvVKtP1t9S3g==
@@ -4685,15 +4882,15 @@ hasown@^2.0.2:
     function-bind "^1.1.2"
 
 hast-util-from-parse5@^8.0.0:
-  version "8.0.2"
-  resolved "https://registry.npmjs.org/hast-util-from-parse5/-/hast-util-from-parse5-8.0.2.tgz"
-  integrity sha512-SfMzfdAi/zAoZ1KkFEyyeXBn7u/ShQrfd675ZEE9M3qj+PMFX05xubzRyF76CCSJu8au9jgVxDV1+okFvgZU4A==
+  version "8.0.3"
+  resolved "https://registry.npmjs.org/hast-util-from-parse5/-/hast-util-from-parse5-8.0.3.tgz"
+  integrity sha512-3kxEVkEKt0zvcZ3hCRYI8rqrgwtlIOFMWkbclACvjlDw8Li9S2hk/d51OI0nr/gIpdMHNepwgOKqZ/sy0Clpyg==
   dependencies:
     "@types/hast" "^3.0.0"
     "@types/unist" "^3.0.0"
     devlop "^1.0.0"
     hastscript "^9.0.0"
-    property-information "^6.0.0"
+    property-information "^7.0.0"
     vfile "^6.0.0"
     vfile-location "^5.0.0"
     web-namespaces "^2.0.0"
@@ -4768,14 +4965,14 @@ hast-util-to-jsx-runtime@^2.0.0:
     vfile-message "^4.0.0"
 
 hast-util-to-parse5@^8.0.0:
-  version "8.0.0"
-  resolved "https://registry.npmjs.org/hast-util-to-parse5/-/hast-util-to-parse5-8.0.0.tgz"
-  integrity sha512-3KKrV5ZVI8if87DVSi1vDeByYrkGzg4mEfeu4alwgmmIeARiBLKCZS2uw5Gb6nU9x9Yufyj3iudm6i7nl52PFw==
+  version "8.0.1"
+  resolved "https://registry.npmjs.org/hast-util-to-parse5/-/hast-util-to-parse5-8.0.1.tgz"
+  integrity sha512-MlWT6Pjt4CG9lFCjiz4BH7l9wmrMkfkJYCxFwKQic8+RTZgWPuWxwAfjJElsXkex7DJjfSJsQIt931ilUgmwdA==
   dependencies:
     "@types/hast" "^3.0.0"
     comma-separated-tokens "^2.0.0"
     devlop "^1.0.0"
-    property-information "^6.0.0"
+    property-information "^7.0.0"
     space-separated-tokens "^2.0.0"
     web-namespaces "^2.0.0"
     zwitch "^2.0.0"
@@ -4788,14 +4985,14 @@ hast-util-whitespace@^3.0.0:
     "@types/hast" "^3.0.0"
 
 hastscript@^9.0.0:
-  version "9.0.0"
-  resolved "https://registry.npmjs.org/hastscript/-/hastscript-9.0.0.tgz"
-  integrity sha512-jzaLBGavEDKHrc5EfFImKN7nZKKBdSLIdGvCwDZ9TfzbF2ffXiov8CKE445L2Z1Ek2t/m4SKQ2j6Ipv7NyUolw==
+  version "9.0.1"
+  resolved "https://registry.npmjs.org/hastscript/-/hastscript-9.0.1.tgz"
+  integrity sha512-g7df9rMFX/SPi34tyGCyUBREQoKkapwdY/T04Qn9TDWfHhAYt4/I0gMVirzK5wEzeUqIjEB+LXC/ypb7Aqno5w==
   dependencies:
     "@types/hast" "^3.0.0"
     comma-separated-tokens "^2.0.0"
     hast-util-parse-selector "^4.0.0"
-    property-information "^6.0.0"
+    property-information "^7.0.0"
     space-separated-tokens "^2.0.0"
 
 he@^1.2.0:
@@ -4832,11 +5029,6 @@ hpack.js@^2.1.6:
     readable-stream "^2.0.1"
     wbuf "^1.1.0"
 
-html-entities@^2.3.2:
-  version "2.5.2"
-  resolved "https://registry.npmjs.org/html-entities/-/html-entities-2.5.2.tgz"
-  integrity sha512-K//PSRMQk4FZ78Kyau+mZurHn3FH0Vwr+H36eE0rPbeYkRRi9YxceYPhuN60UwWorxyKHhqoAJl2OFKa4BVtaA==
-
 html-escaper@^2.0.2:
   version "2.0.2"
   resolved "https://registry.npmjs.org/html-escaper/-/html-escaper-2.0.2.tgz"
@@ -4929,26 +5121,26 @@ http-errors@~1.6.2:
     setprototypeof "1.1.0"
     statuses ">= 1.4.0 < 2"
 
-http-errors@2.0.0:
-  version "2.0.0"
-  resolved "https://registry.npmjs.org/http-errors/-/http-errors-2.0.0.tgz"
-  integrity sha512-FtwrG/euBzaEjYeRqOgly7G0qviiXoJWnvEH2Z1plBdXgbyjv34pHTSb9zoeHMyDy33+DWy5Wt9Wo+TURtOYSQ==
+http-errors@~2.0.0, http-errors@~2.0.1:
+  version "2.0.1"
+  resolved "https://registry.npmjs.org/http-errors/-/http-errors-2.0.1.tgz"
+  integrity sha512-4FbRdAX+bSdmo4AUFuS0WNiPz8NgFt+r8ThgNWmlrjQjt1Q7ZR9+zTlce2859x4KSXrwIsaeTqDoKQmtP8pLmQ==
   dependencies:
-    depd "2.0.0"
-    inherits "2.0.4"
-    setprototypeof "1.2.0"
-    statuses "2.0.1"
-    toidentifier "1.0.1"
+    depd "~2.0.0"
+    inherits "~2.0.4"
+    setprototypeof "~1.2.0"
+    statuses "~2.0.2"
+    toidentifier "~1.0.1"
 
 http-parser-js@>=0.5.1:
-  version "0.5.9"
-  resolved "https://registry.npmjs.org/http-parser-js/-/http-parser-js-0.5.9.tgz"
-  integrity sha512-n1XsPy3rXVxlqxVioEWdC+0+M+SQw0DpJynwtOPo1X+ZlvdzTLtDBIJJlDQTnwZIFJrZSzSGmIOUdP8tu+SgLw==
+  version "0.5.10"
+  resolved "https://registry.npmjs.org/http-parser-js/-/http-parser-js-0.5.10.tgz"
+  integrity sha512-Pysuw9XpUq5dVc/2SMHpuTY01RFl8fttgcyunjL7eEMhGM3cI4eOmiCycJDVCo/7O7ClfQD3SaI6ftDzqOXYMA==
 
-http-proxy-middleware@^2.0.3:
-  version "2.0.7"
-  resolved "https://registry.npmjs.org/http-proxy-middleware/-/http-proxy-middleware-2.0.7.tgz"
-  integrity sha512-fgVY8AV7qU7z/MmXJ/rxwbrtQH4jBQ9m7kp3llF0liB7glmFeVZFBepQb32T3y8n8k2+AEYuMPCpinYW+/CuRA==
+http-proxy-middleware@^2.0.9:
+  version "2.0.9"
+  resolved "https://registry.npmjs.org/http-proxy-middleware/-/http-proxy-middleware-2.0.9.tgz"
+  integrity sha512-c1IyJYLYppU574+YI7R4QyX2ystMtVXZwIdzazUIPIJsHuWNd+mho2j+bKoHftndicGj9yh+xjd+l0yj7VeT1Q==
   dependencies:
     "@types/http-proxy" "^1.17.8"
     http-proxy "^1.18.1"
@@ -4978,7 +5170,12 @@ human-signals@^2.1.0:
   resolved "https://registry.npmjs.org/human-signals/-/human-signals-2.1.0.tgz"
   integrity sha512-B4FFZ6q/T2jhhksgkbEW3HBvWIfDW85snkQgawt07S7J5QXTk6BkNV+0yAeZrM5QpMAdYlocGoljn0sJ/WQkFw==
 
-iconv-lite@0.4.24:
+hyperdyperid@^1.2.0:
+  version "1.2.0"
+  resolved "https://registry.npmjs.org/hyperdyperid/-/hyperdyperid-1.2.0.tgz"
+  integrity sha512-Y93lCzHYgGWdrJ66yIktxiaGULYc6oGiABxhcO5AufBeOyoIdZF7bIfLaOrbM0iGIOXQQgxxRrFEnb+Y6w1n4A==
+
+iconv-lite@~0.4.24:
   version "0.4.24"
   resolved "https://registry.npmjs.org/iconv-lite/-/iconv-lite-0.4.24.tgz"
   integrity sha512-v3MXnZAcvnywkTUEZomIActle7RXXeedOR31wwl7VlyoXO4Qi9arvSenNQWne1TcRwhCL1HwLI21bEqdpj8/rA==
@@ -4995,22 +5192,15 @@ ignore@^5.2.0, ignore@^5.2.4:
   resolved "https://registry.npmjs.org/ignore/-/ignore-5.3.2.tgz"
   integrity sha512-hsBTNUqQTDwkWtcdYI2i06Y/nUBEsNEDJKjWdigLvegy8kDuJAS8uRlpkkcQpyEXL0Z/pjDy5HBmMjRCJ2gq+g==
 
-image-size@^1.0.2:
-  version "1.2.0"
-  resolved "https://registry.npmjs.org/image-size/-/image-size-1.2.0.tgz"
-  integrity sha512-4S8fwbO6w3GeCVN6OPtA9I5IGKkcDMPcKndtUlpJuCwu7JLjtj7JZpwqLuyY2nrmQT3AWsCJLSKPsc2mPBSl3w==
-  dependencies:
-    queue "6.0.2"
-
-immer@^9.0.7:
-  version "9.0.21"
-  resolved "https://registry.npmjs.org/immer/-/immer-9.0.21.tgz"
-  integrity sha512-bc4NBHqOqSfRW7POMkHd51LvClaeMXpm8dx0e8oE2GORbq5aRK7Bxl4FyzVLdGtLmvLKL7BTDBG5ACQm4HWjTA==
+image-size@^2.0.2:
+  version "2.0.2"
+  resolved "https://registry.npmjs.org/image-size/-/image-size-2.0.2.tgz"
+  integrity sha512-IRqXKlaXwgSMAMtpNzZa1ZAe8m+Sa1770Dhk8VkSsP9LS+iHD62Zd8FQKs8fbPiagBE7BzoFX23cxFnwshpV6w==
 
-import-fresh@^3.1.0, import-fresh@^3.3.0:
-  version "3.3.0"
-  resolved "https://registry.npmjs.org/import-fresh/-/import-fresh-3.3.0.tgz"
-  integrity sha512-veYYhQa+D1QBKznvhUHxb8faxlrwUnxseDAbAp457E0wLNio2bOSKnjYDhMj+YiAq61xrMGhQk9iXVk5FzgQMw==
+import-fresh@^3.3.0:
+  version "3.3.1"
+  resolved "https://registry.npmjs.org/import-fresh/-/import-fresh-3.3.1.tgz"
+  integrity sha512-TR3KfrTZTYLPB6jUjfx6MF9WcWrHL9su5TObK4ZkYgBdWKPOFoSoQIdEuTuR82pmtxH2spWG9h6etwfr1pLBqQ==
   dependencies:
     parent-module "^1.0.0"
     resolve-from "^4.0.0"
@@ -5035,15 +5225,7 @@ infima@0.2.0-alpha.45:
   resolved "https://registry.npmjs.org/infima/-/infima-0.2.0-alpha.45.tgz"
   integrity sha512-uyH0zfr1erU1OohLk0fT4Rrb94AOhguWNOcD9uGrSpRvNB+6gZXUoJX5J0NtvzBO10YZ9PgvA4NFgt+fYg8ojw==
 
-inflight@^1.0.4:
-  version "1.0.6"
-  resolved "https://registry.npmjs.org/inflight/-/inflight-1.0.6.tgz"
-  integrity sha512-k92I/b08q4wvFscXCLvqfsHCrjrF7yiXsQuIVvVE7N82W3+aqpzuUdBbfhWcy/FZR3/4IgflMgKLOsvPDrGCJA==
-  dependencies:
-    once "^1.3.0"
-    wrappy "1"
-
-inherits@^2.0.1, inherits@^2.0.3, inherits@~2.0.3, inherits@2, inherits@2.0.4:
+inherits@^2.0.1, inherits@^2.0.3, inherits@~2.0.3, inherits@~2.0.4:
   version "2.0.4"
   resolved "https://registry.npmjs.org/inherits/-/inherits-2.0.4.tgz"
   integrity sha512-k/vGaX4/Yla3WzyMCvTQOXYeIHvqOKtnqBduzTHpzpQZzAskKMhZ2K+EnBiSM9zGSoIFeMpXKxa4dYeZIQqewQ==
@@ -5053,7 +5235,7 @@ inherits@2.0.3:
   resolved "https://registry.npmjs.org/inherits/-/inherits-2.0.3.tgz"
   integrity sha512-x00IRNXNy63jwGkJmzPigoySHbaqpNuzKbBOmzK+g2OdZpQ9w+sxCN+VSB3ja7IAge2OP2qpfxTjeNcyjmW1uw==
 
-ini@^1.3.4, ini@^1.3.5, ini@~1.3.0:
+ini@^1.3.4, ini@~1.3.0:
   version "1.3.8"
   resolved "https://registry.npmjs.org/ini/-/ini-1.3.8.tgz"
   integrity sha512-JV/yugV2uzW5iMRSiZAyDtQd+nxtUnjeLt0acNdw98kKLrvuRVyB80tsREOE7yvGVgalhZ6RNXCmEHkUKBKxew==
@@ -5068,11 +5250,6 @@ inline-style-parser@0.2.4:
   resolved "https://registry.npmjs.org/inline-style-parser/-/inline-style-parser-0.2.4.tgz"
   integrity sha512-0aO8FkhNZlj/ZIbNi7Lxxr12obT7cL1moPfE4tg1LkX7LlLfC6DeX4l2ZEud1ukP9jNQyNnfzQVqwbwmAATY4Q==
 
-interpret@^1.0.0:
-  version "1.4.0"
-  resolved "https://registry.npmjs.org/interpret/-/interpret-1.4.0.tgz"
-  integrity sha512-agE4QfB2Lkp9uICn7BAqoscw4SZP9kTE2hxiFI3jBPmXJfdqiahTbUuKGsMoN2GtqL9AxhYioAcVvgsb1HvRbA==
-
 invariant@^2.2.4:
   version "2.2.4"
   resolved "https://registry.npmjs.org/invariant/-/invariant-2.2.4.tgz"
@@ -5080,10 +5257,10 @@ invariant@^2.2.4:
   dependencies:
     loose-envify "^1.0.0"
 
-ipaddr.js@^2.0.1:
-  version "2.2.0"
-  resolved "https://registry.npmjs.org/ipaddr.js/-/ipaddr.js-2.2.0.tgz"
-  integrity sha512-Ag3wB2o37wslZS19hZqorUnrnzSkpOVy+IiiDEiTqNubEYpYuHWIf6K4psgN2ZWKExS4xhVCrRVfb/wfW8fWJA==
+ipaddr.js@^2.1.0:
+  version "2.3.0"
+  resolved "https://registry.npmjs.org/ipaddr.js/-/ipaddr.js-2.3.0.tgz"
+  integrity sha512-Zv/pA+ciVFbCSBBjGfaKUya/CcGmUHzTydLMaTwrUUEM2DIEO3iZvueGxmacvmN50fGpGVKeTXpb2LcYQxeVdg==
 
 ipaddr.js@1.9.1:
   version "1.9.1"
@@ -5122,7 +5299,7 @@ is-ci@^3.0.1:
   dependencies:
     ci-info "^3.2.0"
 
-is-core-module@^2.16.0:
+is-core-module@^2.16.1:
   version "2.16.1"
   resolved "https://registry.npmjs.org/is-core-module/-/is-core-module-2.16.1.tgz"
   integrity sha512-UfoeMA6fIJ8wTYFEUjelnaGI67v6+N7qXJEvQuIGa99l4xsCruSYOVSQ0uPANn4dAzm8lkYPaKLrrijLq7x23w==
@@ -5139,6 +5316,11 @@ is-docker@^2.0.0, is-docker@^2.1.1:
   resolved "https://registry.npmjs.org/is-docker/-/is-docker-2.2.1.tgz"
   integrity sha512-F+i2BKsFrH66iaUFc0woD8sLy8getkwTwtOBjvs56Cx4CgJDeKQeqfz8wAYiSb8JOprWhHH5p77PbmYCvvUuXQ==
 
+is-docker@^3.0.0:
+  version "3.0.0"
+  resolved "https://registry.npmjs.org/is-docker/-/is-docker-3.0.0.tgz"
+  integrity sha512-eljcgEDlEns/7AXFosB5K/2nCM4P7FQPkGc/DWLy5rmFEWvZayGrik1d9/QIY5nJ4f9YsVvBkA6kJpHn9rISdQ==
+
 is-extendable@^0.1.0:
   version "0.1.1"
   resolved "https://registry.npmjs.org/is-extendable/-/is-extendable-0.1.1.tgz"
@@ -5166,6 +5348,13 @@ is-hexadecimal@^2.0.0:
   resolved "https://registry.npmjs.org/is-hexadecimal/-/is-hexadecimal-2.0.1.tgz"
   integrity sha512-DgZQp241c8oO6cA1SbTEWiXeoxV42vlcJxgH+B3hi1AiqqKruZR3ZGF8In3fj4+/y/7rHvlOZLZtgJ/4ttYGZg==
 
+is-inside-container@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.npmjs.org/is-inside-container/-/is-inside-container-1.0.0.tgz"
+  integrity sha512-KIYLCCJghfHZxqjYBE7rEy0OBuTd5xCHS7tHVgvCLkx7StIoaxwNW3hCALgEUjFfeRk+MG/Qxmp/vtETEF3tRA==
+  dependencies:
+    is-docker "^3.0.0"
+
 is-installed-globally@^0.4.0:
   version "0.4.0"
   resolved "https://registry.npmjs.org/is-installed-globally/-/is-installed-globally-0.4.0.tgz"
@@ -5174,6 +5363,11 @@ is-installed-globally@^0.4.0:
     global-dirs "^3.0.0"
     is-path-inside "^3.0.2"
 
+is-network-error@^1.0.0:
+  version "1.3.0"
+  resolved "https://registry.npmjs.org/is-network-error/-/is-network-error-1.3.0.tgz"
+  integrity sha512-6oIwpsgRfnDiyEDLMay/GqCl3HoAtH5+RUKW29gYkL0QA+ipzpDLA16yQs7/RHCSu+BwgbJaOUqa4A99qNVQVw==
+
 is-npm@^6.0.0:
   version "6.0.0"
   resolved "https://registry.npmjs.org/is-npm/-/is-npm-6.0.0.tgz"
@@ -5194,11 +5388,6 @@ is-obj@^2.0.0:
   resolved "https://registry.npmjs.org/is-obj/-/is-obj-2.0.0.tgz"
   integrity sha512-drqDG3cbczxxEJRoOXcOjtdp1J/lyp1mNn0xaznRs8+muBhgQcrnbspox5X5fOw0HnMnbfDzvnEMEtqDEJEo8w==
 
-is-path-cwd@^2.2.0:
-  version "2.2.0"
-  resolved "https://registry.npmjs.org/is-path-cwd/-/is-path-cwd-2.2.0.tgz"
-  integrity sha512-w942bTcih8fdJPJmQHFzkS76NEP8Kzzvmw92cXsazb8intwLqPibPPdXf4ANdKV3rYMuuQYGIWtvz9JilB3NFQ==
-
 is-path-inside@^3.0.2:
   version "3.0.3"
   resolved "https://registry.npmjs.org/is-path-inside/-/is-path-inside-3.0.3.tgz"
@@ -5226,11 +5415,6 @@ is-regexp@^1.0.0:
   resolved "https://registry.npmjs.org/is-regexp/-/is-regexp-1.0.0.tgz"
   integrity sha512-7zjFAPO4/gwyQAAgRRmqeEeyIICSdmCqa3tsVHMdBzaXXRiqopZL4Cyghg/XulGWrtABTpbnYYzzIRffLkP4oA==
 
-is-root@^2.1.0:
-  version "2.1.0"
-  resolved "https://registry.npmjs.org/is-root/-/is-root-2.1.0.tgz"
-  integrity sha512-AGOriNp96vNBd3HtU+RzFEc75FfR5ymiYv8E553I71SCeXBiMsVDUtdio1OEFvrPyLIQ9tVR5RxXIFe5PUFjMg==
-
 is-stream@^2.0.0:
   version "2.0.1"
   resolved "https://registry.npmjs.org/is-stream/-/is-stream-2.0.1.tgz"
@@ -5248,6 +5432,13 @@ is-wsl@^2.2.0:
   dependencies:
     is-docker "^2.0.0"
 
+is-wsl@^3.1.0:
+  version "3.1.0"
+  resolved "https://registry.npmjs.org/is-wsl/-/is-wsl-3.1.0.tgz"
+  integrity sha512-UcVfVfaK4Sc4m7X3dUSoHoozQGBEFeDC+zVo06t98xe8CzHSZZBekNXH+tu0NalHolcJ/QAGqS46Hef7QXBIMw==
+  dependencies:
+    is-inside-container "^1.0.0"
+
 is-yarn-global@^0.4.0:
   version "0.4.1"
   resolved "https://registry.npmjs.org/is-yarn-global/-/is-yarn-global-0.4.1.tgz"
@@ -5326,30 +5517,25 @@ joi@^17.9.2:
   integrity sha512-RdJUflcE3cUzKiMqQgsCu06FPu9UdIJO0beYbPhHN4k6apgJtifcoCtT9bcxOpYBtpD2kCM6Sbzg4CausW/PKQ==
 
 js-yaml@^3.13.1:
-  version "3.14.1"
-  resolved "https://registry.npmjs.org/js-yaml/-/js-yaml-3.14.1.tgz"
-  integrity sha512-okMH7OXXJ7YrN9Ok3/SXrnu4iX9yOk+25nqX4imS2npuvTYDmo/QEZoqwZkYaIDk3jVvBOTOIEgEhaLOynBS9g==
+  version "3.14.2"
+  resolved "https://registry.npmjs.org/js-yaml/-/js-yaml-3.14.2.tgz"
+  integrity sha512-PMSmkqxr106Xa156c2M265Z+FTrPl+oxd/rgOQy2tijQeK5TxQ43psO1ZCwhVOSdnn+RzkzlRz/eY4BgJBYVpg==
   dependencies:
     argparse "^1.0.7"
     esprima "^4.0.0"
 
 js-yaml@^4.1.0:
-  version "4.1.0"
-  resolved "https://registry.npmjs.org/js-yaml/-/js-yaml-4.1.0.tgz"
-  integrity sha512-wpxZs9NoxZaJESJGIZTyDEaYpl0FKSA+FB9aJiyemKhMwkxQg63h4T1KJgUGHpTqPDNRcmmYLugrRjJlBtWvRA==
+  version "4.1.1"
+  resolved "https://registry.npmjs.org/js-yaml/-/js-yaml-4.1.1.tgz"
+  integrity sha512-qQKT4zQxXl8lLwBtHMWwaTcGfFOZviOJet3Oy/xmGk2gZH677CJM9EvtfdSkgWcATZhj/55JZ0rmy3myCT5lsA==
   dependencies:
     argparse "^2.0.1"
 
-jsesc@^3.0.2:
+jsesc@^3.0.2, jsesc@~3.1.0:
   version "3.1.0"
   resolved "https://registry.npmjs.org/jsesc/-/jsesc-3.1.0.tgz"
   integrity sha512-/sM3dO2FOzXjKQhJuo0Q173wf2KOo8t4I8vHy6lF9poUp7bKT0/NHE8fPX23PwfhnykfqnC2xRxOnVw5XuGIaA==
 
-jsesc@~3.0.2:
-  version "3.0.2"
-  resolved "https://registry.npmjs.org/jsesc/-/jsesc-3.0.2.tgz"
-  integrity sha512-xKqzzWXDttJuOcawBt4KnKHHIf5oQ/Cxax+0PWFG+DFDgHNAdi+TXECADI+RYiFUMmx8792xsMbbgXj4CwnP4g==
-
 json-buffer@3.0.1:
   version "3.0.1"
   resolved "https://registry.npmjs.org/json-buffer/-/json-buffer-3.0.1.tgz"
@@ -5370,15 +5556,20 @@ json-schema-traverse@^1.0.0:
   resolved "https://registry.npmjs.org/json-schema-traverse/-/json-schema-traverse-1.0.0.tgz"
   integrity sha512-NM8/P9n3XjXhIZn1lLhkFaACTOURQXjWhV4BA/RnOv8xvgqtqpAX9IO4mRQxSx1Rlo4tqzeqb0sOlruaOy3dug==
 
+json-schema@^0.4.0:
+  version "0.4.0"
+  resolved "https://registry.npmjs.org/json-schema/-/json-schema-0.4.0.tgz"
+  integrity sha512-es94M3nTIfsEPisRafak+HDLfHXnKBhV3vU5eqPcS3flIWqcxJWgXHXiey3YrpaNsanY5ei1VoYEbOzijuq9BA==
+
 json5@^2.1.2, json5@^2.2.3:
   version "2.2.3"
   resolved "https://registry.npmjs.org/json5/-/json5-2.2.3.tgz"
   integrity sha512-XmOWe7eyHYH14cLdVPoyg+GOH3rYX++KpzrylJwSW98t3Nk+U8XOl8FWKOgwtzdb8lXGf6zYwDUzeHMWfxasyg==
 
 jsonfile@^6.0.1:
-  version "6.1.0"
-  resolved "https://registry.npmjs.org/jsonfile/-/jsonfile-6.1.0.tgz"
-  integrity sha512-5dgndWOriYSm5cnYaJNhalLNDKOqFwyDB/rr1E9ZsGciGvKPs8R2xYGCacuf3z6K1YKDz182fd+fY3cn3pMqXQ==
+  version "6.2.0"
+  resolved "https://registry.npmjs.org/jsonfile/-/jsonfile-6.2.0.tgz"
+  integrity sha512-FGuPw30AdOIUTRMC2OMRtQV+jkVj2cfPqSeWXv1NEAJ1qZ5zb1X6z1mFhbfOB/iy3ssJCD+3KuZ8r8C3uVFlAg==
   dependencies:
     universalify "^2.0.0"
   optionalDependencies:
@@ -5408,13 +5599,13 @@ latest-version@^7.0.0:
   dependencies:
     package-json "^8.1.0"
 
-launch-editor@^2.6.0:
-  version "2.9.1"
-  resolved "https://registry.npmjs.org/launch-editor/-/launch-editor-2.9.1.tgz"
-  integrity sha512-Gcnl4Bd+hRO9P9icCP/RVVT2o8SFlPXofuCxvA2SaZuH45whSvf5p8x5oih5ftLiVhEI4sp5xDY+R+b3zJBh5w==
+launch-editor@^2.6.1:
+  version "2.12.0"
+  resolved "https://registry.npmjs.org/launch-editor/-/launch-editor-2.12.0.tgz"
+  integrity sha512-giOHXoOtifjdHqUamwKq6c49GzBdLjvxrd2D+Q4V6uOHopJv7p9VJxikDsQ/CBXZbEITgUqSVHXLTG3VhPP1Dg==
   dependencies:
-    picocolors "^1.0.0"
-    shell-quote "^1.8.1"
+    picocolors "^1.1.1"
+    shell-quote "^1.8.3"
 
 leven@^3.1.0:
   version "3.1.0"
@@ -5445,26 +5636,6 @@ loader-utils@^2.0.0:
     emojis-list "^3.0.0"
     json5 "^2.1.2"
 
-loader-utils@^3.2.0:
-  version "3.3.1"
-  resolved "https://registry.npmjs.org/loader-utils/-/loader-utils-3.3.1.tgz"
-  integrity sha512-FMJTLMXfCLMLfJxcX9PFqX5qD88Z5MRGaZCVzfuqeZSPsyiBzs+pahDQjbIWz2QIzPZz0NX9Zy4FX3lmK6YHIg==
-
-locate-path@^3.0.0:
-  version "3.0.0"
-  resolved "https://registry.npmjs.org/locate-path/-/locate-path-3.0.0.tgz"
-  integrity sha512-7AO748wWnIhNqAuaty2ZWHkQHRSNfPVIsPIfwEOWO22AmaoVrWavlOcMR5nzTLNYvp36X220/maaRsrec1G65A==
-  dependencies:
-    p-locate "^3.0.0"
-    path-exists "^3.0.0"
-
-locate-path@^6.0.0:
-  version "6.0.0"
-  resolved "https://registry.npmjs.org/locate-path/-/locate-path-6.0.0.tgz"
-  integrity sha512-iPZK6eYjbxRu3uB4/WZ3EsEIMJFMqAoopl3R+zuq0UjcAm/MO6KCweDgPfP3elTztoKP3KtnVHxTn2NHBSDVUw==
-  dependencies:
-    p-locate "^5.0.0"
-
 locate-path@^7.1.0:
   version "7.2.0"
   resolved "https://registry.npmjs.org/locate-path/-/locate-path-7.2.0.tgz"
@@ -5540,18 +5711,24 @@ markdown-table@^3.0.0:
   resolved "https://registry.npmjs.org/markdown-table/-/markdown-table-3.0.4.tgz"
   integrity sha512-wiYz4+JrLyb/DqW2hkFJxP7Vd7JuTDm77fvbM8VfEQdmSMqcImWeeRbHwZjBjIFki/VaMK2BhFi7oUUZeM5bqw==
 
+marked@^16.3.0:
+  version "16.4.2"
+  resolved "https://registry.npmjs.org/marked/-/marked-16.4.2.tgz"
+  integrity sha512-TI3V8YYWvkVf3KJe1dRkpnjs68JUPyEa5vjKrp1XEEJUAOaQc+Qj+L1qWbPd0SJuAdQkFU0h73sXXqwDYxsiDA==
+
 math-intrinsics@^1.1.0:
   version "1.1.0"
   resolved "https://registry.npmjs.org/math-intrinsics/-/math-intrinsics-1.1.0.tgz"
   integrity sha512-/IXtbwEk5HTPyEwyKX6hGkYXxM9nbj64B+ilVJnC/R6B0pH5G4V3b0pVbL7DBj4tkhBAppbQUlf6F6Xl9LHu1g==
 
 mdast-util-directive@^3.0.0:
-  version "3.0.0"
-  resolved "https://registry.npmjs.org/mdast-util-directive/-/mdast-util-directive-3.0.0.tgz"
-  integrity sha512-JUpYOqKI4mM3sZcNxmF/ox04XYFFkNwr0CFlrQIkCwbvH0xzMCqkMqAde9wRd80VAhaUrwFwKm2nxretdT1h7Q==
+  version "3.1.0"
+  resolved "https://registry.npmjs.org/mdast-util-directive/-/mdast-util-directive-3.1.0.tgz"
+  integrity sha512-I3fNFt+DHmpWCYAT7quoM6lHf9wuqtI+oCOfvILnoicNIqjh5E3dEJWiXuYME2gNe8vl1iMQwyUHa7bgFmak6Q==
   dependencies:
     "@types/mdast" "^4.0.0"
     "@types/unist" "^3.0.0"
+    ccount "^2.0.0"
     devlop "^1.0.0"
     mdast-util-from-markdown "^2.0.0"
     mdast-util-to-markdown "^2.0.0"
@@ -5611,9 +5788,9 @@ mdast-util-gfm-autolink-literal@^2.0.0:
     micromark-util-character "^2.0.0"
 
 mdast-util-gfm-footnote@^2.0.0:
-  version "2.0.0"
-  resolved "https://registry.npmjs.org/mdast-util-gfm-footnote/-/mdast-util-gfm-footnote-2.0.0.tgz"
-  integrity sha512-5jOT2boTSVkMnQ7LTrd6n/18kqwjmuYqo7JUPe+tRCY6O7dAuTFMtTPauYYrMPpox9hlN0uOx/FL8XvEfG9/mQ==
+  version "2.1.0"
+  resolved "https://registry.npmjs.org/mdast-util-gfm-footnote/-/mdast-util-gfm-footnote-2.1.0.tgz"
+  integrity sha512-sqpDWlsHn7Ac9GNZQMeUzPQSMzR6Wv0WKRNvQRg0KqHh02fpTz69Qc1QSseNX29bhz1ROIyNyxExfawVKTm1GQ==
   dependencies:
     "@types/mdast" "^4.0.0"
     devlop "^1.1.0"
@@ -5652,9 +5829,9 @@ mdast-util-gfm-task-list-item@^2.0.0:
     mdast-util-to-markdown "^2.0.0"
 
 mdast-util-gfm@^3.0.0:
-  version "3.0.0"
-  resolved "https://registry.npmjs.org/mdast-util-gfm/-/mdast-util-gfm-3.0.0.tgz"
-  integrity sha512-dgQEX5Amaq+DuUqf26jJqSK9qgixgd6rYDHAv4aTBuA92cTknZlKpPfa86Z/s8Dj8xsAQpFfBmPUHWJBWqS4Bw==
+  version "3.1.0"
+  resolved "https://registry.npmjs.org/mdast-util-gfm/-/mdast-util-gfm-3.1.0.tgz"
+  integrity sha512-0ulfdQOM3ysHhCJ1p06l0b0VKlhU0wuQs3thxZQagjcjPrlFRqY215uZGHHJan9GEAXd9MbfPjFJz+qMkVR6zQ==
   dependencies:
     mdast-util-from-markdown "^2.0.0"
     mdast-util-gfm-autolink-literal "^2.0.0"
@@ -5726,9 +5903,9 @@ mdast-util-phrasing@^4.0.0:
     unist-util-is "^6.0.0"
 
 mdast-util-to-hast@^13.0.0:
-  version "13.2.0"
-  resolved "https://registry.npmjs.org/mdast-util-to-hast/-/mdast-util-to-hast-13.2.0.tgz"
-  integrity sha512-QGYKEuUsYT9ykKBCMOEDLsU5JRObWQusAolFMeko/tYPufNkRffBAQjIE+99jbA87xv6FgmjLtwjh9wBWajwAA==
+  version "13.2.1"
+  resolved "https://registry.npmjs.org/mdast-util-to-hast/-/mdast-util-to-hast-13.2.1.tgz"
+  integrity sha512-cctsq2wp5vTsLIcaymblUriiTcZd0CwWtCbLvrOzYCDZoWyMNV8sZ7krj09FSnsiJi3WVsHLM4k6Dq/yaPyCXA==
   dependencies:
     "@types/hast" "^3.0.0"
     "@types/mdast" "^4.0.0"
@@ -5777,12 +5954,17 @@ media-typer@0.3.0:
   resolved "https://registry.npmjs.org/media-typer/-/media-typer-0.3.0.tgz"
   integrity sha512-dq+qelQ9akHpcOl/gUVRTxVIOkAJ1wR3QAvb4RsVjS8oVoFjDGTc679wJYmUmknUF5HwMLOgb5O+a3KxfWapPQ==
 
-memfs@^3.1.2, memfs@^3.4.3:
-  version "3.6.0"
-  resolved "https://registry.npmjs.org/memfs/-/memfs-3.6.0.tgz"
-  integrity sha512-EGowvkkgbMcIChjMTMkESFDbZeSh8xZ7kNSF0hAiAN4Jh6jgHCRS0Ga/+C8y6Au+oqpezRHCfPsmJ2+DwAgiwQ==
+memfs@^4.43.1:
+  version "4.52.0"
+  resolved "https://registry.npmjs.org/memfs/-/memfs-4.52.0.tgz"
+  integrity sha512-dG5ZY1wUCPWhtl4M2mlc7Wx4OrMGtiI79axnScxwDoPR/25biQYrYm21OpKyZcnKv8pvWaX95SRtZgecZ84gFg==
   dependencies:
-    fs-monkey "^1.0.4"
+    "@jsonjoy.com/json-pack" "^1.11.0"
+    "@jsonjoy.com/util" "^1.9.0"
+    glob-to-regex.js "^1.0.1"
+    thingies "^2.5.0"
+    tree-dump "^1.0.3"
+    tslib "^2.0.0"
 
 merge-descriptors@1.0.3:
   version "1.0.3"
@@ -5886,9 +6068,9 @@ micromark-extension-gfm-strikethrough@^2.0.0:
     micromark-util-types "^2.0.0"
 
 micromark-extension-gfm-table@^2.0.0:
-  version "2.1.0"
-  resolved "https://registry.npmjs.org/micromark-extension-gfm-table/-/micromark-extension-gfm-table-2.1.0.tgz"
-  integrity sha512-Ub2ncQv+fwD70/l4ou27b4YzfNaCJOvyX4HxXU15m7mpYY+rjuWzsLIPZHJL253Z643RpbcP1oeIJlQ/SKW67g==
+  version "2.1.1"
+  resolved "https://registry.npmjs.org/micromark-extension-gfm-table/-/micromark-extension-gfm-table-2.1.1.tgz"
+  integrity sha512-t2OU/dXXioARrC6yWfJ4hqB7rct14e8f7m0cbI5hUmDyyIlwv5vEtooptH8INkbLzOatzKuVbQmAYcbWoyz6Dg==
   dependencies:
     devlop "^1.0.0"
     micromark-factory-space "^2.0.0"
@@ -6230,28 +6412,35 @@ micromatch@^4.0.2, micromatch@^4.0.5, micromatch@^4.0.8:
     braces "^3.0.3"
     picomatch "^2.3.1"
 
-"mime-db@>= 1.43.0 < 2":
-  version "1.53.0"
-  resolved "https://registry.npmjs.org/mime-db/-/mime-db-1.53.0.tgz"
-  integrity sha512-oHlN/w+3MQ3rba9rqFr6V/ypF10LSkdwUysQL7GkXoTgIWeV+tcXGA852TBxH+gsh8UWoyhR1hKcoMJTuWflpg==
+mime-db@^1.54.0:
+  version "1.54.0"
+  resolved "https://registry.npmjs.org/mime-db/-/mime-db-1.54.0.tgz"
+  integrity sha512-aU5EJuIN2WDemCcAp2vFBfp/m4EAhWJnUNSSw0ixs7/kXbd6Pg64EmwJkNdFhB8aWt1sH2CTXrLxo/iAGV3oPQ==
+
+"mime-db@>= 1.43.0 < 2", mime-db@1.52.0:
+  version "1.52.0"
+  resolved "https://registry.npmjs.org/mime-db/-/mime-db-1.52.0.tgz"
+  integrity sha512-sPU4uV7dYlvtWJxwwxHD0PuihVNiE7TyAbQ5SWxDCB9mUYvOgroQOwYQQOKPJ8CIbE+1ETVlOoK1UC2nU3gYvg==
 
 mime-db@~1.33.0:
   version "1.33.0"
   resolved "https://registry.npmjs.org/mime-db/-/mime-db-1.33.0.tgz"
   integrity sha512-BHJ/EKruNIqJf/QahvxwQZXKygOQ256myeN/Ew+THcAa5q+PjyTTMMeNQC4DZw5AwfvelsUrA6B67NKMqXDbzQ==
 
-mime-db@1.52.0:
-  version "1.52.0"
-  resolved "https://registry.npmjs.org/mime-db/-/mime-db-1.52.0.tgz"
-  integrity sha512-sPU4uV7dYlvtWJxwwxHD0PuihVNiE7TyAbQ5SWxDCB9mUYvOgroQOwYQQOKPJ8CIbE+1ETVlOoK1UC2nU3gYvg==
-
-mime-types@^2.1.27, mime-types@^2.1.31, mime-types@~2.1.17, mime-types@~2.1.24, mime-types@~2.1.34:
+mime-types@^2.1.27, mime-types@~2.1.17, mime-types@~2.1.24, mime-types@~2.1.34:
   version "2.1.35"
   resolved "https://registry.npmjs.org/mime-types/-/mime-types-2.1.35.tgz"
   integrity sha512-ZDY+bPm5zTTF+YpCrAU9nK0UgICYPT0QtT1NZWFv4s++TNkcgVaT0g6+4R2uI4MjQjzysHB1zxuWL50hzaeXiw==
   dependencies:
     mime-db "1.52.0"
 
+mime-types@^3.0.1:
+  version "3.0.2"
+  resolved "https://registry.npmjs.org/mime-types/-/mime-types-3.0.2.tgz"
+  integrity sha512-Lbgzdk0h4juoQ9fCKXW4by0UJqj+nOOrI9MJ1sSj4nI8aI2eo1qmvQEie4VD1glsS250n15LsWsYtCugiStS5A==
+  dependencies:
+    mime-db "^1.54.0"
+
 mime-types@2.1.18:
   version "2.1.18"
   resolved "https://registry.npmjs.org/mime-types/-/mime-types-2.1.18.tgz"
@@ -6279,10 +6468,10 @@ mimic-response@^4.0.0:
   resolved "https://registry.npmjs.org/mimic-response/-/mimic-response-4.0.0.tgz"
   integrity sha512-e5ISH9xMYU0DzrT+jl8q2ze9D6eWBto+I8CNpe+VI+K2J/F/k3PdkdTdz4wvGVH4NTpo+NRYTVIuMQEMMcsLqg==
 
-mini-css-extract-plugin@^2.9.1:
-  version "2.9.2"
-  resolved "https://registry.npmjs.org/mini-css-extract-plugin/-/mini-css-extract-plugin-2.9.2.tgz"
-  integrity sha512-GJuACcS//jtq4kCtd5ii/M0SZf7OZRH+BxdqXZHaJfb8TJiVl+NgQRPwiYt2EuqeSkNydn/7vP+bcE27C5mb9w==
+mini-css-extract-plugin@^2.9.2:
+  version "2.9.4"
+  resolved "https://registry.npmjs.org/mini-css-extract-plugin/-/mini-css-extract-plugin-2.9.4.tgz"
+  integrity sha512-ZWYT7ln73Hptxqxk2DxPU9MmapXRhxkJD6tkSR04dnQxm8BGu2hzgKLugK5yySD97u/8yy7Ma7E76k9ZdvtjkQ==
   dependencies:
     schema-utils "^4.0.0"
     tapable "^2.2.1"
@@ -6292,7 +6481,7 @@ minimalistic-assert@^1.0.0:
   resolved "https://registry.npmjs.org/minimalistic-assert/-/minimalistic-assert-1.0.1.tgz"
   integrity sha512-UtJcAD4yEaGtjPezWuO9wC4nwUnVH/8/Im3yEHQP4b67cXlD/Qr9hdITCU1xDbSEXg2XKNaP8jsReV7vQd00/A==
 
-minimatch@^3.0.4, minimatch@^3.0.5, minimatch@^3.1.1, minimatch@3.1.2:
+minimatch@3.1.2:
   version "3.1.2"
   resolved "https://registry.npmjs.org/minimatch/-/minimatch-3.1.2.tgz"
   integrity sha512-J7p63hRiAjw1NDEww1W7i37+ByIrOWO5XQQAzZ3VOcL0PNybwpfmV/N05zFAzwQ9USyEcX6t3UO+K5aqBQOIHw==
@@ -6327,10 +6516,10 @@ multicast-dns@^7.2.5:
     dns-packet "^5.2.2"
     thunky "^1.0.2"
 
-nanoid@^3.3.8:
-  version "3.3.8"
-  resolved "https://registry.npmjs.org/nanoid/-/nanoid-3.3.8.tgz"
-  integrity sha512-WNLf5Sd8oZxOm+TzppcYk8gVOgP+l58xNy58D0nbUnOxOWRWvlcCV4kUF7ltmI6PsrLl/BgKEyS4mqsGChFN0w==
+nanoid@^3.3.11:
+  version "3.3.11"
+  resolved "https://registry.npmjs.org/nanoid/-/nanoid-3.3.11.tgz"
+  integrity sha512-N8SpfPUnUp1bK+PMYW8qSWdl9U+wwNWI4QKxOYDy9JAro3WMX7p2OeVRF9v+347pnakNevPmiHhNmZ2HbFA76w==
 
 negotiator@~0.6.4:
   version "0.6.4"
@@ -6365,26 +6554,16 @@ node-emoji@^2.1.0:
     emojilib "^2.4.0"
     skin-tone "^2.0.0"
 
-node-forge@^1:
-  version "1.3.1"
-  resolved "https://registry.npmjs.org/node-forge/-/node-forge-1.3.1.tgz"
-  integrity sha512-dPEtOeMvF9VMcYV/1Wb8CPoVAXtp6MKMlcbAt4ddqmGqUJ6fQZFXkNZNkNlfevtNkGtaSoXf/vNNNSvgrdXwtA==
-
-node-releases@^2.0.19:
-  version "2.0.19"
-  resolved "https://registry.npmjs.org/node-releases/-/node-releases-2.0.19.tgz"
-  integrity sha512-xxOWJsBKtzAq7DY0J+DTzuz58K8e7sJbdgwkbMWQe8UYB6ekmsQ45q0M/tJDsGaZmbC+l7n57UV8Hl5tHxO9uw==
+node-releases@^2.0.27:
+  version "2.0.27"
+  resolved "https://registry.npmjs.org/node-releases/-/node-releases-2.0.27.tgz"
+  integrity sha512-nmh3lCkYZ3grZvqcCH+fjmQ7X+H0OeZgP40OierEaAptX4XofMh5kwNbWh7lBduUzCcV/8kZ+NDLCwm2iorIlA==
 
 normalize-path@^3.0.0, normalize-path@~3.0.0:
   version "3.0.0"
   resolved "https://registry.npmjs.org/normalize-path/-/normalize-path-3.0.0.tgz"
   integrity sha512-6eZs5Ls3WtCisHWp9S2GUy8dqkpGi4BVSz3GaqiE6ezub0512ESztXUwUB6C6IKbQkY2Pnb/mD4WYojCRwcwLA==
 
-normalize-range@^0.1.2:
-  version "0.1.2"
-  resolved "https://registry.npmjs.org/normalize-range/-/normalize-range-0.1.2.tgz"
-  integrity sha512-bdok/XvKII3nUpklnV6P2hxtMNrCboOjAcyBuQnWEhO665FwrSNRxU+AqpsyvO6LgGYPspN+lu5CLtw4jPRKNA==
-
 normalize-url@^8.0.0:
   version "8.0.1"
   resolved "https://registry.npmjs.org/normalize-url/-/normalize-url-8.0.1.tgz"
@@ -6423,9 +6602,9 @@ object-assign@^4.1.1:
   integrity sha512-rJgTQnkUnH1sFw8yT6VSU3zD3sWmu6sZhIseY8VX+GRu3P6F7Fu+JNDoXfklElbLJSnc3FUQHVe4cU5hj+BcUg==
 
 object-inspect@^1.13.3:
-  version "1.13.3"
-  resolved "https://registry.npmjs.org/object-inspect/-/object-inspect-1.13.3.tgz"
-  integrity sha512-kDCGIbxkDSXE3euJZZXzc6to7fCrKHNI/hSRQnRuQ+BWjFNzZwiFF8fj/6o2t2G9/jTj8PSIYTfCLelLZEeRpA==
+  version "1.13.4"
+  resolved "https://registry.npmjs.org/object-inspect/-/object-inspect-1.13.4.tgz"
+  integrity sha512-W67iLl4J2EXEGTbfeHCffrjDfitvLANg0UlX3wFUUSTx92KXRFegMHUVgSqE+wvhAbi4WqjGg9czysTV2Epbew==
 
 object-keys@^1.1.1:
   version "1.1.1"
@@ -6449,24 +6628,17 @@ obuf@^1.0.0, obuf@^1.1.2:
   resolved "https://registry.npmjs.org/obuf/-/obuf-1.1.2.tgz"
   integrity sha512-PX1wu0AmAdPqOL1mWhqmlOd8kOIZQwGZw6rh7uby9fTc5lhaOWFLX3I6R1hrF9k3zUY40e6igsLGkDXK92LJNg==
 
-on-finished@2.4.1:
+on-finished@^2.4.1, on-finished@~2.4.1:
   version "2.4.1"
   resolved "https://registry.npmjs.org/on-finished/-/on-finished-2.4.1.tgz"
   integrity sha512-oVlzkg3ENAhCk2zdv7IJwd/QUD4z2RxRwpkcGY8psCVcCYZNq4wYnVWALHM+brtuJjePWiYF/ClmuDr8Ch5+kg==
   dependencies:
     ee-first "1.1.1"
 
-on-headers@~1.0.2:
-  version "1.0.2"
-  resolved "https://registry.npmjs.org/on-headers/-/on-headers-1.0.2.tgz"
-  integrity sha512-pZAE+FJLoyITytdqK0U5s+FIpjN0JP3OzFi/u8Rx+EV5/W+JTWGXG8xFzevE7AjBfDqHv/8vL8qQsIhHnqRkrA==
-
-once@^1.3.0:
-  version "1.4.0"
-  resolved "https://registry.npmjs.org/once/-/once-1.4.0.tgz"
-  integrity sha512-lNaJgI+2Q5URQBkccEKHTQOPaXdUxnZZElQTZY0MFUAuaEqe1E+Nyvgdz/aIyNi6Z9MzO5dv1H8n58/GELp3+w==
-  dependencies:
-    wrappy "1"
+on-headers@~1.1.0:
+  version "1.1.0"
+  resolved "https://registry.npmjs.org/on-headers/-/on-headers-1.1.0.tgz"
+  integrity sha512-737ZY3yNnXy37FHkQxPzt4UZ2UWPWiCZWLvFZ4fu5cueciegX0zGPnrlY6bwRg4FdQOe9YU8MkmJwGhoMybl8A==
 
 onetime@^5.1.2:
   version "5.1.2"
@@ -6475,7 +6647,17 @@ onetime@^5.1.2:
   dependencies:
     mimic-fn "^2.1.0"
 
-open@^8.0.9, open@^8.4.0:
+open@^10.0.3:
+  version "10.2.0"
+  resolved "https://registry.npmjs.org/open/-/open-10.2.0.tgz"
+  integrity sha512-YgBpdJHPyQ2UE5x+hlSXcnejzAvD0b22U2OuAP+8OnlJT+PjWPxtgmGqKKc+RgTM63U9gN0YzrYc71R2WT/hTA==
+  dependencies:
+    default-browser "^5.2.1"
+    define-lazy-prop "^3.0.0"
+    is-inside-container "^1.0.0"
+    wsl-utils "^0.1.0"
+
+open@^8.4.0:
   version "8.4.2"
   resolved "https://registry.npmjs.org/open/-/open-8.4.2.tgz"
   integrity sha512-7x81NCL719oNbsq/3mh+hVrAWmFuEYUqrq/Iw3kUzH8ReypT9QQ0BLoJS7/G9k6N81XjW4qHWtjWwe/9eLy1EQ==
@@ -6494,19 +6676,10 @@ p-cancelable@^3.0.0:
   resolved "https://registry.npmjs.org/p-cancelable/-/p-cancelable-3.0.0.tgz"
   integrity sha512-mlVgR3PGuzlo0MmTdk4cXqXWlwQDLnONTAg6sm62XkMJEiRxN3GL3SffkYvqwonbkJBcrI7Uvv5Zh9yjvn2iUw==
 
-p-limit@^2.0.0:
-  version "2.3.0"
-  resolved "https://registry.npmjs.org/p-limit/-/p-limit-2.3.0.tgz"
-  integrity sha512-//88mFWSJx8lxCzwdAABTJL2MyWB12+eIY7MDL2SqLmAkeKU9qxRvWuSyTjm3FUmpBEMuFfckAIqEaVGUDxb6w==
-  dependencies:
-    p-try "^2.0.0"
-
-p-limit@^3.0.2:
-  version "3.1.0"
-  resolved "https://registry.npmjs.org/p-limit/-/p-limit-3.1.0.tgz"
-  integrity sha512-TYOanM3wGwNGsZN2cVTYPArw454xnXj5qmWF1bEoAc4+cU/ol7GVh7odevjp1FNHduHc3KZMcFduxU5Xc6uJRQ==
-  dependencies:
-    yocto-queue "^0.1.0"
+p-finally@^1.0.0:
+  version "1.0.0"
+  resolved "https://registry.npmjs.org/p-finally/-/p-finally-1.0.0.tgz"
+  integrity sha512-LICb2p9CB7FS+0eR1oqWnHhp0FljGLZCWBE9aix0Uye9W8LTQPwMTYVGWQWIw9RdQiDg4+epXQODwIYJtSJaow==
 
 p-limit@^4.0.0:
   version "4.0.0"
@@ -6515,20 +6688,6 @@ p-limit@^4.0.0:
   dependencies:
     yocto-queue "^1.0.0"
 
-p-locate@^3.0.0:
-  version "3.0.0"
-  resolved "https://registry.npmjs.org/p-locate/-/p-locate-3.0.0.tgz"
-  integrity sha512-x+12w/To+4GFfgJhBEpiDcLozRJGegY+Ei7/z0tSLkMmxGZNybVMSfWj9aJn8Z5Fc7dBUNJOOVgPv2H7IwulSQ==
-  dependencies:
-    p-limit "^2.0.0"
-
-p-locate@^5.0.0:
-  version "5.0.0"
-  resolved "https://registry.npmjs.org/p-locate/-/p-locate-5.0.0.tgz"
-  integrity sha512-LaNjtRWUBY++zB5nE/NwcaoMylSPk+S+ZHNB1TzdbMJMny6dynpAGt7X/tl/QYq3TIeE6nxHppbo2LGymrG5Pw==
-  dependencies:
-    p-limit "^3.0.2"
-
 p-locate@^6.0.0:
   version "6.0.0"
   resolved "https://registry.npmjs.org/p-locate/-/p-locate-6.0.0.tgz"
@@ -6543,18 +6702,29 @@ p-map@^4.0.0:
   dependencies:
     aggregate-error "^3.0.0"
 
-p-retry@^4.5.0:
-  version "4.6.2"
-  resolved "https://registry.npmjs.org/p-retry/-/p-retry-4.6.2.tgz"
-  integrity sha512-312Id396EbJdvRONlngUx0NydfrIQ5lsYu0znKVUzVvArzEIt08V1qhtyESbGVd1FGX7UKtiFp5uwKZdM8wIuQ==
+p-queue@^6.6.2:
+  version "6.6.2"
+  resolved "https://registry.npmjs.org/p-queue/-/p-queue-6.6.2.tgz"
+  integrity sha512-RwFpb72c/BhQLEXIZ5K2e+AhgNVmIejGlTgiB9MzZ0e93GRvqZ7uSi0dvRF7/XIXDeNkra2fNHBxTyPDGySpjQ==
+  dependencies:
+    eventemitter3 "^4.0.4"
+    p-timeout "^3.2.0"
+
+p-retry@^6.2.0:
+  version "6.2.1"
+  resolved "https://registry.npmjs.org/p-retry/-/p-retry-6.2.1.tgz"
+  integrity sha512-hEt02O4hUct5wtwg4H4KcWgDdm+l1bOaEy/hWzd8xtXB9BqxTWBBhb+2ImAtH4Cv4rPjV76xN3Zumqk3k3AhhQ==
   dependencies:
-    "@types/retry" "0.12.0"
+    "@types/retry" "0.12.2"
+    is-network-error "^1.0.0"
     retry "^0.13.1"
 
-p-try@^2.0.0:
-  version "2.2.0"
-  resolved "https://registry.npmjs.org/p-try/-/p-try-2.2.0.tgz"
-  integrity sha512-R4nPAVTAU0B9D35/Gk3uJf/7XYbQcyohSKdvAxIRSNghFl4e71hVoGnBNQz9cWaXxO2I10KTC+3jMdvvoKw6dQ==
+p-timeout@^3.2.0:
+  version "3.2.0"
+  resolved "https://registry.npmjs.org/p-timeout/-/p-timeout-3.2.0.tgz"
+  integrity sha512-rhIwUycgwwKcP9yTOOFK/AKsAopjjCakVqLHePO3CC6Mir1Z99xT+R63jZxAT5lFZLa2inS5h+ZS2GvR99/FBg==
+  dependencies:
+    p-finally "^1.0.0"
 
 package-json@^8.1.0:
   version "8.1.1"
@@ -6594,7 +6764,7 @@ parse-entities@^4.0.0:
     is-decimal "^2.0.0"
     is-hexadecimal "^2.0.0"
 
-parse-json@^5.0.0, parse-json@^5.2.0:
+parse-json@^5.2.0:
   version "5.2.0"
   resolved "https://registry.npmjs.org/parse-json/-/parse-json-5.2.0.tgz"
   integrity sha512-ayCKvm/phCGxOkYRSCM82iDwct8/EonSEgCSxWxD7ve6jHggsFl4fZVQBPRNgQoKiuV/odhFrGzQXZwbifC8Rg==
@@ -6618,11 +6788,11 @@ parse5-htmlparser2-tree-adapter@^7.0.0:
     parse5 "^7.0.0"
 
 parse5@^7.0.0:
-  version "7.2.1"
-  resolved "https://registry.npmjs.org/parse5/-/parse5-7.2.1.tgz"
-  integrity sha512-BuBYQYlv1ckiPdQi/ohiivi9Sagc9JG+Ozs0r7b/0iK3sKmrb0b9FdWdBbOdx6hBCM/F9Ir82ofnBhtZOjCRPQ==
+  version "7.3.0"
+  resolved "https://registry.npmjs.org/parse5/-/parse5-7.3.0.tgz"
+  integrity sha512-IInvU7fabl34qmi9gY8XOVxhYyMyuH2xUNpb2q8/Y+7552KlejkRvqvD19nMoUW/uQGGbqNpA6Tufu5FL5BZgw==
   dependencies:
-    entities "^4.5.0"
+    entities "^6.0.0"
 
 parseurl@~1.3.2, parseurl@~1.3.3:
   version "1.3.3"
@@ -6637,26 +6807,11 @@ pascal-case@^3.1.2:
     no-case "^3.0.4"
     tslib "^2.0.3"
 
-path-exists@^3.0.0:
-  version "3.0.0"
-  resolved "https://registry.npmjs.org/path-exists/-/path-exists-3.0.0.tgz"
-  integrity sha512-bpC7GYwiDYQ4wYLe+FA8lhRjhQCMcQGuSgGGqDkg/QerRWw9CmGRT0iSOVRSZJ29NMLZgIzqaljJ63oaL4NIJQ==
-
-path-exists@^4.0.0:
-  version "4.0.0"
-  resolved "https://registry.npmjs.org/path-exists/-/path-exists-4.0.0.tgz"
-  integrity sha512-ak9Qy5Q7jYb2Wwcey5Fpvg2KoAc/ZIhLSLOSBmRmygPsGwkVVt0fZa0qrtMz+m6tJTAHfZQ8FnmB4MG4LWy7/w==
-
 path-exists@^5.0.0:
   version "5.0.0"
   resolved "https://registry.npmjs.org/path-exists/-/path-exists-5.0.0.tgz"
   integrity sha512-RjhtfwJOxzcFmNOi6ltcbcu4Iu+FL3zEj83dk4kAS+fVpTxXLO1b38RvJgT/0QwvV/L3aY9TAnyv0EOqW4GoMQ==
 
-path-is-absolute@^1.0.0:
-  version "1.0.1"
-  resolved "https://registry.npmjs.org/path-is-absolute/-/path-is-absolute-1.0.1.tgz"
-  integrity sha512-AVbw3UJ2e9bq64vSaS9Am0fje1Pa8pbGqTTsmXfaIiMpnr5DlDhfJOuLj9Sf95ZPVDAUerDfEk88MPmPe7UCQg==
-
 path-is-inside@1.0.2:
   version "1.0.2"
   resolved "https://registry.npmjs.org/path-is-inside/-/path-is-inside-1.0.2.tgz"
@@ -6679,7 +6834,7 @@ path-to-regexp@^1.7.0:
   dependencies:
     isarray "0.0.1"
 
-path-to-regexp@0.1.12:
+path-to-regexp@~0.1.12:
   version "0.1.12"
   resolved "https://registry.npmjs.org/path-to-regexp/-/path-to-regexp-0.1.12.tgz"
   integrity sha512-RA1GjUVMnvYFxuqovrEqZoxxW5NUZqbwKtYz/Tt7nXerk0LbLblQmrsgdeOxV5SFHf0UDggjS/bSeOZwt1pmEQ==
@@ -6694,7 +6849,7 @@ path-type@^4.0.0:
   resolved "https://registry.npmjs.org/path-type/-/path-type-4.0.0.tgz"
   integrity sha512-gDKb8aZMDeD/tZWs9P6+q0J9Mwkdl6xMV8TjnGP3qJVJ06bdMgkbBlLU8IdfOsIsFz2BW1rNVT3XuNEl8zPAvw==
 
-picocolors@^1.0.0, picocolors@^1.0.1, picocolors@^1.1.1:
+picocolors@^1.0.0, picocolors@^1.1.1:
   version "1.1.1"
   resolved "https://registry.npmjs.org/picocolors/-/picocolors-1.1.1.tgz"
   integrity sha512-xceH2snhtb5M9liqDsmEw56le376mTZkEX/jEb/RxNFyegNul7eNslCXP9FDj/Lcu0X8KEyMceP2ntpaHrDEVA==
@@ -6711,12 +6866,17 @@ pkg-dir@^7.0.0:
   dependencies:
     find-up "^6.3.0"
 
-pkg-up@^3.1.0:
-  version "3.1.0"
-  resolved "https://registry.npmjs.org/pkg-up/-/pkg-up-3.1.0.tgz"
-  integrity sha512-nDywThFk1i4BQK4twPQ6TA4RT8bDY96yeuCVBWL3ePARCiEKDRSrNGbFIgUJpLp+XeIR65v8ra7WuJOFUBtkMA==
+pkijs@^3.3.3:
+  version "3.3.3"
+  resolved "https://registry.npmjs.org/pkijs/-/pkijs-3.3.3.tgz"
+  integrity sha512-+KD8hJtqQMYoTuL1bbGOqxb4z+nZkTAwVdNtWwe8Tc2xNbEmdJYIYoc6Qt0uF55e6YW6KuTHw1DjQ18gMhzepw==
   dependencies:
-    find-up "^3.0.0"
+    "@noble/hashes" "1.4.0"
+    asn1js "^3.0.6"
+    bytestreamjs "^2.0.1"
+    pvtsutils "^1.3.6"
+    pvutils "^1.1.3"
+    tslib "^2.8.1"
 
 postcss-attribute-case-insensitive@^7.0.1:
   version "7.0.1"
@@ -6740,15 +6900,15 @@ postcss-clamp@^4.1.0:
   dependencies:
     postcss-value-parser "^4.2.0"
 
-postcss-color-functional-notation@^7.0.7:
-  version "7.0.7"
-  resolved "https://registry.npmjs.org/postcss-color-functional-notation/-/postcss-color-functional-notation-7.0.7.tgz"
-  integrity sha512-EZvAHsvyASX63vXnyXOIynkxhaHRSsdb7z6yiXKIovGXAolW4cMZ3qoh7k3VdTsLBS6VGdksGfIo3r6+waLoOw==
+postcss-color-functional-notation@^7.0.12:
+  version "7.0.12"
+  resolved "https://registry.npmjs.org/postcss-color-functional-notation/-/postcss-color-functional-notation-7.0.12.tgz"
+  integrity sha512-TLCW9fN5kvO/u38/uesdpbx3e8AkTYhMvDZYa9JpmImWuTE99bDQ7GU7hdOADIZsiI9/zuxfAJxny/khknp1Zw==
   dependencies:
-    "@csstools/css-color-parser" "^3.0.7"
-    "@csstools/css-parser-algorithms" "^3.0.4"
-    "@csstools/css-tokenizer" "^3.0.3"
-    "@csstools/postcss-progressive-custom-properties" "^4.0.0"
+    "@csstools/css-color-parser" "^3.1.0"
+    "@csstools/css-parser-algorithms" "^3.0.5"
+    "@csstools/css-tokenizer" "^3.0.4"
+    "@csstools/postcss-progressive-custom-properties" "^4.2.1"
     "@csstools/utilities" "^2.0.0"
 
 postcss-color-hex-alpha@^10.0.0:
@@ -6785,35 +6945,35 @@ postcss-convert-values@^6.1.0:
     browserslist "^4.23.0"
     postcss-value-parser "^4.2.0"
 
-postcss-custom-media@^11.0.5:
-  version "11.0.5"
-  resolved "https://registry.npmjs.org/postcss-custom-media/-/postcss-custom-media-11.0.5.tgz"
-  integrity sha512-SQHhayVNgDvSAdX9NQ/ygcDQGEY+aSF4b/96z7QUX6mqL5yl/JgG/DywcF6fW9XbnCRE+aVYk+9/nqGuzOPWeQ==
-  dependencies:
-    "@csstools/cascade-layer-name-parser" "^2.0.4"
-    "@csstools/css-parser-algorithms" "^3.0.4"
-    "@csstools/css-tokenizer" "^3.0.3"
-    "@csstools/media-query-list-parser" "^4.0.2"
-
-postcss-custom-properties@^14.0.4:
-  version "14.0.4"
-  resolved "https://registry.npmjs.org/postcss-custom-properties/-/postcss-custom-properties-14.0.4.tgz"
-  integrity sha512-QnW8FCCK6q+4ierwjnmXF9Y9KF8q0JkbgVfvQEMa93x1GT8FvOiUevWCN2YLaOWyByeDX8S6VFbZEeWoAoXs2A==
-  dependencies:
-    "@csstools/cascade-layer-name-parser" "^2.0.4"
-    "@csstools/css-parser-algorithms" "^3.0.4"
-    "@csstools/css-tokenizer" "^3.0.3"
+postcss-custom-media@^11.0.6:
+  version "11.0.6"
+  resolved "https://registry.npmjs.org/postcss-custom-media/-/postcss-custom-media-11.0.6.tgz"
+  integrity sha512-C4lD4b7mUIw+RZhtY7qUbf4eADmb7Ey8BFA2px9jUbwg7pjTZDl4KY4bvlUV+/vXQvzQRfiGEVJyAbtOsCMInw==
+  dependencies:
+    "@csstools/cascade-layer-name-parser" "^2.0.5"
+    "@csstools/css-parser-algorithms" "^3.0.5"
+    "@csstools/css-tokenizer" "^3.0.4"
+    "@csstools/media-query-list-parser" "^4.0.3"
+
+postcss-custom-properties@^14.0.6:
+  version "14.0.6"
+  resolved "https://registry.npmjs.org/postcss-custom-properties/-/postcss-custom-properties-14.0.6.tgz"
+  integrity sha512-fTYSp3xuk4BUeVhxCSJdIPhDLpJfNakZKoiTDx7yRGCdlZrSJR7mWKVOBS4sBF+5poPQFMj2YdXx1VHItBGihQ==
+  dependencies:
+    "@csstools/cascade-layer-name-parser" "^2.0.5"
+    "@csstools/css-parser-algorithms" "^3.0.5"
+    "@csstools/css-tokenizer" "^3.0.4"
     "@csstools/utilities" "^2.0.0"
     postcss-value-parser "^4.2.0"
 
-postcss-custom-selectors@^8.0.4:
-  version "8.0.4"
-  resolved "https://registry.npmjs.org/postcss-custom-selectors/-/postcss-custom-selectors-8.0.4.tgz"
-  integrity sha512-ASOXqNvDCE0dAJ/5qixxPeL1aOVGHGW2JwSy7HyjWNbnWTQCl+fDc968HY1jCmZI0+BaYT5CxsOiUhavpG/7eg==
+postcss-custom-selectors@^8.0.5:
+  version "8.0.5"
+  resolved "https://registry.npmjs.org/postcss-custom-selectors/-/postcss-custom-selectors-8.0.5.tgz"
+  integrity sha512-9PGmckHQswiB2usSO6XMSswO2yFWVoCAuih1yl9FVcwkscLjRKjwsjM3t+NIWpSU2Jx3eOiK2+t4vVTQaoCHHg==
   dependencies:
-    "@csstools/cascade-layer-name-parser" "^2.0.4"
-    "@csstools/css-parser-algorithms" "^3.0.4"
-    "@csstools/css-tokenizer" "^3.0.3"
+    "@csstools/cascade-layer-name-parser" "^2.0.5"
+    "@csstools/css-parser-algorithms" "^3.0.5"
+    "@csstools/css-tokenizer" "^3.0.4"
     postcss-selector-parser "^7.0.0"
 
 postcss-dir-pseudo-class@^9.0.1:
@@ -6850,12 +7010,12 @@ postcss-discard-unused@^6.0.5:
   dependencies:
     postcss-selector-parser "^6.0.16"
 
-postcss-double-position-gradients@^6.0.0:
-  version "6.0.0"
-  resolved "https://registry.npmjs.org/postcss-double-position-gradients/-/postcss-double-position-gradients-6.0.0.tgz"
-  integrity sha512-JkIGah3RVbdSEIrcobqj4Gzq0h53GG4uqDPsho88SgY84WnpkTpI0k50MFK/sX7XqVisZ6OqUfFnoUO6m1WWdg==
+postcss-double-position-gradients@^6.0.4:
+  version "6.0.4"
+  resolved "https://registry.npmjs.org/postcss-double-position-gradients/-/postcss-double-position-gradients-6.0.4.tgz"
+  integrity sha512-m6IKmxo7FxSP5nF2l63QbCC3r+bWpFUWmZXZf096WxG0m7Vl1Q1+ruFOhpdDRmKrRS+S3Jtk+TVk/7z0+BVK6g==
   dependencies:
-    "@csstools/postcss-progressive-custom-properties" "^4.0.0"
+    "@csstools/postcss-progressive-custom-properties" "^4.2.1"
     "@csstools/utilities" "^2.0.0"
     postcss-value-parser "^4.2.0"
 
@@ -6891,18 +7051,18 @@ postcss-image-set-function@^7.0.0:
     "@csstools/utilities" "^2.0.0"
     postcss-value-parser "^4.2.0"
 
-postcss-lab-function@^7.0.7:
-  version "7.0.7"
-  resolved "https://registry.npmjs.org/postcss-lab-function/-/postcss-lab-function-7.0.7.tgz"
-  integrity sha512-+ONj2bpOQfsCKZE2T9VGMyVVdGcGUpr7u3SVfvkJlvhTRmDCfY25k4Jc8fubB9DclAPR4+w8uVtDZmdRgdAHig==
+postcss-lab-function@^7.0.12:
+  version "7.0.12"
+  resolved "https://registry.npmjs.org/postcss-lab-function/-/postcss-lab-function-7.0.12.tgz"
+  integrity sha512-tUcyRk1ZTPec3OuKFsqtRzW2Go5lehW29XA21lZ65XmzQkz43VY2tyWEC202F7W3mILOjw0voOiuxRGTsN+J9w==
   dependencies:
-    "@csstools/css-color-parser" "^3.0.7"
-    "@csstools/css-parser-algorithms" "^3.0.4"
-    "@csstools/css-tokenizer" "^3.0.3"
-    "@csstools/postcss-progressive-custom-properties" "^4.0.0"
+    "@csstools/css-color-parser" "^3.1.0"
+    "@csstools/css-parser-algorithms" "^3.0.5"
+    "@csstools/css-tokenizer" "^3.0.4"
+    "@csstools/postcss-progressive-custom-properties" "^4.2.1"
     "@csstools/utilities" "^2.0.0"
 
-postcss-loader@^7.3.3:
+postcss-loader@^7.3.4:
   version "7.3.4"
   resolved "https://registry.npmjs.org/postcss-loader/-/postcss-loader-7.3.4.tgz"
   integrity sha512-iW5WTTBSC5BfsBJ9daFMPVrLT36MrNiC6fqOZTTaHjBNX6Pfd5p+hSBqe/fEeNd7pc13QiAyGt7VdGMw4eRC4A==
@@ -6911,10 +7071,10 @@ postcss-loader@^7.3.3:
     jiti "^1.20.0"
     semver "^7.5.4"
 
-postcss-logical@^8.0.0:
-  version "8.0.0"
-  resolved "https://registry.npmjs.org/postcss-logical/-/postcss-logical-8.0.0.tgz"
-  integrity sha512-HpIdsdieClTjXLOyYdUPAX/XQASNIwdKt5hoZW08ZOAiI+tbV0ta1oclkpVkW5ANU+xJvk3KkA0FejkjGLXUkg==
+postcss-logical@^8.1.0:
+  version "8.1.0"
+  resolved "https://registry.npmjs.org/postcss-logical/-/postcss-logical-8.1.0.tgz"
+  integrity sha512-pL1hXFQ2fEXNKiNiAgtfA005T9FBxky5zkX6s4GZM2D8RkVgRqz3f4g1JUoq925zXv495qk8UNldDwh8uGEDoA==
   dependencies:
     postcss-value-parser "^4.2.0"
 
@@ -7004,12 +7164,12 @@ postcss-modules-values@^4.0.0:
   dependencies:
     icss-utils "^5.0.0"
 
-postcss-nesting@^13.0.1:
-  version "13.0.1"
-  resolved "https://registry.npmjs.org/postcss-nesting/-/postcss-nesting-13.0.1.tgz"
-  integrity sha512-VbqqHkOBOt4Uu3G8Dm8n6lU5+9cJFxiuty9+4rcoyRPO9zZS1JIs6td49VIoix3qYqELHlJIn46Oih9SAKo+yQ==
+postcss-nesting@^13.0.2:
+  version "13.0.2"
+  resolved "https://registry.npmjs.org/postcss-nesting/-/postcss-nesting-13.0.2.tgz"
+  integrity sha512-1YCI290TX+VP0U/K/aFxzHzQWHWURL+CtHMSbex1lCdpXD1SoR2sYuxDu5aNI9lPoXpKTCggFZiDJbwylU0LEQ==
   dependencies:
-    "@csstools/selector-resolve-nested" "^3.0.0"
+    "@csstools/selector-resolve-nested" "^3.1.0"
     "@csstools/selector-specificity" "^5.0.0"
     postcss-selector-parser "^7.0.0"
 
@@ -7107,67 +7267,75 @@ postcss-place@^10.0.0:
   dependencies:
     postcss-value-parser "^4.2.0"
 
-postcss-preset-env@^10.1.0:
-  version "10.1.3"
-  resolved "https://registry.npmjs.org/postcss-preset-env/-/postcss-preset-env-10.1.3.tgz"
-  integrity sha512-9qzVhcMFU/MnwYHyYpJz4JhGku/4+xEiPTmhn0hj3IxnUYlEF9vbh7OC1KoLAnenS6Fgg43TKNp9xcuMeAi4Zw==
-  dependencies:
-    "@csstools/postcss-cascade-layers" "^5.0.1"
-    "@csstools/postcss-color-function" "^4.0.7"
-    "@csstools/postcss-color-mix-function" "^3.0.7"
-    "@csstools/postcss-content-alt-text" "^2.0.4"
-    "@csstools/postcss-exponential-functions" "^2.0.6"
+postcss-preset-env@^10.2.1:
+  version "10.6.1"
+  resolved "https://registry.npmjs.org/postcss-preset-env/-/postcss-preset-env-10.6.1.tgz"
+  integrity sha512-yrk74d9EvY+W7+lO9Aj1QmjWY9q5NsKjK2V9drkOPZB/X6KZ0B3igKsHUYakb7oYVhnioWypQX3xGuePf89f3g==
+  dependencies:
+    "@csstools/postcss-alpha-function" "^1.0.1"
+    "@csstools/postcss-cascade-layers" "^5.0.2"
+    "@csstools/postcss-color-function" "^4.0.12"
+    "@csstools/postcss-color-function-display-p3-linear" "^1.0.1"
+    "@csstools/postcss-color-mix-function" "^3.0.12"
+    "@csstools/postcss-color-mix-variadic-function-arguments" "^1.0.2"
+    "@csstools/postcss-content-alt-text" "^2.0.8"
+    "@csstools/postcss-contrast-color-function" "^2.0.12"
+    "@csstools/postcss-exponential-functions" "^2.0.9"
     "@csstools/postcss-font-format-keywords" "^4.0.0"
-    "@csstools/postcss-gamut-mapping" "^2.0.7"
-    "@csstools/postcss-gradients-interpolation-method" "^5.0.7"
-    "@csstools/postcss-hwb-function" "^4.0.7"
-    "@csstools/postcss-ic-unit" "^4.0.0"
-    "@csstools/postcss-initial" "^2.0.0"
-    "@csstools/postcss-is-pseudo-class" "^5.0.1"
-    "@csstools/postcss-light-dark-function" "^2.0.7"
+    "@csstools/postcss-gamut-mapping" "^2.0.11"
+    "@csstools/postcss-gradients-interpolation-method" "^5.0.12"
+    "@csstools/postcss-hwb-function" "^4.0.12"
+    "@csstools/postcss-ic-unit" "^4.0.4"
+    "@csstools/postcss-initial" "^2.0.1"
+    "@csstools/postcss-is-pseudo-class" "^5.0.3"
+    "@csstools/postcss-light-dark-function" "^2.0.11"
     "@csstools/postcss-logical-float-and-clear" "^3.0.0"
     "@csstools/postcss-logical-overflow" "^2.0.0"
     "@csstools/postcss-logical-overscroll-behavior" "^2.0.0"
     "@csstools/postcss-logical-resize" "^3.0.0"
-    "@csstools/postcss-logical-viewport-units" "^3.0.3"
-    "@csstools/postcss-media-minmax" "^2.0.6"
-    "@csstools/postcss-media-queries-aspect-ratio-number-values" "^3.0.4"
+    "@csstools/postcss-logical-viewport-units" "^3.0.4"
+    "@csstools/postcss-media-minmax" "^2.0.9"
+    "@csstools/postcss-media-queries-aspect-ratio-number-values" "^3.0.5"
     "@csstools/postcss-nested-calc" "^4.0.0"
-    "@csstools/postcss-normalize-display-values" "^4.0.0"
-    "@csstools/postcss-oklab-function" "^4.0.7"
-    "@csstools/postcss-progressive-custom-properties" "^4.0.0"
-    "@csstools/postcss-random-function" "^1.0.2"
-    "@csstools/postcss-relative-color-syntax" "^3.0.7"
+    "@csstools/postcss-normalize-display-values" "^4.0.1"
+    "@csstools/postcss-oklab-function" "^4.0.12"
+    "@csstools/postcss-position-area-property" "^1.0.0"
+    "@csstools/postcss-progressive-custom-properties" "^4.2.1"
+    "@csstools/postcss-property-rule-prelude-list" "^1.0.0"
+    "@csstools/postcss-random-function" "^2.0.1"
+    "@csstools/postcss-relative-color-syntax" "^3.0.12"
     "@csstools/postcss-scope-pseudo-class" "^4.0.1"
-    "@csstools/postcss-sign-functions" "^1.1.1"
-    "@csstools/postcss-stepped-value-functions" "^4.0.6"
-    "@csstools/postcss-text-decoration-shorthand" "^4.0.1"
-    "@csstools/postcss-trigonometric-functions" "^4.0.6"
+    "@csstools/postcss-sign-functions" "^1.1.4"
+    "@csstools/postcss-stepped-value-functions" "^4.0.9"
+    "@csstools/postcss-syntax-descriptor-syntax-production" "^1.0.1"
+    "@csstools/postcss-system-ui-font-family" "^1.0.0"
+    "@csstools/postcss-text-decoration-shorthand" "^4.0.3"
+    "@csstools/postcss-trigonometric-functions" "^4.0.9"
     "@csstools/postcss-unset-value" "^4.0.0"
-    autoprefixer "^10.4.19"
-    browserslist "^4.23.1"
+    autoprefixer "^10.4.23"
+    browserslist "^4.28.1"
     css-blank-pseudo "^7.0.1"
-    css-has-pseudo "^7.0.2"
+    css-has-pseudo "^7.0.3"
     css-prefers-color-scheme "^10.0.0"
-    cssdb "^8.2.3"
+    cssdb "^8.6.0"
     postcss-attribute-case-insensitive "^7.0.1"
     postcss-clamp "^4.1.0"
-    postcss-color-functional-notation "^7.0.7"
+    postcss-color-functional-notation "^7.0.12"
     postcss-color-hex-alpha "^10.0.0"
     postcss-color-rebeccapurple "^10.0.0"
-    postcss-custom-media "^11.0.5"
-    postcss-custom-properties "^14.0.4"
-    postcss-custom-selectors "^8.0.4"
+    postcss-custom-media "^11.0.6"
+    postcss-custom-properties "^14.0.6"
+    postcss-custom-selectors "^8.0.5"
     postcss-dir-pseudo-class "^9.0.1"
-    postcss-double-position-gradients "^6.0.0"
+    postcss-double-position-gradients "^6.0.4"
     postcss-focus-visible "^10.0.1"
     postcss-focus-within "^9.0.1"
     postcss-font-variant "^5.0.0"
     postcss-gap-properties "^6.0.0"
     postcss-image-set-function "^7.0.0"
-    postcss-lab-function "^7.0.7"
-    postcss-logical "^8.0.0"
-    postcss-nesting "^13.0.1"
+    postcss-lab-function "^7.0.12"
+    postcss-logical "^8.1.0"
+    postcss-nesting "^13.0.2"
     postcss-opacity-percentage "^3.0.0"
     postcss-overflow-shorthand "^6.0.0"
     postcss-page-break "^3.0.4"
@@ -7217,15 +7385,7 @@ postcss-selector-not@^8.0.1:
   dependencies:
     postcss-selector-parser "^7.0.0"
 
-postcss-selector-parser@^6.0.11:
-  version "6.1.2"
-  resolved "https://registry.npmjs.org/postcss-selector-parser/-/postcss-selector-parser-6.1.2.tgz"
-  integrity sha512-Q8qQfPiZ+THO/3ZrOrO0cJJKfpYCagtMUkXbnEfmgUjwXg6z/WBeOyS9APBBPCTSiDV+s4SwQGu8yFsiMRIudg==
-  dependencies:
-    cssesc "^3.0.0"
-    util-deprecate "^1.0.2"
-
-postcss-selector-parser@^6.0.16:
+postcss-selector-parser@^6.0.11, postcss-selector-parser@^6.0.16:
   version "6.1.2"
   resolved "https://registry.npmjs.org/postcss-selector-parser/-/postcss-selector-parser-6.1.2.tgz"
   integrity sha512-Q8qQfPiZ+THO/3ZrOrO0cJJKfpYCagtMUkXbnEfmgUjwXg6z/WBeOyS9APBBPCTSiDV+s4SwQGu8yFsiMRIudg==
@@ -7234,9 +7394,9 @@ postcss-selector-parser@^6.0.16:
     util-deprecate "^1.0.2"
 
 postcss-selector-parser@^7.0.0:
-  version "7.0.0"
-  resolved "https://registry.npmjs.org/postcss-selector-parser/-/postcss-selector-parser-7.0.0.tgz"
-  integrity sha512-9RbEr1Y7FFfptd/1eEdntyjMwLeghW1bHX9GWjXo19vx4ytPQhANltvVxDggzJl7mnWM+dX28kb6cyS/4iQjlQ==
+  version "7.1.1"
+  resolved "https://registry.npmjs.org/postcss-selector-parser/-/postcss-selector-parser-7.1.1.tgz"
+  integrity sha512-orRsuYpJVw8LdAwqqLykBj9ecS5/cRHlI5+nvTo8LcCKmzDmqVORXtOIYEEQuL9D4BxtA1lm5isAqzQZCoQ6Eg==
   dependencies:
     cssesc "^3.0.0"
     util-deprecate "^1.0.2"
@@ -7273,12 +7433,12 @@ postcss-zindex@^6.0.2:
   resolved "https://registry.npmjs.org/postcss-zindex/-/postcss-zindex-6.0.2.tgz"
   integrity sha512-5BxW9l1evPB/4ZIc+2GobEBoKC+h8gPGCMi+jxsYvd2x0mjq7wazk6DrP71pStqxE9Foxh5TVnonbWpFZzXaYg==
 
-"postcss@^7.0.0 || ^8.0.1", postcss@^8, postcss@^8.0.3, postcss@^8.0.9, postcss@^8.1.0, postcss@^8.2.2, postcss@^8.4, postcss@^8.4.21, postcss@^8.4.23, postcss@^8.4.24, postcss@^8.4.26, postcss@^8.4.31, postcss@^8.4.33, postcss@^8.4.38, postcss@^8.4.6:
-  version "8.5.1"
-  resolved "https://registry.npmjs.org/postcss/-/postcss-8.5.1.tgz"
-  integrity sha512-6oz2beyjc5VMn/KV1pPw8fliQkhBXrVn1Z3TVyqZxU8kZpzEKhBdmCFqI6ZbmGtamQvQGuU1sgPTk8ZrXDD7jQ==
+"postcss@^7.0.0 || ^8.0.1", postcss@^8, postcss@^8.0.3, postcss@^8.0.9, postcss@^8.1.0, postcss@^8.2.2, postcss@^8.4, postcss@^8.4.21, postcss@^8.4.23, postcss@^8.4.24, postcss@^8.4.31, postcss@^8.4.33, postcss@^8.4.6, postcss@^8.5.4:
+  version "8.5.6"
+  resolved "https://registry.npmjs.org/postcss/-/postcss-8.5.6.tgz"
+  integrity sha512-3Ybi1tAuwAP9s0r1UQ2J4n5Y0G05bJkpUIO0/bI9MhwmD70S5aTWbXGBwxHrelT+XM1k6dM0pk+SwNkpTRN7Pg==
   dependencies:
-    nanoid "^3.3.8"
+    nanoid "^3.3.11"
     picocolors "^1.1.1"
     source-map-js "^1.2.1"
 
@@ -7309,9 +7469,9 @@ prism-react-renderer@^2.3.0:
     clsx "^2.0.0"
 
 prismjs@^1.29.0:
-  version "1.29.0"
-  resolved "https://registry.npmjs.org/prismjs/-/prismjs-1.29.0.tgz"
-  integrity sha512-Kx/1w86q/epKcmte75LNrEoT+lX8pBpavuAbvJWRXar7Hz8jrtF+e3vY751p0R8H9HdArwaCTNDDzHg/ScJK1Q==
+  version "1.30.0"
+  resolved "https://registry.npmjs.org/prismjs/-/prismjs-1.30.0.tgz"
+  integrity sha512-DEvV2ZF2r2/63V+tK8hQvrR2ZGn10srHbXviTlcv7Kpzw8jWiNTqbVgjO3IY8RxrrOUF8VPMQQFysYYYv0YZxw==
 
 process-nextick-args@~2.0.0:
   version "2.0.1"
@@ -7340,6 +7500,11 @@ property-information@^6.0.0:
   resolved "https://registry.npmjs.org/property-information/-/property-information-6.5.0.tgz"
   integrity sha512-PgTgs/BlvHxOu8QuEN7wi5A0OmXaBcHpmCSTehcs6Uuu9IkDIEo13Hy7n898RHfrQ49vKCoGeWZSaAK01nwVig==
 
+property-information@^7.0.0:
+  version "7.1.0"
+  resolved "https://registry.npmjs.org/property-information/-/property-information-7.1.0.tgz"
+  integrity sha512-TwEZ+X+yCJmYfL7TPUOcvBZ4QfoT5YenQiJuX//0th53DE6w0xxLEtfK3iyryQFddXuvkIk51EEgrJQ0WJkOmQ==
+
 proto-list@~1.2.1:
   version "1.2.4"
   resolved "https://registry.npmjs.org/proto-list/-/proto-list-1.2.4.tgz"
@@ -7365,25 +7530,30 @@ pupa@^3.1.0:
   dependencies:
     escape-goat "^4.0.0"
 
-qs@6.13.0:
-  version "6.13.0"
-  resolved "https://registry.npmjs.org/qs/-/qs-6.13.0.tgz"
-  integrity sha512-+38qI9SOr8tfZ4QmJNplMUxqjbe7LKvvZgWdExBOmd+egZTtjLB67Gu0HRX3u/XOq7UU2Nx6nsjvS16Z9uwfpg==
+pvtsutils@^1.3.6:
+  version "1.3.6"
+  resolved "https://registry.npmjs.org/pvtsutils/-/pvtsutils-1.3.6.tgz"
+  integrity sha512-PLgQXQ6H2FWCaeRak8vvk1GW462lMxB5s3Jm673N82zI4vqtVUPuZdffdZbPDFRoU8kAhItWFtPCWiPpp4/EDg==
+  dependencies:
+    tslib "^2.8.1"
+
+pvutils@^1.1.3:
+  version "1.1.5"
+  resolved "https://registry.npmjs.org/pvutils/-/pvutils-1.1.5.tgz"
+  integrity sha512-KTqnxsgGiQ6ZAzZCVlJH5eOjSnvlyEgx1m8bkRJfOhmGRqfo5KLvmAlACQkrjEtOQ4B7wF9TdSLIs9O90MX9xA==
+
+qs@~6.14.0:
+  version "6.14.1"
+  resolved "https://registry.npmjs.org/qs/-/qs-6.14.1.tgz"
+  integrity sha512-4EK3+xJl8Ts67nLYNwqw/dsFVnCf+qR7RgXSK9jEEm9unao3njwMDdmsdvoKBKHzxd7tCYz5e5M+SnMjdtXGQQ==
   dependencies:
-    side-channel "^1.0.6"
+    side-channel "^1.1.0"
 
 queue-microtask@^1.2.2:
   version "1.2.3"
   resolved "https://registry.npmjs.org/queue-microtask/-/queue-microtask-1.2.3.tgz"
   integrity sha512-NuaNSa6flKT5JaSYQzJok04JzTL1CA6aGhv5rfLW3PgqA+M2ChpZQnAC8h8i4ZFkBS8X5RqkDBHA7r4hej3K9A==
 
-queue@6.0.2:
-  version "6.0.2"
-  resolved "https://registry.npmjs.org/queue/-/queue-6.0.2.tgz"
-  integrity sha512-iHZWu+q3IdFZFX36ro/lKBkSvfkztY5Y7HMiPlOUjhupPcG2JMfst2KKEpu5XndviX/3UhFbRngUPNKtgvtZiA==
-  dependencies:
-    inherits "~2.0.3"
-
 quick-lru@^5.1.1:
   version "5.1.1"
   resolved "https://registry.npmjs.org/quick-lru/-/quick-lru-5.1.1.tgz"
@@ -7406,15 +7576,15 @@ range-parser@1.2.0:
   resolved "https://registry.npmjs.org/range-parser/-/range-parser-1.2.0.tgz"
   integrity sha512-kA5WQoNVo4t9lNx2kQNFCxKeBl5IbbSNBl1M/tLkw9WCn+hxNBAW5Qh8gdhs63CJnhjJ2zQWFoqPJP2sK1AV5A==
 
-raw-body@2.5.2:
-  version "2.5.2"
-  resolved "https://registry.npmjs.org/raw-body/-/raw-body-2.5.2.tgz"
-  integrity sha512-8zGqypfENjCIqGhgXToC8aB2r7YrBX+AQAfIPs/Mlk+BtPTztOvTS01NRW/3Eh60J+a48lt8qsCzirQ6loCVfA==
+raw-body@~2.5.3:
+  version "2.5.3"
+  resolved "https://registry.npmjs.org/raw-body/-/raw-body-2.5.3.tgz"
+  integrity sha512-s4VSOf6yN0rvbRZGxs8Om5CWj6seneMwK3oDb4lWDH0UPhWcxwOWw5+qk24bxq87szX1ydrwylIOp2uG1ojUpA==
   dependencies:
-    bytes "3.1.2"
-    http-errors "2.0.0"
-    iconv-lite "0.4.24"
-    unpipe "1.0.0"
+    bytes "~3.1.2"
+    http-errors "~2.0.1"
+    iconv-lite "~0.4.24"
+    unpipe "~1.0.0"
 
 rc@1.2.8:
   version "1.2.8"
@@ -7426,37 +7596,7 @@ rc@1.2.8:
     minimist "^1.2.0"
     strip-json-comments "~2.0.1"
 
-react-dev-utils@^12.0.1:
-  version "12.0.1"
-  resolved "https://registry.npmjs.org/react-dev-utils/-/react-dev-utils-12.0.1.tgz"
-  integrity sha512-84Ivxmr17KjUupyqzFode6xKhjwuEJDROWKJy/BthkL7Wn6NJ8h4WE6k/exAv6ImS+0oZLRRW5j/aINMHyeGeQ==
-  dependencies:
-    "@babel/code-frame" "^7.16.0"
-    address "^1.1.2"
-    browserslist "^4.18.1"
-    chalk "^4.1.2"
-    cross-spawn "^7.0.3"
-    detect-port-alt "^1.1.6"
-    escape-string-regexp "^4.0.0"
-    filesize "^8.0.6"
-    find-up "^5.0.0"
-    fork-ts-checker-webpack-plugin "^6.5.0"
-    global-modules "^2.0.0"
-    globby "^11.0.4"
-    gzip-size "^6.0.0"
-    immer "^9.0.7"
-    is-root "^2.1.0"
-    loader-utils "^3.2.0"
-    open "^8.4.0"
-    pkg-up "^3.1.0"
-    prompts "^2.4.2"
-    react-error-overlay "^6.0.11"
-    recursive-readdir "^2.2.2"
-    shell-quote "^1.7.3"
-    strip-ansi "^6.0.1"
-    text-table "^0.2.0"
-
-react-dom@*, "react-dom@^16.6.0 || ^17.0.0 || ^18.0.0 || ^19.0.0", "react-dom@^18.0.0 || ^19.0.0", react-dom@^18.2.0, "react-dom@>= 16.8.0 < 19.0.0":
+react-dom@*, "react-dom@^16.6.0 || ^17.0.0 || ^18.0.0 || ^19.0.0", "react-dom@^18.0.0 || ^19.0.0", react-dom@^18.2.0, "react-dom@>= 16.8.0 < 20.0.0":
   version "18.3.1"
   resolved "https://registry.npmjs.org/react-dom/-/react-dom-18.3.1.tgz"
   integrity sha512-5m4nQKp+rZRb09LNH59GM4BxTh9251/ylbKIbpe7TpGxfJ+9kv6BLkLBXIjjspbgbnIBNqlI23tRnTWT0snUIw==
@@ -7464,17 +7604,12 @@ react-dom@*, "react-dom@^16.6.0 || ^17.0.0 || ^18.0.0 || ^19.0.0", "react-dom@^1
     loose-envify "^1.1.0"
     scheduler "^0.23.2"
 
-react-error-overlay@^6.0.11:
-  version "6.0.11"
-  resolved "https://registry.npmjs.org/react-error-overlay/-/react-error-overlay-6.0.11.tgz"
-  integrity sha512-/6UZ2qgEyH2aqzYZgQPxEnz33NJ2gNsnHA2o5+o4wW9bLM/JYQitNP9xPhsXwC08hMMovfGe/8retsdDsczPRg==
-
 react-fast-compare@^3.2.0:
   version "3.2.2"
   resolved "https://registry.npmjs.org/react-fast-compare/-/react-fast-compare-3.2.2.tgz"
   integrity sha512-nsO+KSNgo1SbJqJEYRE9ERzo7YtYbou/OqjSQKxV7jcKox7+usiUVZOAC+XnDOABXggQTno0Y1CpVnuWEc1boQ==
 
-"react-helmet-async@npm:@slorber/react-helmet-async@*", "react-helmet-async@npm:@slorber/react-helmet-async@1.3.0":
+"react-helmet-async@npm:@slorber/react-helmet-async@1.3.0":
   version "1.3.0"
   resolved "https://registry.npmjs.org/@slorber/react-helmet-async/-/react-helmet-async-1.3.0.tgz"
   integrity sha512-e9/OK8VhwUSc67diWI8Rb3I0YgI9/SBQtnhe9aEuK6MhZm7ntZZimXgwXnd8W96YTmSOb9M4d8LwhRZyhWr/1A==
@@ -7490,10 +7625,10 @@ react-is@^16.13.1, react-is@^16.6.0, react-is@^16.7.0:
   resolved "https://registry.npmjs.org/react-is/-/react-is-16.13.1.tgz"
   integrity sha512-24e6ynE2H+OKt4kqsOvNd8kBpV65zoxbA4BVsEOB3ARVWQki/DHzaUoC5KuON/BiccDaCCTZBuOcfZs70kR8bQ==
 
-react-json-view-lite@^1.2.0:
-  version "1.5.0"
-  resolved "https://registry.npmjs.org/react-json-view-lite/-/react-json-view-lite-1.5.0.tgz"
-  integrity sha512-nWqA1E4jKPklL2jvHWs6s+7Na0qNgw9HCP6xehdQJeg6nPBTFZgGwyko9Q0oj+jQWKTTVRS30u0toM5wiuL3iw==
+react-json-view-lite@^2.3.0:
+  version "2.5.0"
+  resolved "https://registry.npmjs.org/react-json-view-lite/-/react-json-view-lite-2.5.0.tgz"
+  integrity sha512-tk7o7QG9oYyELWHL8xiMQ8x4WzjCzbWNyig3uexmkLb54r8jO0yH3WCWx8UZS0c49eSA4QUmG5caiRJ8fAn58g==
 
 react-loadable-ssr-addon-v5-slorber@^1.0.1:
   version "1.0.1"
@@ -7544,7 +7679,7 @@ react-router@^5.3.4, react-router@>=5, react-router@5.3.4:
     tiny-invariant "^1.0.2"
     tiny-warning "^1.0.0"
 
-react@*, "react@^16.13.1 || ^17.0.0 || ^18.0.0", "react@^16.6.0 || ^17.0.0 || ^18.0.0 || ^19.0.0", "react@^18.0.0 || ^19.0.0", react@^18.2.0, react@^18.3.1, "react@>= 16.8.0 < 19.0.0", react@>=0.14.9, react@>=15, react@>=16, react@>=16.0.0:
+react@*, "react@^16.11.0 || ^17.0.0 || ^18.0.0 || ^19.0.0", "react@^16.6.0 || ^17.0.0 || ^18.0.0 || ^19.0.0", "react@^16.8.0 || ^17.0.0 || ^18.0.0 || ^19.0.0", "react@^18 || ~19.0.1 || ~19.1.2 || ^19.2.1", "react@^18.0.0 || ^19.0.0", react@^18.2.0, react@^18.3.1, "react@>= 16.8.0 < 20.0.0", react@>=0.14.9, react@>=15, react@>=16, react@>=16.0.0:
   version "18.3.1"
   resolved "https://registry.npmjs.org/react/-/react-18.3.1.tgz"
   integrity sha512-wS+hAgJShR0KhEvPJArfuPVN1+Hz1t0Y6n5jLrGQbkb4urgPE/0Rve+1kMB1v/oWgHgm4WIcV+i7F2pTVj+2iQ==
@@ -7580,18 +7715,6 @@ readdirp@~3.6.0:
   dependencies:
     picomatch "^2.2.1"
 
-reading-time@^1.5.0:
-  version "1.5.0"
-  resolved "https://registry.npmjs.org/reading-time/-/reading-time-1.5.0.tgz"
-  integrity sha512-onYyVhBNr4CmAxFsKS7bz+uTLRakypIe4R+5A824vBSkQy/hB3fZepoVEf8OVAxzLvK+H/jm9TzpI3ETSm64Kg==
-
-rechoir@^0.6.2:
-  version "0.6.2"
-  resolved "https://registry.npmjs.org/rechoir/-/rechoir-0.6.2.tgz"
-  integrity sha512-HFM8rkZ+i3zrV+4LQjwQ0W+ez98pApMGM3HUrN04j3CqzPOzl9nmP15Y8YXNm8QHGv/eacOVEjqhmWpkRV0NAw==
-  dependencies:
-    resolve "^1.1.6"
-
 recma-build-jsx@^1.0.0:
   version "1.0.0"
   resolved "https://registry.npmjs.org/recma-build-jsx/-/recma-build-jsx-1.0.0.tgz"
@@ -7632,17 +7755,15 @@ recma-stringify@^1.0.0:
     unified "^11.0.0"
     vfile "^6.0.0"
 
-recursive-readdir@^2.2.2:
-  version "2.2.3"
-  resolved "https://registry.npmjs.org/recursive-readdir/-/recursive-readdir-2.2.3.tgz"
-  integrity sha512-8HrF5ZsXk5FAH9dgsx3BlUer73nIhuj+9OrQwEbLTPOBzGkL1lsFCR01am+v+0m2Cmbs1nP12hLDl5FA7EszKA==
-  dependencies:
-    minimatch "^3.0.5"
+reflect-metadata@^0.2.2:
+  version "0.2.2"
+  resolved "https://registry.npmjs.org/reflect-metadata/-/reflect-metadata-0.2.2.tgz"
+  integrity sha512-urBwgfrvVP/eAyXx4hluJivBKzuEbSQs9rKWCrCkbSxNv8mxPcUZKeuoF3Uy4mJl3Lwprp6yy5/39VWigZ4K6Q==
 
-regenerate-unicode-properties@^10.2.0:
-  version "10.2.0"
-  resolved "https://registry.npmjs.org/regenerate-unicode-properties/-/regenerate-unicode-properties-10.2.0.tgz"
-  integrity sha512-DqHn3DwbmmPVzeKj9woBadqmXxLvQoQIwu7nopMc72ztvxVmVk2SBhSnx67zuye5TP+lJsb/TBQsjLKhnDf3MA==
+regenerate-unicode-properties@^10.2.2:
+  version "10.2.2"
+  resolved "https://registry.npmjs.org/regenerate-unicode-properties/-/regenerate-unicode-properties-10.2.2.tgz"
+  integrity sha512-m03P+zhBeQd1RGnYxrGyDAPpWX/epKirLrp8e3qevZdVkKtnCrjjWczIbYc8+xd6vcTStVlqfycTx1KR4LOr0g==
   dependencies:
     regenerate "^1.4.2"
 
@@ -7651,29 +7772,17 @@ regenerate@^1.4.2:
   resolved "https://registry.npmjs.org/regenerate/-/regenerate-1.4.2.tgz"
   integrity sha512-zrceR/XhGYU/d/opr2EKO7aRHUeiBI8qjtfHqADTwZd6Szfy16la6kqD0MIUs5z5hx6AaKa+PixpPrR289+I0A==
 
-regenerator-runtime@^0.14.0:
-  version "0.14.1"
-  resolved "https://registry.npmjs.org/regenerator-runtime/-/regenerator-runtime-0.14.1.tgz"
-  integrity sha512-dYnhHh0nJoMfnkZs6GmmhFknAGRrLznOu5nc9ML+EJxGvrx6H7teuevqVqCuPcPK//3eDrrjQhehXVx9cnkGdw==
-
-regenerator-transform@^0.15.2:
-  version "0.15.2"
-  resolved "https://registry.npmjs.org/regenerator-transform/-/regenerator-transform-0.15.2.tgz"
-  integrity sha512-hfMp2BoF0qOk3uc5V20ALGDS2ddjQaLrdl7xrGXvAIow7qeWRM2VA2HuCHkUKk9slq3VwEwLNK3DFBqDfPGYtg==
-  dependencies:
-    "@babel/runtime" "^7.8.4"
-
-regexpu-core@^6.2.0:
-  version "6.2.0"
-  resolved "https://registry.npmjs.org/regexpu-core/-/regexpu-core-6.2.0.tgz"
-  integrity sha512-H66BPQMrv+V16t8xtmq+UC0CBpiTBA60V8ibS1QVReIp8T1z8hwFxqcGzm9K6lgsN7sB5edVH8a+ze6Fqm4weA==
+regexpu-core@^6.3.1:
+  version "6.4.0"
+  resolved "https://registry.npmjs.org/regexpu-core/-/regexpu-core-6.4.0.tgz"
+  integrity sha512-0ghuzq67LI9bLXpOX/ISfve/Mq33a4aFRzoQYhnnok1JOFpmE/A2TBGkNVenOGEeSBCjIiWcc6MVOG5HEQv0sA==
   dependencies:
     regenerate "^1.4.2"
-    regenerate-unicode-properties "^10.2.0"
+    regenerate-unicode-properties "^10.2.2"
     regjsgen "^0.8.0"
-    regjsparser "^0.12.0"
+    regjsparser "^0.13.0"
     unicode-match-property-ecmascript "^2.0.0"
-    unicode-match-property-value-ecmascript "^2.1.0"
+    unicode-match-property-value-ecmascript "^2.2.1"
 
 registry-auth-token@^5.0.1:
   version "5.0.3"
@@ -7694,12 +7803,12 @@ regjsgen@^0.8.0:
   resolved "https://registry.npmjs.org/regjsgen/-/regjsgen-0.8.0.tgz"
   integrity sha512-RvwtGe3d7LvWiDQXeQw8p5asZUmfU1G/l6WbUXeHta7Y2PEIvBTwH6E2EfmYUK8pxcxEdEmaomqyp0vZZ7C+3Q==
 
-regjsparser@^0.12.0:
-  version "0.12.0"
-  resolved "https://registry.npmjs.org/regjsparser/-/regjsparser-0.12.0.tgz"
-  integrity sha512-cnE+y8bz4NhMjISKbgeVJtqNbtf5QpjZP+Bslo+UqkIt9QPnX9q095eiRRASJG1/tz6dlNr6Z5NsBiWYokp6EQ==
+regjsparser@^0.13.0:
+  version "0.13.0"
+  resolved "https://registry.npmjs.org/regjsparser/-/regjsparser-0.13.0.tgz"
+  integrity sha512-NZQZdC5wOE/H3UT28fVGL+ikOZcEzfMGk/c3iN9UGxzWHMa1op7274oyiUVrAG4B2EuFhus8SvkaYnhvW92p9Q==
   dependencies:
-    jsesc "~3.0.2"
+    jsesc "~3.1.0"
 
 rehype-raw@^7.0.0:
   version "7.0.0"
@@ -7725,9 +7834,9 @@ relateurl@^0.2.7:
   integrity sha512-G08Dxvm4iDN3MLM0EsP62EDV9IuhXPR6blNz6Utcp7zyV3tr4HVNINt6MpaRWbxoOHT3Q7YN2P+jaHX8vUbgog==
 
 remark-directive@^3.0.0:
-  version "3.0.0"
-  resolved "https://registry.npmjs.org/remark-directive/-/remark-directive-3.0.0.tgz"
-  integrity sha512-l1UyWJ6Eg1VPU7Hm/9tt0zKtReJQNOA4+iDMAxTyZNWnJnFlbS/7zhiel/rogTLQ2vMYwDzSJa4BiVNqGlqIMA==
+  version "3.0.1"
+  resolved "https://registry.npmjs.org/remark-directive/-/remark-directive-3.0.1.tgz"
+  integrity sha512-gwglrEQEZcZYgVyG1tQuA+h58EZfq5CSULw7J90AFuCTyib1thgHPoqQ+h9iFvU6R+vnZ5oNFQR5QKgGpk741A==
   dependencies:
     "@types/mdast" "^4.0.0"
     mdast-util-directive "^3.0.0"
@@ -7756,9 +7865,9 @@ remark-frontmatter@^5.0.0:
     unified "^11.0.0"
 
 remark-gfm@^4.0.0:
-  version "4.0.0"
-  resolved "https://registry.npmjs.org/remark-gfm/-/remark-gfm-4.0.0.tgz"
-  integrity sha512-U92vJgBPkbw4Zfu/IiW2oTZLSL3Zpv+uI7My2eq8JxKgqraFdU8YUGicEJCEgSbeaG+QDFqIcwwfMTOEelPxuA==
+  version "4.0.1"
+  resolved "https://registry.npmjs.org/remark-gfm/-/remark-gfm-4.0.1.tgz"
+  integrity sha512-1quofZ2RQ9EWdeN34S79+KExV1764+wCUGop5CPL1WGdD0ocPpu91lzPGbwWMECpEpd42kJGQwzRfyov9j4yNg==
   dependencies:
     "@types/mdast" "^4.0.0"
     mdast-util-gfm "^3.0.0"
@@ -7851,12 +7960,12 @@ resolve-pathname@^3.0.0:
   resolved "https://registry.npmjs.org/resolve-pathname/-/resolve-pathname-3.0.0.tgz"
   integrity sha512-C7rARubxI8bXFNB/hqcp/4iUeIXJhJZvFPFPiSPRnhU5UPxzMFIl+2E6yY6c4k9giDJAhtV+enfA+G89N6Csng==
 
-resolve@^1.1.6, resolve@^1.14.2:
-  version "1.22.10"
-  resolved "https://registry.npmjs.org/resolve/-/resolve-1.22.10.tgz"
-  integrity sha512-NPRy+/ncIMeDlTAsuqwKIiferiawhefFJtkNSW0qZJEqMEb+qBt/77B/jGeeek+F0uOeN05CDa6HXbbIgtVX4w==
+resolve@^1.22.10:
+  version "1.22.11"
+  resolved "https://registry.npmjs.org/resolve/-/resolve-1.22.11.tgz"
+  integrity sha512-RfqAvLnMl313r7c9oclB1HhUEAezcpLjz95wFH4LVuhk9JF/r22qmVP9AMmOU4vMX7Q8pN8jwNg/CSpdFnMjTQ==
   dependencies:
-    is-core-module "^2.16.0"
+    is-core-module "^2.16.1"
     path-parse "^1.0.7"
     supports-preserve-symlinks-flag "^1.0.0"
 
@@ -7873,16 +7982,9 @@ retry@^0.13.1:
   integrity sha512-XQBQ3I8W1Cge0Seh+6gjj03LbmRFWuoszgK9ooCpwYIrhhoO80pfq4cUkU5DkknwfOfFteRwlZ56PYOGYyFWdg==
 
 reusify@^1.0.4:
-  version "1.0.4"
-  resolved "https://registry.npmjs.org/reusify/-/reusify-1.0.4.tgz"
-  integrity sha512-U9nH88a3fc/ekCF1l0/UP1IosiuIjyTh7hBvXVMHYgVcfGvt897Xguj2UOLDeI5BG2m7/uwyaLVT6fbtCwTyzw==
-
-rimraf@^3.0.2:
-  version "3.0.2"
-  resolved "https://registry.npmjs.org/rimraf/-/rimraf-3.0.2.tgz"
-  integrity sha512-JZkJMZkAGFFPP2YqXZXPbMlMBgsxzE8ILs4lMIX/2o0L9UBw9O/Y3o6wFw/i9YLapcUJWwqbi3kdxIPdC62TIA==
-  dependencies:
-    glob "^7.1.3"
+  version "1.1.0"
+  resolved "https://registry.npmjs.org/reusify/-/reusify-1.1.0.tgz"
+  integrity sha512-g6QUff04oZpHs0eG5p83rFLhHeV00ug/Yf9nZM6fLeUrPguBTkTQOdpAWWspMh55TZfVQDPaN3NQJfbVRAxdIw==
 
 rtlcss@^4.1.0:
   version "4.3.0"
@@ -7894,6 +7996,11 @@ rtlcss@^4.1.0:
     postcss "^8.4.21"
     strip-json-comments "^3.1.1"
 
+run-applescript@^7.0.0:
+  version "7.1.0"
+  resolved "https://registry.npmjs.org/run-applescript/-/run-applescript-7.1.0.tgz"
+  integrity sha512-DPe5pVFaAsinSaV6QjQ6gdiedWDcRCbUuiQfQa2wmWV7+xC9bGulGI8+TdRmoFkAPaBXk8CrAbnlY2ISniJ47Q==
+
 run-parallel@^1.1.9:
   version "1.2.0"
   resolved "https://registry.npmjs.org/run-parallel/-/run-parallel-1.2.0.tgz"
@@ -7917,9 +8024,9 @@ safe-buffer@~5.1.0, safe-buffer@~5.1.1:
   integrity sha512-YZo3K82SD7Riyi0E1EQPojLz7kpepnSQI9IyPbHHg1XXXevb5dJI7tpyN2ADxGcQbHG7vcyRHk0cbwqcQriUtg==
 
 sax@^1.2.4:
-  version "1.4.1"
-  resolved "https://registry.npmjs.org/sax/-/sax-1.4.1.tgz"
-  integrity sha512-+aWOz7yVScEGoKNd4PA10LZ8sk0A/z5+nXQG5giUO5rprX9jgYsTdov9qCchZiPIZezbZH+jRut8nPodFAX4Jg==
+  version "1.4.4"
+  resolved "https://registry.npmjs.org/sax/-/sax-1.4.4.tgz"
+  integrity sha512-1n3r/tGXO6b6VXMdFT54SHzT9ytu9yr7TaELowdYpMqY/Ao7EnlQGmAQ1+RatX7Tkkdm6hONI2owqNx2aZj5Sw==
 
 scheduler@^0.23.2:
   version "0.23.2"
@@ -7928,6 +8035,11 @@ scheduler@^0.23.2:
   dependencies:
     loose-envify "^1.1.0"
 
+schema-dts@^1.1.2:
+  version "1.1.5"
+  resolved "https://registry.npmjs.org/schema-dts/-/schema-dts-1.1.5.tgz"
+  integrity sha512-RJr9EaCmsLzBX2NDiO5Z3ux2BVosNZN5jo0gWgsyKvxKIUL5R3swNvoorulAeL9kLB0iTSX7V6aokhla2m7xbg==
+
 schema-utils@^3.0.0:
   version "3.3.0"
   resolved "https://registry.npmjs.org/schema-utils/-/schema-utils-3.3.0.tgz"
@@ -7946,7 +8058,7 @@ schema-utils@^3.2.0:
     ajv "^6.12.5"
     ajv-keywords "^3.5.2"
 
-schema-utils@^4.0.0, schema-utils@^4.0.1, schema-utils@^4.3.0:
+schema-utils@^4.0.0, schema-utils@^4.0.1, schema-utils@^4.2.0, schema-utils@^4.3.0:
   version "4.3.0"
   resolved "https://registry.npmjs.org/schema-utils/-/schema-utils-4.3.0.tgz"
   integrity sha512-Gf9qqc58SpCA/xdziiHz35F4GNIWYWZrEshUc/G/r5BnLph6xpKuLeoJoQuj5WfBIx/eQLf+hmVPYHaxJu7V2g==
@@ -7956,15 +8068,6 @@ schema-utils@^4.0.0, schema-utils@^4.0.1, schema-utils@^4.3.0:
     ajv-formats "^2.1.1"
     ajv-keywords "^5.1.0"
 
-schema-utils@2.7.0:
-  version "2.7.0"
-  resolved "https://registry.npmjs.org/schema-utils/-/schema-utils-2.7.0.tgz"
-  integrity sha512-0ilKFI6QQF5nxDZLFn2dMjvc4hjg/Wkg7rHd3jK6/A4a1Hl9VFdQWvgB1UMGoU94pad1P/8N7fMcEnLnSiju8A==
-  dependencies:
-    "@types/json-schema" "^7.0.4"
-    ajv "^6.12.2"
-    ajv-keywords "^3.4.1"
-
 "search-insights@>= 1 < 3":
   version "2.17.3"
   resolved "https://registry.npmjs.org/search-insights/-/search-insights-2.17.3.tgz"
@@ -7983,13 +8086,13 @@ select-hose@^2.0.0:
   resolved "https://registry.npmjs.org/select-hose/-/select-hose-2.0.0.tgz"
   integrity sha512-mEugaLK+YfkijB4fx0e6kImuJdCIt2LxCRcbEYPqRGCs4F2ogyfZU5IAZRdjCP8JPq2AtdNoC/Dux63d9Kiryg==
 
-selfsigned@^2.1.1:
-  version "2.4.1"
-  resolved "https://registry.npmjs.org/selfsigned/-/selfsigned-2.4.1.tgz"
-  integrity sha512-th5B4L2U+eGLq1TVh7zNRGBapioSORUeymIydxgFpwww9d2qyKvtuPU2jJuHvYAwwqi2Y596QBL3eEqcPEYL8Q==
+selfsigned@^5.5.0:
+  version "5.5.0"
+  resolved "https://registry.npmjs.org/selfsigned/-/selfsigned-5.5.0.tgz"
+  integrity sha512-ftnu3TW4+3eBfLRFnDEkzGxSF/10BJBkaLJuBHZX0kiPS7bRdlpZGu6YGt4KngMkdTwJE6MbjavFpqHvqVt+Ew==
   dependencies:
-    "@types/node-forge" "^1.3.0"
-    node-forge "^1"
+    "@peculiar/x509" "^1.14.2"
+    pkijs "^3.3.3"
 
 semver-diff@^4.0.0:
   version "4.0.0"
@@ -8003,11 +8106,6 @@ semver@^6.3.1:
   resolved "https://registry.npmjs.org/semver/-/semver-6.3.1.tgz"
   integrity sha512-BR7VvDCVHO+q2xBEWskxS6DJE1qRnb7DxzUrogb71CWoSficBxYsiAGd+Kl0mmq/MprG9yArRkyrQxTO6XjMzA==
 
-semver@^7.3.2:
-  version "7.6.3"
-  resolved "https://registry.npmjs.org/semver/-/semver-7.6.3.tgz"
-  integrity sha512-oVekP1cKtI+CTDvHWYFUcMtsK/00wmAEfyqKfNdARm8u1wNVhSgaX7A8d4UuIlUI5e84iEwOhs7ZPYRmzU9U6A==
-
 semver@^7.3.5:
   version "7.6.3"
   resolved "https://registry.npmjs.org/semver/-/semver-7.6.3.tgz"
@@ -8023,24 +8121,24 @@ semver@^7.5.4:
   resolved "https://registry.npmjs.org/semver/-/semver-7.6.3.tgz"
   integrity sha512-oVekP1cKtI+CTDvHWYFUcMtsK/00wmAEfyqKfNdARm8u1wNVhSgaX7A8d4UuIlUI5e84iEwOhs7ZPYRmzU9U6A==
 
-send@0.19.0:
-  version "0.19.0"
-  resolved "https://registry.npmjs.org/send/-/send-0.19.0.tgz"
-  integrity sha512-dW41u5VfLXu8SJh5bwRmyYUbAoSB3c9uQh6L8h/KtsFREPWpbX1lrljJo186Jc4nmci/sGUZ9a0a0J2zgfq2hw==
+send@~0.19.0, send@~0.19.1:
+  version "0.19.2"
+  resolved "https://registry.npmjs.org/send/-/send-0.19.2.tgz"
+  integrity sha512-VMbMxbDeehAxpOtWJXlcUS5E8iXh6QmN+BkRX1GARS3wRaXEEgzCcB10gTQazO42tpNIya8xIyNx8fll1OFPrg==
   dependencies:
     debug "2.6.9"
     depd "2.0.0"
     destroy "1.2.0"
-    encodeurl "~1.0.2"
+    encodeurl "~2.0.0"
     escape-html "~1.0.3"
     etag "~1.8.1"
-    fresh "0.5.2"
-    http-errors "2.0.0"
+    fresh "~0.5.2"
+    http-errors "~2.0.1"
     mime "1.6.0"
     ms "2.1.3"
-    on-finished "2.4.1"
+    on-finished "~2.4.1"
     range-parser "~1.2.1"
-    statuses "2.0.1"
+    statuses "~2.0.2"
 
 serialize-javascript@^6.0.0, serialize-javascript@^6.0.1, serialize-javascript@^6.0.2:
   version "6.0.2"
@@ -8075,15 +8173,15 @@ serve-index@^1.9.1:
     mime-types "~2.1.17"
     parseurl "~1.3.2"
 
-serve-static@1.16.2:
-  version "1.16.2"
-  resolved "https://registry.npmjs.org/serve-static/-/serve-static-1.16.2.tgz"
-  integrity sha512-VqpjJZKadQB/PEbEwvFdO43Ax5dFBZ2UECszz8bQ7pi7wt//PWe1P6MN7eCnjsatYtBT6EuiClbjSWP2WrIoTw==
+serve-static@~1.16.2:
+  version "1.16.3"
+  resolved "https://registry.npmjs.org/serve-static/-/serve-static-1.16.3.tgz"
+  integrity sha512-x0RTqQel6g5SY7Lg6ZreMmsOzncHFU7nhnRWkKgWuMTu5NN0DR5oruckMqRvacAN9d5w6ARnRBXl9xhDCgfMeA==
   dependencies:
     encodeurl "~2.0.0"
     escape-html "~1.0.3"
     parseurl "~1.3.3"
-    send "0.19.0"
+    send "~0.19.1"
 
 set-function-length@^1.2.2:
   version "1.2.2"
@@ -8097,16 +8195,16 @@ set-function-length@^1.2.2:
     gopd "^1.0.1"
     has-property-descriptors "^1.0.2"
 
+setprototypeof@~1.2.0, setprototypeof@1.2.0:
+  version "1.2.0"
+  resolved "https://registry.npmjs.org/setprototypeof/-/setprototypeof-1.2.0.tgz"
+  integrity sha512-E5LDX7Wrp85Kil5bhZv46j8jOeboKq5JMmYM3gVGdGH8xFpPWXUMsNrlODCrkoxMEeNi/XZIwuRvY4XNwYMJpw==
+
 setprototypeof@1.1.0:
   version "1.1.0"
   resolved "https://registry.npmjs.org/setprototypeof/-/setprototypeof-1.1.0.tgz"
   integrity sha512-BvE/TwpZX4FXExxOxZyRGQQv651MSwmWKZGqvmPcRIjDqWub67kTKuIMx43cZZrS/cBBzwBcNDWoFxt2XEFIpQ==
 
-setprototypeof@1.2.0:
-  version "1.2.0"
-  resolved "https://registry.npmjs.org/setprototypeof/-/setprototypeof-1.2.0.tgz"
-  integrity sha512-E5LDX7Wrp85Kil5bhZv46j8jOeboKq5JMmYM3gVGdGH8xFpPWXUMsNrlODCrkoxMEeNi/XZIwuRvY4XNwYMJpw==
-
 shallow-clone@^3.0.0:
   version "3.0.1"
   resolved "https://registry.npmjs.org/shallow-clone/-/shallow-clone-3.0.1.tgz"
@@ -8131,19 +8229,10 @@ shebang-regex@^3.0.0:
   resolved "https://registry.npmjs.org/shebang-regex/-/shebang-regex-3.0.0.tgz"
   integrity sha512-7++dFhtcx3353uBaq8DDR4NuxBetBzC7ZQOhmTQInHEd6bSrXdiEyzCvG07Z44UYdLShWUyXt5M/yhz8ekcb1A==
 
-shell-quote@^1.7.3, shell-quote@^1.8.1:
-  version "1.8.2"
-  resolved "https://registry.npmjs.org/shell-quote/-/shell-quote-1.8.2.tgz"
-  integrity sha512-AzqKpGKjrj7EM6rKVQEPpB288oCfnrEIuyoT9cyF4nmGa7V8Zk6f7RRqYisX8X9m+Q7bd632aZW4ky7EhbQztA==
-
-shelljs@^0.8.5:
-  version "0.8.5"
-  resolved "https://registry.npmjs.org/shelljs/-/shelljs-0.8.5.tgz"
-  integrity sha512-TiwcRcrkhHvbrZbnRcFYMLl30Dfov3HKqzp5tO5b4pt6G/SezKcYhmDg15zXVBswHmctSAQKznqNW2LO5tTDow==
-  dependencies:
-    glob "^7.0.0"
-    interpret "^1.0.0"
-    rechoir "^0.6.2"
+shell-quote@^1.8.3:
+  version "1.8.3"
+  resolved "https://registry.npmjs.org/shell-quote/-/shell-quote-1.8.3.tgz"
+  integrity sha512-ObmnIF4hXNg1BqhnHmgbDETF8dLPCggZWBjkQfhZpbszZnYur5DUljTcCHii5LC3J5E0yeO/1LIMyH+UvHQgyw==
 
 side-channel-list@^1.0.0:
   version "1.0.0"
@@ -8174,7 +8263,7 @@ side-channel-weakmap@^1.0.2:
     object-inspect "^1.13.3"
     side-channel-map "^1.0.1"
 
-side-channel@^1.0.6:
+side-channel@^1.1.0:
   version "1.1.0"
   resolved "https://registry.npmjs.org/side-channel/-/side-channel-1.1.0.tgz"
   integrity sha512-ZX99e6tRweoUXqR+VBrslhda51Nh5MTQwou5tnUDgbtyM0dBgmhEDtWGP/xbKn6hqfPRHujUNwz5fy/wbbhnpw==
@@ -8319,15 +8408,15 @@ srcset@^4.0.0:
   resolved "https://registry.npmjs.org/statuses/-/statuses-1.5.0.tgz"
   integrity sha512-OpZ3zP+jT1PI7I8nemJX4AKmAX070ZkYPVWV/AaKTJl+tXCTGyVdC1a4SL8RUQYEwk/f34ZX8UTykN68FwrqAA==
 
-statuses@2.0.1:
-  version "2.0.1"
-  resolved "https://registry.npmjs.org/statuses/-/statuses-2.0.1.tgz"
-  integrity sha512-RwNA9Z/7PrK06rYLIzFMlaF+l73iwpzsqRIFgbMLbTcLD6cOao82TaWefPXQvB2fOC4AjuYSEndS7N/mTCbkdQ==
+statuses@~2.0.1, statuses@~2.0.2:
+  version "2.0.2"
+  resolved "https://registry.npmjs.org/statuses/-/statuses-2.0.2.tgz"
+  integrity sha512-DvEy55V3DB7uknRo+4iOGT5fP1slR8wQohVdknigZPMpMstaKJQWhwiYBACJE3Ul2pTnATihhBYnRhZQHGBiRw==
 
 std-env@^3.7.0:
-  version "3.8.0"
-  resolved "https://registry.npmjs.org/std-env/-/std-env-3.8.0.tgz"
-  integrity sha512-Bc3YwwCB+OzldMxOXJIIvC6cPRWr/LxOp48CdQTOkPyk/t4JWWJbrilwBd7RJzKV8QW7tJkcgAmeuLLJugl5/w==
+  version "3.10.0"
+  resolved "https://registry.npmjs.org/std-env/-/std-env-3.10.0.tgz"
+  integrity sha512-5GS12FdOZNliM5mAOxFRg7Ir0pWz8MdpYm6AY6VPkGpbA7ZzmbzNcBJQ0GPvvyWgcY7QAhCgf9Uy89I03faLkg==
 
 string_decoder@^1.1.1:
   version "1.3.0"
@@ -8473,10 +8562,13 @@ svgo@^3.0.2, svgo@^3.2.0:
     csso "^5.0.5"
     picocolors "^1.0.0"
 
-tapable@^1.0.0:
-  version "1.1.3"
-  resolved "https://registry.npmjs.org/tapable/-/tapable-1.1.3.tgz"
-  integrity sha512-4WK/bYZmj8xLr+HUCODHGF1ZFzsYffasLUgEiMBY4fgtltdO6B4WJtlSbPaDTLpYTcGVwM2qLnFTICEcNxs3kA==
+swr@^2.2.5:
+  version "2.3.8"
+  resolved "https://registry.npmjs.org/swr/-/swr-2.3.8.tgz"
+  integrity sha512-gaCPRVoMq8WGDcWj9p4YWzCMPHzE0WNl6W8ADIx9c3JBEIdMkJGMzW+uzXvxHMltwcYACr9jP+32H8/hgwMR7w==
+  dependencies:
+    dequal "^2.0.3"
+    use-sync-external-store "^1.6.0"
 
 tapable@^2.0.0, tapable@^2.1.1, tapable@^2.2.0, tapable@^2.2.1:
   version "2.2.1"
@@ -8504,10 +8596,15 @@ terser@^5.10.0, terser@^5.15.1, terser@^5.31.1:
     commander "^2.20.0"
     source-map-support "~0.5.20"
 
-text-table@^0.2.0:
-  version "0.2.0"
-  resolved "https://registry.npmjs.org/text-table/-/text-table-0.2.0.tgz"
-  integrity sha512-N+8UisAXDGk8PFXP4HAzVR9nbfmVJ3zYLAWiTIoqC5v5isinhr+r5uaO8+7r3BMfuNIufIsA7RdpVgacC2cSpw==
+thingies@^2.5.0:
+  version "2.5.0"
+  resolved "https://registry.npmjs.org/thingies/-/thingies-2.5.0.tgz"
+  integrity sha512-s+2Bwztg6PhWUD7XMfeYm5qliDdSiZm7M7n8KjTkIsm3l/2lgVRc2/Gx/v+ZX8lT4FMA+i8aQvhcWylldc+ZNw==
+
+throttleit@2.1.0:
+  version "2.1.0"
+  resolved "https://registry.npmjs.org/throttleit/-/throttleit-2.1.0.tgz"
+  integrity sha512-nt6AMGKW1p/70DF/hGBdJB57B8Tspmbp5gfJ8ilhLnt7kkr2ye7hzD6NVG8GGErk2HWF34igrL2CXmNIkzKqKw==
 
 thunky@^1.0.2:
   version "1.1.0"
@@ -8524,6 +8621,11 @@ tiny-warning@^1.0.0:
   resolved "https://registry.npmjs.org/tiny-warning/-/tiny-warning-1.0.3.tgz"
   integrity sha512-lBN9zLN/oAf68o3zNXYrdCt1kP8WsiGW8Oo2ka41b2IM5JL/S1CTyX1rW0mb/zSuJun0ZUrDxx4sqvYS2FWzPA==
 
+tinypool@^1.0.2:
+  version "1.1.1"
+  resolved "https://registry.npmjs.org/tinypool/-/tinypool-1.1.1.tgz"
+  integrity sha512-Zba82s87IFq9A9XmjiX5uZA/ARWDrB03OHlq+Vw1fSdt0I+4/Kutwy8BP4Y/y/aORMo61FQ0vIb5j44vSo5Pkg==
+
 to-regex-range@^5.0.1:
   version "5.0.1"
   resolved "https://registry.npmjs.org/to-regex-range/-/to-regex-range-5.0.1.tgz"
@@ -8531,7 +8633,7 @@ to-regex-range@^5.0.1:
   dependencies:
     is-number "^7.0.0"
 
-toidentifier@1.0.1:
+toidentifier@~1.0.1:
   version "1.0.1"
   resolved "https://registry.npmjs.org/toidentifier/-/toidentifier-1.0.1.tgz"
   integrity sha512-o5sSPKEkg/DIQNmH43V0/uerLrpzVedkUh8tGNvaeXpfpuwjKenlSox/2O/BTlZUtEe+JG7s5YhEz608PlAHRA==
@@ -8541,6 +8643,11 @@ totalist@^3.0.0:
   resolved "https://registry.npmjs.org/totalist/-/totalist-3.0.1.tgz"
   integrity sha512-sf4i37nQ2LBx4m3wB74y+ubopq6W/dIzXg0FDGjsYnZHVa1Da8FH853wlL2gtUhg+xJXjfk3kUZS3BRoQeoQBQ==
 
+tree-dump@^1.0.3, tree-dump@^1.1.0:
+  version "1.1.0"
+  resolved "https://registry.npmjs.org/tree-dump/-/tree-dump-1.1.0.tgz"
+  integrity sha512-rMuvhU4MCDbcbnleZTFezWsaZXRFemSqAM+7jPnzUl1fo9w3YEKOxAeui0fz3OI4EU4hf23iyA7uQRVko+UaBA==
+
 trim-lines@^3.0.0:
   version "3.0.1"
   resolved "https://registry.npmjs.org/trim-lines/-/trim-lines-3.0.1.tgz"
@@ -8551,11 +8658,23 @@ trough@^2.0.0:
   resolved "https://registry.npmjs.org/trough/-/trough-2.2.0.tgz"
   integrity sha512-tmMpK00BjZiUyVyvrBK7knerNgmgvcV/KLVyuma/SC+TQN167GrMRciANTz09+k3zW8L8t60jWO1GpfkZdjTaw==
 
-tslib@^2.0.3, tslib@^2.6.0:
+tslib@^1.9.3:
+  version "1.14.1"
+  resolved "https://registry.npmjs.org/tslib/-/tslib-1.14.1.tgz"
+  integrity sha512-Xni35NKzjgMrwevysHTCArtLDpPvye8zV/0E4EyYn43P7/7qvQwPh9BGkHewbMulVntbigmcT7rdX3BNo9wRJg==
+
+tslib@^2, tslib@^2.0.0, tslib@^2.0.3, tslib@^2.6.0, tslib@^2.8.1, tslib@2:
   version "2.8.1"
   resolved "https://registry.npmjs.org/tslib/-/tslib-2.8.1.tgz"
   integrity sha512-oJFu94HQb+KVduSUQL7wnpmqnfmLsOA/nAh6b6EH0wCEoK0/mPeXU6c3wKDV83MkOuHPRHtSXKKU99IBazS/2w==
 
+tsyringe@^4.10.0:
+  version "4.10.0"
+  resolved "https://registry.npmjs.org/tsyringe/-/tsyringe-4.10.0.tgz"
+  integrity sha512-axr3IdNuVIxnaK5XGEUFTu3YmAQ6lllgrvqfEoR16g/HGnYY/6We4oWENtAnzK6/LpJ2ur9PAb80RBt7/U4ugw==
+  dependencies:
+    tslib "^1.9.3"
+
 type-fest@^0.21.3:
   version "0.21.3"
   resolved "https://registry.npmjs.org/type-fest/-/type-fest-0.21.3.tgz"
@@ -8586,7 +8705,7 @@ typedarray-to-buffer@^3.1.5:
   dependencies:
     is-typedarray "^1.0.0"
 
-typescript@^4.7.4, "typescript@>= 2.7", typescript@>=4.9.5:
+typescript@^4.7.4, typescript@>=4.9.5:
   version "4.9.5"
   resolved "https://registry.npmjs.org/typescript/-/typescript-4.9.5.tgz"
   integrity sha512-1FXk9E2Hm+QzZQ7z+McJiHL4NW1F2EzMu9Nq9i3zAaGqibafqYwCVU6WyWAuyQRRzOlxou8xZSyXLEN8oKj24g==
@@ -8614,15 +8733,15 @@ unicode-match-property-ecmascript@^2.0.0:
     unicode-canonical-property-names-ecmascript "^2.0.0"
     unicode-property-aliases-ecmascript "^2.0.0"
 
-unicode-match-property-value-ecmascript@^2.1.0:
-  version "2.2.0"
-  resolved "https://registry.npmjs.org/unicode-match-property-value-ecmascript/-/unicode-match-property-value-ecmascript-2.2.0.tgz"
-  integrity sha512-4IehN3V/+kkr5YeSSDDQG8QLqO26XpL2XP3GQtqwlT/QYSECAwFztxVHjlbh0+gjJ3XmNLS0zDsbgs9jWKExLg==
+unicode-match-property-value-ecmascript@^2.2.1:
+  version "2.2.1"
+  resolved "https://registry.npmjs.org/unicode-match-property-value-ecmascript/-/unicode-match-property-value-ecmascript-2.2.1.tgz"
+  integrity sha512-JQ84qTuMg4nVkx8ga4A16a1epI9H6uTXAknqxkGF/aFfRLw1xC/Bp24HNLaZhHSkWd3+84t8iXnp1J0kYcZHhg==
 
 unicode-property-aliases-ecmascript@^2.0.0:
-  version "2.1.0"
-  resolved "https://registry.npmjs.org/unicode-property-aliases-ecmascript/-/unicode-property-aliases-ecmascript-2.1.0.tgz"
-  integrity sha512-6t3foTQI9qne+OZoVQB/8x8rk2k1eVy1gRXhV3oFQ5T6R1dqQ1xtin3XqSlx3+ATBkliTaR/hHyJBm+LVPNM8w==
+  version "2.2.0"
+  resolved "https://registry.npmjs.org/unicode-property-aliases-ecmascript/-/unicode-property-aliases-ecmascript-2.2.0.tgz"
+  integrity sha512-hpbDzxUY9BFwX+UeBnxv3Sh1q7HFxj48DTmXchNgRa46lO8uj3/1iEn3MiNUYTg1g9ctIqXCCERn8gYZhHC5lQ==
 
 unified@^11.0.0, unified@^11.0.3, unified@^11.0.4:
   version "11.0.5"
@@ -8694,15 +8813,15 @@ universalify@^2.0.0:
   resolved "https://registry.npmjs.org/universalify/-/universalify-2.0.1.tgz"
   integrity sha512-gptHNQghINnc/vTGIk0SOFGFNXw7JVrlRUtConJRlvaw6DuX0wO5Jeko9sWrMBhh+PsYAZ7oXAiOnf/UKogyiw==
 
-unpipe@~1.0.0, unpipe@1.0.0:
+unpipe@~1.0.0:
   version "1.0.0"
   resolved "https://registry.npmjs.org/unpipe/-/unpipe-1.0.0.tgz"
   integrity sha512-pjy2bYhSsufwWlKwPc+l3cN7+wuJlK6uz0YdJEOlQDbl6jo/YlPi4mb8agUkVC8BF7V8NuzeyPNqRksA3hztKQ==
 
-update-browserslist-db@^1.1.1:
-  version "1.1.2"
-  resolved "https://registry.npmjs.org/update-browserslist-db/-/update-browserslist-db-1.1.2.tgz"
-  integrity sha512-PPypAm5qvlD7XMZC3BujecnaOxwhrtoFR+Dqkk5Aa/6DssiH0ibKoketaj9w8LP7Bont1rYeoV5plxD7RTEPRg==
+update-browserslist-db@^1.2.0:
+  version "1.2.3"
+  resolved "https://registry.npmjs.org/update-browserslist-db/-/update-browserslist-db-1.2.3.tgz"
+  integrity sha512-Js0m9cx+qOgDxo0eMiFGEueWztz+d4+M3rGlmKPT+T4IS/jP4ylw3Nwpu6cpTTP8R1MAC1kF4VbdLt3ARf209w==
   dependencies:
     escalade "^3.2.0"
     picocolors "^1.1.1"
@@ -8743,6 +8862,11 @@ url-loader@^4.1.1:
     mime-types "^2.1.27"
     schema-utils "^3.0.0"
 
+use-sync-external-store@^1.6.0:
+  version "1.6.0"
+  resolved "https://registry.npmjs.org/use-sync-external-store/-/use-sync-external-store-1.6.0.tgz"
+  integrity sha512-Pp6GSwGP/NrPIrxVFAIkOQeyw8lFenOHijQWkUTrDvrF4ALqylP2C/KCkeS9dpUM3KvYRQhna5vt7IL95+ZQ9w==
+
 util-deprecate@^1.0.1, util-deprecate@^1.0.2, util-deprecate@~1.0.1:
   version "1.0.2"
   resolved "https://registry.npmjs.org/util-deprecate/-/util-deprecate-1.0.2.tgz"
@@ -8840,52 +8964,51 @@ webpack-bundle-analyzer@^4.10.2:
     sirv "^2.0.3"
     ws "^7.3.1"
 
-webpack-dev-middleware@^5.3.4:
-  version "5.3.4"
-  resolved "https://registry.npmjs.org/webpack-dev-middleware/-/webpack-dev-middleware-5.3.4.tgz"
-  integrity sha512-BVdTqhhs+0IfoeAf7EoH5WE+exCmqGerHfDM0IL096Px60Tq2Mn9MAbnaGUe6HiMa41KMCYF19gyzZmBcq/o4Q==
+webpack-dev-middleware@^7.4.2:
+  version "7.4.5"
+  resolved "https://registry.npmjs.org/webpack-dev-middleware/-/webpack-dev-middleware-7.4.5.tgz"
+  integrity sha512-uxQ6YqGdE4hgDKNf7hUiPXOdtkXvBJXrfEGYSx7P7LC8hnUYGK70X6xQXUvXeNyBDDcsiQXpG2m3G9vxowaEuA==
   dependencies:
     colorette "^2.0.10"
-    memfs "^3.4.3"
-    mime-types "^2.1.31"
+    memfs "^4.43.1"
+    mime-types "^3.0.1"
+    on-finished "^2.4.1"
     range-parser "^1.2.1"
     schema-utils "^4.0.0"
 
-webpack-dev-server@^4.15.2:
-  version "4.15.2"
-  resolved "https://registry.npmjs.org/webpack-dev-server/-/webpack-dev-server-4.15.2.tgz"
-  integrity sha512-0XavAZbNJ5sDrCbkpWL8mia0o5WPOd2YGtxrEiZkBK9FjLppIUK2TgxK6qGD2P3hUXTJNNPVibrerKcx5WkR1g==
-  dependencies:
-    "@types/bonjour" "^3.5.9"
-    "@types/connect-history-api-fallback" "^1.3.5"
-    "@types/express" "^4.17.13"
-    "@types/serve-index" "^1.9.1"
-    "@types/serve-static" "^1.13.10"
-    "@types/sockjs" "^0.3.33"
-    "@types/ws" "^8.5.5"
+webpack-dev-server@^5.2.2:
+  version "5.2.3"
+  resolved "https://registry.npmjs.org/webpack-dev-server/-/webpack-dev-server-5.2.3.tgz"
+  integrity sha512-9Gyu2F7+bg4Vv+pjbovuYDhHX+mqdqITykfzdM9UyKqKHlsE5aAjRhR+oOEfXW5vBeu8tarzlJFIZva4ZjAdrQ==
+  dependencies:
+    "@types/bonjour" "^3.5.13"
+    "@types/connect-history-api-fallback" "^1.5.4"
+    "@types/express" "^4.17.25"
+    "@types/express-serve-static-core" "^4.17.21"
+    "@types/serve-index" "^1.9.4"
+    "@types/serve-static" "^1.15.5"
+    "@types/sockjs" "^0.3.36"
+    "@types/ws" "^8.5.10"
     ansi-html-community "^0.0.8"
-    bonjour-service "^1.0.11"
-    chokidar "^3.5.3"
+    bonjour-service "^1.2.1"
+    chokidar "^3.6.0"
     colorette "^2.0.10"
-    compression "^1.7.4"
+    compression "^1.8.1"
     connect-history-api-fallback "^2.0.0"
-    default-gateway "^6.0.3"
-    express "^4.17.3"
+    express "^4.22.1"
     graceful-fs "^4.2.6"
-    html-entities "^2.3.2"
-    http-proxy-middleware "^2.0.3"
-    ipaddr.js "^2.0.1"
-    launch-editor "^2.6.0"
-    open "^8.0.9"
-    p-retry "^4.5.0"
-    rimraf "^3.0.2"
-    schema-utils "^4.0.0"
-    selfsigned "^2.1.1"
+    http-proxy-middleware "^2.0.9"
+    ipaddr.js "^2.1.0"
+    launch-editor "^2.6.1"
+    open "^10.0.3"
+    p-retry "^6.2.0"
+    schema-utils "^4.2.0"
+    selfsigned "^5.5.0"
     serve-index "^1.9.1"
     sockjs "^0.3.24"
     spdy "^4.0.2"
-    webpack-dev-middleware "^5.3.4"
-    ws "^8.13.0"
+    webpack-dev-middleware "^7.4.2"
+    ws "^8.18.0"
 
 webpack-merge@^5.9.0:
   version "5.10.0"
@@ -8910,7 +9033,7 @@ webpack-sources@^3.2.3:
   resolved "https://registry.npmjs.org/webpack-sources/-/webpack-sources-3.2.3.tgz"
   integrity sha512-/DyMEOrDgLKKIG0fmvtz+4dUX/3Ghozwgm6iPp8KRhvn+eQf9+Q7GWxVNMk3+uCPWfdXYC4ExGBckIXdFEfH1w==
 
-"webpack@^4.0.0 || ^5.0.0", "webpack@^4.37.0 || ^5.0.0", webpack@^5.0.0, webpack@^5.1.0, webpack@^5.20.0, webpack@^5.88.1, webpack@^5.95.0, "webpack@>= 4", "webpack@>=4.41.1 || 5.x", webpack@>=5, "webpack@3 || 4 || 5":
+"webpack@^4.0.0 || ^5.0.0", webpack@^5.0.0, webpack@^5.1.0, webpack@^5.20.0, webpack@^5.88.1, webpack@^5.95.0, "webpack@>=4.41.1 || 5.x", webpack@>=5, "webpack@3 || 4 || 5":
   version "5.97.1"
   resolved "https://registry.npmjs.org/webpack/-/webpack-5.97.1.tgz"
   integrity sha512-EksG6gFY3L1eFMROS/7Wzgrii5mBAFe4rIr3r2BTfo7bcc+DWwFZ4OJ/miOuHJO/A85HwyI4eQ0F6IKXesO7Fg==
@@ -8967,13 +9090,6 @@ websocket-extensions@>=0.1.1:
   resolved "https://registry.npmjs.org/websocket-extensions/-/websocket-extensions-0.1.4.tgz"
   integrity sha512-OqedPIGOfsDlo31UNwYbCFMSaO9m9G/0faIHj5/dZFDMFqPTcx6UwqyOy3COEaEOg/9VsGIpdqn62W5KhoKSpg==
 
-which@^1.3.1:
-  version "1.3.1"
-  resolved "https://registry.npmjs.org/which/-/which-1.3.1.tgz"
-  integrity sha512-HxJdYWq1MTIQbJ3nw0cqssHoTNU267KlrDuGZ1WYlxDStUtKUhOaJmh112/TZmHxxUfuJqPXSOm7tDyas0OSIQ==
-  dependencies:
-    isexe "^2.0.0"
-
 which@^2.0.1:
   version "2.0.2"
   resolved "https://registry.npmjs.org/which/-/which-2.0.2.tgz"
@@ -9011,11 +9127,6 @@ wrap-ansi@^8.0.1, wrap-ansi@^8.1.0:
     string-width "^5.0.1"
     strip-ansi "^7.0.1"
 
-wrappy@1:
-  version "1.0.2"
-  resolved "https://registry.npmjs.org/wrappy/-/wrappy-1.0.2.tgz"
-  integrity sha512-l4Sp/DRseor9wL6EvV2+TuQn63dMkPjZ/sp9XkghTEbV9KlPS1xUsZ3u7/IQO4wxtcFB4bgpQPRcR3QCvezPcQ==
-
 write-file-atomic@^3.0.3:
   version "3.0.3"
   resolved "https://registry.npmjs.org/write-file-atomic/-/write-file-atomic-3.0.3.tgz"
@@ -9031,10 +9142,17 @@ ws@^7.3.1:
   resolved "https://registry.npmjs.org/ws/-/ws-7.5.10.tgz"
   integrity sha512-+dbF1tHwZpXcbOJdVOkzLDxZP1ailvSxM6ZweXTegylPny803bFhA+vqBYw4s31NSAk4S2Qz+AKXK9a4wkdjcQ==
 
-ws@^8.13.0:
-  version "8.18.0"
-  resolved "https://registry.npmjs.org/ws/-/ws-8.18.0.tgz"
-  integrity sha512-8VbfWfHLbbwu3+N6OKsOMpBdT4kXPDDB9cJk2bJ6mh9ucxdlnNvH1e+roYkKmN9Nxw2yjz7VzeO9oOz2zJ04Pw==
+ws@^8.18.0:
+  version "8.19.0"
+  resolved "https://registry.npmjs.org/ws/-/ws-8.19.0.tgz"
+  integrity sha512-blAT2mjOEIi0ZzruJfIhb3nps74PRWTCz1IjglWEEpQl5XS/UNama6u2/rjFkDDouqr4L67ry+1aGIALViWjDg==
+
+wsl-utils@^0.1.0:
+  version "0.1.0"
+  resolved "https://registry.npmjs.org/wsl-utils/-/wsl-utils-0.1.0.tgz"
+  integrity sha512-h3Fbisa2nKGPxCpm89Hk33lBLsnaGBvctQopaBSOW/uIs6FTe1ATyAnKFJrzVs9vpGdsTe73WF3V4lIsk4Gacw==
+  dependencies:
+    is-wsl "^3.1.0"
 
 xdg-basedir@^5.0.1, xdg-basedir@^5.1.0:
   version "5.1.0"
@@ -9053,20 +9171,15 @@ yallist@^3.0.2:
   resolved "https://registry.npmjs.org/yallist/-/yallist-3.1.1.tgz"
   integrity sha512-a4UGQaWPH59mOXUYnAG2ewncQS4i4F43Tv3JoAM+s2VDAmS9NsK8GpDMLrCHPksFT7h3K6TOoUNn2pb7RoXx4g==
 
-yaml@^1.7.2:
-  version "1.10.2"
-  resolved "https://registry.npmjs.org/yaml/-/yaml-1.10.2.tgz"
-  integrity sha512-r3vXyErRCYJ7wg28yvBY5VSoAF8ZvlcW9/BwUzEtUsjvX/DKs24dIkuwjtuprwJJHsbyUbLApepYTR1BN4uHrg==
-
-yocto-queue@^0.1.0:
-  version "0.1.0"
-  resolved "https://registry.npmjs.org/yocto-queue/-/yocto-queue-0.1.0.tgz"
-  integrity sha512-rVksvsnNCdJ/ohGc6xgPwyN8eheCxsiLM8mxuE/t/mOVqJewPuO1miLpTHQiRgTKCLexL4MeAFVagts7HmNZ2Q==
-
 yocto-queue@^1.0.0:
-  version "1.1.1"
-  resolved "https://registry.npmjs.org/yocto-queue/-/yocto-queue-1.1.1.tgz"
-  integrity sha512-b4JR1PFR10y1mKjhHY9LaGo6tmrgjit7hxVIeAmyMw3jegXR4dhYqLaQF5zMXZxY7tLpMyJeLjr1C4rLmkVe8g==
+  version "1.2.2"
+  resolved "https://registry.npmjs.org/yocto-queue/-/yocto-queue-1.2.2.tgz"
+  integrity sha512-4LCcse/U2MHZ63HAJVE+v71o7yOdIe4cZ70Wpf8D/IyjDKYQLV5GD46B+hSTjJsvV5PztjvHoU580EftxjDZFQ==
+
+"zod@^3.25.76 || ^4.1.8", zod@^4.1.8:
+  version "4.3.5"
+  resolved "https://registry.npmjs.org/zod/-/zod-4.3.5.tgz"
+  integrity sha512-k7Nwx6vuWx1IJ9Bjuf4Zt1PEllcwe7cls3VNzm4CQ1/hgtFUK2bRNG3rvnpPUhFjmqJKAKtjV576KnUkHocg/g==
 
 zwitch@^2.0.0:
   version "2.0.4"
diff --git a/package-lock.json b/package-lock.json
new file mode 100644
index 00000000..fa5730af
--- /dev/null
+++ b/package-lock.json
@@ -0,0 +1,10 @@
+{
+  "name": "bitloops-language",
+  "lockfileVersion": 3,
+  "requires": true,
+  "packages": {
+    "": {
+      "name": "bitloops-language"
+    }
+  }
+}
diff --git a/package.json b/package.json
new file mode 100644
index 00000000..4f3a86bb
--- /dev/null
+++ b/package.json
@@ -0,0 +1,6 @@
+{
+  "name": "bitloops-language",
+  "lockfileVersion": 3,
+  "requires": true,
+  "packages": {}
+}
diff --git a/yarn.lock b/yarn.lock
new file mode 100644
index 00000000..fb57ccd1
--- /dev/null
+++ b/yarn.lock
@@ -0,0 +1,4 @@
+# THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.
+# yarn lockfile v1
+
+