tonydzi

#!/usr/bin/env python3
"""Control example for crossfile_dedupe_audit.py.

Builds a synthetic transcript corpus with known answers and checks the tool
reports them. Two of the four cases are planted defects the tool MUST see;
two are traps it must NOT report.
"""
import json
import os
import shutil

tonydzi

firefox_places_doctor

If you write rows into Firefox's places.sqlite by hand, this tells you in 30 seconds whether Firefox will actually use them — or quietly pin a CPU core instead.

The pain

You migrated history or bookmarks into a Firefox profile (from Chrome, Arc, Safari, another profile, your own exporter). The rows are there. SELECT count(*) looks right. And then:

• "Firefox sits at 100% CPU after I imported my history and I can't tell why."
• "The URLs are in moz_places but the address bar never suggests them."

tonydzi

Which cap actually binds your MEMORY.md, and what it silently drops

The Claude Code auto-memory index is loaded through a truncation step with two caps: 200 lines and 25,000 size units. Three things about that step are easy to get wrong, and all three cost you content you never see go missing.

1. The size cap is not counted in bytes. The implementation measures trimmed.length on a JavaScript string, which is UTF-16 code units. The field is named byteCount, the cap is named byteCap, and the user-facing message formats it with a byte formatter. If your index is not pure ASCII, the number you are shown is not the number on disk, and the error always runs in the direction of compacting more than needed.

For a Cyrillic index at 1.38 bytes per unit, the real ceiling is around 34,500 bytes on disk, not 25,000. For CJK it is higher still.

2. Truncation is line-first, then size. The line cap is applied, and only then is the survivor cut at the last newline before the size cap. When bo

tonydzi

#!/usr/bin/env python3
"""task_session_map.py - recover the taskId -> sessionId link for Claude Code
scheduled tasks (routines) deterministically, without cwd/title/time heuristics.

Why this works: when a scheduled task fires, the harness injects its prompt into
the executing session's transcript as a record whose content opens with
  <scheduled-task name="..." file="...">
and that record carries the executing session's own sessionId. So the transcript
itself states which task produced it.

tonydzi

Takeout MyActivity.html renders in the export-time timezone, so two exports of one account don't dedupe

A ~90-line, zero-dependency Python helper that normalizes Google Takeout MyActivity.html timestamps to UTC, so importing a second export of the same account doesn't silently double your database.

The symptom

You imported your Takeout activity history months ago. You export again to top it up, run the same importer, and:

• your row count roughly doubles instead of growing by a few thousand;
• every old event is now in there twice, exactly one hour apart;

tonydzi

#!/usr/bin/env python3
"""llm_batch_fuses.py -- four fuses + a detector-agreement cascade for batch LLM jobs.

WHY
---
Any nightly job that calls an LLM once per item (classify sessions, summarize
transcripts, label records) will eventually meet the same four failure modes:

1. An item that always fails gets retried every night, forever.
2. A fatal condition (auth expired, usage limit) fails EVERY item, one call at

tonydzi

# Test-Ps1Encoding.ps1
#
# Find .ps1 files that Windows PowerShell 5.1 will MIS-PARSE, and optionally fix
# them by adding a UTF-8 BOM.
#
# ---------------------------------------------------------------------------
# The bug this catches
# ---------------------------------------------------------------------------
# Windows PowerShell 5.1 (powershell.exe - not pwsh 7) decides a script's
# encoding from its BOM. No BOM means "this is ANSI", i.e. the machine's legacy

tonydzi

"""Verify headroom v2.0.8's MessageDeduper against a Windows hub log tree.

Simulates the shipped O(1) rule (drop a usage record whose message.id equals the
PREVIOUS record's message.id) and measures what inflation survives it, then
classifies the survivors:
  A REPLAY  - the identical record (same uuid) is written again later in the file
  B PARTIAL - one message.id carries DIFFERENT usage payloads (streaming snapshots)
Ground truth for "how many real messages" = distinct uuid, since uuid is unique
per written record and a replay repeats it verbatim.
0 LLM tokens, read-only.

tonydzi

#!/usr/bin/env python3
"""api_wait_gaps.py - measure API-wait stalls across a whole Claude Code transcript corpus.

A "stall" here = wall-clock time in which the RUNTIME owed the next event and no bytes
arrived. Only two record pairs qualify:

    tool_result -> assistant     (tool came back, model has not spoken yet)
    assistant   -> assistant     (mid-stream continuation)

Why the restriction matters: a naive "every gap >= 60s" scan over a corpus is dominated by

tonydzi

scheduled-tasks-doctor

Your Claude Desktop routines vanished from the Routines list — after an app update, after signing in with a different account, or for no visible reason at all. This finds them and puts them back.

They are almost certainly not deleted. The app splits a routine across two places:

what	where	survives an app update?