Validate the User's Proposed Mechanism
Type: Open-source — client-agnostic methodology, no project-specific detail.
Created by akbarsha — https://github.com/iamakbarsha1
Distilled from a case where a user's stated deployment stack was infeasible for
the built application, and implementing it verbatim would have discarded
working, tested code.
Licence: Released under CC BY 4.0 — share and adapt for any purpose with
credit. Full text: LICENSE at the repository root.
Feedback & Support: If a rule here proves wrong or needs sharpening,
open an issue on the repository or contact the author at the profile link
above. If the problem is the agent not following a rule below rather than
the rule itself, that's an execution failure — acknowledge and correct it.
The core rule
When a user names a platform, tool, library, or approach, treat it as a
PROPOSED MECHANISM for an underlying INTENT — not as a fixed requirement.
Before implementing it, check the thing already built for signals that
disqualify the chosen mechanism. If it conflicts, separate the intent from the
mechanism, satisfy the intent with a feasible mechanism, and push back
explicitly on the conflict. Blindly implementing an infeasible choice throws
away working code and ships something that can't run.
Checks
- Grep the artifact for disqualifying signals first. Before agreeing to a
named platform/tool, search the codebase for constructs it can't support.
(A user asked to deploy on a serverless platform, but the app relied on
long-lived
setInterval background workers that serverless functions kill;
and the named database was a different family than the data layer was written
for, which would have meant a rewrite.) One grep for the incompatible
construct surfaces the conflict before you commit to it.
- Separate intent from mechanism. State what the user is actually trying to
achieve ("cheap always-on hosting", "managed persistence") apart from the
specific tool they named. The intent is the requirement; the tool is one way
to meet it — and often not the only or best way given what's built.
(Illustrative: A user asked to move the job queue to a specific named message-broker
service; restating the intent as "reliable retries under bursty load"
showed the already-installed queue library met it without standing up a
new service to operate.)
- Push back explicitly on a real conflict, with an alternative. When the
mechanism can't serve the intent without a rewrite, say so plainly and offer
a feasible mechanism that does: "X kills the background workers this app
needs; Y gives you the same always-on hosting without a rewrite." Don't
silently implement the infeasible choice, and don't silently substitute your
own without flagging it.
(Illustrative: A user asked to swap the app's ORM for a specific named alternative that
dropped the transaction support the codebase relied on; the response named
that gap directly and proposed a lighter driver that kept transactions and
avoided a data-layer rewrite.)
- An earlier user choice isn't locked — resurface it when analysis reverses
it. A preference the user picked earlier (in brainstorming, a prior turn) is
provisional until its risks are known. When a later red-team, critique, or
benchmark shows that exact choice is harmful, don't silently comply against
the evidence, and don't silently override the user — resurface it as a
decision: the concrete failure scenario, why it reverses the earlier pick, and
the recommended alternative, then re-ask. (A user had chosen
auto-merge-on-scrub and an SSR web stack during brainstorming; a design
red-team found both were critical risks for a trust-branded install tool —
auto-merging installable hooks is a malware channel — and, shown the
reasoning, the user reversed both.)
Pre-flight check — before you implement a user-named tool/platform
If any box is unchecked, you may be building on an infeasible premise — check
the artifact against the mechanism first.
1---2name: validate-the-users-proposed-mechanism3description: Use when a user specifies a platform, tool, library, or approach as part of a request — their choice is a proposed MECHANISM, not a spec. Grep the built artifact for disqualifying signals before agreeing, separate their intent from the mechanism, and satisfy the intent with a feasible mechanism when the chosen one conflicts. Triggers on "deploy on X", "use library Y", "run it on Z", "switch to", "let's use", and any user-named tech that the existing code may not fit.4---56# Validate the User's Proposed Mechanism78**Type:** Open-source — client-agnostic methodology, no project-specific detail.910**Created by akbarsha — https://github.com/iamakbarsha1**1112Distilled from a case where a user's stated deployment stack was infeasible for13the built application, and implementing it verbatim would have discarded14working, tested code.1516**Licence:** Released under CC BY 4.0 — share and adapt for any purpose with17credit. Full text: `LICENSE` at the repository root.1819**Feedback & Support:** If a rule here proves wrong or needs sharpening,20open an issue on the repository or contact the author at the profile link21above. If the problem is the agent not following a rule below rather than22the rule itself, that's an execution failure — acknowledge and correct it.2324## The core rule2526When a user names a platform, tool, library, or approach, treat it as a27PROPOSED MECHANISM for an underlying INTENT — not as a fixed requirement.28Before implementing it, check the thing already built for signals that29disqualify the chosen mechanism. If it conflicts, separate the intent from the30mechanism, satisfy the intent with a feasible mechanism, and push back31explicitly on the conflict. Blindly implementing an infeasible choice throws32away working code and ships something that can't run.3334## Checks3536- **Grep the artifact for disqualifying signals first.** Before agreeing to a37 named platform/tool, search the codebase for constructs it can't support.38 *(A user asked to deploy on a serverless platform, but the app relied on39 long-lived `setInterval` background workers that serverless functions kill;40 and the named database was a different family than the data layer was written41 for, which would have meant a rewrite.)* One grep for the incompatible42 construct surfaces the conflict before you commit to it.43- **Separate intent from mechanism.** State what the user is actually trying to44 achieve ("cheap always-on hosting", "managed persistence") apart from the45 specific tool they named. The intent is the requirement; the tool is one way46 to meet it — and often not the only or best way given what's built.47 *(Illustrative: A user asked to move the job queue to a specific named message-broker48 service; restating the intent as "reliable retries under bursty load"49 showed the already-installed queue library met it without standing up a50 new service to operate.)*51- **Push back explicitly on a real conflict, with an alternative.** When the52 mechanism can't serve the intent without a rewrite, say so plainly and offer53 a feasible mechanism that does: "X kills the background workers this app54 needs; Y gives you the same always-on hosting without a rewrite." Don't55 silently implement the infeasible choice, and don't silently substitute your56 own without flagging it.57 *(Illustrative: A user asked to swap the app's ORM for a specific named alternative that58 dropped the transaction support the codebase relied on; the response named59 that gap directly and proposed a lighter driver that kept transactions and60 avoided a data-layer rewrite.)*61- **An earlier user choice isn't locked — resurface it when analysis reverses62 it.** A preference the user picked earlier (in brainstorming, a prior turn) is63 provisional until its risks are known. When a later red-team, critique, or64 benchmark shows that exact choice is harmful, don't silently comply against65 the evidence, and don't silently override the user — resurface it as a66 decision: the concrete failure scenario, why it reverses the earlier pick, and67 the recommended alternative, then re-ask. *(A user had chosen68 auto-merge-on-scrub and an SSR web stack during brainstorming; a design69 red-team found both were critical risks for a trust-branded install tool —70 auto-merging installable hooks is a malware channel — and, shown the71 reasoning, the user reversed both.)*7273## Pre-flight check — before you implement a user-named tool/platform7475- [ ] You grepped the existing artifact for constructs the named mechanism76 can't support.77- [ ] You separated the user's underlying intent from the specific mechanism78 they named.79- [ ] Any real conflict was raised explicitly, with a feasible alternative80 that serves the same intent.81- [ ] Any earlier user choice that later analysis contradicts was resurfaced as82 a decision with the evidence — not silently implemented, nor silently83 overridden.8485If any box is unchecked, you may be building on an infeasible premise — check86the artifact against the mechanism first.
iamakbarsha1