e66ce599 · zzmq.dev@gmail.com/zz
Commit
e66ce599a923471ce1dc41ae5f210f4c58c13f55
zz login + zz agent/repo: full CLI parity with the web app Per direct instruction: "everything you can do in web should also be something you can do in cli/tui -- that's a nonnegotiable UX parity." Adds the CLI side of the JSON /api/* layer from the previous commit: - `zz login`: opens a browser to the existing OAuth flow (Cloudflare/ Google), polls a single-use nonce until the callback mints and hands back a token, saves it to ~/.zz/credentials.json (mode 600). Same approach `gh auth login`/`wrangler login` use -- built on our own OAuth flow rather than embedding a client secret in a distributed CLI, which shouldn't happen (those secrets belong server-side only). - `zz agent create/token/list`: create a peer Agent, mint/show its bearer token, list yourself + Agents you've created. - `zz repo create/list/grant/ask`: create a repo (optionally owned by an Agent you created), list/search repos, grant a repo Role, post a work Ask to a repo's root Lane. All of it calls the exact same JSON API and core logic (doCreateAgent/ doMintToken/doCreateRepo/doRbacGrant/doPostAsk in webApp.ts) the web forms call -- one behavior, two surfaces, not a CLI reimplementation that could drift from the web one. Real bug found and fixed while verifying `zz repo ask` live: repos created through the web/API path never got a "_repo" root Lane bootstrapped (only the Ladder's "_repo" root rung, a different thing) -- demo/greenfield.ts's local flow always did this bootstrap, the web/ API path never did, so posting an Ask threw "no such lane: _repo" on every repo ever created that way. Fixed with a lazy bootstrap in doPostAsk (check lane_get first, lane_propose if missing) -- self- heals every existing repo, not just new ones, confirmed live against a repo created before the fix. Needed a small tools.ts addition: lane_propose now accepts an optional explicit `id`, needed for the well-known "_repo" id (previously only reachable by calling the engine's proposeLane() directly, which Worker code can't do -- it only has the tool surface via MaintainerDO.callTool). Verified live end to end: real `zz login` run against the deployed Worker (actual browser OAuth, actual CLI polling, actual credentials file written); zz agent create/list/token; zz repo create/list/grant; zz repo ask failing then succeeding after the lazy-bootstrap fix on the SAME pre-existing repo. Test repo/agent/tokens cleaned up after. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Troy Howard <thoward37@gmail.com> -- 2026-10-12T02:32:03.000Z