RFCs

README

ai-RFC-001-generative-ui-via-kvg

apidocs-RFC-001-foundations

billing-RFC-001-foundations

Brand assets (logo, color, typography, icon, downloads, press, legal) live as subpages of the existing `brand.koder.dev` Jet vhost, which is the Area-9-of-9 hub of the Koder ecosystem ("How the ecosystem shows itself to the world. Marketing sites, brand assets, public documentation"). The Area-9 hero stays at `/`; the brand-assets pages land at `/logo/`, `/color/`, `/typography/`, `/icon/`, `/downloads/`, `/press/`, `/legal/`. Path C of three reconciliation paths considered; preserves the 9-Area URL symmetry, implements the textual promise of the Area-9 hub, zero migration. KDS at `kds.koder.dev` remains the dev reference.

brand-RFC-001-brand-site-architecture

cache-RFC-001-foundations

canvas-RFC-001-a2ui

classify-RFC-001-foundations

crdt-RFC-001-crdt-runtime

dataset-RFC-001-foundations

design-RFC-001-koder-design-system

design-RFC-002-responsiveness-sdk-extraction

design-RFC-003-facets-as-cross-cutting-tags

Evaluates 3 options for shipping a live, interactive component preview alongside the KDS site — Storybook proper, Ladle / Histoire (lighter alternatives), or a Koder-native HTMX-driven sandbox using the existing design-gen + templ pipeline. Recommendation: Koder-native v0; promote to external tooling later if breadth justifies.

design-RFC-004-component-preview-tooling

Evaluates 3 mechanisms for keeping a Koder Design Figma kit in lockstep with ratified Verge tokens (Tokens Studio plugin vs Specify CLI vs custom Figma plugin reading from `dist/tokens/tokens.json`). Recommendation: custom plugin v0 consuming the already-emitted `tokens.json` (per design-gen #059).

design-RFC-005-figma-kit-and-token-sync

Decides how koder_kit (Flutter / Dart) and koder_web_kit (JS) and future native consumers (Kotlin Android, Swift iOS, Rust embedded) receive the canonical Verge tokens. Evaluates copy-on-build vs publish-and-import. Recommendation: copy-on-build via CI workflow for v0; promote to a published koder_design_tokens package per language when consumer count crosses 3.

design-RFC-006-cross-language-token-distribution

Surveys whether Verge should evolve from its current FLAT token model (`bg`, `surface`, `text`, `accent`, `border`, `focus` declared directly per preset) to a 3-tier hierarchy modeled on Ant Design — **seed tokens** (small input set), **map tokens** (derived by algorithm: light / dark / compact), **alias tokens** (semantic names consumed by components). Owner sign-off required to ratify; this RFC LAYS OUT the three options and trade-offs without picking one.

design-RFC-007-token-hierarchy-seed-map-alias

Evaluated whether KDS should introduce a **Pro layer** above its primitive components — pre-bundled toolbars, saved views, density toggles, column visibility menus, export hooks — to spare every Koder admin tool (Forge, Kdrive admin, Hub publisher, …) from re-wiring the same boilerplate. **Ratified Option C (recipe doc only)** on 2026-05-23 — see `specs/patterns/admin-data-table.kmd`. Re-evaluation trigger documented in R5: when a third admin tool re-derives the same toolbar, re-open this RFC.

design-RFC-008-pro-opinionated-wrappers

Today `make gen` in `tools/design-gen` always full-renders the entire KDS site — ~480 pages × ~3 locales + tokens + OG images + JSON APIs + sitemap + llms.txt. Observed wall-clock: ~10m27s for 226 specs (2026-05-24 timing). Dev iteration cost grows linearly with the corpus. This RFC ratifies the **content-hash + manifest** incremental-build approach (Option A) before implementation begins, with the file-watcher dev mode (Option B) layered on top, and the Bazel-style dependency graph (Option C) deferred until KDS exceeds 1000 pages.

design-RFC-009-incremental-build

dns-RFC-001-koder-dns-platform

dns-RFC-002-phase1-first-pop-network

dns-RFC-003-phase2-hyperscale

embed-RFC-001-foundations

erp-RFC-000-architecture-overview

erp-RFC-001-licitacao-vertical-engine

erp-RFC-002-bpm-workflow-engine

erp-RFC-003-travel-expense-engine

erp-RFC-004-fiscal-brazilian-engine

erp-RFC-005-legal-vertical-engine

extract-RFC-001-foundations

gate-RFC-001-multi-channel-notifications

hub-RFC-001-delta-delivery

hub-RFC-002-federation-protocol

hub-RFC-003-build-attestation

hub-RFC-004-upgrade-chains

hub-RFC-005-migration-manifests

hub-RFC-006-unification-and-rename

Estender o Koder Hub pra hospedar pacotes `.deb` arm64-Bionic (formato Termux) expondo uma fachada `apt`-compatible em `hub.koder.dev/apt/`. Posicionar o KTermux (fork do termux-app — RFC adjacente) como cliente primário desse surface: `pkg install <slug>` resolve via Hub apt repo. `khub` CLI ganha resolver multi-formato (apk/deb/kpkg/...). Mantém-se `.kpkg` como envelope canônico Koder; `.deb` é export target conforme `specs/kpkg/format.kmd §1`.

hub-RFC-007-apt-deb-surface-and-termux-consumer

id-RFC-001-architecture-overview

id-RFC-002-data-model

id-RFC-003-authentication-service

id-RFC-004-oauth2-oidc-service

id-RFC-005-session-service

id-RFC-006-identity-service

id-RFC-007-admin-service-and-cli

id-RFC-008-api-gateway

id-RFC-009-migration-from-zitadel

id-RFC-010-cutover-runbook

id-RFC-011-storage-on-kdb-next

id-RFC-012-account-models

id-RFC-013-invite-chain

id-RFC-014-vault-service

id-RFC-014a-emergency-kit-recovery

id-app-RFC-001-stack-portal-consolidation

imaging-RFC-001-foundations

infra-RFC-001-koder-runtime-strategy

infra-RFC-002-self-hosted-runner-pool

kdb-RFC-001-kdb-next-hyperscale-architecture

kdb-RFC-002-opentelemetry-instrumentation

kdb-RFC-003-fingerprint-history

kdb-RFC-004-sql-planner-and-executor

kdb-RFC-005-catalog-adapter

kdb-RFC-006-explicit-er-modeling

kdb-RFC-007-timeseries-storage

kdb-RFC-008-multi-region-replication

kdb-RFC-009-active-active-multi-primary

kdb-RFC-010-wal-streaming-replication

kdb-RFC-011-standby-read-replicas

kicon-RFC-002-design-generation-pipeline

Architectural direction for layering a workspace abstraction over the single-user Koder Linux desktop, so a single installed system can host multiple isolated user contexts (work / personal / per-client) switchable from the kolide-shell panel — without falling back to the much heavier "second Linux user account + relogin" pattern. Each workspace owns its own per-user storage tree, Koder ID binding, apps catalogue, and kolide-shell settings. Apps stay multi-tenant by default (`policies/multi-tenant-by-default.kmd`) so this RFC is the desktop-side surface that finally makes the policy visible to the end user.

klinux-RFC-001-multi-tenant-desktop

Direction for OS-level updates on installed Koder Linux: how a running system discovers, downloads, applies, and (eventually) rolls back updates to its base system + the koder-suite packages that came from hook 0060. Today the only way to "update" a Koder Linux install is to re-flash the ISO or run `apt upgrade` per-package; this RFC defines the user-facing CLI (`koder-os-update`), the underlying transport, and the trade-offs between three candidate mechanisms (ostree, apt-only, delta packs). Recommended path: **apt-only over Koder Hub** for v0 (ships in weeks, reuses #012/#116/#117), with A/B partition / ostree evaluated for v1+ once #018's CLI is live.

klinux-RFC-002-os-update-mechanism

kodec-RFC-001-cine-workspace-architecture

kodec-RFC-002-phase3-decoders

koder-exec-kit-RFC-001-execution-backends

koder-pair-RFC-001-architecture

kompass-RFC-001-identity-and-org-unification

kortex-001-ecosystem-map

kortex-002-architecture

kortex-003-common-event-schema

kortex-004-common-control-plane

kortex-005-llm-provider-abstraction

kortex-006-auto-remediation-rules-engine

kortex-007-chatops-pipeline

kortex-015-browser-event-source

kpc-RFC-001-foundations

lang-RFC-017-compiler-decomposition

mcp-registry-RFC-001

memory-RFC-001-foundations

modelreg-RFC-001-foundations

monorepo-RFC-001-area-first-directory-structure

monorepo-RFC-002-directory-nomenclature

monorepo-RFC-003-l1-domain-taxonomy

monorepo-RFC-004-l2-area-definition

monorepo-RFC-005-l3-sector-definition

monorepo-RFC-006-l4-distribution-forms

monorepo-RFC-007-l2-audience-model-nomenclature

monorepo-RFC-008-l5-language-conventions

monorepo-RFC-009-meta-internal-split

monorepo-RFC-010-component-frameworks

nimbus-RFC-001-multi-cloud-management-platform

playground-RFC-001-foundations

policies-RFC-001-reuse-first-hierarchy

policies-RFC-002-self-hosted-first

policies-RFC-003-component-policies-hierarchy

policies-RFC-003-rfc-phase-pickup

prompt-RFC-001-foundations

sandbox-RFC-001-architecture

sandbox-RFC-001-foundations

scene3d-RFC-001-foundations

scheduler-RFC-001

search-RFC-001-engine-and-cli

search-RFC-001-foundations

signing-RFC-001-multi-jurisdiction

signs-RFC-001-architecture-overview

snapshots-RFC-001-architecture

stack-RFC-001-kdb-as-unified-data-plane

stack-RFC-002-mcp-integration

stack-RFC-003-koder-icons-shared-ui-library

stack-RFC-004-verge-scope-expansion

stack-RFC-005-full-headless-testability

synth-RFC-001-foundations

take-RFC-001-architecture-overview

talk-RFC-001-quic-transport

tools-RFC-001-foundations

trace-RFC-001-foundations

training-RFC-001-foundations

translate-RFC-001-foundations

tune-RFC-001-koder-tune-smarttv-app

video-RFC-001-foundations

vision-RFC-001-foundations

workflow-RFC-001-foundations