&color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIElzc3VlczwvdGl0bGU+PHBhdGggZD0iTTggOS41YTEuNSAxLjUgMCAxIDAgMC0zIDEuNSAxLjUgMCAwIDAgMCAzWiIgZmlsbD0iIzg0OEQ5NyIvPjxwYXRoIGQ9Ik04IDBhOCA4IDAgMSAxIDAgMTZBOCA4IDAgMCAxIDggMFpNMS41IDhhNi41IDYuNSAwIDEgMCAxMyAwIDYuNSA2LjUgMCAwIDAtMTMgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
- &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFB1bGwgUmVxdWVzdHM8L3RpdGxlPjxwYXRoIGQ9Ik0xLjUgMy4yNWEyLjI1IDIuMjUgMCAxIDEgMyAyLjEyMnY1LjI1NmEyLjI1MSAyLjI1MSAwIDEgMS0xLjUgMFY1LjM3MkEyLjI1IDIuMjUgMCAwIDEgMS41IDMuMjVabTUuNjc3LS4xNzdMOS41NzMuNjc3QS4yNS4yNSAwIDAgMSAxMCAuODU0VjIuNWgxQTIuNSAyLjUgMCAwIDEgMTMuNSA1djUuNjI4YTIuMjUxIDIuMjUxIDAgMSAxLTEuNSAwVjVhMSAxIDAgMCAwLTEtMWgtMXYxLjY0NmEuMjUuMjUgMCAwIDEtLjQyNy4xNzdMNy4xNzcgMy40MjdhLjI1LjI1IDAgMCAxIDAtLjM1NFpNMy43NSAyLjVhLjc1Ljc1IDAgMSAwIDAgMS41Ljc1Ljc1IDAgMCAwIDAtMS41Wm0wIDkuNWEuNzUuNzUgMCAxIDAgMCAxLjUuNzUuNzUgMCAwIDAgMC0xLjVabTguMjUuNzVhLjc1Ljc1IDAgMSAwIDEuNSAwIC43NS43NSAwIDAgMC0xLjUgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4NCg==)
- &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFN0YXJzPC90aXRsZT48cGF0aCBkPSJNOCAuMjVhLjc1Ljc1IDAgMCAxIC42NzMuNDE4bDEuODgyIDMuODE1IDQuMjEuNjEyYS43NS43NSAwIDAgMSAuNDE2IDEuMjc5bC0zLjA0NiAyLjk3LjcxOSA0LjE5MmEuNzUxLjc1MSAwIDAgMS0xLjA4OC43OTFMOCAxMi4zNDdsLTMuNzY2IDEuOThhLjc1Ljc1IDAgMCAxLTEuMDg4LS43OWwuNzItNC4xOTRMLjgxOCA2LjM3NGEuNzUuNzUgMCAwIDEgLjQxNi0xLjI4bDQuMjEtLjYxMUw3LjMyNy42NjhBLjc1Ljc1IDAgMCAxIDggLjI1Wm0wIDIuNDQ1TDYuNjE1IDUuNWEuNzUuNzUgMCAwIDEtLjU2NC40MWwtMy4wOTcuNDUgMi4yNCAyLjE4NGEuNzUuNzUgMCAwIDEgLjIxNi42NjRsLS41MjggMy4wODQgMi43NjktMS40NTZhLjc1Ljc1IDAgMCAxIC42OTggMGwyLjc3IDEuNDU2LS41My0zLjA4NGEuNzUuNzUgMCAwIDEgLjIxNi0uNjY0bDIuMjQtMi4xODMtMy4wOTYtLjQ1YS43NS43NSAwIDAgMS0uNTY0LS40MUw4IDIuNjk0WiIgZmlsbD0iIzg0OEQ5NyIvPjwvc3ZnPg==)
- &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFRhZ3M8L3RpdGxlPjxwYXRoIGQ9Ik04IDJjMS45ODEgMCAzLjY3MS45OTIgNC45MzMgMi4wNzggMS4yNyAxLjA5MSAyLjE4NyAyLjM0NSAyLjYzNyAzLjAyM2ExLjYyIDEuNjIgMCAwIDEgMCAxLjc5OGMtLjQ1LjY3OC0xLjM2NyAxLjkzMi0yLjYzNyAzLjAyM0MxMS42NyAxMy4wMDggOS45ODEgMTQgOCAxNGMtMS45ODEgMC0zLjY3MS0uOTkyLTQuOTMzLTIuMDc4QzEuNzk3IDEwLjgzLjg4IDkuNTc2LjQzIDguODk4YTEuNjIgMS42MiAwIDAgMSAwLTEuNzk4Yy40NS0uNjc3IDEuMzY3LTEuOTMxIDIuNjM3LTMuMDIyQzQuMzMgMi45OTIgNi4wMTkgMiA4IDJaTTEuNjc5IDcuOTMyYS4xMi4xMiAwIDAgMCAwIC4xMzZjLjQxMS42MjIgMS4yNDEgMS43NSAyLjM2NiAyLjcxN0M1LjE3NiAxMS43NTggNi41MjcgMTIuNSA4IDEyLjVjMS40NzMgMCAyLjgyNS0uNzQyIDMuOTU1LTEuNzE1IDEuMTI0LS45NjcgMS45NTQtMi4wOTYgMi4zNjYtMi43MTdhLjEyLjEyIDAgMCAwIDAtLjEzNmMtLjQxMi0uNjIxLTEuMjQyLTEuNzUtMi4zNjYtMi43MTdDMTAuODI0IDQuMjQyIDkuNDczIDMuNSA4IDMuNWMtMS40NzMgMC0yLjgyNS43NDItMy45NTUgMS43MTUtMS4xMjQuOTY3LTEuOTU0IDIuMDk2LTIuMzY2IDIuNzE3Wk04IDEwYTIgMiAwIDEgMS0uMDAxLTMuOTk5QTIgMiAwIDAgMSA4IDEwWiIgZmlsbD0iIzg0OEQ5NyIvPjwvc3ZnPg==)
- &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIEZvcmtzPC90aXRsZT48cGF0aCBkPSJNNSA1LjM3MnYuODc4YzAgLjQxNC4zMzYuNzUuNzUuNzVoNC41YS43NS43NSAwIDAgMCAuNzUtLjc1di0uODc4YTIuMjUgMi4yNSAwIDEgMSAxLjUgMHYuODc4YTIuMjUgMi4yNSAwIDAgMS0yLjI1IDIuMjVoLTEuNXYyLjEyOGEyLjI1MSAyLjI1MSAwIDEgMS0xLjUgMFY4LjVoLTEuNUEyLjI1IDIuMjUgMCAwIDEgMy41IDYuMjV2LS44NzhhMi4yNSAyLjI1IDAgMSAxIDEuNSAwWk01IDMuMjVhLjc1Ljc1IDAgMSAwLTEuNSAwIC43NS43NSAwIDAgMCAxLjUgMFptNi43NS43NWEuNzUuNzUgMCAxIDAgMC0xLjUuNzUuNzUgMCAwIDAgMCAxLjVabS0zIDguNzVhLjc1Ljc1IDAgMSAwLTEuNSAwIC43NS43NSAwIDAgMCAxLjUgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
- &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyB2aWV3Qm94PSIwIDAgMjQgMjQiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyI+PHBhdGggZD0iTTggMTBDOCA3Ljc5MDg2IDkuNzkwODYgNiAxMiA2QzE0LjIwOTEgNiAxNiA3Ljc5MDg2IDE2IDEwVjExSDE3QzE4LjkzMyAxMSAyMC41IDEyLjU2NyAyMC41IDE0LjVDMjAuNSAxNi40MzMgMTguOTMzIDE4IDE3IDE4SDE2LjlDMTYuMzQ3NyAxOCAxNS45IDE4LjQ0NzcgMTUuOSAxOUMxNS45IDE5LjU1MjMgMTYuMzQ3NyAyMCAxNi45IDIwSDE3QzIwLjAzNzYgMjAgMjIuNSAxNy41Mzc2IDIyLjUgMTQuNUMyMi41IDExLjc3OTMgMjAuNTI0NSA5LjUxOTk3IDE3LjkyOTYgOS4wNzgyNEMxNy40ODYyIDYuMjAyMTMgMTUuMDAwMyA0IDEyIDRDOC45OTk3NCA0IDYuNTEzODEgNi4yMDIxMyA2LjA3MDM2IDkuMDc4MjRDMy40NzU1MSA5LjUxOTk3IDEuNSAxMS43NzkzIDEuNSAxNC41QzEuNSAxNy41Mzc2IDMuOTYyNDMgMjAgNyAyMEg3LjFDNy42NTIyOCAyMCA4LjEgMTkuNTUyMyA4LjEgMTlDOC4xIDE4LjQ0NzcgNy42NTIyOCAxOCA3LjEgMThIN0M1LjA2NyAxOCAzLjUgMTYuNDMzIDMuNSAxNC41QzMuNSAxMi41NjcgNS4wNjcgMTEgNyAxMUg4VjEwWk0xMyAxMUMxMyAxMC40NDc3IDEyLjU1MjMgMTAgMTIgMTBDMTEuNDQ3NyAxMCAxMSAxMC40NDc3IDExIDExVjE2LjU4NThMOS43MDcxMSAxNS4yOTI5QzkuMzE2NTggMTQuOTAyNCA4LjY4MzQyIDE0LjkwMjQgOC4yOTI4OSAxNS4yOTI5QzcuOTAyMzcgMTUuNjgzNCA3LjkwMjM3IDE2LjMxNjYgOC4yOTI4OSAxNi43MDcxTDExLjI5MjkgMTkuNzA3MUMxMS42ODM0IDIwLjA5NzYgMTIuMzE2NiAyMC4wOTc2IDEyLjcwNzEgMTkuNzA3MUwxNS43MDcxIDE2LjcwNzFDMTYuMDk3NiAxNi4zMTY2IDE2LjA5NzYgMTUuNjgzNCAxNS43MDcxIDE1LjI5MjlDMTUuMzE2NiAxNC45MDI0IDE0LjY4MzQgMTQuOTAyNCAxNC4yOTI5IDE1LjI5MjlMMTMgMTYuNTg1OFYxMVoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
- 
- 
- | Name | -Description | -Version | -
|---|
-
-
-
-
-
- | Name | -Description | -Version | -
|---|
-
-
-
-
-
- | Name | -Description | -Version | -
|---|
-
-
-
-
-
- | Name | -Description | -Version | -
|---|
This is a test blog post.
+ + +This is a test blog post.
+ + +Welcome to the PSModule blog! Here you'll find the latest news, updates, and insights related to PowerShell + GitHub development.
+This is a test blog post.
+ + +Welcome to the PSModule Dictionary - a comprehensive glossary of terms, concepts, and technologies used throughout our projects and documentation.
+Common terms you might encounter: +- API - Application Programming Interface +- Azure - Microsoft's cloud platform +- CI/CD - Continuous Integration/Continuous Deployment +- Cmdlet - PowerShell command +- Git - Version control system +- GitHub - Code hosting platform +- LTS - Long-Term Servicing +- MkDocs - Documentation generator +- Module - PowerShell package +- Pipeline - Automated process chain +- PowerShell - Task automation framework +- Repository - Code storage location +- Workflow - Automated process series
+This dictionary serves as a reference for developers, contributors, and users to understand the terminology and concepts used in PSModule projects. Each entry includes clear definitions, usage examples, and related links where applicable.
+Application Programming Interface (API) - A set of protocols, routines, and tools for building software applications. APIs specify how software components should interact and are used when programming graphical user interface (GUI) components.
+Example: The GitHub API allows developers to interact with GitHub repositories, issues, and pull requests programmatically.
+Microsoft's cloud computing platform that provides a wide range of cloud services, including compute, analytics, storage, and networking.
+Related: Azure Functions, Azure DevOps
+A set of development tools and services from Microsoft for software development teams, including version control, build automation, and project management.
+A serverless compute service that lets you run event-triggered code without having to explicitly provision or manage infrastructure.
+In version control systems like Git, a branch is a parallel version of a repository that diverges from the main working project.
+Example: Feature branches are used to develop new features in isolation before merging back to the main branch.
+An automated process that compiles, tests, and packages source code into deployable artifacts.
+Continuous Integration/Continuous Deployment (CI/CD) - A software development practice where developers regularly merge their code changes into a central repository, after which automated builds and tests are run.
+A lightweight PowerShell command that follows the verb-noun naming convention and is designed to perform a specific function.
+Example: Get-Process, Set-Location, New-Item
A lightweight, standalone, executable package that includes everything needed to run an application: code, runtime, system tools, libraries, and settings.
+A set of practices that combines software development (Dev) and IT operations (Ops) to shorten the systems development life cycle and provide continuous delivery.
+A platform for developing, shipping, and running applications using containerization technology.
+A distributed version control system for tracking changes in source code during software development.
+A web-based platform for version control and collaboration that lets you and others work together on projects from anywhere.
+GitHub's built-in CI/CD platform that allows you to automate your build, test, and deployment pipeline.
+Example: Automatically running tests when a pull request is created.
+Long-Term Servicing (LTS). +For more info visit: PowerShell Support Lifecycle
+A lightweight markup language with plain text formatting syntax, designed to be converted to HTML and many other formats.
+A fast, simple static site generator that's geared towards building project documentation using Markdown files.
+In PowerShell, a package that contains PowerShell members, such as cmdlets, providers, functions, workflows, variables, and aliases.
+A series of automated processes that allow developers and DevOps professionals to reliably and efficiently compile, build, and deploy their code.
+A task automation and configuration management framework from Microsoft, consisting of a command-line shell and the associated scripting language.
+Pull Request (PR) - A method of submitting contributions to a software project where changes are proposed and reviewed before being merged into the main codebase.
+Repository (Repo) - A storage location for software packages, often used in version control systems to store project files and their revision history.
+An architectural style for designing web services that uses HTTP requests to GET, PUT, POST, and DELETE data.
+Semantic Versioning (SemVer) - A versioning scheme that uses a three-part version number: MAJOR.MINOR.PATCH, where each part is incremented based on the type of changes made.
+Example: Version 1.2.3 where 1 is major, 2 is minor, and 3 is patch.
+A tool that generates a full static HTML website based on raw data and a set of templates.
+A pre-designed format or structure that can be used as a starting point for creating new files, projects, or configurations.
+The process of evaluating and verifying that a software application or system meets specified requirements and functions correctly.
+A system that records changes to a file or set of files over time so that you can recall specific versions later.
+An isolated environment that allows you to install packages and dependencies without affecting the global system installation.
+A series of automated steps or processes that execute in response to specific events or triggers.
+Example: A GitHub Actions workflow that runs tests every time code is pushed to a repository.
+YAML Ain't Markup Language (YAML) - A human-readable data serialization standard commonly used for configuration files and data exchange.
+Example: GitHub Actions workflows are defined using YAML files.
+Contributing to the Dictionary
+Found a term that should be added or need to update an existing definition? Please create an issue or submit a pull request with your suggestions.
+Search Functionality
+Use the search feature in the top navigation to quickly find specific terms and their definitions across the entire documentation site.
+This document defines the structure and guidelines for writing Pester tests for PowerShell functions. The goal is to ensure consistency and comprehensive test coverage while maintaining clarity.
+Each function is tested within a structured Pester Describe block that follows this hierarchy:
Describe#Describe block corresponds to the module.Describe#Describe block.Context#Context block.Get-Uri - simple usageGet-Uri - Pipeline usageGet-Uri - ParameterSet: DetailedIt Statements#It block tests a specific aspect of the function's behavior.FunctionName - <expected behavior>Get-Uri - gets the URI object when provided a stringGet-Uri - returns $null when input is emptyGet-Uri - throws error on invalid inputDescribe 'Uri' {
+ Describe 'Get-Uri' {
+ Context 'Get-Uri - simple usage' {
+ It 'Get-Uri - gets the URI object when provided a string' {
+ $result = Get-Uri -InputString 'https://example.com'
+ $result | Should -BeOfType [System.Uri]
+ }
+ }
+
+ Context 'Get-Uri - Pipeline usage' {
+ It 'Get-Uri - processes input from the pipeline' {
+ $result = 'https://example.com' | Get-Uri
+ $result | Should -BeOfType [System.Uri]
+ }
+ }
+ }
+}
+This ensures our tests are structured, maintainable, and adhere to best practices.
+ + + + + + + + + + + + + + + + + + + + + + +This document defines how changes to a PowerShell module’s public interface determine updates to its version number under Semantic Versioning (SemVer). Semantic Versioning uses a three-part version format: MAJOR.MINOR.PATCH, where each part is incremented based on the nature of changes: +- MAJOR version is incremented for incompatible API changes (breaking changes) (Semantic Versioning 2.0.0 | Semantic Versioning). +- MINOR version is incremented for added functionality that is backward compatible (new features) (Semantic Versioning 2.0.0 | Semantic Versioning). +- PATCH version is incremented for backward-compatible bug fixes or minor improvements (Semantic Versioning 2.0.0 | Semantic Versioning).
+In the context of a PowerShell module, the “public API” consists of all exported functions/cmdlets, public variables, classes, and enums that consumers of the module can use. Changes to these exported elements will dictate whether the version bump is major, minor, or patch. Internal changes that do not affect the exported interface are generally not reflected in the version. The following sections categorize changes and the required version update level, ensuring a consistent and predictable versioning strategy.
+A major version bump signifies a breaking change in the module’s public interface. Any modification that could cause existing scripts or code relying on the module to fail or change behavior in an incompatible way requires incrementing the MAJOR version. These include:
+Removal or Renaming of Exported Commands or Elements: Removing an exported function/cmdlet, variable, class, or enum, or renaming any of these, is a breaking change. Consumers referencing the old name will encounter errors because the item no longer exists or has a different name. (Example: Get-ItemFoo was exported in the previous version but is removed or renamed to Get-FooItem in the new version. Scripts calling Get-ItemFoo will break.) This kind of change must increment the major version to signal the break.
Changes to Function Signatures: Modifying the signature of an exported function or cmdlet in a non-backward-compatible way triggers a major bump. This includes:
+Example: An exported function Invoke-ProcessData -Path <string> is changed to Invoke-ProcessData -Uri <string> (parameter renamed) or an existing parameter is removed. Scripts using the old parameter name or expecting that parameter will fail, hence a major version increment is needed.
Example: An exported class FileClient had a public property Timeout that is removed or renamed, or a method Connect(string server) is changed to Connect(Uri server). Code instantiating FileClient or calling its methods would break, so the major version must increase.
Example: An exported enum LogLevel had members Info, Warning, Error. If Warning is removed or renamed to Warn, any script using LogLevel.Warning will break. Such a change mandates a major version bump. (Adding a new enum value is not breaking – see Minor changes.)
Rationale: According to Semantic Versioning, introducing changes that are not backward compatible requires a major version increment (Semantic Versioning 2.0.0 | Semantic Versioning). By increasing the major version, we communicate to users that they may need to adjust their scripts due to breaking changes. This aligns with the principle that “MAJOR version when you make incompatible API changes” (Semantic Versioning 2.0.0 | Semantic Versioning). For example, if a function or parameter that existed in version 1.x is no longer present in version 2.0, that is an incompatible API change. Our versioning policy follows this rule strictly: breaking changes will never be introduced in a minor or patch release, ensuring that patch and minor updates can be safely adopted without fear of script-breaking surprises.
+A minor version bump is used for new features and additions that are backward compatible with the existing public API. These changes enhance the module’s functionality without breaking any existing usage. In other words, existing scripts will continue to work as before, and new capabilities are introduced. Changes that trigger a MINOR version increase include:
+Adding New Exported Functions/Cmdlets: Introducing a new function or cmdlet to the module is a backward-compatible addition. Since it does not remove or change existing functions, nothing breaks; users simply have an additional function available. Example: Adding a new cmdlet New-Report to the module (where it didn’t exist before) would be a new feature. This warrants a minor version bump because it’s an additive, non-breaking change.
Adding New Parameters to Existing Functions: If you extend an existing function’s capabilities by adding a new parameter in a way that does not break existing calls, it is a minor change. The key here is that the new parameter must be optional or have a default value such that any existing calls (which don’t pass this parameter) still work exactly as before. In semantic versioning terms, this is adding functionality in a backwards-compatible manner (semantic versioning - Does adding a parameter to a function definition require a new major version? - Stack Overflow).
+-Force switch or an optional -TimeoutSeconds parameter (with a default value) to a function is a minor update. Users can start using the new parameter if they want the new behavior, but all old usages remain valid.Important: If a new parameter is added as required (with no default), that breaks existing calls (which would now be missing a required argument), and thus would be a breaking change requiring a major bump (semantic versioning - Does adding a parameter to a function definition require a new major version? - Stack Overflow). So, new parameters must be introduced in a backward-compatible way (optional or with defaults) to qualify as a minor version update.
+Adding New Exported Variables: If the module begins to export a new public variable (for example, a new preference variable or a constant) that wasn’t present before, it’s an additive change. Since no existing variable is removed or changed, existing scripts are unaffected (they simply might not use or know about the new variable). This constitutes a minor version increment. Example: Adding a new $PublicConfig variable that scripts can read is a new feature, bumped in the minor version.
Adding New Classes or Members: Introducing a new public class (exported from the module) or adding new members to an existing exported class in a non-breaking way is a minor change:
+Adding a new method or property to an existing exported class can be considered backward compatible as long as it doesn’t conflict with existing members. Existing scripts constructing or using the class will continue to work as before. (One caveat: if consumers have derived from this class, adding new abstract members would be breaking, but assuming typical usage where classes are used as-is, new members are just additional features.)
+ Example: A class Connection gains a new method TestConnection() in version 1.2. Previous scripts using Connection are not affected (they don’t call the new method), but now have the option to use TestConnection. This is a minor feature addition.
Adding New Enum Values or New Enums: If the module introduces a new enumeration type, or adds additional members to an existing enum, it’s generally treated as a backward-compatible addition:
+Color with values Red/Green/Blue) is additive.New Value in Existing Enum: Adding a value to an existing exported enum can be viewed as a new feature. Code that doesn’t know about the new value isn’t forced to use it. (Existing switch statements or logic that enumerate enum values may not account for it, but they won’t immediately break at runtime; however, developers should update their code to handle the new case if appropriate. Since it doesn’t outright break compilation or invocation in PowerShell, it’s considered backward compatible in this context.)
+ Example: The enum LogLevel had Info, Warning, Error. If we add Verbose as a new level in a minor release, existing scripts using LogLevel continue to run (they might not handle Verbose if encountered, but nothing crashes by the mere presence of the new value). It’s an additive feature, hence a minor bump.
Non-Breaking Changes to Existing Features: In some cases, a change might alter behavior but still be backward compatible. For instance, making an existing parameter accept a new type of input in addition to existing types (broadening what is accepted) could be considered a new capability that doesn’t break old usage. Such changes can fall under minor version if they extend functionality without removal or contradiction of the old behavior. (However, caution is advised: changing behavior can sometimes surprise users. If in doubt, treat as major if it might disrupt assumptions.)
+In summary, any new functionality that does not force existing users to change their usage is a candidate for a minor version increment (Semantic Versioning 2.0.0 | Semantic Versioning). Minor releases accumulate enhancements and new features, signalling to users that new capabilities are available, but all existing scripts should continue to work as they did in the previous version. Users can upgrade to the new minor version and gain new functions or options without needing to modify their existing code. This aligns with the SemVer guideline that “MINOR version [increments] when you add functionality in a backward compatible manner” (Semantic Versioning 2.0.0 | Semantic Versioning).
+A patch version bump is used for changes that do not affect the module’s public API or add new features, but rather fix issues or improve internal implementation. Patch updates are meant to be safe, drop-in updates for users, with no risk of breaking functionality or changing how features are used. Scenarios for a PATCH version increment include:
+Resolving a minor issue where an enum value wasn’t handled in an internal function (assuming no public API change). + As long as the outward-facing contract remains the same (same function name, parameters, outputs), these are patch changes. Consumers might notice the bug is resolved, but they do not need to change their code – they just get the benefit of the fix.
+Performance Improvements: Optimizations that improve the performance or efficiency of the module without affecting the external behavior or API. For instance, rewriting an algorithm inside a function to run faster or use less memory, but with the same input/output interface and results, qualifies as a patch. Users’ experience may improve (faster execution), but they don’t need to change anything in their usage. This is a non-breaking internal improvement.
+Refactoring and Internal Cleanup: Changes to the internal code structure, organization, or quality that do not change any aspect of the public interface or observable behavior fall under patch (or possibly no version change at all – see the next section). If you release a new version that purely refactors code (improves maintainability, updates comments, reorganizes module files) and the module’s exported functions and behavior remain identical, it can be considered a patch update. From the user’s perspective, nothing changed functionally, so there’s no new feature (hence not a minor) and no break (hence not a major). Releasing it as a patch version indicates it’s a minor improvement or maintenance release.
+Documentation or Metadata Updates: If you publish a new version to update documentation included in the module (e.g., help content) or to adjust module metadata (like author info, tags, etc.) without any code change affecting functionality, this would be a patch version increment. (However, often documentation changes alone might not necessitate a new release; if they do, patch is appropriate since the API is unchanged.)
+Note: A patch release should not introduce any new public surface area or change the meaning of anything in the public API. It is strictly for fixes and invisible improvements. According to SemVer rules, “PATCH version when you make backwards-compatible bug fixes” (Semantic Versioning 2.0.0 | Semantic Versioning) – this includes fixes and minor tweaks that do not affect compatibility. Users upgrading from one patch version to the next within the same minor series (e.g., 1.2.3 to 1.2.4) should notice no differences except the resolved issues or performance gains. They do not get new features (and thus don’t need to learn anything new), and they do not have to worry about breaks.
+Certain changes do not require any version number increase at all, because they have no effect on the module’s outward-facing behavior or interface. In a disciplined development practice, if the only changes in a commit or release are purely internal and produce no difference in functionality or API, the version can remain the same. In practice, such changes are often bundled with other changes or released as patch versions if needed. But as a guideline, metadata or refactoring changes that do not impact the exported interface should not influence the version number (they are essentially “no-ops” as far as the user is concerned). Examples:
+Refactoring without Behavioral Changes: If the code is refactored (e.g., splitting a large function into smaller private helper functions, renaming internal variables, improving readability) but the exported functions, classes, and variables all behave exactly the same and have the same signatures, then there’s no need for a version change. The module behaves identically from the consumer’s perspective.
+Build System or Test Changes: Updates to the module’s build scripts, continuous integration configuration, or test suite do not require a version bump. These are changes for the developers/maintainers and do not ship to the user in a way that affects usage.
+Metadata Updates: Changing non-functional metadata such as author name, project URL, licensing info, etc., in the module manifest (PSD1) doesn’t affect how the module is used at runtime. Such changes alone don’t merit a version increment.
+Formatting and Comments: Modifying code formatting, comments, or other non-executable parts of the code has no effect on functionality. No version change is needed for these kinds of modifications alone.
+No-Op Rebuilds: In some cases, a module might be rebuilt or repackaged without any code changes (for example, re-signing the module or packaging it differently). If the contents of the module’s public API and behavior are unchanged, the version number should ideally remain the same. (If a rebuild must be published, one might use the same version or a patch if required by tooling, but from a semantic standpoint, nothing changed.)
+In summary, if a change does not modify or add to the public interface and does not fix a user-facing bug, it should not cause any visible version change. The automated versioning scripts or maintainers should ignore such changes when determining how to bump the version. Essentially, purely internal changes = no bump (or at most a patch if a release is needed for some reason). This ensures the version number reflects meaningful changes that users care about.
+(Note: In practice, every release must have a unique version. So if you are releasing changes that have no API impact, you might still increment the patch to publish it. But the key is that those internal changes by themselves never escalate the version beyond patch, and if they are truly no-ops, you might choose not to release until there’s a user-facing change.)
+This module follows a “latest version” support strategy, meaning that only the most recent release is fully supported and maintained. When a new version is released, it supersedes previous versions. Older versions are not maintained, and users are expected to upgrade to the latest version to receive fixes and new features. As stated in Microsoft’s guidance for PowerShell modules: “Only the latest major version receives full support, including new features, bug fixes, and updates. We strongly recommend upgrading to the latest version…” (Versioning, release cadence, and breaking changes - Microsoft Entra PowerShell | Microsoft Learn). In our context, this means:
+We do not create maintenance releases for older major versions. For example, if the module is currently at 2.x, we will not typically release further updates for 1.x; any fixes or enhancements will go into a new 2.x (or later) release. The focus is on moving forward with the latest version of the module.
+Breaking changes will be introduced only with a major version bump, and when we do increment the major version, users should plan to update their scripts to accommodate those changes. Since older majors won’t get back-ported fixes, upgrading is important to stay supported.
+Minor and patch releases are intended to be safe to adopt (no breaking changes). Users should feel confident updating to a new minor version within the same major series to get new features, and applying patch updates for bug fixes. Given that we don’t maintain parallel old versions, applying these updates is the primary way to get issues resolved.
+Semantic versioning in this module serves as a contract with users: by looking at how the version changed, users can tell what to expect:
+By adhering to this strategy, we ensure clarity and consistency. Users who always upgrade to the latest version will benefit from all improvements and will only need to make script changes when a major version increments (which will be clearly indicated by the version number change).
+To enforce the above rules, we will use custom PowerShell scripts as part of our build/release process to automatically determine the appropriate version bump based on the changes in the module. The automation will compare the module’s exported interface between the current release and the new version under development: +- It will detect additions of public elements (functions, parameters, variables, classes, enum values) and detect removals or changes to public elements. +- Based on this comparison, the script will decide the version increment: + - If new public functions, new optional parameters, or other new exported members are found (and no breaking changes), the script will set the version bump to Minor (since new functionality has been added in a backwards-compatible way). + - If any exported function/variable/class/enum from the previous version is missing in the new version, or a function’s signature has changed incompatibly, etc., the script will flag a Major bump (since a breaking change was detected). + - If no differences in the public API are found (meaning no new features and no removed/changed features), then the changes must be purely fixes or internal improvements. In this case, the script will default to a Patch bump (PowerShell: Automatic Module Semantic Versioning).
+This approach mirrors the “fingerprint” strategy: generating a list (fingerprint) of all public API elements (e.g., FunctionName:ParameterName for each parameter of each function, plus entries for other exported members) for the current and previous version, and comparing them (PowerShell: Automatic Module Semantic Versioning) (PowerShell: Automatic Module Semantic Versioning).
+- If the new fingerprint has entries not present in the old fingerprint, those represent new capabilities (triggering a minor version increase) (PowerShell: Automatic Module Semantic Versioning).
+- If the old fingerprint has entries not present in the new fingerprint, those represent removed or changed items (triggering a major version increase) (PowerShell: Automatic Module Semantic Versioning).
+- If neither additions nor removals are detected, only patch-level changes exist (PowerShell: Automatic Module Semantic Versioning).
Using automation ensures that our versioning rules are applied consistently on every release. However, we will also manually review changes for any subtleties that automation might miss. For example, a change in behavior that is technically backward-compatible in the API surface might still be communicated as a bigger change if it could impact users (the automation might view it as no API change, but maintainers might still choose to bump minor for a significant new behavior or even major if a fix alters expected outcomes in rare cases). The tooling serves as a baseline, and maintainers can override or augment the decision if necessary (but always adhering to the rule that breaking changes cannot be released under a non-major bump).
+Example of the automated logic in practice:
+Suppose in version 1.3.0 the module has a function Get-Data -Path <string> and in the development code we change this to Get-Data -Path <string> -Filter <string>, where -Filter is a new optional parameter. The script compares the exported interface:
+- Old version fingerprint might include an entry like Get-Data:Path for the parameter.
+- New version fingerprint includes Get-Data:Path and Get-Data:Filter.
+The new fingerprint has an entry not in the old (Get-Data:Filter), indicating a new parameter. The old fingerprint has none that the new lacks (we didn’t remove anything; Path is still there). So the tool will identify a new feature addition with no removals, resulting in a Minor bump (1.4.0). This matches our expectation: adding an optional -Filter parameter is a backward-compatible enhancement.
If instead we had removed -Path or renamed Get-Data to Get-ItemData, the old fingerprint would contain entries not in the new, flagging a breaking change. The script would then recommend a Major bump (to 2.0.0), aligning with our policy that such a removal/rename is breaking.
If we only fixed a bug inside Get-Data but made no changes to its parameters or outputs, the fingerprints would be identical. The automation would not find any new or removed public element, and thus default to a Patch bump (1.3.1). This ensures even unseen internal changes result in at least a patch update if a release is made, but nothing more.
This specification provides a clear framework for versioning a PowerShell module in accordance with Semantic Versioning principles, tailored to the specific elements of a PowerShell module’s public interface. By classifying changes into major, minor, or patch categories, we ensure that the module’s version number accurately communicates the impact of changes: +- Major versions for breaking changes (removals, renames, incompatible alterations). +- Minor versions for new features and additions that are backward compatible. +- Patch versions for bug fixes and non-breaking improvements.
+Developers maintaining the module can use these guidelines to decide the appropriate version number for each release. Automated scripts will assist in detecting the scope of changes, but sound judgment will be applied in edge cases. Users of the module can rely on the version number to understand the significance of an update. Ultimately, this practice enables a predictable upgrade path where users only need to be concerned about potential breaking changes when the major version increases, and are otherwise free to take minor and patch updates confidently.
+By adhering to this specification, we uphold a contract of compatibility and improvement with our users, making module releases transparent and manageable in the long run.
+ + + + + + + + + + + + + + + + + + + + + + +This specification documents a scalable GitHub Copilot customization architecture designed to provide consistent guidance, prompts, and chat modes +across multiple repositories in community organizations and enterprises.The architecture addresses the challenge of managing GitHub Copilot +configurations at scale by implementing a multi-tier approach that balances centralized governance with project-specific flexibility. This system +enables organizations to:
+The architecture replaces GitHub Copilot's single-file approach with a structured three-tier system that manages instructions, prompts, and chat modes +through a hierarchical precedence model.
+Modern software organizations require a structured system for managing GitHub Copilot configuration files that enables AI agents to make consistent +changes across multiple repositories while allowing for project-specific customization.
+Due to the absence of native organization-wide configuration support in GitHub that provides a single location for common Copilot configurations, this +architecture implements a scalable multi-tier approach for managing:
+This architecture serves multiple organizational contexts: +- Enterprises: Large organizations needing centralized AI assistance standards across teams and projects +- Enterprise Adoption: Enterprises adopting community frameworks while maintaining their own customizations +- Multi-Division Enterprises: Large organizations with division-specific requirements within enterprise standards +- Community Organizations: Open source projects and community frameworks requiring consistent standards across repositories
+Each Copilot configuration type follows a flexible three-tier management approach:
+This design allows organizations to: +- Enforce enterprise-wide governance and compliance requirements +- Adopt community standards and frameworks as a foundation +- Allow repository-level customization within enterprise and organizational constraints
+The file .github/copilot-instructions.md is not supported in this architecture. This specification replaces the simplified single-file approach with
+ a structured system that manages all GitHub Copilot configuration files through multi-tier management.
The multi-tier Copilot files can be automatically synchronized from different sources:
+Enterprise Tier Synchronization: +- Source: Enterprise's central configuration repository +- Target: Enterprise repositories (optional, based on enterprise policy) +- Content: Enterprise-specific customizations, compliance requirements, security patterns
+Organization Tier Synchronization: +- Source: Community framework or organization's base repository +- Target: All repositories adopting the framework +- Content: Universal patterns and base standards
+Repository Tier Management: +- Source: Local repository maintenance +- Target: Current repository only +- Content: Project-specific overrides and customizations
+The synchronization process applies to all Copilot configuration types:
+- Updates: Files under organization/ and enterprise/ folders are managed by automation
+- Preserves: All files under repository/ folders are never modified by sync mechanisms
+- Flexibility: Organizations can choose which tiers to implement and their synchronization criteria
The .github/ folder contains three Copilot configuration directories, each supporting the three-tier structure:
.github/
+├── instructions/ # AI agent guidance and patterns
+│ ├── enterprise/ # Enterprise-managed customizations (automated sync, optional)
+│ │ ├── main.instructions.md # Enterprise-wide guidelines and compliance
+│ │ └── {Language}/ # Enterprise language-specific patterns
+│ │ ├── main.instructions.md # Enterprise style guides (e.g., C# enterprise standards)
+│ │ └── {context}.instructions.md # Enterprise context requirements
+│ ├── organization/ # Community/framework-managed patterns (automated sync)
+│ │ ├── main.instructions.md # Core framework guidelines
+│ │ └── {Language}/ # Language-specific framework patterns
+│ │ ├── main.instructions.md # Style guide and core instructions
+│ │ └── {context}.instructions.md # Specialized context instructions
+│ └── repository/ # Repository-managed overrides (manual)
+│ ├── main.instructions.md # Repository context and specific rules
+│ └── {Language}/ # Repository-specific language customizations
+│ ├── main.instructions.md # Repository language patterns
+│ └── {context}.instructions.md # Repository context overrides
+├── prompts/ # Reusable prompt templates
+│ ├── enterprise/ # Enterprise-specific prompts (automated sync, optional)
+│ │ └── {prompt-files} # Enterprise-customized prompt templates
+│ ├── organization/ # Community/framework prompts (automated sync)
+│ │ └── {prompt-files} # Standard framework prompt templates
+│ └── repository/ # Repository-specific prompts (manual)
+│ └── {prompt-files} # Project-specific prompt templates
+└── chatmodes/ # Specialized conversation contexts
+ ├── enterprise/ # Enterprise-specific chat modes (automated sync, optional)
+ │ └── {chatmode-files} # Enterprise-customized chat modes
+ ├── organization/ # Community/framework chat modes (automated sync)
+ │ └── {chatmode-files} # Standard framework chat modes
+ └── repository/ # Repository-specific chat modes (manual)
+ └── {chatmode-files} # Project-specific chat modes
+| Configuration Type | +Tier | +File Path | +Management | +Description | +
|---|---|---|---|---|
| Instructions | +Enterprise | +instructions/enterprise/main.instructions.md |
+Enterprise-Managed, Optional | +Enterprise-wide guidelines, compliance requirements, and governance | +
| Instructions | +Enterprise | +instructions/enterprise/{Language}/main.instructions.md |
+Enterprise-Managed, Optional | +Enterprise-specific language standards (e.g., "C# Enterprise coding standards") | +
| Instructions | +Enterprise | +instructions/enterprise/{Language}/{context}.instructions.md |
+Enterprise-Managed, Optional | +Enterprise-specific patterns for compliance, security, or organizational needs | +
| Instructions | +Organization | +instructions/organization/main.instructions.md |
+Community/Framework-Managed | +Universal framework guidelines and architectural principles | +
| Instructions | +Organization | +instructions/organization/{Language}/main.instructions.md |
+Community/Framework-Managed | +Community standard style guides and language-specific patterns | +
| Instructions | +Organization | +instructions/organization/{Language}/{context}.instructions.md |
+Community/Framework-Managed | +Framework-specific patterns for specialized scenarios | +
| Instructions | +Repository | +instructions/repository/main.instructions.md |
+Repository-Managed | +Repository-specific context, technology stack, and project rules | +
| Instructions | +Repository | +instructions/repository/{Language}/main.instructions.md |
+Repository-Managed | +Project-specific language overrides and patterns | +
| Instructions | +Repository | +instructions/repository/{Language}/{context}.instructions.md |
+Repository-Managed | +Most specific project-based overrides | +
| Prompts | +Enterprise | +prompts/enterprise/{name}.prompt.md |
+Enterprise-Managed, Optional | +Enterprise-customized prompt templates incorporating company standards | +
| Prompts | +Organization | +prompts/organization/{name}.prompt.md |
+Community/Framework-Managed | +Standard community prompt templates for common development scenarios | +
| Prompts | +Repository | +prompts/repository/{name}.prompt.md |
+Repository-Managed | +Project-specific prompt templates tailored to repository requirements | +
| Chat Modes | +Enterprise | +chatmodes/enterprise/{name}.chatmode.md |
+Enterprise-Managed, Optional | +Enterprise-specific conversation contexts incorporating company culture and standards | +
| Chat Modes | +Organization | +chatmodes/organization/{name}.chatmode.md |
+Community/Framework-Managed | +Standard conversation contexts and AI behaviors from the community | +
| Chat Modes | +Repository | +chatmodes/repository/{name}.chatmode.md |
+Repository-Managed | +Project-specific conversation contexts and behaviors | +
For instructions, context-specific files may include:
+- File extension patterns: tests.instructions.md, classes.instructions.md
+- Folder-specific patterns: workflows.instructions.md, docs.instructions.md
+- Functional patterns: api.instructions.md, config.instructions.md, compliance.instructions.md
Instructions are evaluated and applied in hierarchical order, with more specific instructions taking precedence:
+instructions/enterprise/main.instructions.md) - Enterprise-wide governance and complianceinstructions/enterprise/{Language}/main.instructions.md) - Enterprise language standardsinstructions/enterprise/{Language}/{context}.instructions.md) - Enterprise specialized requirementsinstructions/organization/main.instructions.md) - Community/framework base patternsinstructions/organization/{Language}/main.instructions.md) - Community language-specific patternsinstructions/organization/{Language}/{context}.instructions.md) - Community specialized patternsinstructions/repository/main.instructions.md) - Project-specific context and overridesinstructions/repository/{Language}/main.instructions.md) - Project-specific language patternsinstructions/repository/{Language}/{context}.instructions.md) - Project-specific customizationsFor prompts and chat modes, the precedence follows the three-tier approach:
+When multiple tiers have the same prompt/chat mode, the enterprise tier takes highest precedence, followed by organization tier, then repository tier.
+Organizations can choose to implement: +- Two-tier: Organization + Repository (skip enterprise tier) +- Three-tier: Organization + Enterprise + Repository (full implementation) +- Enterprise-only: Enterprise + Repository (for enterprises with internal frameworks)
+Repositories transitioning from legacy approaches should:
+.github/copilot-instructions.md).github/ with instructions/, prompts/, and chatmodes/ directoriesenterprise/ folders (if using enterprise tier)repository/main.instructions.md{Language}/ foldersprompts/ and chatmodes/ foldersNote: Organization and enterprise files will be automatically synchronized when implemented, so manual creation is typically not necessary.
+When processing files in repositories using this architecture, AI agents should:
+Repository maintainers should understand:
+Enterprise administrators implementing the enterprise tier should:
+All instruction files must follow this format:
+---
+applyTo: "<glob pattern targeting specific file types>"
+description: "Brief, actionable description of the instruction's purpose"
+---
+Content structure: Context lead, Goal, Execution steps, Behavior rules, Output format, Error handling, Definitions
+Prompt files should follow established GitHub Copilot prompt conventions with clear context and expected outcomes, including tier identification for +provenance tracking.
+Chat mode files should define conversation contexts, specialized behaviors, and interaction patterns following GitHub Copilot chat mode +specifications, with tier identification for configuration management.
+This architecture is guided by the following principles:
+This is a test blog post.
", "image": "https://psmodule.io/docs/assets/images/social/Blog/2024/01/31/test-blog-post.png", "date_modified": "2024-01-31T00:00:00+00:00", "date_published": "2024-01-31T00:00:00+00:00", "authors": [{"name": "Marius Storhaug"}], "tags": null}]} \ No newline at end of file diff --git a/feed_json_updated.json b/feed_json_updated.json new file mode 100644 index 0000000..e7fb96e --- /dev/null +++ b/feed_json_updated.json @@ -0,0 +1 @@ +{"version": "https://jsonfeed.org/version/1.1", "title": "PSModule Docs", "home_page_url": "https://psmodule.io/docs/", "feed_url": "https://psmodule.io/docs/feed_json_updated.json", "description": null, "icon": null, "authors": [], "language": "en", "items": [{"id": "https://psmodule.io/docs/Blog/2024/01/31/test-blog-post/", "url": "https://psmodule.io/docs/Blog/2024/01/31/test-blog-post/", "title": "Test blog post", "content_html": "This is a test blog post.
", "image": "https://psmodule.io/docs/assets/images/social/Blog/2024/01/31/test-blog-post.png", "date_modified": "2024-01-31T00:00:00+00:00", "date_published": "2024-01-31T00:00:00+00:00", "authors": [{"name": "Marius Storhaug"}], "tags": null}]} \ No newline at end of file diff --git a/feed_rss_created.xml b/feed_rss_created.xml new file mode 100644 index 0000000..f53be23 --- /dev/null +++ b/feed_rss_created.xml @@ -0,0 +1 @@ +We empower PowerShell-savvy developers to effortlessly transform their ideas into impactful solutions. Our approach centers around a development framework that allows developers to focus on delivering value through their code. -By leveraging the GitHub platform and PowerShell, we aim to automate the repetitive tasks, enabling developers — whether as consumers or contributors - — to concentrate on coding without distractions. - -## Supported Platforms - -This development framework is built to serve the needs of modern developers and environments. We prioritize supporting the latest Long-Term Servicing -(LTS) version of PowerShell to ensure that we can leverage the most recent features and capabilities, keeping our framework aligned with the demands +By leveraging the GitHub platform and PowerShell, we aim to automate the repetitive tasks, enabling developers — whether as consumers or contributors + — to concentrate on coding without distractions.
+This development framework is built to serve the needs of modern developers and environments. We prioritize supporting the latest Long-Term Servicing +(LTS) version of PowerShell to ensure that we can leverage the most recent features and capabilities, keeping our framework aligned with the demands of today’s development landscape. We assume most of the users of this framework work on modern platforms and have access to the latest versions of -PowerShell or seek to use it to develop solutions intended to run on modern systems, like GitHub Actions, Azure Functions on a developer machine. - -### The Trade-Off: Not Supporting Windows PowerShell - -We’ve made a deliberate choice not to actively persure to support the older Windows PowerShell (5.1) version, as it limits our ability to use the +PowerShell or seek to use it to develop solutions intended to run on modern systems, like GitHub Actions, Azure Functions on a developer machine.
+We’ve made a deliberate choice not to actively persure to support the older Windows PowerShell (5.1) version, as it limits our ability to use the newest PowerShell features. Where its low effort to support Windows PowerShell, we will do so, but we will not actively develop modules for it. While we recognize that some users may still rely on Windows PowerShell 5.1, they can run tools developed in this framework by installing PowerShell 7 alongside it or on remote systems. This decision ensures that this framework can focus on delivering new features for modern development without being constrained by legacy technology, which would otherwize require significant effort to develop and maintain, even if it is available in -the newer versions of PowerShell. - -## Products and projects we focus on - -Our framework is dedicated to advancing the tools and processes that empower modern development and operations teams, with a specific focus on GitHub -as our primary toolstack. We concentrate on the following key areas: - -- PowerShell modules -- GitHub Actions and Workflows -- Serverless applications using Function Apps in Azure - -### PowerShell modules - +the newer versions of PowerShell.
+Our framework is dedicated to advancing the tools and processes that empower modern development and operations teams, with a specific focus on GitHub +as our primary toolstack. We concentrate on the following key areas:
+
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIElzc3VlczwvdGl0bGU+PHBhdGggZD0iTTggOS41YTEuNSAxLjUgMCAxIDAgMC0zIDEuNSAxLjUgMCAwIDAgMCAzWiIgZmlsbD0iIzg0OEQ5NyIvPjxwYXRoIGQ9Ik04IDBhOCA4IDAgMSAxIDAgMTZBOCA4IDAgMCAxIDggMFpNMS41IDhhNi41IDYuNSAwIDEgMCAxMyAwIDYuNSA2LjUgMCAwIDAtMTMgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFB1bGwgUmVxdWVzdHM8L3RpdGxlPjxwYXRoIGQ9Ik0xLjUgMy4yNWEyLjI1IDIuMjUgMCAxIDEgMyAyLjEyMnY1LjI1NmEyLjI1MSAyLjI1MSAwIDEgMS0xLjUgMFY1LjM3MkEyLjI1IDIuMjUgMCAwIDEgMS41IDMuMjVabTUuNjc3LS4xNzdMOS41NzMuNjc3QS4yNS4yNSAwIDAgMSAxMCAuODU0VjIuNWgxQTIuNSAyLjUgMCAwIDEgMTMuNSA1djUuNjI4YTIuMjUxIDIuMjUxIDAgMSAxLTEuNSAwVjVhMSAxIDAgMCAwLTEtMWgtMXYxLjY0NmEuMjUuMjUgMCAwIDEtLjQyNy4xNzdMNy4xNzcgMy40MjdhLjI1LjI1IDAgMCAxIDAtLjM1NFpNMy43NSAyLjVhLjc1Ljc1IDAgMSAwIDAgMS41Ljc1Ljc1IDAgMCAwIDAtMS41Wm0wIDkuNWEuNzUuNzUgMCAxIDAgMCAxLjUuNzUuNzUgMCAwIDAgMC0xLjVabTguMjUuNzVhLjc1Ljc1IDAgMSAwIDEuNSAwIC43NS43NSAwIDAgMC0xLjUgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4NCg==)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFN0YXJzPC90aXRsZT48cGF0aCBkPSJNOCAuMjVhLjc1Ljc1IDAgMCAxIC42NzMuNDE4bDEuODgyIDMuODE1IDQuMjEuNjEyYS43NS43NSAwIDAgMSAuNDE2IDEuMjc5bC0zLjA0NiAyLjk3LjcxOSA0LjE5MmEuNzUxLjc1MSAwIDAgMS0xLjA4OC43OTFMOCAxMi4zNDdsLTMuNzY2IDEuOThhLjc1Ljc1IDAgMCAxLTEuMDg4LS43OWwuNzItNC4xOTRMLjgxOCA2LjM3NGEuNzUuNzUgMCAwIDEgLjQxNi0xLjI4bDQuMjEtLjYxMUw3LjMyNy42NjhBLjc1Ljc1IDAgMCAxIDggLjI1Wm0wIDIuNDQ1TDYuNjE1IDUuNWEuNzUuNzUgMCAwIDEtLjU2NC40MWwtMy4wOTcuNDUgMi4yNCAyLjE4NGEuNzUuNzUgMCAwIDEgLjIxNi42NjRsLS41MjggMy4wODQgMi43NjktMS40NTZhLjc1Ljc1IDAgMCAxIC42OTggMGwyLjc3IDEuNDU2LS41My0zLjA4NGEuNzUuNzUgMCAwIDEgLjIxNi0uNjY0bDIuMjQtMi4xODMtMy4wOTYtLjQ1YS43NS43NSAwIDAgMS0uNTY0LS40MUw4IDIuNjk0WiIgZmlsbD0iIzg0OEQ5NyIvPjwvc3ZnPg==)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFRhZ3M8L3RpdGxlPjxwYXRoIGQ9Ik04IDJjMS45ODEgMCAzLjY3MS45OTIgNC45MzMgMi4wNzggMS4yNyAxLjA5MSAyLjE4NyAyLjM0NSAyLjYzNyAzLjAyM2ExLjYyIDEuNjIgMCAwIDEgMCAxLjc5OGMtLjQ1LjY3OC0xLjM2NyAxLjkzMi0yLjYzNyAzLjAyM0MxMS42NyAxMy4wMDggOS45ODEgMTQgOCAxNGMtMS45ODEgMC0zLjY3MS0uOTkyLTQuOTMzLTIuMDc4QzEuNzk3IDEwLjgzLjg4IDkuNTc2LjQzIDguODk4YTEuNjIgMS42MiAwIDAgMSAwLTEuNzk4Yy40NS0uNjc3IDEuMzY3LTEuOTMxIDIuNjM3LTMuMDIyQzQuMzMgMi45OTIgNi4wMTkgMiA4IDJaTTEuNjc5IDcuOTMyYS4xMi4xMiAwIDAgMCAwIC4xMzZjLjQxMS42MjIgMS4yNDEgMS43NSAyLjM2NiAyLjcxN0M1LjE3NiAxMS43NTggNi41MjcgMTIuNSA4IDEyLjVjMS40NzMgMCAyLjgyNS0uNzQyIDMuOTU1LTEuNzE1IDEuMTI0LS45NjcgMS45NTQtMi4wOTYgMi4zNjYtMi43MTdhLjEyLjEyIDAgMCAwIDAtLjEzNmMtLjQxMi0uNjIxLTEuMjQyLTEuNzUtMi4zNjYtMi43MTdDMTAuODI0IDQuMjQyIDkuNDczIDMuNSA4IDMuNWMtMS40NzMgMC0yLjgyNS43NDItMy45NTUgMS43MTUtMS4xMjQuOTY3LTEuOTU0IDIuMDk2LTIuMzY2IDIuNzE3Wk04IDEwYTIgMiAwIDEgMS0uMDAxLTMuOTk5QTIgMiAwIDAgMSA4IDEwWiIgZmlsbD0iIzg0OEQ5NyIvPjwvc3ZnPg==)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIEZvcmtzPC90aXRsZT48cGF0aCBkPSJNNSA1LjM3MnYuODc4YzAgLjQxNC4zMzYuNzUuNzUuNzVoNC41YS43NS43NSAwIDAgMCAuNzUtLjc1di0uODc4YTIuMjUgMi4yNSAwIDEgMSAxLjUgMHYuODc4YTIuMjUgMi4yNSAwIDAgMS0yLjI1IDIuMjVoLTEuNXYyLjEyOGEyLjI1MSAyLjI1MSAwIDEgMS0xLjUgMFY4LjVoLTEuNUEyLjI1IDIuMjUgMCAwIDEgMy41IDYuMjV2LS44NzhhMi4yNSAyLjI1IDAgMSAxIDEuNSAwWk01IDMuMjVhLjc1Ljc1IDAgMSAwLTEuNSAwIC43NS43NSAwIDAgMCAxLjUgMFptNi43NS43NWEuNzUuNzUgMCAxIDAgMC0xLjUuNzUuNzUgMCAwIDAgMCAxLjVabS0zIDguNzVhLjc1Ljc1IDAgMSAwLTEuNSAwIC43NS43NSAwIDAgMCAxLjUgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyB2aWV3Qm94PSIwIDAgMjQgMjQiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyI+PHBhdGggZD0iTTggMTBDOCA3Ljc5MDg2IDkuNzkwODYgNiAxMiA2QzE0LjIwOTEgNiAxNiA3Ljc5MDg2IDE2IDEwVjExSDE3QzE4LjkzMyAxMSAyMC41IDEyLjU2NyAyMC41IDE0LjVDMjAuNSAxNi40MzMgMTguOTMzIDE4IDE3IDE4SDE2LjlDMTYuMzQ3NyAxOCAxNS45IDE4LjQ0NzcgMTUuOSAxOUMxNS45IDE5LjU1MjMgMTYuMzQ3NyAyMCAxNi45IDIwSDE3QzIwLjAzNzYgMjAgMjIuNSAxNy41Mzc2IDIyLjUgMTQuNUMyMi41IDExLjc3OTMgMjAuNTI0NSA5LjUxOTk3IDE3LjkyOTYgOS4wNzgyNEMxNy40ODYyIDYuMjAyMTMgMTUuMDAwMyA0IDEyIDRDOC45OTk3NCA0IDYuNTEzODEgNi4yMDIxMyA2LjA3MDM2IDkuMDc4MjRDMy40NzU1MSA5LjUxOTk3IDEuNSAxMS43NzkzIDEuNSAxNC41QzEuNSAxNy41Mzc2IDMuOTYyNDMgMjAgNyAyMEg3LjFDNy42NTIyOCAyMCA4LjEgMTkuNTUyMyA4LjEgMTlDOC4xIDE4LjQ0NzcgNy42NTIyOCAxOCA3LjEgMThIN0M1LjA2NyAxOCAzLjUgMTYuNDMzIDMuNSAxNC41QzMuNSAxMi41NjcgNS4wNjcgMTEgNyAxMUg4VjEwWk0xMyAxMUMxMyAxMC40NDc3IDEyLjU1MjMgMTAgMTIgMTBDMTEuNDQ3NyAxMCAxMSAxMC40NDc3IDExIDExVjE2LjU4NThMOS43MDcxMSAxNS4yOTI5QzkuMzE2NTggMTQuOTAyNCA4LjY4MzQyIDE0LjkwMjQgOC4yOTI4OSAxNS4yOTI5QzcuOTAyMzcgMTUuNjgzNCA3LjkwMjM3IDE2LjMxNjYgOC4yOTI4OSAxNi43MDcxTDExLjI5MjkgMTkuNzA3MUMxMS42ODM0IDIwLjA5NzYgMTIuMzE2NiAyMC4wOTc2IDEyLjcwNzEgMTkuNzA3MUwxNS43MDcxIDE2LjcwNzFDMTYuMDk3NiAxNi4zMTY2IDE2LjA5NzYgMTUuNjgzNCAxNS43MDcxIDE1LjI5MjlDMTUuMzE2NiAxNC45MDI0IDE0LjY4MzQgMTQuOTAyNCAxNC4yOTI5IDE1LjI5MjlMMTMgMTYuNTg1OFYxMVoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
+ 
+ 
+ 
&color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIElzc3VlczwvdGl0bGU+PHBhdGggZD0iTTggOS41YTEuNSAxLjUgMCAxIDAgMC0zIDEuNSAxLjUgMCAwIDAgMCAzWiIgZmlsbD0iIzg0OEQ5NyIvPjxwYXRoIGQ9Ik04IDBhOCA4IDAgMSAxIDAgMTZBOCA4IDAgMCAxIDggMFpNMS41IDhhNi41IDYuNSAwIDEgMCAxMyAwIDYuNSA2LjUgMCAwIDAtMTMgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFB1bGwgUmVxdWVzdHM8L3RpdGxlPjxwYXRoIGQ9Ik0xLjUgMy4yNWEyLjI1IDIuMjUgMCAxIDEgMyAyLjEyMnY1LjI1NmEyLjI1MSAyLjI1MSAwIDEgMS0xLjUgMFY1LjM3MkEyLjI1IDIuMjUgMCAwIDEgMS41IDMuMjVabTUuNjc3LS4xNzdMOS41NzMuNjc3QS4yNS4yNSAwIDAgMSAxMCAuODU0VjIuNWgxQTIuNSAyLjUgMCAwIDEgMTMuNSA1djUuNjI4YTIuMjUxIDIuMjUxIDAgMSAxLTEuNSAwVjVhMSAxIDAgMCAwLTEtMWgtMXYxLjY0NmEuMjUuMjUgMCAwIDEtLjQyNy4xNzdMNy4xNzcgMy40MjdhLjI1LjI1IDAgMCAxIDAtLjM1NFpNMy43NSAyLjVhLjc1Ljc1IDAgMSAwIDAgMS41Ljc1Ljc1IDAgMCAwIDAtMS41Wm0wIDkuNWEuNzUuNzUgMCAxIDAgMCAxLjUuNzUuNzUgMCAwIDAgMC0xLjVabTguMjUuNzVhLjc1Ljc1IDAgMSAwIDEuNSAwIC43NS43NSAwIDAgMC0xLjUgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4NCg==)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFN0YXJzPC90aXRsZT48cGF0aCBkPSJNOCAuMjVhLjc1Ljc1IDAgMCAxIC42NzMuNDE4bDEuODgyIDMuODE1IDQuMjEuNjEyYS43NS43NSAwIDAgMSAuNDE2IDEuMjc5bC0zLjA0NiAyLjk3LjcxOSA0LjE5MmEuNzUxLjc1MSAwIDAgMS0xLjA4OC43OTFMOCAxMi4zNDdsLTMuNzY2IDEuOThhLjc1Ljc1IDAgMCAxLTEuMDg4LS43OWwuNzItNC4xOTRMLjgxOCA2LjM3NGEuNzUuNzUgMCAwIDEgLjQxNi0xLjI4bDQuMjEtLjYxMUw3LjMyNy42NjhBLjc1Ljc1IDAgMCAxIDggLjI1Wm0wIDIuNDQ1TDYuNjE1IDUuNWEuNzUuNzUgMCAwIDEtLjU2NC40MWwtMy4wOTcuNDUgMi4yNCAyLjE4NGEuNzUuNzUgMCAwIDEgLjIxNi42NjRsLS41MjggMy4wODQgMi43NjktMS40NTZhLjc1Ljc1IDAgMCAxIC42OTggMGwyLjc3IDEuNDU2LS41My0zLjA4NGEuNzUuNzUgMCAwIDEgLjIxNi0uNjY0bDIuMjQtMi4xODMtMy4wOTYtLjQ1YS43NS43NSAwIDAgMS0uNTY0LS40MUw4IDIuNjk0WiIgZmlsbD0iIzg0OEQ5NyIvPjwvc3ZnPg==)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFRhZ3M8L3RpdGxlPjxwYXRoIGQ9Ik04IDJjMS45ODEgMCAzLjY3MS45OTIgNC45MzMgMi4wNzggMS4yNyAxLjA5MSAyLjE4NyAyLjM0NSAyLjYzNyAzLjAyM2ExLjYyIDEuNjIgMCAwIDEgMCAxLjc5OGMtLjQ1LjY3OC0xLjM2NyAxLjkzMi0yLjYzNyAzLjAyM0MxMS42NyAxMy4wMDggOS45ODEgMTQgOCAxNGMtMS45ODEgMC0zLjY3MS0uOTkyLTQuOTMzLTIuMDc4QzEuNzk3IDEwLjgzLjg4IDkuNTc2LjQzIDguODk4YTEuNjIgMS42MiAwIDAgMSAwLTEuNzk4Yy40NS0uNjc3IDEuMzY3LTEuOTMxIDIuNjM3LTMuMDIyQzQuMzMgMi45OTIgNi4wMTkgMiA4IDJaTTEuNjc5IDcuOTMyYS4xMi4xMiAwIDAgMCAwIC4xMzZjLjQxMS42MjIgMS4yNDEgMS43NSAyLjM2NiAyLjcxN0M1LjE3NiAxMS43NTggNi41MjcgMTIuNSA4IDEyLjVjMS40NzMgMCAyLjgyNS0uNzQyIDMuOTU1LTEuNzE1IDEuMTI0LS45NjcgMS45NTQtMi4wOTYgMi4zNjYtMi43MTdhLjEyLjEyIDAgMCAwIDAtLjEzNmMtLjQxMi0uNjIxLTEuMjQyLTEuNzUtMi4zNjYtMi43MTdDMTAuODI0IDQuMjQyIDkuNDczIDMuNSA4IDMuNWMtMS40NzMgMC0yLjgyNS43NDItMy45NTUgMS43MTUtMS4xMjQuOTY3LTEuOTU0IDIuMDk2LTIuMzY2IDIuNzE3Wk04IDEwYTIgMiAwIDEgMS0uMDAxLTMuOTk5QTIgMiAwIDAgMSA4IDEwWiIgZmlsbD0iIzg0OEQ5NyIvPjwvc3ZnPg==)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIEZvcmtzPC90aXRsZT48cGF0aCBkPSJNNSA1LjM3MnYuODc4YzAgLjQxNC4zMzYuNzUuNzUuNzVoNC41YS43NS43NSAwIDAgMCAuNzUtLjc1di0uODc4YTIuMjUgMi4yNSAwIDEgMSAxLjUgMHYuODc4YTIuMjUgMi4yNSAwIDAgMS0yLjI1IDIuMjVoLTEuNXYyLjEyOGEyLjI1MSAyLjI1MSAwIDEgMS0xLjUgMFY4LjVoLTEuNUEyLjI1IDIuMjUgMCAwIDEgMy41IDYuMjV2LS44NzhhMi4yNSAyLjI1IDAgMSAxIDEuNSAwWk01IDMuMjVhLjc1Ljc1IDAgMSAwLTEuNSAwIC43NS43NSAwIDAgMCAxLjUgMFptNi43NS43NWEuNzUuNzUgMCAxIDAgMC0xLjUuNzUuNzUgMCAwIDAgMCAxLjVabS0zIDguNzVhLjc1Ljc1IDAgMSAwLTEuNSAwIC43NS43NSAwIDAgMCAxLjUgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyB2aWV3Qm94PSIwIDAgMjQgMjQiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyI+PHBhdGggZD0iTTggMTBDOCA3Ljc5MDg2IDkuNzkwODYgNiAxMiA2QzE0LjIwOTEgNiAxNiA3Ljc5MDg2IDE2IDEwVjExSDE3QzE4LjkzMyAxMSAyMC41IDEyLjU2NyAyMC41IDE0LjVDMjAuNSAxNi40MzMgMTguOTMzIDE4IDE3IDE4SDE2LjlDMTYuMzQ3NyAxOCAxNS45IDE4LjQ0NzcgMTUuOSAxOUMxNS45IDE5LjU1MjMgMTYuMzQ3NyAyMCAxNi45IDIwSDE3QzIwLjAzNzYgMjAgMjIuNSAxNy41Mzc2IDIyLjUgMTQuNUMyMi41IDExLjc3OTMgMjAuNTI0NSA5LjUxOTk3IDE3LjkyOTYgOS4wNzgyNEMxNy40ODYyIDYuMjAyMTMgMTUuMDAwMyA0IDEyIDRDOC45OTk3NCA0IDYuNTEzODEgNi4yMDIxMyA2LjA3MDM2IDkuMDc4MjRDMy40NzU1MSA5LjUxOTk3IDEuNSAxMS43NzkzIDEuNSAxNC41QzEuNSAxNy41Mzc2IDMuOTYyNDMgMjAgNyAyMEg3LjFDNy42NTIyOCAyMCA4LjEgMTkuNTUyMyA4LjEgMTlDOC4xIDE4LjQ0NzcgNy42NTIyOCAxOCA3LjEgMThIN0M1LjA2NyAxOCAzLjUgMTYuNDMzIDMuNSAxNC41QzMuNSAxMi41NjcgNS4wNjcgMTEgNyAxMUg4VjEwWk0xMyAxMUMxMyAxMC40NDc3IDEyLjU1MjMgMTAgMTIgMTBDMTEuNDQ3NyAxMCAxMSAxMC40NDc3IDExIDExVjE2LjU4NThMOS43MDcxMSAxNS4yOTI5QzkuMzE2NTggMTQuOTAyNCA4LjY4MzQyIDE0LjkwMjQgOC4yOTI4OSAxNS4yOTI5QzcuOTAyMzcgMTUuNjgzNCA3LjkwMjM3IDE2LjMxNjYgOC4yOTI4OSAxNi43MDcxTDExLjI5MjkgMTkuNzA3MUMxMS42ODM0IDIwLjA5NzYgMTIuMzE2NiAyMC4wOTc2IDEyLjcwNzEgMTkuNzA3MUwxNS43MDcxIDE2LjcwNzFDMTYuMDk3NiAxNi4zMTY2IDE2LjA5NzYgMTUuNjgzNCAxNS43MDcxIDE1LjI5MjlDMTUuMzE2NiAxNC45MDI0IDE0LjY4MzQgMTQuOTAyNCAxNC4yOTI5IDE1LjI5MjlMMTMgMTYuNTg1OFYxMVoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
+ 
+ 
+ 
&color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIElzc3VlczwvdGl0bGU+PHBhdGggZD0iTTggOS41YTEuNSAxLjUgMCAxIDAgMC0zIDEuNSAxLjUgMCAwIDAgMCAzWiIgZmlsbD0iIzg0OEQ5NyIvPjxwYXRoIGQ9Ik04IDBhOCA4IDAgMSAxIDAgMTZBOCA4IDAgMCAxIDggMFpNMS41IDhhNi41IDYuNSAwIDEgMCAxMyAwIDYuNSA2LjUgMCAwIDAtMTMgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFB1bGwgUmVxdWVzdHM8L3RpdGxlPjxwYXRoIGQ9Ik0xLjUgMy4yNWEyLjI1IDIuMjUgMCAxIDEgMyAyLjEyMnY1LjI1NmEyLjI1MSAyLjI1MSAwIDEgMS0xLjUgMFY1LjM3MkEyLjI1IDIuMjUgMCAwIDEgMS41IDMuMjVabTUuNjc3LS4xNzdMOS41NzMuNjc3QS4yNS4yNSAwIDAgMSAxMCAuODU0VjIuNWgxQTIuNSAyLjUgMCAwIDEgMTMuNSA1djUuNjI4YTIuMjUxIDIuMjUxIDAgMSAxLTEuNSAwVjVhMSAxIDAgMCAwLTEtMWgtMXYxLjY0NmEuMjUuMjUgMCAwIDEtLjQyNy4xNzdMNy4xNzcgMy40MjdhLjI1LjI1IDAgMCAxIDAtLjM1NFpNMy43NSAyLjVhLjc1Ljc1IDAgMSAwIDAgMS41Ljc1Ljc1IDAgMCAwIDAtMS41Wm0wIDkuNWEuNzUuNzUgMCAxIDAgMCAxLjUuNzUuNzUgMCAwIDAgMC0xLjVabTguMjUuNzVhLjc1Ljc1IDAgMSAwIDEuNSAwIC43NS43NSAwIDAgMC0xLjUgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4NCg==)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFN0YXJzPC90aXRsZT48cGF0aCBkPSJNOCAuMjVhLjc1Ljc1IDAgMCAxIC42NzMuNDE4bDEuODgyIDMuODE1IDQuMjEuNjEyYS43NS43NSAwIDAgMSAuNDE2IDEuMjc5bC0zLjA0NiAyLjk3LjcxOSA0LjE5MmEuNzUxLjc1MSAwIDAgMS0xLjA4OC43OTFMOCAxMi4zNDdsLTMuNzY2IDEuOThhLjc1Ljc1IDAgMCAxLTEuMDg4LS43OWwuNzItNC4xOTRMLjgxOCA2LjM3NGEuNzUuNzUgMCAwIDEgLjQxNi0xLjI4bDQuMjEtLjYxMUw3LjMyNy42NjhBLjc1Ljc1IDAgMCAxIDggLjI1Wm0wIDIuNDQ1TDYuNjE1IDUuNWEuNzUuNzUgMCAwIDEtLjU2NC40MWwtMy4wOTcuNDUgMi4yNCAyLjE4NGEuNzUuNzUgMCAwIDEgLjIxNi42NjRsLS41MjggMy4wODQgMi43NjktMS40NTZhLjc1Ljc1IDAgMCAxIC42OTggMGwyLjc3IDEuNDU2LS41My0zLjA4NGEuNzUuNzUgMCAwIDEgLjIxNi0uNjY0bDIuMjQtMi4xODMtMy4wOTYtLjQ1YS43NS43NSAwIDAgMS0uNTY0LS40MUw4IDIuNjk0WiIgZmlsbD0iIzg0OEQ5NyIvPjwvc3ZnPg==)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFRhZ3M8L3RpdGxlPjxwYXRoIGQ9Ik04IDJjMS45ODEgMCAzLjY3MS45OTIgNC45MzMgMi4wNzggMS4yNyAxLjA5MSAyLjE4NyAyLjM0NSAyLjYzNyAzLjAyM2ExLjYyIDEuNjIgMCAwIDEgMCAxLjc5OGMtLjQ1LjY3OC0xLjM2NyAxLjkzMi0yLjYzNyAzLjAyM0MxMS42NyAxMy4wMDggOS45ODEgMTQgOCAxNGMtMS45ODEgMC0zLjY3MS0uOTkyLTQuOTMzLTIuMDc4QzEuNzk3IDEwLjgzLjg4IDkuNTc2LjQzIDguODk4YTEuNjIgMS42MiAwIDAgMSAwLTEuNzk4Yy40NS0uNjc3IDEuMzY3LTEuOTMxIDIuNjM3LTMuMDIyQzQuMzMgMi45OTIgNi4wMTkgMiA4IDJaTTEuNjc5IDcuOTMyYS4xMi4xMiAwIDAgMCAwIC4xMzZjLjQxMS42MjIgMS4yNDEgMS43NSAyLjM2NiAyLjcxN0M1LjE3NiAxMS43NTggNi41MjcgMTIuNSA4IDEyLjVjMS40NzMgMCAyLjgyNS0uNzQyIDMuOTU1LTEuNzE1IDEuMTI0LS45NjcgMS45NTQtMi4wOTYgMi4zNjYtMi43MTdhLjEyLjEyIDAgMCAwIDAtLjEzNmMtLjQxMi0uNjIxLTEuMjQyLTEuNzUtMi4zNjYtMi43MTdDMTAuODI0IDQuMjQyIDkuNDczIDMuNSA4IDMuNWMtMS40NzMgMC0yLjgyNS43NDItMy45NTUgMS43MTUtMS4xMjQuOTY3LTEuOTU0IDIuMDk2LTIuMzY2IDIuNzE3Wk04IDEwYTIgMiAwIDEgMS0uMDAxLTMuOTk5QTIgMiAwIDAgMSA4IDEwWiIgZmlsbD0iIzg0OEQ5NyIvPjwvc3ZnPg==)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIEZvcmtzPC90aXRsZT48cGF0aCBkPSJNNSA1LjM3MnYuODc4YzAgLjQxNC4zMzYuNzUuNzUuNzVoNC41YS43NS43NSAwIDAgMCAuNzUtLjc1di0uODc4YTIuMjUgMi4yNSAwIDEgMSAxLjUgMHYuODc4YTIuMjUgMi4yNSAwIDAgMS0yLjI1IDIuMjVoLTEuNXYyLjEyOGEyLjI1MSAyLjI1MSAwIDEgMS0xLjUgMFY4LjVoLTEuNUEyLjI1IDIuMjUgMCAwIDEgMy41IDYuMjV2LS44NzhhMi4yNSAyLjI1IDAgMSAxIDEuNSAwWk01IDMuMjVhLjc1Ljc1IDAgMSAwLTEuNSAwIC43NS43NSAwIDAgMCAxLjUgMFptNi43NS43NWEuNzUuNzUgMCAxIDAgMC0xLjUuNzUuNzUgMCAwIDAgMCAxLjVabS0zIDguNzVhLjc1Ljc1IDAgMSAwLTEuNSAwIC43NS43NSAwIDAgMCAxLjUgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyB2aWV3Qm94PSIwIDAgMjQgMjQiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyI+PHBhdGggZD0iTTggMTBDOCA3Ljc5MDg2IDkuNzkwODYgNiAxMiA2QzE0LjIwOTEgNiAxNiA3Ljc5MDg2IDE2IDEwVjExSDE3QzE4LjkzMyAxMSAyMC41IDEyLjU2NyAyMC41IDE0LjVDMjAuNSAxNi40MzMgMTguOTMzIDE4IDE3IDE4SDE2LjlDMTYuMzQ3NyAxOCAxNS45IDE4LjQ0NzcgMTUuOSAxOUMxNS45IDE5LjU1MjMgMTYuMzQ3NyAyMCAxNi45IDIwSDE3QzIwLjAzNzYgMjAgMjIuNSAxNy41Mzc2IDIyLjUgMTQuNUMyMi41IDExLjc3OTMgMjAuNTI0NSA5LjUxOTk3IDE3LjkyOTYgOS4wNzgyNEMxNy40ODYyIDYuMjAyMTMgMTUuMDAwMyA0IDEyIDRDOC45OTk3NCA0IDYuNTEzODEgNi4yMDIxMyA2LjA3MDM2IDkuMDc4MjRDMy40NzU1MSA5LjUxOTk3IDEuNSAxMS43NzkzIDEuNSAxNC41QzEuNSAxNy41Mzc2IDMuOTYyNDMgMjAgNyAyMEg3LjFDNy42NTIyOCAyMCA4LjEgMTkuNTUyMyA4LjEgMTlDOC4xIDE4LjQ0NzcgNy42NTIyOCAxOCA3LjEgMThIN0M1LjA2NyAxOCAzLjUgMTYuNDMzIDMuNSAxNC41QzMuNSAxMi41NjcgNS4wNjcgMTEgNyAxMUg4VjEwWk0xMyAxMUMxMyAxMC40NDc3IDEyLjU1MjMgMTAgMTIgMTBDMTEuNDQ3NyAxMCAxMSAxMC40NDc3IDExIDExVjE2LjU4NThMOS43MDcxMSAxNS4yOTI5QzkuMzE2NTggMTQuOTAyNCA4LjY4MzQyIDE0LjkwMjQgOC4yOTI4OSAxNS4yOTI5QzcuOTAyMzcgMTUuNjgzNCA3LjkwMjM3IDE2LjMxNjYgOC4yOTI4OSAxNi43MDcxTDExLjI5MjkgMTkuNzA3MUMxMS42ODM0IDIwLjA5NzYgMTIuMzE2NiAyMC4wOTc2IDEyLjcwNzEgMTkuNzA3MUwxNS43MDcxIDE2LjcwNzFDMTYuMDk3NiAxNi4zMTY2IDE2LjA5NzYgMTUuNjgzNCAxNS43MDcxIDE1LjI5MjlDMTUuMzE2NiAxNC45MDI0IDE0LjY4MzQgMTQuOTAyNCAxNC4yOTI5IDE1LjI5MjlMMTMgMTYuNTg1OFYxMVoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
+ 
+ 
+ 
&color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIElzc3VlczwvdGl0bGU+PHBhdGggZD0iTTggOS41YTEuNSAxLjUgMCAxIDAgMC0zIDEuNSAxLjUgMCAwIDAgMCAzWiIgZmlsbD0iIzg0OEQ5NyIvPjxwYXRoIGQ9Ik04IDBhOCA4IDAgMSAxIDAgMTZBOCA4IDAgMCAxIDggMFpNMS41IDhhNi41IDYuNSAwIDEgMCAxMyAwIDYuNSA2LjUgMCAwIDAtMTMgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFB1bGwgUmVxdWVzdHM8L3RpdGxlPjxwYXRoIGQ9Ik0xLjUgMy4yNWEyLjI1IDIuMjUgMCAxIDEgMyAyLjEyMnY1LjI1NmEyLjI1MSAyLjI1MSAwIDEgMS0xLjUgMFY1LjM3MkEyLjI1IDIuMjUgMCAwIDEgMS41IDMuMjVabTUuNjc3LS4xNzdMOS41NzMuNjc3QS4yNS4yNSAwIDAgMSAxMCAuODU0VjIuNWgxQTIuNSAyLjUgMCAwIDEgMTMuNSA1djUuNjI4YTIuMjUxIDIuMjUxIDAgMSAxLTEuNSAwVjVhMSAxIDAgMCAwLTEtMWgtMXYxLjY0NmEuMjUuMjUgMCAwIDEtLjQyNy4xNzdMNy4xNzcgMy40MjdhLjI1LjI1IDAgMCAxIDAtLjM1NFpNMy43NSAyLjVhLjc1Ljc1IDAgMSAwIDAgMS41Ljc1Ljc1IDAgMCAwIDAtMS41Wm0wIDkuNWEuNzUuNzUgMCAxIDAgMCAxLjUuNzUuNzUgMCAwIDAgMC0xLjVabTguMjUuNzVhLjc1Ljc1IDAgMSAwIDEuNSAwIC43NS43NSAwIDAgMC0xLjUgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4NCg==)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFN0YXJzPC90aXRsZT48cGF0aCBkPSJNOCAuMjVhLjc1Ljc1IDAgMCAxIC42NzMuNDE4bDEuODgyIDMuODE1IDQuMjEuNjEyYS43NS43NSAwIDAgMSAuNDE2IDEuMjc5bC0zLjA0NiAyLjk3LjcxOSA0LjE5MmEuNzUxLjc1MSAwIDAgMS0xLjA4OC43OTFMOCAxMi4zNDdsLTMuNzY2IDEuOThhLjc1Ljc1IDAgMCAxLTEuMDg4LS43OWwuNzItNC4xOTRMLjgxOCA2LjM3NGEuNzUuNzUgMCAwIDEgLjQxNi0xLjI4bDQuMjEtLjYxMUw3LjMyNy42NjhBLjc1Ljc1IDAgMCAxIDggLjI1Wm0wIDIuNDQ1TDYuNjE1IDUuNWEuNzUuNzUgMCAwIDEtLjU2NC40MWwtMy4wOTcuNDUgMi4yNCAyLjE4NGEuNzUuNzUgMCAwIDEgLjIxNi42NjRsLS41MjggMy4wODQgMi43NjktMS40NTZhLjc1Ljc1IDAgMCAxIC42OTggMGwyLjc3IDEuNDU2LS41My0zLjA4NGEuNzUuNzUgMCAwIDEgLjIxNi0uNjY0bDIuMjQtMi4xODMtMy4wOTYtLjQ1YS43NS43NSAwIDAgMS0uNTY0LS40MUw4IDIuNjk0WiIgZmlsbD0iIzg0OEQ5NyIvPjwvc3ZnPg==)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFRhZ3M8L3RpdGxlPjxwYXRoIGQ9Ik04IDJjMS45ODEgMCAzLjY3MS45OTIgNC45MzMgMi4wNzggMS4yNyAxLjA5MSAyLjE4NyAyLjM0NSAyLjYzNyAzLjAyM2ExLjYyIDEuNjIgMCAwIDEgMCAxLjc5OGMtLjQ1LjY3OC0xLjM2NyAxLjkzMi0yLjYzNyAzLjAyM0MxMS42NyAxMy4wMDggOS45ODEgMTQgOCAxNGMtMS45ODEgMC0zLjY3MS0uOTkyLTQuOTMzLTIuMDc4QzEuNzk3IDEwLjgzLjg4IDkuNTc2LjQzIDguODk4YTEuNjIgMS42MiAwIDAgMSAwLTEuNzk4Yy40NS0uNjc3IDEuMzY3LTEuOTMxIDIuNjM3LTMuMDIyQzQuMzMgMi45OTIgNi4wMTkgMiA4IDJaTTEuNjc5IDcuOTMyYS4xMi4xMiAwIDAgMCAwIC4xMzZjLjQxMS42MjIgMS4yNDEgMS43NSAyLjM2NiAyLjcxN0M1LjE3NiAxMS43NTggNi41MjcgMTIuNSA4IDEyLjVjMS40NzMgMCAyLjgyNS0uNzQyIDMuOTU1LTEuNzE1IDEuMTI0LS45NjcgMS45NTQtMi4wOTYgMi4zNjYtMi43MTdhLjEyLjEyIDAgMCAwIDAtLjEzNmMtLjQxMi0uNjIxLTEuMjQyLTEuNzUtMi4zNjYtMi43MTdDMTAuODI0IDQuMjQyIDkuNDczIDMuNSA4IDMuNWMtMS40NzMgMC0yLjgyNS43NDItMy45NTUgMS43MTUtMS4xMjQuOTY3LTEuOTU0IDIuMDk2LTIuMzY2IDIuNzE3Wk04IDEwYTIgMiAwIDEgMS0uMDAxLTMuOTk5QTIgMiAwIDAgMSA4IDEwWiIgZmlsbD0iIzg0OEQ5NyIvPjwvc3ZnPg==)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIEZvcmtzPC90aXRsZT48cGF0aCBkPSJNNSA1LjM3MnYuODc4YzAgLjQxNC4zMzYuNzUuNzUuNzVoNC41YS43NS43NSAwIDAgMCAuNzUtLjc1di0uODc4YTIuMjUgMi4yNSAwIDEgMSAxLjUgMHYuODc4YTIuMjUgMi4yNSAwIDAgMS0yLjI1IDIuMjVoLTEuNXYyLjEyOGEyLjI1MSAyLjI1MSAwIDEgMS0xLjUgMFY4LjVoLTEuNUEyLjI1IDIuMjUgMCAwIDEgMy41IDYuMjV2LS44NzhhMi4yNSAyLjI1IDAgMSAxIDEuNSAwWk01IDMuMjVhLjc1Ljc1IDAgMSAwLTEuNSAwIC43NS43NSAwIDAgMCAxLjUgMFptNi43NS43NWEuNzUuNzUgMCAxIDAgMC0xLjUuNzUuNzUgMCAwIDAgMCAxLjVabS0zIDguNzVhLjc1Ljc1IDAgMSAwLTEuNSAwIC43NS43NSAwIDAgMCAxLjUgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyB2aWV3Qm94PSIwIDAgMjQgMjQiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyI+PHBhdGggZD0iTTggMTBDOCA3Ljc5MDg2IDkuNzkwODYgNiAxMiA2QzE0LjIwOTEgNiAxNiA3Ljc5MDg2IDE2IDEwVjExSDE3QzE4LjkzMyAxMSAyMC41IDEyLjU2NyAyMC41IDE0LjVDMjAuNSAxNi40MzMgMTguOTMzIDE4IDE3IDE4SDE2LjlDMTYuMzQ3NyAxOCAxNS45IDE4LjQ0NzcgMTUuOSAxOUMxNS45IDE5LjU1MjMgMTYuMzQ3NyAyMCAxNi45IDIwSDE3QzIwLjAzNzYgMjAgMjIuNSAxNy41Mzc2IDIyLjUgMTQuNUMyMi41IDExLjc3OTMgMjAuNTI0NSA5LjUxOTk3IDE3LjkyOTYgOS4wNzgyNEMxNy40ODYyIDYuMjAyMTMgMTUuMDAwMyA0IDEyIDRDOC45OTk3NCA0IDYuNTEzODEgNi4yMDIxMyA2LjA3MDM2IDkuMDc4MjRDMy40NzU1MSA5LjUxOTk3IDEuNSAxMS43NzkzIDEuNSAxNC41QzEuNSAxNy41Mzc2IDMuOTYyNDMgMjAgNyAyMEg3LjFDNy42NTIyOCAyMCA4LjEgMTkuNTUyMyA4LjEgMTlDOC4xIDE4LjQ0NzcgNy42NTIyOCAxOCA3LjEgMThIN0M1LjA2NyAxOCAzLjUgMTYuNDMzIDMuNSAxNC41QzMuNSAxMi41NjcgNS4wNjcgMTEgNyAxMUg4VjEwWk0xMyAxMUMxMyAxMC40NDc3IDEyLjU1MjMgMTAgMTIgMTBDMTEuNDQ3NyAxMCAxMSAxMC40NDc3IDExIDExVjE2LjU4NThMOS43MDcxMSAxNS4yOTI5QzkuMzE2NTggMTQuOTAyNCA4LjY4MzQyIDE0LjkwMjQgOC4yOTI4OSAxNS4yOTI5QzcuOTAyMzcgMTUuNjgzNCA3LjkwMjM3IDE2LjMxNjYgOC4yOTI4OSAxNi43MDcxTDExLjI5MjkgMTkuNzA3MUMxMS42ODM0IDIwLjA5NzYgMTIuMzE2NiAyMC4wOTc2IDEyLjcwNzEgMTkuNzA3MUwxNS43MDcxIDE2LjcwNzFDMTYuMDk3NiAxNi4zMTY2IDE2LjA5NzYgMTUuNjgzNCAxNS43MDcxIDE1LjI5MjlDMTUuMzE2NiAxNC45MDI0IDE0LjY4MzQgMTQuOTAyNCAxNC4yOTI5IDE1LjI5MjlMMTMgMTYuNTg1OFYxMVoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
+ 
+ 
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIElzc3VlczwvdGl0bGU+PHBhdGggZD0iTTggOS41YTEuNSAxLjUgMCAxIDAgMC0zIDEuNSAxLjUgMCAwIDAgMCAzWiIgZmlsbD0iIzg0OEQ5NyIvPjxwYXRoIGQ9Ik04IDBhOCA4IDAgMSAxIDAgMTZBOCA4IDAgMCAxIDggMFpNMS41IDhhNi41IDYuNSAwIDEgMCAxMyAwIDYuNSA2LjUgMCAwIDAtMTMgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFB1bGwgUmVxdWVzdHM8L3RpdGxlPjxwYXRoIGQ9Ik0xLjUgMy4yNWEyLjI1IDIuMjUgMCAxIDEgMyAyLjEyMnY1LjI1NmEyLjI1MSAyLjI1MSAwIDEgMS0xLjUgMFY1LjM3MkEyLjI1IDIuMjUgMCAwIDEgMS41IDMuMjVabTUuNjc3LS4xNzdMOS41NzMuNjc3QS4yNS4yNSAwIDAgMSAxMCAuODU0VjIuNWgxQTIuNSAyLjUgMCAwIDEgMTMuNSA1djUuNjI4YTIuMjUxIDIuMjUxIDAgMSAxLTEuNSAwVjVhMSAxIDAgMCAwLTEtMWgtMXYxLjY0NmEuMjUuMjUgMCAwIDEtLjQyNy4xNzdMNy4xNzcgMy40MjdhLjI1LjI1IDAgMCAxIDAtLjM1NFpNMy43NSAyLjVhLjc1Ljc1IDAgMSAwIDAgMS41Ljc1Ljc1IDAgMCAwIDAtMS41Wm0wIDkuNWEuNzUuNzUgMCAxIDAgMCAxLjUuNzUuNzUgMCAwIDAgMC0xLjVabTguMjUuNzVhLjc1Ljc1IDAgMSAwIDEuNSAwIC43NS43NSAwIDAgMC0xLjUgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4NCg==)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFN0YXJzPC90aXRsZT48cGF0aCBkPSJNOCAuMjVhLjc1Ljc1IDAgMCAxIC42NzMuNDE4bDEuODgyIDMuODE1IDQuMjEuNjEyYS43NS43NSAwIDAgMSAuNDE2IDEuMjc5bC0zLjA0NiAyLjk3LjcxOSA0LjE5MmEuNzUxLjc1MSAwIDAgMS0xLjA4OC43OTFMOCAxMi4zNDdsLTMuNzY2IDEuOThhLjc1Ljc1IDAgMCAxLTEuMDg4LS43OWwuNzItNC4xOTRMLjgxOCA2LjM3NGEuNzUuNzUgMCAwIDEgLjQxNi0xLjI4bDQuMjEtLjYxMUw3LjMyNy42NjhBLjc1Ljc1IDAgMCAxIDggLjI1Wm0wIDIuNDQ1TDYuNjE1IDUuNWEuNzUuNzUgMCAwIDEtLjU2NC40MWwtMy4wOTcuNDUgMi4yNCAyLjE4NGEuNzUuNzUgMCAwIDEgLjIxNi42NjRsLS41MjggMy4wODQgMi43NjktMS40NTZhLjc1Ljc1IDAgMCAxIC42OTggMGwyLjc3IDEuNDU2LS41My0zLjA4NGEuNzUuNzUgMCAwIDEgLjIxNi0uNjY0bDIuMjQtMi4xODMtMy4wOTYtLjQ1YS43NS43NSAwIDAgMS0uNTY0LS40MUw4IDIuNjk0WiIgZmlsbD0iIzg0OEQ5NyIvPjwvc3ZnPg==)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFRhZ3M8L3RpdGxlPjxwYXRoIGQ9Ik04IDJjMS45ODEgMCAzLjY3MS45OTIgNC45MzMgMi4wNzggMS4yNyAxLjA5MSAyLjE4NyAyLjM0NSAyLjYzNyAzLjAyM2ExLjYyIDEuNjIgMCAwIDEgMCAxLjc5OGMtLjQ1LjY3OC0xLjM2NyAxLjkzMi0yLjYzNyAzLjAyM0MxMS42NyAxMy4wMDggOS45ODEgMTQgOCAxNGMtMS45ODEgMC0zLjY3MS0uOTkyLTQuOTMzLTIuMDc4QzEuNzk3IDEwLjgzLjg4IDkuNTc2LjQzIDguODk4YTEuNjIgMS42MiAwIDAgMSAwLTEuNzk4Yy40NS0uNjc3IDEuMzY3LTEuOTMxIDIuNjM3LTMuMDIyQzQuMzMgMi45OTIgNi4wMTkgMiA4IDJaTTEuNjc5IDcuOTMyYS4xMi4xMiAwIDAgMCAwIC4xMzZjLjQxMS42MjIgMS4yNDEgMS43NSAyLjM2NiAyLjcxN0M1LjE3NiAxMS43NTggNi41MjcgMTIuNSA4IDEyLjVjMS40NzMgMCAyLjgyNS0uNzQyIDMuOTU1LTEuNzE1IDEuMTI0LS45NjcgMS45NTQtMi4wOTYgMi4zNjYtMi43MTdhLjEyLjEyIDAgMCAwIDAtLjEzNmMtLjQxMi0uNjIxLTEuMjQyLTEuNzUtMi4zNjYtMi43MTdDMTAuODI0IDQuMjQyIDkuNDczIDMuNSA4IDMuNWMtMS40NzMgMC0yLjgyNS43NDItMy45NTUgMS43MTUtMS4xMjQuOTY3LTEuOTU0IDIuMDk2LTIuMzY2IDIuNzE3Wk04IDEwYTIgMiAwIDEgMS0uMDAxLTMuOTk5QTIgMiAwIDAgMSA4IDEwWiIgZmlsbD0iIzg0OEQ5NyIvPjwvc3ZnPg==)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIEZvcmtzPC90aXRsZT48cGF0aCBkPSJNNSA1LjM3MnYuODc4YzAgLjQxNC4zMzYuNzUuNzUuNzVoNC41YS43NS43NSAwIDAgMCAuNzUtLjc1di0uODc4YTIuMjUgMi4yNSAwIDEgMSAxLjUgMHYuODc4YTIuMjUgMi4yNSAwIDAgMS0yLjI1IDIuMjVoLTEuNXYyLjEyOGEyLjI1MSAyLjI1MSAwIDEgMS0xLjUgMFY4LjVoLTEuNUEyLjI1IDIuMjUgMCAwIDEgMy41IDYuMjV2LS44NzhhMi4yNSAyLjI1IDAgMSAxIDEuNSAwWk01IDMuMjVhLjc1Ljc1IDAgMSAwLTEuNSAwIC43NS43NSAwIDAgMCAxLjUgMFptNi43NS43NWEuNzUuNzUgMCAxIDAgMC0xLjUuNzUuNzUgMCAwIDAgMCAxLjVabS0zIDguNzVhLjc1Ljc1IDAgMSAwLTEuNSAwIC43NS43NSAwIDAgMCAxLjUgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyB2aWV3Qm94PSIwIDAgMjQgMjQiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyI+PHBhdGggZD0iTTggMTBDOCA3Ljc5MDg2IDkuNzkwODYgNiAxMiA2QzE0LjIwOTEgNiAxNiA3Ljc5MDg2IDE2IDEwVjExSDE3QzE4LjkzMyAxMSAyMC41IDEyLjU2NyAyMC41IDE0LjVDMjAuNSAxNi40MzMgMTguOTMzIDE4IDE3IDE4SDE2LjlDMTYuMzQ3NyAxOCAxNS45IDE4LjQ0NzcgMTUuOSAxOUMxNS45IDE5LjU1MjMgMTYuMzQ3NyAyMCAxNi45IDIwSDE3QzIwLjAzNzYgMjAgMjIuNSAxNy41Mzc2IDIyLjUgMTQuNUMyMi41IDExLjc3OTMgMjAuNTI0NSA5LjUxOTk3IDE3LjkyOTYgOS4wNzgyNEMxNy40ODYyIDYuMjAyMTMgMTUuMDAwMyA0IDEyIDRDOC45OTk3NCA0IDYuNTEzODEgNi4yMDIxMyA2LjA3MDM2IDkuMDc4MjRDMy40NzU1MSA5LjUxOTk3IDEuNSAxMS43NzkzIDEuNSAxNC41QzEuNSAxNy41Mzc2IDMuOTYyNDMgMjAgNyAyMEg3LjFDNy42NTIyOCAyMCA4LjEgMTkuNTUyMyA4LjEgMTlDOC4xIDE4LjQ0NzcgNy42NTIyOCAxOCA3LjEgMThIN0M1LjA2NyAxOCAzLjUgMTYuNDMzIDMuNSAxNC41QzMuNSAxMi41NjcgNS4wNjcgMTEgNyAxMUg4VjEwWk0xMyAxMUMxMyAxMC40NDc3IDEyLjU1MjMgMTAgMTIgMTBDMTEuNDQ3NyAxMCAxMSAxMC40NDc3IDExIDExVjE2LjU4NThMOS43MDcxMSAxNS4yOTI5QzkuMzE2NTggMTQuOTAyNCA4LjY4MzQyIDE0LjkwMjQgOC4yOTI4OSAxNS4yOTI5QzcuOTAyMzcgMTUuNjgzNCA3LjkwMjM3IDE2LjMxNjYgOC4yOTI4OSAxNi43MDcxTDExLjI5MjkgMTkuNzA3MUMxMS42ODM0IDIwLjA5NzYgMTIuMzE2NiAyMC4wOTc2IDEyLjcwNzEgMTkuNzA3MUwxNS43MDcxIDE2LjcwNzFDMTYuMDk3NiAxNi4zMTY2IDE2LjA5NzYgMTUuNjgzNCAxNS43MDcxIDE1LjI5MjlDMTUuMzE2NiAxNC45MDI0IDE0LjY4MzQgMTQuOTAyNCAxNC4yOTI5IDE1LjI5MjlMMTMgMTYuNTg1OFYxMVoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
+ 
+ 
+ 
&color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIElzc3VlczwvdGl0bGU+PHBhdGggZD0iTTggOS41YTEuNSAxLjUgMCAxIDAgMC0zIDEuNSAxLjUgMCAwIDAgMCAzWiIgZmlsbD0iIzg0OEQ5NyIvPjxwYXRoIGQ9Ik04IDBhOCA4IDAgMSAxIDAgMTZBOCA4IDAgMCAxIDggMFpNMS41IDhhNi41IDYuNSAwIDEgMCAxMyAwIDYuNSA2LjUgMCAwIDAtMTMgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFB1bGwgUmVxdWVzdHM8L3RpdGxlPjxwYXRoIGQ9Ik0xLjUgMy4yNWEyLjI1IDIuMjUgMCAxIDEgMyAyLjEyMnY1LjI1NmEyLjI1MSAyLjI1MSAwIDEgMS0xLjUgMFY1LjM3MkEyLjI1IDIuMjUgMCAwIDEgMS41IDMuMjVabTUuNjc3LS4xNzdMOS41NzMuNjc3QS4yNS4yNSAwIDAgMSAxMCAuODU0VjIuNWgxQTIuNSAyLjUgMCAwIDEgMTMuNSA1djUuNjI4YTIuMjUxIDIuMjUxIDAgMSAxLTEuNSAwVjVhMSAxIDAgMCAwLTEtMWgtMXYxLjY0NmEuMjUuMjUgMCAwIDEtLjQyNy4xNzdMNy4xNzcgMy40MjdhLjI1LjI1IDAgMCAxIDAtLjM1NFpNMy43NSAyLjVhLjc1Ljc1IDAgMSAwIDAgMS41Ljc1Ljc1IDAgMCAwIDAtMS41Wm0wIDkuNWEuNzUuNzUgMCAxIDAgMCAxLjUuNzUuNzUgMCAwIDAgMC0xLjVabTguMjUuNzVhLjc1Ljc1IDAgMSAwIDEuNSAwIC43NS43NSAwIDAgMC0xLjUgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4NCg==)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFN0YXJzPC90aXRsZT48cGF0aCBkPSJNOCAuMjVhLjc1Ljc1IDAgMCAxIC42NzMuNDE4bDEuODgyIDMuODE1IDQuMjEuNjEyYS43NS43NSAwIDAgMSAuNDE2IDEuMjc5bC0zLjA0NiAyLjk3LjcxOSA0LjE5MmEuNzUxLjc1MSAwIDAgMS0xLjA4OC43OTFMOCAxMi4zNDdsLTMuNzY2IDEuOThhLjc1Ljc1IDAgMCAxLTEuMDg4LS43OWwuNzItNC4xOTRMLjgxOCA2LjM3NGEuNzUuNzUgMCAwIDEgLjQxNi0xLjI4bDQuMjEtLjYxMUw3LjMyNy42NjhBLjc1Ljc1IDAgMCAxIDggLjI1Wm0wIDIuNDQ1TDYuNjE1IDUuNWEuNzUuNzUgMCAwIDEtLjU2NC40MWwtMy4wOTcuNDUgMi4yNCAyLjE4NGEuNzUuNzUgMCAwIDEgLjIxNi42NjRsLS41MjggMy4wODQgMi43NjktMS40NTZhLjc1Ljc1IDAgMCAxIC42OTggMGwyLjc3IDEuNDU2LS41My0zLjA4NGEuNzUuNzUgMCAwIDEgLjIxNi0uNjY0bDIuMjQtMi4xODMtMy4wOTYtLjQ1YS43NS43NSAwIDAgMS0uNTY0LS40MUw4IDIuNjk0WiIgZmlsbD0iIzg0OEQ5NyIvPjwvc3ZnPg==)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFRhZ3M8L3RpdGxlPjxwYXRoIGQ9Ik04IDJjMS45ODEgMCAzLjY3MS45OTIgNC45MzMgMi4wNzggMS4yNyAxLjA5MSAyLjE4NyAyLjM0NSAyLjYzNyAzLjAyM2ExLjYyIDEuNjIgMCAwIDEgMCAxLjc5OGMtLjQ1LjY3OC0xLjM2NyAxLjkzMi0yLjYzNyAzLjAyM0MxMS42NyAxMy4wMDggOS45ODEgMTQgOCAxNGMtMS45ODEgMC0zLjY3MS0uOTkyLTQuOTMzLTIuMDc4QzEuNzk3IDEwLjgzLjg4IDkuNTc2LjQzIDguODk4YTEuNjIgMS42MiAwIDAgMSAwLTEuNzk4Yy40NS0uNjc3IDEuMzY3LTEuOTMxIDIuNjM3LTMuMDIyQzQuMzMgMi45OTIgNi4wMTkgMiA4IDJaTTEuNjc5IDcuOTMyYS4xMi4xMiAwIDAgMCAwIC4xMzZjLjQxMS42MjIgMS4yNDEgMS43NSAyLjM2NiAyLjcxN0M1LjE3NiAxMS43NTggNi41MjcgMTIuNSA4IDEyLjVjMS40NzMgMCAyLjgyNS0uNzQyIDMuOTU1LTEuNzE1IDEuMTI0LS45NjcgMS45NTQtMi4wOTYgMi4zNjYtMi43MTdhLjEyLjEyIDAgMCAwIDAtLjEzNmMtLjQxMi0uNjIxLTEuMjQyLTEuNzUtMi4zNjYtMi43MTdDMTAuODI0IDQuMjQyIDkuNDczIDMuNSA4IDMuNWMtMS40NzMgMC0yLjgyNS43NDItMy45NTUgMS43MTUtMS4xMjQuOTY3LTEuOTU0IDIuMDk2LTIuMzY2IDIuNzE3Wk04IDEwYTIgMiAwIDEgMS0uMDAxLTMuOTk5QTIgMiAwIDAgMSA4IDEwWiIgZmlsbD0iIzg0OEQ5NyIvPjwvc3ZnPg==)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIEZvcmtzPC90aXRsZT48cGF0aCBkPSJNNSA1LjM3MnYuODc4YzAgLjQxNC4zMzYuNzUuNzUuNzVoNC41YS43NS43NSAwIDAgMCAuNzUtLjc1di0uODc4YTIuMjUgMi4yNSAwIDEgMSAxLjUgMHYuODc4YTIuMjUgMi4yNSAwIDAgMS0yLjI1IDIuMjVoLTEuNXYyLjEyOGEyLjI1MSAyLjI1MSAwIDEgMS0xLjUgMFY4LjVoLTEuNUEyLjI1IDIuMjUgMCAwIDEgMy41IDYuMjV2LS44NzhhMi4yNSAyLjI1IDAgMSAxIDEuNSAwWk01IDMuMjVhLjc1Ljc1IDAgMSAwLTEuNSAwIC43NS43NSAwIDAgMCAxLjUgMFptNi43NS43NWEuNzUuNzUgMCAxIDAgMC0xLjUuNzUuNzUgMCAwIDAgMCAxLjVabS0zIDguNzVhLjc1Ljc1IDAgMSAwLTEuNSAwIC43NS43NSAwIDAgMCAxLjUgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyB2aWV3Qm94PSIwIDAgMjQgMjQiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyI+PHBhdGggZD0iTTggMTBDOCA3Ljc5MDg2IDkuNzkwODYgNiAxMiA2QzE0LjIwOTEgNiAxNiA3Ljc5MDg2IDE2IDEwVjExSDE3QzE4LjkzMyAxMSAyMC41IDEyLjU2NyAyMC41IDE0LjVDMjAuNSAxNi40MzMgMTguOTMzIDE4IDE3IDE4SDE2LjlDMTYuMzQ3NyAxOCAxNS45IDE4LjQ0NzcgMTUuOSAxOUMxNS45IDE5LjU1MjMgMTYuMzQ3NyAyMCAxNi45IDIwSDE3QzIwLjAzNzYgMjAgMjIuNSAxNy41Mzc2IDIyLjUgMTQuNUMyMi41IDExLjc3OTMgMjAuNTI0NSA5LjUxOTk3IDE3LjkyOTYgOS4wNzgyNEMxNy40ODYyIDYuMjAyMTMgMTUuMDAwMyA0IDEyIDRDOC45OTk3NCA0IDYuNTEzODEgNi4yMDIxMyA2LjA3MDM2IDkuMDc4MjRDMy40NzU1MSA5LjUxOTk3IDEuNSAxMS43NzkzIDEuNSAxNC41QzEuNSAxNy41Mzc2IDMuOTYyNDMgMjAgNyAyMEg3LjFDNy42NTIyOCAyMCA4LjEgMTkuNTUyMyA4LjEgMTlDOC4xIDE4LjQ0NzcgNy42NTIyOCAxOCA3LjEgMThIN0M1LjA2NyAxOCAzLjUgMTYuNDMzIDMuNSAxNC41QzMuNSAxMi41NjcgNS4wNjcgMTEgNyAxMUg4VjEwWk0xMyAxMUMxMyAxMC40NDc3IDEyLjU1MjMgMTAgMTIgMTBDMTEuNDQ3NyAxMCAxMSAxMC40NDc3IDExIDExVjE2LjU4NThMOS43MDcxMSAxNS4yOTI5QzkuMzE2NTggMTQuOTAyNCA4LjY4MzQyIDE0LjkwMjQgOC4yOTI4OSAxNS4yOTI5QzcuOTAyMzcgMTUuNjgzNCA3LjkwMjM3IDE2LjMxNjYgOC4yOTI4OSAxNi43MDcxTDExLjI5MjkgMTkuNzA3MUMxMS42ODM0IDIwLjA5NzYgMTIuMzE2NiAyMC4wOTc2IDEyLjcwNzEgMTkuNzA3MUwxNS43MDcxIDE2LjcwNzFDMTYuMDk3NiAxNi4zMTY2IDE2LjA5NzYgMTUuNjgzNCAxNS43MDcxIDE1LjI5MjlDMTUuMzE2NiAxNC45MDI0IDE0LjY4MzQgMTQuOTAyNCAxNC4yOTI5IDE1LjI5MjlMMTMgMTYuNTg1OFYxMVoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
+ 
+ 
+ 
&color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIElzc3VlczwvdGl0bGU+PHBhdGggZD0iTTggOS41YTEuNSAxLjUgMCAxIDAgMC0zIDEuNSAxLjUgMCAwIDAgMCAzWiIgZmlsbD0iIzg0OEQ5NyIvPjxwYXRoIGQ9Ik04IDBhOCA4IDAgMSAxIDAgMTZBOCA4IDAgMCAxIDggMFpNMS41IDhhNi41IDYuNSAwIDEgMCAxMyAwIDYuNSA2LjUgMCAwIDAtMTMgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFB1bGwgUmVxdWVzdHM8L3RpdGxlPjxwYXRoIGQ9Ik0xLjUgMy4yNWEyLjI1IDIuMjUgMCAxIDEgMyAyLjEyMnY1LjI1NmEyLjI1MSAyLjI1MSAwIDEgMS0xLjUgMFY1LjM3MkEyLjI1IDIuMjUgMCAwIDEgMS41IDMuMjVabTUuNjc3LS4xNzdMOS41NzMuNjc3QS4yNS4yNSAwIDAgMSAxMCAuODU0VjIuNWgxQTIuNSAyLjUgMCAwIDEgMTMuNSA1djUuNjI4YTIuMjUxIDIuMjUxIDAgMSAxLTEuNSAwVjVhMSAxIDAgMCAwLTEtMWgtMXYxLjY0NmEuMjUuMjUgMCAwIDEtLjQyNy4xNzdMNy4xNzcgMy40MjdhLjI1LjI1IDAgMCAxIDAtLjM1NFpNMy43NSAyLjVhLjc1Ljc1IDAgMSAwIDAgMS41Ljc1Ljc1IDAgMCAwIDAtMS41Wm0wIDkuNWEuNzUuNzUgMCAxIDAgMCAxLjUuNzUuNzUgMCAwIDAgMC0xLjVabTguMjUuNzVhLjc1Ljc1IDAgMSAwIDEuNSAwIC43NS43NSAwIDAgMC0xLjUgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4NCg==)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFN0YXJzPC90aXRsZT48cGF0aCBkPSJNOCAuMjVhLjc1Ljc1IDAgMCAxIC42NzMuNDE4bDEuODgyIDMuODE1IDQuMjEuNjEyYS43NS43NSAwIDAgMSAuNDE2IDEuMjc5bC0zLjA0NiAyLjk3LjcxOSA0LjE5MmEuNzUxLjc1MSAwIDAgMS0xLjA4OC43OTFMOCAxMi4zNDdsLTMuNzY2IDEuOThhLjc1Ljc1IDAgMCAxLTEuMDg4LS43OWwuNzItNC4xOTRMLjgxOCA2LjM3NGEuNzUuNzUgMCAwIDEgLjQxNi0xLjI4bDQuMjEtLjYxMUw3LjMyNy42NjhBLjc1Ljc1IDAgMCAxIDggLjI1Wm0wIDIuNDQ1TDYuNjE1IDUuNWEuNzUuNzUgMCAwIDEtLjU2NC40MWwtMy4wOTcuNDUgMi4yNCAyLjE4NGEuNzUuNzUgMCAwIDEgLjIxNi42NjRsLS41MjggMy4wODQgMi43NjktMS40NTZhLjc1Ljc1IDAgMCAxIC42OTggMGwyLjc3IDEuNDU2LS41My0zLjA4NGEuNzUuNzUgMCAwIDEgLjIxNi0uNjY0bDIuMjQtMi4xODMtMy4wOTYtLjQ1YS43NS43NSAwIDAgMS0uNTY0LS40MUw4IDIuNjk0WiIgZmlsbD0iIzg0OEQ5NyIvPjwvc3ZnPg==)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFRhZ3M8L3RpdGxlPjxwYXRoIGQ9Ik04IDJjMS45ODEgMCAzLjY3MS45OTIgNC45MzMgMi4wNzggMS4yNyAxLjA5MSAyLjE4NyAyLjM0NSAyLjYzNyAzLjAyM2ExLjYyIDEuNjIgMCAwIDEgMCAxLjc5OGMtLjQ1LjY3OC0xLjM2NyAxLjkzMi0yLjYzNyAzLjAyM0MxMS42NyAxMy4wMDggOS45ODEgMTQgOCAxNGMtMS45ODEgMC0zLjY3MS0uOTkyLTQuOTMzLTIuMDc4QzEuNzk3IDEwLjgzLjg4IDkuNTc2LjQzIDguODk4YTEuNjIgMS42MiAwIDAgMSAwLTEuNzk4Yy40NS0uNjc3IDEuMzY3LTEuOTMxIDIuNjM3LTMuMDIyQzQuMzMgMi45OTIgNi4wMTkgMiA4IDJaTTEuNjc5IDcuOTMyYS4xMi4xMiAwIDAgMCAwIC4xMzZjLjQxMS42MjIgMS4yNDEgMS43NSAyLjM2NiAyLjcxN0M1LjE3NiAxMS43NTggNi41MjcgMTIuNSA4IDEyLjVjMS40NzMgMCAyLjgyNS0uNzQyIDMuOTU1LTEuNzE1IDEuMTI0LS45NjcgMS45NTQtMi4wOTYgMi4zNjYtMi43MTdhLjEyLjEyIDAgMCAwIDAtLjEzNmMtLjQxMi0uNjIxLTEuMjQyLTEuNzUtMi4zNjYtMi43MTdDMTAuODI0IDQuMjQyIDkuNDczIDMuNSA4IDMuNWMtMS40NzMgMC0yLjgyNS43NDItMy45NTUgMS43MTUtMS4xMjQuOTY3LTEuOTU0IDIuMDk2LTIuMzY2IDIuNzE3Wk04IDEwYTIgMiAwIDEgMS0uMDAxLTMuOTk5QTIgMiAwIDAgMSA4IDEwWiIgZmlsbD0iIzg0OEQ5NyIvPjwvc3ZnPg==)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIEZvcmtzPC90aXRsZT48cGF0aCBkPSJNNSA1LjM3MnYuODc4YzAgLjQxNC4zMzYuNzUuNzUuNzVoNC41YS43NS43NSAwIDAgMCAuNzUtLjc1di0uODc4YTIuMjUgMi4yNSAwIDEgMSAxLjUgMHYuODc4YTIuMjUgMi4yNSAwIDAgMS0yLjI1IDIuMjVoLTEuNXYyLjEyOGEyLjI1MSAyLjI1MSAwIDEgMS0xLjUgMFY4LjVoLTEuNUEyLjI1IDIuMjUgMCAwIDEgMy41IDYuMjV2LS44NzhhMi4yNSAyLjI1IDAgMSAxIDEuNSAwWk01IDMuMjVhLjc1Ljc1IDAgMSAwLTEuNSAwIC43NS43NSAwIDAgMCAxLjUgMFptNi43NS43NWEuNzUuNzUgMCAxIDAgMC0xLjUuNzUuNzUgMCAwIDAgMCAxLjVabS0zIDguNzVhLjc1Ljc1IDAgMSAwLTEuNSAwIC43NS43NSAwIDAgMCAxLjUgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyB2aWV3Qm94PSIwIDAgMjQgMjQiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyI+PHBhdGggZD0iTTggMTBDOCA3Ljc5MDg2IDkuNzkwODYgNiAxMiA2QzE0LjIwOTEgNiAxNiA3Ljc5MDg2IDE2IDEwVjExSDE3QzE4LjkzMyAxMSAyMC41IDEyLjU2NyAyMC41IDE0LjVDMjAuNSAxNi40MzMgMTguOTMzIDE4IDE3IDE4SDE2LjlDMTYuMzQ3NyAxOCAxNS45IDE4LjQ0NzcgMTUuOSAxOUMxNS45IDE5LjU1MjMgMTYuMzQ3NyAyMCAxNi45IDIwSDE3QzIwLjAzNzYgMjAgMjIuNSAxNy41Mzc2IDIyLjUgMTQuNUMyMi41IDExLjc3OTMgMjAuNTI0NSA5LjUxOTk3IDE3LjkyOTYgOS4wNzgyNEMxNy40ODYyIDYuMjAyMTMgMTUuMDAwMyA0IDEyIDRDOC45OTk3NCA0IDYuNTEzODEgNi4yMDIxMyA2LjA3MDM2IDkuMDc4MjRDMy40NzU1MSA5LjUxOTk3IDEuNSAxMS43NzkzIDEuNSAxNC41QzEuNSAxNy41Mzc2IDMuOTYyNDMgMjAgNyAyMEg3LjFDNy42NTIyOCAyMCA4LjEgMTkuNTUyMyA4LjEgMTlDOC4xIDE4LjQ0NzcgNy42NTIyOCAxOCA3LjEgMThIN0M1LjA2NyAxOCAzLjUgMTYuNDMzIDMuNSAxNC41QzMuNSAxMi41NjcgNS4wNjcgMTEgNyAxMUg4VjEwWk0xMyAxMUMxMyAxMC40NDc3IDEyLjU1MjMgMTAgMTIgMTBDMTEuNDQ3NyAxMCAxMSAxMC40NDc3IDExIDExVjE2LjU4NThMOS43MDcxMSAxNS4yOTI5QzkuMzE2NTggMTQuOTAyNCA4LjY4MzQyIDE0LjkwMjQgOC4yOTI4OSAxNS4yOTI5QzcuOTAyMzcgMTUuNjgzNCA3LjkwMjM3IDE2LjMxNjYgOC4yOTI4OSAxNi43MDcxTDExLjI5MjkgMTkuNzA3MUMxMS42ODM0IDIwLjA5NzYgMTIuMzE2NiAyMC4wOTc2IDEyLjcwNzEgMTkuNzA3MUwxNS43MDcxIDE2LjcwNzFDMTYuMDk3NiAxNi4zMTY2IDE2LjA5NzYgMTUuNjgzNCAxNS43MDcxIDE1LjI5MjlDMTUuMzE2NiAxNC45MDI0IDE0LjY4MzQgMTQuOTAyNCAxNC4yOTI5IDE1LjI5MjlMMTMgMTYuNTg1OFYxMVoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
+ 
+ 
+ 
&color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIElzc3VlczwvdGl0bGU+PHBhdGggZD0iTTggOS41YTEuNSAxLjUgMCAxIDAgMC0zIDEuNSAxLjUgMCAwIDAgMCAzWiIgZmlsbD0iIzg0OEQ5NyIvPjxwYXRoIGQ9Ik04IDBhOCA4IDAgMSAxIDAgMTZBOCA4IDAgMCAxIDggMFpNMS41IDhhNi41IDYuNSAwIDEgMCAxMyAwIDYuNSA2LjUgMCAwIDAtMTMgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFB1bGwgUmVxdWVzdHM8L3RpdGxlPjxwYXRoIGQ9Ik0xLjUgMy4yNWEyLjI1IDIuMjUgMCAxIDEgMyAyLjEyMnY1LjI1NmEyLjI1MSAyLjI1MSAwIDEgMS0xLjUgMFY1LjM3MkEyLjI1IDIuMjUgMCAwIDEgMS41IDMuMjVabTUuNjc3LS4xNzdMOS41NzMuNjc3QS4yNS4yNSAwIDAgMSAxMCAuODU0VjIuNWgxQTIuNSAyLjUgMCAwIDEgMTMuNSA1djUuNjI4YTIuMjUxIDIuMjUxIDAgMSAxLTEuNSAwVjVhMSAxIDAgMCAwLTEtMWgtMXYxLjY0NmEuMjUuMjUgMCAwIDEtLjQyNy4xNzdMNy4xNzcgMy40MjdhLjI1LjI1IDAgMCAxIDAtLjM1NFpNMy43NSAyLjVhLjc1Ljc1IDAgMSAwIDAgMS41Ljc1Ljc1IDAgMCAwIDAtMS41Wm0wIDkuNWEuNzUuNzUgMCAxIDAgMCAxLjUuNzUuNzUgMCAwIDAgMC0xLjVabTguMjUuNzVhLjc1Ljc1IDAgMSAwIDEuNSAwIC43NS43NSAwIDAgMC0xLjUgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4NCg==)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFN0YXJzPC90aXRsZT48cGF0aCBkPSJNOCAuMjVhLjc1Ljc1IDAgMCAxIC42NzMuNDE4bDEuODgyIDMuODE1IDQuMjEuNjEyYS43NS43NSAwIDAgMSAuNDE2IDEuMjc5bC0zLjA0NiAyLjk3LjcxOSA0LjE5MmEuNzUxLjc1MSAwIDAgMS0xLjA4OC43OTFMOCAxMi4zNDdsLTMuNzY2IDEuOThhLjc1Ljc1IDAgMCAxLTEuMDg4LS43OWwuNzItNC4xOTRMLjgxOCA2LjM3NGEuNzUuNzUgMCAwIDEgLjQxNi0xLjI4bDQuMjEtLjYxMUw3LjMyNy42NjhBLjc1Ljc1IDAgMCAxIDggLjI1Wm0wIDIuNDQ1TDYuNjE1IDUuNWEuNzUuNzUgMCAwIDEtLjU2NC40MWwtMy4wOTcuNDUgMi4yNCAyLjE4NGEuNzUuNzUgMCAwIDEgLjIxNi42NjRsLS41MjggMy4wODQgMi43NjktMS40NTZhLjc1Ljc1IDAgMCAxIC42OTggMGwyLjc3IDEuNDU2LS41My0zLjA4NGEuNzUuNzUgMCAwIDEgLjIxNi0uNjY0bDIuMjQtMi4xODMtMy4wOTYtLjQ1YS43NS43NSAwIDAgMS0uNTY0LS40MUw4IDIuNjk0WiIgZmlsbD0iIzg0OEQ5NyIvPjwvc3ZnPg==)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFRhZ3M8L3RpdGxlPjxwYXRoIGQ9Ik04IDJjMS45ODEgMCAzLjY3MS45OTIgNC45MzMgMi4wNzggMS4yNyAxLjA5MSAyLjE4NyAyLjM0NSAyLjYzNyAzLjAyM2ExLjYyIDEuNjIgMCAwIDEgMCAxLjc5OGMtLjQ1LjY3OC0xLjM2NyAxLjkzMi0yLjYzNyAzLjAyM0MxMS42NyAxMy4wMDggOS45ODEgMTQgOCAxNGMtMS45ODEgMC0zLjY3MS0uOTkyLTQuOTMzLTIuMDc4QzEuNzk3IDEwLjgzLjg4IDkuNTc2LjQzIDguODk4YTEuNjIgMS42MiAwIDAgMSAwLTEuNzk4Yy40NS0uNjc3IDEuMzY3LTEuOTMxIDIuNjM3LTMuMDIyQzQuMzMgMi45OTIgNi4wMTkgMiA4IDJaTTEuNjc5IDcuOTMyYS4xMi4xMiAwIDAgMCAwIC4xMzZjLjQxMS42MjIgMS4yNDEgMS43NSAyLjM2NiAyLjcxN0M1LjE3NiAxMS43NTggNi41MjcgMTIuNSA4IDEyLjVjMS40NzMgMCAyLjgyNS0uNzQyIDMuOTU1LTEuNzE1IDEuMTI0LS45NjcgMS45NTQtMi4wOTYgMi4zNjYtMi43MTdhLjEyLjEyIDAgMCAwIDAtLjEzNmMtLjQxMi0uNjIxLTEuMjQyLTEuNzUtMi4zNjYtMi43MTdDMTAuODI0IDQuMjQyIDkuNDczIDMuNSA4IDMuNWMtMS40NzMgMC0yLjgyNS43NDItMy45NTUgMS43MTUtMS4xMjQuOTY3LTEuOTU0IDIuMDk2LTIuMzY2IDIuNzE3Wk04IDEwYTIgMiAwIDEgMS0uMDAxLTMuOTk5QTIgMiAwIDAgMSA4IDEwWiIgZmlsbD0iIzg0OEQ5NyIvPjwvc3ZnPg==)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIEZvcmtzPC90aXRsZT48cGF0aCBkPSJNNSA1LjM3MnYuODc4YzAgLjQxNC4zMzYuNzUuNzUuNzVoNC41YS43NS43NSAwIDAgMCAuNzUtLjc1di0uODc4YTIuMjUgMi4yNSAwIDEgMSAxLjUgMHYuODc4YTIuMjUgMi4yNSAwIDAgMS0yLjI1IDIuMjVoLTEuNXYyLjEyOGEyLjI1MSAyLjI1MSAwIDEgMS0xLjUgMFY4LjVoLTEuNUEyLjI1IDIuMjUgMCAwIDEgMy41IDYuMjV2LS44NzhhMi4yNSAyLjI1IDAgMSAxIDEuNSAwWk01IDMuMjVhLjc1Ljc1IDAgMSAwLTEuNSAwIC43NS43NSAwIDAgMCAxLjUgMFptNi43NS43NWEuNzUuNzUgMCAxIDAgMC0xLjUuNzUuNzUgMCAwIDAgMCAxLjVabS0zIDguNzVhLjc1Ljc1IDAgMSAwLTEuNSAwIC43NS43NSAwIDAgMCAxLjUgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyB2aWV3Qm94PSIwIDAgMjQgMjQiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyI+PHBhdGggZD0iTTggMTBDOCA3Ljc5MDg2IDkuNzkwODYgNiAxMiA2QzE0LjIwOTEgNiAxNiA3Ljc5MDg2IDE2IDEwVjExSDE3QzE4LjkzMyAxMSAyMC41IDEyLjU2NyAyMC41IDE0LjVDMjAuNSAxNi40MzMgMTguOTMzIDE4IDE3IDE4SDE2LjlDMTYuMzQ3NyAxOCAxNS45IDE4LjQ0NzcgMTUuOSAxOUMxNS45IDE5LjU1MjMgMTYuMzQ3NyAyMCAxNi45IDIwSDE3QzIwLjAzNzYgMjAgMjIuNSAxNy41Mzc2IDIyLjUgMTQuNUMyMi41IDExLjc3OTMgMjAuNTI0NSA5LjUxOTk3IDE3LjkyOTYgOS4wNzgyNEMxNy40ODYyIDYuMjAyMTMgMTUuMDAwMyA0IDEyIDRDOC45OTk3NCA0IDYuNTEzODEgNi4yMDIxMyA2LjA3MDM2IDkuMDc4MjRDMy40NzU1MSA5LjUxOTk3IDEuNSAxMS43NzkzIDEuNSAxNC41QzEuNSAxNy41Mzc2IDMuOTYyNDMgMjAgNyAyMEg3LjFDNy42NTIyOCAyMCA4LjEgMTkuNTUyMyA4LjEgMTlDOC4xIDE4LjQ0NzcgNy42NTIyOCAxOCA3LjEgMThIN0M1LjA2NyAxOCAzLjUgMTYuNDMzIDMuNSAxNC41QzMuNSAxMi41NjcgNS4wNjcgMTEgNyAxMUg4VjEwWk0xMyAxMUMxMyAxMC40NDc3IDEyLjU1MjMgMTAgMTIgMTBDMTEuNDQ3NyAxMCAxMSAxMC40NDc3IDExIDExVjE2LjU4NThMOS43MDcxMSAxNS4yOTI5QzkuMzE2NTggMTQuOTAyNCA4LjY4MzQyIDE0LjkwMjQgOC4yOTI4OSAxNS4yOTI5QzcuOTAyMzcgMTUuNjgzNCA3LjkwMjM3IDE2LjMxNjYgOC4yOTI4OSAxNi43MDcxTDExLjI5MjkgMTkuNzA3MUMxMS42ODM0IDIwLjA5NzYgMTIuMzE2NiAyMC4wOTc2IDEyLjcwNzEgMTkuNzA3MUwxNS43MDcxIDE2LjcwNzFDMTYuMDk3NiAxNi4zMTY2IDE2LjA5NzYgMTUuNjgzNCAxNS43MDcxIDE1LjI5MjlDMTUuMzE2NiAxNC45MDI0IDE0LjY4MzQgMTQuOTAyNCAxNC4yOTI5IDE1LjI5MjlMMTMgMTYuNTg1OFYxMVoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
+ 
+ 
+ 
&color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIElzc3VlczwvdGl0bGU+PHBhdGggZD0iTTggOS41YTEuNSAxLjUgMCAxIDAgMC0zIDEuNSAxLjUgMCAwIDAgMCAzWiIgZmlsbD0iIzg0OEQ5NyIvPjxwYXRoIGQ9Ik04IDBhOCA4IDAgMSAxIDAgMTZBOCA4IDAgMCAxIDggMFpNMS41IDhhNi41IDYuNSAwIDEgMCAxMyAwIDYuNSA2LjUgMCAwIDAtMTMgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
- &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFB1bGwgUmVxdWVzdHM8L3RpdGxlPjxwYXRoIGQ9Ik0xLjUgMy4yNWEyLjI1IDIuMjUgMCAxIDEgMyAyLjEyMnY1LjI1NmEyLjI1MSAyLjI1MSAwIDEgMS0xLjUgMFY1LjM3MkEyLjI1IDIuMjUgMCAwIDEgMS41IDMuMjVabTUuNjc3LS4xNzdMOS41NzMuNjc3QS4yNS4yNSAwIDAgMSAxMCAuODU0VjIuNWgxQTIuNSAyLjUgMCAwIDEgMTMuNSA1djUuNjI4YTIuMjUxIDIuMjUxIDAgMSAxLTEuNSAwVjVhMSAxIDAgMCAwLTEtMWgtMXYxLjY0NmEuMjUuMjUgMCAwIDEtLjQyNy4xNzdMNy4xNzcgMy40MjdhLjI1LjI1IDAgMCAxIDAtLjM1NFpNMy43NSAyLjVhLjc1Ljc1IDAgMSAwIDAgMS41Ljc1Ljc1IDAgMCAwIDAtMS41Wm0wIDkuNWEuNzUuNzUgMCAxIDAgMCAxLjUuNzUuNzUgMCAwIDAgMC0xLjVabTguMjUuNzVhLjc1Ljc1IDAgMSAwIDEuNSAwIC43NS43NSAwIDAgMC0xLjUgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4NCg==)
- &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFN0YXJzPC90aXRsZT48cGF0aCBkPSJNOCAuMjVhLjc1Ljc1IDAgMCAxIC42NzMuNDE4bDEuODgyIDMuODE1IDQuMjEuNjEyYS43NS43NSAwIDAgMSAuNDE2IDEuMjc5bC0zLjA0NiAyLjk3LjcxOSA0LjE5MmEuNzUxLjc1MSAwIDAgMS0xLjA4OC43OTFMOCAxMi4zNDdsLTMuNzY2IDEuOThhLjc1Ljc1IDAgMCAxLTEuMDg4LS43OWwuNzItNC4xOTRMLjgxOCA2LjM3NGEuNzUuNzUgMCAwIDEgLjQxNi0xLjI4bDQuMjEtLjYxMUw3LjMyNy42NjhBLjc1Ljc1IDAgMCAxIDggLjI1Wm0wIDIuNDQ1TDYuNjE1IDUuNWEuNzUuNzUgMCAwIDEtLjU2NC40MWwtMy4wOTcuNDUgMi4yNCAyLjE4NGEuNzUuNzUgMCAwIDEgLjIxNi42NjRsLS41MjggMy4wODQgMi43NjktMS40NTZhLjc1Ljc1IDAgMCAxIC42OTggMGwyLjc3IDEuNDU2LS41My0zLjA4NGEuNzUuNzUgMCAwIDEgLjIxNi0uNjY0bDIuMjQtMi4xODMtMy4wOTYtLjQ1YS43NS43NSAwIDAgMS0uNTY0LS40MUw4IDIuNjk0WiIgZmlsbD0iIzg0OEQ5NyIvPjwvc3ZnPg==)
- &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFRhZ3M8L3RpdGxlPjxwYXRoIGQ9Ik04IDJjMS45ODEgMCAzLjY3MS45OTIgNC45MzMgMi4wNzggMS4yNyAxLjA5MSAyLjE4NyAyLjM0NSAyLjYzNyAzLjAyM2ExLjYyIDEuNjIgMCAwIDEgMCAxLjc5OGMtLjQ1LjY3OC0xLjM2NyAxLjkzMi0yLjYzNyAzLjAyM0MxMS42NyAxMy4wMDggOS45ODEgMTQgOCAxNGMtMS45ODEgMC0zLjY3MS0uOTkyLTQuOTMzLTIuMDc4QzEuNzk3IDEwLjgzLjg4IDkuNTc2LjQzIDguODk4YTEuNjIgMS42MiAwIDAgMSAwLTEuNzk4Yy40NS0uNjc3IDEuMzY3LTEuOTMxIDIuNjM3LTMuMDIyQzQuMzMgMi45OTIgNi4wMTkgMiA4IDJaTTEuNjc5IDcuOTMyYS4xMi4xMiAwIDAgMCAwIC4xMzZjLjQxMS42MjIgMS4yNDEgMS43NSAyLjM2NiAyLjcxN0M1LjE3NiAxMS43NTggNi41MjcgMTIuNSA4IDEyLjVjMS40NzMgMCAyLjgyNS0uNzQyIDMuOTU1LTEuNzE1IDEuMTI0LS45NjcgMS45NTQtMi4wOTYgMi4zNjYtMi43MTdhLjEyLjEyIDAgMCAwIDAtLjEzNmMtLjQxMi0uNjIxLTEuMjQyLTEuNzUtMi4zNjYtMi43MTdDMTAuODI0IDQuMjQyIDkuNDczIDMuNSA4IDMuNWMtMS40NzMgMC0yLjgyNS43NDItMy45NTUgMS43MTUtMS4xMjQuOTY3LTEuOTU0IDIuMDk2LTIuMzY2IDIuNzE3Wk04IDEwYTIgMiAwIDEgMS0uMDAxLTMuOTk5QTIgMiAwIDAgMSA4IDEwWiIgZmlsbD0iIzg0OEQ5NyIvPjwvc3ZnPg==)
- &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIEZvcmtzPC90aXRsZT48cGF0aCBkPSJNNSA1LjM3MnYuODc4YzAgLjQxNC4zMzYuNzUuNzUuNzVoNC41YS43NS43NSAwIDAgMCAuNzUtLjc1di0uODc4YTIuMjUgMi4yNSAwIDEgMSAxLjUgMHYuODc4YTIuMjUgMi4yNSAwIDAgMS0yLjI1IDIuMjVoLTEuNXYyLjEyOGEyLjI1MSAyLjI1MSAwIDEgMS0xLjUgMFY4LjVoLTEuNUEyLjI1IDIuMjUgMCAwIDEgMy41IDYuMjV2LS44NzhhMi4yNSAyLjI1IDAgMSAxIDEuNSAwWk01IDMuMjVhLjc1Ljc1IDAgMSAwLTEuNSAwIC43NS43NSAwIDAgMCAxLjUgMFptNi43NS43NWEuNzUuNzUgMCAxIDAgMC0xLjUuNzUuNzUgMCAwIDAgMCAxLjVabS0zIDguNzVhLjc1Ljc1IDAgMSAwLTEuNSAwIC43NS43NSAwIDAgMCAxLjUgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
- &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyB2aWV3Qm94PSIwIDAgMjQgMjQiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyI+PHBhdGggZD0iTTggMTBDOCA3Ljc5MDg2IDkuNzkwODYgNiAxMiA2QzE0LjIwOTEgNiAxNiA3Ljc5MDg2IDE2IDEwVjExSDE3QzE4LjkzMyAxMSAyMC41IDEyLjU2NyAyMC41IDE0LjVDMjAuNSAxNi40MzMgMTguOTMzIDE4IDE3IDE4SDE2LjlDMTYuMzQ3NyAxOCAxNS45IDE4LjQ0NzcgMTUuOSAxOUMxNS45IDE5LjU1MjMgMTYuMzQ3NyAyMCAxNi45IDIwSDE3QzIwLjAzNzYgMjAgMjIuNSAxNy41Mzc2IDIyLjUgMTQuNUMyMi41IDExLjc3OTMgMjAuNTI0NSA5LjUxOTk3IDE3LjkyOTYgOS4wNzgyNEMxNy40ODYyIDYuMjAyMTMgMTUuMDAwMyA0IDEyIDRDOC45OTk3NCA0IDYuNTEzODEgNi4yMDIxMyA2LjA3MDM2IDkuMDc4MjRDMy40NzU1MSA5LjUxOTk3IDEuNSAxMS43NzkzIDEuNSAxNC41QzEuNSAxNy41Mzc2IDMuOTYyNDMgMjAgNyAyMEg3LjFDNy42NTIyOCAyMCA4LjEgMTkuNTUyMyA4LjEgMTlDOC4xIDE4LjQ0NzcgNy42NTIyOCAxOCA3LjEgMThIN0M1LjA2NyAxOCAzLjUgMTYuNDMzIDMuNSAxNC41QzMuNSAxMi41NjcgNS4wNjcgMTEgNyAxMUg4VjEwWk0xMyAxMUMxMyAxMC40NDc3IDEyLjU1MjMgMTAgMTIgMTBDMTEuNDQ3NyAxMCAxMSAxMC40NDc3IDExIDExVjE2LjU4NThMOS43MDcxMSAxNS4yOTI5QzkuMzE2NTggMTQuOTAyNCA4LjY4MzQyIDE0LjkwMjQgOC4yOTI4OSAxNS4yOTI5QzcuOTAyMzcgMTUuNjgzNCA3LjkwMjM3IDE2LjMxNjYgOC4yOTI4OSAxNi43MDcxTDExLjI5MjkgMTkuNzA3MUMxMS42ODM0IDIwLjA5NzYgMTIuMzE2NiAyMC4wOTc2IDEyLjcwNzEgMTkuNzA3MUwxNS43MDcxIDE2LjcwNzFDMTYuMDk3NiAxNi4zMTY2IDE2LjA5NzYgMTUuNjgzNCAxNS43MDcxIDE1LjI5MjlDMTUuMzE2NiAxNC45MDI0IDE0LjY4MzQgMTQuOTAyNCAxNC4yOTI5IDE1LjI5MjlMMTMgMTYuNTg1OFYxMVoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
- 
- 
- &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIElzc3VlczwvdGl0bGU+PHBhdGggZD0iTTggOS41YTEuNSAxLjUgMCAxIDAgMC0zIDEuNSAxLjUgMCAwIDAgMCAzWiIgZmlsbD0iIzg0OEQ5NyIvPjxwYXRoIGQ9Ik04IDBhOCA4IDAgMSAxIDAgMTZBOCA4IDAgMCAxIDggMFpNMS41IDhhNi41IDYuNSAwIDEgMCAxMyAwIDYuNSA2LjUgMCAwIDAtMTMgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
- &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFB1bGwgUmVxdWVzdHM8L3RpdGxlPjxwYXRoIGQ9Ik0xLjUgMy4yNWEyLjI1IDIuMjUgMCAxIDEgMyAyLjEyMnY1LjI1NmEyLjI1MSAyLjI1MSAwIDEgMS0xLjUgMFY1LjM3MkEyLjI1IDIuMjUgMCAwIDEgMS41IDMuMjVabTUuNjc3LS4xNzdMOS41NzMuNjc3QS4yNS4yNSAwIDAgMSAxMCAuODU0VjIuNWgxQTIuNSAyLjUgMCAwIDEgMTMuNSA1djUuNjI4YTIuMjUxIDIuMjUxIDAgMSAxLTEuNSAwVjVhMSAxIDAgMCAwLTEtMWgtMXYxLjY0NmEuMjUuMjUgMCAwIDEtLjQyNy4xNzdMNy4xNzcgMy40MjdhLjI1LjI1IDAgMCAxIDAtLjM1NFpNMy43NSAyLjVhLjc1Ljc1IDAgMSAwIDAgMS41Ljc1Ljc1IDAgMCAwIDAtMS41Wm0wIDkuNWEuNzUuNzUgMCAxIDAgMCAxLjUuNzUuNzUgMCAwIDAgMC0xLjVabTguMjUuNzVhLjc1Ljc1IDAgMSAwIDEuNSAwIC43NS43NSAwIDAgMC0xLjUgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4NCg==)
- &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFN0YXJzPC90aXRsZT48cGF0aCBkPSJNOCAuMjVhLjc1Ljc1IDAgMCAxIC42NzMuNDE4bDEuODgyIDMuODE1IDQuMjEuNjEyYS43NS43NSAwIDAgMSAuNDE2IDEuMjc5bC0zLjA0NiAyLjk3LjcxOSA0LjE5MmEuNzUxLjc1MSAwIDAgMS0xLjA4OC43OTFMOCAxMi4zNDdsLTMuNzY2IDEuOThhLjc1Ljc1IDAgMCAxLTEuMDg4LS43OWwuNzItNC4xOTRMLjgxOCA2LjM3NGEuNzUuNzUgMCAwIDEgLjQxNi0xLjI4bDQuMjEtLjYxMUw3LjMyNy42NjhBLjc1Ljc1IDAgMCAxIDggLjI1Wm0wIDIuNDQ1TDYuNjE1IDUuNWEuNzUuNzUgMCAwIDEtLjU2NC40MWwtMy4wOTcuNDUgMi4yNCAyLjE4NGEuNzUuNzUgMCAwIDEgLjIxNi42NjRsLS41MjggMy4wODQgMi43NjktMS40NTZhLjc1Ljc1IDAgMCAxIC42OTggMGwyLjc3IDEuNDU2LS41My0zLjA4NGEuNzUuNzUgMCAwIDEgLjIxNi0uNjY0bDIuMjQtMi4xODMtMy4wOTYtLjQ1YS43NS43NSAwIDAgMS0uNTY0LS40MUw4IDIuNjk0WiIgZmlsbD0iIzg0OEQ5NyIvPjwvc3ZnPg==)
- &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFRhZ3M8L3RpdGxlPjxwYXRoIGQ9Ik04IDJjMS45ODEgMCAzLjY3MS45OTIgNC45MzMgMi4wNzggMS4yNyAxLjA5MSAyLjE4NyAyLjM0NSAyLjYzNyAzLjAyM2ExLjYyIDEuNjIgMCAwIDEgMCAxLjc5OGMtLjQ1LjY3OC0xLjM2NyAxLjkzMi0yLjYzNyAzLjAyM0MxMS42NyAxMy4wMDggOS45ODEgMTQgOCAxNGMtMS45ODEgMC0zLjY3MS0uOTkyLTQuOTMzLTIuMDc4QzEuNzk3IDEwLjgzLjg4IDkuNTc2LjQzIDguODk4YTEuNjIgMS42MiAwIDAgMSAwLTEuNzk4Yy40NS0uNjc3IDEuMzY3LTEuOTMxIDIuNjM3LTMuMDIyQzQuMzMgMi45OTIgNi4wMTkgMiA4IDJaTTEuNjc5IDcuOTMyYS4xMi4xMiAwIDAgMCAwIC4xMzZjLjQxMS42MjIgMS4yNDEgMS43NSAyLjM2NiAyLjcxN0M1LjE3NiAxMS43NTggNi41MjcgMTIuNSA4IDEyLjVjMS40NzMgMCAyLjgyNS0uNzQyIDMuOTU1LTEuNzE1IDEuMTI0LS45NjcgMS45NTQtMi4wOTYgMi4zNjYtMi43MTdhLjEyLjEyIDAgMCAwIDAtLjEzNmMtLjQxMi0uNjIxLTEuMjQyLTEuNzUtMi4zNjYtMi43MTdDMTAuODI0IDQuMjQyIDkuNDczIDMuNSA4IDMuNWMtMS40NzMgMC0yLjgyNS43NDItMy45NTUgMS43MTUtMS4xMjQuOTY3LTEuOTU0IDIuMDk2LTIuMzY2IDIuNzE3Wk04IDEwYTIgMiAwIDEgMS0uMDAxLTMuOTk5QTIgMiAwIDAgMSA4IDEwWiIgZmlsbD0iIzg0OEQ5NyIvPjwvc3ZnPg==)
- &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIEZvcmtzPC90aXRsZT48cGF0aCBkPSJNNSA1LjM3MnYuODc4YzAgLjQxNC4zMzYuNzUuNzUuNzVoNC41YS43NS43NSAwIDAgMCAuNzUtLjc1di0uODc4YTIuMjUgMi4yNSAwIDEgMSAxLjUgMHYuODc4YTIuMjUgMi4yNSAwIDAgMS0yLjI1IDIuMjVoLTEuNXYyLjEyOGEyLjI1MSAyLjI1MSAwIDEgMS0xLjUgMFY4LjVoLTEuNUEyLjI1IDIuMjUgMCAwIDEgMy41IDYuMjV2LS44NzhhMi4yNSAyLjI1IDAgMSAxIDEuNSAwWk01IDMuMjVhLjc1Ljc1IDAgMSAwLTEuNSAwIC43NS43NSAwIDAgMCAxLjUgMFptNi43NS43NWEuNzUuNzUgMCAxIDAgMC0xLjUuNzUuNzUgMCAwIDAgMCAxLjVabS0zIDguNzVhLjc1Ljc1IDAgMSAwLTEuNSAwIC43NS43NSAwIDAgMCAxLjUgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
- 
- 
&color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIElzc3VlczwvdGl0bGU+PHBhdGggZD0iTTggOS41YTEuNSAxLjUgMCAxIDAgMC0zIDEuNSAxLjUgMCAwIDAgMCAzWiIgZmlsbD0iIzg0OEQ5NyIvPjxwYXRoIGQ9Ik04IDBhOCA4IDAgMSAxIDAgMTZBOCA4IDAgMCAxIDggMFpNMS41IDhhNi41IDYuNSAwIDEgMCAxMyAwIDYuNSA2LjUgMCAwIDAtMTMgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
- &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFB1bGwgUmVxdWVzdHM8L3RpdGxlPjxwYXRoIGQ9Ik0xLjUgMy4yNWEyLjI1IDIuMjUgMCAxIDEgMyAyLjEyMnY1LjI1NmEyLjI1MSAyLjI1MSAwIDEgMS0xLjUgMFY1LjM3MkEyLjI1IDIuMjUgMCAwIDEgMS41IDMuMjVabTUuNjc3LS4xNzdMOS41NzMuNjc3QS4yNS4yNSAwIDAgMSAxMCAuODU0VjIuNWgxQTIuNSAyLjUgMCAwIDEgMTMuNSA1djUuNjI4YTIuMjUxIDIuMjUxIDAgMSAxLTEuNSAwVjVhMSAxIDAgMCAwLTEtMWgtMXYxLjY0NmEuMjUuMjUgMCAwIDEtLjQyNy4xNzdMNy4xNzcgMy40MjdhLjI1LjI1IDAgMCAxIDAtLjM1NFpNMy43NSAyLjVhLjc1Ljc1IDAgMSAwIDAgMS41Ljc1Ljc1IDAgMCAwIDAtMS41Wm0wIDkuNWEuNzUuNzUgMCAxIDAgMCAxLjUuNzUuNzUgMCAwIDAgMC0xLjVabTguMjUuNzVhLjc1Ljc1IDAgMSAwIDEuNSAwIC43NS43NSAwIDAgMC0xLjUgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4NCg==)
- &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFN0YXJzPC90aXRsZT48cGF0aCBkPSJNOCAuMjVhLjc1Ljc1IDAgMCAxIC42NzMuNDE4bDEuODgyIDMuODE1IDQuMjEuNjEyYS43NS43NSAwIDAgMSAuNDE2IDEuMjc5bC0zLjA0NiAyLjk3LjcxOSA0LjE5MmEuNzUxLjc1MSAwIDAgMS0xLjA4OC43OTFMOCAxMi4zNDdsLTMuNzY2IDEuOThhLjc1Ljc1IDAgMCAxLTEuMDg4LS43OWwuNzItNC4xOTRMLjgxOCA2LjM3NGEuNzUuNzUgMCAwIDEgLjQxNi0xLjI4bDQuMjEtLjYxMUw3LjMyNy42NjhBLjc1Ljc1IDAgMCAxIDggLjI1Wm0wIDIuNDQ1TDYuNjE1IDUuNWEuNzUuNzUgMCAwIDEtLjU2NC40MWwtMy4wOTcuNDUgMi4yNCAyLjE4NGEuNzUuNzUgMCAwIDEgLjIxNi42NjRsLS41MjggMy4wODQgMi43NjktMS40NTZhLjc1Ljc1IDAgMCAxIC42OTggMGwyLjc3IDEuNDU2LS41My0zLjA4NGEuNzUuNzUgMCAwIDEgLjIxNi0uNjY0bDIuMjQtMi4xODMtMy4wOTYtLjQ1YS43NS43NSAwIDAgMS0uNTY0LS40MUw4IDIuNjk0WiIgZmlsbD0iIzg0OEQ5NyIvPjwvc3ZnPg==)
- &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFRhZ3M8L3RpdGxlPjxwYXRoIGQ9Ik04IDJjMS45ODEgMCAzLjY3MS45OTIgNC45MzMgMi4wNzggMS4yNyAxLjA5MSAyLjE4NyAyLjM0NSAyLjYzNyAzLjAyM2ExLjYyIDEuNjIgMCAwIDEgMCAxLjc5OGMtLjQ1LjY3OC0xLjM2NyAxLjkzMi0yLjYzNyAzLjAyM0MxMS42NyAxMy4wMDggOS45ODEgMTQgOCAxNGMtMS45ODEgMC0zLjY3MS0uOTkyLTQuOTMzLTIuMDc4QzEuNzk3IDEwLjgzLjg4IDkuNTc2LjQzIDguODk4YTEuNjIgMS42MiAwIDAgMSAwLTEuNzk4Yy40NS0uNjc3IDEuMzY3LTEuOTMxIDIuNjM3LTMuMDIyQzQuMzMgMi45OTIgNi4wMTkgMiA4IDJaTTEuNjc5IDcuOTMyYS4xMi4xMiAwIDAgMCAwIC4xMzZjLjQxMS42MjIgMS4yNDEgMS43NSAyLjM2NiAyLjcxN0M1LjE3NiAxMS43NTggNi41MjcgMTIuNSA4IDEyLjVjMS40NzMgMCAyLjgyNS0uNzQyIDMuOTU1LTEuNzE1IDEuMTI0LS45NjcgMS45NTQtMi4wOTYgMi4zNjYtMi43MTdhLjEyLjEyIDAgMCAwIDAtLjEzNmMtLjQxMi0uNjIxLTEuMjQyLTEuNzUtMi4zNjYtMi43MTdDMTAuODI0IDQuMjQyIDkuNDczIDMuNSA4IDMuNWMtMS40NzMgMC0yLjgyNS43NDItMy45NTUgMS43MTUtMS4xMjQuOTY3LTEuOTU0IDIuMDk2LTIuMzY2IDIuNzE3Wk04IDEwYTIgMiAwIDEgMS0uMDAxLTMuOTk5QTIgMiAwIDAgMSA4IDEwWiIgZmlsbD0iIzg0OEQ5NyIvPjwvc3ZnPg==)
- &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIEZvcmtzPC90aXRsZT48cGF0aCBkPSJNNSA1LjM3MnYuODc4YzAgLjQxNC4zMzYuNzUuNzUuNzVoNC41YS43NS43NSAwIDAgMCAuNzUtLjc1di0uODc4YTIuMjUgMi4yNSAwIDEgMSAxLjUgMHYuODc4YTIuMjUgMi4yNSAwIDAgMS0yLjI1IDIuMjVoLTEuNXYyLjEyOGEyLjI1MSAyLjI1MSAwIDEgMS0xLjUgMFY4LjVoLTEuNUEyLjI1IDIuMjUgMCAwIDEgMy41IDYuMjV2LS44NzhhMi4yNSAyLjI1IDAgMSAxIDEuNSAwWk01IDMuMjVhLjc1Ljc1IDAgMSAwLTEuNSAwIC43NS43NSAwIDAgMCAxLjUgMFptNi43NS43NWEuNzUuNzUgMCAxIDAgMC0xLjUuNzUuNzUgMCAwIDAgMCAxLjVabS0zIDguNzVhLjc1Ljc1IDAgMSAwLTEuNSAwIC43NS43NSAwIDAgMCAxLjUgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
- 
- 
&color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIElzc3VlczwvdGl0bGU+PHBhdGggZD0iTTggOS41YTEuNSAxLjUgMCAxIDAgMC0zIDEuNSAxLjUgMCAwIDAgMCAzWiIgZmlsbD0iIzg0OEQ5NyIvPjxwYXRoIGQ9Ik04IDBhOCA4IDAgMSAxIDAgMTZBOCA4IDAgMCAxIDggMFpNMS41IDhhNi41IDYuNSAwIDEgMCAxMyAwIDYuNSA2LjUgMCAwIDAtMTMgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFB1bGwgUmVxdWVzdHM8L3RpdGxlPjxwYXRoIGQ9Ik0xLjUgMy4yNWEyLjI1IDIuMjUgMCAxIDEgMyAyLjEyMnY1LjI1NmEyLjI1MSAyLjI1MSAwIDEgMS0xLjUgMFY1LjM3MkEyLjI1IDIuMjUgMCAwIDEgMS41IDMuMjVabTUuNjc3LS4xNzdMOS41NzMuNjc3QS4yNS4yNSAwIDAgMSAxMCAuODU0VjIuNWgxQTIuNSAyLjUgMCAwIDEgMTMuNSA1djUuNjI4YTIuMjUxIDIuMjUxIDAgMSAxLTEuNSAwVjVhMSAxIDAgMCAwLTEtMWgtMXYxLjY0NmEuMjUuMjUgMCAwIDEtLjQyNy4xNzdMNy4xNzcgMy40MjdhLjI1LjI1IDAgMCAxIDAtLjM1NFpNMy43NSAyLjVhLjc1Ljc1IDAgMSAwIDAgMS41Ljc1Ljc1IDAgMCAwIDAtMS41Wm0wIDkuNWEuNzUuNzUgMCAxIDAgMCAxLjUuNzUuNzUgMCAwIDAgMC0xLjVabTguMjUuNzVhLjc1Ljc1IDAgMSAwIDEuNSAwIC43NS43NSAwIDAgMC0xLjUgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4NCg==)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFN0YXJzPC90aXRsZT48cGF0aCBkPSJNOCAuMjVhLjc1Ljc1IDAgMCAxIC42NzMuNDE4bDEuODgyIDMuODE1IDQuMjEuNjEyYS43NS43NSAwIDAgMSAuNDE2IDEuMjc5bC0zLjA0NiAyLjk3LjcxOSA0LjE5MmEuNzUxLjc1MSAwIDAgMS0xLjA4OC43OTFMOCAxMi4zNDdsLTMuNzY2IDEuOThhLjc1Ljc1IDAgMCAxLTEuMDg4LS43OWwuNzItNC4xOTRMLjgxOCA2LjM3NGEuNzUuNzUgMCAwIDEgLjQxNi0xLjI4bDQuMjEtLjYxMUw3LjMyNy42NjhBLjc1Ljc1IDAgMCAxIDggLjI1Wm0wIDIuNDQ1TDYuNjE1IDUuNWEuNzUuNzUgMCAwIDEtLjU2NC40MWwtMy4wOTcuNDUgMi4yNCAyLjE4NGEuNzUuNzUgMCAwIDEgLjIxNi42NjRsLS41MjggMy4wODQgMi43NjktMS40NTZhLjc1Ljc1IDAgMCAxIC42OTggMGwyLjc3IDEuNDU2LS41My0zLjA4NGEuNzUuNzUgMCAwIDEgLjIxNi0uNjY0bDIuMjQtMi4xODMtMy4wOTYtLjQ1YS43NS43NSAwIDAgMS0uNTY0LS40MUw4IDIuNjk0WiIgZmlsbD0iIzg0OEQ5NyIvPjwvc3ZnPg==)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFRhZ3M8L3RpdGxlPjxwYXRoIGQ9Ik04IDJjMS45ODEgMCAzLjY3MS45OTIgNC45MzMgMi4wNzggMS4yNyAxLjA5MSAyLjE4NyAyLjM0NSAyLjYzNyAzLjAyM2ExLjYyIDEuNjIgMCAwIDEgMCAxLjc5OGMtLjQ1LjY3OC0xLjM2NyAxLjkzMi0yLjYzNyAzLjAyM0MxMS42NyAxMy4wMDggOS45ODEgMTQgOCAxNGMtMS45ODEgMC0zLjY3MS0uOTkyLTQuOTMzLTIuMDc4QzEuNzk3IDEwLjgzLjg4IDkuNTc2LjQzIDguODk4YTEuNjIgMS42MiAwIDAgMSAwLTEuNzk4Yy40NS0uNjc3IDEuMzY3LTEuOTMxIDIuNjM3LTMuMDIyQzQuMzMgMi45OTIgNi4wMTkgMiA4IDJaTTEuNjc5IDcuOTMyYS4xMi4xMiAwIDAgMCAwIC4xMzZjLjQxMS42MjIgMS4yNDEgMS43NSAyLjM2NiAyLjcxN0M1LjE3NiAxMS43NTggNi41MjcgMTIuNSA4IDEyLjVjMS40NzMgMCAyLjgyNS0uNzQyIDMuOTU1LTEuNzE1IDEuMTI0LS45NjcgMS45NTQtMi4wOTYgMi4zNjYtMi43MTdhLjEyLjEyIDAgMCAwIDAtLjEzNmMtLjQxMi0uNjIxLTEuMjQyLTEuNzUtMi4zNjYtMi43MTdDMTAuODI0IDQuMjQyIDkuNDczIDMuNSA4IDMuNWMtMS40NzMgMC0yLjgyNS43NDItMy45NTUgMS43MTUtMS4xMjQuOTY3LTEuOTU0IDIuMDk2LTIuMzY2IDIuNzE3Wk04IDEwYTIgMiAwIDEgMS0uMDAxLTMuOTk5QTIgMiAwIDAgMSA4IDEwWiIgZmlsbD0iIzg0OEQ5NyIvPjwvc3ZnPg==)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIEZvcmtzPC90aXRsZT48cGF0aCBkPSJNNSA1LjM3MnYuODc4YzAgLjQxNC4zMzYuNzUuNzUuNzVoNC41YS43NS43NSAwIDAgMCAuNzUtLjc1di0uODc4YTIuMjUgMi4yNSAwIDEgMSAxLjUgMHYuODc4YTIuMjUgMi4yNSAwIDAgMS0yLjI1IDIuMjVoLTEuNXYyLjEyOGEyLjI1MSAyLjI1MSAwIDEgMS0xLjUgMFY4LjVoLTEuNUEyLjI1IDIuMjUgMCAwIDEgMy41IDYuMjV2LS44NzhhMi4yNSAyLjI1IDAgMSAxIDEuNSAwWk01IDMuMjVhLjc1Ljc1IDAgMSAwLTEuNSAwIC43NS43NSAwIDAgMCAxLjUgMFptNi43NS43NWEuNzUuNzUgMCAxIDAgMC0xLjUuNzUuNzUgMCAwIDAgMCAxLjVabS0zIDguNzVhLjc1Ljc1IDAgMSAwLTEuNSAwIC43NS43NSAwIDAgMCAxLjUgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
+ 
+ 
&color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIElzc3VlczwvdGl0bGU+PHBhdGggZD0iTTggOS41YTEuNSAxLjUgMCAxIDAgMC0zIDEuNSAxLjUgMCAwIDAgMCAzWiIgZmlsbD0iIzg0OEQ5NyIvPjxwYXRoIGQ9Ik04IDBhOCA4IDAgMSAxIDAgMTZBOCA4IDAgMCAxIDggMFpNMS41IDhhNi41IDYuNSAwIDEgMCAxMyAwIDYuNSA2LjUgMCAwIDAtMTMgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFB1bGwgUmVxdWVzdHM8L3RpdGxlPjxwYXRoIGQ9Ik0xLjUgMy4yNWEyLjI1IDIuMjUgMCAxIDEgMyAyLjEyMnY1LjI1NmEyLjI1MSAyLjI1MSAwIDEgMS0xLjUgMFY1LjM3MkEyLjI1IDIuMjUgMCAwIDEgMS41IDMuMjVabTUuNjc3LS4xNzdMOS41NzMuNjc3QS4yNS4yNSAwIDAgMSAxMCAuODU0VjIuNWgxQTIuNSAyLjUgMCAwIDEgMTMuNSA1djUuNjI4YTIuMjUxIDIuMjUxIDAgMSAxLTEuNSAwVjVhMSAxIDAgMCAwLTEtMWgtMXYxLjY0NmEuMjUuMjUgMCAwIDEtLjQyNy4xNzdMNy4xNzcgMy40MjdhLjI1LjI1IDAgMCAxIDAtLjM1NFpNMy43NSAyLjVhLjc1Ljc1IDAgMSAwIDAgMS41Ljc1Ljc1IDAgMCAwIDAtMS41Wm0wIDkuNWEuNzUuNzUgMCAxIDAgMCAxLjUuNzUuNzUgMCAwIDAgMC0xLjVabTguMjUuNzVhLjc1Ljc1IDAgMSAwIDEuNSAwIC43NS43NSAwIDAgMC0xLjUgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4NCg==)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFN0YXJzPC90aXRsZT48cGF0aCBkPSJNOCAuMjVhLjc1Ljc1IDAgMCAxIC42NzMuNDE4bDEuODgyIDMuODE1IDQuMjEuNjEyYS43NS43NSAwIDAgMSAuNDE2IDEuMjc5bC0zLjA0NiAyLjk3LjcxOSA0LjE5MmEuNzUxLjc1MSAwIDAgMS0xLjA4OC43OTFMOCAxMi4zNDdsLTMuNzY2IDEuOThhLjc1Ljc1IDAgMCAxLTEuMDg4LS43OWwuNzItNC4xOTRMLjgxOCA2LjM3NGEuNzUuNzUgMCAwIDEgLjQxNi0xLjI4bDQuMjEtLjYxMUw3LjMyNy42NjhBLjc1Ljc1IDAgMCAxIDggLjI1Wm0wIDIuNDQ1TDYuNjE1IDUuNWEuNzUuNzUgMCAwIDEtLjU2NC40MWwtMy4wOTcuNDUgMi4yNCAyLjE4NGEuNzUuNzUgMCAwIDEgLjIxNi42NjRsLS41MjggMy4wODQgMi43NjktMS40NTZhLjc1Ljc1IDAgMCAxIC42OTggMGwyLjc3IDEuNDU2LS41My0zLjA4NGEuNzUuNzUgMCAwIDEgLjIxNi0uNjY0bDIuMjQtMi4xODMtMy4wOTYtLjQ1YS43NS43NSAwIDAgMS0uNTY0LS40MUw4IDIuNjk0WiIgZmlsbD0iIzg0OEQ5NyIvPjwvc3ZnPg==)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIFRhZ3M8L3RpdGxlPjxwYXRoIGQ9Ik04IDJjMS45ODEgMCAzLjY3MS45OTIgNC45MzMgMi4wNzggMS4yNyAxLjA5MSAyLjE4NyAyLjM0NSAyLjYzNyAzLjAyM2ExLjYyIDEuNjIgMCAwIDEgMCAxLjc5OGMtLjQ1LjY3OC0xLjM2NyAxLjkzMi0yLjYzNyAzLjAyM0MxMS42NyAxMy4wMDggOS45ODEgMTQgOCAxNGMtMS45ODEgMC0zLjY3MS0uOTkyLTQuOTMzLTIuMDc4QzEuNzk3IDEwLjgzLjg4IDkuNTc2LjQzIDguODk4YTEuNjIgMS42MiAwIDAgMSAwLTEuNzk4Yy40NS0uNjc3IDEuMzY3LTEuOTMxIDIuNjM3LTMuMDIyQzQuMzMgMi45OTIgNi4wMTkgMiA4IDJaTTEuNjc5IDcuOTMyYS4xMi4xMiAwIDAgMCAwIC4xMzZjLjQxMS42MjIgMS4yNDEgMS43NSAyLjM2NiAyLjcxN0M1LjE3NiAxMS43NTggNi41MjcgMTIuNSA4IDEyLjVjMS40NzMgMCAyLjgyNS0uNzQyIDMuOTU1LTEuNzE1IDEuMTI0LS45NjcgMS45NTQtMi4wOTYgMi4zNjYtMi43MTdhLjEyLjEyIDAgMCAwIDAtLjEzNmMtLjQxMi0uNjIxLTEuMjQyLTEuNzUtMi4zNjYtMi43MTdDMTAuODI0IDQuMjQyIDkuNDczIDMuNSA4IDMuNWMtMS40NzMgMC0yLjgyNS43NDItMy45NTUgMS43MTUtMS4xMjQuOTY3LTEuOTU0IDIuMDk2LTIuMzY2IDIuNzE3Wk04IDEwYTIgMiAwIDEgMS0uMDAxLTMuOTk5QTIgMiAwIDAgMSA4IDEwWiIgZmlsbD0iIzg0OEQ5NyIvPjwvc3ZnPg==)
+ &color=rgba(0%2C%200%2C%200%2C%200)&logo=data:image/svg%2bxml;base64,PHN2ZyByb2xlPSJpbWciIHZpZXdCb3g9IjAgMCAxNiAxNiIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj48dGl0bGU+R2l0SHViIEZvcmtzPC90aXRsZT48cGF0aCBkPSJNNSA1LjM3MnYuODc4YzAgLjQxNC4zMzYuNzUuNzUuNzVoNC41YS43NS43NSAwIDAgMCAuNzUtLjc1di0uODc4YTIuMjUgMi4yNSAwIDEgMSAxLjUgMHYuODc4YTIuMjUgMi4yNSAwIDAgMS0yLjI1IDIuMjVoLTEuNXYyLjEyOGEyLjI1MSAyLjI1MSAwIDEgMS0xLjUgMFY4LjVoLTEuNUEyLjI1IDIuMjUgMCAwIDEgMy41IDYuMjV2LS44NzhhMi4yNSAyLjI1IDAgMSAxIDEuNSAwWk01IDMuMjVhLjc1Ljc1IDAgMSAwLTEuNSAwIC43NS43NSAwIDAgMCAxLjUgMFptNi43NS43NWEuNzUuNzUgMCAxIDAgMC0xLjUuNzUuNzUgMCAwIDAgMCAxLjVabS0zIDguNzVhLjc1Ljc1IDAgMSAwLTEuNSAwIC43NS43NSAwIDAgMCAxLjUgMFoiIGZpbGw9IiM4NDhEOTciLz48L3N2Zz4=)
+ 
+ We empower PowerShell-savvy developers to effortlessly transform their ideas into impactful solutions. Our approach centers around a development framework that allows developers to focus on delivering value through their code. By leveraging the GitHub platform and PowerShell, we aim to automate the repetitive tasks, enabling developers \u2014 whether as consumers or contributors \u2014 to concentrate on coding without distractions.
"},{"location":"#supported-platforms","title":"Supported Platforms","text":"This development framework is built to serve the needs of modern developers and environments. We prioritize supporting the latest Long-Term Servicing (LTS) version of PowerShell to ensure that we can leverage the most recent features and capabilities, keeping our framework aligned with the demands of today\u2019s development landscape. We assume most of the users of this framework work on modern platforms and have access to the latest versions of PowerShell or seek to use it to develop solutions intended to run on modern systems, like GitHub Actions, Azure Functions on a developer machine.
"},{"location":"#the-trade-off-not-supporting-windows-powershell","title":"The Trade-Off: Not Supporting Windows PowerShell","text":"We\u2019ve made a deliberate choice not to actively persure to support the older Windows PowerShell (5.1) version, as it limits our ability to use the newest PowerShell features. Where its low effort to support Windows PowerShell, we will do so, but we will not actively develop modules for it. While we recognize that some users may still rely on Windows PowerShell 5.1, they can run tools developed in this framework by installing PowerShell 7 alongside it or on remote systems. This decision ensures that this framework can focus on delivering new features for modern development without being constrained by legacy technology, which would otherwize require significant effort to develop and maintain, even if it is available in the newer versions of PowerShell.
"},{"location":"#products-and-projects-we-focus-on","title":"Products and projects we focus on","text":"Our framework is dedicated to advancing the tools and processes that empower modern development and operations teams, with a specific focus on GitHub as our primary toolstack. We concentrate on the following key areas:
We are PSModule :)
"},{"location":"Blog/","title":"Blog","text":"Welcome to the PSModule blog! Here you'll find the latest news, updates, and insights related to PowerShell + GitHub development.
"},{"location":"Blog/2024/01/31/test-blog-post/","title":"Test blog post","text":"This is a test blog post.
","tags":["Foo","Bar"]},{"location":"Dictionary/","title":"Dictionary","text":"Welcome to the PSModule Dictionary - a comprehensive glossary of terms, concepts, and technologies used throughout our projects and documentation.
"},{"location":"Dictionary/#quick-reference","title":"Quick Reference","text":"Common terms you might encounter: - API - Application Programming Interface - Azure - Microsoft's cloud platform - CI/CD - Continuous Integration/Continuous Deployment - Cmdlet - PowerShell command - Git - Version control system - GitHub - Code hosting platform - LTS - Long-Term Servicing - MkDocs - Documentation generator - Module - PowerShell package - Pipeline - Automated process chain - PowerShell - Task automation framework - Repository - Code storage location - Workflow - Automated process series
"},{"location":"Dictionary/#overview","title":"Overview","text":"This dictionary serves as a reference for developers, contributors, and users to understand the terminology and concepts used in PSModule projects. Each entry includes clear definitions, usage examples, and related links where applicable.
"},{"location":"Dictionary/#a","title":"A","text":""},{"location":"Dictionary/#api","title":"API","text":"Application Programming Interface (API) - A set of protocols, routines, and tools for building software applications. APIs specify how software components should interact and are used when programming graphical user interface (GUI) components.
Example: The GitHub API allows developers to interact with GitHub repositories, issues, and pull requests programmatically.
"},{"location":"Dictionary/#azure","title":"Azure","text":"Microsoft's cloud computing platform that provides a wide range of cloud services, including compute, analytics, storage, and networking.
Related: Azure Functions, Azure DevOps
"},{"location":"Dictionary/#azure-devops","title":"Azure DevOps","text":"A set of development tools and services from Microsoft for software development teams, including version control, build automation, and project management.
"},{"location":"Dictionary/#azure-functions","title":"Azure Functions","text":"A serverless compute service that lets you run event-triggered code without having to explicitly provision or manage infrastructure.
"},{"location":"Dictionary/#b","title":"B","text":""},{"location":"Dictionary/#branch","title":"Branch","text":"In version control systems like Git, a branch is a parallel version of a repository that diverges from the main working project.
Example: Feature branches are used to develop new features in isolation before merging back to the main branch.
"},{"location":"Dictionary/#build-pipeline","title":"Build Pipeline","text":"An automated process that compiles, tests, and packages source code into deployable artifacts.
"},{"location":"Dictionary/#c","title":"C","text":""},{"location":"Dictionary/#cicd","title":"CI/CD","text":"Continuous Integration/Continuous Deployment (CI/CD) - A software development practice where developers regularly merge their code changes into a central repository, after which automated builds and tests are run.
"},{"location":"Dictionary/#cmdlet","title":"Cmdlet","text":"A lightweight PowerShell command that follows the verb-noun naming convention and is designed to perform a specific function.
Example: Get-Process, Set-Location, New-Item
A lightweight, standalone, executable package that includes everything needed to run an application: code, runtime, system tools, libraries, and settings.
"},{"location":"Dictionary/#d","title":"D","text":""},{"location":"Dictionary/#devops","title":"DevOps","text":"A set of practices that combines software development (Dev) and IT operations (Ops) to shorten the systems development life cycle and provide continuous delivery.
"},{"location":"Dictionary/#docker","title":"Docker","text":"A platform for developing, shipping, and running applications using containerization technology.
"},{"location":"Dictionary/#g","title":"G","text":""},{"location":"Dictionary/#git","title":"Git","text":"A distributed version control system for tracking changes in source code during software development.
"},{"location":"Dictionary/#github","title":"GitHub","text":"A web-based platform for version control and collaboration that lets you and others work together on projects from anywhere.
"},{"location":"Dictionary/#github-actions","title":"GitHub Actions","text":"GitHub's built-in CI/CD platform that allows you to automate your build, test, and deployment pipeline.
Example: Automatically running tests when a pull request is created.
"},{"location":"Dictionary/#l","title":"L","text":""},{"location":"Dictionary/#lts","title":"LTS","text":"Long-Term Servicing (LTS). For more info visit: PowerShell Support Lifecycle
"},{"location":"Dictionary/#m","title":"M","text":""},{"location":"Dictionary/#markdown","title":"Markdown","text":"A lightweight markup language with plain text formatting syntax, designed to be converted to HTML and many other formats.
"},{"location":"Dictionary/#mkdocs","title":"MkDocs","text":"A fast, simple static site generator that's geared towards building project documentation using Markdown files.
"},{"location":"Dictionary/#module","title":"Module","text":"In PowerShell, a package that contains PowerShell members, such as cmdlets, providers, functions, workflows, variables, and aliases.
"},{"location":"Dictionary/#p","title":"P","text":""},{"location":"Dictionary/#pipeline","title":"Pipeline","text":"A series of automated processes that allow developers and DevOps professionals to reliably and efficiently compile, build, and deploy their code.
"},{"location":"Dictionary/#powershell","title":"PowerShell","text":"A task automation and configuration management framework from Microsoft, consisting of a command-line shell and the associated scripting language.
"},{"location":"Dictionary/#pull-request","title":"Pull Request","text":"Pull Request (PR) - A method of submitting contributions to a software project where changes are proposed and reviewed before being merged into the main codebase.
"},{"location":"Dictionary/#r","title":"R","text":""},{"location":"Dictionary/#repository","title":"Repository","text":"Repository (Repo) - A storage location for software packages, often used in version control systems to store project files and their revision history.
"},{"location":"Dictionary/#rest-api","title":"REST API","text":"An architectural style for designing web services that uses HTTP requests to GET, PUT, POST, and DELETE data.
"},{"location":"Dictionary/#s","title":"S","text":""},{"location":"Dictionary/#semantic-versioning","title":"Semantic Versioning","text":"Semantic Versioning (SemVer) - A versioning scheme that uses a three-part version number: MAJOR.MINOR.PATCH, where each part is incremented based on the type of changes made.
Example: Version 1.2.3 where 1 is major, 2 is minor, and 3 is patch.
"},{"location":"Dictionary/#static-site-generator","title":"Static Site Generator","text":"A tool that generates a full static HTML website based on raw data and a set of templates.
"},{"location":"Dictionary/#t","title":"T","text":""},{"location":"Dictionary/#template","title":"Template","text":"A pre-designed format or structure that can be used as a starting point for creating new files, projects, or configurations.
"},{"location":"Dictionary/#testing","title":"Testing","text":"The process of evaluating and verifying that a software application or system meets specified requirements and functions correctly.
"},{"location":"Dictionary/#v","title":"V","text":""},{"location":"Dictionary/#version-control","title":"Version Control","text":"A system that records changes to a file or set of files over time so that you can recall specific versions later.
"},{"location":"Dictionary/#virtual-environment","title":"Virtual Environment","text":"An isolated environment that allows you to install packages and dependencies without affecting the global system installation.
"},{"location":"Dictionary/#w","title":"W","text":""},{"location":"Dictionary/#workflow","title":"Workflow","text":"A series of automated steps or processes that execute in response to specific events or triggers.
Example: A GitHub Actions workflow that runs tests every time code is pushed to a repository.
"},{"location":"Dictionary/#y","title":"Y","text":""},{"location":"Dictionary/#yaml","title":"YAML","text":"YAML Ain't Markup Language (YAML) - A human-readable data serialization standard commonly used for configuration files and data exchange.
Example: GitHub Actions workflows are defined using YAML files.
Contributing to the Dictionary
Found a term that should be added or need to update an existing definition? Please create an issue or submit a pull request with your suggestions.
Search Functionality
Use the search feature in the top navigation to quickly find specific terms and their definitions across the entire documentation site.
"},{"location":"GitHub-Actions/","title":"GitHub Actions","text":"Action parameters:
For nested actions we should be using unique names for the github action. The names of the action should be something like _INPUT"},{"location":"GitHub-Actions/Some-More/","title":"Some more","text":""},{"location":"GitHub-Actions/Test-Something/","title":"Test something","text":""},{"location":"GitHub-Actions/Subtopic/","title":"Subtopic","text":""},{"location":"GitHub-Actions/Subtopic/Some-More/","title":"Some more","text":""},{"location":"GitHub-Actions/Subtopic/Test-Something/","title":"Test something","text":""},{"location":"PowerShell-Modules/","title":"PowerShell","text":"
qweqwe
"},{"location":"PowerShell-Modules/Test-Specification/","title":"PowerShell Function Test Specification","text":""},{"location":"PowerShell-Modules/Test-Specification/#overview","title":"Overview","text":"This document defines the structure and guidelines for writing Pester tests for PowerShell functions. The goal is to ensure consistency and comprehensive test coverage while maintaining clarity.
"},{"location":"PowerShell-Modules/Test-Specification/#test-structure","title":"Test Structure","text":"Each function is tested within a structured Pester Describe block that follows this hierarchy:
Describe","text":"Describe block corresponds to the module.Describe","text":"Describe block.Context","text":"Context block.Get-Uri - simple usageGet-Uri - Pipeline usageGet-Uri - ParameterSet: DetailedIt Statements","text":"It block tests a specific aspect of the function's behavior.FunctionName - <expected behavior>Get-Uri - gets the URI object when provided a stringGet-Uri - returns $null when input is emptyGet-Uri - throws error on invalid inputDescribe 'Uri' {\n Describe 'Get-Uri' {\n Context 'Get-Uri - simple usage' {\n It 'Get-Uri - gets the URI object when provided a string' {\n $result = Get-Uri -InputString 'https://example.com'\n $result | Should -BeOfType [System.Uri]\n }\n }\n\n Context 'Get-Uri - Pipeline usage' {\n It 'Get-Uri - processes input from the pipeline' {\n $result = 'https://example.com' | Get-Uri\n $result | Should -BeOfType [System.Uri]\n }\n }\n }\n}\nThis ensures our tests are structured, maintainable, and adhere to best practices.
"},{"location":"PowerShell-Modules/Versioning/","title":"PowerShell Module Semantic Versioning Specification","text":""},{"location":"PowerShell-Modules/Versioning/#introduction","title":"Introduction","text":"This document defines how changes to a PowerShell module\u2019s public interface determine updates to its version number under Semantic Versioning (SemVer). Semantic Versioning uses a three-part version format: MAJOR.MINOR.PATCH, where each part is incremented based on the nature of changes: - MAJOR version is incremented for incompatible API changes (breaking changes) (Semantic Versioning 2.0.0 | Semantic Versioning). - MINOR version is incremented for added functionality that is backward compatible (new features) (Semantic Versioning 2.0.0 | Semantic Versioning). - PATCH version is incremented for backward-compatible bug fixes or minor improvements (Semantic Versioning 2.0.0 | Semantic Versioning).
In the context of a PowerShell module, the \u201cpublic API\u201d consists of all exported functions/cmdlets, public variables, classes, and enums that consumers of the module can use. Changes to these exported elements will dictate whether the version bump is major, minor, or patch. Internal changes that do not affect the exported interface are generally not reflected in the version. The following sections categorize changes and the required version update level, ensuring a consistent and predictable versioning strategy.
"},{"location":"PowerShell-Modules/Versioning/#major-version-x-breaking-changes","title":"Major Version (X) \u2013 Breaking Changes","text":"A major version bump signifies a breaking change in the module\u2019s public interface. Any modification that could cause existing scripts or code relying on the module to fail or change behavior in an incompatible way requires incrementing the MAJOR version. These include:
Removal or Renaming of Exported Commands or Elements: Removing an exported function/cmdlet, variable, class, or enum, or renaming any of these, is a breaking change. Consumers referencing the old name will encounter errors because the item no longer exists or has a different name. (Example: Get-ItemFoo was exported in the previous version but is removed or renamed to Get-FooItem in the new version. Scripts calling Get-ItemFoo will break.) This kind of change must increment the major version to signal the break.
Changes to Function Signatures: Modifying the signature of an exported function or cmdlet in a non-backward-compatible way triggers a major bump. This includes:
Example: An exported function Invoke-ProcessData -Path <string> is changed to Invoke-ProcessData -Uri <string> (parameter renamed) or an existing parameter is removed. Scripts using the old parameter name or expecting that parameter will fail, hence a major version increment is needed.
Example: An exported class FileClient had a public property Timeout that is removed or renamed, or a method Connect(string server) is changed to Connect(Uri server). Code instantiating FileClient or calling its methods would break, so the major version must increase.
Example: An exported enum LogLevel had members Info, Warning, Error. If Warning is removed or renamed to Warn, any script using LogLevel.Warning will break. Such a change mandates a major version bump. (Adding a new enum value is not breaking \u2013 see Minor changes.)
Rationale: According to Semantic Versioning, introducing changes that are not backward compatible requires a major version increment (Semantic Versioning 2.0.0 | Semantic Versioning). By increasing the major version, we communicate to users that they may need to adjust their scripts due to breaking changes. This aligns with the principle that \u201cMAJOR version when you make incompatible API changes\u201d (Semantic Versioning 2.0.0 | Semantic Versioning). For example, if a function or parameter that existed in version 1.x is no longer present in version 2.0, that is an incompatible API change. Our versioning policy follows this rule strictly: breaking changes will never be introduced in a minor or patch release, ensuring that patch and minor updates can be safely adopted without fear of script-breaking surprises.
"},{"location":"PowerShell-Modules/Versioning/#minor-version-y-backward-compatible-additions","title":"Minor Version (Y) \u2013 Backward-Compatible Additions","text":"A minor version bump is used for new features and additions that are backward compatible with the existing public API. These changes enhance the module\u2019s functionality without breaking any existing usage. In other words, existing scripts will continue to work as before, and new capabilities are introduced. Changes that trigger a MINOR version increase include:
Adding New Exported Functions/Cmdlets: Introducing a new function or cmdlet to the module is a backward-compatible addition. Since it does not remove or change existing functions, nothing breaks; users simply have an additional function available. Example: Adding a new cmdlet New-Report to the module (where it didn\u2019t exist before) would be a new feature. This warrants a minor version bump because it\u2019s an additive, non-breaking change.
Adding New Parameters to Existing Functions: If you extend an existing function\u2019s capabilities by adding a new parameter in a way that does not break existing calls, it is a minor change. The key here is that the new parameter must be optional or have a default value such that any existing calls (which don\u2019t pass this parameter) still work exactly as before. In semantic versioning terms, this is adding functionality in a backwards-compatible manner (semantic versioning - Does adding a parameter to a function definition require a new major version? - Stack Overflow).
-Force switch or an optional -TimeoutSeconds parameter (with a default value) to a function is a minor update. Users can start using the new parameter if they want the new behavior, but all old usages remain valid.Important: If a new parameter is added as required (with no default), that breaks existing calls (which would now be missing a required argument), and thus would be a breaking change requiring a major bump (semantic versioning - Does adding a parameter to a function definition require a new major version? - Stack Overflow). So, new parameters must be introduced in a backward-compatible way (optional or with defaults) to qualify as a minor version update.
Adding New Exported Variables: If the module begins to export a new public variable (for example, a new preference variable or a constant) that wasn\u2019t present before, it\u2019s an additive change. Since no existing variable is removed or changed, existing scripts are unaffected (they simply might not use or know about the new variable). This constitutes a minor version increment. Example: Adding a new $PublicConfig variable that scripts can read is a new feature, bumped in the minor version.
Adding New Classes or Members: Introducing a new public class (exported from the module) or adding new members to an existing exported class in a non-breaking way is a minor change:
Adding a new method or property to an existing exported class can be considered backward compatible as long as it doesn\u2019t conflict with existing members. Existing scripts constructing or using the class will continue to work as before. (One caveat: if consumers have derived from this class, adding new abstract members would be breaking, but assuming typical usage where classes are used as-is, new members are just additional features.) Example: A class Connection gains a new method TestConnection() in version 1.2. Previous scripts using Connection are not affected (they don\u2019t call the new method), but now have the option to use TestConnection. This is a minor feature addition.
Adding New Enum Values or New Enums: If the module introduces a new enumeration type, or adds additional members to an existing enum, it\u2019s generally treated as a backward-compatible addition:
Color with values Red/Green/Blue) is additive.New Value in Existing Enum: Adding a value to an existing exported enum can be viewed as a new feature. Code that doesn\u2019t know about the new value isn\u2019t forced to use it. (Existing switch statements or logic that enumerate enum values may not account for it, but they won\u2019t immediately break at runtime; however, developers should update their code to handle the new case if appropriate. Since it doesn\u2019t outright break compilation or invocation in PowerShell, it\u2019s considered backward compatible in this context.) Example: The enum LogLevel had Info, Warning, Error. If we add Verbose as a new level in a minor release, existing scripts using LogLevel continue to run (they might not handle Verbose if encountered, but nothing crashes by the mere presence of the new value). It\u2019s an additive feature, hence a minor bump.
Non-Breaking Changes to Existing Features: In some cases, a change might alter behavior but still be backward compatible. For instance, making an existing parameter accept a new type of input in addition to existing types (broadening what is accepted) could be considered a new capability that doesn\u2019t break old usage. Such changes can fall under minor version if they extend functionality without removal or contradiction of the old behavior. (However, caution is advised: changing behavior can sometimes surprise users. If in doubt, treat as major if it might disrupt assumptions.)
In summary, any new functionality that does not force existing users to change their usage is a candidate for a minor version increment (Semantic Versioning 2.0.0 | Semantic Versioning). Minor releases accumulate enhancements and new features, signalling to users that new capabilities are available, but all existing scripts should continue to work as they did in the previous version. Users can upgrade to the new minor version and gain new functions or options without needing to modify their existing code. This aligns with the SemVer guideline that \u201cMINOR version [increments] when you add functionality in a backward compatible manner\u201d (Semantic Versioning 2.0.0 | Semantic Versioning).
"},{"location":"PowerShell-Modules/Versioning/#patch-version-z-bug-fixes-and-improvements","title":"Patch Version (Z) \u2013 Bug Fixes and Improvements","text":"A patch version bump is used for changes that do not affect the module\u2019s public API or add new features, but rather fix issues or improve internal implementation. Patch updates are meant to be safe, drop-in updates for users, with no risk of breaking functionality or changing how features are used. Scenarios for a PATCH version increment include:
Resolving a minor issue where an enum value wasn\u2019t handled in an internal function (assuming no public API change). As long as the outward-facing contract remains the same (same function name, parameters, outputs), these are patch changes. Consumers might notice the bug is resolved, but they do not need to change their code \u2013 they just get the benefit of the fix.
Performance Improvements: Optimizations that improve the performance or efficiency of the module without affecting the external behavior or API. For instance, rewriting an algorithm inside a function to run faster or use less memory, but with the same input/output interface and results, qualifies as a patch. Users\u2019 experience may improve (faster execution), but they don\u2019t need to change anything in their usage. This is a non-breaking internal improvement.
Refactoring and Internal Cleanup: Changes to the internal code structure, organization, or quality that do not change any aspect of the public interface or observable behavior fall under patch (or possibly no version change at all \u2013 see the next section). If you release a new version that purely refactors code (improves maintainability, updates comments, reorganizes module files) and the module\u2019s exported functions and behavior remain identical, it can be considered a patch update. From the user\u2019s perspective, nothing changed functionally, so there\u2019s no new feature (hence not a minor) and no break (hence not a major). Releasing it as a patch version indicates it\u2019s a minor improvement or maintenance release.
Documentation or Metadata Updates: If you publish a new version to update documentation included in the module (e.g., help content) or to adjust module metadata (like author info, tags, etc.) without any code change affecting functionality, this would be a patch version increment. (However, often documentation changes alone might not necessitate a new release; if they do, patch is appropriate since the API is unchanged.)
Note: A patch release should not introduce any new public surface area or change the meaning of anything in the public API. It is strictly for fixes and invisible improvements. According to SemVer rules, \u201cPATCH version when you make backwards-compatible bug fixes\u201d (Semantic Versioning 2.0.0 | Semantic Versioning) \u2013 this includes fixes and minor tweaks that do not affect compatibility. Users upgrading from one patch version to the next within the same minor series (e.g., 1.2.3 to 1.2.4) should notice no differences except the resolved issues or performance gains. They do not get new features (and thus don\u2019t need to learn anything new), and they do not have to worry about breaks.
"},{"location":"PowerShell-Modules/Versioning/#internal-changes-with-no-version-impact","title":"Internal Changes with No Version Impact","text":"Certain changes do not require any version number increase at all, because they have no effect on the module\u2019s outward-facing behavior or interface. In a disciplined development practice, if the only changes in a commit or release are purely internal and produce no difference in functionality or API, the version can remain the same. In practice, such changes are often bundled with other changes or released as patch versions if needed. But as a guideline, metadata or refactoring changes that do not impact the exported interface should not influence the version number (they are essentially \u201cno-ops\u201d as far as the user is concerned). Examples:
Refactoring without Behavioral Changes: If the code is refactored (e.g., splitting a large function into smaller private helper functions, renaming internal variables, improving readability) but the exported functions, classes, and variables all behave exactly the same and have the same signatures, then there\u2019s no need for a version change. The module behaves identically from the consumer\u2019s perspective.
Build System or Test Changes: Updates to the module\u2019s build scripts, continuous integration configuration, or test suite do not require a version bump. These are changes for the developers/maintainers and do not ship to the user in a way that affects usage.
Metadata Updates: Changing non-functional metadata such as author name, project URL, licensing info, etc., in the module manifest (PSD1) doesn\u2019t affect how the module is used at runtime. Such changes alone don\u2019t merit a version increment.
Formatting and Comments: Modifying code formatting, comments, or other non-executable parts of the code has no effect on functionality. No version change is needed for these kinds of modifications alone.
No-Op Rebuilds: In some cases, a module might be rebuilt or repackaged without any code changes (for example, re-signing the module or packaging it differently). If the contents of the module\u2019s public API and behavior are unchanged, the version number should ideally remain the same. (If a rebuild must be published, one might use the same version or a patch if required by tooling, but from a semantic standpoint, nothing changed.)
In summary, if a change does not modify or add to the public interface and does not fix a user-facing bug, it should not cause any visible version change. The automated versioning scripts or maintainers should ignore such changes when determining how to bump the version. Essentially, purely internal changes = no bump (or at most a patch if a release is needed for some reason). This ensures the version number reflects meaningful changes that users care about.
(Note: In practice, every release must have a unique version. So if you are releasing changes that have no API impact, you might still increment the patch to publish it. But the key is that those internal changes by themselves never escalate the version beyond patch, and if they are truly no-ops, you might choose not to release until there\u2019s a user-facing change.)
"},{"location":"PowerShell-Modules/Versioning/#versioning-strategy-and-update-expectations","title":"Versioning Strategy and Update Expectations","text":"This module follows a \u201clatest version\u201d support strategy, meaning that only the most recent release is fully supported and maintained. When a new version is released, it supersedes previous versions. Older versions are not maintained, and users are expected to upgrade to the latest version to receive fixes and new features. As stated in Microsoft\u2019s guidance for PowerShell modules: \u201cOnly the latest major version receives full support, including new features, bug fixes, and updates. We strongly recommend upgrading to the latest version\u2026\u201d (Versioning, release cadence, and breaking changes - Microsoft Entra PowerShell | Microsoft Learn). In our context, this means:
We do not create maintenance releases for older major versions. For example, if the module is currently at 2.x, we will not typically release further updates for 1.x; any fixes or enhancements will go into a new 2.x (or later) release. The focus is on moving forward with the latest version of the module.
Breaking changes will be introduced only with a major version bump, and when we do increment the major version, users should plan to update their scripts to accommodate those changes. Since older majors won\u2019t get back-ported fixes, upgrading is important to stay supported.
Minor and patch releases are intended to be safe to adopt (no breaking changes). Users should feel confident updating to a new minor version within the same major series to get new features, and applying patch updates for bug fixes. Given that we don\u2019t maintain parallel old versions, applying these updates is the primary way to get issues resolved.
Semantic versioning in this module serves as a contract with users: by looking at how the version changed, users can tell what to expect:
By adhering to this strategy, we ensure clarity and consistency. Users who always upgrade to the latest version will benefit from all improvements and will only need to make script changes when a major version increments (which will be clearly indicated by the version number change).
"},{"location":"PowerShell-Modules/Versioning/#automated-version-bump-determination-implementation","title":"Automated Version Bump Determination (Implementation)","text":"To enforce the above rules, we will use custom PowerShell scripts as part of our build/release process to automatically determine the appropriate version bump based on the changes in the module. The automation will compare the module\u2019s exported interface between the current release and the new version under development: - It will detect additions of public elements (functions, parameters, variables, classes, enum values) and detect removals or changes to public elements. - Based on this comparison, the script will decide the version increment: - If new public functions, new optional parameters, or other new exported members are found (and no breaking changes), the script will set the version bump to Minor (since new functionality has been added in a backwards-compatible way). - If any exported function/variable/class/enum from the previous version is missing in the new version, or a function\u2019s signature has changed incompatibly, etc., the script will flag a Major bump (since a breaking change was detected). - If no differences in the public API are found (meaning no new features and no removed/changed features), then the changes must be purely fixes or internal improvements. In this case, the script will default to a Patch bump (PowerShell: Automatic Module Semantic Versioning).
This approach mirrors the \u201cfingerprint\u201d strategy: generating a list (fingerprint) of all public API elements (e.g., FunctionName:ParameterName for each parameter of each function, plus entries for other exported members) for the current and previous version, and comparing them (PowerShell: Automatic Module Semantic Versioning) (PowerShell: Automatic Module Semantic Versioning). - If the new fingerprint has entries not present in the old fingerprint, those represent new capabilities (triggering a minor version increase) (PowerShell: Automatic Module Semantic Versioning). - If the old fingerprint has entries not present in the new fingerprint, those represent removed or changed items (triggering a major version increase) (PowerShell: Automatic Module Semantic Versioning). - If neither additions nor removals are detected, only patch-level changes exist (PowerShell: Automatic Module Semantic Versioning).
Using automation ensures that our versioning rules are applied consistently on every release. However, we will also manually review changes for any subtleties that automation might miss. For example, a change in behavior that is technically backward-compatible in the API surface might still be communicated as a bigger change if it could impact users (the automation might view it as no API change, but maintainers might still choose to bump minor for a significant new behavior or even major if a fix alters expected outcomes in rare cases). The tooling serves as a baseline, and maintainers can override or augment the decision if necessary (but always adhering to the rule that breaking changes cannot be released under a non-major bump).
Example of the automated logic in practice: Suppose in version 1.3.0 the module has a function Get-Data -Path <string> and in the development code we change this to Get-Data -Path <string> -Filter <string>, where -Filter is a new optional parameter. The script compares the exported interface: - Old version fingerprint might include an entry like Get-Data:Path for the parameter. - New version fingerprint includes Get-Data:Path and Get-Data:Filter. The new fingerprint has an entry not in the old (Get-Data:Filter), indicating a new parameter. The old fingerprint has none that the new lacks (we didn\u2019t remove anything; Path is still there). So the tool will identify a new feature addition with no removals, resulting in a Minor bump (1.4.0). This matches our expectation: adding an optional -Filter parameter is a backward-compatible enhancement.
If instead we had removed -Path or renamed Get-Data to Get-ItemData, the old fingerprint would contain entries not in the new, flagging a breaking change. The script would then recommend a Major bump (to 2.0.0), aligning with our policy that such a removal/rename is breaking.
If we only fixed a bug inside Get-Data but made no changes to its parameters or outputs, the fingerprints would be identical. The automation would not find any new or removed public element, and thus default to a Patch bump (1.3.1). This ensures even unseen internal changes result in at least a patch update if a release is made, but nothing more.
This specification provides a clear framework for versioning a PowerShell module in accordance with Semantic Versioning principles, tailored to the specific elements of a PowerShell module\u2019s public interface. By classifying changes into major, minor, or patch categories, we ensure that the module\u2019s version number accurately communicates the impact of changes: - Major versions for breaking changes (removals, renames, incompatible alterations). - Minor versions for new features and additions that are backward compatible. - Patch versions for bug fixes and non-breaking improvements.
Developers maintaining the module can use these guidelines to decide the appropriate version number for each release. Automated scripts will assist in detecting the scope of changes, but sound judgment will be applied in edge cases. Users of the module can rely on the version number to understand the significance of an update. Ultimately, this practice enables a predictable upgrade path where users only need to be concerned about potential breaking changes when the major version increases, and are otherwise free to take minor and patch updates confidently.
By adhering to this specification, we uphold a contract of compatibility and improvement with our users, making module releases transparent and manageable in the long run.
"},{"location":"Solutions/","title":"Solutions","text":"qweqwe
"},{"location":"Solutions/GitHub-Copilot-Customization-Architecture/","title":"GitHub Copilot Customization Architecture","text":"This specification documents a scalable GitHub Copilot customization architecture designed to provide consistent guidance, prompts, and chat modes across multiple repositories in community organizations and enterprises.The architecture addresses the challenge of managing GitHub Copilot configurations at scale by implementing a multi-tier approach that balances centralized governance with project-specific flexibility. This system enables organizations to:
The architecture replaces GitHub Copilot's single-file approach with a structured three-tier system that manages instructions, prompts, and chat modes through a hierarchical precedence model.
"},{"location":"Solutions/GitHub-Copilot-Customization-Architecture/#purpose-and-context","title":"Purpose and Context","text":"Modern software organizations require a structured system for managing GitHub Copilot configuration files that enables AI agents to make consistent changes across multiple repositories while allowing for project-specific customization.
Due to the absence of native organization-wide configuration support in GitHub that provides a single location for common Copilot configurations, this architecture implements a scalable multi-tier approach for managing:
This architecture serves multiple organizational contexts: - Enterprises: Large organizations needing centralized AI assistance standards across teams and projects - Enterprise Adoption: Enterprises adopting community frameworks while maintaining their own customizations - Multi-Division Enterprises: Large organizations with division-specific requirements within enterprise standards - Community Organizations: Open source projects and community frameworks requiring consistent standards across repositories
"},{"location":"Solutions/GitHub-Copilot-Customization-Architecture/#architecture-specification","title":"Architecture Specification","text":""},{"location":"Solutions/GitHub-Copilot-Customization-Architecture/#three-tier-management-system","title":"Three-Tier Management System","text":"Each Copilot configuration type follows a flexible three-tier management approach:
This design allows organizations to: - Enforce enterprise-wide governance and compliance requirements - Adopt community standards and frameworks as a foundation - Allow repository-level customization within enterprise and organizational constraints
"},{"location":"Solutions/GitHub-Copilot-Customization-Architecture/#design-decision-legacy-file-elimination","title":"Design Decision: Legacy File Elimination","text":"The file .github/copilot-instructions.md is not supported in this architecture. This specification replaces the simplified single-file approach with a structured system that manages all GitHub Copilot configuration files through multi-tier management.
The multi-tier Copilot files can be automatically synchronized from different sources:
Enterprise Tier Synchronization: - Source: Enterprise's central configuration repository - Target: Enterprise repositories (optional, based on enterprise policy) - Content: Enterprise-specific customizations, compliance requirements, security patterns
Organization Tier Synchronization: - Source: Community framework or organization's base repository - Target: All repositories adopting the framework - Content: Universal patterns and base standards
Repository Tier Management: - Source: Local repository maintenance - Target: Current repository only - Content: Project-specific overrides and customizations
The synchronization process applies to all Copilot configuration types: - Updates: Files under organization/ and enterprise/ folders are managed by automation - Preserves: All files under repository/ folders are never modified by sync mechanisms - Flexibility: Organizations can choose which tiers to implement and their synchronization criteria
The .github/ folder contains three Copilot configuration directories, each supporting the three-tier structure:
.github/\n\u251c\u2500\u2500 instructions/ # AI agent guidance and patterns\n\u2502 \u251c\u2500\u2500 enterprise/ # Enterprise-managed customizations (automated sync, optional)\n\u2502 \u2502 \u251c\u2500\u2500 main.instructions.md # Enterprise-wide guidelines and compliance\n\u2502 \u2502 \u2514\u2500\u2500 {Language}/ # Enterprise language-specific patterns\n\u2502 \u2502 \u251c\u2500\u2500 main.instructions.md # Enterprise style guides (e.g., C# enterprise standards)\n\u2502 \u2502 \u2514\u2500\u2500 {context}.instructions.md # Enterprise context requirements\n\u2502 \u251c\u2500\u2500 organization/ # Community/framework-managed patterns (automated sync)\n\u2502 \u2502 \u251c\u2500\u2500 main.instructions.md # Core framework guidelines\n\u2502 \u2502 \u2514\u2500\u2500 {Language}/ # Language-specific framework patterns\n\u2502 \u2502 \u251c\u2500\u2500 main.instructions.md # Style guide and core instructions\n\u2502 \u2502 \u2514\u2500\u2500 {context}.instructions.md # Specialized context instructions\n\u2502 \u2514\u2500\u2500 repository/ # Repository-managed overrides (manual)\n\u2502 \u251c\u2500\u2500 main.instructions.md # Repository context and specific rules\n\u2502 \u2514\u2500\u2500 {Language}/ # Repository-specific language customizations\n\u2502 \u251c\u2500\u2500 main.instructions.md # Repository language patterns\n\u2502 \u2514\u2500\u2500 {context}.instructions.md # Repository context overrides\n\u251c\u2500\u2500 prompts/ # Reusable prompt templates\n\u2502 \u251c\u2500\u2500 enterprise/ # Enterprise-specific prompts (automated sync, optional)\n\u2502 \u2502 \u2514\u2500\u2500 {prompt-files} # Enterprise-customized prompt templates\n\u2502 \u251c\u2500\u2500 organization/ # Community/framework prompts (automated sync)\n\u2502 \u2502 \u2514\u2500\u2500 {prompt-files} # Standard framework prompt templates\n\u2502 \u2514\u2500\u2500 repository/ # Repository-specific prompts (manual)\n\u2502 \u2514\u2500\u2500 {prompt-files} # Project-specific prompt templates\n\u2514\u2500\u2500 chatmodes/ # Specialized conversation contexts\n \u251c\u2500\u2500 enterprise/ # Enterprise-specific chat modes (automated sync, optional)\n \u2502 \u2514\u2500\u2500 {chatmode-files} # Enterprise-customized chat modes\n \u251c\u2500\u2500 organization/ # Community/framework chat modes (automated sync)\n \u2502 \u2514\u2500\u2500 {chatmode-files} # Standard framework chat modes\n \u2514\u2500\u2500 repository/ # Repository-specific chat modes (manual)\n \u2514\u2500\u2500 {chatmode-files} # Project-specific chat modes\ninstructions/enterprise/main.instructions.md Enterprise-Managed, Optional Enterprise-wide guidelines, compliance requirements, and governance Instructions Enterprise instructions/enterprise/{Language}/main.instructions.md Enterprise-Managed, Optional Enterprise-specific language standards (e.g., \"C# Enterprise coding standards\") Instructions Enterprise instructions/enterprise/{Language}/{context}.instructions.md Enterprise-Managed, Optional Enterprise-specific patterns for compliance, security, or organizational needs Instructions Organization instructions/organization/main.instructions.md Community/Framework-Managed Universal framework guidelines and architectural principles Instructions Organization instructions/organization/{Language}/main.instructions.md Community/Framework-Managed Community standard style guides and language-specific patterns Instructions Organization instructions/organization/{Language}/{context}.instructions.md Community/Framework-Managed Framework-specific patterns for specialized scenarios Instructions Repository instructions/repository/main.instructions.md Repository-Managed Repository-specific context, technology stack, and project rules Instructions Repository instructions/repository/{Language}/main.instructions.md Repository-Managed Project-specific language overrides and patterns Instructions Repository instructions/repository/{Language}/{context}.instructions.md Repository-Managed Most specific project-based overrides Prompts Enterprise prompts/enterprise/{name}.prompt.md Enterprise-Managed, Optional Enterprise-customized prompt templates incorporating company standards Prompts Organization prompts/organization/{name}.prompt.md Community/Framework-Managed Standard community prompt templates for common development scenarios Prompts Repository prompts/repository/{name}.prompt.md Repository-Managed Project-specific prompt templates tailored to repository requirements Chat Modes Enterprise chatmodes/enterprise/{name}.chatmode.md Enterprise-Managed, Optional Enterprise-specific conversation contexts incorporating company culture and standards Chat Modes Organization chatmodes/organization/{name}.chatmode.md Community/Framework-Managed Standard conversation contexts and AI behaviors from the community Chat Modes Repository chatmodes/repository/{name}.chatmode.md Repository-Managed Project-specific conversation contexts and behaviors"},{"location":"Solutions/GitHub-Copilot-Customization-Architecture/#context-file-examples","title":"Context File Examples","text":"For instructions, context-specific files may include: - File extension patterns: tests.instructions.md, classes.instructions.md - Folder-specific patterns: workflows.instructions.md, docs.instructions.md - Functional patterns: api.instructions.md, config.instructions.md, compliance.instructions.md
Instructions are evaluated and applied in hierarchical order, with more specific instructions taking precedence:
instructions/enterprise/main.instructions.md) - Enterprise-wide governance and complianceinstructions/enterprise/{Language}/main.instructions.md) - Enterprise language standardsinstructions/enterprise/{Language}/{context}.instructions.md) - Enterprise specialized requirementsinstructions/organization/main.instructions.md) - Community/framework base patternsinstructions/organization/{Language}/main.instructions.md) - Community language-specific patternsinstructions/organization/{Language}/{context}.instructions.md) - Community specialized patternsinstructions/repository/main.instructions.md) - Project-specific context and overridesinstructions/repository/{Language}/main.instructions.md) - Project-specific language patternsinstructions/repository/{Language}/{context}.instructions.md) - Project-specific customizationsFor prompts and chat modes, the precedence follows the three-tier approach:
When multiple tiers have the same prompt/chat mode, the enterprise tier takes highest precedence, followed by organization tier, then repository tier.
"},{"location":"Solutions/GitHub-Copilot-Customization-Architecture/#implementation-flexibility","title":"Implementation Flexibility","text":"Organizations can choose to implement: - Two-tier: Organization + Repository (skip enterprise tier) - Three-tier: Organization + Enterprise + Repository (full implementation) - Enterprise-only: Enterprise + Repository (for enterprises with internal frameworks)
"},{"location":"Solutions/GitHub-Copilot-Customization-Architecture/#migration-from-legacy-implementation","title":"Migration from Legacy Implementation","text":"Repositories transitioning from legacy approaches should:
.github/copilot-instructions.md).github/ with instructions/, prompts/, and chatmodes/ directoriesenterprise/ folders (if using enterprise tier)repository/main.instructions.md{Language}/ foldersprompts/ and chatmodes/ foldersNote: Organization and enterprise files will be automatically synchronized when implemented, so manual creation is typically not necessary.
"},{"location":"Solutions/GitHub-Copilot-Customization-Architecture/#implementation-guidelines","title":"Implementation Guidelines","text":""},{"location":"Solutions/GitHub-Copilot-Customization-Architecture/#for-ai-agents","title":"For AI Agents","text":"When processing files in repositories using this architecture, AI agents should:
Repository maintainers should understand:
Enterprise administrators implementing the enterprise tier should:
All instruction files must follow this format:
---\napplyTo: \"<glob pattern targeting specific file types>\"\ndescription: \"Brief, actionable description of the instruction's purpose\"\n---\nContent structure: Context lead, Goal, Execution steps, Behavior rules, Output format, Error handling, Definitions
"},{"location":"Solutions/GitHub-Copilot-Customization-Architecture/#prompts-format","title":"Prompts Format","text":"Prompt files should follow established GitHub Copilot prompt conventions with clear context and expected outcomes, including tier identification for provenance tracking.
"},{"location":"Solutions/GitHub-Copilot-Customization-Architecture/#chat-modes-format","title":"Chat Modes Format","text":"Chat mode files should define conversation contexts, specialized behaviors, and interaction patterns following GitHub Copilot chat mode specifications, with tier identification for configuration management.
"},{"location":"Solutions/GitHub-Copilot-Customization-Architecture/#design-principles","title":"Design Principles","text":"This architecture is guided by the following principles: