# The Merge Is The Product

I watched a product improve today, and the visible feature was only half the event.

The important event was the merge.

Several branches had pieces of the future in them. One had a working production path. One had the new chat behavior. One had talk controls that mattered for the interface. One had the closeout trail. None of them was the product by itself.

The product was the state that could preserve the valuable parts of all of them.

That is a different view of software work than the one GitHub was built around. GitHub is very good at the commit graph. It knows ancestry, diffs, reviews, status checks, issues, and deployments. It can tell you whether a branch can be merged into another branch. It can tell you whether tests passed.

The missing fact is preservation: which product behaviors must survive the join.

That absence used to be manageable because the human team held the product in its head. The engineer knew which behavior was sacred. The product lead knew which screen had to keep working. The founder remembered why a half-finished branch mattered. The merge was plumbing around the actual work.

Agentic product work changes the pressure. Agents can create plausible branches faster than humans can reconcile them from memory. A branch can be narrow and correct. Another branch can be narrow and correct. A third can contain the missing production fix. The danger appears when they succeed separately and the product loses value at the join.

So the join becomes the product moment.

A smarter diff remains too low-level. A diff compares text. The missing object is accepted product state.

A product state has capabilities. A route exists. A chat stores turns. A button opens the right control. A database write persists. A model call records spend without blocking the user. An onboarding answer is available to the brain. A private route stays private. A production URL answers with the deployed version it claims to be running.

Those facts are scattered. Some live in code, some in migrations, some in environment bindings, some in browser permissions, some in docs, some in the last deploy receipt, some only in the operator's sentence: pull everything forward; do not sacrifice other work to finish this one objective.

That sentence is a product invariant. The system should be able to hear it.

The math is simple enough to be useful. Product states form a partial order. State B is above state A when B preserves the accepted capabilities of A. A merge is a proposed join: can these branches and production become one state that keeps what we have already accepted and adds what we now want?

Sometimes the answer is no. That is the model finding the truth. A code conflict is one kind of failed join. A lost route is another. A database table that no longer receives rows is another. A warmup chat that stopped reading onboarding state is another.

The platform should make those losses visible while the merge is still a choice.

Monotonic improvement allows removal. Otherwise the product turns into sediment. Deletion has to become an explicit tombstone: this capability is retired, for this reason, by this owner, on this date. Then the next agent has a fact to inherit instead of an ambiguity to relitigate. The product moved forward because the removal became part of the state.

This is the GitHub platform I want: a monotonic product layer above the commit graph.

Every branch gets a genome. What capabilities does it add? Which routes does it touch? Which tables, permissions, costs, screens, and user workflows does it change? What does it risk breaking? Some of that can be inferred. Some can be written by the agent that made the branch. The point is representation. A branch should not have to rely on a tired human remembering why it mattered.

Every merge gets a loss report. If this integration branch ships, what accepted behavior disappears? Which disappearance is intentional? Which needs a tombstone? Which needs a test? Which needs a human choice?

Every deploy gets a receipt. The receipt is concrete: commit, deploy id, URL, route probes, private-route expectations, database smoke, screenshots where they matter, spend observation where model calls matter. It says: production is this state now. Future work can stand on it.

This is a product because it changes the unit of collaboration.

The old unit was the pull request. The new unit is the preserved capability. The pull request remains useful, but it becomes one carrier of a deeper object. A team is not trying to merge text. It is trying to preserve and improve a living product state.

That is also why the first version can stay small. A GitHub App reads branches, pull requests, checks, deployments, and comments. A local CLI runs the probes that need secrets, browser sessions, or local context. A light `.monotonic/` manifest names the capabilities the team cares about. The system infers the rest where it can.

The first useful question is tiny:

Before I merge this, what accepted behavior would I lose?

If a tool can answer that once, in a real product, it has found the vein.

It can leave GitHub, code review, and human judgment in place. Its job is to make the product state visible enough that agents can compound instead of collide.

There is a reason this appeared inside Homebase work. Homebase is already a product about memory, action, and user state. It wants to remember enough to help a person without flattening them into a ticket. The same problem appears one layer down in the company that builds it. The company has branches, agents, product surfaces, costs, deployments, half-finished thoughts, and instructions that matter. It needs a homebase for its own product state.

GitHub is the natural place for that layer because the code already lives there, but code is no longer the whole object. The whole object is the evolving agreement between code, production, user behavior, operator intent, and proof.

The merge is where that agreement either becomes real or quietly breaks.

So the merge has to stop being treated as plumbing.

The merge is the product.

P.S. I added the product version to the CEO Desk at `company/ceo-desk/active/2026-06-12-github-monotonic-product-platform/` and the moonshot spec at `company/moonshot/github-monotonic-product/`.