The contract

The panel contract

A package says which of six kinds of panel it has and how urgent it is. That is the entire interface between a package and Laser — and it is short on purpose.

Why a contract at all

In a terminal the only surface is lines of text. So every package draws its own progress bar, invents its own prompt, and decides for itself what "done" looks like. Each of those decisions is reasonable alone. Put five of them in one window and you have five applications wearing a trench coat: five vocabularies, five layouts, five ideas about how loudly to ask for your attention.

The usual fix is a plugin API that lets each package draw whatever it wants inside a box. That fixes the borders and none of the noise. Laser does not pass presentation through at all. A package does not say how it looks. It says what it has.

The six kinds

Run
Work that is happening. Queued, running, paused, done.
Decision
Something is waiting on a person.
Stream
Output as it arrives.
Plan
Steps, and which one it is on.
Document
Something to read, or a diff to approve.
Collection
Many of something, countable.

Six is not an arbitrary number, and the list is not a taxonomy of features. It is a taxonomy of what a person needs to do with a thing on screen: wait for it, answer it, watch it, follow it, read it, or count it. A seventh kind would have to name a seventh relationship, and there is not one.

What Laser owns

Given a kind and an urgency, Laser decides where the panel lands, how big it gets, and what it looks like when it needs you. That division is the whole design: the package knows what is true, and the interface knows how to show it. Neither is good at the other's job.

It also means the six kinds are not six templates. A run and a decision earn more room than a document reference, and a decision that has been waiting for you gets louder than one that has not — without the package that raised it having any say in either.

Panels grow and shrink in place

When a panel changes, it is the same element changing. It does not disappear and get replaced by a new one that pops into the layout somewhere else.

This sounds like a detail of animation and is really a detail of attention. Anything that appears from nothing takes a person's eyes with it, so an interface built out of things popping in spends its user's attention on nothing at a steady rate. An element that grows where it already was keeps the reader's place — and leaves the interruption budget for the panel that genuinely needs it.

A package that has never heard of Laser

It still renders correctly. That is the test the contract is built to pass, and it is only passable because the contract asks for so little: a kind, and an urgency. Anything that can be described in those terms can be drawn properly, whether or not it was written with this in mind.

An interface that requires every package to adopt it is not a system. It is a negotiation, held once per package, forever.