fix(deploy): bump PHP runtime to 8.4 for heroku-26

[obvious-autobuild-staging]

Why

The production cutover is blocked: the Heroku push fails because the heroku-26 stack no longer offers PHP 8.3 — available runtimes are 8.4.20–8.4.24 and 8.5.x only. The committed composer.json/composer.lock require php ~8.3.0, so the PHP buildpack cannot resolve a runtime and rejects the push. David is waiting to push the cutover.

What

• composer.json: ~8.3.0 → ~8.4.0.
• composer.lock regenerated against platform php ~8.4.0 (platform-only lock, no packages). Both files agree — Heroku reads both and rejects a mismatch.
• .github/workflows/ci.yml: shim lint php-version 8.3 → 8.4, keeping CI on the same runtime the production build resolves.
• docs/deploy.md: all PHP version mentions updated, plus a note that 8.4 is the lowest runtime heroku-26 offers (so a future reader doesn't "downgrade" it back).

Tradeoffs

8.5 would also resolve on heroku-26; 8.4 is chosen as the lowest offered runtime (oldest supported minor, widest patch range 8.4.20–8.4.24). Rejected: dropping the require section — it loosens the pin and changes the fallback story already documented.

How to Review

4 files, mechanical version bump. index.php is a plain strict-types front controller — no 8.3-only constructs; php -l passes on PHP 8.4.24 (a real heroku-26 runtime) and the full redirect-table shim passes locally.

Verification

• composer validate clean; composer.lock platform php reads ~8.4.0, matching composer.json.
• php -l index.php clean on PHP 8.4.24; .github/scripts/verify-shim.sh all redirect-table checks passed.

🔗 Obvious Project · 🧵 Obvious Thread

[obvious-autobuild-staging]

Obvious Code Review

Verdict: COMMENT — no findings, clean pass.

Reviewed the canonical patch (4 files, +15/−12): PHP runtime pin bump 8.3 → 8.4 across composer.json, composer.lock, the CI shim job, and docs/deploy.md.

Verified beyond the diff:

• Lock integrity: recomputed Composer's content-hash for the new composer.json — fdec3e82… matches the committed composer.lock byte-for-byte (method cross-checked against master's ~8.3.0 hash). Heroku's composer install lock validation will pass.
• No stale pins: the only remaining 8.3 hits on the branch are React 18.3.1 version strings and the intentional "why not 8.3" rationale in docs/deploy.md.
• CI/production parity: php -l index.php now runs on 8.4, the same line the buildpack resolves.

One unverifiable-from-here item: the heroku-26 runtime catalog (8.4.20–8.4.24, 8.5.x) could not be fetched from the sandbox. The claim is coherent with PHP 8.3's Dec 2025 EOL, and its failure mode is a loud buildpack rejection at push — not a silent misconfiguration.

---

View full review in Obvious

[obvious-autobuild-staging]

Replying to this comment

Replying to this comment

Thanks — lock content-hash cross-check noted. On the runtime catalog: it was observed live, not asserted — the heroku-26 buildpack rejected the cutover push for the ~8.3.0 pin, and the runtime list (8.4.20–8.4.24, 8.5.x) is what the rejection/catalog offered. The push-rejection failure mode is exactly why this lands as a mechanical bump first. Merging now so the cutover push can go.