Roles y el actor

No todo el mundo en una raíz juega el mismo papel. Una persona sostiene la intención. Otra construye a partir de ella. Otra la revisa. Otra responde por ella ante alguien más.

Necesitan respuestas distintas a la misma pregunta. Eidos lo resuelve con dos archivos.

`_eidos/roles/<role>.md`

Un contrato de respuesta por rol, que dice cómo debería hablarle un agente a ese tipo de persona:

Vocabulario y profundidad técnica
Qué sacar a la luz frente a qué plegar
Quién sostiene qué decisiones

Qué roles existen es cosa de tu Framework. Cada semilla trae un reparto escrito contra sus propias colecciones:

Semilla	Su reparto
`software`	Framework Owner · Developer · Designer · Project Manager · Stakeholder
`book`	Framework Owner · Editor · Reader · Collaborator
`research`	Framework Owner · Researcher · Reviewer (adversarial) · Sponsor (non-technical)

Estos archivos son versionados y ajustables por el equipo. Si tus desarrolladores quieren que se les lleve menos de la mano, edita developer.md y lo tienen todos.

Aquí va uno real, recortado:

# 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.

Fíjate en la línea de Decisions. Incluso el rol escrito para el lector más técnico devuelve las decisiones de producto al Framework Owner. Eso no es cortesía: es el principio de «las personas primero» expresado rol a rol.

`_eidos/me.md`

Personal, en gitignore, uno por persona. Nombra el rol en el que estás y luego lo calibra en tres ejes:

Eje	Qué cambia
Propiedad	Qué posees de verdad en esta raíz, y por tanto qué decisiones vuelven a ti.
Experiencia con el alcance	Cuánta orientación recibes antes de la respuesta.
Capacidad técnica	Vocabulario y profundidad, con independencia del rol.

El rol fija la línea base; la calibración la ajusta por persona. Configúralo con whoami. Estar en blanco o ausente está bien: por defecto se comporta como facilitación completa al estilo de un Framework Owner, y el agente se ofrece a anotar quién eres.

Cómo los usa un agente

Lee al actor antes de actuar.

Un agente lee _eidos/me.md, luego el contrato correspondiente en _eidos/roles/, y responde como define ese archivo. Lee el archivo en lugar de inferir por su nombre, porque un Framework define su propio reparto y «designer» podría significar algo específico en el tuyo.

El resultado es que la misma raíz le responde distinto a cada lector. Un stakeholder que pregunta «¿esto qué hace?» recibe resultados y compromisos. Una desarrolladora que pregunta lo mismo recibe criterios de aceptación, dependencias y lo que sigue sin decidir. Ninguna es un resumen de la otra: son lecturas distintas del mismo archivo.

El Framework Owner

Un rol es común a todas las semillas, porque el estándar depende de que exista: el Framework Owner, que sostiene la intención, el alcance y las decisiones.

Todo el principio de «las personas primero» se apoya en que este rol exista: la persona escribe; el agente facilita. Sin dueño no hay nadie a quien el agente pueda devolver una decisión, y o se atasca o, peor, decide.

El principio de «las personas primero» vale para todos los roles. Solo cambia el modo: un rol de Developer recibe profundidad técnica y sigue sin poder fijar el alcance.

Trabajar con agentes: cómo se ve la facilitación en la práctica.
Skills