Name things the way Drupal core does: canceled, core's *Hooks suffix, summary() over explain(), delete() over forget(), action over act

A contributor arriving at Orchestra knows Drupal, not Orchestra. Every word we invent for something core already names is a word they have to learn for no reason. This audit checked every class, interface, trait, enum, method, plugin id, route, service id, permission and config key in the module against core's own vocabulary, and this issue fixes the places where we spent a word core does not use for something core does name.

How it was checked. Every candidate word was counted against a corpus of 24,173 identifiers taken from core's class, interface, trait, enum and method names in core/lib and core/modules. A word with zero hits in core is an invention. An invention is only a defect where core already has a word for the same thing; where the domain is genuinely outside core, the invention is correct and is deliberately kept.

Already correct, and left alone. All 484 production filenames match the type they declare. All 70 interfaces end Interface and all 27 traits end Trait. Capability interfaces use core's adjective form (AssignableInterface, RetryableExceptionInterface), with no Supports*Interface anywhere. Enums are bare nouns in core's style. All 91 plugin ids are snake_case, all 64 route names are prefixed, service ids are prefixed or core-shaped, CSS is BEM throughout, and all 697 test method names pass the phpcs lowerCamel rule.

Proposed resolution

• American spelling. cancelled appears on 221 lines, including four stored state constants (STATE_CANCELLED = 'cancelled' on the process instance, the token, the work item and the incident). Core spells it canceled 45 times against 9, and labeled 15 times against 1. StatusCatalogue and its interface are British too; core has neither spelling, and core's word for "which of these are available here" is Repository (27 classes), so it becomes StatusRepository.
• Hook classes take core's suffix. Core's Hook/ directories hold 371 classes ending Hooks against 15 ending Hook, then only *Requirements, *Alter and *Operations. Of our 34, only 8 end Hooks; the others end Hook, Cleanup, Sweep, Deletion, Tokens, Scope, Invalidation, Healer, Guard or Cancellation. They take the shape core uses throughout, the extension name then the topic then Hooks, as in NodeTokensHooks and ViewsThemeHooks.
• explain() becomes summary(). Our flow condition is a condition plugin type, and core's ConditionInterface declares this exact method as summary(). explain has zero hits in core, so a contributor arriving from core's Condition looks for summary() and does not find it.
• forget() becomes delete() or reset(). forget and recall both have zero hits in core, which uses reset() 34 times and resetCache() 10. OrchestraReturn is a key-value store in all but name, and core's KeyValueStoreInterface spells the pair get() and delete().
• figure becomes the amount vocabulary. orchestra_payment spends amount 69 times and figure 43 times on the same axis. The distinction being drawn is real, the raw value against the formatted display string, but the word is not; the constants beside it already say SHOWN_QUERY.
• project is the word Drupal keeps for a drupal.org project. All 59 Project* identifiers in core are that noun and none is the verb. projectToConfig() and projectFromConfig() join the toConfig() and fromConfig() pair the module already uses elsewhere, which also retires the third and fourth spellings of one idea, toWorking() and harvest().
• Agent nouns core never forms. Core has zero Healer, Drainer, Sweeper and Survey, against 187 Provider, 142 Manager, 135 Handler, 24 Preview and 13 Processor. MigrationSurvey becomes MigrationPreview, matching the PayablePreview we already have, and StepClass becomes StepCssClass, since it builds CSS classes and its old name read as the PHP class of a step. Seven classes sitting in EventSubscriber directories did not end Subscriber either; core has 111 that do. The drain and sweep families are deliberately left: both are used consistently for one idea across the engine's hottest path, and process does not carry the bounded-until-empty meaning that DrainState exists to track.
• snake_case where Drupal spells snake_case. The config keys flowLabels and nodeLabels sit directly beside their own siblings nodes and flows, and become flow_labels and node_labels. The public parameters $actorUid, $completerUid and $checkExpiry sit beside our own $node_id and $token_id in the same files.
• The act vocabulary becomes action. act as a noun has zero hits in core, and named the link that opens the thing a person has to do. Core calls that an operation, but we already spend operation on three different things and two of them are core's own meaning, so it cannot move. action is what this code already called it: OperationController::actionLinks() took a $action whose own docblock read "a pending-actions finder entry (outcomes with urls, act_url, act_label)", it lives in PendingActionsFinder beside PendingActionHandlerInterface, and the French for the views field already read "Lien d'action". So actionUrl(), actionLabel(), actionAccess(), PendingActionLabel, TaskActionLink, the action_label config key, the action_link views field and the orchestra-action--{node} classes. Core's Action plugin sense (orchestra_action, ActionTask) is a different subject and is untouched, as is the verb in actingFor().
• Smaller ones. view own process instances is the only one of eleven permissions that does not name the module, right next to its sibling access orchestra instances. TaskDisposition and JoinDecision are two enums in one namespace with the same shape and two different words. activeChips() is Material Design vocabulary that Claro does not use. noteBoundary() records when a delegation next changes, so it is recordNextChange(), and voteValue() reads Completion::OUTCOME_KEY, so it is outcomeValue(). inertAction(), landingPage(), cohortClosed(), qualify() and catchUp() are left alone: each turned out to be consistent, load-bearing vocabulary tied to a shipped config key, a CSS class, a base field or an XML term, not a stray metaphor.

Deliberately kept. Core has no word for a workflow engine's furniture, so these stay exactly as they are and a later sweep must not "fix" them: token, park, gateway, join, split, instance, signal, outcome, advance, subprocess, tenant, incident, deadline, timer, audience, initiator, delegation, work item, continuation, checkout, payable. JoinInterface::arrive() is BPMN's own verb for a token reaching a join and stays too, despite zero hits in core.

Deliberately not in this change

One finding needs a decision rather than a rename, and is recorded here so it is not re-litigated later.

Accessor density. 22.9% of core's method names begin get (2276 of 9942). Ours is 9.0% (90 of 1005), which is 40% of core's density. 409 of our methods carry no verb at all, and 364 of those have no core precedent as a bare name: instance(), deadline(), outcomes(), recipients(), successors(), milestones(), refusals() and so on. This is the largest readability gap left in the module, but each one is a separate judgement about whether the method reads as a question, a predicate or an action, so it does not belong in a mechanical rename pass.

Remaining tasks

No update path is provided. The module is pre-1.0 and alpha releases are reinstall-only, so the stored state values, the config keys and the affected plugin ids change in place. The French translations and the documentation move in the same merge request.

AI-Generated: Yes (Claude Code was used to run this naming audit against Drupal core's vocabulary, to draft this issue summary, and to write the renames on the merge request. I reviewed the work before posting it.)