Why Linear runs the project

What we track

Between September 29 and October 10 we filed 463 issues: 438 for the game and its engine, 13 for the asset studio and 12 for this website. The game’s issues sit under 25 milestones, one per release plus a few parking milestones for later work. Our Linear team shares issue numbers with the studio’s other projects, so the newest number is past 750.

In the same twelve days the game’s repository took 759 commits. Every one of the 744 that is not a release commit names the issue it belongs to.

Why it matters here

Almost all of our code is written by Claude Code sessions, and a session starts with no memory of the one before it. Some run overnight, some run in parallel on separate parts of the game, and a research pass may finish hours before anyone builds from it. Linear is where the work outlives the session.

Every session starts the same way. It reads the roadmap for the current milestone, then the open issues in Linear. When a document and Linear disagree about whether something is done, Linear wins.

That only works if an issue can be picked up cold. A vague issue makes a session rediscover what the last one knew: it rereads code, reruns measurements and guesses at intent, and that costs time and tokens before any work starts. So we write issues and milestones to be read later by someone who wasn’t there. An issue carries:

• what we saw, dated, and where it was seen;
• what exists today, with the earlier issue linked when there is one;
• what we want;
• how we’ll know it is done, usually as a test or a measurement.

Each milestone carries an exit criterion. An issue’s description is the spec written before the build, and we don’t rewrite it to match what shipped. The changelog records what shipped.

What that buys

• A fix that came back. The jet exhaust behind the ship tore and stuttered, and we fixed it on October 8. The next evening it was back. The new issue named the earlier fix and its commit, said nothing on that path had changed since, gave the frame rates from the play session, and marked the suspected cause as a hypothesis to confirm. The session that picked it up found the real cause and closed it about two hours after it was filed.
• A sound that needed a second pass. Settled rubble kept up a constant patter. A first issue thinned it and left a tool that logs every contact sound. Two days later a staccato was still there after big collapses. The new issue linked the first one, listed what it had already done, and its first step was to measure with that tool. The session started from a measurement it already knew how to take.
• A feature parked with its reasons. Smoke shadows left odd shapes on building faces, so we turned them off. The issue records the likely cause, four candidate fixes, what the pass costs per frame, and what “done” will look like. The game’s notes name the issue next to the switch that turns them off. Whoever picks it up later starts with all of that.
• Research handed between sessions. A research pass in the game’s repository wrote up how to make better ship models, and the asset studio’s session built from it the same night. The studio’s issue opened by pointing at that document and the exact section to work from, so it had nothing else to look up.

How it is enforced

Rules that rely on memory get forgotten, so the game’s repository checks them.

• Commits: a commit hook rejects any commit that doesn’t name its issue, either as completing it or as part of it. Release commits are the only exception.
• The end of a turn: a hook runs when a Claude Code session tries to end a turn. If a pushed commit completed an issue that hasn’t been confirmed Done in Linear, or a commit hasn’t been pushed, the session is handed the list and can’t stop until it deals with it.
• Releases: the release script refuses to tag a version while any issue fixed since the last release is still open.
• Dropped work: dropped work is canceled with a reason, never left open.

The hooks don’t query Linear themselves. They keep a record of which issues each session has confirmed as closed, and the session closes the issue in Linear through its Linear tools. The hooks make forgetting hard.

This website follows the same rules. Every change starts as an issue, a task folder keeps the working notes, and an issue’s status is a claim about the live site, so Done means deployed.

What it adds up to

Linear keeps the work designed. Decisions are written down when they are made. Ideas that aren’t for now are parked under a later milestone, so the scope of the current one stays fixed. Any session can pick up any piece of work where the last one left off.