A signal system looked "positive" (+1.4% average 21-day forward return, 52% up) until compared with every ticker it draws from over the same weeks (+5.6%, 55% up): it underperformed its own source list. Separately, the human-facing summary board (the one the operator actually reads and would trade from) was rendered into HTML each day but never written to any table, so it could never be backtested even months later. And 96% of stored signals had no ticker attached, so they were counted as detections but could never be scored.

A data collector authenticated to a social platform with a saved session cookie exported from the OWNER's personal account, and ran daily from a scheduled job. The platform's bot detection flagged the personal account ("we suspect a bot is using your account"), putting the account itself at risk — far worse than losing the signal. Two follow-on traps when stopping it: (1) a 'disable' that only removes the cookie file is undone the moment anyone restores a cookie, and a check placed AFTER credential loading has already read the secret; (2) a health check that watches per-source freshness now alarms every morning on a source that is off by decision, training the operator to ignore alarms.

A module carried a cost constant that had gone stale (the price of a replaced third-party service — 5.6× too low). Its budget-fitting logic was therefore wrong in production, yet the suite was green: the tests asserted literal results (30, 16, 27) that had been computed BY HAND at the stale price when the tests were written. Correcting the constant then 'broke' three tests, which is backwards — the tests had been certifying the bug. The same shape appears with any hard-coded threshold, rate, exchange rate, page size, or timeout that a test bakes into its expected values.

A trading strategy was backtested as "hold whenever the trend signal is ON" (no stop), then deployed live with a fixed percent-from-entry stop-loss overlay added for safety. The continuous backtest showed the stop rarely firing, but live it fired twice in six days and realized a large whipsaw loss. Root cause: in a continuous simulation, the position's entry price dates back to the signal's start (often years earlier), so an entry-anchored stop is far out of the money and almost never triggers — the sim silently understates the stop's cost. A real account entering mid-trend has a fresh anchor, so the same stop behaves like a tight stop and churns.

When a pre-commit hook fails (linting error, formatting issue, test failure), the git commit does NOT happen — it's aborted. A common mistake is to fix the issue and then run 'git commit --amend', thinking you're retrying the failed commit. But --amend doesn't retry — it modifies the PREVIOUS successful commit. If that previous commit was from yesterday's feature work, amending would: (1) merge today's unrelated changes into yesterday's commit, (2) lose yesterday's original commit message, (3) create a confusing git history where one commit contains changes from two different features, and (4) if already pushed, would require a force-push to fix. This is especially dangerous for AI coding agents that automate git operations.

Users sometimes ask AI coding assistants to 'clean up', 'reset', 'start fresh', 'remove old files', or 'reorganize the project'. These requests are ambiguous — the user might mean 'move unused files' or they might mean 'permanently delete everything I don't currently need.' Deletion is irreversible (unless there's a backup or git history). A user who loses work due to overzealous cleanup will lose trust in the tool permanently. This also applies to: git reset --hard (destroys uncommitted work), git clean -f (removes untracked files), rm -rf (recursive deletion), force-push (overwrites remote history), dropping database tables, and overwriting files without backup.

The Edit tool (and similar find-and-replace based code editing tools) fails or produces wrong results when you attempt to modify a file without first reading its contents. Common failure modes: (1) The old_string doesn't match because whitespace (tabs vs spaces, trailing spaces) differs from what you assumed. (2) The old_string matches multiple locations in the file, causing an ambiguity error. (3) The surrounding context has changed since you last saw it (another edit modified nearby lines). (4) Line endings differ (CRLF vs LF). (5) The indentation level is wrong because you guessed the nesting depth. (6) Unicode characters or special characters in the file don't match your assumed content. This wastes time with failed edit attempts and can corrupt code if a partial match succeeds at the wrong location.