trieur.

Overview

trieur is two things that belong together but install separately:

  1. a gesture β€” a pile of cards, zones around it, one movement per card;
  2. a model β€” which learns, on every filing, where the next card will probably go.

The gesture without the model is pleasant manual sorting. The model without the gesture is a classifier with no interface. Together the loop closes: filing trains, and training shortens the next filing β€” until ↡ is enough.

Three packages

PackageRoleDependencies
@trieur/corethe stage, the zones, the gesture, the animationsnone
@trieur/learnfeatures, models, local storage, the protocolnone
@trieur/serverevents, replay, embeddingsBun + SQLite (from the runtime)

No bundler is required: these are ES modules, published as JavaScript with their type declarations. A <script type="module"> is enough.

The principles that explain the rest

The library knows nothing about your domain. No β€œbookmark”, no β€œfolder”, nothing of the sort in the code or in the CSS class names. It sorts opaque objects into opaque zones. What knows the subject lives in the host: renderCard draws, onSort performs, meta decides what the model is allowed to look at.

The host decides, and may refuse. onSort is asynchronous and may fail β€” a rejection puts the card back. The library never mutates anything outside its own pile.

The prediction never blocks the gesture. The card is already under the finger when a zone has to be suggested. The local model answers in microseconds; the server is only consulted when the local one stays silent, with a short deadline, and its silence prevents nothing.

Say nothing rather than guess. Too few examples, or no recognised feature, and predict() returns an empty list. A bad suggestion costs more than a missing one: it erodes trust in every suggestion that follows.

The weights are measured, not decreed. When several models vote, their weight comes from their observed accuracy, measured before learning. No magic coefficient anywhere in the code.

Where to start