git:20261019.b3a119b to git:20261024.d153cce

---

name: validate-the-users-proposed-mechanism

description: >

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.

---

# 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.

## When this fires

**Where:** A request arrives with the tool already chosen — "deploy this on

X", "switch to library Y", "move the queue to Z" — and the thing already built

may not fit it.

**The case this came from.** A user asked to deploy on a serverless platform.

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, so implementing the request verbatim would have thrown

away working, tested code. One grep for the incompatible construct surfaced

both conflicts before anything was committed to.

**Another shape it takes.** *(Illustrative: A user asks to put a CDN in front

of an API for speed. The endpoints are authenticated per-user and already

sub-50ms; the intent — cheaper read traffic — is met by a response cache

keyed on the user, while the CDN as named would serve one user's data to

another.)*

## 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

- [ ] You grepped the existing artifact for constructs the named mechanism

can't support.

- [ ] You separated the user's underlying intent from the specific mechanism

they named.

- [ ] Any real conflict was raised explicitly, with a feasible alternative

that serves the same intent.

- [ ] Any earlier user choice that later analysis contradicts was resurfaced as

a decision with the evidence — not silently implemented, nor silently

overridden.

If any box is unchecked, you may be building on an infeasible premise — check

the artifact against the mechanism first.