From 4d93f38b694d062f744aa2da6e1b27badcbe308b Mon Sep 17 00:00:00 2001 From: "sungkuk.chae-at-471112812288" <76669236+cskwork@users.noreply.github.com> Date: Mon, 28 Sep 2026 17:09:30 +0900 Subject: [PATCH] fix: narrow the reuse rule to what is not specific to one feature (v0.18.1) Keep the analogous-flow probe and the reuse option. Drop the example transitions, shorten the rule, and make the adversary block only when a researcher reported a concrete existing flow that the options omit without a reason. --- VERSION | 2 +- log/changelog-v0.18.0.md | 8 +------- log/changelog-v0.18.1.md | 15 +++++++++++++++ roles/adversary.md | 8 ++++---- roles/researcher.md | 8 +++----- skills/1-intent/SKILL.md | 23 +++++++++-------------- 6 files changed, 33 insertions(+), 31 deletions(-) create mode 100644 log/changelog-v0.18.1.md diff --git a/VERSION b/VERSION index a86d3df..f3a5a57 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -v0.18.0 +v0.18.1 diff --git a/log/changelog-v0.18.0.md b/log/changelog-v0.18.0.md index b4dd94f..8478c60 100644 --- a/log/changelog-v0.18.0.md +++ b/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 diff --git a/log/changelog-v0.18.1.md b/log/changelog-v0.18.1.md new file mode 100644 index 0000000..66622f9 --- /dev/null +++ b/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. diff --git a/roles/adversary.md b/roles/adversary.md index 7368805..8f43f3c 100644 --- a/roles/adversary.md +++ b/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 diff --git a/roles/researcher.md b/roles/researcher.md index 86f3a15..bb23638 100644 --- a/roles/researcher.md +++ b/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"): diff --git a/skills/1-intent/SKILL.md b/skills/1-intent/SKILL.md index e126423..cbad08f 100644 --- a/skills/1-intent/SKILL.md +++ b/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