The laptop test: a day using Barge

Start a Barge session from a Linear issue, close the laptop, and review the draft PR later. This is an illustrative workflow, not a measured session.

Morning: start from the issue

Choose a ticket with a clear outcome. From the repository root:

barge linear owner/repo main BSH-123 --alive

The control plane folds the issue’s text, comments, attachments, and linked issues into the task. A returned session URL confirms server-side acceptance, not that provisioning has finished. The session can queue and run without the laptop.

The --alive flag enables queued follow-ups within the session’s runtime budget, which defaults to 120 minutes. It does not extend the budget. Close the laptop after the CLI confirms the handoff.

While the session is alive: check in

Open the dashboard from whatever machine is at hand. The session view shows which of the five stages the session is in, the logs so far, and the test output.

If another requirement occurs to you, queue it in the session chat or with barge message <session-id> <text>. It does not interrupt the current build. After the initial PR and verification, the worker processes queued instructions using a resumable agent thread and updates the same branch.

Check the session state first. Sessions without keep-alive, sessions without a resumable thread after the build, and terminal sessions reject messages.

If the session finishes

After the build, the worker commits, pushes, and opens a draft PR. Configured workspace checks ran before the agent started, so read the later verification rather than assuming those checks covered the final changes. The post-PR stages run against the PR branch:

1. A bounded review and fix loop: findings, fixes on the same branch, re-review, capped so it converges or stops and says what is left.
2. A manual pass suited to the change. UI work can start an app, wait for an HTTP success response, and capture scripted Chromium checks at desktop (1440x900) and mobile (390x844) viewports. API and CLI work uses non-browser checks instead.

Findings and results post as PR comments, with captured UI evidence attached there. Verification can fail, be blocked, or be partial. Exhausting the budget can leave stages skipped; a draft PR is not evidence that all checks passed.

Evening: review

Read the diff and the available verification reports. If the worker started this morning, its default two-hour runtime window will have ended by evening. Queue time does not count toward that window, so check the session state before sending another message. The PR and its comments remain for review after the worker is gone.

If the session is still alive and eligible, another queued message can update the same branch. Otherwise, request a continuation with the separate PR-comment /handoff flow or start new work from an appropriate repository ref. Neither requires pretending the original session is still running. Merge only after you are satisfied with the work and required checks.

What the workflow buys

The laptop does not have to stay awake while the cloud worker runs. You can check progress from another machine and review the PR when you have time.

What it does not buy

You still need to review the attempt. The bounded automated review and manual pass can miss problems or stop before resolving them. Worker cleanup is attempted when the session ends, with reconciliation for failed teardown; logs and some artifacts can remain according to retention rules.

Try it

Follow the series index for the parts that have shipped so far.

Barge is in private beta. Join the waitlist to get an invitation.