---
name: tools
description: Canonical personal files and how Ben wants planning context sourced
sources: [backfill]
aliases: []
---
- [stated] Maintains three canonical personal files as source of truth for context and planning: "Me," "Roadmap," "Mirror"
- [stated] For planning and prioritization, locate and read the canonical files first; memory is fallback only; if files are not accessible, say so and ask Ben to upload them
- [stated] Health context (genotype and bloodwork) lives in a dedicated "ben-health" skill, not in memory. Load that skill before answering anything on supplements, hormones, compounds, sleep, cognition or cardiovascular risk; ask him to re-send the .skill file if it is not installed

## Printer on Ben's Mac (Canon E3300)
- [stated] Ben's printer "has been giving me issues every time I want to print." Fixed 11 Sep 2026.
- Queue `Canon_E3300` on the Mac, printer is a **Canon E3300 series**, UUID `urn:uuid:00000000-0000-1000-8000-0018a3425958`, IPP at `ipp://<ip>/ipp/print`.
- **ROOT CAUSE, and it will recur on any network gear he owns: the router hands the printer a NEW DHCP address, the CUPS queue still points at the OLD one, and CUPS shows "Connecting to printer" forever while jobs pile up silently.** Found five jobs stacked from 25 Aug, 1 Sep and 11 Sep. The printer had moved 192.168.1.47 to 192.168.1.42; the old address showed `(incomplete)` in `arp -a`.
- Diagnosis order that worked, fastest first: `lpstat -p -d` (is it "Connecting to printer"), `lpstat -o` (how old is the oldest stuck job, that dates the breakage), `lpstat -v` (what address is it pointed at), `ping` plus `nc -z <ip> 631`, then `arp -a` and a port-631 sweep to find where it went. Confirm identity with `ipptool -T 6 -tv ipp://<ip>/ipp/print /usr/share/cups/ipptool/get-printer-attributes.test` and grep the UUID. Repair is `cancel -a`, `lpadmin -p <queue> -v ipp://<newip>/ipp/print`, `cupsenable`, `cupsaccept`.
- **Permanent fix deployed: `~/printerkeeper/keeper.sh` plus LaunchAgent `~/Library/LaunchAgents/com.bk.printerkeeper.plist`, StartInterval 300 and RunAtLoad.** Every 5 minutes it checks the queue's current address, and if the printer is not answering there it ping-sweeps the /24, tests whoever answers on 631, matches the UUID, then repoints the queue and re-enables it. Log at `~/printerkeeper/keeper.log`. Verified by deliberately breaking the queue to 192.168.1.199: it self-repaired in 7 seconds.
- **`ipptool -t` does NOT print the attribute values, only PASS/FAIL. It must be `-tv`.** An identity or state check built on `-t` silently matches nothing, which is what made the keeper report "printer not found" while the printer was plainly reachable.
- **THE SHELL TRAP THAT COST THE MOST TIME: the Mac's default shell is zsh, and zsh does NOT word-split an unquoted variable the way bash does.** `for ip in $hosts` passed the entire newline-joined list to `nc` as ONE argument and the loop ran once against garbage. Command substitution `$(...)` IS split, plain `$var` is not. Use `echo "$hosts" | while read -r ip` or `${(f)hosts}`. Assume zsh semantics on anything written for his Mac.
- Also worth knowing: a ping sweep fills `arp -a` with ~250 `(incomplete)` rows, so any arp-based scan must `grep -v incomplete` or it will spend minutes probing addresses where nothing exists.
- If it ever misbehaves again the first question is whether the printer is simply powered off or asleep; the keeper logs "printer not found on 192.168.1.0/24 (off or asleep)" for that case rather than thrashing.