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.

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.