Documentation / @etherfold/core / SERVER_GENERATION_CAPS
Variable: SERVER_GENERATION_CAPS ​
constSERVER_GENERATION_CAPS:GenerationCaps
Defined in: packages/core/src/receivingContainer.ts:259
THE GENERATION CAPS THIS RUNTIME DEFAULTS TO, and the number is a decision rather than a placeholder.
A cap is a COUNT that REFUSES at the bound and never evicts, so the only cost of a generous one is disk and the only cost of a mean one is a refusal an operator has to act on. A server or a CLI should be far more generous than a browser tab (BROWSER_GENERATION_CAPS, two of each, because a tab keeps the previous generation only until the successor is promoted), because here the database IS the durable artifact and the retained generation is what the pointer moves BACK to.
Four generations is the ordinary lifecycle plus headroom: the incumbent, the successor being built beside it, the predecessor kept so the revert stays free after the promotion, and one spare so a routine upgrade never meets the bound as a surprise. Two streams, and deliberately NOT four: a generation is a re-fold of a stream that is already stored, while a STREAM is the expensive thing (the raw logs, fetched from a node that may not serve old ones at all), and the case that needs a second one is a filter change whose predecessor's stream is retained until its successor is promoted -- which is the browser's own reasoning, at the same number, for the same resource.
It is a DEFAULT and not a policy: a host states its own (ReceivingIndexerOptions.caps) and gets the refusal at its own bound.