dhpk-matrix-cell-onboard

Matrix cell onboard

Adding a new cell to a multi-major test matrix is more than appending one YAML row. The cell only earns its keep when (1) composer.json can resolve it, (2) every polyfill branch in src/ that could fire for this cell has a test, and (3) the Testbench / phpunit / monolog / meta-tags versions in the new cell are mutually compatible.

This skill is a procedure, not an agent. Run it as a checklist.

---

When to run

• Adding a new php × <framework> combination (e.g. PHP 8.3 + Laravel 12)
• Restoring a cell that was previously excluded (e.g. PHP 7.3 dropped, now needs to come back for a customer)
• A dep ships a new major (Monolog 4, Flysystem 4, PHPUnit 12) and you want to start exercising it before raising the floor

When NOT to Use

• Just bumping the patch version inside an existing cell (no matrix change)
• Adding a test file that runs on all existing cells (no matrix change)
• Removing a cell — use the symmetric "matrix cell retire" procedure (informal: same checklist in reverse)

---

Inputs

You need the proposed cell as a tuple of pinned versions:

php: "8.3"
laravel: "^12.0"
phpunit: "^11.0"
monolog: "^3.0"        # or ^4.0 if testing pre-release
meta-tags: "^4.0"      # if applicable
testbench: "^10.0"     # auto-derived from laravel, see step 3

If the user hands you only php: 8.3, laravel: 12, fill the rest from the existing cell adjacency rules below before asking them.

---

Procedure

Step 1 — Verify composer.json can resolve the cell

For each dep in the proposed cell, check composer.json's require (and require-dev) constraint.

grep -E '"(php|laravel/framework|monolog/monolog|butschster/meta-tags|orchestra/testbench|phpunit/phpunit)"' composer.json

A constraint like "php": "^7.3 || ^8.0" admits 8.3. A constraint like "laravel/framework": "^6.0 || ... || ^11.0" does NOT admit 12.0 — you must extend it first.

Output of step 1: a per-dep list of composer OK or composer NEEDS EXTENSION: <current> → <proposed>.