The docs say what the site shows of coordinated work. Sessions, claims and dependencies gains On the site: the Work page's Live now, merge queue, What happened and Just landed, how an empty one says to start, an issue's Work panel and who may edit what it is blocked by, and a session's page. The merge queue guide says a pull request shows a failed combination above its checks until it passes or merges, and its issue and the Work page show it too. Why-blame says the panel shows how the line was decided, the failed combination and its fix first, and where else decisions are listed.
3 files+50−00/3 viewed
| 203 | 203 | A combined state that passes is recorded too: an `integration_passed` | |
| 204 | 204 | decision and the `integration.passed` event, with `pull` and `combination`. | |
| 205 | 205 | ||
| 206 | + | On the site, the pull request shows the failure above its checks until it | |
| 207 | + | passes in the queue or merges: the pull requests tested together, with the | |
| 208 | + | one that answers for it marked, the check that failed (linked to its run), | |
| 209 | + | what it fails with, and the fix once one is recorded. Its issue shows the | |
| 210 | + | same under its pull requests, and the repository's | |
| 211 | + | [Work page](/guides/sessions/#on-the-site) lists it among what happened. | |
| 212 | + | ||
| 206 | 213 | ### Getting back in the queue | |
| 207 | 214 | ||
| 208 | 215 | The merge stays asked for. Push a fix to the pull request, starting from |
| 21 | 21 | What git and g1t record (commits, pull requests, checks, merges) is the | |
| 22 | 22 | truth; sessions are the account of how it got there. | |
| 23 | 23 | ||
| 24 | + | ## On the site | |
| 25 | + | ||
| 26 | + | Everything here shows on g1t.sh as it happens, without reloading. | |
| 27 | + | ||
| 28 | + | - **The Work page**, `g1t.sh/<workspace>/<repo>/work`, a tab beside | |
| 29 | + | **Pull requests**, **Merge queue** and **Sessions**: | |
| 30 | + | - **Live now**: the active claims and the active and idle sessions, | |
| 31 | + | grouped by the issue they are on, with sessions on no issue yet | |
| 32 | + | after them. An issue with more than one claim is marked. | |
| 33 | + | - **Merge queue**: what is waiting to land and what is being tested, | |
| 34 | + | as on the [Merge queue](/guides/merge-queue/#the-merge-queue-page) page. | |
| 35 | + | - **What happened**: the latest 30 coordination events, from claims to | |
| 36 | + | what the merge queue found when it combined changes. | |
| 37 | + | - **Just landed**: the latest merges, each with a link to the session | |
| 38 | + | behind it. | |
| 39 | + | ||
| 40 | + | With nothing going on, it says how to start: install the | |
| 41 | + | [Claude Code plugin](/guides/claude-code-plugin/), or run | |
| 42 | + | `g1t work claim <number>` from any harness. | |
| 43 | + | - **An issue's Work panel**, at the top of its sidebar: its claims (who, | |
| 44 | + | from which harness, since when and when each lapses; ones released, | |
| 45 | + | expired or handed off lately are shown dimmed), the sessions on it with | |
| 46 | + | their state and when each was last heard from, what it is blocked by | |
| 47 | + | and where each of those stands, and the issues it blocks. Its author | |
| 48 | + | and anyone with the Triage role change what it is blocked by with | |
| 49 | + | **Edit**. Under its pull requests, the issue shows the latest | |
| 50 | + | combination that failed in the merge queue, and its | |
| 51 | + | [decision records](/guides/why-blame/#decision-records), each marked | |
| 52 | + | **Claimed**, **Tested** or **Approved**. | |
| 53 | + | - **A session's page**, opened from any of these: who ran it, in which | |
| 54 | + | harness, the issue, pull request, branch and commit it is on, and what | |
| 55 | + | it recorded. | |
| 56 | + | ||
| 24 | 57 | ## Picking up an issue | |
| 25 | 58 | ||
| 26 | 59 | Before working on an issue, load its whole context in one call: `issue` |
| 79 | 79 | - the commit that last changed it; | |
| 80 | 80 | - the pull request it arrived in, and who or what wrote it and merged it; | |
| 81 | 81 | - the issue that asked for it, with its description; | |
| 82 | + | - how it was decided: the [decision records](#decision-records) on the | |
| 83 | + | issue and every pull request for it, oldest first, each marked | |
| 84 | + | **Claimed**, **Tested** or **Approved**. A combination that failed in | |
| 85 | + | the merge queue is shown first, with the pull requests tested together, | |
| 86 | + | the check that failed and the fix that answered it; then the | |
| 87 | + | proposals, the fix, the approval and the merge; | |
| 82 | 88 | - when a coding agent wrote it, the agent's own account of the change and the | |
| 83 | 89 | commands it ran, taken from its session. The steps shown are from the | |
| 84 | 90 | work that produced that commit: the agent's messages, and the tool calls | |
| ⋯ | |||
| 155 | 161 | attributed to whoever recorded it, carries | |
| 156 | 162 | the issue the pull request is for, and is published as `decision.recorded`. | |
| 157 | 163 | ||
| 164 | + | A pull request's **Session** tab lists its decisions above what was | |
| 165 | + | recorded, with the harness sessions working on it; an issue lists its own | |
| 166 | + | and its pull requests' under them. | |
| 167 | + | ||
| 158 | 168 | Read them with the `pull_request` tool's `list_decisions` action, with | |
| 159 | 169 | `GET /repos/{owner}/{name}/pulls/{number}/decisions`, or for an issue and | |
| 160 | 170 | all its pull requests with | |