Tribus (cooperative-work primitive): foundations
Status
proposed — aberta 2026-06-04 a partir da deliberação /k-arch que avaliou o escopo de identidade/colaboração de um produto Koder análogo ao Claude Cowork (o "coworker digital" agêntico da Anthropic). Nome Koder Tribus ratificado pelo owner 2026-06-04 (latim tribus = a tribo / divisão do povo; veia latina do Imago; distinto do SaaS "Tribe" e do termo interno "workspace"). Entrada no registries/component-names.md ainda pendente de PR (ticket #008).
Summary
Define o primitivo de trabalho cooperativo da Koder Stack: a tribe — um container compartilhável com membership/ACL própria, desacoplado do tenant-casa de cada membro — sobre o qual usuários compartilham e interagem com trabalho, tarefas e arquivos. O produto é Koder Tribus; cada container cooperativo que um usuário cria é uma *tribe*. Entregue como service de foundation (services/foundation/tribus, espelhando services/foundation/sync) e consumido por produtos (Drive, Board, Craft, KPC e um futuro produto user-facing). Quem entra numa tribe é resolvido por uma política de membership em camadas (T0T1T2), não por um tipo de conta fixo.
Por que "tribe" e não "cowork space": o termo workspace já é load-bearing na Stack (
id-RFC-012 §2: a orgconta B2B; `multi-tenancy contract.kmd: a fronteira de governançaworkspace_id`). Chamar o container de "cowork space" criaria colisão permanente com "workspace". tribe é distinto e quente — você cria tribes, convida pra sua tribe, tem tribe members.
Motivation
O comparativo (/k-evolve modo comparativo, 2026-06-04) mostrou que a categoria do Cowork está descoberta na Stack: KPC, Kode e Agents são todos single-user-isolados hoje. Não existe primitivo de cooperação humana cross-conta. E o valor do Cowork é cruzar fronteiras (analista↔analista, freelancer↔cliente, empresa↔empresa) — modelar como "feature dentro de uma org" (workspace-only) assa a suposição errada (anti-padrão D3/D12 da architecture-quality.kmd). A forma de raiz é um primitivo compartilhável próprio (a tribe) com membership por grant explícito.
Decisão (régua: Princípio #2 Quality > Speed + architecture-quality.kmd)
A deliberação /k-arch separou dois eixos ortogonais — (i) qual é o container e (ii) quem pode ser membro — e decidiu:
- Container = a "tribe" (membership/ACL própria, default-deny, desacoplada do
tenant-casa), reusando o sharing do Koder Drive (permissions + share-link + shared-with-me) e o broker de fan-out do
services/foundation/syncpara presençaatividade. Satisfaz D1D3D5D9/D10. Rejeita "workspace-only" (porta de mão única).
- Membership em camadas sobre o primitivo:
- *0 — identidades Koder (indivíduo + membro de org), por grant explícito,
cruzando tenants.*Ship primeiro.
- *1 — e-mail externo (gmailhotmailqualquer) via convite→signup + link
anônimo. Aditivo; respeita o sole-IdP*(
oauth-client-external-providers.kmd R1): o e-mail externo vira identidade Koder real (convite,id-RFC-013Phase 2), ou fica em link anônimo (view/comment). - T2 — guest federado first-class (sem virar conta Koder). Deferido —
mudaria o R1 do sole-IdP (porta de mão única D7/D9; reprovado pelo YAGNI). Decisão de owner.
- *0 — identidades Koder (indivíduo + membro de org), por grant explícito,
Resposta direta à pergunta de escopo
| Cenário | Camada | Como |
|---|---|---|
| Entre contas Koder individuais | T0 | grant explícito; carve-out do 404 cross-tenant |
| Entre contas Koder dentro de orgs | T0 | a identidade individual do membro recebe o grant |
| + e-mails não-Koder (gmailhotmail…) | T1 | convite→signup (vira conta Koder) ou link anônimo |
| Guest com qualquer e-mail sem conta | T2 | deferido — decisão de owner (muda o sole-IdP) |
Architecture
Camadas
Produto user-facing (futuro; consome o primitivo)
products/horizontal