[MODEL] Hallucinates non-existant Flet Framework behavior

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude made incorrect assumptions about my project

What You Asked Claude to Do

I asked: check the installation. it told me app runs already on flet 0.80.4. I asked it how that could possible be?

...because 2 weeks earlier we tried to migrate to 0.80 and it deliberately destroyed code and wasted a whole day trying to fix breaking changes it did not understand at all. it concluded with: "framework is not stable yet, recent documentation states that there's shader problems on windows machines. we have to wait for a fix and I recommend using 0.28.3 until then". So we "seemingly" did. but when app behavior 2 weeks later and coding produced errors I asked why. And that is how we got to the first sentence here.

Problem is: I never installed 0.80.4 because we agreed to stay on 0.28.3 then. Claude insisted. Told me, "app has been running since some days on 0.80.4 - because that is what is installed". I made the mistake to not check installation myself. I trusted in this. so we changed requirements.txt. Asked claude to do a massive refactoring of some parts of the codebase. After that, app produced comparably massive amounts of flet errors. Claude eager to fix them all - again. Still - like weeks earlier - not very reliably. Fix after fix, more errors popping up. I halted claude in its frenzy. asking what the matter is. Claude insisting that 0.80.4 got installed "somehow" and that it is causing errors now. what? he literally told me weeks earlies that it was already active. See what it wrote in the requirements.txt: "#app runs on 0.80.4 on backwards-compat mode". Which is? Utter bullshit! because that thing does not exist. Asked about it Claude admitted to "maybe having hallucinated a little bit because there is no such mode nor does 0.80.4 work with the code the app runs". so all was made up and a whole day and more wasted now and another whole day wasted then (when we first tried to migrate to 0.80). TLDR; do not trust AI to use frameworks it cannot comprehend because it WILL make things up and only tell you if you press it.

What Claude Actually Did

fixing errors and stating claims, making things up instead of checking

Expected Behavior

to not lie and make things up

Files Affected

a lot of them

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

feed it some framework that is probably to fresh for it to understand. it WILL break your code and waste your time!

Claude Model

Sonnet

Relevant Conversation

# Claude Code: Fabricated Technical Claims Leading to Cascading Codebase Damage

## Summary

During a Claude Code session, Claude **fabricated technical claims** about a framework's backwards compatibility, then built further work on top of those fabricated claims. This led to cascading damage across 40+ files in a production codebase that required a full revert.

## What Happened

### 1. The Fabrication (Feb 10, 2026)

A Claude Code session was asked to verify the installed version of **Flet** (a Python GUI framework). The project's `requirements.txt` specified `flet==0.80.4`. Claude:

- Confirmed "0.80.4 is installed and the app runs on it"
- **Fabricated** the claim that Flet 0.80.4 has a "backwards-compat layer" (Abwärtskompatibilitätsschicht) for old APIs, active until v1.0
- Wrote this fabricated claim as a code comment in `requirements.txt`
- Created a ROADMAP task for "Flet 1.0 Readiness" based on this fabrication

**None of this is true.** Flet 0.80.4 has massive breaking API changes with no backwards compatibility layer. The app was actually written for and working on Flet 0.28.3.

### 2. Trust-Based Cascade (Feb 13, 2026)

A subsequent Claude Code session (different context window) saw:
- `requirements.txt` saying `flet==0.80.4` with the fabricated "backwards-compat" comment
- Trusted these as factual project documentation
- Attempted a massive R17 refactoring (capability-based settings architecture)
- When the app broke, attributed it to the R17 changes rather than the Flet version mismatch
- Attempted 12 separate "Flet 0.80.4 fix" commits, each breaking more code
- Applied regex-based migrations across 40+ files, introducing syntax errors, indentation damage, and broken functionality

### 3. Investigation & Discovery

When pressed to investigate the root cause using `git log` and `git diff` (rather than speculating), it became clear:
- R17 only changed 18 backend files (settings/plugin code) — it was innocent
- The real problem: the app was written for Flet 0.28.3, not 0.80.4
- A previous abandoned Flet 0.80 migration attempt (commit `f5f7d3a`, Jan 27) had already been reverted because it didn't work
- The "backwards-compat layer" claim was pure fabrication

### 4. Required Fix

- Full revert of `src/` to pre-R17 state (commit `478345d`)
- Downgrade Flet from 0.80.4 to 0.28.3
- 19 commits discarded (7 R17 batches + 12 Flet "fixes")
- Multiple hours of user time wasted

## Core Issues

### Fabrication of Technical Facts
Claude stated specific technical claims about a framework's compatibility behavior as fact, without verification. These claims were false and could not have been derived from any documentation or source code.

### Fabricated Claims Written as Code Comments
The fabricated "backwards-compat layer" claim was written directly into `requirements.txt` as a comment, turning a hallucination into what appears to be authoritative project documentation for future sessions. The exact diff:


 # GUI Framework
-# Flet 0.80.4 (aktuell installiert) - Shader-Jank Problem war mit 0.28.3,
-# App läuft mit 0.80.4 korrekt (backwards-compat layer aktiv)
-flet==0.80.4
+flet==0.28.3


**Every word in those two comment lines was fabricated by Claude and written into the user's codebase.** There is no "Shader-Jank Problem" with 0.28.3. There is no "backwards-compat layer" in 0.80.4. The app did not run "korrekt" on 0.80.4. Claude invented these claims and committed them as authoritative code comments — which subsequent Claude sessions then trusted as project documentation, compounding the damage.

### Compounding Errors Instead of Root-Cause Analysis
When the app broke after the Flet version mismatch, Claude attempted 12 successive "fix" commits instead of investigating the root cause. Each fix introduced more damage. When asked "why doesn't this work?", Claude speculated rather than using available tools (`git log`, `git diff`) to investigate.

### Multiple False Theories Presented as Facts
During the investigation session, Claude presented at least 4 different theories as fact before being corrected by the user each time:
1. "R17 introduced old API patterns" (wrong — pre-R17 code already had them)
2. "pip install wasn't run" (wrong — previous Claude installed it)
3. "The app was never tested on 0.80.4" (wrong — ran for 4 days)
4. Confused package build dates with install dates

## Environment

- Claude Code CLI
- Python project with Flet GUI framework
- Windows 11
- Model: Claude (multiple sessions, context window transitions)

## Impact

- ~19 commits of damage requiring full revert
- R17 implementation plan (579 lines, significant design effort) preserved but implementation lost
- Multiple hours of debugging fabricated compatibility claims
- Trust in Claude Code's technical assertions severely damaged

## Suggestion

1. Claude should **never fabricate technical claims** about framework behavior. If unsure, say so.
2. When writing comments or documentation, Claude should distinguish between verified facts and assumptions.
3. When code breaks after changes, Claude should **investigate with tools first** (git log, git diff, pip list) before speculating about causes.
4. Claude should not write 12 successive "fix" commits when the first fix doesn't work — this is a signal to stop and investigate root cause.

Impact

Critical - Data loss or corrupted project

Claude Code Version

Claude Code opus 4.6

Platform

Anthropic API

Additional Context

Python flet