# Approval & Deployment

Once a task completes successfully, you review the changes and decide whether to approve and deploy them. This is the final step before code goes into your repositories.

## Reviewing Changes

Before approving, carefully review what the agent changed.

### Changes Review Process

1. **Open task detail** page for completed task
2. **Scroll to "Results" section**
3. **View files changed** showing git diffs for each repository
4. **Review test results** (passed/failed counts)
5. **Read activity feed** to understand what was done

## Approving Tasks

When you're satisfied with the changes, approve them to commit and optionally push.

### Approval Workflow

1. **Click "Approve" button** on task detail
2. **Adjust generated commit message** if desired
3. **Choose deployment options**:
   - **Pull from remote after commit (rebase)**: Keep local branch up to date
   - **Push to branch**: Immediately push to the current/default branch
   - **Create new branch**: Create a new branch for this work
   - **Commit only**: Commit but don't push (manual push later)
5. **Click **Commit Changes** when ready

### Approval Restrictions

You cannot approve if:
- **No changes**: Task made no file modifications
- **No container**: Environment has been deleted
- **Task is queued or running**: Wait for task to complete
- **Permissions**: You don't have permission to approve for this environment

### After Approval

Once approved:
- Changes are **committed** with your commit message
- Changes are **pushed** (if you selected that option)
- Task status shows **"Approved"**
- Approver info is recorded (name, email, timestamp)
- Previous approval status is cleared if you provide follow-up instructions

## Creating Pull Requests

After approving task changes, you can create pull requests on GitHub or Azure DevOps to merge your work into target branches.

### From Approval Dialog

Create pull requests directly when approving:

1. Click **Approve** button
2. Check **Create pull request** (auto-enables push and new branch options)
3. Enter **branch name** (applied to all repositories)
4. Click **Commit Changes**
5. Review auto-generated **PR title and description**
6. Click **Create Pull Request**

Pull requests target the branches you selected when creating the task.

### After Approval

If you already approved and pushed to a new branch:

1. Click **Create Pull Request** button (top-right actions)
2. Review auto-generated **PR title and description**
3. Click **Create Pull Request**

The button appears only when the task is approved, pushed to a new branch (different from target), and no PRs exist yet.

### Requirements

- Approved and pushed to new branch
- Git provider supports PRs (GitHub, Azure DevOps)
- OAuth connection authorized (prompted if needed)

### After Creation

- PR links appear in task detail
- Review and merge through Git provider

## IBM i Sync

For environments with an IBM i connection that has the **Sync** feature enabled, you can sync changed source files directly to an IBM i library. This writes source members to the target library via SSH—useful for getting code onto IBM i for integration with traditional source member-based IBM i source control / change management systems.

### From Approval Dialog

Sync as part of the approval step:

1. Click **Approve** on a completed task
2. Check **Sync to IBM i** (appears only when the Sync feature is configured)
3. Enter a **library name** (max 10 characters, alphanumeric)
4. Click **Commit Changes** — approval proceeds, then the sync runs automatically
5. A live log streams the sync progress

The library is created if it doesn't exist. Source physical files and members are created from the changed files.

### After Approval

If you already approved without syncing, or need to sync again to a different library:

1. Click **Sync to IBM i** button (top-right actions on task detail)
2. Enter the target **library name**
3. Click **Sync** to start
4. A live log streams the sync progress

The button appears only when the task is approved and the environment has an IBM i connection with the Sync feature.

### Sync Details

After a sync completes, the task metadata shows the synced library name, timestamp, and a link to view the full sync log.

File mapping follows IBM i conventions:
- **Member name** — filename without extensions (max 10 characters)
- **Source type** — last file extension (e.g., `RPGLE`, `SQL`)
- **Source physical file** — parent directory name (e.g., `QRPGLESRC`)

## Deployment Workflow

### Full Task Lifecycle

1. **Create task** with instructions
2. **Agent runs** autonomously
3. **Review changes** (patches, logs, tests)
4. **Provide feedback** if needed (follow-up instructions)
5. **Agent resumes** and refines work
6. **Repeat until satisfied** (steps 3-5)
7. **Approve changes** when complete
8. **Changes deployed** to your deployment target

### Multi-Variant Deployment

When comparing multiple agents (task groups):

1. **All variants complete**
2. **Judge tasks evaluate** (if auto-judge enabled)
3. **You select winner** (manually or via judge recommendation)
4. **Approve winner variant**
5. **Changes from winner** are deployed
6. **Other variants** remain available for reference
7. **Loser variants** can be deleted or archived

### Approval Audit Trail

CoderFlow tracks:
- **Approver**: Who approved the changes
- **Approval time**: When approval was given
- **Commit message**: What was written
- **Branch deployed to**: Where changes went
- **Remote push**: Whether changes were pushed

This creates an audit trail for compliance and history.
