Estimate: 28m · Depends on: 6.6.2, 6.1.2, 5.1.2, 5.3.3, 5.4.2, 5.4.4, 5.4.5
The registry + engine extensions consuming the Epic-5 surfaces — the same extension pattern as 6.1.2 over 6.1.1.
Triggers: commented consumes work-item/comment.created (5.1.2's emit — a third consumer, no new emit path) and transitioned consumes work-item/transitioned (5.4.5's emit), both honoring provenance skip; both events grow the viaAutomationRuleId? field if 5.1.2/5.4.5 landed without it.
Actions: add-watcher (a member picker config) via watchersService (5.4.4 — its view-access validation applies; an ineligible user = a recorded failure); add-comment (a fixed-body config) via commentsService (5.1.2 — mention parsing applies; the comment's own event carries provenance so mention emails still send but no rule re-fires); add-label (type-to-create config) via labelsService (5.4.2 find-or-create semantics); set-custom-field (per-type value config — select option / user / number / date / text) via customFieldsService values (5.3.3 — per-type validation + revision diffs apply). Each is a TOTAL registry entry (config schema + validate + execute + editor kind); stale referents (deleted option/label/field/user) degrade to a recorded failure with the typed error, never a crash.
Conditions: the rule editor's field vocabulary grows the 6.1.2 dynamic entries (custom fields, labels, components) — the condition compiler already handles them; this subtask wires validation + the editor-kind contract.
pnpm test:coverage ≥90% on the extensions.commentsService + its event; 5.4.4 watchersService; 5.4.2 labelsService; 5.3.3 customFieldsService values; 5.4.5 work-item/transitioned