flagon-io/g1t

public

Where people and agents ship software together. The open-source git platform for the whole job: issues, agents, checks and deploys to the edge.

g1t.sh

git agents cloudflare rust forge mcp

340 linesCode BlameRaw

Pick any line to see why it is the way it is: the commit, the pull request and issue it came from, and what the agent was thinking.

API: notifications over REST and MCP, with notifications scopes6d ago	1	# Contributing to g1t
	2
	3	g1t is built the way it asks others to build: issues and pull requests on
	4	[g1t.sh/flagon-io/g1t](https://g1t.sh/flagon-io/g1t), required checks that prove
	5	a change works, and a merge queue that keeps `main` passing.
	6
	7	## A change ships with its docs
	8
	9	Documentation is part of the product, held to the same bar as the code.
	10	A pull request that changes what someone can do, see or call changes the
	11	docs in the same pull request:
	12
	13	\| If you change \| Update \|
	14	\| --- \| --- \|
	15	\| Something a person does on g1t.sh \| The guide for it in `apps/docs/src/content/docs/guides/` \|
	16	\| An API route, a field, or an MCP tool \| `apps/api/src/operations.rs` descriptions (they feed the OpenAPI document and the API reference), the example and notes for it in `apps/api/src/reference.json`, `reference/mcp.md`, and any guide that shows the call. Then refresh the docs' copy of the OpenAPI document with `G1T_WRITE_OPENAPI=1 cargo test -p g1t-api openapi`; `cargo test` fails until you do. \|
Merge branch 'worktree-agent-ac950b9c891220ad3'yesterday	17	\| What coding agents are told about g1t \| `guides/bring-your-own-agent.mdx`, `guides/claude-code-plugin.md`, the plugin's skills in `plugins/claude-code/`, and `apps/web/public/llms.txt` \|
API: notifications over REST and MCP, with notifications scopes6d ago	18	\| Settings, limits or prices \| The page that names them, and the table it is in \|
	19	\| A new feature \| A section in the guide that owns it, linked from the docs home if it is a new task \|
architecture and suchyesterday	20	\| How g1t is put together: a service, a binding, a store, an event route, the path of a request \| Its page in the docs' Architecture section (`apps/docs/src/content/docs/architecture/`), and its diagram in `apps/docs/src/diagrams/architecture.ts`. [How g1t ships](https://docs.g1t.sh/architecture/shipping/#keeping-this-section-true) says which page covers what. \|
API: notifications over REST and MCP, with notifications scopes6d ago	21
	22	The style, in short: plain sentences, second person, no marketing words,
	23	sentence-case headings, a numbered list for steps, a table for options, and
	24	every API mention with its exact route or tool name. Examples are copyable
	25	and real. Nothing is documented that the code does not do.
	26
	27	Check the docs build before you push:
	28
	29	```sh
	30	cd apps/docs && npm run build
	31	```
	32
	33	## Icons
	34
	35	- Interface icons come from [Lucide](https://lucide.dev/icons). In the
	36	apps, import them from `lucide-react`. In the docs, use `@lucide/astro`:
	37	import an icon component, or give `apps/docs/src/components/Card.astro`
	38	and `Aside.astro` a Lucide name such as `icon="git-branch"`. Starlight's
	39	own `<Card>`, `<LinkCard>` and `<Aside>` draw Starlight's icon set, so the
	40	docs import the wrappers in `apps/docs/src/components/` instead.
	41	- Brand marks come from [Simple Icons](https://simpleicons.org)
	42	(`simple-icons`), and follow each brand's own usage guidelines. Add the
	43	dependency with the first one you show.
	44	- The g1t logo and illustrations are our own artwork, in
	45	`apps/web/app/components/logo.tsx` and `art.tsx`.
	46	- Never hand-copy an icon's SVG paths into a file. If Lucide lacks the
	47	icon you need, pick the closest one that it has.
	48
CONTRIBUTING says how the site's interface is built: from the shadcn components in apps/web/app/components/ui, themed with g1t's tokens, adding a missing one there first, changing looks through variants rather than one-off class strings, and looking at every changed page in both themes on a desktop and a phone.4d ago	49	## Interface components
	50
	51	- Build the site from the components in `apps/web/app/components/ui`,
	52	which are [shadcn/ui](https://ui.shadcn.com) components themed with
	53	g1t's tokens: buttons, cards, badges, tables, tabs, separators,
	54	breadcrumbs, menus, dialogs, sheets, tooltips, form controls.
	55	- If shadcn has a component you need and `ui` doesn't, add it there
	56	first, themed with the tokens, then use it. Don't rebuild it inline.
	57	- Change how something looks through the component's variants, not
	58	with a one-off class string at the call site. A long `className` on a
	59	`div` that draws a card, a pill or a button is a component that should
	60	exist.
	61	- Hover hints use the `Tooltip` component, never `title=`. Native
	62	`<select>`, file inputs, checkboxes and radios use their `ui`
	63	components.
Merge branch 'worktree-agent-ac950b9c891220ad3'yesterday	64	- Every avatar is `Avatar` (`ui/avatar.tsx`), and @g1t's is `Avatar`
	65	with `agent` set, or `AgentAvatar` (`components/agent-avatar.tsx`), which
	66	wraps it: g1t's pixel 1 with the agent marker in its corner, named
	67	"…, agent" to a screen reader. Never hand-draw a sparkle, a letter on a
	68	tile or the marker at a call site: a place that shows @g1t differently is
	69	a bug.
CONTRIBUTING says how the site's interface is built: from the shadcn components in apps/web/app/components/ui, themed with g1t's tokens, adding a missing one there first, changing looks through variants rather than one-off class strings, and looking at every changed page in both themes on a desktop and a phone.4d ago	70	- Look at every page you change, in light and dark, on a desktop and a
	71	phone, before calling it done.
	72
API: notifications over REST and MCP, with notifications scopes6d ago	73	## Before you push
	74
	75	- `cargo test` in the crate or service you changed.
	76	- `npx tsc -b --force` in `apps/web` (the incremental build misses changes
	77	in `packages/contracts`).
	78	- Look at what you changed in a browser. Screenshots catch what type
	79	checks do not.
	80
Merge remote-tracking branch 'origin/claude/cool-newton-7nm8r9'2d ago	81	## Checking g1t against GitHub
	82
	83	g1t runs GitHub Actions workflows as GitHub does. The Conformance
	84	workflow is how that is checked: `.g1t/workflows/conformance.yml` and
	85	`.github/workflows/conformance.yml` are the same file (a test in
	86	`crates/actions` fails when they differ), and each run's
	87	`conformance-report` artifact records what its jobs saw: which `GITHUB_*`
	88	and `RUNNER_*` variables were set and of what kind, every key of the
	89	contexts and the event and its type, how the workspace is laid out, and
	90	the values of outputs, files, caches, artifacts and expressions that
	91	should be the same everywhere. It reads no secrets and runs only by hand.
	92
	93	1. Run it on both, at the same commit: **Actions → Conformance → Run
	94	workflow** on GitHub and on g1t.sh.
	95	2. Download each run's `conformance-report` artifact, and name the two
	96	files `github.json` and `g1t.json`.
	97	3. Compare them:
	98
	99	```sh
	100	node scripts/conformance-diff.mjs github.json g1t.json
	101	```
	102
	103	It lists what GitHub has that g1t lacks or has otherwise, then what only
	104	g1t has, and exits 1 while there are differences. A difference is a bug in
	105	g1t, or belongs in [What g1t can't do yet](https://docs.g1t.sh/about/limitations/).
	106	Add a step and a `CHECK_` value to the workflow for anything new g1t
	107	should match.
	108
API: notifications over REST and MCP, with notifications scopes6d ago	109	## Deploying
	110
	111	Pushes to `main` deploy themselves: `.g1t/workflows/deploy.yml` runs
	112	`scripts/deploy.mjs`, which deploys only the parts that changed, migrations
	113	first. Every deployable part is listed in `deploy/stack.jsonc`; a new service
architecture and suchyesterday	114	or app goes there, in the table on
	115	[How a self-hosted g1t runs](https://docs.g1t.sh/guides/self-hosting-architecture/#each-part),
	116	and in the one on [Services and contracts](https://docs.g1t.sh/architecture/services/#every-unit)
The docs folder is gone, and what it held lives where people read it: how a self-hosted g1t runs and how to deploy g1t to Cloudflare are pages on docs.g1t.sh under Run g1t yourself, and speed, rate limits and operating g1t.sh are sections of CONTRIBUTING.md; code that cited a file in docs/ now points to the page or section that covers it, or says what it means itself, and applied migrations and the runner images are left as they were.4d ago	117	(`npm run test:deploy` says what is missing).
	118	[Deploy g1t to Cloudflare](https://docs.g1t.sh/guides/deploy-to-cloudflare/)
	119	covers the tool, the workflow, rollbacks, adding a unit and first-time
	120	setup.
	121
	122	- Migrations run before the code, so the old code reads the new schema
	123	for a minute or more. Add tables and columns; change what rows mean in
	124	two deploys (code that reads both forms first); never drop what live code
	125	still reads.
	126	- The self-hosted runner is released, not deployed: bump `version` in
	127	`crates/runner/Cargo.toml`, merge, and push a `runner-v<version>` tag.
	128	`.g1t/workflows/runner-release.yml` builds, signs and publishes it, and
	129	runners update themselves to it. `scripts/runner-release.mjs` does the
	130	same by hand.
Merge main into rm-agents: mirroring removal, open signups, free-tier limits, the g1t CLI and runner fixes, with the agent removal kept. The CLI's table of operations is regenerated from the API without the agent, customize and AI credit operations; no CLI command used them.2d ago	131	- The g1t CLI is released the same way: bump `version` in
	132	`crates/g1t/Cargo.toml`, merge, and push a `cli-v<version>` tag.
	133	`.g1t/workflows/cli-release.yml` builds it for every platform, signs
	134	the release with the runner's release key and publishes it to
	135	g1t.sh/downloads/cli/, where g1t.sh/install and g1t.sh/install.ps1
	136	find it. `scripts/cli-release.mjs` does the same by hand. The command
	137	reference in the docs is generated from the CLI
	138	(`G1T_WRITE_DOCS=1 cargo test -p g1t cli_reference`), and its table of
	139	API operations from the OpenAPI document
	140	(`G1T_WRITE_OPS=1 cargo test -p g1t ops_table`); tests fail when either
	141	falls behind. The guide is [The g1t CLI](https://docs.g1t.sh/guides/cli/).
preparing for cloud work3d ago	142	- The desktop app is released the same way: bump `version` in
	143	`apps/desktop/src-tauri/Cargo.toml`, merge, and push a
	144	`desktop-v<version>` tag. `.g1t/workflows/desktop-release.yml` builds
A desktop release goes out with what can be built. Linux is built on g1t's machines in every release; Windows and macOS each wait on a repository variable: a machine registered for them, or for Windows a cross build on Linux once aka.ms and download.visualstudio.microsoft.com are workflow-only domains, which is where the first release stopped. A platform with no machine is skipped and the download page says it is coming, with a word for the visitor whose platform this release lacks. The guide and CONTRIBUTING say so.3d ago	145	the installers (Linux on g1t's machines; Windows and macOS on machines
Merge branch 'main' into ask-integrationyesterday	146	registered for them, or Windows cross-built on Linux, each switched on
	147	by a repository variable the
A desktop release goes out with what can be built. Linux is built on g1t's machines in every release; Windows and macOS each wait on a repository variable: a machine registered for them, or for Windows a cross build on Linux once aka.ms and download.visualstudio.microsoft.com are workflow-only domains, which is where the first release stopped. A platform with no machine is skipped and the download page says it is coming, with a word for the visitor whose platform this release lacks. The guide and CONTRIBUTING say so.3d ago	148	workflow's header names; a platform with no machine is left out of that
	149	release), signs the updater's files and publishes them, and installed
	150	apps update themselves. `scripts/desktop-release.mjs` does the
preparing for cloud work3d ago	151	same by hand. The app loads the live site, so a change to the site needs
	152	no release; only a change under `apps/desktop` does. The guide is
	153	[The desktop app](https://docs.g1t.sh/guides/desktop/).
The phone app with your own g1t, on g1t.sh/download until Google Play, and Node 24 (#5)3d ago	154	- The phone app for Android is released on g1t.sh/download while it
	155	is not in Google Play (that waits on Flagon's D-U-N-S number): bump
	156	`version` in `apps/mobile/app.config.ts` when its native side changes,
	157	merge, and push a `mobile-v<version>` tag.
	158	`.g1t/workflows/mobile-release.yml` has EAS build the APK and publishes
	159	it; `scripts/mobile-release.mjs` does the same by hand. A change to the
	160	app's code alone needs no release: `eas update --channel preview` in
	161	`apps/mobile` reaches installed copies. Its server half (chat scopes,
	162	`/-/notify`, notify's phone push) deploys with the site and services.
	163	The guide is [The phone app](https://docs.g1t.sh/guides/mobile/).
The docs folder is gone, and what it held lives where people read it: how a self-hosted g1t runs and how to deploy g1t to Cloudflare are pages on docs.g1t.sh under Run g1t yourself, and speed, rate limits and operating g1t.sh are sections of CONTRIBUTING.md; code that cited a file in docs/ now points to the page or section that covers it, or says what it means itself, and applied migrations and the runner images are left as they were.4d ago	164
Merge branch 'worktree-agent-a63425cb2d4935c5f'yesterday	165	## How g1t's own CI caches
	166
	167	g1t's workflows cache with `actions/cache` against g1t's own cache
	168	([the Actions guide](https://docs.g1t.sh/guides/actions/#the-cache) has its
	169	rules). Three of them shape everything here: a run restores from its own
	170	ref, its pull request's base, then `main`, so a release tag never reads
	171	another tag's entries; a key is written once; and a repository holds
	172	10 GiB, past which the entries restored longest ago go. So:
	173
	174	- `main` saves; pull requests and tags restore. CI's Rust and desktop
	175	jobs keep their caches on each push to `main`, and the Caches workflow
	176	(`.g1t/workflows/caches.yml`) builds and saves what only releases use,
	177	when its key is missing. Release workflows only restore.
	178	- Rust caches are keyed by the toolchain and the dependencies, from
	179	`node scripts/deploy/ci-cache.mjs keys`: `rustc -V`, and a hash of the
	180	packages `Cargo.lock` takes from crates.io and git. A release bumping a
	181	workspace crate's version changes neither. A restore key never crosses
	182	toolchains.
	183	- **A Cargo target restored from an older entry is pruned before it is
	184	saved** (`ci-cache.mjs prune`), to what this build used.
	185	- A partial install never saves a whole-install key. npm's downloads
	186	and the crates are saved only by jobs that fetch all of them.
	187	- One set of paths per entry. An entry's version is the hash of its
	188	paths, so every step that names it, in every workflow, names the same
	189	ones. `crates/actions/tests/repository_workflows.rs` holds all of this.
Merge branch 'worktree-agent-a3b9b1f730f55b5bf'yesterday	190	- sccache only reads on a tag (`scripts/sccache.sh` sets
	191	`SCCACHE_GHA_RW_MODE=READ_ONLY` when `GITHUB_REF_TYPE` is `tag`): a
	192	release's run finds what `main`'s runs compiled, and saves nothing only
	193	its own tag could read.
	194	- Images a build runs in are pinned by digest. The CLI's release
	195	builds in `cargo-zigbuild` (`BUILDER` in `scripts/cli-release.mjs`), and
	196	its cache is keyed by that digest (`zigbuild` from `ci-cache.mjs keys`)
	197	rather than by this machine's `rustc`.
Merge branch 'worktree-agent-a63425cb2d4935c5f'yesterday	198
	199	\| Entry \| Key \| Saved by \| Restored by \|
	200	\| --- \| --- \| --- \| --- \|
	201	\| npm's downloads \| `npm-full-<os>-<package-lock.json>` \| Caches (`npm`) \| every npm install \|
	202	\| Crates and their index \| `cargo-crates-<os>-<deps>` \| CI Rust (`cargo fetch` of the whole lockfile) \| Deploy, the runner release \|
	203	\| The test build \| `cargo-test-<os>-<rust>-<deps>` \| CI Rust \| CI Rust on pull requests \|
	204	\| Workers' builds \| `cargo-workers-<os>-<rust>-<group>-<deps>` \| Deploy \| Deploy \|
	205	\| The runner's image build \| `runner-musl-<os>-<rust>-<deps>` \| Deploy \| Deploy \|
	206	\| worker-build and its tools \| `worker-build-…`, `worker-build-tools-…` \| Deploy \| Deploy \|
	207	\| Compiled crates \| sccache's, one per crate \| every Rust job \| every Rust job \|
	208	\| The desktop app's check \| `desktop-check-<os>-<rust>-<desktop deps>` \| CI desktop \| CI desktop on pull requests \|
	209	\| apt for Tauri \| `apt-tauri-<os>-<scripts/apt-install.sh>` \| CI desktop \| the desktop release \|
	210	\| The runner release \| `runner-release-<os>-<target>-<rust>-<deps>`, zig \| Caches (`runner`) \| the runner release \|
	211	\| The desktop release \| `desktop-release-linux-…`, `desktop-release-windows-…`, `xwin-…`, `apt-tauri-windows-…` \| Caches (`desktop-linux`, `desktop-windows`) \| the desktop release \|
Merge branch 'worktree-agent-a3b9b1f730f55b5bf'yesterday	212	\| The CLI release \| `cli-release-<os>-<zigbuild>-<deps>` (`target/zig`, every platform) \| Caches (`cli`), built whole \| the CLI release \|
Merge branch 'worktree-agent-a63425cb2d4935c5f'yesterday	213
	214	To see whether a change helped, read a run's cache steps: `Cache restored
	215	from key` names the entry (the key itself is a hit; another is a start),
	216	`Cache Size` and the step's time say what it cost, and the post step says
	217	whether it saved. `sccache's hits and misses` is on each Rust job's summary.
Merge branch 'worktree-agent-a3b9b1f730f55b5bf'yesterday	218	`g1t cache usage` says what the repository's entries hold against its
	219	10 GiB, and `g1t cache list --sort size-in-bytes` which take the most.
Merge branch 'worktree-agent-a63425cb2d4935c5f'yesterday	220
Merge branch 'worktree-agent-a56293a6f836cd343'yesterday	221	## Adding a machine size
	222
	223	g1t's hosted machines are one catalogue: `INSTANCE_TYPES` in
	224	`crates/contracts/src/actions.rs`, mirrored row for row in
	225	`packages/contracts/src/instances.ts`. Each row is a `runs-on` label, the
	226	machine it bills as (`machine`, such as `2-core`), the runner's Durable
	227	Object class that runs it (`class` / `sandboxClass`), the Cloudflare
	228	Containers instance type behind that class (`container`), its vCPUs,
	229	memory and disk, and its price a minute (`micros_per_minute`). The runner
	230	starts a job in its label's class, billing charges its minutes at its
	231	rate and reports them by machine, and the docs' tables follow it.
	232
	233	- A new label for an existing machine (another name for the standard
	234	one, say): a row with the new label and class and the machine's
	235	`machine`, size and rate; the class and its binding below.
	236	- A new size: a row with a new `machine` key and its rate. The rate is
	237	what a minute costs at Cloudflare's list prices with half the vCPUs
	238	busy, plus 20%, rounded up to a tenth of a cent, and never under its
	239	cost with every vCPU busy; `rates_cover_the_machine_at_full_cpu_and_its_usual_cost_plus_the_margin`
	240	checks it.
	241	- Pointing a label at another instance type: change its `container`
	242	and size (and `machine`, if it is a different machine now), and the
	243	class's `instance_type` in `services/runner/wrangler.jsonc`. A custom
	244	instance type works the same way, once the account may use them: add its
	245	size to the runner test's table of instance types.
	246	- Renaming a label: change `label`; keep `machine`, so its minutes stay
	247	on the same line of everyone's usage.
	248
	249	Never reuse a `machine` key for a different machine: past usage is
	250	reported under it. For a new class, add it to `services/runner/wrangler.jsonc`
	251	(`containers`, a `durable_objects` binding and a migration tag with
	252	`new_sqlite_classes`), export it from `services/runner/src/index.ts`
	253	(`export class SandboxXCore extends AttemptSandbox {}`), and give it a
	254	binding in `SANDBOX_BINDINGS` (`services/runner/src/egress.ts`). The tests
	255	that hold all of this together are `cargo test -p g1t-contracts instance`
	256	(the table, its rates and its TypeScript mirror) and the runner's
	257	`npm test` (every class in wrangler.jsonc, its instance type, size and
	258	binding against the catalogue). Then update the machine tables in
	259	`guides/actions.md`, `guides/usage-and-billing.md` and
	260	`architecture/compute.mdx`.
	261
The docs folder is gone, and what it held lives where people read it: how a self-hosted g1t runs and how to deploy g1t to Cloudflare are pages on docs.g1t.sh under Run g1t yourself, and speed, rate limits and operating g1t.sh are sections of CONTRIBUTING.md; code that cited a file in docs/ now points to the page or section that covers it, or says what it means itself, and applied migrations and the runner images are left as they were.4d ago	262	## Speed
	263
	264	Pages are a few rounds of service calls, and each round costs a trip to
	265	the databases, so start calls together and add no rounds.
	266
	267	- Every page answers with `Server-Timing`: each loader, each service's
	268	calls and their database time. Look at it in DevTools when a page feels
	269	slow.
	270	- `scripts/perf/measure.ps1` times pages from your machine (`-BrowserUA`
	271	for signed-out pages as a browser sees them). A page that only reads
	272	must not set the `g1t_d1` cookie: a new read-only service method goes in
	273	`READS` in `apps/web/app/lib/perf.ts`.
	274	- Targets from the US: signed-out pages under 200 ms to first byte,
	275	signed-in pages under 400 ms, streamed panels within a second.
	276	- Workers run without Smart Placement; `scripts/perf/placement-probe.mjs`
	277	measures a placement before you pin one.
A doc opens at once: the page carries the document's saved state, so the editor mounts without waiting for its live room, which connects in the background and sends only what changed, with a quiet dot that turns green when it's synced; edits made before then are kept and sent once. The editor's code is preloaded from the page and fetched early when you hover a doc, the app's shared code ships in a few chunks instead of a hundred small ones, socket tickets come with the page instead of a round trip, and the artifacts service answers a page, a sidebar and a room in parallel lookups instead of a dozen in a row, reporting its database round trips in Server-Timing. The artifacts guide says how a doc opens, and CONTRIBUTING's Speed section has the numbers.4d ago	278	- A TypeScript service reports its database time too (`db;dur`, from
	279	`openD1` in `@g1t/contracts`): the round trips a method makes are what
	280	it costs, so start them together (`Promise.all`), keep what never
	281	changes across requests in the isolate (the artifacts service keeps a
	282	workspace's slug for 30 s and whether its General space exists), and
	283	don't wake a Durable Object for a read D1 can answer.
	284	- Nothing live gates a page. A page carries what it shows (a doc's text
	285	and its saved document), opens its sockets as it hydrates rather than
	286	from inside the code they feed, keeps what is typed until they answer,
	287	and says so with a dot, never a spinner. A page opened with an access
	288	token gets its socket tickets with the page (the root loader mints the
	289	feed's, an artifact's loader its room's) rather than asking for each.
	290	- Code that only the browser runs (the doc editor) is still fetched with
	291	the page: `vite.config.ts` notes the chunk and what it imports for the
	292	route's `links`, and a link to such a page warms the chunk on hover.
	293	Modules several routes share are grouped by who shares them
	294	(`codeSplitting.groups`), so a page fetches tens of files, not a
	295	hundred and more. Before this, opening a doc fetched 124 files
	296	(1,049 KB) in three waves and the editor appeared at 2.8–3.3 s; a doc
	297	now fetches 71 files (1,026 KB) in one wave, and against the deployed
	298	services the editor appears at 2.1 s, of which the room's answer is
A doc saved before g1t kept documents with the page opens as fast as any other from its second open: the page asks its room for the document once, sends it with the page and keeps it on the row, instead of leaving the editor to wait for the room's first message. The artifacts guide says so, and CONTRIBUTING's Speed section has today's measurements on g1t.sh and what is still to cut.3d ago	299	0.65 s and the editor's own start 0.4 s. With the saved document in the
	300	page, measured on g1t.sh signed in (2026-10-10, warm, 1440×900), the
	301	editor appears at 1.5 s: first byte 0.53 s, scripts by 0.75 s, the
	302	editor's own start the rest. A doc without a saved document (one last
	303	saved before documents were kept) waited for its room's first message
	304	instead, 0.9 s after the socket opened, and appeared at 2.0–2.5 s; the
	305	page now asks the room once and keeps the answer, so only its first
	306	open pays. Still to cut: the live socket's four service calls before
	307	the room answers, the page and sidebar's 27 database round trips in two
	308	calls, the root loader's billing and identity calls (0.7–1.3 s and
	309	0.45 s inside), and the 3.4 MB of script a doc page decodes.
The docs folder is gone, and what it held lives where people read it: how a self-hosted g1t runs and how to deploy g1t to Cloudflare are pages on docs.g1t.sh under Run g1t yourself, and speed, rate limits and operating g1t.sh are sections of CONTRIBUTING.md; code that cited a file in docs/ now points to the page or section that covers it, or says what it means itself, and applied migrations and the runner images are left as they were.4d ago	310
	311	## Rate limits
	312
	313	`RATE_LIMITS` in `packages/contracts/src/rate-limits.ts` is the table of
	314	record, and the [rate limits page](https://docs.g1t.sh/reference/rate-limits/)
	315	is the public one: change both, and the binding in the Worker's
	316	`wrangler.jsonc`, together (`front-door-limits.test.ts` fails when they
	317	disagree). Limits fail open, keys hash anything secret, and each Worker
	318	takes its namespace ids from its own block of a hundred (41xx packages,
	319	42xx web, 43xx repos, 44xx api, 45xx og, 46xx status).
	320
	321	## Operating g1t.sh
	322
	323	For Flagon staff.
	324
	325	- Incidents are declared, updated and resolved in sudo, under
	326	Platform → Incidents, and appear on status.g1t.sh within 30 seconds.
	327	Declare as soon as people are affected, and pick the higher severity
	328	when unsure. SEV1 (down for most people, or data at risk) gets an update
	329	at least every 30 minutes and SEV2 (a core part broken for many) at least
	330	hourly; both email subscribers and need a blameless postmortem within
	331	five working days.
The artifacts service is services/artifacts, the Worker g1t-artifacts, bound as ARTIFACTS by the API, the site and the agents; its live rooms move to it with a Durable Object transfer from g1t-docs-service, and its database, bucket, indexes and queue keep their names. The git store's binding and settings are GITSTORE, its ops scripts gitstore-*, and workflow run artifacts keep their compatible API under run_artifacts modules. The deploy tool puts a Worker that has never deployed before the Workers in its stage that bind to it, and the deploy guide gives the cutover runbook.4d ago	332	- An Artifacts outage: `scripts/ops/gitstore-namespaces.mjs` shows a
The docs folder is gone, and what it held lives where people read it: how a self-hosted g1t runs and how to deploy g1t to Cloudflare are pages on docs.g1t.sh under Run g1t yourself, and speed, rate limits and operating g1t.sh are sections of CONTRIBUTING.md; code that cited a file in docs/ now points to the page or section that covers it, or says what it means itself, and applied migrations and the runner images are left as they were.4d ago	333	failing namespace. After 15 minutes, serve it read-only from the fallback
	334	git store (`scripts/ops/restore-to-gitstore.mjs restore`, then the repos
	335	Worker's secret `GIT_FALLBACK_NAMESPACES`) and open an incident. To
	336	switch back, `reconcile` anything the fallback took, then delete the
	337	secret. The script's header has every step.
Merge branch 'worktree-agent-ac950b9c891220ad3'yesterday	338	- Costs and margin, credits and the platform pause are
The docs folder is gone, and what it held lives where people read it: how a self-hosted g1t runs and how to deploy g1t to Cloudflare are pages on docs.g1t.sh under Run g1t yourself, and speed, rate limits and operating g1t.sh are sections of CONTRIBUTING.md; code that cited a file in docs/ now points to the page or section that covers it, or says what it means itself, and applied migrations and the runner images are left as they were.4d ago	339	in sudo, under Costs & margin. The code is in `services/billing/src`
	340	(`costs.rs`, `margin.rs`, `pricing.rs`, `budget.rs`, `platform.rs`).

This file's history is long; its oldest lines are credited to the oldest commit read.