# 3 · Change: a diff someone can trust The diff is what the person reviews. They don't see your reasoning, only lines added and lines removed. A good diff is one where every line has a reason they would agree with, and nothing is left behind that they have to find and clean up later. --- ### C1 · The smallest diff that does the job **Rule:** Change only the lines the job needs. Leave the formatting, order and structure of everything else as it was. Don't reformat a file, reorder imports, or change quotes, spacing or line breaks in lines you didn't need to touch, unless the project's formatter does it on save and the person expects that. **Why:** The reviewer reads every changed line. Forty lines of reformatting around a three-line fix hide the fix, and they spoil the history for the next person who asks "when did this line change, and why?". **Agent trap:** rewriting a whole function, or a whole file, to change one condition, because writing it out again is easier for you than editing it. To you the result looks the same. The diff shows 200 changed lines, and the person has to check every one. **Check:** run `git diff --stat`, then read `git diff`. Every hunk should trace back to your one-line scope from B3. Revert any hunk that doesn't. > **In ihumane Pro** (https://ihumane.ai/#pricing): > - C2 · Mention what's outside the ask; don't change it > - C3 · Change an interface everywhere, or not at all > - C4 · Delete what you replace > - C5 · Comments say why, never what changed > - C6 · Leave no scaffolding > - C7 · A new dependency has to earn its place ### C8 · Secrets stay out of code, logs and URLs **Rule:** API keys, passwords, tokens and private keys come from environment variables or the project's secret store. Never write them into source files, tests, fixtures, comments or commit messages. Don't log them, don't put them in URLs, and don't send server secrets to the browser. If you find a real secret already in the code, don't copy it: tell the person, because it may need replacing. **Why:** Code gets copied, pushed, shared and indexed. A key in a repository ends up public sooner or later, and the person pays for whatever it's used for. **Agent trap:** hard-coding the key "for now" to get a request working, then forgetting it. Logging the whole request while debugging, authorisation header included. Putting a server key in front-end code because that's where the request happened to be. **Check:** `checks/tidy.js` flags common key formats and secret-looking strings. Also search your diff for `key`, `token`, `secret` and `password`, and look at each result. > **In ihumane Pro** (https://ihumane.ai/#pricing): > - C9 · Outside input never builds code ## Summary checklist - [ ] Read `git diff` in full: every hunk traces back to the one-line scope. - [ ] No reformatting, reordering or renaming outside the lines the job needed. - [ ] Ideas outside the scope are in the report, not in the code. - [ ] Every user of a changed interface was found and updated, or still works. - [ ] Replaced code is deleted, not commented out or kept as `v2`. - [ ] Every new comment says why, and makes sense to someone who never saw the old code. - [ ] `checks/tidy.js --diff` run: every "fix" fixed, every "look" kept only with a reason. - [ ] New dependencies, if any, are justified in the report and the lock file changed with them. - [ ] No secrets in code, logs or URLs; no outside input in queries, commands, paths or HTML.