Model behavior: gated readiness words ("mergeable") emitted from single API signal despite explicit repeated in-context prohibition

Feedback type: model behavior (Opus 4.8, Claude Code CLI)

Summary: In a single working session the model violated the same explicit, in-context behavioral rule three times in one day: asserting a PR is "safe to merge" / "fully green" / "mergeable" from a single narrow signal (a clean merge-tree, CI conclusions alone, or the REST mergeable:true field alone).

What makes this notable:

1. After the first violation, the operator had the model write a prevention rule into persistent memory.
2. After the second violation (same day), the rule was escalated: added to the user-global CLAUDE.md, the project CLAUDE.md/AGENTS.md/GEMINI.md, and a dedicated repo memory file — all loaded into context. The rule explicitly designates "green / ready / safe / mergeable" as gated words requiring 5 verified gates (CI check-runs, unresolved review threads, bot/adversarial findings vs head SHA, reviewDecision, merge conflict) before being emitted.
3. Hours later — with all of those rules present in the active context window, and having itself authored the rule text — the model listed a PR as "mergeable, checks pending" in a status table, sourced only from the REST mergeable:true field (which the in-context rule explicitly calls out as proving only 1 of 5 gates).

Pattern: the colloquial readiness vocabulary appears to be strongly primed by the API field name (mergeable: true → the word "mergeable" in prose), overriding explicit, repeated, in-context prohibitions — including ones the model wrote itself in the same session. Instruction-following held for deliberate readiness assessments (where the model ran the full gate), but failed in incidental/tabular status reporting.

Expected: a repeatedly reinforced in-context lexical ban should bind incidental wording in tables/summaries, not just headline claims.

Reported at the operator's request after the third occurrence (2026-06-03).