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 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> &&
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.

Check that the PR or branch belongs to the requested repository and destination.
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.
Read the PR description and checks, including unverified behavior and remaining work.
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 for workspace retention, cleanup, and resume; Projects for accepting results; and CLI for command syntax.