A customer taps Order on the kiosk, and that one button has to do four things: refuse the order when the mango has run out, write the order down, hand back a receipt now, and put the ticket on the kitchen screen before the customer turns away.

None of that is drawing a screen. Together it is the business service: the action a request asks for, the business rule behind it, the background job it starts, and the change other screens must be told about.

Every module splits that work across the same three files, and the split never changes. A request arrives at the API port and passes through them in order:

Each file answers one question, and only that one:

Let's follow two real actions from the counter through the three files:

The decision lives in the service. This is where the order meets a second module, inventory, and where both documents are loaded before either is saved:

The manager's half is the mirror image: the same three files, a different guard, and no state machine, because refilling today's inventory is allowed whenever an admin asks. Its signal appears in Bounding A Call below.

A model's signal file exports exactly three classes, and every module declares all three even when two of them are empty. Which one you reach for depends on one thing: who starts the call.

Start from the product behavior, not from the class list. Does the user need an answer now, a live conversation, a broadcast to many screens, or a job that finishes later?

Every endpoint takes an option object, and guards is only its first field. The rest say how the call behaves: how long it may take, whether its answer may be reused, whether agents see it.

Here is the manager's half of the shift:

Some work has no caller waiting for it. Nobody presses a button to make ice cream melt, and nobody asks for last night's orders to be closed. That work goes in the Internal class, and the server starts it itself:

Both are internal signals, and the batch replica, the server process that runs background jobs, is what runs them.

The same file also gains a pubsub room. It is an endpoint nobody calls, because the server is what publishes into it:

When an order moves to processing, the kitchen screen is already open, and nobody is going to press refresh. So the service publishes the saved order into the room named after its new status, and every screen subscribed to that status appends the ticket.

The service reaches its own signal through an injected field, then publishes right after the save:

A service never builds the things it needs. It lists them in the builder argument of serve(), and the container hands each one in before any handler runs.

That is what lets a payment provider, a cache backend or a whole sibling module be swapped without editing the business method that uses it.

An adaptor is the unit you plug. It is a class built on adapt(), and it registers itself under the name it is given.

It takes the same injectors as a service minus service and signal. So an adaptor can hold config, another adaptor and shared state, but not business logic:

Refusing an order because the mango ran out and refusing an order from a customer who is not signed in are not the same refusal, and they are not written in the same file. Each layer throws what only it can know:

A chain method is the smallest version of this. It validates, mutates, and returns this. It never saves, so chains compose and the caller decides when the write happens:

Best-effort code does not throw at all. It returns a plain value, and the caller decides whether that is an error:

There are no Result wrappers anywhere in the stack.

Every signal is also served to AI agents as an MCP server on POST /mcp, mounted by default. You write nothing extra in a signal file, and there is no per-endpoint switch to turn on.

Instead, exposure follows the guards. The guards are already the authorization decision, and a second switch would only guarantee that endpoints added later stay invisible until somebody remembers them.