MageBroker: Magento upgrades, fixed by IBM Bob

Problem A Magento 2 store runs dozens of modules: core, vendor extensions and custom code. Each one declares dependencies in several places: package versions and a PHP requirement in composer.json, load order in etc/module.xml, and class overrides in etc/di.xml. When a team upgrades Magento (for example 2.4.6 to 2.4.7) or installs an extension, these declarations break. Composer only reports version problems, often revealing the next one after each fix, and it does not see load-order or dependency-injection conflicts at all; those surface later, during setup or in production. Developers end up in a slow loop: run composer, read one error, fix it, run it again, module by module. Solution MageBroker turns that loop into one scan and one verified fix pass. 1. A deterministic Python CLI (Typer, Rich, networkx, packaging) with six detectors: version conflicts, missing packages, circular module sequences, duplicate di.xml preferences, PHP upgrade blockers checked against a Magento/PHP compatibility matrix, and sequences that point to modules that don't exist. A Composer constraint translator handles ^, ~, wildcards, ranges, OR groups and Magento patch versions such as 103.0.6-p3. The scan writes a terminal report, findings.json, report.md and a 0 to 100 health score, and exits with code 1 on critical findings so it can gate CI. It runs fully offline. 2. A custom IBM Bob mode, "Magento Broker", stored in .bob/custom_modes.yaml so it ships with the repository. One prompt runs a six-step workflow: scan, three parallel subagents (composer and PHP, module load order, di.xml), merge into an ordered fix-plan.md with before/after diffs and auto or manual labels, apply only the auto fixes, re-scan, and report before and after. Composer commands are written into the plan, never run automatically. Results On a synthetic Magento 2.4.6 store targeting 2.4.7, with six planted bugs and no client data: - 6 findings down to 1, health score from 10 to 80 - 5 files fixed automatically by Bob (2 composer.json, 2 module.xml, 1 di.xml) - the remaining finding, a missing payment package, stays manual: Bob writes the exact composer require command instead of guessing, and the CI gate stays closed until a human resolves it - 37 automated tests, including a bug-free fixture that must return zero findings - the demo is repeatable with scripts/reset-demo.sh Why it matters Agencies and in-house teams repeat this dependency triage for every Magento patch and minor release. MageBroker shows every blocker at once, applies the low-risk fixes with a reviewable plan, and keeps humans in charge of anything risky. What's next Adobe's full compatibility matrix for every 2.4.x release, Packagist lookups to suggest versions for missing packages, more Magento-specific detectors (plugins, layout XML, db_schema), and a GitHub Action that posts the fix plan on pull requests.