Review the exact change that will merge.

Start from two readable Active repositories.

An external contributor does not need target-organization membership. They first fork the public repository into an organization and project they control, push their branch there, and use that fork as the proposal source.

Open a pull request in three steps.

1. Compare.Select the source repository and enter full source and target refs. The target is the repository whose Pull requests tab you opened.
2. Add details and reviewers.Enter a title, rich-text description, and optional reviewer user IDs. Duplicate reviewer IDs are removed. Reviewers must be members of the target organization.
3. Review the snapshot request.Confirm source, target, title, reviewers, and visibility. Select Pin revisions and open.

At creation, the server resolves the exact source tip, target tip, and merge base. It does not trust revision values supplied by the browser. If the repository contains a valid pull-request pipeline, Mozaic also attempts to schedule the verify check automatically.

The current form accepts a title of up to 240 characters and a description of up to 256 KiB. Pull-request creation is idempotent, so retrying the same completed browser command does not create a second proposal.

Treat new source code as new evidence.

Pushing to the source branch does not silently rewrite the current review. Choose Synchronize source on an Open pull request when the author wants the proposal to adopt the latest source revision.

1. Finish the push.Make sure the intended source ref has reached the source repository.
2. Synchronize.Mozaic resolves source, target, and merge base again and creates the next sequential snapshot.
3. Re-review the result.Prior snapshot reviews and checks are cleared from current eligibility, previous execution grants are revoked, and conversations anchored to the older diff become outdated.
4. Run current checks.A new verify check is attempted automatically. Use Run verify if it was not scheduled or if a current-snapshot rerun is needed.

Submit conversations and a decision.

A reviewer needs Review code in the target project. The author can participate in discussion but cannot approve their own change.

Use a draft review for several comments

1. Start a review.Create a draft review for the current snapshot.
2. Add comments.Attach comments to an exact path and line, or add a general comment. A reply must point to a visible root conversation; replies do not nest again.
3. Offer a suggestion when useful.Suggestions are anchored to lines on the new side of the current diff. The replacement is staged with the comment.
4. Choose a decision.Select Approve, Request changes, or Comment. A comment-only review needs a review body or at least one draft comment.
5. Submit once.Mozaic atomically turns the staged comments into conversations and records the review decision against the snapshot.

Resolve conversations

Resolve only a current, non-outdated conversation after the requested change or explanation is complete. A branch policy can require every current conversation to be resolved. Outdated conversations remain in history but do not become current again.

Signed approvals

When branch policy requires signed approvals, approving with a fresh server-verified WebAuthn assertion records signature evidence. Password, TOTP, recovery-code freshness, and client-provided fields do not mark an approval as signed.

Run the repository pipeline for this snapshot.

1. Commit the definition.The source snapshot must contain a valid .mozaic/pipeline.yml with the pull_request trigger.
2. Schedule verify.The pull-request author can schedule their own current-snapshot check. Another member needs Run pipelines.
3. Follow the run.The check records the canonical plan hash, attempt ID, trust, and conclusion. Pull-request runs execute as external_restricted.
4. Rerun carefully.A rerun revokes older grants and cancels earlier runs for the same snapshot before creating a new attempt.

The execution grant is bound to the current snapshot and plan and expires after 30 minutes. Only a current, trusted, passed check satisfies a required check. Queued, running, failed, cancelled, infrastructure-failure, or indeterminate conclusions do not.

See Pipelines for the YAML schema, execution limits, artifacts, and run diagnostics.

Define admission rules on an exact branch ref.

Changing branch policy requires Manage source, an Active repository, and fresh authentication. Enter a full ref such as refs/heads/main; policies do not match prefixes or wildcards.

Pull-request admission

Require updates to pass through a pull request instead of direct ref updates.

Approvals

Require 0-20 distinct non-author reviewers' latest current-snapshot approvals.

Checks

Require up to 20 stable check names. The inherited default requires trusted verify.

Conversations

Require every current conversation to be resolved.

Signatures

Optionally require signed approvals and a verified signature on the exact source tip.

Strategies

Allow merge commit, squash, or both. At least one strategy is required.

Emergency bypass

Optionally let an actor with the separate Bypass branch policy claim supply a bounded audited reason. Signature enforcement remains non-bypassable unless policy explicitly makes it bypassable.

Merge only when the current target still matches.

1. Select a strategy.Choose Merge commit or Squash. The strategy must be allowed by the exact target policy.
2. Read every blocker.Mozaic evaluates status, draft state, target movement, decisions, approvals, checks, conversations, signatures, strategy, and bypass policy.
3. Refresh authentication.Merging requires Review code and a fresh authentication window.
4. Merge the exact snapshot.The server re-evaluates policy and compares-and-swaps the target ref. It fails instead of overwriting a target that moved after review.
5. Inspect the receipt.The pull request becomes Merged, the resulting revision is retained, grants are revoked, and recognized work-item references are applied idempotently after merge.

Eligibility blocker codes

not_open / draft

The proposal lifecycle cannot merge.

strategy_not_allowed

Select a strategy enabled by target policy.

target_advanced

The target no longer equals the pinned target revision. Synchronize and review the new snapshot.

changes_requested

A reviewer's latest current-snapshot decision requests changes.

approvals_missing

Not enough eligible current-snapshot approvals satisfy policy.

required_check_missing

A required check is absent, untrusted, or not passed for this snapshot.

conversations_unresolved

A current conversation remains open.

source_signature_missing

The exact source tip does not satisfy signature policy.

bypass_not_allowed

A bypass was requested but policy or the actor's scoped claim does not permit it.

An audited bypass reason contains 8-2000 visible characters. It is not a blanket override: target compare-and-swap and every non-bypassable invariant still apply.

Use lifecycle controls without erasing history.

• The author or a user with Manage source can close an Open pull request.
• A Closed, unmerged pull request can be reopened while its repository remains Active.
• Closing revokes execution grants. Reopening does not make old snapshot evidence current automatically.
• A Closed but conversation-unlocked pull request can still accept discussion and comment-only reviews. Approve and Request changes require Open status.
• Archiving the repository makes all existing pull requests read-only until the repository is reactivated.
• Merged is terminal; a Merged pull request cannot be reopened, synchronized, or otherwise edited.

Keep review evidence bounded.

• Mutations compare the current pull-request version. A stale tab receives a precondition failure instead of overwriting newer work.
• The author cannot approve their own work or request themselves as reviewer.
• Approval count uses each reviewer's latest decision for the current snapshot; repeated approvals do not inflate the count.
• Moderators can hide or restore submitted prose. Security/legal hard redaction permanently replaces current and historical prose and requires fresh authentication.

Resolve common failures.