Pre-release audit since alpha11: untranslated strings, undocumented modules, stale references, a dev dependency, a stale metrics page and a token load per row

A pre-release audit of 1.x since 1.0.0-alpha11, ahead of the next alpha. Six findings, all of them release hygiene rather than behavior: nothing here changes what the engine does. The design decisions the audit also surfaced (the instance read scope now defaulting to workers rather than the initiator, and the breadth of "reassign orchestra tasks") are deliberate and belong in the release notes, not here.

1. Strings reach the site untranslated

Six strings were reworded in this period, leaving the French translation matching the old text while the new text goes untranslated: "Assignment" to "Assignee", "Comment task" to "Complete task", "Submission id variable" to "Store submission id in variable", "Status: @status" to "State: @state", and the reworded descriptions of the wait-all join and the subprocess retry setting.

Sixteen further strings were added with no translation at all, among them the payment timeout setting and its description, the payment empty message, the webform escape outcomes, the workflow version translation data field, and the two new human-node settings for the completion payload and the completer variable.

Eleven more are translated in a different module's .po file than the one that defines them. These do render translated, because interface translations are keyed by source string and context rather than by module, but they fall back to English whenever the defining module is enabled without the other. The clearest case is the work item state label in src/Entity/WorkItem.php, whose "Work item status" context entry lives in orchestra_inbox, so an engine installed without the inbox shows it in English.

Another 27 strings in the same files turn out never to have been translated, mostly on the webform handler settings form. Same defect, same edit, so this closes them too: 60 strings across nine .po files.

2. Two shipped modules are missing from the module table

orchestra_presentation and orchestra_inbox_views are shipped, and orchestra_inbox, orchestra_ui and orchestra_views depend on the first of them, but neither is listed in the module table in README.md.

3. Stale references left by the outcome and payload rename

• docs/incidents.md shows a dead-end diagnostic reading validation.result, which no longer resolves; it should be validation.outcome.
• tests/src/Kernel/InstanceOriginTest.php builds its fixture node with result_variable and result_scope, now dead keys. The test still passes because it only asserts the recorded origin, but the fixture no longer configures anything.
• A comment in orchestra_interaction_task.routing.yml names userCanAct(), renamed to mayAct().

4. A dev-only dependency

orchestra_domain needs domain_render_context, which had no tagged release when the dependency was added, so composer.json pinned drupal/domain_extras to 3.x-dev. domain_extras 3.0.4 now ships it, so the constraint becomes ^3.0.4.

5. The codebase metrics snapshot is a release out of date

docs/metrics.md was last regenerated at the alpha11 commit itself and does not know about any of the work since, including the three new modules. Regenerated from the committed script: 879 files and 68,156 code lines become 998 and 80,350, and the test-to-production ratio moves from 57% to 61%.

6. The task action columns load a token per row

Resolving where a task is acted on goes through TaskActions::family(), which reads the work item's token, and then the token's instance. The act-link and operations columns of the personal task views asked that per row, so a listing paid two entity loads a row. Both runtime entities deliberately skip the persistent cache, because they are read to decide a write, so nothing absorbs those loads between requests either.

The instance act link and the work item holder columns added in the same period already batch in preRender(); these two did not. TaskActions gains a prefetch() that loads a whole listing's tokens and instances in two queries, and both columns call it. A kernel test pins the count to the batch rather than to the row count: with four rows carrying four distinct tokens it reads them in fewer than four queries, and five without the prefetch.

Not a defect, documented instead

AssignmentMatcher memoizes viewer tokens and acting-for ids by account id alone, while both derive from the tenant resolved for the request. That is safe today only because a notification context can switch the acting tenant for the duration of a callback, and every shipped dispatcher resolves its recipients before entering that callback and renders inside it. The memo is left as it is, since keying it by tenant would add a tenant resolution to a hot path to guard a caller that does not exist, but the docblock now states the constraint rather than claiming the tenant cannot change mid-request.