docs: reframe daily-drivers around direct tailscale reach

The rule claimed the agent can't reach the other daily driver, so the only move was to flag the drift. That's false: both machines are on the same tailnet, and this session repaired ratio's dotfiles over tailscale ssh. So the rule now says reach the other box directly to sync, verify, or repair, with flag-it kept as the fallback for when tailscale is down.

I added a section on the connection mechanics: tailscale status lists the nodes, the tailscale IP and MagicDNS name always resolve, a bare hostname only resolves when MagicDNS is configured locally, and the first connection needs StrictHostKeyChecking=accept-new.

1 files changed, 24 insertions, 4 deletions

diff --git a/claude-rules/daily-drivers.md b/claude-rules/daily-drivers.md
index eeda33f..a891c13 100644
--- a/claude-rules/daily-drivers.md
+++ b/claude-rules/daily-drivers.md
@@ -14,9 +14,17 @@ config, a systemd unit, a credential, a one-time bootstrap step — consider
 whether the *other* daily driver needs the same change, and flag it. Don't
 assume a change made on the current machine is live everywhere.
 
-This is a prompt to think, not a script to run. The agent can't reach the other
-machine; the point is to surface "the other daily driver may need this too" at
-the moment the change lands, so it doesn't silently drift to one box.
+Both machines are on the same tailnet, so the agent can usually reach the other
+one directly over tailscale ssh — it can sync, verify, or repair the other daily
+driver, not just flag the drift. Reach for that when a change needs to land on
+both boxes now. (This session repaired ratio's dotfiles and verified the fix
+over tailscale; the .emacs.d side has driven ratio the same way — `git fetch` +
+`reset --hard` and an `scp` across.)
+
+When tailscale is down or the other machine is offline, fall back to the
+original discipline: this is a prompt to think, and the point is to surface "the
+other daily driver may need this too" at the moment the change lands, so it
+doesn't silently drift to one box.
 
 ## How the sync actually happens
 
@@ -34,11 +42,23 @@ The mechanism depends on what changed:
 When the change is the one-time kind, say so explicitly: name the manual step
 the other machine still needs.
 
+## Reaching the other machine over tailscale
+
+`tailscale status` lists every node with its tailscale IP and online state.
+Connect by tailscale IP (e.g. `100.71.182.1`) or MagicDNS name (e.g.
+`ratio.tailf3bb8c.ts.net`) — both always resolve and connect. A bare hostname
+(`ssh ratio`) works only when MagicDNS is configured on the local machine;
+without it the bare name can fail to resolve, which makes the box look
+unreachable when it isn't. Prefer the IP or the full MagicDNS name when in
+doubt. The first connection from a new address fails host-key verification under
+`BatchMode`; add `-o StrictHostKeyChecking=accept-new` to clear it.
+
 ## Knowing which machine you're on
 
 `uname -n` returns the hostname (`ratio` or `velox`). Use it when a reminder is
 machine-specific ("on ratio, you still need to …") so the note is actionable
-rather than abstract.
+rather than abstract — and after an ssh hop, to confirm which machine you landed
+on.
 
 ## Current open instance