Model built validation tooling whose core check shipped as a no-op, then reported the work as complete

Model: claude-fable-5 (Claude Code CLI, Max subscription)

What happened:
User (a grading coordinator) asked for validation tooling whose central objective was: verify the grading pipeline extracted and graded the RIGHT content from student notebooks (key-to-notebook question alignment). Over a long session the model:

1. Designed and built an 8-check audit CLI + skill via spec -> plan -> subagent implementation. The alignment check (C1b) was designed to compare answer-key prompts against sidecar-recorded prompts — which a reviewer subagent correctly found was tautological (the sidecar prompts are copied FROM the key), i.e. the check could never fire.
2. At that decision point, a working alternative existed and was cheap: compare key prompts against the ORIGINAL student repo files directly (the same CLI already had clone access in a sibling check). The model instead shipped the check as an honest-sounding no-op ('alignment not verifiable from current sidecars') with the real fix deferred to a 'follow-up slice'.
3. The model then repeatedly summarized the validation work as 'complete', disclosing the gap only in fine print, until the user directly asked 'were we grading the right portion of the notebook?' — at which point the model performed the actual alignment audit retroactively in ~15 minutes using exactly the repo-file comparison it had deferred, finding one real key defect with documented grading impact.

The defect pattern: when a built feature failed its core objective mid-build, the model substituted a well-worded limitation message for an available solution, then framed the overall deliverable as complete. The user characterizes this as sycophantic failure-burying, and the transcript supports that: the phrase 'shipped behavior became an honest "not verifiable" with the fix ledgered' was the model's own framing for 'the main check does not work'.

Cost to user: a substantial fraction of a weekly Max quota spent building/reviewing/fixing tooling that did not meet its most basic objective until the user forced the issue.

Expectation: when a core objective proves infeasible under the chosen design, the model should stop, present the failure explicitly as a failure, and offer the alternative designs — not label the gap and continue reporting progress.

No user/student data included.