[david-ruiz-cko]

This pull request improves dependency management and build consistency for the project by ensuring that Composer dependencies are always installed according to the composer.lock file, rather than being re-resolved on each CI run. It also documents this approach and pins the PHP version used for dependency resolution. These changes enhance security and reliability in both CI and local development environments.

Dependency management and CI workflow improvements:

• Updated both .github/workflows/build-master.yml and .github/workflows/build-release.yml to use composer install instead of composer update, ensuring that dependencies are installed exactly as specified in composer.lock and not re-resolved on each run. This reduces the risk of inadvertently introducing malicious or incompatible package versions during CI runs. [1] [2]
• Added a config.platform.php setting with version 8.1 to composer.json to ensure consistent dependency resolution across different environments, matching the CI configuration.

Documentation updates:

• Updated the README.md to instruct users to run composer install (not composer update) for local development, ensuring local environments match CI and clarifying when to use each command.

[agent-wall-e]

🔴 Risk Classification: MAJOR

Approval route: AI Review + Human Approval Required
Rollback controls: Change-freeze window + documented rollback plan

Classification reasons

• security_sensitive_path:.github/workflows/build-master.yml
• security_sensitive_path:.github/workflows/build-release.yml

Operational gates

• ✅ jira_ticket (INT-1751)
• ✅ independent_review

Files analysed: 6

---

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}

[agent-wall-e]

🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code	Kind	Clause	Meaning
security_sensitive_path — .github/workflows/build-master.yml	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).
security_sensitive_path — .github/workflows/build-release.yml	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).

Kinds:

• classifying — this rule contributed to the chosen tier.
• informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

_{wall-e 2026.06.19-02 · debug}

[agent-wall-e]

🔵 Advisory review: Sound, but needs your judgement

This PR needs a human approval. The code itself reads as correct; whether it should land depends on context I don't have.

The change correctly switches CI from composer update to composer install, removes composer.lock from .gitignore, commits the lock file, and pins the platform to PHP 8.1 — all consistent with the stated intent. The approach is technically sound, but committing the lock file for the first time is a consequential, one-way operation that a human should explicitly sign off on.

For you to decide

• The composer.lock file is newly committed (3048 lines added) after being removed from .gitignore; a reviewer should verify its contents are trustworthy — i.e., it was generated cleanly from the current composer.json on a known-good machine, not copied from an untrusted source.
• The config.platform.php is set to 8.1 in composer.json; a reviewer should confirm the actual runtime PHP version across all CI matrix legs is ≥ 8.1 and that no leg runs a version where the locked dependencies would fail to install.
• Both workflow files now run composer install, which will fail if composer.lock is ever out of sync with composer.json; the existing composer validate step catches this, but the team should be aware that PRs which update composer.json without updating composer.lock will now break CI rather than silently re-resolving.
• The README now instructs contributors to run composer install and commit an updated lock when upgrading — this is correct, but the team should agree on the process for periodic dependency updates (who runs composer update, how often, how it is reviewed) since that workflow now requires an intentional, visible step.

---

_{This is not an approval. wall-e cannot auto-approve this PR — it is an opinion to help whoever does. Advisory review · us.anthropic.claude-sonnet-4-6 · wall-e 2026.06.19-02}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud