eregulations

Use when adding a new external webservice (a SOAP or REST backend exposed as a REST endpoint) to a `mule3-<country>` eRegistrations integration repo — e.g. "add VerifyX like VerifyTIN", "expose this SOAP proxy as /api/...", "new webservice in mule3-lesotho". Covers the Mule 3 flow, the Java `Callable` component, the SOAP template, and all the registration touchpoints that are easy to forget. This is the `dev` dispatch target of `ereg-router` for Mule 3 integration work. DO NOT TRIGGER for changing an EXISTING webservice's mapping in BPA (that is a bot/mapping change), or for the platform's own services outside the `mule3-<country>` repos.

Use when standing up a legacy Windows/SQL-Server-hosted eRegulations or TradePortal country instance as a new per-country application on the multi-instance Coolify host — symptoms include having a raw `.bak` country DB backup, an old "Global DB" `.bak`, a content zip (Multilang/PublicConfig/PublicContent/media), and an old `Web.config` to migrate onto eRegulations-deploy's Coolify architecture. A production country gets its own dedicated SQL Server (phase 0); test and demo instances share one. Triggers on "deploy <country> to Coolify", "stand up the legacy instance", "migrate this .bak onto the shared SQL Server". This is the `deploy` dispatch target of `ereg-router` for a legacy instance. DO NOT TRIGGER for redeploying an instance that already exists on Coolify (that is a plain redeploy), or for a 7.x-native instance that was never on the legacy Windows stack.

Use when handling any eRegulations or TradePortal request — a country portal throwing errors or refusing to start, a deploy or redeploy of Admin or Public, an upgrade to 7.x, a code change across the Admin and Public repos, a new instance, or a missing or wrong translation label. Classifies the request, resolves which instance and version it concerns, detects what this environment can actually do right now, and evaluates the safety gates before any work starts. Also reachable explicitly as /eregulations:ereg.

Use when asked to consolidate a per-instance MultilangCentralRepository's legacy label-family files (`Common.txt`, `e-RegulationsAdmin.txt`, `LayoutHomeAdmin.txt`, etc.) into `LangAdmin.txt`, so the Admin SPA — hardcoded to read only the LangAdmin family — can reach translations that already exist under other legacy module names. Symptoms: "copy the labels into LangAdmin.txt", "consolidate translations for <instance>", or the Admin SPA showing untranslated default text for a label that is clearly already translated somewhere in the legacy admin. This is the `translations` dispatch target of `ereg-router`. DO NOT TRIGGER for eRegistrations (2.x) translation work through the Global Translation Service — that is the `translations-mcp` plugin — or for reconciling a local snapshot directory against a server directory during an upgrade (a different script, see the gotcha below).