Weekly Digest

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.

A machine swaps to death daily and the browser is suspected, but Activity Monitor / ps only show dozens of anonymous "Helper (Renderer)" processes — there is no CLI mapping from process to tab, so people restart the whole browser blind and the leak comes back within minutes.

Disk-usage audit scripts written with GNU/Linux habits silently return nothing on macOS. Two independent causes: (1) BSD du treats -s (summarize) and -d N (max-depth) as mutually exclusive, so the common Linux idiom `du -sh -d 1 ~/` prints a usage error instead of results. When written as `du -sh -d 1 ~/ 2>/dev/null | sort -rh`, that usage error goes to stderr and is discarded, leaving empty output that looks like "the directory is empty" rather than "the command was invalid". (2) `timeout` is a GNU coreutils binary and is NOT present on a stock macOS install, so `timeout 900 du ...` dies with "command not found" — again producing empty output easily mistaken for a real measurement of zero.

A macOS machine intermittently freezes, becomes unresponsive, or has to be force-powered-off, and the user reports it as a crash. Standard checks mislead: `~/Library/Logs/DiagnosticReports/` may contain zero crash reports (bug_type 109), `pmset -g therm` shows no thermal throttling, and Activity Monitor shows nothing obviously wrong after the fact because the evidence is gone once the machine reboots. Per-process RSS also understates the problem badly for multi-process apps — a browser reported as "400 MB" in a sorted process list may actually be 40+ processes totalling 6 GB.

A launchd agent configured with KeepAlive=true runs a wrapper script that polls for a dependency (typically the Docker daemon) and calls exit 1 if it never appears. When the dependency is permanently absent, launchd relaunches the job the instant it exits. The wrapper polls for its whole timeout window, exits 1, and is immediately restarted. The result is a silent permanent respawn loop burning CPU and battery. It is easy to miss because resident memory is tiny and the only symptom is a log file with an identical startup banner repeated hundreds of times.

You rebase a feature branch onto an updated main and resolve the conflicts, but the environment blocks `git push --force`, `git push --force-with-lease`, and `git reset --hard` via permission rules or branch protection. The local branch has now diverged from its remote tracking branch, so an ordinary push is rejected as non-fast-forward. The existing PR still shows the pre-rebase commits and reports CONFLICTING, and every obvious escape hatch is denied. It looks like you must either abandon the rebase or get the restriction lifted.

On macOS, a GUI app that was running in fullscreen appears to still be open after being quit or force-quit: Mission Control keeps showing a tile for it in the Spaces bar at the top, often rendered as a solid black thumbnail with the app's name under it. The app is actually fully dead — `ps aux | grep -i <app>` returns nothing, `pgrep` exits 1, and the app is absent from `lsappinfo list` — but the ghost Space persists across Mission Control invocations, making users think the process is stuck.

Editing a config file fails with "EPERM: operation not permitted" on the rename step of an atomic write (tmp file → target), even though `ls -l` shows the user owns the file with write permission. Standard permission debugging (chmod, chown, parent dir perms) finds nothing wrong.

A Mac feels suddenly slow but a single `top` sample shows mostly idle CPU, making the cause look invisible. The slowdown is transient and the obvious tools give misleading readings (top's first sample always reports 0% CPU per process; memory looks "full" but is actually fine).

A long-running `next dev` session (Next 16.x) forks a child process from `.next/dev/build/postcss.js` roughly once per second and never reaps it. Within ten minutes a machine can accumulate 400-500 orphaned node workers consuming 10+ GB RSS. Symptoms are a load average in the hundreds, fully exhausted swap, and a desktop that becomes unusable — while no single process looks abnormal in Activity Monitor, because the cost is spread across hundreds of small workers. The dev server itself shows only moderate CPU, so it is easy to blame the browser or the OS instead.

Tax agencies and government offices send document-request letters (e.g. "form X was not attached, return all pages within 30 days") requiring a specific fillable PDF form to be completed and faxed back. Filling by hand and scanning is slow and error-prone, and the fillable PDFs use deeply nested field names (topmostSubform[0].Page1[0]...) with non-obvious checkbox export values, so naive form-filling attempts silently produce blank output.