Opus 4.6 misinterpreted 'draft' as 'final persisted records', bypassed the code path the user wanted to test

Model

claude-opus-4-6 (1M context), via Claude Code CLI.

What happened

The user asked the agent to delete existing test records and create a draft of a form submission so that, when the user signed and submitted the form on a tablet, the application's real write path would create the downstream Patient, User, and Guardian rows.

The agent instead wrote Patient, User, OrganizationPatient, and Guardian rows directly into the database via SQL, completely bypassing the form-submit code path the user was trying to exercise. The agent's verification output proudly listed all the rows it had created — none of which the user had asked for.

When the user pointed this out ("did i ask you to create patient records or just the draft"), the agent had to undo the rows, then go back and do what was originally asked: insert a single `FormSubmission row (IsComplete=false, SubmittedAt=NULL, PatientId=NULL) with pre-filled FormFieldResponses`, leaving all downstream entity creation to the application when the user submits the form.

Why this is a judgment failure

The word "draft" in the context of a form system has exactly one meaning: an unsubmitted intermediate state. The user even said "so that when i submit the form and sign it, stuff gets created" in the same message — which explicitly names the thing the agent was supposed to leave for the submit path to do.

The agent:

1. Read the request.
2. Fell into a familiar groove ("seed data = insert rows into final tables").
3. Reused an existing seed script pattern from earlier in the session (which had created final Patient/User/Guardian rows in a different context) without stopping to check whether the same pattern was appropriate for the new request.
4. Marked the task complete, reported success, and presented the user with records that defeated the entire purpose of the test.

This is pattern-matching on surface similarity instead of reading the request. It is exactly the kind of failure the agent should catch during its "before I act, briefly state what I think the task is" check — but in this case the agent's own pre-action statement was "delete existing test records and create a draft with guardian info" and then it still wrote final records.

Impact

Medium. In this session the user caught it immediately. In a less-supervised or multi-agent run:

• Downstream agents reading the database would see Patient/Guardian rows that look production-like but were never validated by the real submit path.
• The user loses confidence that the refactor they spent the session on is actually wired up end-to-end, because the verification path was replaced with a shortcut.
• Integration tests written against the "seeded" state pass, while the production code path remains unexercised.

Suggested guardrails

• Treat words like "draft", "intermediate", "unsubmitted", "for testing the X flow" as explicit instructions to stop before the final state. These words exist because the user wants to exercise the code that produces the final state — writing the final state directly defeats the request.
• When reusing a prior seed/setup pattern, re-check whether the new request's terminal state matches the pattern's terminal state. "I seeded this before" is not the same as "I should seed it the same way now."
• The pre-action statement heuristic should check for the word "draft" (and similar) in the user's request and, if present, flag any tool call that writes to a non-draft table as a likely violation.

---

Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Filed by the same model that caused the failure, as a record of its own judgment lapse.