Watch a Project

TL;DR

Start with Review-paced while you learn how Zozo works in your repository, move to Full-speed when you can review several Pull Requests at once, and choose Autonomous only when passing checks are enough to merge. Every new Project needs an explicit primary Credential for both Dispatch and Intake; each activity can also have one fallback.

Choose Your Project Pace

When you add a Project, Zozo asks how quickly it should move through eligible work. A Pace is an add-time preset for two settings: Pacing and merge policy. Choose one of three options:

Pace	What Zozo does	Best for
Review-paced	Opens one Pull Request, then waits for you to merge or close it before picking up another Issue from that Project. Zozo leaves every Pull Request open for your review.	A new Project, a sensitive codebase, or any team that wants to inspect each change before Zozo starts the next one.
Full-speed	Keeps picking up eligible Issues even while earlier Pull Requests remain open. Zozo still leaves every Pull Request open for your review.	Teams that can review several Pull Requests in parallel but still want a person to merge each change.
Autonomous	Keeps picking up eligible Issues and automatically completes the Landing of each Pull Request when it's ready and its checks pass.	Trusted repositories where green CI is enough to accept a change.

Review-paced is the safest starting point. Full-speed can create Pull Requests faster than your team reviews them, while Autonomous can merge changes without waiting for a person.

The three presets map to those settings like this:

Pace	Pacing	Merge policy
Review-paced	On	open-PR-only
Full-speed	Off	open-PR-only
Autonomous	Off	auto-merge

After you add the Project, use the Pacing and Merge policy switches in Watched Projects to change those settings independently. The Base Branch field controls the branch used for future work.

Add Another Project

Open Projects in your Dashboard (#/projects). Under Add a Project, choose one of two paths.

Watch an Existing Repository

1. Choose Watch an existing repository.
2. Search the repositories available to Zozo's connected GitHub credential.
3. Select Add beside the repository you want to watch.
4. Choose Review-paced, Full-speed, or Autonomous.
5. Choose the primary Credential for Dispatch and for Intake, plus either an optional fallback Credential or No fallback for each.
6. Set Priority and Active, then select Add Project.

Create a New Repository

1. Choose Create a new repository.
2. Enter the repository name and select Create repository.
3. Choose Review-paced, Full-speed, or Autonomous.
4. Choose the primary Credential for Dispatch and for Intake, plus either an optional fallback Credential or No fallback for each.
5. Set Priority and Active, then select Add Project.

Zozo creates an empty private repository under your GitHub account and starts watching it immediately. The creation flow doesn't offer an organization or visibility picker. You can start an Intake Session for the new Project without any additional repository setup.

Lower priority numbers are considered first when more than one Project has eligible work. Leave Active on if you want Auto-dispatch to select work from the Project.

Your plan limits how many Projects you can watch. See Understand Your Quotas if you reach that limit.

Configure a Watched Project

Each row under Watched Projects has its own settings and actions. Changes apply only to that Project.

Active

Active controls whether Auto-dispatch can select new work from the Project. Turning it off doesn't interrupt a Run that's already in flight. Turn it back on when you want the Project to participate again.

The Active switch doesn't enable Auto-dispatch for the whole fleet. Use the dispatch control on the Dashboard for that standing mode.

Pacing

Pacing is on by default. While it's on, Zozo doesn't pick a fresh Issue from a Project that already has an Outstanding Pull Request, which is a Zozo-authored Pull Request that is still open. Merging or closing that Pull Request clears Review-paced work to continue.

Turn Pacing off when your review capacity can keep up with several open Pull Requests. Existing work can still resume and an automatic Landing can still finish while a Project is paced.

Merge Policy

The merge policy decides who completes a successful change:

• open-PR-only leaves the Pull Request open for a person to review and merge.
• auto-merge places the Pull Request into Zozo's Landing flow. Zozo waits for checks, verifies that the branch is current, handles safe updates, and merges when the change is ready.

Changing this switch also changes the displayed Pace when the new Pacing and merge-policy combination matches one of the three presets.

Base Branch

The Base Branch is the concrete branch used to create future Managed Worktrees and target their Pull Requests. Zozo fills it once from GitHub's default branch when you add a Project. Later changes to GitHub's default branch don't silently retarget the Project or an open Landing.

A Project added by an older Zozo version may have no stored value. It keeps using main until you select Resolve from GitHub or save a branch name. Zozo checks that the branch exists before saving it. If GitHub is unavailable, the save is refused so an unverified name can't strand a later attempt.

For a batch that lands automatically into staging before a manual merge to main, follow The Core Loop's staging workflow.

Credential Routes

Use Edit credential to set the Credential Route for Dispatch and Intake independently. Each route needs one primary Credential and can name one different fallback Credential. Both names can belong to the same Provider, such as a Claude subscription followed by a Claude API key. A Credential carries its Provider, so you don't set redundant Provider route fields.

Paused and unhealthy Credentials remain available to select and save. Missing names stay visible for repair, but Zozo won't save either activity's routes until every configured name resolves and both primary names are set.

Each selected Credential brings its own model and effort for the activity. Tune those values from its row on the Credentials page. Choosing a fallback Credential therefore chooses the model and effort that fallback will run with as well as its billing identity.

For fallback rules and routing examples, see Understanding Credentials.

Stop Conditions

Use Edit stop conditions to put ceilings on a Project's dispatch Runs:

• Max turns limits agent turns.
• Max tokens limits token usage.
• Max cost limits reported cost in US dollars.
• Timeout limits elapsed wall-clock time in milliseconds.

A Stop Condition ends a Run when its ceiling is reached. Leave a field unset to inherit the global value on Settings. If neither the Project nor Settings supplies a value, that ceiling isn't enforced. These settings apply to dispatch work, not Intake Sessions or Wayfinder sessions.

Unverified Landing

Toggle Unverified Landing authorizes an Unverified Landing for an auto-merge Project. This allows Zozo to merge when checks fail, aren't reported, or remain pending through the checks wait. Zozo still waits for the check verdict, verifies branch ancestry, and handles conflicts.

Use only when CI can't run

An Unverified Landing can merge defective code. Turn it on only when CI can't produce a passing result at all, and turn it off as soon as CI works again. The setting has no effect with open-PR-only.

Other Project Actions

• Start Corpus Map begins a Wayfinder map for the Project when Wayfinder is available. Zozo may also offer this once when you activate a Project. Zozo's Wayfinder is adapted from Matt Pocock's MIT-licensed wayfinder skill.
• Remove stops watching the Project and removes its saved configuration from this Dashboard.

How Work Reaches the Agent

Watching a Project establishes where Zozo can work. An open GitHub Issue joins the Frontier, the set of work safe to pick up, when it carries the ready-for-agent label.

With Auto-dispatch enabled, the Dispatcher:

1. Checks active watched Projects for open Issues on the Frontier.
2. Skips Issues that are claimed, awaiting a person, awaiting a Landing, or otherwise excluded.
3. Prefers priority-next, then the oldest eligible Issue.
4. Claims the Issue and starts its Dispatch.

An open Issue without ready-for-agent won't be selected automatically. See Label Reference for the complete label vocabulary and exclusion rules.

Related

• Work Model explains how Issues become Pull Requests and how Auto-dispatch finds work.
• Understanding Credentials covers Provider pins, fallbacks, models, effort, and named Credentials in more detail.
• Understand Your Quotas explains the watched Projects limit and concurrency limits.
• Quickstart walks through your first Project and first Run.