---
title: "Delivering code and checking results"
description: "Deliver Session changes through commits, pushes, and pull requests, then distinguish delivery receipts from local observations. Covers workspace and Agent repositories, retries, and undelivered work."
---

# Delivering code and checking results

Finishing a code change in a Session does not mean that it has reached GitHub. aachat does not automatically commit, push, or create pull requests. Check the change and its validation, then establish which repository and branch or PR received it.

Project documents, Media, and HTML use their own storage and synchronization mechanisms. This page covers delivery of Git-managed code and Agent capabilities.

## Two repositories and their destinations

| Area | Contents | Delivery destination |
|---|---|---|
| Workspace repo | Working code checked out at the Session workspace root | The Project's working branch when one is configured; otherwise the normal PR route |
| Agent repo | `identity.md`, `memory/`, `knowledge/`, skills, and `environment.yaml` | The Agent repository's `main`; pushed changes are available to subsequent Sessions |

Before working, check the Session repository, delivery destination, and repository instructions. A Team's default repository, a Project working branch, and the checked-out Session branch are different settings. Do not treat them as permission to skip a required PR and push to `main`.

Do not commit synchronized Project files under `aachat/projects/` or generated contracts into the workspace repository. See [Shared Documents](/en/docs/shared-documents) for documents and [Environment](/en/docs/environment) for environment configuration.

## Recording delivery as an Agent

These commands are for an Agent inside a Session started by aachat. In an external terminal or coding agent, use ordinary Git/GitHub commands; do not use `chat` outside an aachat Session.

Read `git status` and `git diff`, then commit only files relevant to the task. Follow the repository's tests and PR template.

```bash
git status --short --branch
git diff
git add path/to/changed-file
git commit -m "Describe the completed change"
```

For delivery to a configured working branch, replace `<working-branch>` with the verified destination.

```bash
git push origin HEAD:<working-branch> &&
chat delivery record-push --target <working-branch>
```

For a PR, push the Session branch, write the PR description to a file, and create the PR. Replace `main` in this example if the repository specifies a different base.

```bash
source_branch="$(git branch --show-current)"
git push -u origin HEAD &&
chat delivery record-push --target "$source_branch"
```

```bash
pr_url="$(gh pr create --base main --title "Describe the change" --body-file pr-body.md)" &&
chat delivery record-pr --url "$pr_url" --base main
```

The Agent repository is a separate Git worktree. Review and commit its changes, then deliver from that directory.

```bash
cd "$AA_AGENT_DIR"
git status --short --branch
git diff
# Add and commit the relevant files before running:
git push origin HEAD:main &&
chat delivery record-push --target main
```

`record-push` and `record-pr` save a receipt of a delivery that has just succeeded. They do not push to GitHub or create a PR. The examples use `&&` so recording follows a successful native operation. An Agent worktree can have a detached HEAD while its delivery destination remains `main`.

## What a human should check

Open the Session from the Project Work Panel and inspect its code delivery display and result. `PR #… created` represents a recorded PR; `Pushed to …` represents a recorded branch delivery. If the Session changed both repositories, inspect the workspace and Agent entries separately.

1. Check that the PR or branch belongs to the requested repository and destination.
2. Compare the delivered HEAD with the change and validation being reported. If more changes were made after delivery, check that those also reached the destination.
3. Read the PR description and checks, including unverified behavior and remaining work.
4. If the task includes merge, release, or verification after deployment, check those outcomes separately.

A delivery receipt does not prove CI success, review approval, merge, or production deployment. A stopped Session or a message saying “done” does not replace those checks.

## Local observations and attention

At the end of a turn, local observation inspects uncommitted changes, Session commits, and their relationship to a saved delivered HEAD. It does not fetch the remote or query GitHub, so it cannot establish remote delivery by itself. A missing or unavailable observation is not evidence of no changes.

| Display | Check and next action |
|---|---|
| Uncommitted changes | Inspect the diff and commit wanted changes. Do not discard work without checking its purpose |
| Push needed | Verify the destination, push remaining commits, and record the delivery |
| Delivery not recorded | Check whether the native delivery succeeded. If it did, retry only receipt recording |
| PR not created | Pushing a branch and creating a PR are separate. Create the required PR and record its URL |
| Unexpected target | Compare the actual destination with the destination fixed for the Session |
| Local inspection failed | Inspect the error and local Git state. Do not reinterpret failed observation as undelivered work or no changes |

The Local HEAD relationship `same / ahead / behind / diverged / unavailable` is a comparison result. In particular, a previous PR receipt does not establish delivery of commits made afterwards. Check the remote state as well.

If push or PR creation succeeded but receipt recording failed, do not repeat the external operation. Keep the same repository, branch, and HEAD, retry only `chat delivery`, and report the missing receipt. If the work boundary is unknown, history has diverged, or Git objects are unavailable, preserve the work and follow the recovery guidance. Never record a fictional delivery to clear attention.

## Before ending a Session

The working directory is not permanent storage. State whether the work is pushed, unpushed, or involves no repository changes, and hand over the PR URL or branch, validation, and remaining gaps. For unpushed work, explain what remains and the next action needed to deliver it.

See [Sessions](/en/docs/sessions) for workspace retention, cleanup, and resume; [Projects](/en/docs/projects) for accepting results; and [CLI](/en/docs/cli) for command syntax.