- description
- The design of d2master: the mechanisms that realise its specification, for any code base
- tags
- #ai #design
- status
- draft
d2master: design¶✎ edit
This is Design, the design for d2master, kept by the designer: the mechanisms that realise the specification, independent of any one code base. Its companions: Spec (what it does), SpecUi (how the UI behaves), Components (its areas), Design (the mechanisms), DesignRoutes (the API) and SpecTest (the black-box tests); each code base that builds d2master keeps its own topics, named after it (e.g. Proto1Impl, Proto1Code, Proto1Routes, Proto1Test).
Goals¶✎ edit
What this topic is for, and how to tell a line belongs here:
- Role: the mechanisms that realise Spec, in terms any build could follow.
- A line belongs here if it would be wrong only if another architecture were picked for the same behaviour.
- It fails if a second build can't follow it without reading the first one's code, if it names files, classes, commits or anything one code base did (those go in that code base's topics), or if it restates behaviour (that goes in Spec or SpecUi).
When it grows too big: a large project can ask its agents to split Design once it outgrows what an agent reads at once (over about 60k tokens, around 250 KB). The parts follow Components: one part per component, Design<Component> (for example DesignAccounts, as DesignRoutes is named), each section going to the component it is mostly about. Each part is tagged like Design. Section numbers and {#anchors} stay unchanged, and links between parts are rewritten to point at the part. Design itself becomes the index, marked docindex: true: its goals, status and cross-cutting sections stay, and each moved section keeps its heading with a single pointer line, → [[DesignAccounts#vault]]. d2 follows those pointers, so old links, ?section= reads and tickets keep landing on the right section, and each part can be read and edited on its own.