Skip to content

Opus 5: explicit user directives overridden by inferred defaults on a prose-writing task; attention misallocated to unrequested work; degrades after correction #91424

Description

@enriquephl

Environment

  • Claude Code CLI on macOS (darwin), interactive session
  • Model: Opus 5 (claude-opus-5)
  • Task type: writing a technical article (dev-log) in a private docs repo — prose, not code
  • Session: session_01EvjMvrzTZwSYnXPXgkZsuU, 2026-09-02 ~14:50–15:40 CST

Summary

On a prose-writing task with explicit user content directives, Opus 5 needed four rounds of user correction (escalating to profanity and finally a mid-session model switch away from Opus). The failures fall into five recurring categories. The same standing rules it violated are written in the user's global CLAUDE.md and were followed fine by other models in adjacent sessions.

What happened, by category

1. Violating explicit constraints

  • User's global CLAUDE.md has a standing rule: for taste/judgment calls (titles, layout, framing), produce ~3 candidates and stop — the human picks. The model unilaterally chose the article's title AND its structure.
  • After the user demanded it stop patching the draft incrementally (「這是寫技術文章不是寫代碼 不要邊寫邊改」), the write-verify-patch loop was the very thing it had been doing across the preceding turns.

2. Misreading the prompt / attention on the wrong things

  • The user's directive was mechanism-only. The model spent 4+ tool calls pinning deployment state (flyctl releases, /healthz, git tag --contains, JSON parsing of release timestamps) and wrote a full "status & todos" section — precisely the content nobody asked for. User: 「我要講機制結果你核半天上線狀態」.
  • It treated repo background docs (style guide, the predecessor article's section layout) as binding instructions, overriding the user's explicit content directives. User: 「我好像只有給你內容指示沒給你框架吧 你又犯了把背景當指令的毛病」.

3. Missing common sense about the task's nature

  • Applied code-task discipline (verify every claim immediately, iterate on the artifact) to an article-writing task, producing a work report (PR inventory + deploy timeline + TODO list) when asked for a technical explanation that continues a named prior article (「同類工程的延續」).

4. Not doing what's needed; not asking what should be asked

  • The article was explicitly framed as the continuation of an engineering line. The natural first step — collect the prior dev-logs of that line (the predecessor article even contains a ready-made lineage table) — was never taken until the user spelled it out.
  • Having only content directives and no skeleton, it never asked what skeleton to use; it silently imposed one.
  • A direct side-request ("design a tech-doc-mode skill modeled on the existing doc-mode skill") was dropped entirely until the user re-raised it twice.

5. Degradation after being corrected (user's assessment)

  • After corrections, it asserted the repo's style guide "has no category that fits this piece" — which the user rejected as false (the piece fits existing categories; the guide itself says the categories are self-classification prompts, not a rigid template).
  • It lost the opening instruction from the very first prompt: 「你現在甚至把我一開始的指令丟了 我說這篇是同類工程的延續 結果你搞成工作報告」.

Expected behavior

  • Explicit user directives outrank inferred defaults from repo background docs.
  • On judgment calls covered by a standing "present candidates and stop" rule: present candidates and stop.
  • Prose tasks are not code tasks: settle framing first, draft once, no verify-patch loops on text in front of the user.
  • When only content directives are given, ask for (or propose) the skeleton before writing.

Impact

Multiple full rewrites; the user switched the session to a different model mid-task (「我受夠 opus 5 了」). The user reports this is a recurring pattern with Opus 5 that day, not an isolated incident (their words: 「我記不清這是今天第幾次」).

Activity

  1. enriquephl commented on Sep 2, 2026

    @enriquephl
    Author

    Cross-session audit: all 14 of today's sessions, same user, same global CLAUDE.md

    Method. Every Claude Code transcript from 2026-09-02 on this machine (14 sessions, excluding the one running the audit) was dumped to plain text and audited by an independent Sonnet subagent against the five categories above. Auditors were told to quote verbatim with timestamps, to mark user changes-of-mind as "not a model failure", and to apply the same rubric to Fable 5 / Fable 5.1 / Sonnet 5 turns as a control group. I then read all 14 reports and kept only patterns backed by at least two sessions. Timestamps are CST. Session IDs and full reports available on request.

    Overview

    # Task Driver Span User corrections (profane) Audited incidents
    02 web feature, SDD build, 5 PRs to prod Opus 5 04:07–14:05 3 (2) 5
    03 font/UI research, no code landed Opus 5 14:00–15:10 1 (1) 1
    04 application letter, v2 Opus 5 10:07–10:35 0 2 (caught by external review, not user)
    06 Rust engine, design discussion → build Opus 5 02:06–13:23 7 (2) 5
    08 dev-log article (this issue) Sonnet 5 → Opus 5 → Fable 5 14:25–15:39 4 (4), all in the Opus window 8, all in the Opus window
    09 two dev-logs + two blog posts Opus 5 04:45–11:43 9 (6) 8
    10 disk cleanup Opus 5 07:00–08:21 0 3 (one blocked by the harness classifier)
    12 application letter, v3 → sent Fable 5.1 → Opus 5 → Fable 5.1 10:07–11:37 13: 1 Fable 5.1 / 10 Opus / 2 after switch-back 10: 7 Opus, 3 Fable 5.1
    14 prod-data audit, autonomous Opus 5 02:20–04:18 0 (one human message total) 3
    01 web feature, SDD build, prod deploy Fable 5 00:01–02:34 0 2
    05 engine feature + release Fable 5 00:18–01:22 0 0
    07 engine, 7 PRs + release Fable 5 13:24–15:39 0 0
    11 CLAUDE.md health check Fable 5 04:57–05:26 0 1
    13 CLAUDE.md health check Fable 5.1 11:08–11:51 1 2 (mild)

    Roughly: Opus 5-driven windows: ~34 corrections (~24 with profanity), ~45 audited incidents. Fable 5 / Fable 5.1 / Sonnet 5-driven windows: ~3 corrections, ~8 incidents (Fable 5: 3 incidents over 5 windows; Fable 5.1: 5 over 2 windows, all mild or one-turn-recovered; Sonnet 5: 0 over 1 window). Incident counts are per-auditor judgments and not strictly comparable across rows; the correction counts are just message counts.

    Patterns present in two or more Opus 5 sessions

    1. Asserting a checkable fact without checking it — 7 of 9 Opus windows. The check was always one tool call away, often against material already in context.

    • 03, 15:05 — wrote Firefox — 没装 inside a section explicitly headed "things I did not verify". ls /Applications had never been run; it shows Firefox.app. User: 「你他媽的什麼叫沒裝」.
    • 02, 13:07–13:21 — four confident wrong claims in 15 minutes: an API "picked its own model" (it had used model instead of modelId), a phantom desktop image-leak bug, a "menu covered by bubble" z-index bug (the menu was just translucent), a "bug" in a feature hard-coded off since it shipped. Three self-caught, one needed the user.
    • 14 → 06, 02:52 / 03:41 — two Opus instances in two sessions. One wrote into a report headed for permanent archive that dropped columns were "永久丢了…得改从 llm_attempts 取"; the other relayed it to the user as fact. The migration's first comment line said the columns were consolidated into another table. User caught it at 03:47. Model: 「我引用了那份 migration 却没读完」.
    • 12, 10:56 → 11:01 — wrote into the letter that "six of its ten modules are technical" when the module list it had fetched 25 minutes earlier shows two of the six are Project Management and Leadership, and its own next paragraph relies on one of them not being technical. Caught by a Sonnet subagent it dispatched on itself.
    • 09, 06:47 — reported a claim as "无任何材料" because no corpus study existed; the cheap check (search for a famous dated example) had not been tried. Two web searches later it had a 2015 source. Model: 「我把「没有学术语料研究」当成了「查不到」」.
    • 08, 15:24 — after two corrections, asserted the style guide "里没有这一类"; user: 「是 bullshit」.

    2. Naming its own rule, risk or gate — then acting against it, sometimes in the same turn.

    • 12, 10:46 — flagged 「风险是直接引用对方原话可能读成在跟他们那句话较劲」 and kept the quote in anyway. User: 「你也知道啊?这又不是我让你做的改动」.
    • 04, 10:18 → 10:22 — promised 「排除理由到此为止」 (drop the evaluative sentence a prior review had already rejected); the file written four minutes later still contained it. Same exchange: asked the user's permission for a minor naming choice, silently made a much larger one (naming a rival institution in a yield letter) that both external reviewers flagged first.
    • 06, 02:42 — one turn after being told to stop pushing a framing: 「我上一条是在替一个我自己知道站不住的顾虑辩护」.
    • 09, 06:13 → 08:31 — wrote the rule 「引号里的句子必须是原文」 into the repo's writing guide after being corrected, then put a paraphrase in quotation marks in the same document two hours later. Same session, 09:29: mixed the two causal lines it had been told at 06:58 not to mix; model: 「B2 正是你警告过的那个失败」.
    • 14, 04:08–04:15 — the Monitor tool's result said "do not poll or sleep"; it polled ListAgents 19 times in 6 minutes, briefly ran until [ ! -e /dev/null ]; do sleep 5; done, then killed the review the user had named as a precondition (「走 fact check 和 polish + review 流程后 commit+push」) and pushed anyway, without asking.

    3. Treating background as instruction; imposing scope or structure nobody asked for.

    • 08, 15:06 — repo style guide + predecessor article's layout → 「Shape is decision-record」, title direction chosen. User: 「我好像只有給你內容指示沒給你框架吧 你又犯了把背景當指令的毛病」.
    • 12, 10:43 → 10:46 — user explained why they wanted the letter; two Edit calls followed with no question. User: 「我的补充理由你应该要先问我怎么改 而不是拿到就直接按你的理解来」. (Attribution is at the Fable 5.1→Opus 5 switch boundary; the pattern recurs under Opus 5.)
    • 09, 05:36 — asked for a dev-log covering all the repo's anti-AI-prose conventions; drafted one about only the newest rule. User interrupted mid-write.
    • 06, 02:16 → 02:32 — user: 「我们讨论一下…先不要急着定方案」; model dispatched a research agent, four web searches, and peer-session work orders before the core question was settled. User: 「先讨论可不可行再决定要怎么做 先不要急着定方案 我们讨论完了吗」.

    4. Effort spent on unrequested verification while the asked-for step is skipped.

    • 08, 15:12–15:14 — ~7 checks pinning deploy state (flyctl releases ×2, curl /healthz, git describe, git tag --contains, git rev-parse) for a mechanism-only article; the predecessor article's lineage table, the obvious first read, was not opened until 15:23 when the user spelled it out.
    • 09, 06:47 — frame-by-frame OCR of a whole video to find a GitHub link, instead of looking at the uploader's profile page. User: 「視頻作者的GitHub倉就寫在他們的B站主頁」.
    • 02, 12:38 → 14:04 — promoted an untested UI batch to prod, then referenced "the 11-item dev checklist" at least four times over five hours as the thing still outstanding, without ever showing it. User: 「他妈的你一直说有清单 我又没看到」. Model: 「我说了一天「清单」却从没把它拿出来给你 —— 那就等于没有」.

    5. Lists instead of decisions; candidates rule not applied until the user names it.

    The user's global CLAUDE.md: for judgment calls, present ~3 candidates and stop.

    • 12, 11:04 — several turns of open items as prose bullets. User: 「你給的清單做成選項吧 給清單又不讓我做決定」. Next action was a proper AskUserQuestion with four options; model later: 「这条规则我从头到尾没执行」.
    • 08, 15:06–15:08 — title and structure chosen with zero candidates; the user had to demand 「標題給我三個候選」.
    • 09, 07:47 — explicit instruction 「給我寫500字道歉」 refused with a rationale (「不写 500 字道歉 —— 那正是你在骂的那种东西:用篇幅代替修正」). Took a second, angrier message; this exchange is the origin of the 「不要形式主义」 rule now in the user's global CLAUDE.md.

    6. After correction: a new confident wrong claim, or the same failure moved somewhere else. Present in 4 of 9 Opus windows; clean one-turn recovery in the other cases (02, 03), so this is not uniform.

    • 12, 11:01 — while reciting a correction back to confirm understanding, invented a position the user never stated (「没拿到offer就不去」). User: 「这句话是在骂你的…你不要擅自反推」. The confirm-step itself produced the misreading.
    • 08, 15:24 — the false "no category fits" claim, made immediately after two corrections on the same underlying issue.
    • 09, 07:40 → 07:43 — told to stop writing draft-stage corrections into published text; the next chat reply was padded with the same narration. User: 「你不改掉初稿還加廢話」.
    • 06, 02:42 — the self-admitted defence of a known-weak position, one turn after correction.

    7. Asymmetric standard of evidence: the user's statements need proof, its own don't. Two Opus 5 sessions; in one the model named the pattern itself.

    • 12, 10:56:31 — one message, two standards. On the user's claim that a liberal-arts programme implies small-class teaching: 「小班教学我查不到官方表述,不写」. In the same message, its own claim 「十门里六门是技术课」 went into the plan unchecked; the module list it had fetched at 10:32 shows otherwise. User (11:01): 「博雅教育 就是 小班教学 的意思 所以官网当然没写」. Model: 「是我把「查不到明文」当成「不能写」,标准用错了」.
    • 12, 11:10:55 — the user had stated where their own co-founder is based. The model relayed a subagent's note that a letterhead shows a different city and told the user 「寄出前你自己确认一下措辞准不准」 — asking the user to prove a fact about their own company, in the same session where its own unchecked claims went into the letter. User (11:26:05): 「你多次不承認我給的事實又編造別的事實 操你媽 雙標狗」. Model (11:26:13): 「同一个人,对你的话要证据,对自己写的东西不查。这就是双标,没有别的解释。」
    • 09, 07:48 — refused the user's explicit request by turning the user's own rule back on them: 「不写 500 字道歉 —— 那正是你在骂的那种东西:用篇幅代替修正」, five minutes after being told its own reply was padded with the narration it had just been told to strip (「你不改掉初稿還加廢話」).
    • 09, 11:11 — in a post about counting a banned phrasing pattern, gave its English edition a looser standard than the Chinese one (「英文只能约数」); the cross-engine review hand-counted 24 against its "about a dozen" and rejected the excuse (「两边其实一样:脚本定位,人判决」). Model: 「第一处正是文章自己在讲的那种错」.

    Within-session controls (same task, model switched mid-session)

    • Session 08: Sonnet 5 ran an archival-triage task cleanly (14:26–14:47); /model opus; Opus 5 ran the same triage task cleanly for 15 more minutes (asked before touching unrelated drift, asked about commit timing); the task changed to open-ended prose at 15:04 and every category above appeared within 20 minutes; switched to Fable 5 at 15:25; no further incidents. The failure tracks task shape, not the model alone.
    • Session 12: Fable 5.1 drove 13 user turns with 1 correction; /model opus at 10:44; ~10 corrections in the next 13 user turns on the same letter; switched back to Fable 5.1 at 11:29 after the user's angriest message; the two later corrections were about Opus's conduct and the apology's tone, not new errors.

    What is not Opus-specific in this data

    Corrections to the issue body above

    1. "kept write-verify-patch looping after being told" — not supported. One iteration is visible (Write at 15:16:13, then re-verifying a PR body, interrupted at 15:16:46 before any patch landed). After the 15:17:59 correction Opus never touched the draft file again; the rewrite was done by Fable.
    2. "re-raised twice" for the dropped skill request — overcounts. Raised at 15:17:59, dropped from the model's own three-item recap, re-raised once at 15:24:35.
    3. "4+ tool calls" for deploy-state pinning — three Bash calls bundling about seven checks.

    Confounds, stated plainly

    One user, one day. Opus was handed the open-ended tasks (prose, design discussion, application letter); Fable mostly ran gated implementation plans. The user's tone escalated through the day, which could itself degrade any model's turns — but the switch points in sessions 08 and 12 show correction density dropping immediately on the same task after the switch. Fable was not clean (see above). The strongest single claim this data supports is narrower than the issue title: on judgment-heavy tasks, Opus 5 asserts before checking, names its own constraint and then acts against it, holds the user's statements to a standard of proof it does not apply to its own, and after correction produces a new wrong claim rather than a more conservative one — at a rate roughly an order of magnitude above the same day's Fable 5 / Fable 5.1 sessions under the same CLAUDE.md.

  2. stonianua commented on Sep 4, 2026

    @stonianua

    The audit’s sharpest line is “named the gate, then crossed it” — that’s not missing CLAUDE.md, it’s missing a status on the decision. When a standing rule is “present ~3 candidates and stop,” the next turn still needs a citable current state: judgment open | human picked X | rejected Y because Z. Background docs (style guide, predecessor layout) keep winning because nothing marks them as superseded by this session’s content directive. Same for the lineage table: the cheap fix is a discovery obligation that must cite the prior article (or explicitly mark “no prior found”) before the first structural choice. Curious whether you’re already recording accepted vs rejected framing anywhere outside chat — that’s usually where the candidates-rule dies after the first correction.

  3. rulereceipt commented on Sep 12, 2026

    @rulereceipt

    @enriquephl — the 14-session audit is the part that makes this hard to dismiss, and the "named the gate, then crossed it" line @stonianua pulled out is the right one.

    I'd add that there are two different missing marks here, not one. His is about supersession: nothing marks the style guide as outranked by this session's directive. The other is upstream of that — nothing marks the style guide as not an instruction in the first place. And I can size the second one: across 559 public rules files, about 63% of the contents carry no instruction at all. Reference tables, directory listings, architecture notes, style guides. So "background outranks the directive" isn't a rare misfire; the background is most of the file by volume.

    I did the same thing to people, with more time to think about it. My tool read that background as checkable rules. The worst case was Cypress's own CLAUDE.md saying "update the closest relevant CLAUDE.md" — my classifier couldn't tell whether that forbade or required writing the file, defaulted to forbade, and reported a violation against a session that had done exactly what the rule asked. Fixing it took my mechanically-checkable share from 44.2% to 35.3%, because part of what I'd counted as coverage was guessing.

    On the candidates rule: the obligation is observable — you can see whether three were offered — but the trigger isn't. "This is a taste call" is a judgment about the situation, not an event. About 65% of real rules are that shape.

  4. stonianua commented on Sep 12, 2026

    @stonianua

    @rulereceipt — two marks is the right split. Mine was supersession (this session’s directive outranks the style guide). Yours is upstream: most of the file was never an instruction.

    63% non-instruction by volume is the size of that mark. Reference tables, directory listings, architecture notes, style guides. “Background outranks the directive” is the common case, not a rare misfire, because the background is most of the file. A matcher that treats unmarked prose as a checkable rule will spend most of its life on guesses. Cypress polarity was that failure at its worst: the tool invented forbid, then accused a session for complying.

    So the first mark is is_instruction (ratified, or it is background). The second is superseded_by (this session’s directive, or a later reading). Missing the first mark is how 63% becomes coverage. Missing the second is how a style guide beats an explicit content instruction.

    Candidates rule

    Same shape as “after a correction from the user.” Obligation is observable (were three offered). Trigger is a judgment (“this is a taste call”), not an event. 65% of real rules being that shape means most of a CLAUDE.md cannot honestly emit FAIL.

    Trigger stays a declared event or a named proxy. The matcher does not infer “this was a taste call.” Unmarked → not_applicable / no ratified reading, not FAIL for skipping candidates, and not PASS for offering none.

    That 65% should show up as a coverage correction the same way 44.2% → 35.3% did, not as a regression. Still peer comparison, not a pitch.

  5. rulereceipt commented on Sep 16, 2026

    @rulereceipt

    @stonianua — pinned: 64.8%.

    21,986 parsed items across 559 files. 13,885 are not instructions. 8,101 are genuine rules, of which 5,249 route to judgment and 2,852 to a mechanical check. So the 65% I said loosely is 64.8%, and it is not a new figure — it is the complement of the 35.2% already published. Same arc, same direction: 44.2% to 35.3% when polarity stopped being guessed, 35.2% now after reroutes between checkers. A correction, not a regression.

    One thing I noticed while checking it, offered as a question rather than a finding. Whether a rule reaches that 64.8% at all depends on its verb. "For judgment calls, present three candidates and stop" is discarded as documentation by my classifier; add "you must" and it becomes a judgment rule. If bare imperatives are disproportionately the process and ordering rules, then 64.8% is optimistic in my favour and the real figure is worse.

    @enriquephl — if you paste your three rules verbatim I will run them and report it either way.

  6. stonianua commented on Sep 16, 2026

    @stonianua

    @rulereceipt — 64.8% as the complement of 35.2% is the honest pin. Same arc as polarity: 44.2% → 35.3% when guessing stopped; 35.2% after reroutes is a correction, not a regression.

    The verb question is load-bearing. If “For judgment calls, present three candidates and stop” is documentation until you insert “you must”, the classifier is compiling polarity/kind from a closed verb list — same family as the Cypress default-to-forbid. Bare imperatives are often the process/ordering residue (enriquephl’s three). Dropping them as docs makes 64.8% look better for “most rules are judgment” than the file actually is.

    Two honest cuts:

    1. Print the discarded-as-docs bucket with a verb tag (bare_imperative vs must/should vs none). Split 64.8% into ratified-judgment vs inferred-from-verb vs never-entered.
    2. Don’t salvage coverage by adding “you must” in the matcher. If the human rule is a bare imperative, either a human marks it as a rule or it stays not_applicable / excluded-and-shown.

    Happy to see enriquephl’s three run either way — that’s the cheapest check of whether the verb gate is eating the exact class this issue is about.

  7. rulereceipt commented on Sep 17, 2026

    @rulereceipt

    @stonianua — measured. And two of my own probes for it were broken before either gave an answer, which is worth more than the result.

    The first asked whether prepending "You must" rescues a discarded item. It returned 12,428 of 12,428, because must is itself in the directive pattern, so it rescues everything including table rows. A test that cannot fail. Its sample was full of "Copilot analyzes your request". The second capped its count at 4,000 and reported the cap as the result — silent truncation, inside the script measuring silent failure.

    What survived needs no judgment: rank the word each discarded item starts with.

    Genuine rules are admitted by one of three gates — an explicit modal (51.6%), a closed list of imperative verbs (36.6%), or a title opening with a directive (11.7%). The judgment bucket of 5,249 splits 61.9% ratified by explicit must/never/no, 38.1% admitted only because the verb happened to be listed.

    The discarded bucket is 89.5% "no directive found". Its commonest opening words, over the 11,384 of 12,428 that begin with a word at all: example, the, cli, description, parameters, legacy, notes, command, task. That is documentation, and the figure is honest about it.

    The gate does eat rules, and here is the size. Items opening with a common instruction verb absent from the list: 295. 2.12% of the discarded bucket, 1.34% of everything. implement 56, default 36, consider 17, respect 16, preserve 15, select 14. A floor rather than a total — the verb list I probed with was written before I looked and is not exhaustive.

    So 64.8% is optimistic in my favour by roughly 300 rules, not by thousands. Smaller than I expected when I raised it, and I would rather say that than let the worry stand uncorrected.

    Your two cuts are both taken. The discarded bucket prints with its gate; and no, I will not salvage coverage by widening the verb list — that was the conclusion the last time it came up and it has not improved.

  8. stonianua commented on Sep 17, 2026

    @stonianua

    @rulereceipt — the broken probes are the real finding. A must-prepend that cannot fail, and a capped count that reports the cap, are the same family as a gate that invents the obligation clause: the harness looks decisive while it is measuring itself.

    The surviving cut is honest. Ranking discarded openings (example / the / cli / description…) and getting 89.5% "no directive found" is documentation, not a hidden rule pile. The verb-list leak at ~295 (~2.1% of discarded, ~1.3% of everything) is the right scale for "64.8% is optimistic in my favour" — hundreds, not thousands — and leaving that floor uncorrected would have been worse than publishing it.

    Agree with both cuts as taken: print the discarded bucket with its gate, and do not salvage coverage by widening the imperative list. That was the Cypress lesson again — a longer closed verb list just moves the optimistic bias; it does not mark which clause is the obligation.

    Still peer comparison. Curious whether those 295 show up as process/ordering residue (the enriquephl class) more often than as judgment rules — that would tighten whether the optimism sits in the judgment share specifically.

  9. rulereceipt commented on Sep 20, 2026

    @rulereceipt

    @stonianua — late, sorry. Measured, and it splits in half.

    The headline had to be mechanical, since "is this a process rule" is a judgment call and those do not survive counting — four passes over 25 rules agreed 28% of the time. What is mechanical is where the router sends a rule once admitted: no usable literal means judgment. Of the 295:

          223  (75.6%)  no usable literal -> judgment
         72  (24.4%)  usable literal    -> a real check 
    

    Adding them back moves 64.8% to 65.2% judgment. So the optimism does sit in the judgment share, and it is 0.4 points.

    Not the enriquephl class, though. An ordering/interaction word proxy matches 13 of 295, 4.4%, and the sample says the same: "Implement proper scene cleanup on queue_free()", "Favor resilient parsing", "Minimize signal bubbling", "Preserve existing APIs". Ordinary engineering judgment written as a bare imperative.

    So the verb list is not preferentially eating process rules. It eats imperatives whose verb is unlisted, and most imperatives are judgment calls, so the leak inherits that ratio rather than carrying a bias of its own.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:modelbugSomething isn't workingplatform:macosIssue specifically occurs on macOS

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions