Zozo: an inspectable issue-to-PR example and a review checklist for coding-agent work

[ryanroundhouse]

I'm Ryan, founder of Zozo. This post was prepared with AI assistance from the public issue, diff and CI logs linked below.

Zozo coordinates coding runtimes, including Codex, against a backlog. I wanted to share an example that developers can actually inspect, along with the checks I'd use before trusting the resulting PR. This example does not establish which runtime produced the change, so it is not a Codex benchmark.

Trace a small task through the evidence

Issue 17 in our public Discord-game demo asks for a read-only /market command. Buying and selling are out of scope. Merged PR 18 is the implementation.

Three useful review paths:

1. Persistence: src/db/repositories/station-markets-repository.ts stores one market per guild. The repository tests cover first-read seeding, persistence of the ticked state and separate guilds.
2. Presentation: src/engine/economy/market-view.test.ts checks commodity ordering and price/stock formatting. The command tests check the no-ship response and the market embed.
3. Boundaries and gaps: CI includes the engine layering tests. The command also has a no-guild branch, but this change adds no dedicated test for that branch. That's a concrete review question.

GitHub Actions run 40205403766 passed lint, build and 246 tests across 21 files. Check the checkout step: it tested merge ref ad35555e1193a5d3529059045046c8ae424fbb97, combining PR head c9aebb81aaf2e37dcc4333787bf931e4a4debb99 with the then-current base. It did not test the raw head alone.

The PR body separately labels the checks inside the Zozo Run as a Verification Gap. Later CI does not change that journal evidence. Dependency installation reported seven audit vulnerabilities; this walkthrough does not assess exploitability or establish production readiness. There is no unattended-speed claim here.

A small review receipt

For each agent-produced PR, keep: issue/acceptance criterion; relevant diff and test; configured checks; PR head SHA; CI-tested SHA; in-Run evidence versus later CI; unresolved warnings or untested paths; your review decision. This checklist works without Zozo too.

Reproducing the check

Also record the actual Node/npm versions and working directory used by the agent and CI, separately from the Node version used to start Zozo. At the example's PR head, package.json declares Node >=22; its CI configuration selects Node 22 and runs npm ci, lint, build and test. Those configuration values do not establish the exact interpreter used in the historical Zozo Run. That remains Not observed here, not a demonstrated version mismatch.

For a new trial, capture node --version, npm --version, the actual test command and test count in both contexts. If a result cannot be reproduced, compare the tested commit and environment before attributing the difference to the coding model.

For a Zozo trial on a repository you control, the Local quickstart starts with npx zozohq@latest up. Use one small issue and Review-paced / open-PR-only, with explicit Dispatch/Intake credentials and real build/test commands. Empty check fields disable those checks. Review eligible work before enabling auto-dispatch.

Local Stack is free; model access is separate. Requirements include Node 22/24/26, Git and, for GitHub projects, GitHub CLI 2.94+. Agents run unrestricted as you with your files; loopback is not a filesystem sandbox. Closing the terminal stops the stack. Windows support currently directs you to Claude Code; Zozo's Codex provider is not supported on Windows yet.

Supported runtimes are Claude Code, Codex and OpenCode via OpenRouter. OpenCode is the runtime, OpenRouter supplies separately metered model access through an API key, and a usable runtime must be present. OpenCode effort is low/medium/high; subscription credentials are unsupported.

Projects use GitHub + GitHub Issues, or matched Jira Cloud + Bitbucket Cloud. Atlassian is limited to one Jira site and Bitbucket workspace per Stack: no GitHub/Jira mixing, Bitbucket Issues, Server/Data Center or Atlassian prototyping. Medium/Large Intake and Wayfinder need a Spec Issue Type. This example only demonstrates a GitHub evidence trail.

For people reviewing coding-agent work: which missing detail in a handoff like this most often prevents you from accepting the PR?

[TheodorNEngoy]

One addition to the review receipt: the boundary-case input behind each coverage claim. In PR18’s repository test, the comment says the third read is earlier than the persisted timestamp, but it passes later again. Reading at t0 after the later read, while still expecting lastUpdated to equal later, would exercise the stated no-rewind case.

I inspected the public diff and source; I haven’t run the tests or bot. This is a coverage gap, not evidence that the implementation rewinds time.

[ryanroundhouse]

Lol you're right. Thanks for finding that.