fix(meta): correct the Requires PHP floor to 7.4 and enforce it with PHPCompatibility

[Herm71]

Closes #25.

The bug

plugin.php declared Requires PHP: 7.0, but lib/functions/general.php declares:

function ucsccomms_enqueue_admin_styles(): void {

: void is PHP 7.1+. On 7.0 that's a parse error, so the plugin fatalled on activation on the exact version it advertised. I checked the rest of the codebase — : void is the only construct above 7.0 in all 204 lines, so the true floor was 7.1.

Nothing enforced the claim either: no require php constraint in composer.json, no config.platform.php, "platform": {} in the lock, and the PHPCompatibilityWP block in .phpcs.xml.dist commented out since the ruleset was first written.

Changes

1. plugin.php — Requires PHP: 7.0 → 7.4.
2. composer.json — added phpcompatibility/phpcompatibility-wp: ^2.1 to require-dev.
3. .phpcs.xml.dist — replaced the commented-out block with a live one:

   <config name="testVersion" value="7.4-"/>
   <rule ref="PHPCompatibilityWP"/>

   The open-ended 7.4- form also catches constructs removed in later PHP, not just ones too new for the floor.
4. composer.lock — refreshed (3 new dev packages; content hash updated so CI's composer install stays valid).

Why 7.4 and not 8.1

Deliberate, per the issue's prompt to decide rather than default. 7.4 is the conservative claim: safely true of the current code, and it keeps the widest install compatibility. Worth noting both options are past EOL as of August 2026 — 7.4 since Nov 2022, 8.1 since Dec 2025 — so neither is an endorsement. The header states where the plugin parses and runs, not what anyone should be hosting on. Raising it later is a one-line change now that the sniff enforces it.

Verification

composer run lint exits 0 — the new standard produced zero findings against the plugin code.

A clean run could equally mean the sniff silently isn't loading, so I mutation-checked it. Temporarily setting testVersion to 7.0-:

25 | ERROR | void return type is not present in PHP version 7.0 or earlier
   |       | (PHPCompatibility.FunctionDeclarations.NewReturnTypeDeclarations.voidFound)

That is precisely the bug this issue describes, so the enforcement is real and the floor is now machine-proven on every PR.

composer run lint    → exits 0, zero errors, zero warnings
phpunit              → OK (22 tests, 38 assertions)
composer validate    → ./composer.json is valid

Runtime floor vs. test toolchain

Kept separate, as the issue asks. PHPUnit ^12.5 needs PHP 8.3+ and CI runs it on 8.3/8.4 — that doesn't weaken the 7.4 claim, because PHPCompatibility proves the floor statically, with no 7.4 runtime anywhere. No downgrade to PHPUnit 9.6.

Docs

• CLAUDE.md — the Known quirks entry recording the contradiction is removed. Added a note under Commands → PHP that Requires PHP and testVersion are now a pair that must be changed together, since nothing else enforces the floor.
• ROADMAP.md — a "Resolved after the audit" record with cause, fix, and the 7.4 rationale.

Acceptance criteria

• Requires PHP matches the actual minimum the code parses and runs on.
• PHPCompatibilityWP active with a matching testVersion.
• composer run lint exits 0.
• CLAUDE.md "Known quirks" entry removed.

🤖 Generated with Claude Code