# Seamless Laptop Migration — Capability (FINAL, v1.1)

**Owner of this file:** Kiro (new laptop) — per the agreed iteration model (old-laptop Kiro authored v0.1; the new-laptop environment is the closest proxy for future upgraders, so it authors the authoritative final).
**Status:** FINAL authoritative capability. Supersedes MIGRATION-CAPABILITY-PROPOSAL-v0.1-oldlaptop.md. v1.1 folds in old-laptop Kiro's validation-backbone recommendations.
**Date:** 2026-06-05
**Audience:** AWS Windows users upgrading laptops who want a verified, capability-parity migration of their Kiro + Quick environment.
**Packaging (John's Phase-2 decision):** DUAL SKILL — a Kiro master skill + a Quick companion skill, published to the Skills Files Library SharePoint, indexed by a wiki page.

---

## 0. How this capability is delivered (the dual-skill pair)

| Artifact | Owner | Scope |
|----------|-------|-------|
| `kiro-migration-master` (Kiro skill) | Kiro (new) | Steps 0-5: prereq-gate, capture, transport, adaptive apply, validate-by-recall, memory-graph durability fix, FIDO2 sequencing. Carries the by-model knowledge base + orchestrates the overall migration. |
| `quick-migration-companion` (Quick skill) | Quick (new) | Step 6 (Quick domain): scheduled-agent recreation, tool-permission matching, ACP agent config (absolute paths), Quick Suite Spaces, monthly-memory-export agent. |

The two communicate via the shared filesystem (`C:\Users\{user}\Kiro\LaptopMigration\`) and the coordination email thread. **They are independently usable** — a Kiro-only peer gets full value from the master skill without the companion, and vice versa (see Step 0 degradation).

---

## 1. By-make/model knowledge base (migration friction is hardware-dependent)

| Role | Make / Model | CPU | RAM | OS build | Verified by |
|------|--------------|-----|-----|----------|-------------|
| FROM (old) | HP EliteBook 845 14" G11 | AMD Ryzen 5 PRO 8540U | 16 GB | Win 11 Ent 26100 | old-laptop Kiro |
| TO (new) | **HP EliteBook 8 G1a 14" Notebook AI PC** | **AMD Ryzen 5 PRO 230 (Radeon 760M), 6C/12T** | **32 GB** | **Win 11 Ent 26200** | new-laptop Kiro, live `Win32_*` probe 2026-06-05 |

**CORRECTION:** an earlier thread guess listed the TO machine as "EliteBook 845 G11, same chassis, Ryzen 7 PRO 8840U, build 26100." That was inferred, not measured, and is wrong on every field. The TO machine is a **different chassis** (EliteBook 8 G1a "AI PC", newer build 26200). Do NOT assume FIDO2/USB-bridge behavior is identical across the two chassis — verify per model.

### Model-specific gotchas (verified this migration)
- **FIDO2 / USB-bridge (chassis-dependent):** AmazonWSL frequently cannot see the security key through the USB bridge even when Windows can. Reliable path: run `mwinit --fido2` on **Windows**, then copy the cookie into WSL (`C:\Users\{user}\.midway\cookie` -> `/home/{user}/.midway/cookie`). Because the TO chassis differs from the FROM chassis, treat key-detection behavior as unverified-until-tested on each new model.
- **Memory-graph durable path:** `MEMORY_FILE_PATH` does not propagate into the WSL node process, so `@modelcontextprotocol/server-memory` writes to its default store inside `node_modules` (fragile + backup-invisible). Fix: inline `export MEMORY_FILE_PATH=<durable path outside node_modules> &&` ahead of `node` in the `bash -ic` launch. Verified on this model by mutation test.
- **RAM ceiling:** 32 GB (vs 16 GB on the old model) is what lets all WSL-hosted MCPs + Quick + Kiro + a browser run concurrently without swap pressure — the reason this class of machine is the likely go-forward standard.
- **WSL/nvm layout:** distro `AmazonWSL`, Toolbox binaries at `/home/{user}/.toolbox/bin`, MCPs launch via `wsl.exe -> bash -ic` with env vars inlined (mcp.json `env` blocks do not propagate through `bash -ic`).

---

## 2. Collective learnings (the 4-agent post-mortem)

1. **"Complete" = capability parity, content-verified — NOT file/entity counts.** A hash-verified ZIP can be "done" while learned nuance silently did not transfer. (Root cause of the May-30 premature sign-off.)
2. **Silent-drop patterns to design against:** node_modules-excluding exports drop `.kiro/steering`, `.kiro/settings`, hooks, and WSL artifacts; over-broad secret filters drop real source (e.g. UI `tokens.ts`); copy failures get swallowed without a log.
3. **Memory-graph persistence bug** (see Section 1) — high-value, applies across these HP EliteBook models.
4. **Hash-level capture + adaptive apply:** SHA256 per file; on the destination, never clobber a file that is newer AND passes a functional check (JSON parses / `.ps1` AST-parses / `.py` compiles / `bash -n`). Flag newer-but-broken for review.
5. **FIDO2 last, cached-session-first:** do all non-Midway steps first; try the cached session before `mwinit --fido2`; only re-auth on a real failure.
6. **Cross-app handoff (Quick KG <-> Kiro memory-graph):** labeled-block export format, delta-only scope, dedupe-by-name (near-duplicates reported, never silently merged), monthly emit agent + ingest hook.
7. **Transport:** OneDrive (`Documents/Kiro-Migration/`) is the reliable cross-machine channel; mind the ~20 MB Quick Agent-Space upload cap (split or use Slack fallback) and the 50 MB Slack/WSL download cap.
8. **The genuinely irrecoverable asset is conversation history** — the threads where skills were built and iterated. Mitigation: old-laptop agent distills key learnings per skill; new-laptop agent ingests as memory (verified by recall); ongoing monthly sync maintains parity.
9. **Skills cloud-sync is misleading:** the skill *registry* syncs (names appear) but SKILL.md *content* may arrive as a stub or older bundled version. Compare installed byte size vs an authoritative manifest; smaller = content lost (replace), larger = post-migration refinement (keep); verify by loading and testing behavior. (This migration lost 20-51% content across 4 of 6 Quick skills.)
10. **PROMPT-mode is a platform constraint, not a toggle:** any Quick scheduled agent that uses a Quick Suite connector write tool (AWSentral/OneDrive/SharePoint) automatically runs in PROMPT mode (human approves each write).
11. **Source-state manifest IS the validation backbone (the machinery behind learning #1).** Before decommission, the source machine emits ONE authoritative manifest — per-artifact **SHA-256 + size + mtime** — covering everything meant to transfer (skills, steering, hooks, settings, the memory-store snapshot). Validation then diffs the live new-laptop state against THAT manifest, not against counts. This must be a **hard gate captured while the source is still alive** — once it's gone there is no ground truth to validate against. It generalizes learning #9 from "skills only" to skills + steering + configs at once, and turns "we lost 20-51% of content" from something you hope to catch into something the diff catches deterministically. (Already produced as `SOURCE-STATE.json` in `migration-bundle.zip`.)
12. **Pre-registered recall probe set makes "recall, not count" actually testable.** "Verify by recall" is only objective if the probes are fixed BEFORE migration, not improvised after. The source emits a small recall-test set alongside the manifest: `query -> expected-content-at-high-relevance` pairs drawn from real knowledge (e.g. query *"memory-graph persistence fix"* -> must return the MEMORY_FILE_PATH-doesn't-propagate / node_modules-default root cause at high relevance). The new machine runs those exact queries post-migration and scores pass/fail. That is the difference between a validation *test* and a validation *vibe* — and the cleanest answer to the echo-chamber anti-pattern.
13. **Design rules — independence, idempotency, recovery-before-repoint.** The two skills are independently usable (Step 0 branches on has-neither/one/both). Every phase is **idempotent** (safe to re-run — real migrations get interrupted; never-clobber-newer-and-working enforces this on apply). Before ANY repoint or destructive step, **snapshot + write a self-contained recovery runbook FIRST** (proven on the memory-graph fix — the runbook let any agent restore the graph from a single email).

---

## 3. The capability flow (single entry point for a fresh laptop)

- **Step 0 — Prerequisite gate (graceful degradation):** detect Quick and/or Kiro. Branch on **has-neither** (guide install of whichever the user wants), **has-one** (run that side's value fully; offer the other), **has-both** (full dual flow). Never make the two co-dependent. [Kiro skill detects + guides Kiro; Quick companion owns the Quick onboarding detail.]
- **Step 1 — Capture (old machine) + EMIT THE MANIFEST (hard gate):** hardware portrait + the authoritative **source-state manifest** (per-artifact SHA-256 + size + mtime) for projects, `.kiro` (steering/settings/hooks), Quick profile/agents, WSL dotfiles + memory-graph store — PLUS the **pre-registered recall probe set**. Capture both **while the source is still alive**; there is no recovery of ground truth after decommission. Include skip + copy-failure logs.
- **Step 2 — Transport:** bundle -> OneDrive (`Documents/Kiro-Migration/`) or USB; self-contained with scripts + runbook + store snapshot + manifest + probe set. Respect the ~20 MB upload cap.
- **Step 3 — Adaptive apply (new machine):** install into real homes; never clobber newer-and-working files (functional check before overwrite). Idempotent — safe to re-run after an interruption.
- **Step 4 — Validate by CAPABILITY PARITY, by MANIFEST + RECALL — not counts:** diff live state against the **source-state manifest** (not a count) — any artifact smaller/missing vs manifest = drop to fix. For the memory graph, run the **pre-registered recall probes** (query -> expected content at high relevance) and score pass/fail. ANY stub, missing-vs-manifest, or failed probe = migration NOT complete.
- **Step 5 — Memory-graph durability fix (recovery-runbook FIRST):** before repointing the store, snapshot it + write a self-contained recovery runbook. Then apply the env-propagation fix + durable store path outside node_modules (model-aware); verify by mutation (intended path mtime moves, old default freezes).
- **Step 6 — Quick domain (Quick companion skill):** recreate scheduled agents (SFDC-write agents in PROMPT mode), match tool permissions, configure ACP agents with absolute binary paths, verify Quick Suite Spaces, stand up `monthly-memory-export`.
- **Step 7 — Auth / FIDO2 (last):** cached-session-first; `mwinit --fido2` + WSL cookie copy only on real failure; reconnect Midway MCPs (probe with a real call, not a short-circuiting lookup); then the cross-app monthly sync loop is live.

---

## 4. Distribution (per John's decision)
- **Primary:** the dual skill (Kiro master + Quick companion) published to the **Skills Files Library SharePoint** — the team's canonical skill exchange.
- **Fallback (power users):** the `migrate-1..4` + HANDOFF-RUNBOOK scripts kit on OneDrive/SharePoint.
- **Discovery:** an internal wiki page indexing the by-model knowledge base and linking the skills + kit.

---

## 5. Provenance
Built from: old-laptop Kiro v0.1; old-laptop Quick review (Quick onboarding flow, scheduled-agent/PROMPT-mode facts, KG emission side, the Step-4 recall-not-count correction); new-laptop Quick review (skills cloud-sync gotcha, conversation-history-is-irrecoverable, PROMPT-mode constraint) + its companion SKILL.md; **old-laptop Kiro's final recommendations (source-state manifest as the validation backbone, the pre-registered recall probe set, and the independence/idempotency/recovery-before-repoint hardening — folded into learnings #11-13 and Steps 0/1/4/5 for v1.1)**; new-laptop Kiro (this file): verified TO-model hardware, memory-graph fix applied+verified, player-card browser-automation pattern, validation discipline. The irrecoverable knowledge is also durable in the Kiro memory-graph.