Use Lyt on multiple machines
Your PodYou have one pod. A second computer is not a second setup — it is that same pod projected onto another device. These four steps install Lyt there as a secondary machine, bring your existing vaults down, and sync the ones you work on.
One pod, many machines
Your pod is the set of vaults you can reach. It is not stored on any one computer — your markdown and its history live in Git, so they travel. What does not travel is the machine-local part: the registry and the search index, which each machine builds for itself.
So a second machine is not a second pod. It is another projection of the one you already have, and setting it up means installing Lyt, signing in as the same GitHub identity, and letting that machine rebuild its own local view of vaults that already exist.
1. Install Lyt here, as a secondary machine
This is an ordinary install with one thing added: the GitHub account. Signing in as the same identity is what makes this a second machine on your existing pod rather than the start of a separate one. Nothing is installed there yet, and the agent on that machine has never heard of Lyt, so the request names the package and the prerequisites outright.
Set up Lyt on this machine. This is a SECOND machine on a pod I already have — I am not starting a new one. Lyt is the npm package @younndai/lyt. It needs Node.js 20.9 or newer, npm, and git. 1. Check whether Node.js 20.9+, npm and git are available. If any is missing, stop and tell me exactly which. Do not install a language runtime or git yourself. 2. Check whether I am signed in to GitHub (gh auth status). I need to be signed in as the SAME account I use on my other machine — that identity is what makes this machine part of my existing pod instead of a separate one. If I am not signed in, or I am signed in as a different account, stop and tell me. 3. Install Lyt globally with: npm install -g @younndai/lyt If this needs administrator approval or fails, stop and show me the exact error. Do not use a different package, a different installer, or a privilege-escalation method. 4. Run: lyt init --auto --json This builds this machine's own local setup, and installs Lyt's agent manual and skills into your instructions so you know how to operate Lyt here. If my pod is already on GitHub under this account, this step recognises it and brings down the vaults my pod records. Then tell me what each step changed or created, say which steps made no changes, and tell me plainly whether this machine joined my existing pod or started a fresh one.
Nothing is published. What lands here depends on your pod: if it is already on GitHub under this account, this step reconstructs the vaults the pod records. If it is not — because your first machine has never synced its pod — this machine starts one of its own, so check that answer before continuing. Either way, vaults your pod does not record are not fetched; that is the next step.
2. See what else this machine can reach
Your pod records the vaults it knows about, and step 1 brought those down. This step looks wider: every Lyt vault the account can reach on GitHub, including ones your pod has never recorded.
Using Lyt, show me which of my existing vaults this machine can reach on GitHub. Look only — do not change anything or bring anything down yet.
Read-only, but networked: it walks every GitHub repository your account can reach. Repositories it cannot read or parse are skipped and logged, so a clean result is not proof the list is complete. Check it against what you expect.
lyt discover --jsonRead the list before the next step. If a vault you expected is missing, the usual cause is being signed in as a different GitHub identity than the one that owns it.
3. Bring those vaults onto this machine
This is the step that actually brings your notes down.
Using Lyt, bring the vaults you just found onto this machine. For each one, tell me whether it was adopted as mine or subscribed to as someone else's — I want the two lists separately.
This one writes, and it does two different things: vaults you can push to are adopted as yours, while vaults you cannot push to are subscribed as external material. A failed permission check counts as no-push, so a vault of yours can land as a subscription. Lyt does not ask again — run the read-only look above first.
lyt discover --autoIf you would rather walk it yourself, typing lyt init --wizard at a terminal opens the guided setup, which verifies the machine, detects another machine of yours, and walks the same joining step interactively.
4. Sync the vaults you work on
From here on, the two machines are peers on the one pod. Neither is the original, and neither holds the truth — Git does. Sync is how a machine puts its work there and takes the other machine's work back.
Using Lyt, tell me whether my research notes vault is in step with its remote. Check only — do not change anything.
The check is read-only.
lyt sync --check --vault research/notesUsing Lyt, sync my research notes vault — that vault only, not the whole pod. This one publishes, so tell me exactly what it pushed.
This step publishes, and Lyt does not ask again. Scoping it to one vault is your control. Add --no-publish to hold every outward action if you want a local-only pass first.
lyt sync --vault research/notesRun the sync when the check result is what you expected. Scoping the command prevents another vault from being published or changed by surprise.
If local state comes back incomplete
If something looks missing after all this, and your vaults are safe in their Git sources, your notes are fine — it is the machine-local bookkeeping that needs a rebuild.
Markdown and Git carry the durable content. Registry rows and search indexes are machine-local projections Lyt can rebuild, so an incomplete reconstruction is a local problem with a local fix. Diagnose it before applying any repair.
If the topology does not reconstruct cleanly, use repair and recover.