Demo script: a planned outcome running in parallel, the Code button and Branches, forks described as they are measured, and checks before recording
1 file+48−160/1 viewed
| 1 | 1 | # Demo script | |
| 2 | 2 | ||
| 3 | − | A walk through g1t for the submission video. It runs about eight minutes at | |
| 4 | − | a normal speaking pace and uses `flagon-io/hello`, a small Rust greeter whose | |
| 3 | + | A walk through g1t for the submission video. It runs about nine minutes at | |
| 4 | + | a normal speaking pace (the entry allows five to ten) and uses `flagon-io/hello`, a small Rust greeter whose | |
| 5 | 5 | whole history was written by agents working on issues. | |
| 6 | 6 | ||
| 7 | 7 | Everything shown is live on g1t.sh. Nothing is mocked. | |
| 8 | 8 | ||
| 9 | 9 | The judges weigh agent collaboration (half), concurrency and conflicts (a | |
| 10 | − | quarter) and ease of use (a quarter). Sections 3 to 6 carry the first two; | |
| 11 | − | sections 2 and 8 the third. | |
| 10 | + | quarter) and ease of use (a quarter). Sections 3 to 7 carry the first two; | |
| 11 | + | sections 2 and 9 the third. | |
| 12 | 12 | ||
| 13 | 13 | ## Before recording | |
| 14 | 14 | ||
| 19 | 19 | - Write the three issues for section 3 in a scratch file so they can be | |
| 20 | 20 | pasted (titles below). Agents take one to three minutes each: start them, | |
| 21 | 21 | talk over sections 4 and 5, and come back. | |
| 22 | + | - In `flagon-io/hello` Settings → Branches and merging, check **Merge through | |
| 23 | + | a queue** and **Merge automatically when ready** are on, so section 7's pull | |
| 24 | + | requests enter the queue by themselves. (`automation-lab` is set to wait | |
| 25 | + | for a person, so do not record there.) | |
| 26 | + | - Write the brief for section 4 in the scratch file too. | |
| 22 | 27 | - Do not deploy the runner while agents work. | |
| 23 | 28 | ||
| 24 | 29 | ## 1. The problem (30 seconds) | |
| 36 | 41 | ||
| 37 | 42 | On `flagon-io/hello`, Code tab. | |
| 38 | 43 | ||
| 39 | − | - Show the clone box: HTTPS, and the one line that connects an agent. | |
| 44 | + | - The file list reads like any forge's: each file with the commit that last | |
| 45 | + | changed it. Press **Code**: clone over HTTPS, the one line that connects | |
| 46 | + | an agent, or **Download ZIP**. | |
| 47 | + | - Glance at **Branches** (each with its pull request, checks and how far it | |
| 48 | + | has moved) and **Compare**. | |
| 40 | 49 | - In the terminal: `git clone https://g1t.sh/flagon-io/hello.git`. | |
| 41 | 50 | - Open `.g1t/workflows/ci.yml`. It is a GitHub Actions workflow, unchanged: | |
| 42 | 51 | `actions/checkout@v7`, a Rust toolchain action, `actions/cache@v6`, then | |
| 65 | 74 | filling in live: the prompt, what the agent was told about the other work | |
| 66 | 75 | in progress, every command it runs. | |
| 67 | 76 | ||
| 68 | − | > Each agent has its own sandbox and its own fork. A fork is copy-on-write, | |
| 69 | − | > so it costs about what a branch would, and an agent cannot damage what it | |
| 70 | − | > cannot write to. Each is told what else is in flight, so two agents on | |
| 71 | − | > the same file know about each other before they collide. | |
| 77 | + | > Each agent has its own sandbox and its own fork, so an agent cannot damage | |
| 78 | + | > what it cannot write to; a day after its pull request lands, the fork is | |
| 79 | + | > retired and only its head is kept. Each agent is told what else is in | |
| 80 | + | > flight, so two agents on the same file know about each other before they | |
| 81 | + | > collide. | |
| 72 | 82 | ||
| 73 | 83 | While they run, go on. | |
| 74 | 84 | ||
| 75 | − | ## 4. Agents keep CI honest, and fix what it catches (1 minute 30 seconds) | |
| 85 | + | ## 4. One outcome, planned into work that runs in parallel (1 minute) | |
| 86 | + | ||
| 87 | + | Issues tab, then **Outcomes**. | |
| 88 | + | ||
| 89 | + | - Paste a brief, such as: *The greeter should support `--shout`, which | |
| 90 | + | upper-cases the greeting, documented in the README and covered by tests.* | |
| 91 | + | Press **Plan it**. In about twenty seconds an agent has read the | |
| 92 | + | repository and proposed issues: what each must make true, the files each | |
| 93 | + | will touch, and which has to land before which. | |
| 94 | + | - Press **Open these and assign g1t**. The first issue starts at once. Come | |
| 95 | + | back to it at the end: as soon as it merges, the ones that depended on it | |
| 96 | + | start together, each with its own agent. | |
| 97 | + | ||
| 98 | + | > You say what should be true; g1t works out the order. Independent pieces | |
| 99 | + | > run at once, and a piece that needs another starts the moment that one | |
| 100 | + | > lands, from its result. | |
| 101 | + | ||
| 102 | + | ## 5. Agents keep CI honest, and fix what it catches (1 minute 30 seconds) | |
| 76 | 103 | ||
| 77 | 104 | Open issue **#80, CI: fail when a flag is missing from the README**, and its | |
| 78 | 105 | pull request **#81**. | |
| 94 | 121 | > failure goes back to the agent with the log, and the pull request cannot | |
| 95 | 122 | > merge until it is green. | |
| 96 | 123 | ||
| 97 | − | ## 5. Checks, reviews and choosing between pull requests (1 minute) | |
| 124 | + | ## 6. Checks, reviews and choosing between pull requests (1 minute) | |
| 98 | 125 | ||
| 99 | 126 | Open **Say goodbye too** (#4) and its pull request **Add a farewell** (#9). | |
| 100 | 127 | ||
| 110 | 137 | ||
| 111 | 138 | > This is the overlap radar. g1t says so while the work is still going on, | |
| 112 | 139 | > not at the end as a merge conflict. Agents see the same thing through the | |
| 113 | − | > API, which is how the agents in section 3 were told about each other. | |
| 140 | + | > API, which is how the agents in sections 3 and 4 were told about each other. | |
| 114 | 141 | ||
| 115 | 142 | Open **A blank name greets nobody** (#1): closed, saying which pull request | |
| 116 | 143 | resolved it; the other is marked superseded. | |
| 136 | 163 | g1t sent #87's agent back; it caught up and made the new `--both` code | |
| 137 | 164 | use `farewell()`. Both are on main, and main builds. | |
| 138 | 165 | ||
| 139 | − | ## 6. The merge queue (1 minute 15 seconds) | |
| 166 | + | ## 7. The merge queue (1 minute 15 seconds) | |
| 140 | 167 | ||
| 141 | 168 | Back to the pull requests from section 3. Their checks have passed and a g1t | |
| 142 | 169 | agent has reviewed them. | |
| 160 | 187 | If one conflicts on camera, so much the better: open its Session and show | |
| 161 | 188 | the agent being given both sides and what the pull request is for. | |
| 162 | 189 | ||
| 163 | − | ## 7. Bring your own agent (45 seconds) | |
| 190 | + | ## 8. Bring your own agent (45 seconds) | |
| 164 | 191 | ||
| 165 | 192 | Terminal. | |
| 166 | 193 | ||
| 177 | 204 | > including GitHub's own Actions endpoints, and the two are generated from | |
| 178 | 205 | > one list, so they cannot drift apart. | |
| 179 | 206 | ||
| 180 | − | ## 8. Close (30 seconds) | |
| 207 | + | ## 9. Close (30 seconds) | |
| 181 | 208 | ||
| 182 | 209 | Back on the Issues tab: the three issues from section 3, closed, each saying | |
| 183 | − | which pull request resolved it. | |
| 210 | + | which pull request resolved it. Then the outcome from section 4: its plan | |
| 211 | + | page shows every issue landed, the later ones started in parallel once the | |
| 212 | + | first merged. Finish on mission control: the week, split into what agents | |
| 213 | + | landed on their own, what a person merged, and people's own work. | |
| 184 | 214 | ||
| 185 | 215 | > Issues and pull requests, as you know them, and your GitHub Actions as | |
| 186 | 216 | > they are. What changes is the number of hands. Every agent isolated in its | |
| 200 | 230 | | Checks stay queued | Press the re-run button on the checks panel. | | |
| 201 | 231 | | Nothing enters the queue | Auto-merge waits for checks, workflows and a review; the pull request's sidebar says which is missing. | | |
| 202 | 232 | | Merge is refused | Read the message: it is a draft, its checks or workflows have not passed, or it needs a review. | | |
| 233 | + | | A check fails in checkout | It retries the fetch twice itself; if it still fails, press **Re-run failed jobs**. | | |
| 234 | + | | A planned issue does not start | Open it: a start that was refused says why in a comment. **Assign to g1t** on the issue starts it by hand. | |