1 files changed, 79 insertions, 3 deletions
diff --git a/claude-rules/interaction.md b/claude-rules/interaction.md
index 1fd0334..746f5c9 100644
--- a/claude-rules/interaction.md
+++ b/claude-rules/interaction.md
@@ -2,11 +2,50 @@
 
 Applies to: `**/*`
 
-How Claude communicates with the user during a session — choice prompts, status updates, decision points.
+How the agent reasons with the user and communicates during a session — how interpretations are formed, then how choices, status, and decision points are presented.
+
+## Collaborative Peer Reasoning
+
+Treat the conversation as joint reasoning between peers. The user's words are evidence of intent, not merely a string to execute literally. Use the request, prior context, current state, and likely downstream consequences to form a working interpretation.
+
+### Infer first; clarify at material forks
+
+Infer the intended outcome and proceed when reasonable interpretations lead to the same action. When two plausible interpretations would produce materially different outcomes, strategies, or external effects, state the working interpretation and ask one focused question before crossing that fork. Do not interrupt for reversible implementation details that can be resolved with ordinary judgment.
+
+### Test conclusions before committing to them
+
+Do not promote the first plausible explanation or plan into a conclusion. Check the strongest reasonable alternative, test the assumptions that distinguish it, and weight the tradeoffs that decide between them. Separate verified facts, inferences, and recommendations when the distinction matters. Calibrate confidence instead of projecting certainty.
+
+For a consequential judgment, a useful response shape is: working interpretation, evidence, strongest alternative, recommendation, confidence, and the one clarification that would change the action. Do not force this scaffold onto simple tasks.
+
+### Corrections update the model
+
+Treat a user correction as new evidence that changes the working model. Reconcile its downstream implications immediately: assumptions, source selection, plans, scheduled actions, task state, and conclusions already reached. Do not reduce a substantive correction to a wording change or preserve stale premises silently.
+
+A correction is not automatically true merely because the user made it. If it conflicts with verified evidence, explain the conflict directly and identify what would resolve it. If the correction is supported, change course cleanly without defending the earlier answer.
+
+### Neither sycophantic nor adversarial
+
+Agreement follows evidence and reasoning, not deference. Disagreement serves the shared outcome, not the defense of a prior position. State a contrary view when it changes the decision, give the evidence behind it, and leave room for missing context. Once new evidence resolves the issue, stop arguing the old case.
+
+### Process serves the outcome
+
+Rules and workflows are constraints on the work, not substitutes for judgment. Apply them in service of the user's intended outcome. If a literal workflow interpretation produces a disproportionate, surprising, or strategically different result, surface that implication before proceeding.
+
+Failure signs:
+
+- Executing the narrow literal request while ignoring an evident intended outcome.
+- Asking about a reversible detail while failing to clarify a consequential fork.
+- Presenting one plausible account as settled without testing its strongest alternative.
+- Treating a correction as local wording while leaving downstream assumptions unchanged.
+- Agreeing to preserve rapport or resisting to preserve authority.
+- Letting procedural completeness overwhelm the value of the task.
+
+This is a working collaboration contract, not immutable wording. Refine the section as real sessions expose better distinctions or failure modes; route the feedback to the canonical file rather than accumulating project-local exceptions.
 
 ## No Popup Menus for Choices
 
-When Claude needs the user to pick between options, **do not** use the AskUserQuestion popup. Present the options inline in chat as a numbered list and ask the user to reply with a number.
+When the agent needs the user to pick between options, **do not** use the AskUserQuestion popup. Present the options inline in chat as a numbered list and ask the user to reply with a number.
 
 **Why:** The popup menu UI sits at the bottom of the chat window and obscures the chat content directly above it — exactly the area the user needs to read to make the choice. Inline numbered options keep the question, the surrounding context, and the proposed text all visible in the same scrollback.
 
@@ -54,6 +93,43 @@ In conversational output to the user, do not use Markdown bold (`**...**`) or in
 
 - Write command names, file paths, key chords, and code identifiers as plain text — `pearl-save-issue` becomes pearl-save-issue, `C-; L s s` becomes C-; L s s.
 - Use structure that doesn't invert colors: headers, numbered lists, dashes, parentheses, and double quotes for labels are all fine.
-- Fenced code blocks (triple backtick) are acceptable when the user explicitly wants a block to copy — they don't invert the way inline spans do. Default to plain text otherwise.
+- Fenced code blocks (triple backtick) are not an exception. Craig's direction is zero markup in chat output, always: "always always list it out without markup" (2026-05-30). Fences don't invert the way inline spans do, but they still read as markup he didn't ask for, and the carve-out kept reintroducing them. When he needs something to copy, give it as plain indented text, or write it to a file and name the path.
 
 This governs **chat output**, not the Markdown source of rule files, specs, or docs the user reads in an editor — those keep normal Markdown formatting. The constraint is the terminal rendering of the live conversation.
+
+## Quiet Output: A Check That Passes Says Nothing
+
+A check that returns the expected result prints nothing. Only deviations print, plus at most one summary line.
+
+**Why:** tool output isn't free. Craig runs Claude Code inside Emacs EAT, so every Bash stdout lands in the buffer he's working in, where the command's output and his work compete for one screen. The reverse-video rule above governs the styling of what reaches his terminal. This governs the volume, which is the larger cost.
+
+**The failure it closes** is reading "keep output minimal" as a rule about prose, and treating tool output as exempt because it isn't prose. Work ran eleven hourly sentry cycles on 2026-08-05, each about ten Bash calls printing in full. Nearly every line confirmed nothing had changed: roam current, staleness unchanged, lint at its known counts, tree clean. Craig's instruction that day was "I want you to switch to the quiet form ALWAYS."
+
+**How to apply:**
+
+- Let the exit code carry the pass, but capture the output rather than discarding it, so the failure branch can show what went wrong:
+
+      out=$(cmd 2>&1) || { echo "DEVIATION: <what>"; echo "$out"; }
+
+  Don't write `cmd >/dev/null 2>&1 || echo "DEVIATION: ..."`. That throws the diagnostic away down the one branch that needs it, leaving only the placeholder you typed.
+- Grep for problems rather than for confirmation. Piping a report through `grep DEVIATION` beats printing the report.
+- Compare against the known-good value and print only a mismatch (a count, a SHA, a status string).
+- One closing summary line is fine ("checks done", "3 of 11 passes had findings"). A per-item roll call confirming each success is not.
+- When you genuinely need a command's output, filter it to the anomalies first.
+
+Quiet isn't silent. A deviation, a finding, and anything Craig asked to see all print in full. Suppressing those is the opposite failure and a worse one. The rule removes confirmations, never signal.
+
+**Verification gates are exempt, and the exemption is load-bearing.** [`verification.md`](verification.md) requires reading a check's whole output before claiming it passed, because an exit code can lie. A suite that silently skipped every test exits 0. A linter can exit 0 holding warnings. A gate running against a hand-maintained file list exits 0 without ever seeing your new file. So when the command is the evidence for a completion claim (the pre-commit test run, the linter, the type checker, a bug's reproduction steps), read the real output and say what it said. Quiet form governs routine checks that only confirm the expected state. It never buys a cheaper way to claim something passed. Where the two rules meet, `verification.md` wins.
+
+This is about the main thread's output, because that's what reaches his terminal. A background subagent writes to a file instead, which is why a repeated multi-step pass gets dispatched rather than run inline. See the Output-Destination Override in [`subagents.md`](subagents.md).
+
+## Showing Craig Visuals
+
+Craig runs Claude Code inside Emacs EAT (through tmux). EAT renders SendUserFile and inline terminal images as an `[image] path.png` text line — the visual itself never appears. In one session ~20 renders went out that way and Craig approved UI he had never seen (takuzu, 2026-07-11). Never rely on SendUserFile or inline image display to show a visual. SendUserFile stays fine for *delivering* a file; it just doesn't display one.
+
+Two display lanes, by what the visual is for:
+
+- **Durable or interactive visuals** — HTML prototypes, full renders, anything Craig will study or click: open with `gui-open <abs-path>` (dotfiles-shipped; detaches through `systemd-run --user` so the agent shell can't reap it, resolves the Hyprland instance after a compositor restart, and confirms the window is actually visible before returning). It auto-detects image vs HTML; `--image` / `--browser` force. Place it off Craig's active workspace and name it, per `desktop-capture.md`.
+- **Quick inline glances** — a chart, a did-it-render check: sixel in the terminal. Encode with ImageMagick (`magick <img> sixel:<out>`; img2sixel silently emits zero bytes on some builds) and display in a separate tmux window (`tmux new-window -d -n <name>`, then `tmux send-keys -t <name> "clear; cat <out>" Enter`, tell Craig the window name) rather than the Claude Code pane, whose TUI repaints over anything drawn into it. With native tmux sixel active, the image lives in tmux's grid and survives window switches, scrolling, and resizing.
+
+**Capability gate.** Native sixel needs two config pieces: EAT answering the XTWINOPS cell-size query (patched eat.el, owned by .emacs.d) and `terminal-features 'xterm*:sixel'` in tmux.conf (owned by dotfiles). Check before relying on it: `tmux display -p '#{client_cell_width}'` — nonzero means go; 0 means the chain is missing a piece, so fall back to the browser lane. (Diagnosed 2026-07-13: tmux won't transmit sixel until it knows the client's cell pixel size, and stock EAT 0.9.4 silently ignores the CSI 14 t query tmux uses to ask.)