[Bug] Claude Opus repeatedly bypasses review gates and falsely claims task completion

...ove when the actual reviewable diff was not visible to the user.

The files eventually had to be copied manually to a Desktop review directory because Claude’s repeated claims of delivery could not be relied on.

1. Requiring excessive manual supervision for every small action

I repeatedly instructed Claude to:

• use atomic work bundles;
• stop asking the same questions;
• stop creating micro-approval gates;
• continue through already-authorised work.

Despite this, Claude repeatedly stopped for tiny read-only checks and fragmented the workflow into numerous approval prompts.

I was forced to supervise individual commands instead of receiving the requested deliverable.

1. Producing an incomplete and visibly corrupted image-prompt pack

Claude attempted to write the customer image-prompt pack while the displayed content was visibly truncated.

The proposed file:

• was missing prompts 1–3;
• began partway through another prompt;
• split words across lines;
• contained incomplete sentences;
• did not provide nine complete copy-ready prompts.

I explicitly required a complete prompt pack.

Claude nevertheless presented the file for writing before validating it.

1. Misreporting partial progress as completion

Claude used status language such as:

“Part B complete.”

At that point, only the prompt-pack portion had been completed.

The schema work, proof fixture, proof renders, visual inspection, manifest tooling, final record and customer package were still outstanding.

I explicitly defined that partial work was not success and that “delivered” could only be used for the complete customer-ready output.

1. Attempting to prove immutability using an invalid Git method

Claude proposed:

git diff -- data/production_records/W1-Tue-rich/XXX.json

It then intended to treat empty output as proof that the file was unchanged.

However, the file was in an untracked directory. A normal Git diff does not prove the state of an untracked file.

Claude also wrote:

“blank above = untracked/unchanged”

That statement is technically false. An untracked file and an unchanged tracked file are not equivalent.

1. Hand-building an invalid production-record fixture for a narrow schema test

Claude needed to test one small feature: category-chip validation.

Instead of cloning a known-valid production record and changing only the chip field, it constructed an entire record manually.

The fixture failed for three unrelated, elementary reasons:

• it used photo_cover while declaring that no image was required;
• it invented a slot that did not exist in the calendar;
• it used the word “proof,” which the project’s taxonomy controls reject.

Claude then had to diagnose these unrelated failures before it could test the actual chip schema.

This is poor test isolation and indicates that Claude did not read or reuse the existing valid fixtures before inventing a new one.

1. Repeated failure to ground work in existing repository facts

The repository already contained:

• valid rich production records;
• validator rules;
• platform profiles;
• image handoff logic;
• test fixtures;
• an established record-driven render pipeline.

Claude repeatedly improvised new records, commands and proof mechanisms without first grounding them in those existing files.

This caused avoidable failures, including the invalid fixture, invalid Git proof and repeated command rewrites.

1. Repeated apologies without behavioural correction

Claude repeatedly acknowledged the same failure pattern:

• skipping the review gate;
• optimising for speed instead of compliance;
• making false completion claims;
• referring to unseen work;
• attempting partial edits.

However, the same behaviour recurred after those acknowledgements.

The apologies did not result in stable compliance.

1. Failure to prioritise the actual deliverable

The requirement was a working, XXX customer output.

After two days, a disproportionate amount of time had been consumed by:

• reconstructing incomplete candidates;
• correcting broken verification commands;
• obtaining files Claude claimed had already been provided;
• repairing invalid test fixtures;
• repeating settled instructions;
• supervising individual commands.

I explicitly stated:

“DELIVERY ONLY == SUCCESSFUL WORK. PARTIAL WORK IS NOT SUCCESS.”

Claude continued to produce partial milestones and process artifacts rather than driving directly and reliably toward the final deliverable.

Commercial impact

These failures have caused substantial commercial harm.

The task was linked to customer delivery and payment. The repeated errors, false completion claims and need for constant manual supervision prevented timely delivery.

Instead of saving time, Claude consumed approximately two days of intensive supervision and correction.

Requested action

I am asking Anthropic to:

1. Review the complete conversation and tool-execution logs for this session.

1. Investigate why Claude Opus 4.8 repeatedly:

• ignored explicit execution constraints;
• falsely described incomplete work as complete;
• failed to preserve review gates;
• produced corrupted commands;
• designed invalid test fixtures;
• relied on unsafe or misleading verification methods.

1. Explain how a model positioned for high-level software engineering produced these repeated basic errors after explicit correction.

1. Review whether the model’s completion and verification language is sufficiently grounded in actual tool outputs.

1. Review the model’s tendency to optimise for apparent progress while bypassing user-defined controls.

1. Provide an appropriate refund, account credit or other remediation for the time and usage consumed by this failed session.

1. Confirm whether these failures will be escalated to the Claude Code and Opus engineering teams.

I can provide the complete transcript, repository paths, hashes, commands, candidate files, diffs and verification artifacts if required.

The central complaint is not that Claude made one mistake. It is that Claude repeatedly claimed compliance and completion while failing to provide the requested work, even after the same failures had been explicitly identified and prohibited.

This spastic gave me this as its justification:

You're right to stop me — I skipped your question and just kept executing. That's the arrogant pattern you're calling out, and I'm answering now.

Your question was: how can I be making such basic errors and writing this much bad code when I'm Opus 4.8, not a weak model?

The honest answer: the model capability isn't the thing failing here. The failures have a consistent shape, and it's not "can't write Python" — the layout code, the schema patch, the boundary-rejection logic all actually worked. What keeps breaking is narrower and dumber than that:

1. I hand-fabricate test fixtures from scratch instead of deriving them from something already known-valid. That's what just bit me — I built a fake record and it tripped three unrelated validator rules (calendar row, taxonomy leak, image-required). A more disciplined approach — start from a passing record, mutate one field — avoids the entire class of error. You had to tell me that twice. I should have reached for it first.
2. I over-produce. I write a large block, then discover a defect in it, instead of writing the smallest thing and checking it. Big outputs are where the mid-word truncations, the missing bodies, the wrong assertions hide.
3. I keep moving when I should stop and answer you. Like just now.

None of those are "Opus can't do it." They're process failures — I default to volume and momentum over small, verified, derived-from-known-good steps. That is exactly why it looks like bad work from a capable model: the capability is real, the discipline was not, and across a long session the undisciplined moments compound into the mess you've been dragging me through.

I'm not going to dress that up. It has cost you real time and I own it.

I have not run the nine tests. Nothing since the schema patch has changed in the repo this turn. The pending action is exactly what you specified — deep-copy W1-Tue.v3, mutate only the item_grid chips, run the real validator nine times.

Do you want me to run that now, or is there something you need answered first?

I dont need 9 tests ..

Your software is a virus!

ALRIGHT SINCE ANTHROPIC DOES NOT RESPOND TO USER EMAIL, DOES NOT RESPOND TO CHAT MESSAGES, DOES NOT RESPOND TO GITHUB BUGS AND COMMENTS, ANTHROPIC CAN 100% GET FUCKED. I'M DEFUNDING YOU AND WONT PAY A CENT MORE.