A point of sale, lifted out of the register that grew it

Phlo POS became a product layer of its own: a set of resources that customer apps mount, rather than a codebase each one forks.

It came out of a working horeca register. That app had grown the whole apparatus, tender flows, shift handling, cash counting, receipt building, an ESC/POS print chain, offline replay, and none of it was about that particular bar. The second customer would have meant copying it, and a copy is where two registers begin drifting apart.

So the layer is a directory an app points at:

"paths": {"resources": ["/srv/control/pos/", "/srv/clients/<name>/shared/"]}

What stays in the customer app is genuinely theirs: loyalty rules, the tender keys on the counter, the local print agent's hardware. What moved is everything else.

The layer is also the reason four engine resources exist. The numpad had three copies inside it before it became one resource outside it, with the on-screen keyboard alongside. The store came from drawing the same order on two screens at once. And the self-writing manual came from the recurring question of what exactly is running on this machine.

One principle from it is worth quoting whole, because it shaped the realtime layer too: realtime is comfort, never a requirement. A register that cannot reach the daemon keeps selling.

See the ecosystem for where the POS layer sits.