Component Naming Forms

mandatory

Forms of reference for every Koder Stack component: type, display name, bare name, slug, path, and aliases array. Defines the regex per form, the prefix rule (Koder vs no-Koder), and global uniqueness. §7 binds each rendering surface (landing title/hero/navbar, app title bar, Hub card, CLI, URLs) to a concrete form, closing the bare-vs-display ambiguity. Registry lives at meta/docs/stack/registries/component-names.md and is CI-checked by `koder-spec-audit naming`.

Defines the forms of reference every component of the Koder Stack must declare. Each component has up to 6 forms: a structural type, a prosaic display name, a contextual bare name, a canonical slug, a filesystem path, and an optional array of aliases for compact/colloquial reference.

Applies to every entry in meta/docs/stack/registries/component-names.md.

1. The 6 forms

Form Example (Flow) Example (Koda) Example (Drafts) Example (Kdb umbrella) Where it's used
type service engine meta umbrella classification
display Koder Flow Koder Koda Drafts Kdb UI, marketing, prose docs
bare Flow Koda Drafts Kdb conversation where Koder context is implied
slug koder-flow koda drafts kdb repo, path segment, package id
path services/foundation/flow engines/lang/koda meta/context/drafts infra/data/kdb filesystem reference
aliases [kflow] [] [kdrafts] [] CLI binary, D-Bus tail, oral speech

The "Where it's used" column is a summary. The exhaustive, normative surface→form mapping (which surface uses display vs bare vs slug) lives in §7.

2. Rules

R1 — type is required (enum)

type ∈ { product, service, engine, meta, umbrella }
  • product — user-facing app/CLI (`products