Skip to content

Instantly share code, notes, and snippets.

View YoraiLevi's full-sized avatar
🎯
Focusing

Yorai Levi YoraiLevi

🎯
Focusing
View GitHub Profile
@YoraiLevi
YoraiLevi / instructions-a-stranger-can-follow.md
Created July 4, 2026 15:07
Writing instructions a stranger can actually follow — a tool-agnostic method for runbooks that reproduce on someone else's machine (practice / failure-prevented / checkable tell).

Writing instructions a stranger can actually follow

A method for reproducible runbooks: how to write a procedure that works on someone else's machine, months from now, for a reader who has none of your context. Tool-agnostic; applies to any setup, install, migration, or fix you want another person to be able to repeat.


Write for the person who will actually use this: a stranger, on a different machine, later, with none of the context that's currently obvious to you. Everything that's implicit in your head right now — which value goes where, what "it worked" looks like, which shell you're in — is absent from theirs. A good runbook closes that gap on its own: it stands alone, it proves itself as it goes, and it never assumes the reader's environment matches yours.

Each practice below is stated the same way: what to do, the failure it prevents, and the tell — how you know you actually did it.

@YoraiLevi
YoraiLevi / researching-without-fooling-yourself.md
Created July 4, 2026 15:07
Researching a hard problem without fooling yourself — a tool-agnostic method for depth and honesty (each principle: the practice, the failure it prevents, and the checkable tell).

Researching a hard problem without fooling yourself

A method for depth and honesty: how to investigate a hard technical question and reach an answer that is actually right — not merely plausible. Tool-agnostic; applies whether you research alone, with a team, or by directing others.


The failure this whole method guards against is the cheap one. You form an explanation early, it feels right because it's fluent, and you build on it — so a wrong premise quietly scales into confidently-wrong work, and the more you build the more expensive the correction becomes. Fluency is not evidence. The throughline below: anchor every claim to something a skeptic could check — a primary source, a measurement, the live system — and distrust every source until you have, including your own memory.

Each practice is stated the same way: what to do, the failure it prevents, and the tell — how you know you actually did it, so it's verifiable rather than aspirational.

@YoraiLevi
YoraiLevi / ssh-symlink-redirectionguard-windows.md
Created July 4, 2026 14:18
Make symbolic links traverse over SSH on Windows 11 — disable RedirectionGuard for sshd (fixes STATUS_UNTRUSTED_MOUNT_POINT), with pre/post verification, a no-security-rollback alternative, and the mechanism.
@YoraiLevi
YoraiLevi / sshd-as-user-howto.md
Last active July 4, 2026 01:09
Run the Windows OpenSSH service as your own user account — and see the SSH logon-session token change (Network -> Service); side effect: cmdkey/DPAPI/mapped drives work over SSH.

Run the Windows OpenSSH service as your own user account — and see the SSH logon-session token change

A follow-along runbook. Assumes the built-in Microsoft OpenSSH server is already installed and you can already log in over SSH with a key. Tested on Windows 11 / Server 2022, OpenSSH 9.x.


What this changes

By default the sshd service runs as LocalSystem. This guide changes it to run as your own user account. That one change alters the logon-session token your SSH sessions receive, and that in turn unlocks some things that don't otherwise work over SSH:

@YoraiLevi
YoraiLevi / windows-ssh-credential-session.md
Created July 1, 2026 04:39
Getting a credential-bearing session on Windows over SSH: logon types, why cmdkey/DPAPI/mapped drives fail under OpenSSH, and every fix (sshd-as-user, Cygwin passwd -R, Bitvise, scheduled tasks, Ansible become) with trade-offs to choose by your constraints.

Getting a credential-bearing session on Windows over SSH — why cmdkey, DPAPI and mapped drives fail under OpenSSH, the logon-type model that explains it, and every way to fix it (sshd-as-user, Cygwin passwd -R, Bitvise, scheduled tasks, Ansible become), with the trade-offs to choose by your own constraints.

By: YoraiLevi | Date: 2026-07-01


You SSH into a Windows box, and things that work fine at the desktop quietly fail. cmdkey /add … returns "Credentials cannot be saved from this logon session." Drive letters you mapped at the console (W:, Z:) don't exist in your SSH shell. net use \\server\share can't reach the share, or maps it and then loses it on reboot. Anything that reads a DPAPI-protected secret (Credential Manager, some Git/AWS credential helpers, saved Wi-Fi/VPN creds) comes up empty.

These look like five unrelated bugs. They are one thing seen through five APIs. Understand Windows logon session types and the whole landscape collapses into a single decision: *how do

@YoraiLevi
YoraiLevi / macos-power-user-setup.md
Last active June 27, 2026 15:06
macOS Power-User Setup — consolidated & deduped from 4 YouTube guides (119 items)
@YoraiLevi
YoraiLevi / push-ssh-key-to-server.md
Last active June 28, 2026 23:18
Windows OpenSSH server for a Tailscale mesh — per-user keys, key-only, pwsh shell (two-phase runbook)

Push this machine's SSH public key to a remote server (cross-platform)

Append this machine's public key to a remote server's authorized_keys over a single SSH session — from a pwsh (Windows) or bash/zsh (Linux/macOS) client, to a Windows or Unix server. Set user / host / target-OS in the variables at the top of a block; the rest is fixed.

Two tricks make it robust (learned the hard way):

  • The key is piped in over stdin, never embedded in the command — so there are no long lines to wrap into a broken multi-line command, and no key-quoting.
  • The remote command is assembled from short pieces (-join '; ' / printf '%s; ') so every source
@YoraiLevi
YoraiLevi / multi-agent-github-issues-handoff.md
Last active June 27, 2026 07:07
Multi-agent task queue on GitHub Issues — ENGINEER ON-RAMP / front door (2026-06-27)

Multi-agent task queue on GitHub Issues — engineer on-ramp

1-2 page front door. The evidence base — phased runbook, live proof table, build log, ~65 dated sources — is the deep report (docs/.research/multi-agent-github-issues.md). Read this to navigate that; the LOCKED decisions are owned here (the deep report carries the reasoning + runbook and defers to this page). Every claim below links to its source so you can check it in one click.

Cast of characters (one line each): GitHub Issues = the single durable task store (no external DB). gh = the CLI we drive everything through (v2.94.0, native deps GA). native blocked_by = a structured GitHub dependency relation ([`gh issue edit --add-blocked-b

@YoraiLevi
YoraiLevi / multi-agent-github-issues.md
Last active June 27, 2026 07:07
Multi-agent task queue on GitHub Issues — DEEP REPORT (homelab, YoraiLevi/project-proposals; 2026-06-27)

Multi-agent task queue on GitHub Issues — deep report

Deep report (full precision). Companion on-ramp: docs/.research/multi-agent-github-issues-handoff.md (~2-screen front door; the LOCKED decisions are owned there, this report carries the reasoning + runbook). Every load-bearing claim links inline to its source at the point of use. Recon executed live in YoraiLevi/project-proposals on 2026-06-27, gh 2.94.0 — see the Proof table and the Build log.

Topic: a system that stores tasks as GitHub Issues and lets multiple AI agents (Claude Code et al.) discover, claim, execute, and hand off work via the gh CLI on one private homelab repo with a single human owner.


1. Where this survey lands

@YoraiLevi
YoraiLevi / jj-gitbutler-handoff.md
Last active June 27, 2026 05:20
Multi-machine dev VCS — engineer on-ramp (Option C: GitButler + private mesh-remote + but-CLI automation). Front door to the deep jj-gitbutler research.

Multi-machine dev VCS — engineer on-ramp

1–2 page front door. The deep evidence — ~440 lines, ~57 cited sources, adversarial verdicts — is the deep report (docs/.research/jj-gitbutler.md). Read this to navigate that; every claim below links to its source so you can check it in one click.

Cast of characters (one line each): Syncthing = a peer-to-peer file syncer. git = the VCS underneath everything. GitButler = a git client built around virtual branches (apply several branches to ONE working tree at once; each edit/"hunk" is assigned to a "lane"). but = GitButler's command-line tool. jj (Jujutsu) = a separate git-compatible VCS we evaluated and rejected (can't coexist with GitButler — see [deep report, Axis 2](https://gist.github.com/YoraiLevi/b95c3a1261d4d454acb2b8