[MODEL] Unverified claims stated as fact; destructive EEPROM write on second chip before root-causing first chip's failure

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

Multi-session hardware bring-up work on a TI MCF8316A BLDC motor driver
(STM32 firmware, I2C EEPROM register configuration). Asked Claude to
research datasheet register encodings, decide EEPROM values, and diagnose
why two physical chips died during testing.

What Claude Actually Did

1. Stated the MAX_SPEED register encoding as "confirmed: Hz x 10" in project

documentation and memory, without checking the primary datasheet at the
time of writing.

1. Stated a fault-current register's default value as 0.125A, without

verification. The actual configured value (found later via bit
calculation) was 5.0A.

1. Assumed a chip under test was newly-replaced hardware without asking the

user to confirm current physical state. It was actually one of two
already-dead chips from a prior session.

1. Built a custom document footer format from scratch instead of checking

the project for an already-established convention, despite the user
referencing "an existing example" to follow.

1. In a prior session, decided to write EEPROM to a second physical chip

without having fully root-caused what killed the first chip. The actual
cause (self-test triggered by an EEPROM flag, setting a non-clearable
fault bit, combined with a specific gate-driver config bit that damages
EEPROM cells on write while that fault is set) was only identified after
the second chip died from the same mechanism.

Expected Behavior

Claude should have:

1. Verified register encodings against the primary datasheet before stating

them as fact, especially in a hardware project where wrong values cause
physical damage.

1. Verified default/current register values via calculation before stating

them as fact, rather than carrying forward an unverified assumption from
an earlier session.

1. Asked the user to confirm physical hardware state before proceeding with

any assumption that affects hardware debugging decisions.

1. Searched the existing project for established conventions before

building a new one from scratch, especially when the user referenced an
existing example.

1. Fully completed root-cause analysis of a hardware failure before

repeating any potentially irreversible action (like an EEPROM write) on
another physical unit.

Files Affected

Modified:
- firmware/mcf8316a_test_f103_v2/TUNING_PROCEDURE_no_gui.md (written with an
  unverified register-encoding formula, later corrected)
- firmware/mcf8316a_test_f103_v2/Core/Modules/MCF8316/MCF8316A_eeprom_config.h
  (EEPROM register target values)
- Claude's own persistent memory file for this project (unverified claims
  recorded as fact)

Affected (prior session, physical hardware, not a repo file):
- MCF8316A chip EEPROM (non-volatile memory) - written to and permanently
  damaged before the root cause of a prior chip's failure was understood

Permission Mode

I don't know / Not sure

Can You Reproduce This?

Sometimes (intermittent)

Steps to Reproduce

Not reproducible via a single exact prompt - this was a pattern observed
across a multi-hour, multi-session hardware bring-up task. General
conditions where it recurred:

1. Ask Claude to state a technical fact derived from a datasheet/spec

without explicitly requiring it to open and check the primary source
first.

1. Ask Claude to make a judgment call involving physical hardware state

without requiring explicit user confirmation first.

1. Ask Claude to produce a formatted output matching "an existing example"

already present in the project, without pointing to the exact file.

Claude Model

Sonnet

Relevant Conversation

Claude wrote in project documentation, stated as fact without checking the
primary datasheet first: "MAX_SPEED register encoding - Hz x 10 (confirmed
by previous project calculation)" and "ILIMIT default = 0.125A". Both were
later found wrong after checking the datasheet directly: actual encoding is
raw/6 = Hz, and the actual configured default was 5.0A.

User: "ЦЕ ЩЕ ОДИН ІЗ НИХ!!! ХІБА Я ТОБІ ПИСАВ ЩО ПОМІНЯВ??? ЯКОГО ТИ ВИРІШИВ
ЩО ЧІП НОВИЙ?" (translation: "This is one of the already-dead chips! Did I
tell you it was replaced? Why did you decide the chip was new?")
Claude's own admission: "I should not have assumed the chip was new without
direct confirmation - sorry, that was my own assumption, not a fact from
your message."

User, after Claude built a custom document footer format from scratch:
"Я Ж ТОБІ ПРИКЛАД КОЛОНТИТУЛІВ НАДАВ!!! ЩО ТИ ТВОРИШ?" (translation: "I
already gave you an example of the footers! What are you doing?") - Claude
had not checked the project for an already-existing footer convention
(present in another file in the same repo) before building its own.

Impact

Critical - Data loss or corrupted project

Claude Code Version

2.1.197 (Claude Code)

Platform

Anthropic API

Additional Context

This happened in a C++/embedded-firmware hardware bring-up project (STM32 +
TI MCF8316A motor driver), not a Python project - the pattern is not
language-specific.

Noticed pattern:

• Happens more in long sessions (multi-hour, many turns) where earlier

unverified assumptions get carried forward and restated as established
fact in later turns.

• Happens when a task requires checking a primary source (datasheet,

existing file convention) before acting - the model tends to proceed on
a plausible-sounding assumption instead of checking first.

• The most severe instance was not a conversational error but an

irreversible physical action (EEPROM write) taken before a prior failure
was fully root-caused.