Pick any line to see why it is the way it is: the commit, the pull request and issue it came from, and what the agent was thinking.
| Initial g1t: services, event bus, intents and attempts | 1 | # g1t plan |
| 2 | ||
| 3 | g1t is a git forge for agents, built on Cloudflare Workers and Artifacts for | |
| 4 | the "Build the Next-Gen Git Platform on Cloudflare" competition. | |
| 5 | ||
| 6 | - Submission closes **October 14, 2026, 11:59 PM PDT**: a 5–10 minute demo | |
| 7 | video, this repository (MIT) and run instructions. | |
| 8 | - Judging: 50% originality and quality of the prototype for agent-oriented | |
| 9 | collaboration; 25% multi-agent concurrency, coordination, context | |
| 10 | preservation, review and conflict handling; 25% ease of use. | |
| 11 | ||
| Agents as a team: lifecycle, merge queue, billing and a new shell | 12 | ## The point |
| 13 | ||
| 14 | **GitHub is where people keep code. g1t is where a team of agents ships it.** | |
| 15 | ||
| 16 | Hosting git is table stakes, and g1t does it the way GitHub does: issues, | |
| 17 | branches, pull requests, review, protected branches, people working by hand. | |
| 18 | None of that is the selling point. The selling point is the layer above it, | |
| 19 | which no forge has: **you hand g1t an outcome, and a fleet of agents converges | |
| 20 | it onto `main`, coordinating with each other and with you, with every decision | |
| 21 | on the record.** | |
| 22 | ||
| 23 | Three things only g1t does, and every feature should serve one of them: | |
| 24 | ||
| 25 | 1. **Outcomes, not pull requests.** The unit people work in is "make onboarding | |
| 26 | work offline", not branch #4012. A brief becomes a plan of issues with | |
| 27 | dependencies; agents take them as they unblock; people steer the outcome | |
| 28 | and see it converge. GitHub, Origin and Entire all stop at the pull request. | |
| 29 | 2. **Agents that work as a team.** Agents know what the others are doing, file | |
| 30 | what they find instead of widening their change, ask and answer each other | |
| 31 | through the forge, and defer to people. Many agents on one codebase without | |
| 32 | a human refereeing collisions. | |
| 33 | 3. **`main` that only ever moves forward.** Every change lands through checks | |
| 34 | in the combination it will live in (the merge queue), failures go back to the | |
| 35 | agent that wrote them, and any line can answer "why is this here?" | |
| 36 | ||
| 37 | ### Against the others | |
| 38 | ||
| 39 | | | GitHub | Cursor Origin | Entire | g1t | | |
| 40 | | --- | --- | --- | --- | --- | | |
| 41 | | Core idea | Code hosting with Copilot bolted on | A forge for Cursor's cloud agents | Store every agent session with the code | Agents converge an outcome onto `main` | | |
| 42 | | Unit of work | Pull request | Pull request, stacked | Commit plus session | Outcome → plan → issues → pull requests | | |
| 43 | | Agent context | In the Copilot app | In Cursor | In the repo, per commit | Per commit, plus why-blame on any line and what agents told each other | | |
| 44 | | Many agents at once | Compare outputs by hand | Agents can review agents | Not the focus | Plan with dependencies, overlap awareness, coordination tools, queue | | |
| 45 | | Landing | Merge queue (paid) | Stacks | Not the focus | Speculative queue testing combinations; failures return to their agent | | |
| 46 | | Which agents | Copilot, some others | Cursor's | Any (CLI) | Hosted agents plus any MCP client | | |
| 47 | ||
| 48 | Entire's insight, that the session belongs with the code, is one g1t shares | |
| 49 | and already ships (sessions, why-blame). Origin's, that agents should live in | |
| 50 | the forge, too. Neither coordinates a team of agents towards an outcome; that | |
| 51 | is the gap g1t is built for. | |
| 52 | ||
| Initial g1t: services, event bus, intents and attempts | 53 | ## Product model |
| 54 | ||
| Issues and pull requests replace intents and attempts | 55 | g1t keeps the two things every engineer already knows, issues and pull |
| 56 | requests, and changes the assumption underneath them. A forge built for | |
| Agents as a team: lifecycle, merge queue, billing and a new shell | 57 | people expects a few changes in flight, each watched by its author. g1t |
| 58 | expects dozens of agents working at once across a project, each on its own | |
| 59 | issue, all of which have to land on `main`. A person assigns an issue to | |
| 60 | the g1t agent and chooses nothing else: not how many agents, and not which | |
| 61 | model. An issue can still collect more than one pull request (a second | |
| 62 | attempt, or someone's own agent alongside g1t's), and when it does the | |
| 63 | issue records which one was taken. | |
| Initial g1t: services, event bus, intents and attempts | 64 | |
| 65 | | Concept | What it is | | |
| 66 | | --- | --- | | |
| Issues and pull requests replace intents and attempts | 67 | | **Issue** | What should change in a repo: a bug, a feature, a question. Opened by a person, an agent or an integration such as an error tracker. Carries labels, acceptance checks (commands that must pass), comments, and every pull request made for it. | |
| 68 | | **Pull request** | A proposed change in its own Artifacts fork, made by an agent or a person, usually for an issue. Any number can be open for one issue. Starts as a draft; marked ready; merged or closed. | | |
| 69 | | **Session** | The agent's full context for a pull request: prompt, messages, tool calls, cost. Stored with the pull request and linked from every commit it produced. | | |
| 70 | | **Compare view** | Every pull request for an issue side by side with diff, check results, conflicts against main and against each other, and a reviewer agent's summary. | | |
| 71 | | **Merge** | A person or a policy picks a pull request. A per-repo merge queue lands it. The issue closes, recording which pull request resolved it; the others for that issue close as superseded, or are rebased by their agents when the issue is kept open. | | |
| 72 | ||
| 73 | Issues and pull requests share one sequence of numbers per repository, so | |
| 74 | `#12` names exactly one of them. | |
| Initial g1t: services, event bus, intents and attempts | 75 | |
| 76 | Features that fall out of the model: | |
| 77 | ||
| 78 | - **Why-blame.** Click a line and see the prompt and reasoning that produced | |
| 79 | it, not only the commit. | |
| Issues and pull requests replace intents and attempts | 80 | - **Overlap radar.** Pull requests that touch the same files are flagged |
| 81 | while the agents are still working, and the agents are told. | |
| 82 | - **Live lanes.** Watch every pull request progress in real time. | |
| 83 | ||
| 84 | ## Why issues and pull requests, not something new | |
| 85 | ||
| 86 | An earlier version of this plan merged the two into one new object, an | |
| 87 | "issue" holding "pull requests". That was wrong, for three reasons. | |
| Initial g1t: services, event bus, intents and attempts | 88 | |
| Issues and pull requests replace intents and attempts | 89 | - **Issues come from everywhere.** People file them, agents file them, and |
| 90 | Sentry files them. Most are never worked on by whoever opened them. They | |
| 91 | need their own life: labels, triage, discussion, closing as not planned. | |
| 92 | - **"Which change did we take?" needs two objects.** When five agents each | |
| 93 | propose a change, the answer has to be recorded somewhere other than the | |
| 94 | five proposals. On g1t it is on the issue: `resolved by #14`. | |
| 95 | - **Nobody should have to learn a word to use the product.** An engineer who | |
| 96 | has used any forge can use g1t on the first day, and finds the agent | |
| 97 | features where they would look for them. | |
| Rust repos service with shipping; pull requests kept in the model | 98 | |
| Issues and pull requests replace intents and attempts | 99 | What g1t adds to the familiar pair: |
| Rust repos service with shipping; pull requests kept in the model | 100 | |
| Agents as a team: lifecycle, merge queue, billing and a new shell | 101 | - **Several pull requests per issue is supported**, not an accident. It |
| 102 | is the exception, for a second attempt or a competing one, but when it | |
| 103 | happens the issue's page lists them with their state, and merging one | |
| 104 | closes the issue with that pull request recorded and the others marked | |
| 105 | superseded. | |
| Issues and pull requests replace intents and attempts | 106 | - **A pull request can be part of the work.** Merging with "keep the issue |
| 107 | open" leaves the issue and its other pull requests alone. | |
| 108 | - **Every pull request has a fork and a session.** See | |
| 109 | [forks and branches](https://docs.g1t.sh/concepts/forks/). | |
| 110 | - **Labels need no setup.** A repository starts with `bug`, `feature`, | |
| 111 | `docs`, `chore` and `question`; any other name becomes a label the first | |
| 112 | time it is used, so an integration can tag what it files. | |
| Pull requests from branches | 113 | - **The developer path is unchanged.** Push a branch, open a pull request |
| 114 | from it, get review, merge. Agents get a fork per pull request instead. | |
| Rust repos service with shipping; pull requests kept in the model | 115 | - **Both paths meet at `main`.** The same landing rules apply to a person's |
| Issues and pull requests replace intents and attempts | 116 | pull request and an agent's. |
| Rust repos service with shipping; pull requests kept in the model | 117 | |
| Initial g1t: services, event bus, intents and attempts | 118 | ## Converging on main |
| 119 | ||
| Issues and pull requests replace intents and attempts | 120 | Twelve issues started together will finish at different times and touch |
| Initial g1t: services, event bus, intents and attempts | 121 | overlapping code. Getting them all into `main` without a person refereeing |
| 122 | is the hard part, and it is handled in four places. | |
| 123 | ||
| 124 | 1. **Before work starts: plan the overlap away.** A project is a graph of | |
| Issues and pull requests replace intents and attempts | 125 | issues. A planner agent can split a large goal into issues, predict |
| Initial g1t: services, event bus, intents and attempts | 126 | which files each will touch, and add a dependency where two would collide, |
| 127 | so one starts from the other's result instead of from `main`. | |
| Issues and pull requests replace intents and attempts | 128 | 2. **While agents work: overlap radar.** Each pull request's changed files and |
| 129 | symbols are tracked as it pushes. When two pull requests from different issues | |
| Initial g1t: services, event bus, intents and attempts | 130 | enter the same area, both agents are told what the other is doing there. |
| Issues and pull requests replace intents and attempts | 131 | 3. **When `main` moves: the author resolves.** Every open pull request is |
| 132 | trial-merged against the new `main`. A clean merge updates the pull request | |
| 133 | silently. A conflict resumes that pull request's agent with its original | |
| Initial g1t: services, event bus, intents and attempts | 134 | session and the incoming change, so the conflict is resolved by the agent |
| 135 | that wrote the code and still knows why. | |
| Issues and pull requests replace intents and attempts | 136 | 4. **At landing: a speculative queue.** Approved pull requests enter the |
| 137 | repo's queue. g1t builds the combined states (`main`+A, `main`+A+B, …) and runs | |
| 138 | their checks in parallel. Pull requests land in order as their combined state | |
| Initial g1t: services, event bus, intents and attempts | 139 | passes; one that fails is ejected back to its agent and the states behind |
| 140 | it are rebuilt. `main` only ever receives a state that passed. | |
| 141 | ||
| 142 | Landing can be fully automatic: a repo policy such as "checks pass and the | |
| Issues and pull requests replace intents and attempts | 143 | reviewer agent approves" merges without a person. |
| Initial g1t: services, event bus, intents and attempts | 144 | |
| 145 | ## Agents aware of each other | |
| 146 | ||
| Issues and pull requests replace intents and attempts | 147 | Each repo keeps a live **work registry**: for every running pull request, its |
| 148 | issue, a running summary of what it has done, and the files and symbols it | |
| Initial g1t: services, event bus, intents and attempts | 149 | has touched or plans to touch. Agents use it through MCP tools; g1t also |
| 150 | acts on it without being asked. | |
| 151 | ||
| Issues and pull requests replace intents and attempts | 152 | - **Before starting.** When an issue is opened, or an agent is about to |
| 153 | begin a task, g1t searches open issues and running pull requests for the same | |
| Initial g1t: services, event bus, intents and attempts | 154 | goal (by meaning, not wording) and for the same area of code. If a match |
| 155 | exists the agent is told who is on it and how far along, and chooses: join | |
| 156 | as a deliberate racer, wait for the result, or drop the task. Duplicate | |
| Issues and pull requests replace intents and attempts | 157 | issues are offered for merging. |
| Initial g1t: services, event bus, intents and attempts | 158 | - **Finding out-of-scope work.** An agent that discovers something outside |
| Issues and pull requests replace intents and attempts | 159 | its issue asks the registry who works there. If another pull request owns that |
| Initial g1t: services, event bus, intents and attempts | 160 | area, it **hands off**: a note, the relevant excerpt of its session, and |
| 161 | optionally commits the receiver can take. If nobody does, it opens a child | |
| Issues and pull requests replace intents and attempts | 162 | issue instead of widening its own change. |
| 163 | - **Asking.** An agent can put a question or a request to another pull request. | |
| Initial g1t: services, event bus, intents and attempts | 164 | The receiver gets it at its next turn. |
| Issues and pull requests replace intents and attempts | 165 | - **Waiting.** An agent that needs another pull request's result parks itself. |
| Initial g1t: services, event bus, intents and attempts | 166 | Its sandbox sleeps, spend stops, and it resumes from the new state when |
| Issues and pull requests replace intents and attempts | 167 | that pull request merges. |
| Initial g1t: services, event bus, intents and attempts | 168 | - **Agents that do not cooperate.** For pushes from tools that never call |
| Issues and pull requests replace intents and attempts | 169 | these tools, g1t compares the pushed change against running pull requests and |
| Initial g1t: services, event bus, intents and attempts | 170 | flags near-duplicates itself. |
| 171 | ||
| 172 | Every handoff, question and wait has a state (offered, accepted, declined, | |
| 173 | done), appears in the timeline, and is visible to people. A handoff declined | |
| 174 | twice, or two agents passing work back and forth, goes to the "needs you" | |
| 175 | inbox. | |
| 176 | ||
| 177 | ## Review at scale | |
| 178 | ||
| 179 | Cloudflare's brief asks "how do you review everything they produce?". With | |
| 180 | hundreds of agents, a person cannot read every diff, so review is by | |
| 181 | exception. | |
| 182 | ||
| Issues and pull requests replace intents and attempts | 183 | - **Evidence, not diffs.** Every pull request carries a proof bundle: checks run |
| Initial g1t: services, event bus, intents and attempts | 184 | and their output, a preview URL, a plain-language summary, and the |
| 185 | behaviour that changed. | |
| Issues and pull requests replace intents and attempts | 186 | - **Two agent reviewers.** One reviews the change against the issue. A |
| Initial g1t: services, event bus, intents and attempts | 187 | second is adversarial: it tries to break the change and reports what it |
| 188 | found. | |
| 189 | - **Risk tiers.** Each change is scored from what it touches, how large it | |
| Issues and pull requests replace intents and attempts | 190 | is, and how the reviewers ruled. Low risk merges on policy; high risk goes |
| Initial g1t: services, event bus, intents and attempts | 191 | to a person with the evidence already assembled. |
| Issues and pull requests replace intents and attempts | 192 | - **Trust is earned.** An agent's record on a path (merged, reverted, caught |
| Initial g1t: services, event bus, intents and attempts | 193 | by review) raises or lowers the tier its changes land in. |
| Issues and pull requests replace intents and attempts | 194 | - **Sampling.** A share of auto-merged changes is sent to a person anyway, |
| Initial g1t: services, event bus, intents and attempts | 195 | to keep the policy honest. |
| 196 | ||
| 197 | ## Rethinking the git primitives | |
| 198 | ||
| Issues and pull requests replace intents and attempts | 199 | - **No branches for agents.** A pull request is a fork; `main` is the only |
| Initial g1t: services, event bus, intents and attempts | 200 | long-lived line. There is nothing to name, clean up or go stale. |
| Issues and pull requests replace intents and attempts | 201 | - **Projected main.** New pull requests start from `main` plus everything already |
| Initial g1t: services, event bus, intents and attempts | 202 | in the landing queue, so they are built on the state they will land on. |
| 203 | - **Structural merge.** The merge engine merges by syntax tree, not by line, | |
| 204 | for supported languages. Two agents adding different functions to the same | |
| 205 | file do not conflict. | |
| 206 | - **Forkable sessions.** A session can be forked at any turn: the code as it | |
| 207 | was at that moment plus the conversation up to it, continued with a | |
| 208 | different instruction. Branching applies to the reasoning as well as the | |
| 209 | code. | |
| Issues and pull requests replace intents and attempts | 210 | - **Provenance in history.** Every commit records its issue, session, |
| 211 | agent, model and cost, and is signed with a key issued to that pull request. The | |
| Initial g1t: services, event bus, intents and attempts | 212 | history can be audited by machine. |
| 213 | ||
| 214 | ## People in the loop | |
| 215 | ||
| 216 | ### Code that arrives from outside | |
| 217 | ||
| 218 | People will keep pushing with plain git, their editor, or another tool. Every | |
| 219 | push goes through g1t's git front end, so none of it bypasses the model. | |
| 220 | ||
| Issues and pull requests replace intents and attempts | 221 | - **A push to a branch becomes a pull request.** g1t adopts it with the pusher as |
| 222 | author. A reviewer agent writes the issue it appears to serve and offers | |
| 223 | to attach it to an open issue it matches. From there it gets the same | |
| 224 | checks, compare view and queue as agent work. | |
| Initial g1t: services, event bus, intents and attempts | 225 | - **A push to `main` follows repo policy.** Protected: refused with a message |
| 226 | saying which ref to push to instead, so it enters the queue. Open: accepted | |
| 227 | and treated as "`main` moved", which re-verifies the queue and triggers | |
| Issues and pull requests replace intents and attempts | 228 | resolve-on-move for every open pull request. |
| Initial g1t: services, event bus, intents and attempts | 229 | - **Context is an open format.** A commit trailer names the session that |
| 230 | produced it, so any tool can attach its transcript. Commits without one are | |
| 231 | shown in why-blame as "pushed by a person, no session". | |
| Issues and pull requests replace intents and attempts | 232 | - **Approval rules.** Per repo and per path: merge automatically, require a |
| Initial g1t: services, event bus, intents and attempts | 233 | named person, or require a person when the change is large or the reviewer |
| 234 | agent is unsure. | |
| 235 | ||
| 236 | ### Joining work that is already running | |
| 237 | ||
| 238 | - **Every session has a live page** that works on a phone: the transcript as | |
| 239 | it streams, the current diff, check results. | |
| 240 | - **Steer.** Send a message, pause, or redirect. Hosted agents receive it | |
| 241 | immediately; a person's own Claude Code receives it at its next turn | |
| 242 | through the CLI hooks. | |
| 243 | - **Answer.** When an agent is blocked on a question, it appears in a "needs | |
| 244 | you" inbox and as a notification. The answer resumes the agent. | |
| Issues and pull requests replace intents and attempts | 245 | - **Take over and hand back.** Check out the pull request's fork, commit by hand, |
| Initial g1t: services, event bus, intents and attempts | 246 | push, and let the agent continue from there. |
| 247 | ||
| 248 | ### Planning by writing | |
| 249 | ||
| 250 | - **Brief.** Write the outcome in prose on the site, or commit it as a | |
| Issues and pull requests replace intents and attempts | 251 | markdown file. A planner agent turns it into a project: issues, acceptance |
| Initial g1t: services, event bus, intents and attempts | 252 | checks, dependencies. The person edits the graph before anything starts. |
| 253 | - **Plan from their own agent.** The same operations are MCP tools, so a | |
| 254 | person can plan in their own Claude Code session and create the project | |
| 255 | from there. | |
| 256 | - **The brief stays the source of truth.** Editing it later re-plans: new | |
| Issues and pull requests replace intents and attempts | 257 | issues are added, obsolete ones are closed. |
| Initial g1t: services, event bus, intents and attempts | 258 | |
| 259 | ### Seeing what moved | |
| 260 | ||
| Issues and pull requests replace intents and attempts | 261 | - **Project page.** The outcome, the issue graph coloured by state, and how |
| Initial g1t: services, event bus, intents and attempts | 262 | many acceptance checks pass now compared with when the project started. |
| 263 | - **Digest.** An agent-written summary per project and per person: what | |
| Issues and pull requests replace intents and attempts | 264 | merged, what is blocked on whom, which conflicts were resolved, what it |
| Initial g1t: services, event bus, intents and attempts | 265 | cost. |
| Issues and pull requests replace intents and attempts | 266 | - **Timeline.** Every event (push, steer, check, conflict, merge) in order, |
| Initial g1t: services, event bus, intents and attempts | 267 | each linked to the session and the person or agent behind it. |
| 268 | ||
| 269 | ## One session, any surface | |
| 270 | ||
| 271 | A session belongs to g1t, not to the device it started on. The browser, a | |
| 272 | phone and Claude Code are views of the same session. | |
| 273 | ||
| 274 | - **Browser and phone.** The site is a responsive, installable web app with | |
| 275 | push notifications. Everything a person does (brief, steer, answer, | |
| Issues and pull requests replace intents and attempts | 276 | approve, merge) works there. |
| Initial g1t: services, event bus, intents and attempts | 277 | - **Claude Code.** Through `mcp.g1t.sh` and the CLI hooks, a local session is |
| 278 | a g1t session: its transcript syncs as it runs and it appears in mission | |
| 279 | control like any other. | |
| 280 | - **Moving a session.** A local session can be sent to the cloud: a hosted | |
| 281 | agent takes over the fork and the transcript and continues, so the laptop | |
| 282 | can close. A hosted session can be pulled down: the CLI checks out the fork | |
| 283 | and resumes it in local Claude Code with its history. | |
| 284 | - **Limit.** A session running only on a laptop stops when the laptop does. | |
| 285 | It can be steered between turns but not continued until it is moved or the | |
| 286 | laptop is back. | |
| 287 | ||
| 288 | ## For people who do not write code | |
| 289 | ||
| 290 | - **Documents are first-class.** Specs, guides, policies and decisions live | |
| 291 | in repos as markdown, shown in a Docs view: rendered pages, edited in the | |
| 292 | browser like a document, with inline comments. "Suggest a change" is an | |
| Issues and pull requests replace intents and attempts | 293 | pull request and "publish" is merge, without git vocabulary. |
| 294 | - **Document issues.** "Write the onboarding guide for the billing API" is | |
| 295 | an issue. Its acceptance checks are a checklist judged by a reviewer agent | |
| Initial g1t: services, event bus, intents and attempts | 296 | instead of commands. Agents draft and revise; people comment and approve. |
| 297 | - **Templates.** Product brief, RFC, decision record. A filled-in template is | |
| 298 | a brief the planner can turn into a project. | |
| 299 | - **Explain.** Ask about any repo, project or change in plain language and | |
| 300 | get an answer with links to the code and sessions behind it. | |
| 301 | - **Living documentation.** g1t generates "how this works" pages from the | |
| Issues and pull requests replace intents and attempts | 302 | code and keeps them current. When a merged change contradicts a document, |
| 303 | an issue opens to update it. | |
| 304 | - **See it, don't read it.** Every pull request on a deployable repo gets a | |
| 305 | preview URL (Workers Builds from the pull request's fork), so an approver clicks | |
| Initial g1t: services, event bus, intents and attempts | 306 | through the result instead of reading a diff. Changes are also summarised |
| 307 | in plain language. | |
| 308 | - **Roles.** Viewer, commenter, planner, approver: a person can plan and | |
| 309 | approve work without ever cloning a repo. | |
| 310 | ||
| 311 | ## The macro view | |
| 312 | ||
| 313 | The hierarchy above a single repo: | |
| 314 | ||
| 315 | | Level | What it is | | |
| 316 | | --- | --- | | |
| 317 | | **Workspace** | A company or team: its people, repos, agents, budget and policies. | | |
| 318 | | **Initiative** | A business outcome with an owner and measurable results, e.g. "move billing to usage-based pricing". Spans any number of repos. | | |
| Issues and pull requests replace intents and attempts | 319 | | **Project** | One deliverable inside an initiative: a brief and its graph of issues. | |
| 320 | | **Issue / Pull request** | As above. An issue may touch several repos; a pull request for it then holds one fork per repo and they land together. | | |
| Initial g1t: services, event bus, intents and attempts | 321 | |
| Agents as a team: lifecycle, merge queue, billing and a new shell | 322 | How it feeds up, and what is built: |
| 323 | ||
| 324 | - **A workspace is the unit everything belongs to.** Repositories, people, | |
| 325 | access tokens, and later projects, budgets and policies are the | |
| 326 | workspace's, never a person's. An account owns nothing; its first step | |
| 327 | after confirming its email is creating a workspace, and the site sends it | |
| 328 | there from wherever it was going. | |
| 329 | - **One namespace.** Usernames and workspaces share one set of names, as on | |
| 330 | Docker Hub and npm. A username is reserved for its owner's workspace, so | |
| 331 | `g1t.sh/<name>` never means two things. | |
| 332 | - **The workspace page is the roll-up.** `g1t.sh/<workspace>` shows its | |
| 333 | repositories with their open issues and pull requests, and the pull | |
| 334 | requests in progress across all of them. Projects and initiatives will | |
| 335 | roll up to the same page. Its own pages live under `/<workspace>/-/` | |
| 336 | (people, access tokens, settings), which no repository can be named. | |
| 337 | - **Workspace access tokens instead of service accounts.** A workspace has | |
| 338 | tokens of its own, in the same table and code path as personal ones. One | |
| 339 | acts as the workspace, with a member's rights in that workspace only, | |
| 340 | records who made it and when it was last used, and keeps working when | |
| 341 | that person leaves. CI, integrations and automations use these. | |
| 342 | ||
| Initial g1t: services, event bus, intents and attempts | 343 | ### Portfolio |
| 344 | ||
| 345 | One page answers "where is the business" across every initiative: | |
| 346 | ||
| 347 | - **Health** per initiative: on track, at risk, or blocked, derived from | |
| Issues and pull requests replace intents and attempts | 348 | facts (checks passing, issues stalled, questions waiting on a person), |
| Initial g1t: services, event bus, intents and attempts | 349 | not self-reported. |
| Issues and pull requests replace intents and attempts | 350 | - **Progress** as measurable results: acceptance checks passing, issues |
| 351 | merged out of planned, and the trend since the start. | |
| Initial g1t: services, event bus, intents and attempts | 352 | - **Forecast** from actual throughput: at the current rate, when the |
| Issues and pull requests replace intents and attempts | 353 | remaining issues land. |
| Initial g1t: services, event bus, intents and attempts | 354 | - **Spend** in tokens and dollars against a budget, per initiative. |
| 355 | - **Waiting on people**: every decision or approval a person owes, by name. | |
| 356 | - **Roadmap**: initiatives laid out as now, next, later, with optional | |
| 357 | time-boxed cycles for teams that work in sprints. | |
| 358 | ||
| 359 | ### Status without asking | |
| 360 | ||
| 361 | - **Standup.** An agent writes a daily report per initiative and one for the | |
| Issues and pull requests replace intents and attempts | 362 | whole workspace: what merged, what changed direction, what is at risk and |
| Initial g1t: services, event bus, intents and attempts | 363 | why, what needs a person. Delivered by email or webhook. |
| 364 | - **Ask.** A question box over the full event log and all sessions: "what | |
| 365 | happened on the billing migration since Monday?" answers with links to the | |
| 366 | sessions and commits behind each claim. | |
| 367 | ||
| 368 | ### Long-running agents | |
| 369 | ||
| 370 | Work that runs for days needs supervision that does not depend on someone | |
| 371 | watching. | |
| 372 | ||
| Issues and pull requests replace intents and attempts | 373 | - **Checkpoints.** A long pull request reports milestones against its issue, so |
| 374 | progress is visible before anything merges. | |
| 375 | - **Stall and drift detection.** A pull request with no meaningful progress, or | |
| 376 | whose changes have wandered away from its issue, is flagged and can be | |
| Initial g1t: services, event bus, intents and attempts | 377 | stopped or re-briefed automatically. |
| Issues and pull requests replace intents and attempts | 378 | - **Budgets.** Hard limits on spend and time per pull request, project and |
| Initial g1t: services, event bus, intents and attempts | 379 | initiative. |
| 380 | ||
| 381 | ### Context hub | |
| 382 | ||
| 383 | Agents working across repos and days need context that outlives any one | |
| 384 | session and reaches beyond the code. The context hub is one place an agent | |
| 385 | asks, whatever the source. | |
| 386 | ||
| 387 | | Source | What it holds | How it gets there | | |
| 388 | | --- | --- | --- | | |
| 389 | | **Memory** | Decisions, conventions, gotchas, facts about systems | Written by agents and people in g1t | | |
| 390 | | **Code and sessions** | The repos, and the reasoning behind every change | Already in g1t | | |
| 391 | | **Connected sources** | Jira and Linear tickets, Notion and Confluence pages, Google Drive documents, Slack threads, Sentry issues | Connectors, authorised per workspace | | |
| 392 | ||
| 393 | How it behaves: | |
| 394 | ||
| 395 | - **One search.** An agent asks a question and gets ranked results across | |
| 396 | all sources, each labelled with where it came from, who wrote it, and how | |
| 397 | fresh it is. | |
| 398 | - **Connected sources stay where they are.** g1t indexes them for search and | |
| 399 | fetches the current version when an agent opens one. The external system | |
| Issues and pull requests replace intents and attempts | 400 | remains the source of truth, and a link placed on an issue ("see |
| Initial g1t: services, event bus, intents and attempts | 401 | JIRA-482", a Notion URL) is pulled into the agent's starting context. |
| 402 | - **Permissions carry over.** A connector only exposes what the connecting | |
| 403 | account can see, and a workspace admin chooses which spaces, projects or | |
| 404 | channels are included. | |
| 405 | - **External content is untrusted.** A ticket or page can contain text meant | |
| 406 | to manipulate an agent. It is marked as reference material, never treated | |
| 407 | as instructions. | |
| 408 | - **Documentation is separate.** Context is what agents know; documentation | |
| 409 | is what people read, and it is generated from context and code. | |
| 410 | ||
| 411 | Memory is the part of the hub that g1t owns and agents write to: | |
| 412 | ||
| 413 | - **Memory is written freely.** Any agent or person adds an entry with one | |
| 414 | call: a decision, a convention, a gotcha, a fact about a system. No review | |
| 415 | gate. Each entry records who wrote it, from which session, and when. | |
| 416 | - **It is still a repository.** Each workspace has a memory repo in | |
| 417 | Artifacts, so every write is a commit: versioned, attributable, and | |
| 418 | revertible. | |
| 419 | - **It is kept healthy by an agent.** A consolidation agent merges | |
| 420 | duplicates, retires entries that newer ones contradict, and flags | |
| 421 | conflicts it cannot settle. People can pin an entry (agents may not change | |
| 422 | it), correct it, or retract it. | |
| 423 | - **Agents read it.** Every session starts with the context relevant to its | |
| Issues and pull requests replace intents and attempts | 424 | issue, found by search, and can query more through MCP. |
| Initial g1t: services, event bus, intents and attempts | 425 | - **Updates are events.** A memory write or a change in a connected source |
| 426 | is an event, so "when context changes, update the affected docs" is an | |
| 427 | automation, on by default. | |
| 428 | - **It is scoped inside the workspace.** Some context applies to the whole | |
| 429 | workspace, some to one initiative, project or repo, so an agent gets what | |
| 430 | applies to its work. | |
| 431 | - **It never crosses workspaces.** A workspace is the isolation boundary: its | |
| 432 | context, sessions and private repos are invisible to every other | |
| 433 | workspace, and an agent's token is bound to one workspace. | |
| 434 | ||
| 435 | ## Working in g1t | |
| 436 | ||
| 437 | - **Mission control.** The signed-in home page: every running session, every | |
| Issues and pull requests replace intents and attempts | 438 | issue waiting on a decision, and what merged, across all repos. |
| 439 | - **Projects.** Group issues across repos toward one outcome and track how | |
| 440 | many are open, racing, or merged. | |
| 441 | - **Steering.** Send a message to a running pull request, or to all pull requests on an | |
| 442 | issue at once, without stopping them. | |
| Initial g1t: services, event bus, intents and attempts | 443 | - **Automations.** Rules that start work without a person (next section). |
| 444 | ||
| 445 | ## Automations and integrations | |
| 446 | ||
| 447 | An automation is **when** an event happens, **if** conditions hold, **do** | |
| 448 | something. They are defined as files in the repo (`.g1t/automations/`), the | |
| 449 | way GitHub Actions workflows are, and can also be built in the UI. | |
| 450 | ||
| 451 | ### Events that can trigger one | |
| 452 | ||
| 453 | | Source | Examples | | |
| 454 | | --- | --- | | |
| Issues and pull requests replace intents and attempts | 455 | | Git | push, merge, check failed, `main` moved | |
| 456 | | g1t | issue opened, pull request stalled, context updated, handoff declined, budget reached | | |
| Initial g1t: services, event bus, intents and attempts | 457 | | Time | cron schedule | |
| 458 | | Integrations | Sentry issue, PagerDuty incident, Linear or Jira ticket, Slack message or mention, GitHub issue, Stripe event | | |
| 459 | | Anything else | a signed generic webhook, or an email to a per-repo address | | |
| 460 | ||
| Issues and pull requests replace intents and attempts | 461 | **Actions**: open an issue (optionally assigning N agents to it), message |
| 462 | a running pull request, update documentation, notify, call a | |
| Initial g1t: services, event bus, intents and attempts | 463 | webhook, write back to the source system. |
| 464 | ||
| 465 | **Example: Sentry.** A new production error arrives. The automation opens an | |
| Issues and pull requests replace intents and attempts | 466 | issue labelled `bug`, with the stack trace, release and frequency in its |
| 467 | description. Why-blame | |
| Initial g1t: services, event bus, intents and attempts | 468 | finds the session that wrote the failing line, so the fixing agent starts |
| Issues and pull requests replace intents and attempts | 469 | with the original reasoning. When the fix merges, g1t comments on the Sentry |
| Initial g1t: services, event bus, intents and attempts | 470 | issue and resolves it. |
| 471 | ||
| 472 | ### Rules every automation obeys | |
| 473 | ||
| 474 | - **Deduplication.** The same Sentry issue firing 500 times maps to one | |
| Issues and pull requests replace intents and attempts | 475 | issue. |
| Initial g1t: services, event bus, intents and attempts | 476 | - **Limits.** Concurrency and budget caps per automation. |
| 477 | - **Loop protection.** Work started by an automation cannot retrigger the | |
| 478 | same automation without a person in between. | |
| 479 | - **External input is untrusted.** A webhook payload can contain text written | |
| 480 | by an attacker. Agents started by external events run with reduced | |
| Issues and pull requests replace intents and attempts | 481 | permissions and cannot merge without the repo's approval rule passing. |
| Initial g1t: services, event bus, intents and attempts | 482 | |
| 483 | **Checks** are the other half of what GitHub Actions does: build and test | |
| Issues and pull requests replace intents and attempts | 484 | commands declared in `.g1t/checks.yaml`, run in sandboxes on every pull request |
| Initial g1t: services, event bus, intents and attempts | 485 | and on every combined state in the landing queue. |
| 486 | ||
| 487 | Agents can also reach integrations directly: an agent definition lists MCP | |
| 488 | servers (Sentry, Linear and so on) it may use while working. | |
| 489 | ||
| 490 | ## Agents and models | |
| 491 | ||
| 492 | ### Defining an agent | |
| 493 | ||
| 494 | An agent is a file (`.g1t/agents/<name>.md`, or in the workspace library): | |
| 495 | instructions, the harness and model to run, the tools and MCP servers it may | |
| 496 | use, its sandbox image, permissions and budget. Agents take roles: planner, | |
| 497 | implementer, reviewer, conflict resolver, documenter, memory consolidator. | |
| 498 | Each role has a default that a repo can replace. | |
| 499 | ||
| 500 | ### Where it runs, and on whose model | |
| 501 | ||
| 502 | | Option | How it works | Fits | | |
| 503 | | --- | --- | --- | | |
| 504 | | Hosted, g1t's model | g1t runs the sandbox and bills usage | Getting started; no keys to manage | | |
| 505 | | Hosted, your API key | Same sandbox, your Anthropic, OpenAI or Google key | Teams with existing contracts | | |
| 506 | | Hosted, your endpoint | Any OpenAI-compatible URL: Bedrock, Vertex, Azure, a self-hosted model | Private or fine-tuned models | | |
| Issues and pull requests replace intents and attempts | 507 | | Your runner | A g1t runner daemon on your own machines picks up pull requests | Code or models that may not leave your network | |
| Initial g1t: services, event bus, intents and attempts | 508 | | Your own session | Local Claude Code, Cursor or any MCP client joins through `mcp.g1t.sh` | Individuals; subscription plans | |
| 509 | ||
| 510 | Decisions behind this: | |
| 511 | ||
| 512 | - **g1t does not build its own agent loop.** It runs existing harnesses | |
| 513 | (Claude Code first, through its headless mode) behind a small runner | |
| 514 | contract: a container image, an entry command, and session events reported | |
| 515 | through the CLI. Other harnesses plug in by meeting the contract. | |
| 516 | - **All hosted model traffic goes through Cloudflare AI Gateway.** That gives | |
| 517 | one place for spend tracking, budgets, rate limits, fallback and logs, | |
| 518 | whichever provider or endpoint is behind it. | |
| Agents as a team: lifecycle, merge queue, billing and a new shell | 519 | - **Nobody picks a model.** A person assigns work to `g1t-agent`, as they |
| 520 | would assign an issue to Copilot, and g1t routes it. Today the kind of | |
| 521 | work decides (implementing, reviewing, catching up), from one setting on | |
| 522 | the runner, and each request is tagged at the gateway with that kind, the | |
| 523 | repository and the pull request. The session records which model ran. | |
| 524 | The gateway's own dynamic routes cannot make the choice yet: they work | |
| 525 | only on its OpenAI-compatible endpoint, and the harness speaks | |
| 526 | Anthropic's. | |
| Initial g1t: services, event bus, intents and attempts | 527 | - **Subscriptions stay local.** A Claude subscription cannot be used by a |
| 528 | hosted sandbox; it needs an API key. People on subscriptions use their own | |
| 529 | Claude Code session, which is a full participant. | |
| Agents as a team: lifecycle, merge queue, billing and a new shell | 530 | - **The workspace pays.** A workspace buys credit by card and each agent |
| 531 | run deducts what the model cost plus a margin. The billing service asks | |
| 532 | nothing of the others: the runner asks it before starting a sandbox and | |
| 533 | is refused when there is no credit, and the sandbox reports what its run | |
| 534 | cost with a token only it holds. Where no card processor is configured | |
| 535 | nothing is charged and agents stay limited to listed accounts. | |
| Initial g1t: services, event bus, intents and attempts | 536 | - **Keys are secrets.** Stored in Cloudflare Secrets Store, injected into the |
| Issues and pull requests replace intents and attempts | 537 | sandbox for one pull request, never shown again. |
| Initial g1t: services, event bus, intents and attempts | 538 | |
| Agents as a team: lifecycle, merge queue, billing and a new shell | 539 | ### Seeing a pull request through |
| 540 | ||
| 541 | Assigning an issue is the only thing a person does until there is something | |
| 542 | to merge. A pull request made by a g1t agent goes through checks, a review | |
| 543 | by another agent, revision when either finds something, and catching up | |
| 544 | when `main` moves, without anyone pressing a button. It ends as ready to | |
| 545 | merge, or as "needs you" with the reason: the checks still fail after two | |
| 546 | revisions, a review could not be written, or a conflict could not be | |
| 547 | resolved. | |
| 548 | ||
| 549 | The work service decides the next step from the pull request's state and | |
| 550 | claims it in one statement, so a step is taken once. The runner asks on | |
| 551 | every event that could change the answer (ready, pushed, checks finished, | |
| 552 | review finished, `main` moved), and on a five-minute sweep for anything | |
| 553 | missed, and carries the step out in a sandbox. | |
| 554 | ||
| 555 | A pull request does not have to be up to date with `main` to merge, | |
| 556 | unless the repository's settings require it, as on GitHub. Merging one that | |
| 557 | is behind brings it up to date first (a clean merge needs no model; an | |
| 558 | agent resolves a conflict) and lands it when that push arrives. With the | |
| 559 | requirement on, catching up is a step of its own and the checks run again | |
| 560 | on the result. | |
| 561 | ||
| 562 | Each repository sets its own rules, on one settings page: whether its | |
| 563 | default branch takes pushes at all, how many approvals a merge needs and | |
| 564 | whether an agent's counts, whether failed checks can be overridden, whether | |
| 565 | a second agent reviews, and how often an agent is sent back before a person | |
| 566 | is asked. A g1t agent's pull request follows the same rules as anyone's. | |
| 567 | Pushes to a protected branch are refused in the git front end, with the | |
| 568 | reason shown by git beside the branch. | |
| 569 | ||
| 570 | Merging is a person's decision unless the repository says otherwise. With | |
| 571 | "merge automatically when ready" turned on in its settings, a ready pull | |
| 572 | request lands by itself, attributed to `g1t`. That is the whole path from | |
| 573 | an assigned issue to a commit on `main` with nobody in between. Required | |
| 574 | human approval per path, and risk tiers, are still to come. | |
| 575 | ||
| Initial g1t: services, event bus, intents and attempts | 576 | ### Choosing the right agent automatically |
| 577 | ||
| Issues and pull requests replace intents and attempts | 578 | Because several agents can work on the same issue, every issue with more |
| 579 | than one pull request is an evaluation on real work. g1t records, per repo and per kind of issue, each | |
| Initial g1t: services, event bus, intents and attempts | 580 | agent's win rate, cost and time. That produces a leaderboard, and a routing |
| Issues and pull requests replace intents and attempts | 581 | policy: send each new issue to the agent that wins that kind most often, |
| Initial g1t: services, event bus, intents and attempts | 582 | start with the cheapest that is good enough, and escalate to a stronger one |
| 583 | when checks fail. | |
| 584 | ||
| 585 | ## What GitHub ships today, and where g1t differs | |
| 586 | ||
| 587 | GitHub's Agent HQ and Copilot app give each agent session its own git | |
| 588 | worktree and branch, list sessions in a mission-control view grouped by | |
| 589 | project, and let a task be assigned to several agents so their output can be | |
| 590 | compared. Underneath, the unit of work is still a branch and a pull request. | |
| 591 | ||
| 592 | | | GitHub | g1t | | |
| 593 | | --- | --- | --- | | |
| 594 | | Where a session works | A worktree on one developer's machine, or a cloud sandbox | A server-side fork that any agent on any machine can join and anyone can open | | |
| 595 | | Agent context | Lives in the app's session view | Stored with the repository and linked from each commit (why-blame) | | |
| Issues and pull requests replace intents and attempts | 596 | | Several agents on one task | Separate pull requests to compare by hand | One issue holding every pull request made for it, compared side by side, with the merged one recorded on the issue | |
| Initial g1t: services, event bus, intents and attempts | 597 | | Collisions between agents | Found as merge conflicts at the end | Flagged during the work (overlap radar) | |
| Issues and pull requests replace intents and attempts | 598 | | Landing changes | One pull request at a time | A merge queue that lands the chosen one and closes the rest as superseded | |
| Initial g1t: services, event bus, intents and attempts | 599 | | Which agents | Those offered through a Copilot subscription | Any MCP client, plus hosted agents | |
| 600 | ||
| 601 | ## How agents connect | |
| 602 | ||
| 603 | 1. **Bring your own agent.** A remote MCP server at `mcp.g1t.sh` lets Claude | |
| Issues and pull requests replace intents and attempts | 604 | Code (or any MCP client) list issues, claim one, get a clone URL and |
| Initial g1t: services, event bus, intents and attempts | 605 | token, report progress and submit. Adding it is one command; sign-in is a |
| 606 | browser OAuth flow with no token to paste. The `g1t` CLI installs Claude | |
| 607 | Code hooks that upload the session transcript as the agent works. | |
| Agents as a team: lifecycle, merge queue, billing and a new shell | 608 | 2. **g1t agents.** Assign an issue to g1t's own agent, or many issues at |
| 609 | once, each to an agent of its own. g1t starts a sandbox for each | |
| 610 | (Cloudflare Containers), running a coding agent headless against its | |
| 611 | own pull request and fork. | |
| Initial g1t: services, event bus, intents and attempts | 612 | 3. **API and CLI.** Everything above is available at `api.g1t.sh` and |
| 613 | through `g1t`. | |
| 614 | ||
| 615 | ## Public surfaces | |
| 616 | ||
| 617 | | Host | What it serves | | |
| 618 | | --- | --- | | |
| 619 | | `g1t.sh` | The site, git over HTTPS, git over SSH | | |
| Agents as a team: lifecycle, merge queue, billing and a new shell | 620 | | `api.g1t.sh` | REST API, with no version in its paths, with a published OpenAPI document, cursor pagination, rate-limit headers, idempotency keys on writes, server-sent events for live pull request state, and signed webhooks | |
| Initial g1t: services, event bus, intents and attempts | 621 | | `mcp.g1t.sh` | Remote MCP server over streamable HTTP | |
| 622 | ||
| 623 | g1t is its own OAuth 2.1 authorization server: authorization code with PKCE, | |
| OAuth 2.1 sign-in for MCP clients and other applications | 624 | dynamic client registration that stores nothing (a client id encodes its |
| 625 | own registration, so the open endpoint cannot be used to fill a database), | |
| 626 | discovery metadata and rotating refresh tokens. Still to come: scopes | |
| Issues and pull requests replace intents and attempts | 627 | per resource (`repo:read`, `repo:write`, `issue:write`, `pull:write`). |
| Initial g1t: services, event bus, intents and attempts | 628 | MCP clients, the CLI (device flow) and third-party apps all use it. Access |
| 629 | tokens and SSH keys remain for git itself. | |
| 630 | ||
| 631 | ## Architecture | |
| 632 | ||
| 633 | | Component | Language | Runs on | Responsibility | | |
| 634 | | --- | --- | --- | --- | | |
| Issues and pull requests replace intents and attempts | 635 | | `crates/contracts`, `packages/contracts` | Rust, TypeScript | — | The interface of every service, the event catalogue, shared types. Services and clients depend on this, never on each other's code. | |
| OAuth 2.1 sign-in for MCP clients and other applications | 636 | | `services/identity` | Rust | Worker + D1 | Accounts, workspaces and memberships, sessions, SSH keys, access tokens, device sign-in, OAuth codes and grants | |
| Issues and pull requests replace intents and attempts | 637 | | `services/repos` | Rust | Worker + D1 + Artifacts | Repository registry, contents, forks, diffs, landing, git over HTTPS. Storage sits behind a `GitStore` port with an Artifacts adapter. | |
| 638 | | `services/work` | Rust | Worker + D1 | Issues, pull requests, comments, sessions; later a Durable Object per repo for the landing queue and live state | | |
| Agents as a team: lifecycle, merge queue, billing and a new shell | 639 | | `services/billing` | Rust | Worker + D1 + Stripe | Each workspace's agent credit: payments, the ledger of every run, and the gate on starting one | |
| Events service in Rust, with RFC 3339 times and accurate push events | 640 | | `services/events` | Rust | Worker + Queues + D1 | The event bus: durable log, and one queue per subscribing service | |
| Issues and pull requests replace intents and attempts | 641 | | `services/runner`, `crates/runner` | TypeScript, Rust | Worker + Containers | Starts a sandbox per g1t agent; the program inside runs the agent harness and reports through the public API | |
| Initial g1t: services, event bus, intents and attempts | 642 | | `apps/web` | TypeScript | Worker | Server-rendered site. Holds no data; calls services over RPC. | |
| Issues and pull requests replace intents and attempts | 643 | | `apps/docs` | TypeScript | Worker (static) | Documentation and the API explorer | |
| API and MCP server in Rust; a public index at the API root | 644 | | `apps/api` | Rust | Worker | REST API (`api.g1t.sh`), MCP server (`mcp.g1t.sh`) and OpenAPI document, all generated from one list of operations; the OAuth endpoints | |
| Initial g1t: services, event bus, intents and attempts | 645 | | `crates/sshd` | Rust | Container | Git over SSH, bridged to Artifacts | |
| 646 | | `crates/merged` | Rust | Container | Trial merges, conflict matrix, landing merges (needs real git; the Artifacts binding is read-only) | | |
| 647 | | `crates/core` | Rust | native and WASM | pkt-line, packfile and diff code shared by the above and by the Worker | | |
| Issues and pull requests replace intents and attempts | 648 | | `crates/g1t` | Rust | user's machine | CLI: auth, SSH proxy, Claude Code hooks, issues and pull requests | |
| Initial g1t: services, event bus, intents and attempts | 649 | |
| Issues and pull requests replace intents and attempts | 650 | Storage: Artifacts for repositories (one fork per pull request), D1 for accounts |
| Initial g1t: services, event bus, intents and attempts | 651 | and metadata, R2 for session transcripts and logs, Durable Object SQLite for |
| 652 | per-repo coordination state. | |
| 653 | ||
| 654 | How the services fit together: | |
| 655 | ||
| 656 | - **Each service is its own Worker with its own database.** It deploys, | |
| 657 | scales and fails on its own. Callers reach it through a typed RPC binding | |
| 658 | to the interface in `packages/contracts`. | |
| 659 | - **Expected failures are values.** Every call returns a `Result`, so "not | |
| 660 | found" or "forbidden" crosses a service boundary as data. | |
| 661 | - **Side effects travel as events.** A service publishes what happened | |
| Issues and pull requests replace intents and attempts | 662 | (`git.push`, `issue.opened`, `pull.merged`, …) to the bus and does not |
| Initial g1t: services, event bus, intents and attempts | 663 | call other services to react. Each subscriber consumes from its own queue. |
| 664 | Timelines, webhooks and automations read the same stream, which is what | |
| 665 | lets something like GitHub Actions be built on top. | |
| 666 | - **Every read takes the viewer.** Authorization is decided inside the | |
| 667 | service that owns the data, not by its callers. | |
| 668 | ||
| 669 | The Workers runtime scales request handling on its own, so the edge layer | |
| 670 | stays in TypeScript. Rust is used where there is real computation or a real | |
| 671 | protocol to implement. | |
| 672 | ||
| API and MCP server, Rust identity service, registration, site redesign | 673 | ## Languages |
| 674 | ||
| 675 | The site is TypeScript. Everything behind it is Rust, compiled to | |
| API and MCP server in Rust; a public index at the API root | 676 | WebAssembly for Workers and natively for containers and the CLI. Identity, repos, work, events and the API are all Rust. The one exception |
| 677 | is the Worker that starts sandboxes, because Cloudflare's Containers | |
| 678 | library is TypeScript. Rust services speak a | |
| API and MCP server, Rust identity service, registration, site redesign | 679 | small JSON protocol over service bindings (`POST /rpc/<method>`), with the |
| 680 | types in `crates/contracts`. | |
| 681 | ||
| 682 | ## Identifiers | |
| 683 | ||
| 684 | Every id is a [TypeID](https://github.com/jetify-com/typeid): a prefix naming | |
| 685 | the kind of thing, then a UUIDv7 in lowercase base32, such as | |
| Issues and pull requests replace intents and attempts | 686 | `pr_01jb2k7x9hfq0b3zj0f5s2m8ra`. |
| API and MCP server, Rust identity service, registration, site redesign | 687 | |
| 688 | - The prefix makes an id self-describing and stops ids of different kinds | |
| 689 | being mixed up. | |
| 690 | - Ids sort by creation time as plain strings. In SQLite (D1 and Durable | |
| 691 | Objects) that keeps inserts at the end of the primary-key index instead of | |
| 692 | scattering them, and gives time-ordered paging for free. | |
| 693 | - The suffix decodes to a standard UUIDv7 for any system that wants one. | |
| 694 | - Ids are made by the service that creates the record, not by the database, | |
| 695 | so they work across services and can be assigned before a write. | |
| 696 | ||
| 697 | ## Events at scale, and audit | |
| 698 | ||
| 699 | The current event log is a single D1 database. That is fine for a | |
| 700 | prototype and wrong for the target: D1 is one writer and 10 GB. The design | |
| 701 | for volume splits storage by how the data is read. | |
| 702 | ||
| 703 | | Tier | Store | Holds | Read by | | |
| 704 | | --- | --- | --- | --- | | |
| 705 | | Hot | A Durable Object per repository, with SQLite | Recent events for that repo | Timelines, live pages over WebSocket | | |
| 706 | | Complete | Cloudflare Pipelines into R2 as Apache Iceberg | Every event, forever, partitioned by day and workspace | Analytics, standups, "ask", export | | |
| 707 | | Audit | The same R2 store, under object lock | Who did what, from where, with which credential | Compliance, investigation | | |
| 708 | ||
| 709 | - **No single hot database.** Each repository's recent events live with that | |
| 710 | repository, so load spreads across as many objects as there are repos. | |
| 711 | - **The complete record is files, not rows.** Iceberg on R2 has no practical | |
| 712 | size limit and is queried with SQL. | |
| 713 | - **Audit is a property of every event.** The envelope carries the actor | |
| 714 | (person, agent, token or system), the credential used, the request id and | |
| 715 | the source address. Audit entries for a workspace are hash-chained, so a | |
| 716 | removed or altered entry is detectable, and are written under a retention | |
| 717 | lock. | |
| 718 | - **Delivery is at least once.** Consumers are idempotent on the event id. | |
| 719 | ||
| Initial g1t: services, event bus, intents and attempts | 720 | ## Accounts and forge basics |
| 721 | ||
| 722 | - Registration with email verification, sign-in, forgot password (Cloudflare | |
| 723 | Email Sending), Turnstile on public forms. | |
| 724 | - GitHub sign-in, SSH keys, access tokens, active sessions. | |
| 725 | - Profiles, public and private repositories, repository search (D1 full-text). | |
| 726 | - Rendered README, syntax highlighting, commit history, diffs. | |
| 727 | ||
| 728 | ## Built on Cloudflare | |
| 729 | ||
| 730 | | Need | Product | | |
| 731 | | --- | --- | | |
| Issues and pull requests replace intents and attempts | 732 | | Repositories; a fork per pull request; data residency per workspace | Artifacts (forks, jurisdictions) | |
| Initial g1t: services, event bus, intents and attempts | 733 | | Reacting to pushes | Artifacts event subscriptions on Queues | |
| Issues and pull requests replace intents and attempts | 734 | | Preview URL per pull request; deploy on merge | Workers Builds and previews | |
| Initial g1t: services, event bus, intents and attempts | 735 | | Site, API, MCP, git front end | Workers | |
| 736 | | Per-repo coordination, live updates | Durable Objects | | |
| Issues and pull requests replace intents and attempts | 737 | | Pull request lifecycles, automations | Workflows, Cron Triggers | |
| Initial g1t: services, event bus, intents and attempts | 738 | | Agent sandboxes, SSH server, merge engine | Sandbox SDK and Containers | |
| 739 | | Fast starts on large repos | ArtifactFS | | |
| 740 | | Model traffic, spend, budgets | AI Gateway | | |
| 741 | | Summaries, embeddings | Workers AI | | |
| 742 | | Context hub search | Vectorize | | |
| 743 | | Accounts and metadata | D1 | | |
| 744 | | Transcripts and logs | R2 | | |
| 745 | | Email, bot protection, keys | Email Sending, Turnstile, Secrets Store | | |
| 746 | ||
| 747 | ## The submission | |
| 748 | ||
| 749 | - **g1t is built on g1t.** This repository is hosted on g1t.sh, its features | |
| Issues and pull requests replace intents and attempts | 750 | are opened as issues and built by racing agents, and it deploys from |
| Initial g1t: services, event bus, intents and attempts | 751 | Artifacts through Workers Builds. The history is the proof. |
| Issues and pull requests replace intents and attempts | 752 | - **The demo follows one story.** A brief becomes a project; twelve issues |
| Initial g1t: services, event bus, intents and attempts | 753 | fan out to dozens of agents; agents notice each other, hand off, and |
| 754 | resolve a conflict; reviewers triage; the queue lands everything on | |
| 755 | `main`; why-blame explains a line; the portfolio shows where it all | |
| 756 | stands. Then the same thing at a thousand agents. | |
| 757 | - **Judges can try it in a minute.** Open registration on g1t.sh, one-click | |
| 758 | import of a GitHub repo, one command to connect Claude Code, a seeded demo | |
| 759 | workspace, and a single deploy command for running their own copy. | |
| 760 | - **The formats are open.** The commit trailers, session format and runner | |
| 761 | contract are published so other tools can interoperate. | |
| 762 | ||
| 763 | ## Build order | |
| 764 | ||
| Agents as a team: lifecycle, merge queue, billing and a new shell | 765 | What is left is ordered by how much it shows the point above, not by forge |
| 766 | parity. Forge basics are done well enough; each item below should make the | |
| 767 | demo's story stronger. | |
| 768 | ||
| Plan: what is done from the agent-first list, and what is next | 769 | Done from this list: the outcome page (a plan's issues as a live graph with |
| 770 | cost and a feed of what happened), coordination you can see (agents' issues | |
| 771 | and comments stand out in the feed; agents hold g1t's tools through a token | |
| 772 | scoped to one repository), steering a running agent (messages delivered | |
| 773 | between steps, and at the end), and recording sessions from anyone's own | |
| Plan: integrations are in | 774 | Claude Code (`curl -fsSL https://g1t.sh/install/claude.sh | sh`). Integrations are |
| 775 | in: a workspace's own model provider (Anthropic or any Anthropic-compatible | |
| 776 | endpoint, reached through a model proxy so no sandbox holds a key, for a | |
| 777 | flat orchestration fee), alerts from Sentry, Datadog and signed webhooks | |
| 778 | that open one issue per problem and can start an agent, and Jira and Linear | |
| 779 | tickets that agents read, people import, and that hear back. Racing a | |
| Plan: what is done from the agent-first list, and what is next | 780 | set number of agents on one issue is dropped: choosing how many agents to |
| 781 | use is not something people should have to do. | |
| Agents as a team: lifecycle, merge queue, billing and a new shell | 782 | |
| Plan: what is done from the agent-first list, and what is next | 783 | 1. **Handoffs and questions between agents** as states (offered, accepted, |
| 784 | declined, done) on the outcome page, not only comments. | |
| 785 | 2. **The large run.** Dozens of agents on a real repository, end to end, for | |
| 786 | the video; g1t hosted on g1t. | |
| 787 | 3. **Polish for judges trying it in a minute:** a seeded demo workspace, the | |
| 788 | empty states, and the first-run path from sign-up to an outcome landing. | |
| Initial g1t: services, event bus, intents and attempts | 789 | |
| Agents as a team: lifecycle, merge queue, billing and a new shell | 790 | Earlier items still open, after those: |
| 791 | ||
| 792 | 1. Deleting a branch once its pull request merges; approval rules per | |
| 793 | path; risk tiers. | |
| OAuth 2.1 sign-in for MCP clients and other applications | 794 | 2. Scopes on OAuth grants and access tokens. |
| API and MCP server in Rust; a public index at the API root | 795 | 3. Event storage per the design above: per-repo hot log, Iceberg on R2, |
| 796 | hash-chained audit. | |
| Rust repos service with shipping; pull requests kept in the model | 797 | 4. CLI with Claude Code hooks to record sessions automatically. |
| Agents as a team: lifecycle, merge queue, billing and a new shell | 798 | 5. Reviewing and catching up automatically, by policy; required reviews; |
| 799 | risk tiers. | |
| 800 | 6. Compare view, proof bundles; handoff between agents. | |
| 801 | 7. Projects, mission control, steering; why-blame, digest, timeline. | |
| 802 | 8. Context hub, portfolio; automations and integrations (Sentry first). | |
| 803 | 9. SSH; bot protection; own keys, endpoints and runners. | |
| 804 | 10. Large run (100+ agents across many issues), hardening, demo. | |
| Initial g1t: services, event bus, intents and attempts | 805 | |
| 806 | Later: code search, mirroring to GitHub, passkeys, SSH | |
| 807 | on port 22 without the CLI proxy (needs the Workers inbound TCP private | |
| 808 | beta). |