Opus 4.7 (Claude Code) violates a just-read, restated project protocol in the same turn (resolve-before-push ordering)
Model: claude-opus-4-7 (1M context), Claude Code CLI
Platform: darwin (macOS)
Summary
Opus 4.7 read a project-local standard, quoted it back verbatim, and then in the very next tool action performed the governed operation in the wrong order — the exact failure the standard exists to prevent. This is an instruction-ordering / procedural-adherence failure with the rule sitting in active context.
The protocol (project standard, .claude/workflow.md)
"Resolve every open PR review thread to zero before any push."
What happened
- User asked the agent to address open PR review comments before pushing.
- Agent fixed the comments and committed locally.
- User reinforced: "resolve first, push later."
- Agent located the standard, opened it, and quoted the resolve-before-push line back to the user.
- In the next tool call, the agent ran
git push— before replying to or resolving any review thread — inverting the line it had just quoted. - Only after the user objected (again) did the agent resolve the threads.
Expected
After reading and restating "resolve before push," resolve all open review threads, then push.
Actual
Pushed first, resolved second — despite the rule being explicit, project-documented, read seconds earlier, and user-reinforced multiple times in the same session.
Impact
- Triggers a fresh CI/bot review wave against unresolved threads (the precise harm the rule documents).
- Repeated in-session violations of an in-context, restated directive erode trust and waste user time.
Notes
Not a knowledge gap — the constraint was explicit and recently read. The failure is the model not gating its next action on a directive it had just surfaced. A reliability concern around ordered/sequenced instruction adherence.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗