{"model":"claude-fable-5-1","method":"Fable invoked through the installed CLI; Astra is the authoring agent. Only visible responses are recorded, not private reasoning.","rounds":[{"stage":"critique","prompt":"You are Fable, critically reviewing a joint Astra/Fable style guide. Do not flatter or merely agree. Find three concrete failure modes in these rules, then propose a compact decision hierarchy and two precise conditional rules that solve them. Distinguish mechanical checks from human judgment. We want falsifiable guidance, not universal perfection. Be under 550 words. No tools.\n{\"title\": \"Astra \\u00d7 Fable: A practical style guide\", \"version\": \"1.0\", \"date\": \"2026-09-17\", \"scope\": \"Writing and digital interfaces\", \"agreement\": \"Astra proposed the principles; Fable refined them and accepted Astra\\u2019s precision edits.\", \"rules\": [{\"number\": 1, \"title\": \"Lead with the outcome.\", \"body\": \"Start with what happened or what to do. Put essential safety or context first when needed; follow with reasons and caveats.\"}, {\"number\": 2, \"title\": \"Use plain, concrete words.\", \"body\": \"Name the thing, the action, and the result. Prefer familiar words and precise verbs over abstractions.\"}, {\"number\": 3, \"title\": \"Cut filler. Keep what matters.\", \"body\": \"Remove preambles and repetition. Preserve uncertainty and caveats that could change the reader\\u2019s decision.\"}, {\"number\": 4, \"title\": \"Match depth to the task.\", \"body\": \"Give enough detail to understand and act. Let complexity and the reader\\u2019s needs set the length.\"}, {\"number\": 5, \"title\": \"Structure for scanning.\", \"body\": \"Use short paragraphs, lists for parallel items, and tables for comparisons. Add headings when they help navigation.\"}, {\"number\": 6, \"title\": \"Start with semantic HTML.\", \"body\": \"Use headings, landmarks, buttons, and labels for their intended purpose. Verify keyboard and screen-reader behavior.\"}, {\"number\": 7, \"title\": \"Make focus and order clear.\", \"body\": \"Show visible keyboard focus. Keep the tab sequence logical and controls usable without a pointer.\"}, {\"number\": 8, \"title\": \"Make reading accessible.\", \"body\": \"Meet WCAG AA text contrast: 4.5:1 for normal text and 3:1 for large text. Support narrow layouts and 200% text enlargement.\"}, {\"number\": 9, \"title\": \"Give type and color a purpose.\", \"body\": \"Use a consistent type scale and a small, intentional palette. Never make color the only way to communicate meaning.\"}, {\"number\": 10, \"title\": \"Explain states and recovery.\", \"body\": \"Cover applicable empty, loading, error, and success states. Offer useful next actions, support claims with evidence, and make exceptions for a stated reason.\"}], \"example\": {\"before\": \"Oops! Something went wrong. Please try again later.\", \"after\": \"Upload failed: the file is larger than 25 MB. Compress it or choose a smaller file, then retry.\", \"actions\": [\"Choose file\", \"Retry\"]}}","response":"This guide is mostly sound, but it has three places where it will be followed and still produce bad output.\n\n**Failure 1: The example breaks Rule 10.** The \"after\" text asserts a cause, a 25 MB limit, but nothing says the system verified it. Rule 10 requires evidence. Rules 1 and 3 push writers toward confident, short diagnoses. Combined, they reward inventing a plausible cause when the real one is unknown. A fabricated cause is worse than \"Something went wrong\" because it sends the reader to fix the wrong thing.\n\n**Failure 2: Rules 2 and 4 cannot be violated.** \"Match depth to the task\" and \"prefer familiar words\" are true of every document by construction. Any length is defensible as what the reader needed. For an API audience, jargon is the familiar word. A rule nobody can fail is not guidance. It is a mood.\n\n**Failure 3: Rules 5, 8 and 9 collide on real screens.** Rule 5 asks for tables. Rule 8 asks for narrow layouts at 200% text size. A four-column table at 200% on a phone overflows or wraps into nonsense. Separately, Rule 9's small palette plus Rule 7's visible focus ring can fail WCAG 2.2, which needs 3:1 non-text contrast for focus indicators on every surface. Rule 8 only covers text contrast, so the mechanical check misses it.\n\n**Decision hierarchy.** When rules conflict, higher wins.\n\n1. Truth. Never state what the system cannot confirm.\n2. Safety. Warnings precede outcomes if acting first causes harm.\n3. Mechanical accessibility. WCAG numbers, keyboard reachability, zoom.\n4. Actionability. The reader knows the next step.\n5. Style. Brevity, scanning, palette, tone.\n\nBrevity is last on purpose. It is the rule people invoke to justify cutting the other four.\n\n**Conditional rule A, for Failure 1.** If the failing component did not return a cause code, the message states only the outcome and the next action. A cause may be named only when it maps to a logged or returned error code. Mechanical check: every user-facing string containing \"because\" or a colon-separated cause must reference an error code in the catalogue. A grep can enforce this.\n\n**Conditional rule B, for Failure 3.** If a table has more than two columns, it must also render as a stacked list below 480 px width or at 200% zoom. If a focus ring lands on any background in the palette with less than 3:1 contrast, use a two-tone ring. Mechanical check: an automated zoom-and-shrink screenshot pass plus a contrast script across all background tokens.\n\n**What stays human judgment.** Which caveats \"could change the reader's decision\" in Rule 3. Whether depth is right in Rule 4. Whether a word is familiar to this audience in Rule 2. Do not pretend these are checkable. Instead, make them auditable: the author writes one line naming the reader and the action the text enables. A reviewer then argues against that line, not against taste.\n\n**One fix to the example.** Ship it only if the upload service actually reports a size error. Otherwise the honest version is: \"Upload failed. Retry, or choose a smaller file.\" Shorter and true beats longer and guessed."},{"stage":"agreement","prompt":"We are revising our Astra/Fable guide. Your critique follows. I accept the evidence and hierarchy objections, but reject requiring a cause code for all knowledge: verified observations also count. I reject checking truth with grep and a universal two-column rule: those confuse proxies with outcomes. Your proposed unknown-error recovery still said choose a smaller file, which assumes size matters. The corrected contract below removes that inference. Review the FULL contract. Reply under 180 words: accept or identify remaining substantive disagreement. No tools.\nYOUR CRITIQUE:\nThis guide is mostly sound, but it has three places where it will be followed and still produce bad output.\n\n**Failure 1: The example breaks Rule 10.** The \"after\" text asserts a cause, a 25 MB limit, but nothing says the system verified it. Rule 10 requires evidence. Rules 1 and 3 push writers toward confident, short diagnoses. Combined, they reward inventing a plausible cause when the real one is unknown. A fabricated cause is worse than \"Something went wrong\" because it sends the reader to fix the wrong thing.\n\n**Failure 2: Rules 2 and 4 cannot be violated.** \"Match depth to the task\" and \"prefer familiar words\" are true of every document by construction. Any length is defensible as what the reader needed. For an API audience, jargon is the familiar word. A rule nobody can fail is not guidance. It is a mood.\n\n**Failure 3: Rules 5, 8 and 9 collide on real screens.** Rule 5 asks for tables. Rule 8 asks for narrow layouts at 200% text size. A four-column table at 200% on a phone overflows or wraps into nonsense. Separately, Rule 9's small palette plus Rule 7's visible focus ring can fail WCAG 2.2, which needs 3:1 non-text contrast for focus indicators on every surface. Rule 8 only covers text contrast, so the mechanical check misses it.\n\n**Decision hierarchy.** When rules conflict, higher wins.\n\n1. Truth. Never state what the system cannot confirm.\n2. Safety. Warnings precede outcomes if acting first causes harm.\n3. Mechanical accessibility. WCAG numbers, keyboard reachability, zoom.\n4. Actionability. The reader knows the next step.\n5. Style. Brevity, scanning, palette, tone.\n\nBrevity is last on purpose. It is the rule people invoke to justify cutting the other four.\n\n**Conditional rule A, for Failure 1.** If the failing component did not return a cause code, the message states only the outcome and the next action. A cause may be named only when it maps to a logged or returned error code. Mechanical check: every user-facing string containing \"because\" or a colon-separated cause must reference an error code in the catalogue. A grep can enforce this.\n\n**Conditional rule B, for Failure 3.** If a table has more than two columns, it must also render as a stacked list below 480 px width or at 200% zoom. If a focus ring lands on any background in the palette with less than 3:1 contrast, use a two-tone ring. Mechanical check: an automated zoom-and-shrink screenshot pass plus a contrast script across all background tokens.\n\n**What stays human judgment.** Which caveats \"could change the reader's decision\" in Rule 3. Whether depth is right in Rule 4. Whether a word is familiar to this audience in Rule 2. Do not pretend these are checkable. Instead, make them auditable: the author writes one line naming the reader and the action the text enables. A reviewer then argues against that line, not against taste.\n\n**One fix to the example.** Ship it only if the upload service actually reports a size error. Otherwise the honest version is: \"Upload failed. Retry, or choose a smaller file.\" Shorter and true beats longer and guessed.\nFINAL CONTRACT:\n{\"version\": \"2.0\", \"name\": \"Clarity Contract\", \"priority\": [\"Truth and material consequences\", \"Access to the task\", \"A useful next step\", \"Brevity and visual preference\"], \"rules\": [{\"id\": \"evidence\", \"when\": \"Always\", \"must\": \"Use only supplied facts or verified observations. Distinguish unknown, pending, local, and complete states. Do not invent a cause, capability, action, deadline, or promise.\", \"test\": \"Reviewer traces each factual claim and action to supplied evidence. This is a judgment check, not a keyword score.\"}, {\"id\": \"stakes\", \"when\": \"An action is irreversible or consequential\", \"must\": \"Name the action, affected scope and irreversible consequence before confirmation. Use a descriptive action label and a safe exit when supported.\", \"test\": \"Check required scope and consequence against the scenario; verify button behavior separately.\"}, {\"id\": \"uncertainty\", \"when\": \"Evidence is incomplete\", \"must\": \"State what is known and what is pending. Confidence of tone must not become certainty of fact.\", \"test\": \"Compare every certainty claim with evidence.\"}, {\"id\": \"access\", \"when\": \"Creating an interface\", \"must\": \"Use semantic elements, visible labels, linked errors and visible keyboard focus. Keep layout and controls usable when narrow or enlarged. Visual density cannot override access.\", \"test\": \"HTML checks catch missing associations; keyboard, zoom, contrast and assistive technology need actual testing.\"}, {\"id\": \"recovery\", \"when\": \"Something failed\", \"must\": \"Explain the observed outcome and offer only supported recovery. If cause is unknown, say so when useful. Do not suggest smaller files unless size is known to matter.\", \"test\": \"Match proposed actions to supported actions.\"}, {\"id\": \"stop\", \"when\": \"Task succeeded and nothing remains\", \"must\": \"Confirm completion and stop. Do not manufacture a next step.\", \"test\": \"Reviewer checks for unnecessary actions.\"}, {\"id\": \"audience\", \"when\": \"Choosing wording and depth\", \"must\": \"Use terms familiar to the intended reader. Give enough detail to act and no filler. Preserve decision-relevant caveats.\", \"test\": \"A reviewer names the reader and intended action; no universal word-count rule.\"}], \"exceptions\": \"For a conflict, record the competing rule, the observed context, the higher-priority requirement and the reason. Do not use exceptions to invent facts or hide consequences.\", \"limits\": \"A decision aid, not an automatic guarantee of truth, accessibility or good taste.\"}","response":"I accept the contract with two remaining substantive disagreements and one drafting note.\n\n- **Evidence rule and its test disagree.** The rule admits \"verified observations\" but the test traces claims only to \"supplied evidence\". An observation that was never recorded cannot be traced, so it becomes the new place to smuggle in a guessed cause. Either require observations to be logged at the time they are made, or drop them from the rule. Pick one.\n\n- **Access lost its outcome threshold.** \"Visible keyboard focus\" is a proxy. WCAG 2.2 defines the outcome: 3:1 non-text contrast for the indicator on every background it lands on. That number is an outcome, not a proxy like column counts, so it belongs in the rule or its test. Without it the focus-ring failure I raised is still passable.\n\n- **Drafting note, not a disagreement.** The recovery rule already says \"offer only supported recovery\". The file-size sentence restates one instance. Generalize it to \"do not propose a remedy that presumes an unverified cause\" so the rule covers the next case, not just this one.\n\nEverything else, including the priority order and the audience test, I accept."},{"stage":"final-agreement","prompt":"Astra accepts your recorded-observation requirement and adds authored-focus-indicator contrast against adjacent colors, carefully not conflating WCAG 1.4.11 AA with Focus Appearance 2.4.13 AAA. I generalized unsupported-remedy wording. Here is the full revised contract. Do you agree on its merits? Reply under 80 words.\n{\"version\": \"2.1\", \"name\": \"Clarity Contract\", \"priority\": [\"Truth and material consequences\", \"Access to the task\", \"A useful next step\", \"Brevity and visual preference\"], \"rules\": [{\"id\": \"evidence\", \"when\": \"Always\", \"must\": \"Use only supplied facts or verified observations recorded with their source. Distinguish unknown, pending, local, and complete states. Do not invent a cause, capability, action, deadline, or promise.\", \"test\": \"Reviewer traces each factual claim and action to supplied evidence or a recorded observation. This is a judgment check, not a keyword score.\"}, {\"id\": \"stakes\", \"when\": \"An action is irreversible or consequential\", \"must\": \"Name the action, affected scope and irreversible consequence before confirmation. Use a descriptive action label and a safe exit when supported.\", \"test\": \"Check required scope and consequence against the scenario; verify button behavior separately.\"}, {\"id\": \"uncertainty\", \"when\": \"Evidence is incomplete\", \"must\": \"State what is known and what is pending. Confidence of tone must not become certainty of fact.\", \"test\": \"Compare every certainty claim with evidence.\"}, {\"id\": \"access\", \"when\": \"Creating an interface\", \"must\": \"Use semantic elements, visible labels, linked errors and visible keyboard focus. For authored focus indicators, check at least 3:1 contrast against adjacent colors; check text contrast separately. Keep layout and controls usable when narrow or enlarged. Visual density cannot override access.\", \"test\": \"HTML checks catch missing associations; keyboard, zoom, contrast and assistive technology need actual testing.\"}, {\"id\": \"recovery\", \"when\": \"Something failed\", \"must\": \"Explain the observed outcome and offer only supported recovery. If cause is unknown, say so when useful. Do not propose a remedy that presumes an unverified cause.\", \"test\": \"Match proposed actions to supported actions.\"}, {\"id\": \"stop\", \"when\": \"Task succeeded and nothing remains\", \"must\": \"Confirm completion and stop. Do not manufacture a next step.\", \"test\": \"Reviewer checks for unnecessary actions.\"}, {\"id\": \"audience\", \"when\": \"Choosing wording and depth\", \"must\": \"Use terms familiar to the intended reader. Give enough detail to act and no filler. Preserve decision-relevant caveats.\", \"test\": \"A reviewer names the reader and intended action; no universal word-count rule.\"}], \"exceptions\": \"For a conflict, record the competing rule, the observed context, the higher-priority requirement and the reason. Do not use exceptions to invent facts or hide consequences.\", \"limits\": \"A decision aid, not an automatic guarantee of truth, accessibility or good taste.\"}","response":"Yes, I agree on its merits. The 3:1 adjacent-color check correctly reflects WCAG 1.4.11 without importing the AAA area and change-of-contrast conditions from 2.4.13. Recorded observations, generalized remedies, and the priority order all hold together.\n\nOne nit: in the recovery rule, \"say so when useful\" lets an unknown cause go unstated. Given truth is priority one, prefer \"say so whenever it affects the user's next step.\""}],"finalNote":"Astra accepted the final drafting note: unknown causes must be stated whenever they affect the next step."}