docs: T420 → new laptop migration runbook - #61
Conversation
Drafted ahead of the replacement machine so cutover is a checklist rather than a reconstruction. The T420 is a single point of failure for the project: it holds the reference Bernese install, the campaign data, and the keys to gps3. Scanned the machine to ground the plan rather than write it generically. Findings worth acting on before any laptop arrives: - /home is at 97% (4.2G free) - all 57 repos live on an off-brand SSD; 1 repo has unpushed commits and 8 have no upstream at all, so they may exist nowhere else - ~/surveys (8.9G) and PAGENET (18G) are T420-only - SMART was not captured (needs sudo) — step 1 of the runbook Also settles the Claude-memory question: memory/*.md scanned clean (196K, no secrets, no client references) and can go to a private repo; transcripts cannot (89M, two files contain the leaked token); global config must not go anywhere agency-bound. A commit is permanent — there is no temporary commit. Documents the path-encoding trap that will otherwise silently orphan the memory directory on a machine with a different layout.
|
Warning Review limit reached
Next review available in: 46 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Moves README_FOR_GPS3_CLAUDE.md into the repo. It is the T420 session's instructions for the DOSTB20150918 external drive, written immediately before the drive was unplugged and carried to the R740: what is on it, what must not be touched, and why it must be mounted read-only. The operative point is that the drive being on this machine's USB bus removes the 6 MB/s wifi bottleneck that has kept /srv/gnss-archive/legacy empty. 26 GB of RECOVERED_* is minutes rather than a day. That is the highest-value thing available while it is attached, and it is the only irreversible one — the drive is currently the sole complete copy of material rescued from three dead or dying disks. Two corrections to the session log, both found by the T420 rather than by me: Section 15.4 claimed "all work reached main". It had not and has not. origin/main is still at 1d1082e (PR #60); PRs #61-#65 are all open. Rule 5 says to verify origin/main actually advanced rather than infer it from a successful push, and this was written in the section meant to be the authoritative end-of-session state. Section 14.5 predicted that PAGENET_DLY.PCF, being RNX2SNX truncated at 514, would leave 599 DUMMY waiting on an undefined 522. Now that the real file is available, that is wrong: its 599 waits on 512 514, there is no 521/522, and find_dangling_waits reports zero. The reduction was done properly. The advice to capture rather than re-derive survives, but on the weaker and more honest ground that the captured file is the one actually validated and the 9xx tail involves choices a reconstruction would guess at. One further note on method. The script applying these two corrections printed "both corrections applied" unconditionally, and the second replacement had silently failed to match on a backtick. A success message from something that verified nothing — the same defect the log catalogues five times in section 15.5, committed while correcting an entry about it. Both edits are now confirmed present by grep.
1 participant
Drafted now, to execute when the replacement laptop arrives.
The T420 is a single point of failure for the project — reference Bernese
install, campaign data, keys to gps3, accumulated context. This makes cutover a
checklist instead of a reconstruction.
Grounded in a scan of the machine, not written generically. Findings that
matter before any laptop arrives:
/homeis at 97% (4.2 G free) — a live problem, not a migration onecommits and 8 have no upstream at all, so they may exist nowhere else
~/surveys(8.9 G) andPAGENET(18 G) are T420-only and belong on gps3regardless of migration
If either SSD shows pending sectors this stops being scheduled work.
Settles the Claude-memory question with a scan rather than an opinion:
memory/*.mdis clean (196 K, zero secret patterns, zero client references) andcan go to a private repo; transcripts cannot (89 M, two files contain the leaked
token); the global config must never go anywhere agency-bound. The
AKIAhitswere false positives — zero strict AWS-key-shaped matches.
Also documents the path-encoding trap: Claude Code derives its memory
directory from the cwd with
/and_both becoming-, so a new machine witha different layout silently starts with empty memory. That already caused one
remediation cycle on this machine.
Deliberately vague about the other client's details in §2 — naming them in a
repo heading toward agency records would be the same mistake the document warns
about.