task: #3624693 Bring seven statements in the docs and docblocks back to what the code does
Seven statements a file-by-file audit found that the code no longer bears out. None of them changes behavior, so they are one task.
docs/roadmap.md, Domain tenancy: a domain was said to be bound to a tenant by a third-party setting on the domain record. The binding lives on the tenant, on its own Domains form, and the submodule README says a domain record holds Domain's configuration and nothing of ours.docs/roadmap.md, the audit log: the audit event was called the spine the notifications feature reuses. Notifications never ride it; the notifications page says so in its own second paragraph.docs/roadmap.md, Views: three ready-made dashboards. The Views page lists six.docs/tokens.md, Safety: a message interaction result was said to be filtered as admin HTML. It renders through the restricted HTML format, and falls back to admin-HTML filtering only where that format is not installed.MessageInteractionTest's class docblock andExternalInteractionNodeFeatureTest::testMessageRichTextFlattenedToString: the same slip, in the two places a reader would check it.ProcessInstanceInterface::getInitiatorId(): a subprocess was said to inherit its parent's initiator. That is one of three the step chooses between, since the initiator source setting.OperationInterface: an operation was said not to be pushed to the inbox as a work item, and inbox task types to be the ones that create one. Every human node mints a work item; its mode decides which surface lists it.
Each is reworded in place. Prose only, so no test is added.
Rebased on 1.x after !531 (merged) merged (clean, no overlap).
Audit rounds (5, closed on a clean round). For a prose-only change the defect that matters is a correction that is itself wrong, so round 1 re-derived all seven against the code rather than against other prose — which is exactly what made the first pass circular in two places.
Five verified in code. The domain binding is a third-party setting on the tenant, read back by a orchestra.tenant_resolver-tagged resolver that loops tenants asking TenantDomains::namedBy(). OrchestraNotificationEvent exists in src/Event/ and is dispatched by OrchestraNotification, while the only subscriber to OrchestraAuditableEvent is the audit trail's own. Work item minting is gated on HumanNodeInterface and the mode is stamped from getWorkMode(), so an operation mints one exactly as a task does. InitiatorSource has exactly three cases. And MessageInteraction::respond() renders through restricted_html with an admin-HTML fallback.
Two were loose and are now fixed.
- The dashboard count went from three to six, but the roadmap entry names
orchestra_views,orchestra_vboandorchestra_vbo_inbox— and only four of the six ship there. The inbox and My tasks come fromorchestra_inbox_views, since they read the work item. Six dashboards attributed to modules that ship four is the same trap one module over, so the entry now says which ships which. ExternalInteractionNodeFeatureTest's docblock said the render path goes through the restricted HTML format full stop, where the module documents a fallback when that format is absent — the very distinction the rest of this change exists to draw.
Round 2 confirmed the correction set is complete. Sweeping each of the six claim-shapes across docs and code finds no further instance: every remaining "admin HTML" mention is the fallback branch or the format comparison, "inherits its parent" elsewhere is about chain ids and cohorts rather than initiators, and the two notification READMEs agree (orchestra_inbox_notification states it "never subscribes to the audit event").
Rounds 3 to 5 found nothing further; the neighbouring roadmap entries on these same six subsystems check out, and every edited line stays within the file's 80-column wrap.