Koder Stack — Vocabulary

Canonical terms used in Stack documentation and in conversations about the Stack. When in doubt, prefer these words over informal synonyms — they carry precise meaning here.

For the directory structure these terms describe, see taxonomy.md.

---

Taxonomic levels

The monorepo is organized as a strict hierarchy with a single criterion at each level. The five levels above the repository root each have a canonical term:

Domain (L1)

The five top-level directories of the monorepo, each defined by the form of consumption of the components inside it: products/ (direct interaction), services/ (API call), engines/ (embedding), infra/ (operation), meta/ (reading). Every Sector belongs to exactly one Domain.

Area (L2)

A directory inside a Domain that groups Sectors sharing the same purpose or theme. The grouping criterion is local to each Domain (audience model in products/, functional domain in services/ and engines/, infrastructure function in infra/, artifact type in meta/). The L2 of products/ was renamed from suite/ to horizontal/ per RFC-007.

Sector (L3)

A unit of product or service identity within an Area: proper market name, independent lifecycle, and at least one distribution form. Customers contract a Sector — not a Domain or an Area. Examples: products/horizontal/kmail, services/foundation/id, engines/sdk/go, infra/data/kdb, meta/sites/stack.

Distribution form (L4)

The category of artifact through which a Sector is delivered to the consumer. Closed vocabulary across the entire monorepo:

• backend/ — server (HTTPgRPCWebSocket).
• app/{mobile, desktop, tv, web, cli, tui}/ — human-facing surfaces.
• engine/ — embeddable artifact (library, framework, SDK, runtime,

  binding); exclusive to Sectors in the engines/ Domain.

• landing/ — Sector marketing landing page.
• <brand>/ — B2B brand variant in an engine + product pair.

Language conventions (L5)

The idiomatic rules of the canonical language and framework chosen for each L4. Not directories — rules: file layout, naming, build tools, test patterns, error handling. Concrete conventions live as specs and policies under meta/docs/stack/.

---

Component-level concepts

componente

A component is any concrete, deployable element in the Koder Stack: an app, engine, service, daemon, gateway, desktop program, CLI, SDK, API server, runtime, or any web asset deployed to production (landing pages, documentation sites).

The defining trait: it has a deployed state that can be outdated, broken, or out of sync with the source. It is shipped, not just written.

Examples: products/horizontal/talk/backend, products/horizontal/pass, infra/net/jet, services/ai/gateway, engines/sdk/go, engines/lang/koda, infra/data/kdb, infra/observe/apm, any <sector>/landing/index.html.

documento

A document is any human-authored reference artifact: RFC, spec, backlog ticket, presentation slide deck, diagram, README, release note, design doc, KMD spec, or any other content whose primary purpose is to be *read and reasoned about*.

Landing pages are not documents — they are components (deployed web assets at L4 landing/ or meta/sites/<...>/).

Examples: meta/docs/stack/areas.md, any meta/docs/stack/rfcs/RFC-NNN.md, any .kmd spec file, any <sector>/backlog/NNN-*.md, this file.

módulo

A module is the broadest term: any Sector (L3) or any second-level subdirectory of the monorepo prior to migration. A module can be a component, a document collection, or a mix of both. Every module belongs to exactly one Area, which belongs to exactly one Domain.

The phrase "todos os módulos" means all Sectors across all Areas across all Domains.

artefato

A specific build output (.deb, .kpkg, .tar.gz, .apk, .AppImage, .msi). Not the source module itself; the artifact is what is shipped from the module.

alias

A alias is a compact/colloquial form of reference for a component, registered alongside the canonical slug in meta/docs/stack/registries/component-names.md. Examples: kflow for Koder Flow, kdrafts for Drafts, kterm for Koder Term.

Aliases capture how a component is spoken or typed in a terminal — not a mechanical k-prefix rule. They exist when the bare name is a common English word likely to cause ambiguity or PATH collision; they are absent when the bare name is already distinctive (Koda, Kortex, Kompass).

Each component has up to 3 aliases, each globally unique across the registry, each matching ^[a-z][a-z0-9]*$ (compact, no hyphens). The mechanism lives in meta/docs/stack/specs/naming/forms.kmd; the judgement of when to create an alias is in meta/docs/stack/policies/naming-aliases.kmd.

umbrella

A umbrella is a registry entry of type umbrella representing a Sector that groups 2+ deployable components but has no binary/CLI of its own. Example: Kdb is the umbrella for kdb-kv, kdb-ts, kdb-vec, kdb-search, kdb-stream — kdb is spoken/written but never executed.

Umbrellas have display without the Koder prefix (per forms.kmd R2.2) and default to aliases: []. They appear in the registry to give a name to the conceptual grouping that conversations and docs already use.

Kore (the engines backbone)

Kore (umbrella, slug kore, path engines/) names the whole reusable backbone of the Koder Stack — every engine (the technical sense below): the koda runtime + sibling lang engines (`engines/lang