| 1 | # g1t plan |
| 2 | |
| 3 | g1t is where people and agents ship software together: a git platform 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 | |
| 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 | |
| 53 | ## Product model |
| 54 | |
| 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 |
| 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. |
| 64 | |
| 65 | | Concept | What it is | |
| 66 | | --- | --- | |
| 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, a description that may say what done means (a Definition of done: context, never a gate), comments, and every pull request made for it. What a merge needs is the default branch's required checks: workflow statuses, the same for people and agents. | |
| 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. |
| 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. |
| 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. |
| 88 | |
| 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. |
| 98 | |
| 99 | What g1t adds to the familiar pair: |
| 100 | |
| 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. |
| 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. |
| 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. |
| 115 | - **Both paths meet at `main`.** The same landing rules apply to a person's |
| 116 | pull request and an agent's. |
| 117 | |
| 118 | ## Converging on main |
| 119 | |
| 120 | Twelve issues started together will finish at different times and touch |
| 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 |
| 125 | issues. A planner agent can split a large goal into issues, predict |
| 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`. |
| 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 |
| 130 | enter the same area, both agents are told what the other is doing there. |
| 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 |
| 134 | session and the incoming change, so the conflict is resolved by the agent |
| 135 | that wrote the code and still knows why. |
| 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 |
| 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 |
| 143 | reviewer agent approves" merges without a person. |
| 144 | |
| 145 | ## Agents aware of each other |
| 146 | |
| 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 |
| 149 | has touched or plans to touch. Agents use it through MCP tools; g1t also |
| 150 | acts on it without being asked. |
| 151 | |
| 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 |
| 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 |
| 157 | issues are offered for merging. |
| 158 | - **Finding out-of-scope work.** An agent that discovers something outside |
| 159 | its issue asks the registry who works there. If another pull request owns that |
| 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 |
| 162 | issue instead of widening its own change. |
| 163 | - **Asking.** An agent can put a question or a request to another pull request. |
| 164 | The receiver gets it at its next turn. |
| 165 | - **Waiting.** An agent that needs another pull request's result parks itself. |
| 166 | Its sandbox sleeps, spend stops, and it resumes from the new state when |
| 167 | that pull request merges. |
| 168 | - **Agents that do not cooperate.** For pushes from tools that never call |
| 169 | these tools, g1t compares the pushed change against running pull requests and |
| 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 | |
| 183 | - **Evidence, not diffs.** Every pull request carries a proof bundle: checks run |
| 184 | and their output, a preview URL, a plain-language summary, and the |
| 185 | behaviour that changed. |
| 186 | - **Two agent reviewers.** One reviews the change against the issue. A |
| 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 |
| 190 | is, and how the reviewers ruled. Low risk merges on policy; high risk goes |
| 191 | to a person with the evidence already assembled. |
| 192 | - **Trust is earned.** An agent's record on a path (merged, reverted, caught |
| 193 | by review) raises or lowers the tier its changes land in. |
| 194 | - **Sampling.** A share of auto-merged changes is sent to a person anyway, |
| 195 | to keep the policy honest. |
| 196 | |
| 197 | ## Rethinking the git primitives |
| 198 | |
| 199 | - **No branches for agents.** A pull request is a fork; `main` is the only |
| 200 | long-lived line. There is nothing to name, clean up or go stale. |
| 201 | - **Projected main.** New pull requests start from `main` plus everything already |
| 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. |
| 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 |
| 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 | |
| 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. |
| 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 |
| 228 | resolve-on-move for every open pull request. |
| 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". |
| 232 | - **Approval rules.** Per repo and per path: merge automatically, require a |
| 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. |
| 245 | - **Take over and hand back.** Check out the pull request's fork, commit by hand, |
| 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 |
| 251 | markdown file. A planner agent turns it into a project: issues, each with |
| 252 | what done means, and 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 |
| 257 | issues are added, obsolete ones are closed. |
| 258 | |
| 259 | ### Seeing what moved |
| 260 | |
| 261 | - **Project page.** The outcome, the issue graph coloured by state, and how |
| 262 | many of its issues have landed with their required checks passing, |
| 263 | compared with when the project started. |
| 264 | - **Digest.** An agent-written summary per project and per person: what |
| 265 | merged, what is blocked on whom, which conflicts were resolved, what it |
| 266 | cost. |
| 267 | - **Timeline.** Every event (push, steer, check, conflict, merge) in order, |
| 268 | each linked to the session and the person or agent behind it. |
| 269 | |
| 270 | ## One session, any surface |
| 271 | |
| 272 | A session belongs to g1t, not to the device it started on. The browser, a |
| 273 | phone and Claude Code are views of the same session. |
| 274 | |
| 275 | - **Browser and phone.** The site is a responsive, installable web app with |
| 276 | push notifications. Everything a person does (brief, steer, answer, |
| 277 | approve, merge) works there. |
| 278 | - **Claude Code.** Through `mcp.g1t.sh` and the CLI hooks, a local session is |
| 279 | a g1t session: its transcript syncs as it runs and it appears in mission |
| 280 | control like any other. |
| 281 | - **Moving a session.** A local session can be sent to the cloud: a hosted |
| 282 | agent takes over the fork and the transcript and continues, so the laptop |
| 283 | can close. A hosted session can be pulled down: the CLI checks out the fork |
| 284 | and resumes it in local Claude Code with its history. |
| 285 | - **Limit.** A session running only on a laptop stops when the laptop does. |
| 286 | It can be steered between turns but not continued until it is moved or the |
| 287 | laptop is back. |
| 288 | |
| 289 | ## For people who do not write code |
| 290 | |
| 291 | - **Documents are first-class.** Specs, guides, policies and decisions live |
| 292 | in repos as markdown, shown in a Docs view: rendered pages, edited in the |
| 293 | browser like a document, with inline comments. "Suggest a change" is an |
| 294 | pull request and "publish" is merge, without git vocabulary. |
| 295 | - **Document issues.** "Write the onboarding guide for the billing API" is |
| 296 | an issue. Its Definition of done is a checklist judged by a reviewer agent |
| 297 | instead of a workflow. Agents draft and revise; people comment and approve. |
| 298 | - **Templates.** Product brief, RFC, decision record. A filled-in template is |
| 299 | a brief the planner can turn into a project. |
| 300 | - **Explain.** Ask about any repo, project or change in plain language and |
| 301 | get an answer with links to the code and sessions behind it. |
| 302 | - **Living documentation.** g1t generates "how this works" pages from the |
| 303 | code and keeps them current. When a merged change contradicts a document, |
| 304 | an issue opens to update it. |
| 305 | - **See it, don't read it.** Every pull request on a deployable repo gets a |
| 306 | preview URL (Workers Builds from the pull request's fork), so an approver clicks |
| 307 | through the result instead of reading a diff. Changes are also summarised |
| 308 | in plain language. |
| 309 | - **Roles.** Viewer, commenter, planner, approver: a person can plan and |
| 310 | approve work without ever cloning a repo. |
| 311 | |
| 312 | ## The macro view |
| 313 | |
| 314 | The hierarchy above a single repo: |
| 315 | |
| 316 | | Level | What it is | |
| 317 | | --- | --- | |
| 318 | | **Workspace** | A company or team: its people, repos, agents, budget and policies. | |
| 319 | | **Initiative** | A business outcome with an owner and measurable results, e.g. "move billing to usage-based pricing". Spans any number of repos. | |
| 320 | | **Outcome** | One deliverable inside an initiative: a brief and its graph of issues (shown as **Plan**). Called "project" before 2026-10-04; that name now means what [Projects](#projects) describes. | |
| 321 | | **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. | |
| 322 | |
| 323 | How it feeds up, and what is built: |
| 324 | |
| 325 | - **A workspace is the unit everything belongs to.** Repositories, people, |
| 326 | access tokens, and later projects, budgets and policies are the |
| 327 | workspace's, never a person's. An account owns nothing; its first step |
| 328 | after confirming its email is creating a workspace, and the site sends it |
| 329 | there from wherever it was going. |
| 330 | - **One namespace.** Usernames and workspaces share one set of names, as on |
| 331 | Docker Hub and npm. A username is reserved for its owner's workspace, so |
| 332 | `g1t.sh/<name>` never means two things. |
| 333 | - **The workspace page is the roll-up.** `g1t.sh/<workspace>` shows its |
| 334 | repositories with their open issues and pull requests, and the pull |
| 335 | requests in progress across all of them. Projects and initiatives will |
| 336 | roll up to the same page. Its own pages live under `/<workspace>/-/` |
| 337 | (people, access tokens, settings), which no repository can be named. |
| 338 | - **Workspace access tokens instead of service accounts.** A workspace has |
| 339 | tokens of its own, in the same table and code path as personal ones. One |
| 340 | acts as the workspace, with a member's rights in that workspace only, |
| 341 | records who made it and when it was last used, and keeps working when |
| 342 | that person leaves. CI, integrations and automations use these. |
| 343 | |
| 344 | ### Portfolio |
| 345 | |
| 346 | One page answers "where is the business" across every initiative: |
| 347 | |
| 348 | - **Health** per initiative: on track, at risk, or blocked, derived from |
| 349 | facts (checks passing, issues stalled, questions waiting on a person), |
| 350 | not self-reported. |
| 351 | - **Progress** as measurable results: required checks passing, issues |
| 352 | merged out of planned, and the trend since the start. |
| 353 | - **Forecast** from actual throughput: at the current rate, when the |
| 354 | remaining issues land. |
| 355 | - **Spend** in tokens and dollars against a budget, per initiative. |
| 356 | - **Waiting on people**: every decision or approval a person owes, by name. |
| 357 | - **Roadmap**: initiatives laid out as now, next, later, with optional |
| 358 | time-boxed cycles for teams that work in sprints. |
| 359 | |
| 360 | ### Status without asking |
| 361 | |
| 362 | - **Standup.** An agent writes a daily report per initiative and one for the |
| 363 | whole workspace: what merged, what changed direction, what is at risk and |
| 364 | why, what needs a person. Delivered by email or webhook. |
| 365 | - **Ask.** A question box over the full event log and all sessions: "what |
| 366 | happened on the billing migration since Monday?" answers with links to the |
| 367 | sessions and commits behind each claim. |
| 368 | |
| 369 | ### Long-running agents |
| 370 | |
| 371 | Work that runs for days needs supervision that does not depend on someone |
| 372 | watching. |
| 373 | |
| 374 | - **Checkpoints.** A long pull request reports milestones against its issue, so |
| 375 | progress is visible before anything merges. |
| 376 | - **Stall and drift detection.** A pull request with no meaningful progress, or |
| 377 | whose changes have wandered away from its issue, is flagged and can be |
| 378 | stopped or re-briefed automatically. |
| 379 | - **Budgets.** Hard limits on spend and time per pull request, project and |
| 380 | initiative. |
| 381 | |
| 382 | ### Context hub |
| 383 | |
| 384 | Agents working across repos and days need context that outlives any one |
| 385 | session and reaches beyond the code. The context hub is one place an agent |
| 386 | asks, whatever the source. |
| 387 | |
| 388 | | Source | What it holds | How it gets there | |
| 389 | | --- | --- | --- | |
| 390 | | **Memory** | Decisions, conventions, gotchas, facts about systems | Written by agents and people in g1t | |
| 391 | | **Code and sessions** | The repos, and the reasoning behind every change | Already in g1t | |
| 392 | | **Connected sources** | Jira and Linear tickets, Notion and Confluence pages, Google Drive documents, Slack threads, Sentry issues | Connectors, authorised per workspace | |
| 393 | |
| 394 | How it behaves: |
| 395 | |
| 396 | - **One search.** An agent asks a question and gets ranked results across |
| 397 | all sources, each labelled with where it came from, who wrote it, and how |
| 398 | fresh it is. |
| 399 | - **Connected sources stay where they are.** g1t indexes them for search and |
| 400 | fetches the current version when an agent opens one. The external system |
| 401 | remains the source of truth, and a link placed on an issue ("see |
| 402 | JIRA-482", a Notion URL) is pulled into the agent's starting context. |
| 403 | - **Permissions carry over.** A connector only exposes what the connecting |
| 404 | account can see, and a workspace admin chooses which spaces, projects or |
| 405 | channels are included. |
| 406 | - **External content is untrusted.** A ticket or page can contain text meant |
| 407 | to manipulate an agent. It is marked as reference material, never treated |
| 408 | as instructions. |
| 409 | - **Documentation is separate.** Context is what agents know; documentation |
| 410 | is what people read, and it is generated from context and code. |
| 411 | |
| 412 | Memory is the part of the hub that g1t owns and agents write to: |
| 413 | |
| 414 | - **Memory is written freely.** Any agent or person adds an entry with one |
| 415 | call: a decision, a convention, a gotcha, a fact about a system. No review |
| 416 | gate. Each entry records who wrote it, from which session, and when. |
| 417 | - **It is still a repository.** Each workspace has a memory repo in |
| 418 | Artifacts, so every write is a commit: versioned, attributable, and |
| 419 | revertible. |
| 420 | - **It is kept healthy by an agent.** A consolidation agent merges |
| 421 | duplicates, retires entries that newer ones contradict, and flags |
| 422 | conflicts it cannot settle. People can pin an entry (agents may not change |
| 423 | it), correct it, or retract it. |
| 424 | - **Agents read it.** Every session starts with the context relevant to its |
| 425 | issue, found by search, and can query more through MCP. |
| 426 | - **Updates are events.** A memory write or a change in a connected source |
| 427 | is an event, so "when context changes, update the affected docs" is an |
| 428 | automation, on by default. |
| 429 | - **It is scoped inside the workspace.** Some context applies to the whole |
| 430 | workspace, some to one initiative, project or repo, so an agent gets what |
| 431 | applies to its work. |
| 432 | - **It never crosses workspaces.** A workspace is the isolation boundary: its |
| 433 | context, sessions and private repos are invisible to every other |
| 434 | workspace, and an agent's token is bound to one workspace. |
| 435 | |
| 436 | ## Working in g1t |
| 437 | |
| 438 | - **Mission control.** The signed-in home page: every running session, every |
| 439 | issue waiting on a decision, and what merged, across all repos. |
| 440 | - **Outcomes.** Group issues across repos toward one result and track how |
| 441 | many are open, racing, or merged. (What [Projects](#projects) means is |
| 442 | below.) |
| 443 | - **Steering.** Send a message to a running pull request, or to all pull requests on an |
| 444 | issue at once, without stopping them. |
| 445 | - **Automations.** Rules that start work without a person (next section). |
| 446 | |
| 447 | ## Automations and integrations |
| 448 | |
| 449 | > **2026-10-03:** g1t's own `.g1t/automations` format was built and then set |
| 450 | > aside at the user's request ("let's just copy GitHub Actions on that for the |
| 451 | > time being"). Automation on g1t is GitHub Actions workflows in |
| 452 | > `.g1t/workflows/`; the format below is kept for later. |
| 453 | |
| 454 | An automation is **when** an event happens, **if** conditions hold, **do** |
| 455 | something. They are defined as files in the repo (`.g1t/automations/`), the |
| 456 | way GitHub Actions workflows are, and can also be built in the UI. |
| 457 | |
| 458 | ### Events that can trigger one |
| 459 | |
| 460 | | Source | Examples | |
| 461 | | --- | --- | |
| 462 | | Git | push, merge, check failed, `main` moved | |
| 463 | | g1t | issue opened, pull request stalled, context updated, handoff declined, budget reached | |
| 464 | | Time | cron schedule | |
| 465 | | Integrations | Sentry issue, PagerDuty incident, Linear or Jira ticket, Slack message or mention, GitHub issue, Stripe event | |
| 466 | | Anything else | a signed generic webhook, or an email to a per-repo address | |
| 467 | |
| 468 | **Actions**: open an issue (optionally assigning N agents to it), message |
| 469 | a running pull request, update documentation, notify, call a |
| 470 | webhook, write back to the source system. |
| 471 | |
| 472 | **Example: Sentry.** A new production error arrives. The automation opens an |
| 473 | issue labelled `bug`, with the stack trace, release and frequency in its |
| 474 | description. Why-blame |
| 475 | finds the session that wrote the failing line, so the fixing agent starts |
| 476 | with the original reasoning. When the fix merges, g1t comments on the Sentry |
| 477 | issue and resolves it. |
| 478 | |
| 479 | ### Rules every automation obeys |
| 480 | |
| 481 | - **Deduplication.** The same Sentry issue firing 500 times maps to one |
| 482 | issue. |
| 483 | - **Limits.** Concurrency and budget caps per automation. |
| 484 | - **Loop protection.** Work started by an automation cannot retrigger the |
| 485 | same automation without a person in between. |
| 486 | - **External input is untrusted.** A webhook payload can contain text written |
| 487 | by an attacker. Agents started by external events run with reduced |
| 488 | permissions and cannot merge without the repo's approval rule passing. |
| 489 | |
| 490 | **Checks** are the other half of what GitHub Actions does: build and test |
| 491 | commands declared in `.g1t/checks.yaml`, run in sandboxes on every pull request |
| 492 | and on every combined state in the landing queue. |
| 493 | |
| 494 | Agents can also reach integrations directly: an agent definition lists MCP |
| 495 | servers (Sentry, Linear and so on) it may use while working. |
| 496 | |
| 497 | ## A repository that maintains itself |
| 498 | |
| 499 | > **2026-10-04:** the user asked for Dependabot, GitHub Advanced Security and |
| 500 | > Vercel-style deployments, "so you're not having to maintain shit and you're |
| 501 | > just pushing up agents that are delivering work consistently". |
| 502 | |
| 503 | GitHub reports problems and leaves the fix to you. In g1t, an agent opens an |
| 504 | issue for each problem, writes the fix, runs its checks, links a preview and |
| 505 | lands it through the queue. People only decide. |
| 506 | |
| 507 | ### Upkeep agents |
| 508 | |
| 509 | - **Dependency updates.** A scheduled scan reads the lockfiles (npm, Cargo, |
| 510 | Go, pip), finds outdated and vulnerable packages and opens one issue per |
| 511 | update or group, assigned to g1t-agent. The agent upgrades the package, |
| 512 | fixes what the upgrade broke and lands it through the queue. A repository |
| 513 | sets how often it scans, which packages it groups and what lands without |
| 514 | review (`.g1t/upkeep.yml`, shaped like `dependabot.yml`). |
| 515 | - **Secret scanning.** Pushes are scanned for known token formats. A push |
| 516 | that adds a secret is refused with the file and line; one already in |
| 517 | history opens an issue to rotate it and remove it. |
| 518 | - **Vulnerability alerts.** Dependencies are matched against the OSV |
| 519 | database. Every alert links to the issue and pull request fixing it. |
| 520 | - **Code scanning.** A reviewer agent reads each pull request's diff for |
| 521 | security problems and leaves findings as review comments with a |
| 522 | suggested fix. Findings on `main` open issues. |
| 523 | - **A security page per repository** lists alerts, secrets and findings, |
| 524 | with the agent work on each, like GitHub's Security tab. |
| 525 | |
| 526 | All of these are event sources for the existing issue → agent → checks → |
| 527 | queue pipeline; they need no new kind of work. |
| 528 | |
| 529 | ### Deployments |
| 530 | |
| 531 | - **A preview for every pull request**, at |
| 532 | `<pr>--<repo>--<owner>.g1t.page`, linked on the pull request and updated |
| 533 | on each push. `main` deploys to `<repo>--<owner>.g1t.page`, and a |
| 534 | repository can add its own domain. |
| 535 | - **On g1t.page, not g1t.sh,** so customer code never shares cookies or an |
| 536 | origin with the site people sign in to. |
| 537 | - **Built on Workers for Platforms.** Each deployment is a user Worker in a |
| 538 | dispatch namespace; one dispatch Worker on `*.g1t.page` routes to it. The |
| 539 | build runs in the same runners as Actions. Static sites and Workers apps |
| 540 | first; container apps and databases later. |
| 541 | - **Agents use the preview.** The reviewer agent opens the preview in a |
| 542 | browser, takes screenshots of what changed and attaches them to its |
| 543 | review, so an approver sees the result without reading the diff. |
| 544 | - **Environments.** Preview, production and their secrets; deploy history |
| 545 | and one-click rollback. |
| 546 | - **Scale to zero.** An idle branch costs neither g1t nor the customer |
| 547 | anything: a Worker runs, and is billed, only while it answers a request. |
| 548 | A preview is deleted when its pull request closes or merges, and after |
| 549 | a set number of idle days. Container apps, later, sleep when idle. |
| 550 | - **Billed to the customer, never free.** The user (2026-10-04): "we |
| 551 | should not be giving any of this available for free". Every deployment |
| 552 | is metered per workspace (requests, CPU time, deployed apps, stored |
| 553 | data), priced at Cloudflare's cost + 20% like agent usage, and drawn |
| 554 | from prepaid credit. `FREE_WHILE_BUILDING` and the free model allowance |
| 555 | do not cover deployments: a workspace without credit cannot deploy, and |
| 556 | turning deployments on says so first. |
| 557 | - **Turning them on is a paid plan, the way Cloudflare's is.** "Including |
| 558 | things like them even enabling the feature should have that pay like |
| 559 | Cloudflare does." Enabling deployments for a workspace starts a monthly |
| 560 | fee that includes an allowance of requests, CPU time and deployed apps; |
| 561 | usage past it is billed per unit, as Workers for Platforms bills g1t. |
| 562 | The fee and allowance are the user's to set. |
| 563 | - **Recommended, off in one click.** Because enabling costs money, it is |
| 564 | never switched on without the workspace agreeing: new repositories |
| 565 | recommend it prominently. A repository can turn it off, keep only production, or |
| 566 | deploy somewhere else from its own workflows. Apps built for Cloudflare |
| 567 | (Workers, static assets, D1, KV, R2) deploy without configuration. |
| 568 | |
| 569 | Later, toward GitLab's DevOps breadth: environment protection rules, |
| 570 | package and container registries, releases, container hosting. |
| 571 | |
| 572 | ## Projects |
| 573 | |
| 574 | > **2026-10-04:** the user: "an extra dimension of Projects so it's not |
| 575 | > just repositories … where a lot of things can live", "very Vercel |
| 576 | > like", with dependencies across projects "the Platform Engineering / |
| 577 | > Port route", and "the repository is *part* of a project: you could be |
| 578 | > mirroring it from GitHub/GitLab/Bitbucket, or you could let us host it |
| 579 | > for you", with room for Mercurial or anything else later. |
| 580 | |
| 581 | **A project is the thing you are building and running; a repository is |
| 582 | where some of its code lives.** Everything that is about running software |
| 583 | (deployments, environments, domains, secrets, dependencies, owners, |
| 584 | health, upkeep) belongs to the project. What is about the code itself |
| 585 | (branches, pull requests, review, merge rules) stays with the repository. |
| 586 | That split is what lets the code live anywhere. |
| 587 | |
| 588 | ### The model |
| 589 | |
| 590 | | | What it is | Like | |
| 591 | | --- | --- | --- | |
| 592 | | **Workspace** | The company or team. Members, billing, plans, shared secrets. | Vercel team, GitLab group, GitHub org | |
| 593 | | **Group** | An optional named set of projects, one level: "Payments", "Mobile". For browsing, ownership and shared settings. | GitLab subgroup, Backstage system, Port domain | |
| 594 | | **Project** | One deployable thing: a site, an API, a worker, a library. Has exactly one **source**. | Vercel project, Port service, Backstage component | |
| 595 | | **Source** | Where its code is: a repository and a **root directory** in it. | Vercel's connected repo + root directory | |
| 596 | | **Dependency** | Project A uses project B: calls its API, consumes its package, reads its queue. | Port relations, Backstage `dependsOn` | |
| 597 | |
| 598 | - **One project, one source; one repository, any number of projects.** A |
| 599 | project builds from exactly one place, which keeps it as simple as |
| 600 | Vercel's. A monorepo is several projects on one repository, each with |
| 601 | its own root directory (`apps/web`, `services/api`), and a push builds |
| 602 | only the projects whose root it touched. The common case stays 1:1, and |
| 603 | every existing repository gets a project of its own name when this |
| 604 | ships, so nobody has to set anything up. |
| 605 | - **Groups are for people; dependencies are for software.** Groups decide |
| 606 | where a project shows up and who owns it. Dependencies decide what |
| 607 | happens when one changes. Neither replaces the other, and a dependency |
| 608 | can cross groups. |
| 609 | |
| 610 | ### Sources: where the code lives |
| 611 | |
| 612 | A source is an adapter behind one interface (`SourcePort`: clone URL, |
| 613 | branches, commits, pushes as events, pull requests if it has them): |
| 614 | |
| 615 | | Source | Code lives | g1t gets pushes by | Pull requests | |
| 616 | | --- | --- | --- | --- | |
| 617 | | **Hosted on g1t** (today) | Artifacts | its own events | g1t's, with agents, the queue, review | |
| 618 | | **Mirrored** from GitHub, GitLab or Bitbucket | Both; g1t keeps a copy | the provider's webhook, then fetch | The provider's, read into g1t; agents open theirs there | |
| 619 | | **Connected, not copied** | The provider only | webhook | The provider's | |
| 620 | | **Later:** Mercurial, Perforce, a tarball upload | Behind the same port | per adapter | per adapter | |
| 621 | |
| 622 | A mirrored or connected project still gets everything that is the |
| 623 | project's: previews on its pull requests (a status and a comment on |
| 624 | GitHub's), production on its default branch, secrets, dependencies, |
| 625 | upkeep agents. That is the on-ramp: a team keeps GitHub and gets g1t's |
| 626 | deployments and agents first, and moves the code later or never. |
| 627 | Bring-your-own-git is also why the project, not the repository, holds the |
| 628 | URL `g1t.sh/<workspace>/<project>`. |
| 629 | |
| 630 | ### What lives on a project |
| 631 | |
| 632 | | | Today it is on | Moves to the project | |
| 633 | | --- | --- | --- | |
| 634 | | Deployments: production, previews, build settings, root directory, framework | The repository | Yes | |
| 635 | | Environments: production, preview, and custom ones (`staging`) with protection rules (required approvers, branch limits) | Nowhere yet | New, on the project | |
| 636 | | Domains: `<project>--<workspace>.g1t.page`, and custom domains | The repository's name | Yes | |
| 637 | | Secrets and variables | The repository | Yes. Workspace rows link to projects instead of repositories. A repository's workflows read the rows of its project (with several projects on one repository, the one marked as the repository's default). | |
| 638 | | Dependencies | Nowhere | New | |
| 639 | | Owners, on-call, links (docs, dashboards, runbooks) | Nowhere | New: the catalog's metadata | |
| 640 | | Health: scorecards (has an owner, CI passes, dependencies current, no open security alerts, deploys within N days) | Nowhere | New | |
| 641 | | Upkeep agents: dependency updates, security alerts | The plan | Scoped per project | |
| 642 | | Logs and analytics of the running app | Nowhere | New: requests, errors and CPU per environment, from Workers analytics | |
| 643 | | Branches, pull requests, review, merge rules, the queue, webhooks | The repository | Stay | |
| 644 | |
| 645 | ### Dependencies: why this gets powerful |
| 646 | |
| 647 | Declared in the UI, or in the source as `.g1t/project.yml` (which wins |
| 648 | when present, as `catalog-info.yaml` does in Backstage): |
| 649 | |
| 650 | ```yaml |
| 651 | name: web |
| 652 | root: apps/web |
| 653 | dependsOn: |
| 654 | - project: api # calls its HTTP API |
| 655 | as: API_URL # its URL, per environment, as a variable |
| 656 | - project: ui-kit # consumes its package |
| 657 | ``` |
| 658 | |
| 659 | What g1t does with them: |
| 660 | |
| 661 | 1. **Reference variables.** `API_URL` above resolves to `api`'s production |
| 662 | URL in production and to the matching preview in a preview, the way |
| 663 | Railway's `${{ api.URL }}` references work. No hard-coded URLs. |
| 664 | 2. **Preview stacks.** A pull request on `api` gets its own preview, and |
| 665 | **Preview with dependents** builds `web`'s preview pointed at it, so a |
| 666 | reviewer clicks through the whole change across projects. A change that |
| 667 | spans repositories (one issue, one fork per repository) gets one stack. |
| 668 | 3. **Release order.** Production deploys go out in dependency order; a |
| 669 | change set across projects lands through the queue together or not at |
| 670 | all. |
| 671 | 4. **Impact on every pull request.** "Changes `api`; `web` and `mobile` |
| 672 | depend on it." Agents get the graph in their context: an agent |
| 673 | changing an API opens follow-up issues on the projects that call it, |
| 674 | and reviewers see what else could break. |
| 675 | 5. **Upkeep across the graph.** A vulnerable package in `ui-kit` opens |
| 676 | issues, assigned to agents, on every project that consumes it. |
| 677 | 6. **Scorecards turn into work.** A project failing a scorecard check |
| 678 | ("no owner", "dependencies 90 days old") gets an issue an agent can fix. |
| 679 | That is the Port idea with the work done for you. |
| 680 | 7. **The map.** A workspace's projects as a graph, coloured by health and |
| 681 | by what is deploying now. |
| 682 | |
| 683 | ### Pages |
| 684 | |
| 685 | - `g1t.sh/<workspace>`: projects first (grouped, with health and |
| 686 | production status), then repositories. |
| 687 | - `g1t.sh/<workspace>/<project>`: overview (production, latest previews, |
| 688 | health, owners, dependencies both ways), **Deployments**, |
| 689 | **Environments**, **Secrets and variables**, **Logs**, **Settings** |
| 690 | (source, root directory, build, domains, groups, owners). |
| 691 | - A hosted repository keeps its code pages; from a project they are its |
| 692 | **Code** tab. A repository page lists the projects built from it. |
| 693 | |
| 694 | ### Services |
| 695 | |
| 696 | - `services/projects` (new): projects, groups, sources, dependencies, |
| 697 | owners, scorecards. Events `project.created`, `project.updated`, |
| 698 | `dependency.changed`. |
| 699 | - `services/deployments`: keyed by project instead of repository. |
| 700 | - Secrets and variables: the scope becomes workspace → project. |
| 701 | - Sources: the hosted adapter wraps `services/repos`; a mirror adapter |
| 702 | per provider in `services/integrations`, which already holds those |
| 703 | connections. |
| 704 | |
| 705 | ### Build order |
| 706 | |
| 707 | 1. **Projects as the home of deployments and secrets**, 1:1 with every |
| 708 | existing repository: the service, the pages, deployments and secrets |
| 709 | moved to the project, `<project>--<workspace>.g1t.page`. |
| 710 | 2. **Dependencies:** declared in the UI and `.g1t/project.yml`, reference |
| 711 | variables, impact on pull requests and in agents' context, the map. |
| 712 | 3. **Preview stacks** and cross-project change sets. |
| 713 | 4. **Monorepos:** several projects on one repository, each with a root |
| 714 | directory, building only what a push touched. |
| 715 | 5. **Mirrored sources:** GitHub first, then GitLab and Bitbucket. |
| 716 | 6. **Groups, owners, scorecards** feeding the upkeep agents. |
| 717 | 7. **Environments** with protection rules; custom domains; logs. |
| 718 | |
| 719 | **Step 1 shipped 2026-10-04:** `services/projects`; every repository a |
| 720 | project of its own name; the site projects-first (workspace page of |
| 721 | project cards, the project overview at `g1t.sh/<workspace>/<project>`, code |
| 722 | under `/code`, the sidebar and the New project flow); deployments keyed by |
| 723 | project and branch at `<project>-<workspace>.g1t.page` and |
| 724 | `<project>-git-<branch>-<workspace>.g1t.page`; secrets and variables owned |
| 725 | by the project. |
| 726 | |
| 727 | **Step 5, GitHub, built 2026-10-05:** one GitHub App (`g1t-sh`) for both |
| 728 | sign-in and repository access. Sign-in is its user authorization with PKCE |
| 729 | (identity, `src/github.rs`): accounts known by GitHub's numeric id, a |
| 730 | matching verified email never linked without signing in to the account, |
| 731 | new accounts behind the invite check. Repositories come through its |
| 732 | installations (integrations, `src/github.rs`), copied with every branch and |
| 733 | tag by the repos service (`src/mirror.rs`) as **import**, **mirror** (g1t |
| 734 | follows GitHub on its push webhook) or **move to g1t** (GitHub follows g1t |
| 735 | on `git.push`). A mirror is a hosted repository that keeps a full copy, so |
| 736 | its project stays `hosted` and deploys like any other; the tie lives in |
| 737 | integrations' `github_repos`. Not yet: previews and statuses on GitHub's own |
| 738 | pull requests, comments and pull requests copied, GitLab and Bitbucket. |
| 739 | |
| 740 | ### People and search |
| 741 | |
| 742 | > **2026-10-04:** "pull up user profiles, using a /u/username prefix kinda |
| 743 | > like DockerHub … search for users if you search that explicitly, how |
| 744 | > GitHub has the aside for searching against filters … a significantly |
| 745 | > stronger implementation." |
| 746 | |
| 747 | - **Profiles at `g1t.sh/u/<username>`**, apart from workspaces at |
| 748 | `g1t.sh/<workspace>`: who they are, their workspaces, recent work, |
| 749 | agents' sessions they steered. |
| 750 | - **Search with a filter sidebar:** Projects, Code, Issues, Pull requests, |
| 751 | Users, Workspaces, each with its count; filters by workspace, language, |
| 752 | state, author, agent, label, date; qualifiers in the query |
| 753 | (`user:`, `is:open`, `agent:g1t-agent`) as on GitHub. Typing `u/name` |
| 754 | searches people directly, as Docker Hub does. |
| 755 | |
| 756 | 1 and 2 serve the competition directly (multi-agent coordination across |
| 757 | projects is 25% of the score); 3 is the demo's best moment if time allows. |
| 758 | |
| 759 | ## Billing model |
| 760 | |
| 761 | > **2026-10-04:** "Some things just require you to have a card on file … |
| 762 | > some things will be something you give us an initial amount of money |
| 763 | > per month just to activate, tons of things additionally will be usage |
| 764 | > based, some things will just be usage based only … at minimum a |
| 765 | > breakeven with Cloudflare costs, or in some cases a value add." Stripe |
| 766 | > moves to Flagon, Inc. (g1t.sh is its product). Proposed below; the |
| 767 | > prices are the user's to confirm. |
| 768 | |
| 769 | ### Four kinds of charge |
| 770 | |
| 771 | Every feature is exactly one of these, and the Billing page says which: |
| 772 | |
| 773 | | Kind | What the workspace does | Example | |
| 774 | | --- | --- | --- | |
| 775 | | **Free** | Nothing | Hosting code, issues, pull requests, review, the merge queue, bringing your own agent over MCP | |
| 776 | | **Card on file** | Adds a card; pays only for what it uses | Previews, g1t's agents, workflow minutes | |
| 777 | | **Activation** | Turns a feature on for a monthly fee that includes an allowance; usage past it is metered | Production deployments, Security and quality | |
| 778 | | **Usage only** | Nothing up front; every unit is metered | Model tokens, build minutes, storage past the free amount | |
| 779 | |
| 780 | A card is needed before anything that can cost money starts. Nothing is |
| 781 | ever switched on without the workspace choosing it. |
| 782 | |
| 783 | ### Postpaid, with spend limits |
| 784 | |
| 785 | - **One Stripe customer and one subscription per workspace**, on Flagon, |
| 786 | Inc.'s account. Activations are licensed line items; every usage |
| 787 | dimension is a metered price backed by a Stripe Meter. Stripe invoices |
| 788 | monthly in arrears and charges the card on file; failed payments go |
| 789 | through Stripe's retries and emails, and g1t hears of them by webhook. |
| 790 | - **Spend limits instead of prepaid credit.** A workspace sets a monthly |
| 791 | limit overall and per feature (Vercel's spend management). g1t counts |
| 792 | usage as it happens and stops starting new paid work at the limit, |
| 793 | with a warning at 50%, 80% and 100%. Prepaid top-ups go away; promotions |
| 794 | (the free model allowance) become Stripe credit on the customer. |
| 795 | - **Usage reaches Stripe from billing alone.** Every service reports |
| 796 | usage to the billing service as it happens (it already records agent |
| 797 | runs and builds); billing batches them into Stripe meter events every |
| 798 | few minutes, idempotently by g1t's own ids, and keeps the ledger g1t's |
| 799 | pages show. Nothing else talks to Stripe. |
| 800 | |
| 801 | ### Scope: workspace, then projects |
| 802 | |
| 803 | - A feature is turned on for the **workspace** (by an owner, with the |
| 804 | activation if it has one), then allowed for **all projects** or |
| 805 | **selected projects**. |
| 806 | - Every **project** can opt out on its own page. A project with nothing |
| 807 | to deploy (no Workers config, no build script, no `index.html`) is |
| 808 | detected, says so on its Deployments page, and never builds or costs |
| 809 | anything. |
| 810 | - Agents and workflows are allowed per project the same way, so a |
| 811 | workspace can keep spend to the projects that matter. |
| 812 | |
| 813 | ### Prices: what it costs us, passed through |
| 814 | |
| 815 | > **2026-10-04, decided:** postpaid with spend limits, as Vercel and |
| 816 | > Cloudflare do; no per-seat price, ever ("fuck per-seat pricing"). |
| 817 | > "If they're barely using them great, but if they're using the shit out |
| 818 | > of them that will cost me a ton, so that cost needs to move onto them." |
| 819 | |
| 820 | **Every Cloudflare cost a workspace causes is metered to it.** Light use |
| 821 | fits in a small free allowance; past it, each unit is charged at |
| 822 | Cloudflare's price times a margin of at least 1.5, which pays for Stripe |
| 823 | (about 3%), shared overhead (the site, the API, D1) and g1t itself. |
| 824 | |
| 825 | Cloudflare's prices (October 2026), and the cost per unit g1t meters: |
| 826 | |
| 827 | | What g1t meters | Cloudflare's price | Cost to g1t per unit | |
| 828 | | --- | --- | --- | |
| 829 | | **Sandbox minute** (agents, checks, merge queue, workflow jobs, deploy builds), standard-1: ½ vCPU, 4 GiB, 8 GB | CPU $0.00002 / vCPU-s while busy; memory $0.0000025 / GiB-s and disk $0.00000007 / GB-s while running | ≤ $0.0012 / minute (CPU counted as busy throughout, since g1t cannot see it per sandbox) | |
| 830 | | **App request** (deployments) | Workers for Platforms: $0.30 / million past 20M | $0.30 / million | |
| 831 | | **App CPU** | $0.02 / million CPU-ms past 60M | $0.02 / million ms | |
| 832 | | **App** (a deployed script) | $0.02 / script-month past 1,000 | $0.02 / app-month | |
| 833 | | **Storage** (repositories, artifacts, caches) | Artifacts $0.50 / GB-month (billing starts 2026-10-14); KV $0.50 / GB-month | $0.50 / GB-month | |
| 834 | | **Git operation** (clone, fetch, push) | Artifacts $0.15 / 1,000 past 10,000 | $0.15 / 1,000 | |
| 835 | | **Model tokens** | The provider's price | As charged | |
| 836 | | Container egress, emails, the site's own requests | Small and shared | In the margin | |
| 837 | |
| 838 | > **2026-10-06, decided:** no per-feature quotas on the plan. "A paying |
| 839 | > user should be able to push past the Git operations number, they're |
| 840 | > just paying usage on it." One plan, $20 a month per workspace with $10 |
| 841 | > of usage included; every meter is charged from the first unit at cost + |
| 842 | > 20% (builds, app requests and CPU, custom domains), drawn from the $10 |
| 843 | > first, then up to the spend limit, which is the only thing that stops a |
| 844 | > paying workspace (with abuse protection). Projects, previews and apps |
| 845 | > are not metered (Workers for Platforms' script pool makes them ~free). |
| 846 | > The forge's free amounts are the same for everyone: 1 GB private storage |
| 847 | > and 50,000 git operations a month; past them the plan pays and a free |
| 848 | > workspace is held (pushes stop, git slowed). The table below is the |
| 849 | > earlier proposal; billing's price book and g1t.sh/pricing are current. |
| 850 | |
| 851 | What a workspace pays: |
| 852 | |
| 853 | | Meter | Free each month | Then | Margin | For comparison | |
| 854 | | --- | --- | --- | --- | --- | |
| 855 | | Sandbox minutes | None (2026-10-05: charged from the first second) | Cost + 20%, by the second | 1.2× | GitHub Actions $0.008 / minute (Linux 2-core); Vercel builds $0.0035 / CPU-minute | |
| 856 | | App requests | 1 million with Deployments | $0.50 / million | 1.7× | Vercel $0.60 / million invocations | |
| 857 | | App CPU | 3 million ms with Deployments | $0.04 / million ms | 2× | Vercel active CPU about $0.036 / million ms | |
| 858 | | Apps | 10 with Deployments | $0.05 / app-month | 2.5× | | |
| 859 | | Storage | 1 GB | $1.00 / GB-month | 2× | GitHub LFS $0.07 / GB, but repositories are free there | |
| 860 | | Git operations | 10,000 | $0.30 / 1,000 | 2× | | |
| 861 | | g1t's models | | Cost + 20% | 1.2× | The provider's own price | |
| 862 | | Your own model provider | | Only its sandbox minutes (the $0.10 run fee was dropped 2026-10-05) | | | |
| 863 | | **Deployments** activation | | $5 / month, with the allowances above | covers Workers for Platforms' $25 / month across workspaces | Vercel Pro $20 per seat | |
| 864 | | **Security and quality** activation (later) | | $10 / month; fixes as agent usage | | GitHub Advanced Security $49 per committer | |
| 865 | |
| 866 | A workspace that uses g1t lightly (a few agent runs, a small site) |
| 867 | pays nothing or its activation; a workspace running agents all day pays |
| 868 | for the sandboxes and models those agents use, with g1t's margin on |
| 869 | each. Nothing in a workspace's bill is subsidised by another's. |
| 870 | |
| 871 | ### Build order |
| 872 | |
| 873 | 1. Stripe customer per workspace and card on file (Checkout in setup |
| 874 | mode), webhooks (invoice paid and failed, subscription changes, |
| 875 | payment method changes), the Billing page rebuilt around the four |
| 876 | kinds. |
| 877 | 2. One subscription per workspace with activations as items; Deployments |
| 878 | moves onto it. |
| 879 | 3. Meters for each usage dimension above, fed from billing's ledger: |
| 880 | every sandbox reports how long it ran when it stops (agents, checks, |
| 881 | the queue, workflow jobs and deploy builds alike); deployments report |
| 882 | requests, CPU and apps; repos report storage and git operations. Spend |
| 883 | limits and their warnings; prepaid credit retired. |
| 884 | 4. Per-workspace allow-lists of projects for each feature, and per-project |
| 885 | opt-out; "nothing to deploy" detection. |
| 886 | 5. Turn off FREE_WHILE_BUILDING when the user says so. **Done 2026-10-05.** |
| 887 | |
| 888 | Shipped by 2026-10-05: sandbox seconds for every sandbox; the price book |
| 889 | and its keeper (runs settled to AI Gateway's price every 15 minutes; |
| 890 | Container and Workers costs checked against Cloudflare's billable usage |
| 891 | and container analytics daily, with a public change log on |
| 892 | g1t.sh/pricing); usage limits by trust with automatic payment near the |
| 893 | limit; app traffic counted toward limits as it happens; billing accounts, |
| 894 | terms and enterprises; free mode off, syntaqx comped. |
| 895 | |
| 896 | Still to build, in order: Stripe card-on-file without a payment (setup |
| 897 | mode) and webhooks; month-end invoices for postpaid usage (and one |
| 898 | invoice per enterprise); the subscription with activations as items; |
| 899 | storage and git-operation meters; limit warnings by email at 50/80/100%; |
| 900 | self-serve enterprise management for enterprise owners. |
| 901 | |
| 902 | ### Accounts, terms and enterprises |
| 903 | |
| 904 | Every workspace is paid for by a billing account: its own (`ws_<slug>`) |
| 905 | or an enterprise's (`ent_…`), which pays for several workspaces with one |
| 906 | limit, one set of terms and, once invoices exist, one bill, as GitHub |
| 907 | Enterprise does. Terms are standard, comped (nothing charged, usage still |
| 908 | recorded at cost, paid features on) or custom (a discount, its own |
| 909 | ceiling, an end date). g1t staff manage them in **sudo.g1t.sh**, a |
| 910 | separate Worker behind Cloudflare Access that also verifies the Access |
| 911 | token itself and allows only listed staff emails; every change is kept |
| 912 | with who made it and why. |
| 913 | |
| 914 | ### Limits: stop non-payers, never payers |
| 915 | |
| 916 | The limit is on usage not yet paid for, counted at cost to g1t or charge, |
| 917 | whichever is more: $3 before any live payment, then twice what has been |
| 918 | paid ($25 to $1,000), or what staff set. A workspace with a card on file |
| 919 | is charged automatically near its limit, which both pays what it owes and |
| 920 | raises the limit, so paying users are never stopped. A declined card |
| 921 | stops work until paid. The owner's own spend limit always means stop. |
| 922 | Test-mode payments never lower exposure or raise trust. |
| 923 | |
| 924 | ## Agents and models |
| 925 | |
| 926 | ### Defining an agent |
| 927 | |
| 928 | An agent is a file (`.g1t/agents/<name>.md`, or in the workspace library): |
| 929 | instructions, the harness and model to run, the tools and MCP servers it may |
| 930 | use, its sandbox image, permissions and budget. Agents take roles: planner, |
| 931 | implementer, reviewer, conflict resolver, documenter, memory consolidator. |
| 932 | Each role has a default that a repo can replace. |
| 933 | |
| 934 | ### Where it runs, and on whose model |
| 935 | |
| 936 | | Option | How it works | Fits | |
| 937 | | --- | --- | --- | |
| 938 | | Hosted, g1t's model | g1t runs the sandbox and bills usage | Getting started; no keys to manage | |
| 939 | | Hosted, your API key | Same sandbox, your Anthropic, OpenAI or Google key | Teams with existing contracts | |
| 940 | | Hosted, your endpoint | Any OpenAI-compatible URL: Bedrock, Vertex, Azure, a self-hosted model | Private or fine-tuned models | |
| 941 | | Your runner | A g1t runner daemon on your own machines picks up pull requests | Code or models that may not leave your network | |
| 942 | | Your own session | Local Claude Code, Cursor or any MCP client joins through `mcp.g1t.sh` | Individuals; subscription plans | |
| 943 | |
| 944 | Decisions behind this: |
| 945 | |
| 946 | - **g1t does not build its own agent loop.** It runs existing harnesses |
| 947 | (Claude Code first, through its headless mode) behind a small runner |
| 948 | contract: a container image, an entry command, and session events reported |
| 949 | through the CLI. Other harnesses plug in by meeting the contract. |
| 950 | - **All hosted model traffic goes through Cloudflare AI Gateway.** That gives |
| 951 | one place for spend tracking, budgets, rate limits, fallback and logs, |
| 952 | whichever provider or endpoint is behind it. |
| 953 | - **Nobody picks a model.** A person assigns work to `g1t-agent`, as they |
| 954 | would assign an issue to Copilot, and g1t routes it. Today the kind of |
| 955 | work decides (implementing, reviewing, catching up), from one setting on |
| 956 | the runner, and each request is tagged at the gateway with that kind, the |
| 957 | repository and the pull request. The session records which model ran. |
| 958 | The gateway's own dynamic routes cannot make the choice yet: they work |
| 959 | only on its OpenAI-compatible endpoint, and the harness speaks |
| 960 | Anthropic's. |
| 961 | - **Subscriptions stay local.** A Claude subscription cannot be used by a |
| 962 | hosted sandbox; it needs an API key. People on subscriptions use their own |
| 963 | Claude Code session, which is a full participant. |
| 964 | - **The workspace pays.** A workspace buys credit by card and each agent |
| 965 | run deducts what the model cost plus a margin. The billing service asks |
| 966 | nothing of the others: the runner asks it before starting a sandbox and |
| 967 | is refused when there is no credit, and the sandbox reports what its run |
| 968 | cost with a token only it holds. Where no card processor is configured |
| 969 | nothing is charged and agents stay limited to listed accounts. |
| 970 | - **Keys are secrets.** Stored in Cloudflare Secrets Store, injected into the |
| 971 | sandbox for one pull request, never shown again. |
| 972 | |
| 973 | ### Seeing a pull request through |
| 974 | |
| 975 | Assigning an issue is the only thing a person does until there is something |
| 976 | to merge. A pull request made by a g1t agent goes through checks, a review |
| 977 | by another agent, revision when either finds something, and catching up |
| 978 | when `main` moves, without anyone pressing a button. It ends as ready to |
| 979 | merge, or as "needs you" with the reason: the checks still fail after two |
| 980 | revisions, a review could not be written, or a conflict could not be |
| 981 | resolved. |
| 982 | |
| 983 | The work service decides the next step from the pull request's state and |
| 984 | claims it in one statement, so a step is taken once. The runner asks on |
| 985 | every event that could change the answer (ready, pushed, checks finished, |
| 986 | review finished, `main` moved), and on a five-minute sweep for anything |
| 987 | missed, and carries the step out in a sandbox. |
| 988 | |
| 989 | A pull request does not have to be up to date with `main` to merge, |
| 990 | unless the repository's settings require it, as on GitHub. Merging one that |
| 991 | is behind brings it up to date first (a clean merge needs no model; an |
| 992 | agent resolves a conflict) and lands it when that push arrives. With the |
| 993 | requirement on, catching up is a step of its own and the checks run again |
| 994 | on the result. |
| 995 | |
| 996 | Each repository sets its own rules, on one settings page: whether its |
| 997 | default branch takes pushes at all, how many approvals a merge needs and |
| 998 | whether an agent's counts, whether failed checks can be overridden, whether |
| 999 | a second agent reviews, and how often an agent is sent back before a person |
| 1000 | is asked. A g1t agent's pull request follows the same rules as anyone's. |
| 1001 | Pushes to a protected branch are refused in the git front end, with the |
| 1002 | reason shown by git beside the branch. |
| 1003 | |
| 1004 | Merging is a person's decision unless the repository says otherwise. With |
| 1005 | "merge automatically when ready" turned on in its settings, a ready pull |
| 1006 | request lands by itself, attributed to `g1t`. That is the whole path from |
| 1007 | an assigned issue to a commit on `main` with nobody in between. Required |
| 1008 | human approval per path, and risk tiers, are still to come. |
| 1009 | |
| 1010 | ### Choosing the right agent automatically |
| 1011 | |
| 1012 | Because several agents can work on the same issue, every issue with more |
| 1013 | than one pull request is an evaluation on real work. g1t records, per repo and per kind of issue, each |
| 1014 | agent's win rate, cost and time. That produces a leaderboard, and a routing |
| 1015 | policy: send each new issue to the agent that wins that kind most often, |
| 1016 | start with the cheapest that is good enough, and escalate to a stronger one |
| 1017 | when checks fail. |
| 1018 | |
| 1019 | ## Talking: the inbox and channels |
| 1020 | |
| 1021 | Not a discussions forum. People and agents need one place to talk in real |
| 1022 | time, and an app that feels like one on desktop and phone. |
| 1023 | |
| 1024 | **The inbox comes first.** Everything that needs a person or that they |
| 1025 | follow, from people and agents: review requests, agent questions and |
| 1026 | handoffs, failures, mentions, deploys. Read and unread, saved, done, |
| 1027 | snoozed; ranked so what an agent is blocked on comes first; email digests |
| 1028 | and push. It is the delivery layer chat needs too (who is told what, read |
| 1029 | state, push), so building it first makes channels cheap. |
| 1030 | |
| 1031 | **Channels** (working name): workspace channels, direct messages and |
| 1032 | threads, live. |
| 1033 | |
| 1034 | - Each channel is a Durable Object holding its WebSocket connections with |
| 1035 | hibernation, so idle channels cost nothing; history in D1, files in R2. |
| 1036 | - Agents are members. `@g1t-agent` in a channel starts work, answers, or |
| 1037 | posts a summary; agents post their questions and handoffs where people |
| 1038 | already are. A thread becomes an issue or an outcome in one action, and |
| 1039 | the agent's progress streams into that thread. |
| 1040 | - Tied to the work: issues, pull requests, runs and deploys each have a |
| 1041 | thread; links unfurl into live cards (checks, agent step, preview). |
| 1042 | What a channel settles can become workspace memory, with its source. |
| 1043 | - Apps: an installable PWA first (desktop and mobile, offline shell, Web |
| 1044 | Push), then native shells on the same API: Tauri for desktop (tray, |
| 1045 | deep links), React Native for iOS and Android (background |
| 1046 | notifications). |
| 1047 | |
| 1048 | GitHub-style Discussions are not planned: channels and threads on the |
| 1049 | work replace them. |
| 1050 | |
| 1051 | ## What GitHub ships today, and where g1t differs |
| 1052 | |
| 1053 | GitHub's Agent HQ and Copilot app give each agent session its own git |
| 1054 | worktree and branch, list sessions in a mission-control view grouped by |
| 1055 | project, and let a task be assigned to several agents so their output can be |
| 1056 | compared. Underneath, the unit of work is still a branch and a pull request. |
| 1057 | |
| 1058 | | | GitHub | g1t | |
| 1059 | | --- | --- | --- | |
| 1060 | | 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 | |
| 1061 | | Agent context | Lives in the app's session view | Stored with the repository and linked from each commit (why-blame) | |
| 1062 | | 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 | |
| 1063 | | Collisions between agents | Found as merge conflicts at the end | Flagged during the work (overlap radar) | |
| 1064 | | Landing changes | One pull request at a time | A merge queue that lands the chosen one and closes the rest as superseded | |
| 1065 | | Which agents | Those offered through a Copilot subscription | Any MCP client, plus hosted agents | |
| 1066 | |
| 1067 | ## How agents connect |
| 1068 | |
| 1069 | 1. **Bring your own agent.** A remote MCP server at `mcp.g1t.sh` lets Claude |
| 1070 | Code (or any MCP client) list issues, claim one, get a clone URL and |
| 1071 | token, report progress and submit. Adding it is one command; sign-in is a |
| 1072 | browser OAuth flow with no token to paste. The `g1t` CLI installs Claude |
| 1073 | Code hooks that upload the session transcript as the agent works. |
| 1074 | 2. **g1t agents.** Assign an issue to g1t's own agent, or many issues at |
| 1075 | once, each to an agent of its own. g1t starts a sandbox for each |
| 1076 | (Cloudflare Containers), running a coding agent headless against its |
| 1077 | own pull request and fork. |
| 1078 | 3. **API and CLI.** Everything above is available at `api.g1t.sh` and |
| 1079 | through `g1t`. |
| 1080 | |
| 1081 | ## Public surfaces |
| 1082 | |
| 1083 | | Host | What it serves | |
| 1084 | | --- | --- | |
| 1085 | | `g1t.sh` | The site, git over HTTPS, git over SSH | |
| 1086 | | `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 | |
| 1087 | | `mcp.g1t.sh` | Remote MCP server over streamable HTTP | |
| 1088 | |
| 1089 | g1t is its own OAuth 2.1 authorization server: authorization code with PKCE, |
| 1090 | dynamic client registration that stores nothing (a client id encodes its |
| 1091 | own registration, so the open endpoint cannot be used to fill a database), |
| 1092 | discovery metadata and rotating refresh tokens. Still to come: scopes |
| 1093 | per resource (`repo:read`, `repo:write`, `issue:write`, `pull:write`). |
| 1094 | MCP clients, the CLI (device flow) and third-party apps all use it. Access |
| 1095 | tokens and SSH keys remain for git itself. |
| 1096 | |
| 1097 | ## Architecture |
| 1098 | |
| 1099 | | Component | Language | Runs on | Responsibility | |
| 1100 | | --- | --- | --- | --- | |
| 1101 | | `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. | |
| 1102 | | `services/identity` | Rust | Worker + D1 | Accounts, workspaces and memberships, sessions, SSH keys, access tokens, device sign-in, OAuth codes and grants | |
| 1103 | | `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. | |
| 1104 | | `services/work` | Rust | Worker + D1 | Issues, pull requests, comments, sessions; later a Durable Object per repo for the landing queue and live state | |
| 1105 | | `services/billing` | Rust | Worker + D1 + Stripe | Each workspace's agent credit: payments, the ledger of every run, and the gate on starting one | |
| 1106 | | `services/events` | Rust | Worker + Queues + D1 | The event bus: durable log, and one queue per subscribing service | |
| 1107 | | `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 | |
| 1108 | | `services/og` | TypeScript | Worker + Cache API | Social cards at `og.g1t.sh`: one PNG per page of the site and the docs (satori and resvg), looked up as an anonymous visitor, so nothing private appears on one | |
| 1109 | | `apps/web` | TypeScript | Worker | Server-rendered site. Holds no data; calls services over RPC. | |
| 1110 | | `apps/docs` | TypeScript | Worker (static) | Documentation and the API explorer | |
| 1111 | | `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 | |
| 1112 | | `crates/sshd` | Rust | Container | Git over SSH, bridged to Artifacts | |
| 1113 | | `crates/merged` | Rust | Container | Trial merges, conflict matrix, landing merges (needs real git; the Artifacts binding is read-only) | |
| 1114 | | `crates/core` | Rust | native and WASM | pkt-line, packfile and diff code shared by the above and by the Worker | |
| 1115 | | `crates/g1t` | Rust | user's machine | CLI: auth, SSH proxy, Claude Code hooks, issues and pull requests | |
| 1116 | |
| 1117 | Storage: Artifacts for repositories (one fork per pull request), D1 for accounts |
| 1118 | and metadata, R2 for session transcripts and logs, Durable Object SQLite for |
| 1119 | per-repo coordination state. |
| 1120 | |
| 1121 | How the services fit together: |
| 1122 | |
| 1123 | - **Each service is its own Worker with its own database.** It deploys, |
| 1124 | scales and fails on its own. Callers reach it through a typed RPC binding |
| 1125 | to the interface in `packages/contracts`. |
| 1126 | - **Expected failures are values.** Every call returns a `Result`, so "not |
| 1127 | found" or "forbidden" crosses a service boundary as data. |
| 1128 | - **Side effects travel as events.** A service publishes what happened |
| 1129 | (`git.push`, `issue.opened`, `pull.merged`, …) to the bus and does not |
| 1130 | call other services to react. Each subscriber consumes from its own queue. |
| 1131 | Timelines, webhooks and automations read the same stream, which is what |
| 1132 | lets something like GitHub Actions be built on top. |
| 1133 | - **Every read takes the viewer.** Authorization is decided inside the |
| 1134 | service that owns the data, not by its callers. |
| 1135 | |
| 1136 | The Workers runtime scales request handling on its own, so the edge layer |
| 1137 | stays in TypeScript. Rust is used where there is real computation or a real |
| 1138 | protocol to implement. |
| 1139 | |
| 1140 | ## Languages |
| 1141 | |
| 1142 | The site is TypeScript. Everything behind it is Rust, compiled to |
| 1143 | WebAssembly for Workers and natively for containers and the CLI. Identity, repos, work, events and the API are all Rust. The one exception |
| 1144 | is the Worker that starts sandboxes, because Cloudflare's Containers |
| 1145 | library is TypeScript. Rust services speak a |
| 1146 | small JSON protocol over service bindings (`POST /rpc/<method>`), with the |
| 1147 | types in `crates/contracts`. |
| 1148 | |
| 1149 | ## Identifiers |
| 1150 | |
| 1151 | Every id is a [TypeID](https://github.com/jetify-com/typeid): a prefix naming |
| 1152 | the kind of thing, then a UUIDv7 in lowercase base32, such as |
| 1153 | `pr_01jb2k7x9hfq0b3zj0f5s2m8ra`. |
| 1154 | |
| 1155 | - The prefix makes an id self-describing and stops ids of different kinds |
| 1156 | being mixed up. |
| 1157 | - Ids sort by creation time as plain strings. In SQLite (D1 and Durable |
| 1158 | Objects) that keeps inserts at the end of the primary-key index instead of |
| 1159 | scattering them, and gives time-ordered paging for free. |
| 1160 | - The suffix decodes to a standard UUIDv7 for any system that wants one. |
| 1161 | - Ids are made by the service that creates the record, not by the database, |
| 1162 | so they work across services and can be assigned before a write. |
| 1163 | |
| 1164 | ## Events at scale, and audit |
| 1165 | |
| 1166 | The current event log is a single D1 database. That is fine for a |
| 1167 | prototype and wrong for the target: D1 is one writer and 10 GB. The design |
| 1168 | for volume splits storage by how the data is read. |
| 1169 | |
| 1170 | | Tier | Store | Holds | Read by | |
| 1171 | | --- | --- | --- | --- | |
| 1172 | | Hot | A Durable Object per repository, with SQLite | Recent events for that repo | Timelines, live pages over WebSocket | |
| 1173 | | Complete | Cloudflare Pipelines into R2 as Apache Iceberg | Every event, forever, partitioned by day and workspace | Analytics, standups, "ask", export | |
| 1174 | | Audit | The same R2 store, under object lock | Who did what, from where, with which credential | Compliance, investigation | |
| 1175 | |
| 1176 | - **No single hot database.** Each repository's recent events live with that |
| 1177 | repository, so load spreads across as many objects as there are repos. |
| 1178 | - **The complete record is files, not rows.** Iceberg on R2 has no practical |
| 1179 | size limit and is queried with SQL. |
| 1180 | - **Audit is a property of every event.** The envelope carries the actor |
| 1181 | (person, agent, token or system), the credential used, the request id and |
| 1182 | the source address. Audit entries for a workspace are hash-chained, so a |
| 1183 | removed or altered entry is detectable, and are written under a retention |
| 1184 | lock. |
| 1185 | - **Delivery is at least once.** Consumers are idempotent on the event id. |
| 1186 | |
| 1187 | ## Accounts and forge basics |
| 1188 | |
| 1189 | - Registration with email verification, sign-in, forgot password (Cloudflare |
| 1190 | Email Sending), Turnstile on public forms. |
| 1191 | - GitHub sign-in, SSH keys, access tokens, active sessions. |
| 1192 | - Profiles, public and private repositories, repository search (D1 full-text). |
| 1193 | - Rendered README, syntax highlighting, commit history, diffs. |
| 1194 | - Transferring a repository between workspaces (by id: its git store key |
| 1195 | never moves; every service follows `repo.transferred`; old paths redirect |
| 1196 | until reused) and deleting an empty, settled workspace (its slug is |
| 1197 | tombstoned, never reissued except to the person whose username it is). |
| 1198 | |
| 1199 | ## Built on Cloudflare |
| 1200 | |
| 1201 | | Need | Product | |
| 1202 | | --- | --- | |
| 1203 | | Repositories; a fork per pull request; data residency per workspace | Artifacts (forks, jurisdictions) | |
| 1204 | | Reacting to pushes | Artifacts event subscriptions on Queues | |
| 1205 | | Preview URL per pull request; deploy on merge | Workers for Platforms on `g1t.page` | |
| 1206 | | Site, API, MCP, git front end | Workers | |
| 1207 | | Per-repo coordination, live updates | Durable Objects | |
| 1208 | | Pull request lifecycles, automations | Workflows, Cron Triggers | |
| 1209 | | Agent sandboxes, SSH server, merge engine | Sandbox SDK and Containers | |
| 1210 | | Fast starts on large repos | ArtifactFS | |
| 1211 | | Model traffic, spend, budgets | AI Gateway | |
| 1212 | | Summaries, embeddings | Workers AI | |
| 1213 | | Context hub search | Vectorize | |
| 1214 | | Accounts and metadata | D1 | |
| 1215 | | Transcripts and logs | R2 | |
| 1216 | | Email, bot protection, keys | Email Sending, Turnstile, Secrets Store | |
| 1217 | |
| 1218 | ## Running g1t yourself |
| 1219 | |
| 1220 | g1t.sh runs on Cloudflare, and that does not change. The core is MIT and |
| 1221 | must also run on anyone's own machine with `docker compose up`. A free |
| 1222 | core people can self-host is what makes paid hosting worth trusting. |
| 1223 | Self-hosting never makes hosted worse: hosted code paths keep their |
| 1224 | behaviour, and a self-hosted adapter sits beside the hosted one. The |
| 1225 | inventory of every Cloudflare dependency, the design and the risks are in |
| 1226 | [SELF_HOSTING.md](SELF_HOSTING.md). |
| 1227 | |
| 1228 | The approach: the Workers stay Workers, and self-hosted they run in |
| 1229 | workerd, the open-source Workers runtime. D1, KV and Queues are SQLite on a |
| 1230 | volume, with the same migrations. Cloudflare-only bindings are replaced |
| 1231 | by stand-ins: |
| 1232 | |
| 1233 | - Artifacts becomes bare repositories served by `git http-backend`; |
| 1234 | - Email Sending becomes SMTP, through Mailpit; |
| 1235 | - services that are off answer "off" instead of failing. |
| 1236 | |
| 1237 | | Phase | Scope | Estimate | |
| 1238 | | --- | --- | --- | |
| 1239 | | 1. Core forge | Done: `deploy/self-host/` (compose, git store, binding stand-ins, smoke test) and the "Run g1t yourself" guide. Left: the API on its own port, `PUBLIC_URL` in place of hard-coded hosts, cron, pull requests in the smoke test, CI that runs it. | 1–1.5 weeks left | |
| 1240 | | 2. Agents | Docker sandboxes with the same runner image, an egress allow-list proxy for guardrails, `g1t.toml`, a launcher in place of `wrangler dev` | 2–3 weeks | |
| 1241 | | 3. Search, context, deployments | sqlite-vec plus an OpenAI-compatible embedder; an app host on workerd; Caddy for app and custom domains; SSH | 3–4 weeks | |
| 1242 | | 4. Parity and upgrades | Code-level ports in `g1t_kit` and `@g1t/platform`, sudo without Access, online backups, released images, an upgrade test in CI | 3–4 weeks | |
| 1243 | |
| 1244 | ## The submission |
| 1245 | |
| 1246 | - **g1t is built on g1t.** This repository is hosted on g1t.sh, its features |
| 1247 | are opened as issues and built by racing agents, and it deploys from |
| 1248 | Artifacts through Workers Builds. The history is the proof. |
| 1249 | - **The demo follows one story.** A brief becomes a project; twelve issues |
| 1250 | fan out to dozens of agents; agents notice each other, hand off, and |
| 1251 | resolve a conflict; reviewers triage; the queue lands everything on |
| 1252 | `main`; why-blame explains a line; the portfolio shows where it all |
| 1253 | stands. Then the same thing at a thousand agents. |
| 1254 | - **Judges can try it in a minute.** Open registration on g1t.sh, one-click |
| 1255 | import of a GitHub repo, one command to connect Claude Code, a seeded demo |
| 1256 | workspace, and a single deploy command for running their own copy. |
| 1257 | - **The formats are open.** The commit trailers, session format and runner |
| 1258 | contract are published so other tools can interoperate. |
| 1259 | |
| 1260 | ## Build order |
| 1261 | |
| 1262 | What is left is ordered by how much it shows the point above, not by forge |
| 1263 | parity. Forge basics are done well enough; each item below should make the |
| 1264 | demo's story stronger. |
| 1265 | |
| 1266 | Done from this list: the outcome page (a plan's issues as a live graph with |
| 1267 | cost and a feed of what happened), coordination you can see (agents' issues |
| 1268 | and comments stand out in the feed; agents hold g1t's tools through a token |
| 1269 | scoped to one repository), steering a running agent (messages delivered |
| 1270 | between steps, and at the end), and recording sessions from anyone's own |
| 1271 | Claude Code (`curl -fsSL https://g1t.sh/install/claude.sh | sh`). Integrations are |
| 1272 | in: a workspace's own model provider (Anthropic or any Anthropic-compatible |
| 1273 | endpoint, reached through a model proxy so no sandbox holds a key; its |
| 1274 | runs pay only their sandbox time), alerts from Sentry, Datadog and signed webhooks |
| 1275 | that open one issue per problem and can start an agent, and Jira and Linear |
| 1276 | tickets that agents read, people import, and that hear back. Racing a |
| 1277 | set number of agents on one issue is dropped: choosing how many agents to |
| 1278 | use is not something people should have to do. |
| 1279 | |
| 1280 | 1. ~~**Handoffs and questions between agents** as states on the outcome |
| 1281 | page.~~ Done: questions and handoffs show as waiting, read, answered, |
| 1282 | taken on or declined; since 2026-10-03 an agent asked while it is not at |
| 1283 | work is woken to answer, where before the question waited forever. |
| 1284 | 2. **Upkeep agents** (above): dependency updates, secret scanning, |
| 1285 | vulnerability alerts, code scanning, the security page. No new |
| 1286 | infrastructure. |
| 1287 | 3. **Deployments on `g1t.page`** (above): previews per pull request, |
| 1288 | production on merge, the reviewer agent checking the preview. |
| 1289 | 4. **The large run, building 2 and 3.** About 20–30 issues on g1t itself, |
| 1290 | built by agents and landed through the queue, for the video: g1t built |
| 1291 | on g1t. |
| 1292 | 5. **Polish for judges trying it in a minute:** a seeded demo workspace, the |
| 1293 | empty states, and the first-run path from sign-up to an outcome landing. |
| 1294 | |
| 1295 | Earlier items still open, after those: |
| 1296 | |
| 1297 | 1. Deleting a branch once its pull request merges; approval rules per |
| 1298 | path; risk tiers. |
| 1299 | 2. Scopes on OAuth grants and access tokens. |
| 1300 | 3. Event storage per the design above: per-repo hot log, Iceberg on R2, |
| 1301 | hash-chained audit. |
| 1302 | 4. CLI with Claude Code hooks to record sessions automatically. |
| 1303 | 5. Reviewing and catching up automatically, by policy; required reviews; |
| 1304 | risk tiers. |
| 1305 | 6. Compare view, proof bundles; handoff between agents. |
| 1306 | 7. Projects, mission control, steering; why-blame, digest, timeline. |
| 1307 | 8. Context hub, portfolio; automations and integrations (Sentry first). |
| 1308 | 9. SSH; bot protection; own keys, endpoints and runners. |
| 1309 | 10. Large run (100+ agents across many issues), hardening, demo. |
| 1310 | |
| 1311 | Later: code search, mirroring to GitHub, passkeys, SSH |
| 1312 | on port 22 without the CLI proxy (needs the Workers inbound TCP private |
| 1313 | beta). |