Lanes

Zwei Engineers in einem Payments-Team in São Paulo hatten dieselbe Claude-Code-Session auf demselben Repo vierzig Minuten lang laufen, bevor einer von ihnen es bemerkte. Sie waren auf verschiedenen Branches, in verschiedenen Terminals, auf verschiedenen Etagen desselben Gebäudes. Als sie es bereinigten, waren drei der Agent-Commits überschrieben, zwei neue widersprachen sich, und der On-Call-Engineer war von einem Flaky-Test gepagt worden — der gar nicht flaky war, sondern von einem Modell umgeschrieben wurde, das keiner von beiden gebrieft hatte.

Genau diese Art von Kollision verhindert eine Lane. Wenn du von dieser Seite nur eine Sache mitnimmst: Eine Lane ist ein Zaun. Sie sagt dem Workspace, dem Agent und deinen Teammates, dass diese Arbeit, auf diesem Scope, mit dieser Permission-Menge von diesem Run gehört, bis er schließt. Zwei Lanes überlappen nie auf denselben Files. Zwei Agents laufen nie in derselben Lane.

Die These: Das meiste Chaos im agentischen Engineering ist nicht Modellqualität, sondern das Fehlen einer Primitive, die sagt „Das ist meins, lass es in Ruhe.” Lanes sind diese Primitive.

Was eine Lane wirklich ist

In Storage-Terms ist eine Lane eine Zeile in lanes mit einer UUID, einem Owner (menschliche oder Agent-Identity), einer Liste claimter Pfade, einem signierten Start-Eintrag im Provenance Ledger und einem Status — open, paused, merged oder abandoned. Du denkst normalerweise nicht über die Zeile nach. Du denkst über die Card im Lanes-Panel: Titel, Scope, Live-Diff und Sign-off-Slot unten.

In Runtime-Terms ist eine Lane eine Enforcement-Boundary. Wenn ein Agent in Lane A versucht, eine Datei außerhalb von As claimtem Scope zu lesen oder zu schreiben, gibt der Workspace einen LANE_SCOPE_DENIED-Error zurück, bevor das File System überhaupt angefasst wird. Der Agent sieht den Error in seinem Tool-Log und engt die Arbeit ein oder bittet den Lane-Owner, den Claim auszuweiten.

In Audit-Terms ist eine Lane ein in sich geschlossenes Kapitel im Provenance Ledger. Jeder Read, Write, Modell-Call, Command-Execution und Sign-off in der Lane kettet zurück zum Start-Eintrag der Lane. Wenn du Evidence für SOC 2 oder ein internes Post-Mortem exportierst, exportierst du Lanes, nicht Commits.

Warum das nicht einfach ein Branch ist

Der naheliegende Einwand: „Ich habe doch schon Git-Branches. Wofür brauche ich Lanes?”

Branches beantworten die Frage welche Files unterscheiden sich von main?. Sie beantworten nicht wer arbeitet daran?, welche Tools benutzen sie?, hat in der letzten Stunde jemand anderes dieselben Pfade angefasst? oder darf der Agent aus dieser Arbeit heraus die Produktions-Datenbank aufrufen?. Branches sind eine Snapshot-Primitive. Lanes sind eine Session-Primitive.

In der Praxis hast du oft ein 1:1-Mapping — eine Lane erzeugt einen Branch und merged in ein PR. Aber die Lane überlebt den Branch. Die Lane trägt die Modell-Logs, die Tool-Calls, den Sign-off und die Provenance, nachdem der Branch gelöscht ist. In sechs Monaten ist der Branch weg; die Lane ist weiterhin abfragbar.

Kryptografische Provenance

Jede Lane trägt eine Kette signierter Einträge — Ed25519-Signaturen über BLAKE3-Content-Hashes, in append-only-Reihenfolge. Der Chain-Head signiert den vorherigen Head, sodass das Manipulieren eines historischen Eintrags jeden folgenden Eintrag invalidiert. Das ist dieselbe Konstruktion, die Federation-Root-Signer für das Evidence-Bundle des Workspaces verwenden.

Drei Keys sind wichtig:

Key	Lebt in	Verwendet für
Lane signing key	Workspace HSM	Signieren von Tool-Call-Einträgen in der Lane
Owner attestation key	User Device	Signieren des Sign-off-Eintrags, der die Lane schließt
Federation root key	Nur Workspace-Owner	Stempeln des geschlossenen Chain-Heads in das Evidence Bundle

Du verwaltest keinen davon manuell für eine normale Lane. Sie tauchen auf, wenn du ein externes HSM integrierst (BYOK), Evidence für ein Audit exportierst oder ein Federation-Receipt von außerhalb des Workspaces verifizierst.

Scope-Claims und Konflikte

Ein Scope-Claim ist eine Liste von Glob-Patterns: apps/api/auth/**, infra/terraform/networking/*.tf, package.json. Wenn eine zweite Lane versucht, ein Pattern zu claimen, das sich mit einer offenen Lane überlappt, oberflächt der Workspace die Kollision in beiden Lane-UIs und weigert sich, die neue zu starten. Der Owner der neuen Lane sieht den Namen des bestehenden Owners und kann entweder warten, ihn um Freigabe der konfliktären Pfade bitten oder den Scope einengen.

Drei Ausnahmen, die du kennen solltest:

• Eine Lane kann freiwillig einen Pfad mit einer anderen Lane sharen per Share path. Wird selten gebraucht — meist für geteilte Config-Dateien, die zwei parallele Features beide anfassen. Sharen verwandelt den Pfad in eine serialisierte Resource: Agents holen sich einen Lock für die Dauer eines einzelnen Tool-Calls.
• Der Workspace-Owner kann einen Pfad von einer stehengebliebenen Lane force-claimen. Das loggt einen expliziten Sign-off-Eintrag, der den Override benennt.
• README.md, CHANGELOG.md und jeder Pfad, der von .sprintloop/shared-paths gematcht wird, sind immer geteilt. Jede Lane kann an sie anhängen.

Eine Lane erstellen

Drei Wege, in aufsteigender Automatisierung:

1. Manuell aus dem Lanes-Panel. Klicke New lane, tippe einen einzeiligen Titel, wähle das Repo, claime die Pfade, die du erwartest anzufassen, weise dich selbst oder einen Agent als Owner zu. Die Lane öffnet im Drafting-State ohne Einträge im Ledger.

2. Aus einem Issue. Wenn ein SprintLoop-Issue auf In progress verschoben wird, bietet der Workspace an, eine Lane gegen das verlinkte Repo zu spinnen, mit den Akzeptanzkriterien des Issues als Brief der Lane vorgeladen. Das ist der Weg, in den sich die meisten Teams in der ersten Woche einpendeln.

3. Aus einer Agent-Harness. Eine Claude-Code- oder Codex-Session, die in SprintLoop läuft, öffnet beim ersten File-Read ihre eigene Lane. Der Agent ist Owner; der Mensch, der die Session gestartet hat, ist die Sign-off-Authority. Die Lane wird auto-betitelt aus dem ersten Prompt und nach dem ersten Commit umbenannt.

Eine Lane schließen

Eine Lane schließt, wenn ihr Diff merged, wenn der Owner sie explizit aufgibt oder nach sieben Tagen Inaktivität (per Workspace konfigurierbar). Beim Schließen wird der Chain-Head des Lane-Ledgers vom Owner signiert und in den Federation-Root des Workspaces gestempelt. Das ist der Moment, in dem die Arbeit archivisch beweisbar wird: Jeder mit dem öffentlichen Verifikations-Key kann später prüfen, dass diese Änderungsmenge, in dieser Reihenfolge, von diesem Owner, mit diesen Tool-Calls, an diesem Commit-Hash endete.

Wenn du danach noch eine Seite liest, mach es Harness Racing — so wird eine einzelne Lane parallel an zwei oder mehr Agents dispatched.