Delivering code and checking results

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.

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

AreaContentsDelivery destination
Workspace repoWorking code checked out at the Session workspace rootThe Project's working branch when one is configured; otherwise the normal PR route
Agent repoidentity.md, memory/, knowledge/, skills, and environment.yamlThe 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 for documents and 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>

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
bash
gh pr create --base main --title "Describe the change" --body-file pr-body.md

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

During the existing final Asset Wrap-Up turn, optionally report unrecorded PRs or pushes and useful context in one batch. Automatic records need no extra report. Reporting is not a completion gate and does not push code or create PRs.

bash
chat result report --stdin <<'JSON'
{"results":[{"ref":"https://github.com/owner/repo/pull/123","delivery":{"repo":"workspace","pushed_to":"source-branch","base":"main"}},{"delivery":{"repo":"agent","pushed_to":"main"}}]}
JSON

Replace the example values with the actual completed deliveries. Summary and inputs are optional for delivery-only reports. repo selects the Session repository independently of cwd. Normal input declares that the current HEAD was pushed; if HEAD has since advanced, provide both delivery.head_sha (full SHA) and delivery.source_branch. The Agent repository may have a detached HEAD and still deliver to main.

Use chat session show <session-id> --project <team/project> for the completed response, result cards, and repository status. Use chat result list --session <session-id> --project <team/project> for more results and chat result show <result-id> --project <team/project> for evidence and references.

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.

DisplayCheck and next action
Uncommitted changesInspect the diff and commit wanted changes. Do not discard work without checking its purpose
Push neededVerify the destination, push remaining commits, and record the delivery
Delivery not recordedCheck whether the native delivery succeeded. If it did, retry only receipt recording
PR not createdPushing a branch and creating a PR are separate. Create the required PR and record its URL
Unexpected targetCompare the actual destination with the destination fixed for the Session
Local inspection failedInspect 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 reporting fails after a successful push or PR creation, use the printed spool file: chat result report --retry-stdin < saved-file.json. The file fixes the SHA, Project, expected version, and nonces. Do not edit it or repeat the native operation. Repeating the normal JSON is a new update, not a retry. A partial failure retains only failed or unknown items; reporting failure alone does not block Session completion.

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 for workspace retention, cleanup, and resume; Projects for accepting results; and CLI for command syntax.