Align prose with STYLE.md across modules 01-07 and top-level README

Replace residual em-dashes, arrow-notation shorthand, and a handful of
filler intensifiers; fix two small typos. Add .gitignore to keep the
working CHANGES.md audit out of the repo.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

02-errors-and-logs/README.md

@@ -2,14 +2,14 @@
 
 ## Key idea
 
-Errors, stack traces, and log output are *exactly* the kind of thing chat models excel at parsing. A transformer's attention is built for finding the relevant token among noise. Use it!
+Errors, stack traces, and log output are *exactly* the kind of thing chat models excel at parsing. A transformer's attention is built for finding the relevant token among (machine generated) noise. Use it!
 
-Errors and logs are the canonical copy-paste use case. The trick is pasting *enough* context but not *too much*, and being explicit about what you were trying to do.
+Errors and logs are the canonical copy-paste use case of World 1. The trick is pasting *enough* context but not *too much*, and being explicit about what you were trying to do.
 
 ## Key goals
 
 - Recognize when a chat is the right tool for an error or log
-- Paste the right amount of context — neither too little nor too much
+- Paste the right amount of context (neither too little nor too much)
 - Frame the paste so the model can give a useful answer, not a guess
 - Use the answer as a starting point, not gospel
 
@@ -17,16 +17,16 @@ Errors and logs are the canonical copy-paste use case. The trick is pasting *eno
 
 ## Why chat is the right mode here
 
-A typical Python traceback is 10–40 lines of mostly-noise with one or two lines of actual signal. A 500-line server log has maybe three lines that matter. Two reasons chat works here:
+A typical Python traceback is 10–40 lines of mostly noise with one or two lines of actual signal. A 500-line server log has maybe three lines that matter. Two reasons chat works here:
 
 1. **The output is words, not code-in-place.** You are looking for an explanation or at least a pointer, not an edit to a file. Chat is the stronger choice. 
 2. **The input is self-contained.** You can paste the whole error and the model can reason about it without needing your project layout, history, or build state.
 
-An in-project chat can handle errors well too — and is often the right tool, because it can see the file that threw the error without you pasting it. For a long traceback or a multi-page log that doesn't fit cleanly in your editor's chat panel, or when the failure involves output from a server or system that isn't part of your project, a web chat's room to expand and your ability to copy-paste freely make it the better venue.
+An in-project chat can handle errors well too — and is often the right tool, because it can see the file that threw the error without you pasting it. For a long traceback or a multi-page log that doesn't fit cleanly in your editor's chat panel, or when the failure involves output from a server or system that isn't part of your project, a web chat's room to expand and your ability to copy-paste freely make it the better choice.
 
 ## What to paste
 
-Three rules:
+A good practice is to follow these three simple rules:
 
 ### 1. Paste the whole relevant block, not just the last line
 
@@ -51,11 +51,17 @@ ValueError: could not convert string to float: 'N/A'
 
 The second version makes the cause (the string `'N/A'` in the data) obvious. The first leaves the model guessing.
 
-### 2. Trim noise that doesn't help
+### 2. Trim only when you have to
 
-A 2000-line log with five relevant lines is harder for the model (and you) than 50 lines centered on the relevant region. Use `grep`, `tail`, or your eyes to narrow it down. Include enough surrounding context that the model can see the lead-up to the failure, but cut the parts that are clearly unrelated (startup banners, unrelated services, repeated heartbeat lines).
+The advice you'll often hear is "trim aggressively before pasting." In practice, modern chat models are very good at finding the few relevant lines in a noisy log — that's exactly what attention is for. For a typical few-hundred-line log, pasting the whole thing usually works fine, and trimming buys you little.
 
-If you do not know which part is relevant, paste a reasonable chunk and *say so*: "I think the failure is somewhere in here but I'm not sure where to look."
+Trimming is worth the effort in three specific cases:
+
+1. **The log is large enough to bump against context limits** (tens of thousands of lines, or a multi-megabyte file). Here you have no choice — use `grep`, `tail`, or your editor to cut it down.
+2. **The noise is the *kind* that misleads** — unrelated red `ERROR` lines from a different service, deprecation warnings that look like the failure but aren't, repeated retries that bury the original cause. A model will sometimes latch onto the loudest-looking line rather than the actual one.
+3. **You want a faster, cheaper turn.** Less input means less to read and quicker iteration.
+
+Outside those cases, don't agonize over it. If you do not know which part is relevant, paste a reasonable chunk and *say so*: "I think the failure is somewhere in here but I'm not sure where to look." The model will find it.
 
 ### 3. Include the command or code that triggered it
 
@@ -88,18 +94,18 @@ If you've already tried things, say so. *"I tried `pd.read_csv(..., na_values='N
 
 ## What to do with the answer
 
-The model's first answer to an error is often *plausible but wrong about the root cause*. It will identify the right neighborhood — "there is a non-numeric value in your column" — but may guess wrong about the specific row or the fix that works in your case. Treat the answer as a **search query**, not a firm result:
+The model's first answer to an error is often *plausible but wrong about the root cause*. It will identify the right neighborhood ("there is a non-numeric value in your column") but may guess wrong about the specific row or the fix that works in your case. Treat the answer as a **search query**, not a firm result:
 
 - Does the diagnosis match what you see in your data or code?
 - Is the suggested fix one you can verify quickly (one line, one test)?
 - If a suggested fix doesn't work, *say so* in the next turn and paste the new output. The second answer is usually much better because the first one ruled out a possibility.
 
-The biggest mistake students make with chat-based error help is **treating the first response as authoritative**. The right mental model is: the model gives you a focused hypothesis, but you do the verification.
+The biggest mistake we often make with chat-based error help is treating the first response as *authoritative*. The right mental model is: the model gives you a focused hypothesis, but you do the verification.
 
 ## Common pitfalls
 
 - **Pasting only the last line of the traceback.** The model can guess, but it's a guess. Paste the whole traceback.
-- **Pasting a 2000-line log unfiltered.** The model wastes attention on irrelevant material and the answer suffers. Trim.
+- **Pasting a log so large it doesn't fit, or one whose noise actively misleads.** A few hundred noisy lines is fine; tens of thousands of lines, or a log full of unrelated-but-loud `ERROR` entries, is when trimming earns its keep.
 - **Pasting code with no error message.** "Why doesn't this work?" without the actual failure makes the model invent failure modes. Always run the code and paste what happened.
 - **Pasting proprietary code into a public chat.** See [section 06](../06-verifying-and-citing/) — what you paste, the service sees and may log. Match the chat to the sensitivity of the content.
 - **Not iterating.** If the first answer is wrong, the second is usually better. Treat the conversation as a debugging session, not a single oracle query.