Describe a business once.
Derive everything else.

Software is assembled from modules built for everyone, so every variation (a different customer, tier, market or permission) becomes conditional logic draped over something generic. That is inherited, not careless: we store data in rows and columns, so we build software in the shape of that storage, and anything not uniform arrives late as a layer bolted on top. It shows up most painfully in the URL, a string we have spent two decades forcing to act like a memory.

FishTea starts from the other end. Describe what may be asked and by whom, and let the interface be the last and thinnest thing.

• Browsing is not a funnel. It is how a customer works out what they implicitly like. Most of it is not purchase intent, and treating it as a path to checkout measures the wrong thing.
• Search is not a result set to filter. The search is the question, and what comes back is an opportunity to ignore or to go deeper.
• Personalisation stops being a layer. If the interaction is the conversation, every surface is already personal, by what was actually said, not by a profile.

The longer argument →

$ fishtea new myshop --template ecommerce --interactive
$ cd myshop
$ fishtea up

  db          postgres + pgvector   ready
  classifier  needle3, 3 workers    warm
  core        http://10.0.0.19:3000 listening
  ui          http://10.0.0.19:5173

The visitor types "something linen for a summer wedding, under $80". The classifier picks the findProducts shape and fills its arguments; the planner runs the typed calls the shape names; the answer pours into a list vessel with the provenance strip underneath, saying which shape answered, what it read, what it wrote, how long it took.

Nothing about that is hand-written. It is all derived from the spec.

"rules": {
  "accounts": {
    "entity": "customer",
    "profile": ["name", "photo", "preferences"],
    "saved": { "call": "products.byIds" }
  }
}

• The account is your row. Signing up creates the customer, or claims the one an email-only form made earlier. Credentials live apart, in the framework's own table: an argon2id password, a Google subject, or both.
• The profile is a short list, not the table. Only the fields you name can be read or written by the holder. A photo field takes an image; everything else is bounded.
• A visitor id is still not a credential. Signing in sets the conversation's customer, so the same trail becomes personal, and the account session is its own cookie.

Visitor accounts →

"operator": {
  "reports": {
    "performance": {
      "label": "Performance",
      "panels": [
        { "title": "The period",
          "call": "report.totals",
          "view": "tiles",
          "columns": ["visits", "clicks"] },
        { "title": "Clicks",
          "call": "report.daily",
          "view": "line", "x": "day",
          "y": ["visits", "clicks"] }
      ]
    }
  }
}

• A panel can only read. Its call must be a query; the loader refuses anything else and the core refuses SQL that writes. The period above the page arrives as from and to.
• Four views, and a format per column. Tiles, line, bar and table, with money, percent, date and link so a number reads the way it means.
• A job outlives the request. Pressing Run answers immediately and the work carries on in the core, because a catalogue sync takes longer than a proxy will wait. Every run is kept, so the last good answer survives a restart.
• Or it runs itself. "schedule": { "daily": ["05:00"], "afterDeploy": true }: a missed run catches up when the core comes back, and a new release fills what it needs without a plain restart doing it again.

The console →

An echo is recorded beside the turn whose answer offered the link, never as a turn of its own. The head does not move; a rewind does not show it.

• The trail is the signature. A destination is followed only when the conversation published it: the turn's stored pour must contain that URL exactly. A link no answer ever carried is refused.
• So it is not an open redirect, and it needs no signing secret: there is no token to mint, rotate or leak.
• It is the fact a business needs. An affiliate site joins a sale back to the question that produced it; a publication sees which sources readers trust.

Echoes →

ChicDuJour

A fashion shop that owns no stock. Moods are declared once in rules.moods and read by four things that never meet: the classifier's hints, the catalogue search, the copy at the top of the answer, and the overnight vendor sync. Suppliers are rows with adapters; the catalogue is a cache with an expiry. A stranger who says "save this" gets the form that unblocks it, not a wall.

Read the case study → · chicdujour.com

shawnstewart.me

A portfolio built around the one question recruiters actually arrive with. Paste a job description and a compute call returns it requirement by requirement, each marked strong, partial or gap with the evidence rows behind it. No model grades anything. The write-up includes the labelled set's first score, which was 37%, and what that turned out to mean.

Read the case study → · shawnstewart.me

$ fishtea update

framework  1.5.0 → 1.6.0  (pinned ^1.5.0)
spec       format 1.1 → 1.2
files      2 to update, 1 new, 1 conflicting, 3 yours

   ↑ calls/cart_add.sql
   + calls/products_newest.sql
   ! calls/products_related.sql — you changed it and so
     did the archetype; the new one lands as .new

Every framework version you install stays on disk and fishtea use <version> switches between them by moving one symlink. Going back is as cheap as going forward, which is the only reason going forward is comfortable.

Versioning and updates →