About yen

The goal

yen is for complete fleets: many machines, many people, services that span hosts, environments with their own rules. Advanced and complex fleets, that a person can still read and understand.

yen also treats agents as first-class members of the team that runs the infrastructure. An agent reads the same queries as a person: the schema, the errors, why an aspect is active. It proposes a change as data, the fleet stages it, checks the rules across machines, and refuses it with the reason. Nothing reaches a machine unchecked.

For people

Four words: kinds, scopes, aspects, sinks. Plain Nix data. Every rule of how content moves is a sink you can read.

For agents

Every answer is JSON-safe data. Changes are staged, checked by invariants, and limited by grants. An MCP server answers.

Lineage

yen is the latest step of a line of projects, each one a lesson for the next.

flowchart LR
  vix["vic/vix: vic's machines"] --> den["denful/den"]
  den --> gen["sini's gen-* libs"]
  den --> exp["vic's experiments: denful/nest, ned, dnzl"]
  gen --> ren["vic/ren"]
  exp --> ren
  ren --> yen["vic/yen"]

Project	What it gave
vic/vix	a real fleet: vic’s machines, homes and dev environments. Today it runs on yen.
denful/den	aspects: configuration as features that land where they apply
sini’s gen-* libs	the libraries of Den’s next version (den-hoag on Gen): scopes, graphs, laws
denful/nest, ned, dnzl	vic’s experiments: Nest, CSS-like rules over a tree; Ned, inspired by Cycle.js
vic/ren	the fleet template that yen’s reference fleet models
vic/yen	queries instead of merges, Cycle.js sources and sinks, Nix builtins only

The reference fleet shows every capability of Den, den-hoag and clan, and the advanced patterns of real fleets (vix, sini’s and others), each with a check. Contributing says how to help.