Model behavior (Fable 5.1): design request answered bottom-up from existing code instead of from requirements

Preflight Checklist

• [x] I searched existing issues (label model) for similar reports and did not find a duplicate.
• [x] This report does not contain sensitive information (API keys, passwords, etc.).

Type of Behavior Issue

Other unexpected behavior — a design/requirements task was reasoned about bottom-up (from existing code) instead of top-down (from stated requirements).

What You Asked Claude to Do

The user asked for a design to fix a cold-start image-loading UX problem in a private Nuxt 4 web app's chat feature. The request included explicit outcome-level requirements: images should appear quickly when a user enters a chat, and the model should evaluate whether a lazy-loading mechanism already exists in the codebase and whether it actually helps with this problem.

What Claude Actually Did

1. Claude surveyed the existing implementation (image loading code, several call sites) and framed the design as a set of per-mechanism improvements to what was already there, rather than first deriving a target behavior from the requirements and then checking the code against it.
2. For the lazy-loading requirement, Claude answered "already exists (native loading=lazy)" — treating the mere existence of a mechanism as satisfying the requirement, without verifying it actually improved the user-visible outcome.
3. Only after the user pushed back did the actual critical-path cause surface: image URLs are only fetched after a slow session-bootstrap request completes, and no placeholders render in the meantime — so native lazy-loading has nothing to act on during the slow window, making the earlier "already exists" answer misleading in context.
4. Separately, a second, architecture-level diagnosis — that image-loading state was scattered across roughly 7 call sites and needed a single-owner unification (consistent with a prior refactor already present elsewhere in the same codebase) — also had to be supplied by the user, even though Claude had already read every relevant file and had the information needed to reach that conclusion itself.

Expected Behavior

For a design request, Claude should derive the target shape of the solution from the stated requirements first, and only then validate feasibility/fit against the existing code — not the reverse (surveying code first and packaging findings as the design). Additionally, the existence of a mechanism (e.g., loading=lazy) should never be presented as satisfying a stated requirement without checking whether it actually produces the required outcome in context.

Files Affected

None — this was a design/discussion task; no files were modified during the exchange described here.

Permission Mode

N/A — this was a planning/discussion turn, not a file-editing action.

Can You Reproduce This?

Haven't tried to reproduce (single observed instance in a real working session).

Claude Model

Other — model identifier reported by the session was claude-fable-5-1.

Relevant Conversation

User feedback quotes (translated from Chinese) after Claude's initial design pass:

"The problem is still that the signing request is too slow — right after entering a chat, the viewport doesn't even know there are images to load."

"Image loading today is like history loading before our state-machine unification: every call site implements its own version."

Impact

Low - Minor inconvenience (no data loss or unwanted file changes; the cost was an extra correction round before the design addressed the actual root cause).

Claude Code Version

2.1.259 (Claude Code)

Platform

Not specified in this report (default Claude Code CLI configuration).

Additional Context

• Environment: Claude Code CLI on macOS, model claude-fable-5-1, observed 2026-09-04.
• The codebase involved is a private Nuxt 4 web application; repository name, product name, domains, and file paths are intentionally omitted here.
• This same session was also submitted via the in-product /feedback channel, receipt 715b57d4-a741-4511-9624-6517fe284353, in case that helps correlate with other telemetry.