Papéis e o ator

Nem todo mundo em uma raiz faz o mesmo papel. Uma pessoa sustenta a intenção. Outra constrói a partir dela. Outra a revisa. Outra responde por ela a mais alguém.

Elas precisam de respostas diferentes para a mesma pergunta. O Eidos resolve isso com dois arquivos.

_eidos/roles/<role>.md

Um contrato de resposta por papel, dizendo como um agente deve falar com aquele tipo de pessoa:

• Vocabulário e profundidade técnica
• O que trazer à tona e o que dobrar para o lado
• Quem sustenta quais decisões

Quais papéis existem é decisão do seu Framework. Cada semente traz um elenco escrito contra as suas próprias coleções:

Semente	O seu elenco
software	Framework Owner · Developer · Designer · Project Manager · Stakeholder
book	Framework Owner · Editor · Reader · Collaborator
research	Framework Owner · Researcher · Reviewer (adversarial) · Sponsor (non-technical)

Estes arquivos são versionados e ajustáveis pelo time. Se os seus desenvolvedores quiserem menos condução, edite developer.md e todos recebem.

Aqui vai um real, aparado:

_eidos/roles/developer.md

# Developer

## Who they are

Builds the product from its blueprints. Reads a blueprint to answer "what am I
building, exactly?" and to find the edges, the dependencies, and the
things still undecided.

## How to respond

- **Vocabulary & depth:** technical depth is welcome — data models,
  indexes, relationships, dependencies, edge cases, failure modes.
- **Decisions:** clarify and flag, don't decide. Product calls — scope,
  direction, priorities — belong to the Framework Owner.
- **Surface / hide:** surface Behaviors & Acceptance Criteria,
  Dependencies, Testing, Constraints, and anything underspecified that
  would block a build.
- **Focus:** what's promised vs. what's vague; the AC labels; the
  dependency and testing story.

Repare na linha Decisions. Até o papel escrito para o leitor mais técnico devolve as decisões de produto ao Framework Owner. Isso não é gentileza: é o princípio de “pessoas primeiro” expresso papel a papel.

_eidos/me.md

Pessoal, no gitignore, um por pessoa. Ele nomeia o papel em que você está e depois o calibra em três eixos:

Eixo	O que muda
Propriedade	O que você de fato possui nesta raiz, e portanto quais decisões voltam para você.
Experiência com o escopo	Quanta orientação você recebe antes da resposta.
Capacidade técnica	Vocabulário e profundidade, independentemente do papel.

O papel define a linha de base; a calibração a ajusta por pessoa. Configure com whoami. Em branco ou ausente está tudo bem: o padrão é uma facilitação completa no estilo Framework Owner, e o agente se oferece para registrar quem você é.

Por que a calibração é separada do papel

Uma desenvolvedora sênior recém-chegada a este produto e um desenvolvedor júnior que está nele há dois anos precisam de coisas opostas. O papel sozinho não consegue distingui-los; os eixos de calibração conseguem.

Nota

Um papel é uma linha de base, não uma jaula. Você pode escrever um papel próprio direto no seu me.md em vez de escolher um dos do Framework.

O único arquivo que não é versionado

me.md é o único arquivo de _eidos/ mantido fora do controle de versão, e o .gitignore da semente cuida disso. Ele é seu, não do time, que é o que torna seguro ser honesto nele.

Como um agente os usa

Leia o ator antes de agir.

Um agente lê _eidos/me.md, depois o contrato correspondente em _eidos/roles/, e responde como aquele arquivo define. Ele lê o arquivo em vez de inferir pelo nome, porque um Framework define o seu próprio elenco e “designer” pode significar algo específico no seu.

O resultado é que a mesma raiz responde de forma diferente a cada leitor. Um stakeholder que pergunta “o que isso faz?” recebe resultados e trade-offs. Uma desenvolvedora que pergunta o mesmo recebe critérios de aceitação, dependências e o que ainda não foi decidido. Nenhuma é um resumo da outra: são leituras diferentes do mesmo arquivo.

O Framework Owner

Um papel é comum a todas as sementes, porque o padrão depende de ele existir: o Framework Owner, que sustenta a intenção, o escopo e as decisões.

O papel, não o cargo

Isto é um papel dentro da raiz, não um cargo. Pode ser uma product manager, um tech lead, uma autora ou um pesquisador principal. O que importa é que exatamente uma pessoa possa encerrar uma questão de escopo, e que todo mundo saiba quem é.

Todo o princípio de “pessoas primeiro” se apoia na existência desse papel: a pessoa escreve; o agente facilita. Sem um dono não há a quem o agente devolver uma decisão, e ele ou trava ou, pior, decide.

O princípio de “pessoas primeiro” vale para todos os papéis. Só o modo muda: um papel de Developer recebe profundidade técnica e continua sem poder definir o escopo.

A seguir

• Trabalhando com agentes: como a facilitação se parece na prática.
• Skills