RFC-006 — L4 Distribution Forms: how a Sector reaches the world

1. Summary

Define distribution form as the L4 level of the monorepo taxonomy: the category of artifact through which a Sector is delivered to the consumer. This is the first level with a closed, uniform vocabulary — every distribution form has the same name across all Sectors, all Areas, and all Domains, regardless of the Sector's nature.

This RFC also resolves two consequential problems:

1. The vocabulary collision between L2 meta/sites/ and L4 <sector>/site/,

   by renaming the L4 form to landing/.

2. The misleading meta/sites/ opacity, by introducing an explicit subfolder

   structure that names what each site represents.

2. Why a closed vocabulary at L4

Levels L1, L2, and L3 each apply a distinct criterion (consumption, theme, identity), but they let the terms vary by branch. L4 is different: every distribution form ties to a specific platform target, runtime, and packaging channel, all of which carry well-defined tooling, conventions, and CI pipelines.

A closed vocabulary at L4 is mandatory because:

1. Tooling depends on it. /k-parity, /k-test, /k-manifest, the SDK

   lints, and the CI matrix all key off the L4 folder name. Without a fixed set, every tool would need a discovery layer.

2. L5 hangs off it. The next level (RFC-007) is *language and framework

   conventions inside a distribution form* — Flutter conventions live inside app/mobile/ and app/desktop/; Go conventions live inside backend/ and app/cli/. Stable L4 names are a precondition for stable L5 rules.

3. It eliminates synonym drift. Without a closed set, app/android/,

   mobile/, app/flutter/ would all eventually appear in different Sectors meaning the same thing. The closed set forces every Sector to use the same name for the same artifact.

3. The closed vocabulary

3.1 The semantic structure of L4

The folders cluster into four buckets along the same consumption axis used at L1:

backend/                            ← consumed by API
app/{mobile,android,desktop,tv,web,cli,tui} ← consumed by direct human interaction
engine/                             ← consumed by embedding (engines/ Domain only)
landing/                            ← consumed by reading
<brand>/                            ← brand-packaged variant of any of the above

This is not a coincidence. The criterion at L1 (form of consumption) reappears at L4 as a decomposer of the Sector: a Sector is a coherent identity that can be consumed in multiple ways, and L4 enumerates those ways.

engine/ is exclusive to the engines/ Domain

The L4 form engine/ only appears inside Sectors of the engines/ Domain. This is a deliberate constraint that gives the name discriminative power: seeing engine/ anywhere in a path immediately signals that the path is inside the engines/ Domain.

Why singular vs plural matters:

engine/ (singular) is never used in products/horizontal/, products/dev/, services/, infra/, or meta/ Sectors. RFC-002 explicitly retired the generic engine/ folder in product/service Sectors (where it had been used for the consumer-side backend, now renamed backend/). The reintroduction of engine/ as the L4 form is contextually disjoint — inside the engines/ Domain and inside the vertical exception documented below — and therefore unambiguous.

Vertical exception (META-DOCS-133)

products/vertical/ Sectors MAY use engine/ as their primary L4 subdir when all three criteria hold:

1. The vertical is engine-shaped — a domain platform consumed by

   tenant-specific apps and APIs, not a pure end-user app.

2. The vertical's primary code surface is a backend daemon + CLI +

   embeddable libraries, conceptually distinct from any UI.

3. The vertical may later spawn app/{mobile,desktop,…}/ siblings;

   the engine/ subdir does not preclude that.

Rationale: vertical engines like products/vertical/edictus/engine/, products/vertical/clinic/engine/, products/vertical/iuris/engine/ deliver capability that consuming products embed; calling that subtree engine/ matches the conceptual role even when the vertical is shipped as a product (not as an embeddable library from engines/). 11 of 16 verticals follow this pattern (~69%); the exception formalizes observed reality rather than mandating a rename. The registry meta/docs/stack/registries/ticket-prefixes.md already codifies EDICTUS → products/vertical/edictus/engine as canonical.

products/horizontal/ and products/dev/ continue to use backend/ + app/ exclusively — those Sectors are user-facing, not engine-shaped, and don't qualify for the exception.

Why engine/ and not lib/: a Sector in engines/ may be a pure library (koder_ipc), a framework (koder_kit), an SDK (sdk/go), a runtime (lang/kode), a component library (koder_web_kit), or a binding (kodec/c). The umbrella term that covers all of them — and matches the L1 Domain name — is "engine" in the technical sense (RFC-002): a reusable algorithmic component, stateless, portable, embeddable. lib/ is too narrow.

3.2 app/ as the umbrella for human-facing artifacts

All distribution forms consumed by direct human interaction live under app/, distinguished by surface (mobile, desktop, TV, web, CLI, TUI). This makes `app