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 a Platform with a stored Platform Credential, then choose one of two paths. For Atlassian, pick a Jira project from the bound site in the registration dialog, then its required base-level Publish Issue Type and optional parent-capable Spec Issue Type. Optionally pick a component and enter labels to narrow the scope; all four stay editable later from the Project's row menu. Atlassian Label Authority defaults to Observed, with Owned an explicit opt-in. If Atlassian is missing, follow the link to Credentials and save its Platform Credential.

Watch an Existing Repository

1. Choose Watch an existing repository.
2. Search the repositories available to the selected Platform Credential. Atlassian lists repositories in its bound Bitbucket workspace.
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. Review Build command and Test command, then set Priority and Active and 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 Build command and Test command if needed, then set Priority and Active and select Add Project.

Zozo creates an empty private repository under your GitHub account, or in the bound workspace when the Platform is Atlassian, and starts watching it immediately. The creation flow doesn't offer an organization or visibility picker; a Bitbucket create may name the Bitbucket project key to file it under. You can start an Intake Session for the new Project without any additional repository setup. Bitbucket creation needs the optional Repositories admin and Repositories write permissions described in Atlassian Projects.

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.

Atlassian Projects support Small Intake, plus Medium Intake and Large (Wayfinder) when a Spec Issue Type is set. Prototyping Sessions and prototype Tickets require GitHub. Both token health readings on the Atlassian Platform Credential must be valid before Dispatch can select work.

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.

Build and Test Commands

When you select a repository in Setup or Add a Project, Zozo reads its root package.json through the GitHub Platform Credential. A build script prefills Build command with npm run build; a test script prefills Test command with npm test. A missing script leaves its field empty. If the read fails or the file is absent, both fields stay empty and you can still add the Project.

Review the commands before adding the Project. Use Edit commands on Projects to change them later. Saved values apply to the next Run and preserve the commands on existing Projects until you edit them.

Empty means no configured check

Leaving either field empty explicitly disables that configured check. Set the commands your repository needs so future Runs receive the right build and test instructions.

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.

Spec Branch

A Spec is the parent Issue published for a Medium or Large Intake Session. The Spec Branch setting in the Project's Actions menu supplies the default for its plan review toggle. New Projects default to Spec Branch on and Auto-land off. Small Intake Sessions publish without a Spec.

With the toggle on, Publish creates the Spec, then creates and pushes spec/<N>-<slug> on GitHub or spec/<key>-<slug> on Bitbucket from the current Base Branch tip before creating any sub-issues. N is the GitHub Spec number; key is the lowercased Jira key. The slug comes from the title. The Dispatcher stores the choice with its configuration.

Choose before Publish

The Spec Branch choice, branch name, and target are fixed once published. If branch creation fails, Publish stops before creating sub-issues and reports the Spec number or Jira key so you can inspect the created parent Issue.

After Publish issues, Medium and Large Intake Sessions return to the Dashboard, where the new Spec Group scrolls into view and briefly highlights. A Spec Group gathers the Spec's implementation Issues and shows completed, In Progress, and queued work. Watch its progress there; the Intake Sessions list links the published session to its Spec on its tracker. When a Spec published without a Spec Branch has every planned sub-issue closed and at least one completed, a header-only Done Spec Group appears at the bottom of In Progress; review it and choose Close Spec to close the Spec on its tracker and remove the group on refresh.

The controls beneath the tinted header show the read-only Spec Branch route, a labeled Auto-land switch with On/Off text, and the Spec Pull Request link when available. A Spec without a Spec Branch shows its direct Base Branch target.

Auto-land authorizes Zozo to merge the completed Spec Branch into its Base Branch automatically. You can change it after Publish until the worker selects the Spec for Landing. Turning it on alone leaves it editable.

Auto-land locks when Landing starts

When the worker claims the Spec for execution, it records an automatic Landing Trigger and locks Auto-land. The confirmed value stays locked after refresh, restart, or a blocked Landing. An older browser cannot change it after that claim.

A failed setting write keeps the confirmed value and shows an error. Review any Landing blocked reason beside the controls and open the Spec Pull Request to inspect the work.

See Specs for Spec Refresh, manual refresh controls, and Spec Pull Request repair.

Credential Routes

Use Edit Credentials 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.

The Dispatch route also applies while an authorized Landing repairs a branch conflict or failing checks. If the repair's Credential refuses the Run or reaches its usage cap, Zozo continues the same repair on a linked successor Thread using the eligible configured fallback. Before starting that fallback Run, Zozo inspects the surviving branch and Workspace. A clean, committed repair is pushed and freshly verified without another Run; partial, uncommitted, or uncertain work stays in place for the continuation to finish. The existing Pull Request, branch, Workspace, and available Thread history stay with the repair. Turning off Auto-dispatch doesn't cancel that authorized Landing; use Stop when you need to halt it.

An authorized Landing also survives deletion of its repair Run or Thread. Automatic recovery and Retry landing first confirm that the old repair isn't still writing, then verify the existing Issue instructions, Pull Request branch and Base Branch, fresh conflict or check evidence, and the surviving Workspace. A replacement repair continues the same Pull Request and explicitly identifies any missing conversation history. Zozo keeps local work untouched and reports a specific obstacle when it can't establish ownership or evidence safely. A stopped Landing remains stopped after deletion until Retry landing grants fresh authorization.

If every configured Credential is paused or unusable, the Landing stays visible with each route's refusal reason and its known reset time, or an explicit unknown time. If all Run slots are occupied, it instead shows "waiting capacity." Either wait holds no Run slot and doesn't prevent another eligible Landing from progressing. Zozo reconsiders the repair automatically under the normal Credential pause and admission rules, even while Auto-dispatch is off. Retry landing asks for an immediate re-evaluation; it doesn't bypass a pause or claim that a Run started.

For fallback rules and routing examples, see Understanding Credentials.

Stop Conditions

Use Edit stop conditions to put ceilings on each objective handled for a Project. One allowance follows the objective across its initial dispatch Run, Steers, automatic continuation, Landing Repair Runs for conflicts or failing checks, and recovery after restart:

• Max turns limits agent turns.
• Max tokens limits token usage.
• Max cost limits reported cost in US dollars.
• Timeout limits active execution time in milliseconds. Time waiting for a person between Runs doesn't consume it.

Max turns and Timeout can interrupt active Claude work: turns are observed as Claude emits agent messages, and Timeout has its own wall-clock timer. Claude reports token and cost usage at the end of a Run, so Max tokens and Max cost apply when that delayed observation arrives and prevent later continuation or repair work. They aren't live cost cutoffs for an active Claude Run.

The Dashboard's Thread Detail page shows consumed and remaining allowance. Exhaustion stops automatic continuation and Landing repair submission, and isn't retried as an ordinary failure. Use Increase allowance by 50% there to record an explicit human increase; Resume and repair retries never replenish the allowance.

Missing usage stops continuation

Zozo won't treat missing Provider usage evidence as zero. If a configured token, cost, or active-time limit can't be evaluated safely, Thread Detail shows the uncertainty and continuation waits for a person.

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.

A freshly created repository has no checks wired up yet, so its first Landing blocks with "no checks reported" until you decide what to do about it. Turn on Unverified Landing (config key landWithoutPassingChecks) to get past that first block, then retry the Landing. Once a later Pull Request adds CI to the repository, turn Unverified Landing back off so future Landings wait for a real check verdict.

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 or Jira 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.