Explanation¶
Why keryx is built the way it is. These pages give reasoning, not instructions — the background you want when a behaviour surprises you, or when you are deciding whether keryx fits a job at all.
-
The authoring loop, reel workspaces, storyboards, themes, pluggable providers and the generation cache.
-
The deliberate absences, the unsupported combinations, and the things that look configurable but are not.
-
How the packages fit together, and the studio's internal architecture.
Why the reasoning lives here and not in a spec¶
keryx's design records — the numbered specs — are on the project wiki, and they are not documentation. A spec is written once and is true of the moment it was written; it answers "what did we decide in March" rather than "why does the tool behave like this".
So a documentation page that justified itself by citing a spec number was, in practice, not explaining anything: the reader could not follow the reference, and if they could, they would find a decision that may since have been superseded. The reasoning belongs in prose, on a page that changes when the code changes. Where you still see a bare spec number in these docs, treat it as a citation of provenance, not as somewhere to go and read the answer.