docs(brainstorm-with-docs): итоги первого живого теста — R1/F1/SEAM + план v2

- Зачем:
  - первый живой тест скилла вскрыл правки, которые надо закрепить, и идеи для v2.
- Что:
  - SKILL.md: R1 (рекомендация к вопросам-решениям), F1 (2-3 внутри рамки + ≥1
    дивергентный сверх, без филлера), inline/confirm для терминов, read-only
    инспекция данных в шаге 1, нейтральная SEAM-метка.
  - ROADMAP.md: статус первого теста, Landed R1/F1/SEAM, вердикты R2/F4/F5a, план v2.
- Проверка:
  - прочитать SKILL.md (core_rules, шаги 1/4/5) и ROADMAP.md.

agents/.agents/skills/brainstorm-with-docs/SKILL.md

@@ -68,7 +68,11 @@ If invoked with arguments, treat `$ARGUMENTS` as the initial problem statement.
 * Surface assumptions, constraints, risks, trade-offs, and non-goals.
 * Don't interview forever — when the problem, constraints, and success criteria
   are clear enough, stop asking and synthesize.
-* Always consider 2-3 viable approaches before recommending one.
+* Offer 2-3 viable approaches within the user's framing, plus at least one (more
+  if useful) that challenges the framing itself — the null option, a reframe, an
+  adjacent-domain steal. Without the framing-challenger, options collapse into
+  variations of one idea. Don't pad to hit a number; every option must be
+  genuinely distinct.
 * Be direct. Give a real recommendation; don't hide behind "it depends" when the
   context supports a call.
 * Explicitly state what should NOT be done now.
@@ -95,6 +99,11 @@ previously rejected options, deployment model, testing/validation conventions,
 and patterns the solution should follow. Respect a documented structure if one
 exists. If no context is available, say so and continue with what the user gives.
 
+Investigation often needs read-only commands beyond the pre-approved git set —
+listing files, inspecting data, querying a dev datastore. That's expected: run
+them (they may prompt for approval), since grounding options in real data is this
+skill's main strength. Never run state-changing commands (see the gate).
+
 ## 2. Classify the work and pick the likely artifact
 
 Decide what kind of work this is, then which artifact is likely to fit:
@@ -120,8 +129,11 @@ decisions. Ask which part to handle first.
 ## 4. Interview / grill
 
 Interview the user until the problem is clear enough to synthesize. One question
-at a time. When the reason for a question isn't obvious, briefly say why it
-matters. Prefer questions that clarify: the actual problem and why it matters,
+at a time. For a decision or choice question, offer your recommended answer and a
+one-line why — a concrete recommendation to react to moves the user further than a
+bare question; for pure fact-gathering a recommendation may not apply. When the
+reason for a question isn't obvious, briefly say why it matters. Prefer questions
+that clarify: the actual problem and why it matters,
 expected outcome, who is affected, constraints, non-goals, success criteria,
 failure modes, operational and security risks, reversibility, deadlines or
 sequencing, what's been tried, and what must not change.
@@ -138,25 +150,21 @@ Grill actively — don't just collect answers, pressure-test them:
   the code agrees; surface contradictions: "Your code cancels whole Orders, but
   you said partial cancellation is possible — which is right?"
 
-Capture resolved terms in `CONTEXT.md` inline, as they happen, using the format
-in [artifacts/context.md](artifacts/context.md) — don't batch them.
+Capture a NEW resolved term in `CONTEXT.md` inline, as it happens (additive, low
+risk), using the format in [artifacts/context.md](artifacts/context.md) — don't
+batch them. Redefining an already-documented term is a vocabulary change: propose
+it inline, but confirm before writing (see step 6).
 
 ## 5. Synthesize options
 
-<!-- SEAM / TODO(v2): prepend a divergence phase before this convergence step.
-     Full version = idea-generation toolkit (axis of variation, archetype
-     stances, inversion, steal-from-adjacent-domain, cost-shifting, pre-mortem,
-     constraint relaxation, null option).
-     TODO(F1): cheap pre-step — add one <core_rule>: "among the options, at least
-     one must be something the user did not already imply." Deliberately deferred
-     now to keep the v1 live-test baseline clean (we want to see how badly pure
-     convergence collapses into variations of one idea). Reconsider landing this
-     single line right after the first live test, before the full toolkit.
-     Keep this step self-contained so it can be split. -->
+<!-- SEAM: a full divergence phase belongs before this convergence step (v2).
+     Rationale, toolkit, and status live in ROADMAP.md — not here, so a running
+     agent isn't primed with the design intent. -->
 
-Present 2-3 viable approaches. For each: short description, when it fits,
-benefits, trade-offs, risks, operational implications, documentation impact, and
-what it avoids or postpones. Then recommend one, explaining why it fits the
+Present 2-3 viable approaches within the user's framing, plus at least one that
+challenges it. For each: short description, when it fits, benefits, trade-offs,
+risks, operational implications, documentation impact, and what it avoids or
+postpones. Then recommend one, explaining why it fits the
 constraints, what risks remain, what to validate first, and what to explicitly
 not do now.