[Fable] Claude presents implementation conclusions without direct source inspectio

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 ignored my instructions or configuration

What You Asked Claude to Do

I instructed Claude Code Desktop to verify source-specific conclusions against the actual project files before answering, and not to rely on memory, previous summaries, assumptions, or second-hand descriptions.

The project workflow explicitly requires source inspection before making claims about the implementation.

I asked Claude to determine whether there was drift between the documented architecture and the actual code, and to support that conclusion with evidence from the relevant project files.

What Claude Actually Did

1. Claude explicitly acknowledged that its original implementation conclusions were based on second-hand reports rather than direct source inspection.
2. Claude answered questions about the implementation without first reading the relevant project files.
3. It presented conclusions in a source-grounded manner even though no corresponding file-read operation had occurred.
4. When challenged, Claude acknowledged that it had been reasoning from existing conversation context/memory rather than from a fresh source read.
5. It also acknowledged that adding another workflow document would not solve the problem, because a document has no enforcement effect if Claude does not actually perform the read operation.
6. Only after being explicitly challenged did Claude read the relevant source file and produce conclusions tied to actual implementation details.

Expected Behavior

When an answer depends on the contents of project files, Claude should read the relevant files before presenting the conclusion as source-verified.

If the relevant source has not been read, Claude should clearly state that the conclusion is based on prior context or assumptions and should not present it as verified against the code.

Explicit project instructions requiring source verification should therefore result in an observable source-read action before source-specific conclusions are made.

Files Affected

Relevant files in this incident:

[PROJECT_INSTRUCTIONS].md — contained the governing project/workflow instructions Claude was expected to follow.

[PRIMARY_IMPLEMENTATION_FILE].py — primary implementation file Claude made source-specific conclusions about before reading it.

[DATABASE_LAYER].py — relevant to the documented architecture; it was read only after the source-verification failure was challenged.

[ARCHITECTURE_RULES].md — contained the architecture requirement relevant to the conclusion, but was not directly read before that conclusion.

The issue is primarily that Claude presented source-specific conclusions before the relevant source files had been read, rather than that these files were modified incorrectly.
Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Recurring across different prompts, tasks, and sessions; not claimed to be deterministic with one identical prompt.

Steps to Reproduce
Open an existing project in Claude Code Desktop containing persistent project instructions, architecture documentation, and implementation source files.
Have an ongoing conversation in which Claude has accumulated prior summaries and second-hand information about the project.
Ask Claude to assess whether the actual implementation complies with the documented architecture, including whether there is architectural drift.
Observe that Claude can provide implementation-specific conclusions without first performing visible file-read operations on the source files required to substantiate those conclusions.
Challenge Claude explicitly on whether it actually read the relevant source files before reaching those conclusions.
In my observed case, Claude acknowledged that its knowledge of the implementation had come from second-hand reports rather than direct source inspection.
Explicitly require Claude to read the relevant implementation source file.
After the file is actually read, Claude is able to provide concrete source-level evidence that had not been established before the read.

The reported issue is the ability to present implementation-level conclusions as source-grounded before the supporting source has actually been inspected.

Claude Model

Other — Fable 5 / Opus

Relevant Conversation
When challenged on whether it had actually inspected the source before making implementation-level conclusions, Claude explicitly acknowledged:

“Alles wat ik vandaag over de code-realiteit ‘wist’, kwam via CC’s rapporten — tweedehands.”

English translation:

“Everything I ‘knew’ today about the reality of the code came through CC’s reports — second-hand.”

Claude further acknowledged that it does not automatically read project files before answering and that, without an explicit read action, it may answer from existing context or memory.

After I explicitly required Claude to read the relevant implementation source file, a visible file-read operation occurred and Claude was then able to provide concrete implementation-level findings from the actual source.

This is the core reliability issue being reported: the distinction between a conclusion derived from prior/second-hand context and one verified against the actual source was not made clear until I challenged Claude about the missing source inspection.
Impact

High - Significant unwanted changes

Claude Code Version

Claude 1.40609.0 (f65e38) 2026-08-27T16:19:51.000Z

Platform

Anthropic API

Additional Context

This is not an isolated incident and it is not limited to this specific prompt.

I have experienced this failure pattern repeatedly across different Claude Code tasks and sessions over a period of months.

The recurring pattern is:

Project instructions or relevant source files are not inspected before Claude reaches a conclusion.
Claude nevertheless gives a confident, implementation-specific answer.
When I challenge the answer and ask Claude to verify the source, it can continue defending the original conclusion for multiple turns.
In several cases, only after I provide external evidence — for example a screenshot showing that a relevant integration or tool is in fact working — does Claude acknowledge that its previous conclusion was incorrect.
Claude then apologises and corrects the answer, but by that point substantial time and tokens have already been consumed.

The specific source-inspection incident documented in this issue is a particularly clear example because Claude explicitly acknowledged that its earlier conclusions about the code had been based on second-hand information rather than direct inspection of the source.

The practical consequence is severe: I cannot safely rely on implementation-level statements without manually checking whether Claude actually inspected the relevant source or tool state.

I have spent weeks of development effort dealing with this type of re-verification and rework. I use the highest-cost model available for this work and have also incurred substantial additional usage charges. A significant amount of that usage is consumed by repeatedly challenging conclusions, requesting verification, and correcting claims that should have been source-checked before they were presented.

This defeats a core reason for using an agentic coding tool: the user should not have to independently audit whether the agent inspected the evidence underlying each confident technical conclusion.

Impact clarification: No project data was lost or corrupted. I selected “High” because this recurring behaviour materially affects the reliability of development work, causes substantial re-verification and rework, and creates avoidable usage cost.

The reliability requirement I need is:

No source-specific or tool-state-specific conclusion should be presented as verified unless Claude has actually inspected the relevant source/tool state, or explicitly discloses that it has not done so.

Attached evidence is a sanitised conversation transcript showing Claude's explicit acknowledgement that its earlier implementation conclusions were based on second-hand reports rather than direct source inspection, followed by the subsequent source read and materially more specific findings.