Manage SYSTEMS: named groups of up to 9 of your apps, handled as one (ADR-0353). action='list' (default) shows your systems and their apps. 'create' needs name and optionally apps (dropIds you own, each with an optional short alias). 'add' / 'remove' put one app in or out (systemId, dropId). 'rename' takes name. 'delete' removes the grouping only: the apps stay, untouched. A system whose owner deleted it WITH its apps from the dashboard shows suppressionDemandeeLe: its apps are offline, kept 30 days, then erased; only the dashboard restores or erases it, and every other action on it is refused. 'delegate' grants email (an existing Dropyour account) the role 'mainteneur' on EVERY app of the system, with the same limits as dropyour_delegate. 'label' sets a PRIVATE client label (client, empty to remove) used to group systems; the client never sees it. 'export' returns systeme.json: the system in the manifest format (apps with their private routes and events, call permissions with their contracts, subscriptions), where to get each app's content (its own export), the links to apps outside the system, whether shared identity is on, and what is missing (complet); it replays with plan/apply once each app's content is added. 'shared_identity' (enabled: true or false) makes the apps of this system see the SAME identifier for the same signed-in visitor (app.visitor.id), instead of one per app (the default); the visitor is told on the sign-in page which other apps recognise them; never a shared cookie, and the email still reaches an app only with the visitor's consent for that app. Turning it on or off changes the identifiers apps see (signed-in visitors sign in again); an app that leaves the system goes back to its own identifier. 'view' returns the system with its call permissions (internal or not, verified or not), the last compatibility verdict of each called app, and its dated activity, including apps that left it. 'transfer_link' returns a one-time link (24 h; a new one cancels the previous) to whoever opens it while signed in; apps limits it to some of its apps (the others stay with you, in a system of the same name). Links between the apps that leave survive, links to apps outside it are cut, every management token is reset. 'private_routes' (with dropId, a server app, and routes) reserves paths to the apps allowed to call it: anyone else gets 404, the request never reaches the app; the manifest accepts the same as apps.<alias>.routesPrivees. Events: apps.<alias>.sujets = { topic: [keys] } on a server app, and a top-level abonnements: [{ sujet, de, vers, route }] (de emits, vers receives on its route; requires the link de→vers, declared in liens or already set); applied after the links, nothing is removed by omission. 'plan' and 'apply' take a manifest describing the whole system (apps with their html or zip, call permissions with their contracts): plan says, before anything is done, what will be created, published or linked, what is already up to date, what is kept because the manifest does not mention it, and what is refused and why; apply does it step by step (versions saved first on server apps, called apps published before their callers, every new contract replayed at once) and stops at the first failure with a report that never claims more than was done. Running apply again with the same manifest resumes, then does nothing. The manifest never makes an app a server app (that is a subscription) and never deletes anything. 'contracts' returns two files to keep in the system's repository: a runward spec (one line per route an app of the system reads from another under contract) and the JUnit report of the last replay of each contract; npx runward spec-check <spec> then checks them without Dropyour, and fails on a route that broke or was never replayed under its current revision. Nothing is replayed by this action: a contract is replayed when it is declared and before a new version of the called app stays online. 'proof' tells where the system's proof dossier stands (null = never asked); with enabled: true it asks for a new one. The dossier is produced within hours, off the platform: each app's own proof dossier, plus a runward mission of the system derived from its apps, links, contracts and events, that passes runward check --strict, sealed, attested, with a witness re-read by an independent checker; the owner downloads it from the cockpit. An app belongs to one system at most. A system never spans two accounts. Requires a connected account (no managementToken).