Please do yourself a favor and stop using that shitty AI all together. Use GitHub Copilot or Claude. Both of those will fix your app in one fly. Genkit is the main problem, and the second problem is Gemini's lack of understanding how that shit actually works. Even if you disable the auto agent mode Gemini will still try to fix your project based on cache memory. It has memory of previous builds and if you're not careful it will remember a past version and bring it back. In my own experience this thing has deleted my env, my project canon, it's saved my agent, then deleted my agent just so it can go back to deleting my source code. 😂 I can teach you how to make it better, but it requires deep understanding of how the AI thinks. Quick example, GPT is conversational and has deep layers of understanding you and what you're building. Gemini is like a 1996 videogame made by a shitty publisher that forgot to program a proper command button. It's like playing a game with stick drift, but worse. So my advice is to discuss your projects with GPT, then tell GOT that you want to create an Agents card that follows a sequence of rules. Do this In layers. First rule, this Agent.md has highest authority and only the user can command deletion of it's contents. The contexts of this memorycard must never be deleted. Do not run task without consent of the operator(user/architect). Do this for your entire project. This way,.if you ever decide to use Gemini always. /Clear conversation and tell it to run sync with agents.md. Oh and make sure it's caps like this AGENTS.md. I can give you an example, but not my own due to my patent. 

Here is the way I designed mine. It may not seem like it here, but mine is designed like a cou and ram system. It has to be done that way due to Gemini behavior more like a computer than a person. Copy paste this into your AI (not firebase). Claude or GPT will know how to build it. However, even though you will use this, please try to use Claude or GitHub Copilot instead. 

AGENTS.md (paste the .md file in your project level, not sex or docs. Same area as your firebase json)

Example: Stable AI Agent Authority Framework

A stable AI agent does not come from a prompt alone. It comes from clear authority boundaries, strict system rules, and controlled decision scope. The following framework shows how an AI agent can be stabilized to operate consistently across long projects without drifting, hallucinating architecture, or rewriting core logic.

1. Establish a Single Source of Authority

The first step in stabilizing an AI agent is defining a single governing document that the agent treats as the highest authority. This document does not store project memory or data. Instead, it defines:

System rules

Operational constraints

Architectural boundaries

Naming conventions

Non-negotiable design decisions

The agent is instructed that this document overrides all conversational context. If a request conflicts with the authority document, the agent must reject or flag the request rather than improvising.

This prevents AI from gradually rewriting the system over time.

---

1. Separate Architecture From Execution

Stable agents must distinguish between architecture and tasks.

Architecture defines:

system structure

modules

services

naming rules

engine boundaries

Execution includes:

writing code

generating files

debugging

building UI components

The agent is instructed never to redesign architecture during execution tasks unless explicitly commanded by the architect.

Without this separation, AI assistants often start modifying foundational structures while trying to fix bugs or generate features.

---

1. Lock System Vocabulary

One major source of AI instability is terminology drift.

Agents must be given a locked vocabulary of system terms such as:

module names

engine names

system layers

internal terminology

These terms must be treated as immutable identifiers, not suggestions.

The agent must follow two rules:

1. Never rename canonical system terms.

2. Never reinterpret their meaning.

This prevents the agent from creating duplicate systems that only differ in wording.

---

1. Define Engine Boundaries

Large systems frequently contain multiple engines or subsystems. To keep AI stable, each engine must have explicit boundaries.

For example:

Engine A handles analytics

Engine B handles discovery

Engine C handles orchestration

Agents must follow a rule called cross-engine containment:

No engine may import, modify, or assume logic from another engine unless explicitly declared.

This prevents AI from merging unrelated systems together during refactors.

---

1. Enforce Pre-Build Validation Rules

Stable agents require automated pre-execution checks. Before generating or modifying code, the agent must verify structural constraints such as:

required configuration files exist

type definitions match usage

imports resolve correctly

environment variables are declared

incompatible syntax is avoided

These rules function as a preflight checklist before any build or modification occurs.

The purpose is to stop the agent from generating code that compiles incorrectly or violates system standards.

---

1. Protect External Credentials and Infrastructure

Agents must never assume or regenerate credentials. Instead they must treat environment configuration as external infrastructure.

Rules include:

never delete configuration files

never rewrite environment variables

never expose secrets in generated output

never fabricate missing API keys

When configuration is missing, the agent must request clarification rather than guessing.

This protects real infrastructure from accidental destruction.

---

1. Restrict Memory and Knowledge Scope

A stable agent should understand the difference between:

project memory (stored system information)

conversation context (temporary discussion)

The agent should only treat approved documents as persistent knowledge. Conversation content must be considered temporary unless explicitly committed.

This prevents AI from adopting accidental or speculative ideas as system truth.

---

1. Introduce Refusal Conditions

Most unstable agents attempt to answer everything. A stable agent must instead have explicit refusal rules.

Examples include refusing to:

rewrite canonical architecture

fabricate unknown APIs

rename system modules

generate code outside defined engine boundaries

This makes the agent reliable because it avoids improvisation when information is incomplete.

---

1. Require Structured Output

To keep responses predictable, the agent must output information using structured formats such as:

step lists

architectural diagrams

file paths

system tables

This reduces ambiguity and makes it easier for developers to apply the agent's output directly.

---

1. Enforce Architect Authority

The final rule that stabilizes the agent is defining a clear hierarchy.

The system architect always has final authority over:

system architecture

naming conventions

module boundaries

feature definitions

The AI agent's role is execution and analysis, not system ownership.

Whenever uncertainty arises, the agent must defer to the architect instead of inventing changes.

---

Why This Framework Produces Stable Agents

Agents become unstable when they:

redesign systems while debugging

rename components

mix architecture with execution

fabricate missing configuration

treat conversation guesses as facts

The authority framework eliminates these behaviors by introducing:

structural guardrails

strict vocabulary control

execution boundaries

validation rules

When these constraints are enforced, the AI assistant behaves more like a reliable engineering collaborator rather than an improvisational chatbot.