Method packs son el modelo de plugin de PaellaDoc para el vocabulario: PRDs, epics, user stories, criterios de aceptación, registros de decisión.
🇬🇧 English
PaellaDoc separa qué es un artefacto (canónico) de cómo lo llamamos (específico del método). Es la única decisión de diseño que permite a PaellaDoc servir a devs, PMs y no-coders con el mismo motor.
El núcleo cerrado
Hay una lista fija de tipos canónicos de artefacto. Cada method pack tiene que mapear sus conceptos a uno de estos. La lista es corta a propósito:
prd— Declaración del problema (rol: PROBLEM)epic— Alcance (rol: SCOPE)user_story— Elemento de trabajo (rol: WORK_ITEM)acceptance_criteria— Validación en Gherkin (rol: VALIDATION)e2e_test— Puerta de salida para la versión (rol: RELEASE_GATE)decision_record— Decisión trazable (rol: DECISION)technical_spec,engineering_task,design_task,risk,improvement,maintenance_task,technical_debt,product_debt
Cada artefacto tiene una intención de evidencia declarada: qué tipo de prueba del repositorio lo satisface (workflow, capability, behavior, user surface, tests, terminal runs, verification, metric, decision context).
Method packs
Un method pack es un plugin que decide qué vocabulario ves en tu UI. El pack classic predeterminado mapea:
prd→ “Product Requirements Document”epic→ “Epic”user_story→ “User Story”
Un pack distinto podría llamarlos “Brief”, “Initiative”, “Job to be done”. Al orquestador no le importa. El tipo canónico y el rol son lo que fluye por el motor.
Por qué esto importa
Tres beneficios:
- Sin bloqueo de vocabulario. ¿No te gusta “user story”? Usa un pack que lo llame de otra forma. Los datos por debajo son idénticos.
- Sin fragmentación. Un equipo que usa un pack puede pasar el relevo a otro equipo que use otro. Los tipos canónicos son la lingua franca.
- Extensibilidad sin cambios en el núcleo. Un nuevo pack se publica como plugin, registra sus mappings y el motor funciona igual.
Para PMs y no-coders
Probablemente no pienses en los method packs a diario. El pack con el que empiezas es classic y simplemente funciona. Este post es para el momento en que te preguntes «espera, ¿puedo renombrar esto?» — sí, pero es un cambio de pack, no un renombrado puntual. Esa decisión es intencional.
Ampliar packs
La documentación para escribir tu propio pack está en el repositorio principal. Versión corta: implementas una interfaz pequeña que declara instancias de MethodArtifactType y su mapping a tipos canónicos y roles. Todo lo demás (labels de la UI, orden, valores predeterminados) es configuración.
🇪🇸 Español
PaellaDoc separa qué es un artefacto (canónico) de cómo lo llamamos (específico del método). Es la única decisión de diseño que permite a PaellaDoc servir a devs, PMs y no-coders con el mismo motor.
El núcleo cerrado
Hay una lista fija de tipos canónicos de artefacto. Cada method pack tiene que mapear sus conceptos a uno de estos. La lista es corta a propósito:
prd— Declaración del problema (rol: PROBLEM)epic— Alcance (rol: SCOPE)user_story— Elemento de trabajo (rol: WORK_ITEM)acceptance_criteria— Validación en Gherkin (rol: VALIDATION)e2e_test— Puerta de salida para la versión (rol: RELEASE_GATE)decision_record— Decisión trazable (rol: DECISION)technical_spec,engineering_task,design_task,risk,improvement,maintenance_task,technical_debt,product_debt
Cada artefacto tiene una intención de evidencia declarada: qué tipo de prueba del repositorio lo satisface (workflow, capability, behavior, user surface, tests, terminal runs, verification, metric, decision context).
Method packs
Un method pack es un plugin que decide qué vocabulario ves en tu UI. El pack classic predeterminado mapea:
prd→ “Product Requirements Document”epic→ “Epic”user_story→ “User Story”
Un pack distinto podría llamarlos “Brief”, “Initiative”, “Job to be done”. Al orquestador no le importa. El tipo canónico y el rol son lo que fluye por el motor.
Por qué esto importa
Tres beneficios:
- Sin bloqueo de vocabulario. ¿No te gusta “user story”? Usa un pack que lo llame de otra forma. Los datos por debajo son idénticos.
- Sin fragmentación. Un equipo que usa un pack puede pasar el relevo a otro equipo que use otro. Los tipos canónicos son la lingua franca.
- Extensibilidad sin cambios en el núcleo. Un nuevo pack se publica como plugin, registra sus mappings y el motor funciona igual.
Para PMs y no-coders
Probablemente no pienses en los method packs a diario. El pack con el que empiezas es classic y simplemente funciona. Este post es para el momento en que te preguntes «espera, ¿puedo renombrar esto?» — sí, pero es un cambio de pack, no un renombrado puntual. Esa decisión es intencional.
Ampliar packs
La documentación para escribir tu propio pack está en el repositorio principal. Versión corta: implementas una interfaz pequeña que declara instancias de MethodArtifactType y su mapping a tipos canónicos y roles. Todo lo demás (labels de la UI, orden, valores predeterminados) es configuración.