# 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—useful for getting code onto IBM i for integration with traditional source member-based IBM i source control / change management systems.

### Sync / Deploy Credentials

How member sync and UI deploy authenticate depends on the **Sync / deploy credentials** setting on the connection (configured in [Environments > Connections](admin/environments.md#connections)):

- **Prompt** (default for new connections) — You are prompted for a **user profile** and **password** each time you sync or deploy. The password is used once to establish the connection and is never stored.
- **Connection** — Sync and deploy use the SSH user and key already configured on the connection. No additional credentials are needed at runtime.

### 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. If the selected actions use **Prompt** mode, enter your **user profile** and **password**
5. **Select files** to sync from the file tree
6. Click **Commit Changes** — approval proceeds, then the sync runs automatically
7. 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 the **Sync to IBM i** / **Deploy to EJS** button (top-right actions on task detail). The button label adapts based on which types of changed files exist: **Sync to IBM i** for source members only, **Deploy to EJS** for EJS display files only, or **Sync to IBM i & Deploy to EJS** when both are present.
2. Enter the target **library name** when syncing source members
3. If the task also has changed EJS display files, the same dialog includes those files in the selection tree and shows the IBM i IFS target path
4. If the selected sync or deploy actions require prompted credentials, enter your **user profile** and **password**
5. **Select files** to sync or deploy from the file tree
6. Click **Sync**, **Deploy**, or **Sync & Deploy** to start
7. A live log streams the progress

If both source sync and EJS deploy files are selected, source sync runs first and EJS deploy runs second. The button appears only when the task is approved, the environment has an IBM i connection with either the Sync or EJS Display Files feature, and there are eligible changed files to operate on.

### File Selection

The sync dialog shows a file tree of all changed files. Files with recognized IBM i extensions are pre-selected. Files that can't be IBM i source members (name too long, non-source file types like `.gitignore`, `*.md`, etc.) are disabled.

### 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 extension (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.
