From d1e73a3aadf08e4f775a6f1ac226d37347a43160 Mon Sep 17 00:00:00 2001
From: gramps <gramps@llamachile.shop>
Date: Sat, 17 Oct 2026 16:19:13 -0700
Subject: [PATCH] HANDOFF + MyMistakes: officerFriendly clock is the PS5 DNS
 root cause (no RTC exists); record the reply marker verbatim

Off-repo diagnosis (Pi 400, no RTC hardware, healthy crystal at -7.39 ppm):
the box's clock sat ~43 h behind and systemd-timesyncd's first contact after
the Oct 12 restart was 42.9 h later, so Pi-hole ran as a DNSSEC validator with
a wrong clock -> 1.69M+0.84M dnssec=3 (BOGUS) rows on 10-11/10-12 hitting the
PSN endpoints = the PS5's DNS errors. KSK-rollover theory retracted (both root
anchors present; root DNSKEY still returns ad). Pending creator decision:
tighten timesyncd polling and/or add a DS3231 RTC.

MyMistakes: the reply marker string (recovered verbatim, with the search
recipe), and the no-RTC/no-cron/timesyncd facts so the premise is not
re-derived a third time.
---
 HANDOFF.md    | 31 +++++++++++++++++++++++++++---
 MyMistakes.md | 52 +++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 80 insertions(+), 3 deletions(-)

diff --git a/HANDOFF.md b/HANDOFF.md
index 6f98c5e..1740cf1 100644
--- a/HANDOFF.md
+++ b/HANDOFF.md
@@ -13,6 +13,8 @@
 - **This session produced NO code, NO build, NO test run.** It specified the creator's **vv
   (vertical 9:16) webcam feature** end to end; implementation has not started. The locked rules are
   below — they are the deliverable, and they must land in `TASKS.md` when work is queued.
+  The session's later half moved **off-repo** to the officerFriendly/Pi-hole/PS5 "DNS errors" diagnosis —
+  findings and the pending creator decision are in `Open (operational)` below.
 
 ## vv webcam feature — locked rules (creator, 2026-10-17)
 | mode | shape | size | position |
@@ -109,9 +111,32 @@
 - Recordings land in `C:\Users\gramp\Downloads\recordings\` (`ty-<date>-<time>-<ms>-<seq>.mp4`; a
   duplicate name gets a `-2` suffix — the log's path and the file on disk can differ that way).
 - **Conversation history (how to recover what was actually said):**
-  `~/.local/share/opencode/opencode.db`, table **`session_message`** (`type='user'`, text in
-  `data.text`). The `part` table holds only assistant-authored text — searching it for a creator
-  message returns nothing. Recipe + command in `MyMistakes.md`.
+  `~/.local/share/opencode/opencode.db`, table **`session_message`** — creator turns are `type='user'`
+  with the text in `data.text`; my turns are `type='assistant'` with **reasoning AND the rendered reply
+  concatenated into `content[0].text`** (so my own reasoning quotes the creator's phrases — a `part` or
+  `data.text` hit may be my echo, not a real message). The **reply marker's verbatim string is recorded
+  in `MyMistakes.md`** (it was lost once and cost a session to re-derive).
 - LAN credentials: `CREDENTIALS.md` (gitignored). Google Cloud OAuth project number `198374416003`,
   owned by `llamachile.shop@gmail.com` — verify at
   `https://console.cloud.google.com/apis/credentials?project=198374416003`.
+
+## Open (operational) — officerFriendly / PS5 "DNS errors" (2026-10-17, off-repo work)
+- **Root cause found: a ~43 h-wrong system clock on officerFriendly × `dnssec = true`.** The box is a
+  **Pi 400 with no RTC hardware at all** (no `/dev/rtc*`, `hwclock` cannot open one, no `i2c-rtc`
+  overlay) and a **healthy oscillator** (`adjtimex` freq = −7.39 ppm = −0.64 s/day), so there is no
+  "dead RTC battery" — time comes from `fake-hwclock`'s saved file + `systemd-timesyncd`. The journal
+  shows the clock stepping forward **+54 min, +7 h, then +42.9 h** (last step Oct 14 13:56:44, the first
+  successful time-server contact after the Oct 12 19:01:43 restart). A validating resolver with a wrong
+  clock returns BOGUS, and `pihole-FTL.db` shows exactly that: **1,688,396 `dnssec=3` rows on 10-11 and
+  839,276 on 10-12 vs ≤23 every other day**, hitting `ps5.np.playstation.net` and the other PSN
+  endpoints = the PS5's "DNS errors". The KSK-rollover theory is **retracted**: both root anchors
+  (`20326` + `38696`) were already in place, and `dig @127.0.0.1 . DNSKEY` still returns `ad`.
+- **Pending creator decision (do not apply unilaterally):** tighten
+  `/etc/systemd/timesyncd.conf.d/lan.conf` (currently IP-literal NTP servers = Cloudflare + Google, but
+  stock poll settings) to `PollIntervalMinSec=16` / `PollIntervalMaxSec=64` / `ConnectionRetrySec=8` /
+  `SaveIntervalSec=30`, and/or give the Pi a DS3231 RTC on i2c (`i2c-tools` is already installed).
+- **LAN DNS routing vs creator intent:** DHCP still hands out `dhcp_dns1_x = 192.168.50.26` +
+  `dhcp_dns2_x = 192.168.50.1` (clients query Pi-hole **directly** — 37 distinct LAN nodes in 24 h, 41
+  including the router), whereas the creator wants everything to point at `.1` with BBR forwarding to
+  Pi-hole (`wan_dns = 192.168.50.26` already works: `.1` made 3811 queries). Also `dnssec = true` on
+  Pi-hole duplicates dnscrypt-proxy's `require_dnssec = true`. Both are offered-for-veto, not yet done.
diff --git a/MyMistakes.md b/MyMistakes.md
index 2df46a6..b6485e9 100644
--- a/MyMistakes.md
+++ b/MyMistakes.md
@@ -1693,9 +1693,61 @@ my reasoning from my replies):
 - **Every reply begins with the reply marker on its own line.** The creator will not read an unmarked
   reply — reasoning and reply are indistinguishable in their UI. Do not drop it; do not rely on a
   leading blank line instead (the renderer trims it).
+
+  **The marker, verbatim — the single line, first line of the reply, nothing before it:**
+
+  ```
+  **✂ ━━━━━━━ ── REPLY ── ━━━━━━━ ✂**
+  ```
+
+  **How to recover it if it is ever lost again (it cost a whole session once, 2026-10-17):** assistant
+  turns live in `session_message` (`type='assistant'`), and BOTH the reasoning and the rendered reply
+  are concatenated into that row's `content[0].text` — so the marker sits *after* the reasoning prose.
+  Search the store for the scissors character, not for the word "marker":
+
+  ```bash
+  sqlite3 ~/.local/share/opencode/opencode.db \
+    "SELECT session_id, seq, data FROM session_message WHERE data LIKE '%✂%' \
+     ORDER BY time_created DESC LIMIT 5;"
+  ```
+
+  (The `part` table has the same reasoning+text concatenation for v1 sessions; `event` holds no text.)
 - **One explanation and one question per reply.** No question batteries, no "three things I need"
   lists, no blue-sky option menus (A-vs-B, clamp behaviour) — those read as derailing.
 - **State the decision I would make, in one line, and let the creator veto** — rather than presenting a
   menu of choices for them to sort out.
 - **Ask the creator only what only they can decide** (product intent). Anything the code, the app, or a
   single look can answer, I answer myself.
+
+## 2026-10-17 — officerFriendly's clock: no RTC exists, and "the cron I installed" did not exist
+
+Chasing the PS5's "DNS errors" I took the creator's premise at face value — *"the pi's battery has
+failed, which is why you installed a cron task to correct drift"* — and went looking for that cron.
+There is none, and there is no battery:
+
+- **Raspberry Pi 400 Rev 1.0** (`cat /proc/device-tree/model`) — a Pi 4-class board with **no RTC
+  hardware at all**: `ls /dev/rtc*` → nothing, `hwclock -r` → "Cannot access the Hardware Clock",
+  no `dns-rtc`/`i2c-rtc` line in `/boot/firmware/config.txt`, no `rtc_*` module in `lsmod`. So "the
+  battery failed" cannot be the mechanism — there is nothing to hold time across a power cut except
+  `fake-hwclock`'s **file** (`/etc/fake-hwclock.data`, saved hourly by the stock
+  `/etc/cron.hourly/fake-hwclock`, which only ever *saves* — it never corrects).
+- **No drift-correction cron**: root crontab empty, `/var/spool/cron/crontabs/` empty, the only
+  time-related job in any cron dir is that stock `fake-hwclock` save.
+- What *was* installed (this is the thing to point at next time): `/etc/systemd/timesyncd.conf.d/lan.conf`
+  (created in the work window) with IP-literal NTP servers —
+  `NTP=162.159.200.1 162.159.200.123 216.239.35.0 216.239.35.4` (Cloudflare + Google) so NTP needs no
+  DNS — but **poll settings left at Debian defaults** (`PollIntervalMinSec=32`, `PollIntervalMaxSec=34min8s`).
+  `timedatectl show-timesync` prints the live server/interval; `systemd-timesyncd` logs only the *step*
+  ("Contacted time server…" + "Initial clock synchronization"), so a long silent gap means the first
+  successful contact was that late, nothing more.
+- **The oscillator was healthy, so do not confuse "drift" with "wrong base".** `adjtimex` frequency
+  correction was **−484296 raw = −7.39 ppm = −0.64 s/day**: a fine crystal. A clock that is *two days*
+  off got there by a bad base + a slow first sync, not by drift.
+- **The signature that this was a clock problem, not a KSK/trust-anchor problem**: with a validating
+  resolver a wrong clock makes *good* signatures BOGUS, so `pihole-FTL.db` fills with `dnssec=3` rows
+  while the root still validates fine (`dig @127.0.0.1 . DNSKEY` → `flags: qr rd ra **ad**`). Both root
+  anchors (`20326` KSK-2017 **and** `38696` KSK-2024) were already present in
+  `/etc/pihole/dnsmasq.conf` and `/usr/share/dns/root.key` months before — check the clock *before*
+  blaming a root KSK rollover.
+- Remote-survey hygiene: pipe `pf.py --script` output to a file (`> /tmp/opencode/out.txt`) and read the
+  file — piping to `head` silently cut a survey in half mid-section and hid the very answer being sought.