Periscope

Every store has its own idea of types — SQLite has five storage classes, Postgres has dozens, SurrealDB its own. So before anything else Vantage needs a type layer that remembers what each value really is, rather than letting a string quietly turn into a number somewhere downstream. You declare it with a single macro:

vantage_type_system! {
    type_trait: KubeType,
    value_type: serde_json::Value,
    type_variants: [Null, Bool, Integer, Number, Quantity, Text, Time],
}

For Kubernetes it pays off at once: a Quantity knows that "16331752Ki" is sixteen gigabytes and "250m" a quarter of a CPU — real numbers you can sort and chart, not text.

This is the heart of it, and it's a clean bargain. You — or your agent — implement a single trait, TableSource: the one piece that knows how to talk to your backend. In return Vantage hands you everything layered on top, none of which you write — a typed Table<DB, Entity>, an ActiveRecord-style record you can load and edit, readable and writable data sets, CRUD, aggregates, ordering and pagination.

// You implement one trait — the only backend-specific code:
impl TableSource for KubernetesCluster { /* list, read, … */ }

// In return, every backend gets the same toolkit, for free:
//   Table<DB, Entity>  ·  ActiveEntitySet (ActiveRecord)  ·  ReadableDataSet
//   WritableDataSet  ·  aggregates  ·  ordering  ·  pagination

For Kubernetes the only backend-specific work is the read path: a small projector that flattens each nested object into a flat row and pulls out the fields people actually read.

// one pod's nested JSON → a flat, typed row
row.set("namespace", &pod.metadata.namespace);
row.set("node",      &pod.spec.node_name);
row.set("ready",     ready_ratio(&pod.status));    // "2/3"
row.set("restarts",  total_restarts(&pod.status)); // 7

That's all it takes for pods and nodes to behave exactly like database rows — the same Table and record API the rest of Vantage already speaks.

This step enables Vantage's relationship engine: you declare how records relate — with_one for a belongs-to, with_many for a has-many — and from there the UI picks them up on its own, turning every reference into a link you can follow, with no per-screen wiring.

Table::new("replicasets", cluster)
    .with_many("pods", "owner_uid", Pod::table);  // a ReplicaSet → the pods it owns

How much a relation can do depends on the backend. SQL is the most powerful: because the database evaluates them, relations there carry expressions and aggregation — a client's order_count, the sum of an order's lines — computed as correlated subqueries on read.

.with_many("orders", "client_id", Order::table)
.with_expression("order_count", |c| {
    c.get_subquery_as::<Order>("orders")?.get_count_query()
})

Simpler sources keep the relation, just not the cleverness. When a backend can't narrow results after a traversal, Vantage applies those conditions client-side, so the link still resolves to exactly the right rows. For a REST API the conditions are instead sent the way each endpoint expects — folded into the path or the query string.

For Kubernetes that means owner-reference ids and label selectors, matched against the list Vantage already holds — which is what lets a namespace open into its workloads, and a deployment reach down through its replicasets to its pods.

A table can be defined two ways in Vantage, and both are first-class: as a typed model in Rust, or declaratively in YAML with Rhai for the computed fields. Rust gives you compile-time types and the full expression API; YAML lets you add or reshape a table without recompiling — the next step is what makes that possible. For vantage-kubernetes the agent wrote the models in Rust, since the projection is code anyway — a few lines per resource kind:

Table::new("pods", cluster)
    .with_id_column("id")
    .with_column_of::<String>("namespace")
    .with_column_of::<String>("node_name")
    .with_column_of::<String>("ready")
    .with_many("metrics", "pod", PodMetrics::table);

A dozen of these later — pods through jobs, plus live metrics — the backend type is erased, so the same generic UI, CLI and API code runs over any model, Kubernetes or otherwise. The agent proved the seam by drilling a live cluster from a small CLI:

$ k8s-cli apps.deployment name=web :pods
web-8fc56b787-9hgtz   demo   Running   1/1
web-8fc56b787-cgmkf   demo   Running   1/1
web-8fc56b787-zgjcp   demo   Running   1/1
# → exactly the three pods it owns

Everything so far is perfect for Rust code — and invisible to everything else. Vista is the bridge: it wraps a typed table as a schema-bearing handle that the UI, scripts and agents read over a plain serialization boundary, and it can load straight from a YAML schema so nothing on the other side needs a Rust struct. It's the same doorway for every backend, and it's exactly what gives Vantage UI something to drive — the next two prompts build entirely on it.

One last touch the same Vista boundary unlocks: small expressions in Rhai, evaluated at runtime, so a computed column or a label can be written and changed in YAML without recompiling — a ready ratio here, an age there. The data source isn't just readable; it's scriptable.

- { name: ready, value: "${ record.ready }" }   # "2/3", via a Rhai helper