Papéis e me.md
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. Elas precisam de respostas diferentes para a mesma pergunta. O Eidos resolve isso com dois arquivos.
.eidos/roles/<role>.md
Seção intitulada “.eidos/roles/<role>.md”Um contrato de resposta por papel: como um agente fala com aquele tipo de pessoa. Vocabulário e profundidade, o que trazer à tona e o que dobrar, quem tem quais decisões. Os arquivos são commitados e ajustáveis pelo time: se os seus desenvolvedores querem menos acompanhamento, edite o developer.md e todos recebem.
| Semente | Seu elenco |
|---|---|
software |
Developer · Designer · Project Manager · Stakeholder |
book |
Author · Editor · Reader · Collaborator |
research |
Researcher · Reviewer · Sponsor |
Um de verdade, resumido:
# Developer
## Who they are
Builds the product from its blueprints. Reads one to answer "what am Ibuilding, exactly?" and to find the edges and the things still undecided.
## How to respond
- **Vocabulary & depth:** technical depth is welcome: data models, dependencies, failure modes.- **Decisions:** clarify and flag, don't decide. Scope and direction belong to the owners.- **Surface:** requirements, dependencies, out of scope, decisions, and anything underspecified that would block a build.Até o papel escrito para o leitor mais técnico devolve as decisões de produto às pessoas donas do produto. Esse é o princípio da pessoa em primeiro lugar, papel por papel.
.eidos/me.md
Seção intitulada “.eidos/me.md”Local, ignorado pelo git, um por pessoa. Nomeia o papel em que você está e o calibra em três eixos:
| Eixo | O que muda |
|---|---|
| Propriedade | O que é seu 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 |
Um desenvolvedor sênior novo neste produto e um júnior que está nele há dois anos precisam de coisas opostas; o papel sozinho não consegue distingui-los. Em branco também serve: significa facilitação completa, como para as pessoas donas do produto.
eidos roleseidos whoami --role developer --experience "new to this product" --capacity fluentNo eidosmd, o papel, a propriedade e a experiência com o escopo são de cada raiz, e o resto de quem você é não: seu nome, seu email, sua capacidade técnica e uma nota sobre como você gosta de ser ajudado são definidos uma vez (eidos whoami --global, ou Preferences → Eu no navegador) e copiados para o me.md de cada raiz quando ela abre, como linhas simples que um agente lê. Um campo que você mudar no me.md de uma raiz fica nessa raiz; os outros acompanham quando você os muda.
Quem é dono do produto
Seção intitulada “Quem é dono do produto”Nenhum papel é obrigatório. As pessoas donas do produto sustentam a intenção, o escopo e as decisões, seja qual for o seu papel: um product manager, um tech lead, um autor, um pesquisador principal. Uma semente pode escrever um papel para esse lugar (o Author da semente do livro), e a calibração Propriedade de cada pessoa no me.md diz do que ela é dona. O que importa é que uma questão de escopo possa ser encerrada, e que todo mundo saiba por quem.
Um agente lê o me.md antes de agir, depois o arquivo de papel que ele nomeia, e responde como aquele arquivo define. Sem um dono não há ninguém para quem devolver uma decisão, e o agente ou trava ou decide.
No eidosmd, ser dono do Framework e poder mudá-lo são também interruptores de um usuário, à parte do papel: Proprietário marca quem tem a palavra final, e Editor quem pode mudar o Framework e as configurações compartilhadas dos seus plugins. Um papel diz como um agente responde a alguém; os interruptores dizem quem decide e quem edita. Usuários →