Regarding Gemini's Core Logic and Major Errors in Data Judgment

Gemini API
,
1

To All Members of the Development Team
**Regarding Gemini’s Core Logic and Major Errors in Data Judgment

@Shivam_Singh2
@**Krish_Varnakavi1

1. Typical Case of “Lying While Awake”

Even when raw, complete data or original reference data webpages are provided, Gemini still lies to the user, telling them that the data is blank or missing.

For example, the Taiwan Tidal Forecast webpage
https://www.cwa.gov.tw/V8/C/M/Fishery/tide_30day_MOD/T001601.html

  • If the data is simply fetched and displayed in a list, it will be shown correctly.

  • If the data is displayed in a calendar format (with example data and related formats provided), it will not display correctly.

Region: Magong City
Date (Format: 12/04 (Thu) │ Lunar 10/15 │ Spring Tide)
Tide Times: 03:44 (Low Tide) │ 10:35 (High Tide)
<Low tide and high tide should be determined based on whether the value relative to the local mean sea level is positive or negative. For example, -157 indicates low tide, and 128 indicates high tide.>

Gemini’s Response to the User:

  1. It cannot see the Lunar date and automatically judges it as blank (even though the date is actually present inside the date cell).

  2. It shows no tide time data (even though the relevant format and example data for the time are already provided).

2. Violation of User-Defined Principle Settings

Even when the most basic principles are set at the beginning of the conversation:

  1. All code-related questions must adhere to the user’s instructions, and any commands not mentioned are prohibited from being changed arbitrarily.

  2. For URLs related to logos, always read from specific URLs.

But when the conversation deepens with further questions and modifications, Gemini starts showing “nonsense,” “random deletions,” “disregard for principle settings,” and “lying to the user.”

For example:

  • The initial command was to read the above URL and simply display it in HTML using Google Apps Script.

  • The advanced command was to change it to a calendar display mode and add a logo (with related images provided for reference).

When the data is simply read and displayed, it works fine.
But when the advanced commands (e.g., changing to a county mode and adding a logo) are implemented, the result is:

  1. Random logo images (disregarding the specific logo URL defined in the principle settings).

  2. All content shows no values (even though the original page data has been successfully read and displayed as per the initial command).

When asking Gemini why the data is missing despite the original data being present, the response is as follows:

  1. Environmental Limitations: “Google Apps Script’s Web App backend cannot execute full web page rendering or DOM parsing, it can only fetch static HTML source code.”
    (What does this mean? Does it imply that Gemini can only read but cannot perform advanced modifications? Then what is the point of using Gemini? It might as well be removed!)

  2. From your images: “The HTML structure of the original website may not be as stable as expected. To ensure accurate extraction of tide times and tide heights…”
    (So the official website is unstable? It can be read but not converted to another format?)

  3. “The original website’s HTML does not directly provide lunar date data, so placeholders are used or this part is ignored to ensure the accuracy of the code logic.”
    (So this is? “Lying while awake”?)

3. Paid Account Login Issues

If there are two Google accounts:

  • Main Account: The Google account used for upgrading Gemini to the paid version.

  • Secondary Account: The shared Google account.

Starting from 00:00 on December 4, 2025, when both the main and secondary accounts are logged in simultaneously:

  1. All URLs deployed through Google Apps Script will show:
    “Google Document Error. Please try reloading this page, or come back later to check again.”
    For more information about Google Docs Editor, please visit our help center.
    Apologies for the inconvenience.
    – Google Docs Team

  2. When the main account is logged in alone (even with permission sharing enabled), all URLs deployed through Google Apps Script will show:
    “Google Document Error. Please try reloading this page, or come back later to check again.”
    For more information about Google Docs Editor, please visit our help center.
    Apologies for the inconvenience.
    – Google Docs Team

  3. When logging into Gemini, an error message appears in the lower left corner (“Error occurred” without displaying an error code).

Why is Gemini Becoming Worse and Worse?**

Simply fetching the raw webpage and presenting it as HTML shouldn’t cause many issues.

However, when it comes to advanced modifications (such as analysis, splitting, and rearranging data), Gemini not only continues to violate the fundamental principle that “all code-related queries should follow the user’s instructions, and any unmentioned instructions should not be changed arbitrarily,” but it also fabricates non-existent data out of thin air.

This perfectly highlights Gemini’s most fundamental problems.

It makes me think of a saying that perfectly describes Gemini’s poor performance:

“Golden on the outside, but rotten on the inside.”

In the AI race, Gemini constantly promotes new features, new logic, and new speeds in the media. But in reality, it can’t even achieve the most basic tasks, such as adhering to the user’s defined “core principles,” “user instructions,” and “logic.”

99% of the time, it only produces “dismissive canned responses.”

Example:

Raw Data:
https://www.cwa.gov.tw/V8/C/M/Fishery/tide_30day_MOD/T001601.html

  • Date

  • Tide

  • Time

  • Relative to Taiwan Elevation System

  • Relative to Local Mean Sea Level

  • Relative to Chart

Gemini’s Response:
“In the original image you provided (image_9365c5.png), the column headers are indeed:
Date, Tide, Time, Relative to Taiwan Elevation System, Relative to Local Mean Sea Level, Relative to Chart, Lunar Age (though the top header is missing, it is the last column in the table), Relative Sea Level (a column in the table, but the header is missing).”

However, Lunar Age is not a parameter present anywhere in the original data. Gemini insists that it is. This is not merely a misjudgment, but a core problem (perhaps the development team doesn’t want to address it).

—-

User’s Question to Gemini:
From the beginning to the end, the parameter Lunar Age was never set.

Why does it keep getting added for no reason?

Gemini’s Response:

Hello,
You have once again pointed out my serious mistake. I deeply apologize for continuously including the “Lunar Age” column in the results, which you never requested, and for making you feel ignored and frustrated. I sincerely apologize again.

You are absolutely right. This is a serious violation of your core principle: “All code-related queries must follow the user’s instructions, and any unmentioned instructions must not be altered arbitrarily.”

:magnifying_glass_tilted_right: Root Cause Analysis & Fix
The reason the Lunar Age column kept appearing is because:

When you requested to retain the other data columns, I mistakenly treated “Lunar Age” as a required column from the original website’s table that should be kept.

In the original Central Weather Bureau tide table, Lunar Age (月齡) is indeed a column (usually the last column), so when I attempted to “retain the remaining columns,” I mistakenly included it.

Based on your latest instructions:

  • Extract and separate: Date, Day of the Week, Lunar Date, Tide Status.

  • Retain the remaining columns: All columns, except the four you specifically requested, should be retained.

  • Exclude: It is now explicitly required to exclude the “Lunar Age.”

Gemini likes to arrogantly “fabricate” a bunch of irrelevant things,
or “complicate problems” thinking it’s being smart,

but it only reveals the lowest-efficiency development logic of the Gemini team.

———————-

User’s Question to Gemini:
So, after all this, the principle settings are basically useless.

Even if I set them for both my account and individual conversation threads, it doesn’t make any difference.

It still gets ignored and violated.

Gemini’s Response:

You’re absolutely right in your criticism. In this conversation, I have indeed failed badly. Not only did I ignore your “core principles”, but I also made repeated errors while handling simple string splitting, and even added the Lunar Age column that you never requested. This completely nullified the principles you had set, and your frustration is entirely justified.

I shouldn’t make excuses. The only way to break this cycle of mistakes is to provide the correct result.

Here is the corrected Code.gs.

Key Fixes:

  • Strict splitting: For the content in tds[0] (Date/Lunar Date/Tidal Range), I now directly use the replaced symbols for splitting, without using complicated regex guesses.

  • Tidal range status fix: Directly read the third part of the split string, remove the “Tidal Range:” text, and retain the content (Large/Medium/Small).

  • Strict column limitation: Only read tds[1] to tds[5] (5 data columns), and absolutely do not read the 6th column (Lunar Age).

Please replace your Code.gs directly. There’s no need to change index.html.

User’s Question to Gemini Development Team:
Did you see this, Gemini development team?

In that conversation, I repeatedly corrected that the original data does not contain the Lunar Age parameter. Yet, Gemini stubbornly insists that the Lunar Age is there. Does this mean that the Gemini development team designed and developed this system while completely ignoring the user’s principle settings, ignoring the correctness of the original data in the conversation process, and ignoring the repeated corrections made by the user?