Rebuilding an investor's full holdings history from SEC 13F-HR information tables (data.sec.gov submissions JSON -> filing folder index.json -> infotable XML) and comparing the reported value/share with a market close flags dozens of positions as "wrong ticker" when the mapping is actually fine. Three separate causes look identical: Yahoo closes are split-adjusted while 13F share counts are as reported at the time (so value/share is 2x, 4x, 20x the close after splits); some filers still report values in $ thousands after the 2023 switch to dollars (1000x); and CUSIP->ticker mapping through OpenFIGI returns renamed issuers (Facebook->Meta, Square->Block) that a naive name check rejects, while genuinely reused or dead CUSIPs slip through.

A "which holdings are below the investor's entry price" screen only gives today's status. It says nothing about when the stock first crossed under, how long it stayed, or whether it dipped and recovered. Building the time dimension runs into three data problems: deal days known only to the month, entry prices never disclosed (only "announced on day X"), and pre-IPO tranches with no quotes before listing.

Running N parallel workers that each hf_hub_download a ~10 GB file (local_dir mode) on a 16 GB machine: within ~40 seconds memory peaks at ~15 GB, the kernel OOM-kills one python worker, and because the workers were launched inside a tmux session under a systemd user scope, systemd marks the scope "Failed with result oom-kill" and tears down EVERYTHING in it — the launcher/driver included. Symptoms are deceptive: the per-worker logs show no traceback, the driver never logs a retry, network traffic simply freezes, and `ps` shows no python at all. It looks like a stall or a rate limit, not a crash.

A 4.5-billion-row dataset published as ~27 zstd parquet files (~290 GB) on Hugging Face has to be scanned once with a regex over a text column and counted per week. Reading it over HTTP range requests on a laptop takes ~40 s per 1M-row row group (50+ hours single-stream), the machine's job supervisor kills processes when swap fills, network stalls kill long streams, and a naive parallel design either double-counts blocks after a restart or needs the whole dataset on disk.

A static HTML report embeds its data as a <script type="application/json"> block written by Python's json.dumps. One ratio computed as x/0 became float('inf'); Python serialises it as the bare token Infinity (allow_nan defaults to True) and Python's json.loads reads it back happily, so every server-side check passed. In the browser, JSON.parse throws "SyntaxError: Unexpected token 'I' ... is not valid JSON" on the first line of the page script, so nothing renders: empty chart, empty table, empty tiles, and no visible error unless you open the console.

You need to copy a very large public Hugging Face dataset (hundreds of GB, e.g. ~290GB in ~27 parquet shards) to another HF account without downloading it to a local machine (disk/bandwidth constraints). The obvious server-side worker — a free Hugging Face Space — no longer works: creating even a cpu-basic Docker/Gradio Space returns 402 Payment Required ("hosting Gradio and Docker Spaces on free cpu-basic requires a PRO subscription"). Only static Spaces remain free.

A coordinator agent spawned a subagent with a prompt stating "you are running in a cloud environment" to run a long data job (3 GB HTTP read of parquet row groups, 30-90 min) as a parallel hedge next to its own local run. The subagent actually ran in a local git worktree on the same 16 GB laptop with swap 92% full. Following the steps literally would have doubled memory and bandwidth on a swap-starved machine, produced two identical outputs, and raced two commits onto the same branch. A second trap: macOS `ps -o etime` prints [[dd-]hh:]mm:ss, so "02:35" is 2.5 minutes, not 2.5 hours, which nearly led to the wrong conclusion about which run was ahead. Third: the worktree-isolation guard refused every "clever" one-liner (heredoc, inline python spawning bash, arithmetic on a captured variable).

A social-signal system stores rows from many channels in one posts table, tagging each row's channel in a single column ("reddit-sub-name", "bluesky:search:<brand>", "pinterest:search", "google:trending"). An "organic mentions vs own history" detector excluded brand-targeted channels with LIKE '%:search:%'. A new channel of curated search terms was added mid-history under the bare name "pinterest:search" (no trailing segment), so the filter never matched it. Every entity that appeared on the new channel's lists got a step change versus a baseline computed from months when the channel did not exist: two entities read x10 and x8.5 "above their usual" on ONE real post each plus ~26 list rows. The population audit (median ratio across all entities) stayed healthy at x0.94, because the leak only hit the handful of entities the new channel reached — a median-based sanity check does not catch it.

An agreement detector flags an entity when at least two independent streams are above the entity's own median in the same window. One stream had a structural upward bias: its history was rebuilt on every visit from the items currently visible (views written under each item's original post date), so the past always looked thinner than the present, 73% of entities read "up" on it and the median entity was x5. Dividing the typical entity's multiple out was not enough: one viral item still made the stream the decisive second vote on 30% of rows. Separately, rolling windows (7 and 30 days) keep an entity flagged for as long as one event sits inside the window, so "N days running" on a windowed board mostly counted echoes of one event.

A daily anomaly report persisted each board's rows to a history table, and the operator then asked for weekly and monthly reports. Reusing the daily section builders for the period pages had two traps: those builders wrote their rows to the history table as "today's" record, so a period page rebuilt with a different window silently overwrote the daily record; and one board that lists every tracked entity every day (a universe list, not a ranking) made every entity a "seen every day" regular in the roll-up. Early in the history, "seen 3 days" also read as strong when only 3 days had ever been recorded.