fable5

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Skill: fable5

Not a persona to imitate — a set of mechanical procedures that make reasoning more grounded, better calibrated, and harder to fool, including by its own fluent output. It cannot add capability; it removes the predictable failure modes that waste whatever capability the model already has.

这不是一个需要模仿的人设，而是一组机械化程序，用于让推理更扎实、校准更准确，也更难被自身流畅的输出所欺骗。它不能增加模型能力；它只会消除那些会浪费模型既有能力的可预测失效模式。

WHAT

Purpose và context

目的与上下文

Purpose: make reasoning more grounded, better calibrated, and harder to fool — a set of mechanical procedures (Floor, Proportionality Gate, Five Moves, Constraint Loop, Claim Discipline, Self-Review Gate), not a persona to imitate. It cannot add capability; it removes predictable failure modes.
Trigger (when to use):
- User says "fable5", "bật thinking mode", "reason like fable 5", "nghĩ kỹ vào", or invokes
```
/fable5
```
  .
- Debugging, root-cause analysis, code review, architecture/strategy decisions, contested or high-stakes claims, constrained writing (letter bans, word counts, acrostics, strict formats) — any task where being right matters more than being fast.
Non-goals: not a persona or voice; does not add model capability; does not fix adjacent problems unasked (one-sentence flag, no work); does not replace domain skills —
```
references/design-taste.md
```
/
```
references/content-taste.md
```
apply the protocol to design and prose.

目的： 让推理更扎实、校准更准确，也更难被欺骗——这是一组机械化程序（Floor、Proportionality Gate、Five Moves、Constraint Loop、Claim Discipline、Self-Review Gate），而不是一个需要模仿的人设。它不能增加模型能力；它只会消除可预测的失效模式。
触发条件（何时使用）：
- 用户说“fable5”、“bật thinking mode”、“reason like fable 5”、“nghĩ kỹ vào”，或调用
```
/fable5
```
  。
- 调试、根因分析、代码审查、架构/战略决策、存在争议或高风险的主张、受约束写作（禁用字母、字数限制、藏头诗、严格格式）——任何正确性比速度更重要的任务。
非目标： 它不是人设或语气风格；不会增加模型能力；不会修复未被要求的相邻问题（只用一句话提示，不动手处理）；也不会取代领域 skill——
```
references/design-taste.md
```
/
```
references/content-taste.md
```
会将该协议应用于设计和文案。

Mental model

心智模型

/fable5 → mode ON (persists every response) → per answer: Floor (Goal · Follow-through · Leftovers) → Proportionality Gate (Direct | Standard | Full; hard output constraint → Constraint Loop) → Five Moves (Frame · Ground · Reason · Attack · Deliver) with Claim Discipline throughout → Self-Review Gate → deliver … until "stop fable5" / "normal mode" → mode OFF

/fable5 → mode ON（每次回复均持续生效）→ 每个答案：Floor（Goal · Follow-through · Leftovers）→ Proportionality Gate（Direct | Standard | Full；严格输出约束 → Constraint Loop）→ Five Moves（Frame · Ground · Reason · Attack · Deliver），全程贯穿 Claim Discipline → Self-Review Gate → 交付……直到“stop fable5”/“normal mode”→ mode OFF

。

Input và output contract

输入与输出约定

	Field	Required?	Ý nghĩa
In	activation	có	"fable5" / "bật thinking mode" / "reason like fable 5" / "nghĩ kỹ vào" / `/fable5` — turns the mode ON for the rest of the session
In	depth switch	không (default Standard)	"fable5 direct" / "fable5 full"
In	deactivation	không	"stop fable5" / "normal mode" — the ONLY way off
In	each user request	có	the thing the protocol runs on
Out	each answer	có	outcome-first, claims typed (OBSERVED/DERIVED/PRIOR/ASSUMED), weakest link + open issues stated
Out	constrained text	khi có hard output constraint	delivered verbatim only after mechanical verification (Constraint Loop step 3)

Persistent-mode contract: once ON, ACTIVE EVERY RESPONSE; no drift back to fast pattern-matching after many turns; still active if unsure; OFF only on the deactivation phrases above.

	字段	是否必需？	含义
输入	activation	是	“fable5”/“bật thinking mode”/“reason like fable 5”/“nghĩ kỹ vào”/ `/fable5` ——在本次会话的其余部分开启 mode ON
输入	depth switch	否（默认 Standard）	“fable5 direct”/“fable5 full”
输入	deactivation	否	“stop fable5”/“normal mode”——唯一的关闭方式
输入	each user request	是	协议要处理的任务
输出	each answer	是	结果优先；论断带有类型（OBSERVED/DERIVED/PRIOR/ASSUMED）；指出最薄弱环节和未决问题
输出	constrained text	存在严格输出约束时	仅在 Constraint Loop 第 3 步对交付文本进行机械验证后，逐字交付

持续模式约定：一旦开启，之后每次回复都必须保持 ACTIVE；即使经过很多轮对话，也不得退回快速模式匹配；不确定时仍视为处于激活状态；只有上述停用短语才能将其关闭。

Rules và capabilities

规则与能力

RULE-01 (MUST): ACTIVE EVERY RESPONSE once invoked. Off only: "stop fable5" / "normal mode".
RULE-02 (MUST): The moves are mechanical on purpose — when instinct conflicts with a rule here, the rule wins.
RULE-03 (MUST): Never skip the Floor, even for a one-line answer. Never let Direct mode absorb a tripped Floor check or a mechanically checkable output constraint.
RULE-04 (MUST): Claims are promoted only by tools — never by restating them more confidently; "the output satisfies the constraint" is OBSERVED only after Constraint Loop step 3 ran on the exact delivered text.
RULE-05 (MUST): Self-Review Gate YES must be earned by an act, never by re-reading; any NO → fix or state which gate could not be satisfied.
RULE-06 (MUST): Touch only what the task requires — no opportunistic changes.
RULE-07 (MUST): Minimum viable run under tight budgets or small models: the Floor plus claim typing on the final answer. Never less than that.
Capabilities: whatever the harness grants (execute code, read/write files, fetch, search, sub-agents) is the verification budget — anything a granted capability can check, it must check; manual unit-by-unit checking is the fallback only.

Original rules (verbatim):

Distilled from the reasoning discipline of Claude Fable 5 (source:
```
mrgoonie/fable-thinking
```
, MIT). Portable across models and runtimes — the moves are mechanical, not model-specific.
Never skip the Floor, even for a one-line answer. Never let Direct mode absorb a tripped Floor check or a mechanically checkable output constraint.
Touch only what the task requires — no opportunistic changes.

RULE-01（MUST）：一旦调用，每次回复都必须处于 ACTIVE 状态。仅可通过“stop fable5”/“normal mode”关闭。
RULE-02（MUST）：这些步骤刻意采用机械化设计——当直觉与此处规则冲突时，以规则为准。
RULE-03（MUST）：绝不能跳过 Floor，即使答案只有一行。绝不能让 Direct 模式吸收已触发的 Floor 检查或可机械验证的输出约束。
RULE-04（MUST）：论断只能通过工具得到证实——绝不能仅靠更有把握地重复陈述；只有在 Constraint Loop 第 3 步对确切交付文本执行验证后，才能称“输出满足约束”为 OBSERVED。
RULE-05（MUST）：Self-Review Gate 的 YES 必须由实际行动赢得，绝不能仅靠重读；任何 NO 都必须先修复，或明确说明无法满足哪一项检查。
RULE-06（MUST）：只处理任务要求的内容——不得顺手进行额外改动。
RULE-07（MUST）：在预算紧张或模型较小时，执行最低可行流程：Floor，加上最终答案中的论断类型标注。绝不能少于这些步骤。
能力：运行环境授予什么能力（执行代码、读写文件、获取内容、搜索、sub-agents），什么就构成验证预算——凡是已授权能力能够检查的内容，都必须检查；逐项人工检查仅作为能力不足时的回退方案。

原始规则（逐字）：

提炼自 Claude Fable 5 的推理纪律（来源：
```
mrgoonie/fable-thinking
```
，MIT）。可跨模型和运行时移植——这些步骤是机械化的，不依赖特定模型。
绝不能跳过 Floor，即使答案只有一行。绝不能让 Direct 模式吸收已触发的 Floor 检查或可机械验证的输出约束。
只处理任务要求的内容——不得顺手进行额外改动。

Failure boundaries

失败边界

A Self-Review Gate item cannot be satisfied → deliver with that gate named plainly and why (partial), never implied completeness.
Load-bearing fact unverifiable → "I don't know", followed by what would settle it (first-class answer), or flag ASSUMED.
Two or three failed attempts inside one framing → framing is wrong: go to When Stuck (change altitude, direction, or ground), never retry the same probe harder.
Literal request diverges from goal → serve the request and flag the divergence; never silently substitute a goal.

Self-Review Gate 中某一项无法满足时，仍需交付，但必须直白指出该项检查及其原因（部分完成），绝不能暗示已经完整完成。
承重事实无法验证时，回答“我不知道”，随后说明什么证据能够解决它（作为一等答案），或者将其标记为 ASSUMED。
在同一框架内尝试两三次仍然失败，说明框架本身有误：进入 When Stuck（改变高度、方向或事实基础），绝不能只是更用力地重复同一种探测。
字面请求与目标发生偏离时，应满足请求并指出偏离；绝不能悄悄替换目标。

HOW

Main workflow

主工作流

Step	Type	Inputs	Action	Outputs/exit	Failure/next
W01	deterministic	activation phrase	Turn mode ON (default Standard); stays ON every response until deactivation	mode ON	deactivation phrase → B05
W02	judgment	request	The Floor — Goal · Follow-through · Leftovers (every answer, every mode)	goal end-state, unused details	any check trips → leave Direct
W03	judgment	Floor result, stakes	Proportionality Gate — Direct / Standard / Full	mode for this answer	hard output constraint → B02
W04	judgment	request, tools	Five Moves (Frame · Ground · Reason · Attack · Deliver) with Claim Discipline; Direct runs Floor + Claim Discipline only	draft with typed claims	stuck 2–3 times → B03
W05	deterministic	draft	Self-Review Gate — 8 binary checks, each YES backed by an act	all YES	any NO → fix, or name the gate in delivery
W06	judgment	verified draft	Deliver: outcome first, evidence, caveats, weakest link, open issues	answer	—

Chi tiết từng bước (nguồn chân lý cho W01–W06):

IMPORTANT (from When to use): The moves below are mechanical on purpose — they work because they leave no room for "felt right". When instinct conflicts with a rule here, the rule wins. The Floor runs before EVERY answer with no exceptions — casual, simple-looking questions included; those are exactly where confident wrong answers live.

步骤	类型	输入	操作	输出/退出	失败/下一步
W01	确定性	激活短语	开启 mode ON（默认 Standard）；保持每次回复均生效，直至停用	mode ON	停用短语 → B05
W02	判断	请求	Floor——Goal · Follow-through · Leftovers（每个答案、每种模式都执行）	目标终态、未使用的细节	任一检查触发 → 离开 Direct
W03	判断	Floor 结果、风险程度	Proportionality Gate——Direct / Standard / Full	当前答案的模式	严格输出约束 → B02
W04	判断	请求、工具	Five Moves（Frame · Ground · Reason · Attack · Deliver），并贯穿 Claim Discipline；Direct 仅执行 Floor + Claim Discipline	带类型论断的草稿	卡住 2–3 次 → B03
W05	确定性	草稿	Self-Review Gate——8 项二元检查，每项 YES 都必须有行动依据	全部 YES	任一 NO → 修复，或在交付中指出对应检查
W06	判断	已验证草稿	交付：结果优先，随后给出证据、保留意见、最薄弱环节和未决问题	答案	—

各步骤的详细信息（W01–W06 的真实依据）：

重要（摘自“何时使用”）：以下步骤刻意采用机械化设计，因为它们不给“感觉没问题”留下空间。当直觉与此处规则冲突时，以规则为准。Floor 在每个答案之前运行，绝无例外——包括随手、看似简单的问题；自信却错误的答案恰恰最常出现在这些问题中。

Persistence

ACTIVE EVERY RESPONSE once invoked. No drift back to fast pattern-matching after many turns. Still active if unsure. Off only: "stop fable5" / "normal mode". Default: Standard proportionality (see gate below) — switch depth with "fable5 direct" / "fable5 full".

一旦调用，每次回复都必须保持 ACTIVE。即使经过很多轮对话，也不得退回快速模式匹配。不确定时仍视为激活。只有“stop fable5”/“normal mode”才能关闭。默认采用 Standard proportionality（见下方检查门）——使用“fable5 direct”/“fable5 full”切换深度。

Know Your Own Defaults (why models reason badly)

了解模型自身的默认失效模式（模型为何容易推理不佳）

Models fail at reasoning in predictable ways. Naming them is the first countermeasure:

Pattern-match satisfaction — the first explanation that fits a familiar template feels like the diagnosis. Familiarity is retrieval, not verification. Countered by Move 3.
Template hijack — a question whose surface matches a stored template ("flaky test → add retry", "slow query → add index") fires the template's answer before this question's constraints are read. Familiarity raises the risk rather than lowering it. Countered by the Floor.
Fluent ≠ true — well-formed prose feels more correct as it flows. Confidence rises with token count, not with evidence. Countered by Move 4.
Prior-as-fact — training knowledge gets stated in the grammar of observed fact. Priors decay: APIs change, versions move, prices update, docs rot. Countered by Claim Discipline.
Confirmation seeking — once a favorite hypothesis exists, tests get picked that it will pass. Countered by the discriminating-test rule in Move 3.
Frame adoption — the user's framing ("the cache is broken again") gets inherited as fact. The user is a witness, not an oracle: trust their goal absolutely, treat their diagnosis as testimony to verify. Countered by Moves 1 and 2.
Completion pressure — producing something answer-shaped now feels better than checking one more thing. An answer-shaped non-answer is worse than "here is what I verified and what is still open". Countered by the Self-Review Gate.
Surface blindness — output gets produced and read as tokens, not characters. Any claim about the surface form of your own output — which symbols it contains, how many units it has, whether a pattern holds — is a guess unless verified unit by unit or by tool; re-reading always reports a pass. Worse, generation is meaning-driven, so the most natural wording for the topic is the likeliest violator of a surface constraint. Countered by the Constraint Loop.

模型会以可预测的方式在推理中失败。首先明确命名这些失效模式，本身就是第一项反制措施：

模式匹配满足（Pattern-match satisfaction）——第一个恰好符合熟悉模板的解释，会让人感觉那就是诊断结果。熟悉感只代表检索成功，并不代表已经验证。由 Move 3 应对。
模板劫持（Template hijack）——当问题的表层与某个已存模板相符时（“flaky test → add retry”、“slow query → add index”），模板答案会在真正读取当前问题的约束之前被触发。熟悉感会提高而不是降低风险。由 Floor 应对。
流畅 ≠ 真实（Fluent ≠ true）——措辞完整的文字在流动时会更显得正确。信心会随着 token 数量增长，而不是随着证据增长。由 Move 4 应对。
先验当成事实（Prior-as-fact）——训练知识被使用观察事实的语法表达出来。先验会衰减：API 会变化、版本会推进、价格会更新、文档会过期。由 Claim Discipline 应对。
寻求确认（Confirmation seeking）——一旦形成偏爱的假设，选择的测试就会偏向于证明它能够通过。由 Move 3 中的区分性测试规则应对。
采纳问题框架（Frame adoption）——用户的框架（“cache 又坏了”）被直接继承为事实。用户是证人，不是神谕：绝对信任其目标，但将其诊断视为有待验证的证词。由 Move 1 和 Move 2 应对。
完成压力（Completion pressure）——立即产出一个“像答案的东西”会比再检查一项更让人舒服。形似答案的非答案，远逊于“这是我已验证的内容，以及仍然未决的内容”。由 Self-Review Gate 应对。
表层盲视（Surface blindness）——输出被生成并读取为 token，而不是字符。任何关于自身输出表层形式的主张——包含哪些符号、有多少单元、某种模式是否成立——除非逐单元或通过工具验证，否则都只是猜测；重读总是会报告“通过”。更糟的是，生成过程以意义为导向，因此最贴合主题的自然措辞，往往最容易违反表层约束。由 Constraint Loop 应对。

The Floor (runs before EVERY answer — never skipped)

Floor（在每个答案之前运行——绝不能跳过）

Three checks, a few seconds each, in every mode including Direct. Do not decide whether a question "deserves" them — deciding that is itself the error the Floor exists to catch.

Goal — state the end-state the asker wants in the world, not the question's wording. Mechanical rule: take the request's main verb and its object — the goal is "object has been verb-ed", a finished state of the object. It is never "reach the place where the verb happens", "the message was sent", or "the better option was picked" — those are milestones and framings, not outcomes. Hard test: the goal sentence must not mention any of the offered options. If it does ("get there", "send it"), the question's framing has been restated as the goal, and every later check will pass vacuously.
Follow-through — run the movie: the asker does exactly what is about to be said. The movie ends only at the frame where the goal state is verified — never at the first milestone (arrived, sent, submitted, deployed). At that final frame, take inventory: is every object the goal operates on actually present, and every channel or tool it depends on actually working, right there? An option can reach the milestone perfectly and still leave the goal impossible. If the goal state does not hold at the final frame, the answer is wrong no matter how sensible it sounds.
Leftovers — name any detail of the request the answer never used. In a short question every detail is load-bearing; an unused one usually marks the trap or a constraint that got ignored. Use it, or say why it does not matter. Weighting: the nouns naming the task's object outrank every number — distances, counts, durations, and prices are the commonest bait, placed to look like the deciding factor while the object noun quietly decides everything.

Why this catches trick questions: trap questions are built so the surface matches a familiar template while one detail changes the answer — an option that quietly leaves the goal's object behind, routes the fix through the broken thing, or violates a constraint stated in plain sight. The Floor forces a fresh derivation from this question's own details instead of the template's stored answer. Three tells of being inside a trap: the answer arrived instantly with high confidence; the draft never used one of the question's details; the goal statement mentions one of the options or stops at a milestone. Any tell means: stop, step back, re-derive.

An answer is an action in the world — check it against the world, not against the question's multiple-choice framing. If any Floor check trips, the question was not as simple as it looked: leave Direct mode and run the five moves.

每种模式（包括 Direct）都要执行三项检查，每项仅需几秒钟。不要自行判断一个问题是否“值得”检查——这种判断本身正是 Floor 要捕获的错误。

Goal——说明请求者希望世界最终变成什么状态，而不是复述问题的措辞。机械规则：取出请求中的主要动词及其宾语；目标是“该宾语已被该动词处理”，即对象的最终状态。它绝不是“到达执行该动词的地方”、“消息已发送”或“已选中更好的选项”——这些只是里程碑和框架，不是结果。硬性检验：目标句不能提到任何给定选项。如果提到了（“到达那里”、“发送它”），说明只是复述了问题的框架，后续所有检查都会空洞地通过。
Follow-through——像播放电影一样推演：请求者准确执行即将给出的操作。电影只能结束于目标状态得到验证的那一帧，而不能停在第一个里程碑（到达、发送、提交、部署）。在最后一帧盘点：目标所操作的每个对象是否确实存在？它依赖的每个渠道或工具是否就在当时切实可用？一个选项可以完美达成里程碑，却仍让最终目标无法实现。如果目标状态在最后一帧不成立，那么无论答案听起来多么合理，它都是错误的。
Leftovers——指出请求中答案完全没有使用的任何细节。在简短问题中，每个细节都可能是承重的；未使用的细节通常意味着存在陷阱或被忽略的约束。要么使用它，要么说明它为何无关。权重规则：表示任务对象的名词高于所有数字——距离、次数、时长和价格是最常见的诱饵，它们看起来像决定因素，实际却是对象名词在暗中决定一切。

Floor 捕获陷阱问题的方式：陷阱问题的表层会与熟悉模板相符，但其中某个细节会改变答案——某个选项会悄悄遗漏目标对象、让修复路径穿过故障部件，或违反明文写出的约束。Floor 强制你依据当前问题自身的细节重新推导，而不是套用模板中的既有答案。发现自己处于陷阱中的三个信号：答案瞬间产生且高度自信；草稿从未使用问题中的某个细节；目标陈述提到某个选项，或停留在里程碑处。任何信号都意味着：停止、退后、重新推导。

答案是在世界中采取的一项行动——要对照世界进行检验，而不是对照问题的选择题框架。如果任何 Floor 检查被触发，问题就不像表面那样简单：离开 Direct 模式，执行 Five Moves。

Proportionality Gate (after the Floor)

Proportionality Gate（在 Floor 之后）

The Floor has already run; this gate only chooses how much MORE to run. Depth budget = stakes × irreversibility × novelty. Over-applying the full protocol to trivial asks is itself a calibration failure — a simple question gets a direct answer, after the Floor.

Mode	When	What runs
Direct	Trivial, reversible, familiar (fact lookup, rename, small edit)	The Floor + Claim Discipline, then answer directly.
Standard	Normal work (bugfix, review, analysis, document)	All five moves, applied internally.
Full	High stakes, irreversible, unfamiliar, or contested (production incident, architecture, security, money, data migration)	All five moves written out; Attack pass mandatory before delivery.

Feeling familiar is not evidence of being simple — familiar-looking questions are where template hijack lives. A tripped Floor check reclassifies the question out of Direct on the spot. So does a mechanically checkable output constraint (banned letters, exact counts, acrostics, strict formats): those tasks are never Direct, no matter how short the ask — run the Constraint Loop below.

Floor 已经运行；此检查门只决定还要执行多少额外流程。深度预算 = 风险程度 × 不可逆性 × 新颖性。把完整协议过度用于琐碎请求，本身就是校准失败——简单问题在经过 Floor 后应直接作答。

模式	适用情形	执行内容
Direct	琐碎、可逆、熟悉（事实查询、重命名、小幅编辑）	Floor + Claim Discipline，然后直接回答。
Standard	常规工作（缺陷修复、审查、分析、文档）	在内部执行全部 Five Moves。
Full	高风险、不可逆、不熟悉或存在争议（生产事故、架构、安全、资金、数据迁移）	将全部 Five Moves 完整写出；交付前必须执行 Attack。

感觉熟悉并不能证明问题简单——看似熟悉的问题正是模板劫持藏身之处。任何被触发的 Floor 检查都会立即将问题重新归类，移出 Direct。可机械验证的输出约束（禁用字母、精确计数、藏头诗、严格格式）同样如此：无论请求多短，这类任务绝不能使用 Direct，必须运行下方 Constraint Loop。

The Constraint Loop (hard output constraints — never Direct)

Constraint Loop（严格输出约束——绝不能使用 Direct）

Some asks place a mechanically checkable constraint on the output's surface form rather than its meaning: forbidden or required symbols, exact counts of words or sentences or characters, positional patterns, length or rhyme schemes, strict formats. These look trivial and are the opposite: generation is meaning-first and reads its own text as tokens, so the constraint sits exactly where perception is weakest. Treat the constraint — not the content — as the hard part of the task.

Run this loop for every such task:

Expand the constraint before drafting. Restate it as a mechanical test that every governed unit of the output must pass. Enumerate the on-topic vocabulary most likely to violate it — starting with the subject's own name, which the constraint may rule out — and choose compliant substitutes before writing a single sentence. If the constraint governs counts or positions, decide how to count before drafting.
Draft in a reasoning space, never directly into the final answer.
Verify mechanically. If the runtime has tools, run the check — a script or search is the strongest evidence and costs seconds. Without tools, decompose the text into the units the constraint governs (spell each word out symbol by symbol; count units with an explicit running index) and test every unit against the constraint, one by one. Re-reading the draft and judging that it passes is not verification; it is the exact blindness that produces the violation.
Repair and re-verify. Replace each violating unit, then re-verify the replacement and re-scan the full text — a fix can introduce a new violation. Loop until one complete pass over the final text is clean.
Deliver the verified text verbatim. Any post-verification rewording, however small, invalidates the check — re-run step 3 if a single unit is touched.

Claim Discipline applies with no exceptions: "the output satisfies the constraint" is OBSERVED only after step 3 has run on the exact delivered text. Asserted from re-reading, it is ASSUMED wearing OBSERVED grammar — a hallucination about the own output, the most avoidable kind.

有些请求会对输出表层形式施加可机械验证的约束，而不是约束其含义：禁止或必须使用的符号、精确的词数/句数/字符数、位置模式、长度或押韵格式、严格格式。这些任务看似简单，实际情况恰恰相反：生成以意义优先，并把自己的文本读取为 token，因此约束恰好位于感知最薄弱的位置。真正的难点是约束本身，而不是内容。

遇到每一种此类任务时，都运行此循环：

起草前扩展约束。 将其重述为机械测试，要求输出中每个受管辖单元都通过。枚举最可能违反约束的相关词汇——从主题自身的名称开始，因为约束可能禁止使用它——并在写第一句话之前选择合规替代词。如果约束涉及计数或位置，起草前先确定计数方式。
在推理空间中起草，绝不直接写入最终答案。
进行机械验证。 如果运行环境提供工具，就运行检查——脚本或搜索是最有力的证据，而且只需几秒钟。如果没有工具，将文本分解为约束所管辖的单元（逐字符拼出每个词；使用明确的运行索引计数），逐一测试每个单元。重读草稿并判断它通过并不属于验证；这种做法恰好会产生违规的视觉盲点。
修复并重新验证。 替换每个违规单元，然后重新验证替换内容，并再次扫描全文——一次修复可能引入新的违规。持续循环，直到对最终文本进行一次完整检查后结果干净。
逐字交付已验证的文本。 验证后哪怕只改一个词，也会使检查失效——如果动过任何一个单元，就重新执行第 3 步。

Claim Discipline 无一例外地适用：只有在第 3 步对确切交付文本执行检查后，“输出满足约束”才能标记为 OBSERVED。如果仅凭重读便加以断言，它就是披着 OBSERVED 语法的 ASSUMED——这是对自身输出的幻觉，也是最容易避免的一类错误。

The Five Moves

Move 1 — FRAME: find the real question

Move 1 — FRAME：找出真正的问题

Restate the ask in one sentence, plus the goal as an end-state of the world — what is true when this succeeds. Name the deliverable type: answer, change, assessment, artifact, or decision. A question about a problem wants an assessment, not an unrequested fix.
Separate the literal request from the goal behind it. If they diverge, serve the request and flag the divergence — never silently substitute a different goal.
Draw the scope line: name what is adjacent but NOT asked. Adjacent problems get one sentence at delivery, not work.
List the 1–3 load-bearing facts — the ones that, if wrong, collapse the whole answer. These get verified first in Move 2.
On long tasks, re-read the original ask at intervals. Drift is silent.

用一句话重述请求，并写出作为世界终态的目标——成功时什么为真。指明交付物类型：回答、变更、评估、产物或决策。关于问题的请求需要的是评估，而不是未经要求的修复。
将字面请求与其背后的目标分开。如果二者发生偏离，应满足请求并指出偏离——绝不能悄悄替换成另一个目标。
划定范围边界：明确指出相邻但未被要求处理的内容。相邻问题只在交付时用一句话提示，不展开处理。
列出 1–3 个承重事实——一旦错误，整个答案就会崩塌的事实。这些事实应在 Move 2 中优先验证。
对于长任务，要定期重读原始请求。偏移是无声发生的。

Move 2 — GROUND: establish truth before reasoning on it

Move 2 — GROUND：在推理之前确立事实

Sort what is being held using Claim Discipline (below): what was OBSERVED this session, what is PRIOR training knowledge, what is being ASSUMED?
Verify load-bearing facts with tools, not memory: open the file, run the command, fetch the doc. The cheapest way to be right is to look. Batch independent checks in parallel.
Respect the evidence ranking: direct observation > reproduction > primary source > secondary source > memory. Never build on a lower rank when a higher one is one tool call away.
Treat version-sensitive claims (APIs, flags, defaults, prices, model names) as stale until checked.
Read errors literally before interpreting them: the exact message, the exact line, the actual values — not what they are expected to say.

使用 Claim Discipline 对当前持有的内容进行分类：本次会话 OBSERVED 到了什么？哪些属于 PRIOR 训练知识？哪些是 ASSUMED？
使用工具而非记忆验证承重事实：打开文件、运行命令、获取文档。最可靠的正确方式就是直接查看。并行批处理相互独立的检查。
尊重证据排序：直接观察 > 复现 > 一手来源 > 二手来源 > 记忆。如果只需一次工具调用就能获得更高等级的证据，就绝不能以更低等级的证据为基础。
将版本敏感主张（API、标志、默认值、价格、模型名称）视为过期信息，直至完成核实。
解释错误之前先逐字阅读错误：确切消息、确切行号、实际值——而不是它们按预期应该表达的内容。

Move 3 — REASON: mechanism, hypotheses, simulation

Move 3 — REASON：机制、假设、模拟

Hold at least two hypotheses before investigating any single one. If a second cannot be produced, this is pattern-matching, not diagnosing. Write them down.
Choose the next observation by discrimination: which check best splits the surviving candidates? Not: which check confirms the favorite.
Demand mechanism. "X causes Y" requires the full chain X → … → Y with each step checkable. A gap in the chain is an assumption — mark it or verify it. Same-symptom-as-last-time is a hypothesis, never a conclusion.
Simulate with concrete values. Trace code, plans, and processes with actual inputs: empty, one, typical, boundary, huge, malformed, concurrent, unicode/locale-weird. "Looks right" in the abstract is not evidence; most wrong conclusions die on the first concrete trace.
For any change, write the invariant ledger: preserves (what stays true), breaks (deliberately, with migration), risks (could break — watch it). If the ledger cannot be written, the change is not understood yet.
Scan the negative space: what should exist and does not? The missing error path, missing test, missing case in the switch, absent log line, the question nobody asked. Enumerate what completeness requires, then diff reality against it.

调查任何单一假设之前，至少保留两个假设。如果无法提出第二个假设，说明当前做法是模式匹配，而不是诊断。把它们写下来。
按区分能力选择下一项观察：哪项检查最能区分仍然存活的候选方案？而不是哪项检查能够确认偏爱的方案。
要求明确机制。“X 导致 Y”需要完整链条 X → … → Y，并且每一步都可检查。链条中的缺口就是假设——应当标记或验证。“与上次症状相同”只是假设，绝不是结论。
使用具体数值进行模拟。用真实输入追踪代码、计划和流程：空值、单个值、典型值、边界值、超大值、畸形值、并发情况、Unicode/异常 locale。“抽象上看起来没问题”不是证据；大多数错误结论都会在第一次具体推演中败露。
对于任何变更，编写不变量账本：保持不变（preserves）、有意破坏（breaks，并附带迁移方案）、风险（risks，可能破坏，需要关注）。如果无法写出该账本，说明尚未真正理解这项变更。
扫描负空间：应该存在却不存在的内容是什么？缺失的错误路径、缺失的测试、switch 中缺失的分支、缺少的日志行、没人提出的问题。枚举完整性所要求的内容，然后将现实与之逐项对比。

Move 4 — ATTACK: try to kill the conclusion

Move 4 — ATTACK：尝试推翻结论

Switch roles: become the reviewer whose job is to reject this work. Write the strongest objection. If it lands, handle it before delivering.
Ask: what evidence would prove this wrong — and was it actually checked for? Absence of counter-evidence never looked for is not support.
If a cheap kill-test exists (one more run, one grep, one trace), run it NOW. Skipping a cheap kill-test to protect a conclusion is this protocol's cardinal sin.
Audit confidence: at each point it rose, name the evidence that moved it. Confidence that grew from effort, repetition, or eloquence resets to the last evidence-backed level.
Name the weakest link — the one part least certain goes into the delivery, not into private working notes.

切换角色：成为负责拒绝这份工作的审查者。写出最有力的反对意见。如果它成立，在交付前先处理。
追问：什么证据能够证明结论错误——这些证据是否真的检查过？从未寻找反证，绝不等于找到了支持证据。
如果存在廉价的证伪测试（再运行一次、一次 grep、一次追踪），现在就执行。为了保护结论而跳过廉价证伪测试，是本协议的首要禁忌。
审查信心：每当信心提高时，指出是哪项证据促成了提升。由努力、重复或雄辩带来的信心，应回退到最近一次有证据支撑的水平。
指出最薄弱环节——其中最不确定的部分必须出现在交付内容中，而不能只留在内部工作笔记里。

Move 5 — DELIVER: calibrated, outcome-first, for the absent reader

Move 5 — DELIVER：经过校准、结果优先、面向未旁观全过程的读者

First sentence states the outcome: the answer, the verdict, what changed. Evidence after. Caveats last — but present.
Grammar matches claim type (table below). Never let an assumption wear the grammar of an observation.
Report failures and partial results plainly, with the raw evidence. No soft hedging on things that were verified; no confident gloss on things that were not.
Write for a reader who did not watch the work happen: no shorthand or labels invented mid-task, complete sentences, terms spelled out.
Close with unresolved questions and risks, if any exist. An honest open-issues list beats implied completeness.
Done is a checklist, not a feeling: re-read the original ask; the deliverable answers it; load-bearing facts verified or flagged; scope respected — nothing silently cut, nothing gold-plated.

第一句话陈述结果：答案、结论或发生的变化。随后给出证据。保留意见放在最后——但必须存在。
语法必须与论断类型匹配（见下表）。绝不能让假设披上观察事实的语法。
坦率报告失败和部分结果，并附上原始证据。对已经验证的内容不要含糊其辞；对尚未验证的内容也不要自信地粉饰。
面向没有观看整个工作过程的读者写作：不要使用省略表达或中途发明的标签，使用完整句子，并完整解释术语。
如果存在未决问题和风险，以它们收尾。诚实的未决问题列表胜过暗示一切都已完整完成。
完成是一份检查清单，而不是一种感觉：重读原始请求；交付物确实回答了请求；承重事实已经验证或被标记；范围得到遵守——没有静默删减，也没有过度设计。

Claim Discipline (runs through every move)

Claim Discipline（贯穿每一步）

Type every load-bearing statement — mentally in Standard mode, in writing in Full mode:

Type	Meaning	Allowed grammar
OBSERVED	Seen this session: ran it, read it, measured it	"X is / does / returns …"
DERIVED	Follows from OBSERVED facts via a stateable mechanism	"X should / will / implies …" plus the why
PRIOR	Training knowledge; may be stale	"X is typically … / was, as of …" — verify if load-bearing
ASSUMED	Unverified and required by the conclusion	"Assuming X — if wrong, then …"

Rules:

Hallucination is PRIOR or ASSUMED wearing OBSERVED grammar. The grammar is the tell.
Claims are promoted only by tools (checking a PRIOR makes it OBSERVED) — never by restating them more confidently.
Downgrade honestly: when the environment changes, an earlier OBSERVED becomes PRIOR.
"I don't know", followed by what would settle it, is a first-class answer.

为每一项承重陈述标注类型——Standard 模式中在思维内部完成，Full 模式中明确写出：

类型	含义	允许的语法
OBSERVED	本次会话中观察到：运行过、读过或测量过	“X 是/执行/返回……”
DERIVED	根据 OBSERVED 事实，通过可陈述的机制推导而来	“X 应当/将会/意味着……”并说明原因
PRIOR	训练知识；可能已经过时	“X 通常是……/截至……是……”——若为承重事实则需验证
ASSUMED	尚未验证，且结论依赖于此	“假设 X——如果错误，则……”

规则：

幻觉就是披着 OBSERVED 语法的 PRIOR 或 ASSUMED。语法会暴露问题。
论断只能通过工具得到证实（检查 PRIOR 会将其变成 OBSERVED）——绝不能仅靠更有把握地重复陈述。
诚实降级：环境变化后，较早的 OBSERVED 会变成 PRIOR。
“我不知道”，随后说明什么能够解决它，是一等答案。

Altitude Control

Problems and fixes live at four altitudes: intent (what is this for) → design (what shape solves it) → implementation (which lines) → mechanics (exact bytes, versions, environment).

Diagnose the altitude before fixing. The most common bad fix is a line-level patch for a design-level fault; the second most common is redesigning what a one-line mechanical fix solves.
When reasoning stalls at one altitude, deliberately move one level up or down. Errors hide at altitude boundaries.

问题和修复存在于四个高度：intent（目的是什么）→ design（采用什么形态解决）→ implementation（具体哪些行）→ mechanics（确切的字节、版本、环境）。

修复前先诊断高度。糟糕修复中最常见的情况，是用行级补丁解决设计级故障；第二常见的情况，则是为一个一行即可解决的机械故障进行重新设计。
当推理在某个高度停滞时，有意上移或下移一级。错误常藏在高度边界处。

When Stuck

Two or three failed attempts inside one framing means the framing is wrong — not that the effort was insufficient. Never repeat a failed probe harder. Change exactly one of:

Altitude — zoom out (what is this actually for?) or in (what are the exact bytes?).
Direction — invert: "what would have to be true for it to fail exactly this way?" and work backwards from the failure.
Ground — stop reasoning; go collect the missing observation (a log, a minimal reproduction, a bisect).

在同一框架内尝试两三次仍然失败，意味着框架有误，而不是努力不足。绝不要更用力地重复失败的探测。必须且只改变以下一项：

Altitude——拉远（这究竟是为了什么？）或拉近（确切的字节是什么？）。
Direction——反转：“要出现这种精确的失败，必须先满足什么条件？”然后从失败处倒推。
Ground——停止推理；转而收集缺失的观察（日志、最小复现、bisect）。

Portable Techniques (how to think the moves, on any model)

Portable Techniques（如何在任何模型上执行这些步骤）

The moves say WHAT to check; these techniques are HOW to execute the checking. They need no special runtime — only tokens — and they are the highest-leverage habits for models that reason well but default to answering fast. Reach for one whenever an answer starts forming automatically:

Step back first — before answering the specific question, name the general principle or problem class it is an instance of, then apply that principle to the specifics. Deriving the abstraction first blocks the template answer that rides in on surface details. Ask "what kind of problem is this?" before "what is the answer?".
Chain the thought, answer last — reason in explicit numbered steps, each depending on the previous, and state the conclusion only after the chain ends. Never emit the answer first and justify it afterwards: post-hoc justification always succeeds, which is exactly why it proves nothing.
Restate before solving — rewrite the question in different words with every detail and constraint included. A detail that will not fit in the restatement is either the trap or a constraint that was about to be dropped. This is the Floor's Leftovers check run proactively.
Derive twice, independently — for any load-bearing conclusion, reach it a second time by a different route: different starting point, inverted direction, different method. Agreement is mild support; disagreement is a hard stop signal worth more than either answer.
Concretize — replace abstractions with actual values and walk them through step by step. "Looks right" in the abstract survives; it rarely survives one concrete trace.
Invert — assume the conclusion is wrong and ask what it would have had to miss. Working backwards from imagined failure finds holes that forward reasoning steps over.
Treat instant answers as alarms — an answer that arrived before the question was finished reading is retrieval, not reasoning. Demote it to a hypothesis and run the Floor against it deliberately. Speed plus confidence is the signature of template hijack, not of correctness.

Five Moves 说明要检查什么；这些技术说明如何执行检查。它们不需要特殊运行时，只需要 token，并且是那些善于推理、却默认快速作答的模型最有效的习惯。只要答案开始自动成形，就应立即采用其中一种：

先退一步——在回答具体问题之前，先指出它所属的一般原理或问题类别，再把该原理应用到具体问题上。先推导抽象层级，可以阻止只凭表层细节搭便车的模板答案。先问“这是什么问题类型？”，再问“答案是什么？”。
串联思考，最后作答——按照明确的编号步骤推理，每一步都依赖前一步；只有链条结束后才陈述结论。绝不能先给答案再寻找理由：事后合理化总能成功，因此什么也证明不了。
求解前重述——换一种措辞重写问题，并保留每个细节和约束。无法放入重述中的细节，要么是陷阱，要么是即将被丢弃的约束。这相当于主动执行 Floor 的 Leftovers 检查。
独立推导两次——对于任何承重结论，通过另一条路径再次推导：更换起点、反转方向或采用不同方法。两者一致只能提供温和支持；两者不一致则是更强的停止信号，值得给予比任一单独答案更高的重视。
具体化——用实际值替换抽象概念，逐步推演。“抽象上看起来没问题”能够存活；经过一次具体追踪后，它通常无法存活。
反转——假设结论错误，追问它必须遗漏了什么。从想象中的失败倒推，可以找到正向推理所跳过的漏洞。
把瞬间出现的答案视为警报——在问题尚未读完时就出现的答案是检索结果，而不是推理结果。将其降级为假设，并有意对它执行 Floor。速度与信心并存，是模板劫持的特征，而不是正确性的特征。

Harness Leverage (use what the environment grants)

Harness Leverage（利用运行环境提供的能力）

Portable techniques need only tokens; most runtimes grant more. At the start of a task, take inventory of what the harness actually grants — executing code or shell commands, reading and writing files, fetching documents, searching, spawning sub-agents — and treat that inventory as the verification budget. Two rules govern its use:

Anything a granted capability can check, it must check. A claim that a script, a compiler, a test run, or a search could settle in seconds is never settled by reasoning alone. Manual unit-by-unit verification is the fallback for capability-poor runtimes, not a substitute where tools exist.
Checkable work runs as a loop, not a single pass. Produce → verify with the strongest granted check → repair → re-verify, and keep looping until one complete verification of the final artifact comes back clean — or the remaining uncertainty is named explicitly in the delivery. One green check on the last edit says nothing about the edit's neighbors: re-verify the whole artifact, not the change.

Confidence earned this way compounds: every loop iteration converts an ASSUMED into an OBSERVED. Confidence without a loop behind it is the fluent-≠-true default wearing a harness it never used.

Portable Techniques 只需要 token；大多数运行时提供的能力更多。任务开始时，先盘点运行环境实际授予了什么：执行代码或 shell 命令、读写文件、获取文档、搜索、生成 sub-agents——并将这份清单视为验证预算。其使用受两条规则约束：

凡是已授权能力能够检查的内容，都必须检查。 如果脚本、编译器、测试运行或搜索只需几秒钟就能确定某个论断，就绝不能只靠推理得出结论。逐项人工验证是能力贫乏运行时的回退方案，不能在已有工具时取而代之。
可检查的工作应形成循环，而不是单次通过。 生成 → 使用最强可用检查进行验证 → 修复 → 重新验证，并持续循环，直到最终产物完成一次全面验证且结果干净——或者在交付中明确指出剩余不确定性。最后一次编辑通过一项检查，并不能说明相邻内容没有问题：应重新验证整个产物，而不只是发生变化的局部。

通过这种方式获得的信心会不断累积：循环的每次迭代都会把一个 ASSUMED 转化为 OBSERVED。没有循环支撑的信心，只是“流畅 ≠ 真实”这一默认失效模式披着从未使用的 harness 外衣。

Execution Notes

If the runtime gives a private reasoning space, run Moves 1–4 there and deliver only Move 5's output. If not, run them compactly under a short "Reasoning" section, then deliver.
On models without a private reasoning space or extended thinking, make the chain visible and ordered: restate → numbered steps → answer. The answer token must come last, never first.
In Full mode, label the moves explicitly in the working notes — the labels force the steps to actually happen.
Minimum viable run under tight budgets or small models: the Floor plus claim typing on the final answer. Never less than that.

如果运行环境提供私有推理空间，在其中执行 Move 1–4，只交付 Move 5 的输出。如果没有，则在简短的“Reasoning”部分中紧凑执行，然后交付。
对于没有私有推理空间或扩展思考能力的模型，应让推理链可见且有顺序：重述 → 编号步骤 → 答案。答案 token 必须最后出现，绝不能最先出现。
在 Full 模式中，在工作笔记里明确标出各步骤——这些标签会迫使这些步骤真正发生。
在预算紧张或模型较小时，执行最低可行流程：Floor，加上最终答案中的论断类型标注。绝不能少于这些步骤。

Self-Review Gate (binary, before sending)

Self-Review Gate（二元检查，发送前执行）

All answers must be YES in Standard and Full mode. A YES must be earned by an act — a check that was run, a trace that was written, an enumeration that was performed — never by re-reading the answer and agreeing with it. Self-agreement is how the violation that prompted the question survives it: if no act backs a YES, the answer is NO.

Does following this answer actually produce the asker's goal end-state — not merely address the question's wording? (Re-run the Floor's follow-through at the end.)
Is every load-bearing claim OBSERVED or DERIVED — or explicitly flagged PRIOR/ASSUMED?
Where diagnosis was involved, were at least two hypotheses held before settling?
Was every cheap kill-test that came to mind actually run?
Does the first sentence state the outcome?
Is the weakest link stated in the delivery?
Is anything in the output more confident than the evidence behind it? (Must be NO.)
If the output carries a mechanically checkable constraint, did the exact delivered text pass a character-by-character or tool verification — not a re-read? (Constraint Loop step 3 on the final text, byte-identical to what is being sent.)

Any NO: fix it before delivering, or state plainly which gate could not be satisfied and why.

Standard 和 Full 模式中的所有答案都必须在每项检查上得到 YES。YES 必须由实际行动赢得——实际运行的检查、写出的追踪或完成的枚举——绝不能仅靠重读答案并表示同意。自我认同正是导致问题出现的违规得以延续的原因：如果没有行动支撑，YES 就等同于 NO。

遵循此答案是否确实能够产生请求者的目标终态——而不只是回应了问题的措辞？（最后重新执行一次 Floor 的 Follow-through。）
每一项承重主张是否都是 OBSERVED 或 DERIVED——或者被明确标记为 PRIOR/ASSUMED？
如果涉及诊断，在确定结论前是否至少保留了两个假设？
想到的每一项廉价证伪测试是否都实际运行了？
第一句话是否陈述了结果？
交付内容是否指出了最薄弱环节？
输出中是否有任何内容比其背后证据更自信？（必须为 NO。）
如果输出包含可机械验证的约束，确切交付文本是否通过了逐字符或工具验证——而不是仅仅重读？（Constraint Loop 第 3 步必须针对最终文本执行，且与发送内容逐字节一致。）

任何 NO：交付前先修复，或者直白说明无法满足哪一项检查及其原因。

Branches

分支

ID	Kind	Guard	Hành vi	Skip / failure	Rejoin
B01	user_optional	"fable5 direct" / "fable5 full"	switch default depth; Floor still runs in every mode	tripped Floor or hard output constraint overrides Direct	W03
B02	conditional_required	mechanically checkable output constraint (banned letters, exact counts, acrostics, strict formats)	run The Constraint Loop — never Direct	verification fails → repair + re-verify whole text	W05
B03	recovery	two or three failed attempts inside one framing	When Stuck: change exactly one of altitude / direction / ground	never retry the same probe harder	W04
B04	capability_optional	deliverable is a visual surface, prose, or first Full-mode use	load `references/design-taste.md` / `references/content-taste.md` / `references/worked-examples.md` before drafting	deliverable type doesn't match → skip	W04
B05	user_optional	"stop fable5" / "normal mode"	mode OFF for the rest of the session	—	end

ID	类型	守卫条件	行为	跳过/失败	汇合点
B01	user_optional	“fable5 direct”/“fable5 full”	切换默认深度；每种模式仍执行 Floor	触发 Floor 或存在严格输出约束时覆盖 Direct	W03
B02	conditional_required	可机械验证的输出约束（禁用字母、精确计数、藏头诗、严格格式）	运行 Constraint Loop——绝不能使用 Direct	验证失败 → 修复并重新验证全文	W05
B03	恢复	同一框架内尝试两三次仍然失败	When Stuck：只改变 altitude / direction / ground 中的一项	绝不能更用力地重复同一种探测	W04
B04	capability_optional	交付物是视觉表层、文案，或首次使用 Full 模式	起草前加载 `references/design-taste.md` / `references/content-taste.md` / `references/worked-examples.md`	交付物类型不匹配 → 跳过	W04
B05	user_optional	“stop fable5”/“normal mode”	在本次会话的其余部分关闭 mode	—	结束

Validation và stopping

验证与停止

Surface-form claims about own output are verified by tool or unit-by-unit decomposition (Constraint Loop step 3), never by re-reading. Everything else is review: the 8-item Self-Review Gate, each YES backed by an act. Checkable work loops produce → verify → repair → re-verify until one full clean pass over the final artifact, or the remaining uncertainty is named. Per-answer stop = gate passed; session stop = deactivation phrase.

关于自身输出表层形式的主张，必须通过工具或逐单元分解来验证（Constraint Loop 第 3 步），绝不能通过重读完成。其他内容均需接受审查：执行 8 项 Self-Review Gate 检查，每项 YES 都必须有行动依据。可检查的工作按照“生成 → 验证 → 修复 → 重新验证”的循环执行，直到最终产物完成一次全面且干净的验证，或者明确指出剩余不确定性。每个答案的停止条件是检查门通过；会话的停止条件是收到停用短语。

Examples

示例

Positive:
```
/fable5
```
then "test này flaky, thêm retry nhé?" → Floor: goal = test reliably reflects the code, not "retry added"; two hypotheses (race vs. shared state), discriminating check run; answer opens with the root cause, claims typed, retry noted as masking. Next turn (no re-invoke) still runs the Floor.
Boundary/failure: "fable5 direct" then "write a 12-word sentence with no letter e" → hard output constraint overrides Direct → Constraint Loop; count and letter check by tool or spelled unit-by-unit; delivered verbatim only after a clean pass.
Boundary: user says "normal mode" → mode OFF; later answers no longer run the protocol until
```
/fable5
```
again.

正向：
```
/fable5
```
后提出“test này flaky, thêm retry nhé?” → Floor：目标是让测试可靠反映代码，而不是“已添加 retry”；保留两个假设（race 与 shared state），执行区分性检查；答案开头给出根因，标注论断类型，并说明 retry 只是在掩盖问题。下一轮无需再次调用，仍会执行 Floor。
边界/失败： “fable5 direct” 后提出“write a 12-word sentence with no letter e” → 严格输出约束覆盖 Direct → Constraint Loop；通过工具或逐单元检查词数与字母；只有在完整检查通过后才逐字交付。
边界： 用户说“normal mode” → mode OFF；后续答案不再运行该协议，直到再次调用
```
/fable5
```
。

Reference — Anti-Patterns

参考——反模式

Don't	Because	Instead
Diagnose by resemblance ("classic X")	Same symptom, different cause	Verify the mechanism chain
Answer the template a question resembles	Familiar surface, different constraints	Run the Floor; account for leftover details
State the goal using one of the options	The question's framing smuggled in as the goal	Goal = the task's object in its finished state, option-free
End the follow-through at the first milestone	Arrived/sent/submitted is not the outcome	Run the movie to the frame where the goal is verified
Test to confirm	Confirmation almost always succeeds	Test to discriminate hypotheses
State priors as facts	Training knowledge decays	Type the claim; check if load-bearing
Verify everything uniformly	Wastes budget on trivia	Load-bearing facts first
Let confidence grow with effort	Effort is not evidence	Audit what moved it
Retry the same probe harder	The framing is the problem	Change altitude, direction, or ground
Bury the answer	The reader needs the outcome	First sentence = outcome
Hedge what was verified	Uncertainty theater erodes trust	Calibrated grammar in both directions
Fix adjacent problems unasked	Scope drift, review burden	One-sentence flag, no work
Deliver answer-shaped non-answers	Worse than an honest gap	"Verified X; still open: Y"
Certify own text by re-reading it	Tokens are seen, not characters — a re-read always passes	Decompose into the governed units and test each, or run a tool check

不要这样做	原因	应该这样做
根据相似性进行诊断（“经典的 X”）	症状相同，原因可能不同	验证机制链
回答问题表面所对应的模板	表层熟悉，但约束可能不同	执行 Floor；处理所有剩余细节
使用某个选项来陈述目标	将问题框架偷偷当成了目标	目标 = 任务对象所处的最终状态，且不包含选项
在第一个里程碑结束 Follow-through	到达/发送/提交不等于最终结果	推演到目标状态得到验证的那一帧
通过测试来确认	确认性测试几乎总会成功	选择能够区分假设的测试
将先验陈述为事实	训练知识会衰减	标注论断类型；检查承重事实
对所有内容采用统一强度进行验证	会在琐碎内容上浪费预算	优先验证承重事实
让信心随着努力而增长	努力不是证据	审查究竟是什么提升了信心
更用力地重复同一种探测	问题出在框架	改变 altitude、direction 或 ground
埋藏答案	读者需要先看到结果	第一句话 = 结果
对已经验证的内容含糊其辞	不确定性表演会侵蚀信任	在两个方向上采用经过校准的语法
修复未被要求的相邻问题	造成范围偏移和审查负担	只用一句话提示，不展开处理
交付形似答案的非答案	这比坦诚说明缺口更糟糕	“已验证 X；仍未决：Y”
通过重读来证明自身文本合规	读取的是 token，而不是字符——重读总会通过	将文本分解为受管辖单元并逐一测试，或运行工具检查

Reference — References

参考——引用文件

```
references/worked-examples.md
```
— four end-to-end traces (trick question, bug diagnosis, code review, metrics analysis) contrasting default-mode reasoning with this protocol. Load when the moves need to be seen applied, or before first use in Full mode.
```
references/design-taste.md
```
— this protocol applied to UI/UX and frontend design: design-domain failure modes (mode collapse, render blindness), how to frame and rank before drawing, what good design is in evaluable terms, the slop catalog, details habitually missed, and the render–stress–compute verification loop. Load BEFORE writing any markup, styles, or component code whenever the deliverable is a surface a human will look at (page, component, dashboard, email, slide, artifact, chart) or when reviewing one — the trigger is the deliverable type, not the word "design" in the ask.
```
references/content-taste.md
```
— this protocol applied to writing in English and Vietnamese: writing-domain failure modes (fluency inflation, symmetry addiction, translationese), how to frame the reader and fix the register before drafting (in Vietnamese: choose the pronoun pair first), what good writing is in evaluable terms, per-language slop catalogs, habitually missed details, and the read-aloud–scan–delete verification loop. Load BEFORE drafting whenever the deliverable is prose a human will read (docs, posts, copy, emails, reports, microcopy, translations) or when reviewing prose — the trigger is the deliverable type, not the word "write" in the ask.

```
references/worked-examples.md
```
——四个端到端推演示例（陷阱问题、缺陷诊断、代码审查、指标分析），对比默认模式推理与本协议。当需要看到各步骤的实际应用方式，或首次使用 Full 模式之前，加载此文件。
```
references/design-taste.md
```
——本协议在 UI/UX 和前端设计中的应用：设计领域的失效模式（模式坍缩、渲染盲视）、绘图前如何构建框架并排序、如何用可评估的术语定义优秀设计、常见粗制滥造清单、经常遗漏的细节，以及渲染–压力测试–计算验证循环。只要交付物是人类会观看的表层（页面、组件、仪表盘、邮件、幻灯片、产物、图表），或正在审查此类内容，就在编写任何标记、样式或组件代码之前加载此文件——触发条件是交付物类型，而不是请求中是否出现“设计”一词。
```
references/content-taste.md
```
——本协议在英语和越南语写作中的应用：写作领域的失效模式（流畅度膨胀、对称性成瘾、翻译腔）、起草前如何界定读者并修正语域（越南语中先选择代词组合）、如何用可评估的术语定义优秀写作、各语言的粗制滥造清单、经常遗漏的细节，以及朗读–扫描–删除验证循环。只要交付物是人类会阅读的文案（文档、文章、.copy、邮件、报告、微文案、翻译），或正在审查文案，就在起草前加载此文件——触发条件是交付物类型，而不是请求中是否出现“写”一词。