Decisions
27 decisions described. A decision is a choice made for the project, with its context, its options and what it affects.
| Decision | Date | First line | Links |
|---|---|---|---|
| Single extraction path | 2026-09-13 | The text of an office document comes from the PDF the converter produced, never from the document's own format. A reader still opens the original file, for its native properties, but the words that enter the search index, the recognition and the comparison of twin resources are read from the PDF, page by page, with one PDF library; a PDF given as a source goes through the same reading, and a transcript, which no converter touches, gives its cues. | 21 |
| Slots, islands and layers | 2026-09-13 | The site is a set of named slots rendered at build by components, each with a typed view model that is the contract between the generator and a theme; the published HTML carries the full content of every page. Only interactive components are hydrated: an island is served as its static markup inside an element carrying its props, and one small bundle per island, named after a hash of its content, mounts the same component on it, loaded only by the pages that use it, so that a page loads no framework code unless one of its islands needs it. Every such bundle is a classic script, never a module: some browsers refuse a module script on a page opened from the disk, and the site promises to work there; only the document viewer, imported on demand by its island, is a module. Styling is native CSS in four cascade layers, tokens, base, components and project, the project's stylesheet winning every cascade by construction. Without JavaScript the content stays reachable: mentions in native disclosure elements, the search field a plain form, the mode switch hidden. A budget of 150 kB per page is measured on every build. | 23 |
| Standard markdown only | 2026-09-12 | Concordance reads CommonMark, GFM and optional YAML frontmatter, nothing else. No wikilink, no proprietary tag, no directive: every file stays readable without the tool, and structured information goes through frontmatter, headings and lists. | 9 |
| Static first | 2026-09-12 | The build is a pipeline command that produces a static site. The main content of every page is in the served HTML, the site works over file://, and fragments load on demand from JSON files. An optional service will consume the same model later; nothing in the site depends on it. | 10 |
| Type-driven neighbour order | 2026-09-13 | The neighbourhood panel of a page lists neighbour types in a priority order declared per type in the profile: operations first on an API, accessed objects on a screen, what it applies to on a rule. Every displayed neighbour carries the rank of its type; unlisted types and keyword pages share the last rank, confidence decides within a group, and the panel is truncated after this ordering. A type without a declaration keeps the order by decreasing confidence. The order is profile data, never a condition in a template: the panel renders the list as received and separates the groups by rank alone. | 17 |
| Types as modules | 2026-09-13 | A type of the profile is a folder that carries everything the type needs: its declaration, its labels per interface language, its note template and, when the generic page is not enough, the components that render it. The core types are written that way and the default profile is assembled from them, so that the format the engine ships is the format a team extends it with: a project keeps its own modules in a folder its profile names, a plugin contributes modules through a contribution point of the plugin API, and the build merges them before the keys of the project profile, plugins first, refusing a module of a core type, which is extended through the profile, and two modules of one type. The site never learns a type slug: the entity page exposes the declaration of the type and every attribute of the note, declared and not, and a dedicated component for a type, an attribute or a mapped section is resolved by name, the project theme first, then the module, then the generic page, which remains correct when nothing specific is said. | 17 |
| White label by default | 2026-09-13 | The generated site carries the organisation's identity and nothing of the tool's. The name, logo, favicon, font families, corner radius, light and dark palettes, footer and additional stylesheet all come from theme.yaml, validated by the theme schema; a faulty key is reported by its path like a configuration error. The footer credits the tool only when the project asks for it (footer.credit: true, a plain link to the repository); by default nothing a reader sees names it. Font files are shipped by the project itself and bound with @font-face rules: the site emits no request to any other host. Light and dark modes follow the system preference, the reader can force one with the mode switch and the choice is remembered; without JavaScript the theme's default applies. The accent colour never carries information on its own: wherever the default theme uses it, an underline, an outline, a weight or a text carries the same meaning. | 27 |
7 decisions of 27 — pagination by twenty. The Links column counts the related pages, which brings the most central decisions of the journey to the top.