# Work in progress belongs in the forge

Two agents. One function.

Agent A is rewriting login. In another session, agent B picks up a bug ticket and starts fixing a bug in login.

Neither knows about the other.

On a classic forge, this ends one of two ways. Both finish, open their pull requests, and the second one conflicts: a person spends the afternoon untangling two versions of the same function. Or the changes touch different lines, Git merges them cleanly, and the bug ships, because B fixed code that A had already replaced.

Git found the conflict at the end, or never. In both cases, too late.

On Logposa, B is warned the moment it touches login: A is working there. B can wait for A, or take in A’s work before going on: A shares it as a checkpoint, and it lands in B’s workspace, verified. B’s own edits are protected; if the two really collide, B gets an explicit conflict, not a silent overwrite. The conflict is handled while the work is being written, not after it is finished.

Git finds conflicts when you merge. Logposa finds them while the work is being written.

Forges were built for one kind of worker

Git hosting assumes one person, one laptop, and a commit when the work is done. Everything before the commit is private. Other people only see your work once it is finished.

That was fine when a team was a handful of people who talked to each other. It breaks when a large share of the work on your code is done by agents:

• many sessions run at the same time, on the same code;
• none of them knows what the others are doing;
• work changes hands midway: agent to agent, agent to person, person to agent;
• a process can stop at any moment.

The forge is the one place every session goes through. Today, it is also the one place that sees nothing until the end.

The forge sees the work, not just the result

Logposa makes work in progress visible to the forge.

It knows which agent is working where. Not just which file, but which function. When two agent sessions head for the same code, the one arriving second hears about it before it writes a line that will collide. Every warning, wait and merge is recorded, so the team can see afterwards how the work met.

It keeps work in progress where others can reach it. Between saving and publishing, Logposa adds a step: the checkpoint. Unfinished work, made durable and shared with the workspace. Whoever follows the workspace receives it, even from another machine. No “wip” commit needed.

It keeps Git’s history clean. The commit keeps its job: recording what the team decided to publish. Coordination and handoffs happen before it, not inside it.

What changes for your team

• Overlaps caught early. They are flagged while there is still time to choose, not at merge.
• No surprise meetings in production. Two changes to the same function are seen together while they are being written.
• Handoffs without “wip” commits. Share unfinished work as a checkpoint; whoever follows the workspace receives it.
• Nothing lost when a session dies. Work confirmed as saved survives the crash, and someone else can pick it up.
• A history people can read. Only what the team chose to publish.

Built to be trusted

A warning is only useful if it is right, and a checkpoint only if it is real.

Logposa confirms nothing until its contents are durable. Two concurrent changes never overwrite each other in silence: the second one gets an explicit conflict. We test it the hard way: a real agent writes a change, we kill its process outright, we restart it, and the change is intact. Every publication passes a full git fsck --strict.

And Git is still Git. git clone, git push, Git LFS: nothing new to learn.

A forge for humans and agents

A classic forge answers one question: what was published?

Logposa also answers the ones a team of humans and agents runs into all day: who is working where, where is the work, and who can pick it up?

Logposa is opening gradually. Sign in