Skip to main content

render

Function render 

Source
pub fn render(s: &SchemaBrief, reach: &str) -> String
Expand description

A memory store’s brief: the schema, then one worked call per question kind, then reach.

reach is one line naming how to reach the graph from this session, which only the caller knows — a tool name on the MCP arm, a command on the CLI arm. It is fitted first and appended last, so everything above it gives way to it rather than the other way round. It is therefore the one part exempt from the budget. A store with no nodes and no edges gets EMPTY_BRIEF and no reach line at all.

The order is the argument. A session that has just been handed the association surface and an unfamiliar store asks two questions before its own — what is in here and how do I ask — and the first association run showed it answering both by probing Cypher, one guess at a time. So the labels and the edge types come first, complete enough to write a query against, and the worked calls come last, where a reader who skimmed the schema still lands on them.

The calls come off last, and only when nothing else is left. When the budget is short, entries drop from the listings above — edge types first, then labels, since a label with no edge type is still a thing to query and an edge type with no labels is not — and the cut is counted in the same … and N more every other digest uses. Dropping a recipe first would save a line and cost the session the round trip the whole section exists to remove.

§The cap is hard

Dropping lines alone is not a ceiling: a store whose names are themselves hundreds of bytes long spends the budget inside the lines that remain — a schema of 250-character edge types rendered 5,986 bytes against a 4,000 byte cap, because the loop stopped when it ran out of lines rather than when it fit. So three measures run in order, each only when the one before it was not enough:

  1. the listings render whole, which is what every ordinary store gets;
  2. every name is cut to [BRIEF_NAME_CAP] characters, and entries then drop from the listings against the shorter lines, counted;
  3. the worked calls come off from the end, and the brief says so on a final (brief truncated at 4,000 bytes) line.

A brief whose header, history and roles alone overrun the budget — nothing left to drop — is cut on whole lines by [cap_bytes], so the returned string is never longer than the budget whatever the store holds.