Post-plan-approval system message contradicts itself ("edits require manual approval" + "Proceed with implementing"), causing the model to stop instead of starting work

Encuentra el generador de mensajes posterior a la salida en src/plan-mode/<...> e inspecciona la cadena devuelta después de exit_plan_mode en el modo interactivo. Actualiza la redacción contradictoria para que indique al modelo que comience inmediatamente, a la vez que describe la aprobación de la edición como un paso de la UI. Añade o actualiza una prueba de snapshot para exigir "Begin implementing now" y rechazar "require manual approval".

Describe the bug

When a user approves a plan in plan mode (Shift+Tab -> approve, or
selecting "interactive" from the exit_plan_mode choice list), the CLI
emits the following confirmation as a tool result:

Plan approved! Exited plan mode.

You are now in interactive mode (edits require manual approval). Proceed with implementing the plan.

The two sentences contradict each other:

1. "edits require manual approval" reads as a permission gate -- the
   model must wait for the user to hand-approve each subsequent edit.
2. "Proceed with implementing the plan" instructs the model to start
   work immediately in the same response.

In practice, capable models hedge: they output a short text-only
acknowledgement ("Ready to start implementing whenever you give the
word -- recommend kicking off with X") and stop, treating the
parenthetical as the operative gate. The user then has to send a
second message ("go", "start", "do it") to actually begin work, even
though they already approved the plan. This defeats the purpose of the
plan-approval gesture and breaks the documented workflow that says
plan approval IS the go-signal.

The interaction is not a custom-instruction issue. Even repos that
explicitly tell the model "approval = go, same turn, no text-only
sign-offs" hit this regularly because the CLI's own message is in
direct competition with the custom instruction, and the CLI's wording
arrives later in context (right before the model responds).

This belongs to the CLI: the message is generated by the CLI's plan
mode, not by the model or the upstream service. Fixing the wording is
a one-line change.

Affected version

GitHub Copilot CLI 1.0.48

Steps to reproduce the behavior

1. Start an interactive session in any repo:
   copilot (or copilot --resume <id>).

2. Enter plan mode (Shift+Tab) and ask the model to draft a plan, e.g.
   "plan how to refactor X".

3. After the model writes a plan and calls exit_plan_mode, choose
   the "interactive" action when prompted (the most common
   approval-with-no-autopilot path).

4. Observe the tool-result text the CLI returns to the model:

   Plan approved! Exited plan mode.
   You are now in interactive mode (edits require manual approval). Proceed with implementing the plan.
   

5. Observe the model's next response. In most cases it is text-only:
   a one-paragraph "ready to start, recommend kicking off with X"
   sign-off, with NO tool calls. The user then has to send a second
   message ("go" / "start") to make work actually begin.

Reproduces sometimes with Claude Opus 4.7 in this CLI version.

Expected behavior

The post-exit message should give the model exactly one unambiguous
instruction. Either:

• (preferred) drop the parenthetical and say only:

  Plan approved. Begin implementing now in this same response. The
  user has already approved; do not pause for further confirmation.
  Each individual edit will still surface for manual approval through
  the normal interactive-mode UI.

  This makes the contract explicit (approval-at-plan-time, edit-by-edit
  UI gates afterward) and removes the conflicting "wait" reading.

• or keep manual-edit-approval semantics but make them clearly
  about the UI layer, not the model's behaviour:

  Plan approved. Start implementing now. Individual edits will be
  shown to the user for approval through the interactive UI before
  being applied -- you do not need to wait for confirmation in chat.

Either wording resolves the contradiction.

Additional context

(Windows PowerShell 7.6.1 on Windows NT 10.0.26200.0.)

Environment:

• Logs: not attached -- this is a wording/UX bug reproducible from any
  fresh session, no debug log adds signal. Happy to attach a session
  bundle on request (copilot debug-logs --session a34a11f1-5abd-41d0-9a83-1ef76611b062).
• Operating system: Windows 11 (NT 10.0.26200).
• CPU architecture: x86_64.
• Terminal emulator: Windows Terminal.
• Shell: PowerShell 7.6.1.
• CLI version: 1.0.48.

Why this is a CLI bug, not a model bug or a custom-instruction bug:

• The model is following the literal text the CLI hands it. The CLI is
  the speaker.
• The wording is shipped in the CLI binary -- it is not user-editable
  via custom instructions or settings.
• Custom instructions that try to override it ("approval = go, same
  turn") fight against a directly-contradicting tool-result that
  arrives mid-turn, after the rule has already been processed. The
  rule loses about half the time even when it is explicit.

Proposed fix (one line, src/plan-mode/<...> -- replace the whole
"You are now in interactive mode" sentence):

// Before
return 'Plan approved! Exited plan mode.\n\nYou are now in interactive mode (edits require manual approval). Proceed with implementing the plan.';

// After
return 'Plan approved! Begin implementing now in this same response. Individual edits will surface for the user via the normal interactive-mode UI; do not pause for chat confirmation.';

Regression guard suggestion: a snapshot test that asserts the
post-exit_plan_mode tool-result string contains "Begin implementing
now" and does NOT contain the substring "require manual approval".
That single assertion locks the fix and catches accidental reverts.

Adjacent issue (separate report worthwhile): the choice list for
exit_plan_mode actions could surface a one-line preview of the
post-exit message per choice, so users picking "interactive" vs
"autopilot_fleet" know what behavioural contract they are accepting.