fix: validate prepared SQL through typed wpdb receivers

.github/workflows/dependency-canary.yml

@@ -0,0 +1,18 @@
+name: Dependency compatibility
+
+on:
+  schedule:
+    - cron: '26 3 * * 3'
+  workflow_dispatch:
+
+permissions:
+  contents: read
+
+jobs:
+  compatibility:
+    permissions:
+      contents: read
+      issues: write
+    uses: sympress/workflows/.github/workflows/dependency-canary.yml@177fa0d727b278d2103052ec77c102b4a4c492a0
+    with:
+      php_version: '8.5'

.github/workflows/qa.yml

@@ -12,10 +12,10 @@ permissions:
 
 jobs:
   workflows:
-    uses: sympress/workflows/.github/workflows/lint-workflows.yml@v1
+    uses: sympress/workflows/.github/workflows/lint-workflows.yml@177fa0d727b278d2103052ec77c102b4a4c492a0
 
   qa:
-    uses: sympress/workflows/.github/workflows/sympress-qa.yml@v1
+    uses: sympress/workflows/.github/workflows/sympress-qa.yml@177fa0d727b278d2103052ec77c102b4a4c492a0
     with:
       php_version: '8.5'
     secrets:

composer.json

@@ -28,7 +28,7 @@
         "php": "^8.5",
         "automattic/vipwpcs": "^3.0",
         "dealerdirect/phpcodesniffer-composer-installer": "^1.0",
-        "phpcompatibility/php-compatibility": "^9.3 || ^10.0@alpha",
+        "phpcompatibility/php-compatibility": "^9.3 || ^10.0",
         "phpcsstandards/phpcsextra": "^1.2",
         "phpcsstandards/phpcsutils": "^1.0",
         "sirbrillig/phpcs-variable-analysis": "^2.11",
@@ -90,5 +90,6 @@
             "Composer\\Config::disableProcessTimeout",
             "phpunit --coverage-text --coverage-clover tmp/coverage.xml --coverage-html tmp/coverage"
         ]
-    }
+    },
+    "prefer-stable": true
 }

docs/Compatibility.md

@@ -20,13 +20,17 @@ The historical `SymPress-Plugin`, `SymPress-Core`, and `SymPress-Extra` standard
 
 ## PHPCompatibility
 
-The Composer constraint allows stable PHPCompatibility 9.x and PHPCompatibility 10 alpha releases:
+The Composer constraint accepts stable PHPCompatibility 9.x and 10.x releases:
 
 ```json
-"phpcompatibility/php-compatibility": "^9.3 || ^10.0@alpha"
+"phpcompatibility/php-compatibility": "^9.3 || ^10.0"
 ```
 
-Use PHPCompatibility 10 when checking the newest PHP language versions. Use the stable 9.x line when an organization cannot approve alpha dependencies and the target PHP version is covered by that line.
+Use a stable PHPCompatibility 10 release when it becomes available and has been
+verified with all bundled profiles. Until then, fresh stable installations use
+9.x. That line does not cover every newest PHP feature; its passing result cannot
+establish complete PHP 8.5 compatibility. The package's syntax, behavioral and
+static-analysis gates run on PHP 8.5 separately.
 
 ## WordPress VIP Positioning
 

docs/Rules.md

@@ -75,3 +75,15 @@ profile, not in the shared enterprise default.
 | `SymPress.WordPress.HookPriority` | Maintainability | Warning | Encourages explicit hook priority. |
 
 Vendor rules from WPCS, VIPWPCS, Slevomat, PHPCSExtra, PHPCSUtils, PHPCompatibility, and VariableAnalysis follow the same severity classes in project documentation and release notes.
+
+## WordPress SQL receiver coverage
+
+The profile retains WPCS `WordPress.DB.PreparedSQL` and
+`WordPress.DB.PreparedSQLPlaceholders`. WPCS 3.1 identifies receivers by tokens
+named `$wpdb` or `wpdb`; a property literally called `wpdb` can be covered,
+but typed `$this->db`, aliases, factory results and differently named parameters
+are not reliably covered. Consumers must also include the WordPress PHPStan
+profile from `sympress/qa`, which registers the receiver-type based
+`sympress.preparedSql` rule. This complementary check is not a custom PHPCS sniff
+and does not change the pure PHP profile. Audited raw SQL boundaries require a
+narrow documented exception and regression tests.

docs/Sniffs.md

@@ -42,3 +42,15 @@ The package exposes these SymPress custom sniffs:
 - `SymPress.WordPress.HookPriority`
 
 Run `phpcs -e --standard=SymPress` to see the active custom sniff list resolved by the installed package.
+
+## WordPress SQL receiver coverage
+
+The profile retains WPCS `WordPress.DB.PreparedSQL` and
+`WordPress.DB.PreparedSQLPlaceholders`. WPCS 3.1 identifies receivers by tokens
+named `$wpdb` or `wpdb`; a property literally called `wpdb` can be covered,
+but typed `$this->db`, aliases, factory results and differently named parameters
+are not reliably covered. Consumers must also include the WordPress PHPStan
+profile from `sympress/qa`, which registers the receiver-type based
+`sympress.preparedSql` rule. This complementary check is not a custom PHPCS sniff
+and does not change the pure PHP profile. Audited raw SQL boundaries require a
+narrow documented exception and regression tests.

docs/releases/1.1.1.md

@@ -0,0 +1,20 @@
+# Candidate release 1.1.1
+
+This candidate uses stable Composer constraints and the repaired SymPress
+package train. It has not been published. The repository's QA workflow references
+the reviewed immutable workflow commit; a weekly dependency canary resolves
+current permitted stable dependencies and reports a failure or recovery through
+a single GitHub issue.
+
+Runtime files and resources remain in Composer archives. Tests, CI and local
+configuration are excluded through `.gitattributes`. Historical tags remain
+unchanged. The candidate becomes consumable from public registries only after
+the dependency train has been published and exact-head CI/fresh installations
+have passed.
+
+For coordinated local development, provide an explicit root Composer repository
+with the reviewed candidate versions. Do not restore library-level
+`minimum-stability: dev` or moving `dev-main` dependencies. Local candidate
+fixtures demonstrate source compatibility; they do not establish public release
+availability. Application production installs require a committed lock and
+`composer install --no-dev --optimize-autoloader --classmap-authoritative`.