Feature Spec Builder

Convierte «unas pocas palabras» en «requisitos de funcionalidad de nivel de ingeniería».

El núcleo no es escribir documentación, sino sacar y completar sistemáticamente lo que no se dice claramente en una frase. Una frase como «Necesito la función XX» normalmente carece del 80% de la información necesaria para la ingeniería: roles, escenarios, límites, pertenencia de capacidades, interfaces, dependencias, criterios de aceptación. Esta habilidad utiliza un enfoque de «escaneo de dimensiones fijas + aclaración interactiva pregunta por pregunta» para llenar estas brechas, produciendo finalmente una especificación de funcionalidad que supere la revisión de ingeniería.

El resultado de esta habilidad se limita a la especificación de la funcionalidad — incluye borradores de contratos de interfaz y criterios de aceptación, pero no realiza descomposición de tareas ni planificación de implementación, eso se lo dejamos al equipo de ingeniería.

Sección de configuración (rellenar antes del primer uso)

Esta habilidad depende de un sistema de coordenadas propio del producto y de los acuerdos del equipo para la clasificación y la colaboración. Reemplaza los marcadores de posición con las definiciones reales de tu equipo; agrupados por tema, los grupos no utilizados pueden dejarse por defecto.

A. Sistema de coordenadas de capacidades

L1 = <ej. Capacidad atómica / Interfaz subyacente de movimiento y percepción>
L2 = <ej. Capacidad combinada / Paquete de desarrollo a nivel de aplicación>
L3 = <ej. Solución completa / Entrega de escenario>
Cinco dominios: Dom1=<…> Dom2=<…> Dom3=<…> Dom4=<…> Dom5=<…>

B. Convenciones de interfaz

Presupuesto de API = <ej. Límite máximo de 300 métodos>   Convenciones de lenguaje/vinculación = <ej. C++ core + pybind11>

C. Integradores y formas

Niveles de integrador = <ej. Asociado / Profesional / Experto>   Forma = <Simulación / Real / Ambos>
Directorio de salida de resultados = <por defecto feature-specs/; los resultados se escriben en <este directorio>/<nombre de la funcionalidad>/<nombre de la funcionalidad>.md>

D. Principios del producto (la regla para la compuerta de autoverificación antes de generar el resultado)

Usar principios predeterminados integrados: Sí / No (por defecto=Sí, texto completo en references/product-principles.md)
Principios personalizados/complementarios del equipo: <se puede dejar vacío; si se rellena, se fusiona con los predeterminados, en caso de conflicto prevalecen los del equipo>
Prioridad de conflictos: <Dos restricciones duras no se pueden sobrescribir: seguridad predeterminada y compatibilidad hacia atrás son líneas rojas; si ambas chocan, se debe escalar a decisión manual. El orden de prioridad relativa de los demás principios puede rellenarse aquí; si se deja vacío, en caso de conflicto siempre se devuelve al usuario para que decida, sin ordenación automática>
Firmante de cambios disruptivos: <quién debe firmar cuando se determina que es un cambio disruptivo, ej. Responsable de arquitectura de plataforma>

E. Mapeo capa de implementación × departamento (para la descomposición entre capas y asignación de propietarios en el paso 4; ortogonal a L-Tier — L-Tier gestiona el nivel de abstracción externa, la capa de implementación gestiona qué pilas tecnológicas internas se tocan y cuántos departamentos están involucrados)

Capa de implementación → Departamento/rol propietario → Firmante entre capas
  Capa de ejecución:
    Capa SDK de segundo desarrollo      → <rellenar, ej. SDK/Equipo de plataforma>   → <firmante>
    Software subyacente (firmware/middleware)  → <rellenar, ej. Equipo de embebidos/firmware> → <firmante>
    Servicios algorítmicos (percepción/algoritmo)  → <rellenar, ej. Equipo de algoritmos>       → <firmante>
    Hardware (mecánico/electrónico)        → <rellenar, ej. Equipo de hardware/electrónico>   → <firmante>
  Capas no ejecutables (las funcionalidades ecológicas/de integración/documentación caerán aquí, no forzarlas a firmware/algoritmos/hardware):
    Capa de portal de documentación      → <rellenar, ej. DevRel/Documentación/Frontend del sitio> → <firmante>
    Capa de infraestructura de construcción/distribución        → <rellenar, ej. Construcción SDK/DevOps>      → <firmante>
  Ruta de escalamiento entre departamentos = <ej. Propietario de capa → Responsable de departamento → Revisión de arquitectura entre departamentos → CTO>

¿Qué hacer si la sección de configuración no está rellenada?: Al menos completa el grupo A (niveles de capacidad + cinco dominios), estos dos determinan directamente la precisión de la clasificación. Para el resto de grupos, manejo degradado:

A/B/C sin rellenar: Al clasificar (paso de clasificación automática), declara explícitamente «los siguientes niveles de L/dominios/presupuesto/vinculación son mi inferencia» y da la justificación; en todo el texto, los campos que usen este sistema de coordenadas (nivel, dominio de capacidad, presupuesto de API, convenciones de vinculación, distribuidos en las secciones de «Posicionamiento de la capacidad», «Evaluación de impacto · Compatibilidad · Estrategia de publicación», «Borrador del contrato de interfaz») deben marcarse con [pendiente de confirmación], nunca escribas valores inferidos como confirmados; incluye «Los valores reales de la sección de configuración están pendientes de completar» en la sección «Pendientes de confirmación».

D sin rellenar: Por defecto, usa las 10 reglas predeterminadas integradas de references/product-principles.md, e indica en la sección «Autocomprobación de principios del producto» que «En esta ocasión se utilizan los principios de producto predeterminados integrados». La compuerta de autocomprobación de principios del producto debe ejecutarse en cualquier circunstancia, nunca se omite porque la sección de configuración esté vacía.

E sin rellenar: En la descomposición entre capas del paso 4, los propietarios/departamentos/firmantes deben marcarse como [pendiente de confirmación·requiere asignación], indicando al usuario que los complete, nunca inventes nombres de departamentos — asignar incorrectamente la responsabilidad de un departamento inferido al equipo equivocado es el fracaso más peligroso.

F. Organización y procesos (configuración privada local, para colaboración a nivel empresarial)

La «quién es responsable de qué, qué compuertas de proceso se pasan, cómo se planifican las versiones» varía entre empresas y es privado, no se incluye en este skill. Para colaboración a nivel empresarial, copia la plantilla de references/org-process-config.md a un archivo local org-process.local.md (o ejecuta scripts/init-org-config.sh para generarlo), y rellena el mapa de roles / compuertas de entrega / ritmo de versiones y capacidad del pipeline según tu empresa. Privado local, no lo subas (ya está en .gitignore).

Con esta configuración: Al generar el resultado, asigna los propietarios reales según el mapa de roles, enumera las compuertas obligatorias y los artefactos de entrega en «Evaluación de impacto · Compatibilidad · Estrategia de publicación», marca la versión objetivo y el esfuerzo (días-persona) frente a la capacidad del pipeline, y, después del bloqueo de requisitos, indica que los cambios deben pasar por el CCB (detalles en references/org-process-config.md).

Sin esta configuración: Usa marcadores de posición de roles genéricos (como [Gestor de producto·pendiente de asignación]), e indica al usuario que puede generar una configuración local. Bajo ninguna circunstancia escribas nombres reales de personas/procesos internos en el skill o en los documentos que se vayan a compartir públicamente.

Flujo de trabajo

Al recibir un fragmento de requisitos dispersos, avanza estrictamente siguiendo esta cadena principal:

Recibir fragmento → Derivación de requisitos (identificar múltiples funcionalidades implícitas) → Clasificación automática → Descomposición entre capas y enrutamiento (identificar cambios por capa·propietario·orden de dependencias) → Primera capa de aclaración (posicionamiento·grueso) → Segunda capa de aclaración (detalles de funcionalidad·fino) → Documento de salida (pasar compuerta de autocomprobación de principios)

Paso 1: Recibir y reformular

Lee el fragmento dado por el usuario. Primero, reformula tu comprensión en una frase («Entiendo que lo que quieres es… ¿correcto?») y deja que el usuario confirme o corrija. Este paso evita desviarse desde el principio.

Paso 2: Derivación de requisitos (identificar si hay múltiples funcionalidades implícitas)

Un fragmento de demanda dispersa a menudo contiene más de un requisito, especialmente cuando se pega directamente de un chat o correo electrónico: la solicitud principal es la más visible, pero a su alrededor hay otras demandas, preguntas desviadas por la conversación o capacidades implícitas inferidas del objetivo final. No te lances a la más visible y empieces a trabajar, primero haz una exploración de derivación:

Lee todo el fragmento y enumera cada demanda que pueda ser independiente (una acción / una capacidad = una funcionalidad candidata). Presta especial atención a cuatro tipos que a menudo se pasan por alto: ① la «pregunta inicial» que se desvió por seguimiento; ② demandas independientes no relacionadas con la principal, solo mencionadas de pasada en la misma conversación; ③ puntos donde el equipo de I+D ya respondió «no compatible por ahora / impleméntalo tú mismo» (a menudo son requisitos ocultos enterrados); ④ capacidades combinadas inferidas del objetivo final del cliente pero no mencionadas explícitamente.
Heurística de artefactos heterogéneos: Cuando en una misma demanda aparecen diferentes formas de artefactos (código ejecutable/contrato de interfaz/contenido de documentación/estructura de sitio/paquete de distribución), sospecha que es múltiples funcionalidades — diferentes formas de artefacto a menudo corresponden a diferentes propietarios, diferentes formas de aceptación y diferentes ciclos de mantenimiento; mezclarlos hará que los objetos de revisión y los criterios de aceptación entren en conflicto en un mismo .md (por ejemplo, «da un ejemplo de ROS + añade una sección en el sitio web oficial» = funcionalidad de código + funcionalidad de documentación, los propietarios y la aceptación son completamente diferentes).
Clúster de funcionalidades relacionadas que comparten una fuente de verdad única: Si varias funcionalidades extraídas comparten una única fuente de verdad (por ejemplo, el tutorial de documentación = código del repositorio de ejemplos = proyección externa del contrato de la funcionalidad principal), cada una sigue siendo un documento independiente, pero en cada documento, en «Dependencias y requisitos previos» / «Funcionalidades relacionadas», debes fijar explícitamente la pertenencia a la fuente de verdad (qué documento/repositorio tiene el derecho de definición, el resto son proyecciones/referencias), y proporcionar un diagrama de dependencias dentro del clúster — reutiliza el paradigma de «pertenencia del derecho de definición» del «Contrato de transferencia entre capas», para evitar que múltiples documentos tengan versiones que no coincidan.
Si realmente solo hay una demanda, anota «Funcionalidad única confirmada» y pasa directamente a la clasificación.
Si hay varias, dibuja una tabla de derivación de requisitos (Funcionalidad candidata ｜ Texto original ｜ Naturaleza ｜ Estado actual ｜ Relación/dependencia con la demanda principal), y luego deja que el usuario decida cuáles detallar en esta ronda — esto es un alcance de decisión, nunca decidas por él. Las no seleccionadas, déjalas como «marcadores de funcionalidades relacionadas» en la sección «Pendientes de confirmación», para facilitar su posterior registro como elementos independientes.
Cuando se trabajen varias funcionalidades juntas, cada funcionalidad genera su propio documento de especificación de funcionalidad independiente, nunca mezcles múltiples requisitos en el mismo documento — cada una sigue los pasos posteriores individualmente, y se refieren entre sí solo con «funcionalidades relacionadas», indicando claramente las dependencias (por ejemplo, D depende de A+B). (Nota: una funcionalidad, incluso si abarca varias capas, solo genera un .md, con secciones internas divididas por lectores objetivo; esto es «misma funcionalidad con capas internas/lectores diferentes», lo que no entra en conflicto con «múltiples funcionalidades independientes cada una con su propio documento».)

Este paso es el más fácil de omitir en toda la cadena, pero el que más afecta a la corrección de la entrega: omitirlo, y la especificación que recibe el equipo de I+D puede cubrir solo una parte de la demanda del cliente, o pegar varias funcionalidades que deberían ser independientes en una sola.

Paso 3: Clasificación automática

Fija el requisito en el sistema de coordenadas: ¿en qué nivel L1/L2/L3 cae?, ¿en cuál de los cinco dominios?, ¿abarca múltiples dominios? La clasificación en sí misma expone el primer lote de problemas implícitos — si no puedes clasificarlo limpiamente, significa que el fragmento carece de información en alguna dimensión, que es exactamente la brecha que hay que aclarar más adelante. Anota los puntos inciertos de la clasificación.

Nota: La clasificación fija el nivel de abstracción externa (L-Tier) y el dominio de capacidad, no responde «qué capas de implementación interna se tocan, a qué departamento pertenece» — eso es cosa del siguiente paso 4. Una interfaz L1 puede tocar solo la capa de segundo desarrollo, o puede afectar hasta firmware/algoritmos/hardware.

Salida N/A de L-Tier para funcionalidades no ejecutables: Si la funcionalidad es esencialmente una forma de entrega/distribución/instalación/documentación de capacidades existentes (no una nueva capacidad en tiempo de ejecución, no expone API, no consume presupuesto de API, como un paquete de instalación offline/repositorio de ejemplo/sección del sitio web — prototipos H/I), L-Tier se marca explícitamente como N/A (no es una funcionalidad de capacidad, solo cae en el eje de la capa de implementación), los cinco dominios pueden marcarse como N/A, no fuerces un valor L. Señal de determinación: el artefacto es «paquete de distribución/documento/estructura de sitio» en lugar de «API/comportamiento en tiempo de ejecución»; su centro de gravedad se desplaza a la capa de infraestructura de construcción/distribución o capa de portal de documentación + eje de dependencias externas (paso 4).

Paso 4: Descomposición entre capas y enrutamiento (obligatorio para funcionalidades que abarcan capas)

La clasificación solo responde «en qué L cae, en qué dominio»; este paso responde además «qué capas de implementación necesita modificar esta demanda, a quién pertenece cada capa, qué orden de prioridad, y si se puede entregar de forma independiente solo con el segundo desarrollo». Muchas demandas de clientes parecen caer en la capa SDK de segundo desarrollo, pero en realidad dependen fuertemente de capas más profundas — firmware/middleware, servicios algorítmicos, incluso hardware — y estas capas a menudo pertenecen a diferentes departamentos.

Siguiendo las preguntas de determinación de references/cross-layer-routing.md, haz cinco cosas:

Determinar capa por capa si necesita cambios: Para las cuatro capas en tiempo de ejecución (capa SDK de segundo desarrollo / software subyacente (firmware/middleware) / capa de servicios algorítmicos / capa de hardware), pregunta capa por capa «¿qué necesita cambiar en esta capa?». Además, pregunta obligatoriamente por dos tipos de capas que no son en tiempo de ejecución (las funcionalidades ecológicas/de integración/documentación a menudo tienen su centro aquí): capa de portal de documentación (secciones del sitio web oficial, repositorios de ejemplos, IA de documentación — el propietario es DevRel/Documentación/Sitio, no I+D) y capa de infraestructura de construcción/distribución (empaquetado, CI multi-entorno, ABI/precompilación — el propietario es Construcción SDK/DevOps). ⚠ Cuando el artefacto es ejemplo/empaquetado/instalación/distribución/documentación (prototipos H/I), incluso si el toque técnico es solo segundo desarrollo puro, no lo asignes por defecto al grupo de SDK de segundo desarrollo — enrútalo según la configuración del grupo E al propietario correspondiente (forzarlo a los grupos de firmware/algoritmos/hardware, o tirarlo por defecto al grupo de segundo desarrollo, son asignaciones erróneas de alto riesgo). Si puedes responder limpiamente «solo toca la capa de segundo desarrollo, sin cambios en portal/infraestructura», anota «Funcionalidad de capa única (SDK de segundo desarrollo)» y pasa directamente al paso 5.
Determinar la capa de cambio más profunda (compuerta dura) + falsabilidad de viabilidad: Encuentra la capa más profunda que necesita cambios. Una vez que una capa responde «no compatible/no estoy seguro», profundiza capa por capa en el orden segundo desarrollo → firmware → algoritmo → hardware, hasta tocar fondo (encontrar la capa que puede soportarlo o determinar que es físicamente inviable). Da la conclusión de tocar fondo de capa (tres opciones): A. Entregable solo con segundo desarrollo puro / B. Entregable entre capas / C. No entregable en las capas actuales (la capa inferior no está planificada o hay limitación física). Si la capa de cambio más profunda no es la capa SDK de segundo desarrollo, esta funcionalidad no es entregable de forma independiente solo con la capa de segundo desarrollo — marca en un lugar visible del documento: ⚠ No entregable de forma independiente solo con la capa de segundo desarrollo: el cambio más profundo de esta funcionalidad cae en <capa>, necesita que <departamento propietario> entregue primero <capacidad> para que la capa de segundo desarrollo pueda encapsularla, e inclúyelo en la sección «Posicionamiento de la capacidad» y en el DoR. Cuando toques hardware/límites físicos, detente inmediatamente de detallar las firmas de interfaz en la capa de segundo desarrollo — seguir escribiendo un borrador de contrato que no se puede implementar es una causa frecuente de rechazo en la revisión.
Dibujar tabla de descomposición entre capas + ordenar dependencias + determinar contrato de transferencia entre capas: Enumera qué debe cambiar en cada capa, el departamento propietario, si bloquea a la capa superior; ordena la cadena de dependencias de abajo a arriba; para cada dependencia entre capas, fija un contrato de transferencia de «qué expone la capa inferior a la capa superior» (incluyendo la pertenencia del derecho de definición — para evitar que dos departamentos escriban versiones que no coincidan).
Identificar propietarios y elementos pendientes de confirmación entre departamentos (cada elemento debe llevar un triplete de pertenencia): ¿Qué capas tienen un «si necesita cambios/puede soportarlo» que tú no puedes determinar y debes confirmar con el departamento correspondiente (por ejemplo, «¿el firmware soporta realmente la formación de haces?»)? Enuméralos como elementos pendientes de confirmación entre departamentos. El usuario de esta habilidad (normalmente el lado de producto/SDK) no puede obtener respuestas reales de las capas inferiores durante la sesión, por lo que no puedes simplemente marcar [pendiente de confirmación] y dejarlo en la lista — cada elemento debe llevar un triplete: propietario de la verificación (quién contacta a ese departamento)｜para cuándo debe tener respuesta antes de qué hito de revisión｜suposición por defecto/plan de degradación si no se responde a tiempo (mismo paradigma que «responsable + método + plazo» para los [pendiente de confirmación] de tipo umbral). A menudo son los puntos de bloqueo de la ruta crítica de toda la demanda.
Conclusión B/C obligatorio: Reescribir el artefacto real en la narrativa principal (tapar el «falso listo»): Una vez que la conclusión de tocar fondo de capa = B o C, debes modificar la «Definición en una frase» y la historia P1 para que describan solo el artefacto real entregable en esta ronda (por ejemplo, «En esta ronda se entrega stub SDK + firma, la capacidad real de formación de haces depende del firmware en Q4»), nunca escribas el P1 basado en la capacidad completa de la solicitud original del cliente — de lo contrario, el documento que I+D/cliente leen como listo no coincidirá con lo que realmente se puede entregar, que es el falso listo más peligroso. Cuando la capa inferior diga «no compatible y no planificado», debes proporcionar un plan de degradación/fase en la sección «Implementación entre capas y colaboración entre departamentos» (stub mock / escalones limitados / simulación primero), no solo dejarlo como pendiente de confirmación.

Salida temprana para conclusión C donde la capa de segundo desarrollo no tiene ningún artefacto entregable independiente (incluyendo stubs) en esta ronda: Si la falsabilidad confirma que esta funcionalidad es en realidad un cambio de capa inferior/hardware, y ni siquiera tiene sentido un stub en el lado de segundo desarrollo, no continúes con los pasos 5 y 6 de aclaración dimensión por dimensión (eso solo produciría un cascarón vacío lleno de [pendiente de confirmación], desperdiciando el presupuesto de interacción y violando la propia disciplina de alcance). Genera directamente una «Conclusión de enrutamiento entre capas» resumida: conclusión de tocar fondo de capa + tabla de descomposición entre capas + ruta de bloqueo entre capas y escalamiento + mensaje para el cliente, y marca explícitamente «Esta demanda no es una tarea de la capa de segundo desarrollo en este momento, se recomienda transferir al para su registro como proyecto».

Forma de salida: una funcionalidad = un .md (dividido por lectores objetivo). Ya sea de capa única o entre capas, una funcionalidad solo genera un documento de especificación de funcionalidad; el contenido entre capas/departamentos no se divide en múltiples archivos, sino que se organiza en secciones dentro del mismo .md divididas por lectores objetivo (producto/revisión, SDK de segundo desarrollo, firmware, algoritmo, hardware), y se añade una tabla de «Guía de lectura» en la parte superior que enumera claramente «lector objetivo → qué secciones debe leer → de qué es responsable cada uno», facilitando el seguimiento completo dentro de un único documento de especificación. Las plantillas de secciones divididas por lectores objetivo y la plantilla de guía de lectura se encuentran en references/cross-layer-routing.md「IX」.

El resultado se introduce en la sección «Implementación entre capas y colaboración entre departamentos» de la plantilla de salida.

La conclusión de este paso reescribirá la lista de preguntas para los pasos 5 y 6: Por ejemplo, si el cliente pide una interfaz de formación de haces set_microphone_beam_angle, y en este paso se verifica que el firmware aún no soporta la formación de haces, el paso 5 debe preguntar primero «¿aceptas que se concatenen a algoritmo/hardware? ¿el alcance de esta ronda es solo hacer un marcador de posición en el SDK?», en lugar de ir directamente a preguntar por la firma de la interfaz.

¿Por qué es un paso separado y se sitúa antes del posicionamiento?: Una demanda que «en realidad necesita tocar firmware» si se procesa como una funcionalidad normal de segundo desarrollo, produciría un documento que «parece que I+D puede cogerlo, pero en realidad la capa inferior no tiene esa capacidad» — este es el modo de fallo más peligroso. Adelantar este paso es precisamente taponar las «pseudo-funcionalidades de segundo desarrollo» antes del DoR.

Sigue las «Reglas de aclaración interactiva»: En la tabla de descomposición entre capas, todo lo que sea propietario, si una capa necesita cambios, o si la capa inferior ya es compatible, que sea inferido, debe marcarse como [pendiente de confirmación] y presentarse como preguntas de aclaración una por una al usuario (una pregunta a la vez, con opciones), nunca metas departamentos/propietarios/dependencias inferidos como confirmados en la tabla — este paso te tienta naturalmente a llenar toda la tabla de propietarios de una vez, lo que equivale a decidir por el usuario «quién es el propietario, qué capa necesita cambios».

Paso 5: Primera capa de aclaración — Posicionamiento (grueso)

Usa la «Primera capa · Dimensiones de posicionamiento» como lista de verificación, revisa el fragmento elemento por elemento, enumera las dimensiones que no se han respondido y, siguiendo las «Reglas de aclaración interactiva», pregúntalas una por una. Esta capa define la forma de la funcionalidad: qué es, en qué capa/dominio cae, cuáles son sus límites, qué forma tiene. Solo una pregunta a la vez.

Divide las brechas en dos categorías:

Brechas bloqueantes: Sin rellenarlas, no se puede continuar con la clasificación o definir los límites (por ejemplo: ¿a qué tipo de roles sirve? ¿cuál es el comportamiento principal?).
Brechas no bloqueantes: Afectan a la completitud pero no a la columna vertebral (por ejemplo: un código de error periférico, la forma de la documentación).

Paso 6: Segunda capa de aclaración — Detalles funcionales (fino)

Una vez que el posicionamiento está claro, se conoce la forma de la funcionalidad, pero I+D aún no puede empezar a trabajar — porque todavía no sabe «cómo funciona exactamente». Esta capa utiliza las «Segunda capa · Dimensiones de detalles funcionales» para profundizar en las especificaciones de comportamiento: cómo fluye el proceso normal, qué estados tiene, cómo se manejan las excepciones, qué hacer en escenarios límite, cuáles son los valores de los parámetros.

Las preguntas de la segunda capa deben variar según el tipo de funcionalidad: las de tipo guía preguntan por la ruta y la lógica de llegada, las de percepción preguntan por falsos positivos y confianza, las de datos preguntan por esquema y magnitud. El repositorio de preguntas específicas por tipo se encuentra en references/detail-probes.md — primero determina a qué prototipo pertenece esta funcionalidad y luego invoca la lista de sondas correspondiente.

Paso 7: Generar el documento de especificación de la funcionalidad (incluyendo la compuerta de autocomprobación de principios del producto)

Una vez rellenadas las brechas bloqueantes, primero pasa por la compuerta de autocomprobación de principios del producto y luego genera el resultado según la «Plantilla de salida».

Selección de plantilla: Las funcionalidades pequeñas de capa única de segundo desarrollo puro con pocas brechas usan la plantilla simplificada («Definición en una frase», «Origen y contexto», «Posicionamiento de la capacidad», «Límites del alcance», «Historia + MVP», «Especificaciones de comportamiento», «Contrato de interfaz», «Dependencias», «Evaluación de impacto», «Autocomprobación de principios del producto (una línea de conclusión)», «Registro de decisiones», «Pendientes de confirmación», omitiendo la sección «Implementación entre capas y colaboración entre departamentos» y la mayoría de NFRs bajo demanda); las funcionalidades que abarcan capas o las grandes usan la plantilla completa. Ambas comparten el mismo conjunto de elementos obligatorios y DoR.

Antes de generar el resultado, debe pasar: la compuerta de autocomprobación de principios del producto. Toma la sección de configuración «D. Principios del producto» (si no está rellenada, usa las 10 reglas predeterminadas integradas de references/product-principles.md), y para cada principio, da una conclusión de tres estados: ✓ Cumple / ⚠ Viola-con concesión / — No aplica. Las reglas de determinación de tres estados, la lista común de banderas rojas y la prioridad de conflictos se encuentran en references/product-principles.md. Cualquier ⚠ debe tener una concesión explicada en la sección «Autocomprobación de principios del producto», y una línea en la sección «Registro de decisiones clave» (fuente marcada como «Concesión de conflicto de principios del producto», indicando el número). Las funcionalidades ligeras con todos ✓/— pueden comprimir la autocomprobación en una línea de conclusión, sin necesidad de extender una tabla vacía.

La compuerta no la marca la habilidad como aprobada, sino que convierte los elementos no conformes en preguntas de aclaración o [pendiente de confirmación] para el usuario. Cualquier cosa que implique una concesión (sacrificar una capacidad por compatibilidad, qué recortar cuando se supera el presupuesto, si una acción peligrosa necesita una puerta de permisos), debe, siguiendo las «Reglas de aclaración interactiva», hacerse una pregunta a la vez con opciones, y devolverse al usuario para que decida.

Requisitos duros del DoR:

Cualquier principio marcado como ⚠ sin la explicación de concesión correspondiente + registro de decisión → No pasa el DoR, no se puede marcar como «I+D puede asumirlo/pendiente de revisión».
La conclusión de tocar fondo de capa del paso 4 es B/C, y la «Definición en una frase» o P1 aún promete la capacidad completa que no está lista en la capa inferior → No pasa el DoR (primero debe reescribirse como el artefacto real entregable según el punto 5 del paso 4).

Una vez pasada la compuerta, genera el documento según la plantilla seleccionada y escríbelo en el directorio de salida estándar feature-specs/<nombre de la funcionalidad>/<nombre de la funcionalidad>.md (no solo lo pegues en la conversación; la ubicación acordada está en la «Plantilla de salida»); las brechas no bloqueantes aún no resueltas se colocan en la sección «Pendientes de confirmación», y los campos afectados en el cuerpo se marcan con [pendiente de confirmación], nunca se inventan.

¿Por qué dos capas en dos pasadas separadas?: Hacer demasiadas preguntas en una sola sesión puede cansar (ver el límite total en las reglas de aclaración). Se recomienda que tras la primera capa (paso 5) se genere un borrador de «posicionamiento fijado, comportamiento pendiente», y que la segunda capa (paso 6) complete las especificaciones de comportamiento como una pasada de profundización posterior, actualizándolo a la v1.0 lista para I+D. Ambas capas respetan sus propios límites totales sin solaparse. Si la demanda es muy pequeña y las brechas son pocas, también se pueden completar ambas capas en una sola tanda.

Primera capa · Dimensiones de posicionamiento (grueso)

Define la «forma» de la funcionalidad. Revisa el fragmento elemento por elemento; lo que falte es lo que hay que aclarar. Dividido en dos grupos.

Grupo A · Esencia del requisito (Qué / Por qué / Límites)

Rol y escenario: ¿Quién lo usa? ¿En qué escenario se activa? (Usuario final / Desarrollador integrador / Operaciones…)
Comportamiento principal: ¿Qué acción específica realiza esta función? ¿Qué entrada tiene y qué resultado produce?
Límites del alcance: ¿Qué incluye y qué incluye explícitamente? (Este es el que más se pasa por alto y el que mejor evita que I+D imagine un alcance por su cuenta.)
Criterio de éxito: ¿Cómo se considera que «está bien hecho»? ¿Con qué indicadores observables se mide?

Grupo B · Posicionamiento de ingeniería del SDK

Pertenencia al nivel de capacidad: ¿En qué nivel L1 / L2 / L3 cae?
Posicionamiento en los cinco dominios: ¿En qué dominio de capacidad se encuentra? ¿Abarca varios dominios? ¿A quién implica si es así?
Superficie de impacto de la interfaz: ¿Es necesario añadir/modificar qué interfaces? ¿Afecta al límite del presupuesto de API?
Dependencias subyacentes: ¿De qué capacidades existentes depende? ¿Cuáles aún no existen y deben construirse primero?
Forma aplicable: ¿Simulación, real, o ambas? Los criterios de aceptación pueden ser diferentes para cada una.
Disponibilidad para el integrador: ¿Para qué nivel de integrador está orientada? La complejidad del encapsulado/documentación correspondiente es diferente.
Compatibilidad hacia atrás: ¿Rompe los contratos de interfaz existentes? ¿Necesita versionado o una ruta de migración? Si se determina que es disruptivo, hay que preguntar además el rango de integradores/versiones afectados existentes y el período de obsolescencia aceptable, no solo anotar «si es disruptivo».
Impacto en la documentación y certificación: ¿Se necesita nueva documentación para desarrolladores? ¿Entra en el ámbito de evaluación de la certificación de integradores?
Seguridad y permisos (incluyendo modificaciones físicas): ¿A qué nivel de integrador/rol se abre esta capacidad? ¿Implica acciones peligrosas o de alto privilegio? Hay dos tipos de riesgos de seguridad, ambos deben preguntarse obligatoriamente, nunca se permiten por defecto:
- Llamadas peligrosas de software: Desbloquear límites de velocidad/par, desactivar parada de emergencia, control directo del chasis/articulaciones, saltar vallas de seguridad → preguntar «quién tiene derecho a llamarlas, si requiere doble confirmación/auditoría/puerta de permisos».
- Modificaciones físicas peligrosas (funcionalidades de extremo de hardware/modificación, prototipo J): El cliente conecta su propio hardware a un robot que se mueve y puede causar daños → preguntar línea roja de carga/par/alimentación y consecuencias de excederla, zona de modificación prohibida (qué interfaces si se tocan desactivan la parada de emergencia/mecanismo de seguridad), necesidad de recalibración de carga después de modificar el extremo, umbral de autorización/cualificación para la modificación, límites de garantía y responsabilidad, exención de responsabilidad y declaración de cumplimiento, alcance de la información abierta (por niveles de roles/control de acceso). Dar un número incorrecto de línea roja física = seguridad humana + responsabilidad legal.

Segunda capa · Dimensiones de detalles funcionales (fino)

Define «cómo funciona exactamente» la funcionalidad. Este es el punto clave para que el requisito alcance realmente el nivel de ingeniería — si cada una de las siguientes no se define claramente, I+D tendrá que improvisar cuando empiece a trabajar. Estas son dimensiones generales, y se deben tomar las sondas específicas por tipo de funcionalidad de references/detail-probes.md para hacer las preguntas concretas.

Pasos del flujo normal: Desglosa el comportamiento principal en pasos ordenados, indicando la entrada, salida y condición previa de cada paso.
Estados y ciclo de vida: ¿Qué estados tiene? ¿Cómo transita la máquina de estados? ¿Cuáles son las semánticas de start / pause / resume / stop / cancel? ¿Qué operaciones están permitidas en cada estado?
Activación y condiciones previas: ¿Bajo qué condiciones se puede iniciar? ¿Requisitos previos del sistema/recursos? ¿Cómo se manejan la activación repetida y la activación concurrente?
Manejo de excepciones y fallos: Enumera los posibles puntos de fallo de cada paso y determina la estrategia para cada uno — reintento / degradación / cancelación / notificación, así como quién se encarga de la limpieza y cómo termina el estado.
Escenarios límite y periféricos: Comportamiento en caso de entrada vacía, valores extremos, interrupción a medio camino, recursos insuficientes (batería/potencia de cálculo), cambios repentinos en las condiciones externas.
Detalles de los parámetros: Unidad de cada elemento configurable, rango de valores, valor predeterminado, cómo se valida un valor no válido.
Restricciones de tiempo y rendimiento: Tiempo de respuesta, umbral de tiempo de espera, rendimiento, requisitos de tiempo real.
Concurrencia y reentrada: ¿Se pueden ejecutar varias instancias en paralelo? ¿Qué ocurre si el llamador llama a la misma interfaz varias veces?
Observabilidad: ¿Qué consultas de estado, eventos/callbacks, registros o métricas necesita el llamador para percibir el estado de ejecución de la funcionalidad? La observabilidad se pregunta en dos niveles — orientada al llamador (consulta de estado/callback de evento/registro localizable, para que el integrador perciba el estado de ejecución) y orientada a la operación de la plataforma (qué métricas/puntos de instrumentación se usan en producción para juzgar la salud de esta funcionalidad, la tasa de adopción, la distribución de fallos, para la resolución de problemas y la toma de decisiones), esto último a menudo se pasa por alto.

No es necesario preguntar las 9 completamente. Determina cuáles son críticas para esta funcionalidad (el manejo de excepciones casi siempre es crítico para tareas largas, los detalles de los parámetros pueden ser ligeros para consultas puras), preguntas las críticas y deja el resto con valores predeterminados razonables o márcalas como [pendiente de confirmación].

Tres ejes ortogonales, se superponen: Los nueve puntos anteriores + la «clasificación de prototipos de funcionalidad A~J» de detail-probes son un eje cortado por tipo de funcionalidad (H = integración ecológica/implementación de referencia/documentación; I = empaquetado/distribución/instalación offline/despliegue; J = extremo de hardware/especificaciones de interfaz física y materiales de modificación, el contrato externo son interfaces físicas mecánicas/eléctricas); si una funcionalidad necesita además descomposición entre capas de implementación (toca capas distintas de la de segundo desarrollo, incluyendo las dos capas no ejecutables «capa de portal de documentación / capa de infraestructura de construcción·distribución», así como el eje de dependencias externas/EOL) es el segundo eje, ver paso 4 y references/cross-layer-routing.md; qué requisitos no funcionales (NFR) y principios del producto debe cumplir es el tercer eje, ver references/product-principles.md. Los tres no se sustituyen entre sí; si se activan, se superponen.

Reglas de aclaración interactiva

Este es el motor para convertir lo «simple» en «completo», deben cumplirse:

Una pregunta a la vez. Haz una pregunta, para, espera la respuesta del usuario y luego haz la siguiente. No lances una ráfaga de preguntas a la vez.
Bloqueante primero. Pregunta primero las brechas bloqueantes (rol, comportamiento principal, límites del alcance, pertenencia de capacidad), luego las no bloqueantes.
Cada pregunta incluye «por qué se pregunta» y respuestas candidatas. Con el formato: «¿A qué tipo de roles sirve principalmente esta función? (Esto determina en qué capa debe encapsularse) A. Lo usa directamente el usuario final B. Lo usa el integrador para segundo desarrollo C. Pruebas internas». Dar respuestas candidatas reduce significativamente el coste de la respuesta, y el usuario también puede elegir «ninguna de las anteriores» y añadir.
Controla la cantidad total para evitar la fatiga. En cada capa, una sola sesión debe tener como máximo 7~8 preguntas (cada capa cuenta por separado, no se solapan). Si hay demasiadas brechas, rellena primero las bloqueantes y marca el resto como [pendiente de confirmación], diciendo al usuario «las restantes las marco primero, puedes completarlas después». Las preguntas de la segunda capa sobre detalles funcionales son especialmente propensas a excederse; elige las que sean críticas para esta funcionalidad.
Después de responder, reformula para confirmar. Tras la respuesta del usuario, reformula tu comprensión en una frase antes de continuar, asegurándote de no haber malinterpretado.
Nunca decidas por el usuario. Las cuestiones que implican una concesión (hacer o no un límite, qué forma usar, quién es el propietario, qué capa debe cambiar) deben preguntarse, no asumirse por defecto. Marca explícitamente lo «aún no confirmado» como [pendiente de confirmación], en lugar de rellenar silenciosamente un valor que parezca razonable.

Escritura y legibilidad (obligatorio en la salida)

Los documentos de especificación son para que los lean personas y pasen una revisión, no para apilar puntos sueltos. Antes de generar el resultado, comprueba estos tres puntos:

Habla en lenguaje natural, con coherencia lógica. Las frases deben ser fluidas, los párrafos tener un hilo conductor. No apiles fragmentos de «piensa y escribe a trozos». Los términos/abreviaturas que aparezcan por primera vez, o bien se aclaran en el momento con una frase, o se recogen en «Glosario» — no dejes que el lector se atasque con palabras desconocidas. Mejor una frase de explicación coloquial de más que una frase de jerga de menos.
Contexto general + secciones por rol + glosario, estructura de tres partes. Un documento = ① Contexto general (todos lo leen primero: qué es, por qué, para quién, qué se entrega = «Definición en una frase» + «Origen y contexto» + «Glosario») + ② Secciones por rol («Guía de lectura» divide las secciones siguientes por lectores objetivo, cada rol lee solo lo suyo, no dejes que un equipo se ahogue en detalles que no le conciernen) + ③ «Glosario» (los términos se explican por separado, para quienes no los entienden).
Limita la forma de entrega externa, libera los detalles técnicos internos. La especificación fija «qué se entrega externamente» — firma de interfaz, forma del producto, forma del artefacto, plataformas/entornos compatibles, criterio de aceptación; pero no especifica en exceso «cómo se implementa internamente» — qué librería, qué arquitectura, qué herramienta de empaquetado/compilación, se lo dejas a I+D. Cada vez que escribas algo, pregúntate: «¿Esto es un contrato externo o una implementación interna?» Si es interno, cámbialo a «a determinar por I+D» o degrádalo a «sugerencia (no obligatoria)», no conviertas la especificación en un diseño técnico.
El lenguaje natural es para facilitar la comprensión, no para ser vago — los contratos externos deben ser rigurosos. El texto debe ser en lenguaje natural, pero todo lo que se refiera a estándares de salida externa — definición de interfaz (firma/parámetros/retorno/error), formato de mensajes y datos, matriz de plataformas compatibles que debe estar completa celda por celda, forma del artefacto, criterios de aceptación — debe ser preciso, sin ambigüedades y verificable, dando la firma cuando corresponda y completando la matriz cuando sea necesario. Claro y coloquial, pero el contrato no puede ser laxo. Al dividir por capítulos según los roles, concentra estos contratos rigurosos en secciones del tipo «contrato externo», para que I+D/pruebas puedan implementar y verificar según ellos.

Plantilla de salida

Una vez rellenadas las brechas bloqueantes (y pasada la compuerta de autocomprobación de principios del producto del paso 7), genera el resultado siguiendo estrictamente esta plantilla. La plantilla incluye una Definición de Ready (DoR) — solo cuando cada sección esté completa (o marcada explícitamente como [pendiente de confirmación]) esta especificación se considerará «I+D puede asumirla».

Convenciones:

Las secciones ya no se numeran fijamente, se referencian por el nombre de la sección, para evitar que los números se desplacen al insertar secciones.
Plantilla simplificada = el mismo conjunto de secciones sin la sección «Implementación entre capas y colaboración entre departamentos» y las dimensiones de NFR bajo demanda, para funcionalidades pequeñas de capa única de segundo desarrollo puro; plantilla completa para funcionalidades que abarcan capas o grandes.
Nomenclatura de interfaces/parámetros sigue en todo momento: todo en minúsculas con guiones bajos (snake_case), con palabras de significado completo y preciso, sin abreviaturas (por ejemplo, mic→microphone, cfg→config, num→count), y coherente con las interfaces existentes en el mismo dominio.
Un documento solo contiene una funcionalidad, y una funcionalidad solo genera un .md; múltiples funcionalidades tienen cada una su propio documento independiente (nunca se mezclan), pero una funcionalidad, incluso si abarca varias capas, no se divide en múltiples archivos — el contenido entre capas/departamentos se organiza en secciones dentro del mismo .md divididas por lectores objetivo.
Ubicación de la salida (directorio de salida estándar, debe cumplirse): La salida se escribe en un archivo (no solo se pega en la conversación) — en el directorio de salida feature-specs/<nombre de la funcionalidad>/<nombre de la funcionalidad>.md (relativo al directorio de trabajo actual/raíz del repositorio; por defecto raíz feature-specs/, el equipo puede cambiarlo en la sección de configuración). Una funcionalidad, un subdirectorio (para facilitar la colocación de imágenes/subproductos de esa funcionalidad), el nombre del archivo = nombre de la funcionalidad. Varias funcionalidades tienen sus propios subdirectorios independientes; las funcionalidades relacionadas se enlazan entre sí con enlaces relativos.
Funcionalidades entre capas (conclusión B/C): En la parte superior de esta plantilla, añade una tabla de «Guía de lectura (por lectores objetivo)», y en la sección «Implementación entre capas y colaboración entre departamentos», organiza el contenido de cada capa en subsecciones con el formato 【Lector objetivo: Grupo X】 (la plantilla está en references/cross-layer-routing.md「IX」) — todo dentro de este mismo .md, sin dividir en otros archivos.

# Especificación de funcionalidad: [Nombre de la funcionalidad]

> Estado: Borrador / Pendiente de revisión / Confirmado ｜ Solicitante: [Cliente/Socio] ｜ Fecha: AAAA-MM-DD ｜ Plantilla: Completa / Simplificada

## Guía de lectura (por lectores objetivo)
> **Cómo leer**: Primero lee el **Contexto general** («Definición en una frase», «Origen y contexto», «Glosario», todos lo leen); el resto de secciones, según la tabla siguiente, **cada uno lee lo suyo**, no es necesario leer todo. Las funcionalidades entre capas/departamentos deben rellenar esta tabla; para funcionalidades pequeñas de capa única, la tabla se puede simplificar, pero el contexto general y el «Glosario» siguen siendo necesarios.
| Lector objetivo | Secciones que debe leer principalmente | De qué es responsable |
| --- | --- | --- |
| Producto / Revisión | Definición en una frase, Origen y contexto, Posicionamiento de la capacidad, Límites del alcance, Historia + Aceptación, Evaluación de impacto, Autocomprobación de principios del producto, Registro de decisiones, Pendientes | Confirmar alcance/prioridad/concesiones |
| Grupo SDK de segundo desarrollo | Contrato de interfaz, Especificaciones de comportamiento, «Implementación entre capas y colaboración entre departamentos» · Sección de segundo desarrollo | Encapsulación externa y contrato de interfaz |
| Grupo de firmware | «Implementación entre capas y colaboración entre departamentos» · Sección de firmware, Contrato de transferencia entre capas | Confirmar/abrir interfaces de capacidad de la capa inferior |
| Grupo de algoritmos | «Implementación entre capas y colaboración entre departamentos» · Sección de algoritmos | Capacidad algorítmica lista/adaptada |
| Grupo de hardware | «Implementación entre capas y colaboración entre departamentos» · Sección de hardware | Forma de hardware/límites físicos |
| Pruebas / QA | Criterios de aceptación, Contrato externo (interfaz/mensaje/matriz de plataformas), Pendientes | Diseñar pruebas según criterios de aceptación y contrato, cubrir toda la matriz de plataformas |
(Los roles se **seleccionan según el tipo de funcionalidad**: funcionalidades en tiempo de ejecución = capas de implementación; funcionalidades de entrega/integración/instalación = empaquetado·DevOps／documentación／pruebas, etc. **Pruebas/QA siempre se incluye como un rol** — le interesa cómo se prueba la aceptación, qué plataformas cubrir, si el contrato externo es comprobable. Los roles no implicados se eliminan como filas enteras. **El cuerpo del texto debe, en la medida de lo posible, dividirse por capítulos según los roles**, para que cada rol pueda leer de un tirón su parte.)

## Definición en una frase
[Qué — qué hace esta funcionalidad, en una frase. ⚠ Si la conclusión de tocar fondo de capa del paso 4 es B/C, aquí solo se escribe el artefacto real entregable en esta ronda, no la capacidad completa de la capa inferior no lista]

## Origen y contexto (Por qué)
- Demanda original: [La frase original del cliente/socio, mantenla fiel al significado]
- Escenario de negocio: [Quién, en qué escenario, quiere resolver qué problema]
- Valor: [Por qué merece la pena hacerlo]

## Glosario (Términos)
> Términos/abreviaturas que se usan en el documento y que un lector no experto podría no entender, explicados en una frase coloquial (orientados a diferentes roles, no des por sentado que todos lo entienden); si no hay términos desconocidos, escribe «Ninguno».
| Término | Explicación en una frase |
| --- | --- |
| … | … |

## Posicionamiento de la capacidad
- Nivel: L1 / L2 / L3  [Si el grupo A de la configuración no está rellenado, marca `[pendiente de confirmación]`; **si es una funcionalidad no ejecutable de entrega/distribución/instalación/documentación, marca `N/A (no es una funcionalidad de capacidad, solo cae en el eje de la capa de implementación)`**]
- Dominio de capacidad: [Uno de los cinco dominios, o «Multi-dominio: X + Y», o N/A]
- Impacto multi-dominio: [Qué otros dominios/equipos implicará]
- Conclusión entre capas (paso 4): Funcionalidad de capa única (SDK de segundo desarrollo) / ⚠ No entregable de forma independiente solo con la capa de segundo desarrollo: el cambio más profundo cae en <capa>, necesita que <departamento> entregue primero <capacidad> para que la capa de segundo desarrollo pueda encapsularla

## Límites del alcance
- Incluye (In Scope):
  - …
- Excluye explícitamente (Out of Scope):   ← Obligatorio, evitar que I+D expanda el alcance
  - …
- Marcadores de funcionalidades relacionadas (de la derivación de requisitos, no se hacen en esta ronda):
  - …

## Implementación entre capas y colaboración entre departamentos
> Solo es obligatorio si el paso 4 determina que esta funcionalidad abarca capas de implementación (toca capas distintas de la capa SDK de segundo desarrollo); para capa única de segundo desarrollo puro, escribe «Funcionalidad de capa única (SDK de segundo desarrollo), sin colaboración entre capas» y salta esta sección (la plantilla simplificada no incluye esta sección directamente).
> **Forma de salida:** Una funcionalidad solo genera un `.md`; esta sección se organiza en subsecciones por capa, dentro del mismo archivo. Para cada capa que se modifique, escribe siguiendo esta estructura:
> `【Lector objetivo: Grupo X】`
> - Cambios necesarios: [Qué debe cambiar en esta capa]
> - Dependencias: [De qué capacidades/entregas de otras capas depende]
> - Contrato de transferencia entre capas (definición de pertenencia): [Qué expone esta capa a la capa superior, y quién tiene el derecho de definición]
> - Elementos pendientes de confirmación entre departamentos (triplete: propietario de la verificación｜plazo｜suposición por defecto/plan de degradación):
>   - …
> - Ruta de escalamiento: [Si hay bloqueo entre capas, cómo escalar]
> (Repite para cada capa que necesite cambios: segundo desarrollo, firmware, algoritmo, hardware, portal de documentación, infraestructura de construcción/distribución)

## Especificaciones de comportamiento
### Flujo normal (pasos)
1. [Paso 1]: condiciones previas → entrada → salida
2. [Paso 2]: …
…

### Estados y ciclo de vida
- Estados: [idle, ready, running, paused, completed, error…]
- Transiciones: [qué acción provoca qué cambio de estado]

### Condiciones de activación y requisitos previos
- Para iniciar se necesita: [condiciones del sistema/datos/permisos]
- Activación repetida / concurrente: [cómo se maneja]

### Manejo de excepciones
| Paso | Posible fallo | Estrategia | Responsable |
| --- | --- | --- | --- |
| … | … | Reintento / Degradación / Cancelación / Notificación | … |

### Escenarios límite
- [Escenario límite 1]: comportamiento
- [Escenario límite 2]: comportamiento
…

### Detalles de los parámetros
| Parámetro | Unidad | Rango | Valor predeterminado | Validación de valor no válido |
| --- | --- | --- | --- | --- |
| … | … | … | … | … |

### Restricciones de tiempo y rendimiento
- Tiempo de respuesta: [< X ms]
- Tiempo de espera: [Y s]
- Rendimiento: [Z llamadas/s]

### Concurrencia y reentrada
- [¿Se pueden ejecutar múltiples instancias en paralelo?] [¿Qué ocurre si se llama a la interfaz varias veces?]

### Observabilidad
- **Orientada al llamador (integrador)**: [Consultas de estado, eventos/callbacks, registros]
- **Orientada a la operación de la plataforma**: [Métricas/puntos de instrumentación para producción]

## Contrato de interfaz (borrador)
### Nuevas interfaces
| Interfaz | Parámetros de entrada | Valor de retorno / evento | Notas |
| --- | --- | --- | --- |
| `nombre_funcion(param1: tipo1, param2: tipo2) -> tipo_retorno` | … | … | … |

### Modificaciones de interfaces existentes
| Interfaz | Cambio | Impacto |
| --- | --- | --- |
| … | … | … |

### Formato de mensajes / datos (si procede)
- [Definición del formato, campos, tipos, ejemplo]

## Dependencias y requisitos previos
- [Dependencia 1]: [Estado, propietario, fecha prevista]
- [Dependencia 2]: …

## Evaluación de impacto · Compatibilidad · Estrategia de publicación
- Compatibilidad hacia atrás: [Sí / No / Con ruta de migración. Si es disruptivo, indicar el alcance de los integradores/versiones afectados y el período de obsolescencia]
- Impacto en el presupuesto de API: [Nuevas interfaces: X, modificadas: Y, total actual: Z, límite: Z_max]
- Impacto en la documentación y certificación: [Nuevo contenido de documentación, cambios en la certificación de integradores]
- Seguridad y permisos: [Nivel de integrador/rol al que se abre, puertas de permisos necesarias, riesgos de seguridad y contramedidas]
- Entregas / versiones objetivo: [Versión objetivo, esfuerzo estimado (días-persona), capacidad del pipeline]
- Compuertas de proceso: [Compuertas que se deben pasar, artefactos de entrega necesarios]

## Autocomprobación de principios del producto
| Principio | Conclusión | Notas / Concesión |
| --- | --- | --- |
| [Principio 1] | ✓ / ⚠ / — | … |
| [Principio 2] | … | … |
| … | … | … |
> (Si es una funcionalidad ligera con todos ✓/—, se puede comprimir en una línea: «Todos los principios aplicables cumplen / no aplican, sin conflictos». Cualquier ⚠ debe tener la concesión explicada.)

## Registro de decisiones clave
| Decisión | Alternativa considerada | Razón / Contexto | Fuente |
| --- | --- | --- | --- |
| … | … | … | [Discusión con el cliente / Concesión de principio / Confirmación del departamento] |

## Pendientes de confirmación
| Elemento | Tipo (bloqueante / no bloqueante) | Propietario de la verificación | Plazo | Suposición por defecto si no hay respuesta |
| --- | --- | --- | --- | --- |
| … | … | … | … | … |

Auromix/feature-spec-builder

¿Qué es feature-spec-builder?

Preguntar en tu IA favorita

Documentación