fix: narrow the reuse rule (v0.18.1)

VERSION

@@ -1 +1 @@
-v0.18.0
+v0.18.1

log/changelog-v0.18.0.md

@@ -1,12 +1,6 @@
 # v0.18.0 — look for the flow that already exists before designing a new one
 
-A feature asked students to switch between two teachers and reload under the
-chosen one. Stage 1 framed it as "where do we store the chosen teacher",
-sent researchers after backend token-reissue precedents, and approved a
-design with new APIs. The product already had a working re-entry flow for a
-similar switch in the frontend repository; it surfaced after build, and the
-design changed three times, past the spec re-gate cap. Nothing in the kit
-asked for that search. This release adds it.
+Stage 1 now looks for an existing product flow for the same user-visible change before it offers new designs (from one feature whose design changed three times after such a flow surfaced late).
 
 ## Changes
 

log/changelog-v0.18.1.md

@@ -0,0 +1,15 @@
+# v0.18.1 — narrow the v0.18.0 reuse rule
+
+v0.18.0 came from one feature. This patch keeps the probe and the reuse
+option, and removes what was shaped by that one case.
+
+## Changes
+
+- **skills/1-intent:** the "Existing analogous flow" probe no longer lists
+  example transitions; it searches by the behavior the request names. The
+  Reuse rule is shorter: include the reuse option or say why it does not fit.
+- **roles/researcher:** step 1b shortened to the general rule.
+- **roles/adversary 4b:** blocking only when a researcher reported a concrete
+  existing flow (file:line) and the options omit it without a reason. A
+  missing or "none found" report is non-blocking.
+- **log/changelog-v0.18.0.md:** the story is one line.

roles/adversary.md

@@ -18,10 +18,10 @@ Attack, in order:
    cited check support each `[verified]` label?
 4. **Edge cases.** Check empty, huge, concurrent, unauthorized, malformed, and
    retried inputs.
-4b. **Reuse.** Did the options consider the existing analogous flows the
-   researchers reported? An option set that adds a new mechanism while a
-   working flow for the same transition exists, with no stated reason to
-   skip it, is a blocking finding at the intent and spec gates.
+4b. **Reuse.** When a researcher reported a concrete existing flow (file:line)
+   for the same user-visible change, and the options omit it without a
+   stated reason, that is a blocking finding at the intent and spec gates.
+   A missing or "none found" report is non-blocking: ask for the probe.
 5. **Testability.** Can a machine check each requirement? Flag statements such
    as "works well" that do not name an observable result.
 6. **For plans**: every spec requirement maps to a proof command; the file

roles/researcher.md

@@ -14,11 +14,9 @@ Do:
    file:line citation in your report.
 1. Map the area: entry points, key files, data shapes (schemas/types/tables),
    callers and dependencies, side effects (IO, network, global state).
-1b. Before describing any new mechanism, look for the one that already
-   solves the same user-visible transition, across repository and tier
-   boundaries (a frontend flow counts). Do not narrow the search to the
-   mechanism named in your question: a question about "token reissue" still
-   reports an existing re-login or context-switch flow if one exists.
+1b. Look for an existing flow that already makes the same user-visible
+   change, across repository and tier boundaries. Do not limit the search to
+   the mechanism named in your question.
 2. Note important quirks that could affect the change: workarounds, TODOs,
    suspicious duplication, version constraints, and feature flags.
 3. Verify claims you were given ("the bug is in module Y", "the API does X"):

skills/1-intent/SKILL.md

@@ -40,13 +40,12 @@ in parallel, then start the interview:
 - **Affected area**: entry points, data shapes, callers, side effects of the
   code the request touches.
 - **Existing analogous flow**: before any option exists, find a flow the
-  product ALREADY runs that makes the same kind of user-visible transition
-  (switch context, re-authenticate, reload under another owner, change mode)
-  — in every repository and tier the request crosses, frontend included,
-  not only the service you expect to change. Match the request's own
-  behavior words against those flows ("log out and reload as …" names a
-  re-entry). Report each with its entry file:line and whether it works for
-  the roles in scope, or "none found" with the searches that were run.
+  product ALREADY runs for the same kind of user-visible change the request
+  describes — in every repository and tier the request crosses, not only the
+  service you expect to change. Search by the behavior the request names,
+  not by the mechanism you have in mind. Report each with its entry
+  file:line and whether it works for the roles in scope, or "none found"
+  with the searches that were run.
 - **Feasibility**: can the behavior run or be reproduced locally? Verify the
   available test infrastructure, development environments, tools, and access.
 - **Current browser behavior** for UI changes or hard bugs. When a browser
@@ -69,13 +68,9 @@ Record the command, toolchain, and resolved versions. If execution is
 unavailable, cite authoritative compatibility evidence and label the remaining
 uncertainty.
 
-**Reuse rule:** When an existing analogous flow was found, the options shown
-to the human include reusing it, with its evidence. Leaving it out needs a
-stated reason. A question framed as "where do we store X" or "which new
-mechanism" is a solution; restate it as the transition the user makes, then
-check that transition against the flows the probe found. Designs that change
-after approval because an existing flow surfaced late are the cost this rule
-prevents.
+**Reuse rule:** When the probe found an existing flow, the options shown to
+the human include reusing it, with its evidence, or say why it does not fit.
+Ask about the change the user sees before asking which mechanism to build.
 
 ## Grill protocol