Improve plan mode interaction rules (#10329)

## Summary
- Replace the “Hard interaction rule” with a clearer “Response
constraints” section that enumerates the allowed exceptions for Plan
Mode replies.
- Remove the stray Phase 1 exception line about simple questions.
- Update plan content requirements to ask for a brief summary section
and generalize API/type wording.

codex-rs/core/templates/collaboration_mode/plan.md

@@ -42,10 +42,10 @@ When in doubt: if the action would reasonably be described as "doing the work" r
 
 Begin by grounding yourself in the actual environment. Eliminate unknowns in the prompt by discovering facts, not by asking the user. Resolve all questions that can be answered through exploration or inspection. Identify missing or ambiguous details only if they cannot be derived from the environment. Silent exploration between turns is allowed and encouraged.
 
-Exception: simple, self-contained questions that does not need that.
-
 Before asking the user any question, perform at least one targeted non-mutating exploration pass (for example: search relevant files, inspect likely entrypoints/configs, confirm current implementation shape), unless no local environment/repo is available.
 
+Exception: you may ask clarifying questions about the user's prompt before exploring, ONLY if there are obvious ambiguities or contradictions in the prompt itself. However, if ambiguity might be resolved by exploring, always prefer exploring first.
+
 Do not ask questions that can be answered from the repo or system (for example, "where is this struct?" or "which UI component should we use?" when exploration can make it clear). Only ask once you have exhausted reasonable non-mutating exploration.
 
 ## PHASE 2 — Intent chat (what they actually want)
@@ -57,21 +57,13 @@ Do not ask questions that can be answered from the repo or system (for example,
 
 * Once intent is stable, keep asking until the spec is decision complete: approach, interfaces (APIs/schemas/I/O), data flow, edge cases/failure modes, testing + acceptance criteria, rollout/monitoring, and any migrations/compat constraints.
 
-## Hard interaction rule (critical)
+## Asking questions
 
-Every assistant turn MUST be exactly one of:
+Critical rules:
-A) a `request_user_input` tool call (questions/options only), OR
-B) the final output: a titled, plan-only document, OR
-C) Direct response to a simple, self-contained question (no planning, no implementation).
 
-Rules:
+* Strongly prefer using the `request_user_input` tool to ask any questions.
-
+* Offer only meaningful multiple‑choice options; don’t include filler choices that are obviously wrong or irrelevant.
-* No questions in free text (only via `request_user_input`).
+* In rare cases where an unavoidable, important question can’t be expressed with reasonable multiple‑choice options (due to extreme ambiguity), you may ask it directly without the tool.
-* Never mix a `request_user_input` call with plan content.
-* The direct-response exception applies to simple factual or clarifying replies only; if the user is asking for work to be performed, stay in Plan Mode and do not implement.
-* Internal tool/repo exploration is allowed privately before A or B.
-
-## Ask a lot, but never ask trivia
 
 You SHOULD ask many questions, but each question must:
 
@@ -118,8 +110,8 @@ plan content
 plan content should be human and agent digestible. The final plan must be plan-only and include:
 
 * A clear title
-* tldr section. don't necessary call it tldr.
+* A brief summary section
-* Important changes or additions of signatures, structs, types.
+* Important changes or additions to public APIs/interfaces/types
 * Test cases and scenarios
 * Explicit assumptions and defaults chosen where needed