flagon-io/g1t

public

Compare changes

Choose two branches to see what one has that the other does not, then open a pull request for it.

2 commits

README: run the core forge locally with Docker Compose; forks described as copies, not copy-on-write, until Cloudflare says otherwiseChase Pierce73aad901d ago
Demo script: a planned outcome running in parallel, the Code button and Branches, forks described as they are measured, and checks before recordingChase Pierce965fe741d ago

3 files+66−190/3 viewed

+16−1View BlameViewed

58	58		- Issues with labels and comments; a description can say what done means,
59	59		under a Definition of done.
60	60		- Pull requests with a diff and a recorded agent session: in a
61		−	copy-on-write fork, which is how agents work, or from a branch pushed to
	61	+	fork of their own, which is how agents work, or from a branch pushed to
62	62		the repository. Several can be made for one issue.
63	63		- Checks: the repository's workflows run on every pull request, a
64	64		person's or an agent's, and report a check each. The default branch
⋯
169	169
170	170		## Run your own
171	171
	172	+	### On your own machine
	173	+
	174	+	The core forge runs in Docker, with no Cloudflare account:
	175	+
	176	+	```sh
	177	+	docker compose -f deploy/self-host/docker-compose.yml up --build
	178	+	```
	179	+
	180	+	Then open http://localhost:8787 and sign up. The confirmation mail is in
	181	+	Mailpit at http://localhost:8025. Repositories, push and clone, issues and
	182	+	code browsing work; agents, deployments and search are off in this version.
	183	+	[docs/SELF_HOSTING.md](docs/SELF_HOSTING.md) says what works and what is next.
	184	+
	185	+	### On Cloudflare
	186	+
172	187		You need a Cloudflare account on the Workers Paid plan (Artifacts requires
173	188		it), Node 22.22 or newer (`engines` in `package.json`; g1t is built on
174	189		Node 24), Rust with the `wasm32-unknown-unknown` target, and

+2−2View BlameViewed

61	61		A pull request is a proposed change. There are two ways to make one.
62	62
63	63		In a fork. This is how agents work. Opening the pull request creates a
64		−	copy-on-write copy of the repository that belongs to that pull request
65		−	alone. Its author clones the fork, commits and pushes to it. Nothing they do
	64	+	copy of the repository that belongs to that pull request alone, ready in
	65	+	about the time a branch would be. Its author clones the fork, commits and pushes to it. Nothing they do
66	66		can touch `main` or another pull request. The fork lives at
67	67		`g1t.sh/pulls/<pull request id>.git` and is exactly as visible as the
68	68		repository it came from. The pull request starts as a draft.

+48−16View BlameViewed

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