[imanimanyara]

Summary

Adds a shared job calling laranail/.github's reusable security.yml, bringing this repository an OSV.dev scan and a ggshield secret scan it has never had.

Measured 2026-11-13 across laranail: of 88 packages calling a reusable laranail/.github workflow, security.yml had 1 caller against tests.yml's 39, while 23 packages shipped a standalone security.yml running composer audit and nothing else. The estate was unshared rather than unscanned; what this adds is the two scans.

The local audit job is deliberately untouched

It is not a duplicate, and neither job is a superset of the other:

• the local job runs composer update --prefer-stable and audits everything, including dev dependencies;
• the shared job runs composer install then composer audit --locked --no-dev, which skips the dev tree — where roave/security-advisories and the test toolchain live.

The local job also caches composer and pins its own PHP, which the shared workflow does not. Replacing it would have been a removal dressed as a migration. These repositories are public, so the second composer audit run costs nothing.

The secret scan before the credential exists

The shared workflow declares OP_SERVICE_ACCOUNT_TOKEN optional and, when absent, emits a warning and skips the ggshield step rather than failing. secrets: inherit is therefore correct both now and once the credential is set. Failing closed is right for a finding and wrong for a missing setting.

Rolled out after a five-repo pilot

package-tools, console, db-tools, package-management and chrono went first. The pilot earned its keep: it found that the shared workflow's osv-scan job hardcoded php-version: '8.4' while composer-audit honoured the input, so every caller with a PHP floor above 8.4 failed with composer's "Your requirements could not be resolved" — an error naming neither PHP nor a version, inside a job called "OSV.dev scan". Fixed in laranail/.github#29 before this rollout, which is why php-version here is this repository's own value rather than a default.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.

[imanimanyara]

The Vitest · bundle failure was not this change, and is now fixed

git diff --exit-code resources/dist failed because the committed CSS was built with tailwindcss 4.3.3 and CI, which resolves ^4.1.0 fresh with no lockfile, installs 4.3.5.

Reproduced locally: a plain npm install keeps 4.3.3 (npm does not upgrade a package already satisfying the range), so the drift is invisible on a developer machine. npm update tailwindcss @tailwindcss/cli then reproduces CI exactly.

Every byte of the difference is upstream's, which is why regenerating is safe here rather than absorbing a regression:

change	source
v4.3.3 → v4.3.5 banner	Tailwind
@supports … (margin-trim:inline) → (margin-trim:block)	Tailwind's own feature-detection guard
ring/shadow custom-property ordering	Tailwind's emitter

The JS bundle is byte-identical. That is the load-bearing evidence: a real change of ours would have moved it. The licence-banner guard still finds laranail/artisan-ui, lint is clean, and the 37 JS tests pass.

This will happen again, and that is structural

Three rules of this estate are jointly unsatisfiable for a byte-comparison gate:

1. libraries track no lockfile, so CI resolves fresh every run;
2. resources/dist is committed, because consumers install through Composer and never run npm;
3. dependencies float on a range.

So any Tailwind release that changes a byte of output turns this repository red with no commit of its own — exactly what happened here, and the same shape as tayari-ui's Playwright baselines. Worth a decision rather than a rebuild each time; raised with the owner separately.