Outstanding personal actions for John. Agents: surface these proactively, even if the conversation is not about them.
1. Write up the noodle incident as a blog post / post-mortem — honest account of Claude misinterpreting 'stop' as running a 'delete' script (with --yes) against live infrastructure, despite naming conventions and a confirmation flag. Rough draft/outline at writing/noodle-incident-postmortem; root-cause detail and mitigation at ideas/host-safety-and-remote-execution; original recovery plan at memory/envoy/mail-server.
3. Investigate stale Google Drive JSON "location" export — a file called location (and a re-upload named location-new) in Google Drive contains a 100-point OwnTracks JSON batch (who/device/count/locations[]) whose most recent point decodes to 2026-07-01 10:56 UTC, regardless of re-upload or filename — i.e. genuinely stale content, not a Drive caching artefact (confirmed via repeated fresh downloads with changing modifiedTime but identical bytes). Ruled out as a server-side data problem: the locs HTML-table endpoint (full-history view) is confirmed live and correct — 478 fixes for 2026-07-13, last fix 06:03:57 UTC matching the live single-point loc note. So gdata-server/history is fine; the fault is isolated to whatever produces/uploads this Drive JSON export specifically. To investigate: (a) find the job/script that produces the 100-point Drive JSON export and check whether it's reading from a stale cache/snapshot rather than the live gdata-server history (which the working locs HTML view proves is fine); (b) check whether the export is meant to be a periodic append-only log (in which case the batch should have grown/rolled forward, not stayed static) or a fixed historical snapshot mistakenly being reused; (c) check the upload mechanism — possibly a stuck cron/script re-uploading the same cached blob. Discovered 2026-07-13 while checking GWR journey location against Drive vs. the live loc/locs endpoints.
4. Revisit the June 2026 reflection — john/reflection-2026-06 captures a critical read of the Claude "Reflect" summary: effort in June went into scaffolding rather than the career transition, the agenda is reactive, and there is little external review. If the transition is still live, locate or reconstruct the career-transition cluster (the old jobs/prospective/full-stack-agentic-engineer key is absent from both stores) and check outstanding items against where the time actually went.
5. Review ZoneEdit nameserver delegation for critchley.biz — current delegated names ns7.zoneedit.com and ns12.zoneedit.com resolve to the same IPv4 and IPv6 endpoints, weakening redundancy. Verified 2026-07-21 that dns1.zoneedit.com (165.22.116.248) and dns2.zoneedit.com (45.33.33.148) both serve the zone authoritatively with matching SOA serial 1784606704 and the correct webdav.critchley.biz record. Confirm with ZoneEdit that these are the supported nameservers for the legacy lifetime account, then update both the registrar delegation and in-zone NS records if ZoneEdit does not do so automatically.
• Wrote the LinkedIn post version of the authority essay (2026-07-25) — draft cut to ~2,615 characters at writing/failure-does-not-increase-authority-linkedin, from the full essay at writing/failure-does-not-increase-authority (kept unchanged as the original). Still to do: John reviews the cut version and posts it — not yet published.
• Confirmed which L2 gym-instructor docs to send to PT (2026-07-11) — selection settled; documents indexed in TFG/note-for-James.
• Filled in the L2 Programme Card (2026-07-22) — draft built to blueprint page 7 requirements and transcribed onto the official L2_-_Programme_card_John_Critchley.docx at www.critchley.biz/TFG/. Draft at TFG/programme-card-draft.