The Reconciliation Client

What Was Built

Flow began with two intended web surfaces: one for the manufacturing coordinator and one for the operator reconciling the account. The operator client exposed Builds, a dense reconciliation grid, staged edits, proposal actions, and privileged account mechanics over a general JSON API.

It was not a sketch. It was implemented and browser-verified.

The first rendering architecture also required the grid to work without JavaScript while mounting a React interaction over it. Nine columns existed in two languages and two interaction models. The paths drifted: one handled a comparison-unavailable state and the other did not. A React panel scraped a server-rendered page through CSS selectors because neither path could stand alone. No outside user had requested the no-JavaScript guarantee, and the operator had not requested it either.

That first demolition removed 34 templates and both React islands, leaving one TypeScript client over one generated API contract. The reconciliation client survived the demolition. It was cleaner, singular, and still wrong.

What It Cost

The obvious cost was duplicate implementation and drift. The larger cost was conceptual: because reading the account existed only in the browser, every question about reconciliation became a question about screens.

At the time, Flow’s command line had nineteen commands. Every one wrote, validated, or administered. Not one read the account. The core package that loaded current truth and the package that translated stored values into human meaning were consumed by the browser, not by the Peer. The operator’s actual working partner was left grepping raw JSONL and reasoning over storage tokens while a polished client waited for the operator to open it.

The diagnosis behind the client had been correct: the operator could not keep a continuously changing account in working memory, and the durable record was not legible in a session. The build answered the wrong consumer. It made another surface for the operator when the Peer’s read path was missing.

What Killed It

Reality was unambiguous. The operator worked in long sessions with the Peer, inside the repository. That was where evidence arrived, reconciliation happened, changes were reviewed, and customer communication was authored. The operator did not use the web and had no reason to split the work between a browser and the mass.

The decision was not to keep the client as an awareness view. A boundary negotiated screen by screen is not a boundary, and an unused read-only view would remain a second read path waiting to drift. The reconciliation client was deleted entirely:

• its grid, Build views, session bar, entry bundle, and styles;
• the reconciliation API namespace and its six endpoints;
• proposal actions exposed through that namespace; and
• the role-selected shells and access gate that existed only to separate the two clients.

The capability did not die. Grid projection, typed operations, staged-session semantics, proposal review, and capture remained in the core. Governed flow read commands were built over the same current truth and presentation rules for the Peer. Deleting the cut recut access to the mass; it did not break off a smaller machine.

The Boundary Its Death Paid For

Coverage is measured by person and encounter, not by surface. Every person who needs a capability must reach it where that person actually works. Interfaces do not need symmetric catalogs, and a product-authored cut need not be the only route. The operator reaches reconciliation through the harness and Peer; outside evidence can return through the worksheet or an existing channel.

A missing read path is not evidence for a dashboard. Ask who lacks the capability before choosing its surface. In Flow, the Peer needed governed reads and the operator needed grounded answers. Neither needed an operator portal.

Structural absence beats an access rule. Once the client died, the routes and the gate guarding them died too. A gate that protects nothing is not harmless; a later builder reads it as intentional and quietly widens it. With one outside client, ledger mechanics cannot leak into an operator mode because no operator mode exists.

Deleting a facet must not strand the mass. Domain capability belongs behind the cut. If removing a surface removes the only implementation of a truth operation, the surface had an interior and was never disposable.

The Prohibition

Do not build a facet for the operator merely because a conventional product would have an admin application. First improve the harness, reads, tools, and presentation inside the mass. Cut an operator surface only after observed work shows that the operator is genuinely outside the capability they need.

This is not a general ban on visual tools. The corpse prevents a more specific failure: solving absence inside the mass by constructing another building at its edge.