Operator intervention should notify the operator in chat with standard orchestrator formatting, not only write bare issue comments

[fujiwaranosai850]

Root lane

This issue belongs under the operator intervention problem family, not under #218.

Use #203 as the conceptual/root lane for this problem family:

• #203 Add live orchestrator intervention for in-flight worker execution

This issue exists because testing of that intervention surface revealed a delivery/presentation gap in operator-facing behavior.

Problem

During live testing of intervention policies, matching events were successfully intercepted and the configured action executed, but the visible behavior was wrong for operator-facing intervention.

Observed behavior:

• intervention events were detected
• policy matching worked
• auto actions executed
• the resulting comment action landed as a GitHub issue comment
• the comment body was a bare message like:
  • I see that

What did not happen:

• the operator did not receive a visible notification in the same Telegram chat/topic where DevClaw normally communicates
• the message did not use the normal orchestrator presentation style (emoji / role tag / recognizable orchestrator voice)

Why this is a separate lane from #218

#218 is about first-class delivery phases for promoted candidates, acceptance, and demotion semantics.

This issue is not about release-phase workflow modeling.
It is about the operator-facing communication path and presentation semantics of orchestrator intervention.

If we conflate them, we risk mixing:

• workflow-state/lifecycle implementation work
• operator intervention delivery bugs
• chat formatting/presentation requirements

Keep those lanes separate.

Expected behavior

When the orchestrator intercepts a relevant event and is meant to notify or acknowledge it for the operator, it should:

1. notify the operator through the same communication surface DevClaw normally uses for operator interaction (for example the same Telegram chat/topic)
2. preserve the correct target session/topic where applicable
3. use the standard orchestrator-facing message style, not a bare raw issue comment

Examples of the intended shape:

• recognizable orchestrator origin
• standard emoji/tagging pattern
• normal operator-facing syntax and formatting consistent with other orchestrator messages

Concrete gaps exposed by testing

1. Wrong delivery target

   • intervention comment actions are currently issue-tracker-centric rather than operator-chat-centric for this use case

2. Wrong presentation semantics

   • the action produced a raw bare I see that comment rather than a normal orchestrator-formatted message

3. Likely topic/session targeting gap

   • audit evidence suggested the wake path targeted the group-level session key instead of the topic-bound session, which may contribute to missing visible chat delivery

Requested outcome

Design and implement the correct operator-facing intervention delivery behavior so that:

• operator intervention acknowledgements can appear in the operator chat/topic
• the orchestrator uses normal recognizable formatting/persona when surfacing intervention events
• issue comments remain available only where they are the correct delivery path, rather than being the default substitute for operator chat notification

Done when

• intervention-originated operator acknowledgements can be delivered to the correct operator chat/topic
• topic-bound targeting is preserved correctly
• the visible operator-facing message uses standard orchestrator formatting
• testing clearly distinguishes chat notification behavior from issue-comment behavior

Cross-reference

• root capability family: #203
• do not treat #218 as the root lane for this bug