Koder Design — Data facet

bootstrap

Specs sobre como dados são modelados, nomeados, armazenados e configurados na Koder Stack: schema design, DB field naming, formatos de arquivos de configuração, parameter naming, env vars, isolamento multi-tenant.

Parte do Koder Design programme, facet Data. Ver rfcs/design-RFC-001 § Facets.

Specs do facet

Existentes (donas neste facet)

Spec Status Cobre
field-types.kmd done (2026-06-02) Catálogo de tipos primitivos + semânticos (BR) + storage canônico + JSON Schema map
masks.kmd done (2026-06-02) Máscaras de apresentação (CPFCNPJCEPtelefonedata/dinheiro); separação storage↔exibição
validation.kmd done (2026-06-02) Regras (requiredformatlengthcheck-digitcross-field); contrato de erro VL

Planejadas vs já-com-dono (NÃO criar autoridade concorrente)

A varredura de cardinalidade-de-donos (2026-06-02) mostrou que vários itens antes listados como "planejados" já têm dono canônico noutra spec/policy. Para esses, a regra de policies/content-location.kmd é referenciar o dono, não duplicar:

Item Dono canônico Ação
config-format specs/koder-toml/ Já-com-dono — referenciar, não criar
config-parameter-naming specs/koder-toml/ + specs/code/naming.kmd Já-com-dono — referenciar
env-vars policies/environments.kmd (env codes) + policies/security.kmd Já-com-dono — referenciar
field-naming specs/code/naming.kmd (snake_case, sufixos de unidade) Já-com-dono — referenciar
schema-conventions JSON Schema draft 2020-12 (rfcs/extract-RFC-001-foundations.kmd) Já-com-dono (linguagem) — field-types.kmd §R4 mapeia
migrations specs/migrations/ + rfcs/stack-RFC-001-kdb… Já-com-dono — referenciar
storage / object plane rfcs/stack-RFC-006-object-storage-plane-and-trust-tiering.kmd + specs/multi-tenancy/contract.kmd Já-com-dono — referenciar

Se um desses precisar de regra nova que o dono atual não cobre, a regra entra no dono, não numa spec concorrente aqui (evita o segundo-documento- com-autoridade que fratura o SSOT).

Specs existentes que pertencem conceitualmente ao facet Data

(via cross-link, sem mover os arquivos)

  • meta/docs/stack/specs/koder-toml/ — formato koder.toml (config

    canônica de módulo)

  • meta/docs/stack/specs/multi-tenancy/contract.kmd — koder_user_id

    + workspace_id em todo schema; isolamento RLSkey-prefixpath-prefix

  • meta/docs/stack/specs/identity/login-resolution.kmd — modelo de

    identity (também tem aspect Interface)

  • meta/docs/stack/specs/kpkg/, specs/kvg/, specs/kzip/,

    specs/kmd/ — formatos de arquivo Koder

  • meta/docs/stack/rfcs/stack-RFC-001-kdb-as-unified-data-plane.kmd

    — direção de storage backend

Cross-cutting

  • Multi-tenancy: policies/multi-tenant-by-default.kmd (cross-cutting

    rule que toda nova spec deste facet precisa respeitar)

  • Hyperscale: policies/hyperscale-first.kmd

Governance

policies/design-governance.kmd aplicada igualmente.