Correct instruction scopes, API guidance, and safety boundaries 🤖🤖🤖

instructions/bicep-code-best-practices.instructions.md

@@ -1,6 +1,6 @@
 ---
 description: 'Infrastructure as Code with Bicep'
-applyTo: '**/*.bicep'
+applyTo: '**/*.bicep, **/*.bicepparam, **/bicepconfig.json'
 ---
 
 ## Naming Conventions
@@ -22,6 +22,13 @@ applyTo: '**/*.bicep'
 -   Set default values that are safe for test environments (use low-cost pricing tiers)
 -   Use @allowed decorator sparingly to avoid blocking valid deployments
 -   Use parameters for settings that change between deployments
+-   Use `.bicepparam` files with a `using` declaration when supported by the project's tool versions; retain JSON parameter files where required. Keep secrets out of parameter files and use supported secret references.
+-   Use supported user-defined object types for structured parameter contracts when they make validation clearer.
+
+## Modules and Validation
+
+-   Prefer an appropriate Azure Verified Module when it meets the project's requirements, and reference a specific module version. Preserve existing module versions during unrelated changes.
+-   Respect the project's Bicep CLI version and `bicepconfig.json` linter settings. Run the project's Bicep build/lint checks before deployment, and resolve diagnostics rather than disabling rules globally.
 
 ## Variables
 
@@ -52,3 +59,9 @@ applyTo: '**/*.bicep'
 ## Documentation
 
 -   Include helpful // comments within your Bicep files to improve readability
+
+## References
+
+-   [Bicep modules and Azure Verified Modules](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/modules)
+-   [Bicep parameter files](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/parameter-files)
+-   [Bicep linter](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/linter)

instructions/cmake-vcpkg.instructions.md

@@ -1,10 +1,13 @@
 ---
 description: 'C++ project configuration and package management'
-applyTo: '**/*.cmake, **/CMakeLists.txt, **/*.cpp, **/*.h, **/*.hpp'
+applyTo: '**/*.cmake, **/CMakeLists.txt, **/CMakePresets.json, **/CMakeUserPresets.json, **/vcpkg.json, **/vcpkg-configuration.json'
 ---
 
-This project uses vcpkg in manifest mode. Please keep this in mind when giving vcpkg suggestions. Do not provide suggestions like vcpkg install library, as they will not work as expected.
-Prefer setting cache variables and other types of things through CMakePresets.json if possible.
+Inspect the project's existing CMake presets and vcpkg configuration before suggesting changes. When `vcpkg.json` is present, maintain dependencies in that manifest and restore them through CMake configuration or `vcpkg install` without package names; do not substitute classic-mode `vcpkg install <library>` commands.
+Prefer shared cache variables and toolchain settings in `CMakePresets.json`. Put machine-specific paths in untracked `CMakeUserPresets.json`, and use a presets schema supported by the project's CMake version. Set `CMAKE_TOOLCHAIN_FILE` before the first `project()` call, preferably through a preset.
+Preserve explicit registry or `builtin-baseline` versions when the project uses vcpkg versioning; update them deliberately rather than during unrelated changes.
 Give information about any CMake Policies that might affect CMake variables that are suggested or mentioned.
 This project needs to be cross-platform and cross-compiler for MSVC, Clang, and GCC.
-When providing OpenCV samples that use the file system to read files, please always use absolute file paths rather than file names, or relative file paths. For example, use `video.open("C:/project/file.mp4")`, not `video.open("file.mp4")`.
+For OpenCV filesystem examples, follow the project's asset-path convention. If the example must be independent of the working directory, accept an absolute path as input instead of hard-coding a developer-specific Windows path.
+
+References: [vcpkg CMake integration](https://learn.microsoft.com/en-us/vcpkg/users/buildsystems/cmake-integration), [manifest mode](https://learn.microsoft.com/en-us/vcpkg/users/manifests), [CMake presets](https://cmake.org/cmake/help/latest/manual/cmake-presets.7.html).

instructions/generate-modern-terraform-code-for-azure.instructions.md

@@ -3,8 +3,8 @@ description: 'Guidelines for generating modern Terraform code for Azure'
 applyTo: '**/*.tf'
 ---
 
-## 1. Use Latest Terraform and Providers
-Always target the latest stable Terraform version and Azure providers. In code, specify the required Terraform and provider versions to enforce this. Keep provider versions updated to get new features and fixes.
+## 1. Respect Terraform and Provider Version Constraints
+Inspect the project's `required_version`, `required_providers`, and `.terraform.lock.hcl` before generating code. Use compatible, explicitly constrained versions instead of upgrading an existing project to the latest release automatically. Commit the root module's provider lock file; review deliberate upgrades and their plans separately. Reusable modules should declare their minimum supported provider versions and let the root module control upper bounds.
 
 ## 2. Organize Code Cleanly
 Structure Terraform configurations with logical file separation:
@@ -39,6 +39,7 @@ Use Terraform modules to group reusable infrastructure components. For any resou
   - A resource not yet supported in `azurerm`
 - **Document the choice** in code comments
 - Both providers can be used together if needed, but prefer `azurerm` when in doubt
+- For AzureRM 4.x, supply the intended subscription through `subscription_id` or `ARM_SUBSCRIPTION_ID`; do not rely on the Azure CLI's active subscription. Consult the provider's upgrade guide when changing major versions.
 
 ## 6. Minimal Dependencies
 
@@ -54,7 +55,7 @@ Use Terraform modules to group reusable infrastructure components. For any resou
 - **Avoid non-idempotent actions**:
   - Scripts that run on every apply
   - Resources that might conflict if created twice
-- **Test by doing multiple `terraform apply` runs** and ensure the second run results in zero changes
+- Verify repeated plans after an authorized apply in a test environment; the subsequent plan should show no unintended changes. Do not apply to production solely to prove idempotency.
 - Use resource lifecycle settings or conditional expressions to handle drift or external changes gracefully
 
 ## 8. State Management
@@ -80,3 +81,8 @@ Use Terraform modules to group reusable infrastructure components. For any resou
   - CI pipeline
   - Pre-commit hooks
   - Enforce formatting, linting, and basic validation
+
+## References
+
+- [Provider requirements and version constraints](https://developer.hashicorp.com/terraform/language/providers/requirements)
+- [AzureRM 4.0 upgrade guide](https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/guides/4.0-upgrade-guide)

instructions/nextjs-tailwind.instructions.md

@@ -9,10 +9,19 @@ Instructions for high-quality Next.js applications with Tailwind CSS styling and
 
 ## Project Context
 
-- Latest Next.js (App Router)
+- Follow the Next.js, React, and Tailwind versions installed in `package.json` and the lockfile; do not upgrade dependencies as a side effect of a feature or fix.
+- Use the project's existing router and build configuration. The guidance below targets the App Router.
 - TypeScript for type safety
 - Tailwind CSS for styling
 
+### Version-Specific Behavior
+- For Next.js 15+, handle request APIs such as `cookies`, `headers`, `draftMode`, route `params`, and page `searchParams` asynchronously. Next.js 16 removes their temporary synchronous compatibility.
+- For Next.js 15+, do not assume `fetch` or `GET` Route Handlers are cached by default. Select caching and revalidation deliberately for the installed version and test freshness after mutations.
+- Next.js 16 uses Turbopack for development and builds by default. Check custom Webpack configuration before changing build scripts; retain an explicit Webpack build when the project requires it.
+- For Tailwind v4, use the CSS-first setup (`@import "tailwindcss"` and theme variables) and the appropriate Vite or PostCSS integration. Preserve a v3 project's configuration and browser support requirements unless migration is requested.
+
+References: [Next.js 15 upgrade guide](https://nextjs.org/docs/15/app/guides/upgrading/version-15), [Next.js 16 upgrade guide](https://nextjs.org/docs/app/guides/upgrading/version-16), [Tailwind v4 upgrade guide](https://tailwindcss.com/docs/upgrade-guide).
+
 ## Development Standards
 
 ### Architecture

instructions/playwright-typescript.instructions.md

@@ -1,10 +1,12 @@
 ---
 description: 'Playwright test generation instructions'
-applyTo: '**'
+applyTo: '**/tests/**/*.ts, **/e2e/**/*.ts, **/playwright/**/*.ts, **/playwright.config.ts'
 ---
 
 ## Test Writing Guidelines
 
+Use these guidelines for the Playwright suite identified by its configured `testDir` and `testMatch`, including its fixtures and page objects. Keep unrelated application code and other test frameworks outside this scope; adapt the instruction glob if the suite uses a custom location. See [Playwright test configuration](https://playwright.dev/docs/test-configuration).
+
 ### Code Quality Standards
 - **Locators**: Prioritize user-facing, role-based locators (`getByRole`, `getByLabel`, `getByText`, etc.) for resilience and accessibility. Use `test.step()` to group interactions and improve test readability and reporting.
 - **Assertions**: Use auto-retrying web-first assertions. These assertions start with the `await` keyword (e.g., `await expect(locator).toHaveText()`). Avoid `expect(locator).toBeVisible()` unless specifically testing for visibility changes.
@@ -20,8 +22,8 @@ applyTo: '**'
 
 
 ### File Organization
-- **Location**: Store all test files in the `tests/` directory.
-- **Naming**: Use the convention `<feature-or-page>.spec.ts` (e.g., `login.spec.ts`, `search.spec.ts`).
+- **Location**: Store specs, fixtures, and page objects in the existing Playwright suite. Put specs under the configured `testDir` and ensure they match `testMatch`, including projects using `e2e/` or another directory.
+- **Naming**: Follow the suite's configured matcher and existing naming convention; use `<feature-or-page>.spec.ts` when that matcher accepts it.
 - **Scope**: Aim for one test file per major application feature or page.
 
 ### Assertion Best Practices
@@ -70,7 +72,7 @@ test.describe('Movie Search Feature', () => {
 
 ## Test Execution Strategy
 
-1. **Initial Run**: Execute tests with `npx playwright test --project=chromium`
+1. **Initial Run**: Use the project's Playwright test command and configured projects; `npx playwright test --project=chromium` applies when the configuration defines that project.
 2. **Debug Failures**: Analyze test failures and identify root causes
 3. **Iterate**: Refine locators, assertions, or test logic as needed
 4. **Validate**: Ensure tests pass consistently and cover the intended functionality

instructions/power-platform-connector.instructions.md

@@ -1,11 +1,13 @@
 ---
 title: Power Platform Connectors Schema Development Instructions
 description: 'Comprehensive development guidelines for Power Platform Custom Connectors using JSON Schema definitions. Covers API definitions (Swagger 2.0), API properties, and settings configuration with Microsoft extensions.'
-applyTo: '**/*.{json,md}'
+applyTo: '**/apiDefinition.swagger.json, **/apiProperties.json'
 ---
 
 # Power Platform Connectors Schema Development Instructions
 
+These instructions apply automatically to the standard connector definition and properties filenames. Attach them explicitly when working on a connector's `settings.json`, schema files, or documentation with other names; a generic `settings.json` filename also appears in unrelated projects. Keep the Swagger 2.0 format required by the [custom connector importer](https://learn.microsoft.com/en-us/connectors/custom-connectors/define-openapi-definition).
+
 ## Project Overview
 This workspace contains JSON Schema definitions for Power Platform Custom Connectors, specifically for the `paconn` (Power Apps Connector) tool. The schemas validate and provide IntelliSense for:
 

instructions/ruby-on-rails.instructions.md

@@ -5,6 +5,14 @@ applyTo: '**/*.rb'
 
 # Ruby on Rails
 
+## Version and Application Context
+
+- Read `Gemfile.lock`, `config.load_defaults`, and environment configuration before choosing APIs or changing infrastructure. Preserve the application's supported Rails and Ruby versions.
+- New Rails 8 applications default to Propshaft and include production configuration for Solid Queue, Solid Cache, and Solid Cable. Existing apps may retain other asset, job, cache, or cable backends; inspect environment-specific configuration before suggesting a migration.
+- On Rails 8+, `bin/rails generate authentication` provides a starting point for session-based authentication and password resets. Use it only when it fits the requested authentication work; review authorization and any additional account requirements separately.
+
+References: [Rails 8.0 release notes](https://guides.rubyonrails.org/8_0_release_notes.html), [Active Job configuration](https://guides.rubyonrails.org/active_job_basics.html), [Rails authentication guidance](https://guides.rubyonrails.org/security.html).
+
 ## General Guidelines
 
 - Follow the RuboCop Style Guide and use tools like `rubocop`, `standardrb`, or `rufo` for consistent formatting.
@@ -15,8 +23,7 @@ applyTo: '**/*.rb'
 - Apply the Single Responsibility Principle to classes, methods, and modules.
 - Prefer composition over inheritance; extract reusable logic into modules or services.
 - Keep controllers thin — move business logic into models, services, or command/query objects.
-- Apply the “fat model, skinny controller” pattern thoughtfully and with clean abstractions.
-- Extract business logic into service objects for reusability and testability.
+- Keep model responsibilities focused; extract a service or query object when an actual workflow or reuse boundary justifies it.
 - Use partials or view components to reduce duplication and simplify views.
 - Use `unless` for negative conditions, but avoid it with `else` for clarity.
 - Avoid deeply nested conditionals — favor guard clauses and method extractions.
@@ -45,7 +52,7 @@ applyTo: '**/*.rb'
 
 ## App Directory Structure
 
-- Define service objects in the `app/services` directory to encapsulate business logic.
+- Put service objects in `app/services` when needed; do not create extra application layers by default.
 - Use form objects located in `app/forms` to manage validation and submission logic.
 - Implement JSON serializers in the `app/serializers` directory to format API responses.
 - Define authorization policies in `app/policies` to control user access to resources.
@@ -88,7 +95,7 @@ applyTo: '**/*.rb'
 
 ## Frontend Development Best Practices
 
-- Use `app/javascript` as the main directory for managing JavaScript packs, modules, and frontend logic in Rails 6+ with Webpacker or esbuild.
+- Use the application's existing JavaScript setup under `app/javascript`. Modern Rails supports import maps or JavaScript bundling; follow the configured approach rather than introducing Webpacker. See [Working with JavaScript in Rails](https://guides.rubyonrails.org/working_with_javascript_in_rails.html).
 - Structure your JavaScript by components or domains, not by file types, to keep things modular.
 - Leverage Hotwire (Turbo + Stimulus) for real-time updates and minimal JavaScript in Rails-native apps.
 - Use Stimulus controllers for binding behavior to HTML and managing UI logic declaratively.

instructions/self-explanatory-code-commenting.instructions.md

@@ -68,7 +68,7 @@ const emailPattern = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/;
 **API Constraints or Gotchas**
 ```javascript
 // Good: Explains external constraint
-// GitHub API rate limit: 5000 requests/hour for authenticated users
+// Honor the rate-limit and reset headers returned by GitHub
 await rateLimiter.wait();
 const response = await fetch(githubApiUrl);
 ```
@@ -102,8 +102,8 @@ function calculateCompoundInterest(principal, rate, time, compoundFrequency = 1)
 ### Configuration and Constants
 ```javascript
 // Good: Explains the source or reasoning
-const MAX_RETRIES = 3;  // Based on network reliability studies
-const API_TIMEOUT = 5000;  // AWS Lambda timeout is 15s, leaving buffer
+const MAX_RETRIES = 3;  // Bound retry amplification during an upstream outage
+const API_TIMEOUT = 5000;  // Avoid waiting indefinitely when the upstream stalls
 ```
 
 ### Annotations

instructions/taming-copilot.instructions.md

@@ -5,15 +5,15 @@ description: 'Prevent Copilot from wreaking havoc across your codebase, keeping
 
 ## Core Directives & Hierarchy
 
-This section outlines the absolute order of operations. These rules have the highest priority and must not be violated.
+These instructions guide scope and communication within the user's request. Follow applicable system, platform, and repository rules, including tool permissions and security requirements.
 
-1.  **Primacy of User Directives**: A direct and explicit command from the user is the highest priority. If the user instructs to use a specific tool, edit a file, or perform a specific search, that command **must be executed without deviation**, even if other rules would suggest it is unnecessary. All other instructions are subordinate to a direct user order.
+1.  **User-Directed Scope**: Follow the user's requested outcome within the applicable rules and available permissions. Complete the necessary edits and verification; when an action is unavailable or outside the authorized scope, explain the limitation.
 2.  **Factual Verification Over Internal Knowledge**: When a request involves information that could be version-dependent, time-sensitive, or requires specific external data (e.g., library documentation, latest best practices, API details), prioritize using tools to find the current, factual answer over relying on general knowledge.
 3.  **Adherence to Philosophy**: In the absence of a direct user directive or the need for factual verification, all other rules below regarding interaction, code generation, and modification must be followed.
 
 ## General Interaction & Philosophy
 
--   **Code on Request Only**: Your default response should be a clear, natural language explanation. Do NOT provide code blocks unless explicitly asked, or if a very small and minimalist example is essential to illustrate a concept.  Tool usage is distinct from user-facing code blocks and is not subject to this restriction.
+-   **Match the Request**: Answer explanatory questions clearly and concisely. Treat requests to implement or fix behavior as authorization to make the necessary code changes and verify them; do not require the user to separately ask for code.
 -   **Direct and Concise**: Answers must be precise, to the point, and free from unnecessary filler or verbose explanations. Get straight to the solution without "beating around the bush".
 -   **Adherence to Best Practices**: All suggestions, architectural patterns, and solutions must align with widely accepted industry best practices and established design principles. Avoid experimental, obscure, or overly "creative" approaches. Stick to what is proven and reliable.
 -   **Explain the "Why"**: Don't just provide an answer; briefly explain the reasoning behind it. Why is this the standard approach? What specific problem does this pattern solve? This context is more valuable than the solution itself.
@@ -23,7 +23,7 @@ This section outlines the absolute order of operations. These rules have the hig
 -   **Principle of Simplicity**: Always provide the most straightforward and minimalist solution possible. The goal is to solve the problem with the least amount of code and complexity. Avoid premature optimization or over-engineering.
 -   **Standard First**: Heavily favor standard library functions and widely accepted, common programming patterns. Only introduce third-party libraries if they are the industry standard for the task or absolutely necessary.
 -   **Avoid Elaborate Solutions**: Do not propose complex, "clever", or obscure solutions. Prioritize readability, maintainability, and the shortest path to a working result over convoluted patterns.
--   **Focus on the Core Request**: Generate code that directly addresses the user's request, without adding extra features or handling edge cases that were not mentioned.
+-   **Focus on the Core Request**: Generate code that directly addresses the user's request without adding extra features. Retain validation, error handling, and edge cases needed for correctness, security, and the requested behavior.
 
 ## Surgical Code Modification