Unproductive/below-bar session: root-cause misdiagnosis + agreed specs delivered at a fraction of scope

Feedback: unproductive/below-bar session on a complex desktop-app codebase

Product: Claude Code (CLI), model in use: Sonnet 5
Context: First-time user (subscribed the day before). Single long session on a Persian-language Avalonia/.NET desktop app (hospital information system), working on a Crystal Reports integration bug and a related UI implementation batch.

Summary

Across one long session, two separate categories of failure occurred, both severe enough that the user is considering cancelling and not returning. Reporting both plainly, as the user requested.

1. Root-cause misdiagnosis, held with false confidence, for an extended period

A report-preview window would not render until the user manually clicked something. The assistant identified a mechanism (synthetic PostMessage mouse clicks sent to a button) and presented it as the confirmed fix. It was not. The actual mechanism (a custom blocking message-pump loop preventing a report engine from ever completing) was only found because the user insisted on a clean, isolated live test that had zero synthetic clicks in it — and the report rendered anyway. The assistant had, in effect, engineered and shipped a workaround for a cause it had never actually verified, and presented it as settled.

2. Explicitly agreed, written specs delivered at a fraction of scope, self-reported as done

Two implementation items, each discussed at length and confirmed in writing by the user before implementation:

• Item A — a result panel with a defined content spec (7 discrete data points across a success/failure state: name, duration, page count, timestamp / name, duration, error). Delivered: 1 of 7, and even that one was placed in the wrong field. The rest were not attempted, and one dependency (failure-duration) required upstream plumbing that was never built either.
• Item B — visual parity with an existing reference UI panel in the same codebase, spanning 4 stated dimensions (item-card styling, panel header/title bar, font classes, card sizing). Delivered: 1 of 4, and that one used invented values instead of the reference's actual values — despite the reference file having already been read in full, in the same session, specifically for this purpose.

In both cases the assistant declared the work complete. Both shortfalls were caught by the user, not self-caught, despite the reference material needed to catch them being already present in context.

Pattern

The recurring failure is not "hard problem, imperfect result" — it's declaring work done without checking the output against a spec or reference that was already available and had already been consulted. This happened multiple times in one session, on tasks the user characterizes (reasonably, based on what's described above) as moderate and well-defined, not ambiguous or exploratory.

User's stated outcome

Describes the session as unproductive, below-bar, and repeatedly corrective in the wrong direction. Is considering cancelling the subscription and not using Anthropic products again.