>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3631455. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !704 >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>Kessai is laid out the clearest way of the three projects that share this design: its root module, <code>kessai</code>, is the contract every site installs; <code>kessai_engine</code> takes payments on this site; <code>kessai_client</code> takes them through another site instead; <code>kessai_server</code> answers other sites. A site picks its role from the module list, and everything that needs payments to actually happen depends on <code>kessai_engine</code>.</p> <p>Orchestra has the same layers since <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/orchestra/-/work_items/3631451" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/orchestra/-/work_items/3631451</a></span>, under other names: the contract is the submodule <code>orchestra_client_api</code>, and the engine is the root module <code>orchestra</code>. So the module every site installs is a submodule, and the root module is one a client-only site must not have.</p> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>Lay Orchestra out as Kessai:</p> <ul> <li><code>orchestra</code>: the contract, from <code>orchestra_client_api</code> (<code>OrchestraClientInterface</code>, the client resolver, wire identities, notice signatures, request limits). Its settings become <code>orchestra.settings</code>. Hidden from the Extend page, as <code>kessai</code> is (and as <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/orchestra/-/work_items/3631451" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/orchestra/-/work_items/3631451</a></span> already makes <code>orchestra_client_api</code>): it arrives as a dependency of whatever uses it, and a site that installs it alone drives no workflow.</li> <li><code>orchestra_engine</code>: the engine, from today's root module, in <code>Drupal\orchestra_engine</code>, with its config (<code>orchestra_engine.settings</code>, and every engine config entity, such as <code>orchestra_engine.workflow.*</code>). Entity type ids and their tables keep their names.</li> <li><code>orchestra_client</code> and <code>orchestra_server</code> keep their names.</li> <li>Every submodule that depends on <code>orchestra:orchestra</code> for the engine depends on <code>orchestra:orchestra_engine</code>, and every kernel test enables both.</li> </ul> <p>Orchestra is pre-beta, so nothing is kept for the old names: no class aliases, no deprecation layer, no update hook.</p> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <ul> <li>Implement, one commit per step: move the engine, move the contract into the root, rename the config, update the dependents and tests.</li> <li>Write the one-time migration for existing sites, run per site with a backup first: rename the modules in <code>core.extension</code> and their schema versions, rename every engine config object and the dependency lists and third-party settings that name the module, set the provider of the engine's entity types, and re-import the translations under the new projects. Combined with the rename of <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/orchestra/-/work_items/3631451" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/orchestra/-/work_items/3631451</a></span>, so a site migrates once.</li> <li>Follow-ups in the projects that depend on <code>orchestra:orchestra</code> for the engine (yoyaku).</li> <li>Update the documentation.</li> </ul> <h3 id="summary-ui-changes">User interface changes</h3> <p>None, beyond the module names in the module list.</p> <h3 id="summary-api-changes">API changes</h3> <ul> <li>The engine's classes move from <code>Drupal\orchestra</code> to <code>Drupal\orchestra_engine</code>, and the contract's from <code>Drupal\orchestra_client_api</code> to <code>Drupal\orchestra</code>.</li> <li>Service ids follow their module: <code>orchestra.*</code> becomes <code>orchestra_engine.*</code>, <code>orchestra_client_api.*</code> becomes <code>orchestra.*</code>.</li> <li>Modules that need the engine depend on <code>orchestra:orchestra_engine</code>.</li> </ul> <h3 id="summary-data-model-changes">Data model changes</h3> <p>The engine's config objects are renamed from <code>orchestra.*</code> to <code>orchestra_engine.*</code>, and the contract's from <code>orchestra_client_api.*</code> to <code>orchestra.*</code>. Entity data and tables are unchanged.</p> <p>AI-Generated: Yes (Claude Code was used to help draft this issue summary. I reviewed it.)</p>