Split Bookeo and 5c SMS into modules of their own

[DorwardTech]

Phase 1 of the plan. A run sheet needs Bookeo; booking reminders need SMS. Neither has anything to do with the birthday radar, and both clients lived inside it — so this extracts them before the second consumer arrives rather than after.

Module	Contents
Modules/Bookeo	BookeoClient, config/bookeo.php, bookeo:check, the API notes, the credential-leak tests
Modules/Sms	SmsClient, config/sms.php, MobileNumber, GsmMessage, the API notes, the client tests
Modules/Crm	Everything else, now declaring dependencies() => ['bookeo', 'sms']

Both are integration modules — no navigation, no settings page, no operator guide, because there's nothing there for whoever runs the venue. They still appear on /admin/modules, which is the point: when Bookeo credentials are the problem, the module list is where somebody will look.

Singletons on purpose, with a test pinning it. BookeoClient paces itself against Bookeo's rate limit through a shared cache key — two instances would each think they had the whole budget.

Behaviour-neutral by construction

• No table moved.
• No app_settings key renamed.
• No env var renamed — only which config file reads it. BOOKEO_API_KEY and friends are untouched, so nothing about a deployment moves with this.

The one operator-visible change is crm:bookeo-check → bookeo:check. The guide and both READMEs moved with it, and there are no stale references left.

The deploy trap this had to handle

ModuleRegistry::sync() inserts a newly discovered module disabled, and ModuleSeeder only auto-enables a fixed list. Without intervention, the first deploy would leave CRM enabled while both modules it now depends on were off.

Nothing would visibly break — service providers register their bindings regardless of enabled state, which is deliberate so a disabled module can still be diagnosed from a shell — but the next person to toggle CRM off and on again would hit Module [crm] depends on [bookeo], which is not enabled with no idea why.

So: a migration enables them where CRM is already on, and ModuleSeeder lists them first for fresh installs (enable() refuses a module whose dependencies aren't already up).

What deliberately did not move

The whole inbound side stays in CRM — webhook receiver, deliveries table, opt-out list, reply store, both screens.

ReplyChecker matches an inbound message back to crm_sms_sends to work out which customer and child it belongs to. Moving it as-is would make Sms depend on Crm, which depends on Sms.

Breaking that needs an attribution hook — Sms asks "who is this number?", Crm answers, an unrecognised number stays unattributed (already the documented behaviour). Worth doing when a second sender exists, not before. It's written up in Modules/Sms/README.md along with the consequence in the meantime, stated plainly:

anything new that sends SMS must check the CRM module's opt-out list itself. That coupling is the reason to finish the job.

bookeo:check lost its write-back advisory for the same reason — it was reading a crm.* setting. It now reports the customer-write permission factually without naming who wants it; crm:bookeo-log-backfill --dry-run already says what its absence means for the SMS mirror.

Verification

Mechanical and wide: 19 files had an import rewritten, 5 had a config read repointed. I checked each of these came back clean —

• no Modules\Crm reference anywhere in the two new modules
• no stale import of the four moved classes anywhere in the repo
• no stale config('crm.sms.*') / config('crm.bookeo.*') read
• every changed PHP file lints
• no duplicate test helpers (the guard added in Retry the Bookeo write-back on its own schedule, not the reply checker's #39)
• composer validate passes and the lockfile needs no change — the root Modules\ → Modules/ PSR-4 mapping already covers the new namespaces

10 new tests in tests/Feature/Modules/IntegrationModuleTest.php cover the wiring that fails silently: both modules discovered, each client shared not transient, bindings available while the module is disabled, CRM's declared dependencies, enable refused before dependencies are up, disable refused while CRM uses them, and credentials read from the config files that moved.

vendor/ can't be installed in this environment (codeload.github.com is blocked by the proxy), so CI is the verification for the suite itself.

Next

Phase 2 — opt-out list and webhook receiver into Modules/Sms, behind the attribution hook — when you want it. That one touches the webhook URL and live settings rows, so it deserves its own PR.

---

Generated by Claude Code